集群架构

集群是 Google Kubernetes Engine (GKE) 的基础,也就是说,代表容器化应用的 Kubernetes 对象都在集群上运行。

在 GKE 中,一个集群至少包含一个控制层面和多个称为节点的工作器机器。这些控制层面和节点机器运行 Kubernetes 集群编排系统。

下图简要介绍了 GKE 中的区域级集群的架构:

GKE 会在区域控制层面中预配、维护和运营,并且仅预配节点。

控制层面

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

控制层面和 Kubernetes API

控制层面是集群的统一端点。与集群的所有互动都是通过 Kubernetes API 调用完成的,控制层面运行 Kubernetes API 服务器进程来处理这些互动请求。您可以通过 HTTP/gRPC 直接进行 Kubernetes API 调用,也可以通过从 Kubernetes 命令行客户端 (kubectl) 运行命令或者与 Cloud Console 中的界面进行交互来间接进行调用。

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

控制层面与节点的交互

控制层面负责决定在所有集群节点上运行的内容,其中可能包括调度工作负载(如容器化应用),以及管理工作负载的生命周期、扩缩和升级。此外,控制层面还会管理这些工作负载的网络和存储资源。

控制层面和节点也使用 Kubernetes API 进行通信。

控制层面与 gcr.io 容器镜像仓库的交互

当您创建或更新集群时,系统将从 gcr.io 容器镜像仓库拉取在控制层面(和节点)上运行的 Kubernetes 软件的容器映像。如果发生影响 gcr.io 镜像仓库的服务中断,则可能导致以下类型的故障:

  • 在服务中断期间无法创建新的集群。
  • 在服务中断期间无法升级集群。
  • 即使没有用户干预,也可能导致工作负载中断,具体取决于服务中断的具体性质和持续时间。

如果 gcr.io 容器注册表出现区域或地区性服务中断,Google 可能会将请求重定向到不受中断影响的区域或地区。

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

节点

一个集群通常具有一个或多个节点,即运行容器化应用和其他工作负载的工作器机器。各个机器是在您创建集群时 GKE 为您创建的 Compute Engine 虚拟机实例

每个节点都通过控制层面进行管理,控制层面会接收各节点自我报告的状态更新。您可以对节点生命周期进行一些手动控制,也可以让 GKE 对集群的节点执行自动修复自动升级

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

在 GKE 中,还有一些特殊容器作为每个节点的代理运行,以提供日志收集和集群内网络连接等功能。

节点机器类型

每个节点都是标准的 Compute Engine 机器类型。默认类型为 e2-medium。您可以在创建集群时选择其他机器类型。

节点操作系统映像

每个节点都运行一个专用的操作系统映像来运行容器。您可以指定集群和节点池使用的操作系统映像。

满足最低要求的 CPU 平台

创建集群或节点池时,您可以为其节点指定满足基准最低要求的 CPU 平台。选择特定的 CPU 平台对于高级或计算密集型工作负载可能会比较有利。如需了解详情,请参阅满足最低要求的 CPU 平台

节点可分配资源

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

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

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

如需检查集群中可用的节点可分配资源,请运行以下命令:

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

其中,node-name 是要检查的节点的名称。

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

逐出阈值

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

可分配的内存和 CPU 资源

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

Allocatable = Capacity - Reserved - Eviction Threshold

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

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

对于 CPU 资源,GKE 会预留:

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

下表显示了可用于为每个标准节点机器类型调度集群 Linux 工作负载的可分配内存和 CPU 资源的数量:

