kubernetes Readiness and liveness and startupProbe

kubernetes Pod 的生命周期（Readiness and liveness and startupProbe）

容器探针

为何要使用readiness and liveness？

由于k8s中采用大量的异步机制、以及多种对象关系设计上的解耦，当应用实例数 增长/删除、或者应用版本发生变化触发滚动升级时，系统并不能保证应用相关的service、ingress配置老是及时能完成刷新。在一些状况下，每每只是新的Pod完成自身初始化，系统还没有完成EndPoint、负载均衡器等外部可达的访问信息刷新，老得Pod就当即被删除，最终形成服务短暂的额不可用，这对于生产来讲是不可接受的，因此这个时候存活探针（Readiness）就登场了

启动探针（startup Probe）

有时候，服务启动以后并不必定可以立马使用，咱们之前常作的就是使用就绪探针设置initialDelay(容器启动后多少s开始探测)值，来判断服务是否存活，大概设置以下

livenessProbe:
  httpGet:
    path: /test
    prot: 80
  failureThreshold: 1
  initialDelay：10
  periodSeconds: 10

可是这个时候会出现这么一个状况，若是咱们的服务A启动须要60s ，若是采用上面探针的会，这个pod就陷入死循环了，由于启动以后通过10s探测发现不正常就会更具重启策略进行重启Pod，一直进入死循环。那聪明的你确定能猜到咱们调整下initialDelay的值不就行了吗？ 可是你能保证每一个服务你都知道启动须要多少s 能好吗？
聪明的您确定又想到了 哪咱们能够调整下failureThreshold的值就行了，可是应该调整为多大呢？若是咱们设置成

livenessProbe:
  httpGet:
    path: /test
    prot: 80
  failureThreshold: 5
  initialDelay：10
  periodSeconds: 10

若是设置成这样，第一次pod 是能正常启动了，可是咱们到后面探测的话须要（5*10s=50s）咱们才能发现咱们的服务不可用。这在生产中是不容许发生的，因此咱们采用startupProbe使用和livenessProbe同样的探针来判断服务是否启动成功了

livenessProbe:
  httpGet:
    path: /test
    prot: 80
  failureThreshold: 1
  initialDelay：10
  periodSeconds: 10

startupProbe:
  httpGet:
    path: /test
    prot: 80
  failureThreshold: 10
  initialDelay：10
  periodSeconds: 10

咱们这只成这样的话，只要服务在1010=100s内任什么时候候启动来都行，探针探测成功后就交给livenessProbe进行继续探测了，当咱们发现问题的时候110=10 在10s内就能发现问题，并及时做出响应。

服务探针(readiness probe)

检测容器中的程序是否启动就绪,只有当检测容器中的程序启动成功以后,才会变成running状态,不然就是容器启动成功,他仍是失败的信号(由于他里面的服务没有探测成功)

存活探针(liveness Probe)(是否运行)

检测容器是否在运行,只是单纯的检测容器是否存活,并不会检测里面的服务是否正常.若是探针检测到失败,他将启动他的重启策略.

三种类型的处理程序:

• 1, ExecAction: 经过自定义命令来进行探测,当返回值是0的时候说明存活,当返回值非0的时候表示不存活.
• 2, TCPSocketAction: 对容器上的端口进行tcp检查,若是端口是打开的,则说明存活
• 3, HTTPGetAction: 对指定端口和url地址执行HTTP Get请求,若是响应的状态码大于等于200且小于400,则认为存活

每次探测都只能只能是下面三种结果:

• 1, 成功: 容器经过了测试
• 2, 失败: 容器未经过测试
• 3, 未知: 测试失败,所以不会采起任何动做

探针示例:

ExecAction

# cat nginx.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  restartPolicy: OnFailure
  containers:
  - name: nginx
    image: nginx:1.14.1
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80
      protocol: TCP
    - name: https
      containerPort: 443
      protocol: TCP
    livenessProbe:
      exec:
        command: ["test","-f","/usr/share/nginx/html/index.html"]
      failureThreshold: 3
      initialDelaySeconds: 5
      periodSeconds: 5
      timeoutSeconds: 5
    readinessProbe:
      httpGet:
        port: 80
        path: /index.html
      initialDelaySeconds: 15
      timeoutSeconds: 1

咱们启动这个容器,测试一下服务探针.

kubectl create -f nginx.yaml

咱们进入到nginx容器里面把index这个文件删除了,看看详细信息

#kubectl describe pod nginx
.....
Events:
  Type     Reason     Age                From                    Message
  ----     ------     ----               ----                    -------
  Normal   Scheduled  4m24s              default-scheduler       Successfully assigned default/nginx to 192.168.1.124
  Normal   Pulling    4m23s              kubelet, 192.168.1.124  pulling image "nginx:1.14.1"
  Normal   Pulled     4m1s               kubelet, 192.168.1.124  Successfully pulled image "nginx:1.14.1"
  Warning  Unhealthy  57s                kubelet, 192.168.1.124  Readiness probe failed: HTTP probe failed with statuscode: 404
  Warning  Unhealthy  50s (x3 over 60s)  kubelet, 192.168.1.124  Liveness probe failed:
  Normal   Killing    50s                kubelet, 192.168.1.124  Killing container with id docker://nginx:Container failed liveness probe.. Container will be killed and recreated.
  Normal   Pulled     50s                kubelet, 192.168.1.124  Container image "nginx:1.14.1" already present on machine
  Normal   Created    49s (x2 over 4m)   kubelet, 192.168.1.124  Created container
  Normal   Started    49s (x2 over 4m)   kubelet, 192.168.1.124  Started container

很明显的从事件信息里面能够看到他服务探测有一次是报错404的,而后立马就执行了重启容器的过程

探针参数介绍:

exec: 使用自定义命令编写探针
httpGet: 使用http访问的方式探测
tcpSocket: 使用tcp套接字来探测
failureThreshold: 连续失败几回算真正的失败
initialDelaySeconds: 容器启动多少秒以后开始探测(由于容器里面的服务启动须要时间)
periodSeconds: 探测时间间隔多少秒
timeoutSeconds: 命令执行的超时时间

HTTPGet的探针参数:

1. host: 探测那个主机(URL)
2. path: 访问的路径(URI)
3. port: 访问的端口(必须字段)
4. scheme：用于链接主机的方案（HTTP或HTTPS）。默认为HTTP
5. httpHeaders：要在请求中设置的自定义标头。HTTP容许重复标头。