k8s的探针
1、K8S中的三种探针ReadinessProbe、LivenessProbe和StartupProbe的作用如下：LivenessProbe：主要目的：在程序运行期间，监控容器内的应用程序状态。如果发现程序异常退出或处于不健康状态，能够自动重启容器，确保应用持续运行。执行方式：支持执行shell命令、http访问或TCP连接进行检查。
2、K8S中的探针主要分为存活探针、就绪探针和启动探针三类。存活探针：用于检查容器是否存活，并根据检查结果决定是否重启容器。这是提升应用可用性的重要手段。如果容器不再响应存活探针，系统将自动重启该容器，以确保服务的连续性。就绪探针：确保容器已经准备好提供服务。
3、k8s 可以通过存活探针 （liveness probe） 检查容器是否还在运行。 可以为 pod 中的每个容器单独指定存活探针。如果探测失败， k8s 将定期执行探针并重新启动容器。
4、首先，我们来看看三种探针的使用场景和目的。ReadinessProbe和LivenessProbe用于监控应用健康性和稳定性，确保服务可用。StartupProbe则在容器启动阶段监控应用状态，确保在容器启动后应用能够正常运行。ReadinessProbe和LivenessProbe的使用方式支持多种探测方法，包括exec、HTTP和TCP。
5、三大探针各有侧重，功能不同。ReadinessProbe与LivenessProbe在容器启动后会持续运行，直到容器生命周期结束，而StartupProbe则只在容器启动后执行一次，满足特定条件后停止探测。在使用方式上，这三种探针都支持执行、HTTP和TCP三种探测方法，并通过配置实现对探针行为的精确控制。
6、探针，作为工具或设备，用于探测、检测、测量或监测物理或化学性质。在计算机领域，探针指用于监测应用或系统性能的工具。K8S中，探针分为三大类：存活探针、就绪探针和启动探针，分别用于检查容器存活状态、容器是否准备好提供服务以及了解容器何时准备启动。
K8S问题排查-UDP频繁发包导致Pod重启后无法接收数据
原因： conntrack表项问题：在K8S环境中，通过NodePort暴露的UDP服务在接收到频繁请求时，由于UDP conntrack表项默认老化时间为30秒，频繁请求可能导致老化失效。当POD重启后，conntrack表中记录的可能是节点IP而非Pod IP，导致后续请求被错误地转发到节点IP而非新的Pod IP。
首先，构建K8S集群，部署UDP服务并用nc命令模拟客户端频繁发送UDP请求。网络分析显示请求正常到达目标Pod和节点，但Pod重启后接收中断。通过删除Pod构造重启，发现在Pod重启后，流量未按预期到达Pod，而是节点IP。使用iptables跟踪请求路径，发现流量未经过预期路径，而是进入INPUT链，指向DNAT问题。
当 Pod 状态为 CrashLoopBackOff 时，表示容器在启动后立即崩溃或退出。这可能是容器配置错误、应用程序错误、内存不足或权限问题导致。排查此类问题时，需详细检查容器配置、应用程序日志、内存使用情况及权限设置。Pod 状态为 Failed 通常意味着容器已终止，并且至少一个容器以失败方式退出。
经过排查，发现是由于etcd恢复后，控制平面组件缓存中的Object版本与etcd备份中的不一致导致的。通过手动重启所有kube-system下的pod并恢复本地保存的Config和Namespace，解决了Nacos数据丢失的问题。Kafka则手动在Node-01上通过docker-COMpose启动，以补救集群外的部署问题。
通过vagrant+virtualbox安装k8s找不到pod问题
1、通过vagrant+virtualbox安装k8s集群的小伙伴都会碰到找不到pod的问题，但是通过api服务查看，这些pod却是活的好好的。 原因是 ，在virtualbox组网的过程中，采用了双网卡方案，网卡1使用NAT地址转换用来访问互联网，网卡2使用Host-only来实现虚拟机互相访问。
2、Jenkins版本不匹配问题使用了过低版本的Jenkins镜像导致插件安装失败。更换为“jenkinsci/jenkins：latest”镜像，但实际版本并未提升，只是Linux系统不同。最终发现应使用“jenkins/jenkins”镜像，版本为“151-slim”。选择正确的镜像后，插件安装问题得到解决。
3、新建/etc/systemd/system/docker.service.d/http-proxy.conf，添加配置内容。安装virtualbox 安装k8s集群使用vagrant 参考jimmysong的vagrant教程 kubernetes-vagrant-centos-cluster，节点数量应根据个人机器配置调整（参考Kubernetes-vagrant-centos-cluster）。
使用Kubernetes常犯的一些错误
1、使用建议： 不要在Deployment中的镜像使用 ：latest 标签，而是使用固定的版本。 否则可能会导致部署时候，k8s node使用本地的旧版本的image， 导致线上环境出现版本问题。
2、原因：端口映射错误，服务正常工作但不能提供服务。解决方法：删除SVC，重新映射端口。Kubernetes集群服务暴露失败：原因：容器已暴露服务，但SVC配置有误。解决方法：删除SVC，重新映射端口。外网无法访问Kubernetes集群提供的服务：原因：集群的type为ClusterIP，未将服务暴露至外网。
3、在使用Kubernetes过程中，可能会遇到Permission denied错误。这通常发生在配置fluentd时，由于SELinux安全策略未关闭，导致无法创建日志文件。关闭SELinux安全策略即可解决此问题。基于ServiceAccount的配置中，首先生成所有必要的密钥文件，例如将k8s-master替换为master主机名。
4、如果容器无法启动，则Kubernetes将显示错误状态为：CrashLoopBackOff。 通常，在以下情况下容器无法启动： 应用程序中存在错误，导致无法启动 你未正确配置容器 Liveness探针失败太多次 你应该尝试从该容器中检索日志以调查其失败的原因。
k8s中Pod状态及问题排查方法
含义：调度器未能将 Pod 调度到可用节点。可能原因：节点资源不足或 Pod 依赖的资源未准备好。排查方法：检查节点资源使用情况及资源预留情况，确保集群有足够的 cpu 和其他资源。CrashLoopBackOff 状态：含义：容器在启动后立即崩溃或退出。可能原因：容器配置错误、应用程序错误、内存不足或权限问题。
Pod驱逐 节点资源不足时，K8s驱逐内存敏感型Pod。优化资源配额和限制值，避免资源被耗尽。Pod失联 Pod处于Unknown状态，无法获取信息。检查Kubelet状态，修复节点问题。无法被删除 Pod执行删除操作后长时间处于Terminating状态。排查删除操作和集群状态，确保删除流程顺利。
要排查镜像拉取问题，可使用kubectl describe pod命令检查pod事件，寻找“Failed to pull image”或“ImagePullBackOff”事件，表明镜像拉取存在问题。资源不足时，使用kubectl describe node命令检查节点资源状态。检查持久卷（PVC）状态，确保其STATUS为“Bound”，表明存储供应无问题。
首先，要从容器输出和状态详情入手。通过运行`docker logs $container_id`，您可以直接查看容器内的应用程序输出，以获取实时运行信息。接着，`docker inspect $container_id`可提供容器的详细状态信息，其中特别要注意“OOMKilled”信息，该信息表示容器因内存不足而被Docker自动终止。
K8S故障检查-Pod处于ContainerCreating状态
1、常见导致pod长时间处于“ContainerCreating”状态的原因包括镜像拉取问题、资源不足、持久卷问题、网络问题以及安全上下文或Docker/运行时问题。要排查镜像拉取问题，可使用kubectl describe pod命令检查pod事件，寻找“Failed to pull image”或“ImagePullBackOff”事件，表明镜像拉取存在问题。
2、面对k8s应用卡在ContainerCreating状态的困扰，我通过kubectl describe po命令获取到了关键的日志信息。
3、ContainerCreating：这种情况表示容器正在创建中，常见于配置问题导致的容器创建失败。例如，当使用docker服务时，可能会遇到节点上的kube-proxy、kubelet或docker服务重启后容器仍无法创建的情况。解决这类问题，通常需要检查服务的运行状态，确认资源是否充足，或者是否存在网络、存储配置问题。
4、一个pod的完整创建，通常会伴随着各种事件的产生，k8s种事件的种类总共只有4种：PodStatus 有一组PodConditions。PodCondition中的ConditionStatus，它代表了当前pod是否处于某一个阶段（PodScheduled，Ready，Initialized，Unschedulable），“true” 表示处于，“false”表示不处于。
