Kubernetes 是什么
这一课你将能做到
- 用自己的话说清 Docker Compose（单机编排）与 Kubernetes（集群编排）各自解决什么问题，以及「K8s 不替代 Docker」的原因
- 列出 K8s 的自愈、扩缩容、滚动发布、服务发现、资源调度五类核心能力，并各配一个本站（Spring Boot backend + MySQL + Nginx 前端）场景
- 解释「声明式 API / 期望状态」是什么，能向同事讲明白为什么
apply 一份 YAML 比逐台 SSH 改服务器可靠
为什么要学
你已经在 docker-essentials 里用 Compose 把本站跑起来了：Nginx 前端、Spring Boot backend、MySQL、Redis，一条 docker compose up 全起。单机演示完全够用。但只要换一个问法，Compose 就开始吃力：
- backend 流量翻倍，要跑 4 个副本，谁来负载均衡？
- 某台服务器半夜挂了，谁来把上面的容器拉起来？
- 发新版本，能不能做到用户无感知，出问题一键回滚？
这三个问题的答案就是容器编排（Orchestration），而 Kubernetes（常缩写 K8s，因为 K 和 s 之间有 8 个字母）是这一领域事实上的标准。人话：Docker 解决「一个应用怎么打包、在哪都能跑」，K8s 解决「几十上百个应用在一堆机器上怎么跑得好、挂了怎么办、怎么无感升级」。会开车不等于会调度整个车队。
面试视角：Java 后端岗位问到 K8s 的频率越来越高，开场题基本就是「K8s 是什么、解决什么问题」——这一课就是把答案打磨到能脱口而出。
先建立图像
单机 Docker： 一台机器上的若干容器，挂了要人管
Compose（单机编排）：你写 compose.yaml → docker compose up → 本机多个容器按依赖启动
K8s（集群编排）： 你写 YAML「我要 3 个 backend」
↓
API Server 记下期望状态
↓
控制器发现实际只有 2 个 → 自动补 1 个
↓
某个 Pod 挂了 → 自动重建，IP 变了也有 Service 兜住
| Docker Compose | Kubernetes |
|---|
| 规模 | 一台机器 | 多节点集群 |
| 扩缩容 | 手工改文件重启 | 一行命令或自动（HPA） |
| 自愈 | 只有重启策略 | 控制器自动重建到健康节点 |
| 发布 | 整组重建，常停机 | 滚动更新、可回滚 |
| 服务发现 | Compose 网络内服务名 | 全集群 DNS |
| 本站对应 | 本地开发/联调 | 生产部署的演进方向 |
关键认知：K8s 不构建镜像、不替代 Docker。你的 Spring Boot backend 镜像仍然由 Dockerfile 打出来、推到镜像仓库；K8s 只负责「跑几份、跑在哪、挂了怎么办、怎么对外服务」。
跟着做
步骤 1：安装 kubectl 客户端并验证
kubectl 是以后和集群对话的唯一日常工具，先装好客户端（本课还没有集群，装完即止）。
Windows（PowerShell）：
winget install -e --id Kubernetes.kubectl
或用 Chocolatey：
choco install kubernetes-cli -y
重开终端后验证：
应看到 Client Version: v1.3x.x 之类的输出。
步骤 2：盘点本站现有部署方式
在笔记里写三行：backend 怎么起的（jar 直接跑 / Docker）、MySQL 在哪、对外是 Nginx 还是裸端口。重点找「痛点」：哪一处是「挂了要人手动拉」「扩副本要人操作」——这些就是编排要接管的事。
步骤 3：读懂「声明式」最小样例
新建 intro-deploy.yaml（本课只读不跑）：
apiVersion: apps/v1
kind: Deployment
metadata:
name: backend
spec:
replicas: 3 # 期望状态：永远保持 3 个副本
selector:
matchLabels:
app: backend
template:
metadata:
labels:
app: backend
spec:
containers:
- name: api
image: your-registry/backend:1.0.0
命令式思维：docker run ...、docker stop ...，你下指令系统执行，错了要人修。
声明式思维：你只说「我要 3 个」，系统持续对比「实际有几个」，少了自动补。这是 K8s 一切能力的根基。
步骤 4：把本站四段映射到 K8s 对象
Nginx 前端 platform:3000 → Deployment + Service
Spring backend:8080 → Deployment + Service + ConfigMap/Secret
MySQL / Redis → 集群外托管，或 StatefulSet + PVC（进阶）
对外入口 Nginx 反代 → Ingress
顺手建立一个 Namespace 直觉：本站业务对象将来放进一个叫 coderoadmap 的命名空间，与系统组件隔离。
步骤 5：跑第一条「会失败」的命令，确认学习起点
现在应报 The connection to the server localhost:8080 was refused——这是正常现象：客户端装好了，集群还没有。下一课就把它修掉。把它当作里程碑：你现在与目标之间，只差「一个本地集群」。
讲清楚要点
- 容器解决「打包一致」，编排解决「规模与故障」：镜像让应用在哪都能跑；跑得多、机器多之后「谁来管」成为新瓶颈，K8s 回答这个问题。
- K8s 的核心是「期望状态 + 调谐循环」：你提交 YAML（期望），控制平面持续把实际状态调齐（reconcile）。删掉一个受管的 Pod 会立刻被重建——不是 Bug，是特性。
- K8s 消费镜像、不生产镜像：Dockerfile、镜像仓库的知识全部保留；本站 backend 镜像进 K8s 只是「运行环境升级」，不是推倒重来。
- 能力五件套挂在同一个模型上：自愈（控制器重建）、扩缩（改 replicas/HPA）、滚动发布（Deployment 策略）、服务发现（Service DNS）、调度（Scheduler 选节点）。
- 不是所有项目第一天都需要 K8s：单机小站 Compose 足够；出现多机、高频发布、多副本需求时再迁。学本 track 就是为那一天做准备。
- 面试标准答案先背住：「K8s 是容器编排平台，负责容器的自动化部署、扩缩容、自愈与服务发现」——一句话带出四个关键词，比长篇介绍更专业。
你可能会懵的地方
-
有 Docker 了，为什么还要 K8s？
Docker 管单机容器生命周期；K8s 管跨机器的调度、副本、故障迁移。本地开发继续用 Compose 很正常，两者是递进而非替代。
-
K8s 是一个「迷你操作系统」吗？
不是。它是集群的控制系统（API + 存储 + 调谐循环），你跑的还是普通容器进程。它像「数据中心级的服务管家」，不管你的 Java 代码怎么写。
-
本站现在必须迁移到 K8s 吗？
不必须。单机 Compose 可以一直撑到流量打满一台机器之前。本课价值在建立判断标准：出现哪几个信号（多副本、高频发布、自愈需求）时该上编排。
-
「编排」和 CI/CD 是一回事吗？
不是。CI/CD 负责「把镜像构建出来、决定何时发布」；K8s 负责「镜像进集群后怎么跑」。两者通过镜像 tag 衔接：CI 推新 tag → K8s 滚动更新消费新 tag。
-
为什么叫 K8s？
Kubernetes（希腊语「舵手」）首字母 K 与尾字母 s 之间恰好 8 个字母，社区简称 K8s。
错法对照
| 错法 | 问题 | 正解 |
|---|
| 没容器基础直接背 K8s YAML | 排错时连镜像、端口都分不清 | 先打牢 docker-essentials |
| 把 K8s 理解成「更好用的虚拟机」 | 模型错位，架构设计跑偏 | 它管容器工作负载，不管整机克隆 |
| 认为「上了 K8s 就不用运维」 | 网络、证书、备份照样要管 | 编排消除手工，不消除责任 |
| 一上来就上生产多租户集群 | 爆炸半径太大 | 先 minikube 本地练熟对象模型 |
| 「Docker 就是 K8s，差不多」 | 面试直接扣分 | 分清运行时与编排两层 |
卡点急救
kubectl 提示不是内部或外部命令：安装后未生效，重开终端；仍不行则把 kubectl 所在目录加入 PATH（winget 安装通常在 %LOCALAPPDATA%\Microsoft\WinGet\Links）。kubectl version --client 报错或版本过老：卸载重装最新版；注意别与 Docker Desktop 或 Minikube 自带的 kubectl 混淆冲突。- winget/choco 安装缓慢或失败：改从官方文档提供的直链下载 exe，放入 PATH 目录即可，安装方式不影响后续学习。
面试常问
-
Kubernetes 是什么？解决什么问题？
容器编排平台。容器解决了应用的打包与隔离，但多机场景下「跑几份、跑在哪、挂了谁管、怎么无感升级」是新问题。K8s 用声明式 API + 控制循环回答：你声明期望状态（3 副本、端口 8080），它持续把实际状态调谐到期望——自动调度、自愈、扩缩容、滚动发布、服务发现。
-
Docker Compose 和 Kubernetes 的区别？
Compose 是单机编排工具，适合本地开发与小规模部署；K8s 是跨节点集群编排，提供调度、自愈、水平扩缩、滚动更新与统一服务发现。一句话：Compose 管「一台机器上的一组容器」，K8s 管「一组机器上的一群容器」。
-
什么是声明式 API？为什么它重要？
你只描述期望状态（YAML），不写执行步骤；系统通过控制循环（reconcile loop）持续把实际状态向期望对齐。好处：可重复（同份 YAML 幂等 apply）、可自愈（偏差自动修复）、可版本化（YAML 进 Git 成为环境真相源）。
自测三问
- 举一个 Compose 完全够用的场景和一个必须上编排的场景。
- 「期望状态」四个字怎么理解？用 backend 三副本举例说明。
- K8s 会帮你构建镜像吗？你的 backend 镜像从哪来？
小结一句话
K8s 是集群级容器编排平台：在 Docker 镜像能力之上，用声明式 API 管理副本、自愈、扩缩与发布——本站从 Compose 走向生产，第一步就是吃透「期望状态 + 自动调谐」这个模型。
延伸