Kamrada operator：新一代的 Karmada 管理方式

Karmada operator 是 Karmada 社区推出的新组件，它为用户提供了全新的 Karmada 生命周期管理的方式。用户可以在全局集群之上集中式来管理多个 Karmada，通过 CR 资源来控制 Karmada 的创建、升级和卸载。为用户运维和管理 Karmada 提供了极大的便捷。本文章重点是从用户的使用的角度来介绍 Karmada operator。

安装方式

目前社区提供了两种方式来安装 Karmada operator：

1. Helm 安装：
helm chart 的文件在 Karmada 社区仓库，clone 源代码到本地后运行以下命令在 karmada-system 命令空间安装 release 为 karmada-operator 的 chart 实例。

helm install karmada-operator -n karmada-system  --create-namespace ./charts/karmada-operator --debug

2. yaml 文件安装：
Karmada operator 需要访问本集群 kube-apiserver 来 watch CR 资源，所以需要提前准备本集群的 kubeconfig，这里我们使用 secret 资源来存储 kubeconfig 并挂载到 Karmada operator 的 pod 中。

kubectl create namespace karmada-systemkubectl create secret generic my-kubeconfig --from-file=$HOME/.kube/config -n karmada-system

安装 Karmada operator CRD 资源：

kubectl apply -f operator/config/crds

通过 yaml 源文件来创建 Karmada operator 工作负载：

kubectl apply -f operator/config/deploy/karmada-operator.yaml

创建之后，Karmada operator 的工作负载就会被创建并运行：

kubectl get po -n karmada-system
NAME                              READY  STATUS   RESTARTS  AGE
karmada-operator-5b7f485c5-g5lj5  1/1    Running  0         26s

02 创建 Karmada

Karmada operator 提供 Karmada 的 CR，它可以定义安装集群的连接信息。如果没有连接信息，Karmada operator 会默认在本集群来安装 Karmada。我们还可以通过这个 CR 来定义大部分 Kamrada 组件的配置，包括镜像，二进制执行参数，自定义 label 和 annotation 和启用 featuregate 等。

一个 Karmada CR 资源对应一个 Karmada 集群，它是命名空间级别的资源，它会在相同的命名空间下安装 Karmada 组件。下面是一个最简单 Karmada CR，它会在 test 的命令空间来创建一个默认配置的 Karmada 控制平面：

kubectl create namespace test
kubectl apply -f - <<EOF
apiVersion: operator.karmada.io/v1alpha1
kind: Karmada
metadata:
  name: karmada-demo
  namespace: test
EOF

大概等待 40 秒的时间后，Karmada 所有组件的 pod 都会正常地运行起来：

kubectl get po -n test
karmada-demo-aggregated-apiserver-587bc5c697-v27vb      1/1     Running   0          12s
karmada-demo-apiserver-55968d9f8c-mp8hf                 1/1     Running   0          35s
karmada-demo-controller-manager-64455f7fd4-stls6        1/1     Running   0          5s
karmada-demo-etcd-0                                     1/1     Running   0          37s
karmada-demo-kube-controller-manager-584f978bbd-fftwq   1/1     Running   0          5s
karmada-demo-scheduler-6d77b7547-hgz8n                  1/1     Running   0          5s
karmada-demo-webhook-6f5944f5d8-bpkqz                   1/1     Running   0          5s

03 升级 Karmada

一旦 Karmada 被创建，这个 CR 资源会被自动填充必要的默认值。升级 Karmada 是通过修改相关组件的镜像版本来达到升级 Karmada 的目的，下面例子是升级 Karmada 版本到 v1.5.0。当然也可以升级 etcd 和 karmada-apiserver 和 kube-controller-manager 的镜像版本。

kubectl patch karmada karmada-demo -n test --type merge -p '
{
  "spec": {
    "components": {
      "karmadaAggregatedAPIServer": {
        "imageTag": "v1.5.0"
      },
      "karmadaControllerManager": {
        "imageTag": "v1.5.0"
      },
      "karmadaScheduler": {
        "imageTag": "v1.5.0"
      },
      "karmadaWebhook": {
        "imageTag": "v1.5.0"
      }
    }
  }
}'

04 卸载 Karmada

删除 Karmada CR 是一个非常危险的操作，因为一旦 CR 被删除，Karmada 也会同时被销毁。所以请谨慎操作：

kubectl delete karmada karmada-demo -n test

自定义
Karmada CR 资源

上面的场景都基于 Karmada 最简配置，所安装出来的 Karmada 是默认的配置。但是 Karmada CR 是可配置的，我们可以按照自己的场景和需求来配置自定义的 Karmada。下面列举了比较常用的 user story：

设置 Karmada 组件的副本数：

Karmada 所有组件的副本数都是可配置的，默认情况是一个副本数，下面是将 etcd 的副本数伸缩到 3 个副本。

apiVersion: operator.karmada.io/v1alpha1
kind: Karmada
metadata:
  name: karmada-demo
  namespace: test
spec:
  components:
    etcd:
      local:
        replicas: 3

自定义 label 和 annotation：

所有 Karmada 组件的 label 和 annotation 也是可以自定义的，如果设置了自定义的 label 和 annotation，它们会被同时注入到 pod 和对应的 workload 资源中。

apiVersion: operator.karmada.io/v1alpha1
kind: Karmada
metadata:
  name: karmada-demo
  namespace: test
spec:
  components:
    karmadaAPIServer:
      labels:
        <custom-label-key>: <custom-label-value>
      annotations:
        <custom-annotation-key>: <custom-annotation-value>

在外部访问 Karmada APIServer：

默认的情况下，Karmada APIServer 对应的 service 类型是 ClusterIP，在集群外部是不能被访问的。Karmada operator 也提供了 NodePort 的 service 类型，这样在 Agent 模式下，member 集群下才可以连接到 Karmada 的控制平面上。

karmadaAPIServer:
  imageRepository: registry.k8s.io/kube-apiserver
  imageTag: v1.25.4
  replicas: 1
  serviceType: NodePort
  serviceSubnet: 10.96.0.0/12

在公有云或者一些复杂的网络环境下，需要通过额外的 DNS 或者 IP 地址来访问 karmada-apierver，可以将这些 SANs 提前加入到证书中：

karmadaAPIServer:
  imageRepository: registry.k8s.io/kube-apiserver
  imageTag: v1.25.4
  replicas: 1
  serviceSubnet: 10.96.0.0/12
  certSANs:
  - "kubernetes.default.svc"
  - "127.0.0.1"

Karmada 可选组件：

默认情况，Karmada operator 并不会安装 descheduler 和 search 组件。如果想要使用它们，需要在 CR 中显示配置，最简单的配置只需要定义一个结构体，它也会被自动填充默认值。下面是一个例子来开启 descheduler 组件。需要注意的是目前只支持 descheduler 可选组件。

apiVersion: operator.karmada.io/v1alpha1
kind: Karmada
metadata:
  name: karmada-demo
  namespace: test
spec:
  components:
    KarmadaDescheduler: {}

参与 Karmada
operator 的贡献

Karmada operator 是 Karmada 一个全新组件，已经发布第一个可用的版本。后续还会有更多的丰富的功能。如果您对此项目感兴趣或者您同时也正需要它，可以来 karmada 社区来贡献您的 PR，或者您有任何的需求和疑问，非常欢迎提出您的 issue。

代码仓库地址：https://github.com/karmada-io/karmada/tree/master/operator

本文作者

陈文

现任「DaoCloud 道客」云原生开发工程师