K8s——Pod（1）-EW帮帮网

‌最小调度单元‌：每个 Pod 是 Kubernetes 中最小的可部署对象，包含一个或多个容器，这些容器总是被并置（colocated）在同一节点上，共享存储、网络命名空间和控制组（CGroup），确保它们在同一上下文中运行；这避免了容器间的通信延迟和资源冲突。
‌根容器设计‌：每个 Pod 包含一个特殊的 Pause 容器（根容器），用于设置 Pod 的 IP 地址、评估健康状态，并为其他业务容器提供共享网络栈和存储卷；业务容器通过挂载根容器的资源实现高效数据交换。
‌调度机制‌：Pod 被一次性调度到节点后，由 kubelet 管理其生命周期；如果调度失败（如节点崩溃），Pod 将被删除并重新创建，确保高可用性。

‌二、Pod 的特性‌

Pod 具备多个核心特性，支持高效、灵活的容器管理：

‌资源共享环境‌：
- 网络共享：Pod 内所有容器共享同一个 IP 地址和网络命名空间，可通过 localhost 直接通信，外部访问需通过 IP + 端口方式；不同 Pod 间的通信则依赖虚拟网络层（如 Calico）。
- 存储共享：容器可挂载共享存储卷（如 emptyDir、configMap），实现数据持久化或配置同步，简化了状态管理。
‌生命周期管理‌：
- Pod 状态包括 Pending（容器未启动）、Running（容器运行中）、Succeeded（所有容器成功终止）、Failed（容器异常终止）和 Unknown（状态未知）；状态变化由 kubelet 监控和报告。
- 重启策略（通过 spec.restartPolicy 定义）：支持 Always（默认自动重启）、OnFailure（仅在异常退出时重启）和 Never（不重启），确保容器故障时 Pod 能自我修复。
‌容器组织灵活性‌：
- 支持单容器或多容器模式：单容器 Pod 适用于简单应用，多容器 Pod 适用于紧密耦合服务（如 Web 服务器与日志代理），容器间通过共享资源减少通信开销。
- 扩展机制：如 Init 容器（用于启动前初始化任务）和临时容器（用于调试），增强 Pod 的功能适应性。

‌三、Pod 的意义‌

Pod 在 Kubernetes 体系中的意义在于解决容器化应用的设计与管理痛点：

‌支持紧密耦合应用‌：允许将多个关联进程（如 Web 服务与日志处理器）封装在同一 Pod 中，共享上下文环境；这避免了单容器多进程模式下的监控失效问题（如辅助进程崩溃无法被检测），提升应用整体稳定性。
‌提升编排效率‌：作为最小部署单元，Pod 简化了调度和资源分配；控制器（如 Deployment 或 ReplicaSet）基于 Pod 实现自动化扩缩容、滚动更新，降低了运维复杂性。
‌优化资源利用率‌：通过共享网络和存储，减少了冗余资源开销（如独立 IP 分配），同时支持原子性调度（容器作为整体部署），提高了集群资源利用率和应用性能。

Pod 的设计体现了 Kubernetes 对“逻辑主机”的抽象，解决了分布式系统中容器协同的挑战，是现代云原生架构的基础组件。

状态码详解

‌一、Pod 核心状态详解‌

‌Pending（挂起中）‌
- ‌触发条件‌：Pod 已被 API Server 接受，但未完成调度或容器启动。
- ‌典型原因‌：
  - 节点资源不足（CPU/内存）
  - 镜像拉取中（特别是大体积镜像）
  - 存储卷未绑定（如 PVC 挂载延迟）
- ‌关键子状态‌：
  - ContainerCreating：容器创建中（镜像拉取/存储挂载）
  - ImagePullBackOff：镜像拉取失败后的重试等待
‌Running（运行中）‌
- ‌触发条件‌：Pod 已调度到节点，至少一个主容器正在运行或启动中。
- ‌注意‌：
  - 不保证容器已就绪（需结合 Readiness Probe 检测）
  - 可能包含已终止的初始化容器
