Under today's multi-cluster business scene, we often encounter these typical requirements: distribute to multiple specific clusters, specific group distributions according to business need, and differentiated configurations for multi-clusters.
KubeVela v1.3 iterates based on the previous multi-cluster function. This article will reveal how to use it to do swift multiple clustered deployment and management to address all your anxieties.
- Prepare a Kubernetes cluster as the control plane of KubeVela.
- Make sure KubeVela v1.3 and KubeVela CLI v1.3.0 have been installed successfully.
- The list of Kubeconfig from sub clusters that you want to manage. We will take three clusters naming beijing-1, beijing-2 and us-west-1 as examples.
- Download and combine with Multi-Cluster-Demo to better understand how to use the KubeVela multi-cluster capabilities.
Distributing multiple specified clusters is the most basic multi-cluster management operation. In KubeVela, you will use a policy called
topology to implement it. The cluster will be listed in the attribute
clusters, an array.
First let's make sure switching kubeconfig to the control plane cluster, go with
vela cluster join to include in the 3 clusters of Beijing-1, Beijing-2 and us-west-1:
Then open multi-cluster-demo, look into
It can be seen that this app uses the component of type
webservice and distributes 3 Deployments to beijing-1 and beijing-2 clusters through the
Please note that the premise of successfully distributing resource into managed clusters is that it must contain the exactly same namespace as control plane did. Since each cluster has the
default namespace by default, we won't be worry in this case. But suppose we change the namespace in
basic.yaml to be
multi-cluster, we will receive an error:
In future versions of KubeVela, we plan to support a comprehensive Authentication System, more convenient and more securely to: create namespaces in managed cluster through the hub cluster in quick moves.
After creating the sub cluster's namespace, come back to the control plane cluster to create the application and ship out resources:
vela status <App Name> to view detailed infos about this app:
Both the beijing-1 and beijing-2 have issued the corresponding resources, they also displayed external access IP addresses, and you can therefore make it public for your users.
In addition to the above basic need, we often encounter additional situations: cross-regional deployment to certain clusters, specify which cloud provider's cluster, etc. In order to achieve a similar goal, the
labels feature can be used.
Here, suppose the us-west-1 cluster comes from AWS, we must additionally apply to the AWS cluster. You can use the
vela cluster labels add command to tag the cluster. Of course, if there is more of AWS related clusters such as us-west-2, it will be handled as well after they were labeled:
Next we update the
basic.yaml to add an application policy
In order save your time, please deploy
Review the status of the application again:
Apart from above scenarios, we tend to have more application strategic needs, such as high availability of hoping to distribute 5 replicas. In this case, use the
At the same time, we hope that only AWS clusters can get high availability. Then we can expect KubeVela's workflow give us a hand. We use the following workflow: it aims to deploy this app by, first distributing to Beijing's clusters through the
deploy-beijing policy, then distributing 5 copies to clusters which were labeled as AWS:
Then we attach the above policy and workflow to
intermediate.yaml and make it to
Then deploy it, view the status of the application:
The above all are what we'd like to share with you for this time, thank you for reading and trying them out.
We invite you to explore KubeVela v1.3 for more to meet further complex requirements on business, such as dig deep in differentiated configurations to use
override application policy to either override all resources on one type or only certain specific components.