乐趣区

关于阿里云:KubeVela-v13-多集群初体验轻松管理应用分发和差异化配置

jiezi

作者：段威（段少）

在当今的多集群业务场景下，咱们常常遇到的需要有：散发到多个指定集群、按业务布局实现分组散发、以及对多集群进行差异化配置等等。

KubeVela v1.3 在之前的多集群性能上进行了迭代，本文将为你揭示，如何应用 KubeVela 进行多集群利用的部署与治理，实现以上的业务需要。

开始之前

  1. 筹备一个 Kubernetes 集群作为 KubeVela 的管制立体。
  2. 确保 KubeVela v1.3[1] 和 KubeVela CLI v1.3.0 曾经装置胜利。
  3. 你要治理的子集群列表 kubeconfig。咱们将以 beijing-1，beijing-2 和 us-west-1 这 3 个集群为例。
  4. 下载并联合 multi-cluster-demo[2] 来更好的了解，如何应用 KubeVela 多集群能力。

散发到多个指定集群

对多个指定集群进行散发是最根本的多集群治理操作。在 KubeVela 中，你将应用一个叫做 topology 的利用策略来实现它。集群以数组的模式，列在其属性的 clusters 字段里。
首先让咱们确保切换 KUBECONFIG 到筹备好的管控集群，应用 vela cluster join 将 beijing-1，beijing-2 和 us-west-1 这 3 个集群全副纳管进来：

➜   vela cluster join beijing-1.kubeconfig --name beijing-1
➜   vela cluster join beijing-2.kubeconfig --name beijing-2
➜   vela cluster join us-west-1.kubeconfig --name us-west-1
➜   vela cluster list
CLUSTER          TYPE             ENDPOINT                   ACCEPTED  LABELS
beijing-1        X509Certificate  https://47.95.22.71:6443   true
beijing-2        X509Certificate  https://47.93.117.83:6443  true
us-west-1        X509Certificate  https://47.88.31.118:6443  true

接着关上 multi-cluster-demo，查看 basic.yaml：

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: example-app
  namespace: default
spec:
  components:
    - name: hello-world-server
      type: webservice
      properties:
        image: crccheck/hello-world
        port: 8000
      traits:
        - type: scaler
          properties:
            replicas: 3
        - type: gateway
          properties:
            domain: testsvc-mc.example.com
            # classInSpec : true   如果你所下发的集群里有装置 v1.20 以下版本的 Kubernetes，请加上这个字段
            http:
              "/": 8000
  policies:
    - type: topology
      name: beijing-clusters
      properties:
        clusters: ["beijing-1","beijing-2"]

能够看到，这个利用应用了 webservice 类型的组件，最初通过 topology 的利用策略别离向 beijing-1 和 beijing-2 两个集群散发 3 正本 Deployment。

请留神，管控集群对子集群下发资源胜利的前提是，子集群必须有曾经新建的对应命名空间。因为每个集群默认都有 default 命名空间，所以能够失常下发。假如咱们将 basic.yaml 的命名空间改成 multi-cluster，则会收到报错：

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: example-app
  namespace: default
spec:
  components:
    - name: hello-world-server
      type: webservice
      properties:
        image: crccheck/hello-world
        port: 8000
      traits:
        - type: scaler
          properties:
            replicas: 3
        - type: gateway
          properties:
            domain: testsvc-mc.example.com
            # classInSpec : true   如果你所下发的集群里有装置 v1.20 以下版本的 Kubernetes，请加上这个字段
            http:
              "/": 8000
  policies:
    - type: topology
      name: beijing-clusters
      properties:
        clusters: ["beijing-1","beijing-2"]

在将来的 KubeVela 版本中，咱们将反对应用鉴权零碎，更便捷更平安的实现这项操作：通过管控集群一键在子集群创立命名空间。

实现子集群命名空间创立后，切回管控集群创立利用并下发资源：

➜   vela up -f basic.yaml
Applying an application in vela K8s object format...
"patching object" name="example-app" resource="core.oam.dev/v1beta1, Kind=Application"
✅ App has been deployed 🚀🚀🚀
    Port forward: vela port-forward example-app
             SSH: vela exec example-app
         Logging: vela logs example-app
      App status: vela status example-app

Service status: vela status example-app –svc hello-world-server


咱们通过 vela status < 利用名 > 查看服务相干信息：

➜ vela status example-app
About:
Name: example-app
Namespace: default
Created at: 2022-03-25 17:42:33 +0800 CST
Status: running
Workflow:
mode: DAG
finished: true
Suspend: false
Terminated: false
Steps

  • id:wftf9d4exj
    name:deploy-beijing-clusters
    type:deploy
    phase:succeeded
    message:

Services:

  • Name: hello-world-server
    Cluster: beijing-1 Namespace: default
    Type: webservice
    Healthy Ready:3/3
    Traits:
    ✅ scaler ✅ gateway: Visiting URL: testsvc-mc.example.com, IP: 60.205.222.30
  • Name: hello-world-server
    Cluster: beijing-2 Namespace: default
    Type: webservice
    Healthy Ready:3/3
    Traits:
    ✅ scaler ✅ gateway: Visiting URL: testsvc-mc.example.com, IP: 182.92.222.128


