k8spod不会更新（k8s更新deployment）
k8s证书更新方式
1、方法一：配置自动更新脚本。此方法适用于使用原生kubeadm进行部署的集群。 在所有master节点上配置定时更新脚本，设置每周一凌晨三点执行更新操作，当证书有效期低于30天时自动触发更新。 操作步骤需要在所有master节点上执行。 方法二：使用原生kubeadm更新证书。
2、方式一：自动更新脚本对于原生kubeadm部署的集群，可以配置一个自动更新脚本来定期检查证书有效期。使用systemd定时器每周一凌晨三点执行，如证书有效期少于30天，脚本将自动更新。在所有master节点上执行相关配置。方式二：原生kubeadm更新针对kubeadm部署，master节点证书更新是关键。
3、donesystemctl start k8s-certs-renew.timersystemctl status k8s-certs-renew.timer原生 kubeadm 更新：手动操作对于更高级的用户，可以直接在 master 节点上执行原生 kubeadm 命令来更新证书。
4、登入 Jenkins Dashboard - 凭据 - 系统 - 全局凭据 （unrestricted）。 选择【旧凭据项目】，点击更新。 上传生成的 cert.pfx 文件至 Jenkins 中。 输入其凭据密码。至此，该问题解决完毕。通过此方法，能够帮助您解决由于K8S集群证书到期导致的Jenkins动态agent节点生成错误。
5、问题根源在于，kubernetes链接证书过期，无法正常运作。解决方案在于重新生成新的cert.pfx证书，并上传至凭据中心。执行步骤如下：首先，进入Jenkins Dashboard，点击“凭据”选项，选择“系统”并进入“全局凭据 （unrestricted）”页面。
6、先将要过期的证书作更名 3，生成k8s的config view，然后使用kubeadm生成新的证书对 4，依次升级完其它几个要过期的证书，包括与etcd连接的证书对。5，注意，有三个根证书对，是20年过期的，我没有更新（关键我不清楚更新之后，会发生什么事）。
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”表示不处于。
5、在集群部署过程中，可能会遇到问题。例如，如果创建pod时状态为containercreating，检查是否需要升级runc版本并配置源，然后重新安装。初始化集群时出现错误，可能需要编辑crio.conf来解决。另外，遇到fs.may_detach_mounts相关错误，可能是sysctl配置问题，需要调整相关设置后重启CRIO服务。
k8s中Pod状态及问题排查方法
含义：调度器未能将 Pod 调度到可用节点。可能原因：节点资源不足或 Pod 依赖的资源未准备好。排查方法：检查节点资源使用情况及资源预留情况，确保集群有足够的 cpu 和其他资源。CrashLoopBackOff 状态：含义：容器在启动后立即崩溃或退出。可能原因：容器配置错误、应用程序错误、内存不足或权限问题。
要排查镜像拉取问题，可使用kubectl describe pod命令检查pod事件，寻找“Failed to pull image”或“ImagePullBackOff”事件，表明镜像拉取存在问题。资源不足时，使用kubectl describe node命令检查节点资源状态。检查持久卷（PVC）状态，确保其STATUS为“Bound”，表明存储供应无问题。
Pod驱逐 节点资源不足时，K8s驱逐内存敏感型Pod。优化资源配额和限制值，避免资源被耗尽。Pod失联 Pod处于Unknown状态，无法获取信息。检查Kubelet状态，修复节点问题。无法被删除 Pod执行删除操作后长时间处于Terminating状态。排查删除操作和集群状态，确保删除流程顺利。
查看节点机docker中的容器ID，前后不一样，确定是POD被杀掉后重启。通过容器的IP地址、端口号及路径调用HTTP Get方法，如果响应的状态码大于等于200且小于400，则认为容器 健康 。
K8s中Pod生命周期和重启策略
K8s中Pod生命周期包括五种状态，重启策略有三种。Pod生命周期状态： Pending：API Server已创建Pod，但容器镜像尚未运行。 Running：Pod中的所有容器都在运行中或正在启动中。 Succeeded：Pod中的所有容器已成功退出，并且不会重启。 Failed：Pod中的所有容器都已退出，且至少有一个容器是异常退出的。
POD的生命周期与重启策略是K8s中的关键概念，理解它们对于确保应用程序稳定运行至关重要。
Always策略：无论正常或非正常停止，容器均会重启。例如，正常关闭Tomcat服务后，Pod状态恢复正常，而非正常关闭时，容器会重启。Never策略：正常或非正常停止，容器都不会重启。停止Tomcat后，正常情况下容器状态保持，非正常时显示Error状态。
请教Kubernetes部署问题,pod一直处于pending状态
针对k8s 10版本中coreDNS一直处于pending状态的问题，本文提供了一系列解决方案。首先，需要注意的是，当使用kubeadm init后，关闭cni可以解决部分问题。在进行kubeadm init操作前，应该在其他节点上也执行此操作，确保整个系统的一致性。对于kube-flannel.yml文件的修改，是一种推荐的解决方案。
如果你的Pod正在运行并处于就绪状态，但仍无法收到应用程序的响应，则应检查服务的配置是否正确。 Service旨在根据流量的标签将流量路由到Pod。 因此，你应该检查的第一件事是服务关联了多少个Pod。
事件记录Pod整个生命周期中的状态，便于问题排查。对于一直处于Terminated状态的Pod，可使用kubectl delete命令手动删除，支持自定义删除宽限期与是否强制删除。CrashLoopBackOff状态表示Kubernetes尝试启动Pod过程中出现错误，导致容器启动失败。排查方法包括查看描述信息、日志和前一个容器的日志。
和传统的部署方式有所区别的是，如果服务部署在kubernetes上，我们查看和检索日志的维度不能仅仅局限于节点和服务，还需要有podName，containerName等，所以每条日志我们都需要打标增加kubernetes的元信息才发送至后端。
这时，如果你部署 LoadBalancer 则会出现 External-IP 一直处于 pending 的问题。如果你使用的是 minikube ，官方提供了如下便捷的解决方法：执行完命令， External-IP 很快就会出现，详见 https：//minikube.sigs.k8s.io/docs/handbook/accessing/#using-minikube-tunnel 。
K8S线上集群排查,实测排查Node节点NotReady异常状态
1、K8S线上集群Node节点NotReady异常状态的排查方法主要包括以下几点：检查硬件资源：使用df m命令检查磁盘空间，确保有足够的空间供Node节点和Pod使用。使用free命令检查CPU使用率，确保CPU资源未被过度占用。使用top c命令查看CPU使用情况，确保无异常。
2、在项目中遇到的线上集群问题，特别是Kubernetes （K8S）集群中Node节点状态变为NotReady，导致服务停止的问题，我们进行了一次深入的排查与解决。文章将聚焦于如何有效识别和解决这类问题。首先，让我们了解一下在K8S中Pod的状态。
3、在搭建Kubernetes（k8s）集群过程中，若遇到节点一直处于NotReady状态问题，通过执行命令查看日志，发现提示信息为[failed to find plugin flannel in path [/opt/cni/bin]]。执行排查步骤，进入指定目录检查，确认flannel插件是否缺失。
4、一次K8S集群中遇到的Too Many Open Files问题排查，起因是一个运行机器学习推理服务的节点出现Node NotReady异常，通过查看日志发现是因为dockerd进程打开的文件数过多导致。初步怀疑是由于root用户文件限制较小，将限制调整为655360后重启docker进程，但问题并未解决，而是陆续在其他节点上重复出现。
