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

3.1 面向应用的多集群持续发布3.1.1 应用发布

文章插图
上图是面向应用的多集群持续发布架构，我们主要的工作如下：

管理注册多个Kubernetes集群并接入Karmada ， Karmada负责多个集群的资源调度编排和故障转移。
容器平台统一管理K8s资源、Karmada策略和配置。
CICD平台对应用进行单元测试、安全测试、编译镜像等操作，配置应用的存储、密钥、环境变量、网络和资源等，最终对接容器平台的API生成K8s对象，统一交付。

文章插图
图片
一个应用真正的能管理起来其实很复杂，如特定的场景需要原地升级和灰度发布等。为了可以提供更加灵活、高级和易用的应用发布能力，更好地满足应用发布的需求，最终选择使用Openkruise 。比如上图有个游戏的应用game-2408 。它涉及到K8s资源有configmap、secret、pv、pvc、service ， openkruise的cloneset、自研的服务发现和访问资源、以及Karmada的PropagationPolicy和OverridePolicy等资源，都能达到12个资源配置。比如存储等资源都是按需申请和分配的，为了有效管理这些资源和关系，当前主要通过关联数据库进行管理，并打通cicd和容器平台的交互，记录应用发布的状态转换，实现应用的滚动、灰度等发布能力，达到可持续发布的能力。
为了方便问题定位、K8s资源和Karmada资源的策略关系，当前Karmada 策略命名规范如下：

可以识别策略属于那个workload
避免策略重复，需要加入workload类型
策略名超过63个字符，需要hash处理
xxx为非workload的资源名

遇到的问题总结：

一个资源无法被多个策略匹配，导致如configmap、secret等公用资源无法再次下发到其它集群。
多个集群之间串行发布，如发布完A集群才能发布B集群的控制。

3.1.2 Openkruise资源解析

文章插图
当前vivo的应用主要通过OpenKruise的Cloneset(无状态)和AdvancedStatefulset(有状态)控制器进行发布。Kamrada目前只能识别K8s默认的资源，其它的资源都需要开发资源解析。为了解决上面提到的问题， Karmada 引入了 Resource Interpreter Webhook ，通过干预从 ResourceTemplate-> ResourceBinding ->Work ->Resource 的这几个阶段来实现完整的自定义资源分发能力。
（1）InterpretReplica：
该 hook 点发生在从 ResourceTemplate 到 ResourceBinding 这个过程中，针对有 replica 功能的资源对象，比如类似 Deployment 的自定义资源，实现该接口来告诉 Karmada 对应资源的副本数。
（2）ReviseReplica：
该 hook 点发生在从 ResourceBinding 到 Work 这个过程中，针对有 replica 功能的资源对象，需要按照 Karmada 发送的 request 来修改对象的副本数。Karmada 会通过调度策略把每个集群需要的副本数计算好，你需要做的只是把最后计算好的值赋给你的 CR 对象。
（3）RetAIn：
该 hook 点发生在从 Work 到 Resource 这个过程中，针对 spec 内容会在 member 集群单独更新的情况，可以通过该 hook 告知 Karmada 保留某些字段的内容。
（4）AggregateStatus：
该 hook 点发生在从 ResourceBinding 到 ResourceTemplate 这个过程中，针对需要将 status 信息聚合到 Resource Template 的资源类型，可通过实现该接口来更新 Resource Template 的 status 信息。
3.2 面向应用的多集群弹性伸缩3.2.1 弹性伸缩