beijing-1 和 beijing-2 都下发了对应的资源，它们可供内部拜访的 IP 地址也显示进去，你因此能够用你心愿的形式供用户拜访了。## 应用集群 labels 按需分组散发

除了上述的基本操作，咱们经常会遇到另外的状况：跨地区部署到某些集群、指定哪个云厂商的集群等等。为了实现相似这样的需要，能够应用多集群的 labels 性能。在这里，假如 us-west-1 集群来自 AWS，咱们要额定散发利用到 AWS 的集群，则能够应用 vela cluster labels add 来对集群进行标记。当然，如果还有 us-west-2 等多个 AWS 相干集群，同样进行标记后，将会对立下发：

➜ ~ vela cluster labels add us-west-1 provider=AWS
Successfully update labels for cluster us-west-1 (type: X509Certificate).
provider=AWS
➜ ~ vela cluster list
CLUSTER TYPE ENDPOINT ACCEPTED LABELS
beijing-1 X509Certificate https://47.95.22.71:6443 true
beijing-2 X509Certificate https://47.93.117.83:6443 true
us-west-1 X509Certificate https://47.88.31.118:6443 true provider=AWS



接下来咱们对 basic.yaml 进行更新，新增一个利用策略 topology-aws：

…
policies:

- type: topology
  name: beijing-clusters
  properties:
    clusters: ["beijing-1","beijing-2"]
- type: topology
  name: topology-aws
  properties:
    clusterLabelSelector:
      provider: AWS

为了不便你学习，请间接部署基于 basic.yaml 更新后的 intermediate.yaml：

➜ ~ vela up -f intermediate.yaml


再次查看利用的状态：

➜ vela status example-app
…

  • Name: hello-world-server
    Cluster: us-west-1 Namespace: default
    Type: webservice
    Healthy Ready:3/3
    Traits:
    ✅ scaler ✅ gateway: Visiting URL: testsvc-mc.example.com, IP: 192.168.40.10


## 通过利用策略进行配置差异化

除了在 basic.yaml 里定义的 deploy-beijing 这种利用策略，咱们往往有更多的利用策略需要，比方高可用，心愿独自给某些资源散发 5 个正本。这样的话，应用 override 类型的利用策略即可：

…

    clusterLabelSelector:
      provider: AWS
-  type: override
   name: override-high-availability
   properties:
      components:
        - type: webservice
          traits:
          - type: scaler
            properties:
              replicas: 5


同时假如，咱们心愿的是，给 AWS 的利用散发并设置为高可用。那咱们能够应用 KubeVela 提供的专门用于定义过程管制的工作流来治理。咱们应用如下的一个工作流，它心愿将本次利用部署，首先通过 deploy-beijing 的利用策略，分发给北京的集群们，接着给 Label 为 AWS 的集群散发 5 个正本高可用的利用策略：

…

            properties:
              replicas: 5

workflow:

steps:
  - type: deploy
    name: deploy-beijing
    properties:
      policies: ["beijing-clusters"]
  - type: deploy
    name: deploy-aws
    properties:
      policies: ["override-high-availability","topology-aws"]


接着咱们给 intermediate.yaml 加上以上的利用策略和工作流后，更新为 advanced.yaml：

…
policies:

- type: topology
  name: beijing-clusters
  properties:
    clusters: ["beijing-1","beijing-2"]
- type: topology
  name: topology-aws
  properties:
    clusterLabelSelector:
      provider: AWS
-  type: override
   name: override-high-availability
   properties:
      components:
        - type: webservice
          traits:
          - type: scaler
            properties:
              replicas: 5

workflow:

steps:
  - type: deploy
    name: deploy-beijing
    properties:
      policies: ["beijing-clusters"]
  - type: deploy
    name: deploy-aws
    properties:
      policies: ["override-high-availability","topology-aws"]


而后对其进行部署，并再次查看利用的状态：

➜ vela up -f advanced.yaml
Applying an application in vela K8s object format…
“patching object” name=”example-app” resource=”core.oam.dev/v1beta1, Kind=Application”
✅ App has been deployed 🚀🚀🚀

Port forward: vela port-forward example-app
         SSH: vela exec example-app
     Logging: vela logs example-app
  App status: vela status example-app

Service status: vela status example-app –svc hello-world-serverapplication.core.oam.dev/podinfo-app configured

➜ vela status example-app
…

  • Name: hello-world-server
    Cluster: us-west-1 Namespace: default
    Type: webservice
    Healthy Ready:5/5
    Traits:
    ✅ scaler ✅ gateway: Visiting URL: testsvc-mc.example.com, IP: 192.168.40.10


以上就是本次的全副分享，感激你的浏览和试玩。欢送你持续摸索 KubeVela v1.3 正式版 [3]，这里有更多差异化配置的进阶用法等你发现和应用，比方 override 利用策略如何实现资源类型通配还是针对某些特定组件进行笼罩等等，以满足更加简单的场景需要。## 相干链接

[1] KubeVela v1.3
https://github.com/oam-dev/kubevela/releases/tag/v1.3.0

[2] multi-cluster-demo
https://github.com/oam-dev/samples/tree/master/12.Multi_Cluster_Demo

[3] 持续摸索 KubeVela v1.3 正式版
退出移动版