Karmada（Kubernetes Armada）是 CNCF 孵化的一个 Kubernetes 管理系统，使您能够在多个 Kubernetes 集群和云中运行云原生应用程序，而无需更改应用程序。通过使用 Kubernetes 原生 API 并提供先进的调度功能，Karmada 实现了真正的开放式、多云 Kubernetes。
Karmada 旨在为多云和混合云场景下的多集群应用程序管理提供即插即用的自动化，具有集中式多云管理、高可用性、故障恢复和流量调度等关键功能。
特性
- 兼容 K8s 原生 API
从单集群到多集群的无侵入式升级
现有 K8s 工具链的无缝集成
- 开箱即用
- 针对场景内置策略集，包括：Active-active、Remote DR、Geo Redundant 等。
- 在多集群上进行跨集群应用程序自动伸缩、故障转移和负载均衡。
- 避免供应商锁定
- 与主流云提供商集成
- 在集群之间自动分配、迁移
- 未绑定专有供应商编排
- 集中式管理
- 位置无关的集群管理
- 支持公有云、本地或边缘上的集群。
- 丰富多集群调度策略
- 集群亲和性、实例在多集群中的拆分调度/再平衡，
- 多维 HA:区域/AZ/集群/提供商
- 开放和中立
- 由互联网、金融、制造业、电信、云提供商等联合发起。
- 目标是与 CNCF 一起进行开放治理。
Karmada 架构
Karmada 的架构非常类似于单个 Kubernetes 集群，他们都有一个控制平面、一个 APIServer、一个调度器和一组控制器，而且 Karmada 完全兼容 K8s 的原生 API 操作，便于各种 K8s 集群的接入。
Karmada 架构
所以同样 Karmada 的核心是其控制平面，一个完整且可工作的 Karmada 控制平面由以下组件组成。其中 karmada-agent 可以是可选的，这取决于集群注册模式。
karmada-apiserver
APIServer 是 Karmada 控制平面的一个组件，对外暴露 Karmada API 以及 Kubernetes 原生 API，APIServer 是 Karmada 控制平面的前端。
Karmada APIServer 是直接使用 Kubernetes 的 kube-apiserver 实现的，因此 Karmada 与 Kubernetes API 自然兼容。这也使得 Karmada 更容易实现与 Kubernetes 生态系统的集成，例如允许用户使用 kubectl 来操作 Karmada、与 ArgoCD 集成、与 Flux 集成等等。
karmada-aggregated-apiserver
聚合 API 服务器是使用 Kubernetes API 聚合层技术实现的扩展 API 服务器。它提供了集群 API 以及相应的子资源，例如 cluster/status 和 cluster/proxy，实现了聚合 Kubernetes API Endpoint 等可以通过 karmada-apiserver 访问成员集群的高级功能。
kube-controller-manager
kube-controller-manager 由一组控制器组成，Karmada 只是从 Kubernetes 的官方版本中挑选了一些控制器，以保持与原生控制器一致的用户体验和行为。值得注意的是，并非所有的原生控制器都是 Karmada 所需要的。
注意：当用户向 Karmada APIServer 提交 Deployment 或其他 Kubernetes 标准资源时，它们只记录在 Karmada 控制平面的 etcd 中。随后，这些资源会向成员集群同步。然而，这些部署资源不会在 Karmada 控制平面集群中进行 reconcile 过程（例如创建 Pod）。
karmada-controller-manager
Karmada 控制器管理器运行了各种自定义控制器进程。控制器负责监视 Karmada 对象，并与底层集群的 API 服务器通信，以创建原生的 Kubernetes 资源。
karmada-scheduler
karmada-scheduler 负责将 Kubernetes 原生 API 资源对象（以及 CRD 资源）调度到成员集群。
调度器依据策略约束和可用资源来确定哪些集群对调度队列中的资源是可用的，然后调度器对每个可用集群进行打分排序，并将资源绑定到最合适的集群。
karmada-webhook
karmada-webhook 是用于接收 karmada/Kubernetes API 请求的 HTTP 回调，并对请求进行处理。你可以定义两种类型的 karmada-webhook，即验证性质的 webhook 和修改性质的 webhook。修改性质的准入 webhook 会先被调用。它们可以更改发送到 Karmada API 服务器的对象以执行自定义的设置默认值操作。
在完成了所有对象修改并且 Karmada API 服务器也验证了所传入的对象之后，验证性质的 webhook 会被调用，并通过拒绝请求的方式来强制实施自定义的策略。
etcd
一致且高可用的键值存储，用作 Karmada 的所有 Karmada/Kubernetes 资源对象数据的后台数据库。
如果你的 Karmada 使用 etcd 作为其后台数据库，请确保你针对这些数据有一份备份计划。
karmada-agent
Karmada 有 Push 和 Pull 两种集群注册模式，karmada-agent 应部署在每个 Pull 模式的成员集群上。它可以将特定集群注册到 Karmada 控制平面，并将工作负载清单从 Karmada 控制平面同步到成员集群。此外，它也负责将成员集群及其资源的状态同步到 Karmada 控制平面。
插件（Addons）
- karmada-scheduler-estimator
Karmada 调度估计器为每个成员集群运行精确的调度预估，它为调度器提供了更准确的集群资源信息。
注意：早期的 Karmada 调度器只支持根据集群资源的总量来决策可调度副本的数量。在这种情况下，当集群资源的总量足够但每个节点资源不足时，会发生调度失败。为了解决这个问题，引入了估计器组件，该组件根据资源请求计算每个节点的可调度副本的数量，从而计算出真正的整个集群的可调度副本的数量。
- karmada-descheduler
Karmada 重调度组件负责定时检测所有副本（默认为两分钟），并根据成员集群中副本实例状态的变化触发重新调度。
该组件是通过调用 karmada-scheduler-estimator 来感知有多少副本实例状态发生了变化，并且只有当副本的调度策略为动态划分时，它才会发挥作用。
- karmada-search
Karmada 搜索组件以聚合服务的形式，提供了在多云环境中进行全局搜索和资源代理等功能。
其中，全局搜索能力是用来跨多个集群缓存资源对象和事件，以及通过搜索 API 对外提供图形化的检索服务；资源代理能力使用户既可以访问 Karmada 控制平面所有资源，又可以访问成员集群中的所有资源。
CLI 工具
- karmadactl
Karmada 提供了一个命令行工具 karmadactl，用于使用 Karmada API 与 Karmada 的控制平面进行通信。
你可以使用 karmadactl 执行成员集群的添加/剔除，将成员集群标记/取消标记为不可调度，等等。
- kubectl karmada
kubectl karmada 以 kubectl 插件的形式提供功能，但它的实现与 karmadactl 完全相同。
安装
首先要注意我们使用 Karmada 管理的多集群包含两类：
- host 集群：即由 karmada 控制面构成的集群，接受用户提交的工作负载部署需求，将之同步到 member 集群，并从 member 集群同步工作负载后续的运行状况。
- member 集群：由一个或多个 K8s 集群构成，负责运行用户提交的工作负载
所以首先我们需要准备几个 K8s 集群用于测试，其中 host 集群就是我们要安装 Karmada 的集群，这里我们可以使用 KinD 部署一个 host 集群以及两个 member 集群，用于测试 Karmada 的多集群管理功能，当然首先需要在你的测试环境中安装 Docker 和 KinD。
然后，我们可以使用 Karmada 官方提供的 create-cluster.sh 脚本来创建两个 member 集群。
到这里我们就准备好了一个 host 集群和两个 member 集群，接下来我们就可以在 host 集群上安装 Karmada 了。安装 Karmada 的方法有很多，可以直接使用官方的 CLI 工具，也可以使用 Helm Chart 方式，还可以使用 Operator 方式等等，如果需要定制化安装，使用 Helm Chart 的方式会更加灵活。由于官方提供的 CLI 工具并不只是用于安装 Karmada，还可以用于管理 Karmada 集群，所以无论如何我们都可以先安装 CLI 工具 - karmadactl，karmadactl 是允许你控制 Karmada 控制面的 Karmada 命令行工具，此外还提供一个 kubectl 插件 kubectl-karmada，尽管这两个工具的名字不同，但其关联的命令和选项完全相同，所以无论使用哪一个都是一样的，在实际使用中，你可以根据自己的需求选择一个 CLI 工具。
直接使用下面的命令即可一键安装 karmadactl：
安装 kubectl-karmada 与安装 karmadactl 相同，你只需要添加一个 kubectl-karmada 参数即可：
接下来我们就可以在 host 集群上安装 Karmada 了，我们已将 host 集群的 kubeconfig 文件放到了 $HOME/.kube/config。直接执行以下命令即可进行安装：
安装正常的话会看到如上所示的输出信息。默认 Karmada 会安装在 host 集群的 karmada-system 命名空间中：
如上所示 Karmada 控制平面相关 Pod 都已经正常运行，接下来我们就可以将两个 member 集群注册到 Karmada 控制平面中了，注册集群有两种方式，一种是 Push 模式，一种是 Pull 模式：
- Push：Karmada 控制平面将直接访问成员集群的 kube-apiserver 以获取集群状态并部署清单。
- Pull：Karmada 控制平面不会访问成员集群，而是将其委托给名为 Karmada-agent 的额外组件。
我们这里的集群都使用的 KinD 搭建的，所以使用 Push 模式更方便，对于无法直接访问成员集群的环境下面可以使用 Pull 模式。
我们可以使用 kubectl karmada join 命令来注册集群到 Karmada 控制平面。
注册成功后可以查看注册的集群列表：
到这里我们就完成了 Karmada 的安装和集群注册，接下来我们就可以使用 Karmada 来管理多集群了。
资源分发
接下来我们创建一个 Deployment 资源，然后使用 Karmada 将其分发到 member1 和 member2 集群中。首先创建如下所示的 Deployment 资源：
要注意我们需要使用 Karmada 控制平面的 kubeconfig 文件来创建资源对象，因为 Karmada 控制平面会将资源对象分发到成员集群中，所以在应用资源对象时需要使用 --kubeconfig /etc/karmada/karmada-apiserver.config 参数。
现在成员集群 member1 和 member2 下面并没有对应的对象。要进行资源分发我们需要使用一个名为 PropagationPolicy（或者 ClusterPropagationPolicy）的资源对象，该资源对象定义了如何将资源分发到成员集群中。比如我们要将上面的 Deployment 对象分发到 member1 和 member2 集群中，我们可以创建如下所示的 PropagationPolicy 对象：
在上面的 PropagationPolicy 对象中，首先我们通过 resourceSelectors 属性指定了要分发的资源对象，然后通过 placement 字段，指定了资源对象的分发策略。
其中 .spec.placement.clusterAffinity 字段表示对特定集群集合的调度限制，没有该限制，任何集群都可以成为调度候选者，该字段包含以下几个属性：
- LabelSelector：用于选择集群的标签，matchLabels 和 matchExpressions 两种方式都支持。
- FieldSelector：按字段选择成员集群的过滤器。
- ClusterNames：直接指定所选的集群。
- ExcludeClusters：排除指定的集群。
比如我们这里直接通过 clusterNames 属性指定了 member1 和 member2 集群，这意味着 Deployment 对象 nginx 可以被分发到 member1 和 member2 集群中。
此外我们还可以设置 ClusterAffinities 字段来声明多个集群组。调度器将按照它们在规范中出现的顺序逐一评估这些组，不满足调度限制的组将被忽略，这意味着该组中的所有集群都不会被选择。如果没有一个组满足调度限制，则调度失败，这意味着不会选择任何集群。
另外还要注意 ClusterAffinities 不能与 ClusterAffinity 共存。如果 ClusterAffinity 和 ClusterAffinities 均未设置，则任何集群都可以作为调度候选者。
比如现在我们有两个分组的集群，其中本地数据中心的私有集群可以是主要的集群，云提供商提供的托管集群可以是次组。因此，Karmada 调度程序更愿意将工作负载调度到主集群组，并且只有在主组不满足限制（例如缺乏资源）的情况下才会考虑第二组集群，那么就可以配置如下所示的 PropagationPolicy 对象：
又比如对于灾难恢复的场景，集群可以分为 primary 集群和 backup 集群，工作负载将首先调度到主集群，当主集群发生故障（例如数据中心断电）时，Karmada 调度程序可以迁移工作负载到备份集群。这种情况下可以配置如下所示的 PropagationPolicy 对象：
现在我们已经指定了分发的集群，那么具体应该如何调度呢？哪一个集群应该有多少副本呢？这就需要指定调度策略了。和原生 Kubernetes 类似，Karmada 支持多种调度策略，比如支持容忍污点、权重等。
通过 .spec.placement.clusterTolerations 字段可以设置容忍度，与 kubernetes 一样，容忍需要与集群上的污点结合使用。在集群上设置一个或多个污点后，无法在这些集群上调度或运行工作负载，除非策略明确声明可以容忍这些污点。Karmada 目前支持效果为 NoSchedule 和 NoExecute 的污点。我们可以使用 karmadactl taint 命令来设置集群的污点：
为了调度到上述集群，我们需要在 PropagationPolicy 中声明以下内容：
我们常常使用 NoExecute 污点来实现多集群故障转移。
然后更多的时候我们需要设置副本调度策略，我们可以通过 .spec.placement.replicaScheduling 字段来设置副本调度策略，该字段表示将规范中具有副本的资源传播到成员集群时处理副本数量的调度策略。Karmada 一共提供了两种副本调度类型，用于确定 Karmada 传播资源时如何调度副本：
- Duplicated：从资源中将相同的副本复制到每个候选成员集群。
- Divided：根据有效候选成员集群的数量将副本划分为若干部分，每个集群的确切副本由 ReplicaDivisionPreference 确定。
ReplicaDivisionPreference 用于描述当 ReplicaSchedulingType 为 Divided 时副本如何被划分，也提供了两种副本划分方式：
- Aggregated：将副本尽可能少地划分到集群，同时在划分过程中尊重集群的资源可用性。
- Weighted：根据 WeightPreference 按权重划分副本，一共有两种方式。StaticWeightList 根据权重静态分配副本到目标集群，可以通过 ClusterAffinity 选择目标集群。DynamicWeight 指定生成动态权重列表的因子，如果指定，StaticWeightList 将被忽略。
上面我们创建的 Nginx 的 PropagationPolicy 对象中，我们指定了 ReplicaDivisionPreference 为 Weighted，ReplicaSchedulingType 为 Divided，weightPreference 为 1，表示两个集群的权重相同，这意味着副本将均匀地传播到 member1 和 member2。
我们这里直接应用传播策略资源对象即可：
当创建 PropagationPolicy 对象后，Karmada 控制平面 watch 到过后就会自动将资源对象分发到成员集群中，我们可以查看 Deployment 对象的状态：
可以看到 Deployment 对象已经成功分发到了 member1 和 member2 集群中，我们也可以查看 member1 和 member2 集群中的 Pod 对象来进行验证：
和我们声明的副本调度策略一样，两个 Pod 对象均匀地分布在 member1 和 member2 集群中。
分发 CRD
除了内置的资源对象之外，Karmada 还支持分发自定义资源对象（CRD）。这里我们以 Karmada 仓库中的 guestbook 为例进行说明。
首先进入 Karmada 仓库的 guestbook 目录下：
然后在 Karmada 的控制平面上创建 Guestbook CRD：
该 CRD 应该被应用到 karmada-apiserver。
然后我们可以创建一个 ClusterPropagationPolicy 对象，将 Guestbook CRD 分发到 member1，如下所示：
需要注意的是 CustomResourceDefinition 是全局资源，所以我们使用 ClusterPropagationPolicy 对象来分发，该对象的配置和 PropagationPolicy 对象类似，注意 resourceSelectors 字段中的 apiVersion 和 kind 需要设置为 apiextensions.k8s.io/v1 和 CustomResourceDefinition，name 字段需要设置为 Guestbook CRD 的名称。
然后我们直接创建 ClusterPropagationPolicy 对象即可：
应用后正常就会将 Guestbook CRD 对象分发到 member1 集群中。
接下来我们就可以部署分发 Guestbook CRD 对象了，我们可以创建一个 Guestbook CR 对象：
同样在 Karmada 控制平面上应用该 Guestbook CR 对象即可：
然后就可以创建 PropagationPolicy 对象，将 guestbook-sample 分发到 member1 集群：
上面的 PropagationPolicy 对象和我们之前创建的类似，只是这里的 resourceSelectors 字段中的 apiVersion 和 kind 需要设置为 webapp.my.domain/v1 和 Guestbook（我们自己的 CRD）。同样直接应用该 PropagationPolicy 对象即可：
应用后就可以将 guestbook-sample 这个 Guestbook CR 对象分发到 member1 集群中了。
可以看到 CRD 的分发和普通资源对象的分发原理是一样的，只是需要先将 CRD 对象分发到成员集群中。
有的时候我们可能需要对分发的资源到不同集群进行一些覆盖操作，这个时候我们就可以使用 OverridePolicy 和 ClusterOverridePolicy 对象，用于声明资源传播到不同集群时的覆盖规则。
比如我们创建一个 OverridePolicy 对象，用于覆盖 member1 中 guestbook-sample 的 size 字段，如下所示：
上面的对象中通过 resourceSelectors 字段指定了要覆盖的资源对象，然后通过 overrideRules 字段指定了覆盖规则，targetCluster 字段指定了目标集群，overriders 字段指定了覆盖规则，这里我们将 guestbook-sample 的 size 字段覆盖为 4，同时添加了一个 OverridePolicy: test 的注解。
我们直接应用该 OverridePolicy 对象即可：
创建完成后可以查看 member1 集群中的 guestbook-sample 对象来进行验证：
可以看到 guestbook-sample 对象的 size 字段已经被覆盖为 4，同时添加了一个 OverridePolicy: test 的注解，证明覆盖操作成功。
Karmada 提供了多种声明覆盖规则的方案：
- ImageOverrider：覆盖工作负载的镜像。
- CommandOverrider：覆盖工作负载的命令。
- ArgsOverrider：覆盖工作负载的参数。
- LabelsOverrider：覆盖工作负载的标签。
- AnnotationsOverrider：覆盖工作负载的注释。
- PlaintextOverrider：用于覆盖任何类型资源的通用工具。
PlaintextOverrider
上面我们使用的是 PlaintextOverrider 覆盖规则，可以覆盖任何类型资源的字段。PlaintextOverrider 可以根据路径、运算符和值覆盖目标字段，就像 kubectl patch 一样。允许的操作如下：
- add：向资源追加一个或多个元素。
- remove：从资源中删除一个或多个元素。
- replace：替换资源中的一个或多个元素。
ImageOverrider
ImageOverrider 用于覆盖工作负载的镜像，用于覆盖格式为 [registry/]repository[:tag|@digest]（例如 /spec/template/spec/containers/0/image ）的镜像。允许的操作如下：
- add：将注册表、存储库或 tag/digest 附加到容器中的镜像。
- remove：从容器中的镜像中删除注册表、存储库或 tag/digest。
- replace：替换容器中镜像的注册表、存储库或 tag/digest。
比如我们需要创建一个如下所示的 Deployment 对象：
当工作负载传播到特定集群时添加注册表，可以使用如下所示的 OverridePolicy 对象：
上面的覆盖规则表示添加 test-repo 这个镜像仓库到 myapp 的镜像中，这样在传播到集群时就会变成 test-repo/myapp:1.0.0。
replace 和 remove 操作也是类似的，只是分别用于替换和删除镜像中的某些字段。
跨集群弹性伸缩
在 Karmada 中，我们可以使用 FederatedHPA 来实现跨多个集群扩展/缩小工作负载的副本，旨在根据需求自动调整工作负载的规模。
FederatedHPA
当负载增加时，如果 Pod 的数量低于配置的最大值，则 FederatedHPA 扩展工作负载（例如 Deployment、StatefulSet 或其他类似资源）的副本数。当负载减少时，如果 Pod 的数量高于配置的最小值，则 FederatedHPA 缩小工作负载的副本数。
FederatedHPA 是作为 Karmada API 资源和控制器实现的，该资源确定了控制器的行为。FederatedHPA 控制器运行在 Karmada 控制平面中，定期调整其目标（例如 Deployment）的所需规模，以匹配观察到的指标，例如平均 CPU 利用率、平均内存利用率或任何其他自定义指标。
FederatedHPA实现原理
为了实现跨集群的自动扩缩容，Karmada 引入了 FederatedHPA 控制器和 karmada-metrics-adapter，它们的工作方式如下：
- HPA 控制器定期通过指标 API metrics.k8s.io 或 custom.metrics.k8s.io 使用标签选择器查询指标。
- karmada-apiserver 获取指标 API 查询结果，然后通过 API 服务注册将其路由到 karmada-metrics-adapter。
- karmada-metrics-adapter 将从目标集群（Pod 所在的集群）查询指标。收集到指标后，它会对这些指标进行聚合并返回结果。
- HPA 控制器将根据指标计算所需的副本数，并直接扩展/缩小工作负载的规模。然后，karmada-scheduler 将这些副本调度到成员集群中。
注意：要使用此功能，Karmada 版本必须为 v1.6.0 或更高版本。
下面我们就来演示如何使用 FederatedHPA 控制器来实现跨集群的自动扩缩容。首先至少需要两个成员集群，我们需要在成员集群中安装 ServiceExport 和 ServiceImport 来启用多集群服务。在 Karmada 控制平面上安装 ServiceExport 和 ServiceImport 后（init 安装后会自动安装），我 们可以创建 ClusterPropagationPolicy 将这两个 CRD 传播到成员集群。
直接应用该 ClusterPropagationPolicy 对象即可：
应用后就可以在 member1 和 member2 集群中创建 ServiceExport 和 ServiceImport 对象了。
另外我们还需要为成员集群安装 metrics-server 来提供 metrics API，通过运行以下命令来安装：
最后我们还需要在 Karmada 控制平面中安装 karmada-metrics-adapter 以提供指标 API，通过运行以下命令来安装它：
需要注意使用 karmada init 安装的 Karmada 控制平面，需要将 karmada-cert 这个 Secret 对象重新拷贝创建一个名为 karmada-cert-secret 的 Secret 对象。
部署后在 Karmada 控制平面中就会有 karmada-metrics-adapter 这个 Pod 对象。
接下来我们在 member1 和 member2 中部署 Deployment（1 个副本）和 Service 对象，如下所示：
直接应用上面的资源对象即可：
然后让我们在 Karmada 控制平面中部署一个 FederatedHPA 对象，用来自动扩缩容，如下所示：
上面的 FederatedHPA 对象中，我们指定了 scaleTargetRef 字段为 Deployment 对象 nginx，minReplicas 和 maxReplicas 分别为 1 和 10，metrics 字段中指定了 CPU 利用率为 10% 时进行扩缩容。同样直接应用该 FederatedHPA 对象即可：
我们还需要一个多集群服务将请求路由到 member1 和 member2 集群中的 pod。首先在 Karmada 控制平面上创建 ServiceExport 对象，然后创建 PropagationPolicy 以将 ServiceExport 对象传播到 member1 和 member2 集群。
然后在 Karmada 控制平面上创建 ServiceImport 对象，然后创建 PropagationPolicy 以将 ServiceImport 对象传播到 member1 集群。
直接应用上面的资源对象即可：
部署完成后，可以查看多集群服务：
接下来我们在 member1 集群使用 hey 工具来进行 http 负载测试，模拟请求增加，从而触发 Pod 的 CPU 使用率增加：
然后我们可以使用 hey 请求多集群服务以增加 nginx pod 的 CPU 使用率。
等一会儿，副本就会开始扩容了，我们可以查看 FederatedHPA 对象的状态来了解副本的变化：
同时可以查看 member1 和 member2 集群中的 Pod 对象：
可以看到 Pod 的副本数已经扩容到 10 个了。同样当负载测试结束后，Pod 的副本数会自动缩小为 1 个副本。
到这里我们就完成了使用 FederatedHPA 进行跨集群的自动扩缩容，除此之外我们还可以使用 CronFederatedHPA 用于定期自动缩放操作，它可以缩放具有 scale 子资源的工作负载或 Karmada FederatedHPA。典型的场景是在可预见的流量高峰到来前提前扩容工作负载。例如，如果我知道每天早上 9 点会突发流量洪峰，我们就可以提前半个小时扩容相关服务，以处理高峰负载并确保服务持续可用性。在 Karmada 控制平面内运行的 CronFederatedHPA 控制器根据预定义的 cron 计划来伸缩工作负载的副本或 FederatedHPA 的最小/最大副本数。
比如我们有一个如下所示的 CronFederatedHPA 对象：
其中表达式 */1 * * * * 的意思是 nginx deployment 的副本应该每分钟更新为 5 个，确保了处理接下来的流量突发流量洪峰。
除了这些使用场景之外，Karmada 还有很多实践场景，比如跨集群的灾备、多集群网络、多集群服务治理、多集群 CI/CD 等等，这些场景都可以通过 Karmada 来实现，更多最佳实践方案可以参考 Karmada 官方文档以了解更多。
参考链接：https://karmada.io/zh/docs/。
