K8s 实战：Pod 版本更新回滚 + 生命周期管控

一、版本更新与回滚

实验背景

本实验通过 Kubernetes 的 Deployment 资源演示应用的版本更新与回滚流程。Deployment 是 Kubernetes 中用于管理 Pod 和 ReplicaSet 的核心资源，支持滚动更新（避免服务中断）和版本回滚（应对更新故障），是生产环境中部署无状态应用的标准方式。

1.1.版本更新

bash 复制代码

kubectl create deployment web --image myapp:v1 --replicas 4

**create deployment web：**创建一个名为web的 Deployment 资源，用于定义应用的部署规则。
**--image myapp:v1：**指定应用初始镜像为myapp:v1（假设这是应用的第一个稳定版本）。
**--replicas 4：**设置副本数为 4，通过多副本实现高可用------ 即使个别 Pod 故障，其他副本仍能提供服务，避免单点失效。

bash 复制代码

kubectl expose deployment web --port 80 --target-port 80

**expose deployment web：**为web这个 Deployment 创建一个 Service 资源，用于将 Pod 暴露给集群内 / 外的访问者。
**--port 80：**Service 的端口（集群内其他服务通过此端口访问）。
**--target-port 80：**Pod 内应用实际监听的端口（需与容器内应用的端口一致，此处假设myapp镜像的应用监听 80 端口）。
Pod 的 IP 是动态变化的（重建后会改变），而 Service 会分配一个固定的 ClusterIP，并通过标签选择器关联 Pod，实现 "IP 固定化" 和 "自动负载均衡"------ 访问 Service 的 ClusterIP 时，请求会自动转发到后端健康的 Pod。

bash 复制代码

kubectl get service

作用与意义：查看刚创建的 Service 信息，重点获取CLUSTER-IP（示例中为10.106.16.15），这是集群内访问该服务的入口地址。

bash 复制代码

curl 10.106.16.15

作用与意义：通过curl访问 Service 的 ClusterIP，验证应用是否正常响应（示例中返回myapp:v1的页面内容）。

bash 复制代码

kubectl rollout history deployment web

作用与意义：查看web这个 Deployment 的版本更新历史。初始状态下，只有 1 个版本（revision 1），记录了初始部署的配置（如镜像myapp:v1）。

**实际价值：**Kubernetes 会自动记录 Deployment 的每一次更新（如镜像变更、副本数调整等），形成 "版本快照"，为后续回滚提供依据。在生产环境中，这是追溯变更、排查问题的关键。

bash 复制代码

kubectl set image deployments/web myapp=myapp:v2

kubectl rollout history deployment web

作用与意义：

**set image：**修改 Deployment 中容器的镜像，将web Deployment 下的myapp容器镜像从v1更新为v2（假设v2是新开发的版本）。
**底层逻辑：**Kubernetes 会触发 "滚动更新"------ 先创建使用myapp:v2的新 Pod，待新 Pod 就绪后，再逐步删除旧的v1 Pod，整个过程中服务不中断。
再次查看历史，会发现新增一个版本（revision 2），记录了 "镜像从 v1 变为 v2" 的变更。

bash 复制代码

curl 10.106.16.15

访问 Service 验证更新结果，此时应返回 myapp:v2 的页面内容，确认新版本已生效。

实际价值：滚动更新是生产环境中发布新版本的标准方式，通过 "先增后删" 的策略避免服务中断，平衡了更新效率与业务连续性。

1.2.版本回滚

版本回滚（v2→v1）

bash 复制代码

kubectl rollout undo deployment web --to-revision 1

作用与意义：

**rollout undo：**将 Deployment 回滚到指定版本（--to-revision 1即回滚到初始的 v1 版本）。
**底层逻辑：**类似更新流程，Kubernetes 会创建v1版本的 Pod，就绪后删除v2版本的 Pod，实现 "无感知回滚"。

bash 复制代码

kubectl rollout history deployment web

