7.5 通往 Kubernetes：自动化港区之门

7.5 通往 Kubernetes：自动化港区之门

本节摘要：全册收官——为什么单机编队终会不够用、自动化港区（Kubernetes）补的是哪块拼图、Compose 与它的概念对照表，以及一条不踩坑的进阶路线。本站不教 Kubernetes，教你怎么准备好学它。

单机编队的天花板

先诚实地承认工具的边界。第 6 章的编队再顺手，也有三件事它做不到：宿主机挂了业务跟着挂（没有跨机调度，机器故障就是业务故障）；流量涨了不能跨机扩容（单机配额是硬顶）；多台机器的箱子没人管账（哪台机器跑哪些箱子、坏了往哪迁，全靠人工台账）。这三件事的共同名字叫调度——跨机器资源池的自动化管理。

自动化的港区长什么样？你提交的不再是"在某某机器上起一只箱子"的指令，而是期望状态的声明："这个服务要同时有五只副本在跑，任一箱挂了补一只，宿主机满了往别处迁。" 机器的增减、箱子的迁移、故障的自愈，全部由港区中控自动完成。Kubernetes 就是这套中控系统的事实标准。

图 7-4：从单机编队码头到自动化港区

对照表先立起来——你会发现每个新名词都能在已学知识里找到锚点：

看最后一行——你在 Compose 里写的健康检查，在 Kubernetes 里只是换了关键字。这不是巧合而是必然：声明式思维、就绪语义、配额纪律，都是跨平台迁移的"通用货币"。这正是本教程坚持把概念讲透而不只教命令的原因。

概念初见：一份 K8s 风格的声明

提前看一眼彼岸的样子，只找感觉不抠细节：

# Kubernetes 风格的期望声明（Deployment，节选讲结构）
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3                      # 期望：同时保持三只副本
  selector:
    matchLabels:
      app: web
  template:
    spec:
      containers:
        - name: web
          image: registry.example.com/team/myapp:1.4.2
          resources:               # 配额纪律原样迁移
            requests:
              memory: "256Mi"
              cpu: "250m"
            limits:
              memory: "512Mi"
              cpu: "500m"
          readinessProbe:          # 就绪探针：Compose 健康检查的直系亲属
            httpGet:
              path: /health
              port: 8000
​

读这份文件不需要会写，只需要确认一件事：replicas 三副本、resources 配额、readinessProbe 就绪探针——每一块你在 Compose 章节都亲手玩过。差异在于 Kubernetes 把这些声明交给一个跨机器集群去持续兑现：某只副本挂了，中控在其他机器重新拉起；某台机器维护下线，箱子自动迁走。你的技能没有作废，只是升了一个量级。

再感受一下操作语言的迁移——同一个"发布新版本"的动作，两套世界的口令对照：

# Compose 世界：改声明里的标签，重申期望
docker compose pull && docker compose up -d

# Kubernetes 世界：同样只重申期望，中控负责兑现
kubectl set image deployment/web web=registry.example.com/team/myapp:1.4.3
kubectl rollout status deployment/web      # 看发布进度，支持一键 undo 回滚
# kubectl rollout undo deployment/web     <- 出问题退回上一版，一条命令
​

动词变了，"重申期望、中控兑现"的心法一字未变——这是从本章跨出去时最值得带走的行囊。

什么时候动身

不必急着跳船，三个信号出现任一，就值得动身：业务对单机故障零容忍（一挂就赔钱的业务）；需要跨机器弹性扩缩（流量潮汐明显，单机顶不住峰值）；微服务数量失控（箱子多到人工台账记不动）。信号未到之前，Compose 加一台可靠的宿主机能撑很久——过早引入编排平台的复杂度税，比单机的天花板更伤团队。

动身时的学习路线建议（顺序有讲究）：先用托管的 Kubernetes 集群或本地迷你集群（别在搭集群本身上先耗尽热情）；从Deployment加Service加Ingress三件套学起（覆盖日常九成操作）；把本教程的演习应用原样搬上去（同一只镜像、同一套健康检查，对照着学）；概念地图用"Compose 对照表"续写（每学一个新对象就更新你自己的对照表）。照这条路线，你的 Docker 功底每一分都能折现。再垫一句宽心话：到了那边，排障仍是本节的分诊五步法，只是观察工具从 docker 命令族换成 kubectl 一族；配额、健康检查、日志这些概念全部原样生效——学的只是新地图，不是新世界观。

航线尽头的话

全册主线在一票货的旅程中走完了：从认识港区（第 1 章）、靠港起航（第 2 章）、装箱造货（第 3 章）、起吊值勤（第 4 章）、接道修仓（第 5 章）、编队成军（第 6 章），到这一章把整支船队交托给航线。你带走的不是几十条命令，而是一套完整的容器化世界观：标准化交付物、声明式管理、配额与就绪的纪律、体系化的排障路径。自动化港区的门就在前面——而你，已经是合格的引水员了。

本节要点回顾

• 单机编队的天花板：跨机容错、弹性扩容、多机管账——三件事的共同答案是调度。
• Kubernetes 是期望状态声明加集群中控：声明什么，中控持续兑现什么。
• 对照表是你的护照：Pod、Deployment、探针、配额全部有 Compose 锚点。
• 动身三信号：零容忍故障、跨机弹性、服务数量失控；未到信号前别急着缴复杂度税。
• 学习路线：托管或迷你集群起步、三件套优先、原应用搬家对照学、对照表持续续写。

全册完。回望第 1 章那只铁皮箱子——它已经载着你到过很多港口了。