‌Succeeded（成功终止）‌
- ‌触发条件‌：所有容器正常退出（exit code = 0）。
- ‌典型场景‌：Job/CronJob 任务完成
‌Failed（失败终止）‌
- ‌触发条件‌：至少一个容器异常退出（exit code ≠ 0）或被系统终止（如 OOMKilled）。
- ‌排查工具‌：
  - kubectl logs --previous 查看崩溃前日志
  - kubectl describe pod 分析事件详情
‌Unknown（未知状态）‌
- ‌原因‌：节点失联或 API Server 与 kubelet 通信中断。
- ‌处理建议‌：检查节点状态并重启 kubelet

‌二、其他关键状态标识‌

‌状态名称‌	‌中文译名‌	‌触发条件‌	‌典型原因‌
‌CrashLoopBackOff‌	崩溃循环回溯	容器反复崩溃，kubelet 按指数退避策略重启	应用配置错误、依赖缺失、启动崩溃
‌ContainerCreating‌	容器创建中	Pod 已调度，但容器尚未启动完成	镜像拉取延迟、存储/网络配置未就绪
‌Terminating‌	终止中	Pod 收到删除指令但未完全停止	优雅终止耗时过长、终止钩子阻塞
‌Evicted‌	已驱逐	节点资源不足（如内存、磁盘）时主动驱逐 Pod	节点压力过大（OOM、磁盘满）
‌ImagePullBackOff‌	镜像拉取重试中	拉取镜像失败后进入重试循环	镜像不存在、仓库认证失败、网络中断
‌PodInitializing‌	Pod 初始化中	Init 容器正在执行初始化任务	Init 容器未完成（如数据预加载）
‌CreateContainerError‌	容器创建错误	kubelet 无法创建容器	镜像格式损坏、运行时配置冲突

‌三、状态码运维要点‌

‌退出码解析‌：
- ‌0‌：正常退出
- ‌1-128‌：应用自身错误（如配置异常）
- ‌129-255‌：系统中断导致（如 SIGKILL 对应 137）
- 转换规则：负退出码按 256 - (|code| % 256) 转换（如 exit(-1) → 255）
‌调试建议‌：
- 使用 kubectl describe pod 查看 ‌Events‌ 段定位根本原因；
- CrashLoopBackOff 需检查容器日志及资源请求限制；
- Evicted 状态需监控节点资源水位并优化调度策略。

探针

‌一、探针的核心原理‌

探针本质是 ‌kubelet 定期执行的健康检查机制‌，通过三种探测方式判断容器状态，并触发相应控制器行为：

‌检测执行者‌：
- 由节点上的 ‌kubelet‌ 直接发起（非 Master 或 Pod 自身），频率通过 periodSeconds 控制。
‌探测类型‌：
- ‌HTTP GET‌：向容器 IP 发送 HTTP 请求，状态码 2xx/3xx 视为成功（如 httpGet: { path: /healthz, port: 8080 }）。
- ‌TCP Socket‌：尝试与容器指定端口建立 TCP 连接，成功即通过（如数据库服务）。
- ‌Exec‌：在容器内执行命令，退出码为 0 视为健康（如 command: ["sh", "-c", "pgrep nginx"]）。
‌状态反馈机制‌：
- 探测结果实时反馈给 kubelet，触发 Pod 状态变更或控制器动作（如重启容器、调整流量）。

‌二、三大探针的特性与作用‌

‌探针类型‌	‌核心目标‌	‌触发动作‌	‌关键配置参数‌
‌LivenessProbe‌ (存活探针)	检测容器‌是否僵死‌（如死锁、内存泄漏）	失败时 ‌重启容器‌（依据 Pod 的 `restartPolicy`）	`failureThreshold`（连续失败次数阈值） `timeoutSeconds`（单次探测超时时间）
‌ReadinessProbe‌ (就绪探针)	判断容器‌是否准备好接收流量‌	失败时 ‌从 Service 的 Endpoints 移除 IP‌，暂停流量转发	`initialDelaySeconds`（启动后首次探测延迟） `successThreshold`（标记就绪的最小成功次数）
‌StartupProbe‌ (启动探针)	确保‌慢启动容器完成初始化‌	成功前‌禁用 Liveness/Readiness 探针‌；失败时重启容器	`periodSeconds`（探测间隔） `failureThreshold`（允许的最大失败次数）

‌参数详解‌

