K8s 核心资源详解（Pod/Deployment/Service 实战）
文章目录
- 前言
- 一、Pod：K8s 最小运行单元（彻底理清与 Docker 容器关系）
- 1.1 什么是 Pod？
- 1.2 Pod 和 Docker 容器的关系（白话终极解释）
- 1.3 Pod 的核心特点（新手必记）
- 1.4 为什么不直接管理容器，非要加一层 Pod？
- 二、Deployment：无状态服务的大管家（企业 99% 业务都用它）
- 2.1 为什么需要 Deployment？
- 2.2 Deployment 五大核心能力（生产核心价值）
- 2.3 适用场景
- 三、Service：固定入口 + 负载均衡（解决 Pod 最大痛点）
- 3.1 Pod 的致命问题
- 3.2 Service 核心作用
- 3.3 三种常用 Service 类型（新手重点记两种）
- 四、YAML 清单手把手手写实战（企业标准模板）
- 4.1 创建标准部署文件
- 4.2 逐行核心参数详解（必懂）
- Deployment 核心参数
- Service 核心参数
- 4.3 执行 YAML 部署命令
- 4.4 查看部署结果
- 五、核心实战：滚动更新、版本回滚、扩缩容
- 5.1 动态扩缩容实战
- 方式1：命令行快速扩缩容
- 方式2：YAML 文件修改（企业标准）
- 5.2 滚动更新实战（零停机升级）
- 查看更新过程
- 滚动更新核心策略参数（生产必备）
- 5.3 版本回滚实战（生产故障救命功能）
- 1. 查看所有历史版本
- 2. 一键回退上一个版本
- 3. 精准回退指定版本
- 4. 限制历史版本数量（优化存储）
- 六、三大核心资源关系总结（永久记住）
- 七、本篇总结
前言
上一篇我们从零搭建了一套标准可用的 K8s 集群，拥有了完整的容器运行环境。但搭建集群只是入门，真正的 K8s 开发、部署、运维，全部围绕三大核心资源展开：Pod、Deployment、Service。
很多新手学 K8s 只会敲命令、看不懂配置、不会排查问题，本质原因是：分不清 Pod、Deployment、Service 的职责边界，不懂底层运行逻辑。
本篇作为 K8s 核心实战第一篇，彻底打通理论+实操：白话讲透核心概念、手把手手写企业级 YAML 清单、完整演示滚动更新、版本回滚、动态扩缩容，学完可独立完成 K8s 日常项目部署与运维操作。
一、Pod：K8s 最小运行单元（彻底理清与 Docker 容器关系）
1.1 什么是 Pod？
核心定义：Pod 是 K8s 中最小、不可分割的部署与调度单元，K8s 不会直接管理 Docker 容器，所有容器都必须运行在 Pod 内部。
没有任何资源比 Pod 更小，所有服务部署、调度、自愈、扩容，全部基于 Pod 实现。
1.2 Pod 和 Docker 容器的关系（白话终极解释）
我们可以把Pod 理解为「容器的包装盒」：
- Docker 容器：真正运行业务代码、程序的实体（比如 Nginx 程序、Java 项目）
- Pod：封装容器的外壳，为内部容器提供统一网络、存储、IP、命名空间
企业标准规范：一个 Pod 里面只跑一个业务容器。
特殊场景才会一个 Pod 跑多个容器（主容器+辅助容器），日常开发、业务部署完全用不到，新手无需关注。
1.3 Pod 的核心特点（新手必记）
- 短命、临时性：Pod 是一次性资源，删除、故障、重建后 IP 会彻底改变，绝对不能固定 IP 访问服务
- 最小单元：K8s 调度、资源限制、监控的最小单位都是 Pod，不是容器
- 不可自愈：单独创建的 Pod 崩溃后不会自动重启、不会重建，必须依靠上层控制器管理
1.4 为什么不直接管理容器，非要加一层 Pod？
为了标准化！屏蔽底层容器差异（Docker/Containerd），让 K8s 可以统一管理所有容器，实现统一调度、统一网络、统一生命周期。
二、Deployment：无状态服务的大管家（企业 99% 业务都用它）
2.1 为什么需要 Deployment？
刚才讲到：单独的 Pod 毫无生产价值。
Pod 删掉就没、崩了不重启、无法扩容、无法更新、无法回滚，完全无法满足线上业务需求。
于是 K8s 设计了Deployment 控制器，专门用来批量管理 Pod。
通俗理解：Pod 是干活的员工，Deployment 是工头，负责管员工数量、状态、更新、重启。
2.2 Deployment 五大核心能力（生产核心价值）
- 副本维持（自愈）：指定运行 N 个 Pod，挂一个补一个，永远维持数量稳定
- 动态扩缩容：随时增加/减少 Pod 数量，适配流量高低峰
- 滚动更新：更新项目版本，不停机、零中断、逐步替换容器
- 版本回滚：新版本报错，一键退回历史稳定版本
- 版本历史保留：自动记录更新记录，方便追溯与回滚
2.3 适用场景
所有无状态服务全部用 Deployment：Nginx、Java 后端、Vue 前端、微服务等。
简单理解：重启服务不丢数据的项目，都可以用 Deployment。
三、Service：固定入口 + 负载均衡（解决 Pod 最大痛点）
3.1 Pod 的致命问题
前面说过：Pod 是临时资源，重启、重建、迁移后 IP 一定会变。
如果直接用 Pod IP 访问项目，每次更新服务、重启容器，访问地址就失效，业务直接崩掉，完全无法用于生产。
3.2 Service 核心作用
Service 就是一组 Pod 的固定网关，两大核心能力：
- 固定访问入口：Service IP 和端口永久不变，不管后端 Pod 怎么变，访问地址始终不变
- 负载均衡：自动把流量分发到后端多个 Pod，分担压力，实现高可用
3.3 三种常用 Service 类型（新手重点记两种）
- ClusterIP（默认）：仅集群内部访问，外网无法访问，适合微服务之间互相调用
- NodePort（学习/测试常用）：暴露服务器端口，外网可直接通过「服务器IP+端口」访问服务
- LoadBalancer（生产云环境）：云厂商专属负载均衡，本地集群不用
四、YAML 清单手把手手写实战（企业标准模板）
前面我们用命令行临时部署服务，生产环境绝对不用！企业全部采用YAML 声明式配置文件，可版本管理、可复用、可批量部署。
本节手把手手写一套完整的Deployment + Service 一体化 YAML，逐行讲解含义，零基础看懂。
4.1 创建标准部署文件
新建nginx-full.yaml文件，完整配置如下（可直接复制使用）：
# 1. 定义部署资源：管理Nginx PodapiVersion:apps/v1# 资源所属API版本，Deployment固定该版本kind:Deployment# 资源类型：部署控制器metadata:name:nginx-demo# 自定义部署名称，全局唯一labels:app:nginx-demo# 部署标签，用于匹配服务spec:replicas:2# 期望运行的Pod副本数量selector:matchLabels:app:nginx-demo# 匹配下方Pod的标签，建立关联关系# Pod模板：定义创建出来的Pod配置template:metadata:labels:app:nginx-demo# Pod标签，必须与上方匹配spec:containers:# 容器配置（真正运行的Docker容器）-name:nginximage:nginx:alpine# 镜像名称+版本ports:-containerPort:80# 容器内部端口---# 2. 定义服务资源：暴露端口+负载均衡apiVersion:v1kind:Servicemetadata:name:nginx-demo-svcspec:selector:app:nginx-demo# 关联上方Deployment管理的Podtype:NodePort# 服务类型：外网可访问ports:-port:80# 集群内部服务端口targetPort:80# 映射容器端口nodePort:30080# 固定外网端口（范围30000-32767）4.2 逐行核心参数详解（必懂）
Deployment 核心参数
apiVersion：资源版本，Deployment 固定为apps/v1kind：资源类型，当前为 Deployment 部署资源replicas：副本数，定义需要运行多少个业务 Podselector：标签选择器，通过标签绑定对应 Pod，是关联核心template：Pod 模板，所有通过该 Deployment 创建的 Pod 都遵循此模板containerPort：容器内部服务端口，必须和项目启动端口一致
Service 核心参数
selector：通过标签匹配后端 Pod，实现流量转发type: NodePort：开启外网访问模式port：Service 集群内部通信端口targetPort：对应容器的服务端口nodePort：外网访问固定端口，无需每次随机生成
4.3 执行 YAML 部署命令
# 根据YAML文件创建/更新所有资源kubectl apply-fnginx-full.yaml参数详解：kubectl apply是企业标准声明式部署命令，资源不存在则创建，已存在则更新，不会重复报错。
4.4 查看部署结果
# 查看部署状态kubectl get deploy# 查看Pod运行状态kubectl get pods# 查看服务端口状态kubectl get svc浏览器访问：服务器IP:30080，成功打开 Nginx 页面即部署完成。
五、核心实战：滚动更新、版本回滚、扩缩容
这一节是 K8s 生产最核心的能力，也是面试、工作高频考点，全程手把手实操，看懂即会用。
5.1 动态扩缩容实战
业务流量暴涨扩容、流量低谷缩容，两种方式均可实现。
方式1：命令行快速扩缩容
# 将Pod副本调整为4个（扩容）kubectl scale deployment nginx-demo--replicas=4# 查看变化kubectl get pods参数详解：scale专属扩缩容命令，直接修改副本数量，秒级生效。
方式2：YAML 文件修改（企业标准）
修改 YAML 中replicas数值，重新执行kubectl apply -f nginx-full.yaml，配置永久生效。
5.2 滚动更新实战（零停机升级）
滚动更新核心逻辑：先启动新 Pod、再销毁旧 Pod，新旧服务交替运行，全程服务不中断。
我们通过更新镜像版本模拟项目升级：
# 更新镜像版本，触发滚动更新kubectlsetimage deployment nginx-demonginx=nginx:1.21-alpine参数详解：kubectl set image专门用于在线更新容器镜像版本。
查看更新过程
# 实时观察滚动更新进度kubectl rollout status deployment nginx-demo# 查看更新历史记录kubectl rollouthistorydeployment nginx-demo可以清晰看到：新 Pod 先启动就绪，旧 Pod 才逐步销毁，全程服务可正常访问，无停机。
滚动更新核心策略参数（生产必备）
在 Deployment 中可配置更新策略，控制更新节奏，避免瞬间批量替换导致服务抖动：
strategy:type:RollingUpdate# 滚动更新策略（默认）rollingUpdate:maxSurge:1# 更新时最多超出期望副本数的数量maxUnavailable:0# 更新时最大不可用Pod数量（保证零不可用）参数详解：maxSurge控制更新峰值扩容数量，maxUnavailable保证更新过程服务100%可用。
5.3 版本回滚实战（生产故障救命功能）
新版本上线出现 Bug、报错、兼容问题，无需停机，一键回退到历史稳定版本。
1. 查看所有历史版本
kubectl rollouthistorydeployment nginx-demo2. 一键回退上一个版本
kubectl rollout undo deployment nginx-demo3. 精准回退指定版本
# --to-revision 指定版本号kubectl rollout undo deployment nginx-demo --to-revision=14. 限制历史版本数量（优化存储）
默认保留所有更新记录，生产环境可通过参数限制历史版本数量，避免资源浪费：
spec:revisionHistoryLimit:10# 仅保留最近10个历史版本六、三大核心资源关系总结（永久记住）
- Pod：最小运行单元，跑真实容器程序，临时、易变、无自愈能力
- Deployment：管理者，管理 Pod 生命周期，实现自愈、扩容、滚动更新、版本回滚
- Service：统一入口，屏蔽 Pod 动态 IP，提供固定访问地址+负载均衡
企业完整链路：YAML定义Deployment & Service → K8s创建Pod运行容器 → Deployment维持副本稳定 → Service对外提供稳定访问。
七、本篇总结
1、Pod 是 K8s 最小调度单元，基于 Docker/Containerd 容器运行，自身无自愈、无稳定IP，不能单独用于生产；
2、Deployment 是无状态服务核心控制器，承担副本自愈、动态扩缩容、滚动更新、版本回滚四大核心生产能力；
3、Service 解决 Pod IP 动态变化问题，提供固定访问入口与负载均衡，是服务对外暴露、内网互通的关键；
4、掌握企业标准 YAML 手写规范，告别命令行临时部署，适配团队协作与版本管理；
5、熟练掌握扩缩容、零停机滚动更新、故障版本回滚，具备基础 K8s 生产运维能力。