12 篇博文 含有标签「Kubernetes」

"Pods are the atomic unit of scheduling in Kubernetes — not containers."

在 Kubernetes 的世界里，工作负载 (Workload) 是你与应用交互的核心抽象。无论你是部署一个无状态的 Web 服务、一个有状态的数据库，还是在每个节点上运行监控 Agent，K8s 都提供了专门的工作负载资源来满足需求。而所有这些工作负载的基础，都建立在 Pod 之上。

本文将从 Pod 的本质出发，逐层深入解析 Kubernetes 中五大核心工作负载资源的设计理念、编排策略与最佳实践，帮助你在架构选型时做出正确的决策。

一、Pod：K8s 的原子调度单元​

1.1 为什么 Pod 是最小部署单元而非容器​

许多初学者会困惑：既然 Docker 已经有了容器概念，为什么 Kubernetes 还要引入 Pod？答案在于 "超亲密容器"（Hyper-privileged Containers） 的设计哲学。

在现实世界中，一个应用往往不是孤立运行的。例如：

• 一个 Web 服务器需要配合一个日志采集 Sidecar
• 一个主进程需要配合一个健康检查辅助进程
• 一个数据管道需要同时运行 ingest 和 transform 两个紧密协作的进程

这些进程需要共享网络命名空间（可以通过 localhost 互相通信）、共享存储卷（可以读写同一份数据），并且需要作为一个原子单元被调度到同一个节点上。Pod 正是为了解决这一需求而诞生的。

1.2 Pod 的设计理念​

Pod 的设计围绕三个核心能力展开：

Sidecar 模式 是 Pod 多容器设计中最经典的模式。例如，Istio 服务网格通过在每个 Pod 中注入一个 Envoy Sidecar 代理来实现流量管理、安全通信和可观测性，而无需修改应用代码。

1.3 Pod 的 YAML 结构详解​

下面是一个完整的 Pod YAML 示例，每个字段都附有详细注释：

apiVersion: v1          # API 版本，Pod 属于核心 v1 组
kind: Pod               # 资源类型
metadata:
  name: nginx-pod       # Pod 名称，在同一个 Namespace 内必须唯一
  namespace: default    # 命名空间，不指定则使用 default
  labels:               # 标签，用于选择器和组织资源
    app: nginx
    tier: frontend
  annotations:          # 注解，用于存储非标识性的元数据
    description: "A sample nginx pod"
spec:
  # --- 重启策略 ---
  restartPolicy: Always  # 容器退出后的重启策略：Always / OnFailure / Never

  # --- 节点选择 ---
  nodeSelector:          # 通过标签选择节点
    disktype: ssd
  tolerations:           # 容忍度，用于调度到有特定 Taint 的节点
  - key: "dedicated"
    operator: "Equal"
    value: "gpu"
    effect: "NoSchedule"

  # --- 容器定义 ---
  containers:
  - name: nginx          # 容器名称
    image: nginx:1.27    # 镜像地址（含标签）
    imagePullPolicy: IfNotPresent  # 镜像拉取策略：Always / IfNotPresent / Never
    ports:
    - containerPort: 80  # 容器暴露的端口（仅声明，不自动发布）
      protocol: TCP
    resources:           # 资源请求与限制
      requests:          # 调度时保证的最小资源量
        cpu: "100m"      # 100 millicores = 0.1 核
        memory: "128Mi"
      limits:            # 容器可使用的最大资源量
        cpu: "500m"
        memory: "256Mi"
    env:                 # 环境变量
    - name: ENVIRONMENT
      value: "production"
    - name: DB_PASSWORD
      valueFrom:
        secretKeyRef:
          name: db-secret
          key: password
    volumeMounts:        # 挂载存储卷
    - name: nginx-data
      mountPath: /usr/share/nginx/html
    livenessProbe:       # 存活探针
      httpGet:
        path: /healthz
        port: 80
      initialDelaySeconds: 15
      periodSeconds: 10
    readinessProbe:      # 就绪探针
      httpGet:
        path: /ready
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 5
    startupProbe:        # 启动探针（K8s 1.18+）
      httpGet:
        path: /startup
        port: 80
      failureThreshold: 30  # 最多失败 30 次（即最多等待 300 秒）

  # --- Init 容器 ---
  initContainers:
  - name: init-db
    image: busybox:1.36
    command: ['sh', '-c', 'until nslookup db-service; do echo waiting for db; sleep 2; done']

  # --- 存储卷 ---
  volumes:
  - name: nginx-data
    persistentVolumeClaim:
      claimName: nginx-pvc  # 引用 PVC
  - name: config-volume
    configMap:
      name: nginx-config    # 引用 ConfigMap

  # --- DNS 配置 ---
  dnsPolicy: ClusterFirst  # DNS 策略：ClusterFirst / Default / ClusterFirstWithHostNet / None

