侧边栏壁纸
博主头像
好来斯 博主等级

穷则独善其身，达则兼济天下

  • 累计撰写 127 篇文章
  • 累计创建 33 个标签
  • 累计收到 13 条评论

目 录CONTENT

文章目录
kubernetes

若依微服务健康检查终极指南：K8s探针配置实战

Administrator
Administrator
2025-09-25 / 0 评论 / 1 点赞 / 15 阅读 / 0 字 / 正在检测是否收录...
温馨提示：
部分素材来自网络，若不小心影响到您的利益，请联系我们删除。

若依微服务健康检查终极指南：K8s探针配置实战

1. 实际应用场景背景

在企业数字化转型过程中，基于若依框架构建的微服务系统在Kubernetes集群中运行时，如何确保服务高可用成为关键挑战。
通过合理配置健康检查探针，可以实现故障自动恢复和流量智能调度，保障业务连续性。

2. 微服务健康检查的核心价值

Kubernetes通过三种探针来监控容器状态：

  1. 存活探针（Liveness Probe）：检测容器是否正常运行，失败时会重启容器
  2. 就绪探针（Readiness Probe）：检测容器是否准备好接收流量，失败时会从服务端点中移除
  3. 启动探针（Startup Probe）：检测应用是否已启动完成，适用于启动较慢的应用

这些探针协同工作，确保微服务在Kubernetes集群中的高可用性。

2.1 探针失败时的行为

当不同类型的探针失败时，Kubernetes会有不同的处理方式：

  • 启动探针失败：如果启动探针在配置的失败阈值内未能成功，Kubernetes会终止容器并根据重启策略决定是否重启。如果重启策略允许，会在当前Pod内创建一个新的容器实例来替代失败的容器。

  • 就绪探针失败：当就绪探针失败时，Kubernetes不会终止或重启Pod，而是将该Pod从服务的端点列表中移除，这意味着不会有新的流量被路由到这个Pod。一旦就绪探针再次成功，Pod会重新加入到服务端点列表中。

  • 存活探针失败：当存活探针失败时，Kubernetes会终止Pod中的容器，并根据Pod的重启策略在同一个Pod内创建一个新的容器来替代它。这会导致容器的重启，但Pod本身不会被重新创建。如果Pod的重启策略设置为Always或OnFailure，容器重启失败时可能会导致整个Pod被重新调度创建。

需要注意的是，就绪探针和存活探针是并行运行的，它们各自独立地进行检查和响应。如果只有就绪探针失败而存活探针成功，Pod会继续运行但不会接收流量；如果存活探针失败，无论就绪探针状态如何，容器都会被重启。

2.2 探针失败后的行为总结表

探针类型重启策略行为描述
StartupAlways重启工作容器（若多次失败且超时，可能触发 Pod 重建，取决于控制器配置）。
StartupOnFailure重启工作容器（仅当容器退出状态非零时生效）。
StartupNever不重启容器，Pod 保持运行但容器终止（启动失败）。
ReadinessAlways无影响（仅标记容器为未就绪，不重启或删除 Pod）。
ReadinessOnFailure无影响（同上）。
ReadinessNever无影响（同上）。
LivenessAlways重启工作容器（Pod 保持运行，容器重新启动）。若容器持续失败可能导致Pod重建。
LivenessOnFailure重启工作容器（仅当容器退出状态非零时生效，与 Always 在此场景下行为一致）。
LivenessNever不重启容器，Pod 保持运行但容器终止（需外部干预恢复）。

3. 若依系统架构与健康检查需求

若依微服务系统包含多个核心组件：

  • ruoyi-gateway：API网关，负责请求路由和权限控制
  • ruoyi-auth：认证授权服务，处理用户登录和Token验证
  • ruoyi-system：系统管理服务，包含用户、角色、菜单等基础功能
  • ruoyi-web：前端Web服务，提供用户界面

这些服务均基于Spring Boot框架，自带Actuator健康检查端点。

4. 健康检查配置实践

4.1 基础健康检查端点

若依项目基于Spring Boot框架，自带Actuator健康检查端点。为了启用这些功能，首先需要在项目的pom.xml文件中添加以下依赖：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