查看历史会发现，回滚操作会生成一个新的版本记录（如 revision 3），但实际配置与 revision 1 一致，便于追溯回滚动作。

bash 复制代码

curl 10.106.16.15

再次访问 Service，确认返回内容恢复为 myapp:v1，验证回滚成功。

实验总结

本实验通过 Deployment 的 "创建→暴露→更新→回滚" 流程，展示了 Kubernetes 对应用生命周期的精细化管理：

多副本部署保障高可用；
Service 实现 Pod 的稳定访问与负载均衡；
滚动更新实现新版本的无中断发布；
版本历史与回滚机制提供了故障快速恢复能力。

二、pod生命周期

Pod 是 Kubernetes 中最小的部署单元，其生命周期包含 "启动初始化→运行中监控→就绪接收请求" 三个核心阶段。本实验通过Init 容器（初始化阶段） 、存活探针（运行监控阶段） 、就绪探针（请求准入阶段） 的配置与验证，完整演示 Pod 生命周期的管控逻辑，理解 K8s 如何保障应用从启动到服务的稳定性。

2.1.INIT 容器

实验背景

Init 容器是 Pod 启动过程中先于主容器执行的 "初始化容器" ，核心作用是完成主容器启动前的前置依赖任务（如等待其他服务就绪、下载配置文件、初始化数据库等）。其特点是：必须执行成功后，主容器才会启动；且仅在 Pod 首次启动时执行一次，退出后不再重启。

bash 复制代码

kubectl run initpod --image myapp:v1 --dry-run=client -o yaml > init.yml

vim init.yml 
############
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: initpod
  name: initpod
spec:
  containers:
  - image: myapp:v1
    name: initpod   
  initContainers:           # Init 容器：主容器启动前执行的初始化容器
  - name: init-myservice    # Init 容器名称
    image: busybox
    command: ["sh","-c","until test -e /testfile; do echo wating for myservice; sleep 2; done"]                   # 核心逻辑：循环检查 /testfile 是否存在，不存在则输出等待信息，每 2 秒重试一次
###########

kubectl apply -f init.yml 

kubectl get pods        # 查看 pod 状态

od 状态显示为 Init:0/1，含义是 "需要执行 1 个 Init 容器，当前完成 0 个"。
核心逻辑： K8s 会优先启动 Init 容器，只有 Init 容器执行成功（退出码为 0），主容器才会启动。此时 Init 容器卡在 "等待 /testfile" 的循环中，未成功退出，因此主容器处于 "阻塞未启动" 状态。

bash 复制代码

kubectl logs pods/initpod init-myservice    # 查看名为 init-myservice 的 Init 容器日志

日志持续输出 waiting for myservice，验证 Init 容器正在按 command 逻辑循环等待 ------ 证明初始化任务正在执行，未满足 "/testfile 存在" 的条件。
实际价值：通过日志可定位 Init 容器的阻塞原因（如依赖服务未就绪、文件未挂载等），是排查 Pod 启动卡壳的关键手段。

bash 复制代码

kubectl exec pods/initpod -c init-myservice -- /bin/sh -c "touch /testfile" # 进入 Init 容器，手动创建 /testfile

kubectl get pods     # 再次查看 Pod 状态

执行 touch /testfile 后，Init 容器的 until 循环条件满足（/testfile 存在），循环退出，Init 容器执行成功（退出码为 0）。
Pod 状态从 Init:0/1 变为 Running，说明主容器已启动 ------ 验证 Init 容器的 "前置阻塞 + 一次性执行" 特性。
实际意义：此过程模拟了 "依赖就绪后启动主服务" 的生产场景，例如：只有数据库初始化完成，后端应用容器才启动，避免主容器因依赖缺失报错。

2.2.存活探针

实验背景

存活探针（Liveness Probe）是 Kubernetes 用于检测容器是否 "存活" 的核心机制。当探针判定容器不健康时，Kubernetes 会自动重启容器，实现 "故障自愈"，这是保障应用高可用性的关键特性。本实验通过配置 TCP 类型的存活探针，模拟容器故障时的自动恢复过程。

