2. 核心概念：容器运行时（Docker/containerd）、Kubernetes Deployment、Pod、Node、集群资源池

在开始集群升级调优之前，必须统一团队对底层核心概念的认知。本章将逐一拆解容器运行时、Deployment、Pod、Node 与集群资源池这五个关键实体，并阐明它们在升级流程中的角色与约束。

2.1 容器运行时：Docker 与 containerd

容器运行时是负责拉取镜像、创建容器、管理容器生命周期的底层组件。Kubernetes 通过 CRI（Container Runtime Interface）与运行时解耦。当前主流运行时为 containerd（自 Kubernetes v1.24 起弃用 Docker Shim）和 Docker（通过 cri-dockerd 适配器）。

2.2 Pod：最小的调度与升级单元

Pod 是 Kubernetes 中可创建和部署的最小计算单元。一个 Pod 包含一个或多个容器（共享网络栈、存储卷）。在升级场景中，Pod 是 滚动更新 的直接操作对象。

• 不可变基础设施： 升级时不原地修改 Pod，而是创建新 Pod 替换旧 Pod。
• 生命周期钩子： preStop 与 postStart 可用于优雅排空与就绪检查。
• Pod 安全策略： 升级期间需确保新 Pod 通过 PSS（Pod Security Standards）校验。

2.3 Deployment：声明式更新引擎

Deployment 是管理 Pod 副本集的控制器，提供声明式更新、回滚、扩缩容能力。在集群升级中，Deployment 的 滚动更新策略 直接决定升级速度与业务连续性。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1          # 允许超出期望副本数的最大 Pod 数
      maxUnavailable: 0    # 升级期间允许不可用的最大 Pod 数
  template:
    spec:
      containers:
      - name: app
        image: myapp:2.0.0
        resources:
          requests:
            cpu: "500m"
            memory: "512Mi"
          limits:
            cpu: "1"
            memory: "1Gi"

2.4 Node：承载 Pod 的物理/虚拟节点

Node 是集群中的工作节点，运行 kubelet、kube-proxy 及容器运行时。Node 的状态（Ready/NotReady）与资源水位（CPU、内存、磁盘、PID）直接决定 Pod 能否被调度。

• 节点排空（drain）： 升级 Node 前需执行 kubectl drain 驱逐 Pod，确保业务无感。
• 节点标签与污点： 通过 nodeSelector 或 taints/tolerations 控制 Pod 分布，避免升级期间关键 Pod 被调度到待升级节点。
• 系统预留资源： --system-reserved 与 --kube-reserved 参数为系统组件预留资源，防止 Pod 挤占导致节点不稳定。

2.5 集群资源池：容量规划的数学基础

集群资源池是所有 Node 可分配资源的总和。升级期间，由于节点排空与滚动更新，实际可用资源会动态变化。容量规划的核心是确保资源池在升级过程中始终满足业务 SLO。

2.6 概念关系总览

下图展示了容器运行时、Pod、Deployment、Node 与集群资源池之间的层级关系与升级交互路径。

2.7 升级视角下的概念协同

在集群升级过程中，五个核心概念形成以下协同链条：

1. 资源池评估： 计算当前集群可分配资源总量，确定升级窗口内可同时排空的节点数。
2. Node 排空： 逐节点执行 kubectl drain，将 Pod 迁移至其他 Node。
3. Deployment 滚动更新： 利用 maxSurge 与 maxUnavailable 控制 Pod 替换节奏，确保业务不降级。
4. Pod 重建： 新 Pod 调度到可用 Node，使用新版本容器镜像与运行时配置。
5. 运行时升级： 在 Node 层面升级 containerd/Docker 版本，重启 kubelet 使配置生效。