mirror of
https://github.com/kubevela/kubevela.git
synced 2026-08-18 20:17:04 +00:00
Fix sidecar and 404
This commit is contained in:
Lei Zhang
+36
-35
@@ -1,30 +1,49 @@
|
||||
- Overview
|
||||
- [Introduction](/en/introduction.md)
|
||||
|
||||
- Get Started
|
||||
- Getting Started
|
||||
- [Installation](/en/install.md)
|
||||
- [Quick Start](/en/quick-start.md)
|
||||
- [Core Concepts](/en/concepts.md)
|
||||
|
||||
- Learning KubeVela
|
||||
- Application CRD
|
||||
- [Introduction](/en/platform-engineers/overview.md)
|
||||
- [Designing Application](/en/application.md)
|
||||
- Managing Components and Traits
|
||||
- [Definitions](/en/platform-engineers/definition-and-templates.md)
|
||||
- Learning KubeVela
|
||||
- [Core Concepts](/en/concepts.md)
|
||||
- Application
|
||||
- [Overview](/en/platform-engineers/overview.md)
|
||||
- [Define Application](/en/application.md)
|
||||
- Components and Traits
|
||||
- [Overview](/en/platform-engineers/definition-and-templates.md)
|
||||
- CUE
|
||||
- [CUE Basic](/en/cue/basic.md)
|
||||
- [Workload Type](/en/cue/workload-type.md)
|
||||
- [Trait](/en/cue/trait.md)
|
||||
- [Define Components](/en/cue/workload-type.md)
|
||||
- [Define Traits](/en/cue/trait.md)
|
||||
- [Advanced Features](/en/cue/status.md)
|
||||
- Helm
|
||||
- [Workload Type](/en/helm/component.md)
|
||||
- [Trait](/en/helm/trait.md)
|
||||
- [Limitations](/en/helm/known-issues.md)
|
||||
- How-to (Out-of-dated)
|
||||
- [Defining Workload Type](/en/platform-engineers/workload-type.md)
|
||||
- [Defining Trait](/en/platform-engineers/trait.md)
|
||||
- [Defining Cloud Service](/en/platform-engineers/cloud-services.md)
|
||||
- [Define Components](/en/helm/component.md)
|
||||
- [Attach Traits](/en/helm/trait.md)
|
||||
- [Known Limitations](/en/helm/known-issues.md)
|
||||
<!-- - How-to (Out-of-dated) -->
|
||||
<!-- - [Defining Workload Type](/en/platform-engineers/workload-type.md) -->
|
||||
<!-- - [Defining Trait](/en/platform-engineers/trait.md) -->
|
||||
<!-- - [Defining Cloud Service](/en/platform-engineers/cloud-services.md) -->
|
||||
|
||||
- Building Developer Experience
|
||||
- [Overview](/en/quick-start-appfile.md)
|
||||
- [Appfile](/en/developers/learn-appfile.md)
|
||||
- CLI
|
||||
- Debugging
|
||||
- [Port Forwarding](/en/developers/port-forward.md)
|
||||
- [Check Application Logs](/en/developers/check-logs.md)
|
||||
- [Execute Commands in Container](/en/developers/exec-cmd.md)
|
||||
- Extending
|
||||
- [Managing Capabilities](/en/developers/cap-center.md)
|
||||
- [Setting Routes](/en/developers/extensions/set-route.md)
|
||||
- [Setting Auto-scaling Policy](/en/developers/extensions/set-autoscale.md)
|
||||
- [Setting Rollout Strategy](/en/developers/extensions/set-rollout.md)
|
||||
- [Setting Monitoring Policy](/en/developers/extensions/set-metrics.md)
|
||||
- Configuring
|
||||
- [Setting Up Deployment Environment](/en/developers/config-enviroments.md)
|
||||
- [Configuring data/env in Application](/en/developers/config-app.md)
|
||||
<!-- - [Alternative Commands](/en/developers/alternative-cmd.md) -->
|
||||
|
||||
- Roadmap
|
||||
- [KubeVela Roadmap](/en/roadmap.md)
|
||||
@@ -75,22 +94,4 @@
|
||||
- [vela template](/en/cli/vela_template.md)
|
||||
- Extensibility
|
||||
- [vela cap](/en/cli/vela_cap.md)
|
||||
- Developer Experience
|
||||
- [Overview](/en/quick-start-appfile.md)
|
||||
- [Appfile](/en/developers/learn-appfile.md)
|
||||
- CLI
|
||||
- Debugging
|
||||
- [Port Forwarding](/en/developers/port-forward.md)
|
||||
- [Check Application Logs](/en/developers/check-logs.md)
|
||||
- [Execute Commands in Container](/en/developers/exec-cmd.md)
|
||||
- Extending
|
||||
- [Managing Capabilities](/en/developers/cap-center.md)
|
||||
- [Setting Routes](/en/developers/extensions/set-route.md)
|
||||
- [Setting Auto-scaling Policy](/en/developers/extensions/set-autoscale.md)
|
||||
- [Setting Rollout Strategy](/en/developers/extensions/set-rollout.md)
|
||||
- [Setting Monitoring Policy](/en/developers/extensions/set-metrics.md)
|
||||
- Configuring
|
||||
- [Setting Up Deployment Environment](/en/developers/config-enviroments.md)
|
||||
- [Configuring data/env in Application](/en/developers/config-app.md)
|
||||
- [Alternative Commands](/en/developers/alternative-cmd.md)
|
||||
- [FAQ](/en/developers/references/devex/faq.md)
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Designing Application
|
||||
# Defining Application
|
||||
|
||||
This documentation will walk through how to use `Application` custom resource.
|
||||
This documentation will walk through how to use `Application` object to define your application with corresponding operational behaviors in declarative approach.
|
||||
|
||||
## Example
|
||||
|
||||
@@ -8,8 +8,6 @@ The sample application below claimed a `backend` component with *Worker* workloa
|
||||
|
||||
Moreover, the `frontend` component claimed `sidecar` and `autoscaler` traits which means the workload will be automatically injected with a `fluentd` sidecar and scale from 1-100 replicas triggered by CPU usage.
|
||||
|
||||
> For detailed definition about `Application` *workload type* and *traits*, please read the [core concepts](/en/concepts.md#application) documentation.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1alpha2
|
||||
kind: Application
|
||||
|
||||
+4
-4
@@ -23,9 +23,9 @@ This template based workflow make it possible for platform team enforce best pra
|
||||
Below are the core building blocks in KubeVela that make this happen.
|
||||
|
||||
## Application
|
||||
The *Application* is the core API of KubeVela. Its main purpose is for **application encapsulation and abstraction**, i.e. it allows developers to work with a single artifact to capture the complete application definition with simplified primitives.
|
||||
The *Application* is the core API of KubeVela. It allows developers to work with a single artifact to capture the complete application definition with simplified primitives.
|
||||
|
||||
Application encapsulation is important to simplify administrative tasks and can serve as an anchor to avoid configuration drifts during operation. Also, as an abstraction object, `Application` provided a much simpler path for on-boarding Kubernetes capabilities without relying on low level details. For example, a developer will be able to model a "web service" without defining detailed Kubernetes Deployment + Service combo each time, or claim the auto-scaling requirements without referring to the underlying KEDA ScaleObject.
|
||||
Having an "application" concept is important to for any app-centric platform to simplify administrative tasks and can serve as an anchor to avoid configuration drifts during operation. Also, as an abstraction object, `Application` provided a much simpler path for on-boarding Kubernetes capabilities without relying on low level details. For example, a developer will be able to model a "web service" without defining detailed Kubernetes Deployment + Service combo each time, or claim the auto-scaling requirements without referring to the underlying KEDA ScaleObject.
|
||||
|
||||
An example of `website` application with two components (i.e. `frontend` and `backend`) could be modeled as below:
|
||||
|
||||
@@ -58,9 +58,9 @@ spec:
|
||||
image: "fluentd"
|
||||
```
|
||||
|
||||
### Workload Types
|
||||
### Components
|
||||
|
||||
For each of the components in `Application`, its `.type` field represents the definition of this component type and `.settings` claims the values to instantiate it. Some typical component types are *Long Running Web Service*, *One-time Off Task* or *Redis Database*.
|
||||
For each of the components in `Application`, its `.type` field references the detailed definition of this component (such as its workload type, template, parameters etc), and `.settings` is the user input values to instantiate it. Some typical component types are *Long Running Web Service*, *One-time Off Task* or *Redis Database*.
|
||||
|
||||
All supported component types expected to be pre-installed in the platform, or, provided by component providers such as 3rd-party software owner.
|
||||
|
||||
|
||||
@@ -137,4 +137,25 @@ $ curl -H "Host:example.com" http://<your-ingress-ip-address>/
|
||||
Hello World -- This is rolling 02
|
||||
```
|
||||
|
||||
> NOTE: please check the [detailed documentation](../references/traits/rollout.md#how-rollout-works) for `Rollout` trait to fully understand how canary release strategy works in KubeVela.
|
||||
|
||||
**How `Rollout` works?**
|
||||
|
||||
<details>
|
||||
|
||||
`Rollout` trait implements progressive release process to rollout your app following [Canary strategy](https://martinfowler.com/bliki/CanaryRelease.html).
|
||||
|
||||
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.
|
||||
|
||||
</details>
|
||||
|
||||
@@ -34,21 +34,3 @@ Name | Description | Type | Required | Default
|
||||
When `Rollout` and `Autoscle` traits are attached to the same service, they two will fight over the number of instances during rollout. Thus, it's by design that `Rollout` will take over replicas control (specified by `.replicas` field) during rollout.
|
||||
|
||||
> Note: in up coming releases, KubeVela will introduce a separate section in Appfile to define release phase configurations such as `Rollout`.
|
||||
|
||||
## How `Rollout` works?
|
||||
|
||||
`Rollout` trait implements progressive release process to rollout your app following [Canary strategy](https://martinfowler.com/bliki/CanaryRelease.html).
|
||||
|
||||
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.
|
||||
@@ -1,13 +1,17 @@
|
||||
# Managing Components and Traits
|
||||
# Introduction of Definition Objects
|
||||
|
||||
This documentation explains how to manage available application components and traits in your platform with `WorkloadDefinition` and `TraitDefinition` objects.
|
||||
This documentation explains how to register and manage available *components* and *traits* in your platform with `WorkloadDefinition` and `TraitDefinition`, so your end users could "assemble" them into a `Application` resource.
|
||||
|
||||
> All definition objects are expected to be maintained and installed by platform team, think them as *capability providers* in your platform.
|
||||
|
||||
## Overview
|
||||
|
||||
Essentially, a definition object in KubeVela is consisted by three section:
|
||||
- `spec.definitionRef`
|
||||
- **Capability Indexer** defined by `spec.definitionRef`
|
||||
- this is for discovering the provider of this capability.
|
||||
- `Interoperability Fields`
|
||||
- **Interoperability Fields**
|
||||
- they are for the platform to ensure a trait can work with given workload type. Hence only `TraitDefinition` has these fields.
|
||||
- `spec.schematic`
|
||||
- **Capability Encapsulation** defined by `spec.schematic`
|
||||
- this defines the encapsulation (i.e. templating and parametering) of this capability. For now, user can choose to use Helm or CUE as encapsulation.
|
||||
|
||||
Hence, the basic structure of definition object is as below:
|
||||
@@ -28,9 +32,13 @@ spec:
|
||||
# ... interoperability fields
|
||||
```
|
||||
|
||||
## `spec.definitionRef`
|
||||
Let's explain these fields one by one.
|
||||
|
||||
Below is a definition for `Web Service` type in KubeVela:
|
||||
### Capability Indexer
|
||||
|
||||
The indexer of given capability is declared as `spec.definitionRef`.
|
||||
|
||||
Below is a definition for *Web Service* in KubeVela:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1alpha2
|
||||
@@ -49,7 +57,7 @@ spec:
|
||||
|
||||
In above example, it claims to leverage Kubernetes Deployment (`deployments.apps`) as the workload type to instantiate this component.
|
||||
|
||||
Below is an example of `Ingress` trait:
|
||||
Below is an example of *ingress* trait:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1alpha2
|
||||
@@ -64,9 +72,9 @@ spec:
|
||||
|
||||
Similarly, it claims to leverage Kubernetes Ingress (`ingresses.networking.k8s.io`) as the underlying provider of this capability.
|
||||
|
||||
## `Interoperability Fields`
|
||||
### Interoperability Fields
|
||||
|
||||
An overall view of these fields in `TraitDefinition` is show as below.
|
||||
The interoperability fields are **trait only**. An overall view of interoperability fields in a `TraitDefinition` is show as below.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1alpha2
|
||||
@@ -86,7 +94,7 @@ spec:
|
||||
|
||||
Let's explain them in detail.
|
||||
|
||||
### `.spec.appliesToWorkloads`
|
||||
#### `.spec.appliesToWorkloads`
|
||||
|
||||
This field defines the constraints that what kinds of workloads this trait is allowed to apply to.
|
||||
- It accepts an array of string as value.
|
||||
@@ -104,7 +112,7 @@ If this field is omitted, it means this trait is allowded to apply to any worklo
|
||||
KubeVela will raise an error if a trait is applied to a workload which is NOT included in the `appliesToWorkloads`.
|
||||
|
||||
|
||||
### `.spec.conflictsWith`
|
||||
##### `.spec.conflictsWith`
|
||||
|
||||
This field defines that constraints that what kinds of traits are conflicting with this trait, if they are applied to the same workload.
|
||||
- It accepts an array of string as value.
|
||||
@@ -119,7 +127,7 @@ There are four approaches to denote one or a group of workload types.
|
||||
|
||||
If this field is omitted, it means this trait is NOT conflicting with any traits.
|
||||
|
||||
### `.spec.workloadRefPath`
|
||||
##### `.spec.workloadRefPath`
|
||||
|
||||
This field defines the field path of the trait which is used to store the reference of the workload to which the trait is applied.
|
||||
- It accepts a string as value, e.g., `spec.workloadRef`.
|
||||
@@ -128,9 +136,9 @@ If this field is set, KubeVela core will automatically fill the workload referen
|
||||
|
||||
Please check [scaler](https://github.com/oam-dev/kubevela/blob/master/charts/vela-core/templates/defwithtemplate/manualscale.yaml) trait as a demonstration of how to set this field.
|
||||
|
||||
## Capability Encapsulation
|
||||
### Capability Encapsulation
|
||||
|
||||
The encapsulation (i.e. templating and parametering) of given capability are defined in `spec.schematic` field. For example, below is the full definition of `Web Service` type in KubeVela:
|
||||
The encapsulation (i.e. templating and parametering) of given capability are defined in `spec.schematic` field. For example, below is the full definition of *Web Service* type in KubeVela:
|
||||
|
||||
<details>
|
||||
|
||||
@@ -229,8 +237,8 @@ spec:
|
||||
```
|
||||
</details>
|
||||
|
||||
We will explain this section in detail in the following guides:
|
||||
- [Use CUE](en/cue/basic) to encapsulate capabilities.
|
||||
- [Use Helm](en/helm/basic) to encapsulate capabilities.
|
||||
It's by design that KubeVela supports multiple ways to define the encapsulation. Hence, we will explain this field in detail with following guides.
|
||||
- Learn about [CUE](/en/cue/basic) based capability definitions.
|
||||
- Learn about [Helm](/en/helm/component) based capability definitions.
|
||||
|
||||
|
||||
|
||||
@@ -1,5 +1,7 @@
|
||||
# Introduction of Application CRD
|
||||
|
||||
This documentation will explain what is `Application` object and why you need it.
|
||||
|
||||
## Motivation
|
||||
|
||||
Encapsulation is probably the mostly widely used approach to enable easier developer experience and allow users to deliver the whole application resources as one unit. For example, many tools today encapsulate Kubernetes *Deployment* and *Service* into a *Web Service* module, and then instantiate this module by simply providing parameters such as *image=foo* and *ports=80*. This pattern can be found in cdk8s (e.g. [`web-service.ts` ](https://github.com/awslabs/cdk8s/blob/master/examples/typescript/web-service/web-service.ts)), CUE (e.g. [`kube.cue`](https://github.com/cuelang/cue/blob/b8b489251a3f9ea318830788794c1b4a753031c0/doc/tutorial/kubernetes/quick/services/kube.cue#L70)), and many widely used Helm charts (e.g. [Web Service](https://docs.bitnami.com/tutorials/create-your-first-helm-chart/)).
|
||||
|
||||
Reference in New Issue
Block a user