Please enable Javascript to view the contents

Kubevela 下的多集群应用

 ·  ☕ 7 分钟

Kubevela 目前处于 1.1 版本。通常，我们认为 1.x 的版本是相对稳定的，可以尝试引入生产。在不断地跟踪和学习过程中，也感受到 Kubevela 的一些好的地方，这是一篇小结性的文档。

1. Kubevela 能解决什么问题

  • 面向平台开发者

需要区分几个角色: 开发、运维、运维开发。开发面向的是业务需求，运维面向的是业务稳定，运维开发面向的是效率。运维开发提供各种各样的工具，打通开发和运维之间的壁垒，既要快速满足业务上线。又要保障业务稳定。

Kubevela 对开发和运维并没有太大吸引力，却能让运维开发耳目一新。因为，Kubevela 能显著提升团队的平台水平，直达主流梯队。

  • 应用生命周期的管理

Kubevela 提供了管理应用生命周期的解决方案，应用的定义 applications，部署 appdeployments ，版本管理 applicationrevisions，回滚 approllouts，灰度 traits、approllouts。利用这些 CRD 对象，能够覆盖很大一部分业务需求。

  • 应用负载和特性的组件化

Component 提供的是负载的定义，比如 Deployment、CloneSet。Trait 提供的是特征的定义，比如 Ingress、Istio。通过这两种抽象，Kubevela 允许平台的开发者能够组装、定制适合自己业务的平台。

而 Workflow 提供的编排能力，给集成各种云原生组件增添了更多可能，甚至能延展到 CICD 领域。

2. 多集群下应用面临的挑战

  • 统一的视角

在面向应用的平台上，切换集群是一个非常糟糕的用户体验。我们需要的不是在每个集群上部署一套管理服务，然后通过修改数据源，查看不同集群上的数据。

我们应该以应用为中心，集群只是应用的一个属性，而不能将应用归属于某个集群。统一视角就是希望能够提供给用户一个 UI，包含完整的应用描述、所在运行时、实时服务画像等信息。

  • 应用的定义

世界上，没有两个平台团队对应用的定义是一样的。

一个应用应该包含哪些属性，哪些特征，对哪些字段进行哪些限制，很多的细节需要推敲和考虑。当然你也可以选择背负技术债务，将问题延后解决，快速交付几个版本。但却也是道阻且长，越来越难。

每个团队在定义应用时，都会附带一些业务属性。自救是不可能的，繁杂的业务需求不会给平台的开发者喘息之机。

因此，OAM 的出现是个机会，有机会统一应用生命周期管理 (ALM)。虽前有 Kubernetes Applications 死在了沙滩，但 Kubevela 犹如黑夜星光，给人无限希望。

  • 分批发布

分批发布有两个维度，单个集群中的多副本应用，多个集群中的同一个应用。

单个集群上的多副本，不会一次性更新，而是需要分批发布。这个过程，称之为 rollout，是一个逐步放量的过程。

多个集群或者多个区域的服务，在更新时，也需要观察时间，而不能一把就 show hand。

3. AppDeployment 下的多集群应用

这里主要是以 AppDeployment 作为主要对象，将应用在多个集群上进行发布。

  • 在主集群上添加多个子集群

需要在同一个 kubeconfig 配置多个集群的 context，然后按照官方文档操作即可。这里添加了两个集群 prod-cluster-1 和 prod-cluster-2 。下面是查看集群的命令:

1
2
3
4
5

kubectl get clusters.core.oam.dev

NAME             AGE
prod-cluster-1   57d
prod-cluster-2   57d
  • 定义 Application 应用

需要提前定义 components 和 traits，下面是应用的定义：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: cluster-test-app-cloneset
  namespace: default
  annotations:
    app.oam.dev/revision-only: "true"
spec:
  components:
    - name: helloworld-cloneset
      type: cloneset
      properties:
        image: oamdev/helloworld-python:v1
        env:
          - name: "TARGET"
            value: "KubeVela-v1"
        port: 8080
      traits:
        - type: expose-nodeport
          properties:
            ports:
              - protocol: "TCP"
                port: 80

