This page describes the architecture of the Google Kubernetes Engine (GKE) clustersthat run your containerized workloads. Use this page to learn about the controlplane, nodes, and how the various GKE cluster components interactwith each other.

This page is for Admins, Architects, and Operators whodefine IT solutions and system architecture. To learn more about common rolesand example tasks that we reference in Google Cloud content, seeCommon GKE user roles and tasks.

Before reading this page, ensure that you're familiar with theKubernetes cluster architecture.

A GKE cluster consists of acontrol plane and workermachines callednodes. The control plane and nodes make up the Kubernetescluster orchestration system. GKE Autopilot manages theentire underlying infrastructure of clusters, including the control plane,nodes, and all system components.

If you use GKEStandard mode, GKE manages the control plane and systemcomponents, and you manage the nodes.

The following diagram shows the architecture of a GKE cluster:

This diagram shows the following components:

• Control plane: managed by GKE. Runs the Kubernetes API server,workload controllers, Kubernetes scheduler, and cluster state storage.
• Nodes: managed by GKE in Autopilot mode, and managedby customers in Standard mode. All of your Pods run in nodes.
• Other Google Cloud services: available to integrate withGKE.

About the control plane

The control plane runs processes such as the Kubernetes API server, scheduler,and core resource controllers. GKE manages the control planelifecycle from cluster creation to deletion. This includes upgrades to theKubernetes version running on the control plane, which GKEperforms automatically, or manually at your request if you prefer to upgradeearlier than the automatic schedule.

Control plane and the Kubernetes API

The control plane is the unified endpoint for your cluster. You interact withthe control plane through Kubernetes API calls. The control plane runs theKubernetes API server process (kube-apiserver) to handle API requests. You canmake Kubernetes API calls in the following ways:

• Direct calls: HTTP/gRPC
• Indirect calls: Kubernetes command-line clients such askubectl, or theGoogle Cloud console.

The API server process is the hub for all communication for the cluster. Allinternal cluster components such as nodes, system processes, and applicationcontrollers act as clients of the API server.

Your API requests tell Kubernetes what yourdesired state is for the objectsin your cluster. Kubernetes attempts to constantly maintain that state.Kubernetes lets you configure objects in the API eitherimperatively ordeclaratively.

To learn more about object management in Kubernetes, refer to the followingpages:

• Understanding Kubernetes objects
• Kubernetes object management

Control plane and the cluster state database

The open source Kubernetes project usesetcdas the storage database for all cluster data by default. The cluster stateis kept in a key-value store that contains information about the state of everyKubernetes API object in your cluster. For example, the cluster state databasestores every Secret, ConfigMap, and Deployment.

GKE clusters store the cluster state in one of the followingkey-value stores:

• etcd: GKE stores the cluster state in etcd instances thatrun on every control plane virtual machine (VM).
• Spanner: GKE stores the cluster state inSpanner. The Spanner databasedoesn't run in the cluster control plane.

Regardless of the type of database, every GKE cluster serves theetcd API in the control plane. The Kubernetes API server uses the etcd API tocommunicate with the backend cluster state database.

Control plane and node interaction

The control plane manages what runs on all of the cluster's nodes. The controlplane schedules workloads and manages the workloads' lifecycle, scaling, andupgrades. The control plane also manages network and storage resources for thoseworkloads. The control plane and nodes communicate with each other usingKubernetes APIs.

Control plane interactions with Artifact Registry

When you create or update a cluster, GKE pulls container imagesfor the Kubernetes system software running on the control plane and nodes fromArtifact Registry repositories in thepkg.dev or thegcr.io domain. An outageaffecting these registries might cause the following actions to fail:

• New cluster creation
• Cluster version upgrades

Disruptions to workloads might occur even without your intervention, dependingon the specific nature and duration of the outage.

If the Artifact Registry repository outage is regional, we might redirectrequests to a zone or region that isn't affected by the outage.

To check the status of Google Cloud services, go to theGoogle Cloud status dashboard.

About the nodes

Nodes are the worker machines that run your containerized applications and otherworkloads. The individual machines areCompute Engine virtual machines (VMs)that GKE creates. The control plane manages and receivesupdates on each node's self-reported status.

A node runs the services necessary to support the containers that make up your cluster's workloads. These include the runtime and the Kubernetes node agent (kubelet), which communicates with the control plane and is responsible for starting and running containers scheduled on the node.

GKE also runs a number of system containers that run as per-nodeagents, called DaemonSets, that provide functionality such as log collection andintra-cluster network connectivity.

Node management varies based on the clustermode of operation, asfollows: