企业官网建设流程全解析

如果你手上同时跑着三套五套 Kubernetes 集群，你就会明白什么叫“单机一时爽，多集群火葬场”。我最早对多集群管理的诉求特别朴素：最好有一个入口能让我像操作单集群一样操作所有集群。后来我把目光落在 Karmada 生态上，尤其是 Karmada One 这套封装之后，这个诉求算是真正落地了。Karmada One 不是把 Kubernetes 又包一层，而是把分散在多集群里的调度、分发、故障转移统一收敛到一个控制面里，让你在写资源清单时基本不用关心它最终落在哪。

这篇文章我会从自己的上手角度，把 Karmada One 的原理、部署路径、实际使用中的坑都过一遍。无论你是刚开始接触多集群，还是已经在用其他方案想对比一下，应该都能找到一些可用的东西。我不会把它写得像产品说明书，更想还原一个真实的折腾过程，包括那些让人挠头的问题。

1. 多集群管理的真实痛点，以及 Karmada One 的切入点

1.1 为什么我最终还是上了多集群

很多人觉得多集群是规模很大的公司才需要考虑的事，但实际情况是：只要有资源隔离、可用区容灾、或者不同环境独立运维的需求，集群数量就会很快涨起来。我见过一个不算大的团队，手里已经有开发集群、测试集群、预发集群、生产主集群、生产灾备集群，一共五套。每套集群的版本、插件、网络方案都略有差别，发布时要对每套集群单独执行一遍命令，监控要重复配置，权限要重复管理。

这种“复制粘贴式运维”一开始还能忍，等业务多起来就会出现典型的配置漂移：某套集群少了一个标签，另一套集群的镜像仓库地址写错了，还有一套集群因为版本太老用不了新的 API。问题不在某个集群本身，而在于“多个集群”这个事实没有被一个统一抽象接住。

多集群管理的核心不是省掉几个 kubectl 命令，而是把“多个集群的差异”变成可控的、显式的规则。Karmada One 恰好是走这条路：它把成员集群注册到一个控制面，所有对资源的操作都通过控制面发起，再由控制面按照策略分发下去。

1.2 Karmada One 究竟解决哪几层问题

先拆开看，Karmada One 帮我解决了三层问题。

第一层是入口统一。以前我要分别记住每套集群的 kubeconfig、context、命名空间规则，现在只需要一个 Karmada 控制面的 kubeconfig。通过它看的是一份“逻辑资源”，比如一个 Deployment，一个 Service。至于这个 Deployment 实际被分发到哪些集群，由策略决定。

第二层是资源定义统一。正常情况下，你只需要写一份资源模板，Karmada 会根据 PropagationPolicy 把它推给符合条件的集群。如果某个集群需要特殊副本数、特殊镜像地址，再用 OverridePolicy 做覆盖。这样既避免了每个集群维护一套 YAML，也不会因为“模板一份、实际一份”而漂移。

第三层是故障处理统一。成员集群失联、节点异常、资源不可用，这些状态会由控制面统一汇总。配合自动故障转移策略，业务可以在其他健康集群上重新拉起。对我来说，这套机制把“容忍成员集群故障”从人工操作变成了声明式配置。

1.3 适合谁，不适合谁

如果你的集群数量还在两套以下，并且两套集群完全隔离、各自运维，Karmada One 的收益确实不明显。引入 Karmada One 本身也有学习成本和控制面运维成本。

但如果你遇到下面几种情况，就值得认真评估：

• 多套集群需要跑同一套业务，希望一份清单完成发布。
• 有容灾诉求，希望某个集群故障时业务可以迁移到其他集群。
• 团队里不同人负责不同集群，但又想统一权限、统一审计入口。
• 开发测试环境想快速模拟“跨集群”效果。

不适合的情况也有：成员集群之间网络完全不可达，而且业务要求强一致跨集群读写；或者你的集群全是手工管理的特殊发行版，连标准 KubeConfig 都很难导出。这种情况先别急着上 Karmada One，把基础设施标准化才是优先事项。

