为什么需要 Kubernetes

从一台服务器说起#

假设你写了一个网站，要让它 24 小时在线。最开始的做法很朴素：租一台服务器，把程序跑在上面。

用户 → 服务器（跑着你的程序）

单机时代有两个绕不过去的问题：

• 程序之间会打架：两个应用依赖不同版本的 Python、不同的系统库，装在一起就互相破坏。
• 机器会挂：硬盘坏了、内存吃满被系统杀掉，服务就断了，而你往往在用户投诉后才知道。

于是有人发明了虚拟机：一台物理机切成多台，各自装各自的系统。隔离问题解决了，但每台虚拟机都要装一个完整的操作系统，启动慢、占用大。

容器解决了什么，没解决什么#

容器把「应用 + 依赖」打包成一个镜像，共享宿主机的内核，启动只要几百毫秒。用一条命令就能跑起来：

docker run -d -p 8080:80 --name web nginx:1.27

这一步之后，你的应用有了一个可复制的标准件。但把它放到生产环境，你马上会撞上一堆新问题：

单靠 docker run，这些都得靠人肉运维脚本。Kubernetes 就是为了接管这一层工作而生的。

Kubernetes 到底做了什么（一句话）#

你把「期望的状态」写下来交给它，它负责让现实世界不断向这个状态靠拢。

比如你说「我要 3 个 nginx 副本，每个都要健康」，那么：

• 某个 Pod 挂了，它重新拉一个起来；
• 某台机器断电了，它把上面的 Pod 调到别的机器；
• 你把 3 改成 5，它自己去起 2 个新的；
• 你换了镜像版本，它会一个一个替换，保证服务不中断。

这句话里藏着两个贯穿全课程的关键词。

声明式（Declarative）#

你不写「第一步做什么、第二步做什么」，而是写「最终要变成什么样」：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3 # 我期望有 3 个副本
  template:
    spec:
      containers:
        - name: web
          image: nginx:1.27

剩下的「怎么达成」由 Kubernetes 负责。这和 docker run 的命令式思路完全不同，也是新手最容易不适应的地方：别问「怎么操作」，要问「我想让它是什么样」。

控制器（Controller）#

Kubernetes 内部有一批「控制器」，每个控制器只做一件事：盯着某类资源，发现现实和期望不一致就动手修正。Deployment 控制器管副本数，ReplicaSet 控制器管 Pod 数量，Node 控制器管节点健康……

理解了这个模式，后面学的每一个资源（Deployment、Service、Ingress、Job）你都能问同一个问题：它是谁在盯着？期望状态写在哪里？

不用 Kubernetes 也能理解的对照#

同样一件事，两种做法对比一下就很清楚了。

Kubernetes 不解决什么#

前面讲的都是它能替你做什么，边界同样重要。把 Kubernetes 当成「万能运维机器人」是新手最容易失望的地方：它只对「你声明的容器期望状态」负责，其它事情仍然是你的责任。

换句话说，它把「容器怎么可靠地跑起来」这一层标准化了，但它不替你决定应用长什么样，也不替你负责数据。

一套应用在 Kubernetes 里的样子#

先建立一个整体印象，后面每一章都会拆开讲其中一块。假设你要部署一个「前端 + API + 数据库」的应用，在 Kubernetes 里的典型构成是：

用户
 │
 ▼
Ingress（域名与路由规则）
 │
 ▼
Service（稳定的虚拟 IP + DNS）
 │
 ▼
Deployment（管理多个 Pod 副本）
 │
 ▼
Pod（真正运行容器的最小单元）
 ├── ConfigMap / Secret（配置）
 └── PVC（持久化存储）

每一层对应一站，按这个顺序学下去：

横切在所有资源之上的还有：命名空间与权限（第 12 章 命名空间与 RBAC）、健康探针与资源配额（第 11 章 探针与资源管理）、排障手段（第 15 章 排障手册）。

动手感受一下「没有人帮你重启」是什么体验#

这一章不需要集群，只需要 Docker。我们要亲手制造一次「容器挂了没人管」的场景，这样你才会真正理解 Kubernetes 的价值。

docker run -d --name web nginx:1.27
docker ps --filter name=web

docker exec web nginx -s stop
docker ps -a --filter name=web

docker start web
docker ps --filter name=web

docker rm -f web

这段练习就是 Kubernetes 存在的全部理由：它把第三步那个动作，变成了集群默认行为。

怎么学才不迷路#

新手最容易掉的坑是按「kubectl 命令大全」来学，结果记住了一堆命令但串不起来。建议按这个顺序：

1. 先建立心智模型：知道每个资源解决什么问题（本模块 + 第 2 章 集群架构）。
2. 再动手跑起来：用 第 3 章 把本地集群装好，之后每章都跟着敲。
3. 永远用 YAML 而不是命令：kubectl run 只是临时试验，真正的工作方式是 kubectl apply -f。
4. 出问题先 describe 再 logs：第 15 章 排障手册 会给你一套固定的排查顺序。

常见坑：这一章最容易想错的地方#

这一章还没有集群，踩的坑都在认知上。下面这张表是新手最常见的几种误解，以及怎么自己确认。

自测题#

小结#

• 容器解决的是「打包与隔离」，Kubernetes 解决的是「可靠地运行与调度」。
• Kubernetes 的核心思路是声明式：写期望状态，由控制器不断把现实拉回期望。
• 一个典型应用由 Ingress → Service → Deployment → Pod 逐层承载，旁边挂着配置、存储、权限与健康检查。
• 它不解决业务正确性、数据一致性、镜像构建与安全加固，边界要提前想清楚。

相关章节：第 2 章 集群架构 讲清这套机制跑在哪些组件上；第 6 章 Deployment 是「控制器」最典型的落地例子。

练习#

1. 用一句话向同事解释：为什么有了 Docker 还需要 Kubernetes？
2. 翻到本站的速查表，找出「查看节点」和「查看所有命名空间的 Pod」两条命令，先混个眼熟。
3. 想一下你手头最熟悉的一个服务，如果把它搬到 Kubernetes，需要哪些资源？（不用真的写，列出名字即可，学完 第 5 章 用 YAML 描述 Pod 再回来对照。）

下一章我们会把集群拆开看：控制平面和节点上分别跑着什么，为什么一个集群至少需要哪些组件。