【k8s】一些小知识，持续更新

pod健康检查(liveness probe存活探针&&readiness probe 可读性探针)k8s容器探测机制

http get

对容器的ip地址(指定的端口和路径)执行http get请求
如果探测器收到响应，并且响应码是2xx, 3xx，则认为探测成功。如果服务器没有响应或者返回错误响应则说明探测失败，容器将重启。

tcp socket

探针与容器指定端口建立tcp连接，如果连接建立则探测成功，否则探测失败容器重启。

exec

在容器内执行任意命令，并检查命令退出状态码，如果状态码为0，则探测成功，否则探测失败容器重启。

查看pod存活探针信息

通过describe可以查看当前pod详情。
里面有关于pod存活探针的信息：
livenessProbe描述

Liveness:       http-get http://:8080/ delay=0s timeout=1s period=10s #success=1 #failure=3

delays: 延迟，delays=0s，表示在容器启动后立即开始探测
timeout: 超时，timeout=1s,表示容器必须在1s内进行响应，否则这次探测记作失败
period: 周期，period=10s，表示每10s探测一次容器
failure: 失败，failure=3，连续3次失败后重启容器
 
以上存活探针表示：容器启动后立即进行探测，如果1s内容器没有给出回应则记作探测失败。每次间隔10s进行一次探测，在探测连续失败3次后重启容器。

添加livenessProbe参数

initialDelaySeconds。如果没有设置，探针将在启动时立即探测，通常会导致探测失败，因为程序还没准备好开始接收请求。

这种情况很常见，看到容器在重启，使用describe会看到容器退出码为137或者143

Killing container with id docker://kubia:Container failed liveness probe… Container will be killed and recreated.

如果在pod启动时遇到这种情况，一般是没有设置 initialDelaySeconds导致的

pod健康检查(liveness probe存活探针&&readiness probe 可读性探针)：
在Kubernetes集群当中，我们可以通过配置liveness probe（存活探针）和readiness probe（可读性探针）来影响容器的生存周期。参考文档:https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/

kubelet 通过使用 liveness probe 来确定你的应用程序是否正在运行，通俗点将就是是否还活着。一般来说，如果你的程序一旦崩溃了， Kubernetes 就会立刻知道这个程序已经终止了，然后就会重启这个程序。而我们的 liveness probe 的目的就是来捕获到当前应用程序还没有终止，还没有崩溃，如果出现了这些情况，那么就重启处于该状态下的容器，使应用程序在存在 bug 的情况下依然能够继续运行下去。
kubelet使用活跃度探头知道什么时候重新启动的容器。例如，liveness probe可以捕获死锁，应用程序正在运行，但无法取得进展。在这种状态下重新启动容器可以继续存活。

kubelet 使用 readiness probe 来确定容器是否已经就绪可以接收流量过来了。这个探针通俗点讲就是说是否准备好了，现在可以开始工作了。只有当 Pod 中的容器都处于就绪状态的时候 kubelet 才会认定该 Pod 处于就绪状态，因为一个 Pod 下面可能会有多个容器。当然 Pod 如果处于非就绪状态，那么我们就会将他从我们的工作队列(实际上就是我们后面需要重点学习的 Service)中移除出来，这样我们的流量就不会被路由到这个 Pod 里面来了。
使用readiness probe来了解容器何时准备开始接受流量。当所有容器准备就绪时，Pod被认为已准备就绪。此信号的一个用途是控制哪些Pod用作服务的后端。当Pod未就绪时，它将从服务负载平衡器中删除。例如当一个应用服务有大文件加载时，这种情况下不允许接受用户访问，readiness probe就不会对这类型的程序启动服务。

许多运行很长时间的应用程序最终会转换到损坏状态，除非重新启动，否则无法恢复。Kubernetes提供活体探测器来检测和纠正这种情况。

附上参考地址：https://www.cnblogs.com/only-me/p/11393676.html