Kubernetes 入门容器多了，谁来管它们

一个容器跑起来很简单，十个、一百个容器分布在多台机器上，挂了谁重启、流量来了谁扩容，就会变成一团乱麻。Kubernetes 就是专门管容器的调度系统：你只管说“我要跑 3 份”，它负责找机器、拉容器、盯状态、坏了自动换新的。本文从 Pod、Deployment、Service 三个最核心的概念讲起，照着理解就知道它到底在管什么。

先说 Kubernetes 出现的原因。Docker 解决了“一个应用怎么打包、怎么跑”，但生产环境的问题是另一个量级：应用要跑好几份分摊流量，某台机器半夜挂了，上面的容器要自动挪到别的机器，新版本要一批批替换旧版本不能全站中断。这些事靠人盯、靠脚本凑，很快就管不过来。Kubernetes，简称 K8s，干的就是这件事：集群的自动调度员。

理解 K8s 先抓三个概念。第一个是 Pod，它是 K8s 里最小的运行单位，可以理解成一个或几个一起跑的容器住的“小房间”，同一个 Pod 里的容器共享网络，平时你把一个应用容器放一个 Pod 里就够了。第二个是 Deployment，它负责管一批 Pod：你写清楚要跑几份、用哪个镜像，它就保证数量永远对，少了一个立刻补上，多了就撤掉，发新版时它按比例滚动替换，这就是声明式管理的核心，你只说要什么状态，它负责把现状变成那样。

第三个是 Service。Pod 会重建、地址会变，用户和其他服务不可能每次都去找新地址。Service 就是给一组 Pod 套一个固定的访问入口，名字和地址不变，流量进来再分给后面的 Pod，效果有点像负载均衡，但它是集群内部自带的。应用之间互相调用，喊 Service 的名字就行，不用关心背后是哪几个 Pod 在干活。

把三个概念串起来，一次上线就是这个过程：你把镜像推到仓库，写一份配置告诉 Deployment 用这个镜像跑 3 份，再配一个 Service 对外提供访问，剩下的找机器、拉镜像、起容器、补数量，全是 K8s 的事。想扩容就把份数从 3 改成 5，它自己加；某个 Pod 崩了，它自己换个新的，你甚至不会收到通知，因为业务根本没断。

当然，K8s 不是小项目的默认答案，它的复杂度和学习成本是实打实的。判断标准很简单：应用就跑在一两台机器上、容器不超过十个，用 Docker 加 Compose 就足够了，上 K8s 是给自己找运维负担；应用要跑在多台机器上、需要自动恢复和滚动更新、团队不止一个人协作时，K8s 的价值才显现出来。云厂商都有托管版 K8s 服务，控制面不用你自己维护，新手真要上手，优先用托管版，先学用、再学管。

新手上手还有一个顺序建议：先在本地或云上建一个最小集群，亲手部署一个现成的示例应用，把 Pod、Deployment、Service 的配置各写一遍，再试着手动删掉一个 Pod，看它怎么自动补回来，这个体验做一次，声明式管理就不再是抽象名词了。