GKE 集群架构

使用集合让一切井井有条 根据您的偏好保存内容并对其进行分类。

本页面介绍 Google Kubernetes Engine (GKE) 集群的架构。您的容器化 Kubernetes 工作负载都在 GKE 集群中运行。

GKE 集群由控制平面和称为节点的工作器机器组成。控制平面和节点构成 Kubernetes 集群编排系统。GKE 管理集群的整个底层基础架构,包括控制平面、节点和所有系统组件。如果使用 GKE Standard 模式,则 GKE 会管理控制平面和系统组件,而您管理节点。

下图显示了 GKE 集群的架构:

GKE 集群架构。控制平面由 GKE 管理,并运行 API 服务器、资源控制器、调度器和集群存储。这些节点在 Autopilot 模式下由 GKE 管理,在标准模式下由用户管理。用户 Pod 在节点中运行容器。可以使用其他 Google Cloud 服务与 GKE 集成。

控制平面

控制平面运行 Kubernetes API 服务器、调度器和核心资源控制器等进程。GKE 管理从集群创建到删除的控制平面生命周期。其中包括对控制平面上运行的 Kubernetes 版本的升级。该升级将由 GKE 自动执行;如果您希望提前升级,而不按计划自动升级,可以请求手动执行。

控制平面和 Kubernetes API

控制平面是集群的统一端点。您可以通过 Kubernetes API 调用与控制平面进行交互。控制平面运行 Kubernetes API 服务器进程 (kube-apiserver) 以处理 API 请求。您可以通过以下方式进行 Kubernetes API 调用:

  • 直接调用:HTTP/gRPC
  • 间接调用:Kubernetes 命令行客户端,例如 kubectl 或 Google Cloud 控制台。

API 服务器进程是集群所有通信的中心。所有内部集群组件(如节点、系统进程和应用控制器)都充当 API 服务器的客户端。

您的 API 请求会告诉 Kubernetes 集群中对象的所需状态。Kubernetes 会尝试持续保持该状态。Kubernetes 允许您以命令方式或以声明方式配置 API 中的对象。

如需详细了解 Kubernetes 中的对象管理,请参阅以下页面:

控制平面与节点的交互

控制平面管理集群的所有节点上运行的内容。控制平面安排工作负载并管理工作负载的生命周期、扩缩和升级。此外,控制平面还会管理这些工作负载的网络和存储资源。控制平面和节点使用 Kubernetes API 相互通信。

控制平面与 Artifact Registry 的互动

当您创建或更新集群时,GKE 会从 pkg.dev Artifact Registry 或 gcr.io Container Registry 中拉取控制平面和节点上运行的 Kubernetes 系统软件的容器映像。如果发生影响这些注册表的中断,以下操作可能会失败:

  • 创建新集群
  • 集群版本升级

即使没有您的干预,也可能导致工作负载中断,具体取决于服务中断的具体性质和持续时间。

如果 pkg.dev Artifact Registry 或 gcr.io Container Registry 服务中断是区域性的,Google 可能会将请求重定向到不受中断影响的可用区或区域。

如需查看 Google Cloud 服务的状态,请转到 Google Cloud 状态信息中心

节点数

节点是运行容器化应用和其他工作负载的工作器机器。各个机器是 GKE 创建的 Compute Engine 虚拟机 (VM)。控制平面管理和接收每个节点自我报告状态的更新。

节点运行支持容器(容器构成了集群的工作负载)所必需的服务。这些服务包括运行时和 Kubernetes 节点代理 (kubelet);该节点代理会与控制平面通信,并负责启动和运行被调度到该节点上的容器。

GKE 还运行多个系统节点,这些容器作为每个节点的代理(称为 DaemonSet)运行,可提供日志收集和集群内网络连接等功能。

节点管理因集群操作模式而异,如下所示:

节点组件 AutoPilot 模式 标准模式
Lifecycle

由 GKE 完全管理,包括:

GKE 管理以下内容:

您可以管理以下各项:

公开范围 使用 kubectl 查看节点。无法通过 gcloud CLI 或 Google Cloud 控制台查看或访问的底层 Compute Engine 虚拟机。 使用 kubectl、gcloud CLI 和 Google Cloud 控制台查看节点。查看和访问底层 Compute Engine 虚拟机。
连接 不直接连接至底层虚拟机。 使用 SSH 连接至底层虚拟机。
节点操作系统 (OS) 由 GKE 管理。 所有节点都使用包含 containerd 的 Container-Optimized OS (cos_containerd) 为您的节点选择操作系统
机器硬件选择

