Kubernetes NUMA 感知调度优化：让你的应用跑得飞起！🚀
大家好，我是你们的老朋友，江湖人称“代码诗人”的程序猿一枚。今天咱们来聊聊一个让 Kubernetes 应用性能飙升的秘密武器：NUMA 感知调度！
想象一下，你辛辛苦苦写了一个高性能应用，结果部署到 Kubernetes 上，性能却不尽人意，是不是感觉像精心打扮准备去约会，结果发现对象放了你鸽子？ 💔 别担心，今天这堂课，就是教你如何避免这种悲剧，让你的应用在 Kubernetes 集群中也能跑得风生水起！
什么是 NUMA？为什么要关心它？
首先，咱们来科普一下 NUMA (Non-Uniform Memory Access)，翻译过来就是“非一致性内存访问”。 听起来很高大上，其实原理很简单。
在传统的 SMP (Symmetric Multi-Processing) 系统中，所有 CPU 共享同一块内存，访问速度基本一致。就像一群小朋友围着一个玩具，大家都能公平地玩。
但随着 CPU 核心数量的不断增加，这种架构就遇到了瓶颈。想象一下，如果 100 个小朋友围着一个玩具，那抢起来肯定很混乱，效率也会大大降低。 😩
NUMA 就是为了解决这个问题而生的。它把多个 CPU 核心和一部分内存组成一个 “Node”，每个 Node 有自己的本地内存。CPU 访问本地内存的速度比访问其他 Node 的内存快得多。就像每个小朋友都有自己的玩具箱，玩自己的玩具当然更方便啦！ 🥳
用表格来总结一下 SMP 和 NUMA 的区别：
| 特性 | SMP (对称多处理) | NUMA (非一致性内存访问) |
|---|---|---|
| 内存访问速度 | 所有 CPU 访问所有内存的速度基本一致 | CPU 访问本地内存快，访问其他 Node 的内存慢 |
| 扩展性 | 扩展性有限，容易出现性能瓶颈 | 扩展性更好，适用于 CPU 核心数量较多的系统 |
| 适用场景 | CPU 核心数量较少的服务器，对内存访问速度要求不高的应用 | CPU 核心数量较多的服务器，对内存访问速度要求高的应用，如数据库、高性能计算等 |
那么，为什么我们要关心 NUMA 呢？
很简单，如果你的应用对性能要求很高，比如需要频繁访问内存，那么最好让它运行在同一个 NUMA Node 上，这样可以最大限度地利用本地内存的优势，减少跨 Node 的内存访问，从而提高性能。反之，如果你的应用跨越多个 NUMA Node，就会导致性能下降，就像远距离恋爱，沟通成本太高，容易分手！ 💔
Kubernetes 调度器：有点“傻白甜”？
Kubernetes 调度器负责将 Pod 调度到合适的 Node 上。 但是，默认情况下，Kubernetes 调度器对 NUMA 拓扑结构一无所知，它就像一个“傻白甜”，只会根据 CPU 和内存等资源需求来调度 Pod，而不会考虑 Pod 应该运行在哪个 NUMA Node 上。 🤦♀️
这就可能导致一些问题：
- Pod 被调度到错误的 Node 上: 你的应用可能被调度到一个 CPU 资源充足，但离所需内存较远的 Node 上，导致性能下降。
- 资源碎片化: 多个 Pod 可能会被分散到不同的 NUMA Node 上，导致资源利用率不高。
所以，我们需要让 Kubernetes 调度器变得更“聪明”，让它能够感知 NUMA 拓扑结构，并根据应用的特点，将 Pod 调度到最合适的 Node 上。
NUMA 感知调度的几种姿势
好消息是， Kubernetes 社区已经提供了多种方法来实现 NUMA 感知调度。 下面，我们就来介绍几种常用的姿势：
1. 使用 Node Affinity 和 Node Selector：手动挡模式
这是最基本的方法，通过在 Pod 的 YAML 文件中指定 nodeAffinity 或 nodeSelector，将 Pod 调度到特定的 Node 上。
例如：
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: nginx:latest
nodeSelector:
node.kubernetes.io/hostname: node-1 # 将 Pod 调度到名为 node-1 的 Node 上这种方法简单直接，但需要手动配置每个 Pod 的 nodeAffinity 或 nodeSelector，比较繁琐，不适合大规模部署。而且，你需要事先了解集群的 NUMA 拓扑结构，才能做出正确的决策。 这就像手动挡汽车，需要驾驶员手动换挡，比较费力，但对车辆的控制更精准。
2. 使用 Topology Spread Constraints：雨露均沾模式
Topology Spread Constraints 可以让你控制 Pod 在不同拓扑域（如 Node、Region、Zone）上的分布情况。虽然它不是专门为 NUMA 感知调度设计的，但我们可以利用它来将 Pod 分散到不同的 NUMA Node 上，避免所有 Pod 都挤在一个 Node 上，导致资源争用。
例如：
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-deployment
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-container
image: nginx:latest
topologySpreadConstraints:
- maxSkew: 1
topologyKey: kubernetes.io/hostname # 在不同的 Node 上均匀分布 Pod
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app: my-app这种方法可以实现 Pod 在不同 Node 上的均匀分布，但无法保证 Pod 运行在同一个 NUMA Node 上。 这就像“雨露均沾”，每个 Node 都能分到一些 Pod，但无法保证每个 Pod 都能得到最好的资源。
3. 使用 CPU Manager 和 Topology Manager：自动挡模式
CPU Manager 和 Topology Manager 是 Kubernetes 提供的两种高级特性，可以实现更精细的资源管理和 NUMA 感知调度。
- CPU Manager: 可以将 CPU 资源划分为 exclusive 和 shared 两种模式。 exclusive 模式下，Pod 可以独占 CPU 核心，避免与其他 Pod 共享 CPU 资源，提高性能。
- Topology Manager: 可以根据 Pod 的资源需求，将 Pod 调度到合适的 NUMA Node 上，并尽量将 CPU 和内存分配在同一个 Node 上，实现更好的性能。
要启用 CPU Manager 和 Topology Manager，需要在 kubelet 的配置文件中进行配置。
例如：
# kubelet 配置文件
featureGates:
CPUManager: true
TopologyManager: true
cpuManagerPolicy: static # 设置 CPU Manager 的策略为 static
topologyManagerPolicy: best-effort # 设置 Topology Manager 的策略为 best-effort启用 CPU Manager 和 Topology Manager 后，你可以在 Pod 的 YAML 文件中指定 resources.limits 和 resources.requests，并设置 cpu.exclusive annotation 来启用 CPU Manager 的 exclusive 模式。
例如：
apiVersion: v1
kind: Pod
metadata:
name: my-pod
annotations:
cpu-manager.kubernetes.io/topology-aware: "true" # 启用 Topology Manager
spec:
containers:
- name: my-container
image: nginx:latest
resources:
limits:
cpu: "2"
memory: "2Gi"
requests:
cpu: "2"
memory: "2Gi"
securityContext:
capabilities:
drop:
- ALL这种方法可以实现更精细的资源管理和 NUMA 感知调度，但配置比较复杂，需要对 Kubernetes 的底层机制有深入的了解。 这就像自动挡汽车，驾驶起来更轻松，但对车辆的控制不如手动挡那么精准。
4. 使用 NUMA Operator：一键式解决方案
NUMA Operator 是一个 Kubernetes Operator，可以简化 NUMA 感知调度的配置和管理。 它可以自动发现集群的 NUMA 拓扑结构，并根据应用的特点，将 Pod 调度到最合适的 Node 上。
NUMA Operator 提供了一种“一键式”的解决方案，可以大大简化 NUMA 感知调度的配置和管理。
例如：
apiVersion: numaoperator.k8s.io/v1alpha1
kind: NUMANodePolicy
metadata:
name: numa-node-policy
spec:
nodeSelector:
matchLabels:
node-role.kubernetes.io/worker: "" # 选择所有 worker 节点
numaResources:
- name: cpu
count: 2
exclusive: true
- name: memory
size: 2Gi这种方法简单易用，但需要安装和配置 NUMA Operator。 这就像共享单车，扫码就能骑走，非常方便，但你需要先找到一辆共享单车。
用表格来总结一下这几种 NUMA 感知调度的姿势：
| 方法 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| Node Affinity/Node Selector | 简单直接，易于理解 | 需要手动配置，繁琐，需要事先了解集群的 NUMA 拓扑结构 | 少量 Pod，对 NUMA 感知要求不高，需要手动控制 Pod 的调度位置 |
| Topology Spread Constraints | 可以实现 Pod 在不同 Node 上的均匀分布 | 无法保证 Pod 运行在同一个 NUMA Node 上 | 需要将 Pod 分散到不同的 Node 上，避免资源争用 |
| CPU Manager/Topology Manager | 可以实现更精细的资源管理和 NUMA 感知调度 | 配置复杂，需要对 Kubernetes 的底层机制有深入的了解 | 对性能要求很高，需要精细的资源管理和 NUMA 感知调度 |
| NUMA Operator | 简单易用，可以自动发现集群的 NUMA 拓扑结构，并根据应用的特点，将 Pod 调度到最合适的 Node 上。提供了一键式解决方案，大大简化配置和管理 | 需要安装和配置 NUMA Operator | 希望简化 NUMA 感知调度的配置和管理，对 Kubernetes Operator 有一定了解 |
最佳实践：如何选择合适的 NUMA 感知调度方案？
选择合适的 NUMA 感知调度方案，需要根据应用的特点和集群的规模来综合考虑。
- 对于小型集群和简单的应用， 可以使用 Node Affinity 或 Node Selector 来手动控制 Pod 的调度位置。
- 对于中型集群和对性能要求不高的应用， 可以使用 Topology Spread Constraints 来实现 Pod 在不同 Node 上的均匀分布。
- 对于大型集群和对性能要求很高的应用， 可以使用 CPU Manager 和 Topology Manager 来实现更精细的资源管理和 NUMA 感知调度。
- 如果希望简化 NUMA 感知调度的配置和管理， 可以使用 NUMA Operator。
总而言之，没有最好的方案，只有最适合你的方案。
总结：让你的应用起飞！
今天，我们一起学习了 Kubernetes NUMA 感知调度的原理和几种常用的实现方法。 掌握了这些技巧，你就可以让你的应用在 Kubernetes 集群中跑得更快、更稳、更高效！ 🚀
记住，NUMA 感知调度不是银弹， 它只是一种优化手段。要真正提高应用的性能，还需要综合考虑代码优化、资源配置、网络优化等多个方面。
希望今天的分享对你有所帮助！ 如果你还有其他问题，欢迎在评论区留言。 我们下期再见！ 👋