Refine docs and add roadmaps (#685)
Signed-off-by: Jianbo Sun <jianbo.sjb@alibaba-inc.com>
This commit is contained in:
Jianbo Sun
GitHub
parent
285120dd8d
commit
61293c8a10
|
|
@ -0,0 +1,484 @@
|
|||
---
|
||||
title: Build flexible abstraction for any Kubernetes Resources with CUE and KubeVela
|
||||
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, Abstraction]
|
||||
description: ""
|
||||
image: https://raw.githubusercontent.com/oam-dev/KubeVela.io/main/docs/resources/KubeVela-03.png
|
||||
hide_table_of_contents: false
|
||||
---
|
||||
|
||||
This blog will introduce how to use CUE and KubeVela to build you own abstraction API to reduce the complexity of Kubernetes resources. As a platform builder, you can dynamically customzie the abstraction, build a path from shallow to deep for your developers per needs, adapt to growing number of different scenarios, and meet the iterative demands of the company's long-term business development.
|
||||
|
||||
## Convert Kubernetes API Objects Into Custom Components
|
||||
|
||||
Let's start the journey by using the [Kubernetes StatefulSet](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) as example, we will convert it to be a customized module and provide capabilities.
|
||||
|
||||
Save the YAML example of StatefulSet in the official document locally and name it as `my-stateful.yaml`, then execute command as below:
|
||||
|
||||
vela def init my-stateful -t component --desc "My StatefulSet component." --template-yaml ./my-stateful.yaml -o my-stateful.cue
|
||||
|
||||
View the generated "my-stateful.cue" file:
|
||||
|
||||
$ cat my-stateful.cue
|
||||
"my-stateful": {
|
||||
annotations: {}
|
||||
attributes: workload: definition: {
|
||||
apiVersion: "<change me> apps/v1"
|
||||
kind: "<change me> Deployment"
|
||||
}
|
||||
description: "My StatefulSet component."
|
||||
labels: {}
|
||||
type: "component"
|
||||
}
|
||||
|
||||
template: {
|
||||
output: {
|
||||
apiVersion: "v1"
|
||||
kind: "Service"
|
||||
... // omit non-critical info
|
||||
}
|
||||
outputs: web: {
|
||||
apiVersion: "apps/v1"
|
||||
kind: "StatefulSet"
|
||||
... // omit non-critical info
|
||||
}
|
||||
parameter: {}
|
||||
}
|
||||
|
||||
Modify the generated file as follows:
|
||||
|
||||
1. The example of the official StatefulSet website is a composite component composed of two objects `StatefulSet` and `Service`. According to KubeVela [Rules for customize component](https://kubevela.io/docs/platform-engineers/components/custom-component), in composite components, one of the resources such (StatefulSet in our example) need to be represented by the `template.output` field as a core workload, and other auxiliary objects are represented by `template.outputs`, so we make some adjustments and all the automatically generated output and outputs are switched.
|
||||
2. Then we fill in the apiVersion and kind data of the core workload into the part marked as `<change me>`
|
||||
|
||||
After modification, you can use `vela def vet` to do format check and verification.
|
||||
|
||||
$ vela def vet my-stateful.cue
|
||||
Validation succeed.
|
||||
|
||||
The file after two steps of changes is as follows:
|
||||
|
||||
$ cat my-stateful.cue
|
||||
"my-stateful": {
|
||||
annotations: {}
|
||||
attributes: workload: definition: {
|
||||
apiVersion: "apps/v1"
|
||||
kind: "StatefulSet"
|
||||
}
|
||||
description: "My StatefulSet component."
|
||||
labels: {}
|
||||
type: "component"
|
||||
}
|
||||
|
||||
template: {
|
||||
output: {
|
||||
apiVersion: "apps/v1"
|
||||
kind: "StatefulSet"
|
||||
metadata: name: "web"
|
||||
spec: {
|
||||
selector: matchLabels: app: "nginx"
|
||||
replicas: 3
|
||||
serviceName: "nginx"
|
||||
template: {
|
||||
metadata: labels: app: "nginx"
|
||||
spec: {
|
||||
containers: [{
|
||||
name: "nginx"
|
||||
ports: [{
|
||||
name: "web"
|
||||
containerPort: 80
|
||||
}]
|
||||
image: "k8s.gcr.io/nginx-slim:0.8"
|
||||
volumeMounts: [{
|
||||
name: "www"
|
||||
mountPath: "/usr/share/nginx/html"
|
||||
}]
|
||||
}]
|
||||
terminationGracePeriodSeconds: 10
|
||||
}
|
||||
}
|
||||
volumeClaimTemplates: [{
|
||||
metadata: name: "www"
|
||||
spec: {
|
||||
accessModes: ["ReadWriteOnce"]
|
||||
resources: requests: storage: "1Gi"
|
||||
storageClassName: "my-storage-class"
|
||||
}
|
||||
}]
|
||||
}
|
||||
}
|
||||
outputs: web: {
|
||||
apiVersion: "v1"
|
||||
kind: "Service"
|
||||
metadata: {
|
||||
name: "nginx"
|
||||
labels: app: "nginx"
|
||||
}
|
||||
spec: {
|
||||
clusterIP: "None"
|
||||
ports: [{
|
||||
name: "web"
|
||||
port: 80
|
||||
}]
|
||||
selector: app: "nginx"
|
||||
}
|
||||
}
|
||||
parameter: {}
|
||||
}
|
||||
|
||||
Install ComponentDefinition into the Kubernetes cluster:
|
||||
|
||||
$ vela def apply my-stateful.cue
|
||||
ComponentDefinition my-stateful created in namespace vela-system.
|
||||
|
||||
You can see that a `my-stateful` component via `vela components` command:
|
||||
|
||||
$ vela components
|
||||
NAME NAMESPACE WORKLOAD DESCRIPTION
|
||||
...
|
||||
my-stateful vela-system statefulsets.apps My StatefulSet component.
|
||||
...
|
||||
|
||||
When you put this customized component into `Application`, it looks like:
|
||||
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: website
|
||||
spec:
|
||||
components:
|
||||
- name: my-component
|
||||
type: my-stateful
|
||||
EOF
|
||||
|
||||
|
||||
|
||||
## Define Customized Parameters For Component
|
||||
|
||||
In previous section we have defined a ComponentDefinition that has no parameter. In this section we will show how to expose parameters.
|
||||
|
||||
In this example, we expose the following parameters to the user:
|
||||
|
||||
* Image name, allowing users to customize the image
|
||||
* Instance name, allowing users to customize the instance name of the generated StatefulSet object and Service object
|
||||
|
||||
|
||||
... # Omit other unmodified fields
|
||||
template: {
|
||||
output: {
|
||||
apiVersion: "apps/v1"
|
||||
kind: "StatefulSet"
|
||||
metadata: name: parameter.name
|
||||
spec: {
|
||||
selector: matchLabels: app: "nginx"
|
||||
replicas: 3
|
||||
serviceName: "nginx"
|
||||
template: {
|
||||
metadata: labels: app: "nginx"
|
||||
spec: {
|
||||
containers: [{
|
||||
image: parameter.image
|
||||
|
||||
... // Omit other unmodified fields
|
||||
}]
|
||||
}
|
||||
}
|
||||
... // Omit other unmodified fields
|
||||
}
|
||||
}
|
||||
outputs: web: {
|
||||
apiVersion: "v1"
|
||||
kind: "Service"
|
||||
metadata: {
|
||||
name: "nginx"
|
||||
labels: app: "nginx"
|
||||
}
|
||||
spec: {
|
||||
... // Omit other unmodified fields
|
||||
}
|
||||
}
|
||||
parameter: {
|
||||
image: string
|
||||
name: string
|
||||
}
|
||||
}
|
||||
|
||||
After modification, use `vela def apply` to install to the cluster:
|
||||
|
||||
$ vela def apply my-stateful.cue
|
||||
ComponentDefinition my-stateful in namespace vela-system updated.
|
||||
|
||||
Then as a platform builder, you have finished your setup. Let's see what's the developer experience now.
|
||||
|
||||
## Developer Experience
|
||||
|
||||
The only thing your developer need to learn is the [Open Application Model](https://oam.dev/) which always follow a unified format.
|
||||
|
||||
### Discover the Component
|
||||
|
||||
The developers can discover and check the parameters of `my-stateful` component as follows:
|
||||
|
||||
```
|
||||
$ vela def list
|
||||
NAME TYPE NAMESPACE DESCRIPTION
|
||||
my-stateful ComponentDefinition vela-system My StatefulSet component.
|
||||
...snip...
|
||||
```
|
||||
|
||||
$ vela show my-stateful
|
||||
# Properties
|
||||
+----------+-------------+--------+----------+---------+
|
||||
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
|
||||
+----------+-------------+--------+----------+---------+
|
||||
| name | | string | true | |
|
||||
| image | | string | true | |
|
||||
+----------+-------------+--------+----------+---------+
|
||||
|
||||
Updating the ComponentDefinition will not affect existing Applications. It will take effect only after updating the Applications next time.
|
||||
|
||||
### Use the Component in Application
|
||||
|
||||
The developers can easily specify the three new parameters in the application:
|
||||
|
||||
```
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: website
|
||||
spec:
|
||||
components:
|
||||
- name: my-component
|
||||
type: my-stateful
|
||||
properties:
|
||||
image: nginx:latest
|
||||
name: my-component
|
||||
```
|
||||
|
||||
The only thing left is to deploy the yaml file ( assume the name `app-stateful.yaml`) by executing `vela up -f app-stateful.yaml`.
|
||||
|
||||
Then you can see that the name, image, and number of instances of the StatefulSet object have been updated.
|
||||
|
||||
## Dry-run for diagnose or integration
|
||||
|
||||
In order to ensure that the developer's application can run correctly with the parameters, you can also use the `vela dry-run` command to verify the trial run of your template.
|
||||
|
||||
```shell
|
||||
vela dry-run -f app-stateful.yaml
|
||||
```
|
||||
|
||||
By viewing the output, you can compare whether the generated object is consistent with the object you actually expect. You can even execute this YAML directly into the Kubernetes cluster and use the results of the operation for verification.
|
||||
|
||||
<details>
|
||||
|
||||
```
|
||||
# Application(website) -- Component(my-component)
|
||||
---
|
||||
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
labels:
|
||||
app: nginx
|
||||
app.oam.dev/appRevision: ""
|
||||
app.oam.dev/component: my-component
|
||||
app.oam.dev/name: website
|
||||
workload.oam.dev/type: my-stateful
|
||||
name: nginx
|
||||
namespace: default
|
||||
spec:
|
||||
clusterIP: None
|
||||
ports:
|
||||
- name: web
|
||||
port: 80
|
||||
selector:
|
||||
app: nginx
|
||||
template:
|
||||
spec:
|
||||
containers:
|
||||
- image: saravak/fluentd:elastic
|
||||
name: my-sidecar
|
||||
|
||||
---
|
||||
apiVersion: apps/v1
|
||||
kind: StatefulSet
|
||||
metadata:
|
||||
labels:
|
||||
app.oam.dev/appRevision: ""
|
||||
app.oam.dev/component: my-component
|
||||
app.oam.dev/name: website
|
||||
trait.oam.dev/resource: web
|
||||
trait.oam.dev/type: AuxiliaryWorkload
|
||||
name: web
|
||||
namespace: default
|
||||
spec:
|
||||
replicas: 3
|
||||
selector:
|
||||
matchLabels:
|
||||
app: nginx
|
||||
serviceName: nginx
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: nginx
|
||||
spec:
|
||||
containers:
|
||||
- image: k8s.gcr.io/nginx-slim:0.8
|
||||
name: nginx
|
||||
ports:
|
||||
- containerPort: 80
|
||||
name: web
|
||||
volumeMounts:
|
||||
- mountPath: /usr/share/nginx/html
|
||||
name: www
|
||||
terminationGracePeriodSeconds: 10
|
||||
volumeClaimTemplates:
|
||||
- metadata:
|
||||
name: www
|
||||
spec:
|
||||
accessModes:
|
||||
- ReadWriteOnce
|
||||
resources:
|
||||
requests:
|
||||
storage: 1Gi
|
||||
storageClassName: my-storage-class
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
|
||||
You can also use `vela dry-run -h` to view more available function parameters.
|
||||
|
||||
|
||||
## Use `context` to avoid duplication
|
||||
|
||||
KubeVela allows you to reference the runtime information of your application via [`context` keyword](https://kubevela.io/docs/platform-engineers/components/custom-component#cue-context).
|
||||
|
||||
In our example above, the field `name` in the properties and the field `name` of the Component have the same meaning, so we can use the `context` to avoid duplication. We cann use the `context.name` to reference the component name in the runtime, thus the name parameter in `parameter` is no longer needed.
|
||||
|
||||
Just modify the definition file (my-stateful.cue) as the following
|
||||
|
||||
|
||||
... # Omit other unmodified fields
|
||||
template: {
|
||||
output: {
|
||||
apiVersion: "apps/v1"
|
||||
kind: "StatefulSet"
|
||||
- metadata: name: parameter.name
|
||||
+ metadata: name: context.name
|
||||
|
||||
... // Omit other unmodified field
|
||||
|
||||
}
|
||||
parameter: {
|
||||
- name: string
|
||||
image: string
|
||||
}
|
||||
}
|
||||
|
||||
Then deploy the changes by the following:
|
||||
|
||||
```
|
||||
vela def apply my-stateful.cue
|
||||
```
|
||||
|
||||
After that, the developers can immediately run application as below:
|
||||
|
||||
```
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: website
|
||||
spec:
|
||||
components:
|
||||
- name: my-component
|
||||
type: my-stateful
|
||||
properties:
|
||||
image: "nginx:latest"
|
||||
```
|
||||
|
||||
There's no upgrade or restart for any system, they're all running into affect dynamically per your needs.
|
||||
|
||||
## Add Operational Traits On Demand
|
||||
|
||||
OAM follows the principle of "separation of concerns", after the developers finished the component part, the operators can add traits into the application to control the rest part configuration of the deployment. For example, the operators can
|
||||
control replicas, adding labels/annotations, injecting environment variables/sidecars, adding persistent volumes, and so on.
|
||||
|
||||
Technically, the trait system works in two ways:
|
||||
|
||||
- Patch/Override the configurations defined in component.
|
||||
- Generate more configuration.
|
||||
|
||||
The customized process works the same with the component, they both use CUE but has some different keywords for path and override, you can refer to [customize trait](https://kubevela.io/docs/platform-engineers/traits/customize-trait) for details.
|
||||
|
||||
## Operator Experience with traits
|
||||
|
||||
There're already some built-in traits after KubeVela installed. The operator can use `vela traits` to view, the traits marked with `*` are general traits, which can operate on common Kubernetes resource objects.
|
||||
|
||||
$ vela traits
|
||||
NAME NAMESPACE APPLIES-TO CONFLICTS-WITH POD-DISRUPTIVE DESCRIPTION
|
||||
annotations vela-system * true Add annotations on K8s pod for your workload which follows
|
||||
the pod spec in path 'spec.template'.
|
||||
configmap vela-system * true Create/Attach configmaps on K8s pod for your workload which
|
||||
follows the pod spec in path 'spec.template'.
|
||||
labels vela-system * true Add labels on K8s pod for your workload which follows the
|
||||
pod spec in path 'spec.template'.
|
||||
scaler vela-system * false Manually scale K8s pod for your workload which follows the
|
||||
pod spec in path 'spec.template'.
|
||||
sidecar vela-system * true Inject a sidecar container to K8s pod for your workload
|
||||
which follows the pod spec in path 'spec.template'.
|
||||
...snip...
|
||||
|
||||
Taking sidecar as an example, you can check the usage of sidecar:
|
||||
|
||||
$ vela show sidecar
|
||||
# Properties
|
||||
+---------+-----------------------------------------+-----------------------+----------+---------+
|
||||
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
|
||||
+---------+-----------------------------------------+-----------------------+----------+---------+
|
||||
| name | Specify the name of sidecar container | string | true | |
|
||||
| cmd | Specify the commands run in the sidecar | []string | false | |
|
||||
| image | Specify the image of sidecar container | string | true | |
|
||||
| volumes | Specify the shared volume path | [[]volumes](#volumes) | false | |
|
||||
+---------+-----------------------------------------+-----------------------+----------+---------+
|
||||
|
||||
|
||||
## volumes
|
||||
+------+-------------+--------+----------+---------+
|
||||
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
|
||||
+------+-------------+--------+----------+---------+
|
||||
| path | | string | true | |
|
||||
| name | | string | true | |
|
||||
+------+-------------+--------+----------+---------+
|
||||
|
||||
Use the sidecar directly to inject a container, the application description is as follows:
|
||||
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: website
|
||||
spec:
|
||||
components:
|
||||
- name: my-component
|
||||
type: my-stateful
|
||||
properties:
|
||||
image: nginx:latest
|
||||
name: my-component
|
||||
traits:
|
||||
- type: sidecar
|
||||
properties:
|
||||
name: my-sidecar
|
||||
image: saravak/fluentd:elastic
|
||||
|
||||
Deploy and run the application, and you can see that a fluentd sidecar has been deployed and running in the StatefulSet.
|
||||
|
||||
Both components and traits are re-usable on any KubeVela systems, we can package components, traits along with the CRD controllers together as an addon. There're [a growing catalog of addons](https://github.com/kubevela/catalog) in the community.
|
||||
|
||||
## Summarize
|
||||
|
||||
This blog introduces how to deliver complete modular capabilities through CUE. The core is that it can dynamically increase configuration capabilities according to user needs, and gradually expose more functions and usages, so as to reduce the overall learning threshold for users and ultimately improve R&D efficient.
|
||||
The out-of-the-box capabilities provided by KubeVela, including components, traits, policy, and workflow, are also designed as plugable and modifiable capabilities.
|
||||
|
||||
|
||||
|
|
@ -1,10 +1,10 @@
|
|||
---
|
||||
title: GitOps
|
||||
title: FluxCD
|
||||
---
|
||||
|
||||
This section will introduce how to use KubeVela in GitOps environment and why.
|
||||
|
||||
> This section is only apply to CLI, you need to enable the fluxcd addon.
|
||||
> This section is only apply to CLI, you need to enable the [fluxcd](../reference/addons/fluxcd) addon.
|
||||
|
||||
## Introduction
|
||||
|
||||
|
|
|
|||
|
|
@ -7,12 +7,9 @@ You can pick up any of the following ways you're interested to contribute.
|
|||
## Contribute Use cases and Samples
|
||||
|
||||
* If you're using KubeVela, the easiest thing to contribute is to [credit the community](https://github.com/kubevela/kubevela/issues/1662).
|
||||
|
||||
* If you are interested, you can also write a [kubevela.io blog](https://kubevela.net/blog) to tell more about the use case.
|
||||
|
||||
* You can also contribute to [KubeVela Official Samples](https://github.com/kubevela/samples).
|
||||
|
||||
|
||||
## Report bugs
|
||||
|
||||
Before submitting a new issue, try to make sure someone hasn't already reported the problem.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: ServiceAccount Integration for RBAC
|
||||
title: Kubernetes RBAC
|
||||
---
|
||||
|
||||
KubeVela applies Components and runs Workflow with the controller service account, which allows you to manage components across namespaces.
|
||||
|
|
|
|||
|
|
@ -1,16 +1,26 @@
|
|||
---
|
||||
title: Integrate by Triggers
|
||||
title: Triggers
|
||||
description: Integrate with CI system by Triggers
|
||||
---
|
||||
|
||||
After you have created an application, a default trigger is automatically created. You can also delete or create a new trigger.
|
||||
You can use triggers from [VelaUX addon](../../../reference/addons/velaux) to integrate with different CI systems, the architecture and supported platforms are described in the following picture, they're:
|
||||
|
||||
- [Custom](#custom-trigger), refer to [Jenkins CI](../../../tutorials/jenkins) guide for a real world use case
|
||||
- [ACR](#ACR-trigger)
|
||||
- [Harbor](#Harbor-trigger), refer to [Harbor Integration](../../../tutorials/trigger) guide for a real world use case
|
||||
- [DockerHub](#DockerHub-trigger)
|
||||
- [JFrog](#JFrog-trigger)
|
||||
|
||||
|
||||
|
||||
## How to use
|
||||
|
||||
A default trigger will be automatically generated after an application created. You can also delete it and create a new one.
|
||||
|
||||
|
||||
|
||||
KubeVela triggers can integrate with any CI tool like Gitlab CI, Jenkins Pipeline or image registry like Harbor or ACR.
|
||||
|
||||
We now support five types of triggers: Custom, ACR, Harbor, DockerHub and JFrog.
|
||||
|
||||
## Custom Trigger
|
||||
|
||||
Custom triggers will provide a webhook URL, which you can use to integrate with your CI tool using the specified request body.
|
||||
|
|
@ -60,23 +70,13 @@ After CI have executed this step, we can see that application is deployed succes
|
|||
|
||||
|
||||
|
||||
You can refer to [Jenkins CI](../../../tutorials/jenkins) guide for a real use case about custom trigger.
|
||||
|
||||
## Harbor Trigger
|
||||
|
||||
Harbor Trigger can be integrated with Harbor image registry.
|
||||
|
||||
We can start with creating a new harbor trigger. The Payload Type is Harbor, and the Execution Workflow is the workflow you want to deploy in the trigger.
|
||||
|
||||
|
||||
|
||||
After creating the trigger, we can setup this trigger in Harbor:
|
||||
|
||||
|
||||
|
||||
After configuring the trigger, we can see the new deploy revisions when a new image is pushed to the registry.
|
||||
|
||||
|
||||
|
||||
|
||||
You can refer to [Harbor Image Registry](../../../tutorials/trigger) guide for the end to end tutorial.
|
||||
|
||||
## ACR Trigger
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: User management
|
||||
title: Introduction
|
||||
---
|
||||
|
||||
Once VelaUX is installed, there's a built-in administrator user with full access to the system. It is recommended to use the admin user only for the initial configuration, then switch to another user or configure the SSO integration.
|
||||
|
|
|
|||
|
|
@ -1,10 +1,8 @@
|
|||
---
|
||||
title: CUE Components
|
||||
title: Component Definition
|
||||
---
|
||||
|
||||
In this section, it will introduce how to use [CUE](https://cuelang.org/) to declare app components via `ComponentDefinition`.
|
||||
|
||||
> Before reading this part, please make sure you've learned the [Definition CRD](../definition-and-templates) in KubeVela.
|
||||
In this section, we will introduce how to use [CUE](https://cuelang.org/) to customize components via `ComponentDefinition`. Make sure you've learned the basic knowledge about [Definition Concept](../../getting-started/definition) and [how to manage definition](../cue/definition-edit).
|
||||
|
||||
## Declare `ComponentDefinition`
|
||||
|
||||
|
|
|
|||
|
|
@ -1,456 +1,5 @@
|
|||
---
|
||||
title: CUE Advanced
|
||||
title: CUE advanced
|
||||
---
|
||||
|
||||
This section will introduce how to use CUE to deliver KubeVela modules. You can dynamically expand the platform as user needs change, adapt to growing number of users and scenarios, and meet the iterative demands of the company's long-term business development.
|
||||
|
||||
## Convert Kubernetes API Objects Into Custom Components
|
||||
|
||||
Let's take the [Kubernetes StatefulSet][5] as an example to show how to use KubeVela to build custom modules and provide capabilities.
|
||||
|
||||
Save the YAML example of StatefulSet in the official document locally and name it as `my-stateful.yaml`, then execute commande as below:
|
||||
|
||||
vela def init my-stateful -t component --desc "My StatefulSet component." --template-yaml ./my-stateful.yaml -o my-stateful.cue
|
||||
|
||||
View the generated "my-stateful.cue" file:
|
||||
|
||||
$ cat my-stateful.cue
|
||||
"my-stateful": {
|
||||
annotations: {}
|
||||
attributes: workload: definition: {
|
||||
apiVersion: "<change me> apps/v1"
|
||||
kind: "<change me> Deployment"
|
||||
}
|
||||
description: "My StatefulSet component."
|
||||
labels: {}
|
||||
type: "component"
|
||||
}
|
||||
|
||||
template: {
|
||||
output: {
|
||||
apiVersion: "v1"
|
||||
kind: "Service"
|
||||
... // omit non-critical info
|
||||
}
|
||||
outputs: web: {
|
||||
apiVersion: "apps/v1"
|
||||
kind: "StatefulSet"
|
||||
... // omit non-critical info
|
||||
}
|
||||
parameter: {}
|
||||
}
|
||||
|
||||
Modify the generated file as follows:
|
||||
|
||||
1. The example of the official StatefulSet website is a composite component composed of two objects `StatefulSet` and `Service`. According to KubeVela [Rules for customize components] [6], in composite components, core workloads such as StatefulSet need to be represented by the `template.output` field, and other auxiliary objects are represented by `template.outputs`, so we make some adjustments and all the automatically generated output and outputs are switched.
|
||||
2. Then we fill in the apiVersion and kind data of the core workload into the part marked as `<change me>`
|
||||
|
||||
After modification, you can use `vela def vet` to do format check and verification.
|
||||
|
||||
$ vela def vet my-stateful.cue
|
||||
Validation succeed.
|
||||
|
||||
The file after two steps of changes is as follows:
|
||||
|
||||
$ cat my-stateful.cue
|
||||
"my-stateful": {
|
||||
annotations: {}
|
||||
attributes: workload: definition: {
|
||||
apiVersion: "apps/v1"
|
||||
kind: "StatefulSet"
|
||||
}
|
||||
description: "My StatefulSet component."
|
||||
labels: {}
|
||||
type: "component"
|
||||
}
|
||||
|
||||
template: {
|
||||
output: {
|
||||
apiVersion: "apps/v1"
|
||||
kind: "StatefulSet"
|
||||
metadata: name: "web"
|
||||
spec: {
|
||||
selector: matchLabels: app: "nginx"
|
||||
replicas: 3
|
||||
serviceName: "nginx"
|
||||
template: {
|
||||
metadata: labels: app: "nginx"
|
||||
spec: {
|
||||
containers: [{
|
||||
name: "nginx"
|
||||
ports: [{
|
||||
name: "web"
|
||||
containerPort: 80
|
||||
}]
|
||||
image: "k8s.gcr.io/nginx-slim:0.8"
|
||||
volumeMounts: [{
|
||||
name: "www"
|
||||
mountPath: "/usr/share/nginx/html"
|
||||
}]
|
||||
}]
|
||||
terminationGracePeriodSeconds: 10
|
||||
}
|
||||
}
|
||||
volumeClaimTemplates: [{
|
||||
metadata: name: "www"
|
||||
spec: {
|
||||
accessModes: ["ReadWriteOnce"]
|
||||
resources: requests: storage: "1Gi"
|
||||
storageClassName: "my-storage-class"
|
||||
}
|
||||
}]
|
||||
}
|
||||
}
|
||||
outputs: web: {
|
||||
apiVersion: "v1"
|
||||
kind: "Service"
|
||||
metadata: {
|
||||
name: "nginx"
|
||||
labels: app: "nginx"
|
||||
}
|
||||
spec: {
|
||||
clusterIP: "None"
|
||||
ports: [{
|
||||
name: "web"
|
||||
port: 80
|
||||
}]
|
||||
selector: app: "nginx"
|
||||
}
|
||||
}
|
||||
parameter: {}
|
||||
}
|
||||
|
||||
Install ComponentDefinition into the Kubernetes cluster:
|
||||
|
||||
$ vela def apply my-stateful.cue
|
||||
ComponentDefinition my-stateful created in namespace vela-system.
|
||||
|
||||
You can see that a `my-stateful` component via `vela components` command:
|
||||
|
||||
$ vela components
|
||||
NAME NAMESPACE WORKLOAD DESCRIPTION
|
||||
...
|
||||
my-stateful vela-system statefulsets.apps My StatefulSet component.
|
||||
...
|
||||
|
||||
When you put this customized component into `Application`, it looks like:
|
||||
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: website
|
||||
spec:
|
||||
components:
|
||||
- name: my-component
|
||||
type: my-stateful
|
||||
EOF
|
||||
|
||||
|
||||
|
||||
## Define Customized Parameters For Component
|
||||
|
||||
In previous section we have defined a ComponentDefinition that has no parameter. In this section we will show how to expose parameters.
|
||||
|
||||
In this example, we expose the following parameters to the user:
|
||||
|
||||
* Image name, allowing users to customize the image
|
||||
* Instance name, allowing users to customize the instance name of the generated StatefulSet object and Service object
|
||||
* The number of replica, the number of copies of the generated object
|
||||
|
||||
|
||||
... # Omit other unmodified fields
|
||||
template: {
|
||||
output: {
|
||||
apiVersion: "apps/v1"
|
||||
kind: "StatefulSet"
|
||||
metadata: name: parameter.name
|
||||
spec: {
|
||||
selector: matchLabels: app: "nginx"
|
||||
replicas: parameter.replicas
|
||||
serviceName: "nginx"
|
||||
template: {
|
||||
metadata: labels: app: "nginx"
|
||||
spec: {
|
||||
containers: [{
|
||||
image: parameter.image
|
||||
|
||||
... // Omit other unmodified fields
|
||||
}]
|
||||
}
|
||||
}
|
||||
... // Omit other unmodified fields
|
||||
}
|
||||
}
|
||||
outputs: web: {
|
||||
apiVersion: "v1"
|
||||
kind: "Service"
|
||||
metadata: {
|
||||
name: "nginx"
|
||||
labels: app: "nginx"
|
||||
}
|
||||
spec: {
|
||||
... // Omit other unmodified fields
|
||||
}
|
||||
}
|
||||
parameter: {
|
||||
image: string
|
||||
name: string
|
||||
replicas: int
|
||||
}
|
||||
}
|
||||
|
||||
After modification, use `vela def apply` to install to the cluster:
|
||||
|
||||
$ vela def apply my-stateful.cue
|
||||
ComponentDefinition my-stateful in namespace vela-system updated.
|
||||
|
||||
You can see the parameters of my-stateful ComponentDefinition as follows:
|
||||
|
||||
$ vela show my-stateful
|
||||
# Properties
|
||||
+----------+-------------+--------+----------+---------+
|
||||
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
|
||||
+----------+-------------+--------+----------+---------+
|
||||
| name | | string | true | |
|
||||
| replicas | | int | true | |
|
||||
| image | | string | true | |
|
||||
+----------+-------------+--------+----------+---------+
|
||||
|
||||
Updating the ComponentDefinition will not affect existing Applications. It will take effect only after updating the Applications next time.
|
||||
|
||||
You can specify the three new parameters in the application:
|
||||
|
||||
```
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: website
|
||||
spec:
|
||||
components:
|
||||
- name: my-component
|
||||
type: my-stateful
|
||||
properties:
|
||||
image: nginx:latest
|
||||
replicas: 1
|
||||
name: my-component
|
||||
```
|
||||
|
||||
Save the file locally and name it `app-stateful.yaml`, execute `vela up -f app-stateful.yaml` to update the application, you can see that the name, image, and number of instances of the StatefulSet object have been updated.
|
||||
|
||||
## Dry-run
|
||||
|
||||
In order to ensure that the user's application can run correctly with the parameters, you can also use the `vela dry-run` command to verify the trial run of your template.
|
||||
|
||||
```shell
|
||||
vela dry-run -f app-stateful.yaml
|
||||
```
|
||||
|
||||
By viewing the output, you can compare whether the generated object is consistent with the object you actually expect. You can even execute this YAML directly into the Kubernetes cluster and use the results of the operation for verification.
|
||||
|
||||
<details>
|
||||
|
||||
```
|
||||
# Application(website) -- Component(my-component)
|
||||
---
|
||||
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
labels:
|
||||
app: nginx
|
||||
app.oam.dev/appRevision: ""
|
||||
app.oam.dev/component: my-component
|
||||
app.oam.dev/name: website
|
||||
workload.oam.dev/type: my-stateful
|
||||
name: nginx
|
||||
namespace: default
|
||||
spec:
|
||||
clusterIP: None
|
||||
ports:
|
||||
- name: web
|
||||
port: 80
|
||||
selector:
|
||||
app: nginx
|
||||
template:
|
||||
spec:
|
||||
containers:
|
||||
- image: saravak/fluentd:elastic
|
||||
name: my-sidecar
|
||||
|
||||
---
|
||||
apiVersion: apps/v1
|
||||
kind: StatefulSet
|
||||
metadata:
|
||||
labels:
|
||||
app.oam.dev/appRevision: ""
|
||||
app.oam.dev/component: my-component
|
||||
app.oam.dev/name: website
|
||||
trait.oam.dev/resource: web
|
||||
trait.oam.dev/type: AuxiliaryWorkload
|
||||
name: web
|
||||
namespace: default
|
||||
spec:
|
||||
replicas: 3
|
||||
selector:
|
||||
matchLabels:
|
||||
app: nginx
|
||||
serviceName: nginx
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: nginx
|
||||
spec:
|
||||
containers:
|
||||
- image: k8s.gcr.io/nginx-slim:0.8
|
||||
name: nginx
|
||||
ports:
|
||||
- containerPort: 80
|
||||
name: web
|
||||
volumeMounts:
|
||||
- mountPath: /usr/share/nginx/html
|
||||
name: www
|
||||
terminationGracePeriodSeconds: 10
|
||||
volumeClaimTemplates:
|
||||
- metadata:
|
||||
name: www
|
||||
spec:
|
||||
accessModes:
|
||||
- ReadWriteOnce
|
||||
resources:
|
||||
requests:
|
||||
storage: 1Gi
|
||||
storageClassName: my-storage-class
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
|
||||
You can also use `vela dry-run -h` to view more available function parameters.
|
||||
|
||||
|
||||
## Use `context` to get runtime information
|
||||
|
||||
In our Application example above, the name field in the properties and the name field of the Component are the same. So we can use the `context` keyword that carries context information in the template, where `context.name` is the runtime component Name, thus the name parameter in `parameter` is no longer needed.
|
||||
|
||||
... # Omit other unmodified fields
|
||||
template: {
|
||||
output: {
|
||||
apiVersion: "apps/v1"
|
||||
kind: "StatefulSet"
|
||||
metadata: name: context.name
|
||||
... // Omit other unmodified field
|
||||
}
|
||||
parameter: {
|
||||
image: string
|
||||
replicas: int
|
||||
}
|
||||
}
|
||||
|
||||
KubeVela has built-in application [required context][9], you can configure it according to your needs.
|
||||
|
||||
## Add Traits On Demand
|
||||
|
||||
In addition to modifying ComponentDefinitions and adding parameters, you can also use the TraitDefinition to patch configurations to Components. KubeVela has built-in operations to meet the following needs: adding labels, annotations, injecting environment variables, sidecars, adding volumes, and so on. You can also [customize Trait][10] to do more flexible patching.
|
||||
|
||||
You can use `vela traits` to view, the traits marked with `*` are general traits, which can operate on common Kubernetes resource objects.
|
||||
|
||||
$ vela traits
|
||||
NAME NAMESPACE APPLIES-TO CONFLICTS-WITH POD-DISRUPTIVE DESCRIPTION
|
||||
annotations vela-system * true Add annotations on K8s pod for your workload which follows
|
||||
the pod spec in path 'spec.template'.
|
||||
configmap vela-system * true Create/Attach configmaps on K8s pod for your workload which
|
||||
follows the pod spec in path 'spec.template'.
|
||||
env vela-system * false add env on K8s pod for your workload which follows the pod
|
||||
spec in path 'spec.template.'
|
||||
hostalias vela-system * false Add host aliases on K8s pod for your workload which follows
|
||||
the pod spec in path 'spec.template'.
|
||||
labels vela-system * true Add labels on K8s pod for your workload which follows the
|
||||
pod spec in path 'spec.template'.
|
||||
lifecycle vela-system * true Add lifecycle hooks for the first container of K8s pod for
|
||||
your workload which follows the pod spec in path
|
||||
'spec.template'.
|
||||
node-affinity vela-system * true affinity specify node affinity and toleration on K8s pod for
|
||||
your workload which follows the pod spec in path
|
||||
'spec.template'.
|
||||
scaler vela-system * false Manually scale K8s pod for your workload which follows the
|
||||
pod spec in path 'spec.template'.
|
||||
sidecar vela-system * true Inject a sidecar container to K8s pod for your workload
|
||||
which follows the pod spec in path 'spec.template'.
|
||||
|
||||
|
||||
Taking sidecar as an example, you can check the usage of sidecar:
|
||||
|
||||
$ vela show sidecar
|
||||
# Properties
|
||||
+---------+-----------------------------------------+-----------------------+----------+---------+
|
||||
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
|
||||
+---------+-----------------------------------------+-----------------------+----------+---------+
|
||||
| name | Specify the name of sidecar container | string | true | |
|
||||
| cmd | Specify the commands run in the sidecar | []string | false | |
|
||||
| image | Specify the image of sidecar container | string | true | |
|
||||
| volumes | Specify the shared volume path | [[]volumes](#volumes) | false | |
|
||||
+---------+-----------------------------------------+-----------------------+----------+---------+
|
||||
|
||||
|
||||
## volumes
|
||||
+------+-------------+--------+----------+---------+
|
||||
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
|
||||
+------+-------------+--------+----------+---------+
|
||||
| path | | string | true | |
|
||||
| name | | string | true | |
|
||||
+------+-------------+--------+----------+---------+
|
||||
|
||||
Use the sidecar directly to inject a container, the application description is as follows:
|
||||
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: website
|
||||
spec:
|
||||
components:
|
||||
- name: my-component
|
||||
type: my-stateful
|
||||
properties:
|
||||
image: nginx:latest
|
||||
replicas: 1
|
||||
name: my-component
|
||||
traits:
|
||||
- type: sidecar
|
||||
properties:
|
||||
name: my-sidecar
|
||||
image: saravak/fluentd:elastic
|
||||
|
||||
Deploy and run the application, and you can see that a fluentd sidecar has been deployed and running in the StatefulSet.
|
||||
|
||||
You can also use `vela def` to get the CUE source file of the sidecar to modify, add parameters, etc.
|
||||
|
||||
vela def get sidecar
|
||||
|
||||
The customization of operation and maintenance capabilities is similar to component customization, so we won’t go into details here. You can read [Customize Trait][11] for more detailed functions.
|
||||
|
||||
## Summarize
|
||||
|
||||
This section introduces how to deliver complete modular capabilities through CUE. The core is that it can dynamically increase configuration capabilities according to user needs, and gradually expose more functions and usages, so as to reduce the overall learning threshold for users and ultimately improve R&D efficient.
|
||||
The out-of-the-box capabilities provided by KubeVela, including components, traits, policy, and workflow, are also designed as pluggable and modifiable capabilities.
|
||||
|
||||
## Next
|
||||
|
||||
Get to know about how to customize:
|
||||
* [Component](../components/custom-component)
|
||||
* [Trait](../traits/customize-trait)
|
||||
<!-- * [Policy](../policy/custom-policy) -->
|
||||
* [Workflow](../workflow/workflow)
|
||||
|
||||
[1]: ../oam/oam-model
|
||||
[2]: ../oam/x-definition
|
||||
[3]: ../cue/basic
|
||||
[4]: ../cue/definition-edit
|
||||
[5]: https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/
|
||||
[6]: ../components/custom-component#composition
|
||||
[7]: ../cue/basic#cue-templating-and-references
|
||||
[9]: ../oam/x-definition#x-definition-runtime-context
|
||||
[10]: ../traits/patch-trait
|
||||
[11]: ../traits/customize-trait
|
||||
|
||||
|
||||
The docs has been migrated, please refer to [Learning CUE in KubeVela](./basic) sections for details.
|
||||
|
|
@ -505,64 +505,6 @@ output: {
|
|||
}
|
||||
```
|
||||
|
||||
## Import Kube Package
|
||||
## Next
|
||||
|
||||
KubeVela automatically generates all K8s resources as internal packages by reading K8s openapi from the
|
||||
installed K8s cluster.
|
||||
|
||||
You can use these packages with the format `kube/<apiVersion>` in CUE Template of KubeVela just like the same way
|
||||
with the CUE internal packages.
|
||||
|
||||
For example, `Deployment` can be used as:
|
||||
|
||||
```cue
|
||||
import (
|
||||
apps "kube/apps/v1"
|
||||
)
|
||||
|
||||
parameter: {
|
||||
name: string
|
||||
}
|
||||
|
||||
output: apps.#Deployment
|
||||
output: {
|
||||
metadata: name: parameter.name
|
||||
}
|
||||
```
|
||||
|
||||
Service can be used as (import package with an alias is not necessary):
|
||||
|
||||
```cue
|
||||
import ("kube/v1")
|
||||
|
||||
output: v1.#Service
|
||||
output: {
|
||||
metadata: {
|
||||
"name": parameter.name
|
||||
}
|
||||
spec: type: "ClusterIP",
|
||||
}
|
||||
|
||||
parameter: {
|
||||
name: "myapp"
|
||||
}
|
||||
```
|
||||
|
||||
Even the installed CRD works:
|
||||
|
||||
```
|
||||
import (
|
||||
oam "kube/core.oam.dev/v1alpha2"
|
||||
)
|
||||
|
||||
output: oam.#Application
|
||||
output: {
|
||||
metadata: {
|
||||
"name": parameter.name
|
||||
}
|
||||
}
|
||||
|
||||
parameter: {
|
||||
name: "myapp"
|
||||
}
|
||||
```
|
||||
* Learn how to use CUE to extend KubeVela by [Managing Definition](./definition-edit).
|
||||
|
|
|
|||
|
|
@ -2,6 +2,8 @@
|
|||
title: Manage Definition
|
||||
---
|
||||
|
||||
> Before reading this part, please make sure you've learned the [Definition Concept](../../getting-started/definition) of KubeVela.
|
||||
|
||||
In KubeVela CLI, `vela def` command group provides a series of convenient definition writing tools. With these commands, users only need to write CUE files to generate and edit definitions, instead of composing Kubernetes YAML object with mixed CUE string.
|
||||
|
||||
## init
|
||||
|
|
@ -242,3 +244,7 @@ ComponentDefinition my-comp: My component.
|
|||
ComponentDefinition my-comp in namespace my-namespace deleted.
|
||||
```
|
||||
|
||||
## Next
|
||||
|
||||
* Learn more about [defining customized component](../components/custom-component).
|
||||
* Learn more about [defining customized trait](../traits/customize-trait).
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: How-to
|
||||
---
|
||||
|
||||
In this section we will introduce how to define a trait.
|
||||
In this section we will introduce how to define a basic trait with CUE. Make sure you've learned the basic knowledge about [Definition Concept](../../getting-started/definition) and [how to manage definition](../cue/definition-edit).
|
||||
|
||||
## Simple Trait
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Status Write Back
|
||||
title: Define Health of Component and Trait
|
||||
---
|
||||
|
||||
This documentation will explain how to achieve status write back by using CUE templates in definition objects.
|
||||
|
|
|
|||
|
|
@ -1,9 +1,7 @@
|
|||
---
|
||||
title: Machine Learning Addon
|
||||
title: Machine Learning
|
||||
---
|
||||
|
||||
## Machine Learning Addon
|
||||
|
||||
Machine learning addon is divided into model-training addon and model-serving addon. Run the following command to install the addon:
|
||||
|
||||
```shell
|
||||
|
|
|
|||
|
|
@ -0,0 +1,52 @@
|
|||
---
|
||||
title: FluxCD GitOps
|
||||
---
|
||||
|
||||
This addon is built based [FluxCD](https://fluxcd.io/)
|
||||
|
||||
## install
|
||||
|
||||
```shell
|
||||
vela addon enable fluxcd
|
||||
```
|
||||
|
||||
## Definitions
|
||||
|
||||
The following definitions will be enabled after the installation of fluxcd addon.
|
||||
|
||||
- [helm](https://kubevela.io/docs/end-user/components/helm) helps to deploy a helm chart from git repo, helm repo or S3 compatible bucket.
|
||||
|
||||
- [kustomize](https://kubevela.io/docs/end-user/components/kustomize) helps to deploy a kustomize style artifact and GitOps capability to watch changes from git repo or image registry.
|
||||
|
||||
## Note
|
||||
|
||||
- In this addon, there are five controllers to be installed by default
|
||||
|
||||
|CONTROLLER NAME |DEFINITION NAME |DEFINITION TYPE |DEFINITION DESCRIPTION|
|
||||
| :----: | :----: | :----: | ---|
|
||||
|helm-controller |config-helm-repository |ComponentDefinition |Config information to authenticate helm chart repository|
|
||||
|helm-controller |helm |ComponentDefinition |helm release is a group of K8s resources from either gitrepository or helm repo|
|
||||
|kustomize-controller |kustomize |ComponentDefinition |kustomize can fetching, building, updating and applying Kustomize manifests from git repo|
|
||||
|kustomize-controller |kustomize-json-patch |TraitDefinition |A list of JSON6902 patch to selected target|
|
||||
|kustomize-controller |kustomize-patch |TraitDefinition |A list of StrategicMerge or JSON6902 patch to selected target|
|
||||
|kustomize-controller |kustomize-strategy-merge |TraitDefinition |A list of strategic merge to kustomize config
|
||||
|
||||
- Source controller
|
||||
- The source-controller is a Kubernetes operator, specialised in artifacts acquisition from external sources such as Git, Helm repositories and S3 buckets. The source-controller implements the source.toolkit.fluxcd.io API and is a core component of the GitOps toolkit.
|
||||
- 
|
||||
|
||||
- Image (metadata) reflector controller
|
||||
- This is a controller that reflects container image metadata into a Kubernetes cluster. It pairs with the image update automation controller to drive automated config updates.
|
||||
|
||||
- Image automation controller
|
||||
- This controller automates updates to YAML when new container images are available.
|
||||
- Its sibling, image-reflector-controller, scans container image repositories and reflects the metadata in Kubernetes resources. This controller reacts to that image metadata by updating YAML files in a git repository, and committing the changes.
|
||||
|
||||
- kustomize-controller
|
||||
- The kustomize-controller is a Kubernetes operator, specialized in running continuous delivery pipelines for infrastructure and workloads defined with Kubernetes manifests and assembled with Kustomize.
|
||||
- 
|
||||
|
||||
- helm-controller
|
||||
- The helm-controller is a Kubernetes operator, allowing one to declaratively manage Helm chart releases. It is part of a composable GitOps toolkit and depends on source-controller to acquire the Helm charts from Helm repositories.
|
||||
- The desired state of a Helm release is described through a Kubernetes Custom Resource named HelmRelease. Based on the creation, mutation or removal of a HelmRelease resource in the cluster, Helm actions are performed by the operator.
|
||||
- 
|
||||
|
|
@ -5,6 +5,7 @@ title: Overview
|
|||
There's an official addon registry (https://addons.kubevela.net) maintained by KubeVela team. It contains following addons:
|
||||
|
||||
* [VelaUX](./velaux): The KubeVela User Experience (UX ) addon. It will launch a dashboard and an APIServer for better user experience.
|
||||
* [FluxCD](./fluxcd): Provides capability to deliver helm chart and drive GitOps.
|
||||
* [Addon Cloud Resources](./terraform): Provide a bunch of addons to provision cloud resources for different cloud providers.
|
||||
* [Machine Learning Addon](./ai): Machine learning addon is divided into model-training addon and model-serving addon.
|
||||
* [Traefik](./traefik): Traefik is a modern HTTP reverse proxy and load balancer made to deploy microservices with ease.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Addon Cloud Resources
|
||||
title: Cloud Resources
|
||||
---
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ title: Traefik
|
|||
|
||||
Traefik is a modern HTTP reverse proxy and load balancer made to deploy microservices with ease. you can use this addon as a cluster gateway or a microservices gateway.
|
||||
|
||||
## XDefinitions
|
||||
## Definitions
|
||||
|
||||
### http-route(trait)
|
||||
|
||||
|
|
|
|||
|
|
@ -6,15 +6,13 @@ Welcome to join the "User Improvement Plan"! To improve the KubeVela open source
|
|||
|
||||
We will use these data to guide us to improve the installation, user experience and performance. That can also help us to make more decision about features and designs.
|
||||
|
||||
Please read the "User Improvement Plan" carefully, if you don't want to join this plan, just click the quit button in the bottom. This won't block you to use any features about the product.
|
||||
This plan follows the [CNCF Telemetry data collection and usage policy](https://www.linuxfoundation.org/telemetry-data-policy/), you can learn the collection data and more details [here](https://www.linuxfoundation.org/wp-content/uploads/KubeVela-Review-of-Project-Telemetry-Data-Collection-and-Usage.pdf).
|
||||
|
||||
Under the plan, we're going to collect the information including:
|
||||
If you don't want to join this plan, just turn off the button in the "platform setting". This won't block you to use any features about the product.
|
||||
|
||||
* System Information: it includes version of KubeVela and Kubernetes, IP address, timezone, region, etcd.
|
||||
* Operate Behavior Information: it includes which addon installed, the installation process, error info, cluster numbers, application numbers and types, etc.
|
||||
|
||||
|
||||
We promise the data collected can only be used to improve the product user experience and help up to make feature design and decisions.
|
||||
|
||||
We're possible to modify this plan as the product growth, but we will update the plan and notify users about the updates. If you choose to use our service, that means you have agreed our plan and the modification.
|
||||
We promise the data collected can only be used within the community to improve the product user experience and help up to make feature design and decisions.
|
||||
|
||||
Thanks for your support!
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 287 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 391 KiB |
|
|
@ -0,0 +1,34 @@
|
|||
---
|
||||
title: Roadmap 2022.06
|
||||
---
|
||||
|
||||
Date: 2022-04-01 to 2022-06-31
|
||||
|
||||
## Core Platform
|
||||
|
||||
- Enhance the global security of app delivery.
|
||||
* Support multi-cluster authentication and authorization for both KubeVela Controller and VelaUX.
|
||||
* Enhance the security of KubeVela controller.
|
||||
|
||||
- Support observability for application delivery process.
|
||||
* Provide application topology from VelaUX and CLI.
|
||||
* Provide pod level resource status for helm chart and any Kubernetes CRD resources in topology.
|
||||
|
||||
- Support flexible workflow capability.
|
||||
* Condition for workflow step, such as `if always`.
|
||||
* Sub-steps for concurrency deployment.
|
||||
|
||||
## User Experience
|
||||
|
||||
- Release `VelaD` project greatly improve the efficiency of installation, deployment, and usage.
|
||||
- VelaUX improve the extensible components/traits/policies/workflow-steps integration in UI to provide UI editor for definitions.
|
||||
|
||||
|
||||
## Third-party integrations and more addons
|
||||
|
||||
- Provide ArgoCD integration to improve GitOps experience, that'll be alternative to FluxCD addon.
|
||||
- Provide OpenKruise Rollout for better rollout.
|
||||
|
||||
## Best practices
|
||||
|
||||
- Provide one or more best practices about how to deploy and compose cloud resources with KubeVela.
|
||||
|
|
@ -0,0 +1,33 @@
|
|||
---
|
||||
title: Roadmap 2022.09
|
||||
---
|
||||
|
||||
Date: 2022-07-01 to 2022-09-31
|
||||
|
||||
## Core Platform
|
||||
|
||||
- Upgrade CUE engine of KubeVela from 0.2 to 0.4+.
|
||||
- Support KubeVela system level observability for multi-clusters.
|
||||
* Support collect and show log, metrics in a unified Grafana for all KubeVela and addon controllers with the control plane cluster.
|
||||
- Support basic application level observability.
|
||||
* Support collect and show log, metrics with multi-cluster capability.
|
||||
* Automatically generate observability dashboard for application within a unified Grafana.
|
||||
* Allow user to define customize observability rules including logs and metrics.
|
||||
- Support more flexible addons capability.
|
||||
* Standardized definition to make the definition(such as helm component) as one kind of addon dependency, addon can depends on a standard definition instead of any specific implementation(fluxcd or argocd).
|
||||
* Provide partial installation for addon to make it more lightweight.
|
||||
|
||||
|
||||
## User Experience
|
||||
|
||||
- Provide end to end experience from source code development to multi-cluster/hybrid-cloud delivery.
|
||||
- Provide application export/load capability and build a KubeVela AppStore.
|
||||
|
||||
## Third-party integrations and more addons
|
||||
|
||||
- Integrate with OPA/Kyverno/Cosign and other projects to provide a secure software supply chain.
|
||||
|
||||
|
||||
## Best practices
|
||||
|
||||
- Provide one or more best practices about how to use KubeVela in game/financial scenario.
|
||||
|
|
@ -1,7 +1,9 @@
|
|||
---
|
||||
title: KubeVela Roadmap
|
||||
title: Roadmap
|
||||
---
|
||||
|
||||
- [2022 Fall Roadmap](./2022-09-roadmap)
|
||||
- [2022 Summer Roadmap](./2022-06-roadmap)
|
||||
- [2022 Spring Roadmap](./2022-03-roadmap)
|
||||
- [2021 Winter Roadmap](./2021-12-roadmap)
|
||||
- [2021 Fall Roadmap](./2021-09-roadmap)
|
||||
|
|
@ -9,4 +11,6 @@ title: KubeVela Roadmap
|
|||
- [2021 Spring Roadmap](./2021-03-roadmap)
|
||||
- [2020 Winter Roadmap](./2020-12-roadmap)
|
||||
|
||||
To learn more details, please visit the [github issues list](https://github.com/kubevela/kubevela/issues) and milestones.
|
||||
KubeVela follows the [release process and cadence guide](../contributor/release-process) that actions may not be strictly consistent with the roadmap.
|
||||
|
||||
We may adjust the milestone according to the input from [community meeting](https://github.com/kubevela/community#community-meetings) and [github issues](https://github.com/kubevela/kubevela/issues), all community members are expected to join the discussion. You can refer to the [github milestones](https://github.com/kubevela/kubevela/milestones) for the final decisions.
|
||||
|
|
@ -1,12 +1,12 @@
|
|||
---
|
||||
title: Integrating with Jenkins
|
||||
title: Jenkins CI
|
||||
---
|
||||
|
||||
### Introduction
|
||||
|
||||
The workflow execution of KubeVela application can be triggered by webhooks. Therefore, it is rather easy for user to integrate KubeVela with existing Continuous Integration platforms, such as Jenkins or Gitlab.
|
||||
|
||||
In KubeVela 1.2, [VelaUX](../install#2-install-velaux) provides webhook triggers for applications to use. Only a simple curl command in Jenkins pipeline is needed to bridge CI and CD systems.
|
||||
From KubeVela 1.2, [VelaUX](../install#2-install-velaux) provides webhook triggers for applications to use. Only a simple curl command in Jenkins pipeline is needed to bridge CI and CD systems.
|
||||
|
||||
In this section, we will demonstrate how to integrate KubeVela with Jenkins in details.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +1,12 @@
|
|||
---
|
||||
title: Integrating with Image registries
|
||||
title: Harbor Image Registry
|
||||
---
|
||||
|
||||
## Introduction
|
||||
|
||||
In our daily development, when image tags changed, it is more convenient for CI/CD if the environments can automatically deploy the new image. KubeVela provides this mechanism.
|
||||
|
||||
In KubeVela 1.2, [VelaUX](../install#2-install-velaux) provides a good way to do this. We can use KubeVela triggers to apply applications automatically.
|
||||
From KubeVela 1.2, [VelaUX](../install#2-install-velaux) provides a good way to do this. We can use KubeVela triggers to apply applications automatically.
|
||||
|
||||
In this section, we will use GitLab as code repository and Harbor as image repository to integrate with KubeVela triggers, as a result, it will automatically update application when image tags changed.
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@
|
|||
"message": "核心概念",
|
||||
"description": "The label for Core Concepts in sidebar docs"
|
||||
},
|
||||
"sidebar.docs.category.Learning CUE": {
|
||||
"sidebar.docs.category.CUE in KubeVela": {
|
||||
"message": "CUE 语言",
|
||||
"description": "The label for category Learning CUE in sidebar docs"
|
||||
},
|
||||
|
|
@ -35,13 +35,13 @@
|
|||
"message": "实践实验室",
|
||||
"description": "The label for category Hands-on Lab in sidebar docs"
|
||||
},
|
||||
"sidebar.docs.category.Appfile": {
|
||||
"message": "Appfile",
|
||||
"description": "The label for category Appfile in sidebar docs"
|
||||
"sidebar.docs.category.Authentication and Authorization": {
|
||||
"message": "认证和授权",
|
||||
"description": "The label for category Authentication and Authorization in sidebar docs"
|
||||
},
|
||||
"sidebar.docs.category.Roadmap": {
|
||||
"message": "路线规划",
|
||||
"description": "KubeVela 未来的发展计划"
|
||||
"sidebar.docs.category.Conventions": {
|
||||
"message": "开发规约",
|
||||
"description": "KubeVela developer Conventions"
|
||||
},
|
||||
"sidebar.docs.category.Application Deployment": {
|
||||
"message": "Application Deployment",
|
||||
|
|
@ -159,8 +159,8 @@
|
|||
"message": "调试指南",
|
||||
"description": "The label for category Debugging in sidebar docs"
|
||||
},
|
||||
"sidebar.docs.category.Extension": {
|
||||
"message": "平台扩展",
|
||||
"sidebar.docs.category.Contribute Extension": {
|
||||
"message": "贡献平台扩展",
|
||||
"description": "平台扩展参考文档"
|
||||
},
|
||||
"sidebar.docs.category.Simple Template": {
|
||||
|
|
@ -251,10 +251,6 @@
|
|||
"message": "其他高级功能",
|
||||
"description": "其他高级功能"
|
||||
},
|
||||
"sidebar.docs.category.Core Concepts": {
|
||||
"message": "核心概念",
|
||||
"description": "Basic information"
|
||||
},
|
||||
"sidebar.docs.category.Artifacts": {
|
||||
"message": "交付制品",
|
||||
"description": "多样化交付制品"
|
||||
|
|
@ -278,5 +274,32 @@
|
|||
"sidebar.docs.category.CI Integration": {
|
||||
"message": "CI 集成",
|
||||
"description": "CI 集成"
|
||||
},
|
||||
"sidebar.docs.category.Developer Guide": {
|
||||
"message": "开发者手册",
|
||||
"description": "developer guide for sidebar"
|
||||
},
|
||||
"sidebar.docs.category.User management": {
|
||||
"message": "用户管理",
|
||||
"description": "User management for sidebar"
|
||||
},
|
||||
"sidebar.docs.category.Advanced Installation": {
|
||||
"message": "高级安装",
|
||||
"description": "Advanced Installation for sidebar"
|
||||
},
|
||||
"sidebar.docs.category.Helm Chart CD": {
|
||||
"message": "Helm Chart 交付"
|
||||
},
|
||||
"sidebar.docs.category.Container Image CD": {
|
||||
"message": "容器镜像交付"
|
||||
},
|
||||
"sidebar.docs.category.Cloud Resources CD": {
|
||||
"message": "云资源交付"
|
||||
},
|
||||
"sidebar.docs.category.Kubernetes Manifest CD": {
|
||||
"message": "Kubernetes 资源交付"
|
||||
},
|
||||
"sidebar.docs.category.General CD Features": {
|
||||
"message": "通用功能"
|
||||
}
|
||||
}
|
||||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Built-in Trait Type
|
||||
title: 内置运维特征类型
|
||||
---
|
||||
|
||||
This documentation will walk through the built-in traits.
|
||||
|
|
|
|||
|
|
@ -4,13 +4,6 @@ title: 用户体验改进计划
|
|||
|
||||
欢迎您加入“用户体验改进计划”，为了完善 KubeVela 开源产品，避免缺陷，改善开源产品的用户体验，我们需要采集部分安装和使用的数据，汇总之后分析统计这些数据以持续不断地提升产品的安装成功率、操作体验、运行性能，有针对性地改善功能设计，推出对用户有帮助的新功能等。
|
||||
|
||||
请您仔细阅读《用户体验改进计划》的具体内容，如果您不愿意加入该计划，可以直接点击菜单栏末尾的链接退出。
|
||||
请您仔细阅读《用户体验改进计划》的具体内容，如果您不愿意加入该计划，可以直接点击右上角平台设置选择不加入。
|
||||
|
||||
在该用户体验计划下，我们需要采集的信息包括:
|
||||
|
||||
* 系统信息：包括 KubeVela 系统版本，Kubernetes 版本、IP地址、区域、时区等。
|
||||
* 使用信息：除系统信息之外，我们还需要采集一些与操作行为相关的特定数据，包括安装的插件、安装的成功率、操作的成功及失败信息、加入集群数量、部署的应用数量等。
|
||||
|
||||
我们搜集到您的相关信息并进行模糊化处理之后，仅用于改进 KubeVela 产品的功能体验及设计决策。
|
||||
|
||||
根据产品的发展，我们可能会对用户体验改进计划进行修改，我们会在产品和网页中发布更新后的相关信息并在产品界面中明示用户，以便及时通知到用户。如果您选择继续使用我们的服务，即表示您同意接受这些修改。
|
||||
该计划遵守[ CNCF 数据收集相关规定](https://www.linuxfoundation.org/telemetry-data-policy/)，严格保护隐私安全，具体信息可以查看[本链接](https://www.linuxfoundation.org/wp-content/uploads/KubeVela-Review-of-Project-Telemetry-Data-Collection-and-Usage.pdf)。
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
---
|
||||
title: KubeVela 路线规划
|
||||
---
|
||||
|
||||
- [2022 Spring Roadmap](./2022-03-roadmap)
|
||||
- [2021 Winter Roadmap](./2021-12-roadmap)
|
||||
- [2021 Fall Roadmap](./2021-09-roadmap)
|
||||
- [2021 Summer Roadmap](./2021-06-roadmap)
|
||||
- [2021 Spring Roadmap](./2021-03-roadmap)
|
||||
- [2020 Winter Roadmap](./2020-12-roadmap)
|
||||
|
||||
可以通过查看 [github issues 列表](https://github.com/kubevela/kubevela/issues) 以及相应里程碑获取更多信息。
|
||||
135
sidebars.js
135
sidebars.js
|
|
@ -66,9 +66,16 @@ module.exports = {
|
|||
label: 'CI Integration',
|
||||
collapsed: true,
|
||||
items: [
|
||||
'how-to/dashboard/trigger/overview',
|
||||
'tutorials/jenkins',
|
||||
'tutorials/trigger',
|
||||
'how-to/dashboard/trigger/overview',
|
||||
],
|
||||
},
|
||||
{
|
||||
type: 'category',
|
||||
label: 'GitOps',
|
||||
collapsed: true,
|
||||
items: [
|
||||
'case-studies/gitops',
|
||||
],
|
||||
},
|
||||
|
|
@ -80,7 +87,6 @@ module.exports = {
|
|||
'end-user/version-control',
|
||||
'end-user/policies/apply-once',
|
||||
'end-user/policies/gc',
|
||||
'end-user/service-account-integration',
|
||||
],
|
||||
},
|
||||
'end-user/components/more',
|
||||
|
|
@ -97,10 +103,19 @@ module.exports = {
|
|||
'platform-engineers/system-operation/vela-cli-image',
|
||||
],
|
||||
},
|
||||
'tutorials/sso',
|
||||
'how-to/dashboard/user/user',
|
||||
'how-to/dashboard/user/rbac',
|
||||
{
|
||||
'User management': [
|
||||
'how-to/dashboard/user/user',
|
||||
'tutorials/sso',
|
||||
],
|
||||
},
|
||||
'how-to/dashboard/user/project',
|
||||
{
|
||||
'Authentication and Authorization': [
|
||||
'how-to/dashboard/user/rbac',
|
||||
'end-user/service-account-integration',
|
||||
],
|
||||
},
|
||||
{
|
||||
'Manage resource': [
|
||||
'platform-engineers/system-operation/managing-clusters',
|
||||
|
|
@ -116,51 +131,6 @@ module.exports = {
|
|||
'how-to/cli/addon/addon',
|
||||
'platform-engineers/system-operation/observability',
|
||||
'platform-engineers/system-operation/performance-finetuning',
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Extension',
|
||||
collapsed: true,
|
||||
items: [
|
||||
{
|
||||
'Learning CUE': [
|
||||
'platform-engineers/cue/basic',
|
||||
'platform-engineers/cue/definition-edit',
|
||||
'platform-engineers/cue/advanced',
|
||||
],
|
||||
},
|
||||
{
|
||||
Addons: ['platform-engineers/addon/intro'],
|
||||
},
|
||||
'platform-engineers/components/custom-component',
|
||||
{
|
||||
'Cloud Resources': [
|
||||
'platform-engineers/addon/terraform',
|
||||
'platform-engineers/components/component-terraform',
|
||||
],
|
||||
},
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Traits System',
|
||||
items: [
|
||||
'platform-engineers/traits/customize-trait',
|
||||
'platform-engineers/traits/patch-trait',
|
||||
'platform-engineers/traits/status',
|
||||
'platform-engineers/traits/advanced',
|
||||
],
|
||||
},
|
||||
{
|
||||
'Workflow System': [
|
||||
'platform-engineers/workflow/workflow',
|
||||
'platform-engineers/workflow/cue-actions',
|
||||
'platform-engineers/workflow/working-mechanism',
|
||||
],
|
||||
},
|
||||
'platform-engineers/system-operation/velaql',
|
||||
'platform-engineers/debug/dry-run',
|
||||
'platform-engineers/debug/debug',
|
||||
'platform-engineers/x-def-version',
|
||||
],
|
||||
},
|
||||
],
|
||||
},
|
||||
{
|
||||
|
|
@ -171,9 +141,61 @@ module.exports = {
|
|||
'contributor/overview',
|
||||
'contributor/non-code-contribute',
|
||||
'contributor/code-contribute',
|
||||
'contributor/release-process',
|
||||
'contributor/code-conventions',
|
||||
'contributor/principle-of-test',
|
||||
{
|
||||
'Conventions': [
|
||||
'contributor/release-process',
|
||||
'contributor/code-conventions',
|
||||
'contributor/principle-of-test',
|
||||
],
|
||||
},
|
||||
{
|
||||
'CUE in KubeVela': [
|
||||
'platform-engineers/cue/basic',
|
||||
'platform-engineers/cue/definition-edit',
|
||||
'platform-engineers/components/custom-component',
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Traits System',
|
||||
items: [
|
||||
'platform-engineers/traits/customize-trait',
|
||||
'platform-engineers/traits/patch-trait',
|
||||
'platform-engineers/traits/advanced',
|
||||
],
|
||||
},
|
||||
'platform-engineers/traits/status',
|
||||
{
|
||||
'Workflow System': [
|
||||
'platform-engineers/workflow/workflow',
|
||||
'platform-engineers/workflow/cue-actions',
|
||||
'platform-engineers/workflow/working-mechanism',
|
||||
],
|
||||
},
|
||||
{
|
||||
'Debugging': [
|
||||
'platform-engineers/debug/dry-run',
|
||||
'platform-engineers/debug/debug',
|
||||
],
|
||||
},
|
||||
'platform-engineers/system-operation/velaql',
|
||||
],
|
||||
},
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Contribute Extension',
|
||||
collapsed: true,
|
||||
items: [
|
||||
{
|
||||
Addons: ['platform-engineers/addon/intro'],
|
||||
},
|
||||
{
|
||||
'Cloud Resources': [
|
||||
'platform-engineers/addon/terraform',
|
||||
'platform-engineers/components/component-terraform',
|
||||
],
|
||||
},
|
||||
'platform-engineers/x-def-version',
|
||||
],
|
||||
},
|
||||
],
|
||||
},
|
||||
{
|
||||
|
|
@ -192,6 +214,7 @@ module.exports = {
|
|||
items: [
|
||||
'reference/addons/overview',
|
||||
'reference/addons/velaux',
|
||||
'reference/addons/fluxcd',
|
||||
'reference/addons/terraform',
|
||||
'reference/addons/ai',
|
||||
'reference/addons/traefik',
|
||||
|
|
@ -207,11 +230,7 @@ module.exports = {
|
|||
},
|
||||
],
|
||||
},
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Roadmap',
|
||||
items: ['roadmap/README'],
|
||||
},
|
||||
'roadmap/README',
|
||||
{
|
||||
type: 'doc',
|
||||
id: 'developers/references/devex/faq',
|
||||
|
|
|
|||
Loading…
Reference in New Issue