Hang Zhengyang
English ↗

K8s 路线（Manifest 工作机制剖析）

本文补齐两件事：

  1. Kubernetes 基础概念高密度解释；
  2. 物理实体与运行时实体之间的关系图，再映射到 k8s/ 这条手工清单路径。

0. 基础概念速记（高密度）

  • Cluster：K8s 管理边界，一个集群包含控制面与一个或多个工作节点。
  • Node：运行 Pod 的机器（物理机、虚机、或容器化节点）。
  • Pod：最小调度单元；一个 Pod 可含多个容器，共享网络命名空间与卷。
  • Deployment：无状态工作负载控制器；负责副本、滚动更新、自愈。
  • Service (ClusterIP)：稳定虚拟入口；把请求负载到匹配标签的 Pod。
  • Ingress：L7 路由规则对象；必须由 Ingress Controller 执行。
  • ConfigMap / Secret：配置注入对象；前者非敏感，后者敏感。
  • Probe：容器健康探针；readiness 决定接流量，liveness 决定重启。
  • requests/limits：资源请求与上限；影响调度与隔离。
  • etcd：控制面状态数据库；保存对象期望态与元数据。

1. 物理实体分层（你真正“有几台机器”）

从物理/虚拟基础设施看，K8s 至少有以下实体：

  • Control Plane Node(s)
    运行 kube-apiserver、etcd、scheduler、controller-manager。
  • Worker Node(s)
    运行 kubelet、kube-proxy、容器运行时（如 containerd）。
  • 网络平面（CNI + kube-proxy）
    负责 Pod 网络、Service 转发与跨节点连通。

在本地 kind 场景里，这些节点通常表现为 Docker 容器，但逻辑角色不变。

2. 运行时实体分层（对象如何互相作用）

2.1 控制面实体（持续收敛）

  • kube-apiserver：所有对象变更入口（kubectl apply 最终打到这里）。
  • etcd：持久化对象状态。
  • controller-manager：持续对比“期望态 vs 当前态”并修正。
  • scheduler：给 Pending Pod 选节点。

2.2 节点执行实体（把意图变成进程）

  • kubelet：从 API watch 到 Pod 后，调用 runtime 拉镜像并启动容器。
  • 容器运行时：实际创建容器进程。
  • CNI 插件：分配 Pod IP，接入集群网络。

2.3 业务与流量实体（数据面）

  • Deployment -> ReplicaSet -> Pod：工作负载实例链。
  • Service：稳定访问入口，后端是 Pod 集合。
  • Ingress + Ingress Controller：外部 HTTP 流量入口与路由执行层。

3. “实体关系图”一图化理解（文本版）

  1. 你提交 YAML（期望态） -> kube-apiserver。
  2. 对象写入 etcd。
  3. Deployment controller 发现变更 -> 创建/调整 ReplicaSet/Pod。
  4. Scheduler 为 Pod 选 Node。
  5. 目标 Node 的 kubelet 拉镜像并启动容器。
  6. Service 发现 Ready Pod 并加入 endpoint。
  7. Ingress Controller 根据 Ingress 规则把外部流量转发到 Service。

这就是从“声明”到“可访问业务进程”的完整路径。

4. 清单间依赖图（按当前手工路径）

部署顺序来自 k8s/README.md，依赖关系：

  1. nginx-configmap.yaml
    • 提供 edge-proxy 所需 default.conf。
  2. app-deployment.yaml + app-service.yaml
    • 创建 app Pod 与其稳定 Service 入口。
  3. nginx-deployment.yaml + nginx-service.yaml
    • 创建网关 Pod 与其稳定 Service 入口。
  4. ingress.yaml
    • 把 north-south 流量路由到 edge-proxy service。

关键关系：Ingress 不直接到 app Pod，而是先到网关层，再由网关代理至 app-service。

5. 运行时关键参数（为什么这么配）

app-deployment.yaml：

  • replicas: 2：验证多副本行为与 Service 负载分发。
  • readinessProbe/livenessProbe：把“可用”与“存活”分开，避免误判。
  • requests/limits：体现调度约束与资源隔离。
  • imagePullPolicy: IfNotPresent：配合本地镜像加载流程。

nginx-deployment.yaml：

  • ConfigMap + subPath 挂载单文件，保持镜像无侵入。
  • 代理层与业务层解耦，便于独立治理入口策略。

6. 数据面与控制面分离

数据面请求链：

  • Client -> Ingress Controller -> edge-proxy Service -> edge-proxy Pod -> app-service Service -> app-service Pod。

控制面职责：

  • Deployment 控副本与滚动更新；
  • Service 控服务发现与流量分发；
  • Ingress 只表达路由意图，控制器负责执行。

7. 常见失败面（按实体定位）

  1. ImagePullBackOff
    • 节点 runtime 拉不到镜像（镜像未加载/地址不可达）。
  2. 502/连接失败
    • app Pod 未 Ready、Service endpoint 为空、或代理 upstream 配置错误。
  3. kubectl apply/dry-run 报 API 错
    • kubeconfig/context 错误，或 API Server 不可达。

排障顺序建议：

  • 先看控制面连通（context、API server）；
  • 再看对象状态（Deployment/Pod/Service/Ingress）；
  • 最后看数据面链路（port-forward + curl + logs）。

8. 与 Terraform 路径关系

  • k8s/ 路径是对象级真相层：帮助你理解 K8s 原生语义与故障定位。
  • terraform-k8s 是统一交付层：把相同意图放入 IaC 状态机管理。
  • 两者关系是“原生语义基座”与“声明式交付封装”，不是互斥关系。

9. 结论

理解 K8s 的关键不是记命令，而是建立三层心智模型：

  1. 物理实体层：节点、网络、运行时。
  2. 控制面实体层：API、etcd、controller、scheduler。
  3. 业务数据面层：Pod/Service/Ingress 请求路径。

一旦这三层关系清楚，manifest 只是表达手段，排障与设计都会稳定很多。