1.4 Pod 生命周期​

Pod 从创建到终止会经历一系列状态变化。理解这些状态对于排查问题至关重要。

各状态说明：

1.5 Probe 机制：Liveness / Readiness / Startup​

Kubernetes 通过三种探针来监控容器的健康状态：

探针支持四种检测方式：

• httpGet：向容器发送 HTTP GET 请求，2xx/3xx 状态码视为成功。
• tcpSocket：尝试与容器的指定端口建立 TCP 连接。
• exec：在容器内执行命令，返回码为 0 视为成功。
• grpc（v1.24+ 稳定）：使用 gRPC 健康检查协议，服务状态为 SERVING 视为成功。

二、Deployment：无状态应用的编排之王​

Deployment 是 Kubernetes 中最常用的工作负载资源，专门用于管理无状态应用。它提供了声明式更新、滚动发布和回滚等生产级特性。

2.1 ReplicaSet 与 Deployment 的关系​

Deployment → 管理 → ReplicaSet → 管理 → Pod

ReplicaSet (RS) 是下一层的控制器，负责确保指定数量的 Pod 副本始终在运行。而 Deployment 是更高层的抽象，它在 ReplicaSet 之上增加了版本管理和滚动更新能力。

2.2 滚动更新（Rolling Update）策略​

Deployment 支持两种更新策略：

RollingUpdate 通过两个关键参数控制更新节奏：

• maxSurge：更新期间允许超出期望副本数的最大 Pod 数（可以是绝对数或百分比）。
• maxUnavailable：更新期间允许不可用的最大 Pod 数（可以是绝对数或百分比）。

2.3 回滚机制（Rollback）​

Deployment 的每一次更新都会创建一个新的 ReplicaSet，并保留历史版本（由 revisionHistoryLimit 控制，默认为 10）。这使得回滚操作变得极其简单：

# 查看部署历史
kubectl rollout history deployment/nginx-deployment

# 回滚到上一个版本
kubectl rollout undo deployment/nginx-deployment

# 回滚到指定版本
kubectl rollout undo deployment/nginx-deployment --to-revision=2

2.4 完整 YAML 示例​

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: default
  labels:
    app: nginx
spec:
  replicas: 3                          # 期望的 Pod 副本数
  revisionHistoryLimit: 10             # 保留的历史 ReplicaSet 数量
  strategy:
    type: RollingUpdate                # 更新策略：RollingUpdate / Recreate
    rollingUpdate:
      maxSurge: 1                      # 滚动更新时最多多创建 1 个 Pod
      maxUnavailable: 0                # 滚动更新时最多允许 0 个 Pod 不可用
  selector:
    matchLabels:                       # 必须与 Pod template 的 labels 匹配
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.27
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 500m
            memory: 256Mi
        livenessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 10
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 5

三、StatefulSet：有状态应用的首选​

StatefulSet 专为需要稳定网络标识和持久存储的有状态应用设计，如数据库（MySQL、PostgreSQL）、消息队列（Kafka、RabbitMQ）和分布式存储系统（Elasticsearch、etcd）。

3.1 与 Deployment 的核心区别​

3.2 有序部署/扩展/删除​

StatefulSet 的核心特性之一是有序性 (Ordinality)。当创建或扩展 StatefulSet 时，Pod 会按照序号从 0 开始依次创建，且只有前一个 Pod 进入 Running 且 Ready 状态后，才会创建下一个 Pod。

3.3 稳定的网络标识和持久存储​

StatefulSet 为每个 Pod 提供以下稳定性保证：

