KubeVela v1.3 多集群初体验,轻松管理应用分发和差异化配置

本文涉及的产品
云原生网关 MSE Higress,422元/月
可观测监控 Prometheus 版,每月50GB免费额度
函数计算FC,每月15万CU 3个月
简介: KubeVela v1.3 在之前的多集群功能上进行了迭代,本文将为你揭示,如何使用 KubeVela 进行多集群应用的部署与管理,实现以上的业务需求。

作者:段威(段少)


在当今的多集群业务场景下,我们经常遇到的需求有:分发到多个指定集群、按业务规划实现分组分发、以及对多集群进行差异化配置等等。


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 正式版

https://kubevela.net/zh/docs/install

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
5月前
|
运维 监控 Kubernetes
kubevela可观测体系问题之KubeVela 的面向应用监控界面的问题如何解决
kubevela可观测体系问题之KubeVela 的面向应用监控界面的问题如何解决
|
5月前
|
运维 Prometheus Kubernetes
kubevela可观测体系问题之KubeVela 的可观测性能力通过插件机制进行扩展的问题如何解决
kubevela可观测体系问题之KubeVela 的可观测性能力通过插件机制进行扩展的问题如何解决
|
5月前
|
Prometheus 运维 监控
kubevela可观测体系问题之KubeVela的用户在描述应用时加入可观测的配置的问题如何解决
kubevela可观测体系问题之KubeVela的用户在描述应用时加入可观测的配置的问题如何解决
|
存储 Prometheus Kubernetes
阿里 sealer 是如何实现整个集群一键交付的?
顾名思义,和操作系统 .iso 镜像或 Docker 镜像类似,集群镜像是用一定的技术手段把整个集群的所有文件以一定格式打成的一个资源包。
1302 0
阿里 sealer 是如何实现整个集群一键交付的?
|
7月前
|
Kubernetes 容器
KubeVela中,KubeVela 的自定义工作流具体是通过什么机制来实现的呢
KubeVela中,KubeVela 的自定义工作流具体是通过什么机制来实现的呢【1月更文挑战第25天】【1月更文挑战第122篇】
110 1
|
JSON 运维 Prometheus
让应用交付和管理统一:KubeVela 亮点功能及核心技术回顾
让应用交付和管理统一:KubeVela 亮点功能及核心技术回顾
11790 0
让应用交付和管理统一:KubeVela 亮点功能及核心技术回顾
|
运维 Kubernetes Cloud Native
应用纳管和灰度发布:谐云基于 KubeVela 的企业级云原生实践
谐云通过类比事务的方式,将渲染过程分为正向和逆向,同时将首次纳管和真正的纳管动作进行了分离,完成了平台升级的同时,给应用的纳管行为留下了一定的可操作空间。
应用纳管和灰度发布:谐云基于 KubeVela 的企业级云原生实践
|
运维 Kubernetes Cloud Native
利用 Rainbond 云原生平台简化 Kubernetes 业务问题排查
Kubernetes 已经成为了云原生时代基础设施的事实标准,越来越多的应用系统在 Kubernetes 环境中运行。Kubernetes 已经依靠其强大的自动化运维能力解决了业务系统的大多数运行维护问题,然而还是要有一些状况是需要运维人员去手动处理的。那么和传统运维相比,面向 Kubernetes 解决业务运维问题是否有一些基本思路,是否可以借助其他工具简化排查流程,就是今天探讨的主题。
|
边缘计算 Prometheus 运维
OpenYurt v1.2 新版本深度解读(三):五步搭建一个OpenYurt集群
OpenYurt v1.2 新版本深度解读(三):五步搭建一个OpenYurt集群
OpenYurt v1.2 新版本深度解读(三):五步搭建一个OpenYurt集群
|
运维 Cloud Native API
KubeVela 插件指南:轻松扩展你的平台专属能力
本文作者为 KubeVela 社区贡献者 姜洪烨。 我在原文基础上做了适量修改。KubeVela 插件(addon)可以方便地扩展 KubeVela 的能力。正如我们所知,KubeVela 是一个微内核高度可扩展的平台,用户可以通过 模块定义(Definition)扩展 KubeVela 的系统能力,而 KubeVela 插件正是方便将这些自定义扩展及其依赖打包并分发的核心功能。不仅如此,Kube
KubeVela 插件指南:轻松扩展你的平台专属能力