k8s有强大的自愈能力，在容器发生故障的时候会自动重启，
但是不过想要实现更加精细的检查，可以使用liveness与readinesss
liveness: 自定义判断容器健康的条件：
vim liveness.yml
spec:
    containers:  
        args:
        - /bin/bash
        - c
        - touch /tmp/health; sleep 30; rm -rf /tmp/health; sleep 600
        livenessProbe:
          exec:
              command:
              - cat 
              - /tmp/health
          initialDelaySeconds:  10
          periodSeconds: 5


探测的方法是
1：通过 cat 命令检查 /tmp/healthy 文件是否存在。如果命令执行成功，返回值为零，
Kubernetes 则认为本次 Liveness 探测成功；如果命令返回值非零，本次 Liveness 探测失败。

2；initialDelaySeconds: 10 指定容器启动 10 之后开始执行 Liveness 探测，我们一般会根
应用启动的准备时间来设置。比如某个应用正常启动要花 30 秒，
那么 initialDelaySeconds 的值就应该大于 30。

3:periodSeconds: 5 指定每 5 秒执行一次 Liveness 探测。Kubernetes 如果连续执行
  3次 Liveness 探测均失败，则会杀掉并重启容器。




kubectl describe pod liveness:可以看见日志信息
 



readiness:自定义判断容器健康的条件

vim readiness.yml
spec:
    containers:  
        args:
        - /bin/bash
        - c
        - touch /tmp/health; sleep 30; rm -rf /tmp/health; sleep 600
        readiness:
          exec:
              command:
              - cat 
              - /tmp/health
          initialDelaySeconds:  10
          periodSeconds: 5




 Liveness 探测和 Readiness 探测是两种 Health Check 机制，如果不特意配置，
Kubernetes 将对两种探测采取相同的默认行为
即通过判断容器启动进程的返回值是否为零来判断探测是否成功。

    两种探测的配置方法完全一样，支持的配置参数也一样。不同之处在于探测失败后的行为：
Liveness 探测是重启容器；Readiness 探测则是将容器设置为不可用，不接收 Service 转发的请求。

    Liveness 探测和 Readiness 探测是独立执行的，二者之间没有依赖，所以可以单独使用，也可以同时使用。
用 Liveness 探测判断容器是否需要重启以实现自愈；用 Readiness 探测判断容器是否已经准备好对外提供服务。



scale up中readiness的使用

          httpGet:
              scheme: Http
              path: /health
              port: 8080
          initialDelaySeconds:  10
          periodSeconds: 5
部分。这里我们使用了不同于 exec 的另一种探测方法 -- httpGet。
Kubernetes 对于该方法探测成功的判断条件是 http 请求的返回代码在 200-400 之间。

schema 指定协议，支持 HTTP（默认值）和 HTTPS。
path 指定访问路径。
port 指定端口。

上面配置的作用是：
 容器启动 10 秒之后开始探测。
  如果 http://[container_ip]:8080/healthy 返回代码不是 200-400，
表示容器没有就绪，不接收 Service web-svc 的请求。
   每隔 5 秒再探测一次。
 直到返回代码为 200-400，表明容器已经就绪，
然后将其加入到 web-svc 的负责均衡中，开始处理客户请求。
    探测会继续以 5 秒的间隔执行，如果连续发生 3 次失败，
容器又会从负载均衡中移除，直到下次探测成功重新加入。