2. 核心工作机制拆解：控制面、成员集群、资源模板与策略

2.1 控制面组件是怎么拼起来的

Karmada One 的控制面本质上是运行在一套 Kubernetes 集群上的控制器集合。它有自己的 API Server，有 etcd，有 controller-manager，有 scheduler，有 agent。你可以把它想象成“一个专门用来管理其他集群的集群”。

• karmada-apiserver：提供统一的 Kubernetes API 入口，外部的 kubectl 都是连接到它。
• karmada-controller-manager：监听资源模板和策略对象，负责在成员集群上创建、更新、删除实际资源。
• karmada-scheduler：根据传播策略、集群标签、资源可用性，决定某个工作负载应该被调度到哪些成员集群。
• karmada-agent：运行在成员集群侧，负责与控制面保持心跳，也负责执行控制面下发的任务。
• etcd：保存控制面的所有状态，包括集群注册信息、资源模板、策略和事件。

这套结构和 Kubernetes 原生控制器的思路一致：声明期望状态，控制器不断调和当前状态。区别在于，这里的“期望状态”是跨集群的，而“当前状态”分布在多个集群里。

2.2 资源模板：用户只写一份

在 Karmada One 里，你向控制面提交的不再是“某个集群的 Deployment”，而是一个资源模板。这个模板与普通 Kubernetes 里的 Deployment、Service、ConfigMap 长得一模一样，唯一的区别是它被提交到了 Karmada 控制面，而不是某个成员集群。

控制面收到模板后，并不会立刻把它落地到所有集群，而是等策略对象出现。这样设计的好处是：资源的“定义”和“分发”解耦了。你可以先定义资源，再决定哪些集群能用、哪些集群不能用，甚至后续调整分发范围时不需要改业务 YAML。

资源模板的另一个价值是单一事实来源。以前同一份 Deployment 可能在每个集群里各有各的历史，时间一长没人说得清哪份是基准。现在基准就是控制面里的这份模板，成员集群上的实际资源只是它的“投影”。

2.3 PropagationPolicy 和 OverridePolicy：分发与差异

分发逻辑主要靠两种策略对象。

PropagationPolicy 决定“这个资源发给谁”。它通过 resourceSelectors 选择要分发的资源，通过 placement 描述集群亲和性、集群污点容忍、资源优先级等调度约束。比如我要求一个 Deployment 必须同时跑在集群 A 和集群 B，就可以在 clusterAffinity 里列出这两个集群的名字。

OverridePolicy 决定“发给不同集群时，做什么差异调整”。比如集群 A 是普通环境，副本数保持 2；集群 B 是生产环境，副本数要 3。又比如集群 B 需要把镜像仓库地址 prefix 替换成内网地址。这些差异写在一个 OverridePolicy 里，而不是复制两份 Deployment。

我在实际使用中最大的感受是：策略把“环境差异”显式化了。以前环境差异分散在各套集群的 YAML 里，现在集中在策略规则里，出了问题很容易通过审计找到规则来源。

2.4 从“调度”角度看多集群

Karmada 的调度器与 Kubernetes 原生调度器类似，但它面对的对象不是“节点”，而是“成员集群”。调度器会看每个集群的资源是否充足、标签是否匹配、污点是否容忍、负载数据是否正常，然后决定把工作负载放到哪个集合里。

这一点是实现“像单机”的关键。单机操作时你不考虑节点归属，Kubernetes 帮你调度；多集群操作时你也不应该考虑集群归属，而应该由 Karmada 帮你调度。实际落地时，你可以给集群打上 region、env、team 这类标签，然后在策略里写“我只想让属于 region=cn 的集群跑这个业务”，剩下的集群选择交给调度器。

我也把 Karmada One 的调度模型理解为“集群级亲和性”。它不会接管成员集群内部如何调度 Pod 到节点，只需要决定资源分发到哪些集群。成员集群内部的调度依然是原生 Kubernetes 行为。两者之间是清晰的分工，不是互相覆盖。

3. 从零开始跑通 Karmada One 的完整记录

3.1 环境准备与版本选择

