跳转至

Kubernetes:把几千个容器交给一个调度员

1. 这一章讲什么

第 6 章末尾留下一个问题:Docker 管的是一台机器,几百上千个容器跨越多台机器时怎么办?这一章的答案分两层:先讲编排系统这个概念(为什么需要、提供什么能力),再拆开 Kubernetes——它已经是事实标准(书中称市场份额超 90%)——从架构、组件、控制流讲到部署、服务暴露和回滚。

2. 顶层全景

  用户(kubectl)→ API server(唯一入口,管认证授权)
                      │读写
                    etcd(唯一事实存储:全集群状态)
                      │
        ┌─────────────┴──────────────┐
     Scheduler(挑机器)        Controller Manager(纠偏:实际≠期望就动手)
        └─────────────┬──────────────┘
                    Kubelet(每台 worker 上的执行官)
                      │
               容器运行时(Docker/containerd)→ Pod

主线例子(全章共用):一条 kubectl create pod 命令在集群里引起的一连串事件。

3. 核心原理

3.1 为什么需要编排:从图 7.1 的两幅画说起

没有编排系统时,管理员对着每台 VM 单独管自己的容器:部署、扩缩、网络各管各的,VM 越多越乱。有编排系统后,管理员只跟系统说话,由它把容器分发到整个集群、管生命周期、做负载均衡——底层基础设施被抹平了1。书里用一家虚构电商 LetsShop 的六个问题当需求清单:高峰自动扩容、流量分摊、新容器的服务发现、零停机更新与回滚、资源利用率、健康监控——这正是编排系统的功能清单2。

3.2 编排系统的七项能力

书里列了七条3,三条最要紧:

  1. 自愈(self-healing):容器挂了、不健康检查不过关,自动重启,必要时换一台机器重起;副本数永远维持在你声明的数量3。
  2. 弹性扩缩:横向(加/减容器实例)是主路——黑五来了自动加支付网关的实例,结束再减掉3。
  3. 滚动更新与回滚:新版本一批批换旧版本,不是一次性全换;出问题随时退回上一版3。

其余四条:自动部署(IaC 工具 Ansible/Terraform 配合)、服务发现(按名字找服务,不用记 IP,因为容器 IP 随生死不断变化)、安全(RBAC 角色权限、secrets 密钥管理)、日志监控。

3.3 选手对比:五套系统一句话定位

系统 一句话 何时选
Kubernetes 功能最全、生态最大、学习最陡 大规模、复杂应用,行业标准
Docker Swarm 简单,内建于 Docker 小到中规模、团队没精力养 K8s
GKE/EKS/AKS 云厂商托管的 K8s(免运维控制面) 想用它又不想自己管

ECS 与 GKE 的区别书里点了一句:ECS 是任务(task)粒度、用自家编排引擎;GKE 是 pod 粒度、纯正 K8s4。托管服务的共同代价:vendor lock-in5。

3.4 架构:master 决策,worker 干活

一个 K8s 集群 = 1 到 N 个 master 节点(控制面) + 一堆 worker 节点(跑业务)6。master 上四个组件:

  • kube-apiserver:全集群的唯一入口和总机。所有组件之间、用户与集群之间,通信都经它;它做认证(证书/令牌)和授权(RBAC);它是唯一能与 etcd 对话的组件7。无状态,可多实例横向扩展。
  • scheduler(调度器):给新 pod 挑 worker 节点,分两阶段:过滤(把 CPU/内存不够、不满足 node selector、亲和性规则的节点刷掉)→ 打分(在剩下的里面按资源余量、现有负载排个名,挑最高分)8。
  • etcd:全集群状态的分布式键值数据库(节点信息、pod、service、配置),CoreOS 出品,用 Raft 共识算法保证多副本一致——leader 选举、日志复制,单节点故障不丢数据9。它就是「唯一事实」。
  • controller manager(控制器管理器):书里叫它「纠偏者」——定期对照「期望状态」和「实际状态」,不一致就动手:补建 pod、重启、扩缩10。

