Kubernetes（K8s）作为云原生核心的算力架构，本质上是 K8s 对计算资源进行抽象、调度、管理和弹性伸缩，从而实现算力的高效利用和按需分配。
K8s 算力架构的核心是将底层异构的物理 / 虚拟算力资源池化，通过声明式 API 定义算力需求，由控制平面智能调度到节点，并持续保障算力供给与业务需求匹配。下面从核心组件、分层逻辑、调度机制、资源模型四个维度，把这个架构讲清楚。
一、K8s 算力架构核心组件（控制平面 + 节点层）
K8s 算力架构分为控制平面（算力大脑） 和节点层（算力执行单元），两者通过 API Server 通信，构成完整的算力管理闭环：
1. 控制平面（算力调度 / 决策核心）
| 组件 | 核心作用（算力相关） |
|---|---|
| API Server | 算力操作的统一入口（创建 Pod、调整副本数、申请资源），所有算力请求都通过 REST API 提交 |
| Scheduler | 算力调度器，核心职责是为新创建的 Pod 匹配最优节点（根据资源需求、节点负载、亲和性等规则） |
| Controller Manager | 包含多个控制器，保障算力状态符合预期：ReplicaSet：维持 Pod 副本数，弹性扩缩容 Deployment：管理无状态应用的算力版本与伸缩 StatefulSet：管理有状态应用的算力分配 HorizontalPodAutoscaler (HPA)：根据 CPU / 内存 / 自定义指标自动扩缩 Pod 数量 |
| ETCD | 存储所有算力相关的状态（节点资源、Pod 资源请求 / 限制、调度规则、伸缩策略），是算力架构的 “数据中心” |
2. 节点层（算力执行载体）
每个节点（物理机 / 虚拟机）是算力的最小物理单元，包含以下核心组件：
| 组件 | 核心作用（算力相关） |
|---|---|
| Kubelet | 节点算力管家：向控制平面上报节点资源（CPU / 内存 / GPU / 磁盘），接收 Pod 调度指令，启动 / 停止 Pod，监控 Pod 资源使用情况 |
| Container Runtime | 容器运行时（Docker/Containerd/CRI-O）：负责容器的创建、销毁，是算力的 “执行引擎”，通过 Cgroups 限制 Pod 的资源使用 |
| Kube-proxy | 负责节点网络规则配置，保障 Pod 间网络通信，不直接管理算力，但算力的网络互通依赖它 |
| CRI/CNI/CSI | 标准化接口： CRI（容器运行时接口）：解耦 Kubelet 与容器运行时 CNI（容器网络接口）：解耦网络与算力 CSI（容器存储接口）：解耦存储与算力 |
二、K8s 算力架构分层逻辑（自底向上）
1. 物理 / 虚拟资源层（算力底座）
- 底层是服务器集群（x86/ARM CPU、GPU/NPU/TPU 加速卡、内存、磁盘、网络），可以是物理机、虚拟机或云服务器（ECS）。
- K8s 不直接管理硬件，而是通过节点的 kubelet 感知节点的总资源和已用资源（如节点总 CPU 8 核、内存 32G，已用 4 核 / 16G）。
2. 资源抽象层（算力标准化）
K8s 将底层硬件资源抽象为可量化、可申请、可限制的资源单位，分为两类：
（1）可调度资源（核心算力资源）
- CPU：单位是 “核”（1 核 = 1 个物理 CPU 核心），也可用毫核（m），1 核 = 1000m（如 500m 表示 0.5 核）。
- 内存：单位是字节（B），常用 Mi（10241024B）、Gi（10241024*1024B）。
- GPU：以 “卡” 为单位（如 nvidia.com/gpu: 1 表示 1 张 NVIDIA GPU 卡），需安装 GPU 插件（NVIDIA Device Plugin）。
自定义资源：如 NPU、FPGA，可通过 Device Plugin 扩展为可调度资源。
（2）不可调度资源（辅助资源） - 磁盘 IO、网络带宽、PID 数量等，通常通过 LimitRange 或自定义策略限制，不参与核心调度。
3. 资源分配层（算力按需分配）
通过 Pod 的 resources 字段定义算力需求，是 K8s 算力分配的核心规则：
apiVersion: v1 kind: Pod metadata: name: cpu-mem-demo spec: containers: - name: app image: nginx resources: requests: # 算力“申请”：调度时Scheduler保证节点有足够资源满足requests cpu: "500m" # 至少需要0.5核CPU memory: "512Mi" # 至少需要512Mi内存 limits: # 算力“限制”：容器最多能使用的资源，超了会被OOM kill或CPU限流 cpu: "1000m" # 最多使用1核CPU memory: "1Gi" # 最多使用1Gi内存- requests：调度依据，Scheduler 只会把 Pod 调度到 “节点剩余资源 ≥ Pod requests” 的节点。
- limits：资源上限，由 Cgroups 强制执行，防止单个 Pod 占用过多算力影响其他应用。
4. 调度与弹性层（算力智能调度）
（1）核心调度流程
（2）弹性伸缩（算力动态调整）
- 水平伸缩（HPA）：根据 CPU / 内存使用率或自定义指标（如 QPS），自动增加 / 减少 Pod 数量，适配算力需求变化。
apiVersion:autoscaling/v2kind:HorizontalPodAutoscalermetadata:name:nginx-hpaspec:scaleTargetRef:apiVersion:apps/v1kind:Deploymentname:nginx-deployminReplicas:2# 最少2个PodmaxReplicas:10# 最多10个Podmetrics:-type:Resourceresource:name:cputarget:type:UtilizationaverageUtilization:70# CPU利用率超过70%时扩容- 垂直伸缩（VPA）：自动调整 Pod 的 requests/limits（如内存不够时调高 limits），适合算力需求不稳定的应用。
- 集群自动伸缩（CA）：当集群内所有节点资源不足时，自动创建新节点；资源空闲时，自动删除节点（云厂商场景常用，如阿里云 ACK、AWS EKS）。
5. 算力隔离与优先级层（算力保障）
- 资源隔离：通过 Linux Cgroups 实现 Pod 级别的 CPU / 内存隔离，防止 “算力抢占”（如一个 Pod 占用 100% CPU 导致其他 Pod 不可用）。
- Pod 优先级（PriorityClass）：为核心应用设置高优先级，节点资源不足时，优先保障高优先级 Pod 的算力，低优先级 Pod 会被驱逐。
- 污点（Taints）和容忍（Tolerations）：实现节点算力的专属化（如给 GPU 节点加污点，只有 AI 应用的 Pod 能容忍，避免普通应用占用 GPU 算力）。
三、K8s 异构算力架构（GPU/NPU/AI 算力）
针对 AI、高性能计算场景，K8s 扩展了异构算力管理能力，核心是 Device Plugin 机制：
- 硬件厂商（NVIDIA、华为昇腾、Intel）提供 Device Plugin，部署在节点上。
- Device Plugin 向 K8s 注册 GPU/NPU 等异构资源（如 nvidia.com/gpu: 2 表示节点有 2 张 GPU 卡）。
- 用户在 Pod 中申请异构资源，K8s 调度时会匹配有对应资源的节点。
spec:containers:-name:ai-trainingimage:tensorflow/tensorflowresources:limits:nvidia.com/gpu:1# 申请1张GPU卡- 进阶方案：K8s 还支持 GPU 分片（如将 1 张 GPU 卡分为 4 份，供 4 个 Pod 使用）、共享 GPU 等精细化算力管理。
四、K8s 算力架构与云原生的结合
- Serverless K8s：如阿里云 ASK、AWS Fargate，用户无需管理节点，只需提交 Pod，K8s 自动分配算力，按 Pod 使用量计费，极致弹性。
- 边缘 K8s：如 K3s、KubeEdge，将 K8s 算力架构下沉到边缘节点，适配边缘场景的低资源、低时延需求。
- 多集群算力调度：通过 Karmada、Cluster API 实现跨集群算力调度，统一管理多地域、多云的算力资源。
总结
K8s 算力架构的核心可归纳为 3 点：
- 资源抽象：将 CPU / 内存 / GPU 等算力资源标准化为可申请、可限制的单位，实现算力池化。
- 智能调度：通过 Scheduler 和控制器，根据资源需求、优先级、亲和性等规则，将算力精准分配到最优节点。
- 弹性伸缩：通过 HPA/CA/VPA 等机制，动态调整 Pod 数量和节点数量，适配算力需求的动态变化。
