Author: Duan Wei (Duan Shao)

In today’s multi-cluster business scenario, we often encounter requirements such as distribution to multiple designated clusters, group distribution according to the business plan, and differentiated configuration of multiple clusters, etc.

KubeVela V1.3 iterates on the previous multi-cluster functionality, and this article will show you how to use KubeVela for multi-cluster application deployment and management to achieve the above business requirements.

Prior to the start

  1. Prepare a Kubernetes cluster as the control plane for KubeVela.
  2. Ensure that KubeVela V1.3 [1] and KubeVela CLI v1.3.0 have been installed successfully.
  3. List of subsets you want to manage kubeconfig. We will take the three clusters of Beijing-1, Beijing-2 and US-West-1 as examples.
  4. Download and use multi-cluster-Demo [2] to better understand how to use KubeVela’s multi-cluster capabilities.

Distribute to multiple specified clusters

Distribution to multiple designated clusters is the most basic multi-cluster management operation. In KubeVela, you implement this using an application strategy called Topology. Clusters are listed as arrays in the Clusters field for their properties. First let’s make sure to switch KUBECONFIG to the prepared managed cluster and use Vela Cluster Join to manage all the clusters: beijing-1, Beijing-2 and US-West-1

➜ 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
Copy the code

Then open multi-cluster-Demo and check 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: true20For the following versions of Kubernetes, please add this field HTTP:"/": 8000
  policies:
    - type: topology
      name: beijing-clusters
      properties:
        clusters: ["beijing-1"."beijing-2"]
Copy the code

As you can see, the application uses a WebService-type component. Finally, the application policy of the Topology assigns 3 replica Deployment to clusters Beijing -1 and Beijing -2.

Note that the subgroup must have a new namespace before the managed cluster can successfully deliver resources to its subcluster. Each cluster has the default namespace by default. Therefore, this namespace can be delivered normally. If we change the basic.yaml namespace to multi-cluster, we get an error:

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: true20For the following versions of Kubernetes, please add this field HTTP:"/": 8000
  policies:
    - type: topology
      name: beijing-clusters
      properties:
        clusters: ["beijing-1"."beijing-2"]
Copy the code

In a future release of KubeVela, we will support the use of an authentication system to do this more easily and safely: create a namespace in a subset by managing the cluster with one click.

After the subgroup namespace is created, switch back to the managed cluster to create applications and deliver resources:

➜   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 ```css Service status: vela status example-app --svc hello-world-serverCopy the code

We use Vela status < application name > to check the service information:

➜   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
Copy the code

Beijing -1 and Beijing -2 both deliver the corresponding resources, and their IP addresses for external access are displayed, so you can make them accessible to users the way you want.

Use cluster Labels to group distribution as needed

In addition to the above basic operations, we often encounter other situations: deploying to some cluster across a geographical area, specifying which cloud vendor cluster, and so on. To implement a requirement like this, you can use the multi-cluster Labels feature.

In this case, assuming that the US-West-1 cluster is from AWS and we want to distribute additional clusters applied to AWS, we can use Vela Cluster Labels ADD to tag the clusters. Of course, if there are multiple AWS related clusters such as US-West-2, they will be issued uniformly after being marked:

➜ ~ 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
Copy the code

Next we update basic.yaml to add an application policy topology-aws:

. policies: - type: topology name: beijing-clusters properties: clusters: ["beijing-1"."beijing-2"]
    - type: topology
      name: topology-aws
      properties:
        clusterLabelSelector:
          provider: AWS
Copy the code

For your convenience, please directly deploy intermediate. Yaml based on basic.yaml update:

➜ ~ Vela up-f intermediate.yaml
Copy the code

Check the status of the application again:

➜ 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
Copy the code

Configure differentiation by applying policies

In addition to the deploy-Beijing application policy defined in basic.yaml, we tend to have more application policy requirements, such as high availability, and want to distribute five copies of certain resources separately. In this case, an application policy of type Override can be used:

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

Also assume that we want AWS applications to be distributed and set to high availability. Then we can use the workflow provided by KubeVela for defining process control. We use the following workflow, which wants to deploy this application to clusters in Beijing by first distributing the deploy-Beijing application policy, and then distributing 5 copies of the high availability application policy to the Label cluster for AWS:

. 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"]
Copy the code

We then added the above application policies and workflow to intermediate. Yaml and updated it to advance. 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"]
Copy the code

Then deploy it and check the status of the application again:

➜   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. The 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
Copy the code

That’s all we have to share. Thank you for reading and playing.

Welcome to explore the official version of KubeVela V1.3 [3]. There are more advanced uses of differentiated configuration that you can discover and use, such as how the Override application policy performs resource type matchmaking or overrides specific components to meet the requirements of more complex scenarios.

A link to the

[1] KubeVela v1.3 github.com/oam-dev/kub…

[2] multi – cluster – demo github.com/oam-dev/sam…

[3] Continue exploring KubeVela V1.3 kubevela.net/zh/docs/ins… Release the latest information of cloud native technology, collect the most complete content of cloud native technology, hold cloud native activities and live broadcast regularly, and release ali products and user best practices. Explore the cloud native technology with you and share the cloud native content you need.

Pay attention to [Alibaba Cloud native] public account, get more cloud native real-time information!