Java 部署：滚动更新（K8s RollingUpdate 策略）
👋 大家好，欢迎来到我的技术博客！
📚 在这里，我会分享学习笔记、实战经验与技术思考，力求用简单的方式讲清楚复杂的问题。
🎯 本文将围绕Java部署这个话题展开，希望能为你带来一些启发或实用的参考。
🌱 无论你是刚入门的新手，还是正在进阶的开发者，希望你都能有所收获！
文章目录
- Java 部署：滚动更新（K8s RollingUpdate 策略）
Java 部署：滚动更新（K8s RollingUpdate 策略）
在现代云原生应用开发中，持续交付和零停机部署已成为企业级 Java 应用的标配。而 Kubernetes（简称 K8s）作为事实上的容器编排平台，其 RollingUpdate（滚动更新） 策略为实现平滑、安全、无感知的应用升级提供了强大支持。本文将深入探讨如何在 Kubernetes 中对 Java 应用实施滚动更新，涵盖原理、配置、最佳实践、故障处理以及完整的代码与部署示例。
无论你是刚接触 K8s 的 Java 开发者，还是已有一定经验但希望优化部署流程的 DevOps 工程师，本文都将为你提供实用、可落地的指导。让我们从基础开始，逐步构建一个健壮、可维护的滚动更新体系 🚀。
什么是滚动更新（Rolling Update）？
滚动更新是一种渐进式部署新版本应用的策略。它通过逐个替换旧 Pod的方式，确保在整个更新过程中服务始终可用，从而实现零停机（Zero Downtime） 的目标。
在 Kubernetes 中，当你更新一个 Deployment 的镜像版本或配置时，如果策略设置为 RollingUpdate（默认值），K8s 会自动执行以下操作：
- 启动一个或多个新版本的 Pod；
- 等待新 Pod 就绪（通过就绪探针 Ready Probe 判断）；
- 将流量从旧 Pod 逐步切换到新 Pod；
- 删除一个或多个旧 Pod；
- 重复上述过程，直到所有旧 Pod 被替换。
这种“边下边上”的方式，避免了传统“蓝绿部署”或“全量替换”可能带来的服务中断风险。
💡 小知识：Kubernetes 的滚动更新是基于 ReplicaSet 实现的。每次更新 Deployment 时，K8s 会创建一个新的 ReplicaSet，并逐步缩容旧 ReplicaSet、扩容新 ReplicaSet。
为什么 Java 应用特别需要滚动更新？
Java 应用通常具有以下特点，使其对滚动更新有更高需求：
- 启动时间较长：JVM 预热、Spring Boot 初始化等过程可能需要数秒甚至数十秒；
- 内存占用高：频繁重启可能导致资源竞争；
- 有状态中间件依赖：如数据库连接池、缓存客户端等，需优雅关闭；
- 高可用要求：企业级系统通常要求 99.9% 以上的可用性。
若采用一次性删除所有旧实例再启动新实例的方式，用户将经历明显的请求失败或超时。而滚动更新通过控制并发替换数量，确保始终有足够健康的实例处理请求，极大提升了用户体验和系统稳定性 ✅。
Kubernetes 滚动更新的核心机制
Kubernetes 的滚动更新由两个关键参数控制：
maxUnavailable：更新过程中允许不可用的 Pod 最大数量（相对于期望副本数）；maxSurge：更新过程中允许超出期望副本数的最大 Pod 数量。
这两个参数共同决定了更新的速度与安全性。
默认值
对于一个 replicas: 3 的 Deployment，其默认滚动更新策略如下：
strategy:type: RollingUpdate rollingUpdate:maxUnavailable: 25% maxSurge: 25% 这意味着：
- 最多允许 1 个 Pod 不可用（3 × 25% ≈ 0.75 → 向上取整为 1）；
- 最多允许临时增加 1 个 Pod（3 × 25% ≈ 0.75 → 向上取整为 1）。
因此，更新过程可能如下：
- 创建 1 个新 Pod（总数变为 4）；
- 等待新 Pod 就绪；
- 删除 1 个旧 Pod（总数回到 3）；
- 重复直到全部替换。
参数详解
| 参数 | 类型 | 说明 |
|---|---|---|
maxUnavailable | int 或百分比 | 更新期间可处于“未就绪”状态的 Pod 数量上限。设为 0 可实现完全无损更新（但需配合 maxSurge > 0）。 |
maxSurge | int 或百分比 | 允许超过 replicas 设定值的额外 Pod 数量。用于提前启动新实例，加快更新速度。 |
⚠️ 注意：maxUnavailable和maxSurge不能同时为 0，否则更新将无法进行。
构建一个支持滚动更新的 Java 应用
为了演示滚动更新，我们先构建一个简单的 Spring Boot 应用，包含健康检查端点。
1. 创建 Spring Boot 项目
使用 Spring Initializr 创建一个 Web 项目，添加 Spring Web 和 Spring Boot Actuator 依赖。
2. 编写主类
// src/main/java/com/example/rollingupdate/DemoApplication.javapackagecom.example.rollingupdate;importorg.springframework.boot.SpringApplication;importorg.springframework.boot.autoconfigure.SpringBootApplication;@SpringBootApplicationpublicclassDemoApplication{publicstaticvoidmain(String[] args){SpringApplication.run(DemoApplication.class, args);}}3. 添加控制器
// src/main/java/com/example/rollingupdate/HelloController.javapackagecom.example.rollingupdate;importorg.springframework.web.bind.annotation.GetMapping;importorg.springframework.web.bind.annotation.RestController;@RestControllerpublicclassHelloController{@GetMapping("/hello")publicStringhello(){return"Hello from Java App v1! 🌟";}// 模拟版本信息，便于观察更新效果@GetMapping("/version")publicStringversion(){return"v1.0.0";}}4. 配置 Actuator 健康端点
在 application.yml 中启用健康检查端点：
# src/main/resources/application.ymlmanagement:endpoints:web:exposure:include: health,info endpoint:health:show-details: always Actuator 默认提供 /actuator/health 端点，返回 {"status":"UP"} 表示应用健康。
5. 构建 Docker 镜像
编写 Dockerfile：
# Dockerfile FROM eclipse-temurin:17-jre-alpine WORKDIR /app COPY target/*.jar app.jar EXPOSE 8080 ENTRYPOINT ["java", "-jar", "app.jar"] 构建并打标签（假设你的 Docker Hub 用户名为 yourname）：
./mvnw clean package -DskipTests docker build -t yourname/java-rolling-demo:v1 .docker push yourname/java-rolling-demo:v1 🔗 你可以参考 Docker 官方文档 了解如何构建镜像。
编写 Kubernetes Deployment 配置
接下来，我们将这个 Java 应用部署到 Kubernetes，并配置滚动更新策略。
deployment.yaml
apiVersion: apps/v1 kind: Deployment metadata:name: java-rolling-demo spec:replicas:3strategy:type: RollingUpdate rollingUpdate:maxUnavailable:1maxSurge:1selector:matchLabels:app: java-rolling-demo template:metadata:labels:app: java-rolling-demo spec:containers:-name: app image: yourname/java-rolling-demo:v1 ports:-containerPort:8080livenessProbe:httpGet:path: /actuator/health port:8080initialDelaySeconds:30periodSeconds:10readinessProbe:httpGet:path: /actuator/health port:8080initialDelaySeconds:10periodSeconds:5resources:requests:memory:"256Mi"cpu:"100m"limits:memory:"512Mi"cpu:"200m"---apiVersion: v1 kind: Service metadata:name: java-rolling-demo-svc spec:selector:app: java-rolling-demo ports:-protocol: TCP port:80targetPort:8080type: ClusterIP 关键配置说明
readinessProbe：决定 Pod 是否准备好接收流量。只有当探针成功，Service 才会将请求转发给该 Pod。这对滚动更新至关重要——新 Pod 必须完全就绪后才能加入服务。livenessProbe：用于判断应用是否存活。若失败，K8s 会重启容器。resources：限制资源使用，避免单个 Pod 占用过多资源影响其他实例。maxUnavailable: 1：最多允许 1 个 Pod 不可用（3 个副本时，至少 2 个在线）。maxSurge: 1：允许临时多启动 1 个 Pod，加快更新速度。
📌 重要：readinessProbe 是滚动更新平滑性的核心！务必确保其路径能真实反映应用就绪状态。部署并验证初始状态
应用上述配置：
kubectl apply -f deployment.yaml 检查 Pod 状态：
kubectl get pods -l app=java-rolling-demo 输出应类似：
NAME READY STATUS RESTARTS AGE java-rolling-demo-7d5b8c9f45-abc12 1/1 Running 0 2m java-rolling-demo-7d5b8c9f45-def34 1/1 Running 0 2m java-rolling-demo-7d5b8c9f45-ghi56 1/1 Running 0 2m 测试服务：
# 获取 Service IP（或使用 NodePort/Ingress） kubectl get svc java-rolling-demo-svc # 使用 curl 测试（假设已暴露到外部）curl http://<SERVICE-IP>/version # 返回: v1.0.0执行滚动更新：从 v1 到 v2
现在，我们准备发布新版本 v2。
1. 修改 Java 应用代码
更新 HelloController.java：
@GetMapping("/version")publicStringversion(){return"v2.0.0";// 改为 v2}并修改欢迎语：
@GetMapping("/hello")publicStringhello(){return"Hello from Java App v2! 🚀";}2. 构建并推送 v2 镜像
./mvnw clean package -DskipTests docker build -t yourname/java-rolling-demo:v2 .docker push yourname/java-rolling-demo:v2 3. 触发滚动更新
有两种方式：
方式一：直接修改 Deployment YAML
将 image 字段改为 yourname/java-rolling-demo:v2，然后执行：
kubectl apply -f deployment.yaml 方式二：使用 kubectl set image（推荐）
kubectl set image deployment/java-rolling-demo app=yourname/java-rolling-demo:v2 ✅ 这种方式无需修改文件，适合 CI/CD 自动化。
4. 监控更新过程
查看滚动更新状态：
kubectl rollout status deployment/java-rolling-demo 输出示例：
Waiting for deployment "java-rolling-demo" rollout to finish: 1 out of 3 new replicas have been updated... Waiting for deployment "java-rolling-demo" rollout to finish: 2 out of 3 new replicas have been updated... deployment "java-rolling-demo" successfully rolled out 同时，观察 Pod 变化：
kubectl get pods -w -l app=java-rolling-demo 你将看到旧 Pod 逐步被终止，新 Pod 逐步启动：
NAME READY STATUS RESTARTS AGE java-rolling-demo-7d5b8c9f45-abc12 1/1 Running 0 5m java-rolling-demo-7d5b8c9f45-def34 1/1 Running 0 5m java-rolling-demo-7d5b8c9f45-ghi56 1/1 Running 0 5m java-rolling-demo-6b8d9f7c54-jkl78 0/1 ContainerCreating 0 1s java-rolling-demo-6b8d9f7c54-jkl78 1/1 Running 0 10s java-rolling-demo-7d5b8c9f45-abc12 1/1 Terminating 0 5m30s ... 5. 验证新版本
多次调用 /version 接口：
foriin{1..10};docurl -s http://<SERVICE-IP>/version;echo;done初期可能返回 v1.0.0 和 v2.0.0 混合结果，随着更新完成，最终全部返回 v2.0.0。
这正是滚动更新的典型特征：流量逐步切换，用户无感知。
可视化滚动更新过程
下面是一个 Mermaid 图表，展示滚动更新中 Pod 状态的变化：
00:0000:0000:0000:0000:0100:0100:0100:0100:0200:0200:02Pod-A (v1)Pod-B (v1)Pod-C (v1)Pod-D (v2)Pod-E (v2)Pod-F (v2)旧 Pod新 PodKubernetes Rolling Update 过程（replicas=3, maxUnavailable=1, maxSurge=1）
💡 图中显示：新 Pod 在旧 Pod 终止前已启动并就绪，确保服务连续性。
滚动更新中的关键保障：探针（Probes）
前面提到，readinessProbe 是滚动更新平滑的关键。让我们深入理解其作用。
Readiness Probe（就绪探针）
- 作用：告诉 K8s “我准备好接收流量了吗？”
- 触发时机：Pod 启动后周期性调用。
- 行为：若失败，Pod 不会被加入 Service 的 Endpoints，即不会收到任何请求。
- Java 应用建议：
- 初始延迟（
initialDelaySeconds）应大于应用启动时间（如 Spring Boot 通常 10-30 秒）； - 路径应返回真实业务就绪状态（如数据库连接成功、缓存初始化完成等）。
- 初始延迟（
Liveness Probe（存活探针）
- 作用：告诉 K8s “我还活着吗？”
- 行为：若连续失败，K8s 会重启容器。
- 注意：不要将复杂逻辑放入 liveness probe，否则可能导致误杀。
示例：增强健康检查
你可以自定义健康指示器，确保只有在所有依赖就绪后才返回 UP：
@ComponentpublicclassDatabaseHealthIndicatorimplementsHealthIndicator{@OverridepublicHealthhealth(){// 检查数据库连接if(isDatabaseConnected()){returnHealth.up().withDetail("database","available").build();}returnHealth.down().withDetail("database","unavailable").build();}}这样，即使 Spring Boot 启动完成，若数据库未连通，/actuator/health 仍返回 DOWN，Pod 不会接收流量，避免错误请求。
🔗 更多关于 Spring Boot 健康检查的信息，可参考 Spring Boot Actuator 文档。
处理滚动更新失败：回滚（Rollback）
尽管我们做了充分准备，但更新仍可能失败（如新版本有 bug、配置错误等）。Kubernetes 提供了便捷的回滚机制。
查看更新历史
kubectl rollout history deployment/java-rolling-demo 输出：
REVISION CHANGE-CAUSE 1 <none> 2 kubectl set image deployment/java-rolling-demo app=yourname/java-rolling-demo:v2 回滚到上一版本
kubectl rollout undo deployment/java-rolling-demo K8s 会自动将镜像切回 v1，并执行反向滚动更新。
回滚到指定版本
kubectl rollout undo deployment/java-rolling-demo --to-revision=1自动回滚（高级）
Kubernetes 本身不支持“自动回滚”，但可通过以下方式实现：
- 结合监控告警：如 Prometheus + Alertmanager 检测到错误率飙升，触发 webhook 执行
kubectl rollout undo； - 使用 Argo Rollouts：这是一个 K8s 扩展，支持金丝雀发布、自动回滚等高级功能。
🔗 Argo Rollouts 官网 提供了更强大的渐进式交付能力。
优化滚动更新体验的最佳实践
1. 设置合理的探针参数
readinessProbe:httpGet:path: /actuator/health port:8080initialDelaySeconds:20# 根据应用启动时间调整periodSeconds:5timeoutSeconds:3successThreshold:1failureThreshold:32. 控制更新速度
- 若系统敏感，可设置
maxUnavailable: 0和maxSurge: 1，确保始终有全部副本在线； - 若追求速度，可增大
maxSurge（如 50%），但需注意资源压力。
3. 使用 preStop Hook 实现优雅关闭
在 Java 应用终止前，执行清理操作（如关闭连接池、拒绝新请求）：
containers:-name: app image: yourname/java-rolling-demo:v2 lifecycle:preStop:exec:command:["/bin/sh","-c","sleep 15"]同时，在 Spring Boot 中启用优雅关闭：
# application.ymlserver:shutdown: graceful spring:lifecycle:timeout-per-shutdown-phase: 30s 这样，当 Pod 被删除时：
- K8s 先从 Service Endpoints 中移除该 Pod（不再接收新请求）；
- 执行
preStophook（等待 15 秒，让现有请求完成）； - 发送 SIGTERM 信号给 Java 进程；
- Spring Boot 优雅关闭；
- 若超时未退出，发送 SIGKILL。
🌐 更多关于优雅关闭的内容，可参考 Kubernetes 官方文档 - Termination of Pods。
4. 监控滚动更新指标
通过 Prometheus 监控以下指标：
kube_deployment_status_replicas_updated：已更新的副本数；kube_pod_status_ready：Pod 就绪状态；- 应用层指标：错误率、延迟、吞吐量。
一旦异常，立即告警或自动回滚。
滚动更新 vs 其他部署策略
Kubernetes 还支持其他部署策略，适用于不同场景：
| 策略 | 特点 | 适用场景 |
|---|---|---|
| RollingUpdate | 逐步替换，零停机 | 大多数生产环境 |
| Recreate | 先删所有旧 Pod，再建新 Pod | 可接受短暂停机，或有状态应用需完全重置 |
| Blue/Green | K8s 原生不支持，需 Service 切换 | 需要快速回滚、全量验证 |
| Canary | K8s 原生不支持，需 Ingress 或 Service Mesh | 渐进式发布，小流量验证 |
💡 对于 Java 应用，RollingUpdate 是最常用且最安全的选择。
常见问题与排查
Q1: 更新卡住了，怎么办？
- 检查新 Pod 是否就绪：
kubectl describe pod <new-pod> - 查看日志：
kubectl logs <new-pod> - 检查 readinessProbe 是否失败；
- 确认镜像是否拉取成功（网络、权限问题）。
Q2: 用户偶尔收到 502 错误？
- 可能是旧 Pod 被终止时仍有请求在处理；
- 解决方案：配置
preStophook + 优雅关闭； - 确保 Service 的
sessionAffinity未开启（除非必要）。
Q3: 如何暂停/恢复滚动更新？
# 暂停 kubectl rollout pause deployment/java-rolling-demo # 恢复 kubectl rollout resume deployment/java-rolling-demo 适用于调试或分阶段更新。
总结
滚动更新是 Kubernetes 为 Java 应用提供的强大部署能力，它通过渐进式替换 Pod，结合就绪探针和优雅关闭机制，实现了零停机、高可用的持续交付。
要成功实施滚动更新，你需要：
- 构建健康的 Java 应用：提供准确的
/actuator/health端点； - 合理配置 Deployment：设置
maxUnavailable、maxSurge、探针参数； - 实现优雅关闭：使用
preStophook 和 Spring Boot 的 graceful shutdown； - 监控与回滚：建立可观测性，准备快速回滚方案。
随着云原生生态的成熟，滚动更新已成为 Java 应用上线的标准姿势。掌握它，你就能在微服务时代游刃有余地交付高质量软件 🎯。
🌟 最后提醒：永远在非生产环境充分测试你的滚动更新流程！自动化、标准化、可重复，是 DevOps 的核心精神。
Happy Coding & Happy Deploying! 🚀
🙌 感谢你读到这里！
🔍 技术之路没有捷径，但每一次阅读、思考和实践，都在悄悄拉近你与目标的距离。
💡 如果本文对你有帮助，不妨 👍 点赞、📌 收藏、📤 分享 给更多需要的朋友！
💬 欢迎在评论区留下你的想法、疑问或建议，我会一一回复，我们一起交流、共同成长 🌿
🔔 关注我，不错过下一篇干货！我们下期再见！✨