动手之前先把环境想清楚。我建议至少准备三套 Kubernetes 集群：一套用来部署 Karmada 控制面，两套作为成员集群。如果条件有限，也可以先用一套集群承载控制面，再在同一套集群上用 kind 创建两个模拟集群做验证。

版本上要注意：成员集群的 Kubernetes 版本不要和 Karmada 控制面差距太大。Karmada 社区一般会同时兼容最近几个 Kubernetes 版本，但如果你用的是某个发行版自带的特殊版本，最好先在测试环境验证一下 API 兼容性。实际操作时，我会先用“和线上版本一致的 kind 集群”把整套流程跑一遍，再决定要不要动线上。

工具方面需要准备：

• karmadactl 命令行工具，版本要和 Karmada 控制面相匹配。
• kubectl，用于连接控制面 API。
• 一套可用的 kubeconfig，能访问所有成员集群。

3.2 初始化控制面

初始化 Karmada 控制面最直接的方式是使用 karmadactl init。它会在一套集群里创建 Karmada 相关的命名空间、控制器、etcd 和 apiserver，并生成一个独立的 kubeconfig 文件供外部访问。

以我使用的版本为例，类似这样：

# 使用本地的 kubeconfig 作为控制面所在集群的身份 karmadactl init \ --kubeconfig="$HOME/.kube/config" \ --etcd-replicas=1 \ --etcd-storage-mode=emptyDir \ --host-cluster-kubeconfig="$HOME/.kube/config"

注意：etcd-replicas=1 和 emptyDir 只适合测试环境，生产环境至少要用三副本 etcd，并且配合持久化存储。我在第一次跑的时候为了省事用了单副本，后来模拟 etcd 故障，发现控制面读取状态直接超时，才意识到控制面自身的高可用同样不能省。

初始化完成后，karmadactl 会打印出控制面 kubeconfig 的位置，一般是/etc/karmada/karmada-apiserver.config。后续所有操作都用它。

3.3 纳管成员集群

成员集群不需要安装任何 agent，只要控制面能通过 kubeconfig 访问它。纳管命令大致是：

karmadactl join cluster-mem1 \ --kubeconfig=/etc/karmada/karmada-apiserver.config \ --cluster-kubeconfig="$HOME/.kube/config"

这里--kubeconfig指向 Karmada 控制面，--cluster-kubeconfig指向待纳管集群。我一次纳管了两套集群，分别叫 cluster-mem1 和 cluster-mem2。加入后可以通过控制面查看状态：

kubectl --kubeconfig=/etc/karmada/karmada-apiserver.config get clusters

如果成员集群状态显示 Ready，说明控制面和它之间的连通性没有问题。状态不 Ready 时，优先检查网络、证书、kubeconfig 里的 server 地址是否可从控制面访问。

3.4 部署第一个跨集群应用

我希望把一个 Deployment 同时分发到两个成员集群。先在控制面上提交一份普通 Deployment：

apiVersion: apps/v1 kind: Deployment metadata: name: demo labels: app: demo spec: replicas: 2 selector: matchLabels: app: demo template: metadata: labels: app: demo spec: containers: - name: demo image: nginx:stable

直接 apply 这份 YAML 后，控制面只是把它存了下来，成员集群上什么都不会发生。必须再创建一个 PropagationPolicy：

apiVersion: policy.karmada.io/v1alpha1 kind: PropagationPolicy metadata: name: demo-pp spec: resourceSelectors: - apiVersion: apps/v1 kind: Deployment name: demo placement: clusterAffinity: clusterNames: - cluster-mem1 - cluster-mem2

apply 之后，Karmada 控制器看到策略选中了这份资源，就会把 Deployment 推送到两个集群。接下来看看实际状态：

kubectl --kubeconfig=/etc/karmada/karmada-apiserver.config get deployment demo

这个命令仍然是在 Karmada 控制面视角看的，但你会发现 Karmada 会额外展示它被分发到了哪些集群，以及每个集群上的状态。如果需要差异化，比如 cluster-mem2 要跑 3 个副本，再加一个 OverridePolicy：

