Easily Manage your Application Shipment With Differentiated Configuration in Multi-Cluster
Wei Duan
KubeVela TeamUnder 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.
#
Before Starting- 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.
#
Distribute to Multiple Specified ClustersDistributing 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 Basic.yaml
:
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 topology
policy.
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:
We use 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.
#
Use Cluster Labels to Do GroupingIn 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 topology-aws
:
In order save your time, please deploy intermediate.yaml
directly:
Review the status of the application again:
#
Differentiated ConfigurationApart 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 override
policy:
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 advanced.yaml
:
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.