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

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

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

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

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

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

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

1.1 核心逻辑

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

示例

bash 复制代码

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

1.2 调度器工作流程

用户云平台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 风格）

yaml 复制代码

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）动态注入调度规则，无需显式组。

示例：

python 复制代码

# 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）。