从 Kubefed 迁移

Karmada 是在 Kubernetes Federation v1 和 Federation v2（也称为 Kubefed）的基础上开发的。 Karmada 继承了很多两者的概念。例如：

• 资源模板：Karmada 使用 Kubernetes 原生 API 定义用于联邦化的资源模板，使其易于与已采用 Kubernetes 的现有工具集成。
• 分发策略：Karmada 提供独立的 Propagation(placement) Policy API 来定义多集群调度和分发要求。
• 差异化策略：Karmada 提供了独立的 Override Policy API，专门自动化处理集群相关的配置。

Kubefed 的大多数功能都在 Karmada 进行了重塑，因此可以说 Karmada 是其自然继任者。

一般来说，从 Kubefed 迁移到 Karmada 很容易。 本文档概述了 Kubefed 用户的基本迁移路径。 注意：本文档正在编撰中，欢迎任何反馈。

集群注册

Kubefed 在 kubefedctl 命令行工具中提供 join 和 unjoin 命令，Karmada 也在 karmadactl 中实现了这两个命令。

请参阅 kubefed 集群注册和 Karmada 集群注册了解详情。

接入集群

假设您如下使用 kubefedctl 工具接入集群：

kubefedctl join cluster1 --cluster-context cluster1 --host-cluster-context cluster1

现在通过 Karmada，您可以用 karmadactl 工具达到同样的效果：

karmadactl join cluster1 --cluster-context cluster1 --karmada-context karmada 

join 命令背后的行为在 Kubefed 和 Karmada 中类似。 对于 Kubefed，它将创建一个 Kubefed 和 Karmada 所使用的 join 命令在后台具有类似的行为。 对于 Kubefed，此命令将创建一个对象， 而 Karmada 将创建一个 Cluster对象来描述所接入的集群。

检查接入集群的状态

假设您如下使用 kubefedctl 工具来检查接入集群的状态：

$ kubectl -n kube-federation-system get kubefedclusters

NAME       AGE   READY   KUBERNETES-VERSION
cluster1   1m    True    v1.21.2
cluster2   1m    True    v1.22.0

现在通过 Karmada，您可以用 karmadactl 工具达到同样的效果：

$ kubectl get clusters

NAME      VERSION   MODE   READY   AGE
member1   v1.20.7   Push   True    66s

Kubefed 管理着 PUSH 模式的集群，但是 Karmada 支持 PUSH 和 PULL 两种模式。 请参阅集群模式概述。

移除集群

假设您如下使用 kubefedctl 工具移除集群：

kubefedctl unjoin cluster2 --cluster-context cluster2 --host-cluster-context cluster1

现在通过 Karmada，您可以用 karmadactl 工具达到同样的效果：

karmadactl unjoin cluster2 --cluster-context cluster2 --karmada-context karmada 

在 Kubefed 和 Karmada 中 unjoin 命令后台的行为是类似的，都是通过移除集群对象从控制平面中移除集群。

分发工作负载到集群

假设您要将一个工作负载（deployment）分发到名为 cluster1 和 cluster2 的两个集群、 您可能需要将以下 yaml 部署到 Kubefed：

apiVersion: types.kubefed.io/v1beta1
kind: FederatedDeployment
metadata:
  name: test-deployment
  namespace: test-namespace
spec:
  template:
    metadata:
      labels:
        app: nginx
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
          - image: nginx
            name: nginx
  placement:
    clusters:
    - name: cluster2
    - name: cluster1
  overrides:
  - clusterName: cluster2
    clusterOverrides:
    - path: "/spec/replicas"
      value: 5
    - path: "/spec/template/spec/containers/0/image"
      value: "nginx:1.17.0-alpine"
    - path: "/metadata/annotations"
      op: "add"
      value:
        foo: bar
    - path: "/metadata/annotations/foo"
      op: "remove"

现在使用 Karmada，这个 yaml 可以拆分为 3 个 yaml，template、placement 和 overrides 各一个。

在 Karmada 中，模板不需要嵌入到 Federated CRD 中，它与 Kubernetes 的原生声明方式相同：

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

对于 placement 部分，Karmada 提供了 PropagationPolicy API 来保存放置规则：

apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: nginx-propagation
spec:
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      name: nginx
  placement:
    clusterAffinity:
      clusterNames:
        - cluster1
        - cluster2

PropagationPolicy 定义了哪些资源 (resourceSelectors) 应该被分发到哪里 (placement) 的规则。 参见资源分发了解更多细节。

对于 override 部分，Karmada 提供了 OverridePolicy API 来保存差异化规则：

apiVersion: policy.karmada.io/v1alpha1
kind: OverridePolicy
metadata:
  name: example-override
  namespace: default
spec:
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      name: nginx
  overrideRules:
    - targetCluster:
        clusterNames:
          - cluster2
      overriders:
        plaintext:
          - path: "/spec/replicas"
            operator: replace
            value: 5
          - path: "/metadata/annotations"
            operator: add
            value:
              foo: bar
          - path: "/metadata/annotations/foo"
            operator: remove
        imageOverrider:
          - component: Tag
            operator: replace
            value: 1.17.0-alpine

OverridePolicy 定义了哪些资源 (resourceSelectors) 在分发到哪里 (targetCluster) 时应该被覆盖的规则。

除了 Kubefed 之外，Karmada 还提供了各种替代方案来声明差异化规则，参见 Overrider了解更多细节。

FAQ

Karmada 会提供平滑迁移的工具吗？

我们还没有这个计划，因为我们接触了一些 Kubefed 用户，发现他们通常不使用 Vanilla Kubefed，而是使用克隆版本。 他们对 Kubefed 进行了大量扩展以满足他们的需求。 所以，要维护一个通用的工具来满足大多数用户的需求可能是相当困难的。

我们非常期待更多的反馈，请随时与我们联系，我们将乐意支持您完成迁移工作。