Configure Liveness, Readiness and Startup Probes | Kubernetes
对官方文档的阅读、理解，做一个记录。
用到哪里看到哪里。
看之前，总结之前，要问自己，是想真的搞懂，还是想应付了事，为了完成而完成，如果是后者，那就不用再继续下去了。
kubelet 使用 livenessProbe 用于判断何时重启容器，可以使用和readinessProbe相同的http方式，但是failureThreshold更长，为的是能够在该容器被hard kill之前是not ready的。
kubelet使用 readinessProbe 用于判断何时准备接受流量，pod中的所有容器都需要ready，才可以作为service 的后端。当pod没有ready时，或者变成not ready时将会从service 负载均衡中移除；
kubelet 使用startupProbe来判断何时容器应用已经启动，直到这个startupProbe执行检测成功之后才会执行livenessProbe/readinessProbe。startupProbe 的使用场景就是那些启动时间较长的应用，避免容器被livenessProbe kill掉。
之所以写这个kubelet就是想说，是kubelet发起的liveness/readiness/startup probe。
实验环境：
1. 如果你有集群，可能使用自己的集群，如果你没有可以使用killcoda：K8s 1.26 Playground | Killercoda
配置一个command 类型的 livenessProbe
有的应用长时间运行可能会转变成不可用状态，需要重启，livenessProbe会检测这种情况，并重启pod；
配置一个 http request 的livenessProbe
执行http请求，返回等于200 或者小于400 的status值，即为成功，kubelet 认定容器alive and healthy，如果返回其他status 则认定为失败。就目前的资料来看。不能自定义 success status
上述配置的/healthz接口，在前10秒内 返回200 ，大于10秒就返回500，返回500 就会重启容器；
配置一个tcp 的livenessProbe
通过建立tcp连接，来确定容器的状态，如果能个创建tcp 连接，则视为健康，如果不能，则会视为失败；
上述配置中，使用了readiness、liveness两中。
readiness 的配置中，是容器启动后5秒开始探测，如果成功则pod视为ready，kubelet会每10秒钟检测一次。
liveness 的配置中，是容器启动后15秒后开始探测，如果不成功则会restart容器。
配置一个grpc livenessProbe
grpc liveness 需要1.24以及以后版本支持
使用grpc probe，port必须配置。
grpc 不能按名称指定健康检查端口，也不能配置自定义主机名；
配置问题（configuration problems) 例如错误的端口（port)和服务（service）、为应用健康检查协议，会被认定为探测失败。
使用已命名的接口
ports:
- name: liveness-port
containerPort: 8080
hostPort: 8080
livenessProbe:
httpGet:
path: /healthz
port: liveness-port给启动慢的容器 ，配置startup 探针
与liveness/readiness probe 配置上的区别是，有更长的failureThreshold * periodSeconds
上述配置的startupProbe 有 30 * 10 = 600秒（5分钟）的时间来启动。一旦startupprobe检测成功，livenessProbe 就会接管接下的探测工作，如果执行不成功，那么就在5分钟后，根据pod 的重启策略进行 pod重启；
定义一个 readinessProbe
如果readinessProbe检测不通过，该pod不会作为service 的endpoint接受流量，处理请求；
readinessProbe运作与容器的整个生命周期；
与livenessProbe的区别，就是使用readinessProbe定义：
配置readinessProbe和livenessProbe的方式基本相同；
livenessProbe和readinessProbe并行使用，保证当pod执行livenessProbe/readinessProbe执行失败后，不接收流量，处理请求，并且重启容器；
probe参数说明
initialDelaySeconds： 容器启动多久执行startup/liveness/readiness 探针，默认0秒，最小0秒；
periodSeconds：间隔多久执行一次探针，默认10秒，最小1秒；
timeoutSeconds： 探测超时后的时间，单位秒，默认1秒，最小1秒，1.20以后版本生效；
successThreshold： 探测失败后被视为成功的最少连续成功次数。默认值1，liveness和startup必须是1，最小值是1；
failureThreshold： 失败次数，失败多少次被认定为失败
terminationGracePeriodSeconds：重启的等待时间，默认是继承 Pod-level 的 terminationGracePeriodSeconds 值（如果不指定则为 30 秒），最小值是1；
httpProbe参数
host：请求的地址；
scheme： http /https ,默认http
path：请求的路径，默认/;
httpHeaders: 自定义header；
port： 端口；可以是端口名，也可以是端口号；取值范围 1-65535；
tcpProbe
对于 TCP 探测，kubelet 在节点而不是 pod 中建立探测连接，这意味着您不能在主机参数中使用服务名称，因为 kubelet 无法解析它
probe-level terminationGracePeriodSeconds
1.21 版本以后，pod-level terminationGracePeriodSeconds被用来在liveness/startup probe 检测失败后终止容器。当terminationGracePeriodSeconds被设置以后，会导致失败的容器会费特别长的时间来重新启动。
在1.25及以上版本，可以在probe-level 配置terminationGracePeriodSeconds。当pod_level和probe-level都配置的时候kubelet 会使用probe-level 的值；
注意事项：
1.25 版本以后，ProbeTerminationGracePeriod 默认开启，如果不想开启这个功能，需要注意：
1. ProbeTerminationGracePeriod 功能门控仅在 API 服务器上可用。如果 Pod 上存在探测级别的 terminationGracePeriodSeconds 字段，则 kubelet 始终遵守该字段。
2. 如果您有设置了 terminationGracePeriodSeconds 字段的现有 Pod，并且您不再希望使用每个探测器的终止宽限期，则必须删除这些现有的 Pod。
3. 当您（或控制平面或其他组件）创建替换 Pod 时，功能门 ProbeTerminationGracePeriod 被禁用，那么 API server会忽略 Probe 级别的 terminationGracePeriodSeconds 字段，即使 Pod 或 Pod 模板指定了它。
不能为就绪探测设置探测级终止GracePeriodSeconds。它将被 API 服务器拒绝。
