K8s 多集群实践思考和探索( 四 )

  • FedController开始计算clusterA和clusterB资源 , 在clusterA和clusterB创建HPA , 并按比例分配集群的min和max 。
  • 当集群clusterA和clusterB触发定义的cpu资源上限 , clusterA和clusterB开始扩容 。
  • Karmada控制平面的clusterA和clusterB的HPA work对象的status里有记录集群扩容副本情况 。
  • FedHPAController感知到work的变化 , 并获取到每个集群真实的副本数 , 开始更新调度资源RB和控制平面的workload副本数 。保证了控制平面和member集群的调度和副本数一致 , 不会出现重复调度和副本不一致 。反之cpu流量下去开始缩容 , 计算过程一样 。
  • 同时添加了资源再度均衡的能力 , 当集群资源变化时 , FedHPAController会计算集群总资源、节点碎片、是否可调度等情况 , 重新分配每个集群HPA的min和max值 , 确保在扩容时候有充足的资源 。
  • 3.2.2 定时伸缩
    K8s 多集群实践思考和探索

    文章插图
    定时扩缩容是指应在固定时间点执行应用扩容来应对流量的高峰期 。K8s本身没有这个概念 , 这里在Karmada控制平面定义了CronHpa资源 , 并通过Karmada-scheduler对多集群统一调度 。避免非联邦化集群在多个member集群创建多个cronhpa 。定时功能通过go-cron库实现 。
    CronHpa流程:
    1. 用户根据业务需求 , 创建CronHPA 。定义扩容时间和缩容时间 。
    2. 到扩容时间点 , CronHPAController开始扩容workload 。
    3. Karmada-scheduler开始调度 , 根据每个集群的资源开始合理分配每个集群的副本数 。
    4. 到缩容时间点 , CronHPAController开始缩容workload 。
    3.2.3 手动和指定扩缩容
    K8s 多集群实践思考和探索

    文章插图
    手动扩缩容流程:
    1. 用户指定workload , 进行扩容或者缩容 。
    2. Kamrada-scheduler开始调度 , 合理分配扩容或者缩容值到每个集群 。
    指定缩容 , 这里用到了openkruise能力 。如训练模型需要将一批性能差的pod进行缩容 。
    指定缩容流程:
    1. 用户在clusterA 指定workload下面一个pod进行缩容 , 需要在
      ScaleStrategy.PodsToDelete指定pod 。
    2. 需要在Karmada实现openkurise实现该字段的资源解析 , 不让它被控制平面覆盖 。
    3. 并在控制平面更新workload的副本和pp资源 , 保证副本数和调度结果一致 。
    4. member集群的openkruise开始删除指定的pod 。
    也可以尝试从Karmada控制平面指定删除pod和更改调度的结果 , 这样更加合理些 , 也不用添加Karmada资源解析 。
    3.3 统一调度3.3.1 多集群调度
    K8s 多集群实践思考和探索

    文章插图
    Karmada多集群调度主要实现跨集群资源的合理分配和集群故障快速迁移业务 。如上图所示主要通过Karmada scheudler和emulator配合实现 , 其中emulator主要负责每个集群的资源的估算 。
    workload调度流程:
    1. 用户定义workload和策略匹配 , 生成RB资源 。
    2. doSchedulerBinding开始对RB进行调度 , 通过预选和优选调度算法选择合适的集群 , 当前不会进行资源计算 , 和K8s调度预选和优选不一样 。
    3. selecClusters根据筛选的集群 , 进行副本分配 。这里有2种模式 , 主要根据用户配置的策略去选择 。
      a.Static scheduler 只计算所有资源的request , 不考虑调度规则 。
      b.Dynamic scheudler 会在计算所有request的同时 , 也会考虑一部分调度规则 。
    4. 最终计算出每个集群分配的副本数并更新RB资源 , 调度结束后其它控制器会根据RB进一步处理 。
    故障调度:
    1. 比如当集群clusterA发生故障 , 在一定判定条件内 , 会触发Karmada-scheduler重新调度 。


      推荐阅读