为什么需要 k8s（云原生价值）

上一章说了 k8s 是什么。这一章聊聊：凭什么要用它？单机 Docker 不香吗？

答案是：香，但只在规模小的时候。一旦应用变多、机器变多、对稳定性有了要求，纯手工和单机 Docker 就开始吃力了。

2-1 单机部署的三道坎

假设你有 3 个服务、2 台服务器。手动用 Docker 跑，看似没问题。可现实很快会给你三记重锤：

第一，挂了没人管。 半夜容器崩了，用户投诉了你才知道。你得自己写守护脚本，或者设个定时检查——这些边角活儿又臭又长。

第二，扩缩靠手抖。 大促来了，要临时加到 20 个副本。你一个个 docker run，再一个个改负载均衡配置，手忙脚乱。活动结束又得缩回来。

第三，发布怕中断。 升级版本时，要么停服，要么手动灰度一半。出错了回滚？又是一通手敲。

这些活儿本质上都是”运维该干的苦力”，而且容易出错。Kubernetes 把这些都变成了系统能力。

2-2 价值一：弹性扩缩，按需用资源

弹性是 k8s 最直观的好处。你可以：

• 用一条命令，或点一下网页，把某个服务从 3 个副本扩到 10 个。
• 更进阶的，让 k8s 盯着 CPU 使用率，自动加副本、减副本（这叫 HPA，后面章节会讲；想自动增减节点，那是 Cluster Autoscaler 的活）。

想象一个网上商城。白天忙、凌晨闲。有了自动扩缩，忙时自动加副本扛住流量，闲时自动收回省成本。你不用 24 小时都按峰值配资源。

2-3 价值二：自愈，系统自己兜底

“自愈”听着玄乎，其实很朴素：让期望状态和实际状态保持一致。

你告诉 k8s：“我要 3 个副本。” 它就去维持 3 个。某个副本所在的容器崩了，k8s 立刻再起一个补上。某个节点整体宕机，上面的 Pod 会被调度到别的节点重新跑。

整个过程你不用插手。你只声明”我要什么”，剩下的交给系统盯着。

2-4 价值三：声明式，而不是命令式

这是 k8s 设计哲学里最反直觉、也最有力的一点。

命令式是你一步步下指令：“启动 A、再启动 B、把 A 删了”。像厨师一步步炒菜。

声明式是你给一张菜谱：“最终要一桌这样的菜。” 厨房（k8s）自己想办法做出来，中间翻车了也自己重做。

好处在哪儿？你用一份 YAML 文件描述系统该长什么样，把这份文件存进 Git。哪天要重建集群，或者别人要复现环境，kubectl apply -f 一下就行。环境即代码（Infrastructure as Code），可版本、可回滚、可评审。

2-5 价值四：可移植，不被厂商绑死

k8s 提供了一个统一的抽象层。你在笔记本上、在腾讯云、在 AWS、在自建机房，用的命令、写的 YAML 基本一样。

这意味着什么？你的应用不会跟某家云厂商的深度私有能力绑死。哪天要迁移，成本比传统架构低得多。这也是”云原生”的核心理念之一：应用生于云、长于云，但忠于标准。

2-6 价值五：生态与扩展

k8s 不是一个封闭系统。它留了大量扩展点：

• 想换网络方案？有 CNI 插件体系。
• 想要自定义资源？有 CRD（后面章节讲）。
• 想要服务网格、监控、日志？有 Helm、Prometheus、Istio 一整套成熟生态。

你不是在用”一个工具”，而是在用一个”平台的操作系统”。围绕它的工具链极其丰富。

2-7 那它有什么代价

讲价值不能只吹好处。k8s 的代价也实打实：

• 学习曲线陡。 概念多，光核心对象就有十几个。
• 运维有门槛。 自己搭生产集群，网络、存储、证书都要懂。
• 小项目杀鸡用牛刀。 一台机器就能跑完的东西，上 k8s 反而增加复杂度。

2-9 有 k8s 和没有 k8s，差在哪

给你一张直观对比：

场景	没有 k8s	有 k8s
容器挂了	人工发现、手动重启	自动重启、补副本
流量突增	手动加机器、改配置	自动扩缩副本
版本升级	停服或手工灰度	滚动更新、可回滚
多环境	靠文档和记忆	YAML 一份，到处 apply
机器故障	业务中断	Pod 漂到别的节点

你会发现，右边那一列全是”把重复的人肉运维，变成系统的内置能力”。这正是 k8s 存在的意义：让人从重复劳动里解放出来，去想更重要的事。

小结

弹性、自愈、声明式、可移植、生态，这五点就是 k8s 的云原生价值。它代价是学习曲线和运维门槛，所以小项目要权衡。带着”它解决什么痛点”这根线，下一章，我们正式进入 k8s 的核心概念：Pod、Node、Cluster、Namespace，把这几个最基础的词彻底讲透。