add multi cluster deploy use case (#274)
This commit is contained in:
Jianbo Sun
GitHub
parent
c6a64e145d
commit
a0ae54d901
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Canary Release with Istio
|
||||
title: Progressive Rollout with Istio
|
||||
---
|
||||
|
||||
## Introduction
|
||||
|
|
|
|||
|
|
@ -1,5 +0,0 @@
|
|||
---
|
||||
title: Multi-Cluster and Enviroment
|
||||
---
|
||||
|
||||
WIP
|
||||
|
|
@ -0,0 +1,217 @@
|
|||
---
|
||||
title: Multi-Cluster Application Deploy
|
||||
---
|
||||
|
||||
This section will introduce how to use KubeVela for multi-cluster application delivery and why.
|
||||
|
||||
## Introduction
|
||||
|
||||
There are more and more situations come out that organizations need multi-cluster technology for application delivery:
|
||||
|
||||
* For scalability, a single Kubernetes cluster has its limit around 5K nodes or less, it is unable to handle the large scale application load.
|
||||
* For stability/availability, application can deploy in multi-cluster for backup which provides more stability and availability.
|
||||
* For security, you may need to deploy in different zones/areas as government policy requires.
|
||||
|
||||
The following guide will the multi-cluster that helps you easily deploy an application to different environments.
|
||||
|
||||
## Preparation
|
||||
|
||||
You can simply join an existing cluster into KubeVela by specify it's KubeConfig like below.
|
||||
|
||||
```shell script
|
||||
vela cluster join <your kubeconfig path>
|
||||
```
|
||||
|
||||
It will use field `context.cluster` in KubeConfig as the cluster name automatically,
|
||||
you can also specify the name by `--name` parameter. For example:
|
||||
|
||||
```shell
|
||||
vela cluster join stage-cluster.kubeconfig --name cluster-staging
|
||||
vela cluster join prod-cluster.kubeconfig --name cluster-prod
|
||||
```
|
||||
|
||||
After clusters joined, you could list all clusters managed by KubeVela currently.
|
||||
|
||||
```bash
|
||||
$ vela cluster list
|
||||
CLUSTER TYPE ENDPOINT
|
||||
cluster-prod tls https://47.88.4.97:6443
|
||||
cluster-staging tls https://47.88.7.230:6443
|
||||
```
|
||||
|
||||
You can also detach a cluster if you're not using it any more.
|
||||
|
||||
```shell script
|
||||
$ vela cluster detach cluster-prod
|
||||
```
|
||||
|
||||
If there's still any application running in the cluster, the command will be rejected.
|
||||
|
||||
## Deploy Application to multi cluster
|
||||
|
||||
KubeVela regards a Kubernetes cluster as an environment, so you can deploy an application into
|
||||
one or more environments.
|
||||
|
||||
Below is an example, deploy to a staging environment first, check the application running well,
|
||||
and finally promote to production environment.
|
||||
|
||||
For different environments, the deployment configuration can also have some nuance.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: example-app
|
||||
namespace: test
|
||||
spec:
|
||||
components:
|
||||
- name: hello-world-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
traits:
|
||||
- type: scaler
|
||||
properties:
|
||||
replicas: 1
|
||||
- name: data-worker
|
||||
type: worker
|
||||
properties:
|
||||
image: busybox
|
||||
cmd:
|
||||
- sleep
|
||||
- '1000000'
|
||||
policies:
|
||||
- name: example-multi-env-policy
|
||||
type: env-binding
|
||||
properties:
|
||||
envs:
|
||||
- name: staging
|
||||
placement: # selecting the cluster to deploy to
|
||||
clusterSelector:
|
||||
name: cluster-staging
|
||||
selector: # selecting which component to use
|
||||
components:
|
||||
- hello-world-server
|
||||
|
||||
- name: prod
|
||||
placement:
|
||||
clusterSelector:
|
||||
name: cluster-prod
|
||||
patch: # overlay patch on above components
|
||||
components:
|
||||
- name: hello-world-server
|
||||
type: webservice
|
||||
traits:
|
||||
- type: scaler
|
||||
properties:
|
||||
replicas: 3
|
||||
|
||||
- name: health-policy-demo
|
||||
type: health
|
||||
properties:
|
||||
probeInterval: 5
|
||||
probeTimeout: 10
|
||||
|
||||
workflow:
|
||||
steps:
|
||||
# deploy to staging env
|
||||
- name: deploy-staging
|
||||
type: multi-env
|
||||
properties:
|
||||
policy: example-multi-env-policy
|
||||
env: staging
|
||||
|
||||
# manual check
|
||||
- name: manual-approval
|
||||
type: suspend
|
||||
|
||||
# deploy to prod env
|
||||
- name: deploy-prod
|
||||
type: multi-env
|
||||
properties:
|
||||
policy: example-multi-env-policy
|
||||
env: prod
|
||||
```
|
||||
|
||||
After the application deployed, it will run as the workflow steps.
|
||||
|
||||
> You can refer to [Env Binding](../end-user/policies/envbinding) and [Health Check](../end-user/policies/health) policy user guide for parameter details.
|
||||
|
||||
It will deploy application to staging environment first, you can check the `Application` status by:
|
||||
|
||||
```shell
|
||||
kubectl get application multi-env-demo -o yaml
|
||||
```
|
||||
|
||||
We can see that the workflow is suspended at `manual-approval`:
|
||||
|
||||
```yaml
|
||||
...
|
||||
status:
|
||||
workflow:
|
||||
...
|
||||
stepIndex: 2
|
||||
steps:
|
||||
- name: deploy-test-server
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: multi-env
|
||||
- name: manual-approval
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: suspend
|
||||
suspend: true
|
||||
terminated: false
|
||||
```
|
||||
|
||||
You can also check the health status in the `status.service` field below.
|
||||
|
||||
You can use `resume` command after everything verified in statging cluster:
|
||||
|
||||
```shell
|
||||
$ vela workflow resume multi-env-demo
|
||||
|
||||
Successfully resume workflow: multi-env-demo
|
||||
```
|
||||
|
||||
Recheck the `Application` status:
|
||||
|
||||
```shell
|
||||
kubectl get application multi-env-demo -o yaml
|
||||
```
|
||||
|
||||
All the step status in workflow is succeeded:
|
||||
|
||||
```yaml
|
||||
...
|
||||
status:
|
||||
workflow:
|
||||
...
|
||||
stepIndex: 3
|
||||
steps:
|
||||
- name: deploy-test-server
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: multi-env
|
||||
- name: manual-approval
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: suspend
|
||||
- name: deploy-prod-server
|
||||
phase: succeeded
|
||||
resourceRef: {}
|
||||
type: multi-env
|
||||
suspend: false
|
||||
terminated: true
|
||||
```
|
||||
|
||||
## More use cases
|
||||
|
||||
KubeVela can provide many strategies to deploy an application to multiple clusters by composing env-binding policy and workflow steps.
|
||||
|
||||
You can have a glimpse of how does it work as below:
|
||||
|
||||
|
||||
|
||||
More use cases about the multi cluster application deployment are coming soon.
|
||||
|
|
@ -151,4 +151,4 @@ Handling connection for 80
|
|||
|
||||
- [Component Observability](../../component-observability)
|
||||
- [Data Pass Between Components ](../../workflow/component-dependency-parameter)
|
||||
- [Multi-Cluster and Environment](../../../case-studies/multi-app-env-cluster)
|
||||
- [Multi-Cluster and Environment](../../../case-studies/multi-cluster)
|
||||
|
|
|
|||
|
|
@ -97,7 +97,7 @@ NAME COMPONENT TYPE PHASE HEALTHY STATUS AGE
|
|||
example-app hello-world-server webservice running 25s
|
||||
```
|
||||
|
||||
If you want to learn more about `env-binding`, please refer to **[Multi Cluster Deployment](../../case-studies/multi-app-env-cluster)**.
|
||||
If you want to learn more about `env-binding`, please refer to **[Multi Cluster Deployment](../../case-studies/multi-cluster)**.
|
||||
|
||||
## Appendix: Parameter List
|
||||
|
||||
|
|
|
|||
|
|
@ -104,7 +104,7 @@ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/mast
|
|||
|
||||
2. Install KubeVela
|
||||
```shell script
|
||||
helm install --create-namespace -n vela-system kubevela kubevela/vela-core --wait
|
||||
helm install --create-namespace -n vela-system kubevela kubevela/vela-core --set multicluster.enabled=true --wait
|
||||
```
|
||||
You can refer to [advanced installation guide](./platform-engineers/advanced-install) for more custom ways.
|
||||
|
||||
|
|
|
|||
|
|
@ -20,12 +20,6 @@ Install kubevela with enabled certmanager:
|
|||
helm install --create-namespace -n vela-system --set admissionWebhooks.certManager.enabled=true kubevela kubevela/vela-core --wait
|
||||
```
|
||||
|
||||
## Install KubeVela with multi-cluster management
|
||||
|
||||
```shell script
|
||||
helm install --create-namespace -n vela-system kubevela kubevela/vela-core --set multicluster.enabled=true
|
||||
```
|
||||
|
||||
## Install Pre-release
|
||||
|
||||
Add flag `--devel` in command `helm search` to choose a pre-release
|
||||
|
|
|
|||
|
|
@ -30,6 +30,7 @@ The introduction of bootstrap parameters in KubeVela controller are listed as be
|
|||
| oam-spec-var | string | v0.3 | The version of OAM spec to use |
|
||||
| pprof-addr | string | "" | The address of pprof, default to be emtpy to disable pprof |
|
||||
| perf-enabled | bool | false | Enable performance logging, working with monitoring tools like Loki and Grafana to discover performance bottleneck |
|
||||
| enable-cluster-gateway | bool | false | Enable multi cluster feature |
|
||||
|
||||
> Other parameters not listed in the table are old parameters used in previous versions, the latest version ( v1.1 ) does not use them.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: 基于 Istio 的金丝雀发布
|
||||
title: 基于 Istio 的渐进式发布
|
||||
---
|
||||
|
||||
## 简介
|
||||
|
|
|
|||
|
|
@ -159,5 +159,5 @@ EOF
|
|||
|
||||
- [组件可观测性](../../component-observability)
|
||||
- [应用组件间的依赖和参数传递](../../workflow/component-dependency-parameter)
|
||||
- [多应用、多环境、多集群编排](../../../case-studies/multi-app-env-cluster)
|
||||
- [多应用、多环境、多集群编排](../../../case-studies/multi-cluster)
|
||||
|
||||
|
|
|
|||
|
|
@ -95,7 +95,7 @@ NAME COMPONENT TYPE PHASE HEALTHY STATUS AGE
|
|||
example-app hello-world-server webservice running 25s
|
||||
```
|
||||
|
||||
如果你想使用 `env-binding` 在多集群环境下创建应用部署计划，请参考 **[应用多集群部署](../../case-studies/multi-app-env-cluster)** 。
|
||||
如果你想使用 `env-binding` 在多集群环境下创建应用部署计划，请参考 **[应用多集群部署](../../case-studies/multi-cluster)** 。
|
||||
|
||||
## 参数说明
|
||||
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/mast
|
|||
|
||||
2. 安装 KubeVela
|
||||
```shell script
|
||||
helm install --create-namespace -n vela-system kubevela kubevela/vela-core --wait
|
||||
helm install --create-namespace -n vela-system kubevela kubevela/vela-core --set multicluster.enabled=true --wait
|
||||
```
|
||||
你可以参考 [`自定义安装`](./platform-engineers/advanced-install) 获取更多安装模式和功能。
|
||||
|
||||
|
|
|
|||
|
|
@ -24,12 +24,6 @@ helm install cert-manager jetstack/cert-manager --namespace cert-manager --versi
|
|||
helm install --create-namespace -n vela-system --set admissionWebhooks.certManager.enabled=true kubevela kubevela/vela-core
|
||||
```
|
||||
|
||||
## 安装含有多集群能力的 KubeVela
|
||||
|
||||
```shell script
|
||||
helm install --create-namespace -n vela-system kubevela kubevela/vela-core --set multicluster.enabled=true
|
||||
```
|
||||
|
||||
## 安装预发布版
|
||||
|
||||
在使用 `helm search` 命令时，添加标记参数 `--devel` 即可搜索出预发布版。预发布版的版本号格式为 `<next_version>-rc-master`，例如 `0.4.0-rc-master`，代表的是一个基于 `master` 分支构建的发布候选版。
|
||||
|
|
|
|||
|
|
@ -30,6 +30,7 @@ KubeVela 控制器的各项启动参数及其说明如下。
|
|||
| oam-spec-var | string | v0.3 | OAM 标准的使用版本 |
|
||||
| pprof-addr | string | "" | 使用 pprof 监测性能的监听地址，默认为空时不监测 |
|
||||
| perf-enabled | bool | false | 启用控制器性能记录，可以配合监控组件监测当前控制器的性能瓶颈 |
|
||||
| enable-cluster-gateway | bool | false | 启动多集群功能 |
|
||||
|
||||
> 未列在表中的参数为旧版本参数，当前版本 v1.1 无需关心
|
||||
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ module.exports = {
|
|||
'case-studies/jenkins-cicd',
|
||||
'case-studies/gitops',
|
||||
'case-studies/canary-blue-green',
|
||||
// 'case-studies/multi-app-env-cluster',
|
||||
'case-studies/multi-cluster',
|
||||
],
|
||||
},
|
||||
{
|
||||
|
|
|
|||
Loading…
Reference in New Issue