由于历史项目跑在kubernetes中 出现了一些如下问题

• 程序发布的时候 新版本的pod还没有启动成功 老版本的pod就已经停止了 ，这就导致部分请求访问到了新pod，由于新pod内程序还没有启动成功，所有这部分请求就以失败告终。还有可能新pod 启动失败了 就会出现pod一直在重启 然而服务又不可用。
• 运行中的pod 因为网络或者某种原因导致服务暂时不可用，对于kubernetes来说pod是状态是正常的，这时候的业务流量也可能会分发在次pod中，也是会报错误失败。
• 如何让kubernetes定义pod是否健康 是否启动成功？

健康检查

当前的kubernetes版本为 v1.19 提供了三种健康检查。

1. 存活探针 livenessProbe：通过检测容器响应是否正常来决定是否重启

   如果此探针检查失败 会重启容器

2. 就绪探针 readinessProbe: 用来确定容器是否已经就绪可以接受请求

   如果配置了就绪探针 只有通过探针检查后 才会认为pod具备访问的能力，kubernetes才会把ip port 加入到service中的endpoint中去，反之失败也会从endpoint中移除，这样流量就不会被分配到没有准备好的容器中去。

3. 启动探针 startupProbe: 检测容器内应用是否已经启动 v1.18+才支持

   启动探针在没有探测成功之前 livenessProbe、readinessProbe 探针会处于禁用状态。基于此特性 就可以避免livenessProbe由于一直失败 一直重启容器的死锁问题。

这3种探针都分别提供3种探测方式

• exec 执行命令行检查 如果返回值为0，则认为容器健康。
• httpGet HTTP请求检查 如果状态码为200~400之间，则认为容器健康
• tcpSocket TCP端口检查 如果端口是通的就认为容器健康。

由于项目使用SpringBoot 2.2.6项目 就自然使用到了spring-boot-starter-actuator包，注意 这里不同的Boot版本有点区别 如1.x，2.2.x和2.3 配置暴露指标的访问有些不一样。

springboot2.3+版本 还有提供 可读就绪指标/actuator/health/readiness 和 存活指标/actuator/health/liveness接口 可以直接分别用于kubernetes的就绪探针和存活探针。由于这里使用的2.2.6就都使用/actuator/health指标。

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

配置暴露health指标

management.endpoints.web.base-path=/actuator
management.endpoints.web.exposure.include=health

配置启动探针检查 理论是只有应用启动成功之后 才能对外提供服务 所以配置了httpGet探针来探测容器内 ip:port/actuator/health地址 如能成功返回200则认为是启动成功。

startupProbe:  # 启动探针
  httpGet:
    path: /actuator/health
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 10
  timeoutSeconds: 5
  successThreshold: 1
  failureThreshold: 30

这里额外配置了一些指标参数。三种探针 startupProbe 、livenessProbe、readinessProbe 都是一样的配置 这也是kubernetes在健康检查的配置上做得比较优秀的地方。

• periodSeconds 检查周期(s) 多少秒去检查一次
• initialDelaySeconds 延迟时间 (s) pod启动后 延迟多少时间 (s)后再去检查
• timeoutSeconds 超时时间 (s) 访问探测方式的超时时间 如上面访问 ip:port/actuator/health如果5秒还没有返回则认为是超时失败。
• successThreshold 成功阈值 (次数) 默认情况下 只要有1次访问成功 就算成功
• failureThreshold 最大失败次数 如上面配置的30次 30次都尝试都失败就表示Pod启动失败。这里可以配合periodSeconds参数来控制某些程序启动耗费时间太长的问题 如上面配置30*10=300s都没有成功的话 就失败。

配置存活探针 其目的是为了探测保证程序假死的情况

livenessProbe:                 # 存活探针
  httpGet:
    path: /actuator/health
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 10
  timeoutSeconds: 5
  successThreshold: 1
  failureThreshold: 10

配置就绪探针 其目的是为了探测保证程序随时都可用 如果就绪探针出现不可用的时候 会剔除service中的endpoint的ip port。保证流量只分发到可用的容器中去。

readinessProbe:                # 就绪探针
  httpGet:
      path: /actuator/health
      port: 8080
  initialDelaySeconds: 10
  periodSeconds: 10
  timeoutSeconds: 5
  successThreshold: 1
  failureThreshold: 10

这3中探针并不是必须都要配置， 需要视情况配置，如果不配置的情况下 默认按照Pod状态读取。如果Pod状态是成功 那么就认为是存活的、就绪的。

遇到的问题

1. 刚开始只配置了存活探针和就绪探针。导致启动的时候 存活探针一直失败达到了重启的条件。就出现一直重启pod的情况。后面加了启动探针 保证启动时间周期内不触发就绪探针。尽可能的配置failureThreshold * periodSeconds 来包容最坏情况下的启动耗时。

2. 部分服务出现deadline的情况

   context deadline exceeded (Client.Timeout exceeded while awaiting headers) Back-off restarting failed container

   可以把timeoutSeconds 配置调节大几秒钟。