当前位置：首页 > news >正文

Kubernetes Recreate 部署策略完整实战指南

news 2025/11/6 8:32:53

30 分钟掌握 Kubernetes 最简部署策略，让更新过程清晰可见。

在这里插入图片描述

👉 关联文章｜Containerd 从入门到精通：一篇吃透安装、镜像、排障全流程（涵盖 Containerd的基础使用和镜像加速配置及注意事项）

1 问题背景

在 Kubernetes 集群中，部署策略的选择直接影响应用的可用性、资源消耗和运维复杂度。很多工程师在面对 RollingUpdate、Blue-Green、Canary 等复杂策略时，往往忽略了最简单的 Recreate（重新创建） 策略的价值。

核心痛点：

复杂策略配置繁琐，学习成本高
资源消耗大，小集群难以承受
回滚机制复杂，故障排查困难

Recreate 策略的核心特征：先删除所有旧版本 Pod，然后创建新版本 Pod。这种策略会导致短暂的服务中断，但在特定场景下具有独特优势。

2 方案总览

2.1 技术特性对比

特性	Recreate 策略	RollingUpdate 策略
服务可用性	有短暂中断（秒级）	零停机时间
资源消耗	较低（无额外 Pod）	较高（需要额外 Pod）
部署复杂度	简单直接	相对复杂
回滚支持	完整支持	完整支持
适用场景	开发/测试环境、批处理应用	生产环境、用户面应用
更新速度	快速（批量操作）	相对较慢（逐步替换）

2.2 核心优势

零依赖：无需额外的服务网格或负载均衡器支持
资源友好：更新过程中不会额外占用集群资源
回滚完备：Kubernetes 原生支持版本回滚机制
简单可控：过程直观，便于故障排查

3 逐步拆解

3.1 实验环境准备

集群配置：

kubectl get nodes -o wide         # 查看所有节点的详细信息

网络架构详情（点击展开）

组件	版本	配置
Kubernetes	v1.28.2	1 Master + 2 Worker
容器运行时	containerd://1.6.33	CentOS Linux 7
网络插件	Flannel	Pod: 10.244.0.0/16

网络架构详情（点击展开）

网络规划：

Pod 网络：10.244.0.0/16
Service 网络：10.96.0.0/12
节点网络：192.168.209.0/24

验证命令：

kubectl get pods -n kube-system -o wide    # 查看kube-system命名空间下所有Pod的详细信息
kubectl get svc -n kube-system             # 查看kube-system命名空间下的服务列表

3.2 完整实验流程

步骤 1：创建 Recreate 策略 Deployment

目标：创建使用 Recreate 策略的 Nginx Deployment

配置文件内容（点击展开）

cat > nginx-recreate.yaml << 'EOF'
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-recreateannotations:kubernetes.io/change-cause: "Initial deployment with nginx:1.21"
spec:replicas: 2strategy:type: Recreate  # 核心：启用 Recreate 策略selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.21ports:- containerPort: 80resources:requests:cpu: 100mmemory: 128Milimits:cpu: 500mmemory: 512Mi
EOF

关键配置说明：

配置项	说明
`strategy.type: Recreate`	明确指定使用 Recreate 策略
`replicas: 2`	设置双副本，便于观察重建过程
`kubernetes.io/change-cause`	记录变更原因，便于后续回滚管理
`requests`	保证 Pod 启动所需的最小资源
`limits`	防止 Pod 过度消耗集群资源

步骤 2：部署应用并验证初始状态

目标：应用配置并创建 Deployment

操作执行：

kubectl apply -f nginx-recreate.yaml    # 应用配置文件创建Deployment

状态验证：

kubectl get deploy nginx-recreate -o wide    # 查看Deployment的详细状态和资源信息
kubectl get pods -o wide --show-labels     # 查看所有Pod的详细信息，包括标签

预期输出：

NAME             READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS   IMAGES       SELECTOR
nginx-recreate   2/2     2            2           4s    nginx        nginx:1.21   app=nginxNAME                             READY   STATUS    RESTARTS   AGE   IP           NODE    LABELS
nginx-recreate-76858866d-lwv2l   1/1     Running   0          7s    10.244.2.6   node2   app=nginx,pod-template-hash=76858866d
nginx-recreate-76858866d-lx82s   1/1     Running   0          7s    10.244.1.7   node1   app=nginx,pod-template-hash=76858866d

在这里插入图片描述
状态分析：

✅ 2 个 Pod 均处于 Running 状态
✅ Pod 分布在不同的工作节点上（node1 和 node2）
✅ 使用镜像版本为 nginx:1.21

步骤 3：执行版本更新触发 Recreate 策略

目标：使用在线更新命令修改镜像版本，触发 Recreate 策略

更新操作：

kubectl set image deployment/nginx-recreate nginx=nginx:1.23 \--record=true \--annotation="镜像版本更新从1.21到1.23"    # 更新镜像版本并记录变更原因

步骤 4：实时监控 Recreate 过程

