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

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

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

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

云主机的亲和性策略（四）：云主机组

• 1.云主机组的技术实现原理
• • 1.1 核心逻辑
  • 1.2 调度器工作流程
  • 1.3 关键技术点
  • 1.4 公有云实现差异
• 2.其他实现方法
• • 2.1 标签选择器（Tag-based Affinity）
  • • 示例（Kubernetes 风格）
  • 2.2 资源池分区（Resource Pool Partitioning）
  • 2.3 动态策略注入（Dynamic Policy Injection）
• 3.方案对比与选型建议
• 4. 深度优化：混合策略与挑战
• • 4.1 混合策略案例
  • 4.2 常见挑战与解决
• 5.总结

在公有云中，通过 云主机组（如 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 调度器工作流程

#mermaid-svg-gIsRtZweTj5dfLUD {font-family:\"trebuchet ms\",verdana,arial,sans-serif;font-size:16px;fill:#333;}#mermaid-svg-gIsRtZweTj5dfLUD .error-icon{fill:#552222;}#mermaid-svg-gIsRtZweTj5dfLUD .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-gIsRtZweTj5dfLUD .edge-thickness-normal{stroke-width:2px;}#mermaid-svg-gIsRtZweTj5dfLUD .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-gIsRtZweTj5dfLUD .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-gIsRtZweTj5dfLUD .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-gIsRtZweTj5dfLUD .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-gIsRtZweTj5dfLUD .marker{fill:#333333;stroke:#333333;}#mermaid-svg-gIsRtZweTj5dfLUD .marker.cross{stroke:#333333;}#mermaid-svg-gIsRtZweTj5dfLUD svg{font-family:\"trebuchet ms\",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-gIsRtZweTj5dfLUD .actor{stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);fill:#ECECFF;}#mermaid-svg-gIsRtZweTj5dfLUD text.actor>tspan{fill:black;stroke:none;}#mermaid-svg-gIsRtZweTj5dfLUD .actor-line{stroke:grey;}#mermaid-svg-gIsRtZweTj5dfLUD .messageLine0{stroke-width:1.5;stroke-dasharray:none;stroke:#333;}#mermaid-svg-gIsRtZweTj5dfLUD .messageLine1{stroke-width:1.5;stroke-dasharray:2,2;stroke:#333;}#mermaid-svg-gIsRtZweTj5dfLUD #arrowhead path{fill:#333;stroke:#333;}#mermaid-svg-gIsRtZweTj5dfLUD .sequenceNumber{fill:white;}#mermaid-svg-gIsRtZweTj5dfLUD #sequencenumber{fill:#333;}#mermaid-svg-gIsRtZweTj5dfLUD #crosshead path{fill:#333;stroke:#333;}#mermaid-svg-gIsRtZweTj5dfLUD .messageText{fill:#333;stroke:#333;}#mermaid-svg-gIsRtZweTj5dfLUD .labelBox{stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);fill:#ECECFF;}#mermaid-svg-gIsRtZweTj5dfLUD .labelText,#mermaid-svg-gIsRtZweTj5dfLUD .labelText>tspan{fill:black;stroke:none;}#mermaid-svg-gIsRtZweTj5dfLUD .loopText,#mermaid-svg-gIsRtZweTj5dfLUD .loopText>tspan{fill:black;stroke:none;}#mermaid-svg-gIsRtZweTj5dfLUD .loopLine{stroke-width:2px;stroke-dasharray:2,2;stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);fill:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);}#mermaid-svg-gIsRtZweTj5dfLUD .note{stroke:#aaaa33;fill:#fff5ad;}#mermaid-svg-gIsRtZweTj5dfLUD .noteText,#mermaid-svg-gIsRtZweTj5dfLUD .noteText>tspan{fill:black;stroke:none;}#mermaid-svg-gIsRtZweTj5dfLUD .activation0{fill:#f4f4f4;stroke:#666;}#mermaid-svg-gIsRtZweTj5dfLUD .activation1{fill:#f4f4f4;stroke:#666;}#mermaid-svg-gIsRtZweTj5dfLUD .activation2{fill:#f4f4f4;stroke:#666;}#mermaid-svg-gIsRtZweTj5dfLUD .actorPopupMenu{position:absolute;}#mermaid-svg-gIsRtZweTj5dfLUD .actorPopupMenuPanel{position:absolute;fill:#ECECFF;box-shadow:0px 8px 16px 0px rgba(0,0,0,0.2);filter:drop-shadow(3px 5px 2px rgb(0 0 0 / 0.4));}#mermaid-svg-gIsRtZweTj5dfLUD .actor-man line{stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);fill:#ECECFF;}#mermaid-svg-gIsRtZweTj5dfLUD .actor-man circle,#mermaid-svg-gIsRtZweTj5dfLUD line{stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);fill:#ECECFF;stroke-width:2px;}#mermaid-svg-gIsRtZweTj5dfLUD :root{--mermaid-font-family:\"trebuchet ms\",verdana,arial,sans-serif;} 用户 云平台API 调度器 宿主机Hypervisor 策略数据库 1. 创建云主机组（策略=反亲和） 1.1 存储组策略规则 确认存储成功 返回组ID（如group-123） 2. 创建云主机（加入group-123） 2.1 请求调度云主机 2.2 查询group-123已有云主机位置 返回宿主机列表（如[H1, H3]） 2.3 排除已占用的宿主机（H1, H3） 2.4 筛选满足资源的宿主机（剩余H2, H4...） 2.5 选择最优宿主机（如H2） 2.6 在H2创建云主机 返回创建结果 返回调度成功 返回云主机ID（如vm-xyz） 用户 云平台API 调度器 宿主机Hypervisor 策略数据库

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.zone operator: NotIn values: [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）。