9.2 托管集群：租云端的田

9.2 托管集群：租云端的田

本节摘要：托管 Kubernetes（如各云的 EKS、AKS、GKE 及国内同类服务）把控制平面这间"播种总站"交给云厂商运维，你只管田间小屋与苗。本节厘清自建与托管的责任边界、成本构成与选型要点，并解释"控制平面不可见"对日常操作的实际影响——以及对全册知识而言，改变其实比你想象的小。

自持还是租用

书屋的田在试验田里种得不错，业务方来问：生产的田怎么开？这个决策在云时代通常被表述为自建还是托管。

自建：自己找机器、装系统、用 kubeadm 之类的工具把控制平面与节点拼起来。自由度最高（版本、网络方案、节点型号全自定），代价是控制平面的高可用、升级、证书轮换、备份恢复全部自己扛——别忘了 2.1 那句"备份集群约等于备份台账"。

托管：云厂商开出一块"总站归我管"的田，你按节点数与规格付田租加总站管理费。升级控制平面是云厂商的工单，高可用是默认配置，你看到的集群没有 etcd 的机器实体——它作为服务存在。

我的倾向直说：除非有明确的自建理由（数据不出机房、成本规模到了临界点、需要魔改内核级组件），生产从托管起步。把工程精力花在业务与第 8 章那三道防线上，比花在给自己养的 etcd 值班更划算。

托管田长什么样

以一家云的流程为典型样貌（各家命令不同，形态一致）：

# 云厂商命令行开田（示意 以某云为例）
cloud container clusters create greenlib-prod \
  --region cn-east-1 --node-count 3 --node-machine-type 4x8
# Creating cluster greenlib-prod ... done
# Created 命令通常还包括自动生成的访问凭据配置

kubectl get nodes
# NAME                         STATUS   ROLES    AGE   VERSION
# ip-10-0-1-23.cn-east-1       Ready    <none>   3m    v1.29.4
# ip-10-0-2-11.cn-east-1       Ready    <none>   3m    v1.29.4
# ip-10-0-3-7.cn-east-1        Ready    <none>   3m    v1.29.4
# 名单里只有工作节点：总站的机器不在这份名单上 它是服务 不是机器
​

# 节点池扩容：加田不用搬苗
cloud container node-pools resize greenlib-prod --pool default-pool --size 5
# 新两台节点入列后 调度器自动把新种子派往新地

kubectl get pods -n kube-system | grep -v cloud
# coredns-...        1/1   Running
# kube-proxy-...     1/1   Running
# 托管田的系统田里 厂商组件与你熟悉的组件共存
​

注意两处"看不见"：节点名单里没有控制平面（它是服务）；系统田里多了厂商自己的组件（负责把云的负载均衡器、磁盘接到你的清单语义上——第四章 LoadBalancer 型水闸之所以能"自动开闸"，靠的正是它们）。

什么变了，什么没变

对全册知识而言，托管田改变的是界面，不是机制。kubectl 一模一样、清单一模一样、探针与 RBAC 一模一样——台账制度还是那套台账制度。真正新增的是几样"地契条款"：

• 水闸直通云闸：LoadBalancer 型 Service 会联动云的负载均衡器产生真金白银的费用，开闸前看一眼价目表。
• 地块联动云盘：StorageClass 由厂商预置好几个（SSD 级、普通级），PVC 签约时对照的就是云盘规格，6.2 的"地价目录"在托管田里是现货。
• 门禁对接云身份：谁能进田常与云的账号体系打通，8.3 的组可以映射到云上的部门组。
• 版本节奏跟厂商：升级窗口由厂商列表决定，自己的清单要跟着支持矩阵走。

这些条款的共同点：都是把第二章那台播种机的某些零件外包了，操作语义没变。这也是为什么本册敢说"桌面试验田学的手艺，到托管田直接能用"。

⚠️ 常见坑：托管田"顺手开出来的默认节点规格"往往偏小，而且默认节点池混跑全部负载。生产前规划节点池分层（系统组件一池、无状态一池、数据库一池），并配上 6.3 的污点把数据库苗圈进专属池——书屋真上托管田时，这是第一周的功课。

账要算细

托管的成本常被一句话简化成"贵"，细算其实是三笔账：节点租费（与自建同源）、总站管理费（按集群收，每小时几毛到几块的量级）、以及最常被漏算的人力账——自建控制平面的升级、高可用与故障值班折算成工程师工时，多数中等规模团队算下来托管反而便宜。真正让托管显贵的，往往是顺手多开的服务：每开一个 LoadBalancer 型水闸都在计费，管理费反倒是零头。

从试验田到托管田的迁移路径

书屋的迁移路线可以直接照抄：第一周，在托管田复刻责任田与全部清单，把 9.1 的整田验收流程原样再跑一遍；第二周，接入云的 StorageClass 与门禁，地价目录换成现货，第八章的组映射到云账号体系；第三周，灰度切流，路牌上把一小部分域名指到新田，观测一周再全量。迁移的本质是把清单重新 apply 到新台账——这句话本身，就是声明式给迁移上的保险。

常见疑问两则

托管田能装自己的插件吗

节点侧基本都能（CNI、存储、监控的自选件），控制平面侧受限（改不了总站配置）。选型时想清楚"要不要动控制平面"，基本就能预判哪些定制做不了。

被云锁定怎么办

Kubernetes 的清单与手艺是跨云的，真正的粘性在周边：云盘快照、负载均衡器配置、账号体系集成。迁移成本主要花在数据与外围，不在集群本身——这也是"清单即资产"的又一层含义。

本节要点回顾

• 托管 = 总站外包：高可用与升级归厂商，你管节点与苗
• 选型倾向：无明确自建理由 生产从托管起步
• 托管田的界面变化：LoadBalancer 联动云闸、StorageClass 是现货、门禁对接云身份
• 机制不变：kubectl、清单、探针、RBAC 与全册所学完全通用
• 节点池分层与污点圈池，是托管田生产化的第一课