机器类型 内存容量 (GB) 可分配的内存 (GB) CPU 容量(核心数量) 可分配的 CPU(核心数量)
c2-standard-4 16 13.3 4 3.92
c2-standard-8 32 28.6 8 7.91
c2-standard-16 64 58.7 16 15.89
c2-standard-30 120 111.2 30 29.89
c2-standard-60 240 228.4 60 59.85
e2-micro 1 0.62 2 0.941
e2-small 2 1.35 2 0.941
e2-medium (默认值) 4 2.76 2 0.941
e2-standard-2 8 6.1 2 1.93
e2-standard-4 16 13.3 4 3.92
e2-standard-8 32 28.6 8 7.91
e2-standard-16 64 58.7 16 15.89
e2-highmem-2 16 13.3 2 1.93
e2-highmem-4 32 28.6 4 3.92
e2-highmem-8 64 58.7 8 7.91
e2-highmem-16 128 118.6 16 15.89
e2-highcpu-2 2 1.5 2 1.93
e2-highcpu-4 4 2.9 4 3.92
e2-highcpu-8 8 6.1 8 7.91
e2-highcpu-16 16 13.3 16 15.89
g1-small 1.7 1.2 1 0.94
m1-megamem-96 1433.6 1414.7 96 95.69
m1-ultramem-40 961 942.1 40 39.85
m1-ultramem-80 1922 1903.1 80 79.77
m1-ultramem-160 3844 3825.1 160 159.69
m1-ultramem-208 5888 5869.1 208 207.69
m1-ultramem-416 11776 11757.1 416 415.69
n1-standard-1 3.75 2.7 1 0.94
n1-standard-2 7.5 5.7 2 1.93
n1-standard-4 15 12.3 4 3.92
n1-standard-8 30 26.6 8 7.91
n1-standard-16 60 54.7 16 15.89
n1-standard-32 120 111.2 32 31.85
n1-standard-64 240 228.4 64 63.77
n1-standard-96 360 346.4 96 95.69
n1-highmem-2 13 10.7 2 1.93
n1-highmem-4 26 22.8 4 3.92
n1-highmem-8 52 47.2 8 7.91
n1-highmem-16 104 96.0 16 15.89
n1-highmem-32 208 197.4 32 31.85
n1-highmem-64 416 400.8 64 63.77
n1-highmem-96 624 605.1 96 95.69
n1-highcpu-2 1.8 1.3 2 1.93
n1-highcpu-4 3.6 2.6 4 3.92
n1-highcpu-8 7.2 5.5 8 7.91
n1-highcpu-16 14.4 11.9 16 15.89
n1-highcpu-32 28.8 25.3 32 31.85
n1-highcpu-64 57.6 52.5 64 63.77
n1-highcpu-96 86.4 79.6 96 95.69
n2-standard-2 8 6.1 2 1.93
n2-standard-4 16 13.3 4 3.92
n2-standard-8 32 28.6 8 7.91
n2-standard-16 64 58.7 16 15.89
n2-standard-32 128 118.6 32 31.85
n2-standard-48 192 182.6 48 47.85
n2-standard-64 256 244.4 64 63.77
n2-standard-80 320 308.4 80 79.77
n2-highmem-2 16 13.3 2 1.93
n2-highmem-4 32 28.6 4 3.92
n2-highmem-8 64 58.7 8 7.91
n2-highmem-16 128 118.6 16 15.89
n2-highmem-32 256 244.4 32 31.85
n2-highmem-48 384 370.4 48 47.85
n2-highmem-64 512 496.8 64 63.77
n2-highmem-80 640 621.1 80 79.77
n2-highcpu-2 2 1.5 2 1.93
n2-highcpu-4 4 2.9 4 3.92
n2-highcpu-8 8 6.1 8 7.91
n2-highcpu-16 16 13.3 16 15.89
n2-highcpu-32 32 28.6 32 31.85
n2-highcpu-48 48 44.6 48 47.85
n2-highcpu-64 64 58.7 64 63.77
n2-highcpu-80 80 74.7 80 79.77
n2d-standard-2 8 6.1 2 1.93
n2d-standard-4 16 13.3 4 3.92
n2d-standard-8 32 28.6 8 7.91
n2d-standard-16 64 58.7 16 15.89
n2d-standard-32 128 118.6 32 31.85
n2d-standard-48 192 182.6 48 47.85
n2d-standard-64 256 244.4 64 63.77
n2d-standard-80 320 308.4 80 79.77
n2d-standard-96 384 370.4 96 95.69
n2d-standard-128 512 496.8 128 127.69
n2d-standard-224 896 877.1 224 223.69
n2d-highmem-2 16 13.3 2 1.93
n2d-highmem-4 32 28.6 4 3.92
n2d-highmem-8 64 58.7 8 7.91
n2d-highmem-16 128 118.6 16 15.89
n2d-highmem-32 256 244.4 32 31.85
n2d-highmem-48 384 370.4 48 47.85
n2d-highmem-64 512 496.8 64 63.77
n2d-highmem-80 640 621.1 80 79.77
n2d-highmem-96 780 761.1 96 95.69
n2d-highcpu-2 2 1.5 2 1.93
n2d-highcpu-4 4 2.9 4 3.92
n2d-highcpu-8 8 6.1 8 7.91
n2d-highcpu-16 16 13.3 16 15.89
n2d-highcpu-32 32 28.6 32 31.85
n2d-highcpu-48 48 44.6 48 47.85
n2d-highcpu-64 64 58.7 64 63.77
n2d-highcpu-80 80 74.7 80 79.77
n2d-highcpu-96 96 89.2 96 95.69
n2d-highcpu-128 128 118.6 128 127.69
n2d-highcpu-224 224 213.4 224 223.69

1GKE 决定减少可用于在 e2-micro、e2-small 和 e2-medium 机器类型上调度用户工作负载的可分配 CPU 资源(称为节点可分配资源)。如需了解详情,请参阅 GKE 版本说明

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

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

GKE 通常通过单个文件系统和定期扫描来配置其节点。依赖于其大小的启动磁盘的一部分会保留下来供系统使用。

临时存储空间最多可使用启动磁盘的容量,但预留给系统使用的容量和逐出阈值除外。预留总大小取决于根据以下公式计算的启动磁盘大小:

10% * BOOT-DISK-CAPACITY + Min(50% * BOOT-DISK-CAPACITY, 6K + 35% * BOOT-DISK-CAPACITY, 100G)

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

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