worker 上三个:

  • kubelet:每节点的执行官。拿到 PodSpec 就让容器运行时把容器起起来;监控健康(CPU/内存/存储),向控制面汇报11。
  • kube-proxy:每节点的网络管家。维护 iptables/IPVS 规则,把发给 service 的流量按轮询分到后端 pod——没有它,pod 之间、外部和集群之间就断了12。
  • 容器运行时:真正起停容器的人。书里一句关键的分工总结:运行时管「怎么干(how)」,Kubernetes 管「什么时候干(when)」13。

规模数字:K8s 1.29 官方支持单集群 5000 节点14。高可用要求多 master(通常奇数个,etcd 凑成集群),API server 前面挂负载均衡15。

3.5 核心概念:Pod 是原子,不是容器

Pod 是 K8s 的最小部署单位——一个或多个共享同一网络命名空间和存储的容器组成的组,有独立 IP,组内用 localhost 通信16。为什么不是直接用容器?因为紧密协作的伙伴(如应用容器 + 旁边的日志收集容器)该同生共死、共享存储。书里强调 pod 的三个性质:短命(死了不复活,由控制器造新的、IP 也变)、不自扩(要扩缩得靠 Deployment/ReplicaSet)、不持久(数据要 PV/PVC 机制)17。

最小 pod 定义长这样(照抄原书):

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mycontainer
    image: nginx

3.6 控制流:一条 kubectl 命令的旅程(主线例子走一遍)

kubectl create pod 之后,书里给了八步18:

  1. 命令到 API server,认证授权通过,把「要建一个 pod」写进 etcd(此时 pod 处于未调度状态)。
  2. API server 回复用户「正在创建」。
  3. scheduler 一直在问 API server「有没活干」;发现未调度的 pod。
  4. 调度器两阶段挑节点:过滤掉资源不够的,给剩下的打分,选中比如 Worker Node 2。
  5. 告诉 API server;API server 把「该 pod 应在 Node 2」写回 etcd。
  6. API server 通知 Node 2 的 kubelet。
  7. kubelet 指挥容器运行时把 pod 建起来。
  8. kube-proxy 同步网络规则,新 pod 能和别人通信了。

而 controller manager 全程盯场:任何时刻实际状态≠期望状态,它就纠正10。这套「声明期望 + 持续纠偏」就是 Kubernetes 全部魔法的一句话版本。

3.7 从代码到对外服务:七步流水线

写一个 404.html → 写 Dockerfile → build 镜像 → push 到仓库 → 定义 Pod → 定义 Deployment(管副本数,比如 3 个副本分布在 3 台节点)→ 建 Service(稳定入口)19。Deployment 与 Service 的关系:Deployment 管「有几个、什么版本」,Service 管「从哪进、怎么分到它们」20。

3.8 Service 三种暴露方式:按范围选

类型 谁能访问 机制 适用
ClusterIP(默认) 集群内部 分一个虚拟 IP(例:10.150.1.12:3000),转发到 pod 的 targetPort(5000),内部轮询 内部服务(如数据库)
NodePort 集群外经 <节点IP>:<NodePort> 在每个节点开一个 30000–32767 的端口(例:192.10.20.3:30010) 开发测试;生产不推荐(每个节点都开口,端口段只有 2768 个会冲突)
LoadBalancer 集群外经云厂商给的 IP 云负载均衡器 → NodePort → pod 生产对外服务

两个易错点书里特意标了:service 的 targetPort 必须等于容器的 containerPort,否则流量到不了21;NodePort 会自动附带一个 ClusterIP,它是 ClusterIP 的对外扩展22。更高级的 Ingress(HTTP/HTTPS 路由)和 service mesh(Istio/Linkerd)书里明确说超出本章范围23。

3.9 滚动更新与回滚:版本化的部署

主线例子继续:Deployment my-web-app 跑 5 个副本、镜像 my-web-app:1.0,执行

kubectl set image deployment/my-web-app my-web-app-container=my-web-app:2.0

K8s 开始 rolling update(滚动更新):先起一两个新 pod,过 readiness/liveness 健康探针,过了才杀等量旧 pod,逐批直到 5 个全换完;新 pod 探针失败就停住,必要时回滚24。