• 稳定的网络标识：Pod 名称格式为 <statefulset-name>-<ordinal>（如 mysql-0），且关联的 Headless Service 会为每个 Pod 创建一个稳定的 DNS 记录：<pod-name>.<headless-service>.<namespace>.svc.cluster.local。
• 持久存储：通过 volumeClaimTemplates，StatefulSet 会为每个 Pod 自动创建独立的 PVC。即使 Pod 被重新调度到其他节点，只要绑定了相同的 PVC，数据就不会丢失。

3.4 完整 YAML 示例​

apiVersion: v1
kind: Service                     # Headless Service，用于稳定的网络标识
metadata:
  name: mysql
  labels:
    app: mysql
spec:
  clusterIP: None                # Headless Service：不分配 ClusterIP
  selector:
    app: mysql
  ports:
  - port: 3306
    targetPort: 3306
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: mysql             # 必须指向关联的 Headless Service
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:8.0
        ports:
        - containerPort: 3306
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-secret
              key: root-password
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
        livenessProbe:
          exec:
            command: ["mysqladmin", "ping", "-h", "localhost"]
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          exec:
            command: ["mysql", "-h", "localhost", "-e", "SELECT 1"]
          initialDelaySeconds: 5
          periodSeconds: 5
  volumeClaimTemplates:          # 为每个 Pod 自动创建独立的 PVC
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      storageClassName: standard
      resources:
        requests:
          storage: 10Gi

四、DaemonSet：节点级守护进程​

DaemonSet 确保集群中的每个（或特定）节点上都运行一个 Pod 副本。当节点加入集群时，DaemonSet 会自动为其创建 Pod；当节点移除时，这些 Pod 也会被自动回收。

4.1 典型使用场景​

4.2 滚动更新策略​

DaemonSet 支持三种更新策略：

4.3 完整 YAML 示例​

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-exporter
  namespace: monitoring
  labels:
    app: node-exporter
spec:
  selector:
    matchLabels:
      app: node-exporter
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1           # 最多允许 1 个节点上的 Pod 不可用
  template:
    metadata:
      labels:
        app: node-exporter
    spec:
      hostNetwork: true           # 使用宿主机网络（监控场景常见）
      hostPID: true               # 使用宿主机 PID 命名空间
      tolerations:                # 容忍所有 Taint，确保在所有节点上运行
      - operator: Exists
      containers:
      - name: node-exporter
        image: prom/node-exporter:v1.8.0
        args:
        - "--web.listen-address=:9100"
        - "--path.procfs=/host/proc"
        - "--path.sysfs=/host/sys"
        ports:
        - containerPort: 9100
          hostPort: 9100
        volumeMounts:
        - name: proc
          mountPath: /host/proc
          readOnly: true
        - name: sys
          mountPath: /host/sys
          readOnly: true
        resources:
          limits:
            cpu: 200m
            memory: 100Mi
      volumes:
      - name: proc
        hostPath:
          path: /proc
      - name: sys
        hostPath:
          path: /sys

五、Job 与 CronJob：任务编排​

5.1 一次性任务（Job）​

Job 用于运行一次性任务，确保 Pod 成功执行完毕后终止。Job 会持续跟踪 Pod 的完成状态，并在失败时根据重试策略重新创建 Pod。

核心字段说明：

5.2 并行任务（Parallelism + Completions）​

Job 的 parallelism 和 completions 字段可以组合出不同的执行模式：

5.3 定时任务（CronJob）​

CronJob 基于 Cron 表达式来定期创建 Job。它的调度规则与 Linux 的 crontab 基本一致，格式为：

# ┌───────────── 分钟 (0 - 59)
# │ ┌───────────── 小时 (0 - 23)
# │ │ ┌───────────── 日 (1 - 31)
# │ │ │ ┌───────────── 月 (1 - 12)
# │ │ │ │ ┌───────────── 星期 (0 - 6, 0 = 周日)
# │ │ │ │ │
# * * * * *

apiVersion: batch/v1
kind: CronJob
metadata:
  name: database-backup
