06 - 别自己搭 K8s：用云厂商的托管服务

前面把概念和思想都讲清楚了。现在回到最实际的问题：真到了工作中，K8s 是怎么用起来的？

答案可能和你想的不一样：绝大多数团队，都不自己搭 K8s，而是直接用云厂商的托管 K8s。 这一章讲清楚为什么，以及有哪些选择。

自己从零搭一套 K8s 有多痛？

回想第 03 章：一套集群 = 大脑（控制平面）+ 一群 Node。如果全靠自己搭：

• 搭建复杂：控制平面那一堆组件（etcd、API Server、Scheduler……）都得自己装好、配好、连通。
• 高可用难：大脑不能只有一个，挂了整个集群就瞎了。你得搞多个大脑互为备份——非常麻烦。
• 升级要命：K8s 版本更新频繁，自己升级集群一不小心就全崩。
• 要专职运维：网络、存储、证书、监控、故障排查……这需要专门的运维/SRE 团队 7×24 盯着。

对中小团队、AI 创业项目来说，光是把集群维护好，就能耗掉你大半精力——而这些跟你的业务价值毫无关系。

主流做法：用云厂商的”托管 K8s”

于是几乎所有团队都选择：把最难、最不该自己碰的”大脑”和底层运维，交给云厂商。

托管 K8s（Managed Kubernetes）：云厂商帮你把控制平面（大脑）、集群搭建、高可用、升级、底层网络这些全包了。你只管往里面部署自己的应用。

这就像：你不用自己盖楼、修电梯、搞水电（那是物业的事），你只管拎包入住、布置自己的房间（部署你的应用）。

各大云厂商的托管 K8s 产品：

它们本质都是同一套 K8s，你学的概念（Pod、Deployment、Service……）在哪家都通用。区别主要是控制台界面、和自家其他云服务的集成、计费方式。

用托管 K8s，你省掉了什么、还要管什么？

分清楚这个，你就明白托管 K8s 的边界了：

云厂商帮你搞定（你不用管）：

• 控制平面（大脑）的搭建、高可用、升级
• 底层机器的接入、网络打通
• 集群本身的稳定运行

你还是要管（你的活）：

• 往集群里部署你的应用（写 Deployment、Service 等）
• 决定要几台 Node、什么规格（也可以用”弹性/Serverless”模式让它自动伸缩）
• 你自己应用的配置、扩缩策略、监控告警

一句话：云厂商负责”K8s 本身能用”，你负责”用 K8s 部署好你的业务”。

甚至还有”更省心”的选择：Serverless 容器

如果你觉得连”管几台 Node”都嫌麻烦，还有更轻的路子：

很多云厂商提供 Serverless 容器服务（如阿里云 ACK Serverless / ECI、AWS Fargate、Google Cloud Run 等）。你连服务器都不用买、不用管，直接把镜像丢上去,按实际用量付费,自动伸缩。

对很多 AI 应用来说，这种”我只想让我的容器跑起来、别让我操心底层”的方式，可能比完整的 K8s 更合适。这一点我们在下一章和第 08 章还会提到。

小结

• 自己从零搭 K8s 又难又重，需要专职运维，中小团队完全不划算。
• 主流做法：用云厂商的托管 K8s（阿里云 ACK、腾讯云 TKE、AWS EKS、Google GKE……）。
• 托管 = 云厂商管好”大脑”和底层，你只管部署自己的应用。就像拎包入住，不用自己盖楼。
• 你学的 K8s 概念在各家云上通用。
• 更省心的话，还有 Serverless 容器，连服务器都不用管。

那用起来的流程到底长什么样？下一章走一遍。

上一章 ← 05 - 声明式思维 ｜ 下一章 → 07 - 云上 K8s 的大致使用流程