江苏龙网

  1. 主页 > 生活百科 > >

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

k8s

  • Karmada-scheduler会将故障集群的资源 ， 调度到clusrerB和clusterC 。
    • 3.3.2 重调度
    K8s 多集群实践思考和探索

    文章插图
    重调度的存在主要解决应用下发到member集群没有真正的运行起来 ， 导致出现这样的情况可能是集群资源在不断的变化 ， 应用正在Karmada-scheduler多集群调度的时候可能满足 ， 但经过member集群二次调度时候无法调度 。
    重调度流程：
    1. 过滤RB资源 ， 发现RB调度没有达到预期 。
    2. 对workload发起重新调度 。
    3. 进过预选、优选等流程 ， 再次分配调度结果 。
    4. 最终将workload的所有pod调度起来 。
    3.3.3 单集群调度模拟器
    K8s 多集群实践思考和探索

    文章插图
    目前社区单集群的调度估算器 ， 只是简单模拟了4种调度算法 。和实际的调度算法有很大差距 ， 目前线上有很多自研的调度算法和不同集群需要配置不同算法 ， 这样估算器的精确度就会下降 ， 导致调度出现pod pending的情况 。可以对单集群的调度模拟器进行优化 。
    1. 使用fake client 去模拟线上集群 。
    2. fake client启动k8s默认的调度器以及自研的调度算法 ， 修改binding接口 。并配置到每个member集群 。
    3. podRequest请求每个集群调度模拟器 ， 运行真实的调度算法 ， 并计算调度结果 。
    3.4 灰度上线3.4.1  应用迁移
    K8s 多集群实践思考和探索

    文章插图
    对于通过非联邦化资源管理的应用 ， 不能直接删除在创建 ， 需要平滑迁移到Karmada管理 ， 对于用户无感知 。
    主要流程如下：
    1. 管理员通过容器平台 ， 将需要迁移的应用插入迁移白名单 。
    2. 用户通过cicd发布 ， 容器平台会进行发布接口调用 。
    3. isKarmada模块会查看迁移名单 ， 在白名单内将资源联邦化 ， 接入Karmada管理 。不在白名单内保持原有的静态集群管理 。
    4. 最终完成应用的发布 ， 用户完全无感知 。保持2种管理方式并行存在 。
    3.4.2 应用回滚
    K8s 多集群实践思考和探索

    文章插图
    有了应用迁移的能力 ， 是否就可以保证整个流程百分百没有问题 ， 其实是无法保证的 。这就必须有应用回滚能力 ， 提升用户的迁移满意度 。
    回滚的必要性总结：
    1. 应用发布迁移的过程中发生了未知的错误 ， 并且短时间无法恢复 。避免阻塞应用正常发布 ， 需要回滚 。
    2. 应用被Karmada接管后发生未知的错误 ， 需要避免资源联邦化后无法控制 ， 需要回滚 。
    回滚流程：
    1. 管理员通过容器管理平台 ， 将需要回滚的应用从迁移白名单删除 。
    2. 并对应用对应的workload以及关联的资源打上注解 。
    3. 修改exection-controller源码 ， exection-controller发现以上注解 ， 最终调用update/create时不做处理 。
    4. 修改defaultInterpreter源码 ， 发现以上注解ReviseReplica不修改副本数 。
    5. 这样就可以阻断Karmada控制平面和member集群的联系 。这里为什么没有直接从Karmada删除资源 ， 主要避免删除这种高危操作以及方便后期恢复后重新接入Karmada 。
    3.4.3 迁移策略
    K8s 多集群实践思考和探索

    文章插图
    应用迁移Karmada原则：
    1. 先测试、再预发、最后生产
    2. 重大变更 ， 分批次灰度 ， 按照1:2:7比例灰度迁移
    3. 责任人双方点检验证 ， 并观察监控5~10分钟


      推荐阅读


    上一篇：Java与MySQL的并发访问冲突：锁与事务

    下一篇：SpringBoot实现多数据源配置详解