编程语言研究书库
Docker 容器完全指南(第 4 版)

容器编排 — 期望状态的管弦乐队

容器编排 — 期望状态的管弦乐队

这一章是全书的中轴。 前面所有章节在讲"容器"这个乐器怎么造、怎么吹; 从这一章起讲"乐队"怎么指挥。编排器(container orchestrator)做的事, 一句话:你声明期望状态,它让现实永远贴上去。 本章先把"它到底该会哪些事" 列成完整清单(这同时就是评估任何编排器的检查表),再盘点市面上的选手, 最后看趋势。

1. 为什么需要编排器:乐队的比喻

书里给的类比值得原样接住1:一个乐手独奏不需要指挥;一屋子乐手拿着交响曲谱子 即兴合奏,出来的只能是噪音。容器也一样——单机几个容器自己管得来; 一堆容器有不同宿主要求、以特定方式互相通信、还要随负载伸缩时, 就需要一个"指挥"让它们和谐演奏,这就是编排器1。

它要解决的,正是第 09 章那一串模式:服务发现、负载均衡、扩缩、自愈…… 编排器 = 这些模式的自动化实现1。

2. 顶层全景:十二项任务地图

  你 ──声明──▶ 期望状态(镜像、实例数、端口、网络……)
                  │
  ┌───────────────┼───────────────────────────────┐
  │ 调和 reconcile │ 副本崩了→补;缩容→杀;版本旧→换  │
  │ 服务形态        │ 复制式(要 N 个)vs 全局式(每节点1个)│
  │ 服务发现/路由   │ 实例在哪不用知道,接线员替你转    │
  │ 负载均衡        │ round-robin + 健康感知          │
  │ 扩缩            │ 上下都行;调度避开同节点/同机架/同可用区│
  │ 自愈            │ 探针:healthy?ready?由服务自己定义 │
  │ 存储            │ 临时存储随容器死;持久存储跨生命周期 │
  │ 零停机更新      │ 滚动(批处理+自动回滚)/蓝绿/金丝雀 │
  │ 安全            │ 节点 mTLS、网络策略、RBAC、secrets、内容信任、reverse uptime │
  │ 内省            │ 指标/日志/追踪 + exec 进容器调试   │
  └───────────────┴───────────────────────────────┘

  图说:这十二项就是"企业级编排器检查表"。
  下面对照 Kubernetes 的术语逐条走一遍——后面两章会反复用。

3. 核心原理:十二项任务逐项过

3.1 调和期望状态(reconciling the desired state)

你用声明式描述一个服务:用哪个镜像、跑几个实例、开哪些端口——这份宣言就是 期望状态(desired state)。编排器首次见到它:调度容器到集群节点(镜像不在就 先从注册表拉)、配网络端口,尽一切努力让现实精确匹配宣言2。

之后它持续监视,发现偏差就拉回来。书里列了三种典型偏差2:

偏差编排器的动作
一个副本崩了实例数少了 1 → 立即在别的节点调度新实例顶替
缩容了实例多了 → 随机杀掉多余实例,凑回目标数
某实例跑的是旧版镜像发现并替换

"监控偏差、纠正偏差"这件乏味的事,从此外包给编排器——前提是描述方式是 声明式而非命令式2。

3.2 复制式与全局式服务(replicated vs global)

集群节点分两类:manager(管理)节点专职管集群、不跑业务;worker(工作) 节点跑应用3。对应两种服务形态:

  • 复制式(replicated):要求跑指定份数(比如 10 个)——任何时候都保证 恰好这个数;
  • 全局式(global):要求每个 worker 节点上恰好一个实例,节点加几个就 自动有几个——Kubernetes 里这叫 DaemonSet(日志采集、监控代理这类 "每机一个"的服务就是它的用武之地)3。

3.3 服务发现:实例在哪,不该知道也不需要知道

声明式描述里绝不应该指定实例跑在哪些节点——放给编排器决定才是正路; 指定固定位置是反模式,除非极特殊情况4。既然实例可能崩、可能被调到别的节点, 追踪"某实例此刻在哪"是徒劳,而且根本不该追踪4。

那服务 A 怎么找到服务 B?大声说:它不该知道。 就像早期打电话要经过 总机接线员:编排器就是那个接线员,把 A 的请求转给一个可用的 B 实例。 这个过程就叫服务发现4。

3.4 路由与负载均衡

