的一些常见问题)
1为什么 Kubernetes 不直接运行容器而是引入 Pod 这一逻辑概念现实业务里一套完整服务往往不止一个进程。 举个典型例子业务主程序 日志采集 sidecar 配置刷新 agent多个进程需要紧密配合。 将这些进程分别放到独立容器中无法共享网络和存储但如果全部放到一个镜像中则违反了“一个容器一个进程”原则导致资源限制不精细且无法独立升级。Pod 是 K8s 最小调度单元它是一个逻辑抽象不是真正运行的容器。 一个 Pod 内部可以包含多个业务容器共享网络命名空间Pod 内所有容器共用同一个 IP容器之间可以直接用127.0.0.1通信端口互相可见共享存储卷同一个 volume 挂载给 Pod 里多个容器实现文件互通日志、配置文件强制共置调度Pod 内所有容器一定会落在同一个 Node 节点一起创建一起销毁每个容器依然独立每个容器有自己镜像、资源限制、重启策略可以单独升级镜像。2 Pause 容器Infra 容器的作用及工作原理。Pause容器是Pod的底座。当Pod启动时K8s首先创建Pause容器它核心职责初始化并持有 Namespace包括 Network, IPC, 以及可选的 PID 空间。Pod内所有业务容器通过Linux的setns系统调用直接加入到Pause容器已经创建好的Namespace中。这样就能将所有业务容器在底层共享同一个网络堆栈和IPC空间就像在同一台主机上运行一样。3 Pod 从 kubectl apply 到 Running 状态的完整创建流程。受理阶段kubectl 将 YAML 转为 JSON 发给API ServerAPI Server 进行认证、授权、准入控制将 Pod 状态Pending存入etcd。调度阶段Scheduler监听到新 Pod执行预选过滤不合格节点和优选打分选择最佳节点将绑定结果更新回 API Server 并写入 etcd。执行阶段目标节点上的Kubelet监听到分配任务调用CNI分配 IP调用CSI挂载存储 调用CRI拉取镜像并启动容器。反馈阶段Kubelet 监控容器状态上报给 API Server 状态更新为 Running。4Pod 状态中的 Pending 和 ContainerCreating 有什么区别Succeeded 和 Failed 状态分别代表什么含义PendingPod 已被接收但还没有真正开始运行。Pending 表示 Pod 已经被 API Server 接收但还没有完成调度或者正在等待某些前置条件。ContainerCreatingPod 已调度正在创建容器环境。ContainerCreating 表示 Pod 已经被调度到某个具体节点Kubelet 正在为它准备运行环境。Succeeded 是 “任务已完成结果成功”。FailedPod 中有容器异常退出或被系统终止。Failed 表示 Pod 中所有容器都已经终止但至少有一个容器是以非 0 状态退出或者被系统强制终止。5如果一个 Pod 中有 3 个容器其中一个容器因为内存溢出 (OOM) 崩溃了整个 Pod 会发生什么重点K8s 的最小调度单元是 Pod但重启粒度是容器不是整个 Pod。只会 OOM 杀死故障的单个容器其余容器保持运行。根据 Pod 重启策略仅对故障容器执行重启不会删除重建整个 Pod 对象。Pod 状态仍然显示 Running。 风险点仅看 Pod 状态无法感知局部容器故障必须监控容器重启次数。6Init 容器初始化容器与普通业务容器在执行顺序和生命周期上有何不同Init 容器会优先于所有普通业务容器执行。 一个 Pod 可以写多个 init 容器它们串行执行按 yaml 定义顺序一个接一个跑。 第一个 init 容器执行完成退出之后才会跑第二个 init 容器全部 Init 容器全部完成才会启动业务容器。普通容器目的是长期持续运行提供服务。运行中崩溃退出才会根据重启策略重启对应容器多个容器互不阻塞一个挂掉不阻止其他容器运行。不需要必须退出正常状态是持续 Running。7什么是“原生 Sidecar 容器” (Native Sidecar)它解决了传统 Sidecar 的什么问题Sidecar 模式是 Kubernetes 非常经典的设计在同一个 Pod 中附加一个辅助容器和业务容器并行运行共享网络与存储。 常见例子日志采集、代理网格istio‑proxy、监控 agent、配置同步程序。传统 Sidecar和业务容器同时并行启动同时并行退出。传统 sidecar 是普通业务容器启动、停止时序完全不可控会带来业务早启动、日志丢失、Job 无法完成等问题。Native Sidecar 会优先于业务容器启动晚于业务容器退出Job 业务完成后 Pod 可以正常 Succeededsidecar 故障单独重启不重建整个 Pod专门解决 sidecar 生命周期时序痛点。8静态 Pod (Static Pod) 与普通 Pod 的核心区别是什么如何删除一个静态 Pod普通 Pod 由 API Server 管理可调度到任意节点静态 Pod 由节点上的Kubelet 直接管理不经过 API Server调度且始终绑定在特定节点。API Server 看到的静态 Pod 只能读而不能进行更改或删除。删除方法kubectl delete pod 对静态 Pod 无效因为 Kubelet 监测到本地文件丢失才会删除。必须直接删除宿主机上 /etc/kubernetes/manifests/ 目录下的 YAML 文件。 
长河君 · 2026/9/24 4:27:16 · 阅读 1.2k Pod (最小调度单元)的一些常见问题
1为什么 Kubernetes 不直接运行容器而是引入 Pod 这一逻辑概念现实业务里一套完整服务往往不止一个进程。 举个典型例子业务主程序 日志采集 sidecar 配置刷新 agent多个进程需要紧密配合。 将这些进程分别放到独立容器中无法共享网络和存储但如果全部放到一个镜像中则违反了“一个容器一个进程”原则导致资源限制不精细且无法独立升级。Pod 是 K8s 最小调度单元它是一个逻辑抽象不是真正运行的容器。 一个 Pod 内部可以包含多个业务容器共享网络命名空间Pod 内所有容器共用同一个 IP容器之间可以直接用127.0.0.1通信端口互相可见共享存储卷同一个 volume 挂载给 Pod 里多个容器实现文件互通日志、配置文件强制共置调度Pod 内所有容器一定会落在同一个 Node 节点一起创建一起销毁每个容器依然独立每个容器有自己镜像、资源限制、重启策略可以单独升级镜像。2 Pause 容器Infra 容器的作用及工作原理。Pause容器是Pod的底座。当Pod启动时K8s首先创建Pause容器它核心职责初始化并持有 Namespace包括 Network, IPC, 以及可选的 PID 空间。Pod内所有业务容器通过Linux的setns系统调用直接加入到Pause容器已经创建好的Namespace中。这样就能将所有业务容器在底层共享同一个网络堆栈和IPC空间就像在同一台主机上运行一样。3 Pod 从 kubectl apply 到 Running 状态的完整创建流程。受理阶段kubectl 将 YAML 转为 JSON 发给API ServerAPI Server 进行认证、授权、准入控制将 Pod 状态Pending存入etcd。调度阶段Scheduler监听到新 Pod执行预选过滤不合格节点和优选打分选择最佳节点将绑定结果更新回 API Server 并写入 etcd。执行阶段目标节点上的Kubelet监听到分配任务调用CNI分配 IP调用CSI挂载存储 调用CRI拉取镜像并启动容器。反馈阶段Kubelet 监控容器状态上报给 API Server 状态更新为 Running。4Pod 状态中的 Pending 和 ContainerCreating 有什么区别Succeeded 和 Failed 状态分别代表什么含义PendingPod 已被接收但还没有真正开始运行。Pending 表示 Pod 已经被 API Server 接收但还没有完成调度或者正在等待某些前置条件。ContainerCreatingPod 已调度正在创建容器环境。ContainerCreating 表示 Pod 已经被调度到某个具体节点Kubelet 正在为它准备运行环境。Succeeded 是 “任务已完成结果成功”。FailedPod 中有容器异常退出或被系统终止。Failed 表示 Pod 中所有容器都已经终止但至少有一个容器是以非 0 状态退出或者被系统强制终止。5如果一个 Pod 中有 3 个容器其中一个容器因为内存溢出 (OOM) 崩溃了整个 Pod 会发生什么重点K8s 的最小调度单元是 Pod但重启粒度是容器不是整个 Pod。只会 OOM 杀死故障的单个容器其余容器保持运行。根据 Pod 重启策略仅对故障容器执行重启不会删除重建整个 Pod 对象。Pod 状态仍然显示 Running。 风险点仅看 Pod 状态无法感知局部容器故障必须监控容器重启次数。6Init 容器初始化容器与普通业务容器在执行顺序和生命周期上有何不同Init 容器会优先于所有普通业务容器执行。 一个 Pod 可以写多个 init 容器它们串行执行按 yaml 定义顺序一个接一个跑。 第一个 init 容器执行完成退出之后才会跑第二个 init 容器全部 Init 容器全部完成才会启动业务容器。普通容器目的是长期持续运行提供服务。运行中崩溃退出才会根据重启策略重启对应容器多个容器互不阻塞一个挂掉不阻止其他容器运行。不需要必须退出正常状态是持续 Running。7什么是“原生 Sidecar 容器” (Native Sidecar)它解决了传统 Sidecar 的什么问题Sidecar 模式是 Kubernetes 非常经典的设计在同一个 Pod 中附加一个辅助容器和业务容器并行运行共享网络与存储。 常见例子日志采集、代理网格istio‑proxy、监控 agent、配置同步程序。传统 Sidecar和业务容器同时并行启动同时并行退出。传统 sidecar 是普通业务容器启动、停止时序完全不可控会带来业务早启动、日志丢失、Job 无法完成等问题。Native Sidecar 会优先于业务容器启动晚于业务容器退出Job 业务完成后 Pod 可以正常 Succeededsidecar 故障单独重启不重建整个 Pod专门解决 sidecar 生命周期时序痛点。8静态 Pod (Static Pod) 与普通 Pod 的核心区别是什么如何删除一个静态 Pod普通 Pod 由 API Server 管理可调度到任意节点静态 Pod 由节点上的Kubelet 直接管理不经过 API Server调度且始终绑定在特定节点。API Server 看到的静态 Pod 只能读而不能进行更改或删除。删除方法kubectl delete pod 对静态 Pod 无效因为 Kubelet 监测到本地文件丢失才会删除。必须直接删除宿主机上 /etc/kubernetes/manifests/ 目录下的 YAML 文件。