流程图

具体生成过程

用户提交 Pod 定义

用户通过提交 Pod 的 YAML/JSON 配置文件发送到 kube-apiserver。

kubectl apply -f pod.yaml 

API Server 处理请求

• 认证与授权：API Server 验证用户身份（如 TLS 证书、Token）并检查权限（RBAC）。
• 准入控制（Admission Control）：
  • Mutating Admission Controllers：可能修改 Pod 配置（例如注入 Sidecar 容器）。
  • Validating Admission Controllers：验证配置的合法性（如资源限制是否合规）。
• 持久化存储：验证通过后，Pod 的元数据写入 etcd 数据库，此时 Pod 状态为 Pending。

调度器分配节点（Scheduling）

• kube-scheduler 监听 API Server，发现未绑定的 Pod。
• 根据调度策略选择合适节点：
  • 资源需求（CPU/内存）。
  • 节点选择器（nodeSelector）、亲和性（affinity）、污点与容忍（tolerations）。
• 更新 Pod 的 nodeName 字段并写入 etcd，触发事件（如 Scheduled）。

目标节点上的 Pod 创建

• kubelet 监听 API Server，发现分配到本节点的 Pod。
• Pod 配置同步：kubelet 从 API Server 获取 Pod 定义。
• 存储卷挂载：按配置挂载持久卷（PV）、ConfigMap、Secret 等。
• 容器运行时交互：
  • 拉取镜像：通过容器运行时（如 containerd）拉取镜像，失败时状态为 ImagePullBackOff。
  • 创建容器：
    • 先创建 pause 容器（共享网络命名空间）。
    • 按顺序启动 Init 容器（若有），全部成功后继续。
    • 启动主容器，执行生命周期钩子（如 postStart）。

网络配置

• CNI 插件调用：kubelet 调用 CNI 插件为 Pod 分配 IP、设置网络（如 Calico、Flannel）。
• 网络策略（NetworkPolicy）可能由 CNI 插件或其他组件（如 Cilium）实施。

状态上报与监控

• kubelet 持续监控容器状态，定期向 API Server 上报：
  • 容器启动成功 → Pod 状态变为 Running。
  • 容器崩溃或探针失败 → 状态为 CrashLoopBackOff 或 Unhealthy。
• 事件流记录：各组件（调度器、kubelet）通过 API Server 记录事件（如 Pulled, Started），可通过 kubectl describe pod 查看。

控制器管理（Controller Manager）

• 若 Pod 属于高层资源（如 Deployment、ReplicaSet）：
  • 控制器确保实际状态与期望状态一致（例如重启失败的 Pod 或维持副本数）。
  • 自愈机制：自动替换不健康的 Pod（如节点故障时重新调度）。

就绪与服务发现

• 就绪探针（Readiness Probe） 通过后，Pod IP 被加入 Service 的 Endpoints。
• kube-proxy 更新节点上的 iptables/ipvs 规则，允许流量路由到新 Pod。

关键错误场景

• 调度失败：无合适节点 → Pod 保持 Pending，需检查资源请求、节点标签或污点。
• 镜像拉取失败：私有镜像权限问题 → 状态为 ImagePullBackOff。
• 容器崩溃：应用启动错误 → CrashLoopBackOff，需检查日志（kubectl logs）。

高级特性

• Init 容器：按顺序运行，全部成功后才启动主容器。
• Sidecar 注入：通过 Admission Controller（如 Istio 的自动注入）动态修改 Pod 配置。