数据包从源到目标的疏导是路由(按 OSI 2–7 层,层数越高越懂应用语义, 第 7 层按 URL 分流)5。B 服务有多个实例时,负载均衡器拦下调用按 算法分发——最常用 round-robin(1、2、……n 再循环),并且只转给健康实例, 还定期检查每个实例的健康状况6。

3.5 扩缩与智能调度

负载会变(书里举了电商:晚间高峰、黑色星期五、清晨冷清),所以服务既要能上 也要能下。编排器调度时还要讲散布智慧:别把实例全放同一节点(节点挂=服务挂)、 别全放同一机架(电源挂=服务挂)、关键服务跨数据中心/可用区7。

现代编排器更进一步:按 CPU/内存/队列长度/自定义业务指标做水平+垂直自动扩缩 (K8s 的 HPA/VPA),配 Cluster Autoscaler 自动增减节点;云上还能成本感知—— 容错性好的负载优先调度到 spot/可抢占实例,省钱且维持期望状态8。

3.6 自愈:探针是服务与编排器的接缝

容器监控、自动替换崩溃实例、节点不健康就摘出调度循环并把负载挪走——这些自动 修复合称自愈9。但有一种故障编排器自己看不出来的:容器活着、 从外面看健康,里面的应用却已经"病"了(没崩,只是不能正常工作了)。 "健康"对每个服务含义不同,只有服务的作者知道9。

所以编排器定义了**探针(probes)**这道缝,问两个问题:

  1. 你健康吗(healthy)?
  2. 你准备好接流量吗(ready,还是暂时不可用)?

怎么回答完全由服务决定——编排器只定义怎么问(如 HTTP GET)和期望什么回答 (OK / NOT OK)。服务实现了这套问答,才是真正的自愈:不健康的杀掉换新, 暂时不可用的从 round-robin 里摘出去9。

3.7 存储:临时与持久

容器存储分两类10:

  • 临时存储(ephemeral):跟着容器生命周期走,容器一死数据就没——适合缓存、 可再生的临时数据;
  • 持久存储(persistent):与容器生命周期解耦,容器没了数据还在——用户数据、 数据库文件、配置。

编排器提供卷机制把持久存储挂给容器,支持块/文件/对象多种后端、对接云存储和 Ceph/GlusterFS 这类分布式存储,并自动化卷的创建、扩容、删除;还能定义 storage class(存储类)和策略来统一管理10。

3.8 零停机部署

发布周期从一年两次变成一周多次甚至一天多次,停机更新不可接受。编排器的答案11:

  • 滚动更新(rolling):一批一批换——任何时刻只停一两个实例,新实例正常 工作、无异常,才换下一批;失败就自动回滚到旧版。多数编排器原生支持;
  • 蓝绿:新旧并行,新版先内部冒烟测试,路由器一切换流;不对劲切回去;
  • 金丝雀:先导 1% 流量给新版(99% 还在旧版),盯紧,逐步加到 100%。

(与第 09 章对照:同一组模式,区别是这一次路由器后面站着的是编排器。)

3.9 位置感知(affinity 与拓扑散布)

有些服务需要特定硬件(GPU 图形处理器、SSD 固态硬盘);有些服务要求彼此挨着(缓存贴着数据库)或 彼此分开(互备实例分开)。编排器用亲和性(affinity)/反亲和规则表达 "想挨着谁、必须避开谁",把调度决策翻译成跨节点、跨机架、跨可用区的散布策略7。

3.10 安全:五件套加一记奇招

企业级编排器必须内建的安全能力12:

能力机制
节点身份每个节点有加密身份,节点间通信 mTLS(双向 TLS,传输加密)
网络安全网络策略(network policies):谁可以和谁通信,默认拒绝细化到服务级
RBAC授权三元组:主体(用户/组)× 角色(权限集)× 资源集合。开发组的 John 碰不到生产组的资源,反之亦然
Secrets加密存于高可用的集群状态库(静态安全);只发给运行该服务的节点;挂载为 **tmpfs(内存卷)**不落盘;传输走 mTLS(传输安全)。K8s 文档还建议配合 Vault/AWS Secrets Manager 这类更专业的密管
内容信任集群只运行签名镜像:确认作者可信、镜像新鲜、途中未被篡改(MITM)

