Anthos was Google’s hybrid and multi-cloud platform, and its pieces now live under newer names.

Anthos was introduced as a platform for running modern applications consistently across Google Cloud, on-premises data centers, and other public clouds. Its heart was Kubernetes, the open source system for running containers, together with tools to manage many clusters as a group, apply common settings and security rules, and connect services securely.

Product names have shifted since then. Google’s current GKE Enterprise documentation page is now marked as an archive. It states that GKE Enterprise features have either become part of standard Google Kubernetes Engine, known as GKE, or are products you can use alongside it, and that GKE is now a single offering with no editions or tiers. The same page lists Anthos only in archived sections covering releases from version 1.0 in June 2019 through 1.7.2 in June 2021, along with older component names such as Anthos Config Management, Anthos Service Mesh, and Anthos clusters. Google’s deployment options page says Anthos appears only in some documentation link paths.

From my own background knowledge, which I could not fully verify in the pages I read, the sequence was roughly this: the on-premises Anthos offerings became part of Google Distributed Cloud, the broader Anthos bundle was renamed GKE Enterprise, and then the bundle’s features were folded into GKE and related products. If you need exact dates or the current commercial packaging, check Google’s current documentation and your account team.

Running applications in many places is hard to keep consistent and secure.

Few large organizations run everything in one place. Some applications stay in a company data center because of regulations or old hardware. Some run on Google Cloud, others on a different cloud, and some at the edge in factories, shops, or hospitals. Each location tends to develop its own tools, its own settings, and its own habits. Over time this produces several pains.

You cannot understand Anthos without first understanding clusters.

Containers

A container is a lightweight package holding an application and everything it needs to run. Because the package carries its own needs, it behaves the same on a laptop, a data center server, or a cloud machine.

Kubernetes

Kubernetes is an open source system that runs and manages containers across a group of machines. You tell it what you want, for example “keep three copies of this web service running,” and it works to make that true, restarting failed containers and spreading them across machines. A group of machines run by Kubernetes is called a cluster.

GKE

Google Kubernetes Engine, or GKE, is Google’s managed Kubernetes service. Google looks after the control plane, the brain of the cluster, so you do not have to run it yourself.

The platform’s promise is one way of working, whatever the location.

Google’s deployment options page describes the environments that its enterprise Kubernetes platform covers. They are GKE clusters on Google Cloud; Google Distributed Cloud, which includes on-premises VMware and bare metal deployments and connected deployments at the edge; and GKE Multi-Cloud, which covers GKE on AWS, GKE on Azure, and attached clusters, meaning third-party Kubernetes clusters registered to a fleet.

flowchart TD
  CP["Google Cloud control plane and fleet"] --> G1["GKE clusters on Google Cloud"]
  CP --> G2["Google Distributed Cloud on VMware"]
  CP --> G3["Google Distributed Cloud on bare metal"]
  CP --> G4["GKE on AWS"]
  CP --> G5["GKE on Azure"]
  CP --> G6["Attached third-party clusters"]
        

A fleet is a logical group of clusters managed together.

The central organizing idea is the fleet. A fleet groups clusters so that you can apply settings, policies, and features to all of them at once instead of one by one. In Google’s own earlier edge article about Anthos, fleets are described as a way to group clusters logically by communication patterns, location, environment, or administrator, reducing the need for custom management tooling. Google’s deployment options page notes that some features require a cluster to be registered to a fleet, and that attached clusters are third-party Kubernetes clusters registered to a fleet.

flowchart LR
  subgraph F["Fleet"]
    C1["GKE cluster: production"]
    C2["On-premises cluster: factory"]
    C3["AWS cluster: partner region"]
  end
  P["Shared policies, configuration, and mesh"] --> F
  V["Single view in Google Cloud console"] --> F
        

Several components together deliver consistency, security, and visibility.

Google’s archived GKE Enterprise page lists the components that used to form the Anthos family and its successor. Under configuration management, it names Config Sync, Config Controller, and Policy Controller. It also lists Knative serving; Google Distributed Cloud software for VMware and bare metal; GKE Multi-Cloud, with attached clusters, GKE on AWS, and GKE on Azure; and other Google Cloud products such as Cloud Service Mesh, Binary Authorization, Cloud Logging, Cloud Monitoring, and Migrate to Containers. The deployment options page adds GKE Identity Service, the security posture dashboard, Multi-Cluster Ingress, node-to-node encryption, and fully qualified domain name network policies.