回滚:K8s 给每次部署记 revision 编号。kubectl rollout undo deployment/my-web-app 回到上一版,--to-revision=N 回到指定版;kubectl rollout history 看历史,kubectl rollout status 看进度25。回滚同样过健康探针,防止「滚回一个坏状态」26。

3.10 与 DevOps 的关系和 K8s 的代价

关系六条:自动化编排、微服务绝配、CI/CD 的部署端(滚动/金丝雀/蓝绿)、韧性(自愈+LB)、监控日志、安全合规(secrets/RBAC/网络策略)27。

代价四条,书里很诚实28:

  1. 继承了分布式系统全部难题:数据一致性、网络延迟、跨容器调试追踪难;
  2. 资源开销:控制面组件(API server、etcd、scheduler……)自己吃资源,监控日志(Prometheus、Elasticsearch)再吃一份,高可用要冗余再翻倍;
  3. 要专门的专家团队:学习曲线陡;
  4. 小负载不划算:三五个容器的小应用,自建 K8s 集群的复杂度远超收益。

4. 作者的判断与证据

有出处的:架构与组件职责与官方文档一致;5000 节点出自 K8s 官方大集群指南14;「市场份额 90%+」是书中论断29(该数字出处未给出,宜视为量级示意)。

作者的态度:对 K8s 是「推崇但有保留」——反复强调选不选看应用规模、团队能力、现有基础设施29,并如实列了四大挑战,没有当成银弹推销。

书里没展开、我们补的:声明式配置(Desired State)才是 K8s 与一切命令式编排的本质分野——书里讲了机制(期望 vs 实际),没给这个词;另外 5000 节点是「官方测试支持上限」不是「建议规模」(补充,来自通用知识)。

5. 边界与局限

  • Ingress、Helm、operator、stateful set、ConfigMap/Secret 只有名字或几行,全部推给「进一步阅读」23。
  • 网络安全策略、多租户隔离未展开。
  • 安装部分( Docker Desktop / Minikube / kubeadm)是 2024 年的界面截图,时敏。
  • 自建 vs 托管的决策框架只给了定性描述,没有成本对比。

6. 可带走的

  1. 编排系统解决六个问题:部署、扩缩、发现、更新回滚、利用率、监控——LetsShop 六问就是需求规格2。
  2. K8s = 声明式期望状态 + 持续纠偏:你声明「5 个副本」,controller 让世界永远凑齐 5 个10。
  3. API server 是唯一入口、etcd 是唯一事实、scheduler 挑机器、kubelet 干活、kube-proxy 管流量——五个角色记住就够用791112。
  4. Pod 是最小单位:共享网络与存储的一组容器;短命、不自扩、不持久1617。
  5. 建 pod 的八步流:apiserver 写 etcd → scheduler 过滤打分选节点 → 写回 etcd → kubelet 起容器 → kube-proxy 配网络18。
  6. Service 选型:内部用 ClusterIP;临时外部访问用 NodePort(端口段 30000–32767);生产对外用 LoadBalancer22。
  7. targetPort 必须等于 containerPort,这是最常见的接线错误21。
  8. 更新走 rolling update(新 pod 过探针再杀旧的),回滚靠 revision:rollout undo/history/status2425。
  9. K8s 的四大代价:分布式难题、资源开销、专家要求、小负载不划算28。

7. 原文地图

