Guide to Google Anthos architecture and management

Kubernetes pain points and Anthos fundamentals

Kubernetes is great at managing a cluster of hosting resources, but it requires additional features to handle multiple autonomous resource pools, such as those hosted across multiple domains on premises or in various clouds. Without tools to manage multiple resource pools, IT teams would struggle with cooperative missions like cloud bursting or backup.

IT teams can use Anthos for federated operations management. It's a technique that accommodates application deployments across multiple resource pools, while still maintaining the identity and practices associated with each individual resource type. While Anthos is most often discussed for hybrid and multi-cloud applications, it can also support federated operations for VMs as well as containers. This makes it an almost-universal management framework.

Anthos architecture includes:

• Kubernetes, hosted in the data center, in Google Kubernetes Engine (GKE) in Google Cloud or in another public cloud.
• Anthos Config Management, for each cloud or domain.
• Istio service mesh for policy control, even if the applications don't require it.
• Google Operations for monitoring.
• Any additional Anthos tools desired from the Google Cloud Platform (GCP) Marketplace.

Google Connect for Anthos is the central networking element that links all these components. GKE is primarily managed through the Google Cloud Console, so a small GKE element is normally the logical center of Anthos. The rest of the hosting can be on any cloud or in any data center. You can also host GKE Anthos management in some data centers.

Key Google Anthos concepts

IT teams will need to understand a few important concepts before they get started. These concepts will guide choices around resource pooling, management and access.

Environs

Google Anthos controls environs, which are clusters of resources typically related to a common application set. An environ is expected to be allocated and consumed as a single logical pool, and resources have to be registered as a part of an environ in order to be used. Registration connects cluster and cloud resources to the single, distributed, Anthos control plane.

Inside an environ, workload identity pools are used for service authorization, including Istio service mesh access. Resources should not be shared across environs.

Grouping

Grouping is central to policy control in Anthos. It links related resources so Anthos recognizes that certain resources could be the targets of a common set of policies.

Generally, a group should contain resources that host interactive application components, support a common mission such as production or testing, and are likely to host related application components. It's worth taking some time to test grouping concepts with policies to make sure that you've defined groups correctly.

Sameness

Sameness expresses equivalence in some specific area, such as namespace, service and identity. The purpose of sameness is to define the equivalence of things that are functionally the same but are in different clusters.

Namespace and service sameness can indicate that two services are the same, even though they are in different clusters. Identity sameness says that two services have the same access to external resources.

Anthos management considerations

You can use identity sameness and namespace conventions to manipulate clusters, resources and services and create relationships between them. This facilitates the creation of simple policy sets to govern behavior. Without this feature, IT teams might have to define central policies in cluster- or cloud-specific ways, which would make Anthos little more than a repository for a diverging set of cluster policies.

Functionally, Anthos creates a GKE-hosted control plane that extends across all the connected resources and through which policies are exchanged. Within each cluster, an Anthos Config Management instance -- and Config Sync for non-GKE clusters -- provides the policy control resource, and the policies are stored in a central Git repository. All the standard Kubernetes policies are supported and can be applied as central policies via the single control plane to all clusters.

There is a tradeoff between the number of different environs and the ease of policy management and isolation. If an administrator creates a small number of Anthos environs, they'll find it easy to establish policies to manage applications and services but more difficult to isolate service and resource access. If the admin creates a large number of environs, then resource and service isolation is easy but policy control management is more challenging because of the number of environs that need to be controlled.

Proper use of groups and sameness can make Anthos policies, and multi-cloud-and-cluster control, a lot easier. A single policy can define entire classes of service behavior via sameness. A group can define broad swaths of resources, so the policy can cover a wide range of service deployments in a single statement.

However, this approach is susceptible to errors or bad behavior. If something is stated to be the same and isn't, it can create major security and stability issues, and this is true with groups as well.

Anthos limitations and competitors

GKE hosting of Anthos is a limitation for some organizations that don't already use Google Cloud. However, Anthos can also be hosted on Anthos GKE On-Prem, which is GKE platform software hosted on premises or on VMs. This is currently limited to vSphere data centers, as a part of Google's engagement with VMware.

Google is expected to expand Anthos to include the ability to manage a wider variety of cloud and data center resources. Meanwhile, IT teams can also use a range of tools to convert VM and bare metal workloads to containers and Kubernetes, and then to Anthos. For container-centric users, this is obviously the best approach.

Anthos isn't the only Kubernetes federation game in town. Red Hat's OpenShift has multi-cloud and multi-cluster capabilities, but they only work in Red Hat Enterprise Linux deployments and are generally less fully featured for cloud-native service deployments. VMware Tanzu is more open than OpenShift and offers slightly better cloud-native support, but it's a relatively new offering that's still being refined.

Cloud provider services that compete with Anthos are AWS Outposts and Azure Arc. The former represents a fairly basic hybrid cloud strategy of extending applications to on-premises servers managed by AWS.

Azure Arc is similar in architecture to Anthos, but it's not as tightly linked to Kubernetes and cloud-native behavior. That makes Anthos, overall, the most advanced hybrid-and-multi-cloud orchestration and management tool for those prepared to do more cloud-native development.