Environs in Google Cloud are logical groups of Kubernetes clusters and other resources that can be managed together, created by registering clusters to Google Cloud using Connect. The Connect gateway builds on the power of environs to let Anthos users connect to and run commands against registered Anthos clusters in a simple, consistent, and secured way, whether the clusters are on Google Cloud, other public clouds, or on premises, and makes it easier to automate DevOps processes across all your clusters.
This guide assumes that you are already familiar with some basic environ concepts, and with registering clusters to Google Cloud. If not, you can find out more in the Environs guide and in Registering a cluster. You should also be familiar with Kubernetes tools and concepts, including
client-go (if you want to use the gateway for automation purposes), role-based access control (RBAC), and core Kubernetes Resources.
For more general information about working with multiple clusters in Anthos and Google Cloud, see Multi-cluster management.
Why use the Connect gateway?
There are many challenges in managing workloads when your clusters are running in multiple clouds and hybrid environments. Clusters may be running in different virtual private clouds (VPCs) and leverage different identity providers, making connectivity, authentication, and authorization more complicated. Sometimes, just finding out which clusters exist across these environments is difficult.
The Connect gateway makes it easy to:
- Discover what clusters exist (on Google Cloud, on another public cloud, or on premises) and are registered to your environ through a simple query.
- Connect to a desired cluster using the same infrastructure we use to display registered Anthos clusters in the Cloud Console.
- Authenticate using the same identities you use with Google Cloud services.
- Authorize consistently across all your clusters registered in an environ.
The gateway authenticates your Google Cloud identity and provides the connection to the cluster's API server via the Connect service.
You can interact with clusters directly yourself through the gateway using command line tools that accept a
kubeconfig such as
kubectl. You can also easily leverage the gateway with your build pipelines and other DevOps automation. You can see an example of how to do this in our Integrating with Cloud Build tutorial.
You can also use the Connect service to connect to registered clusters outside Google Cloud with your Google Cloud identity in the Cloud Console. To do this, follow the instructions in Logging in to a cluster from the Cloud Console.
How it works
Here is the flow that a typical user or service (such as a CI/CD pipeline) performs to use the Connect gateway, after appropriate authentication and authorization is configured. For more detailed user instructions, see our usage guide.
The user or service discovers clusters by listing environ Membership resources with the
gcloud container hub memberships list
The user or service fetches the Connect gateway-specific
kubeconfigneeded to reach their selected cluster by using the
gcloud beta container hub memberships get-credentials membership-name
If you're already familiar with using the
gcloudcommand line tool with GKE, this is similar to running
gcloud container clusters get-credentialsusing your Google Cloud account, letting you (if authorized) access any cluster registered and connected within your project's environ.
The user or service executes their commands as they normally would with
client-go, using the downloaded
- The user/service is authenticated by the Connect gateway, and authorization is checked to ensure they have permission to use the gateway.
- The request is forwarded through the Connect service and Connect Agent to the corresponding Kubernetes API server.
- The Kubernetes API server authorizes the request, which requires that the Connect agent is authorized to impersonate the user or service, and that the user or service is authorized to execute the desired request.
The total latency of a request via the gateway can be divided into two parts: the RTT (Round Trip Time) from the Connect gateway service to the Connect agent, and the request execution time inside the cluster. The extra latency brought by the RTT is p95<500ms and p99<1s. Note that most
kubectl commands perform a series of several different requests, each requiring a round-trip, before rendering a response to the user.
- Learn how to set up the Connect gateway for users and service accounts
- Learn how to connect to and run commands against a registered cluster using the Connect gateway
- See an example of how to use the Connect gateway as part of your DevOps automation in our Integrating with Cloud Build tutorial.