K8s三件套：Pod、Service与Deployment

可视化演示

动态演示K8s三件套的核心机制，通过全局/局部/动态/静态四种模式展示关键概念与交互流程。

K8s入门总览

小张的“深夜食堂”在一条街上连开了五家分店，每家店的灶台数量、营业时间、员工排班都不一样。靠人肉管理显然行不通，他需要一套“总部管理系统”：总部下达指令，各分店执行报告，所有状态汇到一块大屏上。Kubernetes 就是这套餐饮集团的总部管理系统，只是它管理的不是门店，而是成千上万个容器。

K8s 的名字来源于希腊语“舵手”，由 Google 基于内部 Borg 系统开源。它解决的核心问题是容器编排：当你要部署 100 个 AI 推理服务实例，靠手动 docker run 会疯掉的。K8s 让“运维厨房”自动化——你只需要告诉系统“我想要什么”，它会自己搞定“怎么实现”。

从架构上看，K8s 集群由两类角色组成：Master（主节点）是总部大脑，负责调度、认证、存储配置；Node（工作节点）是各分店厨房，真正运行 Pod。日常你通过 kubectl 命令行工具与集群对话，就像用手机 App 给总部下指令；而 YAML 文件里的内容，就是你和总部签的“服务标准合同”。这套声明式管理的核心思想，可以浓缩成一个收敛公式：

一句话回扣：就像总部盯着各分店的实际营业额与目标营业额，差距大就加派人手、调整菜单，K8s 控制器就是那个永不休息的区域经理。理解了这套“期望—实际—调节”的循环，三件套的戏份就好安排多了。

Pod核心概念

深夜食堂的后厨里，每个灶台都配好了燃气、排烟管和案板。一个灶台可以只给一位厨师用，也可以两位厨师共用——一位颠勺、一位配菜，他们共享同一个台面空间和调味料架。在 K8s 里，这个“灶台”就是 Pod，而灶台上的厨师们，就是容器。

Pod 是 Kubernetes 中最小的调度和部署单元。以前我们直接用 Docker 启动容器，但在 K8s 中，容器必须被“包”进 Pod 里运行。Pod 里的多个容器共享同一个网络命名空间和存储卷：它们可以用 localhost 互相通信，也可以读写同一块数据盘。最常见的例子是“主容器 + 边车容器”：主容器跑 AI 模型推理，边车容器专门采集日志、转发监控指标，两者同生共死。

Pod 的存在是“短命”的。它可能因为节点宕机、内存不足、探针失败而被删除重建。每次重建，Pod 的 IP 都会变化，就像灶台随时可能被拆掉换新址，但灶台本身的功能不变。一个 Pod 的生命周期会经历 Pending（排队等资源）、Running（正常运行）、Succeeded（成功退出）或 Failed（异常退出）等状态。K8s 会通过重启策略决定是否把“死掉”的 Pod 拉起来重跑。Pod 的多容器特性和共享拓扑，可以写成这样：

回扣比喻：正因为灶台（Pod）会随时被拆掉重建，顾客（请求）才不能永远记着某个灶台的位置。这就轮到服务员（Service）登场了——她不需要关心后厨的灶台换了几轮，只需要提供一个永远不变的“点餐窗口”。

Service网络机制

深夜食堂的顾客永远不会直接冲进后厨找灶台，那样既危险又混乱。服务员站在门口，顾客只要说“来一份鱼香肉丝”，服务员就会下单，让后厨任意一个空闲灶台来做。对顾客来说，他始终只面对同一个“点餐窗口”——这就是 Service 的角色。

在 K8s 里，Pod 随时会重建，IP 也跟着变。如果 A 服务直接记录 B 服务的 Pod IP，B 一重启，A 就找不到它了。Service 提供了一个稳定访问入口，可以是固定的虚拟 IP（ClusterIP），也可以是一个 DNS 名字。用户请求打到 Service 上，Service 再转发给后端的某一个 Pod。

Service 怎么知道该把流量转给谁？靠的是标签选择器（selector）。Pod 上有标签，比如 app: nginx 或 tier: backend；Service 声明“我要选择哪些标签的 Pod”，凡匹配的 Pod 自动进入它的后端列表，不匹配的则被剔除。这就像服务员手里有一份“会做鱼香肉丝的厨师名单”，新厨师入职时贴上菜系标签，就自动补进名单；离职时撕掉标签，就自动移出名单。Service 内部通过 kube-proxy 组件实现负载均衡，默认是轮询算法，每个后端 Pod 被选中的概率是均等的：