spec:
  schedule: "0 2 * * *"              # 每天凌晨 2 点执行
  concurrencyPolicy: Forbid          # 禁止并发运行
  successfulJobsHistoryLimit: 3      # 保留最近 3 个成功的 Job
  failedJobsHistoryLimit: 1          # 保留最近 1 个失败的 Job
  jobTemplate:
    spec:
      backoffLimit: 2
      activeDeadlineSeconds: 3600    # 超过 1 小时则标记为失败
      template:
        spec:
          containers:
          - name: backup
            image: postgres:16
            command:
            - /bin/bash
            - -c
            - pg_dump -h db-service -U $DB_USER -d $DB_NAME > /backup/$(date +%Y%m%d).sql
            env:
            - name: DB_USER
              valueFrom:
                secretKeyRef:
                  name: db-secret
                  key: username
            - name: DB_NAME
              value: "myapp"
            volumeMounts:
            - name: backup-data
              mountPath: /backup
          restartPolicy: Never        # Job 必须设置为 Never 或 OnFailure
          volumes:
          - name: backup-data
            persistentVolumeClaim:
              claimName: backup-pvc

5.4 Job 完整 YAML 示例​

apiVersion: batch/v1
kind: Job
metadata:
  name: data-migration
spec:
  completions: 1                     # 需要成功完成 1 次
  parallelism: 1                     # 同时运行 1 个 Pod
  backoffLimit: 3                    # 最多重试 3 次
  activeDeadlineSeconds: 600         # 超时 10 分钟
  ttlSecondsAfterFinished: 86400     # 完成后 24 小时自动清理
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: migrate
        image: myapp:v2.0
        command: ["python", "manage.py", "migrate"]
        env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: app-secrets
              key: database-url

六、ReplicaSet / ReplicationController（简述）​

ReplicationController (RC)​

ReplicationController 是 Kubernetes 最早的副本管理机制，用于确保指定数量的 Pod 副本始终运行。它已被 ReplicaSet 取代，目前仅存在于 API 中以保持向后兼容。

ReplicaSet (RS)​

ReplicaSet 是 ReplicationController 的升级版，主要改进是支持基于集合的标签选择器（Set-based Selector），使得选择逻辑更加灵活。

七、工作负载选择决策树​

面对不同的业务需求，如何选择合适的工作负载资源？以下决策树可以帮助你快速做出判断：

快速参考表​

八、本章小结​

本文从 Pod 的本质出发，系统地解析了 Kubernetes 中五大核心工作负载资源：

1. Pod 是 Kubernetes 的原子调度单元，通过共享网络和存储实现了"超亲密容器"的协作模式。理解 Pod 的生命周期和探针机制是排查问题的基础。

2. Deployment 是无状态应用的首选，通过 ReplicaSet 实现版本管理，支持零停机的滚动更新和一键回滚。

3. StatefulSet 为有状态应用提供了稳定的网络标识、独立的持久存储和有序的部署/删除策略，是运行数据库和消息队列等场景的最佳选择。

4. DaemonSet 确保每个节点运行一个 Pod 副本，是部署基础设施组件（日志、监控、网络插件）的标准方式。

5. Job 与 CronJob 覆盖了一次性任务和定时任务的需求，支持灵活的并行度和重试策略。

选择工作负载资源时，核心判断依据是：应用是否有状态、是否需要长期运行、是否需要在每个节点上运行。掌握这些工作负载的特性与适用场景，是构建可靠 Kubernetes 应用的基石。

在下一篇文章中，我们将深入探讨 Kubernetes 的 Service 与网络模型，解析 ClusterIP、NodePort、LoadBalancer 和 Ingress 的工作原理与选型策略。

参考文档​

本文内容基于 Kubernetes 官方文档校验，以下为核心参考链接：

• Pod Lifecycle — Pod 生命周期与状态
• Configure Liveness, Readiness and Startup Probes — 探针配置
• Deployments — Deployment 文档
• StatefulSets — StatefulSet 文档
• DaemonSets — DaemonSet 文档
• Jobs — Job 文档
• CronJobs — CronJob 文档
• Kubernetes v1.34 Release Notes — v1.34 版本发布说明

"如果你觉得 Kubernetes 太复杂，那是因为它解决的问题本身就很复杂。"

在云原生（Cloud Native）的世界里，Kubernetes（简称 K8s）已经从"可选技能"变成了"基础设施常识"。无论你是后端工程师、DevOps 工程师，还是架构师，理解 K8s 的设计思想和运行机制，都是构建现代分布式系统的必修课。