apiVersion: policy.karmada.io/v1alpha1 kind: OverridePolicy metadata: name: demo-op spec: resourceSelectors: - apiVersion: apps/v1 kind: Deployment name: demo overrideRules: - targetCluster: clusterNames: - cluster-mem2 overriders: plaintext: - path: "/spec/replicas" operator: replace value: 3

这是我的经验：把差异化选择放到 OverridePolicy 里，比在多个集群手工改 YAML 更便于回归。唯一要注意的是，多个 OverridePolicy 同时命中同一资源时，执行顺序可能影响结果，需要提前规划策略名称和优先级。

3.5 验证分发和故障转移

验证分发最简单的方式是直接看两个成员集群上是否都有 demo Pod：

kubectl --kubeconfig=$HOME/.kube/config-cluster1 get pods -n default kubectl --kubeconfig=$HOME/.kube/config-cluster2 get pods -n default

再把 cluster-mem1 故意停掉，比如中断它与控制面的网络连接，观察 Karmada 控制面上集群状态的变化。如果配置了故障转移策略，控制面会在一定时间后把 demo 在 cluster-mem2 上重新调度或扩容，保证整体副本数满足预期。

这里有个容易误解的点：Karmada 不会在业务层保持强一致状态，它更像是在“集群数量”这个维度上做容灾和调度。数据库这类有状态应用不能直接拿它做主从切换，需要搭配其他方案。无状态应用、批处理任务、Web 服务这类场景，非常适合用 Karmada 做故障转移。

4. 让多集群“像单机”的几个关键设计

4.1 统一 API 入口带来多少便利

像操作单机一样操作多集群，最大前提是只有一个入口。Karmada One 把 karmada-apiserver 暴露出来，外部看它就是一个标准 Kubernetes API。你不需要给每套集群单独配 kubectl context，也不需要记住“这个应用在哪个集群”。

这种统一入口不只是方便，更重要的是权限可控。我可以只给开发者一个 Karmada 控制面的 RBAC 权限，让他能在逻辑层创建 Deployment，但看不到某个成员集群的物理节点信息。审计日志也从分散的多套集群汇聚到控制面，出了问题只需要查控制面的记录。

4.2 集群状态对使用者透明

Karmada One 会把成员集群的健康状态、资源水位、调度结果汇总到控制面的 API 里。你可以用 kubectl 查看集群对象，也可以把它接进监控系统。

集群状态透明以后，业务配置就可以做得更聪明。比如我的 PropagationPolicy 里写了 clusterAffinity 和资源优先级，调度器在某个集群资源不足时不会硬塞进去，而是自动把流量导向另一个集群。这跟单机场景下 Kubernetes 调度器把 Pod 调度到资源充足的节点是同一个逻辑。

4.3 策略驱动而非脚本驱动

过去多集群发布的常见做法是写一堆脚本：先遍历集群，再对每套集群执行 kubectl apply，最后等待 rollout。脚本流程一旦复杂，异常分支很难写全。比如某个集群 apply 失败，到底是继续还是中止？脚本不好回答。

Karmada One 把这些问题变成声明式策略：你想要什么状态，写清楚，控制器负责调和。成员集群临时不可用，控制器不会终止，而是不断重试并上报状态。这种“调和式”的体验很接近单机 Kubernetes 的运作方式，也是一种更健壮的运维模型。

5. 真实使用中的坑、排查链路和配套建议

5.1 纳管集群时 kubeconfig 权限不对

我第一次纳管集群时报了很多权限错误，查了半天发现成员集群的 kubeconfig 虽然本地能用，但里边的 token 对应的账号在成员集群上没有创建资源的权限。Karmada 需要管理成员集群里的 Deployment、Service、Namespace 等资源，所以这个身份至少要有足够的 namespace 级写权限。

排查链路可以这样走：

1. 先在本地用这个 kubeconfig 直接 apply 一个测试 Deployment，看是否成功。
2. 如果成功，再看 Karmada 控制面所在机器能否访问成员集群的 apiserver 地址。
3. 如果网络没问题，再检查成员集群的 RBAC 绑定和 AggregatedRole 是否正常。
4. 最后看控制面里 karmada-agent 的日志，里面通常会给出具体的 HTTP 错误码。

