【云计算】云主机的亲和性策略（四）：云主机组

《云主机的亲和性策略》系列，共包含以下文章：

• 1️⃣ 云主机的亲和性策略（一）：快乐旅行团
• 2️⃣ 云主机的亲和性策略（二）：集群节点组
• 3️⃣ 云主机的亲和性策略（三）：云主机 & 宿主机
• 4️⃣ 云主机的亲和性策略（四）：云主机组

😊 如果您觉得这篇文章有用 ✔️ 的话，请给博主一个一键三连 🚀🚀🚀 吧 （点赞 🧡、关注 💛、收藏 💚）！！！您的支持 💖💖💖 将激励 🔥 博主输出更多优质内容！！！

在公有云中，通过 云主机组（如 AWS Placement Group、OpenStack Server Group、Azure Availability Set）实现 亲和性 / 反亲和性 策略是主流方案。

1.云主机组的技术实现原理

1.1 核心逻辑

• 组（Group）作为 策略载体
  • 用户创建云主机组时，需 显式声明组策略类型（如反亲和、亲和或集群），后续将云主机加入该组，调度器自动应用组策略。
• 示例

  # AWS CLI 创建反亲和性组
  aws ec2 create-placement-group --group-name mysql-anti-group --strategy spread
  

1.2 调度器工作流程

1.3 关键技术点

组件	作用
组策略元数据	存储策略类型（如 anti-affinity）和组内云主机列表，通常用分布式数据库（如 etcd）保存。
调度过滤器	在调度链中添加专用过滤器（如 OpenStack 的 ServerGroupAntiAffinityFilter）。
故障域映射	将宿主机映射到故障域（如机架、电源域），组策略可能基于物理故障域而非单台宿主机。

1.4 公有云实现差异

云厂商	组类型	策略粒度	底层隔离单位
AWS	Placement Group (Spread)	单台物理机	宿主机（Rack Unit）
Azure	Availability Set	故障域（Fault Domain）	机架 / 电源组
OpenStack	Server Group (anti-affinity)	宿主机或自定义域	通过 host aggregate 定义
Google Cloud	Availability Policy (Spread)	物理服务器或维护域	宿主机或 Zone 内维护域

🚀 反亲和性组本质：通过组策略约束组内云主机在物理拓扑上的最小分布距离。

2.其他实现方法

2.1 标签选择器（Tag-based Affinity）

• 原理：用户为云主机或宿主机打标签（如 zone=zone1, app=mysql），调度时通过 标签匹配规则 决策。
• 适用场景：容器平台（如 K8s）、支持自定义标签的 IaaS 平台。

示例（Kubernetes 风格）

affinity:nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution:nodeSelectorTerms:- matchExpressions:- key: topology.zoneoperator: NotInvalues: [zone-failure-prone]  # 避免故障高发区podAntiAffinity:requiredDuringSchedulingIgnoredDuringExecution:- topologyKey: "kubernetes.io/hostname"labelSelector:matchLabels:app: mysql

这段代码是 Kubernetes（K8s）中的亲和性（Affinity）配置，用于控制 Pod 在集群中的调度行为。它的核心目标是：

• 优先选择稳定的可用区（避免故障高发区）
• 强制MySQL Pod分散在不同宿主机上（防止单点故障）

• 节点亲和性（nodeAffinity）
  • 作用：调度时 必须（required）满足的条件。
  • 逻辑：Pod只能被调度到 不包含标签 topology.zone=zone-failure-prone 的节点。
  • 场景：避免将 Pod 部署到历史故障率高的可用区（如 AWS 的某个 AZ 曾频繁宕机）。
• Pod 反亲和性（podAntiAffinity）
  • 作用：强制（required）同一集群中带有 app=mysql 标签的 Pod 不能调度到同一宿主机。
  • 逻辑：
    • 调度器检查目标宿主机（通过 kubernetes.io/hostname 标识）是否已有 app=mysql 的Pod。
    • 如果已有，则禁止当前 Pod 调度到该宿主机。
  • 场景：确保 MySQL 集群的多个实例分布在不同的物理节点上，即使宿主机宕机，也不会所有 MySQL 实例同时失效。

