从 Kubefed 迁移

从 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 进行了大量扩展以满足他们的需求。所以，要维护一个通用的工具来满足大多数用户的需求可能是相当困难的。

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