外加一记书里少见的奇招——reverse uptime(反向运行时间)13: 黑客拿下某节点 root、掩藏行踪、以此为大本营横向攻击?容器是朝生暮死的, 节点也是分钟级可重建的——那就设个规矩:节点跑到一天就主动排空、摘除、 拆毁、换新。黑客的大本营没了。作者明说这是前瞻性想法、尚未普及, 但与工程师讨论后认为不难实现13。

3.11 内省(introspection):看不见的黑箱没人敢信

自动化再高,人也要看见集群里发生了什么。这叫内省,现代实现就是 可观测性三支柱14:

  • 指标——系统随时间的行为(资源用量、请求率、错误数),Prometheus 抓存、 Grafana 出图;
  • 日志——事件细节,Loki/Fluent Bit/Elasticsearch 聚合,容器死了信息不丢;
  • 追踪——单个请求跨服务的全程,Jaeger/Tempo + OpenTelemetry。

再加上主动手段:授权操作员可以 exec 进容器看环境变量、翻临时文件, 不需要登录宿主机14。

4. 选手全景:谁还在牌桌上

Kubernetes——事实标准。 Google 出身、捐给 CNCF;核心是声明式 + 调和循环 (控制面的心脏,自愈与韧性的来源);真正拉开差距的是可扩展架构—— 网络、存储、认证、调度几乎处处可定制,**CRD(自定义资源定义)**让任何人能给 K8s API 加新资源类型,服务网格边车、GitOps 控制器都建在这上面。生态层: Helm(包管理,一条命令装复杂应用)、Operator(把运维知识编码进软件, 自动备份/升级/扩缩)、GitOps 工具(Argo CD/Flux:manifest 存 Git, 可审计、可回滚、自动应用)。托管版 EKS/AKS/GKE 免控制面运维; 轻量发行版 K3s/MicroK8s 让笔记本和树莓派跑完整 K8s;演进中的 Gateway API 和边车容器支持。Linux 和 Windows 容器都支持15。

Docker Swarm——简单至上。 Docker Engine 内建,几条命令把一群 Docker 主机 变成集群,Compose 文件直接当服务定义,学习曲线几乎为零;默认开启节点间 mTLS、 证书自动轮换。今天处于维护模式,适合轻量部署、边缘集群和教学——它教会了 一代工程师编排的基本概念16。

其余席位(书里点名)17:托管 Kubernetes(EKS/GKE/AKS——各云把控制面 包走,第 17 章实操);HashiCorp Nomad——轻量、不限于容器(能调 VM、 Java 进程等异构负载);Apache Mesos——伯克利出身的老牌通用集群管理器, 已成历史注脚,但它的思想(Borg 系的两级调度)被 Kubernetes 发扬光大。

怎么选(书末的建议,要点)18:要可扩展、社区强、开放标准的大平台—— Kubernetes 是唯一答案;想要 Kubernetes 的威力又不想养控制面——用你已经在的 那朵云的托管服务; handful 服务、追求极简或教学——Swarm 仍有一席之地。

5. 新兴趋势四股

  1. Serverless 容器(Fargate/Cloud Run/Azure Container Apps): 仍打包成容器,但不再管节点和集群,按需扩缩、闲时缩到零—— 容器的一致性 + serverless 的弹性19;
  2. GitOps:Git 是唯一事实源,集群的每次变更都是一次 commit; Argo CD/Flux 盯着仓库自动调和现实;审计、回滚(走 Git 历史)、 代码评审全部适用——平台工程的运营主干19;
  3. 多集群与边缘:KubeFed/Anthos/Azure Arc 统一跨集群策略与部署; K3s/MicroK8s/k0s 让完整集群跑在小设备上,数据在哪,算力贴到哪19;
  4. AI 驱动的调度:Kueue、预测式 Cluster Autoscaler 用遥测和模型预测需求, 按性能、成本、能耗动态决策——走向"不用手工调参"的自治编排19。

6. 作者的判断与证据

  • **"编排器是模式的自动化"**是本章的总判断,与第 09 章严格对表(服务发现、 负载均衡、健康检查、自愈、滚动更新逐条可指)1。
  • 十二项任务是"at the time of writing, enterprise users typically expect"—— 作者明说这是当下企业期望的清单,不是永恒标准1。
  • reverse uptime被明确标注为"尚未广泛采用"的前瞻想法13——诚实标注 推测与现状的边界。
  • 选手评估(尤其 Swarm 的"历史地位"论)基于公开事实与维护状态,证据扎实16。