由于有 app.oam.dev/revision-only: "true" 的 Annotations，因此相关的资源并不会被创建。我们在此只是定义应用，并不需要创建相应的负载。

  • 修改应用的版本，产生不同的应用版本

为了更加逼近生产环境，我们修改上面 Application 的参数，比如：环境变量、镜像版本等，产生不同的应用版本。

1
2
3
4
5
6

kubectl get applicationrevisions.core.oam.dev

NAME                  AGE
cluster-test-app-v1   57d
cluster-test-app-v2   57d
cluster-test-app-v3   57d

最终，分发到各个集群上的应用版本，由此产生。这些版本，大致相同而有细微差异，类似日常应用更新。

  • AppDeployment 多集群分发应用

AppDeployment 提供了一个更加贴近用户对应用理解的视角。应用不仅包含的是对应用的定义，还有对运行时的选择。这里将 cluster-test-app-v1 部署到 prod-cluster-1 集群，设置 3 个副本数量；而将 cluster-test-app-v2 部署到 prod-cluster-2 集群，设置 4 个副本数量。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

apiVersion: core.oam.dev/v1beta1
kind: AppDeployment
metadata:
  name: cross-cluster-app
  namespace: default
spec:
  appRevisions:
    - revisionName: cluster-test-app-v1
      placement:
        - clusterSelector:
            labels:
              env: stage
            name: prod-cluster-1
          distribution:
            replicas: 3

    - revisionName: cluster-test-app-v2
      placement:
        - clusterSelector:
            labels:
              env: production
            name: prod-cluster-2
          distribution:
            replicas: 4

4 Workflow 下的多集群应用

Workflow 是 Kubevela 近期版本新增的一个特性，在这里主要用来生成 OCM 需要的跨集群资源对象。

4.1 配置 Open Cluster Management (OCM)

  • 使用 vela 命令安装 Open Cluster Management
1

vela addon enable ocm-cluster-manager
  • 在主集群上添加多个子集群

需要在同一个 kubeconfig 配置多个集群的 context。在 dev1 集群上，添加 dev2 集群的 kubeconfig。

1
2
3
4
5

kubectl config get-contexts

CURRENT   NAME           CLUSTER              AUTHINFO                NAMESPACE
*         dev1-context   dev1.cluster.local   dev1-kubernetes-admin
          dev2-context   dev2.cluster.local   dev2-kubernetes-admin
  • 配置环境变量

使用 dev1(主集群) 管理 dev2(子集群) 。在主集群上，执行命令:

1
2
3
4

export HUB_CLUSTER_NAME=dev1
export MANAGED_CLUSTER_NAME=dev2
export CTX_HUB_CLUSTER=dev1-context
export CTX_MANAGED_CLUSTER=dev2-context
  • 查找添加子集群的 Token

在主集群上，执行命令:

1
2
3

clusteradm get token

xxxxxxxxxxxxxx

取出其中的 token 值，Base64 反解码，可以得到一个有效的 hub-token 值。

  • 添加子集群

这里的 hub-apiserver 就是主集群的 kube-apiserver 的访问地址。在主集群上，执行命令:

1

clusteradm join --context ${CTX_MANAGED_CLUSTER} --hub-token xxxxxxxxxxxxxx --hub-apiserver https://1.1.1.1:6443 --cluster-name ${MANAGED_CLUSTER_NAME}
  • 接受新的集群添加请求

在主集群上，执行命令:

1

clusteradm accept --clusters dev2
  • 查看被管理的集群

在主集群上，执行命令:

1
2
3
4

kubectl get managedcluster

NAME   HUB ACCEPTED   MANAGED CLUSTER URLS                JOINED   AVAILABLE   AGE
dev2   true           https://dev1.chenshaowen.com:6443   True     True        3m38s
  • 在被管理的集群上安装 Kubevela rollout

在子集群上，执行命令:

helm repo add kubevela https://charts.kubevela.net/core
helm install vela-rollout  --create-namespace -n vela-system kubevela/vela-rollout

4.2 新建 WorkflowStepDefinition 描述跨集群资源

在主集群使用 Workflow 将跨集群的资源定义在 WorkflowStepDefinition 中。下面是需要用到的资源之一:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

