kubevela
/
kubevela.github.io
mirror of https://github.com/kubevela/kubevela.github.io.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Add the blog of multi cluster management (#573) 

* Add: the blog of multic cluster management

Signed-off-by: BinaryHB0916 <davidduan0916@gmail.com>

* Fix: typos and wording refinement

Signed-off-by: BinaryHB0916 <davidduan0916@gmail.com>

* Fix: typos

Signed-off-by: BinaryHB0916 <davidduan0916@gmail.com>

* Add: link override from multi-clsuter how-to doc

Signed-off-by: BinaryHB0916 <davidduan0916@gmail.com>

* Docs: update multi-cluster how-to (#571)

Signed-off-by: Yin Da <yd219913@alibaba-inc.com>

* Fix: broken link

Signed-off-by: BinaryHB0916 <davidduan0916@gmail.com>

Co-authored-by: Somefive <yd219913@alibaba-inc.com>
This commit is contained in:
Wei (段少) 2022-04-08 13:22:35 +08:00 committed by GitHub
parent 01fd53d181
commit 56a5d9ee7d
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 573 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
blog/2022-04-01-offline-deployment-practice.md → blog/2022-04-01-offline-deployment-practice copy.md
View File

@ -122,8 +122,8 @@ curl -I -m 10 -o /dev/null -s -w %{http_code} http://velaux.xxx.xxx.cn/applicati
## Summarize
During offline deployment, we also try to save Vela Core and Addon's resource that generated to be YAML files after deploying in extranet and re-deploy them in an offline environment, but because of all different kinds of resource involved in and it requires many other authorization issues to resolve, this way is more than cumbersome.
During offline deployment, we also try to save Vela Core and Addon's resource that generated to be YAML files after deploying in extranet and re-deploy them in an offline environment, but because of all different kinds of resource involved in and it requires many other authorization issues to resolve, this way is more than cumbersome.
With this practice of KubeVela's offline deployment , we hope it help you build a complete set of KubeVela in offline environment much faster. Offline installation is pretty much a pain point for most developers, we also see that the KubeVela community is introducing the brand new [velad](https://github.com/oam-dev/velad), a fully offline, highly accountable installation tool. Velad can help automate completion by making many steps as one, such as preparing clusters, downloading and packing image, installing and etc. Further more, it do support many features: In Linux machine (such as Alibaba Cloud ECS) we can locally spin up a cluster to install Vela-Core; while starting a KubeVela control plane, do not have to worry about its data to be lost when machine behind it accidentally was shutdown; Velad can stores all the data from control plane cluster into a traditional database (such as MySQL deployed on another ECS).
With this practice of KubeVela's offline deployment, we hope it help you build a complete set of KubeVela in offline environment much faster. Offline installation is pretty much a pain point for most developers, we also see that the KubeVela community is introducing the brand new [velad](https://github.com/oam-dev/velad), a fully offline, highly accountable installation tool. Velad can help automate completion by making many steps as one, such as preparing clusters, downloading and packing image, installing and etc. Further more, it do support many features: In Linux machine (such as Alibaba Cloud ECS) we can locally spin up a cluster to install Vela-Core; while starting a KubeVela control plane, do not have to worry about its data to be lost when machine behind it accidentally was shutdown; Velad can stores all the data from control plane cluster into a traditional database (such as MySQL deployed on another ECS).
In the recent version to come, China Merchants Bank will increase the efforts in the open source community of KubeVela, actively building: enterprise-level capacity, enhancement on multi-cluster, offline deployment and application-level observability. We'll also be contributing the financial industry's user scenarios and business needs, driving cloud-native ecology achieve more easily and efficient application management experience, and at last but not at least, welcome you the community member to join us together in this journey.

285
blog/2022-04-06-multi-cluster-management.md Normal file
View File

@ -0,0 +1,285 @@
---
title: Easily Manage your Application Shipment With Differentiated Configuration in Multi-Cluster
author: Wei Duan
author_title: KubeVela Team
author_url: https://github.com/oam-dev/KubeVela
author_image_url: https://KubeVela.io/img/logo.svg
tags: [ KubeVela ]
description: ""
image: https://raw.githubusercontent.com/oam-dev/KubeVela.io/main/docs/resources/KubeVela-03.png
hide_table_of_contents: false
---
Under today's multi-cluster business scene, we often encounter these typical requirements: distribute to multiple specific clusters, specific group distributions according to business need, and differentiated configurations for multi-clusters.
KubeVela v1.3 iterates based on the previous multi-cluster function. This article will reveal how to use it to do swift multiple clustered deployment and management to address all your anxieties.
### Before Starting
1. Prepare a Kubernetes cluster as the control plane of KubeVela.
1. Make sure [KubeVela v1.3](https://github.com/oam-dev/kubevela/releases/tag/v1.3.0) and KubeVela CLI v1.3.0 have been installed successfully.
2. The list of Kubeconfig from sub clusters that you want to manage. We will take three clusters naming beijing-1, beijing-2 and us-west-1 as examples.
3. Download and combine with [Multi-Cluster-Demo](https://github.com/oam-dev/sample/tree/master/12.multi_cluster_demo) to better understand how to use the KubeVela multi-cluster capabilities.
### Distribute to Multiple Specified Clusters
Distributing multiple specified clusters is the most basic multi-cluster management operation. In KubeVela, you will use a policy called `topology` to implement it. The cluster will be listed in the attribute `clusters`, an array.
First let's make sure switching kubeconfig to the control plane cluster, go with `vela cluster join` to include in the 3 clusters of Beijing-1, Beijing-2 and us-west-1:
```
➜ vela cluster join beijing-1.kubeconfig --name beijing-1
➜ vela cluster join beijing-2.kubeconfig --name beijing-2
➜ vela cluster join us-west-1.kubeconfig --name us-west-1
➜ vela cluster list
CLUSTER TYPE ENDPOINT ACCEPTED LABELS
beijing-1 X509Certificate https://47.95.22.71:6443 true
beijing-2 X509Certificate https://47.93.117.83:6443 true
us-west-1 X509Certificate https://47.88.31.118:6443 true
```
Then open multi-cluster-demo, look into `Basic.yaml`:
```
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: example-app
namespace: default
spec:
components:
- name: hello-world-server
type: webservice
properties:
image: crccheck/hello-world
port: 8000
traits:
- type: scaler
properties:
replicas: 3
- type: gateway
properties:
domain: testsvc-mc.example.com
# classInSpec : true If the sub clusters has Kubernetes versions below v1.20 installed, please add this field
http:
"/": 8000
policies:
- type: topology
name: beijing-clusters
properties:
clusters: ["beijing-1","beijing-2"]
```
It can be seen that this app uses the component of type `webservice` and distributes 3 Deployments to beijing-1 and beijing-2 clusters through the `topology` policy.
Please note that the premise of successfully distributing resource into managed clusters is that it must contain the exactly same namespace as control plane did. Since each cluster has the **`default`** namespace by default, we won't be worry in this case. But suppose we change the namespace in **`basic.yaml`** to be **`multi-cluster`**, we will receive an error:
```
...
Status: runningWorkflow
Workflow:
mode: DAG
finished: false
Suspend: false
Terminated: false
Steps
- id:9fierfkhsc
name:deploy-beijing-clusters
type:deploy
phase:failed
message:step deploy: step deploy: run step(provider=oam,do=components-apply): Found 1 errors. [(failed to apply component beijing-1-multi-cluster-0: HandleComponentsRevision: failed to create componentrevision beijing-1/multi-cluster/hello-world-server-v1: namespaces "multi-cluster" not found)]
Services:
...
```
**In future versions of KubeVela, we plan to support a comprehensive Authentication System, more convenient and more securely to: create namespaces in managed cluster through the hub cluster in quick moves.**
After creating the sub cluster's namespace, come back to the control plane cluster to create the application and ship out resources:
```
➜ vela up -f basic.yaml
Applying an application in vela K8s object format...
"patching object" name="example-app" resource="core.oam.dev/v1beta1, Kind=Application"
✅ App has been deployed 🚀🚀🚀
Port forward: vela port-forward example-app
SSH: vela exec example-app
Logging: vela logs example-app
App status: vela status example-app
Service status: vela status example-app --svc hello-world-server
```
We use `vela status <App Name>` to view detailed infos about this app:
```
➜ vela status example-app
About:
Name: example-app
Namespace: default
Created at: 2022-03-25 17:42:33 +0800 CST
Status: running
Workflow:
mode: DAG
finished: true
Suspend: false
Terminated: false
Steps
- id:wftf9d4exj
name:deploy-beijing-clusters
type:deploy
phase:succeeded
message:
Services:
- Name: hello-world-server
Cluster: beijing-1 Namespace: default
Type: webservice
Healthy Ready:3/3
Traits:
✅ scaler ✅ gateway: Visiting URL: testsvc-mc.example.com, IP: 60.205.222.30
- Name: hello-world-server
Cluster: beijing-2 Namespace: default
Type: webservice
Healthy Ready:3/3
Traits:
✅ scaler ✅ gateway: Visiting URL: testsvc-mc.example.com, IP: 182.92.222.128
```
Both the beijing-1 and beijing-2 have issued the corresponding resources, they also displayed external access IP addresses, and you can therefore make it public for your users.
### Use Cluster Labels to Do Grouping
In addition to the above basic need, we often encounter additional situations: cross-regional deployment to certain clusters, specify which cloud provider's cluster, etc. In order to achieve a similar goal, the `labels` feature can be used.
Here, suppose the us-west-1 cluster comes from AWS, we must additionally apply to the AWS cluster. You can use the `vela cluster labels add` command to tag the cluster. Of course, if there is more of AWS related clusters such as us-west-2, it will be handled as well after they were labeled:
```
➜ ~ vela cluster labels add us-west-1 provider=AWS
Successfully update labels for cluster us-west-1 (type: X509Certificate).
provider=AWS
➜ ~ vela cluster list
CLUSTER TYPE ENDPOINT ACCEPTED LABELS
beijing-1 X509Certificate https://47.95.22.71:6443 true
beijing-2 X509Certificate https://47.93.117.83:6443 true
us-west-1 X509Certificate https://47.88.31.118:6443 true provider=AWS
```
Next we update the `basic.yaml` to add an application policy `topology-aws`:
```
...
policies:
- type: topology
name: beijing-clusters
properties:
clusters: ["beijing-1","beijing-2"]
- type: topology
name: topology-aws
properties:
clusterLabelSelector:
provider: AWS
```
In order save your time, please deploy `intermediate.yaml` directly:
```
➜ ~ vela up -f intermediate.yaml
```
Review the status of the application again:
```
➜ vela status example-app
...
- Name: hello-world-server
Cluster: us-west-1 Namespace: default
Type: webservice
Healthy Ready:3/3
Traits:
✅ scaler ✅ gateway: Visiting URL: testsvc-mc.example.com, IP: 192.168.40.10
```
### Differentiated Configuration
Apart from above scenarios, we tend to have more application strategic needs, such as high availability of hoping to distribute 5 replicas. In this case, use the `override` policy:
```
...
clusterLabelSelector:
provider: AWS
- type: override
name: override-high-availability
properties:
components:
- type: webservice
traits:
- type: scaler
properties:
replicas: 5
```
At the same time, we hope that only AWS clusters can get high availability. Then we can expect KubeVela's workflow give us a hand. We use the following workflow: it aims to deploy this app by, first distributing to Beijing's clusters through the `deploy-beijing` policy, then distributing 5 copies to clusters which were labeled as AWS:
```
...
properties:
replicas: 5
workflow:
steps:
- type: deploy
name: deploy-beijing
properties:
policies: ["beijing-clusters"]
- type: deploy
name: deploy-aws
properties:
policies: ["override-high-availability","topology-aws"]
```
Then we attach the above policy and workflow to `intermediate.yaml` and make it to `advanced.yaml`:
```
...
policies:
- type: topology
name: beijing-clusters
properties:
clusters: ["beijing-1","beijing-2"]
- type: topology
name: topology-aws
properties:
clusterLabelSelector:
provider: AWS
- type: override
name: override-high-availability
properties:
components:
- type: webservice
traits:
- type: scaler
properties:
replicas: 5
workflow:
steps:
- type: deploy
name: deploy-beijing
properties:
policies: ["beijing-clusters"]
- type: deploy
name: deploy-aws
properties:
policies: ["override-high-availability","topology-aws"]
```
Then deploy it, view the status of the application:
```
➜ vela up -f advanced.yaml
Applying an application in vela K8s object format...
"patching object" name="example-app" resource="core.oam.dev/v1beta1, Kind=Application"
✅ App has been deployed 🚀🚀🚀
Port forward: vela port-forward example-app
SSH: vela exec example-app
Logging: vela logs example-app
App status: vela status example-app
Service status: vela status example-app --svc hello-world-serverapplication.core.oam.dev/podinfo-app configured
➜ vela status example-app
...
- Name: hello-world-server
Cluster: us-west-1 Namespace: default
Type: webservice
Healthy Ready:5/5
Traits:
✅ scaler ✅ gateway: Visiting URL: testsvc-mc.example.com, IP: 192.168.40.10
```
The above all are what we'd like to share with you for this time, thank you for reading and trying them out.
[We invite you to explore KubeVela v1.3 for more](https://kubevela.io/en/docs/install) to meet further complex requirements on business, such as [dig deep](https://kubevela.io/docs/next/case-studies/multi-cluster#override-default-configurations-in-clusters) in differentiated configurations to use `override` application policy to either override all resources on one type or only certain specific components.

2
i18n/zh/docusaurus-plugin-content-blog/2022-04-01-offline-deployment-practice.md
View File

@ -1,5 +1,5 @@
---
title: 招商银行 KubeVela 离线部署实践
title: KubeVela v1.3 多集群初体验，轻松管理应用分发和差异化配置
author: 马祥博
author_title: （云平台开发团队）
author_url: http://www.cmbchina.com/

285
i18n/zh/docusaurus-plugin-content-blog/2022-04-06-multi-cluster-management.md Normal file
View File

@ -0,0 +1,285 @@
---
title: KubeVela v1.3 多集群初体验，轻松管理应用分发和差异化配置
author: 段威（段少）
author_title: KubeVela 团队
author_url: https://github.com/oam-dev/kubevela
author_image_url: https://kubevela.io/img/logo.svg
tags: [ KubeVela ]
description: ""
image: https://raw.githubusercontent.com/oam-dev/KubeVela.io/main/docs/resources/KubeVela-03.png
hide_table_of_contents: false
---
在当今的多集群业务场景下，我们经常遇到的需求有：分发到多个指定集群、按业务规划实现分组分发、以及对多集群进行差异化配置等等。
KubeVela v1.3 在之前的多集群功能上进行了迭代，本文将为你揭示，如何使用 KubeVela 进行多集群应用的部署与管理，实现以上的业务需求。
### 开始之前
1. 准备一个 Kubernetes 集群作为 KubeVela 的控制平面。
1. 确保 [KubeVela v1.3](https://github.com/oam-dev/kubevela/releases/tag/v1.3.0) 和 KubeVela CLI v1.3.0 已经安装成功。
1. 你要管理的子集群列表 kubeconfig。我们将以 beijing-1，beijing-2 和 us-west-1 这 3 个集群为例。
1. 下载并结合 [multi-cluster-demo](https://github.com/oam-dev/samples/tree/master/12.Multi_Cluster_Demo) 来更好的理解，如何使用 KubeVela 多集群能力。
### 分发到多个指定集群
对多个指定集群进行分发是最基本的多集群管理操作。在 KubeVela 中，你将使用一个叫做 `topology` 的应用策略来实现它。集群以数组的形式，列在其属性的 `clusters` 字段里。
首先让我们确保切换 KUBECONFIG 到准备好的管控集群，使用 `vela cluster join` 将 beijing-1，beijing-2 和 us-west-1 这 3 个集群全部纳管进来：
```
➜ vela cluster join beijing-1.kubeconfig --name beijing-1
➜ vela cluster join beijing-2.kubeconfig --name beijing-2
➜ vela cluster join us-west-1.kubeconfig --name us-west-1
➜ vela cluster list
CLUSTER TYPE ENDPOINT ACCEPTED LABELS
beijing-1 X509Certificate https://47.95.22.71:6443 true
beijing-2 X509Certificate https://47.93.117.83:6443 true
us-west-1 X509Certificate https://47.88.31.118:6443 true
```
接着打开 multi-cluster-demo，查看 `basic.yaml`：
```
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: example-app
namespace: default
spec:
components:
- name: hello-world-server
type: webservice
properties:
image: crccheck/hello-world
port: 8000
traits:
- type: scaler
properties:
replicas: 3
- type: gateway
properties:
domain: testsvc-mc.example.com
# classInSpec : true 如果你所下发的集群里有安装 v1.20 以下版本的 Kubernetes ，请加上这个字段
http:
"/": 8000
policies:
- type: topology
name: beijing-clusters
properties:
clusters: ["beijing-1","beijing-2"]
```
可以看到，这个应用使用了 `webservice` 类型的组件，最后通过 `topology` 的应用策略分别向 beijing-1 和 beijing-2 两个集群分发 3 副本 Deployment。
**请注意，管控集群对子集群下发资源成功的前提是，子集群必须有已经新建的对应命名空间。由于每个集群默认都有 **`default`** 命名空间，所以可以正常下发。假设我们将** `basic.yaml` **的命名空间改成** `multi-cluster` **，则会收到报错：**
```
...
Status: runningWorkflow
Workflow:
mode: DAG
finished: false
Suspend: false
Terminated: false
Steps
- id:9fierfkhsc
name:deploy-beijing-clusters
type:deploy
phase:failed
message:step deploy: step deploy: run step(provider=oam,do=components-apply): Found 1 errors. [(failed to apply component beijing-1-multi-cluster-0: HandleComponentsRevision: failed to create componentrevision beijing-1/multi-cluster/hello-world-server-v1: namespaces "multi-cluster" not found)]
Services:
...
```
**在未来的 KubeVela 版本中，我们将支持使用鉴权系统，更便捷更安全的完成这项操作：通过管控集群一键在子集群创建命名空间。**
完成子集群命名空间创建后，切回管控集群创建应用并下发资源：
```
➜ vela up -f basic.yaml
Applying an application in vela K8s object format...
"patching object" name="example-app" resource="core.oam.dev/v1beta1, Kind=Application"
✅ App has been deployed 🚀🚀🚀
Port forward: vela port-forward example-app
SSH: vela exec example-app
Logging: vela logs example-app
App status: vela status example-app
Service status: vela status example-app --svc hello-world-server
```
我们通过 `vela status <应用名>` 查看服务相关信息：
```
➜ vela status example-app
About:
Name: example-app
Namespace: default
Created at: 2022-03-25 17:42:33 +0800 CST
Status: running
Workflow:
mode: DAG
finished: true
Suspend: false
Terminated: false
Steps
- id:wftf9d4exj
name:deploy-beijing-clusters
type:deploy
phase:succeeded
message:
Services:
- Name: hello-world-server
Cluster: beijing-1 Namespace: default
Type: webservice
Healthy Ready:3/3
Traits:
✅ scaler ✅ gateway: Visiting URL: testsvc-mc.example.com, IP: 60.205.222.30
- Name: hello-world-server
Cluster: beijing-2 Namespace: default
Type: webservice
Healthy Ready:3/3
Traits:
✅ scaler ✅ gateway: Visiting URL: testsvc-mc.example.com, IP: 182.92.222.128
```
beijing-1 和 beijing-2 都下发了对应的资源，它们可供外部访问的 IP 地址也显示出来，你因而可以用你希望的方式供用户访问了。
### 使用集群 labels 按需分组分发
除了上述的基本操作，我们常常会遇到另外的情况：跨地域部署到某些集群、指定哪个云厂商的集群等等。为了实现类似这样的需求，可以使用多集群的 labels 功能。
在这里，假设 us-west-1 集群来自 AWS，我们要额外分发应用到 AWS 的集群，则可以使用 `vela cluster labels add` 来对集群进行标记。当然，如果还有 us-west-2 等多个 AWS 相关集群，同样进行标记后，将会统一下发：
```
➜ ~ vela cluster labels add us-west-1 provider=AWS
Successfully update labels for cluster us-west-1 (type: X509Certificate).
provider=AWS
➜ ~ vela cluster list
CLUSTER TYPE ENDPOINT ACCEPTED LABELS
beijing-1 X509Certificate https://47.95.22.71:6443 true
beijing-2 X509Certificate https://47.93.117.83:6443 true
us-west-1 X509Certificate https://47.88.31.118:6443 true provider=AWS
```
接下来我们对 `basic.yaml` 进行更新，新增一个应用策略 `topology-aws`：
```
...
policies:
- type: topology
name: beijing-clusters
properties:
clusters: ["beijing-1","beijing-2"]
- type: topology
name: topology-aws
properties:
clusterLabelSelector:
provider: AWS
```
为了方便你学习，请直接部署基于 `basic.yaml` 更新后的 `intermediate.yaml`：
```
➜ ~ vela up -f intermediate.yaml
```
再次查看应用的状态：
```
➜ vela status example-app
...
- Name: hello-world-server
Cluster: us-west-1 Namespace: default
Type: webservice
Healthy Ready:3/3
Traits:
✅ scaler ✅ gateway: Visiting URL: testsvc-mc.example.com, IP: 192.168.40.10
```
### 通过应用策略进行配置差异化
除了在 `basic.yaml` 里定义的 `deploy-beijing` 这种应用策略，我们往往有更多的应用策略需求，比如高可用，希望单独给某些资源分发 5 个副本。这样的话，使用 `override` 类型的应用策略即可：
```
...
clusterLabelSelector:
provider: AWS
- type: override
name: override-high-availability
properties:
components:
- type: webservice
traits:
- type: scaler
properties:
replicas: 5
```
同时假设，我们希望的是，给 AWS 的应用分发并设置为高可用。那我们可以使用 KubeVela 提供的专门用于定义过程控制的工作流来管理。我们使用如下的一个工作流，它希望将本次应用部署，首先通过 deploy-beijing 的应用策略，分发给北京的集群们，接着给 Label 为 AWS 的集群分发 5 个副本高可用的应用策略：
```
...
properties:
replicas: 5
workflow:
steps:
- type: deploy
name: deploy-beijing
properties:
policies: ["beijing-clusters"]
- type: deploy
name: deploy-aws
properties:
policies: ["override-high-availability","topology-aws"]
```
接着我们给 `intermediate.yaml` 加上以上的应用策略和工作流后，更新为 `advanced.yaml`：
```
...
policies:
- type: topology
name: beijing-clusters
properties:
clusters: ["beijing-1","beijing-2"]
- type: topology
name: topology-aws
properties:
clusterLabelSelector:
provider: AWS
- type: override
name: override-high-availability
properties:
components:
- type: webservice
traits:
- type: scaler
properties:
replicas: 5
workflow:
steps:
- type: deploy
name: deploy-beijing
properties:
policies: ["beijing-clusters"]
- type: deploy
name: deploy-aws
properties:
policies: ["override-high-availability","topology-aws"]
```
然后对其进行部署，并再次查看应用的状态：
```
➜ vela up -f advanced.yaml
Applying an application in vela K8s object format...
"patching object" name="example-app" resource="core.oam.dev/v1beta1, Kind=Application"
✅ App has been deployed 🚀🚀🚀
Port forward: vela port-forward example-app
SSH: vela exec example-app
Logging: vela logs example-app
App status: vela status example-app
Service status: vela status example-app --svc hello-world-serverapplication.core.oam.dev/podinfo-app configured
➜ vela status example-app
...
- Name: hello-world-server
Cluster: us-west-1 Namespace: default
Type: webservice
Healthy Ready:5/5
Traits:
✅ scaler ✅ gateway: Visiting URL: testsvc-mc.example.com, IP: 192.168.40.10
```
以上就是本次的全部分享，感谢你的阅读和试玩。
[欢迎你继续探索 KubeVela v1.3 正式版](https://kubevela.net/zh/docs/install)，这里有更多差异化配置的进阶用法等你发现和使用，比如 `override` 应用策略如何完成资源类型通配还是针对某些特定组件进行覆盖等等，以满足更加复杂的场景需求。