回扣比喻：服务员（Service）最棒的地方是，她手里那张“厨师名单”永远实时更新。哪怕后厨灶台全换新了，顾客依然在同一个窗口点单——这正是微服务之间通信的基础。

Deployment发布控制

店长小张每天要操心三件事：后厨开几个灶台、灶台坏了要不要补、新菜单怎么在不影响营业的情况下换上去。这些事，在 K8s 里都由 Deployment 负责，它堪称最称职的店长。

Deployment 是一种控制器资源，它负责描述“应用期望的最终状态”：副本数要几个、用哪个镜像版本、资源限制是多少。你只需要写一份 YAML，Deployment 就会保证集群里时刻有这么多 Pod 在运行。Pod 挂了，它立刻重建；副本不够，它立刻扩容。它不直接创建 Pod，而是通过管理 ReplicaSet（副本集）来间接控制 Pod。

比起“保证数量”，更体现店长功力的是滚动更新（Rolling Update）。假设你的 AI 模型从 v1 升级到 v2，Deployment 不会把旧的 3 个 Pod 全部杀掉再开新的，而是像旧灶台换新灶台一样：先起一个新 Pod，等它 ready，再停掉一个旧 Pod。整个过程服务不中断，随时有可用的 Pod 在接客。更贴心的是，如果 v2 启动失败，Deployment 会自动暂停并支持一键回滚到 v1，就像店长发现新菜不行，立刻把旧菜单翻回来。滚动更新期间，维护可用副本数量的核心约束是：

回扣比喻：店长从不让后厨“全军覆没”。他每次只换一个灶台，新灶台点火成功才拆旧灶台，生意始终红火。Deployment 就是这样一个懂节奏的店长，把更新这件事变得像呼吸一样自然。

三件套协同关系

现在把三个角色放到同一个场景里：顾客走进深夜食堂，对服务员说“来一份招牌炒饭”。服务员在菜单上记下订单，转身把订单递给任意一个空闲灶台；灶台上的厨师开始炒菜；店长在旁边巡视，随时准备补灶台或换新菜单。整个流程环环相扣，缺一不可。

用 K8s 的话说，一次完整请求的路径是这样的：用户或上游服务发起请求到 Service 的稳定 IP；Service 通过 label selector 找到一组健康的 Pod，把请求转发给其中一个；Deployment 则持续监控这组 Pod 的数量与版本，确保永远有足够的灶台在待命。三者各司其职：Pod 管运行、Service 管流量、Deployment 管声明。

这条链路还有个精妙之处：三个对象通过“标签”这个暗号联系。Deployment 创建的 Pod 带着 app: recommend 标签；Service 的 selector 也写着 app: recommend。于是，当 Deployment 滚动更新时，新 Pod 带着同样的标签加入，Service 自动感知并开始给它分流量；旧 Pod 被删除时，Service 自动把它从后端列表里摘掉。用户无感知，流量不中断。整条协同链路可以形式化表示为：

回扣比喻：小张的餐厅能越开越大，正是因为三个角色配合默契：服务员不碰菜刀，店长不直接炒菜，灶台只专心出餐。K8s 的设计哲学就是“单一职责”，每个对象把自己的事做到极致。

实战部署流程

理论讲了一堆，我们来真实走一遍“深夜食堂”上线新菜品的全流程。假设你是一个 AI 应用开发者，要把一个 PyTorch 模型推理服务部署到 K8s 集群，版本 v1，需要 3 个副本。

第一步，编写 YAML 文件。YAML 是 K8s 的世界语言，它告诉集群“我想要什么”。最简配置包含三部分：Deployment 里写镜像地址、副本数、容器端口；Service 里写稳定访问端口和标签选择器。第二步，执行 kubectl apply -f app.yaml 把声明提交给集群。第三步，用 kubectl get pods 查看 Pod 是否全部 Running。当 3 个 Pod 都变为 Ready 后，Service 会自动创建 Endpoints，把流量分发到这些 Pod 上。

第四步，版本升级。你训练出了精度更高的 v2 模型，修改 YAML 中的镜像标签为 v2，再次 kubectl apply。Deployment 开始滚动更新：新建 v2 Pod，逐步替换 v1 Pod。期间你可以用 kubectl rollout status 实时观察进度；如果 v2 有 Bug，用 kubectl rollout undo 一键回滚。判断一次发布是否成功的黄金标准是就绪副本数是否达标：

