集群是 Google Kubernetes Engine (GKE) 的基础，也就是说，代表容器化应用的 Kubernetes 对象都在集群上运行。
在 GKE 中，一个集群至少包含一个控制层面和多个称为节点的工作器机器。这些控制层面和节点机器运行 Kubernetes 集群编排系统。
下图简要介绍了 GKE 中的可用区级集群的架构：
控制层面
控制层面运行控制层面进程，包括 Kubernetes API 服务器、调度器和核心资源控制器。当您创建或删除集群时，控制层面的生命周期由 GKE 管理。其中包括对控制层面上运行的 Kubernetes 版本的升级。该升级将由 GKE 自动执行；如果您希望提前升级，而不按计划自动升级，可以请求手动执行。
控制层面和 Kubernetes API
控制层面是集群的统一端点。您通过 Kubernetes API 调用与集群进行交互，而控制层面则运行 Kubernetes API 服务器进程来处理这些请求。您可以通过 HTTP/gRPC 直接进行 Kubernetes API 调用，也可以通过从 Kubernetes 命令行客户端 (kubectl) 运行命令或者与控制台中的界面进行交互来间接进行调用。
API 服务器进程是集群所有通信的中心。所有内部集群进程（例如集群节点、系统和组件、应用控制器）都充当 API 服务器的客户端；API 服务器是整个集群的单一数据源。
控制层面与节点的交互
控制层面决定集群的所有节点上运行的内容。控制层面会调度工作负载（如容器化应用），并管理工作负载的生命周期、扩缩和升级。此外，控制层面还会管理这些工作负载的网络和存储资源。
控制层面和节点使用 Kubernetes API 进行通信。
控制与 Artifact Registry 和 Container Registry 的层面交互
当您创建或更新集群时，系统将从 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 虚拟机实例。
每个节点都通过控制层面进行管理，控制层面会接收各节点自我报告的状态更新。您可以对节点生命周期进行一些手动控制，也可以让 GKE 对集群的节点执行自动修复和自动升级。
节点运行支持容器（容器构成了集群的工作负载）所必需的服务。这些服务包括运行时和 Kubernetes 节点代理 (kubelet)；该节点代理会与控制层面通信，并负责启动和运行被调度到该节点上的容器。
在 GKE 中，还有一些特殊容器作为每个节点的代理运行，以提供日志收集和集群内网络连接等功能。
节点机器类型
每个节点都是标准的 Compute Engine 机器类型。默认类型为 e2-medium。您可以在创建集群时选择其他机器类型。
节点操作系统映像
每个节点都运行一个专用的操作系统映像来运行容器。您可以指定集群和节点池使用的操作系统映像。
满足最低要求的 CPU 平台
创建集群或节点池时，您可以为其节点指定满足基准最低要求的 CPU 平台。选择特定的 CPU 平台对于高级或计算密集型工作负载可能会比较有利。如需了解详情，请参阅满足最低要求的 CPU 平台。
节点可分配资源
需要节点的一些资源，才能运行使该节点作为集群的一部分运行所必需的 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
返回的输出包含 Capacity 和 Allocatable 字段，其中提供了针对临时存储、内存和 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 文档。