k8spod经常重启？ k8s启动pod老是启动不起来？
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 通常意味着容器已终止，并且至少一个容器以失败方式退出。
Calico-Node的pod实例一直报错重启的问题
kubekey calico-node起不来，经常重启的问题可能由证书过期、网络配置错误、资源限制或探针设置不当等原因导致。解决方法如下：更新证书和配置：如果k8s集群长时间未使用，可能会导致master节点的证书过期。此时需要更新证书，并检查calico的配置，确保它能正确访问apiServer。
常见导致pod长时间处于“CONTAINERCreating”状态的原因包括镜像拉取问题、资源不足、持久卷问题、网络问题以及安全上下文或Docker/运行时问题。要排查镜像拉取问题，可使用kubectl describe pod命令检查pod事件，寻找“Failed to pull image”或“ImagePullBackOff”事件，表明镜像拉取存在问题。
- 为calico/node创建密钥，确保与Typha之间的TLS安全连接。 配置Typha：- 生成证书和密钥，创建Typha使用的ServiceAccount，设置角色权限并启动Typha实例。1 测试网络：- 创建多实例并验证Pod之间的网络连接，包括不同IP池的IPAM分配。1 查看路由：- 确认Pod间网络连通性，验证路由表中下一跳信息。
切换到cross-subnet模式，kubectleditipPool/default-ipv4-ippool，将ipipMode改为crossSubnet，在UI将calico-node的POD删了重建，重启检查calico网络，可以看见同子网的主机出口走的是bgp，不同子网主机走的是tunl0网卡走ipip模式。
通过修改IP池配置，将ipipMode改为crossSubnet，并重建caliconode的POD。重启后检查网络，跨子网主机将通过tunl0网卡使用ipip模式。配置Route Reflector：在集群内的一台worker节点安装calicoctl，配置其连接kubernetes集群，并通过calicoctl对Calico进行控制。
pod频繁重启文件还在吗
1、在。Pod 只要挂载持久化数据卷，Pod 重启之后数据还是会存在的。Pod 是 Kubernetes 中的最小调度单元，k8s 是通过定义一个 Pod 的资源，然后在 Pod 里面运行容器，容器需要指定一个镜像，这样就可以用来运行具体的服务。一个 Pod 封装一个容器（也可以封装多个容器），Pod 里的容器共享存储、网络、存储等。
2、当pod出现crash状态，容器频繁重启，使用kubelet logs 方法可能无法获取到所需日志时，可以采用kubectl previous参数进行解决。该参数的使用原理基于kubelet在pod失败后会保留前几个容器的失败记录。这为后续查看提供了前提条件。
3、首先，前往运行该 pod 的节点，查找 kubelet 存放的日志文件。这些文件通过数字表示重启次数，例如 2393 和 2394，分别代表第 2393 次和第 2394 次重启后的日志。这些日志文件实际上是链接文件，指向 docker 容器的日志文件。
4、原因： conntrack表项问题：在K8S环境中，通过NodePort暴露的UDP服务在接收到频繁请求时，由于UDP conntrack表项默认老化时间为30秒，频繁请求可能导致老化失效。当Pod重启后，conntrack表中记录的可能是节点IP而非Pod IP，导致后续请求被错误地转发到节点IP而非新的Pod IP。
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状态，直至被终止。