然而，K8s 的学习曲线之陡峭也是出了名的。官方文档动辄数千页，概念繁多且相互关联，很容易让人陷入"见树木不见森林"的困境。

本系列文章将从架构设计出发，逐层深入到核心概念、工作负载管理、网络模型、存储体系、调度策略与安全机制，帮助你构建一套完整、系统的 K8s 认知框架。本文作为系列的第零章，将聚焦于最根本的问题：Kubernetes 是什么？它是如何设计的？它由哪些核心部分组成？

一、为什么需要 Kubernetes​

1.1 容器化演进的必然之路​

要理解 K8s 存在的意义，我们需要先回顾应用部署方式的演进历程：

物理机时代，一个应用独占一台服务器，资源浪费严重。为了提高利用率，我们开始在同一个物理机上部署多个应用，但随之而来的是依赖冲突、端口争抢、一个应用崩溃拖垮整台机器等问题。

虚拟机时代，Hypervisor（如 VMware、KVM）在物理机上虚拟出多个独立的操作系统实例，实现了良好的隔离。但虚拟机本身就很重——一个 VM 动辄几个 GB，启动需要数分钟，而且携带了完整的 Guest OS，大量资源被浪费在运行重复的系统服务上。

容器时代，Docker 横空出世。容器共享宿主机的内核，不需要 Guest OS，一个镜像通常只有几十 MB，启动只需毫秒级。容器通过 Namespace 实现视图隔离，通过 Cgroups 实现资源限制，在轻量和隔离之间找到了一个绝佳的平衡点。

但容器解决的是**"如何打包和运行应用"的问题，却没有解决"如何管理成百上千个容器"**的问题。当你的应用从 3 个容器扩展到 3000 个，跨越几十台机器时，以下问题接踵而至：

• 哪个容器应该运行在哪台机器上？
• 容器挂了谁来重启？机器挂了谁来迁移？
• 如何实现滚动更新而不中断服务？
• 如何让前端服务发现后端服务的地址？
• 如何让外部流量均匀地分发到多个实例？

这就是 Kubernetes 登场的时刻。

1.2 K8s 解决的核心问题​

Kubernetes 作为一个容器编排平台（Container Orchestration Platform），本质上解决的是一个大规模自动化管理的问题。它将运维人员从手工操作中解放出来，通过声明式配置和自动化控制循环，实现了：

• 自动部署与回滚：声明期望状态，K8s 负责将实际状态趋近期望状态
• 服务发现与负载均衡：内置 DNS 和 Service 机制，无需外部注册中心
• 自动扩缩容：根据 CPU/内存/自定义指标自动调整实例数量
• 自我修复：容器崩溃自动重启，节点故障自动迁移
• 滚动更新与蓝绿部署：零停机更新应用

1.3 K8s 的设计哲学​

理解 K8s 的设计哲学，比记住一百个命令更有价值。K8s 的三个核心设计理念贯穿了它的每一个组件：

声明式（Declarative）而非命令式（Imperative）

不可变基础设施（Immutable Infrastructure）

K8s 中的容器镜像一旦构建就不应该被修改。需要更新时，你应该构建新镜像、创建新版本，而不是 SSH 进容器里改配置。这与传统"登录服务器打补丁"的运维方式截然不同。

最终一致性（Eventual Consistency）

K8s 不保证你的请求立即生效，但保证系统最终会收敛到期望状态。这种设计牺牲了即时性，换取了极高的可靠性和容错能力。即使你同时提交了多个冲突的变更，系统也能通过控制循环最终达到一个一致的状态。

二、K8s 整体架构​

Kubernetes 采用经典的主从架构（Master-Worker Architecture），分为**控制面（Control Plane）和数据面（Data Plane）**两个层级。理解这两个层面的职责划分，是理解 K8s 一切行为的基础。

2.1 架构全景图​

2.2 控制面组件详解​

控制面是 K8s 集群的"大脑"，负责全局决策和集群状态的维护。在生产环境中，为了保证高可用，控制面组件通常部署在多个独立的 Master 节点上。

kube-apiserver：集群的统一入口​

