📚 课程目录第4章 Google Kubernetes Engine集群创建与配置

4. Google Kubernetes Engine集群创建与配置

在 GKE 上落地一个应用之前，最先要做的决策不是“装什么插件”，而是“用哪种集群模式”。GKE 提供两种运行模式：Standard（标准模式）与 Autopilot（自动驾驶模式）。它们共享同一套 Kubernetes API，但在节点管理、计费方式、安全基线和可定制程度上差异明显。理解这些差异，才能避免“先建了再改”的高成本返工。

一、Standard 与 Autopilot 的本质区别

Standard 模式下，集群由控制平面和节点池（Node Pool）组成，节点是用户可见、可管理的 Compute Engine 虚拟机。你需要决定机器类型、节点数量、自动扩缩范围、镜像类型，并负责节点升级与安全补丁。它的优势是控制力强：可以使用 DaemonSet、特权容器、自定义节点配置、GPU 节点池、本地 SSD 等。

Autopilot 模式下，Google 管理节点与节点池，你只提交 Pod 的资源配置（CPU/内存请求），GKE 按需自动创建和伸缩底层节点。计费按 Pod 实际请求的资源量计算，而不是按整台虚拟机计费。Autopilot 默认启用多项安全加固：节点使用容器优化操作系统、启用 Shielded GKE Nodes、工作负载身份（Workload Identity）、网络策略等，并且禁止特权容器与 hostPath 等高风险能力。

选择逻辑可以概括为：需要精细控制节点、运行系统级组件或特殊硬件时选 Standard；希望减少运维负担、按 Pod 计费、默认获得安全基线时选 Autopilot。两者并非互斥，同一项目中可以并存多个不同模式的集群。

二、创建集群的关键参数

无论哪种模式，创建集群时都需要确定几个核心参数。以 Standard 模式为例，使用 gcloud container clusters create 时，以下参数最值得关注：

gcloud container clusters create demo-cluster \
  --region=asia-east1 \
  --num-nodes=3 \
  --machine-type=e2-standard-4 \
  --enable-autoscaling --min-nodes=1 --max-nodes=6 \
  --enable-autorepair --enable-autoupgrade \
  --release-channel=regular \
  --workload-pool=my-project.svc.id.goog \
  --enable-network-policy

这里有几个要点。区域（region）与可用区（zone）：区域集群的控制平面跨多个可用区，节点默认分布在三个可用区，可用性更高；单可用区集群成本略低但存在单点风险。发布通道（release channel）决定控制平面与节点的 Kubernetes 版本更新节奏，regular 是多数生产环境的平衡选择，stable 更保守，rapid 适合尝鲜。自动修复与自动升级建议开启，否则节点故障或版本落后需要人工介入。

Autopilot 集群的创建命令更简洁，因为节点相关参数被托管：

gcloud container clusters create-auto demo-auto \
  --region=asia-east1 \
  --release-channel=regular

创建完成后，用 gcloud container clusters get-credentials demo-cluster --region=asia-east1 把集群凭证写入本地 kubeconfig，之后即可用 kubectl get nodes 验证连通性。Standard 集群应能看到节点列表，Autopilot 集群则只显示由系统管理的节点。

三、节点池管理

节点池是 Standard 模式的核心运维单元。一个集群可以有多个节点池，每个节点池拥有独立的机器类型、节点数量、标签、污点和自动扩缩配置。常见的做法是：通用工作负载放在默认节点池，GPU 或高内存任务放在专用节点池，通过节点选择器或亲和性把 Pod 调度到目标池。

调整节点池规模有两种方式：手动 gcloud container clusters resize，或配置集群自动扩缩器（Cluster Autoscaler）。自动扩缩器在 Pod 因资源不足无法调度时增加节点，在节点长期空闲时减少节点。需要注意，缩容不会驱逐没有控制器管理的裸 Pod，因此生产工作负载应使用 Deployment、StatefulSet 等控制器。

节点池升级是另一个高频操作。建议先升级控制平面，再逐个升级节点池，并利用 --max-surge-upgrade 与 --max-unavailable-upgrade 控制滚动节奏，避免一次性中断过多容量。

四、网络与安全配置

网络方面，GKE 集群默认使用 VPC 原生（VPC-native）模式，Pod 和 Service 直接从 VPC 子网分配 IP 地址段。创建时需要规划三个 CIDR：节点子网、Pod 地址段、Service 地址段。它们不能与已有 VPC 网段重叠，否则集群创建会失败。例如节点子网 10.0.0.0/20、Pod 段 10.4.0.0/14、Service 段 10.8.0.0/20 是一组常见且不冲突的示例规划。

安全方面，建议至少启用以下几项：Workload Identity 让 Pod 以 Kubernetes 服务账号身份访问 Google Cloud API，避免下载长期密钥；网络策略限制 Pod 之间的东西向流量；Shielded GKE Nodes 防止节点被篡改；私有集群让节点不暴露公网 IP，仅通过 Cloud NAT 或内部负载均衡访问外部。Autopilot 默认已包含其中多数能力，Standard 则需要显式开启。

规划 CIDR 时，Pod 地址段要预留足够空间。一个 /14 的 Pod 段可提供约 26 万个地址，足以支撑较大规模集群；若规划过小，后期扩容会受限且难以修改。

Standard 集群若未开启自动升级，节点可能长期停留在旧版本，带来安全风险。生产环境建议至少使用 regular 发布通道并开启自动升级与自动修复。

综合来看，GKE 集群创建与配置的核心是：先根据控制力与运维负担选择 Standard 或 Autopilot，再围绕区域、版本通道、自动扩缩确定集群骨架，最后通过网络 CIDR 规划与安全基线把集群变成可承载生产负载的环境。把这些参数在创建阶段就定清楚，后续的节点池调整和应用交付会顺畅得多。