K8s核心概念：Pod、Service与Deployment

可视化演示

动态演示K8s核心概念的核心机制，通过总览/传输/转换/输出四种模式展示关键概念与交互流程。

Pod调度单元

想象一家饭店的后厨。做宫保鸡丁需要配菜、掌勺、装盘三位师傅密切配合。老板干脆让他们坐在同一张工作台旁，共享同一套刀具和食材。这样一来，三人配合默契，调度起来也方便——要上就一起上，要撤就一起撤。这张工作台，就是K8s里的Pod。

在Kubernetes中，Pod是最小、最基本的调度单元，而不是容器。一个Pod内可以包含一个或多个容器，这些容器共享同一个网络命名空间（IP、端口）和存储卷。K8s调度器以Pod为单位决定把任务放到哪台机器上，而不是单独调度某个容器。这意味着Pod内的容器可以通过 localhost 互相访问，也能共享同一个数据卷读写文件。

Pod里的容器生命周期完全绑定：任何容器异常退出，整个Pod都会被K8s感知并重建（通常由上层Deployment完成）。这也是为什么生产实践中，推荐把“关系紧密、需要同生共死”的进程放进一个Pod，比如日志采集边车（sidecar）和应用主容器。日志边车跟着应用一起启停，天然保证日志不丢失。

就像同一桌的师傅必须同进同出，Pod里的容器也共享生命周期。K8s不会单独拆散“一桌人”——这保证了协作型应用要么一起启动，要么一起消失，不给“半桌菜”的尴尬局面留机会。

Service服务发现

客人来饭店，不会直接冲进后厨找“今天做鱼香肉丝的师傅”——师傅可能轮休、可能换了人。客人只需要走到前台，说“一份鱼香肉丝”，前台自然会把订单转给任何一位能做的师傅。这个前台，就是Service。

Pod是有“生命”的：它可能因为故障被销毁重建，也可能因滚动更新被替换，每次重建IP地址都会变化。如果客户端直接记住Pod的IP，一旦Pod重建就失联了。Service提供了一个稳定的虚拟IP（ClusterIP）和DNS名字，作为流量的统一入口。它通过标签选择器（后面的章节详细介绍）找到当前所有符合条件的Pod，并维护一份实时更新的后端列表。

请求到达Service后，kube-proxy会将流量转发到列表中的某个Pod，默认采用轮询（round-robin）策略。这一层转发对客户端完全透明——客户端永远只跟Service通信，不必关心背后Pod的增删变化。就算某个Pod挂掉被重建，Service也会自动把它从列表中去掉，再把新Pod加进来。

只要前台还在，客人就永远能找到吃饭的地方——哪怕后厨换了一拨又一拨厨师。Service就是应用世界里永不关门的“前台”。

Deployment滚动更新

饭店主厨手里有一本“期望菜单”：此刻后厨必须保证有5位能做招牌菜的师傅在岗。他每隔几分钟巡视一圈：人少了就打电话叫临时工，人多了就安排休息。如果明天要换新菜谱，他不会一次性把所有菜换掉（万一客人不满意就全砸了），而是先让两位师傅试做新菜，客人反响好再逐步推广。

Deployment是K8s里管理无状态应用的“主厨”。你在YAML里声明期望的副本数（replicas）和容器镜像版本，Deployment通过底层的ReplicaSet保证这个数量始终满足。当需要升级镜像版本时，Deployment不会“一刀切”地同时替换所有Pod，而是按滚动更新策略逐批替换，确保服务在升级过程中始终可用。

滚动更新有两个关键参数：maxSurge（更新时允许超出期望副本数的个数）和 maxUnavailable（更新时允许最多几个Pod暂时不可用）。比如期望5个副本、maxSurge=1、maxUnavailable=1，那么更新过程中集群里Pod总数最多6个，且最少有4个保持可用。当新的Pod就绪后，旧的Pod才被销毁，如此反复直至全部替换完毕。若新版本发布了严重故障，kubectl rollout undo 还能快速回滚到上一个稳定版本。

主厨“分批换菜”的思路，保证了饭店任何时候都有菜可卖。Deployment的滚动更新同样保证了应用升级不中断——这就是生产环境敢于频繁发布新版本的底气。

ConfigMap配置