主题 原书章 原文位置
有无编排的对比、LetsShop 六问 7 - Containers orchestration system text/12-ch07-7-containers-orchestration-system.txt:51(搜「abstracts the underlying infrastructure」)
编排七能力 7 - Containers orchestration system text/12-ch07-7-containers-orchestration-system.txt:94(搜「Self-Healing」)
五套编排系统对比 7 - Containers orchestration system text/12-ch07-7-containers-orchestration-system.txt:224(搜「Comparison of popular container orchestration」)
master/worker 模型 7 - Containers orchestration system text/12-ch07-7-containers-orchestration-system.txt:165(搜「master-worker model」)
API server 唯一入口 7 - Containers orchestration system text/12-ch07-7-containers-orchestration-system.txt:510(搜「the only component in」)
调度两阶段 7 - Containers orchestration system text/12-ch07-7-containers-orchestration-system.txt:520(搜「Filtering or Predicate phase」)
etcd 与 Raft 7 - Containers orchestration system text/12-ch07-7-containers-orchestration-system.txt:543(搜「Raft consensus algorithm」)
kubelet 职责 7 - Containers orchestration system text/12-ch07-7-containers-orchestration-system.txt:554(搜「PodSpec」)
kube-proxy 与轮询 7 - Containers orchestration system text/12-ch07-7-containers-orchestration-system.txt:571(搜「round-robin」)
Pod 定义与三性质 7 - Containers orchestration system text/12-ch07-7-containers-orchestration-system.txt:583(搜「basic unit of deployment」) · text/12-ch07-7-containers-orchestration-system.txt:607(搜「won’t be resurrected」)
建 pod 八步控制流 7 - Containers orchestration system text/12-ch07-7-containers-orchestration-system.txt:628(搜「Control flow in Kubernetes」)
Deployment/Service 分工 7 - Containers orchestration system text/12-ch07-7-containers-orchestration-system.txt:663(搜「higher-level management construct」)
ClusterIP 示例(10.150.1.12:3000) 7 - Containers orchestration system text/12-ch07-7-containers-orchestration-system.txt:698(搜「default service type」)
NodePort 端口段与安全告诫 7 - Containers orchestration system text/12-ch07-7-containers-orchestration-system.txt:782(搜「30000 and 32767」)
三种 Service 对照表 7 - Containers orchestration system text/12-ch07-7-containers-orchestration-system.txt:813(搜「Comparison of ClusterIP」)
滚动更新全流程 7 - Containers orchestration system text/12-ch07-7-containers-orchestration-system.txt:885(搜「kubectl set image」)
回滚命令组 7 - Containers orchestration system text/12-ch07-7-containers-orchestration-system.txt:910(搜「rollout undo」)
四大挑战 7 - Containers orchestration system text/12-ch07-7-containers-orchestration-system.txt:972(搜「Complexity with Distributed Systems」)
90% 市场份额论断 7 - Containers orchestration system text/12-ch07-7-containers-orchestration-system.txt:1025(搜「more than 90%」)

  1. 出处:「7 - Containers orchestration system」第 41–59 段(text/12-ch07-7-containers-orchestration-system.txt:51,搜「abstracts the underlying infrastructure」)。 ↩

  2. 出处:「7 - Containers orchestration system」第 18–40 段(text/12-ch07-7-containers-orchestration-system.txt:29,搜「How to automatically scale」)。 ↩↩

  3. 出处:「7 - Containers orchestration system」第 61–147 段(自愈 :94 搜「automatically restarted」;扩缩 :79 搜「adjust the number」;滚动回滚 :114 搜「Rolling updates and rollbacks」)。 ↩↩↩↩

  4. 出处:「7 - Containers orchestration system」第 206–214 段(text/12-ch07-7-containers-orchestration-system.txt:210,搜「task-based approach」)。 ↩

  5. 出处:「7 - Containers orchestration system」第 216–223 段(text/12-ch07-7-containers-orchestration-system.txt:221,搜「vendor lock-in」)。 ↩

  6. 出处:「7 - Containers orchestration system」第 261–277 段(text/12-ch07-7-containers-orchestration-system.txt:264,搜「consists of two types of」)。 ↩

  7. 出处:「7 - Containers orchestration system」第 488–511 段(text/12-ch07-7-containers-orchestration-system.txt:510,搜「the only component in」)。 ↩↩

  8. 出处:「7 - Containers orchestration system」第 513–537 段(text/12-ch07-7-containers-orchestration-system.txt:520,搜「Filtering or Predicate phase」;:525 搜「Scoring or Priority Phase」)。 ↩

  9. 出处:「7 - Containers orchestration system」第 539–549 段(text/12-ch07-7-containers-orchestration-system.txt:543,搜「Raft consensus algorithm」)。 ↩↩

  10. 出处:「7 - Containers orchestration system」第 649–653 段(text/12-ch07-7-containers-orchestration-system.txt:650,搜「actual state matches the desired state」)。 ↩↩↩

  11. 出处:「7 - Containers orchestration system」第 551–560 段(text/12-ch07-7-containers-orchestration-system.txt:554,搜「PodSpec」)。 ↩↩

  12. 出处:「7 - Containers orchestration system」第 562–575 段(text/12-ch07-7-containers-orchestration-system.txt:571,搜「round-robin」)。 ↩↩

  13. 出处:「7 - Containers orchestration system」第 592–602 段(text/12-ch07-7-containers-orchestration-system.txt:593,搜「responsible for the “how”」)。 ↩

  14. 出处:「7 - Containers orchestration system」第 460–463 段(text/12-ch07-7-containers-orchestration-system.txt:462,搜「5000 nodes」)。 ↩↩

  15. 出处:「7 - Containers orchestration system」第 442–450 段(text/12-ch07-7-containers-orchestration-system.txt:442,搜「single point of failure」)。 ↩

  16. 出处:「7 - Containers orchestration system」第 577–608 段(text/12-ch07-7-containers-orchestration-system.txt:583,搜「basic unit of deployment」;:603 搜「using localhost」)。 ↩↩

  17. 出处:「7 - Containers orchestration system」第 606–626 段(text/12-ch07-7-containers-orchestration-system.txt:607,搜「won’t be resurrected」;:623 搜「not scaled horizontally by themselves」)。 ↩↩

  18. 出处:「7 - Containers orchestration system」第 628–654 段(text/12-ch07-7-containers-orchestration-system.txt:632,搜「sends a kubectl command」)。 ↩↩

  19. 出处:「7 - Containers orchestration system」第 673–695 段(text/12-ch07-7-containers-orchestration-system.txt:676,搜「404.html」)。 ↩

  20. 出处:「7 - Containers orchestration system」第 660–672 段(text/12-ch07-7-containers-orchestration-system.txt:670,搜「stable IP address and DNS name」)。 ↩

  21. 出处:「7 - Containers orchestration system」第 717–731 段(text/12-ch07-7-containers-orchestration-system.txt:726,搜「targetPort should match the containerPort」)。 ↩↩

  22. 出处:「7 - Containers orchestration system」第 733–787 段(text/12-ch07-7-containers-orchestration-system.txt:782,搜「30000 and 32767」;:786 搜「not recommended to use NodePort」)。 ↩↩

  23. 出处:「7 - Containers orchestration system」第 838–847 段(text/12-ch07-7-containers-orchestration-system.txt:839,搜「Ingress resource」)。 ↩↩

  24. 出处:「7 - Containers orchestration system」第 854–894 段(text/12-ch07-7-containers-orchestration-system.txt:885,搜「kubectl set image」;:891 搜「readiness and liveness probes」)。 ↩↩

  25. 出处:「7 - Containers orchestration system」第 896–922 段(text/12-ch07-7-containers-orchestration-system.txt:910,搜「rollout undo」;:902 搜「immediately preceding revision」)。 ↩↩

  26. 出处:「7 - Containers orchestration system」第 903–906 段(text/12-ch07-7-containers-orchestration-system.txt:905,搜「halt the rollback process」)。 ↩

  27. 出处:「7 - Containers orchestration system」第 933–966 段(text/12-ch07-7-containers-orchestration-system.txt:949,搜「Automated Orchestration」)。 ↩

  28. 出处:「7 - Containers orchestration system」第 968–1014 段(text/12-ch07-7-containers-orchestration-system.txt:972,搜「Complexity with Distributed Systems」;:1007 搜「not suitable for small」)。 ↩↩

  29. 出处:「7 - Containers orchestration system」Summary(text/12-ch07-7-containers-orchestration-system.txt:1025,搜「more than 90%」;:1036 搜「depends on the specific requirements」)。 ↩↩