pod代码变更自动重启服务，pod重启ip会变化吗

kubelet版本升级引起的容器重启机制与参考解决方案

在版本升级前，需对比不同版本容器结构的变化，了解版本升级对容器HASH计算的影响。 采用记录并缓存kubelet版本及启动时间至本地文件的方法，可能因文件损坏导致容器服务仍重启。可临时手动生成文件作为备份。 每次版本升级前需更新源码并重新编译生成二进制文件，这一过程较为繁琐。

PLEG改进了Pod管理的效率，通过观察POD和容器的变更以实现最终一致性。Kubelet需要监控来自多个数据源的pod spec变化，并定期轮询容器运行时以获取容器状态。随着Pod和容器数量的增长，这些操作可能会导致较高的CPU使用率峰值，影响节点性能和可靠性。

要重启使用 kubeadm 部署的 k8s 集群的 API 服务器，首先需要确认 API 服务器的容器是否正常运行。这通常涉及到检查 kubeconfig 文件中的 server 地址设置是否正确。API 服务器作为集群的核心组件，以容器形式存在，且作为静态 pod 管理。这意味着它能够被 kubelet 容器运行时系统拉起。

统一操作：采用 CRI 接口统一容器操作，允许使用不同容器运行时而无需修改 Kubelet 代码。交互方式：通过 CRI 接口与容器运行时交互，如通过 gRPC 服务调用执行创建、删除等操作。架构与模块：模块化设计：Kubelet 架构分为多个模块，各模块协作完成节点管理、资源调度和容器运行等功能。

Pod调度就绪机制达到GA状态，从v26开始加入，v27阶段升级至Beta，解决在前置依赖未满足时，kube-scheduler调度Pod后kubelet侧尝试创建但失败的问题，通过新增机制，避免资源浪费。kubectl交互式删除功能升级至GA，引入了-`i`选项，类似Linux中`rm -i`，增加用户确认，避免误删重要资源。

重启策略决定了容器在失效后的处理方式。Always策略自动重启容器，OnFailure在容器退出状态码非0时触发重启，Never则始终不重启。在实践部署时，发现Always策略为K8s的默认设置，适用于大多数场景，如RC、DaemonSet等。而Job通常会使用Onfailure或Never策略。Kubelet在POD失效时自动重启，无论重启策略如何设置。

K8s中Pod生命周期和重启策略

K8s中Pod生命周期包括五种状态，重启策略有三种。Pod生命周期状态： Pending：API Server已创建Pod，但容器镜像尚未运行。 Running：Pod中的所有容器都在运行中或正在启动中。 Succeeded：Pod中的所有容器已成功退出，并且不会重启。 Failed：Pod中的所有容器都已退出，且至少有一个容器是异常退出的。

POD的生命周期与重启策略是K8s中的关键概念，理解它们对于确保应用程序稳定运行至关重要。

Always策略：无论正常或非正常停止，容器均会重启。例如，正常关闭tomcat服务后，Pod状态恢复正常，而非正常关闭时，容器会重启。Never策略：正常或非正常停止，容器都不会重启。停止Tomcat后，正常情况下容器状态保持，非正常时显示Error状态。

在Pod层面配置共享Volume，允许所有容器访问，保留持久数据，即使容器重启。容器间共享IP与端口空间，通过localhost相互发现。多容器Pod示例展示了共处容器与资源的打包管理，以及容器间通信与协调。Pod中设置重启策略，如Always，降低应用中断时间，适用于所有容器。

容器在其生命周期内也有Waiting、Running和Terminated等状态，以及针对不同状态的具体原因（Reason）描述。例如，容器状态为Terminated且原因CrashLoopBackoff，表示容器由于某种异常退出后，系统试图重启容器。

使用节点选择器和节点亲和性时，需注意标签值的设置。在定义标签时，确保不要使用布尔值（如 true/false），若必须使用，记得在值前加上双引号以确保正确解析。若 Pod 所需的标签不存在于任何节点上，Pod 将长时间处于pending状态，直至被终止。

K8S问题排查-UDP频繁发包导致Pod重启后无法接收数据

1、首先，构建K8S集群，部署UDP服务并用nc命令模拟客户端频繁发送UDP请求。网络分析显示请求正常到达目标Pod和节点，但Pod重启后接收中断。通过删除Pod构造重启，发现在Pod重启后，流量未按预期到达Pod，而是节点IP。使用iptables跟踪请求路径，发现流量未经过预期路径，而是进入INPUT链，指向DNAT问题。

2、当 Pod 状态为 CrashLoopBackOff 时，表示容器在启动后立即崩溃或退出。这可能是容器配置错误、应用程序错误、内存不足或权限问题导致。排查此类问题时，需详细检查容器配置、应用程序日志、内存使用情况及权限设置。Pod 状态为 Failed 通常意味着容器已终止，并且至少一个容器以失败方式退出。

3、在。Pod 只要挂载持久化数据卷，Pod 重启之后数据还是会存在的。Pod 是 kubernetes 中的最小调度单元，k8s 是通过定义一个 Pod 的资源，然后在 Pod 里面运行容器，容器需要指定一个镜像，这样就可以用来运行具体的服务。

4、Evicted：资源不足导致，需要监控存储和内存使用。CrashLoopBackOff：容器异常退出后又立即重启。Pod的重启策略通过spec字段的restartPolicy设定，常见值有Always（默认，异常退出即重启）、OnFailure（退出码非0时重启）和Never（不重启）。

5、当pod出现crash状态，容器频繁重启，使用kubelet logs 方法可能无法获取到所需日志时，可以采用kubectl previous参数进行解决。该参数的使用原理基于kubelet在pod失败后会保留前几个容器的失败记录。这为后续查看提供了前提条件。