第5章 Pod核心原理与工作负载

第5章Pod核心原理与工作负载云原生架构师实战课讲师：资深云原生架构师CONTENTS01.Pod核心原理：最小调度单元的设计哲学02.Pod生命周期：从创建到终止的完整旅程03.工作负载控制器：Deployment与StatefulSet详解04.特殊场景控制器：DaemonSet与Job05.实战案例：Sidecar与InitContainer模式06.常见问题与最佳实践07.课后实操任务：部署有状态应用Pod：Kubernetes的最小调度单元K8s中最小的、可部署的计算单元。它将一个或多个容器组合在一起，形成一个“逻辑主机”，共享网络和存储资源。共享网络(Network)共享同一个网络命名空间，拥有相同的IP和端口空间。容器间通过localhost直接通信。共享存储(IPC)共享同一个IPC命名空间，可通过进程间通信交互，访问同一个存储卷，方便共享数据。Pod生命周期：从Pending到Terminated主要状态阶段(Phases)Pending:系统已接受，但容器尚未准备好Running:已绑定节点，至少一个容器运行中Succeeded:所有容器成功终止，不会重启Failed:至少一个容器以失败状态终止关键健康检查(Milestones)InitContainers:应用启动前的初始化容器ReadinessProbe:检查是否准备好接受请求LivenessProbe:检查是否存活，失败则重启工作负载控制器：确保Pod始终按预期运行什么是工作负载控制器？K8s中管理Pod生命周期的“保姆”，监控Pod状态，在故障或资源不足时自动重建、扩容，确保应用高可用。控制器类型核心特性适用场景Deployment管理无状态应用，支持滚动更新和回滚无状态Web应用、微服务架构StatefulSet管理有状态应用，提供稳定的网络标识和存储数据库集群、分布式系统（如ETCD、Kafka）DaemonSet确保所有（或指定）节点上运行一个Pod副本日志收集（Fluentd）、监控代理（Prometheus）Job管理一次性任务，确保任务成功完成数据处理、批处理作业、定时任务Deployment：无状态应用的首选核心功能特性声明式更新：修改Pod模板自动触发滚动更新，不中断服务。版本控制与回滚：记录版本历史，支持一键回滚至稳定版本。弹性扩缩容：修改Replicas字段，轻松实现水平扩展。典型适用场景无状态Web应用：如Nginx、Tomcat等前端服务。微服务组件：API网关、业务逻辑服务等无状态组件。注意：Deployment仅适用于无状态应用管理。StatefulSet：为有状态应用而生稳定的网络标识每个Pod拥有固定可预测的主机名（如web-0），重建后标识不变。稳定的持久化存储关联独立的PVC，即使Pod被销毁重建，数据卷也会被重新绑定。有序部署与扩缩容严格按照序号顺序进行创建、更新和删除，确保依赖关系正确。▍架构示意图：StatefulSet管理Pod与存储特殊场景控制器：DaemonSet与JobDaemonSet核心功能：确保集群中的所有（或指定）节点上都运行一个Pod副本，常部署节点级守护进程。日志收集在每个节点部署Fluentd或Filebeat收集日志监控代理部署PrometheusNodeExporter监控节点状态存储插件部署存储相关的守护进程（如Ceph客户端）Job核心功能：管理一次性任务，确保任务成功完成。若失败，根据配置进行重试。数据处理执行一次性的数据导入、导出、迁移或离线分析任务批处理作业定期生成业务报表（通常与CronJob配合使用）一次性任务如数据库备份、初始化配置等只需执行一次的操作实战案例(1/2):Sidecar模式-透明的日志采集案例描述将日志采集容器作为Sidecar与应用容器部署在同一个Pod中，实现对应用日志的透明采集。核心优势解耦：采集与业务逻辑分离透明：无需修改业务代码实现方式应用输出日志到共享存储卷Sidecar读取并发送至日志中心实战案例(2/2):InitContainer-应用启动前的准备工作工作流程解析Pod调度到节点后，优先启动InitContainer1执行数据库初始化。随后启动InitContainer2从配置中心下载最新配置文件。所有前置任务完成后，业务容器才正式启动。核心优势与价值前置检查：确保依赖资源就绪，避免业务启动失败。职责分离：主容器专注业务逻辑，简化镜像设计。串行执行：严格的顺序执行机制，保证初始化顺序。流程图：Pod启动生命周期中的InitContainer阶段避坑指南：常见问题与最佳实践问题：Pod处于Pending状态原因：资源不足、镜像拉取失败、端口冲突排查：kubectldescribepod<pod-name>问题：Pod处于CrashLoopBackOff状态原因：应用启动失败、配置错误、依赖不可用排查：kubectllogs<pod-name>-c<container-name>最佳实践：合理设置资源请求与限制配置resources.requests和resources.limits避免节点资源竞争，防止资源浪费最佳实践：配置健康检查探针设置livenessProbe(存活)和readinessProbe(就绪)确保应用自动恢复，提升服务可用性课后实操：部署有状态应用MySQL任务目标使用StatefulSet部署MySQL主从架构配置独立PVC，确保数据持久化存储验证Pod重建后数据与网络标识不变操作步骤创建HeadlessService与StorageClass编写StatefulSetYAML，定义主从配置kubectlapply部署并初始化数据库删除Pod观察重建，验证数据完整性评判标准成功部署主从集群，每个Pod绑定独立PVCPod删除后自动重建，网络标识(hostname)保持不变重建后的Pod数据未丢失，可正常访问本章总结Pod本质：最小调度单元K8s的原子调度单位，通过共享网络命名空间和存储卷，将业务逻辑紧密相关的容器“打包”在一起运行。生命周期与健康检查掌握从Pending到Terminated的全流程状态转换，理解Liveness和Readiness探针在保障应用可用性中的关键作用。工作负载控制器选型根据应用是