Kubernetes
容器的操作系统，负责调度、伸缩和自愈
Kubernetes 不管怎么打包镜像，它管的是“这些容器跑在哪、跑几个、挂了怎么办、怎么被访问”。你用 YAML 描述期望状态（要 3 个副本），控制器不停对比实际状态并修正，这叫声明式 + 调谐循环。
它解决什么问题
几十个容器散在十几台机器上，手动部署、手动扩容、挂了手动重启，半夜被告警叫醒是常态。
真实场景：典型场景：提交一个 Deployment（replicas: 3），K8s 自动找空闲节点拉起 3 个 Pod；某个 Pod 挂了自动重建；流量涨了 HPA 自动扩到 10 个；Service 提供固定访问入口。
核心概念
每个概念一句话 + 一个类比。点击卡片看更详细的解释。
数据流转动画
跟着步骤看一条数据从进入系统到被处理完的完整路径，可以暂停、重播和调速。
从 kubectl apply 到一个可访问的服务
← 左右滑动查看完整流程图 →
kubectl 把 YAML 发给 API Server，校验后写入 etcd。
提示：声明式：你只写期望状态，控制器负责把现实拉回来。 悬停图中的节点可以看概念解释。
优劣势
短句说清适合什么、不适合什么，选型时先看这一栏。
- 自愈：进程挂了、节点挂了都能自动恢复
- 水平扩容和滚动更新是一等公民
- 声明式配置，环境可复制、可回滚
- 生态标准，几乎所有云厂商都支持
- 学习曲线陡，概念多、排查链路长
- 小团队维护集群成本高，托管版也有费用
- 网络、存储、权限（RBAC）都容易踩坑
- 不适合简单单体应用，杀鸡用牛刀
常见使用场景
每个场景都配一句「为什么用它」。
微服务集群
几十个服务统一部署、服务发现、灰度发布。
为什么用它：Service + Deployment 天然匹配微服务的部署模型。
弹性伸缩
大促期间 HPA 按 CPU/QPS 自动扩副本。
为什么用它：声明副本数 + 指标驱动，扩容不用人值守。
多环境一致性
开发/测试/生产用同一套 YAML，只改镜像 tag 和副本数。
为什么用它：配置即代码，环境差异被压缩到最小。
常见问题
上手第一个月最容易卡住的地方。
Q1Pod 和容器什么区别？
Pod 是最小调度单位，可以包含一个或多个容器，它们共享网络命名空间（同一个 IP）和挂载卷。绝大多数情况一个 Pod 一个容器，边车（sidecar）模式才放多个。
Q2Deployment 怎么做滚动更新？
改镜像 tag 后，Deployment 新建一个 ReplicaSet，逐步扩容新 RS、缩容旧 RS，由 maxSurge 和 maxUnavailable 控制节奏。失败可以 kubectl rollout undo 回滚。
Q3Service 的几种类型？
ClusterIP 集群内访问（默认）；NodePort 在每个节点开端口对外；LoadBalancer 找云厂商要负载均衡器；ExternalName 映射到外部域名。
Q4Pod 重启后 IP 变了怎么办？
不要直接用 Pod IP。用 Service 提供稳定虚拟 IP，或者用 Ingress 暴露 HTTP 入口。服务间调用写 Service 名，由 CoreDNS 解析。