livenessProbe:
 httpGet: { path: /health, port: 80 }
 initialDelaySeconds: 10 # 容器启动10秒后开始探测
 periodSeconds: 5 # 每5秒探测一次
 timeoutSeconds: 3 # 超时3秒视为失败
 failureThreshold: 3 # 连续失败3次触发重启

‌三、探针的核心意义‌

‌提升服务自愈能力‌
- 存活探针自动重启异常容器（如进程阻塞但未退出），减少人工干预，保障服务持续可用。
‌保障流量精确调度‌
- 就绪探针确保流量仅转发至已初始化完成的 Pod，避免请求打到未就绪实例导致 5xx 错误。
‌兼容复杂应用场景‌
- 启动探针为慢启动应用（如 Java）提供保护窗口，防止存活探针误判初始化过程为故障。
‌优化滚动更新体验‌
- 就绪探针与 Deployment 结合，实现“新 Pod 就绪 → 旧 Pod 终止”的平滑更新，避免服务中断。

‌四、配置建议与风险规避‌

‌存活探针禁用场景‌：
避免对执行单次任务的 Job 配置存活探针，否则任务完成后容器退出可能触发误重启。
‌参数调优原则‌：
- initialDelaySeconds > 应用启动时间（如 Spring Boot 设 30 秒以上）。
- timeoutSeconds 需大于应用平均响应时间（建议 2-5 秒）。
‌探针轻量化设计‌：
检测接口应独立于核心逻辑（如专用 /healthz），避免资源竞争或级联故障。

镜像拉取策略

‌一、镜像拉取策略（Image Pull Policy）‌

‌原理‌
- 由 imagePullPolicy 字段控制，kubelet 根据策略决定是否从镜像仓库拉取镜像。
- 优先级规则：若未显式指定策略，镜像标签为 :latest 时默认为 Always，否则为 IfNotPresent。

‌特性‌

‌策略类型‌	‌行为‌	‌适用场景‌
`Always`	每次创建 Pod 都强制拉取最新镜像（即使本地已存在）	开发/测试环境，需频繁更新镜像
`IfNotPresent`	仅当本地不存在镜像时拉取（优先使用本地缓存）	生产环境，减少网络开销
`Never`	仅使用本地镜像，不主动拉取（需手动预加载）	离线环境或安全敏感场景

‌意义‌
- 平衡‌镜像一致性‌与‌启动效率‌：Always 确保版本严格一致，IfNotPresent 加速启动。
- 支持‌离线部署‌：通过 Never 策略实现无外网依赖的容器化部署。

‌二、重启策略（Restart Policy）‌

‌原理‌
- 由 restartPolicy 字段定义，kubelet 根据容器退出状态决定是否重启。
- ‌关键机制‌：
  - 检测容器进程退出码（0 为正常，非 0 为异常）。
  - 结合探针（如 livenessProbe）综合判断容器健康状态。

‌特性‌

‌策略类型‌	‌行为‌	‌适用场景‌
`Always`	无论退出码如何均重启（默认策略）	长期运行服务（如 Nginx）
`OnFailure`	仅当容器异常退出（非 0 退出码）时重启	批处理任务（失败后重试）
`Never`	永不重启（即使异常退出）	一次性任务或调试场景

‌意义‌
- ‌自愈能力‌：Always 策略保障服务持续可用，自动恢复崩溃的容器。
- ‌资源优化‌：OnFailure 避免无意义的重启（如成功退出的 Job）。

‌三、联合应用场景‌

‌生产环境典型配置‌：

spec:
 containers:
   - image: nginx:1.25 # 固定版本标签
   imagePullPolicy: IfNotPresent # 减少拉取延迟
 restartPolicy: Always # 确保服务高可用

镜像策略选择 IfNotPresent 提升启动速度，重启策略选择 Always 实现故障自愈。

‌调试任务配置‌：

spec:
 containers:
   - image: debug-tool:latest
   imagePullPolicy: Never # 依赖预加载镜像
 restartPolicy: Never # 避免干扰调试过程

通过 Never 策略完全控制容器生命周期。

通过镜像拉取与重启策略的灵活组合，Kubernetes 实现了‌部署效率‌与‌运行稳定性‌的平衡。

K8s——Pod（1）

基本概念

‌一、Pod 的原理‌