该依赖用于引入Spring Boot Actuator组件，它提供了生产就绪的功能，包括健康检查、指标收集等。Actuator是Spring Boot提供的用于监控和管理应用程序的模块。

然后在各服务的配置文件中启用健康检查并配置管理端口：

# 暴露监控端点
management:
  server:
    port: 18080
  endpoints:
    web:
      exposure:
        include: '*'

该配置的作用：

  1. 将Actuator的管理端口设置为18080，与应用程序的业务端口（通常是8080）分离
  2. 暴露所有web端点（通过include: '*'），包括健康检查端点
  3. 这样做可以将健康检查与业务逻辑分离，提高安全性
    management.png

在实际项目中，将管理端口与业务端口分离不仅提高了安全性，还避免了业务高峰期对健康检查接口的影响。

5. 基于Kustomize的健康检查配置实践

5.1 项目目录结构

ruoyi-cloud/
├── base/
│   ├── ruoyi-auth/
│   │   ├── deployment.yaml
│   │   ├── service.yaml
│   │   └── kustomization.yaml
│   ├── ruoyi-gateway/
│   │   ├── deployment.yaml
│   │   ├── service.yaml
│   │   └── kustomization.yaml
│   ├── ruoyi-system/
│   │   ├── deployment.yaml
│   │   ├── service.yaml
│   │   └── kustomization.yaml
│   └── ruoyi-web/
│       ├── deployment.yaml
│       ├── service.yaml
│       └── kustomization.yaml
└── overlays/
    └── ruoyi-cloud-prod-project/
        ├── ruoyi-auth/
        │   ├── health-patch.yaml
        │   └── kustomization.yaml
        ├── ruoyi-gateway/
        │   ├── health-patch.yaml
        │   └── kustomization.yaml
        ├── ruoyi-system/
        │   ├── ruoyi-system-v1/
        │   │   ├── health-patch.yaml
        │   │   └── kustomization.yaml
        │   └── ruoyi-system-v2/
        │       ├── health-patch.yaml
        │       └── kustomization.yaml
        └── ruoyi-web/
            ├── health-patch.yaml
            └── service-health-patch.yaml

5.2 基础配置文件

基础Deployment配置（以ruoyi-gateway为例）：

# base/ruoyi-gateway/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ruoyi-gateway
spec:
  template:
    spec:
      containers:
        - image: ruoyi-gateway-image
          env:
            - name: POD_IP
              valueFrom:
                fieldRef:
                  fieldPath: status.podIP
          name: ruoyi-gateway
          ports:
            - name: http-8080
              containerPort: 8080
              protocol: TCP
            - name: http-18080
              containerPort: 18080
              protocol: TCP

5.3 健康检查补丁配置

通过Kustomize补丁机制添加健康检查，避免修改基础配置：

# overlays/ruoyi-cloud-prod-project/ruoyi-gateway/health-patch.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ruoyi-gateway
spec:
  template:
    spec:
      containers:
        - name: ruoyi-gateway
          livenessProbe:
            httpGet:
              path: /actuator/health/liveness
              port: 18080
            initialDelaySeconds: 60
            periodSeconds: 10
            timeoutSeconds: 5
            failureThreshold: 3
          readinessProbe:
            httpGet:
              path: /actuator/health/readiness
              port: 18080
            initialDelaySeconds: 30
            periodSeconds: 5
            timeoutSeconds: 5
            failureThreshold: 3

就绪与存活探针是同步进行的。以ruoyi-gateway为例解释相关字段含义：

  • initialDelaySeconds：初始延迟时间，单位为秒
  • periodSeconds：检查间隔时间，单位为秒
  • timeoutSeconds：请求超时时间
  • failureThreshold：失败阈值，即连续多少次检查失败

容器启动后，livenessProbe和readinessProbe就准备开始工作，在经历initialDelaySeconds时间后，就开始向path: port发送HTTP GET请求，并等待响应。每隔periodSeconds时间检查一次，每发一次请求，timeoutSeconds后认为超时失败，如果连续failureThreshold次检查失败，则认为容器已经死亡，Kubernetes会重启该容器。

5.4 Kustomize配置引用

