04 - 必须认识的几个核心概念

这是本教程最重要的一章。K8s 概念多得吓人，但对入门来说，你只要认识下面这几个”主角”，就能听懂绝大多数讨论了。

我们不讲 YAML 细节，只用生活类比把每个概念的作用讲清楚，最后用一个”部署 AI 服务”的例子把它们串起来。

先给你一张关系图

        Ingress（大门 / 门牌路由）
              │  把外部流量按域名/路径引进来
              ▼
        Service（固定入口 + 负载均衡）
              │  稳定地代表一组 Pod
              ▼
   ┌──────────┼──────────┐
   ▼          ▼          ▼
 Pod        Pod        Pod      ← Deployment 保证"永远有 3 个这样的 Pod 在跑"
（装着容器）（装着容器）（装着容器）

  ConfigMap / Secret：给上面的 Pod 提供配置和密钥

下面逐个讲。

1. Pod —— 最小的运行单位

Pod 是 K8s 里能运行的最小单位，里面装着一个（偶尔是几个）容器。

你可能会问：不是有容器了吗，为什么还要包一层 Pod？

因为 K8s 不直接管”容器”，它管的是”Pod”。Pod 是容器的一层薄薄的包装。
绝大多数情况：一个 Pod 里就一个容器，你可以粗略地把 Pod 约等于”一个运行中的容器实例”。
偶尔一个 Pod 里会放几个关系极其紧密、必须同生共死的容器（进阶话题，入门不用管）。

类比：如果容器是”货物”，Pod 就是把货物放进去、贴上标签、能被码头系统识别和调度的那层标准托盘。

关键认知：Pod 是”用完即弃”的。 它随时可能被销毁、被重建（换台机器、扩缩容、更新时都会）。所以你不该关心某一个具体的 Pod——这引出了下一个概念。

2. Deployment —— 声明”我要几个，一直保持”

Deployment 负责保证”始终有你指定数量的 Pod 在健康运行”。

你不用一个个手动创建 Pod，而是告诉 Deployment：

“我要 3 个这个 AI 服务的 Pod，一直给我保持着。”

然后 Deployment 就会：

挂了一个 → 自动补一个新的（自愈）
你想扩容 → 把数字从 3 改成 10，它自动多拉 7 个（扩缩容）
你要发新版本 → 它一个个平滑替换旧 Pod，不断服（滚动更新），出问题还能一键回滚

类比：Deployment 就像牧场的”存栏管理员”。你说”永远给我保持 100 头健康的牛”，它自己盯着，死一头补一头，要扩群就多养几头。你不关心具体哪头牛，只关心”总数和健康”。

这是你日常打交道最多的概念。 部署业务，基本就是写个 Deployment。

3. Service —— 给一组 Pod 一个固定入口

Pod 是用完即弃的，会不断被销毁重建，它的地址（IP）一直在变。那别的服务、或者用户，怎么稳定地找到它？

Service 给一组 Pod 提供一个”固定不变的入口地址”，并自动把请求负载均衡地分发到背后的多个 Pod 上。

不管背后的 Pod 怎么增减、重建、换 IP，Service 这个入口始终不变。
请求打到 Service，它自动帮你分发给背后健康的某个 Pod。

类比：Service 就像餐厅的前台总机号码。后厨的厨师（Pod）今天来 3 个、明天换 5 个、有人请假换人，你都不用管——你永远只拨那个总机号，总机自动把你的需求转给当前在岗的某位厨师。

一句话：Service = 稳定入口 + 自动负载均衡。

4. Ingress —— 把外部流量按规则引进来

Service 解决了”集群内部怎么稳定找到服务”。但外部用户（浏览器、App）怎么通过域名访问进来？这就是 Ingress。

Ingress 是集群的”大门 + 智能门牌”，负责把外部流量按域名和路径，路由到对应的 Service。

比如：

api.你的域名.com → 转给”AI 服务”的 Service
www.你的域名.com → 转给”网站前端”的 Service
还能统一在这里配 HTTPS 证书

类比：Ingress 就像一栋写字楼的大堂前台 + 楼层指引牌。所有访客先到大堂，前台看你找哪家公司（域名/路径），再指引你到对应楼层（Service）。

5. ConfigMap / Secret —— 配置和密钥

你的应用总有些配置项和敏感信息：数据库地址、API Key、开关参数……总不能写死在镜像里（改一次就得重新打包）。

ConfigMap：存放普通配置（如环境变量、参数），和镜像解耦，改配置不用重新打包镜像。

Secret：专门存放敏感信息（如密码、API Key、证书），用法类似 ConfigMap，但会做特殊保护。

类比：ConfigMap 是贴在设备上的”参数说明卡”，Secret 是锁在保险柜里的”密码条”。应用运行时按需取用，和应用本身分开管理。

把它们串起来：部署一个 AI 服务

现在用一个完整场景把这几个概念连起来。假设你要上线一个 FastAPI 写的 AI 服务：

打镜像：先用 Docker 把 AI 服务打成镜像（这是 Docker 教程学过的）。
Deployment：写个 Deployment，说”用这个镜像，给我跑 3 个副本，一直保持”。→ K8s 自动在合适的 Node 上拉起 3 个 Pod。
Pod：这 3 个 Pod 就是真正在跑的 AI 服务实例。挂了？Deployment 自动补。
Service：建个 Service 指向这 3 个 Pod，得到一个固定入口，请求自动均衡分发。
Ingress：配个 Ingress，把 api.你的域名.com 的流量转给上面这个 Service，并挂上 HTTPS。
ConfigMap / Secret：把模型路径、开关这类配置放 ConfigMap，把 API Key、数据库密码放 Secret，注入给 Pod 使用。

于是：用户访问 api.你的域名.com → Ingress 接住 → 转给 Service → Service 均衡分发给某个 Pod → Pod 里的 AI 服务处理请求。中间任何一个 Pod 挂了、你要扩容到 10 个、你要发新版本，K8s 全自动帮你搞定，用户毫无感知。

[配图：用户从域名进入，箭头依次穿过 Ingress → Service → 三个 Pod，旁边 Deployment 用虚线”守护”着这三个 Pod，ConfigMap/Secret 从侧面注入 Pod]

小结

记住这 5 个主角和它们一句话的作用：

概念	一句话作用	生活类比
Pod	最小运行单位，装着容器，用完即弃	装货物的标准托盘
Deployment	保证”永远有 N 个健康 Pod 在跑”，管扩缩容和更新	牧场存栏管理员
Service	给一组 Pod 固定入口 + 负载均衡	餐厅前台总机
Ingress	把外部流量按域名/路径引进来	写字楼大堂前台
ConfigMap / Secret	存配置 / 存密钥，与镜像解耦	参数卡 / 保险柜

搞懂这几个，你就能听懂绝大多数 K8s 讨论了。下一章讲一个比记概念更重要的东西——K8s 的灵魂思想：声明式。

上一章 ← 03 - 一张图看懂 K8s 的组成｜下一章 → 05 - 声明式思维