名词解释教学工作区 · 课程 0014 · 形态 单概念 · 约 5 分钟 · 前置:0013 · 前端 / 后端 / 接口(先分清谁在哪跑) · 相关:0016 · 静态部署与其它部署 · 2026-10-01

Kubernetes:你只说要什么,它负责让现实跟上

1 | 定义

Kubernetes(常缩写 K8s),中文常叫容器编排器 (container orchestrator):一个跑在一批机器之上的集群系统。你向它提交期望状态 (跑什么、要几份、什么版本),它负责把这些工作负载安排到合适的机器上、盯住数量、坏了补上、 升级时一批一批换;你要的东西写成 YAML,用命令行工具 kubectl 交进去。 像机场塔台:你只说"我要三个航班同时在天上",哪架飞机用哪条跑道、哪一班延误了怎么补, 是塔台在安排 —— 你不用自己开飞机,也不用去数停机坪上还剩几个位子。

2 | 它解决什么麻烦

容器先解决了"程序连环境一起打包"这件事;可程序一旦跑在多台机器上,新的麻烦立刻冒出来:

• ① 有三台机器,谁该跑哪个容器?手工分,分完就忘了谁在哪,机器一多就对不上号。
• ② 半夜某个容器挂了怎么办?没人知道,直到用户来投诉,才发现服务少了一半。
• ③ 升级能一次全停吗?不能 —— 只能一批一批换,而且必须能随时退回上一版。
• ④ 重启之后容器飘到别的机器上,原来那个地址还能用吗?不能,IP 已经换了,调用方全得改。

这四件事都不属于"程序"本身,而属于"一堆程序怎么在一批机器上安顿下来"。 编排器就是专门管这件事的那一层。

3 | 它怎么解决

一圈闭环:你写下期望,它盯着现状,一直把两者拉平。

期望状态 你写下的:要几份、什么镜像 -> API server(kube-apiserver) 集群里所有读写的唯一入口 -> etcd 把期望状态存下来 -> 控制器 controller 不停对比期望与现状 -> 调度器 scheduler 挑一台合适的机器 -> kubelet 节点上的代理,盯住本机 Pod -> 容器运行时 真正把容器跑起来

• ① 它认的是期望,不是你下的步骤。这套做法叫 声明式 declarative: 你交一份 YAML,里面写着"这个 Deployment 要 3 份、镜像是 web:1.4";怎么做到、先做哪一步,由它决定。
• ② 控制面 control plane 是四个角色。API server(kube-apiserver) 就是集群对所有客户的接口,收下你的声明, 是全集群唯一的入口;etcd 把期望状态持久化存好;调度器看每台机器还剩多少资源, 决定新 Pod 去哪;控制器 controller 守着一句"现在几份、应该几份",差多少补多少。
• ③ 干活的机器上各有一个代理。kubelet 盯着分配到本机的 Pod, 把它交给容器运行时 container runtime(如 containerd)真正跑起来。
• ④ 最小单位是 Pod,不是容器。一个 Pod 里可以放主程序和一个帮手(比如日志收集), 它们同生同死、共享网络;调度看的是 Pod,不是单个容器。
• ⑤ Service 给一组 Pod 一个稳定入口。Pod 换机器、换 IP,外面用的那个名字和端口不变 —— 第 2 节的第 ④ 条麻烦就在这一步被解决。
• ⑥ 补齐和升级,是同一套循环在干。数量不对就起新的;升级时按滚动更新一批一批替换, 新 Pod 要等探针确认"能接活了"才继续,不对就 kubectl rollout undo 退回上一版。

4 | 用它的代价

• ① 概念一次几十个,而且互相咬合。Pod、Deployment、Service、ConfigMap、Ingress、 Namespace、RBAC……少认识一个,就看不懂另一个,头一个星期基本在背名词。
• ② 控制面自己也要维护。etcd 要定期备份,证书到期要轮换,升级之前要查兼容矩阵; 这块没有专人接,集群就从资产变成负担。
• ③ 抽象叠抽象,排障比 docker run 难。同一句"它没起来", 你要顺着 kubectl get、describe、logs 和事件一层层看下去, 才能从"Pod 状态异常"落到真正的报错上。
• ④ 单机小项目用它,是杀鸡用牛刀。一台机器跑一个小网站,集群自身就要吃掉可观的内存与运维时间, 而它解决的"多副本、多机器"根本还没出现。
• ⑤ 它只保证份数,不保证程序对。镜像写错、配置漏了、代码有 bug,它会忠实照你说的份数 一遍遍重启,报错还得你自己看。
• ⑥ 网络与存储要另配插件。跨机器通信靠网络插件,数据持久化靠存储插件, 每一种都有自己的坑 —— 这些都不在"编排"两个字里面。

5 | 真实使用场景

场景一:声明"要 3 份",然后看着它自己凑齐。

kubectl apply -f deployment.yaml    # 声明:这个 Deployment 要 3 份
kubectl get pods -w                 # 盯着状态,Pod 一行行冒出来
# 手动删掉一个:kubectl delete pod web-xxxx,再看 get pods,很快又是 3 个

你没做任何事,数量是被控制器补齐的 —— 这就是它最值钱的地方。

场景二:滚动更新,不对就回滚。

kubectl set image deployment/web web=registry.example.com/web:1.4
kubectl rollout status deployment/web   # 一批一批替换,直到全部起来
kubectl rollout undo deployment/web     # 新版本有问题,一条命令退回上一版

升级期间旧 Pod 还在接请求,所以不中断;回滚的也是同一套声明,不需要人手去改每台机器。

场景三:本机练手,先用不着真买机器。

minikube start          # 或 kind create cluster:在本机起一个单节点集群
kubectl get nodes       # 看这一台"节点"是否就绪
kubectl create deployment demo --image=nginx --replicas=3
kubectl scale deployment demo --replicas=5   # 改一句期望,它自己再补两个

minikube 与 kind 起的是真集群、走同一套 kubectl 命令,只是把控制面缩到一台机器能装下。

6 | 和相近的东西怎么分

先问一句:这件事管的是"一个容器怎么跑",还是"一堆容器放哪、几份、坏了谁补"?

一句话分工:容器运行时管"怎么跑",编排器管"放哪、几份、坏了谁补"。顺带一句:云厂商卖的托管集群(如 EKS、GKE),就是把控制面这份活当成 SaaS / PaaS 卖给你。

7 | 常见误解

• ① 「K8s 就是 Docker 的加强版。」错在把两层并成一层:一层负责把容器跑起来, 一层负责把一堆容器安排到一批机器上;K8s 不认识 docker 命令,它只跟容器运行时打交道。
• ② 「必须上云才能用。」不用。本机的 minikube 或 kind 就是一套完整集群; 机房里几台旧机器装上轻量发行版,一样能跑。
• ③ 「用了它就不需要运维了。」反了。它假设机器已经有了,而控制面本身还要人维护: etcd 备份、证书轮换、版本升级,一件都少不了。
• ④ 「副本越多,程序越快。」它管的是可用性与调度,不是性能。副本加到 10 份, 每个请求该慢还是慢 —— 慢的根因在程序或资源限制里,不在编排层。

8 | 练习

三题自测,每题只有一个正确选项;选完立刻看到解释。