k8s健康检查探针配置

两种健康检查机制

Liveness探测:用户自定义判断容器是否健康。如果判断失败,则重启容器,使用restart策略。
Readiness探测:根据Deployment控制器的Rollingupdate作为判断条件

三种检查方式:
httpGet: 发送HTTP请求,返回200-400范围状态码表示成功
exec: 执行Shell命令返回状态码为0表示成功
tcpSocket: 发起TCP Socket建立成功
使用exec命令方式做liveness检查
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness # 测试活着
  name: liveness
spec:
  restartPolicy: OnFailure # 使用 restart 判断容器是否活着
  containers:
  - name: liveness
    image: busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30s; rm -rf /tmp/healthy; sleep 300000000 # 创建一个文件30秒后删除
    livenessProbe: # 创建一个健康检查
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 10 # 10秒后开始检查
      periodSeconds: 5 # 每隔5秒检查一次

在这里插入图片描述

使用httpGet命令方式做liveness检查
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: web
  name: web
spec:
  replicas: 1
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      restartPolicy: Always
      containers:
      - image: nginx
        imagePullPolicy: IfNotPresent
        name: web
        ports:
        - containerPort: 80
        livenessProbe:
          tcpSocket:
            port: 80
          initialDelaySeconds: 5
          failureThreshold: 2
          periodSeconds: 5
        readinessProbe:
          httpGet:
            path: /index.html
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 5
        startupProbe:  # startupProbe
	      httpGet:
	        path: /healthz
	        port: liveness-port
	      failureThreshold: 30
	      periodSeconds: 10  # 容器启动30*10=300s内liveness和readiness探针不会执行,300s后startup探针还没成
使用exec命令方式做 readiness检查,结果是直接将容器杀死,置为不可用
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: readiness # 测试活着
  name: readiness
spec:
  restartPolicy: OnFailure # 使用 restart 判断容器是否活着
  containers:
  - name: readiness
    image: busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30s; rm -rf /tmp/healthy; sleep 300000000 # 创建一个文件30秒后删除
    readinessProbe: # 创建一个健康检查
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 10 # 10秒后开始检查
      periodSeconds: 5 # 每隔5秒检查一次

在这里插入图片描述

滚动更新Rollingupdate对判断上的应用
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
spec:
  strategy:  #滚动更新策略
    rollingUpdate:
      maxSurge: 35%  # maxSurge:和期望ready的副本数比,超过期望副本数最大比例(或最大值),这个值调的越大,副本更新速度越快
      maxUnavailable: 35% #maxUnavailable:和期望ready的副本数比,不可用副本数最大比例(或最大值),这个值越小,越能保证服务稳定,更新越平滑
  selector: 
    matchLabels:
      run: app
  replicas: 10
  template:
    metadata:
      labels:
        run: app
    spec:
      containers:
      - name: app
        image: busybox
        args:
        - /bin/sh
        - -c
        - sleep 10; touch /tmp/healthy; sleep 3000000
        readinessProbe:
          exec:
            command:
            - cat 
            - /tmp/healthy
          initialDelaySeconds: 10
          periodSeconds: 5

