fix-resources-url (#36)
yangsoon
GitHub
|
|
@ -1,4 +1,4 @@
|
|||
|
||||
|
||||
|
||||
*Make shipping applications more enjoyable.*
|
||||
|
||||
|
|
|
|||
|
|
@ -16,11 +16,11 @@ First of all, KubeVela introduces a workflow with separate of concerns as below:
|
|||
|
||||
Below is how this workflow looks like:
|
||||
|
||||
|
||||
|
||||
|
||||
This template based workflow make it possible for platform team enforce best practices and deployment confidence with a set of Kubernetes CRDs, and give end users a *PaaS-like* experience (*i.e. app-centric, higher level abstractions, self-service operations etc*) by natural.
|
||||
|
||||
|
||||
|
||||
|
||||
Below are the core concepts in KubeVela that make this happen.
|
||||
|
||||
|
|
@ -93,12 +93,12 @@ Currently, a KubeVela `environment` only maps to a Kubernetes namespace, while t
|
|||
|
||||
The main concepts of KubeVela could be shown as below:
|
||||
|
||||
|
||||
|
||||
|
||||
## Architecture
|
||||
|
||||
The overall architecture of KubeVela is shown as below:
|
||||
|
||||
|
||||
|
||||
|
||||
Specifically, the application controller is responsible for application abstraction and encapsulation (i.e. the controller for `Application` and `Definition`). The rollout controller will handle progressive rollout strategy with the whole application as a unit. The multi-cluster deployment engine is responsible for deploying the application across multiple clusters and environments with traffic shifting and rollout features supported.
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ This command will automatically open the reference documentation for given workl
|
|||
|
||||
Let's take `$ vela show webservice --web` as example. The detailed schema documentation for `Web Service` workload type will show up immediately as below:
|
||||
|
||||
|
||||
|
||||
|
||||
Note that there's in the section named `Specification`, it even provides you with a full sample for the usage of this workload type with a fake name `my-service-name`.
|
||||
|
||||
|
|
@ -30,7 +30,7 @@ Note that there's in the section named `Specification`, it even provides you wit
|
|||
|
||||
Similarly, we can also do `$ vela show autoscale --web`:
|
||||
|
||||
|
||||
|
||||
|
||||
With these auto-generated reference documentations, we could easily complete the application description by simple copy-paste, for example:
|
||||
|
||||
|
|
|
|||
|
|
@ -102,6 +102,6 @@ kubectl --namespace monitoring port-forward `kubectl -n monitoring get pods -l p
|
|||
|
||||
Then access the Prometheus dashboard via http://localhost:9090/targets
|
||||
|
||||
|
||||
|
||||
|
||||
</details>
|
||||
|
|
|
|||
|
|
@ -149,14 +149,14 @@ Hello World -- This is rolling 02
|
|||
In detail, `Rollout` controller will create a canary of your app , and then gradually shift traffic to the canary while measuring key performance indicators like HTTP requests success rate at the same time.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
In this sample, for every `10s`, `5%` traffic will be shifted to canary from the primary, until the traffic on canary reached `50%`. At the mean time, the instance number of canary will automatically scale to `replicas: 2` per configured in Appfile.
|
||||
|
||||
|
||||
Based on analysis result of the KPIs during this traffic shifting, a canary will be promoted or aborted if analysis is failed. If promoting, the primary will be upgraded from v1 to v2, and traffic will be fully shifted back to the primary instances. So as result, canary instances will be deleted after the promotion finished.
|
||||
|
||||
|
||||
|
||||
|
||||
> Note: KubeVela's `Rollout` trait is implemented with [Weaveworks Flagger](https://flagger.app/) operator.
|
||||
|
||||
|
|
|
|||
|
|
@ -20,13 +20,13 @@ This command will automatically open the reference documentation for given compo
|
|||
|
||||
Let's take `$ vela show webservice --web` as example. The detailed schema documentation for `Web Service` component type will show up immediately as below:
|
||||
|
||||
|
||||
|
||||
|
||||
Note that there's in the section named `Specification`, it even provides you with a full sample for the usage of this workload type with a fake name `my-service-name`.
|
||||
|
||||
Similarly, we can also do `$ vela show autoscale`:
|
||||
|
||||
|
||||
|
||||
|
||||
With these auto-generated reference documentations, we could easily complete the application description by simple copy-paste, for example:
|
||||
|
||||
|
|
|
|||
|
|
@ -270,7 +270,7 @@ Metrics server is already enabled.
|
|||
|
||||
Metrics server has to be enabled in `Operations/Add-ons` section of [Alibaba Cloud console](https://cs.console.aliyun.com/) as below.
|
||||
|
||||
|
||||
|
||||
|
||||
Please refer to [metrics server debug guide](https://help.aliyun.com/document_detail/176515.html) if you hit more issue.
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ slug: /
|
|||
|
||||
---
|
||||
|
||||
|
||||
|
||||
|
||||
## Motivation
|
||||
|
||||
|
|
|
|||
|
|
@ -239,7 +239,7 @@ Handling connection for 80
|
|||
Handling connection for 80
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
## Provisioning and consuming cloud resource in a single application v2 (two cloud resources)
|
||||
|
||||
|
|
@ -347,7 +347,7 @@ Handling connection for 80
|
|||
Handling connection for 80
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
## Provisioning and consuming cloud resource in different applications
|
||||
|
||||
|
|
@ -552,4 +552,4 @@ $ kubectl port-forward deployment/express-server 80:80
|
|||
|
||||
We can see the cloud resource is successfully consumed by the application.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -60,7 +60,7 @@ You can render above schema into a form by [form-render](https://github.com/alib
|
|||
|
||||
Below is a form rendered with `form-render`:
|
||||
|
||||
|
||||
|
||||
|
||||
# What's Next
|
||||
|
||||
|
|
|
|||
|
Before Width: | Height: | Size: 82 KiB After Width: | Height: | Size: 82 KiB |
|
Before Width: | Height: | Size: 94 KiB After Width: | Height: | Size: 94 KiB |
|
|
@ -154,7 +154,7 @@ Here is the end to end user experience based on [CloneSet](https://openkruise.io
|
|||
## State Transition
|
||||
Here is the high level state transition graph
|
||||
|
||||
|
||||
|
||||
|
||||
## Roadmap
|
||||
|
||||
|
|
|
|||
|
Before Width: | Height: | Size: 2.9 KiB |
|
Before Width: | Height: | Size: 3.8 KiB |
|
Before Width: | Height: | Size: 5.3 KiB |
|
Before Width: | Height: | Size: 2.7 KiB |
|
Before Width: | Height: | Size: 3.5 KiB |
|
Before Width: | Height: | Size: 4.8 KiB |
|
Before Width: | Height: | Size: 99 KiB |
|
Before Width: | Height: | Size: 139 KiB |
|
Before Width: | Height: | Size: 57 KiB |
|
Before Width: | Height: | Size: 374 KiB |
|
Before Width: | Height: | Size: 137 KiB |
|
Before Width: | Height: | Size: 132 KiB |
|
Before Width: | Height: | Size: 395 KiB |
|
Before Width: | Height: | Size: 62 KiB |
|
Before Width: | Height: | Size: 194 KiB |
|
Before Width: | Height: | Size: 198 KiB |
|
Before Width: | Height: | Size: 217 KiB |
|
Before Width: | Height: | Size: 90 KiB |
|
Before Width: | Height: | Size: 65 KiB |
|
Before Width: | Height: | Size: 236 KiB |
|
Before Width: | Height: | Size: 27 KiB |
|
Before Width: | Height: | Size: 211 KiB |
|
Before Width: | Height: | Size: 108 KiB |
|
Before Width: | Height: | Size: 290 KiB |
|
Before Width: | Height: | Size: 206 KiB |
|
Before Width: | Height: | Size: 478 KiB |
|
Before Width: | Height: | Size: 622 KiB |
|
Before Width: | Height: | Size: 506 KiB |
|
|
@ -1,4 +1,4 @@
|
|||
|
||||
|
||||
|
||||
*Make shipping applications more enjoyable.*
|
||||
|
||||
|
|
|
|||
|
|
@ -16,11 +16,11 @@ First of all, KubeVela introduces a workflow with separate of concerns as below:
|
|||
|
||||
Below is how this workflow looks like:
|
||||
|
||||
|
||||
|
||||
|
||||
This template based workflow make it possible for platform team enforce best practices and deployment confidence with a set of Kubernetes CRDs, and give end users a *PaaS-like* experience (*i.e. app-centric, higher level abstractions, self-service operations etc*) by natural.
|
||||
|
||||
|
||||
|
||||
|
||||
Below are the core concepts in KubeVela that make this happen.
|
||||
|
||||
|
|
@ -93,12 +93,12 @@ Currently, a KubeVela `environment` only maps to a Kubernetes namespace, while t
|
|||
|
||||
The main concepts of KubeVela could be shown as below:
|
||||
|
||||
|
||||
|
||||
|
||||
## Architecture
|
||||
|
||||
The overall architecture of KubeVela is shown as below:
|
||||
|
||||
|
||||
|
||||
|
||||
Specifically, the application controller is responsible for application abstraction and encapsulation (i.e. the controller for `Application` and `Definition`). The rollout controller will handle progressive rollout strategy with the whole application as a unit. The multi-cluster deployment engine is responsible for deploying the application across multiple clusters and environments with traffic shifting and rollout features supported.
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ This command will automatically open the reference documentation for given workl
|
|||
|
||||
Let's take `$ vela show webservice --web` as example. The detailed schema documentation for `Web Service` workload type will show up immediately as below:
|
||||
|
||||
|
||||
|
||||
|
||||
Note that there's in the section named `Specification`, it even provides you with a full sample for the usage of this workload type with a fake name `my-service-name`.
|
||||
|
||||
|
|
@ -30,7 +30,7 @@ Note that there's in the section named `Specification`, it even provides you wit
|
|||
|
||||
Similarly, we can also do `$ vela show autoscale --web`:
|
||||
|
||||
|
||||
|
||||
|
||||
With these auto-generated reference documentations, we could easily complete the application description by simple copy-paste, for example:
|
||||
|
||||
|
|
|
|||
|
|
@ -102,6 +102,6 @@ kubectl --namespace monitoring port-forward `kubectl -n monitoring get pods -l p
|
|||
|
||||
Then access the Prometheus dashboard via http://localhost:9090/targets
|
||||
|
||||
|
||||
|
||||
|
||||
</details>
|
||||
|
|
|
|||
|
|
@ -149,14 +149,14 @@ Hello World -- This is rolling 02
|
|||
In detail, `Rollout` controller will create a canary of your app , and then gradually shift traffic to the canary while measuring key performance indicators like HTTP requests success rate at the same time.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
In this sample, for every `10s`, `5%` traffic will be shifted to canary from the primary, until the traffic on canary reached `50%`. At the mean time, the instance number of canary will automatically scale to `replicas: 2` per configured in Appfile.
|
||||
|
||||
|
||||
Based on analysis result of the KPIs during this traffic shifting, a canary will be promoted or aborted if analysis is failed. If promoting, the primary will be upgraded from v1 to v2, and traffic will be fully shifted back to the primary instances. So as result, canary instances will be deleted after the promotion finished.
|
||||
|
||||
|
||||
|
||||
|
||||
> Note: KubeVela's `Rollout` trait is implemented with [Weaveworks Flagger](https://flagger.app/) operator.
|
||||
|
||||
|
|
|
|||
|
|
@ -20,13 +20,13 @@ This command will automatically open the reference documentation for given compo
|
|||
|
||||
Let's take `$ vela show webservice --web` as example. The detailed schema documentation for `Web Service` component type will show up immediately as below:
|
||||
|
||||
|
||||
|
||||
|
||||
Note that there's in the section named `Specification`, it even provides you with a full sample for the usage of this workload type with a fake name `my-service-name`.
|
||||
|
||||
Similarly, we can also do `$ vela show autoscale`:
|
||||
|
||||
|
||||
|
||||
|
||||
With these auto-generated reference documentations, we could easily complete the application description by simple copy-paste, for example:
|
||||
|
||||
|
|
|
|||
|
|
@ -270,7 +270,7 @@ Metrics server is already enabled.
|
|||
|
||||
Metrics server has to be enabled in `Operations/Add-ons` section of [Alibaba Cloud console](https://cs.console.aliyun.com/) as below.
|
||||
|
||||
|
||||
|
||||
|
||||
Please refer to [metrics server debug guide](https://help.aliyun.com/document_detail/176515.html) if you hit more issue.
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ slug: /
|
|||
|
||||
---
|
||||
|
||||
|
||||
|
||||
|
||||
## Motivation
|
||||
|
||||
|
|
|
|||
|
|
@ -239,7 +239,7 @@ Handling connection for 80
|
|||
Handling connection for 80
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
## Provisioning and consuming cloud resource in a single application v2 (two cloud resources)
|
||||
|
||||
|
|
@ -347,7 +347,7 @@ Handling connection for 80
|
|||
Handling connection for 80
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
## Provisioning and consuming cloud resource in different applications
|
||||
|
||||
|
|
@ -552,4 +552,4 @@ $ kubectl port-forward deployment/express-server 80:80
|
|||
|
||||
We can see the cloud resource is successfully consumed by the application.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -60,7 +60,7 @@ You can render above schema into a form by [form-render](https://github.com/alib
|
|||
|
||||
Below is a form rendered with `form-render`:
|
||||
|
||||
|
||||
|
||||
|
||||
# What's Next
|
||||
|
||||
|
|
|
|||
|
After Width: | Height: | Size: 82 KiB |
|
After Width: | Height: | Size: 94 KiB |
|
|
@ -154,7 +154,7 @@ Here is the end to end user experience based on [CloneSet](https://openkruise.io
|
|||
## State Transition
|
||||
Here is the high level state transition graph
|
||||
|
||||
|
||||
|
||||
|
||||
## Roadmap
|
||||
|
||||
|
|
|
|||