存活探针是 K8s 对 "运行中容器是否健康" 的持续监控机制 ------若探针判定容器不健康（如进程无响应、端口不可用），K8s 会自动重启容器，实现 "故障自愈"，避免服务长期不可用。与 Init 容器不同，存活探针在容器整个运行周期中持续执行。

bash 复制代码

vim live.yml 
#############
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: liveness
  name: liveness
spec:
  containers:
    - image: myapp:v1
      name: liveness
      livenessProbe:
        tcpSocket:
          port: 8080            # 检查容器的 8080 端口是否可连接
        initialDelaySeconds: 3  # 容器启动后延迟 3 秒再开始第一次探测
        periodSeconds: 1        # 每 1 秒执行一次探测
        timeoutSeconds: 1       # 探测超时时间（1 秒内未响应则判定失败）
#############

kubectl apply -f live.yml 

kubectl get pods                # 查看 pod 状态，pod 没启动
kubectl describe pods/liveness  # 查看 pod 详细信息

Pod 状态显示为 CrashLoopBackOff：含义是 "容器反复启动后崩溃"。
kubectl describe 输出 Liveness probe failed: dial tcp 10.244.0.xx:8080: connect: connection refused）：
- **原因：**myapp:v1 容器默认未启动监听 8080 端口的服务（如未启动 nginx、Java 应用等），存活探针 TCP 连接失败，K8s 判定容器 "不健康"，触发重启。
- **核心逻辑：**存活探针的核心是 "持续监控 + 失败重启"------ 只要容器运行，探针就会周期性执行，失败次数达到阈值（默认 3 次）后，容器会被重启，直到探针成功。

bash 复制代码

kubectl exec -it pods/liveness -- /bin/sh   # 进入容器内部
                                            # 在容器内执行命令，开启8080端口

kubectl get pods            # 查看 pod 状态，pod 启动成功

实验总结

本实验通过 TCP 类型的存活探针，验证了 Kubernetes 的 "故障自愈" 能力，核心价值体现在：

自动检测故障：通过定期探测容器端口，及时发现应用无响应的问题（如进程崩溃、端口阻塞）。
自动恢复服务：一旦探测失败，立即重启容器，将服务恢复到正常状态，减少人工干预成本。
参数适配性：initialDelaySeconds 避免启动阶段误判，periodSeconds 和 timeoutSeconds 平衡探测灵敏度与资源消耗。

2.3.就绪探针

实验背景

就绪探针与存活探针的核心区别：

**存活探针：**判断 "容器是否存活→是否需要重启"；
**就绪探针：**判断 "容器是否就绪→是否可以接收请求"。即使容器进程在运行，若就绪探针失败，K8s 也会将其从 Service 的负载均衡列表中移除，不转发请求，避免用户访问到 "未准备好" 的服务（如应用启动后仍在加载数据、初始化配置）。

bash 复制代码

vim read.yml 
############
apiVersion: v1
kind: Pod
metadata:
  labels:
    run: readiness
  name: readiness
spec:
  containers:
    - image: myapp:v1
      name: readiness
      readinessProbe:           # 就绪探针配置
        httpGet:                # 探测方式：发送HTTP GET请求，检查应用层是否正常
          path: /test.html      # 探测路径
          port: 80              # 探测端口
        initialDelaySeconds: 1  # 容器启动后1秒开始第一次探测
        periodSeconds: 3        # 每3秒探测一次
        timeoutSeconds: 1       # 1秒内无响应则判定失败
############

探测方式选择（httpGet）：

适用于 Web 应用，通过检查 "指定 URL 的 HTTP 响应状态码" 判定就绪状态（默认返回 200-399 视为成功）。
本实验中，path: /test.html 是模拟 "应用需加载特定页面 / 配置文件才就绪" 的场景（如实际环境中探测 /health 健康检查接口）。

