Make helm chart delivery in multi-cluster as a blog (#841)
* Make helm chart delivery in multi-cluster as a blog Signed-off-by: Jianbo Sun <jianbo.sjb@alibaba-inc.com> * update v1.4 docs Signed-off-by: Jianbo Sun <jianbo.sjb@alibaba-inc.com>
This commit is contained in:
Jianbo Sun
GitHub
parent
162964c098
commit
271fce8aa1
14
README-zh.md
14
README-zh.md
|
|
@ -73,13 +73,17 @@ Docusaurus website is running at: http://localhost:3000/zh/
|
|||
翻译合格的文章将会 merge 到 [kubevela.io](https://github.com/kubevela/kubevela.io) 的 main 分支进行发布。
|
||||
|
||||
|
||||
### 翻译要求
|
||||
## 翻译注意事项
|
||||
|
||||
- 数字和英文两边是中文要加空格。
|
||||
- KubeVela 统一写法。K 和 V 大写。
|
||||
- 翻译完请先阅读一遍，不要出现遗漏段落，保证文章通顺、符合中文阅读习惯。不追求严格一致，可以意译。review 的时候也会检验。
|
||||
- 品牌名称和概念一般不翻译，但要统一写法，注意大小写。
|
||||
* 品牌名称如 KubeVela 这个品牌名称的 K 和 V 大写。把握不准某个项目名称的写法可以参考其官网。
|
||||
* 概念如 Component、Workload、Trait 这些 OAM/KubeVela 里面定义的专属概念不要翻译，我们也要加强这些词汇的认知。可以在一篇新文章最开始出现的时候用括号加上中文翻译。
|
||||
- 翻译完请先阅读一遍，不要出现遗漏段落，保证文章通顺、符合中文阅读习惯。不追求严格一致，可以意译。
|
||||
- 你和您不要混用，统一使用用 **“你”**。
|
||||
- 不会翻译的词汇可以不翻译，可以在 PR 中说明，review 的时候会查看。
|
||||
- Component、Workload、Trait 这些 OAM/KubeVela 里面定义的专属概念不要翻译，我们也要加强这些词汇的认知。可以在一篇新文章最开始出现的时候用括号加上中文翻译。
|
||||
- 不会翻译的词汇可以不翻译，可以在 PR 中说明，review 的时候会查看/修正。
|
||||
- 注意中英文标点符号。
|
||||
- 注意链接，中文的文档里对应的链接也用中文链接。
|
||||
* 一般国外访问 https://kubevela.io ， 国内访问 https://kubevela.net 更快。
|
||||
* 中文的文档有 `/zh` 后缀，如 `https://kubevela.net/zh/blog/2022/06/27/terraform-integrate-with-vela`。
|
||||
- `PR` 命名规范 `Translate <翻译文件相对路径>`，如 `Translate i18n/zh/docusaurus-plugin-content-docs/current/introduction.md`。
|
||||
|
|
@ -0,0 +1,460 @@
|
|||
---
|
||||
title: Helm Chart Delivery in Multi-Cluster
|
||||
author: Jianbo Sun
|
||||
author_title: KubeVela Team
|
||||
author_url: https://github.com/kubevela/kubevela
|
||||
author_image_url: https://KubeVela.io/img/logo.svg
|
||||
tags: [ KubeVela, "use-case", "helm chart", "multi-cluster" ]
|
||||
description: ""
|
||||
image: https://raw.githubusercontent.com/oam-dev/KubeVela.io/main/docs/resources/KubeVela-03.png
|
||||
hide_table_of_contents: false
|
||||
---
|
||||
|
||||
[Helm Charts](https://artifacthub.io/packages/search?kind=0) are very popular that you can find almost 10K different software packaged in this way. While in today's multi-cluster/hybrid cloud business environment, we often encounter these typical requirements: distribute to multiple specific clusters, specific group distributions according to business need, and differentiated configurations for multi-clusters.
|
||||
|
||||
In this blog, we'll introduce how to use [KubeVela](https://kubevela.io/) to do multi cluster delivery for Helm Charts.
|
||||
|
||||
If you don't have multi clusters, don't worry, we'll introduce from scratch with only Docker or Linux System required. You can also refer to the [basic helm chart delivery](https://kubevela.io/docs/tutorials/helm) in single cluster.
|
||||
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## Prerequisites
|
||||
|
||||
* Docker v20.10.5+ (runc >= v1.0.0-rc93), or Linux system
|
||||
* [VelaD](https://github.com/kubevela/velad), a lightweight deployment tool to set up KubeVela with Kubernetes.
|
||||
|
||||
## Prepare Clusters
|
||||
|
||||
> This section is preparation for multi-cluster, we will start from scratch for convenience. if you're already KubeVela users and have [multi-clusters joined](https://kubevela.io/docs/platform-engineers/system-operation/managing-clusters), you can skip this section.
|
||||
|
||||
1. Install KubeVela control plane
|
||||
|
||||
```shell
|
||||
velad install
|
||||
```
|
||||
|
||||
2. Export the KubeConfig for the newly created cluster
|
||||
|
||||
```
|
||||
export KUBECONFIG=$(velad kubeconfig --name default --host)
|
||||
```
|
||||
|
||||
Now you have successfully installed KubeVela. You can join your cluster to kubevela by:
|
||||
|
||||
```
|
||||
vela cluster join <path-to-kubeconfig-of-cluster> --name foo
|
||||
```
|
||||
|
||||
VelaD can also provide K3s clusters for convenience.
|
||||
|
||||
3. Create and Join a cluster created by velad named `foo`
|
||||
|
||||
```shell
|
||||
velad install --name foo --cluster-only
|
||||
vela cluster join $(velad kubeconfig --name foo --internal) --name foo
|
||||
```
|
||||
|
||||
As a fully extensible control plane, most of KubeVela's capabilities are pluggable. The following steps will guide you to install some addons for different capabilities.
|
||||
|
||||
4. Enable velaux addon, it will provide UI console for KubeVela
|
||||
|
||||
```shell
|
||||
vela addon enable velaux
|
||||
```
|
||||
|
||||
5. Enable fluxcd addon for helm component delivery
|
||||
|
||||
```shell
|
||||
vela addon enable fluxcd
|
||||
```
|
||||
|
||||
If you have already enabled the `fluxcd` addon before you joined the new cluster, you NEED to 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
|
||||
|
||||
We can use `topology` policy to specify the delivery topology for helm chart like the following command:
|
||||
|
||||
```yaml
|
||||
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](https://kubevela.io/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.
|
||||
|
||||
|
||||
## Check Resources from UI console
|
||||
|
||||
By using the `velaux` UI console, you can get even more information with a unified experience for multi clusters. You can refer to [this doc](https://kubevela.io/docs/install#2-install-velaux) to learn how to visit VelaUX.
|
||||
|
||||
With the help of UI, you can:
|
||||
|
||||
* Check pod status and event from different clusters:
|
||||
|
||||
|
||||
|
||||
* Check pod logs from different clusters:
|
||||
|
||||
|
||||
|
||||
* Check resource topology and status:
|
||||
|
||||
|
||||
|
||||
|
||||
## 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](https://kubevela.io/docs/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](https://kubevela.io/docs/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...
|
||||
```
|
||||
|
||||
## Specify different value file for different environment
|
||||
|
||||
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:
|
||||
|
||||
```yaml
|
||||
$ tree ./hello-kubernetes-chart
|
||||
./hello-kubernetes-chart
|
||||
├── Chart.yaml
|
||||
├── templates
|
||||
│ ├── NOTES.txt
|
||||
│ ├── _helpers.tpl
|
||||
│ ├── config-map.yaml
|
||||
│ ├── deployment.yaml
|
||||
│ ├── hpa.yaml
|
||||
│ ├── ingress.yaml
|
||||
│ ├── service.yaml
|
||||
│ ├── serviceaccount.yaml
|
||||
│ └── tests
|
||||
│ └── test-connection.yaml
|
||||
├── values-production.yaml
|
||||
└── values.yaml
|
||||
```
|
||||
|
||||
As we can see, there are values files `values.yaml` `values-production.yaml` in this chart.
|
||||
|
||||
```yaml
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: hello-kubernetes
|
||||
spec:
|
||||
components:
|
||||
- name: hello-kubernetes
|
||||
type: helm
|
||||
properties:
|
||||
repoType: "helm"
|
||||
url: "https://wangyikewxgm.github.io/my-charts/"
|
||||
chart: "hello-kubernetes-chart"
|
||||
version: "0.1.0"
|
||||
|
||||
policies:
|
||||
- name: topology-test
|
||||
type: topology
|
||||
properties:
|
||||
clusters: ["local"]
|
||||
namespace: "test"
|
||||
- name: topology-prod
|
||||
type: topology
|
||||
properties:
|
||||
clusters: ["local"]
|
||||
namespace: "prod"
|
||||
- name: override-prod
|
||||
type: override
|
||||
properties:
|
||||
components:
|
||||
- name: hello-kubernetes
|
||||
properties:
|
||||
valuesFiles:
|
||||
- "values-production.yaml"
|
||||
workflow:
|
||||
steps:
|
||||
- name: deploy2test
|
||||
type: deploy
|
||||
properties:
|
||||
policies: ["topology-test"]
|
||||
- name: deploy2prod
|
||||
type: deploy
|
||||
properties:
|
||||
policies: ["topology-prod", "override-prod"]
|
||||
EOF
|
||||
```
|
||||
|
||||
Access the endpoints of application:
|
||||
|
||||
```yaml
|
||||
vela port-forward hello-kubernetes
|
||||
```
|
||||
|
||||
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:
|
||||
|
||||
|
||||
|
||||
## 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
|
||||
```
|
||||
|
||||
## What's More?
|
||||
|
||||
With the help of KubeVela and its addon, you can get the capability of [Canary Rollout](https://kubevela.io/docs/tutorials/helm-rollout) for your helm charts!
|
||||
|
||||
Go and ship Helm chart with KubeVela, makes deploying and operating applications across today's hybrid, multi-cloud environments easier, faster and more reliable.
|
||||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Overview
|
||||
title: Overview of GitOps
|
||||
---
|
||||
|
||||
> This section will introduce how to use KubeVela in GitOps area and why.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Deploy across Multi-Clusters
|
||||
title: Multi Cluster Application
|
||||
---
|
||||
|
||||
KubeVela is by design a full functional Continuous Delivery (CD) platform with fine grained support for hybrid/multi-cloud/multi-cluster deployment.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Overview
|
||||
title: Developer Overview
|
||||
---
|
||||
|
||||
The developer guide including two parts:
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Overview
|
||||
title: Overview of Terraform
|
||||
description: This section introduces some scenarios of cloud resources management
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
---
|
||||
title: Multi Cluster Distribution
|
||||
title: Distribute Reference Objects
|
||||
---
|
||||
|
||||
> 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.
|
||||
> This section requires you to know the basics about how to deploy [multi-cluster application](../../case-studies/multi-cluster) with policy and workflow.
|
||||
|
||||
You can reference and distribute existing Kubernetes objects with KubeVela in the following scenarios:
|
||||
|
||||
|
|
@ -71,9 +71,11 @@ spec:
|
|||
|
||||
> In some cases, you might want to restrict the scope for the application to access resources. You can set the `--ref-objects-available-scope` to `namespace` or `cluster` in KubeVela controller's bootstrap parameter, to retrict the application to be only able to refer to the resources inside the same namespace or the same cluster.
|
||||
|
||||
## Working with Trait
|
||||
## Override Configuration for Reference Objects
|
||||
|
||||
The *ref-objects* typed component can also be used together with traits. The implicit main workload is the first referenced object and trait patch will be applied on it. The following example demonstrate how to set the replica number for the referenced deployment while deploying it in hangzhou clusters.
|
||||
The [override policy](../../case-studies/multi-cluster#override-default-configurations-in-clusters) can be used to override properties defined in component and traits while the reference objects don't have those properties.
|
||||
|
||||
If you want to override configuration for the *ref-objects* typed component, you can use traits. The implicit main workload is the first referenced object and trait patch will be applied on it. The following example demonstrate how to set the replica number for the referenced deployment while deploying it in hangzhou clusters.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
|
|
@ -103,7 +105,7 @@ spec:
|
|||
|
||||
There are several commonly used trait that could be used together with the ref-objects, particularly for Deployment.
|
||||
|
||||
### Container Image
|
||||
### Override Container Image
|
||||
|
||||
The `container-image` trait can be used to change the default image settings declared in the original deployment.
|
||||
|
||||
|
|
@ -147,7 +149,7 @@ traits:
|
|||
image: nginx-1.20
|
||||
```
|
||||
|
||||
### Command
|
||||
### Override Container Command
|
||||
|
||||
The `command` trait can be used to modify the original running command in deployment's pods.
|
||||
```yaml
|
||||
|
|
@ -200,7 +202,7 @@ traits:
|
|||
args: ["-q"]
|
||||
```
|
||||
|
||||
### Environment Variable
|
||||
### Override Container Environment Variable
|
||||
|
||||
With the trait `env`, you can easily manipulate the declared environment variables.
|
||||
|
||||
|
|
@ -260,7 +262,7 @@ traits:
|
|||
key_for_nginx_second: value_second
|
||||
```
|
||||
|
||||
### Labels & Annotations
|
||||
### Override Labels & Annotations
|
||||
|
||||
To add/update/remove labels or annotations for the workload (like Kubernetes Deployment), use the `labels` or `annotations` trait.
|
||||
|
||||
|
|
@ -292,7 +294,7 @@ traits:
|
|||
to-delete-annotation-key: null
|
||||
```
|
||||
|
||||
### JSON Patch & JSON Merge Patch
|
||||
### Override by using JSON Patch & JSON Merge Patch
|
||||
|
||||
Except for the above trait, a more powerful but more complex way to modify the original resources is to use the `json-patch` or `json-merge-patch` trait. They follow the [RFC 6902](https://datatracker.ietf.org/doc/html/rfc6902) and [RFC 7386](https://datatracker.ietf.org/doc/html/rfc7386) respectively. Usage examples are shown below.
|
||||
|
||||
|
|
@ -351,3 +353,130 @@ traits:
|
|||
image: busybox:1.34
|
||||
command: ["sleep", "864000"]
|
||||
```
|
||||
|
||||
## Distribute Reference Objects with different configuration
|
||||
|
||||
The general idea is to using `override` policy to override traits. Then you can distribute reference objects with different traits for different clusters.
|
||||
|
||||
Assume we're distributing the following Deployment YAML to multi-clusters:
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
labels:
|
||||
app: demo
|
||||
name: demo
|
||||
namespace: demo
|
||||
spec:
|
||||
replicas: 1
|
||||
selector:
|
||||
matchLabels:
|
||||
app: demo
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: demo
|
||||
spec:
|
||||
containers:
|
||||
- image: oamdev/testapp:v1
|
||||
name: demo
|
||||
```
|
||||
|
||||
We can specify the following `topology` policies.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: Policy
|
||||
metadata:
|
||||
name: cluster-beijing
|
||||
namespace: demo
|
||||
type: topology
|
||||
properties:
|
||||
clusters: ["<clusterid1>"]
|
||||
---
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: Policy
|
||||
metadata:
|
||||
name: cluster-hangzhou
|
||||
namespace: demo
|
||||
type: topology
|
||||
properties:
|
||||
clusters: ["<clusterid2>"]
|
||||
```
|
||||
|
||||
Then we can use `override` policy to override with different traits for the reference objects.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: Policy
|
||||
metadata:
|
||||
name: override-replic-beijing
|
||||
namespace: demo
|
||||
type: override
|
||||
properties:
|
||||
components:
|
||||
- name: "demo"
|
||||
traits:
|
||||
- type: scaler
|
||||
properties:
|
||||
replicas: 3
|
||||
---
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: Policy
|
||||
metadata:
|
||||
name: override-replic-hangzhou
|
||||
namespace: demo
|
||||
type: override
|
||||
properties:
|
||||
components:
|
||||
- name: "demo"
|
||||
traits:
|
||||
- type: scaler
|
||||
properties:
|
||||
replicas: 5
|
||||
```
|
||||
|
||||
The workflow can be defined like:
|
||||
|
||||
```
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: Workflow
|
||||
metadata:
|
||||
name: deploy-demo
|
||||
namespace: demo
|
||||
steps:
|
||||
- type: deploy
|
||||
name: deploy-bejing
|
||||
properties:
|
||||
policies: ["override-replic-beijing", "cluster-beijing"]
|
||||
- type: deploy
|
||||
name: deploy-hangzhou
|
||||
properties:
|
||||
policies: ["override-replic-hangzhou", "cluster-hangzhou"]
|
||||
```
|
||||
|
||||
As a result, we can combine them and trigger the final deploy by the following application:
|
||||
|
||||
```
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: demo
|
||||
namespace: demo
|
||||
annotations:
|
||||
app.oam.dev/publishVersion: version1
|
||||
spec:
|
||||
components:
|
||||
- name: demo
|
||||
type: ref-objects
|
||||
properties:
|
||||
objects:
|
||||
- apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
name: demo
|
||||
workflow:
|
||||
ref: deploy-demo
|
||||
```
|
||||
|
||||
With the help of KubeVela, you can reference and distribute any Kubernetes resources to multi clusters.
|
||||
|
|
@ -2,424 +2,4 @@
|
|||
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:
|
||||
|
||||
|
||||
|
||||
## Specify different value file for different environment
|
||||
|
||||
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:
|
||||
|
||||
```yaml
|
||||
$ tree ./hello-kubernetes-chart
|
||||
./hello-kubernetes-chart
|
||||
├── Chart.yaml
|
||||
├── templates
|
||||
│ ├── NOTES.txt
|
||||
│ ├── _helpers.tpl
|
||||
│ ├── config-map.yaml
|
||||
│ ├── deployment.yaml
|
||||
│ ├── hpa.yaml
|
||||
│ ├── ingress.yaml
|
||||
│ ├── service.yaml
|
||||
│ ├── serviceaccount.yaml
|
||||
│ └── tests
|
||||
│ └── test-connection.yaml
|
||||
├── values-production.yaml
|
||||
└── values.yaml
|
||||
```
|
||||
|
||||
As we can see, there are values files `values.yaml` `values-production.yaml` in this chart.
|
||||
|
||||
```yaml
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: hello-kubernetes
|
||||
spec:
|
||||
components:
|
||||
- name: hello-kubernetes
|
||||
type: helm
|
||||
properties:
|
||||
repoType: "helm"
|
||||
url: "https://wangyikewxgm.github.io/my-charts/"
|
||||
chart: "hello-kubernetes-chart"
|
||||
version: "0.1.0"
|
||||
|
||||
policies:
|
||||
- name: topology-test
|
||||
type: topology
|
||||
properties:
|
||||
clusters: ["local"]
|
||||
namespace: "test"
|
||||
- name: topology-prod
|
||||
type: topology
|
||||
properties:
|
||||
clusters: ["local"]
|
||||
namespace: "prod"
|
||||
- name: override-prod
|
||||
type: override
|
||||
properties:
|
||||
components:
|
||||
- name: hello-kubernetes
|
||||
properties:
|
||||
valuesFiles:
|
||||
- "values-production.yaml"
|
||||
workflow:
|
||||
steps:
|
||||
- name: deploy2test
|
||||
type: deploy
|
||||
properties:
|
||||
policies: ["topology-test"]
|
||||
- name: deploy2prod
|
||||
type: deploy
|
||||
properties:
|
||||
policies: ["topology-prod", "override-prod"]
|
||||
EOF
|
||||
```
|
||||
|
||||
Access the endpoints of application:
|
||||
|
||||
```yaml
|
||||
vela port-forward hello-kubernetes
|
||||
```
|
||||
|
||||
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:
|
||||
|
||||
|
||||
|
||||
## 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!
|
||||
This doc has been migrated to [this blog](https://kubevela.io/blog/2022/07/07/helm-multi-cluster).
|
||||
|
|
@ -203,6 +203,4 @@ Example below `values-production.yaml` will override `values.yaml` if they have
|
|||
- "values-production.yaml"
|
||||
```
|
||||
|
||||
## Next
|
||||
|
||||
* Learn [multi cluster delivery](./helm-multi-cluster) for helm chart.
|
||||
Now, you have learned the basic helm delivery. If you want to delivery Helm Chart into multi-clusters, you can refer to [this blog](https://kubevela.io/blog/2022/07/07/helm-multi-cluster).
|
||||
|
|
@ -209,9 +209,6 @@ If continued, the deployment goes on. In the list of instances, you can check ou
|
|||
|
||||
|
||||
|
||||
Now you've learned how to deploy Kubernetes objects.
|
||||
|
||||
Congrats! Now you've learned how to deploy Kubernetes objects.
|
||||
|
||||
## Next
|
||||
|
||||
* Learn how to [distribute resources across multi-clusters](../end-user/components/ref-objects).
|
||||
If you want to learn how to distribute resources across multi-clusters, you can refer to [this doc](../end-user/components/ref-objects).
|
||||
|
|
@ -122,9 +122,8 @@ Services:
|
|||
✅ scaler
|
||||
```
|
||||
|
||||
Now, you have finished learning the basic delivery for container images. Then, you could:
|
||||
|
||||
* 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 the container image.
|
||||
* Refer to [multi-cluster delivery](../case-studies/multi-cluster) to know how to deploy container image into hybrid environment and multi-clusters.
|
||||
|
|
@ -18,6 +18,8 @@ hide_table_of_contents: false
|
|||
|
||||
在正式开始本文档的教程之前，请确保你本地已经正确[安装了 KubeVela](https://kubevela.io/#/en/install) 及其依赖的 K8s 环境。
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
# KubeVela 扩展的基本结构
|
||||
|
||||
KubeVela 的基本架构如图所示：
|
||||
|
|
|
|||
|
|
@ -20,6 +20,8 @@ hide_table_of_contents: false
|
|||
|
||||
KubeVela Github 地址：[https://github.com/kubevela/kubevela/](https://github.com/kubevela/kubevela/)
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## 什么是 KubeVela ？
|
||||
|
||||
一言以蔽之，**KubeVela 是一个简单易用且高度可扩展的应用管理平台与核心引擎**。KubeVela 是基于 Kubernetes 与 OAM 技术构建的。
|
||||
|
|
|
|||
|
|
@ -23,6 +23,8 @@ KubeVela v1.0 启用了新的官网架构和文档维护方式，新增功能包
|
|||
- 终审： 对 review 后的内容进行最后确认；
|
||||
- 合并：merge 到 master 分支，任务结束。
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
### 参与指南
|
||||
|
||||
下面具体介绍参与翻译的具体工作。
|
||||
|
|
|
|||
|
|
@ -14,6 +14,8 @@ KubeVela 打通了应用与基础设施之间的交付管控的壁垒，相较
|
|||
|
||||
本文就以经典的持续集成 (Continuous Integration) 工具 Jenkins 为基础，简单介绍如何打造基于 GitOps 的应用持续交付的“高速公路”。
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## 持续交付“高速公路”
|
||||
|
||||
作为应用开发者的你，更多地关心自己的应用是否正常运作，开发流程是否便捷高效。为此，在这条持续交付的“高速公路”上，将会由以下部件为你保驾护航。
|
||||
|
|
|
|||
|
|
@ -18,6 +18,8 @@ hide_table_of_contents: false
|
|||
|
||||
KubeVela 作为一个开箱即用、面向现代微服务架构的应用交付与管理平台，今天正式发布了 1.1 版本，以更加用户友好和完善的功能集，开启了”让混合环境应用交付更加简单高效“的重要里程碑。
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
具体来说，1.1 版本的 KubeVela 与现有各类应用交付系统相比，有着显著的不同和优势：
|
||||
|
||||
* **完全以应用为中心** 与各类“搭积木”式的 PaaS 系统或者应用平台不同，KubeVela 项目本身是构建于一套完善的应用交付模型与理论基础之上的，这就是“开放应用模型（OAM）”技术。OAM 模型能够通过声明式的定义来捕获面向混合环境的微服务应用交付的整个过程，甚至包括云服务的拉起与绑定、可观测性、多集群分发策略、流量调配和滚动更新等各种运维行为和特征。通过这样一个统一的、基础设施无关的上层模型，KubeVela 天然就能够做到让用户无需关心任何基础设施细节、只专注于业务价值和交付过程，真正实现了完全 Serverless 化的应用管理与交付体验。
|
||||
|
|
|
|||
|
|
@ -14,6 +14,8 @@ KubeVela 作为一个简单、易用、且高可扩展的云原生应用管理
|
|||
|
||||
KubeVela 背后的 OAM 模型天然解决了应用构建过程中对复杂资源的组合、编排等管理问题，同时也将后期的运维策略模型化，这意味着 KubeVela 可以结合 GitOps 管理复杂大规模应用，收敛团队与系统规模变大以后的系统复杂度问题。
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## 什么是 GitOps
|
||||
|
||||
GitOps 是一种现代化的持续交付手段，它的核心思想是：在拥有一个包含环境基础设施及各种应用配置的 Git 仓库中，配合一个自动化过程————使得每次仓库被更新后，自动化过程都能逐渐将环境更新到最新配置。
|
||||
|
|
|
|||
|
|
@ -16,6 +16,8 @@ hide_table_of_contents: false
|
|||
|
||||
图1：KubeVela 架构设计
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## 发展历程回顾
|
||||
|
||||
让我们再来简单回顾一下 OAM 和 KubeVela 的发展阶段和历程：
|
||||
|
|
|
|||
|
|
@ -13,6 +13,7 @@ KubeVela 目前已经支持了 AWS、Azure、GCP、阿里云、腾讯云、百
|
|||
|
||||
同时，我们也期望用户受到本文的启发，贡献其他云服务商的云资源。
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## AWS 最受欢迎的云资源在哪里？
|
||||
|
||||
|
|
|
|||
|
|
@ -20,6 +20,8 @@ hide_table_of_contents: false
|
|||
|
||||
本文主要介绍如何使用 KubeVela 的 AI 插件，来帮助工程师更便捷地完成模型训练及模型服务。
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## KubeVela AI 插件
|
||||
|
||||
KubeVela AI 插件分为模型训练和模型服务两个插件，模型训练插件基于 KubeFlow 的 training-operator，能够支持如 TensorFlow、PyTorch、MXNet 等不同框架的分布式模型训练。而模型服务插件基于 Seldon Core，可以便捷地使用模型启动模型服务，同时也支持流量分发，A/B 测试等高级功能。
|
||||
|
|
|
|||
|
|
@ -16,6 +16,8 @@ hide_table_of_contents: false
|
|||
|
||||
在本文中，我们将结合 KubeVela 以及 Nocalhost 开源项目，给出一个基于 Kubernetes 和容器生态的端云联调、一键完成多集群混合环境部署的解决方案，来回答上述问题。
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
当一个新应用需要开发上线时，我们希望本地 IDE 中调试的结果能和云端最终部署的状态保持一致。这样一致的姿态，能最大程度上给予我们部署的信心，并且让我们可以采用类似 GitOps 这种更高效、敏捷的方式迭代应用更新。即：当新代码被推送至代码仓库中后，环境中的应用会自动化地实时更新。同时，基于端云联调的模式，可以让这整个过程不仅敏捷高效、同样更加稳定可靠。
|
||||
|
||||
基于 KubeVela 和 Nocalhost，我们可以完成这样一种部署过程：
|
||||
|
|
|
|||
|
|
@ -14,6 +14,8 @@ hide_table_of_contents: false
|
|||
|
||||
本文将以 KubeVela v1.2.5 版本为例，介绍招商银行 KubeVela 的离线部署实践，来帮助其他用户在离线环境中更便捷的完成 KubeVela 的部署。
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## KubeVela 离线部署方案
|
||||
|
||||
我们将 KubeVela 的离线部署主要分为三部分，分别是 Vela Cli、Vela Core 以及 Addon 的离线部署，每一部分主要涉及到相关 docker 镜像的加载及 Helm 的 repackage，通过该离线部署方案，能够大大加快 KubeVela 在离线环境的部署。
|
||||
|
|
|
|||
|
|
@ -14,6 +14,8 @@ hide_table_of_contents: false
|
|||
|
||||
KubeVela v1.3 在之前的多集群功能上进行了迭代，本文将为你揭示，如何使用 KubeVela 进行多集群应用的部署与管理，实现以上的业务需求。
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
### 开始之前
|
||||
|
||||
1. 准备一个 Kubernetes 集群作为 KubeVela 的控制平面。
|
||||
|
|
|
|||
|
|
@ -12,6 +12,8 @@ hide_table_of_contents: false
|
|||
|
||||
得益于 KubeVela 社区上百位开发者的参与和 30 多位核心贡献者的 500 多次代码提交， KubeVela 1.3 版本正式发布。相较于[三个月前发布的 v1.2 版本](https://kubevela.io/zh/blog/2022/01/27/blog-1.2)，新版本在 OAM 核心引擎（Vela Core），可视化应用交付平台 (VelaUX) 和社区插件生态这三方面都给出了大量新特性。这些特性的诞生均源自于阿里巴巴、LINE、招商银行、爱奇艺等社区用户大量的深度实践，最终贡献到 KubeVela 项目中，形成大家可以开箱即用的功能。
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## 现代化应用交付的痛点和挑战
|
||||
|
||||
那么，现代化的云原生应用交付和管理，我们到底遇到了什么痛点和挑战呢？
|
||||
|
|
|
|||
|
|
@ -11,6 +11,8 @@ hide_table_of_contents: false
|
|||
|
||||
在应用交付中另一个很大的诉求是对资源交付流程的透明化管理，比如社区里很多用户喜欢使用 Helm Chart ，把一大堆复杂的 YAML 打包在一起，但是一旦部署出现问题，如底层存储未正常提供、关联资源未正常创建、底层配置不正确等，即使是一个很小的问题也会因为整体黑盒化而难以排查。尤其是在现代混合的多集群混合环境下，资源类型众多、错综复杂，如何从中获取到有效信息并解决问题是一个非常大的难题。
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
|
||||
|
||||
如上图所示，KubeVela 已经发布了针对应用的实时观测资源拓扑图功能，进一步完善了 KubeVela 以应用为中心的交付体验。开发者在发起应用交付时只需要关心简单一致的 API ，需要排查问题或者关注交付过程时，可以通过资源拓扑功能，快速获取资源在不同集群的编排关系，从应用一直追踪到 Pod 实例运行状态，自动化地获取资源的关联关系，包括复杂且黑盒化的 Helm Chart。
|
||||
|
|
|
|||
|
|
@ -16,6 +16,8 @@ hide_table_of_contents: false
|
|||
|
||||
在这次发布的 1.4 版本中，我们围绕**让应用交付更安全、上手更简单、过程更透明**三个核心，加入了包括多集群权限认证和授权、复杂资源拓扑展示、一键安装控制平面等核心功能，全面加固了多租户场景下的交付安全性，提升了应用开发和交付的一致性体验，也让应用交付过程更加透明化。
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## 核心功能解读
|
||||
|
||||
### 开箱即用的认证和授权，对接 Kubernetes RBAC，天然支持多集群
|
||||
|
|
|
|||
|
|
@ -0,0 +1,450 @@
|
|||
---
|
||||
title: Helm Chart 多集群交付
|
||||
author: 孙健波（天元）
|
||||
author_title: KubeVela Team
|
||||
author_url: https://github.com/kubevela/kubevela
|
||||
author_image_url: https://KubeVela.io/img/logo.svg
|
||||
tags: [ KubeVela, "use-case", "helm chart", "multi-cluster" ]
|
||||
description: ""
|
||||
image: https://raw.githubusercontent.com/oam-dev/KubeVela.io/main/docs/resources/KubeVela-03.png
|
||||
hide_table_of_contents: false
|
||||
---
|
||||
|
||||
[Helm Charts](https://artifacthub.io/packages/search?kind=0) 如今已是一种非常流行的软件打包方式，在其应用市场中你可以找到接近一万款适用于云原生环境的软件。然后在如今的混合云多集群环境中，业务越来越依赖部署到不同的集群、不同的环境、同时指定不同的配置。再这样的环境下，单纯依赖 Helm 工具可能无法做到灵活的部署和交付。
|
||||
|
||||
在本文中，我们将介绍如何通过 [KubeVela](https://kubevela.io/) 解决多集群环境下 Helm Chart 的部署问题。如果你手里没有多集群也不要紧，我们将介绍一种仅依赖于 Docker 或者 Linux 系统的轻量级部署方式，可以让你轻松的体验多集群功能。当然，KubeVela 也完全具备[单集群的 Helm Chart 交付](https://kubevela.net/zh/docs/tutorials/helm)能力。
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## 前提条件
|
||||
|
||||
* 安装 Docker v20.10.5+ (runc >= v1.0.0-rc93) 或者你的操作系统是 Linux。
|
||||
* [VelaD](https://github.com/kubevela/velad)，一个轻量级的部署 KubeVela 和 Kubernetes 的工具.
|
||||
|
||||
|
||||
## 准备集群
|
||||
|
||||
> 本节是做 KubeVela 以及多集群环境的准备，我们将基于 Docker 或者 Linux 环境从头开始。如果你已经具备了 KubeVela 的环境并且完成了 [集群管理](https://kubevela.net/zh/docs/platform-engineers/system-operation/managing-clusters) ，则可以跳过本节。
|
||||
|
||||
1. 安装 KubeVela 控制平面
|
||||
|
||||
```shell
|
||||
velad install
|
||||
```
|
||||
|
||||
2. 将新创建的集群导入到环境变量
|
||||
|
||||
```
|
||||
export KUBECONFIG=$(velad kubeconfig --name default --host)
|
||||
```
|
||||
|
||||
到这里，恭喜你！我们已经完成了 KubeVela 控制平面的安装。你可以通过下面这个方式加入你的 Kubernetes 集群：
|
||||
|
||||
```
|
||||
vela cluster join <path-to-kubeconfig-of-cluster> --name foo
|
||||
```
|
||||
|
||||
如果你没有现成的 Kubernetes 集群，VelaD 也可以很方便的为你创建一个：
|
||||
|
||||
3. 用 velad 创建一个名为 `foo` 的集群，并加入到控制平面
|
||||
|
||||
```shell
|
||||
velad install --name foo --cluster-only
|
||||
vela cluster join $(velad kubeconfig --name foo --internal) --name foo
|
||||
```
|
||||
|
||||
作为一个充分可扩展的控制平面，KubeVela 的大多数能力都是作为插件提供的。接下来的几步我们介绍安装 Helm 多集群部署的必要插件。
|
||||
|
||||
4. 启用 velaux 插件，获得 UI 控制台
|
||||
|
||||
```shell
|
||||
vela addon enable velaux
|
||||
```
|
||||
|
||||
5. 启用 fluxcd 插件获得 helm chart 交付能力
|
||||
|
||||
```shell
|
||||
vela addon enable fluxcd
|
||||
```
|
||||
|
||||
如果你在加入新集群之前已启用过 `fluxcd` 插件，则应该通过以下方式来为新加入的集群启用（部署）插件：
|
||||
|
||||
```
|
||||
vela addon enable fluxcd --clusters foo
|
||||
```
|
||||
|
||||
至此，我们完成了所有的准备工作，可以查看加入的集群了：
|
||||
|
||||
```console
|
||||
$ vela cluster ls
|
||||
CLUSTER ALIAS TYPE ENDPOINT ACCEPTED LABELS
|
||||
local Internal - true
|
||||
foo X509Certificate https://172.20.0.6:6443 true
|
||||
```
|
||||
|
||||
`local` 是 KubeVela 控制平面的集群，`foo` 则是我们刚刚添加的集群。
|
||||
|
||||
## 多集群部署
|
||||
|
||||
我们可以使用 `topology` 策略来指定 Helm Chart 交付的环境，指令如下：
|
||||
|
||||
```yaml
|
||||
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
|
||||
```
|
||||
|
||||
`clusters` 字段的 topology 策略是一个切片（slice），此处可以指定多个集群的名称。
|
||||
你还可以使用标签选择器或指定命名空间，详情见 [参考文档](https://kubevela.net/zh/docs/end-user/policies/references#topology) 。
|
||||
|
||||
部署后，你可以通过以下方式检查已部署的应用程序：
|
||||
|
||||
```shell
|
||||
vela status helm-hello
|
||||
```
|
||||
|
||||
部署成功的预期输出应该如下：
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
你可以通过以下方式检查已部署的资源：
|
||||
|
||||
```
|
||||
$ vela status helm-hello --tree
|
||||
CLUSTER NAMESPACE RESOURCE STATUS
|
||||
foo ─── default ─┬─ HelmRelease/hello updated
|
||||
└─ HelmRepository/hello updated
|
||||
```
|
||||
|
||||
你也可以通过 VelaUX 检查已部署的资源。
|
||||
|
||||
## 使用 UI 控制台查看部署状态
|
||||
|
||||
通过使用 `velaux` UI 控制台，则可以很方便的查看多集群信息，并获得统一的体验。你可以参考[这篇文档](https://kubevela.io/docs/install#2-install-velaux)了解 VelaUX 的访问和使用细节。
|
||||
|
||||
通过 UI 界面，我们可以：
|
||||
|
||||
* 检查来自不同集群的实例状态和事件：
|
||||
|
||||
|
||||
|
||||
* 检查来自不同集群的实例日志：
|
||||
|
||||
|
||||
|
||||
* 检查资源拓扑关系和状态：
|
||||
|
||||
|
||||
|
||||
## 使用 Override 配置进行部署
|
||||
|
||||
在某些情况下，我们会为不同集群的 Helm Chart 设置不同的 Value ，这样我们可以使用 [Override 策略](https://kubevela.io/docs/end-user/policies/references#override) 。
|
||||
|
||||
下面是一个复杂的示例，我们将把一个 Helm Chart 部署到两个集群中，并为每个集群指定不同的 Value 。让我们部署它：
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
> **注意：如果你觉得策略和工作流程有点复杂，你可以将它们作为一个外部对象并仅引用该对象，用法和 [容器交付](https://kubevela.io/docs/case-studies/multi-cluster#use-policies-and-workflow-outside-the-application) 是一样的。**
|
||||
|
||||
部署过程分为三个步骤：（1）部署到本地集群；（2）等待人工审批；（3）部署到 foo 集群。你会发现它在第一步之后就被暂停了，就像下面这样：
|
||||
|
||||
```
|
||||
$ 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
|
||||
```
|
||||
|
||||
你可以查看并使用 Value 为 “Welcome to Control Plane Cluster!” 的部署在控制平面的 Helm Chart 。
|
||||
|
||||
```
|
||||
vela port-forward helm-hello
|
||||
```
|
||||
|
||||
浏览器会自动提示如下页面：
|
||||
|
||||
|
||||
|
||||
发现部署成功，让我们继续。
|
||||
|
||||
```shell
|
||||
vela workflow resume helm-hello
|
||||
```
|
||||
|
||||
然后它会部署到 foo 集群，你可以查看这些资源的详细信息。
|
||||
|
||||
```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'
|
||||
```
|
||||
|
||||
再次使用端口转发：
|
||||
|
||||
```shell
|
||||
vela port-forward helm-hello
|
||||
```
|
||||
|
||||
然后它会弹出一些选项：
|
||||
|
||||
```
|
||||
? 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
|
||||
```
|
||||
|
||||
选择带有 `foo` 集群的选项，然后你会看到结果已经被新消息覆盖。
|
||||
|
||||
```console
|
||||
$ curl http://127.0.0.1:8080/
|
||||
...snip...
|
||||
<div id="message">
|
||||
Welcome to Your New Foo Cluster!
|
||||
</div>
|
||||
...snip...
|
||||
```
|
||||
|
||||
## 为不同环境指定不同的 Value 文件
|
||||
|
||||
你可以为不同环境选择 Helm Chart 中现有的不同 Value 文件。比如：
|
||||
|
||||
请确保你的本地集群有两个命名空间 “test” 和 “prod”，它们代表我们示例中的两个环境。
|
||||
|
||||
我们以 Chart `hello-kubernetes-chart` 为例。这个 Chart 有两个 Value 文件。你可以拉取此 Chart 并查看其中包含的所有文件：
|
||||
|
||||
```yaml
|
||||
$ tree ./hello-kubernetes-chart
|
||||
./hello-kubernetes-chart
|
||||
├── Chart.yaml
|
||||
├── templates
|
||||
│ ├── NOTES.txt
|
||||
│ ├── _helpers.tpl
|
||||
│ ├── config-map.yaml
|
||||
│ ├── deployment.yaml
|
||||
│ ├── hpa.yaml
|
||||
│ ├── ingress.yaml
|
||||
│ ├── service.yaml
|
||||
│ ├── serviceaccount.yaml
|
||||
│ └── tests
|
||||
│ └── test-connection.yaml
|
||||
├── values-production.yaml
|
||||
└── values.yaml
|
||||
```
|
||||
|
||||
我们可以看到此 Chart 中有 `values.yaml` `values-production.yaml` 这两个 Value 文件。
|
||||
|
||||
```yaml
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: hello-kubernetes
|
||||
spec:
|
||||
components:
|
||||
- name: hello-kubernetes
|
||||
type: helm
|
||||
properties:
|
||||
repoType: "helm"
|
||||
url: "https://wangyikewxgm.github.io/my-charts/"
|
||||
chart: "hello-kubernetes-chart"
|
||||
version: "0.1.0"
|
||||
|
||||
policies:
|
||||
- name: topology-test
|
||||
type: topology
|
||||
properties:
|
||||
clusters: ["local"]
|
||||
namespace: "test"
|
||||
- name: topology-prod
|
||||
type: topology
|
||||
properties:
|
||||
clusters: ["local"]
|
||||
namespace: "prod"
|
||||
- name: override-prod
|
||||
type: override
|
||||
properties:
|
||||
components:
|
||||
- name: hello-kubernetes
|
||||
properties:
|
||||
valuesFiles:
|
||||
- "values-production.yaml"
|
||||
workflow:
|
||||
steps:
|
||||
- name: deploy2test
|
||||
type: deploy
|
||||
properties:
|
||||
policies: ["topology-test"]
|
||||
- name: deploy2prod
|
||||
type: deploy
|
||||
properties:
|
||||
policies: ["topology-prod", "override-prod"]
|
||||
EOF
|
||||
```
|
||||
|
||||
访问 Application 的 endpoint ：
|
||||
|
||||
```yaml
|
||||
vela port-forward hello-kubernetes
|
||||
```
|
||||
|
||||
如果你选择 ```Cluster: local | Namespace: test | Kind: HelmRelease | Name: hello-kubernetes``` 你会看到：
|
||||
|
||||
|
||||
|
||||
选择 ```Cluster: local | Namespace: prod | Kind: HelmRelease | Name: hello-kubernetes``` 则会看到
|
||||
|
||||
|
||||
|
||||
## 清理
|
||||
|
||||
如果你使用 velad 进行此演示，则可以通过以下方式便捷地进行清理：
|
||||
|
||||
* 清理 foo 集群
|
||||
```
|
||||
velad uninstall -n foo
|
||||
```
|
||||
|
||||
* 清理默认集群
|
||||
```
|
||||
velad uninstall
|
||||
```
|
||||
|
||||
## 不仅如此
|
||||
|
||||
KubeVela 提供的能力远不止如此，通过安装其他插件，你还可以获得包括[金丝雀发布](https://kubevela.io/docs/tutorials/helm-rollout) 在内的更多能力，为你的 Helm Chart 交付保驾护航。
|
||||
|
||||
快使用 KubeVela 交付 Helm Chart ，让现代化的应用交付和管理更简单、轻松、可靠！
|
||||
|
|
@ -318,5 +318,8 @@
|
|||
},
|
||||
"sidebar.docs.category.Declarative Workflow": {
|
||||
"message": "声明式工作流"
|
||||
},
|
||||
"sidebar.docs.category.Multi Cluster Delivery": {
|
||||
"message": "多集群交付"
|
||||
}
|
||||
}
|
||||
|
|
@ -382,3 +382,130 @@ traits:
|
|||
image: busybox:1.34
|
||||
command: ["sleep", "864000"]
|
||||
```
|
||||
|
||||
## 引用对象的多集群差异化部署
|
||||
|
||||
通过 `override` 策略与负责差异化配置的运维特征相结合，可以完成引用对象的多集群差异化部署。
|
||||
|
||||
我们以一个 Kubernetes Deployment YAML 为例：
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
labels:
|
||||
app: demo
|
||||
name: demo
|
||||
namespace: demo
|
||||
spec:
|
||||
replicas: 1
|
||||
selector:
|
||||
matchLabels:
|
||||
app: demo
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: demo
|
||||
spec:
|
||||
containers:
|
||||
- image: oamdev/testapp:v1
|
||||
name: demo
|
||||
```
|
||||
|
||||
通过指定 `topology` 策略来描述部署的集群。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: Policy
|
||||
metadata:
|
||||
name: cluster-beijing
|
||||
namespace: demo
|
||||
type: topology
|
||||
properties:
|
||||
clusters: ["<clusterid1>"]
|
||||
---
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: Policy
|
||||
metadata:
|
||||
name: cluster-hangzhou
|
||||
namespace: demo
|
||||
type: topology
|
||||
properties:
|
||||
clusters: ["<clusterid2>"]
|
||||
```
|
||||
|
||||
然后我们通过 `override` 策略来差异化配置运维特征，即给不同的环境配置不同的运维特征。通过这些运维特征去修改引用对象的参数。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: Policy
|
||||
metadata:
|
||||
name: override-replic-beijing
|
||||
namespace: demo
|
||||
type: override
|
||||
properties:
|
||||
components:
|
||||
- name: "demo"
|
||||
traits:
|
||||
- type: scaler
|
||||
properties:
|
||||
replicas: 3
|
||||
---
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: Policy
|
||||
metadata:
|
||||
name: override-replic-hangzhou
|
||||
namespace: demo
|
||||
type: override
|
||||
properties:
|
||||
components:
|
||||
- name: "demo"
|
||||
traits:
|
||||
- type: scaler
|
||||
properties:
|
||||
replicas: 5
|
||||
```
|
||||
|
||||
然后，定义一个使用差异化配置做多集群部署的工作流：
|
||||
|
||||
```
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: Workflow
|
||||
metadata:
|
||||
name: deploy-demo
|
||||
namespace: demo
|
||||
steps:
|
||||
- type: deploy
|
||||
name: deploy-bejing
|
||||
properties:
|
||||
policies: ["override-replic-beijing", "cluster-beijing"]
|
||||
- type: deploy
|
||||
name: deploy-hangzhou
|
||||
properties:
|
||||
policies: ["override-replic-hangzhou", "cluster-hangzhou"]
|
||||
```
|
||||
|
||||
最终，我们将这些对象组合起来，并且通过部署一个执行计划（Application） 来触发部署：
|
||||
|
||||
```
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: demo
|
||||
namespace: demo
|
||||
annotations:
|
||||
app.oam.dev/publishVersion: version1
|
||||
spec:
|
||||
components:
|
||||
- name: demo
|
||||
type: ref-objects
|
||||
properties:
|
||||
objects:
|
||||
- apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
name: demo
|
||||
workflow:
|
||||
ref: deploy-demo
|
||||
```
|
||||
|
||||
通过 KubeVela，你可以引用任意的 Kubernetes 资源，然后做多集群分发和差异化配置。
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 54 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 48 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 46 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 1.4 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 586 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 476 KiB |
|
|
@ -2,423 +2,5 @@
|
|||
title: 多集群交付
|
||||
---
|
||||
|
||||
本章节介绍如何将 Helm Chart 部署到多个目标环境和集群。
|
||||
在开始之前，请确保你已经了解 [Helm Chart 交付](./helm) 及其相关背景。
|
||||
|
||||
## 准备集群
|
||||
|
||||
> 本节是为多集群做准备，方便起见，我们将从头开始。如果你已经完成 [集群管理](../platform-engineers/system-operation/managing-clusters) ，则可以跳过本节。
|
||||
|
||||
1. 使用 [velad](https://github.com/kubevela/velad) 安装 KubeVela 控制平面
|
||||
|
||||
```shell
|
||||
velad install
|
||||
```
|
||||
|
||||
2. 为新创建的集群导出 KubeConfig
|
||||
|
||||
```
|
||||
export KUBECONFIG=$(velad kubeconfig --name default --host)
|
||||
```
|
||||
|
||||
3. 为 UI 控制台启用 velaux 插件
|
||||
|
||||
```shell
|
||||
vela addon enable velaux
|
||||
```
|
||||
|
||||
4. 用 velad 创建一个名为 `foo` 的集群
|
||||
|
||||
```shell
|
||||
velad install --name foo --cluster-only
|
||||
```
|
||||
|
||||
5. 将创建的集群加入控制平面
|
||||
|
||||
```shell
|
||||
vela cluster join $(velad kubeconfig --name foo --internal) --name foo
|
||||
```
|
||||
|
||||
6. 为 helm 组件启用 fluxcd 插件
|
||||
|
||||
```shell
|
||||
vela addon enable fluxcd
|
||||
```
|
||||
|
||||
如果你在加入新集群之前已启用 `fluxcd` 插件，则应该通过以下方式来为新加入的集群启用插件：
|
||||
|
||||
```
|
||||
vela addon enable fluxcd --clusters foo
|
||||
```
|
||||
|
||||
现在我们完成了所有的准备工作，可以查看加入的集群了：
|
||||
|
||||
```console
|
||||
$ vela cluster ls
|
||||
CLUSTER ALIAS TYPE ENDPOINT ACCEPTED LABELS
|
||||
local Internal - true
|
||||
foo X509Certificate https://172.20.0.6:6443 true
|
||||
```
|
||||
|
||||
`local` 是 KubeVela 控制平面的集群，`foo` 则是我们刚刚添加的集群。
|
||||
|
||||
## 多集群部署
|
||||
|
||||
多集群交付的原理与 [容器的多集群应用交付](../case-studies/multi-cluster#deliver-application-to-clusters) 的基本一致。
|
||||
|
||||
我们可以使用 `topology` 策略来指定 Helm Chart 交付的环境，指令如下：
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
`clusters` 字段的 topology 策略是一个切片（slice），此处可以指定多个集群的名称。
|
||||
你还可以使用标签选择器或指定命名空间，详情见 [参考文档](../end-user/policies/references#topology) 。
|
||||
|
||||
部署后，你可以通过以下方式检查已部署的应用程序：
|
||||
|
||||
```shell
|
||||
vela status helm-hello
|
||||
```
|
||||
|
||||
部署成功的预期输出应该如下：
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
你可以通过以下方式检查已部署的资源：
|
||||
|
||||
```
|
||||
$ vela status helm-hello --tree
|
||||
CLUSTER NAMESPACE RESOURCE STATUS
|
||||
foo ─── default ─┬─ HelmRelease/hello updated
|
||||
└─ HelmRepository/hello updated
|
||||
```
|
||||
|
||||
你也可以通过 VelaUX 检查已部署的资源，这已在 [helm 交付文档](./helm#visualize-the-resources-created-by-helm-release) 中介绍。
|
||||
|
||||
## 使用 Override 配置进行部署
|
||||
|
||||
在某些情况下，我们会为不同集群的 Helm Chart 设置不同的 Value ，这样我们可以使用 [Override 策略](../end-user/policies/references#override) 。
|
||||
|
||||
下面是一个复杂的示例，我们将把一个 Helm Chart 部署到两个集群中，并为每个集群指定不同的 Value 。让我们部署它：
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
> **注意：如果你觉得策略和工作流程有点复杂，你可以将它们作为一个外部对象并仅引用该对象，用法和 [容器交付](../case-studies/multi-cluster#use-policies-and-workflow-outside-the-application) 是一样的。**
|
||||
|
||||
部署过程分为三个步骤：（1）部署到本地集群；（2）等待人工审批；（3）部署到 foo 集群。你会发现它在第一步之后就被暂停了，就像下面这样：
|
||||
|
||||
```
|
||||
$ 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
|
||||
```
|
||||
|
||||
你可以查看并使用 Value 为 “Welcome to Control Plane Cluster!” 的部署在控制平面的 Helm Chart 。
|
||||
|
||||
```
|
||||
vela port-forward helm-hello
|
||||
```
|
||||
|
||||
浏览器会自动提示如下页面：
|
||||
|
||||
|
||||
|
||||
发现部署成功，让我们继续。
|
||||
|
||||
```shell
|
||||
vela workflow resume helm-hello
|
||||
```
|
||||
|
||||
然后它会部署到 foo 集群，你可以查看这些资源的详细信息。
|
||||
|
||||
```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'
|
||||
```
|
||||
|
||||
再次使用端口转发：
|
||||
|
||||
```shell
|
||||
vela port-forward helm-hello
|
||||
```
|
||||
|
||||
然后它会弹出一些选项：
|
||||
|
||||
```
|
||||
? 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
|
||||
```
|
||||
|
||||
选择带有 `foo` 集群的选项，然后你会看到结果已经被新消息覆盖。
|
||||
|
||||
```console
|
||||
$ curl http://127.0.0.1:8080/
|
||||
...snip...
|
||||
<div id="message">
|
||||
Welcome to Your New Foo Cluster!
|
||||
</div>
|
||||
...snip...
|
||||
```
|
||||
|
||||
## 使用 UI 控制台查看更多信息
|
||||
|
||||
如果你使用的是 `velaux` UI 控制台，则可以查看更多的多集群信息，并拥有统一的体验。
|
||||
|
||||
* 检查来自不同集群的 Pod 状态和事件：
|
||||
|
||||
|
||||
|
||||
* 检查来自不同集群的 Pod 日志：
|
||||
|
||||
|
||||
|
||||
* 检查资源拓扑树的关系和状态：
|
||||
|
||||
|
||||
|
||||
## 为不同环境指定不同的 Value 文件
|
||||
|
||||
你可以为不同环境选择 Helm Chart 中现有的不同 Value 文件。比如：
|
||||
|
||||
请确保你的本地集群有两个命名空间 “test” 和 “prod”，它们代表我们示例中的两个环境。
|
||||
|
||||
我们以 Chart `hello-kubernetes-chart` 为例。这个 Chart 有两个 Value 文件。你可以拉取此 Chart 并查看其中包含的所有文件：
|
||||
|
||||
```yaml
|
||||
$ tree ./hello-kubernetes-chart
|
||||
./hello-kubernetes-chart
|
||||
├── Chart.yaml
|
||||
├── templates
|
||||
│ ├── NOTES.txt
|
||||
│ ├── _helpers.tpl
|
||||
│ ├── config-map.yaml
|
||||
│ ├── deployment.yaml
|
||||
│ ├── hpa.yaml
|
||||
│ ├── ingress.yaml
|
||||
│ ├── service.yaml
|
||||
│ ├── serviceaccount.yaml
|
||||
│ └── tests
|
||||
│ └── test-connection.yaml
|
||||
├── values-production.yaml
|
||||
└── values.yaml
|
||||
```
|
||||
|
||||
我们可以看到此 Chart 中有 `values.yaml` `values-production.yaml` 这两个 Value 文件。
|
||||
|
||||
```yaml
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: hello-kubernetes
|
||||
spec:
|
||||
components:
|
||||
- name: hello-kubernetes
|
||||
type: helm
|
||||
properties:
|
||||
repoType: "helm"
|
||||
url: "https://wangyikewxgm.github.io/my-charts/"
|
||||
chart: "hello-kubernetes-chart"
|
||||
version: "0.1.0"
|
||||
|
||||
policies:
|
||||
- name: topology-test
|
||||
type: topology
|
||||
properties:
|
||||
clusters: ["local"]
|
||||
namespace: "test"
|
||||
- name: topology-prod
|
||||
type: topology
|
||||
properties:
|
||||
clusters: ["local"]
|
||||
namespace: "prod"
|
||||
- name: override-prod
|
||||
type: override
|
||||
properties:
|
||||
components:
|
||||
- name: hello-kubernetes
|
||||
properties:
|
||||
valuesFiles:
|
||||
- "values-production.yaml"
|
||||
workflow:
|
||||
steps:
|
||||
- name: deploy2test
|
||||
type: deploy
|
||||
properties:
|
||||
policies: ["topology-test"]
|
||||
- name: deploy2prod
|
||||
type: deploy
|
||||
properties:
|
||||
policies: ["topology-prod", "override-prod"]
|
||||
EOF
|
||||
```
|
||||
|
||||
访问 Application 的 endpoint ：
|
||||
|
||||
```yaml
|
||||
vela port-forward hello-kubernetes
|
||||
```
|
||||
|
||||
如果你选择 ```Cluster: local | Namespace: test | Kind: HelmRelease | Name: hello-kubernetes``` 你会看到：
|
||||
|
||||
|
||||
|
||||
选择 ```Cluster: local | Namespace: prod | Kind: HelmRelease | Name: hello-kubernetes``` 则会看到
|
||||
|
||||
|
||||
|
||||
## 清理
|
||||
|
||||
如果你使用 velad 进行此演示，则可以通过以下方式便捷地进行清理：
|
||||
|
||||
* 清理 foo 集群
|
||||
```
|
||||
velad uninstall -n foo
|
||||
```
|
||||
|
||||
* 清理默认集群
|
||||
```
|
||||
velad uninstall
|
||||
```
|
||||
|
||||
使用 Helm Chart ，快乐交付一下！
|
||||
文档已迁移至[博客](https://kubevela.net/zh/blog/2022/07/07/helm-multi-cluster).
|
||||
|
|
@ -122,6 +122,4 @@ Services:
|
|||
|
||||
到此，你已经掌握了 Helm 应用的交付能力，快去交付更多的 Helm 应用吧。
|
||||
|
||||
## 下一步
|
||||
|
||||
- [学习直接部署 Kubernetes 原生资源](./k8s-object)
|
||||
如果你想掌握 Helm Chart 的多集群部署，可以参考[这篇博客](https://kubevela.net/zh/blog/2022/07/07/helm-multi-cluster)了解实践细节。
|
||||
|
|
|
|||
|
|
@ -16,81 +16,10 @@ KubeVela 支持面向应用组织多个 Kubernetes 资源进行交付，常见
|
|||
|
||||
- 准备一个 Deployment+Service 资源的 Yaml 定义文件，请注意，涉及多个资源时请将 Deployment、Statefulset、Job 等工作负载类资源置于第一个。如果多个工作负载类资源，请拆分为多个应用。
|
||||
|
||||
<!-- - 准备两个或更多的运行时集群, 参考: [管理运行时集群](./manage-cluster) TODO v1.2-->
|
||||
|
||||
## 规划并创建交付目标
|
||||
|
||||
[交付目标(Target)](../getting-started/core-concept#交付目标（target）) 定义了应用交付的运行时集群和命名空间，创建交付目标的同时完成运行时集群的命名空间创建。
|
||||
|
||||
点击 `New Target` 按钮进入创建流程，填写必要的信息，选择集群、命名空间即可完成创建。我们使用 2 个集群来创建交付目标，当然如果你暂无多个集群，也可以使用一个集群的多个命名空间来创建多个交付目标。我们最少准备 3 个交付目标，1 个用于测试环境，2 个或更多用于生产环境。
|
||||
|
||||
## 创建 Kubernetes 应用
|
||||
|
||||
完成交付目标创建后，我们开始创建应用。与 [交付第一个应用](../quick-start) 一样，首先我们需要填写应用的基础信息，这里有三个不同点：
|
||||
|
||||
（1）选择部署类型 k8s-objects; 该类型用于部署多个 Kubernetes 原生资源，请注意，同一个应用请尽量保持只有一个 Workload 资源，即不要出现多个 Deployment 或者 Statefulset。
|
||||
|
||||
（2）环境规划时我们分配两个环境，测试环境和生产环境，其中开发环境选择 1 个准备的开发用交付目标, 生产环境选择多个交付目标。
|
||||
|
||||
|
||||
|
||||
（3）设置部署参数，直接上传准备好的 Yaml 文件即可。需要注意的是，资源的名称如果在配置中指定，即使用配置的名称，你需要确定其与已存在的资源不冲突，如果不指定，则使用 KubeVela 资源命名规则自动命名。编辑器会自动将输入的内容进行格式化。
|
||||
|
||||
|
||||
|
||||
设置完成后点击 `Create` 即可完成应用创建。
|
||||
|
||||
## 部署测试环境
|
||||
|
||||
|
||||
|
||||
进入应用管理页面，你会发现改应用自动生成了 2 个环境，2 个工作流。Vela 会自动为每一个环境生成默认的工作流，工作流由`deploy2env`类型的步骤组成，每一个交付目标对于一个步骤，表示将应用交付到该交付目标。
|
||||
|
||||
我们首先切换到测试环境 Tab 页面下，点击页面中的 Deploy 按钮进行该环境的部署。由于测试环境我们只分配了一个交付目标，默认情况下工作流步骤只有一步。观察页面右上方的工作流执行状态，其变更为绿色后即已执行完成。如果其为红色，即工作流执行遇到故障，我们将鼠标移动到步骤上方即可查询失败原因，处理异常后工作量会继续重拾，如果故障解决其可完成部署。
|
||||
|
||||
部署完成后，刷新实例列表即可查看到 Pod 列表，如果 Pod 运行异常可以点击行查看 Pod 详情信息。
|
||||
|
||||
|
||||
|
||||
对于测试环境，它当然应该持续进行迭代，当我们变更了部署参数（镜像版本，实例数等），只需要重新执行测试环境的 Workflow 即可升级部署，鼠标移动到页面右上方，选择测试环境的 流水线 执行即可。若点击旁边的 Deploy 按钮，其含义是执行默认的流水线。
|
||||
|
||||
|
||||
|
||||
## 部署生产环境
|
||||
|
||||
当我们在测试环境多次部署完成业务的测试工作以后，我们要开始将应用发布到生产环境，我们切换到生产环境 Tab 下，会发现当前环境处于未部署状态。是的，同一个应用的不同环境是完全隔离管理的，它的背后是生成独立的应用部署实例（Application CR）。
|
||||
|
||||
由于我们生产环境有多个交付目标，它默认情况下是根据先后顺序依次部署，这时如果假设大家希望在部署完第一个交付目标后，希望人工审核/校验一下部署状态后再执行后续部署。带着这个需求，我们需要进入到应用基准配置的工作流管理页面。
|
||||
|
||||
|
||||
|
||||
我们可以看到已经自动生成的两条流水线配置，这时我们点击生产环境流水线的 `Edit` 进入编辑模式，从左侧的工作流步骤的选项中选择 `suspend`, 将其拖入右侧画板中。便捷弹窗将自动出现，该类型没有更多的配置参数，你可以设置别名或直接保存即可。
|
||||
|
||||
添加完成后我们需要编排它的顺序，首先断开已有步骤之间的连线（通过点击连线+delete 键）,然后将 suspend 步骤连线在中间即可。编辑完成后需要点击右上方的 Save 按钮即可保存并生效。
|
||||
|
||||
|
||||
|
||||
工作流编辑完成后回到生产环境页面下，点击 Deploy 按钮，即可开始生产环境的部署。
|
||||
|
||||
|
||||
|
||||
观察右上方的工作流执行状态，当第一个交付目标完成部署后，即会停止在第二个步骤等待用户进行审核操作，我们从下方的实例列表也可以查看到第一个交付目标的实例已经生成并处于运行状态。
|
||||
|
||||
暂停步骤有三个操作可以进行：
|
||||
|
||||
- Rollback: 版本回退，即将采用历史最新的完成部署的版本进行重新部署，当前版本部署工作流终止。
|
||||
- Terminate: 终止，即停止当前版本的部署，但不会改变已经部署的交付目标。
|
||||
- Continue: 继续执行，进入下一个步骤的执行。
|
||||
|
||||
当你选择继续执行后，第二个或更多的交付目标即可完成部署。从实例列表中你可以查看到多个交付目标的实例，可以通过选择交付目标进行实例筛选查询。
|
||||
|
||||
|
||||
|
||||
## 通过 CLI 交付
|
||||
|
||||
通过 CLI 部署的应用没有环境的概念，你可以通过部署多个应用来实现与控制台中类似的环境隔离。
|
||||
|
||||
这是一个部署 Kubernetes 原生资源的示例应用，我们知道大多数 Kubernetes 应用都由 Deployment 和 Service 组成。该应用配置中包括了 2 个部署策略和 3 个工作流步骤，这些配置的表达的含义是部署应用到两个命名空间且在第一个完成部署后需要人工审核。
|
||||
这是一个部署 Kubernetes 原生资源的示例应用，我们知道大多数 Kubernetes 应用都由 Deployment 和 Service 组成。
|
||||
该应用配置中包括了 2 个部署策略和 3 个工作流步骤，这些配置的表达的含义是部署应用到两个命名空间且在第一个完成部署后需要人工审核。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
|
|
@ -192,7 +121,78 @@ $ vela up -f https://kubevela.io/example/applications/app-with-k8s-objects.yaml
|
|||
$ vela workflow resume app-with-k8s-objects
|
||||
```
|
||||
|
||||
## 下一步
|
||||
## 通过 UI 控制台部署
|
||||
|
||||
- [交付云厂商服务](./consume-cloud-services)
|
||||
- [分发已存在的 Kubernetes 对象](../end-user/components/ref-objects)
|
||||
如果你开启了 [`velaux`](../reference/addons/velaux) 插件，你可以直接在 UI 控制台完成 Kubernetes 对象的部署。
|
||||
|
||||
### 规划并创建交付目标
|
||||
|
||||
[交付目标(Target)](../getting-started/core-concept#交付目标（target）) 定义了应用交付的运行时集群和命名空间，创建交付目标的同时完成运行时集群的命名空间创建。
|
||||
|
||||
点击 `New Target` 按钮进入创建流程，填写必要的信息，选择集群、命名空间即可完成创建。我们使用 2 个集群来创建交付目标，当然如果你暂无多个集群，也可以使用一个集群的多个命名空间来创建多个交付目标。我们最少准备 3 个交付目标，1 个用于测试环境，2 个或更多用于生产环境。
|
||||
|
||||
### 创建 Kubernetes 应用
|
||||
|
||||
完成交付目标创建后，我们开始创建应用。与 [交付第一个应用](../quick-start) 一样，首先我们需要填写应用的基础信息，这里有三个不同点：
|
||||
|
||||
（1）选择部署类型 k8s-objects; 该类型用于部署多个 Kubernetes 原生资源，请注意，同一个应用请尽量保持只有一个 Workload 资源，即不要出现多个 Deployment 或者 Statefulset。
|
||||
|
||||
（2）环境规划时我们分配两个环境，测试环境和生产环境，其中开发环境选择 1 个准备的开发用交付目标, 生产环境选择多个交付目标。
|
||||
|
||||
|
||||
|
||||
（3）设置部署参数，直接上传准备好的 Yaml 文件即可。需要注意的是，资源的名称如果在配置中指定，即使用配置的名称，你需要确定其与已存在的资源不冲突，如果不指定，则使用 KubeVela 资源命名规则自动命名。编辑器会自动将输入的内容进行格式化。
|
||||
|
||||
|
||||
|
||||
设置完成后点击 `Create` 即可完成应用创建。
|
||||
|
||||
### 部署测试环境
|
||||
|
||||
|
||||
|
||||
进入应用管理页面，你会发现改应用自动生成了 2 个环境，2 个工作流。Vela 会自动为每一个环境生成默认的工作流，工作流由`deploy2env`类型的步骤组成，每一个交付目标对于一个步骤，表示将应用交付到该交付目标。
|
||||
|
||||
我们首先切换到测试环境 Tab 页面下，点击页面中的 Deploy 按钮进行该环境的部署。由于测试环境我们只分配了一个交付目标，默认情况下工作流步骤只有一步。观察页面右上方的工作流执行状态，其变更为绿色后即已执行完成。如果其为红色，即工作流执行遇到故障，我们将鼠标移动到步骤上方即可查询失败原因，处理异常后工作量会继续重拾，如果故障解决其可完成部署。
|
||||
|
||||
部署完成后，刷新实例列表即可查看到 Pod 列表，如果 Pod 运行异常可以点击行查看 Pod 详情信息。
|
||||
|
||||
|
||||
|
||||
对于测试环境，它当然应该持续进行迭代，当我们变更了部署参数（镜像版本，实例数等），只需要重新执行测试环境的 Workflow 即可升级部署，鼠标移动到页面右上方，选择测试环境的 流水线 执行即可。若点击旁边的 Deploy 按钮，其含义是执行默认的流水线。
|
||||
|
||||
|
||||
|
||||
### 部署生产环境
|
||||
|
||||
当我们在测试环境多次部署完成业务的测试工作以后，我们要开始将应用发布到生产环境，我们切换到生产环境 Tab 下，会发现当前环境处于未部署状态。是的，同一个应用的不同环境是完全隔离管理的，它的背后是生成独立的应用部署实例（Application CR）。
|
||||
|
||||
由于我们生产环境有多个交付目标，它默认情况下是根据先后顺序依次部署，这时如果假设大家希望在部署完第一个交付目标后，希望人工审核/校验一下部署状态后再执行后续部署。带着这个需求，我们需要进入到应用基准配置的工作流管理页面。
|
||||
|
||||
|
||||
|
||||
我们可以看到已经自动生成的两条流水线配置，这时我们点击生产环境流水线的 `Edit` 进入编辑模式，从左侧的工作流步骤的选项中选择 `suspend`, 将其拖入右侧画板中。便捷弹窗将自动出现，该类型没有更多的配置参数，你可以设置别名或直接保存即可。
|
||||
|
||||
添加完成后我们需要编排它的顺序，首先断开已有步骤之间的连线（通过点击连线+delete 键）,然后将 suspend 步骤连线在中间即可。编辑完成后需要点击右上方的 Save 按钮即可保存并生效。
|
||||
|
||||
|
||||
|
||||
工作流编辑完成后回到生产环境页面下，点击 Deploy 按钮，即可开始生产环境的部署。
|
||||
|
||||
|
||||
|
||||
观察右上方的工作流执行状态，当第一个交付目标完成部署后，即会停止在第二个步骤等待用户进行审核操作，我们从下方的实例列表也可以查看到第一个交付目标的实例已经生成并处于运行状态。
|
||||
|
||||
暂停步骤有三个操作可以进行：
|
||||
|
||||
- Rollback: 版本回退，即将采用历史最新的完成部署的版本进行重新部署，当前版本部署工作流终止。
|
||||
- Terminate: 终止，即停止当前版本的部署，但不会改变已经部署的交付目标。
|
||||
- Continue: 继续执行，进入下一个步骤的执行。
|
||||
|
||||
当你选择继续执行后，第二个或更多的交付目标即可完成部署。从实例列表中你可以查看到多个交付目标的实例，可以通过选择交付目标进行实例筛选查询。
|
||||
|
||||
|
||||
|
||||
至此，你已经完成了基本的 Kubernetes 对象的交付过程。
|
||||
|
||||
如果你想了解如何将 Kubernetes 对象分发至多集群，可以参考[多集群部分](../end-user/components/ref-objects)文档。
|
||||
|
|
|
|||
|
|
@ -118,6 +118,8 @@ Services:
|
|||
✅ scaler
|
||||
```
|
||||
|
||||
## 下一步
|
||||
至此，你已经了解了最基本的容器镜像部署，接下来你可以：
|
||||
|
||||
[学习基于 Helm Chart 部署应用](./helm)
|
||||
* 了解 [组件参考手册](../end-user/components/references#webservice)查看更多字段说明。
|
||||
* 了解 [运维特征参考手册](../end-user/traits/references)查看适用的运维特征功能。
|
||||
* 了解 [多集群交付](../case-studies/multi-cluster)，学习如何将容器镜像部署到多集群、多环境中。
|
||||
|
|
@ -318,5 +318,8 @@
|
|||
},
|
||||
"sidebar.docs.category.Declarative Workflow": {
|
||||
"message": "声明式工作流"
|
||||
},
|
||||
"sidebar.docs.category.Multi Cluster Delivery": {
|
||||
"message": "多集群交付"
|
||||
}
|
||||
}
|
||||
|
|
@ -382,3 +382,130 @@ traits:
|
|||
image: busybox:1.34
|
||||
command: ["sleep", "864000"]
|
||||
```
|
||||
|
||||
## 引用对象的多集群差异化部署
|
||||
|
||||
通过 `override` 策略与负责差异化配置的运维特征相结合，可以完成引用对象的多集群差异化部署。
|
||||
|
||||
我们以一个 Kubernetes Deployment YAML 为例：
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
labels:
|
||||
app: demo
|
||||
name: demo
|
||||
namespace: demo
|
||||
spec:
|
||||
replicas: 1
|
||||
selector:
|
||||
matchLabels:
|
||||
app: demo
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: demo
|
||||
spec:
|
||||
containers:
|
||||
- image: oamdev/testapp:v1
|
||||
name: demo
|
||||
```
|
||||
|
||||
通过指定 `topology` 策略来描述部署的集群。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: Policy
|
||||
metadata:
|
||||
name: cluster-beijing
|
||||
namespace: demo
|
||||
type: topology
|
||||
properties:
|
||||
clusters: ["<clusterid1>"]
|
||||
---
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: Policy
|
||||
metadata:
|
||||
name: cluster-hangzhou
|
||||
namespace: demo
|
||||
type: topology
|
||||
properties:
|
||||
clusters: ["<clusterid2>"]
|
||||
```
|
||||
|
||||
然后我们通过 `override` 策略来差异化配置运维特征，即给不同的环境配置不同的运维特征。通过这些运维特征去修改引用对象的参数。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: Policy
|
||||
metadata:
|
||||
name: override-replic-beijing
|
||||
namespace: demo
|
||||
type: override
|
||||
properties:
|
||||
components:
|
||||
- name: "demo"
|
||||
traits:
|
||||
- type: scaler
|
||||
properties:
|
||||
replicas: 3
|
||||
---
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: Policy
|
||||
metadata:
|
||||
name: override-replic-hangzhou
|
||||
namespace: demo
|
||||
type: override
|
||||
properties:
|
||||
components:
|
||||
- name: "demo"
|
||||
traits:
|
||||
- type: scaler
|
||||
properties:
|
||||
replicas: 5
|
||||
```
|
||||
|
||||
然后，定义一个使用差异化配置做多集群部署的工作流：
|
||||
|
||||
```
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: Workflow
|
||||
metadata:
|
||||
name: deploy-demo
|
||||
namespace: demo
|
||||
steps:
|
||||
- type: deploy
|
||||
name: deploy-bejing
|
||||
properties:
|
||||
policies: ["override-replic-beijing", "cluster-beijing"]
|
||||
- type: deploy
|
||||
name: deploy-hangzhou
|
||||
properties:
|
||||
policies: ["override-replic-hangzhou", "cluster-hangzhou"]
|
||||
```
|
||||
|
||||
最终，我们将这些对象组合起来，并且通过部署一个执行计划（Application） 来触发部署：
|
||||
|
||||
```
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: demo
|
||||
namespace: demo
|
||||
annotations:
|
||||
app.oam.dev/publishVersion: version1
|
||||
spec:
|
||||
components:
|
||||
- name: demo
|
||||
type: ref-objects
|
||||
properties:
|
||||
objects:
|
||||
- apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
name: demo
|
||||
workflow:
|
||||
ref: deploy-demo
|
||||
```
|
||||
|
||||
通过 KubeVela，你可以引用任意的 Kubernetes 资源，然后做多集群分发和差异化配置。
|
||||
|
|
@ -98,6 +98,7 @@ UI Schema 包含的字段如下：
|
|||
- [x] HelmValues: 从用户选择的 Chart 和 版本加载可配置的参数，供用户进行 Values 配置。
|
||||
- [x] ImageInput: 镜像输入框，针对镜像进行有效性检测并响应其匹配的镜像仓库认证信息。
|
||||
- [x] PolicySelect: 加载当前应用的策略列表，供用户进行选择，支持多选。
|
||||
- [x] CertBase64: 支持输入或上传文本文件，自动将内容进行 base64 编码后进行提交，适用于证书，密钥等字段需求。(1.5+ 版本有效)
|
||||
|
||||
#### 组合表单
|
||||
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 54 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 48 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 46 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 1.4 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 586 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 476 KiB |
|
|
@ -2,423 +2,5 @@
|
|||
title: 多集群交付
|
||||
---
|
||||
|
||||
本章节介绍如何将 Helm Chart 部署到多个目标环境和集群。
|
||||
在开始之前，请确保你已经了解 [Helm Chart 交付](./helm) 及其相关背景。
|
||||
|
||||
## 准备集群
|
||||
|
||||
> 本节是为多集群做准备，方便起见，我们将从头开始。如果你已经完成 [集群管理](../platform-engineers/system-operation/managing-clusters) ，则可以跳过本节。
|
||||
|
||||
1. 使用 [velad](https://github.com/kubevela/velad) 安装 KubeVela 控制平面
|
||||
|
||||
```shell
|
||||
velad install
|
||||
```
|
||||
|
||||
2. 为新创建的集群导出 KubeConfig
|
||||
|
||||
```
|
||||
export KUBECONFIG=$(velad kubeconfig --name default --host)
|
||||
```
|
||||
|
||||
3. 为 UI 控制台启用 velaux 插件
|
||||
|
||||
```shell
|
||||
vela addon enable velaux
|
||||
```
|
||||
|
||||
4. 用 velad 创建一个名为 `foo` 的集群
|
||||
|
||||
```shell
|
||||
velad install --name foo --cluster-only
|
||||
```
|
||||
|
||||
5. 将创建的集群加入控制平面
|
||||
|
||||
```shell
|
||||
vela cluster join $(velad kubeconfig --name foo --internal) --name foo
|
||||
```
|
||||
|
||||
6. 为 helm 组件启用 fluxcd 插件
|
||||
|
||||
```shell
|
||||
vela addon enable fluxcd
|
||||
```
|
||||
|
||||
如果你在加入新集群之前已启用 `fluxcd` 插件，则应该通过以下方式来为新加入的集群启用插件：
|
||||
|
||||
```
|
||||
vela addon enable fluxcd --clusters foo
|
||||
```
|
||||
|
||||
现在我们完成了所有的准备工作，可以查看加入的集群了：
|
||||
|
||||
```console
|
||||
$ vela cluster ls
|
||||
CLUSTER ALIAS TYPE ENDPOINT ACCEPTED LABELS
|
||||
local Internal - true
|
||||
foo X509Certificate https://172.20.0.6:6443 true
|
||||
```
|
||||
|
||||
`local` 是 KubeVela 控制平面的集群，`foo` 则是我们刚刚添加的集群。
|
||||
|
||||
## 多集群部署
|
||||
|
||||
多集群交付的原理与 [容器的多集群应用交付](../case-studies/multi-cluster#deliver-application-to-clusters) 的基本一致。
|
||||
|
||||
我们可以使用 `topology` 策略来指定 Helm Chart 交付的环境，指令如下：
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
`clusters` 字段的 topology 策略是一个切片（slice），此处可以指定多个集群的名称。
|
||||
你还可以使用标签选择器或指定命名空间，详情见 [参考文档](../end-user/policies/references#topology) 。
|
||||
|
||||
部署后，你可以通过以下方式检查已部署的应用程序：
|
||||
|
||||
```shell
|
||||
vela status helm-hello
|
||||
```
|
||||
|
||||
部署成功的预期输出应该如下：
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
你可以通过以下方式检查已部署的资源：
|
||||
|
||||
```
|
||||
$ vela status helm-hello --tree
|
||||
CLUSTER NAMESPACE RESOURCE STATUS
|
||||
foo ─── default ─┬─ HelmRelease/hello updated
|
||||
└─ HelmRepository/hello updated
|
||||
```
|
||||
|
||||
你也可以通过 VelaUX 检查已部署的资源，这已在 [helm 交付文档](./helm#visualize-the-resources-created-by-helm-release) 中介绍。
|
||||
|
||||
## 使用 Override 配置进行部署
|
||||
|
||||
在某些情况下，我们会为不同集群的 Helm Chart 设置不同的 Value ，这样我们可以使用 [Override 策略](../end-user/policies/references#override) 。
|
||||
|
||||
下面是一个复杂的示例，我们将把一个 Helm Chart 部署到两个集群中，并为每个集群指定不同的 Value 。让我们部署它：
|
||||
|
||||
```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
|
||||
```
|
||||
|
||||
> **注意：如果你觉得策略和工作流程有点复杂，你可以将它们作为一个外部对象并仅引用该对象，用法和 [容器交付](../case-studies/multi-cluster#use-policies-and-workflow-outside-the-application) 是一样的。**
|
||||
|
||||
部署过程分为三个步骤：（1）部署到本地集群；（2）等待人工审批；（3）部署到 foo 集群。你会发现它在第一步之后就被暂停了，就像下面这样：
|
||||
|
||||
```
|
||||
$ 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
|
||||
```
|
||||
|
||||
你可以查看并使用 Value 为 “Welcome to Control Plane Cluster!” 的部署在控制平面的 Helm Chart 。
|
||||
|
||||
```
|
||||
vela port-forward helm-hello
|
||||
```
|
||||
|
||||
浏览器会自动提示如下页面：
|
||||
|
||||
|
||||
|
||||
发现部署成功，让我们继续。
|
||||
|
||||
```shell
|
||||
vela workflow resume helm-hello
|
||||
```
|
||||
|
||||
然后它会部署到 foo 集群，你可以查看这些资源的详细信息。
|
||||
|
||||
```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'
|
||||
```
|
||||
|
||||
再次使用端口转发：
|
||||
|
||||
```shell
|
||||
vela port-forward helm-hello
|
||||
```
|
||||
|
||||
然后它会弹出一些选项：
|
||||
|
||||
```
|
||||
? 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
|
||||
```
|
||||
|
||||
选择带有 `foo` 集群的选项，然后你会看到结果已经被新消息覆盖。
|
||||
|
||||
```console
|
||||
$ curl http://127.0.0.1:8080/
|
||||
...snip...
|
||||
<div id="message">
|
||||
Welcome to Your New Foo Cluster!
|
||||
</div>
|
||||
...snip...
|
||||
```
|
||||
|
||||
## 使用 UI 控制台查看更多信息
|
||||
|
||||
如果你使用的是 `velaux` UI 控制台，则可以查看更多的多集群信息，并拥有统一的体验。
|
||||
|
||||
* 检查来自不同集群的 Pod 状态和事件：
|
||||
|
||||
|
||||
|
||||
* 检查来自不同集群的 Pod 日志：
|
||||
|
||||
|
||||
|
||||
* 检查资源拓扑树的关系和状态：
|
||||
|
||||
|
||||
|
||||
## 为不同环境指定不同的 Value 文件
|
||||
|
||||
你可以为不同环境选择 Helm Chart 中现有的不同 Value 文件。比如：
|
||||
|
||||
请确保你的本地集群有两个命名空间 “test” 和 “prod”，它们代表我们示例中的两个环境。
|
||||
|
||||
我们以 Chart `hello-kubernetes-chart` 为例。这个 Chart 有两个 Value 文件。你可以拉取此 Chart 并查看其中包含的所有文件：
|
||||
|
||||
```yaml
|
||||
$ tree ./hello-kubernetes-chart
|
||||
./hello-kubernetes-chart
|
||||
├── Chart.yaml
|
||||
├── templates
|
||||
│ ├── NOTES.txt
|
||||
│ ├── _helpers.tpl
|
||||
│ ├── config-map.yaml
|
||||
│ ├── deployment.yaml
|
||||
│ ├── hpa.yaml
|
||||
│ ├── ingress.yaml
|
||||
│ ├── service.yaml
|
||||
│ ├── serviceaccount.yaml
|
||||
│ └── tests
|
||||
│ └── test-connection.yaml
|
||||
├── values-production.yaml
|
||||
└── values.yaml
|
||||
```
|
||||
|
||||
我们可以看到此 Chart 中有 `values.yaml` `values-production.yaml` 这两个 Value 文件。
|
||||
|
||||
```yaml
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: hello-kubernetes
|
||||
spec:
|
||||
components:
|
||||
- name: hello-kubernetes
|
||||
type: helm
|
||||
properties:
|
||||
repoType: "helm"
|
||||
url: "https://wangyikewxgm.github.io/my-charts/"
|
||||
chart: "hello-kubernetes-chart"
|
||||
version: "0.1.0"
|
||||
|
||||
policies:
|
||||
- name: topology-test
|
||||
type: topology
|
||||
properties:
|
||||
clusters: ["local"]
|
||||
namespace: "test"
|
||||
- name: topology-prod
|
||||
type: topology
|
||||
properties:
|
||||
clusters: ["local"]
|
||||
namespace: "prod"
|
||||
- name: override-prod
|
||||
type: override
|
||||
properties:
|
||||
components:
|
||||
- name: hello-kubernetes
|
||||
properties:
|
||||
valuesFiles:
|
||||
- "values-production.yaml"
|
||||
workflow:
|
||||
steps:
|
||||
- name: deploy2test
|
||||
type: deploy
|
||||
properties:
|
||||
policies: ["topology-test"]
|
||||
- name: deploy2prod
|
||||
type: deploy
|
||||
properties:
|
||||
policies: ["topology-prod", "override-prod"]
|
||||
EOF
|
||||
```
|
||||
|
||||
访问 Application 的 endpoint ：
|
||||
|
||||
```yaml
|
||||
vela port-forward hello-kubernetes
|
||||
```
|
||||
|
||||
如果你选择 ```Cluster: local | Namespace: test | Kind: HelmRelease | Name: hello-kubernetes``` 你会看到：
|
||||
|
||||
|
||||
|
||||
选择 ```Cluster: local | Namespace: prod | Kind: HelmRelease | Name: hello-kubernetes``` 则会看到
|
||||
|
||||
|
||||
|
||||
## 清理
|
||||
|
||||
如果你使用 velad 进行此演示，则可以通过以下方式便捷地进行清理：
|
||||
|
||||
* 清理 foo 集群
|
||||
```
|
||||
velad uninstall -n foo
|
||||
```
|
||||
|
||||
* 清理默认集群
|
||||
```
|
||||
velad uninstall
|
||||
```
|
||||
|
||||
使用 Helm Chart ，快乐交付一下！
|
||||
文档已迁移至[博客](https://kubevela.net/zh/blog/2022/07/07/helm-multi-cluster).
|
||||
|
|
@ -122,6 +122,4 @@ Services:
|
|||
|
||||
到此，你已经掌握了 Helm 应用的交付能力，快去交付更多的 Helm 应用吧。
|
||||
|
||||
## 下一步
|
||||
|
||||
- [学习直接部署 Kubernetes 原生资源](./k8s-object)
|
||||
如果你想掌握 Helm Chart 的多集群部署，可以参考[这篇博客](https://kubevela.net/zh/blog/2022/07/07/helm-multi-cluster)了解实践细节。
|
||||
|
|
|
|||
|
|
@ -16,81 +16,10 @@ KubeVela 支持面向应用组织多个 Kubernetes 资源进行交付，常见
|
|||
|
||||
- 准备一个 Deployment+Service 资源的 Yaml 定义文件，请注意，涉及多个资源时请将 Deployment、Statefulset、Job 等工作负载类资源置于第一个。如果多个工作负载类资源，请拆分为多个应用。
|
||||
|
||||
<!-- - 准备两个或更多的运行时集群, 参考: [管理运行时集群](./manage-cluster) TODO v1.2-->
|
||||
|
||||
## 规划并创建交付目标
|
||||
|
||||
[交付目标(Target)](../getting-started/core-concept#交付目标（target）) 定义了应用交付的运行时集群和命名空间，创建交付目标的同时完成运行时集群的命名空间创建。
|
||||
|
||||
点击 `New Target` 按钮进入创建流程，填写必要的信息，选择集群、命名空间即可完成创建。我们使用 2 个集群来创建交付目标，当然如果你暂无多个集群，也可以使用一个集群的多个命名空间来创建多个交付目标。我们最少准备 3 个交付目标，1 个用于测试环境，2 个或更多用于生产环境。
|
||||
|
||||
## 创建 Kubernetes 应用
|
||||
|
||||
完成交付目标创建后，我们开始创建应用。与 [交付第一个应用](../quick-start) 一样，首先我们需要填写应用的基础信息，这里有三个不同点：
|
||||
|
||||
（1）选择部署类型 k8s-objects; 该类型用于部署多个 Kubernetes 原生资源，请注意，同一个应用请尽量保持只有一个 Workload 资源，即不要出现多个 Deployment 或者 Statefulset。
|
||||
|
||||
（2）环境规划时我们分配两个环境，测试环境和生产环境，其中开发环境选择 1 个准备的开发用交付目标, 生产环境选择多个交付目标。
|
||||
|
||||
|
||||
|
||||
（3）设置部署参数，直接上传准备好的 Yaml 文件即可。需要注意的是，资源的名称如果在配置中指定，即使用配置的名称，你需要确定其与已存在的资源不冲突，如果不指定，则使用 KubeVela 资源命名规则自动命名。编辑器会自动将输入的内容进行格式化。
|
||||
|
||||
|
||||
|
||||
设置完成后点击 `Create` 即可完成应用创建。
|
||||
|
||||
## 部署测试环境
|
||||
|
||||
|
||||
|
||||
进入应用管理页面，你会发现改应用自动生成了 2 个环境，2 个工作流。Vela 会自动为每一个环境生成默认的工作流，工作流由`deploy2env`类型的步骤组成，每一个交付目标对于一个步骤，表示将应用交付到该交付目标。
|
||||
|
||||
我们首先切换到测试环境 Tab 页面下，点击页面中的 Deploy 按钮进行该环境的部署。由于测试环境我们只分配了一个交付目标，默认情况下工作流步骤只有一步。观察页面右上方的工作流执行状态，其变更为绿色后即已执行完成。如果其为红色，即工作流执行遇到故障，我们将鼠标移动到步骤上方即可查询失败原因，处理异常后工作量会继续重拾，如果故障解决其可完成部署。
|
||||
|
||||
部署完成后，刷新实例列表即可查看到 Pod 列表，如果 Pod 运行异常可以点击行查看 Pod 详情信息。
|
||||
|
||||
|
||||
|
||||
对于测试环境，它当然应该持续进行迭代，当我们变更了部署参数（镜像版本，实例数等），只需要重新执行测试环境的 Workflow 即可升级部署，鼠标移动到页面右上方，选择测试环境的 流水线 执行即可。若点击旁边的 Deploy 按钮，其含义是执行默认的流水线。
|
||||
|
||||
|
||||
|
||||
## 部署生产环境
|
||||
|
||||
当我们在测试环境多次部署完成业务的测试工作以后，我们要开始将应用发布到生产环境，我们切换到生产环境 Tab 下，会发现当前环境处于未部署状态。是的，同一个应用的不同环境是完全隔离管理的，它的背后是生成独立的应用部署实例（Application CR）。
|
||||
|
||||
由于我们生产环境有多个交付目标，它默认情况下是根据先后顺序依次部署，这时如果假设大家希望在部署完第一个交付目标后，希望人工审核/校验一下部署状态后再执行后续部署。带着这个需求，我们需要进入到应用基准配置的工作流管理页面。
|
||||
|
||||
|
||||
|
||||
我们可以看到已经自动生成的两条流水线配置，这时我们点击生产环境流水线的 `Edit` 进入编辑模式，从左侧的工作流步骤的选项中选择 `suspend`, 将其拖入右侧画板中。便捷弹窗将自动出现，该类型没有更多的配置参数，你可以设置别名或直接保存即可。
|
||||
|
||||
添加完成后我们需要编排它的顺序，首先断开已有步骤之间的连线（通过点击连线+delete 键）,然后将 suspend 步骤连线在中间即可。编辑完成后需要点击右上方的 Save 按钮即可保存并生效。
|
||||
|
||||
|
||||
|
||||
工作流编辑完成后回到生产环境页面下，点击 Deploy 按钮，即可开始生产环境的部署。
|
||||
|
||||
|
||||
|
||||
观察右上方的工作流执行状态，当第一个交付目标完成部署后，即会停止在第二个步骤等待用户进行审核操作，我们从下方的实例列表也可以查看到第一个交付目标的实例已经生成并处于运行状态。
|
||||
|
||||
暂停步骤有三个操作可以进行：
|
||||
|
||||
- Rollback: 版本回退，即将采用历史最新的完成部署的版本进行重新部署，当前版本部署工作流终止。
|
||||
- Terminate: 终止，即停止当前版本的部署，但不会改变已经部署的交付目标。
|
||||
- Continue: 继续执行，进入下一个步骤的执行。
|
||||
|
||||
当你选择继续执行后，第二个或更多的交付目标即可完成部署。从实例列表中你可以查看到多个交付目标的实例，可以通过选择交付目标进行实例筛选查询。
|
||||
|
||||
|
||||
|
||||
## 通过 CLI 交付
|
||||
|
||||
通过 CLI 部署的应用没有环境的概念，你可以通过部署多个应用来实现与控制台中类似的环境隔离。
|
||||
|
||||
这是一个部署 Kubernetes 原生资源的示例应用，我们知道大多数 Kubernetes 应用都由 Deployment 和 Service 组成。该应用配置中包括了 2 个部署策略和 3 个工作流步骤，这些配置的表达的含义是部署应用到两个命名空间且在第一个完成部署后需要人工审核。
|
||||
这是一个部署 Kubernetes 原生资源的示例应用，我们知道大多数 Kubernetes 应用都由 Deployment 和 Service 组成。
|
||||
该应用配置中包括了 2 个部署策略和 3 个工作流步骤，这些配置的表达的含义是部署应用到两个命名空间且在第一个完成部署后需要人工审核。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
|
|
@ -192,7 +121,78 @@ $ vela up -f https://kubevela.io/example/applications/app-with-k8s-objects.yaml
|
|||
$ vela workflow resume app-with-k8s-objects
|
||||
```
|
||||
|
||||
## 下一步
|
||||
## 通过 UI 控制台部署
|
||||
|
||||
- [交付云厂商服务](./consume-cloud-services)
|
||||
- [分发已存在的 Kubernetes 对象](../end-user/components/ref-objects)
|
||||
如果你开启了 [`velaux`](../reference/addons/velaux) 插件，你可以直接在 UI 控制台完成 Kubernetes 对象的部署。
|
||||
|
||||
### 规划并创建交付目标
|
||||
|
||||
[交付目标(Target)](../getting-started/core-concept#交付目标（target）) 定义了应用交付的运行时集群和命名空间，创建交付目标的同时完成运行时集群的命名空间创建。
|
||||
|
||||
点击 `New Target` 按钮进入创建流程，填写必要的信息，选择集群、命名空间即可完成创建。我们使用 2 个集群来创建交付目标，当然如果你暂无多个集群，也可以使用一个集群的多个命名空间来创建多个交付目标。我们最少准备 3 个交付目标，1 个用于测试环境，2 个或更多用于生产环境。
|
||||
|
||||
### 创建 Kubernetes 应用
|
||||
|
||||
完成交付目标创建后，我们开始创建应用。与 [交付第一个应用](../quick-start) 一样，首先我们需要填写应用的基础信息，这里有三个不同点：
|
||||
|
||||
（1）选择部署类型 k8s-objects; 该类型用于部署多个 Kubernetes 原生资源，请注意，同一个应用请尽量保持只有一个 Workload 资源，即不要出现多个 Deployment 或者 Statefulset。
|
||||
|
||||
（2）环境规划时我们分配两个环境，测试环境和生产环境，其中开发环境选择 1 个准备的开发用交付目标, 生产环境选择多个交付目标。
|
||||
|
||||
|
||||
|
||||
（3）设置部署参数，直接上传准备好的 Yaml 文件即可。需要注意的是，资源的名称如果在配置中指定，即使用配置的名称，你需要确定其与已存在的资源不冲突，如果不指定，则使用 KubeVela 资源命名规则自动命名。编辑器会自动将输入的内容进行格式化。
|
||||
|
||||
|
||||
|
||||
设置完成后点击 `Create` 即可完成应用创建。
|
||||
|
||||
### 部署测试环境
|
||||
|
||||
|
||||
|
||||
进入应用管理页面，你会发现改应用自动生成了 2 个环境，2 个工作流。Vela 会自动为每一个环境生成默认的工作流，工作流由`deploy2env`类型的步骤组成，每一个交付目标对于一个步骤，表示将应用交付到该交付目标。
|
||||
|
||||
我们首先切换到测试环境 Tab 页面下，点击页面中的 Deploy 按钮进行该环境的部署。由于测试环境我们只分配了一个交付目标，默认情况下工作流步骤只有一步。观察页面右上方的工作流执行状态，其变更为绿色后即已执行完成。如果其为红色，即工作流执行遇到故障，我们将鼠标移动到步骤上方即可查询失败原因，处理异常后工作量会继续重拾，如果故障解决其可完成部署。
|
||||
|
||||
部署完成后，刷新实例列表即可查看到 Pod 列表，如果 Pod 运行异常可以点击行查看 Pod 详情信息。
|
||||
|
||||
|
||||
|
||||
对于测试环境，它当然应该持续进行迭代，当我们变更了部署参数（镜像版本，实例数等），只需要重新执行测试环境的 Workflow 即可升级部署，鼠标移动到页面右上方，选择测试环境的 流水线 执行即可。若点击旁边的 Deploy 按钮，其含义是执行默认的流水线。
|
||||
|
||||
|
||||
|
||||
### 部署生产环境
|
||||
|
||||
当我们在测试环境多次部署完成业务的测试工作以后，我们要开始将应用发布到生产环境，我们切换到生产环境 Tab 下，会发现当前环境处于未部署状态。是的，同一个应用的不同环境是完全隔离管理的，它的背后是生成独立的应用部署实例（Application CR）。
|
||||
|
||||
由于我们生产环境有多个交付目标，它默认情况下是根据先后顺序依次部署，这时如果假设大家希望在部署完第一个交付目标后，希望人工审核/校验一下部署状态后再执行后续部署。带着这个需求，我们需要进入到应用基准配置的工作流管理页面。
|
||||
|
||||
|
||||
|
||||
我们可以看到已经自动生成的两条流水线配置，这时我们点击生产环境流水线的 `Edit` 进入编辑模式，从左侧的工作流步骤的选项中选择 `suspend`, 将其拖入右侧画板中。便捷弹窗将自动出现，该类型没有更多的配置参数，你可以设置别名或直接保存即可。
|
||||
|
||||
添加完成后我们需要编排它的顺序，首先断开已有步骤之间的连线（通过点击连线+delete 键）,然后将 suspend 步骤连线在中间即可。编辑完成后需要点击右上方的 Save 按钮即可保存并生效。
|
||||
|
||||
|
||||
|
||||
工作流编辑完成后回到生产环境页面下，点击 Deploy 按钮，即可开始生产环境的部署。
|
||||
|
||||
|
||||
|
||||
观察右上方的工作流执行状态，当第一个交付目标完成部署后，即会停止在第二个步骤等待用户进行审核操作，我们从下方的实例列表也可以查看到第一个交付目标的实例已经生成并处于运行状态。
|
||||
|
||||
暂停步骤有三个操作可以进行：
|
||||
|
||||
- Rollback: 版本回退，即将采用历史最新的完成部署的版本进行重新部署，当前版本部署工作流终止。
|
||||
- Terminate: 终止，即停止当前版本的部署，但不会改变已经部署的交付目标。
|
||||
- Continue: 继续执行，进入下一个步骤的执行。
|
||||
|
||||
当你选择继续执行后，第二个或更多的交付目标即可完成部署。从实例列表中你可以查看到多个交付目标的实例，可以通过选择交付目标进行实例筛选查询。
|
||||
|
||||
|
||||
|
||||
至此，你已经完成了基本的 Kubernetes 对象的交付过程。
|
||||
|
||||
如果你想了解如何将 Kubernetes 对象分发至多集群，可以参考[多集群部分](../end-user/components/ref-objects)文档。
|
||||
|
|
|
|||
|
|
@ -118,6 +118,8 @@ Services:
|
|||
✅ scaler
|
||||
```
|
||||
|
||||
## 下一步
|
||||
至此，你已经了解了最基本的容器镜像部署，接下来你可以：
|
||||
|
||||
[学习基于 Helm Chart 部署应用](./helm)
|
||||
* 了解 [组件参考手册](../end-user/components/references#webservice)查看更多字段说明。
|
||||
* 了解 [运维特征参考手册](../end-user/traits/references)查看适用的运维特征功能。
|
||||
* 了解 [多集群交付](../case-studies/multi-cluster)，学习如何将容器镜像部署到多集群、多环境中。
|
||||
12
sidebars.js
12
sidebars.js
|
|
@ -29,7 +29,6 @@ module.exports = {
|
|||
collapsed: true,
|
||||
items: [
|
||||
'tutorials/webservice',
|
||||
'case-studies/multi-cluster',
|
||||
'tutorials/access-application',
|
||||
'end-user/traits/rollout',
|
||||
'end-user/traits/sidecar',
|
||||
|
|
@ -41,7 +40,6 @@ module.exports = {
|
|||
collapsed: true,
|
||||
items: [
|
||||
'tutorials/helm',
|
||||
'tutorials/helm-multi-cluster',
|
||||
'tutorials/helm-rollout',
|
||||
],
|
||||
},
|
||||
|
|
@ -72,10 +70,18 @@ module.exports = {
|
|||
collapsed: true,
|
||||
items: [
|
||||
'tutorials/k8s-object',
|
||||
'end-user/components/ref-objects',
|
||||
'tutorials/k8s-object-rollout',
|
||||
],
|
||||
},
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Multi Cluster Delivery',
|
||||
collapsed: true,
|
||||
items: [
|
||||
'case-studies/multi-cluster',
|
||||
'end-user/components/ref-objects',
|
||||
],
|
||||
},
|
||||
{
|
||||
type: 'category',
|
||||
label: 'CI Integration',
|
||||
|
|
|
|||
|
Before Width: | Height: | Size: 54 KiB After Width: | Height: | Size: 54 KiB |
|
Before Width: | Height: | Size: 48 KiB After Width: | Height: | Size: 48 KiB |
|
Before Width: | Height: | Size: 46 KiB After Width: | Height: | Size: 46 KiB |
|
Before Width: | Height: | Size: 1.4 MiB After Width: | Height: | Size: 1.4 MiB |
|
Before Width: | Height: | Size: 586 KiB After Width: | Height: | Size: 586 KiB |
|
Before Width: | Height: | Size: 476 KiB After Width: | Height: | Size: 476 KiB |
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Overview
|
||||
title: Overview of GitOps
|
||||
---
|
||||
|
||||
> This section will introduce how to use KubeVela in GitOps area and why.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Deploy across Multi-Clusters
|
||||
title: Multi Cluster Application
|
||||
---
|
||||
|
||||
KubeVela is by design a full functional Continuous Delivery (CD) platform with fine grained support for hybrid/multi-cloud/multi-cluster deployment.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Overview
|
||||
title: Developer Overview
|
||||
---
|
||||
|
||||
The developer guide including two parts:
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Overview
|
||||
title: Overview of Terraform
|
||||
description: This section introduces some scenarios of cloud resources management
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
---
|
||||
title: Multi Cluster Distribution
|
||||
title: Distribute Reference Objects
|
||||
---
|
||||
|
||||
> 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.
|
||||
> This section requires you to know the basics about how to deploy [multi-cluster application](../../case-studies/multi-cluster) with policy and workflow.
|
||||
|
||||
You can reference and distribute existing Kubernetes objects with KubeVela in the following scenarios:
|
||||
|
||||
|
|
@ -71,9 +71,11 @@ spec:
|
|||
|
||||
> In some cases, you might want to restrict the scope for the application to access resources. You can set the `--ref-objects-available-scope` to `namespace` or `cluster` in KubeVela controller's bootstrap parameter, to retrict the application to be only able to refer to the resources inside the same namespace or the same cluster.
|
||||
|
||||
## Working with Trait
|
||||
## Override Configuration for Reference Objects
|
||||
|
||||
The *ref-objects* typed component can also be used together with traits. The implicit main workload is the first referenced object and trait patch will be applied on it. The following example demonstrate how to set the replica number for the referenced deployment while deploying it in hangzhou clusters.
|
||||
The [override policy](../../case-studies/multi-cluster#override-default-configurations-in-clusters) can be used to override properties defined in component and traits while the reference objects don't have those properties.
|
||||
|
||||
If you want to override configuration for the *ref-objects* typed component, you can use traits. The implicit main workload is the first referenced object and trait patch will be applied on it. The following example demonstrate how to set the replica number for the referenced deployment while deploying it in hangzhou clusters.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
|
|
@ -103,7 +105,7 @@ spec:
|
|||
|
||||
There are several commonly used trait that could be used together with the ref-objects, particularly for Deployment.
|
||||
|
||||
### Container Image
|
||||
### Override Container Image
|
||||
|
||||
The `container-image` trait can be used to change the default image settings declared in the original deployment.
|
||||
|
||||
|
|
@ -147,7 +149,7 @@ traits:
|
|||
image: nginx-1.20
|
||||
```
|
||||
|
||||
### Command
|
||||
### Override Container Command
|
||||
|
||||
The `command` trait can be used to modify the original running command in deployment's pods.
|
||||
```yaml
|
||||
|
|
@ -200,7 +202,7 @@ traits:
|
|||
args: ["-q"]
|
||||
```
|
||||
|
||||
### Environment Variable
|
||||
### Override Container Environment Variable
|
||||
|
||||
With the trait `env`, you can easily manipulate the declared environment variables.
|
||||
|
||||
|
|
@ -260,7 +262,7 @@ traits:
|
|||
key_for_nginx_second: value_second
|
||||
```
|
||||
|
||||
### Labels & Annotations
|
||||
### Override Labels & Annotations
|
||||
|
||||
To add/update/remove labels or annotations for the workload (like Kubernetes Deployment), use the `labels` or `annotations` trait.
|
||||
|
||||
|
|
@ -292,7 +294,7 @@ traits:
|
|||
to-delete-annotation-key: null
|
||||
```
|
||||
|
||||
### JSON Patch & JSON Merge Patch
|
||||
### Override by using JSON Patch & JSON Merge Patch
|
||||
|
||||
Except for the above trait, a more powerful but more complex way to modify the original resources is to use the `json-patch` or `json-merge-patch` trait. They follow the [RFC 6902](https://datatracker.ietf.org/doc/html/rfc6902) and [RFC 7386](https://datatracker.ietf.org/doc/html/rfc7386) respectively. Usage examples are shown below.
|
||||
|
||||
|
|
@ -351,3 +353,130 @@ traits:
|
|||
image: busybox:1.34
|
||||
command: ["sleep", "864000"]
|
||||
```
|
||||
|
||||
## Distribute Reference Objects with different configuration
|
||||
|
||||
The general idea is to using `override` policy to override traits. Then you can distribute reference objects with different traits for different clusters.
|
||||
|
||||
Assume we're distributing the following Deployment YAML to multi-clusters:
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
labels:
|
||||
app: demo
|
||||
name: demo
|
||||
namespace: demo
|
||||
spec:
|
||||
replicas: 1
|
||||
selector:
|
||||
matchLabels:
|
||||
app: demo
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: demo
|
||||
spec:
|
||||
containers:
|
||||
- image: oamdev/testapp:v1
|
||||
name: demo
|
||||
```
|
||||
|
||||
We can specify the following `topology` policies.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: Policy
|
||||
metadata:
|
||||
name: cluster-beijing
|
||||
namespace: demo
|
||||
type: topology
|
||||
properties:
|
||||
clusters: ["<clusterid1>"]
|
||||
---
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: Policy
|
||||
metadata:
|
||||
name: cluster-hangzhou
|
||||
namespace: demo
|
||||
type: topology
|
||||
properties:
|
||||
clusters: ["<clusterid2>"]
|
||||
```
|
||||
|
||||
Then we can use `override` policy to override with different traits for the reference objects.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: Policy
|
||||
metadata:
|
||||
name: override-replic-beijing
|
||||
namespace: demo
|
||||
type: override
|
||||
properties:
|
||||
components:
|
||||
- name: "demo"
|
||||
traits:
|
||||
- type: scaler
|
||||
properties:
|
||||
replicas: 3
|
||||
---
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: Policy
|
||||
metadata:
|
||||
name: override-replic-hangzhou
|
||||
namespace: demo
|
||||
type: override
|
||||
properties:
|
||||
components:
|
||||
- name: "demo"
|
||||
traits:
|
||||
- type: scaler
|
||||
properties:
|
||||
replicas: 5
|
||||
```
|
||||
|
||||
The workflow can be defined like:
|
||||
|
||||
```
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: Workflow
|
||||
metadata:
|
||||
name: deploy-demo
|
||||
namespace: demo
|
||||
steps:
|
||||
- type: deploy
|
||||
name: deploy-bejing
|
||||
properties:
|
||||
policies: ["override-replic-beijing", "cluster-beijing"]
|
||||
- type: deploy
|
||||
name: deploy-hangzhou
|
||||
properties:
|
||||
policies: ["override-replic-hangzhou", "cluster-hangzhou"]
|
||||
```
|
||||
|
||||
As a result, we can combine them and trigger the final deploy by the following application:
|
||||
|
||||
```
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: demo
|
||||
namespace: demo
|
||||
annotations:
|
||||
app.oam.dev/publishVersion: version1
|
||||
spec:
|
||||
components:
|
||||
- name: demo
|
||||
type: ref-objects
|
||||
properties:
|
||||
objects:
|
||||
- apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
name: demo
|
||||
workflow:
|
||||
ref: deploy-demo
|
||||
```
|
||||
|
||||
With the help of KubeVela, you can reference and distribute any Kubernetes resources to multi clusters.
|
||||
|
|
@ -98,6 +98,7 @@ The spec are as follows:
|
|||
- [x] HelmValues: Load the default values of the selected helm chart and version to assist the user to configure the custom values.
|
||||
- [x] PolicySelect: Load the policies of the current application to assist user selection.
|
||||
- [x] ImageInput: Load and show the image info by users input image name.
|
||||
- [x] CertBase64: Support users upload or input the string, automatically base64 encoded. Suitable the fields such as the certificates and keys. (Added in 1.5+)
|
||||
|
||||
#### Combination form
|
||||
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 54 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 48 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 46 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 1.4 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 586 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 476 KiB |
|
|
@ -2,424 +2,4 @@
|
|||
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:
|
||||
|
||||
|
||||
|
||||
## Specify different value file for different environment
|
||||
|
||||
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:
|
||||
|
||||
```yaml
|
||||
$ tree ./hello-kubernetes-chart
|
||||
./hello-kubernetes-chart
|
||||
├── Chart.yaml
|
||||
├── templates
|
||||
│ ├── NOTES.txt
|
||||
│ ├── _helpers.tpl
|
||||
│ ├── config-map.yaml
|
||||
│ ├── deployment.yaml
|
||||
│ ├── hpa.yaml
|
||||
│ ├── ingress.yaml
|
||||
│ ├── service.yaml
|
||||
│ ├── serviceaccount.yaml
|
||||
│ └── tests
|
||||
│ └── test-connection.yaml
|
||||
├── values-production.yaml
|
||||
└── values.yaml
|
||||
```
|
||||
|
||||
As we can see, there are values files `values.yaml` `values-production.yaml` in this chart.
|
||||
|
||||
```yaml
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: hello-kubernetes
|
||||
spec:
|
||||
components:
|
||||
- name: hello-kubernetes
|
||||
type: helm
|
||||
properties:
|
||||
repoType: "helm"
|
||||
url: "https://wangyikewxgm.github.io/my-charts/"
|
||||
chart: "hello-kubernetes-chart"
|
||||
version: "0.1.0"
|
||||
|
||||
policies:
|
||||
- name: topology-test
|
||||
type: topology
|
||||
properties:
|
||||
clusters: ["local"]
|
||||
namespace: "test"
|
||||
- name: topology-prod
|
||||
type: topology
|
||||
properties:
|
||||
clusters: ["local"]
|
||||
namespace: "prod"
|
||||
- name: override-prod
|
||||
type: override
|
||||
properties:
|
||||
components:
|
||||
- name: hello-kubernetes
|
||||
properties:
|
||||
valuesFiles:
|
||||
- "values-production.yaml"
|
||||
workflow:
|
||||
steps:
|
||||
- name: deploy2test
|
||||
type: deploy
|
||||
properties:
|
||||
policies: ["topology-test"]
|
||||
- name: deploy2prod
|
||||
type: deploy
|
||||
properties:
|
||||
policies: ["topology-prod", "override-prod"]
|
||||
EOF
|
||||
```
|
||||
|
||||
Access the endpoints of application:
|
||||
|
||||
```yaml
|
||||
vela port-forward hello-kubernetes
|
||||
```
|
||||
|
||||
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:
|
||||
|
||||
|
||||
|
||||
## 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!
|
||||
This doc has been migrated to [this blog](https://kubevela.io/blog/2022/07/07/helm-multi-cluster).
|
||||
|
|
@ -203,6 +203,4 @@ Example below `values-production.yaml` will override `values.yaml` if they have
|
|||
- "values-production.yaml"
|
||||
```
|
||||
|
||||
## Next
|
||||
|
||||
* Learn [multi cluster delivery](./helm-multi-cluster) for helm chart.
|
||||
Now, you have learned the basic helm delivery. If you want to delivery Helm Chart into multi-clusters, you can refer to [this blog](https://kubevela.io/blog/2022/07/07/helm-multi-cluster).
|
||||
|
|
@ -209,9 +209,6 @@ If continued, the deployment goes on. In the list of instances, you can check ou
|
|||
|
||||
|
||||
|
||||
Now you've learned how to deploy Kubernetes objects.
|
||||
|
||||
Congrats! Now you've learned how to deploy Kubernetes objects.
|
||||
|
||||
## Next
|
||||
|
||||
* Learn how to [distribute resources across multi-clusters](../end-user/components/ref-objects).
|
||||
If you want to learn how to distribute resources across multi-clusters, you can refer to [this doc](../end-user/components/ref-objects).
|
||||
|
|
@ -122,9 +122,8 @@ Services:
|
|||
✅ scaler
|
||||
```
|
||||
|
||||
Now, you have finished learning the basic delivery for container images. Then, you could:
|
||||
|
||||
* 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 the container image.
|
||||
* Refer to [multi-cluster delivery](../case-studies/multi-cluster) to know how to deploy container image into hybrid environment and multi-clusters.
|
||||
|
|
@ -31,7 +31,6 @@
|
|||
"collapsed": true,
|
||||
"items": [
|
||||
"tutorials/webservice",
|
||||
"case-studies/multi-cluster",
|
||||
"tutorials/access-application",
|
||||
"end-user/traits/rollout",
|
||||
"end-user/traits/sidecar"
|
||||
|
|
@ -43,7 +42,6 @@
|
|||
"collapsed": true,
|
||||
"items": [
|
||||
"tutorials/helm",
|
||||
"tutorials/helm-multi-cluster",
|
||||
"tutorials/helm-rollout"
|
||||
]
|
||||
},
|
||||
|
|
@ -74,10 +72,18 @@
|
|||
"collapsed": true,
|
||||
"items": [
|
||||
"tutorials/k8s-object",
|
||||
"end-user/components/ref-objects",
|
||||
"tutorials/k8s-object-rollout"
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "category",
|
||||
"label": "Multi Cluster Delivery",
|
||||
"collapsed": true,
|
||||
"items": [
|
||||
"case-studies/multi-cluster",
|
||||
"end-user/components/ref-objects"
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "category",
|
||||
"label": "CI Integration",
|
||||
|
|
|
|||
Loading…
Reference in New Issue