Fleet management overview
Anthos offers a set of capabilities that helps you and your organization (from infrastructure operators and workload developers to security and network engineers) manage clusters, infrastructure, and workloads, on Google Cloud and across public cloud and on-premises environments. These capabilities are all built around the idea of the fleet: a logical grouping of Kubernetes clusters and other resources that can be managed together. Fleets are managed by the Fleet service, also known as the Hub service.
This page describes our expanding portfolio of multi-cluster management capabilities and provides resources to get started managing your fleet.
Typically, as organizations embrace cloud-native technologies like containers, container orchestration, and service meshes, they reach a point where running a single cluster is no longer sufficient. There are a variety of reasons why organizations choose to deploy multiple clusters to achieve their technical and business objectives; for example, separating production from non-production environments, or separating services across tiers, locales, or teams. You can read more about the benefits and tradeoffs involved in multi-cluster approaches in multi-cluster use cases.
Anthos and Google Cloud use the concept of a fleet to simplify managing multi-cluster deployments. A fleet provides a way to logically group and normalize Kubernetes clusters, making administration of infrastructure easier. A fleet can be entirely made up of Google Kubernetes Engine clusters on Google Cloud, or include clusters outside Google Cloud. A growing number of Anthos and Google Cloud components use fleet concepts such as identity sameness and namespace sameness to simplify working with multiple clusters.
Adopting fleets helps your organization uplevel management from individual clusters to entire groups of clusters. Furthermore, the normalization that fleets require can help your teams adopt similar best practices to those used at Google.
- To learn more about how fleets work, and to find a complete list of fleet-enabled features, see How fleets work.
To learn about current limitations and requirements for using fleets in multi-cluster deployments, as well as recommendations for implementing fleets in your organization, see Fleet requirements and best practices.
To help you implement fleets in your own systems, read about hypothetical scenarios that use fleets in Fleet examples.
Creating a fleet
Creating a fleet involves registering the clusters you want to manage together to a fleet in your chosen fleet host project. Some cluster types are automatically registered at cluster creation time, while other cluster types must be manually registered. You can read more about how this works in the Fleet creation overview, and follow the linked instructions to start adding clusters to your fleet.
When you add a cluster outside Google Cloud to your fleet, a Connect Agent is installed on the cluster to establish control plane connectivity between the cluster and Google Cloud. The agent can traverse NATs, egress proxies, VPNs, and other interconnects that you have between your environments and Google. Your Kubernetes clusters and their API servers do not need public or externally exposed IP addresses. To learn more about the Connect Agent, see the Connect Agent overview.
Authenticating to clusters
Connecting and authenticating users and service accounts to clusters across multiple environments can be challenging. With fleets, you can choose from two options for consistent, secure authentication to clusters for all your organization's developers and admins.
Connect gateway: Use this option if you want to use Google Cloud as your identity provider. The Connect gateway builds on fleets to provide a consistent way to connect to and run commands against your registered clusters from the command line, and makes it simpler to automate DevOps tasks across multiple clusters. Users do not need direct IP connectivity to a fleet cluster to connect to it using this option. Find out more in the Connect gateway guide.
Anthos Identity Service: Use this option if you want to use your existing third-party identity provider, such as Microsoft ADFS. Anthos Identity Service lets you configure your fleet clusters so that users can log in with their existing third-party ID and password. OIDC and LDAP providers are supported. Find out more in Introducing Anthos Identity Service.
With either approach, users can log in to clusters from the command line or from the Google Cloud console.
Google Cloud console
The Google Cloud console provides a central user interface for managing all of your fleet clusters no matter where they are running. After you have registered your clusters to your fleet, you can log in to view, monitor, debug, and manage your workloads.
To learn more and to get started, see Work with clusters from the Google Cloud console.
Who can use fleet management features?
If you just want to use the Anthos features described in this guide on Google Cloud, you can register GKE clusters to a fleet and use some enterprise and multicluster features at no additional charge above regular GKE pricing. You can then pay separately for additional fleet-enabled features such as Anthos Config Management and Anthos Service Mesh.
If you want to register clusters outside Google Cloud to your fleet, or if you want to enable and use multiple Anthos features for a single per-vCPU charge, you must enable the entire Anthos platform. Find out how to do this in the Anthos pricing guide.
For complete details of which features are included in each option, see the Anthos Deployment Options page.
While managing more than one cluster has its challenges, there are many reasons to deploy multiple clusters to achieve technical and business objectives. Find out more in our Multi-cluster use cases guide.
- Learn more about fleets in How fleets work
- Get started creating your fleet following the Fleet creation overview
- Learn more about fleet security features in Secure your fleet