Config Sync keeps clusters matching settings stored in a central place.

Config Sync follows a practice called GitOps. In GitOps, the desired state of your systems is written in files stored in a version-controlled repository, and an automated agent continuously makes the real systems match those files. Instead of someone logging in to each cluster and changing things by hand, you change the files once, review the change like any other, and the agent applies it everywhere.

sequenceDiagram
  participant D as Developer
  participant R as Central repository
  participant S as Config Sync agent
  participant C as Cluster
  D->>R: Propose a configuration change
  R-->>D: Review and approve
  S->>R: Watch for changes
  R-->>S: New approved version
  S->>C: Apply changes to match
  C-->>S: Report status
        

Policy Controller checks what is being deployed and blocks what breaks the rules.

Policy Controller lets you define rules about what is allowed in your clusters. For example, you can require that every workload has an owner label, forbid containers from running with excessive privileges, or insist that images come only from approved registries. It builds on an open source project called Open Policy Agent Gatekeeper, as I understand it from general knowledge. Rules are checked when someone tries to create or change something, and existing resources can also be audited for violations.

flowchart LR
  U["Someone deploys a workload"] --> PC{"Policy Controller check"}
  PC -->|"Meets rules"| OK["Accepted into the cluster"]
  PC -->|"Breaks a rule"| NO["Rejected with a reason"]
        

A service mesh manages how application pieces talk to each other.

Modern applications are often split into many small services that call one another over the network. A service mesh adds a layer that handles this traffic. Google’s earlier edge article describes its mesh, then called Anthos Service Mesh, as based on open source Istio, providing traffic management, tracing, monitoring, logging, and zero-trust security for microservices. Today the product is called Cloud Service Mesh.

flowchart LR
  A["Service A + helper proxy"] |"encrypted, authenticated"| B["Service B + helper proxy"]
  B |"encrypted, authenticated"| C["Service C + helper proxy"]
  M["Mesh control plane"] -.->|"rules and certificates"| A
  M -.-> B
  M -.-> C
        

For clusters in your own data center or at the edge, Google offers software you install yourself.

Google’s archived page lists Google Distributed Cloud software as available on VMware and on bare metal. The deployment options page also mentions connected deployments at the edge. In these setups, you supply the servers, and Google’s software turns them into Kubernetes clusters that connect to Google Cloud for management, policy, and visibility.

Google’s tools can manage Kubernetes on other clouds as well.

GKE Multi-Cloud, according to Google’s archived page, comprises attached clusters, GKE on AWS, and GKE on Azure. With GKE on AWS and Azure, Google’s software creates and manages Kubernetes clusters on machines in those clouds. With attached clusters, you take a conformant Kubernetes cluster that already exists, run by someone else, and register it to your fleet, so it can receive shared policies and appear in the same dashboards.

flowchart TD
  F["Fleet in Google Cloud"] --> A1["Cluster created by Google tools on AWS"]
  F --> A2["Cluster created by Google tools on Azure"]
  F --> A3["Existing cluster from another provider: attached"]
  F --> A4["Cluster on Google Cloud"]
        

Security works best when the same layers apply everywhere.

The platform brings several security tools together. Google’s pages mention Binary Authorization for allowing only trusted images, Policy Controller for admission rules, GKE Identity Service for signing in with existing identity providers, a security posture dashboard, node-to-node encryption, and fully qualified domain name network policies. The service mesh adds encrypted, authenticated service-to-service traffic.

You cannot manage what you cannot see.

Google’s pages list Cloud Logging and Cloud Monitoring among the related products, and note logging and monitoring for system components as part of the features enabled with the GKE API. Together with the mesh’s tracing and the Google Cloud console’s fleet views, they let operators see health, performance, and problems across clusters in different places.

Many companies start by moving older applications into containers.

Not every application is born in a container. Many run on virtual machines and were built years ago. Google lists Migrate to Containers among the related products, a tool meant to help move such workloads into containers. The deployment options page also refers to VM management for non-Google Cloud environments, and Google’s pricing page mentions VM Runtime on Google Distributed Cloud for bare metal, which lets virtual machines run alongside containers on the same cluster.

flowchart LR
  VM["Application on a virtual machine"] --> MIG["Migrate to Containers"]
  MIG --> CT["Application in a container"]
  CT --> CL["Runs on a cluster in the fleet"]
  VM -.->|"or run the VM alongside containers"| VR["VM Runtime on the cluster"]
        

