Day18-Kubernetes 那些事-Health Check

前言

由於现在 Pod 的数量越来越多了，因此如何控管好每个 Pod 可说是非常重要的动作，在开始细部介绍 K8s 是如何确保 Pod 是可以正常运行之前，首先要来做个事情准备，而这个就是 Pod 的 Health Check。

什麽是 Health Check？

Health Check 顾名思义就是健康检查，通常我们做健康检查的时候，医生都会问我们各个部位有没有哪边不舒服，如果都正常就代表我们其实没有生病， Pod 也是一样的道理，只要定时地透过访问某个路径来确保真的有回传资料就可以确保此 Pod 真的是处於正常的健康状态。

如何进行 Health Check？

一般来说 Health Check 有两种做法。

• 定期的透过指令去访问 container

  这种方式就不需借助 K8s，直接在 Dockerfile 内加上指令就可以，方法有非常多种，只要确保 container 可以正常回应需求即可，笔者通常都会利用 tail 输出 container 的记录档，以确保 container 是真的有在运行。

• 定期发送一个 HTTP request 给 container

  这个就必须要透过 K8s 的帮忙了，在 K8s 中一共有两种方式进行，这两种方式的使用场景也不太一样，所以读者未来要设定 Health Check 的时候也可以自行评估看看要使用哪种方式进行。

K8s Health Check

上面提到 K8s 的 Health Check 就是透过定时发送一个 HTTP request 到 container 中，这边就来介绍一下 K8s 是如何做到的。

• livenessProbe(存活探针)

  用於判断 Pod 是否为 Running 状态，如果 livenessProbe 探测到容器不健康，则该 Pod 将被砍掉并重启，如果该 Pod 不包含 livenessProbe，则 K8s 会认为该 Pod 的 livenessProbe 返回值永远成功。

• readinessProbe(就续探针)

  用於判断 Pod 是否启动完成可以接收请求，如果 readinessProbe 失败，则会将此 Pod 从对应的 service 的连线列表中移除，从此不再将任何请求调度此Pod上，直到下次探测成功。

Health Check 写法

由於 Health Check 是透过定时发送一个 HTTP request 到 container 中，所以这边一样沿用之前写好的 Deployment，并把 Health Check 加进去，也因为 livenessProbe 以及 readinessProbe 两者写法几乎一样，所以这边笔者只会挑其中一种来做示范。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloworld
spec:
  replicas: 2
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    minReadySeconds: 60
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: frontend
  template:
    metadata:
      labels:
        app: frontend
    spec:
      containers:
        - name: helloworld
          image: w5151381guy/helloworld
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: 200m
              memory: 500Mi
            limits:
              cpu: 500m
              memory: 800Mi
          livenessProbe:
            httpGet:
              path: /
              scheme: HTTP
              port: 8080
            initialDelaySeconds: 3
            periodSeconds: 60
            successThreshold: 2
            failureThreshold: 5

接下来要使用的是 livenessProbe，因此会在 container 内加上 livenessProbe 的设定，接下来就是细部设定要访问的 container 路径，在访问的过程都是用 GET 这个 HTTP method，所以才会加上 httpGet。

接下来就讲讲访问路径的详细设定吧！

• path

  设定 Health Check 要造访的路径，通常要进行 Health Check 时都会有一个独立的路径叫 /healthz ，但因为笔者并没有多设定这个路径要做的事情所以就直接打根路径了。

• scheme

  设定要造访的 scheme，预设为 HTTP 也可设定为 HTTPS。

• port

  设定要造访的 port，这边通常都会跟 container 走一样的 port。

讲完访问路径之後，接下来要讲 Health Check 每次访问时的设定了。

• initialDelaySeconds

  设定 Pod 刚启动时要间隔多久再启动 Health Check。

• periodSeconds

  每多久访问一次，预设为 10 秒。

• successThreshold

  设定访问几次而且都成功就代表 Pod 成功运行，预设为 1 次。

• failureThreshold

  代表 Pod 回传不如预期时，会再重新尝试的次数，预设为 3 次。

有 Health Check 的 Pod

可以发现在 container 的详细资料中多了一个 Liveness，也可以看到这个 Liveness 主要是在做什麽事情。

无 Health Check 的 Pod

没有 Health Check 的 Pod 其 container 也不会有 Liveness，所以根据 livenessProbe 的预设值这里永远都会回传探测成功。

小结

今天介绍了 K8s 的 Health Check，未来读者要建立 Pod 的时候要记得把 Health Check 的设定一并加进去，这样也会方便控管 Pod 整体运作。

接下来就要介绍 K8s 内部是如何沟通以及 Pod 是如何被删除的，如果有任何问题都欢迎在下面留言给我，那我们就下一篇文章见喽～