关键配置说明

字段	含义
requiredDuringScheduling...	硬性规则：不满足条件则 Pod 调度失败（状态为Pending）。
IgnoredDuringExecution	规则仅影响调度阶段，已运行的 Pod 即使违反规则也不会被驱逐。
topologyKey: kubernetes.io/hostname	反亲和性的作用域是 宿主机级别（同一宿主机不能有重复 Pod）。
operator: NotIn	排除操作符（还支持 In，Exists 等）。

调度结果示例

假设集群有 3 台宿主机和 2 个 AZ：

• 宿主机分布：
  • node-1：AZ-1（标签 topology.zone=az1）
  • node-2：AZ-1（标签 topology.zone=az1）
  • node-3：AZ-2（标签 topology.zone=zone-failure-prone）
• 调度行为：
  • 1️⃣ 排除 node-3（因为它在 zone-failure-prone）。
  • 2️⃣ 若已有 app=mysql 的 Pod 在 node-1，则新 Pod 只能调度到 node-2。
  • 3️⃣ 若尝试部署第 3 个 MySQL Pod，因无可用宿主机而 Pending。

⭐⭐⭐ 推荐阅读博主的其他相关博文：

• 【Kubernetes】Pod 资源调度之亲和性调度
• 【Kubernetes】Pod 驱逐

2.2 资源池分区（Resource Pool Partitioning）

• 原理：预先将宿主机划分为逻辑分区（如 高可用区、GPU 区），创建云主机时指定分区，分区内默认反亲和。
• 技术实现：
  • 管理员配置 宿主机聚合（Host Aggregate）。
  • 调度器限制单分区内云主机密度（如每宿主机最多 1 个关键 VM）。
• 优势：避免用户配置，适合标准化部署。

2.3 动态策略注入（Dynamic Policy Injection）

• 原理：通过 API 或策略引擎（如 OpenStack Nova Scheduler）动态注入调度规则，无需显式组。
• 示例：

  # OpenStack 调度器自定义过滤器
  class AntiAffinityFilter(filters.BaseHostFilter):def host_passes(self, host_state, filter_properties):request = filter_properties['request_spec']if 'anti_affinity' in request:return self._check_anti_affinity(host_state)
  

• 适用场景：高度定制化云平台或私有云。

3.方案对比与选型建议

方法	灵活性	用户易用性	调度复杂度	适用场景
云主机组	★★★☆☆	★★★★★	低	通用 IaaS 场景（用户直观控制）
标签选择器	★★★★★	★★★☆☆	高	K8s / 容器平台、多维度策略需求
资源池分区	★★☆☆☆	★★★★☆	中	企业标准化运维（减少用户干预）
动态策略注入	★★★★☆	★☆☆☆☆	极高	私有云深度定制开发

4. 深度优化：混合策略与挑战

4.1 混合策略案例

• 目标：同时满足反亲和性 + 靠近特定网络设备。
• 实现：
  • 用 云主机组 保证跨宿主机分布。
  • 通过 标签选择器 将云主机调度到靠近指定交换机的宿主机（标签 switch=core-sw1）。

4.2 常见挑战与解决

挑战	解决思路
资源碎片化	软亲和性（Soft Anti-Affinity）+ 超卖策略，允许轻度策略违反。
大规模调度延迟	分层调度器（如 Google Omega）+ 缓存宿主机状态。
跨集群策略同步	全局策略引擎（如 HashiCorp Consul 存储策略状态）。
异构硬件兼容性	策略绑定到宿主机标签（如 gpu_type=a100），避免调度到不兼容节点。

5.总结

• 云主机组是亲和性 / 反亲和性的高抽象层实现：通过逻辑组封装策略，降低用户使用门槛，适合公有云标准化服务。
• 替代方案各有侧重：
  • 标签选择器 → 灵活但复杂，适合技术专家；
  • 资源池分区 → 企业级标准化管控；
  • 动态注入 → 私有云深度定制。
• 🚀 未来趋势：云厂商正结合 AI 调度（如预测性放置）优化策略执行效率，在保证反亲和性的同时提升资源利用率（如 AWS 的 Predictive Placement）。