这个坑的教训是：不要在控制面和成员集群之间用“最小权限”权限太小的凭据，也不要反过来用集群管理员凭据一把梭。最好创建一个专门用于多集群管理的 ServiceAccount，并绑定必要的权限。

5.2 资源冲突与覆盖策略互相打架

当多个 PropagationPolicy 或 OverridePolicy 都命中同一个资源时，Karmada 会用优先级和创建时间来做仲裁，但如果你在 OverridePolicy 里同时修改同一个字段，比如两个规则都改 replicas，最终结果会很难判断。我在测试环境就遇到过：集群 A 的副本数莫名其妙变成 5，查了半天发现是两个 OverridePolicy 的优先级设置不够克制。

我的建议是：给策略加上清晰的命名前缀，并且在 apply 之前先用kubectl get propagationpolicy和kubectl get overridepolicy看看当前策略列表，避免无意间重复命中。越是策略驱动，越要小心“策略的单一职责”。

5.3 跨集群网络的隐藏税

Karmada 只管分发和调度，不管成员集群之间的网络打通。如果业务需要跨集群访问 Service，你就得自己解决 DNS、ingress、负载均衡或者服务网格的问题。这一点最容易被忽略，因为“部署一个跨集群应用”听起来像“部署完了自动互通”。

实际使用中，我通常先把业务分成两类：一类是无状态应用，分发到多个集群后各自独立对外，不互相依赖；另一类是有主从关系或有状态应用，尽量不要跨集群互相访问，而是通过控制面或数据层中间件统一处理。Karmada One 解决的是“管理面”，不是“数据面跨集群网络”，这一点要摆正心态。

5.4 监控、审计和日常巡检怎么配套

Karmada 控制面本身也是一个 Kubernetes 集群，它承载着所有成员的调度状态，所以监控优先级其实很高。我建议至少监控这些指标：

• 控制面 apiserver 的 QPS、错误率、延迟。
• etcd 的磁盘占用和 leader 切换次数。
• 成员集群的 heartbeat 是否稳定。
• 调度失败的事件数量和原因。

另外，Karmada 的事件里藏着很多信息。比如某个 Deployment 调度失败，Karmada 会生成事件说明是资源不足、集群不健康，还是策略不匹配。巡检时不要只看资源状态，也要看事件流水。

6. 一些我觉得值得坚持的配置习惯

6.1 小步走，不要一次纳管太多集群

我见过有人一开始就把十个集群全部纳管进来，结果策略还没想清楚，控制面刷屏式地产生调度失败事件。正确做法是先纳管两套集群，跑一个非核心业务，把策略、权限、监控链路都验证完，再逐步扩大范围。Karmada One 的抽象能帮你简化操作，但不会自动帮你定义“哪些业务适合多集群”，这个判断得自己来。

6.2 把策略当代码管理

PropagationPolicy 和 OverridePolicy 都是普通的 Kubernetes 资源，完全可以用 Git 管理。我给每个业务目录建了 policies 子目录，里面放 propagation、override、failover 三类配置。每次变更先走 review，再 apply 到控制面。这样做的好处是，几个月后回头看某条策略为什么这么写，Git 历史能给你答案。

6.3 关注故障演练

多集群不是部署完就完了，故障转移是否有效，必须通过演练验证。我会定期在测试环境把某个成员集群的网络断开，观察控制面是否在预期时间内把业务迁移到其他集群，同时检查监控告警是否及时。演练中发现的问题，往往就是线上事故的前兆。

我个人的体会是：Karmada One 的价值不是某个单点技术，而是一种思路上的转变——把多集群看作一个整体资源池，而不是一堆需要逐个拼接的独立集群。工具能帮你收敛入口和控制逻辑，但真正让多集群“像单机一样简单”的，是清晰的定义、克制的策略和持续的演练。只有这些配套齐全，你才能放心地把业务交到这套抽象之上。