apiVersion: core.oam.dev/v1beta1
kind: WorkflowStepDefinition
metadata:
  name: dispatch-traits
  namespace: vela-system
spec:
  schematic:
    cue:
      template: |
        import ("vela/op")

        comp: op.#Load & {
           component: parameter.component
        }

        apply: op.#Apply & {
            value: {
                apiVersion: "work.open-cluster-management.io/v1"
                kind: "ManifestWork"
                metadata: {
                   namespace: parameter.cluster
                   name: parameter.component + "-traits"
                }
                spec: {
                   workload: manifests : comp.value.auxiliaries
                }
            }
        }


        parameter: {
          component: string
          cluster: string
        }

其中 ManifestWork 定义了分发到某个集群的配置和资源信息。这里只定义了 dispatch-traits，相应的我们还需要定义 dispatch-comp-rev。

分发资源的过程可以理解为，将待分发的资源打包成主集群上的 ManifestWork 对象，通过 OCM 分发到子集群的 AppliedManifestworks 对象，然后由子集群提取资源进行创建。

4.3 创建应用进行分发

这里使用 Application 在主集群 dev1 上定义一个应用，分发到子集群 dev2 上。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: workflow-rollout-demo
  namespace: default
spec:
  components:
    - name: nginx-server
      externalRevision: nginx-server-v1
      type: webservice
      properties:
        image: nginx:1.20.0
        port: 80
      traits:
        - type: rollout
          properties:
            targetRevision: nginx-server-v1
            targetSize: 2
            rolloutBatches:
              - replicas: 1
              - replicas: 1

  workflow:
    steps:
      - name: dispatch-comp-rev-v1
        type: dispatch-comp-rev
        properties:
           compRev: nginx-server-v1
           cluster: dev2

      - name: dispatchRollout
        type: dispatch-traits
        properties:
          component: nginx-server
          cluster: dev2

在 OCM 多集群应用的场景下，子集群需要部署 Kubevela rollout 组件。因此，Kubevela 能够更精细地控制子集群 rollout 过程，比如滚动过程中每个批次的比例和数量等。

4.4 可能会碰到的问题

  • OCM 在子集群创建资源时报错
E0905 14:36:23.461052       1 base_controller.go:270] "ManifestWorkAgent" controller failed to sync "nginx-server-traits", err: rollouts.standard.oam.dev "nginx-server" is forbidden: User "system:serviceaccount:open-cluster-management-agent:klusterlet-work-sa" cannot get resource "rollouts" in API group "standard.oam.dev" in the namespace "default"

提示是权限不够，在子集群上，直接给 klusterlet-work-sa 绑定了一个 admin 权限。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: admin-ocm
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
subjects:
  - kind: ServiceAccount
    name: klusterlet-work-sa
    namespace: open-cluster-management-agent

5. 总结

本篇主要讨论的是 Kubevela 在多集群下的应用，主要内容如下:

  • 多集群下的应用，不同于单集群，不能简单地切换数据源实现，其对交互设计有更高的要求。多集群应用平台需要有统一的视角，查看应用在多集群下的服务画像，以应用为中心，将集群当做属性，分清主次。
  • AppDeployment 是一个很好的抽象，也能给平台设计一些启发，还能看到一些 KubeFed 的身影。AppDeployment 是以用户视角呈现的多集群应用，但目前对 Workload 的处理粒度太大，面向的是整个 Application，也就是全量删除、更新、创建 Workload。如果用于生产，还需要配合 rollout 进行更新。
  • 借助 Workflow 集成 OCM 下的 Kubevela 多集群应用，更具扩展性，后续也可以换成其他多集群组件，比如 Karmada。利用 OCM 的分发能力，加上子集群上的 Kubevela rollout 组件，我们可以实现分批发布、滚动更新。

实际上，多集群下的应用，不仅仅需要考虑的是对应用描述的分发，更重要的还有负载的滚动更新、资源的统一分配、应用的智能调度、应用的自动扩缩容、服务的状态画像等。Kubevela 针对的是看得见的应用，但支撑起整个应用平台还需要更多底层组件。

6. 参考

微信公众号
作者
微信公众号

相关内容