kube-apiserver 是整个 K8s 系统的唯一入口。所有组件——无论是内部的 Scheduler、Controller，还是外部的 kubectl、CI/CD Pipeline——都通过 API Server 进行通信。

API Server 本身是无状态的，它可以水平扩展。所有的状态数据都存储在 etcd 中。

etcd：集群的"真相之源"​

etcd 是一个分布式的、一致的键值存储系统，基于 Raft 共识算法实现。它是 K8s 集群的唯一数据源（Single Source of Truth）——集群中所有的一切：节点信息、Pod 状态、配置数据、Secret……全部存储在 etcd 中。

kube-scheduler：调度决策者​

当你创建一个 Pod 时，API Server 只是将这个 Pod 的信息记录到了 etcd 中——此时 Pod 还处于 Pending 状态，因为它还没有被分配到任何节点上。Scheduler 的职责就是为每个未调度的 Pod 选择一个最合适的节点。

调度过程分为三个阶段：

1. 过滤（Filtering）：排除不满足条件的节点（资源不足、端口冲突、污点容忍不匹配等）
2. 打分（Scoring）：对剩余节点进行优先级打分（亲和性、镜像本地性、负载均衡等），选择得分最高的节点
3. 绑定（Binding）：将调度决策应用到集群，将 Pod 与选定节点进行绑定

kube-controller-manager：状态守护者​

Controller Manager 运行着多个控制器（Controller），每个控制器都是一个独立的控制循环（Reconciliation Loop），负责监控集群的某一部分状态，并持续将其推向期望状态。

常见的内置控制器包括：

while true:
    实际状态 = 从 API Server 获取当前状态
    期望状态 = 从配置中获取期望状态
    if 实际状态 != 期望状态:
        执行调谐操作（创建/删除/更新）
    sleep(一段时间)

cloud-controller-manager：云平台桥梁​

如果你在 AWS、GCP、Azure 等云平台上运行 K8s，CCM 负责与云厂商的 API 交互，管理云平台特有的资源：

• Node Controller：调用云 API 查询节点地址和状态
• Route Controller：配置云平台的路由规则
• Service Controller：创建云平台的负载均衡器（如 AWS ELB）

CCM 的引入使得 K8s 的核心代码不需要耦合任何特定云厂商的 SDK，实现了云平台无关性。

2.3 数据面组件详解​

数据面（也叫 Worker Node）是实际运行应用工作负载的地方。每个 Worker 节点上运行着三个核心组件：

kubelet：节点上的"车间主任"​

kubelet 是运行在每个 Worker 节点上的代理，它的职责是：

1. 接收指令：从 API Server 获取分配到本节点的 Pod 规格（Spec）
2. 管理容器：通过 CRI（Container Runtime Interface）调用容器运行时，创建和管理 Pod 中的容器
3. 健康检查：定期执行 Liveness Probe、Readiness Probe 和 Startup Probe
4. 状态上报：将节点和 Pod 的状态信息上报给 API Server

你可以把 kubelet 理解为一个"车间主任"——它不制定生产计划（那是 Scheduler 的事），但负责确保分配到自己车间的生产任务被正确执行。

kube-proxy：网络规则的维护者​

kube-proxy 运行在每个节点上，负责维护节点的网络规则，实现 Service 的负载均衡和网络代理。它通过操作 iptables 或 IPVS 规则，将访问 Service 的流量转发到后端的 Pod。

简单来说，当你访问一个 Service 的 ClusterIP 时，kube-proxy 维护的规则会将流量自动转发到该 Service 关联的某个 Pod 上。

Container Runtime：容器的实际执行者​

kubelet 本身并不直接运行容器，而是通过 CRI（Container Runtime Interface） 标准接口调用容器运行时。常见的 CRI 兼容运行时包括：

• containerd：目前最主流的选择，Docker 的核心运行时组件独立出来的版本
• CRI-O：专为 Kubernetes 设计的轻量级运行时，由 Red Hat 主导
• Kata Containers：提供虚拟机级别的隔离，适用于安全要求极高的场景

三、核心概念模型​

Kubernetes 中的一切都被抽象为 API 对象（API Object）。理解这些对象及其关系，是使用 K8s 的基础。

3.1 API 对象与声明式配置​