根据用例请求 Pod 中的计算类

GKE 管理机器配置、调度、数量和生命周期。

创建节点池时选择并配置 Compute Engine 机器类型。根据需要配置大小调整、扩缩、数量、调度和位置设置。

适用于 GKE Standard 的节点可分配资源

需要节点的一些资源,才能运行使该节点作为集群的一部分运行所必需的 GKE 和 Kubernetes 节点组件。因此,您可能会发现节点的“总资源数量”(如机器类型文档中所指定)与节点在 GKE 中的“可分配资源数量”之间存在差异。

由于规模较大的机器类型往往运行更多容器(乃至更多 Pod),因此 GKE 会为 Kubernetes 组件预留更多资源,以应对规模较大的机器的需求。此外,Windows Server 节点比典型 Linux 节点需要的资源更多。这些节点需要使用额外资源来运行 Windows 操作系统和无法在容器中运行的 Windows Server 组件。

您可以为 Pod 请求资源或限制其资源使用。如需了解如何为 pod 请求资源或限制 pod 的资源使用,请参阅管理容器的资源

如需检查集群中可用的节点可分配资源,请运行以下命令,并将 NODE_NAME 替换为您要检查的节点的名称:

kubectl describe node NODE_NAME | grep Allocatable -B 7 -A 6

返回的输出包含 CapacityAllocatable 字段,其中提供了针对临时存储、内存和 CPU 的测量结果。

逐出阈值

如需确定 Pod 的可用内存量,您还必须考虑逐出阈值。GKE 会在每个节点上额外预留 100 MiB 内存以用于 kubelet 逐出。

可分配的内存和 CPU 资源

可分配的资源按以下方式计算:

ALLOCATABLE = CAPACITY - RESERVED - EVICTION-THRESHOLD

对于内存资源,GKE 会预留:

  • 内存不足 1 GiB 的机器的 255 MiB 内存
  • 前 4 GiB 内存的 25%
  • 接下来 4 GiB 内存(最多 8 GiB)的 20%
  • 接下来 8 GiB 内存(最多 16 GiB)的 10%
  • 接下来 112 GiB 内存(最多 128 GiB)的 6%
  • 128 GiB 以上任何内存的 2%

对于 CPU 资源,GKE 会预留:

  • 第一个核心的 6%
  • 下一个核心(最多 2 个核心)的 1%
  • 接下来 2 个核心(最多 4 个核心)的 0.5%
  • 4 个以上任何核心数量的 0.25%

可分配的本地临时存储资源

从 GKE 1.10 版开始,您可以在处理 CPU 和内存资源时管理本地临时存储资源。如需了解如何让 Pod 指定临时存储请求和限制并了解它们的操作方式,请参阅 Kubernetes 文档中的本地临时存储

GKE 通常通过单个文件系统和定期扫描来配置其节点。临时存储空间也可以由本地 SSD 提供支持。在任一情况下,系统都预留了一部分文件系统供 kubelet 使用。其余部分(称为可分配的本地临时存储空间)可用作临时存储空间资源。

为 kubelet 和其他系统组件预留的文件系统数量由以下因素决定:

EVICTION-THRESHOLD + SYSTEM-RESERVATION

由启动磁盘支持的临时存储空间

默认情况下,临时存储由节点启动磁盘提供支持。在这种情况下,逐出阈值和系统预留大小由以下公式指定:

EVICTION-THRESHOLD = 10% * BOOT-DISK-CAPACITY

SYSTEM-RESERVATION = Min(50% * BOOT-DISK-CAPACITY, 6GiB + 35% * BOOT-DISK-CAPACITY, 100 GiB)

如需了解启动磁盘容量增加时可用的可分配临时存储空间量的近似表示,请参阅下图:

显示临时存储空间如何随启动磁盘容量增加的图表。这种关系很接近线性。

由本地 SSD 支持的临时存储空间

系统保留的空间取决于本地 SSD 的数量:

本地固态硬盘的数量 SYSTEM-RESERVATION (GiB)
1 50
2 75
3 个或更多 100

逐出阈值类似于由启动磁盘提供支持的临时存储:

EVICTION-THRESHOLD = 10% * NUM-LOCAL-SSDS * 375 GB

每个本地 SSD 的容量为 375 GiB。如需了解详情,请参阅有关添加本地 SSD 的 Compute Engine 文档。