K8s 核心资源详解（Pod/Deployment/Service 实战）

文章目录

• • 前言
  • [一、Pod：K8s 最小运行单元（彻底理清与 Docker 容器关系）](#一、Pod：K8s 最小运行单元（彻底理清与 Docker 容器关系）)
  • • [1.1 什么是 Pod？](#1.1 什么是 Pod？)
    • [1.2 Pod 和 Docker 容器的关系（白话终极解释）](#1.2 Pod 和 Docker 容器的关系（白话终极解释）)
    • [1.3 Pod 的核心特点（新手必记）](#1.3 Pod 的核心特点（新手必记）)
    • [1.4 为什么不直接管理容器，非要加一层 Pod？](#1.4 为什么不直接管理容器，非要加一层 Pod？)
  • [二、Deployment：无状态服务的大管家（企业 99% 业务都用它）](#二、Deployment：无状态服务的大管家（企业 99% 业务都用它）)
  • • [2.1 为什么需要 Deployment？](#2.1 为什么需要 Deployment？)
    • [2.2 Deployment 五大核心能力（生产核心价值）](#2.2 Deployment 五大核心能力（生产核心价值）)
    • [2.3 适用场景](#2.3 适用场景)
  • [三、Service：固定入口 + 负载均衡（解决 Pod 最大痛点）](#三、Service：固定入口 + 负载均衡（解决 Pod 最大痛点）)
  • • [3.1 Pod 的致命问题](#3.1 Pod 的致命问题)
    • [3.2 Service 核心作用](#3.2 Service 核心作用)
    • [3.3 三种常用 Service 类型（新手重点记两种）](#3.3 三种常用 Service 类型（新手重点记两种）)
  • [四、YAML 清单手把手手写实战（企业标准模板）](#四、YAML 清单手把手手写实战（企业标准模板）)
  • • [4.1 创建标准部署文件](#4.1 创建标准部署文件)
    • [4.2 逐行核心参数详解（必懂）](#4.2 逐行核心参数详解（必懂）)
    • • [Deployment 核心参数](#Deployment 核心参数)
      • [Service 核心参数](#Service 核心参数)
    • [4.3 执行 YAML 部署命令](#4.3 执行 YAML 部署命令)
    • [4.4 查看部署结果](#4.4 查看部署结果)
  • 五、核心实战：滚动更新、版本回滚、扩缩容
  • • [5.1 动态扩缩容实战](#5.1 动态扩缩容实战)
    • • 方式1：命令行快速扩缩容
      • [方式2：YAML 文件修改（企业标准）](#方式2：YAML 文件修改（企业标准）)
    • [5.2 滚动更新实战（零停机升级）](#5.2 滚动更新实战（零停机升级）)
    • • 查看更新过程
      • 滚动更新核心策略参数（生产必备）
    • [5.3 版本回滚实战（生产故障救命功能）](#5.3 版本回滚实战（生产故障救命功能）)
    • • [1. 查看所有历史版本](#1. 查看所有历史版本)
      • [2. 一键回退上一个版本](#2. 一键回退上一个版本)
      • [3. 精准回退指定版本](#3. 精准回退指定版本)
      • [4. 限制历史版本数量（优化存储）](#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 Pod
apiVersion: 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: nginx
        image: nginx:alpine # 镜像名称+版本
        ports:
        - containerPort: 80 # 容器内部端口

---
# 2. 定义服务资源：暴露端口+负载均衡
apiVersion: v1
kind: Service
metadata:
  name: nginx-demo-svc
spec:
  selector:
    app: nginx-demo # 关联上方Deployment管理的Pod
  type: NodePort    # 服务类型：外网可访问
  ports:
  - port: 80        # 集群内部服务端口
    targetPort: 80  # 映射容器端口
    nodePort: 30080 # 固定外网端口（范围30000-32767）

4.2 逐行核心参数详解（必懂）

Deployment 核心参数

• apiVersion：资源版本，Deployment 固定为 apps/v1
• kind：资源类型，当前为 Deployment 部署资源
• replicas：副本数，定义需要运行多少个业务 Pod
• selector：标签选择器，通过标签绑定对应 Pod，是关联核心
• template：Pod 模板，所有通过该 Deployment 创建的 Pod 都遵循此模板
• containerPort：容器内部服务端口，必须和项目启动端口一致

Service 核心参数

• selector：通过标签匹配后端 Pod，实现流量转发
• type: NodePort：开启外网访问模式
• port：Service 集群内部通信端口
• targetPort：对应容器的服务端口
• nodePort：外网访问固定端口，无需每次随机生成

4.3 执行 YAML 部署命令

# 根据YAML文件创建/更新所有资源
kubectl apply -f nginx-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，新旧服务交替运行，全程服务不中断。

我们通过更新镜像版本模拟项目升级：

# 更新镜像版本，触发滚动更新
kubectl set image deployment nginx-demo nginx=nginx:1.21-alpine

参数详解 ：kubectl set image 专门用于在线更新容器镜像版本。

查看更新过程

# 实时观察滚动更新进度
kubectl rollout status deployment nginx-demo

# 查看更新历史记录
kubectl rollout history deployment nginx-demo

可以清晰看到：新 Pod 先启动就绪，旧 Pod 才逐步销毁，全程服务可正常访问，无停机。

滚动更新核心策略参数（生产必备）

在 Deployment 中可配置更新策略，控制更新节奏，避免瞬间批量替换导致服务抖动：

strategy:
  type: RollingUpdate       # 滚动更新策略（默认）
  rollingUpdate:
    maxSurge: 1             # 更新时最多超出期望副本数的数量
    maxUnavailable: 0       # 更新时最大不可用Pod数量（保证零不可用）

参数详解 ：maxSurge 控制更新峰值扩容数量，maxUnavailable 保证更新过程服务100%可用。

5.3 版本回滚实战（生产故障救命功能）

新版本上线出现 Bug、报错、兼容问题，无需停机，一键回退到历史稳定版本。

1. 查看所有历史版本

kubectl rollout history deployment nginx-demo

2. 一键回退上一个版本

kubectl rollout undo deployment nginx-demo

3. 精准回退指定版本

# --to-revision 指定版本号
kubectl rollout undo deployment nginx-demo --to-revision=1

4. 限制历史版本数量（优化存储）

默认保留所有更新记录，生产环境可通过参数限制历史版本数量，避免资源浪费：

spec:
  revisionHistoryLimit: 10  # 仅保留最近10个历史版本

六、三大核心资源关系总结（永久记住）

1. Pod：最小运行单元，跑真实容器程序，临时、易变、无自愈能力
2. Deployment：管理者，管理 Pod 生命周期，实现自愈、扩容、滚动更新、版本回滚
3. 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 生产运维能力。