判断(我们的,不是书里的): 读编排器最好的心智模型是**"把第 09 章的模式 变成 API 对象"**:期望状态=Deployment,全局式=DaemonSet,接线员=Service, 探针=liveness/readiness,存储类=StorageClass,授权=RBAC…… 第 15 章的每个 K8s 名词都能在本章任务清单里找到"它自动化的是哪个模式"。 如果错,会错在: K8s 的对象模型比"十二项任务"更细(比如把"配置管理" 和"密钥"分成 ConfigMap/Secret 两类);映射是多对多,不是一一对应—— 但作为第一遍理解,这张表不会把人带歪。

7. 边界与局限

  • 本章是编录式的:每项任务只到机制层,没有实操(实操从第 15 章开始)。
  • 对编排器的反模式与成本(控制面复杂度、YAML 膨胀、"K8s 用于一切"的 过度工程化)着墨少,批判性视角要靠读者自带。
  • 多租户与硬隔离(命名空间之外的真正隔离)未展开。
  • 趋势一节是 2026 年快照;serverless 容器与边缘编排的产品名迭代极快。

8. 可带走的

  1. 编排器 = 期望状态的自动调和器;声明式是前提2。
  2. 复制式 vs 全局式(DaemonSet);manager 不跑业务3。
  3. 服务间不该知道实例位置——接线员(编排器)负责转接4。
  4. 自愈的关键是探针:healthy 和 ready 是两个问题,答案由服务定义9。
  5. 调度讲散布:节点、机架、可用区逐层铺开7。
  6. 存储分临时/持久;storage class 管供给10。
  7. 零停机三件套:滚动(自动回滚)/蓝绿/金丝雀(1% 起步)11。
  8. 安全五件套:mTLS 节点身份、网络策略、RBAC、secrets(静态+传输双安全)、 内容信任;外加 reverse uptime 的巧思1213。
  9. 内省 = 三支柱 + exec;黑箱没人敢信14。
  10. 选型:K8s 是默认答案;托管服务免养控制面;Swarm 留给简单与学习18。

9. 原文地图

