算力调度平台配置与GPU资源编排实战 - 第3节
Pod：算力的最小单元
Pod 是 Kubernetes 里最小的调度单位。说白了，它就是一个或多个容器的“合租屋”。
我刚开始接触 K8s 时，总觉得 Pod 有点多余——直接用容器不就好了？后来在项目中部署一个日志采集器，需要跟业务容器共享网络栈，我才明白 Pod 的设计有多巧妙。
Pod 的核心特性
- 共享网络：同一个 Pod 里的容器，共用同一个 IP 和端口空间。它们通过 localhost 就能互相通信。
- 共享存储：可以挂载同一个 Volume，实现数据交换。
- 生命周期一致：Pod 里的容器要么一起启动，要么一起销毁。
重要：Pod 是“临时”的。它可能因为节点故障、资源不足、更新调度等原因被销毁重建。不要把 Pod 当成持久化实体来设计。
Pod 的典型配置
apiVersion: v1
kind: Pod
metadata:
name: my-app-pod
labels:
app: my-app
spec:
containers:
- name: app-container
image: nginx:1.21
ports:
- containerPort: 80
resources:
requests:
memory: "256Mi"
cpu: "250m"
limits:
memory: "512Mi"
cpu: "500m"嗯，这里要注意 requests 和 limits 的区别。requests 是“我至少要这么多”，limits 是“我最多只能用这么多”。我在生产环境里见过有人把 limits 设得特别大，结果节点资源被某个 Pod 吃光，其他 Pod 全挂了。
我的习惯：requests 和 limits 的比例控制在 1:2 以内。比如 requests 给 256Mi，limits 给 512Mi。这样既保证资源够用，又不会浪费。
Node：算力的物理载体
Node 就是集群里的工作节点。它可以是物理机，也可以是虚拟机。每个 Node 上都运行着 kubelet、kube-proxy 和容器运行时（比如 Docker 或 containerd）。
你想想看，Pod 是“租客”，Node 就是“房子”。房子不够大，租客再多也住不下。
Node 的状态管理
| 状态 | 含义 | 常见原因 |
|---|---|---|
| Ready | 节点正常，可以调度 Pod | — |
| NotReady | 节点异常，无法调度 | kubelet 挂了、网络不通、磁盘满 |
| DiskPressure | 磁盘空间不足 | 日志没清理、镜像太多 |
| MemoryPressure | 内存紧张 | Pod 内存超配严重 |
我曾经遇到过 DiskPressure 导致整个节点上的 Pod 被驱逐。排查后发现是日志轮转没配好，一个容器一天写了 50GB 日志。从那以后，我每个 Pod 都会配日志轮转和 Volume 大小限制。
Namespace：逻辑隔离的艺术
Namespace 是 Kubernetes 里的“虚拟集群”。同一个集群里可以创建多个 Namespace，每个 Namespace 里的资源是相互隔离的。
为什么会需要 Namespace？我举个例子：你有一个开发环境、一个测试环境、一个生产环境。如果所有 Pod 都混在一起，名字冲突不说，权限管理也乱成一锅粥。
Namespace 的典型用法
- 环境隔离：dev、test、prod 各一个 Namespace
- 团队隔离：每个团队一个 Namespace，互不干扰
- 资源配额：给每个 Namespace 设置 CPU、内存上限
# 创建 Namespace
kubectl create namespace dev
# 在 Namespace 里创建 Pod
kubectl run nginx --image=nginx -n dev
# 查看 Namespace 里的资源
kubectl get pods -n dev我建议：永远不要在生产环境里使用 default Namespace。哪怕只有一个项目，也建一个专用的 Namespace。这样后续扩容、迁移、审计都方便得多。
Controller Manager：集群的“大脑”
Controller Manager 是 Kubernetes 控制平面的核心组件。它负责运行各种控制器，确保集群的实际状态跟用户期望的状态一致。
说白了，你告诉 K8s“我要 3 个 Nginx Pod”，Controller Manager 就会盯着，少了就补，多了就删，坏了就重启。
常见的控制器
| 控制器 | 作用 | 适用场景 |
|---|---|---|
| ReplicaSet | 保证指定数量的 Pod 运行 | 无状态应用 |
| Deployment | 管理 ReplicaSet，支持滚动更新 | Web 服务、API 服务 |
| StatefulSet | 管理有状态应用，保证 Pod 身份稳定 | 数据库、消息队列 |
| DaemonSet | 每个 Node 上运行一个 Pod | 日志采集、监控代理 |
| Job | 运行一次性任务 | 数据迁移、批处理 |
核心逻辑：Controller Manager 通过“控制循环”工作。它不断从 API Server 获取期望状态，对比实际状态，然后执行操作让两者一致。这个循环每秒跑很多次，所以集群能快速响应变化。
知识体系结构图
总结一下：Controller Manager 是大脑，Namespace 是隔离墙，Node 是物理资源，Pod 是运行单元。这四个概念构成了 Kubernetes 调度的基础骨架。我在做算力调度时，80% 的问题都能在这四个概念里找到根因。
避坑指南：刚上手时别急着搞复杂的调度策略。先把 Pod 的 requests/limits 配好，把 Namespace 划分清楚，把 Controller Manager 的日志看明白。基础打牢了，后面学什么都快。