Chore: update helm chart delivery for multi-clusters
Signed-off-by: Jianbo Sun <jianbo.sjb@alibaba-inc.com>
This commit is contained in:
Jianbo Sun
parent
49ad1cbd4d
commit
260c667c5f
Binary file not shown.
|
After Width: | Height: | Size: 1.4 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 586 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 476 KiB |
|
|
@ -207,6 +207,8 @@ spec:
|
|||
EOF
|
||||
```
|
||||
|
||||
> **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](../case-studies/multi-cluster#use-policies-and-workflow-outside-the-application).**
|
||||
|
||||
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:
|
||||
|
||||
```
|
||||
|
|
@ -274,3 +276,59 @@ local ─── default ─┬─ HelmRelease/hello updated 2022-06-0
|
|||
Status: stored artifact for revision 'ab876069f02d779cb4b63587af1266464818ba3790c0ccd50337e3cdead44803'
|
||||
```
|
||||
|
||||
Use port forward again:
|
||||
|
||||
```shell
|
||||
vela port-forward helm-hello
|
||||
```
|
||||
|
||||
Then it will prompt some selections:
|
||||
|
||||
```
|
||||
? You have 2 deployed resources in your app. Please choose one: [Use arrows to move, type to filter]
|
||||
> Cluster: foo | Namespace: default | Kind: HelmRelease | Name: hello
|
||||
Cluster: local | Namespace: default | Kind: HelmRelease | Name: hello
|
||||
```
|
||||
|
||||
Choose the option with cluster `foo`, then you'll see the result that has was overridden with new message.
|
||||
|
||||
```console
|
||||
$ curl http://127.0.0.1:8080/
|
||||
...snip...
|
||||
<div id="message">
|
||||
Welcome to Your New Foo Cluster!
|
||||
</div>
|
||||
...snip...
|
||||
```
|
||||
|
||||
## More from UI console
|
||||
|
||||
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:
|
||||
|
||||
|
||||
|
||||
## Clean up
|
||||
|
||||
If you're using velad for this demo, you can clean up very easily by:
|
||||
|
||||
* Clean up the foo cluster
|
||||
```
|
||||
velad uninstall -n foo
|
||||
```
|
||||
|
||||
* Clean up the default cluster
|
||||
```
|
||||
velad uninstall
|
||||
```
|
||||
|
||||
Happy shipping with Helm chart!
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Multi-cluster Distribution
|
||||
title: Multi Cluster Distribution
|
||||
---
|
||||
|
||||
> This section requires you to know the basics about how to deploy multi-cluster application with policy and workflow. You can refer to [Multi-cluster Delivery](../../case-studies/multi-cluster) for container images, they're working in the same way.
|
||||
|
|
@ -11,7 +11,6 @@ You can reference and distribute existing Kubernetes objects with KubeVela in th
|
|||
- Using Kubernetes apiserver as the control plane and storing all Kubernetes objects data in external databases. Then dispatch those data into real Kuberenetes managed clusters.
|
||||
|
||||
|
||||
|
||||
### Refer to Existing Kubernetes Objects in Component
|
||||
|
||||
To use existing Kubernetes objects in the component, you need to use the `ref-objects` typed component and declare which resources you want to refer to. For example, in the following example, the secret `image-credential-to-copy` in namespace `examples` will be taken as the source object for the component. Then you can use the topology policy to dispatch it into hangzhou clusters.
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ This section will introduce the lifecycle of managed clusters.
|
|||
|
||||
KubeVela can generally adopt any Kubernetes cluster as managed cluster, the control plane won't install anything to your managed cluster unless you have enable any addons.
|
||||
|
||||
If you don't have any clusters, you can refer to [VelaD](https://github.com/kubevela/velad) to create one:
|
||||
If you don't have any clusters, you can refer to [VelaD](https://github.com/kubevela/velad/blob/main/docs/02.multicluster.md) to create one for demo:
|
||||
|
||||
```
|
||||
velad install --name <cluster-name> --cluster-only
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 54 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.4 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 586 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 476 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 276 KiB |
|
|
@ -0,0 +1,334 @@
|
|||
---
|
||||
title: Multi Cluster Delivery
|
||||
---
|
||||
|
||||
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](./helm) along with all addon enabled.
|
||||
|
||||
## Prepare Clusters
|
||||
|
||||
> This section is preparation for multi-cluster, we will start from scratch for convenience. if you already have [multi-clusters joined](../platform-engineers/system-operation/managing-clusters), you can skip this section.
|
||||
|
||||
1. Install KubeVela control plane with [velad](https://github.com/kubevela/velad)
|
||||
|
||||
```shell
|
||||
velad install
|
||||
```
|
||||
|
||||
2. Export the KubeConfig for the newly created cluster
|
||||
|
||||
```
|
||||
export KUBECONFIG=$(velad kubeconfig --name default --host)
|
||||
```
|
||||
|
||||
3. Enable velaux addon for UI console
|
||||
|
||||
```shell
|
||||
vela addon enable velaux
|
||||
```
|
||||
|
||||
4. Create a cluster with velad named `foo`
|
||||
|
||||
```shell
|
||||
velad install --name foo --cluster-only
|
||||
```
|
||||
|
||||
5. Join the created cluster to control plane
|
||||
|
||||
```shell
|
||||
vela cluster join $(velad kubeconfig --name foo --internal) --name foo
|
||||
```
|
||||
|
||||
6. Enable fluxcd addon for helm component
|
||||
|
||||
```shell
|
||||
vela addon enable fluxcd
|
||||
```
|
||||
|
||||
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:
|
||||
|
||||
```
|
||||
vela addon enable fluxcd --clusters foo
|
||||
```
|
||||
|
||||
Finally, we have finished all preparation, you can check the clusters joined:
|
||||
|
||||
```console
|
||||
$ vela cluster ls
|
||||
CLUSTER ALIAS TYPE ENDPOINT ACCEPTED LABELS
|
||||
local Internal - true
|
||||
foo X509Certificate https://172.20.0.6:6443 true
|
||||
```
|
||||
|
||||
One cluster named `local` is the KubeVela control plane, another one named `foo` is the cluster we just joined.
|
||||
|
||||
## Deploy across multi clusters
|
||||
|
||||
The basic mechanism for multi cluster delivery is almost the same with [deploy container image](../case-studies/multi-cluster#deliver-application-to-clusters).
|
||||
|
||||
We can use `topology` policy to specify the delivery topology for helm chart like the following command:
|
||||
|
||||
```shell
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: helm-hello
|
||||
spec:
|
||||
components:
|
||||
- name: hello
|
||||
type: helm
|
||||
properties:
|
||||
repoType: "helm"
|
||||
url: "https://jhidalgo3.github.io/helm-charts/"
|
||||
chart: "hello-kubernetes-chart"
|
||||
version: "3.0.0"
|
||||
policies:
|
||||
- name: foo-cluster-only
|
||||
type: topology
|
||||
properties:
|
||||
clusters: ["foo"]
|
||||
EOF
|
||||
```
|
||||
|
||||
The `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](../end-user/policies/references#topology) for more details.
|
||||
|
||||
After deployed, you can check the deployed application by:
|
||||
|
||||
```shell
|
||||
vela status helm-hello
|
||||
```
|
||||
|
||||
The expected output should be as follows if deployed successfully:
|
||||
|
||||
```console
|
||||
About:
|
||||
|
||||
Name: helm-hello
|
||||
Namespace: default
|
||||
Created at: 2022-06-09 19:14:57 +0800 CST
|
||||
Status: running
|
||||
|
||||
Workflow:
|
||||
|
||||
mode: DAG
|
||||
finished: true
|
||||
Suspend: false
|
||||
Terminated: false
|
||||
Steps
|
||||
- id:vtahj5zrz4
|
||||
name:deploy-foo-cluster-only
|
||||
type:deploy
|
||||
phase:succeeded
|
||||
message:
|
||||
|
||||
Services:
|
||||
|
||||
- Name: hello
|
||||
Cluster: foo Namespace: default
|
||||
Type: helm
|
||||
Healthy Fetch repository successfully, Create helm release successfully
|
||||
No trait applied
|
||||
```
|
||||
|
||||
You can check the deployed resource by:
|
||||
|
||||
```
|
||||
$ vela status helm-hello --tree
|
||||
CLUSTER NAMESPACE RESOURCE STATUS
|
||||
foo ─── default ─┬─ HelmRelease/hello updated
|
||||
└─ HelmRepository/hello updated
|
||||
```
|
||||
|
||||
You can also check the deployed resource by VelaUX, it's already introduced in the [basic helm delivery docs](./helm#visualize-the-resources-created-by-helm-release).
|
||||
|
||||
|
||||
## Deploy with override configurations
|
||||
|
||||
In some cases, we will deploy helm chart into different clusters with different values, then we can use the [override policy](../end-user/policies/references#override).
|
||||
|
||||
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:
|
||||
|
||||
```shell
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: helm-hello
|
||||
spec:
|
||||
components:
|
||||
- name: hello
|
||||
type: helm
|
||||
properties:
|
||||
repoType: "helm"
|
||||
url: "https://jhidalgo3.github.io/helm-charts/"
|
||||
chart: "hello-kubernetes-chart"
|
||||
version: "3.0.0"
|
||||
policies:
|
||||
- name: topology-local
|
||||
type: topology
|
||||
properties:
|
||||
clusters: ["local"]
|
||||
- name: topology-foo
|
||||
type: topology
|
||||
properties:
|
||||
clusters: ["foo"]
|
||||
- name: override-local
|
||||
type: override
|
||||
properties:
|
||||
components:
|
||||
- name: hello
|
||||
properties:
|
||||
values:
|
||||
configs:
|
||||
MESSAGE: Welcome to Control Plane Cluster!
|
||||
- name: override-foo
|
||||
type: override
|
||||
properties:
|
||||
components:
|
||||
- name: hello
|
||||
properties:
|
||||
values:
|
||||
configs:
|
||||
MESSAGE: Welcome to Your New Foo Cluster!
|
||||
workflow:
|
||||
steps:
|
||||
- name: deploy2local
|
||||
type: deploy
|
||||
properties:
|
||||
policies: ["topology-local", "override-local"]
|
||||
- name: manual-approval
|
||||
type: suspend
|
||||
- name: deploy2foo
|
||||
type: deploy
|
||||
properties:
|
||||
policies: ["topology-foo", "override-foo"]
|
||||
EOF
|
||||
```
|
||||
|
||||
> **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](../case-studies/multi-cluster#use-policies-and-workflow-outside-the-application).**
|
||||
|
||||
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:
|
||||
|
||||
```
|
||||
$ vela status helm-hello
|
||||
About:
|
||||
|
||||
Name: helm-hello
|
||||
Namespace: default
|
||||
Created at: 2022-06-09 19:38:13 +0800 CST
|
||||
Status: workflowSuspending
|
||||
|
||||
Workflow:
|
||||
|
||||
mode: StepByStep
|
||||
finished: false
|
||||
Suspend: true
|
||||
Terminated: false
|
||||
Steps
|
||||
- id:ww4cydlvee
|
||||
name:deploy2local
|
||||
type:deploy
|
||||
phase:succeeded
|
||||
message:
|
||||
- id:xj6hu97e1e
|
||||
name:manual-approval
|
||||
type:suspend
|
||||
phase:succeeded
|
||||
message:
|
||||
|
||||
Services:
|
||||
|
||||
- Name: hello
|
||||
Cluster: local Namespace: default
|
||||
Type: helm
|
||||
Healthy Fetch repository successfully, Create helm release successfully
|
||||
No trait applied
|
||||
```
|
||||
|
||||
You can check the helm chart deployed in control plane with the value "Welcome to Control Plane Cluster!".
|
||||
|
||||
```
|
||||
vela port-forward helm-hello
|
||||
```
|
||||
|
||||
It will automatically prompt with your browser with the following page:
|
||||
|
||||
|
||||
|
||||
Let's continue the workflow as we have checked the deployment has succeeded.
|
||||
|
||||
```shell
|
||||
vela workflow resume helm-hello
|
||||
```
|
||||
|
||||
Then it will deploy to the foo cluster, you can check the resources with detailed information:
|
||||
|
||||
```console
|
||||
$ vela status helm-hello --tree --detail
|
||||
CLUSTER NAMESPACE RESOURCE STATUS APPLY_TIME DETAIL
|
||||
foo ─── default ─┬─ HelmRelease/hello updated 2022-06-09 19:38:13 Ready: True Status: Release reconciliation succeeded Age: 64s
|
||||
└─ HelmRepository/hello updated 2022-06-09 19:38:13 URL: https://jhidalgo3.github.io/helm-charts/ Age: 64s Ready: True
|
||||
Status: stored artifact for revision 'ab876069f02d779cb4b63587af1266464818ba3790c0ccd50337e3cdead44803'
|
||||
local ─── default ─┬─ HelmRelease/hello updated 2022-06-09 19:38:13 Ready: True Status: Release reconciliation succeeded Age: 7m34s
|
||||
└─ HelmRepository/hello updated 2022-06-09 19:38:13 URL: https://jhidalgo3.github.io/helm-charts/ Age: 7m34s Ready: True
|
||||
Status: stored artifact for revision 'ab876069f02d779cb4b63587af1266464818ba3790c0ccd50337e3cdead44803'
|
||||
```
|
||||
|
||||
Use port forward again:
|
||||
|
||||
```shell
|
||||
vela port-forward helm-hello
|
||||
```
|
||||
|
||||
Then it will prompt some selections:
|
||||
|
||||
```
|
||||
? You have 2 deployed resources in your app. Please choose one: [Use arrows to move, type to filter]
|
||||
> Cluster: foo | Namespace: default | Kind: HelmRelease | Name: hello
|
||||
Cluster: local | Namespace: default | Kind: HelmRelease | Name: hello
|
||||
```
|
||||
|
||||
Choose the option with cluster `foo`, then you'll see the result that has was overridden with new message.
|
||||
|
||||
```console
|
||||
$ curl http://127.0.0.1:8080/
|
||||
...snip...
|
||||
<div id="message">
|
||||
Welcome to Your New Foo Cluster!
|
||||
</div>
|
||||
...snip...
|
||||
```
|
||||
|
||||
## More from UI console
|
||||
|
||||
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:
|
||||
|
||||
|
||||
|
||||
## Clean up
|
||||
|
||||
If you're using velad for this demo, you can clean up very easily by:
|
||||
|
||||
* Clean up the foo cluster
|
||||
```
|
||||
velad uninstall -n foo
|
||||
```
|
||||
|
||||
* Clean up the default cluster
|
||||
```
|
||||
velad uninstall
|
||||
```
|
||||
|
||||
Happy shipping with Helm chart!
|
||||
|
|
@ -2,67 +2,54 @@
|
|||
title: Deploy Helm Chart
|
||||
---
|
||||
|
||||
This section introduces that how you deploy Helm Chart into multi-environments and clusters.
|
||||
This section introduces how you deploy Helm Chart.
|
||||
|
||||
The typical usage of deploying Helm Chart is to integrate middleware, many from in [bitnami](https://github.com/bitnami/charts) or open-source application tools such as Gitlab, Jenkins in [Helm Official Repo](https://hub.helm.sh/). KubeVela can help you easily deploy these applications to any managed cluster and manage them.
|
||||
The typical usage of deploying Helm Chart is to integrate middleware, many from in [bitnami](https://github.com/bitnami/charts) or open-source application tools such as Gitlab, and Jenkins in [Helm Official Repo](https://hub.helm.sh/). KubeVela can help you easily deploy these applications to any managed cluster and manage them.
|
||||
|
||||
Starting from here, you will learn to use the KubeVela Addons to install plug-ins. The Helm Chart is currently supported by the FluxCD addon. In addition to the Helm Chart, FluxCD addon also supports Kustomize.
|
||||
|
||||
## Before starting
|
||||
|
||||
- Choose a Helm Chart you needed. Or in this case, we take [bitnami/redis](https://github.com/bitnami/charts/tree/master/bitnami/redis) as an example.
|
||||
- Choose a Helm Chart you want to deploy. In the tutorial, we take [bitnami/redis](https://github.com/bitnami/charts/tree/master/bitnami/redis) as an example.
|
||||
- Ensure that the cluster you deliver has a usable default StorageClass. Most of our delivery middleware requires data persistence, and the default StorageClass is needed to allocate PV.
|
||||
- Enable the VelaUX addon, If you are only CLI users, go to [Deploy via CLI](#deploy-via-cli)
|
||||
- Enable the VelaUX addon for UI console. If you are only CLI users, you can skip to [Deploy via CLI](#deploy-via-cli)
|
||||
|
||||
## Enable fluxcd addon
|
||||
|
||||
Enabling Addon should have been experienced in the installation of KubeVela, like installing VelaUX. In this case, you will learn to enable addon in the UI page.
|
||||
|
||||
Let's get into the page of `Addon`. This page will automatically list the community Addons that can be installed. They are all from [Official Repo](https://github.com/kubevela/catalog/tree/master/addons). We click `fluxcd` to check the details and status of this addon.
|
||||
|
||||
From the details, we can know that:
|
||||
|
||||
- Definitions： The extension capabilities provided by the addon may include component, trait, etc. For the fluxcd addon, it provides two component types, `helm` and `kustomize`, among which `helm` is the type we need to pay attention to and use here.
|
||||
|
||||
- Readme： Addon description, explain the capabilities and related information.
|
||||
|
||||
We can click the `Enable` button. After the fluxcd addon is enabled, it will be installed on all clusters connected to KubeVela, so it will take a certain amount of time.
|
||||
|
||||
|
||||
|
||||
When the addon is `enabled`, it means that it's ready to. You can start to deploy Helm Chart.
|
||||
|
||||
You can also enable the addon via CLI:
|
||||
Helm Chart delivery relies on addon in KubeVela, you need to enable `fluxcd` addon before start.
|
||||
|
||||
```shell
|
||||
vela addon enable fluxcd
|
||||
```
|
||||
|
||||
You can also enable the addon from UI console with more detail information. After `velaux` addon enabled, you can get into the page of `Addon`.
|
||||
This page will automatically list the community Addons that can be installed.
|
||||
They are all from [Community Repo](https://github.com/kubevela/catalog/tree/master/addons).
|
||||
You can check detail information of this addon by clicking the `fluxcd` UI section.
|
||||
|
||||
Details will include:
|
||||
|
||||
- Definitions: The extension capabilities provided by the addon may include component, trait, etc. For the fluxcd addon, it provides two component types, `helm` and `kustomize`, among which `helm` is the type we need to pay attention to and use here.
|
||||
|
||||
- README: Addon description, explain the capabilities and related information.
|
||||
|
||||
We can click the `Enable` button. After the fluxcd addon is enabled, it will be installed on all clusters connected to KubeVela, so it will take a certain amount of time.
|
||||
|
||||
|
||||
|
||||
When the addon status become `enabled`, it means it's ready for helm chart delivery.
|
||||
|
||||
## Creating Redis application
|
||||
|
||||
You've must have mastered creating applications through the previous sections. When it comes to creating Redis with Helm Chart, all you need is to select type as `helm`, Then select the Target which has the default StorageClass that provides PV, and at last enter the deployment parameter configuration page.
|
||||
After `fluxcd` addon enabled, there's a `helm` definition added, you can check the parameter details by:
|
||||
|
||||
|
||||
```
|
||||
vela show helm
|
||||
```
|
||||
|
||||
As shown, you need to do the following configuration:
|
||||
You can also check the [fluxcd addon](../reference/addons/fluxcd) docs for details.
|
||||
|
||||
- Repo Type: Git and Helm are supported. In this example, we choose Helm.
|
||||
- Repo URL: Fill in the repo address you needed. we type in: https://charts.bitnami.com/bitnami. If you have configured the helm repo in [Integration](../how-to/dashboard/config/helm-repo) you can choose the repo directly.
|
||||
- Chart: After fill Helm repo URL, will list all available charts in this field. You can choose one from the list, here we choose: redis.
|
||||
- Version: After choose the helm chart, will list all available versions in this field. Choose one version of this chart, here we choose: 16.8.5.
|
||||
- Values: After choose the version, will list all parameters of this helm Chart. Since we are using ACK cluster in the example, PV has a minimum capacity requirement, 15Gi. In the same way, other parameters can also be configured according to your cluster's status.
|
||||
|
||||
After filling in the above parameters, click `Create` to complete the application creation and enter the application configuration page. The following steps will stay the same as you've learned in [Deploy First Application](../quick-start).
|
||||
|
||||
## Modify deployment parameters
|
||||
|
||||
Clicking the component name, you can open the component configuration page. For the Helm Chart component, we can set the Values configuration options to change the application deployment parameters. the Values configuration options are generated by `values.yaml`, you can set the custom value for every option.
|
||||
|
||||
After modifying the deployment parameters, the workflow of the environment must be executed to make the modified parameters take effect in the specified environment. Due to the existence of Revision, the configuration parameters will be saved in each historical version.
|
||||
|
||||
## Deploy via CLI
|
||||
|
||||
You can also create the application with helm component via CLI:
|
||||
Let's take the `redis` chart as example, you can deploy by the following application:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
|
|
@ -87,15 +74,13 @@ spec:
|
|||
size: 16Gi
|
||||
```
|
||||
|
||||
Deploy this application：
|
||||
Deploy it by：
|
||||
|
||||
```shell
|
||||
vela up -f https://kubevela.io/example/applications/app-with-chart-redis.yaml
|
||||
```
|
||||
|
||||
> Currently, The application created by CLI will be synced to UI, but it will be readonly.
|
||||
|
||||
Next, check the deployment status of the application through `vela status helm-redis`
|
||||
Then check the deployment status of the application through `vela status helm-redis`
|
||||
|
||||
```
|
||||
About:
|
||||
|
|
@ -127,4 +112,55 @@ Services:
|
|||
No trait applied
|
||||
```
|
||||
|
||||
> You can also check the application on UI, application created by CLI will be synced automatically but readonly.
|
||||
|
||||
## Deploy Helm Chart from UI Console
|
||||
|
||||
The experience on UI console is quite the same with [container image delivery](../tutorials/webservice). When it comes to deploying Helm Chart, all you need is to select type as `helm`.
|
||||
|
||||
>The `helm` component type will automatically discovered after fluxcd addon enabled.
|
||||
|
||||
Then select the Target which has the default StorageClass that provides PV, and at last enter the deployment parameter configuration page.
|
||||
|
||||
|
||||
|
||||
As shown, you need to do the following configuration:
|
||||
|
||||
- Repo Type: Git and Helm are supported. In this example, we choose Helm.
|
||||
- Repo URL: Fill in the repo address you needed. we type in: https://charts.bitnami.com/bitnami. If you have configured the helm repo in [Integration](../how-to/dashboard/config/helm-repo) you can choose the repo directly.
|
||||
- Chart: After fill Helm repo URL, will list all available charts in this field. You can choose one from the list, here we choose: redis.
|
||||
- Version: After choosing the helm chart, will list all available versions in this field. Choose one version of this chart, here we choose: 16.8.5.
|
||||
- Values: After choosing the version, will list all parameters of this helm Chart. Since we are using ACK cluster in the example, PV has a minimum capacity requirement, 15Gi. In the same way, other parameters can also be configured according to your cluster's status.
|
||||
|
||||
After filling in the above parameters, click `Create` to complete the application creation and enter the application configuration page. The following steps will stay the same as you've learned in [Deploy First Application](../quick-start).
|
||||
|
||||
### Modify deployment parameters
|
||||
|
||||
Clicking the component name, you can open the component configuration page. For the Helm Chart component, we can set the Values configuration options to change the application deployment parameters. the Values configuration options are generated by `values.yaml`, you can set the custom value for every option.
|
||||
|
||||
In the VelaUX, the value key format like `replica.persistence.size=15Gi`. they will be converted to YAML value:
|
||||
|
||||
```yaml
|
||||
values:
|
||||
replica:
|
||||
persistence:
|
||||
size: 15Gi
|
||||
```
|
||||
|
||||
After modifying the deployment parameters, the workflow of the environment must be executed to make the modified parameters take effect in the specified environment. Due to the existence of Revision, the configuration parameters will be saved in each historical version.
|
||||
|
||||
### Visualize the resources created by Helm Release
|
||||
|
||||
For a helm chart, users often don't know what resources they will create, making it difficult to troubleshoot. In VelaUX, users can visualize the resources created by Helm Release. via the resource graph, users could know the relationships between the resources and the status of all resources. Click the `Detail` action button could view the resource YAML.
|
||||
|
||||
|
||||
|
||||
You can hover your mouse on it to check the health status, by clicking the icon on the right, you can even get the yaml details for debug.
|
||||
|
||||
|
||||
|
||||
At this point, Helm Chart in KubeVela is no stranger to you, go ahead and try more!
|
||||
|
||||
## Next
|
||||
|
||||
* Learn [multi cluster delivery](./helm-multi-cluster) for helm chart.
|
||||
|
|
@ -119,3 +119,7 @@ Services:
|
|||
|
||||
* Refer to [webservice details](../end-user/components/references#webservice) to know usage of full fields.
|
||||
* Refer to [trait reference](../end-user/traits/references) to know which traits can be used for webservice.
|
||||
|
||||
## Next
|
||||
|
||||
* Learn [multi cluster delivery](../case-studies/multi-cluster) for container image.
|
||||
|
|
@ -74,6 +74,10 @@
|
|||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.4/tutorials/helm"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.4/tutorials/helm-multi-cluster"
|
||||
}
|
||||
]
|
||||
},
|
||||
|
|
|
|||
Loading…
Reference in New Issue