bash 复制代码

kubectl apply -f read.yml 

kubectl get pods        # # 查看 Pod 状态，未就绪
kubectl describe pods/readiness

Pod 状态显示为 Running 但 READY 列为 0/1：含义是 "容器进程在运行，但未就绪，无法接收请求"。
kubectl describe 输出 Readiness probe failed: HTTP probe failed with statuscode: 404：
- 原因：/test.html 文件不存在，HTTP 请求返回 404，就绪探针判定 "未就绪"。
- 核心逻辑：即使容器进程（如 nginx）在运行，只要就绪探针失败，K8s 就会将该 Pod 从 Service 的后端列表中排除，避免请求被转发到 "能访问但返回错误" 的容器。

bash 复制代码

kubectl exec pods/readiness -- /bin/sh -c "touch /usr/share/nginx/html/test.html"   # 进入容器，手动创建/test.html
kubectl get pods    # 再次查看Pod状态

创建 /test.html 后，就绪探针发送 HTTP GET 请求到 /test.html，返回 200 状态码，探针成功，Pod 的READY列从 0/1 变为 1/1。
实际价值：此时若该 Pod 关联了 Service，K8s 会自动将其加入负载均衡列表，开始转发请求 ------ 避免了 "应用启动但未就绪时接收请求导致失败" 的问题（如用户访问返回 404、503）。
示例场景：若 myapp:v1 启动后需要 10 秒加载数据库数据，可通过就绪探针循环探测 /health 接口，直到数据加载完成（接口返回 200），才允许接收请求，提升用户体验。

2.4.实验总结

Pod 生命周期三大核心机制的价值

机制	作用阶段	核心目标	关键特性	生产场景应用
Init 容器	Pod 启动前	完成主容器前置依赖	阻塞主容器启动、一次性执行、成功后退出	等待数据库就绪、下载配置文件、初始化权限
存活探针	容器运行中	故障自愈（不健康则重启）	持续探测、失败重启、保障容器存活	恢复端口无响应、进程死锁的应用
就绪探针	容器运行中	请求准入控制（就绪才接收）	持续探测、未就绪则隔离、就绪后加入负载	避免未加载完成的应用接收用户请求

三者协同作用，覆盖了 Pod 从 "启动→运行→服务" 的全生命周期稳定性需求：

Init 容器确保主容器 "有依赖才能启动"；
存活探针确保运行中容器 "不健康能自愈"；
就绪探针确保服务 "就绪后才接收请求"；最终实现 K8s 应用的高可用、低故障运行。

存活探针和就绪探针的区别

1. 区别

存活探针（Liveness Probe） ：

核心是判断「容器是否还 "活着"（能正常运行）」，不是只看 "是否存在所选资源"。

比如容器里的应用进程崩溃、端口阻塞、执行命令返回错误等，只要探针判定 "不健康"，Kubernetes 就会 直接重启容器（不是重启 Pod，Pod 里的容器重启），目的是修复 "死了" 的应用，实现 "故障自愈"。
就绪探针（Readiness Probe） ：

核心是判断「容器是否 "就绪"（能正常提供服务）」，未就绪时确实 "不重启"，但不只是 "等待"------ 更关键的是，Kubernetes 会 把这个 Pod 从服务负载均衡列表中移除 ，不让流量转发给它。

比如应用启动了但还在加载配置 / 连接数据库，此时容器 "活着" 但不能服务，就绪探针会让它 "待命"，直到就绪后再重新接入流量，避免用户访问到 "能连但用不了" 的服务。

2. 一句话总结关键差异

维度	存活探针（Liveness）	就绪探针（Readiness）
目标	保 "存活"（修复故障）	保 "可用"（避免无效流量）
失败后行为	重启容器（自愈）	移除流量、等待就绪（不重启）
典型场景	应用崩溃、端口无响应	应用启动中、依赖未就绪（如 DB）