在 K8s 中，你不需要告诉系统"如何做"，而是描述"你要什么"。你通过提交 YAML（或 JSON）文件来定义 API 对象，API Server 会将你的声明持久化到 etcd，然后各个控制器会持续工作，确保实际状态趋近于你声明的期望状态。

3.2 YAML 配置结构解析​

每个 K8s API 对象的 YAML 配置都遵循以下结构：

apiVersion: apps/v1          # API 版本，标识对象属于哪个 API 组
kind: Deployment             # 对象类型，K8s 内置了几十种对象类型
metadata:                    # 对象的元数据（名称、标签、注解等）
  name: nginx-deployment
  namespace: default
  labels:
    app: nginx
    tier: frontend
spec:                        # 对象的规格（期望状态）
  replicas: 3                # 期望运行 3 个 Pod 副本
  selector:                  # 选择器，用于关联管理的 Pod
    matchLabels:
      app: nginx
  template:                  # Pod 模板，定义如何创建 Pod
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 500m
            memory: 512Mi

3.3 API 对象层级关系​

K8s 的 API 对象之间存在着清晰的层级关系。上层对象管理下层对象，形成了一个从粗粒度到细粒度的管理链。

四、一次请求的完整旅程​

理论讲了不少，现在让我们通过一个具体的场景来串联所有知识：当你执行 kubectl apply -f nginx-deployment.yaml 时，K8s 内部到底发生了什么？

4.1 完整时序图​

4.2 控制循环（Reconciliation Loop）详解​

时序图展示了一次性的创建流程，但 K8s 的真正威力在于其持续运行的控制循环。让我们深入理解这个机制：

第一步：感知变化（Watch 机制）

K8s 的各个组件并不是定期轮询 API Server，而是通过基于 HTTP 长连接的 Watch 机制 来感知变化。当你创建、修改或删除一个对象时，API Server 会通过 Watch 通道将事件推送给所有订阅者。事件类型包括：

• ADDED：新对象被创建
• MODIFIED：对象被更新
• DELETED：对象被删除

这种基于事件驱动的设计，比轮询更高效，延迟更低。

第二步：计算差异（Diff）

控制器收到事件后，会将实际状态与期望状态进行对比。例如，Deployment Controller 发现期望的副本数是 3，但当前只有 2 个 Pod 在运行。

第三步：执行调谐（Reconcile）

控制器计算出需要执行的操作后，会通过 API Server 发起调谐请求。在上面的例子中，Deployment Controller 会创建一个新的 ReplicaSet，ReplicaSet Controller 会创建一个新的 Pod。

第四步：重复

整个过程是一个无限循环。即使某个操作失败了，下一轮循环也会再次尝试。这就是 K8s 实现自愈能力的根本原因。

五、本章小结与下一篇预告​

本文作为 Kubernetes 全景解析系列的第零章，我们从宏观视角梳理了 K8s 的全貌：

掌握这些基础知识后，你将不再对 K8s 感到迷茫——它的每一个行为都可以追溯到上述架构和机制中。

下一篇，我们将深入 K8s 的工作负载管理： 从 Pod 的生命周期到 Deployment、StatefulSet、DaemonSet 等工作负载控制器的使用场景与最佳实践。理解了工作负载，你就能真正开始在 K8s 上部署和运行应用了。

系列导航

章节	主题	状态
0	架构设计与核心概念	✅ 已发布
1	工作负载与 Pod 生命周期深度解析	✅ 已发布
2	网络模型与服务发现全链路解析	✅ 已发布
3	存储体系与配置管理深度剖析	✅ 已发布
4	调度器、资源管理与弹性伸缩	✅ 已发布
5	安全体系与可观测性全景	✅ 已发布
6	生产级微服务架构实战	✅ 已发布
7	有状态应用与 Operator 模式实战	✅ 已发布

参考文档​

本文内容基于 Kubernetes 官方文档校验，以下为核心参考链接：

• Kubernetes Cluster Architecture — 集群架构概览
• Kubernetes Components — 核心组件说明
• kube-proxy (optional) — kube-proxy 可选组件说明
• Scheduling Framework — 调度框架
• Container Runtimes — 容器运行时
• Kubernetes v1.34 Release Notes — v1.34 版本发布说明