回扣比喻：这一套流程把“开店”变成了“填表格”——你只需把菜单（YAML）交给总部，店长（Deployment）、服务员（Service）、灶台（Pod）会自动跑起来。AI 工程落地的效率，就是这么被提上去的。

核心面试考点

前面六节已经把三件套的日常讲清楚了。如果你要参加面试或写简历，还需要把下面这些“暗号”记住：它们是你和面试官对暗号的钥匙。

第一组暗号是对象关系：容器嵌套在 Pod 里，Pod 由 ReplicaSet 管理，ReplicaSet 由 Deployment 管理；Service 独立于这条链，只通过标签与 Pod 松耦合。第二组是更新策略：滚动更新有两个关键参数 maxSurge（最多允许多出几个 Pod）和 maxUnavailable（最多允许几个 Pod 不可用），它们共同保证更新期间服务不中断。第三组是网络原理：Service 的 ClusterIP 是虚拟 IP，真正转发靠节点上的 kube-proxy 写 iptables/IPVS 规则。

还有一道高频题：Pod 被删除重建后，IP 变了，为什么 Service 还能找到它？答案是，Service 的 Endpoints 控制器会持续监听 Pod 的变化，把新 Pod 的 IP 加入转发列表。这也是“服务员手里名单实时更新”的底层实现。面试中最常考的更新容错公式是：

回扣比喻：面试官问的其实不是“背参数”，而是你有没有理解店长脑子里那本账：既不能把灶台全拆了停工（maxUnavailable），也不能一下开太多灶台浪费成本（maxSurge）。账算明白了，K8s 三件套也就真正吃透了。

AI 应用场景

Python 演示

"""K8s三件套概念模拟：用代码演示滚动更新与流量分发"""import time  class Pod:    id_counter = 0     def __init__(self, version):        self.id = Pod.id_counter        Pod.id_counter += 1        self.version = version        self.is_ready = True     def describe(self):        state = "就绪" if self.is_ready else "下线"        return f"Pod-{self.id}(v{self.version},{state})"  class Deployment:    def __init__(self, name, replicas, version):        self.name = name        self.desired_replicas = replicas        self.version = version        self.pod_list = [Pod(version) for _ in range(replicas)]     def rolling_update(self, new_version, batch_size=1):        print(f"开始滚动更新：v{self.version} -> v{new_version}")        order_count = 0        while order_count < self.desired_replicas:            new_pod = Pod(new_version)            old_pod = self.pod_list.pop(0)            old_pod.is_ready = False            self.pod_list.append(new_pod)            order_count += batch_size            print(f"  {old_pod.describe()}，替换为 {new_pod.describe()}")            time.sleep(0.2)        self.version = new_version        print(f"更新完成：{self.name} 现运行 v{new_version}")  class Service:    def __init__(self, deployment):        self.deployment = deployment        self.endpoint_list = deployment.pod_list     def request(self):        if not self.endpoint_list:            return "无可用 Pod"        pod = self.endpoint_list[0]        return f"请求命中 {pod.describe()}"  if __name__ == "__main__":    dep = Deployment("ai-model", 3, "v1")    svc = Service(dep)    print(svc.request())    dep.rolling_update("v2")    print(svc.request())

1. class Deployment对应 K8s 里的 Deployment 控制器，维护期望副本数和版本号。
2. self.pod_list = [Pod(version) for _ in range(replicas)]初始化时创建期望数量的 Pod，像店长一次性开好三个灶台。
3. def rolling_update(self, new_version, batch_size=1)对应滚动更新流程，每次只替换 batch_size 个旧 Pod。
4. old_pod.is_ready = False模拟旧 Pod 被下线，真实 K8s 中它会收到终止信号并腾空流量。
5. self.pod_list.append(new_pod)新 Pod 加入列表，Service 会自动感知并向它分发流量。
6. class Service对应 K8s 里的 Service 对象，负责把请求转发到后端的某一个 Pod。
7. self.endpoint_list = deployment.pod_list模拟 Service 的 Endpoints 列表，始终指向当前存活的 Pod。
8. svc.request()模拟一次用户请求被分发到后端 Pod，验证服务在更新过程中始终可用。

常见误区

面试题