每道菜的配方都写在后厨墙上的菜谱里，而不是刻在厨师脑子里。今天客人普遍口味偏淡，老板改写菜谱里“盐3克”为“盐1克”，所有厨师照着新菜谱做菜就行——不需要重新培训任何一个厨师。菜谱，就是ConfigMap。

应用的配置（数据库地址、超时时间、功能开关）如果写死在容器镜像里，每次改配置都要重新构建镜像、重新发布，效率极低。ConfigMap把配置从镜像中剥离出来，以键值对的形式独立存储。Pod可以像“看菜谱”一样读取这些配置，镜像本身则保持通用不变。

ConfigMap有两种主流注入方式：一是通过环境变量注入，Pod启动时把配置值变成容器内的环境变量；二是把ConfigMap挂载成文件，容器运行时读取配置文件。二者的更新行为不同：环境变量注入是一次性的，修改ConfigMap后需要重建Pod才生效；文件挂载则会随ConfigMap更新而动态刷新（有秒级延迟）。

菜谱可以随时改，但已经出锅的菜不会自动变咸变淡。理解了这句，你就明白了为什么环境变量方式不能“热更新”——菜已经端上桌了。

声明式API

你去饭店点菜，只需对服务员说“鱼香肉丝，少辣”，把目标描述清楚就够了，至于后厨是先切肉还是先热油，你完全不用操心。这就是声明式。反过来，如果你站在后厨边上喊“先放油！再下肉！再加酱！”，那就是命令式——你说一步，他做一步。

Kubernetes的API设计是声明式的：用户提供一个YAML文件，描述“我想要什么”（比如“3个运行nginx的Pod”），而不是“请依次执行哪些命令”。kubectl apply 就是声明式操作——把清单提交给API Server，然后由系统自行协调落地。

声明式的核心价值在于可重复和可自愈。同一个YAML文件提交一百次，结果完全一致（幂等）；而且系统会持续对比“清单描述的状态”和“集群当前状态”，一旦现实偏离了声明，控制器会自动把它拉回来。命令式操作则很难做到这一点——你手动创建的Pod挂了就没了，没有人替你负责重建。

你只负责说“想吃什么”，后厨保证“菜必上桌”——声明式API把用户从繁琐的操作步骤中解放出来，让“要什么”和“怎么实现”彻底解耦。

协调循环

主厨的例行工作是什么？不是炒菜，而是“巡视”。他手里拿着期望菜单，每隔几分钟就在后厨转一圈：数数实际有多少师傅在岗。少三个，立刻打电话叫人来；多两个，安排休息。这个“看→比→调→再看”的无限循环，就是K8s控制器的灵魂——协调循环。

几乎所有K8s控制器（ReplicaSet、Deployment、DaemonSet等）的内部都是一个协调循环：读取期望状态（用户声明的replicas）、拉取实际状态（当前Pod列表）、计算差距、执行调整（创建/删除Pod），然后继续循环。这个循环没有“终点”，它永远在运行——这正是系统“自愈”能力的来源。

协调循环依赖两个底层组件：etcd持久化保存期望状态（YAML里写的“理想”），API Server暴露当前状态（集群里实际的“现实”）。控制器通过List-Watch机制订阅变化：先一次性拉取全量状态，再持续监听增量事件，保证任何偏差都能被及时发现。即使没有任何事件发生，部分控制器也会周期性地重新执行协调，防止“静默漂移”。

主厨永远不偷懒，K8s的控制器也永远不松懈。正是这永不停歇的巡视，让“期望”和“现实”的差距被时刻钉死——这就是云原生系统“自愈”的真相。

标签选择器

外卖订单上会有“少辣”“免葱”“多加香菜”这样的备注。后厨接单后，根据备注把订单分给相应的师傅：“少辣”给能把辣度调低的师傅。备注就是标签，筛选备注的过程就是选择器匹配。

标签（Label）是挂在K8s资源上的键值对，比如 app=frontend、env=production。它不承载业务逻辑，只用于“分类和标记”。选择器（Selector）则是一套匹配规则，用来筛选出所有满足条件的资源。在K8s中，Service用选择器找Pod，Deployment用选择器管Pod，两个资源之间的关联关系完全由标签和选择器建立——这是K8s解耦设计的关键。

