06 · 容器编排与 K8s 概念
容器解决"单机怎么跑"，编排解决"多机怎么管"。Kubernetes（K8s）是事实标准，但对小团队往往过重。本篇讲 Pod/Deployment/Service 三大概念、声明式思维、何时才需要 K8s。先给结论：先判断"你真的需要编排吗"，再谈概念；多数前端转全栈阶段用
docker compose就够。
速览卡
| 项 | 内容 |
|---|---|
| 一句话定位 | 理解编排解决什么问题，以及要不要上 K8s 的判断框架 |
| 核心内容 | 容器编排动机、Pod/Deployment/Service、声明式、调度与扩展、何时别用 |
| 读完能回答 | Pod 和容器什么关系？K8s 到底解决哪类痛？小项目该不该上？ |
| 相关板块 | D01 · Docker ｜ D02 · 部署 CI/CD ｜ C05 · 服务架构 |
一、先给结论：编排解决三个"单机搞不定"的问题
text
① 多机调度：容器放哪台机器跑？
② 自动恢复：机器/容器挂了怎么办？
③ 统一入口：多实例怎么对外提供稳定服务？一句话：单容器用 Docker，多容器一台机用 Compose，多机 + 自愈 + 弹性才需要编排。
二、从 Compose 到 K8s：什么时候升级
| 阶段 | 方案 | 什么时候够 |
|---|---|---|
| 单容器 | Docker | 一个服务自己玩 |
| 多容器单机 | Docker Compose | 前后端 + 依赖都在一台机 |
| 多机多服务 | 托管容器平台 | 不想自己运维集群 |
| 完整编排 | Kubernetes | 高可用、自愈、弹性是硬需求 |
决策关键：如果你能数出"这台机器、那个服务"怎么部署，说明还没到 K8s 的复杂度。K8s 的收益来自"无需关心机器"，前提是你有足够的服务规模。
三、三大概念：Pod、Deployment、Service
3.1 Pod：最小的调度单元
text
Pod ≈ 一个"能一起调度、共享网络"的容器组（通常 1 容器）| 概念 | 类比 |
|---|---|
| Pod | 一个"房间"（容器是房间里的进程） |
| 多容器 Pod | 需要共享存储/网络的极少数场景 |
3.2 Deployment：声明"我要几个、什么版本"
yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: api
spec:
replicas: 3
selector:
matchLabels:
app: api
template:
metadata:
labels:
app: api
spec:
containers:
- name: api
image: ghcr.io/you/api:abc123
ports:
- containerPort: 8000| 作用 | 说明 |
|---|---|
| 期望状态 | 声明"3 个副本" |
| 自愈 | 挂了自动补，滚动更新按策略替换 |
| 版本化 | 改镜像 tag 即发新版，支持回滚 |
3.3 Service：稳定的入口
text
Pod 的 IP 会变，Service 提供一个稳定 VIP/DNS，把流量转发给标签匹配的 Pod| 类型 | 场景 |
|---|---|
| ClusterIP | 集群内部访问（默认） |
| NodePort | 简单对外暴露 |
| LoadBalancer | 云厂商负载均衡 |
| Ingress | 域名/路径路由到多个 Service |
心智模型：Deployment 管"有多少个实例"，Service 管"怎么稳定地找到它们"，Ingress 管"外部怎么按域名/路径进来"。
四、声明式思维：从"步骤"到"期望状态"
text
传统运维：执行命令 → 达到状态
K8s： 写期望状态 → 控制器持续对齐| 面 | 做法 |
|---|---|
| 命令式 | docker run ...、写脚本一步一步做 |
| 声明式 | kubectl apply -f deployment.yaml，K8s 负责对齐 |
前端类比：像声明式 UI（React/Vue 的数据驱动）——你不描述"怎么改 DOM"，只描述"应该长什么样"。K8s 对基础设施同理。
五、调度与弹性：K8s 凭什么"自动"
| 能力 | 说明 |
|---|---|
| 调度器 | 按资源/亲和性决定 Pod 放哪台机器 |
| ReplicaSet | 保证副本数与期望一致 |
| HPA | 按 CPU/自定义指标自动扩缩 |
| 滚动更新 | 分批替换，配合就绪检查 |
| 亲和/反亲和 | 控制 Pod 分布（跨机高可用） |
把 D02 的发布策略搬到 K8s：滚动更新、蓝绿、金丝雀都有对应控制器/流程，健康检查（存活/就绪）是它们能成立的前提。
六、别急着上 K8s：成本清单
| 成本 | 说明 |
|---|---|
| 运维负担 | 集群升级、节点管理、网络/存储排障 |
| 学习曲线 | 声明式 + 大量 YAML + 新概念 |
| 资源开销 | 控制平面与额外抽象不便宜 |
| 调试变难 | 多副本/多节点让"本地复现"更难 |
推荐路径：先用托管容器平台（云厂商托管 K8s/Serverless）感受声明式收益，再决定要不要深入 K8s 自建。别为"简历好看"给 3 个服务搭集群。
七、自检清单
- [ ] 能说清 Pod、Deployment、Service 各管什么
- [ ] 知道 Compose → 托管平台 → K8s 的升级条件
- [ ] 能读懂一份 Deployment YAML 的关键字段
- [ ] 知道 Service 与 Ingress 的分工
- [ ] 能列出上 K8s 的三种成本，并判断当前项目该不该上
八、常见误区
| 误区 | 事实 |
|---|---|
| "Pod 就是容器" | Pod 是最小调度单元，通常一容器但概念不同 |
| "上了 K8s 就高可用" | 高可用要副本、反亲和、就绪检查配合 |
| "小项目也该用 K8s" | 编排解决多机问题，单机用 Compose 更省 |
| "Service 就够对外了" | 对外暴露一般要 Ingress/LoadBalancer |
| "YAML 多就是专业" | 声明式是把复杂度转移到理解与维护上 |
九、动手练习
练习 A：翻译 Compose 到 K8s
把自己一个 Compose 服务（含健康检查）翻译成 Deployment + Service，对比两者的声明差异。
练习 B：体验声明式
在 Kind/Minikube 起一个单节点集群，apply 一份 Deployment，删掉一个 Pod 观察自动重建。
练习 C：做一次要不要上 K8s 的评估
给自己负责的服务列"规模、可用性要求、运维人力"三项，按文中的升级条件给出结论并说明理由。
相关文档
本区
- 01 · Docker 与容器化 —— 镜像与 Compose 前置
- 02 · 部署与 CI/CD —— 发布策略与健康检查
- 05 · 可观测性基础设施 —— 多实例下的观测
- D 域 README
其他域
- C05 · 服务架构 —— 微服务与单体取舍
- C08 · 可观测性 —— 集群内观测
- S06 · 运维安全 —— 集群凭证与最小权限