<think>好的,我现在需要帮用户解答关于Spring Boot服务在Kubernetes中配置健康检查的问题。首先,我得回忆一下Kubernetes的健康检查机制,主要包括存活探针Liveness Probe)和就绪探针Readiness Probe),可能还有启动探针(Startup Probe)。Spring Boot提供了Actuator端点,比如/health、/actuator/health,这些可以用来作为探针的检查路径。 接下来,我需要考虑用户可能对Spring Boot和Kubernetes的基础知识了解程度。他们可能已经知道如何部署应用到Kubernetes,但不确定如何正确配置健康检查。用户的需求是合理的配置,所以需要详细说明每个探针的作用和配置建议。 首先,要确保Spring Boot应用已经引入了Actuator依赖,并启用了健康端点。然后,在Kubernetes的Deployment或Pod配置中定义livenessProbe和readinessProbe。需要解释每个参数的用途,比如initialDelaySeconds、periodSeconds、failureThreshold等,以及如何根据应用启动时间和响应需求调整这些参数。 可能会遇到的一个问题是,默认的Actuator端点可能暴露太多信息,或者路径需要调整。这时候需要告诉用户如何自定义健康端点的路径,或者使用不同的端口。另外,如果应用启动时间较长,启动探针配置也很重要,避免在启动过程中被误杀。 还需要提醒用户注意探针的响应时间和资源消耗,避免设置过短的超时时间导致误判。同时,结合Spring Boot的健康指标,比如数据库连接、磁盘空间等,确保探针能真实反映应用状态。 最后,总结配置示例和最佳实践,帮助用户快速应用到实际项目中。可能还需要提到一些常见问题和解决方案,比如探针失败后的处理策略,或者如何监控探针的状态。</think>Spring Boot 服务在 Kubernetes 中的健康检查配置主要涉及 **存活探针(Liveness Probe)** 和 **就绪探针(Readiness Probe)** 的合理设置。以下是分步配置指南: --- ### 一、前置条件 1. Spring Boot 需集成 Actuator 依赖 ```xml <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> ``` 2. 配置开放健康检查端点(application.yml) ```yaml management: endpoints: web: exposure: include: health,info endpoint: health: show-details: always ``` --- ### 二、Kubernetes 探针配置 #### 1. 存活探针Liveness Probe) **作用**:检测应用是否处于运行状态,失败则重启 Pod **推荐配置**: ```yaml livenessProbe: httpGet: path: /actuator/health/liveness port: 8080 initialDelaySeconds: 30 # 等待应用完成初始化 periodSeconds: 10 # 每10秒检查一次 failureThreshold: 3 # 连续失败3次触发重启 timeoutSeconds: 5 # 超时时间 ``` #### 2. 就绪探针Readiness Probe) **作用**:检测应用是否准备好接收流量,失败则从 Service 端点移除 ```yaml readinessProbe: httpGet: path: /actuator/health/readiness port: 8080 initialDelaySeconds: 20 periodSeconds: 5 failureThreshold: 3 timeoutSeconds: 3 ``` #### 3. 启动探针(Startup Probe,可选) **适用场景**:应用启动时间超过1分钟的情况 ```yaml startupProbe: httpGet: path: /actuator/health/startup port: 8080 failureThreshold: 30 # 允许最多30次检查 periodSeconds: 10 ``` --- ### 三、健康端点配置建议 1. **自定义健康组**(Spring Boot 2.3+) ```yaml management: endpoint: health: group: liveness: include: livenessState,ping readiness: include: readinessState,ping startup: include: startupState,ping ``` 2. **健康指标分级**: - 核心依赖(数据库、消息队列)放在 readiness 检查 - 次要依赖(缓存、外部API)放在 separate health group --- ### 四、最佳实践 1. **超时时间**应大于服务的 99% 响应时间 2. **失败阈值**根据业务容忍度设置(生产环境建议 ≥3) 3. **不要共用同一个端点**,避免存活/就绪状态耦合 4. 对长启动服务启用 `startupProbe`,禁用其他探针直到启动完成 5. 生产环境建议独立健康检查端口(与业务端口分离) --- ### 五、完整示例 ```yaml apiVersion: apps/v1 kind: Deployment spec: template: spec: containers: - name: spring-boot-app image: myapp:1.0.0 ports: - containerPort: 8080 livenessProbe: httpGet: path: /actuator/health/liveness port: 8080 initialDelaySeconds: 45 periodSeconds: 10 readinessProbe: httpGet: path: /actuator/health/readiness port: 8080 initialDelaySeconds: 20 periodSeconds: 5 startupProbe: httpGet: path: /actuator/health/startup port: 8080 failureThreshold: 30 periodSeconds: 10 ``` --- ### 六、常见问题排查 1. 检查健康端点是否返回 200 状态码 `kubectl exec <pod> -- curl -v http://localhost:8080/actuator/health` 2. 查看探针事件 `kubectl describe pod <pod-name> | grep -A 10 "Events:"` 3. 使用 `failureThreshold=1` 进行快速故障测试 通过合理配置健康检查,可以有效提高 Kubernetes 集群的自我修复能力和流量管理精度。建议根据实际业务负载进行压力测试,最终确定最佳参数组合。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

king config

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值