选择器支持两种匹配方式：相等匹配（=、==、!=）和集合匹配（in、notin、exists）。一个选择器可以包含多个条件，多个条件之间是“与”关系——资源必须满足所有条件才被选中。比如 selector: app=frontend, env=prod 同时满足两个标签的Pod才会被Service纳入后端列表。这种松散耦合让不同团队可以独立管理自己的资源，只要标签规范一致，就能互相发现。

备注贴得好，后厨不慌乱。一套设计合理的标签体系，能让Service、Deployment、监控、日志等十几种资源各取所需、互不干扰——这是K8s世界里最重要的“组织纪律”。

资源清单编写

在K8s里“点菜”，靠的是一张标准的“点菜单”。菜单必须写清楚四个部分：菜系（是川菜还是粤菜）、菜名（宫保鸡丁）、桌号（坐哪桌）、具体要求（少辣多葱）。这张菜单，就是资源清单（Manifest）。

无论Pod、Service还是Deployment，在K8s里都以YAML清单的形式描述。所有资源清单都包含四个核心字段：apiVersion（API版本）、kind（资源类型）、metadata（元数据：名称、标签、命名空间）、spec（规格：期望状态的详细描述）。掌握这四个字段，你就能读懂任何一份K8s清单。

以Deployment为例：apiVersion 是 apps/v1，kind 是 Deployment，metadata 里写名字和标签，spec 里写副本数、选择器和Pod模板。kubectl apply -f 提交清单后，API Server校验合法性、写入etcd，随后控制器开始协调。可以说，写清单就是“与K8s签订契约”——你许诺目标，K8s许诺执行。

菜单写清楚，后厨才好干活。资源清单写清楚，K8s才能精确执行——这就是“一切皆声明、声明即契约”的云原生世界观。

---

AI 应用场景

Python 演示

class Pod:    """模拟一个 Pod 实例"""     def __init__(self, name):        self.name = name        self.status = "Running"  class ReplicaSetController:    """模拟 K8s 控制器: 让实际 Pod 数量向期望值收敛"""     def __init__(self, desired):        self.desired = desired        self.pods = []        self.gc_count = 0     def reconcile(self):        """协调循环: 对比期望与实际, 补齐或删除 Pod"""        self.gc_count += 1        current = len(self.pods)        if current < self.desired:            need = self.desired - current            for i in range(need):                self.pods.append(Pod("pod-%d" % (self.gc_count * 10 + i)))            print("补齐: 当前 %d 个 Pod -> 期望 %d 个" % (current, self.desired))        elif current > self.desired:            for _ in range(current - self.desired):                self.pods.pop()            print("缩容: 当前 %d 个 Pod -> 期望 %d 个" % (current, self.desired))        else:            print("稳定: 当前 %d 个 Pod 与期望一致" % current)  class Service:    """模拟 Service 的轮询负载均衡"""     def __init__(self, pods):        self.pods = pods        self.qq_index = 0     def request(self):        """模拟一次外部请求经 Service 转发到某个 Pod"""        if not self.pods:            return "503: 无可用 Pod"        pod = self.pods[self.qq_index % len(self.pods)]        self.qq_index += 1        return "200: 请求已转发到 %s" % pod.name  def main():    ctl = ReplicaSetController(3)    ctl.reconcile()    svc = Service(ctl.pods)    for i in range(4):        print("外部请求 %d -> %s" % (i + 1, svc.request()))    ctl.desired = 2    ctl.reconcile()  if __name__ == "__main__":    main()

1. ctl = ReplicaSetController(3)创建控制器并声明期望 3 个 Pod，对应 YAML 里的 spec.replicas。
2. def reconcile(self)协调循环的核心方法：对比当前 Pod 数量与期望值，多删少补。
3. self.gc_count计数器，用于生成不重复的 Pod 名称，呼应控制器每次协调都会产生新资源。
4. svc = Service(ctl.pods)把当前 Pod 列表交给 Service，模拟 kube-proxy 维护后端转发列表。
5. svc.request()每次请求按 self.qq_index % len(self.pods) 轮询选择 Pod，实现负载均衡。
6. ctl.desired = 2修改期望副本数后再次 reconcile，模拟扩容或缩容场景。

常见误区

面试题