[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2024-12-24。"],[],[],null,["# GKE cluster architecture\n\n[Autopilot](/kubernetes-engine/docs/concepts/autopilot-overview) [Standard](/kubernetes-engine/docs/concepts/choose-cluster-mode)\n\n*** ** * ** ***\n\nThis page describes the architecture of the Google Kubernetes Engine (GKE) clusters\nthat run your containerized workloads. Use this page to learn about the control\nplane, nodes, and how the various GKE cluster components interact\nwith each other.\n\nThis page is for Admins, Architects, and Operators who\ndefine IT solutions and system architecture. To learn more about common roles\nand example tasks that we reference in Google Cloud content, see\n[Common GKE user roles and tasks](/kubernetes-engine/enterprise/docs/concepts/roles-tasks).\n\nBefore reading this page, ensure that you're familiar with the\n[Kubernetes cluster architecture](https://kubernetes.io/docs/concepts/architecture/).\n\nA GKE cluster consists of a *control plane* and worker\nmachines called *nodes*. The control plane and nodes make up the Kubernetes\ncluster orchestration system. GKE Autopilot manages the\nentire underlying infrastructure of clusters, including the control plane,\nnodes, and all system components.\n\nIf you use GKE\nStandard mode, GKE manages the control plane and system\ncomponents, and you manage the nodes.\n\nThe following diagram shows the architecture of a GKE cluster:\n\nThis diagram shows the following components:\n\n- Control plane: managed by GKE. Runs the Kubernetes API server, workload controllers, Kubernetes scheduler, and cluster state storage.\n- Nodes: managed by GKE in Autopilot mode, and managed by customers in Standard mode. All of your Pods run in nodes.\n- Other Google Cloud services: available to integrate with GKE.\n\nAbout the control plane\n-----------------------\n\nThe control plane runs processes such as the Kubernetes API server, scheduler,\nand core resource controllers. GKE manages the control plane\nlifecycle from cluster creation to deletion. This includes upgrades to the\nKubernetes version running on the control plane, which GKE\nperforms automatically, or manually at your request if you prefer to upgrade\nearlier than the automatic schedule.\n\n### Control plane and the Kubernetes API\n\nThe control plane is the unified endpoint for your cluster. You interact with\nthe control plane through Kubernetes API calls. The control plane runs the\nKubernetes API server process (`kube-apiserver`) to handle API requests. You can\nmake Kubernetes API calls in the following ways:\n\n- Direct calls: HTTP/gRPC\n- Indirect calls: Kubernetes command-line clients such as `kubectl`, or the Google Cloud console.\n\nThe API server process is the hub for all communication for the cluster. All\ninternal cluster components such as nodes, system processes, and application\ncontrollers act as clients of the API server.\n\nYour API requests tell Kubernetes what your *desired state* is for the objects\nin your cluster. Kubernetes attempts to constantly maintain that state.\nKubernetes lets you configure objects in the API either *imperatively* or\n*declaratively*.\n\nTo learn more about object management in Kubernetes, refer to the following\npages:\n\n- [Understanding Kubernetes objects](https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/)\n- [Kubernetes object management](https://kubernetes.io/docs/concepts/overview/working-with-objects/object-management/)\n\n### Control plane and the cluster state database\n\nThe open source Kubernetes project uses\n[etcd](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/)\nas the storage database for all cluster data by default. The cluster state\nis kept in a key-value store that contains information about the state of every\nKubernetes API object in your cluster. For example, the cluster state database\nstores every Secret, ConfigMap, and Deployment.\n\nGKE clusters store the cluster state in one of the following\nkey-value stores:\n\n- **etcd**: GKE stores the cluster state in etcd instances that run on every control plane virtual machine (VM).\n- **Spanner** : GKE stores the cluster state in [Spanner](/spanner). The Spanner database doesn't run in the cluster control plane.\n\nRegardless of the type of database, every GKE cluster serves the\netcd API in the control plane. The Kubernetes API server uses the etcd API to\ncommunicate with the backend cluster state database.\n\n### Control plane and node interaction\n\nThe control plane manages what runs on all of the cluster's nodes. The control\nplane schedules workloads and manages the workloads' lifecycle, scaling, and\nupgrades. The control plane also manages network and storage resources for those\nworkloads. The control plane and nodes communicate with each other using\nKubernetes APIs.\n\n### Control plane interactions with Artifact Registry\n\nWhen you create or update a cluster, GKE pulls container images\nfor the Kubernetes system software running on the control plane and nodes from\nArtifact Registry repositories in the `pkg.dev` or the `gcr.io` domain. An outage\naffecting these registries might cause the following actions to fail:\n\n- New cluster creation\n- Cluster version upgrades\n\nDisruptions to workloads might occur even without your intervention, depending\non the specific nature and duration of the outage.\n\nIf the Artifact Registry repository outage is regional, we might redirect\nrequests to a zone or region that isn't affected by the outage.\n\nTo check the status of Google Cloud services, go to the\n[Google Cloud status dashboard](https://status.cloud.google.com/).\n**Best practice** :\n\nDeploy across multiple regions to permit availability of applications\nduring region outages.\n\nAbout the nodes\n---------------\n\nNodes are the worker machines that run your containerized applications and other\nworkloads. The individual machines are\n[Compute Engine virtual machines (VMs)](/compute/docs/instances)\nthat GKE creates. The control plane manages and receives\nupdates on each node's self-reported status.\n\nA 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.\n\nGKE also runs a number of system containers that run as per-node\nagents, called DaemonSets, that provide functionality such as log collection and\nintra-cluster network connectivity.\n**Best practice** :\n\nUse `stdout` for containerized applications because `stdout` lets your platform handle the [application logs](/kubernetes-engine/docs/how-to/view-logs).\n\nNode management varies based on the cluster\n[mode of operation](/kubernetes-engine/docs/concepts/choose-cluster-mode), as\nfollows:\n\n\u003cbr /\u003e"]]