主题原书章原文位置
指挥类比与定义What are orchestrators, and why do we need them?text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:19(搜「orchestra」) · text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:26(搜「in harmony」)
调和期望状态What are orchestrators, and why do we need them?text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:40(搜「Reconciling」) · text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:47(搜「desired state」) · text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:58(搜「crashes」) · text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:69(搜「delegate」)
复制式与全局式What are orchestrators, and why do we need them?text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:72(搜「Replicated and global」) · text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:81(搜「managers and workers」) · text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:91(搜「DaemonSet」)
服务发现(接线员)What are orchestrators, and why do we need them?text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:93(搜「Service discovery」) · text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:100(搜「anti-pattern」) · text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:111(搜「operator」)
路由What are orchestrators, and why do we need them?text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:115(搜「Routing」)
负载均衡What are orchestrators, and why do we need them?text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:140(搜「Load balancing」) · text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:150(搜「round-robin」)
扩缩与散布What are orchestrators, and why do we need them?text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:156(搜「Scaling」) · text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:165(搜「Black Friday」) · text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:168(搜「same cluster node」)
智能扩缩与成本What are orchestrators, and why do we need them?text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:176(搜「Intelligent autoscaling」) · text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:183(搜「horizontal and vertical」) · text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:188(搜「spot instances」)
自愈与探针What are orchestrators, and why do we need them?text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:192(搜「Self-healing」) · text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:210(搜「health status is service-dependent」) · text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:213(搜「probes」) · text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:221(搜「round robin」)
存储两类与供给What are orchestrators, and why do we need them?text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:222(搜「Data persistence」) · text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:228(搜「two main categories」) · text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:245(搜「Ceph」) · text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:249(搜「storage classes」)
零停机三件套What are orchestrators, and why do we need them?text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:258(搜「Zero-downtime」) · text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:275(搜「roll the updated instances back」) · text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:285(搜「1%」) · text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:291(搜「out of the box」)
RBACWhat are orchestrators, and why do we need them?text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:385(搜「RBAC」) · text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:398(搜「grant」) · text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:401(搜「create, stop, remove」)
Secrets 双安全What are orchestrators, and why do we need them?text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:407(搜「Secrets」) · text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:425(搜「tmpfs」) · text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:430(搜「secure both at rest」) · text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:436(搜「Vault」)
内容信任What are orchestrators, and why do we need them?text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:438(搜「Content trust」) · text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:446(搜「man-in-the-middle」)
reverse uptimeWhat are orchestrators, and why do we need them?text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:452(搜「Reverse uptime」) · text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:466(搜「one day」) · text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:469(搜「not yet broadly」)
内省三支柱What are orchestrators, and why do we need them?text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:475(搜「Introspection」) · text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:490(搜「three pillars」) · text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:499(搜「Prometheus」) · text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:511(搜「exec」)
K8s 事实标准Overview of popular orchestratorstext/155-fm-overview-of-popular-orchestrators.txt:54(搜「de facto」) · text/155-fm-overview-of-popular-orchestrators.txt:64(搜「reconciliation」) · text/155-fm-overview-of-popular-orchestrators.txt:68(搜「CRDs」) · text/155-fm-overview-of-popular-orchestrators.txt:73(搜「Helm」) · text/155-fm-overview-of-popular-orchestrators.txt:76(搜「Operators」) · text/155-fm-overview-of-popular-orchestrators.txt:80(搜「Argo CD」) · text/155-fm-overview-of-popular-orchestrators.txt:89(搜「K3s」)
Swarm 简史Overview of popular orchestratorstext/155-fm-overview-of-popular-orchestrators.txt:99(搜「simplicity」) · text/155-fm-overview-of-popular-orchestrators.txt:110(搜「mTLS」) · text/155-fm-overview-of-popular-orchestrators.txt:117(搜「maintenance mode」)
选型建议Overview of popular orchestratorstext/155-fm-overview-of-popular-orchestrators.txt:325(搜「default choice」) · text/156-fm-emerging-orchestration-trends.txt:2(搜「clear winner」) · text/156-fm-emerging-orchestration-trends.txt:6(搜「smaller setups」) · text/156-fm-emerging-orchestration-trends.txt:9(搜「Nomad」)
四股趋势Emerging orchestration trendstext/156-fm-emerging-orchestration-trends.txt:33(搜「Serverless containers」) · text/156-fm-emerging-orchestration-trends.txt:42(搜「scales the container instances」) · text/156-fm-emerging-orchestration-trends.txt:45(搜「GitOps」) · text/156-fm-emerging-orchestration-trends.txt:52(搜「Argo CD」) · text/156-fm-emerging-orchestration-trends.txt:58(搜「Multi-cluster」) · text/156-fm-emerging-orchestration-trends.txt:67(搜「K3s」) · text/156-fm-emerging-orchestration-trends.txt:73(搜「AI-driven」)