在overlay层引用补丁文件：

# overlays/ruoyi-cloud-prod-project/ruoyi-gateway/kustomization.yaml
resources:
  - ../../../base/ruoyi-gateway
patches:
  - health-patch.yaml

6. 各服务健康检查配置详解

6.1 Java服务健康检查（ruoyi-gateway、ruoyi-auth、ruoyi-system）

这些基于Spring Boot的服务使用Actuator端点：

livenessProbe:
  httpGet:
    path: /actuator/health/liveness
    port: 18080
  initialDelaySeconds: 60
  periodSeconds: 10
  timeoutSeconds: 5
  failureThreshold: 3
readinessProbe:
  httpGet:
    path: /actuator/health/readiness
    port: 18080
  initialDelaySeconds: 30
  periodSeconds: 5
  timeoutSeconds: 5
  failureThreshold: 3

6.2 Web服务健康检查（ruoyi-web）

前端Web服务使用首页作为健康检查端点：

livenessProbe:
  httpGet:
    path: /index.html
    port: 80
  initialDelaySeconds: 60
  periodSeconds: 10
  timeoutSeconds: 5
  failureThreshold: 3
readinessProbe:
  httpGet:
    path: /index.html
    port: 80
  initialDelaySeconds: 30
  periodSeconds: 5
  timeoutSeconds: 5
  failureThreshold: 3

7. Istio服务网格中的健康检查适配

在Istio环境中，健康检查配置会被自动重写：

原始配置：

livenessProbe:
  httpGet:
    path: /actuator/health/liveness
    port: 18080
    scheme: HTTP

Istio重写后：

livenessProbe:
  httpGet:
    path: /app-health/ruoyi-gateway/livez
    port: 15020
    scheme: HTTP

这是Istio的正常行为，通过重写探针路径确保流量经过sidecar代理。

8. 健康检查参数优化建议

8.1 探针参数配置原则

  1. initialDelaySeconds：根据应用启动时间设置，避免过早探测
  2. periodSeconds：生产环境建议10-30秒，平衡及时性和性能
  3. timeoutSeconds：通常设置为3-5秒，避免网络波动导致误判
  4. failureThreshold：设置为3次，防止瞬时故障导致服务中断

8.2 不同环境的差异化配置

开发环境可适当放宽探针条件，生产环境则需要更严格的配置以确保服务稳定性。

9. 故障排查与监控

9.1 常用排查命令

# 查看Pod详细信息和探针状态
kubectl describe pod <pod-name> -n <namespace>

# 查看Pod日志
kubectl logs <pod-name> -n <namespace> -c <container-name>

# 查看探针相关事件
kubectl get events --field-selector involvedObject.name=<pod-name>

9.2 常见问题处理

  1. 频繁重启：检查initialDelaySeconds是否足够长
  2. 探针超时：优化健康检查端点性能或增加timeoutSeconds
  3. 就绪探针失败：检查服务依赖和配置

10. 总结

通过Kustomize补丁机制为若依微服务系统配置健康检查，既保持了基础配置的纯净性，又实现了灵活的定制化需求。合理配置存活探针和就绪探针，结合Istio服务网格的自动适配，可以显著提升系统在Kubernetes环境中的稳定性和可靠性。

关键实践要点：

  1. 使用Kustomize补丁机制分离基础配置和定制配置
  2. 合理设置探针参数，平衡检测及时性和系统性能
  3. 理解Istio环境下健康检查的自动重写机制
  4. 建立完善的监控和故障排查流程

参考文档：

  1. Kubernetes官方文档 - 配置Liveness、Readiness和Startup探针
  2. Spring Boot Actuator文档
  3. Istio健康检查集成指南
  4. Kustomize官方文档
1
kustomize kubernetes

  1. 支付宝打赏

    qrcode alipay

  2. 微信打赏

    qrcode weixin
版权归属： Administrator
本文链接： https://howlaisi.com/categories/kubernetes/ruo-yi-wei-fu-wu-jian-kang-jian-cha-zhong-ji-zhi-nan-k8stan-zhen-pei-zhi-shi-zhan
许可协议： 本文使用《署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0)》协议授权

评论区