Google’s setup guidance boils down to a few clear steps.

Google’s deployment options page outlines these steps for getting the enterprise Kubernetes features.

A sensible learning path for beginners

Costs depend on where clusters run and which add-on products you enable.

Pricing has changed along with the product names, so treat this chapter as a guide to how to think about cost, not as a quote. Google’s GKE pricing page, at the time of writing, lists hourly rates for multi-cloud and on-premises environments, charged on vCPUs under management. A vCPU is under management when the GKE control plane sees it as schedulable compute capacity. For on-premises options, the count excludes the admin cluster and control plane nodes, and for bare metal with hyperthreading enabled, one physical CPU counts as two vCPUs.

Related GKE charges

The same pricing page states that the standard cluster management fee is 0.10 US dollars per cluster per hour for all GKE clusters, and that a free tier gives 74.40 US dollars per billing account per month, equivalent to one free Autopilot or zonal Standard cluster. It also says this free tier does not apply to the hybrid and multi-cloud SKUs. I could not confirm from the pages I read what extra per-vCPU charge, if any, applies to GKE clusters on Google Cloud for the fleet features. Ask your account team or check the current pricing page.

Teams that succeed with fleets share a few habits.

Patterns that work

Anti-patterns to avoid

A fleet platform is powerful, but it suits specific situations.

Alternatives

flowchart TD
  Q["How many places do your clusters run?"] --> A{"Only Google Cloud?"}
  A -->|"Yes"| G["Plain GKE, add fleet features as needed"]
  A -->|"No"| B{"On-premises or edge needed?"}
  B -->|"Yes"| D["Consider Google Distributed Cloud with a fleet"]
  B -->|"No, other clouds only"| M["Consider GKE Multi-Cloud or attached clusters"]
        

Other providers offer similar hybrid and multi-cloud ideas under different names.

Here is how organizations typically use these ideas.

Keep this short list close when you plan or review a fleet.

Quick answers to the questions beginners ask most.

Google’s hybrid and multi-cloud platform for running and managing Kubernetes clusters consistently across Google Cloud, on-premises, and other clouds.

Google’s current documentation shows Anthos only in archived sections, and says the former GKE Enterprise features have become part of GKE or are products to use alongside it. Check with Google or your account team for the current packaging.

The pieces are now known by names like GKE, GKE Multi-Cloud, Google Distributed Cloud, Config Sync, Policy Controller, and Cloud Service Mesh. The exact timeline of renames is something to verify in current Google material.

A logical group of clusters that you manage together, applying shared settings, policies, and features.

It keeps clusters matching configuration stored in a central repository, following the GitOps approach.

It enforces rules about what may be deployed in clusters, rejecting changes that break them and auditing existing resources.

A service mesh, formerly branded Anthos Service Mesh and based on Istio, that provides traffic management, observability, and secure service-to-service communication.

Yes. Google lists GKE on AWS and GKE on Azure, plus attached clusters for third-party Kubernetes clusters registered to a fleet.

Yes, through Google Distributed Cloud software on VMware or bare metal, plus connected edge deployments.

Multi-cloud and on-premises options are listed with hourly rates charged on vCPUs under management, and add-on products have their own pricing. Other clouds bill their own resources separately. Verify current figures before budgeting.

Not necessarily. Plain GKE may be enough, though fleet features such as Config Sync and Policy Controller can still help if you run many clusters.

Learn Kubernetes and a single GKE cluster first, then try Config Sync, then Policy Controller in audit mode, then register a second cluster to a fleet.

Anthos was Google’s answer to a common problem: organizations run Kubernetes in many places and need consistent control. Its name has faded from current documentation, but its ideas continue in GKE, fleets, Google Distributed Cloud, GKE Multi-Cloud, Config Sync, Policy Controller, Cloud Service Mesh, Binary Authorization, and related tools. A fleet groups clusters wherever they run. Config Sync applies configuration from a repository, Policy Controller guards what is deployed, and the service mesh secures and observes service traffic. Clusters can live on Google Cloud, in your data center or edge sites, on AWS or Azure, or be attached from other providers. Costs combine Google’s charges, other providers’ bills, add-on products, and your own hardware. Understand the ideas, check current names and prices, start small, and expand deliberately.