Footnotes

  1. 出处:「Chapter 14: Introducing Container Orchestration」的引入与「What are orchestrators, and why do we need them?」第 1–31 段(text/153-ch14-chapter-14-introducing-container-orchestration.txt:7,搜「rarely」;text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:25,搜「conductor」;:26,搜「in harmony」)。 ↩ ↩2 ↩3 ↩4 ↩5

  2. 出处:「What are orchestrators, and why do we need them?」第 40–70 段(text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:47,搜「desired state」;:52,搜「exactly match」;:58,搜「crashes」;:69,搜「delegate」)。 ↩ ↩2 ↩3 ↩4

  3. 出处:「What are orchestrators, and why do we need them?」第 72–91 段(text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:77,搜「specific number」;:80,搜「managers and workers」;:91,搜「DaemonSet」)。 ↩ ↩2 ↩3

  4. 出处:「What are orchestrators, and why do we need them?」第 93–113 段(text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:97,搜「up to the orchestrator」;:100,搜「anti-pattern」;:110,搜「operator」;:113,搜「service discovery」)。 ↩ ↩2 ↩3 ↩4

  5. 出处:「What are orchestrators, and why do we need them?」第 115–139 段(text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:120,搜「funneled」)。 ↩

  6. 出处:「What are orchestrators, and why do we need them?」第 140–155 段(text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:150,搜「round-robin」;:154,搜「healthy instance」)。 ↩

  7. 出处:「What are orchestrators, and why do we need them?」第 156–175、293–323 段(text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:165,搜「Black Friday」;:168,搜「same cluster node」;:175,搜「availability zones」)。 ↩ ↩2 ↩3

  8. 出处:「What are orchestrators, and why do we need them?」第 176–190 段(text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:183,搜「horizontal and vertical」;:187,搜「spot instances」)。 ↩

  9. 出处:「What are orchestrators, and why do we need them?」第 192–221 段(text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:201,搜「self-healing system」;:210,搜「service-dependent」;:213,搜「probes」;:221,搜「round robin」)。 ↩ ↩2 ↩3 ↩4

  10. 出处:「What are orchestrators, and why do we need them?」第 222–256 段(text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:228,搜「two main categories」;:231,搜「Ephemeral」;:235,搜「Persistent」;:244,搜「Ceph」;:249,搜「storage classes」)。 ↩ ↩2 ↩3

  11. 出处:「What are orchestrators, and why do we need them?」第 258–291 段(text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:269,搜「batch-wise」;:274,搜「roll the updated instances back」;:285,搜「1%」;:291,搜「out of the box」)。 ↩ ↩2

  12. 出处:「What are orchestrators, and why do we need them?」第 324–450 段(text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:389,搜「provide RBAC」;:398,搜「grant」;:425,搜「tmpfs」;:430,搜「secure both at rest」;:435,搜「Vault」;:442,搜「signed images」;:446,搜「man-in-the-middle」)。 ↩ ↩2

  13. 出处:「What are orchestrators, and why do we need them?」第 452–473 段(text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:466,搜「one day」;:470,搜「not yet broadly」;:472,搜「creative resilience」)。 ↩ ↩2 ↩3 ↩4

  14. 出处:「What are orchestrators, and why do we need them?」第 475–513 段(text/154-fm-what-are-orchestrators-and-why-do-we-need-them.txt:482,搜「introspection」;:490,搜「three pillars」;:499,搜「Prometheus」;:511,搜「connect to a container shell」)。 ↩ ↩2 ↩3

  15. 出处:「Overview of popular orchestrators」第 54–97 段(text/155-fm-overview-of-popular-orchestrators.txt:55,搜「undisputed standard」;:64,搜「reconciliation loop」;:68,搜「CRDs」;:73,搜「Helm」;:76,搜「Operators」;:80,搜「GitOps」;:84,搜「EKS」;:89,搜「K3s」;:97,搜「Windows containers」)。 ↩

  16. 出处:「Overview of popular orchestrators」第 99–125 段(text/155-fm-overview-of-popular-orchestrators.txt:104,搜「simplicity」;:110,搜「mTLS」;:117,搜「maintenance mode」;:121,搜「grasp the fundamental concepts」)。 ↩ ↩2

  17. 出处:「Overview of popular orchestrators」第 127–315 段(text/155-fm-overview-of-popular-orchestrators.txt:212,搜「GKE」;:244,搜「lightweight alternative」;:290,搜「Mesos」)。 ↩

  18. 出处:「Overview of popular orchestrators」第 325 段与「Emerging orchestration trends」的选型段(text/155-fm-overview-of-popular-orchestrators.txt:325,搜「default choice」;text/156-fm-emerging-orchestration-trends.txt:2,搜「clear winner」;:6,搜「smaller setups」;:9,搜「Nomad shines」)。 ↩ ↩2

  19. 出处:「Emerging orchestration trends」第 25–99 段(text/156-fm-emerging-orchestration-trends.txt:33,搜「Serverless containers」;:41,搜「no longer manage any nodes」;:42,搜「scales the container instances」;:45,搜「GitOps」;:54,搜「rollback」;:58,搜「Multi-cluster」;:67,搜「K3s」;:73,搜「AI-driven」;:82,搜「autonomous」)。 ↩ ↩2 ↩3 ↩4

容器安全 — 供应链、镜像信任、加固与运行时防线

Previous Page

Kubernetes 入门 — 从集群 anatomy 到 Pod、Deployment 与 Service

Next Page

On this page

容器编排 — 期望状态的管弦乐队1. 为什么需要编排器:乐队的比喻2. 顶层全景:十二项任务地图3. 核心原理:十二项任务逐项过3.1 调和期望状态(reconciling the desired state)3.2 复制式与全局式服务(replicated vs global)3.3 服务发现:实例在哪,不该知道也不需要知道3.4 路由与负载均衡3.5 扩缩与智能调度3.6 自愈:探针是服务与编排器的接缝3.7 存储:临时与持久3.8 零停机部署3.9 位置感知(affinity 与拓扑散布)3.10 安全:五件套加一记奇招3.11 内省(introspection):看不见的黑箱没人敢信4. 选手全景:谁还在牌桌上5. 新兴趋势四股6. 作者的判断与证据7. 边界与局限8. 可带走的9. 原文地图Footnotes