从入门到精通:掌握kubernetes探针的使用技巧
1、Liveness Probe Liveness Probe 主要用于检测容器是否存活。当探测失败，Kubernetes 将自动重启容器，确保应用程序处于健康状态。
2、在实际应用中，通过合理配置这些探针，如使用LivenessProbe进行健康检查，可以确保容器运行正常。LivenessProbe支持通过执行shell命令、http访问或TCP连接进行检查。而ReadinessProbe则用于判断容器是否准备好接收请求。StartupProbe则专注于容器启动阶段的稳定性，确保容器在启动后达到预期状态。
3、启动容器时，可以为 Kubernetes 配置一个等待时间，经过等待时间后才可以执行第 一次准备就绪检查。之后，它会周期性地调用探针，并根据就绪探针的结果采取行动。如果某个 pod 报告它尚未准备就绪，则会从该服务（Service）中删除该 Pod。如果 POD 再次准备就绪，则重新添加 pod。
4、对于就绪探针，可以使用HTTP Get请求作为检测方式。通过向容器的特定端口发送请求，并检查返回的状态码，Kubernetes可以判断容器是否已准备好接收流量。如果探测成功，容器将被标记为就绪；如果探测失败，则容器将被标记为未就绪。启动探针与就绪探针类似，但用于确保容器在启动后达到特定的状态。
5、首先，我们来看看三种探针的使用场景和目的。ReadinessProbe和LivenessProbe用于监控应用健康性和稳定性，确保服务可用。StartupProbe则在容器启动阶段监控应用状态，确保在容器启动后应用能够正常运行。ReadinessProbe和LivenessProbe的使用方式支持多种探测方法，包括exec、HTTP和TCP。
6、在调整小猫K8（通常指的是Kubernetes，简称k8s）时，需要考虑多个方面来确保其稳定运行和高效性。以下是一些关键步骤和技巧： **检查集群状态**：首先，使用`kubectl get nodes`和`kubectl get pods --all-namespaces`等命令来查看节点和Pod的状态，确保所有组件都在正常运行。
Pod的健康检查
Pod健康检查是Kubernetes生态系统中确保容器健康运行的关键机制，主要包括存活探测和就绪探测。 存活探测： 目的：监控容器内部应用程序的健康状态，确保应用程序在异常情况下能被及时重启。 实现方式： 命令执行：通过执行容器内部的自定义命令，判断应用程序的健康状态。
在Kubernetes的生态系统中，Pod健康检查机制是确保容器健康运行的关键。默认情况下，kubelet依据容器运行状态来判断健康，但这不足以监控容器内部应用程序的健康状况，比如程序假死。由此引入了健康检查机制，它通过存活探测（livenessProbe）和就绪探测（readinessProbe）来监控容器的健康状态。
大概意思就是最开始前10s返回状态码200，10s过后就返回500的status_code了。所以当容器启动3秒后，kubelet开始执行健康检查。第一次健康监测会成功，因为是在10s之内，但是10s后，健康检查失败，因为现在返回的是一个错误的状态码了，所以kebelet将会杀掉和重启容器。
探测的目的 ： 用来维持 pod的健壮性，当pod挂掉之后，Deployment会生成新的pod，但如果pod是正常运行的，但pod里面出了问题，此时deployment是监测不到的。
HEALTHCHECK的CMD命令和其他CMD命令一样，支持SHELL和EXEC两种格式。
云原生之K8S中Pod健康检测、服务可用性检查详解
通过容器的IP地址和端口号执行TCP检查，如果能够建立TCP连接，则表明容器 健康 。 资源文件定义 访问8080端口，但是8080端口未开放，所以访问会超时，不能建立连接，命中检测，重启Pod 用于判断容器服务是否可用（Ready状态） ，达到Ready状态的Pod才可以接收请求。
LVS虚拟服务器：外部流量通过dns解析得到的vip进入集群，LVS的viRtual server负责将流量分发给边缘节点。边缘节点配置：高可用性：在边缘节点上安装keepalived，通过IPVS创建并管理VIP，确保VIP的高可用性。健康检查：配置keepalived时，使用TCP_CHECK来检测real_server的健康状态。
在Kubernetes集群管理中，控制器是实现资源状态管理的关键组件。控制循环的工作原理涉及监控API服务器，通过Reflector获取资源状态，Informer监听变更，将变更加入Delta Queue，并确保线程安全处理。这一流程确保了资源始终符合预期规范，如Deployment和ReplicaSet控制器分别管理应用部署更新和副本数量的稳定性。
健康 检测接口用于检测应用的 健康 状态，在K8S中，使用Readiness和Liveness分别来探测应用是否就绪和是否存活，如果未就绪或者未存活，K8S会采取相应的措施来确保应用可用。如果我们应用未定义好相应的 健康 检测接口，K8S就无法判断应用是否正常可用，整个应用对我们来说就是黑匣子，也就谈不上应用稳定性了。
控制器控制器工作原理 Kubernetes控制器负责保持资源对象状态与期望状态一致。其工作流程包括监听API服务器、获取资源状态、处理资源变更，通过线程安全机制确保稳定性。扩缩容 Kubernetes通过部署、运维机制实现自动扩缩容。强调了健康检查、错误处理和弹性的重要性，确保应用高可用。
当Pod创建后进入调度阶段，Kubernetes调度器依据Pod的资源需求和调度规则选择节点。如果所有节点都无法满足Pod的需求，Pod将进入Pending状态。导致调度失败的原因包括集群资源不足、资源配额限制、NodeSelector不匹配、亲和性/反亲和性规则未被满足、节点不可用、或污点容忍不匹配等。
K8s中Pod生命周期和重启策略
例如，Deployment通常会将Pod的重启策略设置为Always，以确保Pod在出现问题时能够自动恢复。K8s重启的时间间隔和最大延迟 Kubernetes在重启Pod时，会遵循一定的时间间隔和最大延迟规则。具体来说，重启的时间间隔通常是2的幂次方倍增（即2n），最大延迟时间通常为5分钟。
Always策略：无论正常或非正常停止，容器均会重启。例如，正常关闭Tomcat服务后，Pod状态恢复正常，而非正常关闭时，容器会重启。Never策略：正常或非正常停止，容器都不会重启。停止Tomcat后，正常情况下容器状态保持，非正常时显示Error状态。
在Pod层面配置共享Volume，允许所有容器访问，保留持久数据，即使容器重启。容器间共享IP与端口空间，通过localhost相互发现。多容器Pod示例展示了共处容器与资源的打包管理，以及容器间通信与协调。Pod中设置重启策略，如Always，降低应用中断时间，适用于所有容器。
容器在其生命周期内也有Waiting、Running和Terminated等状态，以及针对不同状态的具体原因（Reason）描述。例如，容器状态为Terminated且原因CrashLoopBackOff，表示容器由于某种异常退出后，系统试图重启容器。
这是默认的镜像拉取策略。Always：每次创建Pod都会重新拉取一次镜像。Never：Pod不会主动拉取这个镜像，仅使用本地镜像。注意：对于标签为latest的镜像文件，其默认的镜像获取策略即为Always；而对于其他标签的镜像，其默认策略则为IfNotPresent。
使用节点选择器和节点亲和性时，需注意标签值的设置。在定义标签时，确保不要使用布尔值（如 true/false），若必须使用，记得在值前加上双引号以确保正确解析。若 Pod 所需的标签不存在于任何节点上，Pod 将长时间处于pending状态，直至被终止。
aliveness和liveness的区别
1、用途差异显著 - liveness探针主要用于确认Pod是否准备好接收流量，即当Pod就绪后，才能允许外部流量进入。- aliveness探针则用于检测容器是否仍然运行中，若检测到容器不活跃，则会触发Pod的终止。 探测机制区分 - liveness探针支持三种探测方式：HTTP GET、执行命令（exec）和TCP Socket。- aliveness探针仅支持HTTP GET和TCP Socket两种探测方式。
2、用途不同、探测方式不同。用途不同。liveness主要用于判断Pod是否就绪，如果就绪，接入层流量就能打到相应的Pod。而aliveness主要用于判断容器是否存活，如果不存活，则会杀死Pod。探测方式不同。liveness探测方式有httpget、exec和tCPSocket。而aliveness的探测方式只有httpget和tcPsocket。
3、alive同根词有aliveness，词根是alive。aliveness释义：adj. 活着的；有活力的；注意到的；热闹的 例句：Everything I do brings me aliveness and growth.我做的每一件事都带给我活力和成长。
4、v. 活，居住，过著 词形变化：名词：liveness 动词过去式：lived 过去分词：lived 现在分词：living 第三人称单数：lives 例句与用法： where do You live？你住在哪儿？ The cat is playing with a live mouse.猫在戏弄那只活老鼠。 People cannot live without air.没有空气，人们就不能生存。
5、第一步：Readiness 探测的配置语法与 Liveness 探测完全一样 这个配置文件只是将前面例子中的 liveness 替换为了 readiness，我们看看有什么不同的效果。第二步：部署 Pod readiness 的 READY 状态经历了如下变化：刚被创建时，READY 状态为不可用。
