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

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

• 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 关键技术点

1.4 公有云实现差异

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

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 实例同时失效。

关键配置说明

调度结果示例

假设集群有 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.方案对比与选型建议

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

4.1 混合策略案例

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

4.2 常见挑战与解决

5.总结

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