This section introduces how you deploy Helm Chart into multi-environments and clusters. Before start, make sure you have learned the basic helm chart delivery along with all addon enabled.
This section is preparation for multi-cluster, we will start from scratch for convenience. if you already have multi-clusters joined, you can skip this section.
- Install KubeVela control plane with velad
- Export the KubeConfig for the newly created cluster
- Enable velaux addon for UI console
- Create a cluster with velad named
- Join the created cluster to control plane
- Enable fluxcd addon for helm component
If you have already enabled the
fluxcd addon before you joined the new cluster, you should enable the addon for the newly joined cluster by:
Finally, we have finished all preparation, you can check the clusters joined:
One cluster named
local is the KubeVela control plane, another one named
foo is the cluster we just joined.
The basic mechanism for multi cluster delivery is almost the same with deploy container image.
We can use
topology policy to specify the delivery topology for helm chart like the following command:
clusters field of topology policy is a slice, you can specify multiple cluster names here.
You can also use label selector or specify namespace with that, refer to the reference docs for more details.
After deployed, you can check the deployed application by:
The expected output should be as follows if deployed successfully:
You can check the deployed resource by:
You can also check the deployed resource by VelaUX, it's already introduced in the basic helm delivery docs.
In some cases, we will deploy helm chart into different clusters with different values, then we can use the override policy.
Below is a complex example that we will deploy one helm chart into two clusters and specify different values for each cluster. Let's deploy it:
Note: If you feel the policy and workflow is a bit complex, you can make them as an external object and just reference the object, the usage is the same with the container delivery.
The deploy process has three steps: 1) deploy to local cluster; 2) wait for manual approval; 3) deploy to foo cluster. So you will find it was suspended after the first step, just like follows:
You can check the helm chart deployed in control plane with the value "Welcome to Control Plane Cluster!".
It will automatically prompt with your browser with the following page:
Let's continue the workflow as we have checked the deployment has succeeded.
Then it will deploy to the foo cluster, you can check the resources with detailed information:
Use port forward again:
Then it will prompt some selections:
Choose the option with cluster
foo, then you'll see the result that has was overridden with new message.
If you're using the
velaux UI console, you can get even more information with a unified experience for multi clusters.
- Check pod status and event from different clusters:
- Check pod logs from different clusters:
- Check resource topology and status:
You can choose different value file present in a helm chart for different environment. eg:
Please make sure your local cluster have two namespaces "test" and "prod" which represent two environments in our example.
We use the chart
hello-kubernetes-chart as an example.This chart has two values files. You can pull this chart and have a look all contains files in it:
As we can see, there are values files
values-production.yaml in this chart.
Access the endpoints of application:
If you choose
Cluster: local | Namespace: test | Kind: HelmRelease | Name: hello-kubernetes you will see:
If you choose
Cluster: local | Namespace: prod | Kind: HelmRelease | Name: hello-kubernetes you will see:
If you're using velad for this demo, you can clean up very easily by:
- Clean up the foo cluster
- Clean up the default cluster
Happy shipping with Helm chart!