Karmada 实战使用 PropagationPolicy 与 OverridePolicy 将 CRD 应用Guestbook分发到多集群【免费下载链接】karmadaOpen, Multi-Cloud, Multi-Cluster Kubernetes Orchestration项目地址: https://gitcode.com/GitHub_Trending/ka/karmada导读本文基于 Karmada 仓库中的 samples/guestbook 示例完整演示如何将一个由 CRD 定义的 Guestbook 应用从 Karmada 控制面分发到成员集群。你会学到如何在 Karmada 中注册 CRD、用ClusterPropagationPolicy传播 CRD 本身、用PropagationPolicy传播 CRD 实例、以及用OverridePolicy在成员集群侧对资源做差异化覆盖如把副本数从 2 改写为 4。全程使用kubectl即可操作无需修改 Karmada 任何源码。示例前置准备示例假定你已经部署好 Karmada 控制面karmada-apiserver并接入至少一个成员集群member1。目录与 kubeconfig 设置如下cd samples/guestbook export KUBECONFIG${HOME}/.kube/karmada.configkarmada.config是 Karmada 控制面的 kubeconfig后续所有写往karmada-apiserver的kubectl命令都依赖它成员集群的 kubeconfig 是${HOME}/.kube/members.config包含 member1、member2 等多个 context第 7 步验证覆盖结果时需要切换到member1context。本示例文件位于仓库 samples/guestbook 目录共包含 5 个 YAMLguestbooks-crd.yaml、guestbooks-clusterpropagationpolicy.yaml、guestbook.yaml、guestbooks-propagationpolicy.yaml、guestbooks-overridepolicy.yaml。第一步在 Karmada 中创建 Guestbook CRD首先把 CRD 应用到karmada-apiserverkubectl apply -f guestbooks-crd.yaml该 CRD 定义了一个名为guestbooks.webapp.my.domain的自定义资源关键结构见 guestbooks-crd.yaml字段类型说明spec.sizeinteger1~10必填实例数量本示例默认 2后续被 OverridePolicy 改写为 4spec.configMapNamestring长度 1~15必填Guestbook 配置对应的 ConfigMap 名称spec.aliasstringenumPhone / Address / Name别名status.active/status.standbystring / string[]运行状态观测字段scope: Namespaced表示该 CRD 是命名空间级资源这也是后面guestbook-sample能使用命名空间级PropagationPolicy与OverridePolicy的前提。注意此时 CRD 只存在于karmada-apiserver并不会自动出现在成员集群中——这正是下一步要解决的问题。第二步用 ClusterPropagationPolicy 把 CRD 传播到成员集群kubectl apply -f guestbooks-clusterpropagationpolicy.yaml该策略内容见 guestbooks-clusterpropagationpolicy.yamlapiVersion: policy.karmada.io/v1alpha1 kind: ClusterPropagationPolicy metadata: name: example-policy spec: resourceSelectors: - apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition name: guestbooks.webapp.my.domain placement: clusterAffinity: clusterNames: - member1它通过resourceSelectors精确命中刚才的 CRDapiextensions.k8s.io/v1/CustomResourceDefinition/guestbooks.webapp.my.domain并借助placement.clusterAffinity.clusterNames只分发到member1。为什么传播 CRD 只能用 ClusterPropagationPolicy而不能用 PropagationPolicy这是本示例反复强调的关键点。原因在于CRD 是**集群级cluster-scoped**资源PropagationPolicy是命名空间级策略只能作用于某个 Namespace 内的资源ClusterPropagationPolicy是集群级策略才能匹配并传播集群级资源如 CRD、Namespace、ClusterRole 等。从 Karmada API 定义 也可以印证ResourceSelector通过apiVersion、kind、namespace、name、labelSelector等字段来选择目标资源而PropagationPolicy的匹配范围天然被限定在自身所在 Namespace即resourceSelectors不显式写 Namespace 时继承父对象作用域因此无法覆盖集群级 CRD。Karmada 官方 FAQ 中也明确指出二者的适用差异详见 FAQPropagationPolicy 与 ClusterPropagationPolicy 的区别。第三步在 Karmada 中创建 Guestbook 实例kubectl apply -f guestbook.yaml实例内容见 guestbook.yamlapiVersion: webapp.my.domain/v1 kind: Guestbook metadata: name: guestbook-sample spec: size: 2 configMapName: test alias: Name它定义了名为guestbook-sample的 Guestbook初始size: 22 个实例。第四步用 PropagationPolicy 传播 guestbook-samplekubectl apply -f guestbooks-propagationpolicy.yaml策略内容见 guestbooks-propagationpolicy.yamlapiVersion: policy.karmada.io/v1alpha1 kind: PropagationPolicy metadata: name: example-policy spec: resourceSelectors: - apiVersion: webapp.my.domain/v1 kind: Guestbook placement: clusterAffinity: clusterNames: - member1这里的resourceSelectors只写了apiVersion和kind未写name与namespace——按 API 注释 的语义name缺省表示选择该 Kind 下的全部资源Namespace 缺省则继承父对象策略所在 Namespace作用域。因此guestbook-sample会被自动命中并分发到member1。从 Karmada 的控制器实现看这一步由 pkg/detector 中的资源探测器Resource Detector完成它持续监听 PropagationPolicy/ClusterPropagationPolicy 与目标资源为匹配的资源创建 ResourceBinding命名空间资源或 ClusterResourceBinding集群级资源随后由执行控制器把资源真正投递到成员集群。第五步从 Karmada 查看 guestbook-sample 状态kubectl get guestbook -oyaml在karmada-apiserver上执行可看到guestbook-sample已被 Karmada 纳管其.status如active/standby会由状态控制器从成员集群回传聚合status.subresources在 CRD 中已开启从而在控制面直接观察到跨集群应用的运行状态。第六步创建 OverridePolicy 覆盖 size 字段kubectl apply -f guestbooks-overridepolicy.yaml策略内容见 guestbooks-overridepolicy.yamlapiVersion: policy.karmada.io/v1alpha1 kind: OverridePolicy metadata: name: guestbook-sample spec: resourceSelectors: - apiVersion: webapp.my.domain/v1 kind: Guestbook overrideRules: - targetCluster: clusterNames: - member1 overriders: plaintext: - path: /spec/size operator: replace value: 4 - path: /metadata/annotations operator: add value: {OverridePolicy:test}它做了两件事用overriders.plaintext的replace操作把member1上guestbook-sample的/spec/size从 2 覆盖为 4用add操作给/metadata/annotations增加OverridePolicy: test注解。plaintext 覆盖器的底层实现plaintext覆盖器本质上是一组 JSON Patch 风格的path operator value指令。在 pkg/util/overridemanager/overridemanager.go 中parseJSONPatchesByPlaintext会把PlaintextOverrider列表转换为统一的overrideOption{Op, Path, Value}对应 pkg/apis/policy/v1alpha1/override_types.go 中的PlaintextOverrider类型随后applyJSONPatch基于evanphx/json-patch与go-openapi/jsonpointer将指令真正应用到 unstructured 对象上。从调用链看OverrideManager.ApplyOverridePolicies是核心入口pkg/util/overridemanager/overridemanager.go对集群级资源只应用ClusterOverridePolicy对命名空间级资源先应用ClusterOverridePolicy再按资源所在 Namespace 应用OverridePolicyapplyNamespacedOverrides会以rawObj.GetNamespace()为范围列出并匹配策略。示例中guestbook-sample是命名空间级资源因此命中了这个 OverridePolicy。同时targetCluster.clusterNames: [member1]限定了覆盖只对member1生效——这正是多集群差异化配置的核心价值不同集群可以各持不同的覆盖规则。第七步在成员集群验证覆盖结果kubectl --kubeconfig${HOME}/.kube/members.config config use-context member1 kubectl --kubeconfig${HOME}/.kube/members.config get guestbooks -o yaml如果一切正常member1上guestbook-sample的.spec.size会被覆盖为4且metadata.annotations中会出现OverridePolicy: test。与此同时karmada-apiserver上的原始guestbook-sample仍保持size: 2形成控制面模板 成员集群差异化的双视图。验证思路与排查提示确认成员集群已接入若guestbook-sample未出现在 member1先检查kubectl get clusters中 member1 是否Ready以及集群级资源CRD是否已成功传播确认策略命名空间一致PropagationPolicy、OverridePolicy与guestbook-sample需在同一个 Namespace示例均为default否则resourceSelectors无法命中覆盖顺序与优先级OverrideManager对命名空间级资源按先 ClusterOverridePolicy、后 OverridePolicy的顺序应用pkg/util/overridemanager/overridemanager.go多个命中的 OverridePolicy 按ResourceMatchSelectorsPriority排序后依次叠加后应用的覆盖会覆盖先前的值size 取值范围CRD schema 限定size最小 1、最大 10示例覆盖为 4 在合法范围内若覆盖值越界会被 API 校验拒绝。小结本示例通过 6 个kubectl命令完整走通了 Karmada 传播 CRD 应用的标准链路CRD 注册 → ClusterPropagationPolicy 传播 CRD → 创建实例 → PropagationPolicy 传播实例 → OverridePolicy 差异化覆盖 → 成员集群验证。核心要点可归纳为集群级资源CRD必须用ClusterPropagationPolicy命名空间级资源用PropagationPolicyPropagationPolicy/OverridePolicy与资源必须处于同一 Namespace 才能命中OverridePolicy的plaintext覆盖器基于 JSON Patch 语义支持replace、add等操作且可用targetCluster限定生效集群实现真正的多集群差异化分发。【免费下载链接】karmadaOpen, Multi-Cloud, Multi-Cluster Kubernetes Orchestration项目地址: https://gitcode.com/GitHub_Trending/ka/karmada创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考