12｜如何自动检查业务真实的健康状态？

k8s极简实践希望加上存储章节

1. 非k8s架构下其实也是通过探测来实现的只不过探测工具是自己的脚本和工具不一样。比如startupProbe可以通过查看进程是否存在、端口判断否启动；readinessProbe可以通过业务暴露的探活接口、真实业务接口来判断，但是摘除流量需要依赖负载均衡器的能力；livenessProbe也可以通过接口来判断但是重启就需要自己通过脚本来实现。在k8s架构下kubelet就像一位你的运维同事帮你把这些活儿给做了

1.通过脚本定时检查进程是否存在，进程不存在则拉去

老师上章节您讲HPA根据cpu或内存使用率扩容pod。请教一下，如何通过自定义指标扩容node主机节点呢。

1. Pod 的生命周期一共有下面这 5 个状态： - Pending：正在创建 Pod，例如调度 Pod 和拉取镜像的阶段。 - Running：运行阶段，至少有一个容器正在启动或运行。 - Succeeded：运行成功，并且不会重新启动，例如 Job 创建的 Pod。 - Failed：Pod 的所有容器都停止了，并且至少有一个容器退出状态码非 0。Unknown：无法获取 Pod 的状态。 2. Pod 中的容器，也有下面 3 种状态： - `Waiting`：容器等待中，例如正在拉取镜像。 - `Running`：容器运行中，PID=1 的业务进程正在启动或运行。 - `Terminated`：容器终止中，例如正在删除 Pod。 3. Pod具有PodStatus，该状态具有`PodConditions`数组 ，该Pod已通过或未通过。PodCondition数组的每个元素都有六个可能的字段： - 该`lastProbeTime`字段提供上次探测Pod条件的时间戳。 - 该`lastTransitionTime`字段提供Pod上一次从一种状态转换为另一种状态的时间戳。 - 该`message`字段是人类可读的消息，指示有关过渡的详细信息。 - 该`reason`字段是条件最后一次转换的唯一单词CamelCase原因。 - 该`status`字段是一个字符串，可能的值为“ True”，“ False”和“ Unknown”。 - 该`type`字段是具有以下可能值的字符串： - PodScheduled：Pod已调度到一个节点； - Ready：Pod能够处理请求，应将其添加到所有匹配服务的负载平衡池中； - Initialized：所有初始化容器 已成功启动； - Unschedulable：例如，由于缺乏资源或其他限制，调度程序无法立即调度Pod； - ContainersReady：Pod中的所有容器已准备就绪。

如果服务接受流量后触发了bug，导致假死，这种如何快速发现呢？

如果存活和就绪配置一样，就会导致业务压力上来后本来应该摘除流量，结果业务重启了，这样场景有什么最佳实践吗？是默认存活比就绪配置的久检查一些？

4. 探针： - Readiness：又称为就绪探针，它用来确定 Pod 是否为就绪（Ready）状态，以及是否能够接收外部流量。 - Liveness： 又称为存活探针，相比 Readiness 探针，它还能够在检测到 Pod 处于不健康状态时自动将 Pod 重启，（重启条件需要restartPolicy是 Always或OnFailure，默认是 Always） - StartupProbe：适用于业务应用启动慢的场景。当 Pod 启动时，如果配置了 StartupProbe，那么 Readiness 和 Liveness 探针都将被临时禁用，直到 StartupProbe 探针返回成功才会启用 Readiness 和 Liveness 探针 参数： - `initialDelaySeconds` 的含义是在容器启动之后，延迟 10 秒钟再进行第一次探针检查。 - `failureThreshold` 的含义是，如果连续 5 次探针失败则代表 Readiness 探针失败，Pod 状态为 NotReady，此时 Pod 不会接收外部请求。 - `periodSeconds` 的含义是探针每 10 秒钟轮询检测 1 次。 - `successThreshold` 的含义是只要探针成功 1 次就代表探针成功了，Pod 状态为 Ready 表示可以接收外部请求。 - `timeoutSeconds` 代表探针的超时时间为 1 秒。 5. TCP 探测: spec: containers: - name: flask-backend image: lyzhang1999/backend:latest ports: - containerPort: 5000 readinessProbe: tcpSocket: port: 5000 initialDelaySeconds: 10 failureThreshold: 5 periodSeconds: 10 successThreshold: 1 timeoutSeconds: 1 livenessProbe: tcpSocket: port: 5000 initialDelaySeconds: 10 failureThreshold: 5 periodSeconds: 10 successThreshold: 1 timeoutSeconds: 1

发现三处亮点 1.pod和容器的状态分别进行介绍，这差距 以前的文章都是pod状态多少多少种，基本没有提容器状态，这么一看理解更清晰 2.以前碰到过deployment进行更新时，会出现pod并未就绪就加入到endpoint里面，看完文章原来还是健康检查未理解 3.原来健康检查代表你的可用性，是有数据支持的 比如检测次数 间隔多久，这样说啥都有数据来支撑 真tm吊

1. 在我印象里我最初接触到的健康检查方式是Nginx upstream_check_module 开源模块实现的，一般是在 Nginx 作为反代的时候会用到 2. readinessProbe: tcpSocket: port: 5000