重启pod当中一个容器（重启pod命令）

原标题：重启pod当中一个容器（重启pod命令）

导读：

pod和容器的关系是1、Pod 与容器之间的关系： Pod 是容器的容器，容器在 Pod 内部运行。 Pod 内的容器共享网络和存储资源，确保内部...

Pod和容器的关系是

1、POD 与容器之间的关系： pod 是容器的容器，容器在 Pod 内部运行。 Pod 内的容器共享网络和存储资源，确保内部容器间的高效交互。 kubernetes 在每个 Pod 中引入一个 Infra container，所有容器共享其 network Namespace，实现网络视图的一致性。

2、包含关系，Pod和容器的关系是包含关系。在Kubernetes中，一个Pod可以包含一个或多个容器，每个容器都是一个独立运行的应用程序或服务的实例。这些容器共享相同的网络命名空间、存储卷和其他资源，形成了一个逻辑上的整体，使得它们可以作为一个整体进行部署和管理。

3、在 KuberneTES 中，Pod 是核心概念之一，对于容器和 Pod 之间的关系，我们需要明确理解。首先，Pod 并非实体，而是一个逻辑概念，它在集群上承载和协调容器的执行。Pod 是容器的容器，可以看作是云平台中的虚拟机，而容器则是虚拟机中的用户程序，共享网络、存储和资源，确保内部容器间的高效交互。

4、容器与Pod之间的联系体现在它们都是Kubernetes核心组件，用于构建、部署和管理微服务架构。Pod负责管理一组相关的容器，并提供统一的网络与存储资源。容器则作为Pod中的基本运行单元，承载应用逻辑。容器提供了轻量级的虚拟化环境，使得应用在不同环境中快速部署与运行成为可能。

kubelet参数pod-infra-container-image什么意思

1、kubelet参数pod-infra-container-image什么意思这个是一个基础容器，每一个Pod启动的时候都会启动一个这样的容器。如果你的本地没有这个镜像，kubelet会连接外网把这个镜像下载下来。最开始的时候是在google的registry上，因此国内因为GFW都下载不了导致Pod运行不起来。现在每个版本的Kubernetes都把这个镜像打包，你可以提前传到自己的registry上，然后再用这个参数指定。

2、如果运行时标识值为 remote ，并且 --pod-infra-container-image 值非空，会输出警告信息：具体流程如下：关于 kubelet 动态配置解析请参考 Dynamic Kubelet Configuration 同时定义 --dynamic-config-dir 与 --config 时， kubelet 会 --dynamic-config-dir 中的动态配置。

3、在Kubernetes（K8s）中，当pod状态显示为“ContainerCreating”，这意味着pod已经由调度器分配至特定节点，该节点的kubelet正在创建容器。在此阶段，系统会进行容器创建操作。一旦所有容器启动并运行，pod状态将从“ContainerCreating”转变为“Running”。

4、kubelet会向containerd发起创建Pod的CRI请求，containerd则把请求转发给kata-runtime/shim-rune，最终调用QEMU/Dragonball/rune创建实际的Pod。在机密容器中，Pod被映射为CPU TEE。cpu TEE执行初始化，最终启动kata-agent/enclave-agent监听后续请求。

5、ImagePullBackoffKubernetes Pod启动失败原因之一是运行时无法从注册表中检索容器镜像。这种情况意味着Pod不会启动，因为清单中至少有一个容器无法启动。当Pod遇到此问题时，kubectl get Pods 命令将显示Pod状态为ImagePullBackOff。镜像名称或标签输入错误时，可能会发生此错误。

pod频繁 重启 文件还在吗

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

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

首先，前往运行该 pod 的节点，查找 kubelet 存放的日志文件。这些文件通过数字表示重启次数，例如 2393 和 2394，分别代表第 2393 次和第 2394 次重启后的日志。这些日志文件实际上是链接文件，指向 Docker 容器的日志文件。

原因： 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问题。