Kubernetes 资源调度器的高级策略：拓扑感知与亲和性 – 一场关于“家”的深刻思考
各位观众，各位热爱Kubernetes的同学们，欢迎来到今天的“云原生动物园”特别讲座！我是今天的饲养员，啊不，是讲师，名叫“云小匠”。今天，我们要聊聊Kubernetes资源调度器里的两大高级策略：拓扑感知与亲和性。
你可能会觉得，资源调度听起来枯燥乏味，跟搬砖似的。但我要告诉你，它其实蕴含着深刻的哲学思考，关乎“家”的构建，关乎应用们的幸福生活。🤔
想象一下，你是一个社区规划师，要为一群性格各异的居民安排住所。有些人喜欢热闹，有些人喜欢安静；有些人需要离学校近，有些人需要离医院近。如果胡乱安排，轻则邻里矛盾，鸡飞狗跳，重则影响整个社区的和谐发展。
Kubernetes的资源调度器，就像这位社区规划师，负责将一个个Pod（也就是应用们）安排到合适的Node（也就是服务器）上。而拓扑感知和亲和性，就是这位规划师手中的两大“神器”，能让应用们找到最适合自己的“家”，享受最舒适的生活。
一、拓扑感知：摸清“地形”，因地制宜
拓扑感知，顾名思义，就是要让调度器了解集群的“地形地貌”。这个“地形地貌”指的是什么呢？它包括：
- 可用区（Availability Zone）：地理位置上隔离的区域，比如北京A区、北京B区，用于提高容错性。
- 节点区域（Node Region）：逻辑上的分组，比如开发环境、测试环境、生产环境。
- 硬件架构：CPU类型、GPU型号、存储类型等。
了解这些“地形地貌”有什么用呢？就好比你知道哪里是学区房，哪里是别墅区，才能更好地分配资源。
1. 跨可用区部署：鸡蛋不要放在一个篮子里
假设你有一个电商应用，高峰期流量巨大。为了保证高可用，你需要将应用部署到多个可用区。如果所有Pod都挤在一个可用区，一旦该可用区发生故障，整个应用就瘫痪了。
这时候，拓扑感知就派上用场了。你可以告诉调度器，尽量将Pod分散到不同的可用区，实现“鸡蛋不要放在一个篮子里”的策略。
Kubernetes提供了一个内置的拓扑域 topologySpreadConstraints 来实现这个目标。它允许你定义如何将Pod均匀地分布在集群的各种拓扑域（如可用区、节点、区域等）中。
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-app
image: nginx:latest
topologySpreadConstraints:
- maxSkew: 1 # 允许的最大偏差
topologyKey: topology.kubernetes.io/zone # 基于可用区进行分布
whenUnsatisfiable: DoNotSchedule # 如果无法满足约束，则不调度
labelSelector:
matchLabels:
app: my-app这个配置的意思是：将 my-app 的Pod尽可能均匀地分布在不同的可用区 (topology.kubernetes.io/zone)。maxSkew: 1 表示允许的最大偏差是1，也就是说，如果一个可用区有N个Pod，另一个可用区的Pod数量可以是N+1或N-1。whenUnsatisfiable: DoNotSchedule 表示如果无法满足这个约束，就不要调度新的Pod。
2. 节点区域隔离：各司其职，互不干扰
有时候，你需要将不同环境的应用部署到不同的节点区域，比如将开发环境的应用部署到开发集群，将生产环境的应用部署到生产集群。这样可以避免不同环境的应用互相干扰，保证生产环境的稳定性。
你可以通过给Node打标签，然后使用Node Selector来指定Pod应该部署到哪个节点区域。
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-app
image: nginx:latest
nodeSelector:
environment: production # 只在标签为environment=production的节点上运行首先，你需要给你的生产环境Node打上标签：
kubectl label node <node-name> environment=production然后，在Deployment的nodeSelector中指定environment: production，这样Pod就会只部署到生产环境的Node上。
3. 硬件资源优化：物尽其用，人尽其才
有些应用对硬件资源有特殊要求，比如需要使用GPU进行机器学习训练，或者需要使用SSD进行高性能存储。拓扑感知可以帮助你将这些应用部署到具有相应硬件资源的Node上。
你可以通过给Node打标签，然后使用Node Affinity来指定Pod应该部署到具有特定硬件资源的Node上。
比如，你可以给拥有GPU的Node打上标签 gpu=true，然后在Pod的nodeAffinity中指定必须运行在拥有GPU的Node上：
apiVersion: apps/v1
kind: Deployment
metadata:
name: gpu-app
spec:
replicas: 1
selector:
matchLabels:
app: gpu-app
template:
metadata:
labels:
app: gpu-app
spec:
containers:
- name: gpu-app
image: tensorflow/tensorflow:latest-gpu
resources:
limits:
nvidia.com/gpu: 1 # 请求使用一块GPU
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: gpu
operator: In
values:
- "true" # 必须在标签为gpu=true的节点上运行这里，requiredDuringSchedulingIgnoredDuringExecution 表示在调度期间必须满足这个条件，但在Pod运行期间如果条件不满足，不会驱逐Pod。
总结：拓扑感知，就像一位经验丰富的地质学家，摸清了集群的地形地貌，才能因地制宜，合理安排资源，让应用们各得其所。 🗺️
二、亲和性：寻找“邻居”，抱团取暖
亲和性，顾名思义，就是让Pod之间建立某种“亲密关系”，让它们尽可能地靠近彼此。这种“亲密关系”可以是：
- Node Affinity：让Pod部署到特定的Node上。
- Pod Affinity：让Pod部署到与特定Pod在同一个Node上。
- Pod Anti-Affinity：让Pod避免部署到与特定Pod在同一个Node上。
亲和性就好比给应用们牵线搭桥，让它们找到志同道合的“邻居”，一起构建和谐的“社区”。
1. Node Affinity：锁定“目标”，精准投放
我们前面已经提到过Node Affinity，它可以让Pod部署到符合特定条件的Node上。它有三种模式：
- RequiredDuringSchedulingIgnoredDuringExecution：必须满足条件才能调度，但不影响Pod的运行。
- PreferredDuringSchedulingIgnoredDuringExecution：尽量满足条件，但不强制。
- RequiredDuringSchedulingRequiredDuringExecution：必须满足条件才能调度，且持续满足条件，否则驱逐Pod。
举个例子，假设你有一个需要高速网络的应用，你可以将它部署到具有高速网卡的Node上。
apiVersion: apps/v1
kind: Deployment
metadata:
name: high-network-app
spec:
replicas: 3
selector:
matchLabels:
app: high-network-app
template:
metadata:
labels:
app: high-network-app
spec:
containers:
- name: high-network-app
image: nginx:latest
affinity:
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution: # 尽量满足，但不强制
- weight: 100
preference:
matchExpressions:
- key: network-speed
operator: In
values:
- "10G" # 尽量部署到标签为network-speed=10G的节点上这个配置的意思是，尽量将 high-network-app 的Pod部署到标签为 network-speed=10G 的Node上。weight: 100 表示这个偏好的权重，权重越高，越倾向于满足这个条件。
2. Pod Affinity：同甘共苦，生死相随
Pod Affinity可以让Pod部署到与特定Pod在同一个Node上。这对于需要频繁交互的应用非常有用，可以减少网络延迟。
比如，你有一个Web应用和一个缓存应用，它们需要频繁交互。你可以将它们部署到同一个Node上，减少网络延迟，提高性能。
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app
spec:
replicas: 3
selector:
matchLabels:
app: web-app
template:
metadata:
labels:
app: web-app
spec:
containers:
- name: web-app
image: nginx:latest
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
labelSelector:
matchExpressions:
- key: app
operator: In
values:
- cache-app # 必须和标签为app=cache-app的Pod在同一个节点上
topologyKey: kubernetes.io/hostname # 基于hostname进行匹配
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: cache-app
spec:
replicas: 1
selector:
matchLabels:
app: cache-app
template:
metadata:
labels:
app: cache-app
spec:
containers:
- name: cache-app
image: redis:latest这个配置的意思是，web-app 的Pod必须和标签为 app=cache-app 的Pod在同一个Node上。topologyKey: kubernetes.io/hostname 表示基于hostname进行匹配，也就是说，只有hostname相同的Node才会被认为是同一个Node。
3. Pod Anti-Affinity：保持距离，互不干扰
Pod Anti-Affinity可以让Pod避免部署到与特定Pod在同一个Node上。这对于需要高可用性的应用非常有用，可以避免单点故障。
比如，你有一个数据库应用，为了保证高可用，你需要将它的多个副本分散到不同的Node上。
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: db-app
spec:
replicas: 3
selector:
matchLabels:
app: db-app
serviceName: db-service
template:
metadata:
labels:
app: db-app
spec:
containers:
- name: db-app
image: postgres:latest
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
labelSelector:
matchExpressions:
- key: app
operator: In
values:
- db-app # 避免和标签为app=db-app的Pod在同一个节点上
topologyKey: kubernetes.io/hostname这个配置的意思是，db-app 的Pod避免和标签为 app=db-app 的Pod在同一个Node上。
总结：亲和性，就像一位热心的媒婆，给应用们牵线搭桥，让它们找到合适的“邻居”，抱团取暖，共同发展。 🤝
三、进阶技巧：组合拳，威力无穷
拓扑感知和亲和性可以单独使用，也可以组合使用，发挥更大的威力。
1. 拓扑感知 + Pod Anti-Affinity：高可用性与资源利用率兼得
假设你有一个关键业务应用，既要保证高可用性，又要尽可能地利用资源。你可以将应用部署到多个可用区，同时使用Pod Anti-Affinity避免同一个应用的多个副本部署到同一个Node上。
apiVersion: apps/v1
kind: Deployment
metadata:
name: critical-app
spec:
replicas: 3
selector:
matchLabels:
app: critical-app
template:
metadata:
labels:
app: critical-app
spec:
containers:
- name: critical-app
image: nginx:latest
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app: critical-app
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
labelSelector:
matchExpressions:
- key: app
operator: In
values:
- critical-app
topologyKey: kubernetes.io/hostname这个配置的意思是，将 critical-app 的Pod尽可能均匀地分布在不同的可用区，同时避免同一个应用的多个副本部署到同一个Node上。
2. 拓扑感知 + Node Affinity：精准投放，优化性能
假设你有一个需要高性能存储的应用，你可以将它部署到具有SSD的Node上，同时使用拓扑感知将Pod分散到不同的可用区。
apiVersion: apps/v1
kind: Deployment
metadata:
name: high-performance-app
spec:
replicas: 3
selector:
matchLabels:
app: high-performance-app
template:
metadata:
labels:
app: high-performance-app
spec:
containers:
- name: high-performance-app
image: nginx:latest
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app: high-performance-app
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: storage
operator: In
values:
- "ssd"这个配置的意思是，将 high-performance-app 的Pod尽可能均匀地分布在不同的可用区，同时必须部署到标签为 storage=ssd 的Node上。
总结：拓扑感知和亲和性就像武林高手，单独使用已威力不凡，组合使用更是如虎添翼，能解决各种复杂的调度问题。 🥋
四、最佳实践：量体裁衣，灵活应对
在实际应用中，选择合适的拓扑感知和亲和性策略需要根据具体情况进行分析。没有一成不变的规则，只有量体裁衣的方案。
- 明确目标： 首先要明确你的目标是什么，是高可用性、高性能、资源利用率，还是其他？
- 了解集群： 其次要了解你的集群的拓扑结构和硬件资源，比如可用区、节点区域、CPU类型、GPU型号、存储类型等。
- 评估风险： 然后要评估各种策略的风险和收益，比如过度约束可能导致资源浪费，约束不足可能导致性能下降。
- 持续优化： 最后要持续监控和优化你的调度策略，根据实际情况进行调整。
记住，Kubernetes的资源调度是一个动态的过程，需要不断地学习和实践，才能掌握其中的精髓。 📚
五、结语：构建和谐的“云原生社区”
各位观众，今天的“云原生动物园”特别讲座就到这里。希望通过今天的讲解，大家对Kubernetes的拓扑感知和亲和性有了更深入的理解。
Kubernetes的资源调度不仅仅是技术问题，更是一种哲学思考。它关乎“家”的构建，关乎应用们的幸福生活。只有合理地安排资源，才能构建一个和谐、高效、可持续的“云原生社区”。
希望大家都能成为优秀的“社区规划师”，为自己的应用们打造一个温馨舒适的“家”！ 🏡
谢谢大家！ 🙏