目标：使用 watch 模式观察 Pod 重建过程，这是验证 Recreate 策略效果的关键步骤

监控命令：

kubectl get pods -w    # 实时监控Pod状态变化（watch模式）

在这里插入图片描述
观察要点：

终止阶段：所有旧 Pod 同时进入 Terminating 状态
清理阶段：旧 Pod 完全从集群中移除
中断期间：集群中无可用 Pod，服务暂时不可用（约 5-15 秒）
创建阶段：新 Pod 批量创建并进入 Running 状态

步骤 5：验证更新结果

目标：确认新版本 Pod 使用了更新后的镜像

验证命令：

kubectl describe pods | grep "Image:" | grep nginx    # 查看Pod使用的镜像版本
kubectl get deployment nginx-recreate -o wide         # 查看Deployment的详细状态

在这里插入图片描述
预期输出：

Image:          nginx:1.23
Image:          nginx:1.23NAME             READY   UP-TO-DATE   AVAILABLE   AGE   CONTAINERS   IMAGES       SELECTOR
nginx-recreate   2/2     2            2           5m    nginx        nginx:1.23   app=nginx

验证结果：

✅ 所有 Pod 镜像版本已更新为 nginx:1.23
✅ Deployment 状态正常，所有副本就绪

4 完整示例

4.1 回滚机制验证

查看部署历史

目标：查看可用的部署版本历史

查看命令：

kubectl rollout history deployment/nginx-recreate    # 查看Deployment的版本历史记录

预期输出：

deployment.apps/nginx-recreate 
REVISION  CHANGE-CAUSE
1         Initial deployment with nginx:1.21
2         Updated nginx from 1.21 to 1.23

执行回滚操作

目标：假设新版本出现问题，需要回滚到之前的稳定版本

回滚命令：

kubectl rollout undo deployment/nginx-recreate \--to-revision=1 \--annotation="kubernetes.io/change-cause=Rolled back to nginx:1.21 due to compatibility issues"    # 回滚到指定版本并记录原因

验证回滚结果

验证命令：

kubectl rollout status deployment/nginx-recreate    # 查看回滚操作的状态
kubectl get pods -o wide --show-labels             # 查看回滚后Pod的详细信息和标签

预期输出：

deployment "nginx-recreate" successfully rolled outNAME                             READY   STATUS    RESTARTS   AGE   IP           NODE    LABELS
nginx-recreate-76858866d-abc12   1/1     Running   0          30s   10.244.1.8   node1   app=nginx,pod-template-hash=76858866d
nginx-recreate-76858866d-def34   1/1     Running   0          32s   10.244.2.7   node2   app=nginx,pod-template-hash=76858866d

验证结果：

✅ 成功回滚到修订版本 1
✅ 所有 Pod 镜像版本恢复为 nginx:1.21
✅ Deployment 状态正常

5 常见坑

现象	原因	验证命令
Pod 卡在 Terminating 状态	应用未正确处理 SIGTERM 信号	`kubectl describe pod <pod-name> \| grep -A 10 "Events"`
新 Pod 无法创建	集群资源不足	`kubectl describe nodes \| grep -A 5 "Allocated resources"`
回滚失败	历史版本被清理	`kubectl rollout history deployment/nginx-recreate`
服务中断时间过长	terminationGracePeriodSeconds 设置过大	`kubectl get deployment nginx-recreate -o yaml \| grep terminationGracePeriodSeconds`
镜像拉取失败	镜像仓库不可达或认证失败	`kubectl describe pod <pod-name> \| grep -A 5 "Failed to pull image"`

背景补充（点击展开）

Pod 终止流程详解

当 Kubernetes 删除 Pod 时，会经历以下阶段：

发送 SIGTERM 信号（默认 30 秒宽限期）
等待应用优雅关闭
发送 SIGKILL 信号（强制终止）
清理资源

资源不足排查命令

# 查看节点资源使用情况
kubectl top nodes                                           # 显示各节点的CPU和内存使用情况# 查看 Pod 资源请求和限制
kubectl get pods -o yaml | grep -A 5 "resources:"          # 查看Pod的资源请求和限制配置# 检查是否有 Pod 处于 Pending 状态
kubectl get pods --field-selector=status.phase=Pending     # 筛选出处于Pending状态的Pod

6 结论与建议

核心结论

结论	说明
适用场景	Recreate 策略适合开发测试环境，简单直接，资源消耗低
服务中断	更新过程中会有 5-15 秒的服务不可用时间
资源效率	更新时不需要额外的 Pod 资源，适合资源受限场景
回滚机制	支持快速回滚到任意历史版本，机制完善

使用建议

场景类型	推荐程度	原因说明
开发环境	⭐⭐⭐⭐⭐ 强烈推荐	快速迭代，无需考虑服务连续性
测试环境	⭐⭐⭐⭐ 推荐	验证功能，可接受短暂中断
生产环境	⭐⭐ 谨慎使用	仅在维护窗口或后端服务场景使用
用户面应用	⭐ 不推荐	用户体验要求高，不能容忍服务中断