mirror of
https://github.com/kubevela/kubevela.git
synced 2026-02-24 14:54:06 +00:00
Compare commits
83 Commits
v1.0.3
...
release-1.
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
89d8e37c7c | ||
|
|
446f682f6c | ||
|
|
44e8352d1e | ||
|
|
5d9b3fbce6 | ||
|
|
6c0364453f | ||
|
|
2aa5b47e45 | ||
|
|
efa60a67a1 | ||
|
|
89b479e1bc | ||
|
|
d591d6ad64 | ||
|
|
916b3b52de | ||
|
|
df0eaaa74a | ||
|
|
2740067eb5 | ||
|
|
53b49aca53 | ||
|
|
b75de8aa94 | ||
|
|
2fc6971261 | ||
|
|
27a5630652 | ||
|
|
14334dd954 | ||
|
|
8948518d9f | ||
|
|
368dd687c2 | ||
|
|
34bee10bc3 | ||
|
|
d6aadacc9b | ||
|
|
ea738c119a | ||
|
|
7cf425969a | ||
|
|
b5cd647876 | ||
|
|
d2a28cbb8e | ||
|
|
a350a44982 | ||
|
|
e01ff21d30 | ||
|
|
2fdd33a80a | ||
|
|
7cee9cef98 | ||
|
|
01dfedfac2 | ||
|
|
a05a983a9a | ||
|
|
53b28d61a9 | ||
|
|
a8605a02f9 | ||
|
|
acb6f3ba04 | ||
|
|
0d264c16f7 | ||
|
|
675b0e24db | ||
|
|
7ed1c66578 | ||
|
|
5079659404 | ||
|
|
b3302b318c | ||
|
|
e1dfe40794 | ||
|
|
0571ae3a54 | ||
|
|
29744a6f18 | ||
|
|
fbd4565115 | ||
|
|
3543cb9b23 | ||
|
|
1d731b808a | ||
|
|
bba6e056a5 | ||
|
|
7787fe8e6a | ||
|
|
6a956f9343 | ||
|
|
b76a3f3f42 | ||
|
|
fd44069a21 | ||
|
|
cd8f31c4d8 | ||
|
|
f625877eb1 | ||
|
|
396f244af1 | ||
|
|
ed3e8d384a | ||
|
|
5f34a0c658 | ||
|
|
c40108f413 | ||
|
|
63855abed9 | ||
|
|
4dd00ac536 | ||
|
|
55b6ef1846 | ||
|
|
737b4dc2e4 | ||
|
|
60b8ec3ff2 | ||
|
|
fed2d13d98 | ||
|
|
85d6c77fad | ||
|
|
a488a24af4 | ||
|
|
00a4e4ca01 | ||
|
|
ef0888f256 | ||
|
|
0519c1ea8c | ||
|
|
467506c498 | ||
|
|
0ac7f02fc9 | ||
|
|
662a791e71 | ||
|
|
b726c5291f | ||
|
|
7377e17f8f | ||
|
|
1867436174 | ||
|
|
a3c97ecf31 | ||
|
|
4be93ad8b8 | ||
|
|
ee7dac354d | ||
|
|
21c631ac26 | ||
|
|
90f7d11787 | ||
|
|
b1ad5574b8 | ||
|
|
290b6c0815 | ||
|
|
b9a56aeb17 | ||
|
|
ba68e33e23 | ||
|
|
b3fd25cae1 |
1
.github/ISSUE_TEMPLATE/config.yaml
vendored
1
.github/ISSUE_TEMPLATE/config.yaml
vendored
@@ -1 +0,0 @@
|
||||
blank_issues_enabled: true
|
||||
5
.github/ISSUE_TEMPLATE/config.yml
vendored
Normal file
5
.github/ISSUE_TEMPLATE/config.yml
vendored
Normal file
@@ -0,0 +1,5 @@
|
||||
blank_issues_enabled: true
|
||||
contact_links:
|
||||
- name: Questions & Help
|
||||
url: https://github.com/oam-dev/kubevela/discussions
|
||||
about: Please ask and answer questions here.
|
||||
5
.github/workflows/check-docs.yml
vendored
5
.github/workflows/check-docs.yml
vendored
@@ -14,6 +14,11 @@ jobs:
|
||||
- uses: actions/setup-node@v1
|
||||
with:
|
||||
node-version: '12.x'
|
||||
- uses: actions/setup-python@v2
|
||||
with:
|
||||
python-version: '3.7'
|
||||
- name: Clean md files
|
||||
run: python ./hack/website/clean-md.py ./docs/en
|
||||
- name: Test Build
|
||||
env:
|
||||
VERSION: ${{ github.ref }}
|
||||
|
||||
28
.github/workflows/go.yml
vendored
28
.github/workflows/go.yml
vendored
@@ -149,7 +149,7 @@ jobs:
|
||||
- name: Setup Kind Cluster
|
||||
run: |
|
||||
kind delete cluster
|
||||
kind create cluster
|
||||
kind create cluster --image kindest/node:v1.18.15@sha256:5c1b980c4d0e0e8e7eb9f36f7df525d079a96169c8a8f20d8bd108c0d0889cc4
|
||||
kubectl version
|
||||
kubectl cluster-info
|
||||
|
||||
@@ -179,6 +179,20 @@ jobs:
|
||||
- name: Run e2e tests
|
||||
run: make e2e-test
|
||||
|
||||
- name: Stop kubevela, get profile
|
||||
run: make end-e2e
|
||||
|
||||
- name: Upload coverage report
|
||||
uses: codecov/codecov-action@v1
|
||||
with:
|
||||
token: ${{ secrets.CODECOV_TOKEN }}
|
||||
file: /tmp/e2e-profile.out
|
||||
flags: e2etests
|
||||
name: codecov-umbrella
|
||||
|
||||
- name: Clean e2e profile
|
||||
run: rm /tmp/e2e-profile.out
|
||||
|
||||
- name: Cleanup image
|
||||
if: ${{ always() }}
|
||||
run: make image-cleanup
|
||||
@@ -189,6 +203,11 @@ jobs:
|
||||
if: needs.detect-noop.outputs.noop != 'true'
|
||||
|
||||
steps:
|
||||
- name: Setup Go
|
||||
uses: actions/setup-go@v2
|
||||
with:
|
||||
go-version: ${{ env.GO_VERSION }}
|
||||
|
||||
- name: Checkout
|
||||
uses: actions/checkout@v2
|
||||
with:
|
||||
@@ -201,8 +220,11 @@ jobs:
|
||||
key: ${{ runner.os }}-pkg-${{ hashFiles('**/go.sum') }}
|
||||
restore-keys: ${{ runner.os }}-pkg-
|
||||
|
||||
- name: Install StaticCheck
|
||||
run: GO111MODULE=off go get honnef.co/go/tools/cmd/staticcheck
|
||||
|
||||
- name: Static Check
|
||||
run: go run honnef.co/go/tools/cmd/staticcheck -- ./...
|
||||
run: staticcheck ./...
|
||||
|
||||
- name: License Header Check
|
||||
run: make check-license-header
|
||||
@@ -279,4 +301,4 @@ jobs:
|
||||
- name: Run cross-build
|
||||
run: make cross-build
|
||||
- name: Run compress binary
|
||||
run: make compress
|
||||
run: make compress
|
||||
|
||||
2
.github/workflows/registry.yml
vendored
2
.github/workflows/registry.yml
vendored
@@ -37,7 +37,7 @@ jobs:
|
||||
with:
|
||||
registry: ghcr.io
|
||||
username: ${{ github.repository_owner }}
|
||||
password: ${{ secrets.CR_PAT }}
|
||||
password: ${{ secrets.GITHUB_TOKEN }}
|
||||
- name: Login docker.io
|
||||
uses: docker/login-action@v1
|
||||
with:
|
||||
|
||||
5
.github/workflows/release-docs.yaml
vendored
5
.github/workflows/release-docs.yaml
vendored
@@ -14,6 +14,11 @@ jobs:
|
||||
- uses: actions/setup-node@v1
|
||||
with:
|
||||
node-version: '12.x'
|
||||
- uses: actions/setup-python@v2
|
||||
with:
|
||||
python-version: '3.7'
|
||||
- name: Clean md files
|
||||
run: python ./hack/website/clean-md.py ./docs/en
|
||||
- name: Sync to kubevela.io Repo
|
||||
env:
|
||||
SSH_DEPLOY_KEY: ${{ secrets.GH_PAGES_DEPLOY }}
|
||||
|
||||
4
.github/workflows/release.yml
vendored
4
.github/workflows/release.yml
vendored
@@ -134,4 +134,6 @@ jobs:
|
||||
VERSION: ${{ steps.get_version.outputs.VERSION }}
|
||||
COMMIT_ID: ${{ github.sha }}
|
||||
run: |
|
||||
bash ./hack/website/release.sh
|
||||
bash ./hack/website/release.sh
|
||||
- name: Update kubectl plugin version in krew-index
|
||||
uses: rajatjindal/krew-release-bot@v0.0.38
|
||||
36
.github/workflows/sync-api.yml
vendored
Normal file
36
.github/workflows/sync-api.yml
vendored
Normal file
@@ -0,0 +1,36 @@
|
||||
name: sync-api
|
||||
on:
|
||||
push:
|
||||
paths:
|
||||
- 'apis/**'
|
||||
- 'pkg/oam/**'
|
||||
tags:
|
||||
- "v*"
|
||||
|
||||
jobs:
|
||||
sync-core-api:
|
||||
runs-on: ubuntu-20.04
|
||||
steps:
|
||||
- name: Set up Go 1.14
|
||||
uses: actions/setup-go@v1
|
||||
env:
|
||||
GO_VERSION: '1.14'
|
||||
GOLANGCI_VERSION: 'v1.38'
|
||||
with:
|
||||
go-version: ${{ env.GO_VERSION }}
|
||||
id: go
|
||||
|
||||
- name: Check out code into the Go module directory
|
||||
uses: actions/checkout@v2
|
||||
|
||||
- name: Get the version
|
||||
id: get_version
|
||||
run: echo ::set-output name=VERSION::${GITHUB_REF#refs/tags/}
|
||||
|
||||
- name: Sync to kubevela-core-api Repo
|
||||
env:
|
||||
SSH_DEPLOY_KEY: ${{ secrets.VELA_API_DEPLOY }}
|
||||
VERSION: ${{ steps.get_version.outputs.VERSION }}
|
||||
COMMIT_ID: ${{ github.sha }}
|
||||
run: |
|
||||
bash ./hack/apis/sync.sh
|
||||
47
.krew.yaml
Normal file
47
.krew.yaml
Normal file
@@ -0,0 +1,47 @@
|
||||
apiVersion: krew.googlecontainertools.github.com/v1alpha2
|
||||
kind: Plugin
|
||||
metadata:
|
||||
name: vela
|
||||
spec:
|
||||
version: "{{ .TagName }}"
|
||||
platforms:
|
||||
- selector:
|
||||
matchLabels:
|
||||
os: linux
|
||||
arch: amd64
|
||||
{{addURIAndSha "https://github.com/oam-dev/kubevela/releases/download/{{ .TagName }}/kubectl-vela-{{ .TagName }}-linux-amd64.tar.gz" .TagName }}
|
||||
files:
|
||||
- from: "*/kubectl-vela"
|
||||
to: "."
|
||||
- from: "*/LICENSE"
|
||||
to: "."
|
||||
bin: "kubectl-vela"
|
||||
- selector:
|
||||
matchLabels:
|
||||
os: darwin
|
||||
arch: amd64
|
||||
{{addURIAndSha "https://github.com/oam-dev/kubevela/releases/download/{{ .TagName }}/kubectl-vela-{{ .TagName }}-darwin-amd64.tar.gz" .TagName }}
|
||||
files:
|
||||
- from: "*/kubectl-vela"
|
||||
to: "."
|
||||
- from: "*/LICENSE"
|
||||
to: "."
|
||||
bin: "kubectl-vela"
|
||||
- selector:
|
||||
matchLabels:
|
||||
os: windows
|
||||
arch: amd64
|
||||
{{addURIAndSha "https://github.com/oam-dev/kubevela/releases/download/{{ .TagName }}/kubectl-vela-{{ .TagName }}-windows-amd64.zip" .TagName }}
|
||||
files:
|
||||
- from: "*/kubectl-vela.exe"
|
||||
to: "."
|
||||
- from: "*/LICENSE"
|
||||
to: "."
|
||||
bin: "kubectl-vela.exe"
|
||||
shortDescription: Easily interact with KubeVela
|
||||
homepage: https://kubevela.io
|
||||
description: |
|
||||
kubectl vela is a kubectl plugin from the KubeVela project. KubeVela is
|
||||
a modern application platform that is fully self-service, and adapts to
|
||||
your needs when you grow. This plugin allows you to better view, manage
|
||||
and maintain KubeVela applications.
|
||||
@@ -109,8 +109,45 @@ Start to test.
|
||||
```
|
||||
make e2e-test
|
||||
```
|
||||
## Logging Conventions
|
||||
|
||||
### Contribute Docs
|
||||
|
||||
### Structured logging
|
||||
|
||||
We recommend using `klog.InfoS` to structure the log. The `msg` argument need start from a capital letter.
|
||||
and name arguments should always use lowerCamelCase.
|
||||
|
||||
```golang
|
||||
// func InfoS(msg string, keysAndValues ...interface{})
|
||||
klog.InfoS("Reconcile traitDefinition", "traitDefinition", klog.KRef(req.Namespace, req.Name))
|
||||
// output:
|
||||
// I0605 10:10:57.308074 22276 traitdefinition_controller.go:59] "Reconcile traitDefinition" traitDefinition="vela-system/expose"
|
||||
```
|
||||
|
||||
### Use `klog.KObj` and `klog.KRef` for Kubernetes objects
|
||||
|
||||
`klog.KObj` and `klog.KRef` can unify the output of kubernetes object.
|
||||
|
||||
```golang
|
||||
// KObj is used to create ObjectRef when logging information about Kubernetes objects
|
||||
klog.InfoS("Start to reconcile", "appDeployment", klog.KObj(appDeployment))
|
||||
// KRef is used to create ObjectRef when logging information about Kubernetes objects without access to metav1.Object
|
||||
klog.InfoS("Reconcile application", "application", klog.KRef(req.Namespace, req.Name))
|
||||
```
|
||||
|
||||
### Logging Level
|
||||
|
||||
[This file](https://github.com/oam-dev/kubevela/blob/master/pkg/controller/common/logs.go) contains KubeVela's log level,
|
||||
you can set the log level by `klog.V(level)`.
|
||||
|
||||
```golang
|
||||
// you can use klog.V(common.LogDebug) to print debug log
|
||||
klog.V(common.LogDebug).InfoS("Successfully applied components", "workloads", len(workloads))
|
||||
```
|
||||
|
||||
more detail in [Structured Logging Guide](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/migration-to-structured-logging.md#structured-logging-in-kubernetes).
|
||||
|
||||
## Contribute Docs
|
||||
|
||||
Please read [the documentation](https://github.com/oam-dev/kubevela/tree/master/docs/README.md) before contributing to the docs.
|
||||
|
||||
|
||||
48
Dockerfile.e2e
Normal file
48
Dockerfile.e2e
Normal file
@@ -0,0 +1,48 @@
|
||||
# Build the manager binary
|
||||
FROM --platform=${BUILDPLATFORM:-linux/amd64} golang:1.14-alpine as builder
|
||||
|
||||
WORKDIR /workspace
|
||||
# Copy the Go Modules manifests
|
||||
COPY go.mod go.mod
|
||||
COPY go.sum go.sum
|
||||
# cache deps before building and copying source so that we don't need to re-download as much
|
||||
# and so that source changes don't invalidate our downloaded layer
|
||||
RUN go mod download
|
||||
|
||||
# Copy the go source
|
||||
COPY cmd/core/main.go main.go
|
||||
COPY cmd/core/main_e2e_test.go main_e2e_test.go
|
||||
COPY cmd/ cmd/
|
||||
COPY apis/ apis/
|
||||
COPY pkg/ pkg/
|
||||
COPY version/ version/
|
||||
|
||||
# Build
|
||||
ARG TARGETARCH
|
||||
ARG VERSION
|
||||
ARG GITVERSION
|
||||
|
||||
RUN apk add gcc musl-dev libc-dev ;\
|
||||
go test -c -o manager-${TARGETARCH} -cover -covermode=atomic -coverpkg ./... .
|
||||
|
||||
# Use alpine as base image due to the discussion in issue #1448
|
||||
# You can replace distroless as minimal base image to package the manager binary
|
||||
# Refer to https://github.com/GoogleContainerTools/distroless for more details
|
||||
# Overwrite `BASE_IMAGE` by passing `--build-arg=BASE_IMAGE=gcr.io/distroless/static:nonroot`
|
||||
ARG BASE_IMAGE
|
||||
FROM ${BASE_IMAGE:-alpine:latest}
|
||||
# This is required by daemon connnecting with cri
|
||||
RUN apk add --no-cache ca-certificates bash
|
||||
|
||||
WORKDIR /
|
||||
|
||||
ARG TARGETARCH
|
||||
COPY --from=builder /workspace/manager-${TARGETARCH} /usr/local/bin/manager
|
||||
|
||||
COPY entrypoint.sh /usr/local/bin/
|
||||
|
||||
VOLUME ["/workspace/data"]
|
||||
|
||||
ENTRYPOINT ["entrypoint.sh"]
|
||||
|
||||
CMD ["manager"]
|
||||
9
Makefile
9
Makefile
@@ -65,7 +65,6 @@ dashboard-build:
|
||||
doc-gen:
|
||||
rm -r docs/en/cli/*
|
||||
go run hack/docgen/gen.go
|
||||
go run hack/references/generate.go
|
||||
|
||||
docs-build:
|
||||
ifneq ($(wildcard git-page),)
|
||||
@@ -156,7 +155,8 @@ docker-push:
|
||||
e2e-setup:
|
||||
helm install --create-namespace -n flux-system helm-flux http://oam.dev/catalog/helm-flux2-0.1.0.tgz
|
||||
helm install kruise https://github.com/openkruise/kruise/releases/download/v0.7.0/kruise-chart.tgz
|
||||
helm upgrade --install --create-namespace --namespace vela-system --set image.pullPolicy=IfNotPresent --set image.repository=vela-core-test --set applicationRevisionLimit=5 --set image.tag=$(GIT_COMMIT) --wait kubevela ./charts/vela-core
|
||||
sh ./hack/e2e/modify_charts.sh
|
||||
helm upgrade --install --create-namespace --namespace vela-system --set image.pullPolicy=IfNotPresent --set image.repository=vela-core-test --set applicationRevisionLimit=5 --set dependCheckWait=10s --set image.tag=$(GIT_COMMIT) --wait kubevela ./charts/vela-core
|
||||
ginkgo version
|
||||
ginkgo -v -r e2e/setup
|
||||
kubectl wait --for=condition=Ready pod -l app.kubernetes.io/name=vela-core,app.kubernetes.io/instance=kubevela -n vela-system --timeout=600s
|
||||
@@ -197,9 +197,12 @@ ifneq ($(shell docker images -q $(VELA_CORE_TEST_IMAGE)),)
|
||||
docker rmi -f $(VELA_CORE_TEST_IMAGE)
|
||||
endif
|
||||
|
||||
end-e2e:
|
||||
sh ./hack/e2e/end_e2e.sh
|
||||
|
||||
# load docker image to the kind cluster
|
||||
kind-load:
|
||||
docker build -t $(VELA_CORE_TEST_IMAGE) .
|
||||
docker build -t $(VELA_CORE_TEST_IMAGE) -f Dockerfile.e2e .
|
||||
kind load docker-image $(VELA_CORE_TEST_IMAGE) || { echo >&2 "kind not installed or error loading image: $(VELA_CORE_TEST_IMAGE)"; exit 1; }
|
||||
|
||||
# Run tests
|
||||
|
||||
59
README.md
59
README.md
@@ -8,59 +8,44 @@
|
||||
[](https://twitter.com/oam_dev)
|
||||
[](https://artifacthub.io/packages/search?repo=kubevela)
|
||||
|
||||

|
||||

|
||||
|
||||
*Make shipping applications more enjoyable.*
|
||||
|
||||
# KubeVela
|
||||
|
||||
KubeVela is a modern application engine that adapts to your application's needs, not the other way around.
|
||||
|
||||
## Community
|
||||
|
||||
- Slack: [CNCF Slack](https://slack.cncf.io/) #kubevela channel
|
||||
- Gitter: [Discussion](https://gitter.im/oam-dev/community)
|
||||
- Bi-weekly Community Call: [Meeting Notes](https://docs.google.com/document/d/1nqdFEyULekyksFHtFvgvFAYE-0AMHKoS3RMnaKsarjs)
|
||||
|
||||
## Introduction
|
||||
|
||||
*Developers simply want to deploy.*
|
||||
|
||||
Traditional Platform-as-a-Service (PaaS) systems enable easy application deployments, but this happiness disappears when your application outgrows the capabilities of your platform. This is inevitable regardless of your PaaS is built on Kubernetes or not - the root cause is its inflexibility.
|
||||
|
||||
KubeVela is a modern application deployment system that adapts to your needs. Essentially, KubeVela enables you to define platform capabilities (such as workloads, operational behaviors, and cloud services) as reusable [CUE](https://cuelang.org/) or [Helm](https://helm.sh) components, per needs of your application deployment. And when your needs grow, your platform capabilities expand naturally in a programmable approach.
|
||||
|
||||
Perfect in flexibility though, X-as-Code tends to lead to configuration drift. That's why KubeVela is fully built as a [Kubernetes Controller](https://kubernetes.io/docs/concepts/architecture/controller/) instead of a client-side tool, i.e. all its capabilities are modeled as code but enforced with battle tested reconciling loops which will never leave inconsistency in your clusters. Think about *Platform-as-Code* enabled by Kubernetes, CUE and Helm.
|
||||
|
||||
With developer experience in mind, KubeVela exposes those programmable platform capabilities as application-centric API shown as below:
|
||||
- Components - deployable/provisionable entities that composed your application deployment
|
||||
- e.g. a Kubernetes workload, a MySQL database, or a AWS OSS bucket
|
||||
- Traits - attachable operational features per your needs
|
||||
- e.g. autoscaling rules, rollout strategies, ingress rules, sidecars, security policies etc
|
||||
- Application - full description of your application deployment assembled with components and traits.
|
||||
|
||||
## Getting Started
|
||||
|
||||
- [Installation](https://kubevela.io/docs/install)
|
||||
- [Quick start](https://kubevela.io/docs/quick-start)
|
||||
- [How it works](https://kubevela.io/docs/concepts)
|
||||
KubeVela is a modern application platform that makes deploying and managing applications across today's hybrid, multi-cloud environments easier and faster.
|
||||
|
||||
## Features
|
||||
|
||||
- **Zero-restriction application deployment system** - design and express platform capabilities with CUE and Helm per needs of your application, and let Kubernetes controller guarantee the determinism in the application deployment. GUI forms are automatically generated for capabilities so even your dashboard are fully extensible.
|
||||
- **Generic progressive rollout framework** - built-in rollout framework and strategies to upgrade your microservice regardless of its workload type (e.g. stateless, stateful, or even custom operators etc).
|
||||
- **Multi-cluster multi-revision application deployment** - built-in model to deploy or rollout your apps across hybrid infrastructures, with Service Mesh for traffic shifting.
|
||||
- **Simple and native** - KubeVela is a just simple Kubernetes custom controller, all its capabilities are defined as [Custom Resources](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) so they naturally work with any CI/CD or GitOps tools which work with Kubernetes.
|
||||
**Application Centric** - Leveraging Open Application Model (OAM), KubeVela introduces consistent yet higher level API to capture a full deployment of microservices on top of hybrid environments. Placement strategy and patch, traffic shifting and rolling update are all declared at application level. No infrastructure level concern, simply deploy.
|
||||
|
||||
**Natively Extensible** - KubeVela uses [CUE](https://github.com/cuelang/cue) to glue capabilities (e.g. workload types, operational behaviors, and cloud services) provided by runtime infrastructure and expose them to users via self-service API. When users' needs grow, these API can naturally expand in programmable approach. No restriction, fully flexible.
|
||||
|
||||
**Runtime Agnostic** - KubeVela is built with Kubernetes as control plane but adaptable to any runtime as data-plane. It can deploy (and manage) diverse workload types such as container, cloud functions, databases, or even EC2 instances across hybrid environments. Also, this means KubeVela seamlessly works with any Kubernetes compatible CI/CD or GitOps tools via declarative API.
|
||||
|
||||
## Getting Started
|
||||
|
||||
- [Introduction](https://kubevela.io/docs)
|
||||
- [Installation](https://kubevela.io/docs/install)
|
||||
- [Deploy an Application](https://kubevela.io/docs/application)
|
||||
|
||||
## Documentation
|
||||
|
||||
Visit the [KubeVela documentation site](https://kubevela.io/) to find *Installation Instruction*, *Platform Builder Guide* and *Developer Experience Guide*.
|
||||
Full documentation is available on the [KubeVela website](https://kubevela.io/).
|
||||
|
||||
## Community
|
||||
|
||||
- Slack: [CNCF Slack](https://slack.cncf.io/) #kubevela channel (*English*)
|
||||
- Gitter: [oam-dev](https://gitter.im/oam-dev/community) (*English*)
|
||||
- [DingTalk Group](https://page.dingtalk.com/wow/dingtalk/act/en-home): `23310022` (*Chinese*)
|
||||
- Bi-weekly Community Call: [Meeting Notes](https://docs.google.com/document/d/1nqdFEyULekyksFHtFvgvFAYE-0AMHKoS3RMnaKsarjs)
|
||||
|
||||
## Talks and Conferences
|
||||
|
||||
| Engagement | Link |
|
||||
|:-----------|:------------|
|
||||
| 🎤 Talks | - [KubeVela - The Modern App Delivery System in Alibaba](https://docs.google.com/presentation/d/1CWCLcsKpDQB3bBDTfdv2BZ8ilGGJv2E8L-iOA5HMrV0/edit?usp=sharing) |
|
||||
| 🎤 Talks | - [KubeVela - The Modern App Delivery System in Alibaba](https://docs.google.com/presentation/d/1CWCLcsKpDQB3bBDTfdv2BZ8ilGGJv2E8L-iOA5HMrV0/edit?usp=sharing) <br> - [Cloud-Native Apps With Open Application Model (OAM) And KubeVela](https://www.youtube.com/watch?v=2CBu6sOTtwk) |
|
||||
| 🌎 KubeCon | - [ [NA 2020] Standardizing Cloud Native Application Delivery Across Different Clouds](https://www.youtube.com/watch?v=0yhVuBIbHcI) <br> - [ [EU 2021] Zero Pain Microservice Development and Deployment with Dapr and KubeVela](https://sched.co/iE4S) |
|
||||
| 📺 Conferences | - [Dapr, Rudr, OAM: Mark Russinovich presents next gen app development & deployment](https://www.youtube.com/watch?v=eJCu6a-x9uo) <br> - [Mark Russinovich presents "The Future of Cloud Native Applications with OAM and Dapr"](https://myignite.techcommunity.microsoft.com/sessions/82059)|
|
||||
|
||||
|
||||
@@ -17,7 +17,7 @@ limitations under the License.
|
||||
package common
|
||||
|
||||
import (
|
||||
v1alpha12 "github.com/crossplane/crossplane-runtime/apis/core/v1alpha1"
|
||||
runtimev1alpha1 "github.com/crossplane/crossplane-runtime/apis/core/v1alpha1"
|
||||
"k8s.io/apimachinery/pkg/runtime"
|
||||
|
||||
"github.com/oam-dev/kubevela/apis/standard.oam.dev/v1alpha1"
|
||||
@@ -84,7 +84,7 @@ type Schematic struct {
|
||||
|
||||
HELM *Helm `json:"helm,omitempty"`
|
||||
|
||||
// TODO(wonderflow): support HCL(terraform)here.
|
||||
Terraform *Terraform `json:"terraform,omitempty"`
|
||||
}
|
||||
|
||||
// A Helm represents resources used by a Helm module
|
||||
@@ -98,6 +98,17 @@ type Helm struct {
|
||||
Repository runtime.RawExtension `json:"repository"`
|
||||
}
|
||||
|
||||
// Terraform is the struct to describe cloud resources managed by Hashicorp Terraform
|
||||
type Terraform struct {
|
||||
// Configuration is Terraform Configuration
|
||||
Configuration string `json:"configuration"`
|
||||
|
||||
// Type specifies which Terraform configuration it is, HCL or JSON syntax
|
||||
// +kubebuilder:default:=hcl
|
||||
// +kubebuilder:validation:Enum:=hcl;json
|
||||
Type string `json:"type,omitempty"`
|
||||
}
|
||||
|
||||
// A WorkloadTypeDescriptor refer to a Workload Type
|
||||
type WorkloadTypeDescriptor struct {
|
||||
// Type ref to a WorkloadDefinition via name
|
||||
@@ -162,10 +173,11 @@ const (
|
||||
type ApplicationComponentStatus struct {
|
||||
Name string `json:"name"`
|
||||
// WorkloadDefinition is the definition of a WorkloadDefinition, such as deployments/apps.v1
|
||||
WorkloadDefinition WorkloadGVK `json:"workloadDefinition,omitempty"`
|
||||
Healthy bool `json:"healthy"`
|
||||
Message string `json:"message,omitempty"`
|
||||
Traits []ApplicationTraitStatus `json:"traits,omitempty"`
|
||||
WorkloadDefinition WorkloadGVK `json:"workloadDefinition,omitempty"`
|
||||
Healthy bool `json:"healthy"`
|
||||
Message string `json:"message,omitempty"`
|
||||
Traits []ApplicationTraitStatus `json:"traits,omitempty"`
|
||||
Scopes []runtimev1alpha1.TypedReference `json:"scopes,omitempty"`
|
||||
}
|
||||
|
||||
// ApplicationTraitStatus records the trait health status
|
||||
@@ -195,20 +207,47 @@ type RawComponent struct {
|
||||
type AppStatus struct {
|
||||
// INSERT ADDITIONAL STATUS FIELD - define observed state of cluster
|
||||
// Important: Run "make" to regenerate code after modifying this file
|
||||
v1alpha1.RolloutStatus `json:",inline"`
|
||||
runtimev1alpha1.ConditionedStatus `json:",inline"`
|
||||
|
||||
Rollout AppRolloutStatus `json:"rollout,omitempty"`
|
||||
|
||||
Phase ApplicationPhase `json:"status,omitempty"`
|
||||
|
||||
// Components record the related Components created by Application Controller
|
||||
Components []v1alpha12.TypedReference `json:"components,omitempty"`
|
||||
Components []runtimev1alpha1.TypedReference `json:"components,omitempty"`
|
||||
|
||||
// Services record the status of the application services
|
||||
Services []ApplicationComponentStatus `json:"services,omitempty"`
|
||||
|
||||
// ResourceTracker record the status of the ResourceTracker
|
||||
ResourceTracker *v1alpha12.TypedReference `json:"resourceTracker,omitempty"`
|
||||
ResourceTracker *runtimev1alpha1.TypedReference `json:"resourceTracker,omitempty"`
|
||||
|
||||
// LatestRevision of the application configuration it generates
|
||||
// +optional
|
||||
LatestRevision *Revision `json:"latestRevision,omitempty"`
|
||||
}
|
||||
|
||||
// DefinitionType describes the type of DefinitionRevision.
|
||||
// +kubebuilder:validation:Enum=Component;Trait
|
||||
type DefinitionType string
|
||||
|
||||
const (
|
||||
// ComponentType represents DefinitionRevision refer to type ComponentDefinition
|
||||
ComponentType DefinitionType = "Component"
|
||||
|
||||
// TraitType represents DefinitionRevision refer to type TraitDefinition
|
||||
TraitType DefinitionType = "Trait"
|
||||
)
|
||||
|
||||
// AppRolloutStatus defines the observed state of AppRollout
|
||||
type AppRolloutStatus struct {
|
||||
v1alpha1.RolloutStatus `json:",inline"`
|
||||
|
||||
// LastUpgradedTargetAppRevision contains the name of the app that we upgraded to
|
||||
// We will restart the rollout if this is not the same as the spec
|
||||
LastUpgradedTargetAppRevision string `json:"lastTargetAppRevision"`
|
||||
|
||||
// LastSourceAppRevision contains the name of the app that we need to upgrade from.
|
||||
// We will restart the rollout if this is not the same as the spec
|
||||
LastSourceAppRevision string `json:"LastSourceAppRevision,omitempty"`
|
||||
}
|
||||
|
||||
@@ -25,9 +25,26 @@ import (
|
||||
)
|
||||
|
||||
// DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
|
||||
func (in *AppStatus) DeepCopyInto(out *AppStatus) {
|
||||
func (in *AppRolloutStatus) DeepCopyInto(out *AppRolloutStatus) {
|
||||
*out = *in
|
||||
in.RolloutStatus.DeepCopyInto(&out.RolloutStatus)
|
||||
}
|
||||
|
||||
// DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new AppRolloutStatus.
|
||||
func (in *AppRolloutStatus) DeepCopy() *AppRolloutStatus {
|
||||
if in == nil {
|
||||
return nil
|
||||
}
|
||||
out := new(AppRolloutStatus)
|
||||
in.DeepCopyInto(out)
|
||||
return out
|
||||
}
|
||||
|
||||
// DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
|
||||
func (in *AppStatus) DeepCopyInto(out *AppStatus) {
|
||||
*out = *in
|
||||
in.ConditionedStatus.DeepCopyInto(&out.ConditionedStatus)
|
||||
in.Rollout.DeepCopyInto(&out.Rollout)
|
||||
if in.Components != nil {
|
||||
in, out := &in.Components, &out.Components
|
||||
*out = make([]v1alpha1.TypedReference, len(*in))
|
||||
@@ -71,6 +88,11 @@ func (in *ApplicationComponentStatus) DeepCopyInto(out *ApplicationComponentStat
|
||||
*out = make([]ApplicationTraitStatus, len(*in))
|
||||
copy(*out, *in)
|
||||
}
|
||||
if in.Scopes != nil {
|
||||
in, out := &in.Scopes, &out.Scopes
|
||||
*out = make([]v1alpha1.TypedReference, len(*in))
|
||||
copy(*out, *in)
|
||||
}
|
||||
}
|
||||
|
||||
// DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new ApplicationComponentStatus.
|
||||
@@ -269,6 +291,11 @@ func (in *Schematic) DeepCopyInto(out *Schematic) {
|
||||
*out = new(Helm)
|
||||
(*in).DeepCopyInto(*out)
|
||||
}
|
||||
if in.Terraform != nil {
|
||||
in, out := &in.Terraform, &out.Terraform
|
||||
*out = new(Terraform)
|
||||
**out = **in
|
||||
}
|
||||
}
|
||||
|
||||
// DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new Schematic.
|
||||
@@ -296,6 +323,21 @@ func (in *Status) DeepCopy() *Status {
|
||||
return out
|
||||
}
|
||||
|
||||
// DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
|
||||
func (in *Terraform) DeepCopyInto(out *Terraform) {
|
||||
*out = *in
|
||||
}
|
||||
|
||||
// DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new Terraform.
|
||||
func (in *Terraform) DeepCopy() *Terraform {
|
||||
if in == nil {
|
||||
return nil
|
||||
}
|
||||
out := new(Terraform)
|
||||
in.DeepCopyInto(out)
|
||||
return out
|
||||
}
|
||||
|
||||
// DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
|
||||
func (in *WorkloadGVK) DeepCopyInto(out *WorkloadGVK) {
|
||||
*out = *in
|
||||
|
||||
@@ -62,6 +62,9 @@ type ComponentDefinitionStatus struct {
|
||||
runtimev1alpha1.ConditionedStatus `json:",inline"`
|
||||
// ConfigMapRef refer to a ConfigMap which contains OpenAPI V3 JSON schema of Component parameters.
|
||||
ConfigMapRef string `json:"configMapRef,omitempty"`
|
||||
// LatestRevision of the component definition
|
||||
// +optional
|
||||
LatestRevision *common.Revision `json:"latestRevision,omitempty"`
|
||||
}
|
||||
|
||||
// +kubebuilder:object:root=true
|
||||
|
||||
@@ -154,6 +154,9 @@ type TraitDefinitionStatus struct {
|
||||
runtimev1alpha1.ConditionedStatus `json:",inline"`
|
||||
// ConfigMapRef refer to a ConfigMap which contains OpenAPI V3 JSON schema of Component parameters.
|
||||
ConfigMapRef string `json:"configMapRef,omitempty"`
|
||||
// LatestRevision of the trait definition
|
||||
// +optional
|
||||
LatestRevision *common.Revision `json:"latestRevision,omitempty"`
|
||||
}
|
||||
|
||||
// +kubebuilder:object:root=true
|
||||
|
||||
@@ -782,6 +782,11 @@ func (in *ComponentDefinitionSpec) DeepCopy() *ComponentDefinitionSpec {
|
||||
func (in *ComponentDefinitionStatus) DeepCopyInto(out *ComponentDefinitionStatus) {
|
||||
*out = *in
|
||||
in.ConditionedStatus.DeepCopyInto(&out.ConditionedStatus)
|
||||
if in.LatestRevision != nil {
|
||||
in, out := &in.LatestRevision, &out.LatestRevision
|
||||
*out = new(common.Revision)
|
||||
**out = **in
|
||||
}
|
||||
}
|
||||
|
||||
// DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new ComponentDefinitionStatus.
|
||||
@@ -2067,6 +2072,11 @@ func (in *TraitDefinitionSpec) DeepCopy() *TraitDefinitionSpec {
|
||||
func (in *TraitDefinitionStatus) DeepCopyInto(out *TraitDefinitionStatus) {
|
||||
*out = *in
|
||||
in.ConditionedStatus.DeepCopyInto(&out.ConditionedStatus)
|
||||
if in.LatestRevision != nil {
|
||||
in, out := &in.LatestRevision, &out.LatestRevision
|
||||
*out = new(common.Revision)
|
||||
**out = **in
|
||||
}
|
||||
}
|
||||
|
||||
// DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new TraitDefinitionStatus.
|
||||
|
||||
@@ -19,6 +19,7 @@ package v1beta1
|
||||
import (
|
||||
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
|
||||
|
||||
"github.com/oam-dev/kubevela/apis/core.oam.dev/common"
|
||||
"github.com/oam-dev/kubevela/apis/standard.oam.dev/v1alpha1"
|
||||
)
|
||||
|
||||
@@ -48,19 +49,6 @@ type AppRolloutSpec struct {
|
||||
RevertOnDelete bool `json:"revertOnDelete,omitempty"`
|
||||
}
|
||||
|
||||
// AppRolloutStatus defines the observed state of AppRollout
|
||||
type AppRolloutStatus struct {
|
||||
v1alpha1.RolloutStatus `json:",inline"`
|
||||
|
||||
// LastUpgradedTargetAppRevision contains the name of the app that we upgraded to
|
||||
// We will restart the rollout if this is not the same as the spec
|
||||
LastUpgradedTargetAppRevision string `json:"lastTargetAppRevision"`
|
||||
|
||||
// LastSourceAppRevision contains the name of the app that we need to upgrade from.
|
||||
// We will restart the rollout if this is not the same as the spec
|
||||
LastSourceAppRevision string `json:"LastSourceAppRevision,omitempty"`
|
||||
}
|
||||
|
||||
// AppRollout is the Schema for the AppRollout API
|
||||
// +kubebuilder:object:root=true
|
||||
// +kubebuilder:resource:categories={oam},shortName=approllout
|
||||
@@ -76,8 +64,8 @@ type AppRollout struct {
|
||||
metav1.TypeMeta `json:",inline"`
|
||||
metav1.ObjectMeta `json:"metadata,omitempty"`
|
||||
|
||||
Spec AppRolloutSpec `json:"spec,omitempty"`
|
||||
Status AppRolloutStatus `json:"status,omitempty"`
|
||||
Spec AppRolloutSpec `json:"spec,omitempty"`
|
||||
Status common.AppRolloutStatus `json:"status,omitempty"`
|
||||
}
|
||||
|
||||
// AppRolloutList contains a list of AppRollout
|
||||
|
||||
@@ -62,6 +62,9 @@ type ComponentDefinitionStatus struct {
|
||||
runtimev1alpha1.ConditionedStatus `json:",inline"`
|
||||
// ConfigMapRef refer to a ConfigMap which contains OpenAPI V3 JSON schema of Component parameters.
|
||||
ConfigMapRef string `json:"configMapRef,omitempty"`
|
||||
// LatestRevision of the component definition
|
||||
// +optional
|
||||
LatestRevision *common.Revision `json:"latestRevision,omitempty"`
|
||||
}
|
||||
|
||||
// +kubebuilder:object:root=true
|
||||
|
||||
@@ -155,6 +155,9 @@ type TraitDefinitionStatus struct {
|
||||
runtimev1alpha1.ConditionedStatus `json:",inline"`
|
||||
// ConfigMapRef refer to a ConfigMap which contains OpenAPI V3 JSON schema of Component parameters.
|
||||
ConfigMapRef string `json:"configMapRef,omitempty"`
|
||||
// LatestRevision of the component definition
|
||||
// +optional
|
||||
LatestRevision *common.Revision `json:"latestRevision,omitempty"`
|
||||
}
|
||||
|
||||
// +kubebuilder:object:root=true
|
||||
|
||||
64
apis/core.oam.dev/v1beta1/definitionrevision_types.go
Normal file
64
apis/core.oam.dev/v1beta1/definitionrevision_types.go
Normal file
@@ -0,0 +1,64 @@
|
||||
/*
|
||||
Copyright 2021. The KubeVela Authors.
|
||||
|
||||
Licensed under the Apache License, Version 2.0 (the "License");
|
||||
you may not use this file except in compliance with the License.
|
||||
You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing, software
|
||||
distributed under the License is distributed on an "AS IS" BASIS,
|
||||
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
||||
See the License for the specific language governing permissions and
|
||||
limitations under the License.
|
||||
*/
|
||||
|
||||
package v1beta1
|
||||
|
||||
import (
|
||||
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
|
||||
|
||||
"github.com/oam-dev/kubevela/apis/core.oam.dev/common"
|
||||
)
|
||||
|
||||
// DefinitionRevisionSpec is the spec of DefinitionRevision
|
||||
type DefinitionRevisionSpec struct {
|
||||
// Revision record revision number of DefinitionRevision
|
||||
Revision int64 `json:"revision"`
|
||||
|
||||
// RevisionHash record the hash value of the spec of DefinitionRevision object.
|
||||
RevisionHash string `json:"revisionHash"`
|
||||
|
||||
// DefinitionType
|
||||
DefinitionType common.DefinitionType `json:"definitionType"`
|
||||
|
||||
// ComponentDefinition records the snapshot of the created/modified ComponentDefinition
|
||||
ComponentDefinition ComponentDefinition `json:"componentDefinition,omitempty"`
|
||||
|
||||
// TraitDefinition records the snapshot of the created/modified TraitDefinition
|
||||
TraitDefinition TraitDefinition `json:"traitDefinition,omitempty"`
|
||||
}
|
||||
|
||||
// +kubebuilder:object:root=true
|
||||
|
||||
// DefinitionRevision is the Schema for the DefinitionRevision API
|
||||
// +kubebuilder:resource:scope=Namespaced,categories={oam},shortName=comprev
|
||||
// +kubebuilder:printcolumn:name="REVISION",type=integer,JSONPath=".spec.revision"
|
||||
// +kubebuilder:printcolumn:name="HASH",type=string,JSONPath=".spec.revisionHash"
|
||||
// +kubebuilder:printcolumn:name="TYPE",type=string,JSONPath=".spec.definitionType"
|
||||
type DefinitionRevision struct {
|
||||
metav1.TypeMeta `json:",inline"`
|
||||
metav1.ObjectMeta `json:"metadata,omitempty"`
|
||||
|
||||
Spec DefinitionRevisionSpec `json:"spec,omitempty"`
|
||||
}
|
||||
|
||||
// +kubebuilder:object:root=true
|
||||
|
||||
// DefinitionRevisionList contains a list of DefinitionRevision
|
||||
type DefinitionRevisionList struct {
|
||||
metav1.TypeMeta `json:",inline"`
|
||||
metav1.ListMeta `json:"metadata,omitempty"`
|
||||
Items []DefinitionRevision `json:"items"`
|
||||
}
|
||||
@@ -61,6 +61,14 @@ var (
|
||||
TraitDefinitionGroupVersionKind = SchemeGroupVersion.WithKind(TraitDefinitionKind)
|
||||
)
|
||||
|
||||
// DefinitionRevision type metadata.
|
||||
var (
|
||||
DefinitionRevisionKind = reflect.TypeOf(DefinitionRevision{}).Name()
|
||||
DefinitionRevisionGroupKind = schema.GroupKind{Group: Group, Kind: DefinitionRevisionKind}.String()
|
||||
DefinitionRevisionKindAPIVersion = DefinitionRevisionKind + "." + SchemeGroupVersion.String()
|
||||
DefinitionRevisionGroupVersionKind = SchemeGroupVersion.WithKind(DefinitionRevisionKind)
|
||||
)
|
||||
|
||||
// Application type metadata.
|
||||
var (
|
||||
ApplicationKind = reflect.TypeOf(Application{}).Name()
|
||||
@@ -121,6 +129,7 @@ func init() {
|
||||
SchemeBuilder.Register(&ComponentDefinition{}, &ComponentDefinitionList{})
|
||||
SchemeBuilder.Register(&WorkloadDefinition{}, &WorkloadDefinitionList{})
|
||||
SchemeBuilder.Register(&TraitDefinition{}, &TraitDefinitionList{})
|
||||
SchemeBuilder.Register(&DefinitionRevision{}, &DefinitionRevisionList{})
|
||||
SchemeBuilder.Register(&ScopeDefinition{}, &ScopeDefinitionList{})
|
||||
SchemeBuilder.Register(&Application{}, &ApplicationList{})
|
||||
SchemeBuilder.Register(&AppRollout{}, &AppRolloutList{})
|
||||
|
||||
@@ -237,22 +237,6 @@ func (in *AppRolloutSpec) DeepCopy() *AppRolloutSpec {
|
||||
return out
|
||||
}
|
||||
|
||||
// DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
|
||||
func (in *AppRolloutStatus) DeepCopyInto(out *AppRolloutStatus) {
|
||||
*out = *in
|
||||
in.RolloutStatus.DeepCopyInto(&out.RolloutStatus)
|
||||
}
|
||||
|
||||
// DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new AppRolloutStatus.
|
||||
func (in *AppRolloutStatus) DeepCopy() *AppRolloutStatus {
|
||||
if in == nil {
|
||||
return nil
|
||||
}
|
||||
out := new(AppRolloutStatus)
|
||||
in.DeepCopyInto(out)
|
||||
return out
|
||||
}
|
||||
|
||||
// DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
|
||||
func (in *Application) DeepCopyInto(out *Application) {
|
||||
*out = *in
|
||||
@@ -744,6 +728,11 @@ func (in *ComponentDefinitionSpec) DeepCopy() *ComponentDefinitionSpec {
|
||||
func (in *ComponentDefinitionStatus) DeepCopyInto(out *ComponentDefinitionStatus) {
|
||||
*out = *in
|
||||
in.ConditionedStatus.DeepCopyInto(&out.ConditionedStatus)
|
||||
if in.LatestRevision != nil {
|
||||
in, out := &in.LatestRevision, &out.LatestRevision
|
||||
*out = new(common.Revision)
|
||||
**out = **in
|
||||
}
|
||||
}
|
||||
|
||||
// DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new ComponentDefinitionStatus.
|
||||
@@ -756,6 +745,81 @@ func (in *ComponentDefinitionStatus) DeepCopy() *ComponentDefinitionStatus {
|
||||
return out
|
||||
}
|
||||
|
||||
// DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
|
||||
func (in *DefinitionRevision) DeepCopyInto(out *DefinitionRevision) {
|
||||
*out = *in
|
||||
out.TypeMeta = in.TypeMeta
|
||||
in.ObjectMeta.DeepCopyInto(&out.ObjectMeta)
|
||||
in.Spec.DeepCopyInto(&out.Spec)
|
||||
}
|
||||
|
||||
// DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new DefinitionRevision.
|
||||
func (in *DefinitionRevision) DeepCopy() *DefinitionRevision {
|
||||
if in == nil {
|
||||
return nil
|
||||
}
|
||||
out := new(DefinitionRevision)
|
||||
in.DeepCopyInto(out)
|
||||
return out
|
||||
}
|
||||
|
||||
// DeepCopyObject is an autogenerated deepcopy function, copying the receiver, creating a new runtime.Object.
|
||||
func (in *DefinitionRevision) DeepCopyObject() runtime.Object {
|
||||
if c := in.DeepCopy(); c != nil {
|
||||
return c
|
||||
}
|
||||
return nil
|
||||
}
|
||||
|
||||
// DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
|
||||
func (in *DefinitionRevisionList) DeepCopyInto(out *DefinitionRevisionList) {
|
||||
*out = *in
|
||||
out.TypeMeta = in.TypeMeta
|
||||
in.ListMeta.DeepCopyInto(&out.ListMeta)
|
||||
if in.Items != nil {
|
||||
in, out := &in.Items, &out.Items
|
||||
*out = make([]DefinitionRevision, len(*in))
|
||||
for i := range *in {
|
||||
(*in)[i].DeepCopyInto(&(*out)[i])
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new DefinitionRevisionList.
|
||||
func (in *DefinitionRevisionList) DeepCopy() *DefinitionRevisionList {
|
||||
if in == nil {
|
||||
return nil
|
||||
}
|
||||
out := new(DefinitionRevisionList)
|
||||
in.DeepCopyInto(out)
|
||||
return out
|
||||
}
|
||||
|
||||
// DeepCopyObject is an autogenerated deepcopy function, copying the receiver, creating a new runtime.Object.
|
||||
func (in *DefinitionRevisionList) DeepCopyObject() runtime.Object {
|
||||
if c := in.DeepCopy(); c != nil {
|
||||
return c
|
||||
}
|
||||
return nil
|
||||
}
|
||||
|
||||
// DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
|
||||
func (in *DefinitionRevisionSpec) DeepCopyInto(out *DefinitionRevisionSpec) {
|
||||
*out = *in
|
||||
in.ComponentDefinition.DeepCopyInto(&out.ComponentDefinition)
|
||||
in.TraitDefinition.DeepCopyInto(&out.TraitDefinition)
|
||||
}
|
||||
|
||||
// DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new DefinitionRevisionSpec.
|
||||
func (in *DefinitionRevisionSpec) DeepCopy() *DefinitionRevisionSpec {
|
||||
if in == nil {
|
||||
return nil
|
||||
}
|
||||
out := new(DefinitionRevisionSpec)
|
||||
in.DeepCopyInto(out)
|
||||
return out
|
||||
}
|
||||
|
||||
// DeepCopyInto is an autogenerated deepcopy function, copying the receiver, writing into out. in must be non-nil.
|
||||
func (in *Distribution) DeepCopyInto(out *Distribution) {
|
||||
*out = *in
|
||||
@@ -1150,6 +1214,11 @@ func (in *TraitDefinitionSpec) DeepCopy() *TraitDefinitionSpec {
|
||||
func (in *TraitDefinitionStatus) DeepCopyInto(out *TraitDefinitionStatus) {
|
||||
*out = *in
|
||||
in.ConditionedStatus.DeepCopyInto(&out.ConditionedStatus)
|
||||
if in.LatestRevision != nil {
|
||||
in, out := &in.LatestRevision, &out.LatestRevision
|
||||
*out = new(common.Revision)
|
||||
**out = **in
|
||||
}
|
||||
}
|
||||
|
||||
// DeepCopy is an autogenerated deepcopy function, copying the receiver, creating a new TraitDefinitionStatus.
|
||||
|
||||
@@ -25,7 +25,7 @@ limitations under the License.
|
||||
//go:generate go run -tags generate sigs.k8s.io/controller-tools/cmd/controller-gen object:headerFile=../hack/boilerplate.go.txt paths=./... crd:crdVersions=v1 output:artifacts:config=../config/crd/base
|
||||
|
||||
// Generate legacy_support for K8s 1.12~1.15 versions CRD manifests
|
||||
//go:generate go run -tags generate sigs.k8s.io/controller-tools/cmd/controller-gen object:headerFile=../hack/boilerplate.go.txt paths=./... crd:trivialVersions=true output:artifacts:config=../legacy/charts/vela-core-legacy/crds
|
||||
//go:generate go run -tags generate sigs.k8s.io/controller-tools/cmd/controller-gen object:headerFile=../hack/boilerplate.go.txt paths=./... crd output:artifacts:config=../legacy/charts/vela-core-legacy/crds
|
||||
//go:generate go run ../legacy/convert/main.go ../legacy/charts/vela-core-legacy/crds
|
||||
|
||||
//go:generate go run ../hack/crd/update.go ../charts/vela-core/crds/standard.oam.dev_podspecworkloads.yaml
|
||||
|
||||
@@ -38,15 +38,16 @@ type CRDInfo struct {
|
||||
|
||||
// Capability defines the content of a capability
|
||||
type Capability struct {
|
||||
Name string `json:"name"`
|
||||
Type CapType `json:"type"`
|
||||
CueTemplate string `json:"template,omitempty"`
|
||||
CueTemplateURI string `json:"templateURI,omitempty"`
|
||||
Parameters []Parameter `json:"parameters,omitempty"`
|
||||
CrdName string `json:"crdName,omitempty"`
|
||||
Center string `json:"center,omitempty"`
|
||||
Status string `json:"status,omitempty"`
|
||||
Description string `json:"description,omitempty"`
|
||||
Name string `json:"name"`
|
||||
Type CapType `json:"type"`
|
||||
CueTemplate string `json:"template,omitempty"`
|
||||
CueTemplateURI string `json:"templateURI,omitempty"`
|
||||
Parameters []Parameter `json:"parameters,omitempty"`
|
||||
CrdName string `json:"crdName,omitempty"`
|
||||
Center string `json:"center,omitempty"`
|
||||
Status string `json:"status,omitempty"`
|
||||
Description string `json:"description,omitempty"`
|
||||
Category CapabilityCategory `json:"category,omitempty"`
|
||||
|
||||
// trait only
|
||||
AppliesTo []string `json:"appliesTo,omitempty"`
|
||||
@@ -58,6 +59,9 @@ type Capability struct {
|
||||
Source *Source `json:"source,omitempty"`
|
||||
Install *Installation `json:"install,omitempty"`
|
||||
CrdInfo *CRDInfo `json:"crdInfo,omitempty"`
|
||||
|
||||
// Terraform
|
||||
TerraformConfiguration string `json:"terraformConfiguration,omitempty"`
|
||||
}
|
||||
|
||||
// Chart defines all necessary information to install a whole chart
|
||||
@@ -121,6 +125,7 @@ type Parameter struct {
|
||||
Usage string `json:"usage,omitempty"`
|
||||
Type cue.Kind `json:"type,omitempty"`
|
||||
Alias string `json:"alias,omitempty"`
|
||||
JSONType string `json:"jsonType,omitempty"`
|
||||
}
|
||||
|
||||
// SetFlagBy set cli flag from Parameter
|
||||
|
||||
50
apis/types/event.go
Normal file
50
apis/types/event.go
Normal file
@@ -0,0 +1,50 @@
|
||||
/*
|
||||
Copyright 2021 The KubeVela Authors.
|
||||
|
||||
Licensed under the Apache License, Version 2.0 (the "License");
|
||||
you may not use this file except in compliance with the License.
|
||||
You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing, software
|
||||
distributed under the License is distributed on an "AS IS" BASIS,
|
||||
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
||||
See the License for the specific language governing permissions and
|
||||
limitations under the License.
|
||||
*/
|
||||
|
||||
package types
|
||||
|
||||
// reason for Application
|
||||
const (
|
||||
ReasonParsed = "Parsed"
|
||||
ReasonRendered = "Rendered"
|
||||
ReasonApplied = "Applied"
|
||||
ReasonHealthCheck = "HealthChecked"
|
||||
ReasonDeployed = "Deployed"
|
||||
ReasonRollout = "Rollout"
|
||||
|
||||
ReasonFailedParse = "FailedParse"
|
||||
ReasonFailedRender = "FailedRender"
|
||||
ReasonFailedApply = "FailedApply"
|
||||
ReasonFailedHealthCheck = "FailedHealthCheck"
|
||||
ReasonFailedGC = "FailedGC"
|
||||
ReasonFailedRollout = "FailedRollout"
|
||||
)
|
||||
|
||||
// event message for Application
|
||||
const (
|
||||
MessageParsed = "Parsed successfully"
|
||||
MessageRendered = "Rendered successfully"
|
||||
MessageApplied = "Applied successfully"
|
||||
MessageHealthCheck = "Health checked healthy"
|
||||
MessageDeployed = "Deployed successfully"
|
||||
MessageRollout = "Rollout successfully"
|
||||
|
||||
MessageFailedParse = "fail to parse application, err: %v"
|
||||
MessageFailedRender = "fail to render application, err: %v"
|
||||
MessageFailedApply = "fail to apply component, err: %v"
|
||||
MessageFailedHealthCheck = "fail to health check, err: %v"
|
||||
MessageFailedGC = "fail to garbage collection, err: %v"
|
||||
)
|
||||
@@ -313,9 +313,6 @@ spec:
|
||||
status:
|
||||
description: AppStatus defines the observed state of Application
|
||||
properties:
|
||||
batchRollingState:
|
||||
description: BatchRollingState only meaningful when the Status is rolling
|
||||
type: string
|
||||
components:
|
||||
description: Components record the related Components created by Application Controller
|
||||
items:
|
||||
@@ -367,13 +364,6 @@ spec:
|
||||
- type
|
||||
type: object
|
||||
type: array
|
||||
currentBatch:
|
||||
description: The current batch the rollout is working on/blocked it starts from 0
|
||||
format: int32
|
||||
type: integer
|
||||
lastAppliedPodTemplateIdentifier:
|
||||
description: lastAppliedPodTemplateIdentifier is a string that uniquely represent the last pod template each workload type could use different ways to identify that so we cannot compare between resources We update this field only after a successful rollout
|
||||
type: string
|
||||
latestRevision:
|
||||
description: LatestRevision of the application configuration it generates
|
||||
properties:
|
||||
@@ -409,17 +399,82 @@ spec:
|
||||
- kind
|
||||
- name
|
||||
type: object
|
||||
rollingState:
|
||||
description: RollingState is the Rollout State
|
||||
type: string
|
||||
rolloutOriginalSize:
|
||||
description: RolloutTargetSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
|
||||
format: int32
|
||||
type: integer
|
||||
rolloutTargetSize:
|
||||
description: RolloutTargetSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
|
||||
format: int32
|
||||
type: integer
|
||||
rollout:
|
||||
description: AppRolloutStatus defines the observed state of AppRollout
|
||||
properties:
|
||||
LastSourceAppRevision:
|
||||
description: LastSourceAppRevision contains the name of the app that we need to upgrade from. We will restart the rollout if this is not the same as the spec
|
||||
type: string
|
||||
batchRollingState:
|
||||
description: BatchRollingState only meaningful when the Status is rolling
|
||||
type: string
|
||||
conditions:
|
||||
description: Conditions of the resource.
|
||||
items:
|
||||
description: A Condition that may apply to a resource.
|
||||
properties:
|
||||
lastTransitionTime:
|
||||
description: LastTransitionTime is the last time this condition transitioned from one status to another.
|
||||
format: date-time
|
||||
type: string
|
||||
message:
|
||||
description: A Message containing details about this condition's last transition from one status to another, if any.
|
||||
type: string
|
||||
reason:
|
||||
description: A Reason for this condition's last transition from one status to another.
|
||||
type: string
|
||||
status:
|
||||
description: Status of this condition; is it currently True, False, or Unknown?
|
||||
type: string
|
||||
type:
|
||||
description: Type of this condition. At most one of each condition type may apply to a resource at any point in time.
|
||||
type: string
|
||||
required:
|
||||
- lastTransitionTime
|
||||
- reason
|
||||
- status
|
||||
- type
|
||||
type: object
|
||||
type: array
|
||||
currentBatch:
|
||||
description: The current batch the rollout is working on/blocked it starts from 0
|
||||
format: int32
|
||||
type: integer
|
||||
lastAppliedPodTemplateIdentifier:
|
||||
description: lastAppliedPodTemplateIdentifier is a string that uniquely represent the last pod template each workload type could use different ways to identify that so we cannot compare between resources We update this field only after a successful rollout
|
||||
type: string
|
||||
lastTargetAppRevision:
|
||||
description: LastUpgradedTargetAppRevision contains the name of the app that we upgraded to We will restart the rollout if this is not the same as the spec
|
||||
type: string
|
||||
rollingState:
|
||||
description: RollingState is the Rollout State
|
||||
type: string
|
||||
rolloutOriginalSize:
|
||||
description: RolloutTargetSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
|
||||
format: int32
|
||||
type: integer
|
||||
rolloutTargetSize:
|
||||
description: RolloutTargetSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
|
||||
format: int32
|
||||
type: integer
|
||||
targetGeneration:
|
||||
description: NewPodTemplateIdentifier is a string that uniquely represent the new pod template each workload type could use different ways to identify that so we cannot compare between resources
|
||||
type: string
|
||||
upgradedReadyReplicas:
|
||||
description: UpgradedReadyReplicas is the number of Pods upgraded by the rollout controller that have a Ready Condition.
|
||||
format: int32
|
||||
type: integer
|
||||
upgradedReplicas:
|
||||
description: UpgradedReplicas is the number of Pods upgraded by the rollout controller
|
||||
format: int32
|
||||
type: integer
|
||||
required:
|
||||
- currentBatch
|
||||
- lastTargetAppRevision
|
||||
- rollingState
|
||||
- upgradedReadyReplicas
|
||||
- upgradedReplicas
|
||||
type: object
|
||||
services:
|
||||
description: Services record the status of the application services
|
||||
items:
|
||||
@@ -431,6 +486,28 @@ spec:
|
||||
type: string
|
||||
name:
|
||||
type: string
|
||||
scopes:
|
||||
items:
|
||||
description: A TypedReference refers to an object by Name, Kind, and APIVersion. It is commonly used to reference cluster-scoped objects or objects where the namespace is already known.
|
||||
properties:
|
||||
apiVersion:
|
||||
description: APIVersion of the referenced object.
|
||||
type: string
|
||||
kind:
|
||||
description: Kind of the referenced object.
|
||||
type: string
|
||||
name:
|
||||
description: Name of the referenced object.
|
||||
type: string
|
||||
uid:
|
||||
description: UID of the referenced object.
|
||||
type: string
|
||||
required:
|
||||
- apiVersion
|
||||
- kind
|
||||
- name
|
||||
type: object
|
||||
type: array
|
||||
traits:
|
||||
items:
|
||||
description: ApplicationTraitStatus records the trait health status
|
||||
@@ -465,22 +542,6 @@ spec:
|
||||
status:
|
||||
description: ApplicationPhase is a label for the condition of a application at the current time
|
||||
type: string
|
||||
targetGeneration:
|
||||
description: NewPodTemplateIdentifier is a string that uniquely represent the new pod template each workload type could use different ways to identify that so we cannot compare between resources
|
||||
type: string
|
||||
upgradedReadyReplicas:
|
||||
description: UpgradedReadyReplicas is the number of Pods upgraded by the rollout controller that have a Ready Condition.
|
||||
format: int32
|
||||
type: integer
|
||||
upgradedReplicas:
|
||||
description: UpgradedReplicas is the number of Pods upgraded by the rollout controller
|
||||
format: int32
|
||||
type: integer
|
||||
required:
|
||||
- currentBatch
|
||||
- rollingState
|
||||
- upgradedReadyReplicas
|
||||
- upgradedReplicas
|
||||
type: object
|
||||
type: object
|
||||
applicationConfiguration:
|
||||
@@ -604,6 +665,22 @@ spec:
|
||||
required:
|
||||
- template
|
||||
type: object
|
||||
terraform:
|
||||
description: Terraform is the struct to describe cloud resources managed by Hashicorp Terraform
|
||||
properties:
|
||||
configuration:
|
||||
description: Configuration is Terraform Configuration
|
||||
type: string
|
||||
type:
|
||||
default: hcl
|
||||
description: Type specifies which Terraform configuration it is, HCL or JSON syntax
|
||||
enum:
|
||||
- hcl
|
||||
- json
|
||||
type: string
|
||||
required:
|
||||
- configuration
|
||||
type: object
|
||||
type: object
|
||||
status:
|
||||
description: Status defines the custom health policy and status message for workload
|
||||
@@ -670,6 +747,21 @@ spec:
|
||||
configMapRef:
|
||||
description: ConfigMapRef refer to a ConfigMap which contains OpenAPI V3 JSON schema of Component parameters.
|
||||
type: string
|
||||
latestRevision:
|
||||
description: LatestRevision of the component definition
|
||||
properties:
|
||||
name:
|
||||
type: string
|
||||
revision:
|
||||
format: int64
|
||||
type: integer
|
||||
revisionHash:
|
||||
description: RevisionHash record the hash value of the spec of ApplicationRevision object.
|
||||
type: string
|
||||
required:
|
||||
- name
|
||||
- revision
|
||||
type: object
|
||||
type: object
|
||||
type: object
|
||||
description: ComponentDefinitions records the snapshot of the componentDefinitions related with the created/modified Application
|
||||
@@ -847,6 +939,22 @@ spec:
|
||||
required:
|
||||
- template
|
||||
type: object
|
||||
terraform:
|
||||
description: Terraform is the struct to describe cloud resources managed by Hashicorp Terraform
|
||||
properties:
|
||||
configuration:
|
||||
description: Configuration is Terraform Configuration
|
||||
type: string
|
||||
type:
|
||||
default: hcl
|
||||
description: Type specifies which Terraform configuration it is, HCL or JSON syntax
|
||||
enum:
|
||||
- hcl
|
||||
- json
|
||||
type: string
|
||||
required:
|
||||
- configuration
|
||||
type: object
|
||||
type: object
|
||||
status:
|
||||
description: Status defines the custom health policy and status message for trait
|
||||
@@ -896,6 +1004,21 @@ spec:
|
||||
configMapRef:
|
||||
description: ConfigMapRef refer to a ConfigMap which contains OpenAPI V3 JSON schema of Component parameters.
|
||||
type: string
|
||||
latestRevision:
|
||||
description: LatestRevision of the trait definition
|
||||
properties:
|
||||
name:
|
||||
type: string
|
||||
revision:
|
||||
format: int64
|
||||
type: integer
|
||||
revisionHash:
|
||||
description: RevisionHash record the hash value of the spec of ApplicationRevision object.
|
||||
type: string
|
||||
required:
|
||||
- name
|
||||
- revision
|
||||
type: object
|
||||
type: object
|
||||
type: object
|
||||
description: TraitDefinitions records the snapshot of the traitDefinitions related with the created/modified Application
|
||||
@@ -1028,6 +1151,22 @@ spec:
|
||||
required:
|
||||
- template
|
||||
type: object
|
||||
terraform:
|
||||
description: Terraform is the struct to describe cloud resources managed by Hashicorp Terraform
|
||||
properties:
|
||||
configuration:
|
||||
description: Configuration is Terraform Configuration
|
||||
type: string
|
||||
type:
|
||||
default: hcl
|
||||
description: Type specifies which Terraform configuration it is, HCL or JSON syntax
|
||||
enum:
|
||||
- hcl
|
||||
- json
|
||||
type: string
|
||||
required:
|
||||
- configuration
|
||||
type: object
|
||||
type: object
|
||||
status:
|
||||
description: Status defines the custom health policy and status message for workload
|
||||
@@ -1379,9 +1518,6 @@ spec:
|
||||
status:
|
||||
description: AppStatus defines the observed state of Application
|
||||
properties:
|
||||
batchRollingState:
|
||||
description: BatchRollingState only meaningful when the Status is rolling
|
||||
type: string
|
||||
components:
|
||||
description: Components record the related Components created by Application Controller
|
||||
items:
|
||||
@@ -1433,13 +1569,6 @@ spec:
|
||||
- type
|
||||
type: object
|
||||
type: array
|
||||
currentBatch:
|
||||
description: The current batch the rollout is working on/blocked it starts from 0
|
||||
format: int32
|
||||
type: integer
|
||||
lastAppliedPodTemplateIdentifier:
|
||||
description: lastAppliedPodTemplateIdentifier is a string that uniquely represent the last pod template each workload type could use different ways to identify that so we cannot compare between resources We update this field only after a successful rollout
|
||||
type: string
|
||||
latestRevision:
|
||||
description: LatestRevision of the application configuration it generates
|
||||
properties:
|
||||
@@ -1475,17 +1604,82 @@ spec:
|
||||
- kind
|
||||
- name
|
||||
type: object
|
||||
rollingState:
|
||||
description: RollingState is the Rollout State
|
||||
type: string
|
||||
rolloutOriginalSize:
|
||||
description: RolloutTargetSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
|
||||
format: int32
|
||||
type: integer
|
||||
rolloutTargetSize:
|
||||
description: RolloutTargetSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
|
||||
format: int32
|
||||
type: integer
|
||||
rollout:
|
||||
description: AppRolloutStatus defines the observed state of AppRollout
|
||||
properties:
|
||||
LastSourceAppRevision:
|
||||
description: LastSourceAppRevision contains the name of the app that we need to upgrade from. We will restart the rollout if this is not the same as the spec
|
||||
type: string
|
||||
batchRollingState:
|
||||
description: BatchRollingState only meaningful when the Status is rolling
|
||||
type: string
|
||||
conditions:
|
||||
description: Conditions of the resource.
|
||||
items:
|
||||
description: A Condition that may apply to a resource.
|
||||
properties:
|
||||
lastTransitionTime:
|
||||
description: LastTransitionTime is the last time this condition transitioned from one status to another.
|
||||
format: date-time
|
||||
type: string
|
||||
message:
|
||||
description: A Message containing details about this condition's last transition from one status to another, if any.
|
||||
type: string
|
||||
reason:
|
||||
description: A Reason for this condition's last transition from one status to another.
|
||||
type: string
|
||||
status:
|
||||
description: Status of this condition; is it currently True, False, or Unknown?
|
||||
type: string
|
||||
type:
|
||||
description: Type of this condition. At most one of each condition type may apply to a resource at any point in time.
|
||||
type: string
|
||||
required:
|
||||
- lastTransitionTime
|
||||
- reason
|
||||
- status
|
||||
- type
|
||||
type: object
|
||||
type: array
|
||||
currentBatch:
|
||||
description: The current batch the rollout is working on/blocked it starts from 0
|
||||
format: int32
|
||||
type: integer
|
||||
lastAppliedPodTemplateIdentifier:
|
||||
description: lastAppliedPodTemplateIdentifier is a string that uniquely represent the last pod template each workload type could use different ways to identify that so we cannot compare between resources We update this field only after a successful rollout
|
||||
type: string
|
||||
lastTargetAppRevision:
|
||||
description: LastUpgradedTargetAppRevision contains the name of the app that we upgraded to We will restart the rollout if this is not the same as the spec
|
||||
type: string
|
||||
rollingState:
|
||||
description: RollingState is the Rollout State
|
||||
type: string
|
||||
rolloutOriginalSize:
|
||||
description: RolloutTargetSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
|
||||
format: int32
|
||||
type: integer
|
||||
rolloutTargetSize:
|
||||
description: RolloutTargetSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
|
||||
format: int32
|
||||
type: integer
|
||||
targetGeneration:
|
||||
description: NewPodTemplateIdentifier is a string that uniquely represent the new pod template each workload type could use different ways to identify that so we cannot compare between resources
|
||||
type: string
|
||||
upgradedReadyReplicas:
|
||||
description: UpgradedReadyReplicas is the number of Pods upgraded by the rollout controller that have a Ready Condition.
|
||||
format: int32
|
||||
type: integer
|
||||
upgradedReplicas:
|
||||
description: UpgradedReplicas is the number of Pods upgraded by the rollout controller
|
||||
format: int32
|
||||
type: integer
|
||||
required:
|
||||
- currentBatch
|
||||
- lastTargetAppRevision
|
||||
- rollingState
|
||||
- upgradedReadyReplicas
|
||||
- upgradedReplicas
|
||||
type: object
|
||||
services:
|
||||
description: Services record the status of the application services
|
||||
items:
|
||||
@@ -1497,6 +1691,28 @@ spec:
|
||||
type: string
|
||||
name:
|
||||
type: string
|
||||
scopes:
|
||||
items:
|
||||
description: A TypedReference refers to an object by Name, Kind, and APIVersion. It is commonly used to reference cluster-scoped objects or objects where the namespace is already known.
|
||||
properties:
|
||||
apiVersion:
|
||||
description: APIVersion of the referenced object.
|
||||
type: string
|
||||
kind:
|
||||
description: Kind of the referenced object.
|
||||
type: string
|
||||
name:
|
||||
description: Name of the referenced object.
|
||||
type: string
|
||||
uid:
|
||||
description: UID of the referenced object.
|
||||
type: string
|
||||
required:
|
||||
- apiVersion
|
||||
- kind
|
||||
- name
|
||||
type: object
|
||||
type: array
|
||||
traits:
|
||||
items:
|
||||
description: ApplicationTraitStatus records the trait health status
|
||||
@@ -1531,22 +1747,6 @@ spec:
|
||||
status:
|
||||
description: ApplicationPhase is a label for the condition of a application at the current time
|
||||
type: string
|
||||
targetGeneration:
|
||||
description: NewPodTemplateIdentifier is a string that uniquely represent the new pod template each workload type could use different ways to identify that so we cannot compare between resources
|
||||
type: string
|
||||
upgradedReadyReplicas:
|
||||
description: UpgradedReadyReplicas is the number of Pods upgraded by the rollout controller that have a Ready Condition.
|
||||
format: int32
|
||||
type: integer
|
||||
upgradedReplicas:
|
||||
description: UpgradedReplicas is the number of Pods upgraded by the rollout controller
|
||||
format: int32
|
||||
type: integer
|
||||
required:
|
||||
- currentBatch
|
||||
- rollingState
|
||||
- upgradedReadyReplicas
|
||||
- upgradedReplicas
|
||||
type: object
|
||||
type: object
|
||||
applicationConfiguration:
|
||||
@@ -1670,6 +1870,22 @@ spec:
|
||||
required:
|
||||
- template
|
||||
type: object
|
||||
terraform:
|
||||
description: Terraform is the struct to describe cloud resources managed by Hashicorp Terraform
|
||||
properties:
|
||||
configuration:
|
||||
description: Configuration is Terraform Configuration
|
||||
type: string
|
||||
type:
|
||||
default: hcl
|
||||
description: Type specifies which Terraform configuration it is, HCL or JSON syntax
|
||||
enum:
|
||||
- hcl
|
||||
- json
|
||||
type: string
|
||||
required:
|
||||
- configuration
|
||||
type: object
|
||||
type: object
|
||||
status:
|
||||
description: Status defines the custom health policy and status message for workload
|
||||
@@ -1736,6 +1952,21 @@ spec:
|
||||
configMapRef:
|
||||
description: ConfigMapRef refer to a ConfigMap which contains OpenAPI V3 JSON schema of Component parameters.
|
||||
type: string
|
||||
latestRevision:
|
||||
description: LatestRevision of the component definition
|
||||
properties:
|
||||
name:
|
||||
type: string
|
||||
revision:
|
||||
format: int64
|
||||
type: integer
|
||||
revisionHash:
|
||||
description: RevisionHash record the hash value of the spec of ApplicationRevision object.
|
||||
type: string
|
||||
required:
|
||||
- name
|
||||
- revision
|
||||
type: object
|
||||
type: object
|
||||
type: object
|
||||
description: ComponentDefinitions records the snapshot of the componentDefinitions related with the created/modified Application
|
||||
@@ -1914,6 +2145,22 @@ spec:
|
||||
required:
|
||||
- template
|
||||
type: object
|
||||
terraform:
|
||||
description: Terraform is the struct to describe cloud resources managed by Hashicorp Terraform
|
||||
properties:
|
||||
configuration:
|
||||
description: Configuration is Terraform Configuration
|
||||
type: string
|
||||
type:
|
||||
default: hcl
|
||||
description: Type specifies which Terraform configuration it is, HCL or JSON syntax
|
||||
enum:
|
||||
- hcl
|
||||
- json
|
||||
type: string
|
||||
required:
|
||||
- configuration
|
||||
type: object
|
||||
type: object
|
||||
status:
|
||||
description: Status defines the custom health policy and status message for trait
|
||||
@@ -1963,6 +2210,21 @@ spec:
|
||||
configMapRef:
|
||||
description: ConfigMapRef refer to a ConfigMap which contains OpenAPI V3 JSON schema of Component parameters.
|
||||
type: string
|
||||
latestRevision:
|
||||
description: LatestRevision of the component definition
|
||||
properties:
|
||||
name:
|
||||
type: string
|
||||
revision:
|
||||
format: int64
|
||||
type: integer
|
||||
revisionHash:
|
||||
description: RevisionHash record the hash value of the spec of ApplicationRevision object.
|
||||
type: string
|
||||
required:
|
||||
- name
|
||||
- revision
|
||||
type: object
|
||||
type: object
|
||||
type: object
|
||||
description: TraitDefinitions records the snapshot of the traitDefinitions related with the created/modified Application
|
||||
@@ -2095,6 +2357,22 @@ spec:
|
||||
required:
|
||||
- template
|
||||
type: object
|
||||
terraform:
|
||||
description: Terraform is the struct to describe cloud resources managed by Hashicorp Terraform
|
||||
properties:
|
||||
configuration:
|
||||
description: Configuration is Terraform Configuration
|
||||
type: string
|
||||
type:
|
||||
default: hcl
|
||||
description: Type specifies which Terraform configuration it is, HCL or JSON syntax
|
||||
enum:
|
||||
- hcl
|
||||
- json
|
||||
type: string
|
||||
required:
|
||||
- configuration
|
||||
type: object
|
||||
type: object
|
||||
status:
|
||||
description: Status defines the custom health policy and status message for workload
|
||||
|
||||
@@ -325,9 +325,6 @@ spec:
|
||||
status:
|
||||
description: AppStatus defines the observed state of Application
|
||||
properties:
|
||||
batchRollingState:
|
||||
description: BatchRollingState only meaningful when the Status is rolling
|
||||
type: string
|
||||
components:
|
||||
description: Components record the related Components created by Application Controller
|
||||
items:
|
||||
@@ -379,13 +376,6 @@ spec:
|
||||
- type
|
||||
type: object
|
||||
type: array
|
||||
currentBatch:
|
||||
description: The current batch the rollout is working on/blocked it starts from 0
|
||||
format: int32
|
||||
type: integer
|
||||
lastAppliedPodTemplateIdentifier:
|
||||
description: lastAppliedPodTemplateIdentifier is a string that uniquely represent the last pod template each workload type could use different ways to identify that so we cannot compare between resources We update this field only after a successful rollout
|
||||
type: string
|
||||
latestRevision:
|
||||
description: LatestRevision of the application configuration it generates
|
||||
properties:
|
||||
@@ -421,17 +411,82 @@ spec:
|
||||
- kind
|
||||
- name
|
||||
type: object
|
||||
rollingState:
|
||||
description: RollingState is the Rollout State
|
||||
type: string
|
||||
rolloutOriginalSize:
|
||||
description: RolloutTargetSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
|
||||
format: int32
|
||||
type: integer
|
||||
rolloutTargetSize:
|
||||
description: RolloutTargetSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
|
||||
format: int32
|
||||
type: integer
|
||||
rollout:
|
||||
description: AppRolloutStatus defines the observed state of AppRollout
|
||||
properties:
|
||||
LastSourceAppRevision:
|
||||
description: LastSourceAppRevision contains the name of the app that we need to upgrade from. We will restart the rollout if this is not the same as the spec
|
||||
type: string
|
||||
batchRollingState:
|
||||
description: BatchRollingState only meaningful when the Status is rolling
|
||||
type: string
|
||||
conditions:
|
||||
description: Conditions of the resource.
|
||||
items:
|
||||
description: A Condition that may apply to a resource.
|
||||
properties:
|
||||
lastTransitionTime:
|
||||
description: LastTransitionTime is the last time this condition transitioned from one status to another.
|
||||
format: date-time
|
||||
type: string
|
||||
message:
|
||||
description: A Message containing details about this condition's last transition from one status to another, if any.
|
||||
type: string
|
||||
reason:
|
||||
description: A Reason for this condition's last transition from one status to another.
|
||||
type: string
|
||||
status:
|
||||
description: Status of this condition; is it currently True, False, or Unknown?
|
||||
type: string
|
||||
type:
|
||||
description: Type of this condition. At most one of each condition type may apply to a resource at any point in time.
|
||||
type: string
|
||||
required:
|
||||
- lastTransitionTime
|
||||
- reason
|
||||
- status
|
||||
- type
|
||||
type: object
|
||||
type: array
|
||||
currentBatch:
|
||||
description: The current batch the rollout is working on/blocked it starts from 0
|
||||
format: int32
|
||||
type: integer
|
||||
lastAppliedPodTemplateIdentifier:
|
||||
description: lastAppliedPodTemplateIdentifier is a string that uniquely represent the last pod template each workload type could use different ways to identify that so we cannot compare between resources We update this field only after a successful rollout
|
||||
type: string
|
||||
lastTargetAppRevision:
|
||||
description: LastUpgradedTargetAppRevision contains the name of the app that we upgraded to We will restart the rollout if this is not the same as the spec
|
||||
type: string
|
||||
rollingState:
|
||||
description: RollingState is the Rollout State
|
||||
type: string
|
||||
rolloutOriginalSize:
|
||||
description: RolloutTargetSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
|
||||
format: int32
|
||||
type: integer
|
||||
rolloutTargetSize:
|
||||
description: RolloutTargetSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
|
||||
format: int32
|
||||
type: integer
|
||||
targetGeneration:
|
||||
description: NewPodTemplateIdentifier is a string that uniquely represent the new pod template each workload type could use different ways to identify that so we cannot compare between resources
|
||||
type: string
|
||||
upgradedReadyReplicas:
|
||||
description: UpgradedReadyReplicas is the number of Pods upgraded by the rollout controller that have a Ready Condition.
|
||||
format: int32
|
||||
type: integer
|
||||
upgradedReplicas:
|
||||
description: UpgradedReplicas is the number of Pods upgraded by the rollout controller
|
||||
format: int32
|
||||
type: integer
|
||||
required:
|
||||
- currentBatch
|
||||
- lastTargetAppRevision
|
||||
- rollingState
|
||||
- upgradedReadyReplicas
|
||||
- upgradedReplicas
|
||||
type: object
|
||||
services:
|
||||
description: Services record the status of the application services
|
||||
items:
|
||||
@@ -443,6 +498,28 @@ spec:
|
||||
type: string
|
||||
name:
|
||||
type: string
|
||||
scopes:
|
||||
items:
|
||||
description: A TypedReference refers to an object by Name, Kind, and APIVersion. It is commonly used to reference cluster-scoped objects or objects where the namespace is already known.
|
||||
properties:
|
||||
apiVersion:
|
||||
description: APIVersion of the referenced object.
|
||||
type: string
|
||||
kind:
|
||||
description: Kind of the referenced object.
|
||||
type: string
|
||||
name:
|
||||
description: Name of the referenced object.
|
||||
type: string
|
||||
uid:
|
||||
description: UID of the referenced object.
|
||||
type: string
|
||||
required:
|
||||
- apiVersion
|
||||
- kind
|
||||
- name
|
||||
type: object
|
||||
type: array
|
||||
traits:
|
||||
items:
|
||||
description: ApplicationTraitStatus records the trait health status
|
||||
@@ -477,22 +554,6 @@ spec:
|
||||
status:
|
||||
description: ApplicationPhase is a label for the condition of a application at the current time
|
||||
type: string
|
||||
targetGeneration:
|
||||
description: NewPodTemplateIdentifier is a string that uniquely represent the new pod template each workload type could use different ways to identify that so we cannot compare between resources
|
||||
type: string
|
||||
upgradedReadyReplicas:
|
||||
description: UpgradedReadyReplicas is the number of Pods upgraded by the rollout controller that have a Ready Condition.
|
||||
format: int32
|
||||
type: integer
|
||||
upgradedReplicas:
|
||||
description: UpgradedReplicas is the number of Pods upgraded by the rollout controller
|
||||
format: int32
|
||||
type: integer
|
||||
required:
|
||||
- currentBatch
|
||||
- rollingState
|
||||
- upgradedReadyReplicas
|
||||
- upgradedReplicas
|
||||
type: object
|
||||
type: object
|
||||
served: true
|
||||
@@ -794,9 +855,6 @@ spec:
|
||||
status:
|
||||
description: AppStatus defines the observed state of Application
|
||||
properties:
|
||||
batchRollingState:
|
||||
description: BatchRollingState only meaningful when the Status is rolling
|
||||
type: string
|
||||
components:
|
||||
description: Components record the related Components created by Application Controller
|
||||
items:
|
||||
@@ -848,13 +906,6 @@ spec:
|
||||
- type
|
||||
type: object
|
||||
type: array
|
||||
currentBatch:
|
||||
description: The current batch the rollout is working on/blocked it starts from 0
|
||||
format: int32
|
||||
type: integer
|
||||
lastAppliedPodTemplateIdentifier:
|
||||
description: lastAppliedPodTemplateIdentifier is a string that uniquely represent the last pod template each workload type could use different ways to identify that so we cannot compare between resources We update this field only after a successful rollout
|
||||
type: string
|
||||
latestRevision:
|
||||
description: LatestRevision of the application configuration it generates
|
||||
properties:
|
||||
@@ -890,17 +941,82 @@ spec:
|
||||
- kind
|
||||
- name
|
||||
type: object
|
||||
rollingState:
|
||||
description: RollingState is the Rollout State
|
||||
type: string
|
||||
rolloutOriginalSize:
|
||||
description: RolloutTargetSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
|
||||
format: int32
|
||||
type: integer
|
||||
rolloutTargetSize:
|
||||
description: RolloutTargetSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
|
||||
format: int32
|
||||
type: integer
|
||||
rollout:
|
||||
description: AppRolloutStatus defines the observed state of AppRollout
|
||||
properties:
|
||||
LastSourceAppRevision:
|
||||
description: LastSourceAppRevision contains the name of the app that we need to upgrade from. We will restart the rollout if this is not the same as the spec
|
||||
type: string
|
||||
batchRollingState:
|
||||
description: BatchRollingState only meaningful when the Status is rolling
|
||||
type: string
|
||||
conditions:
|
||||
description: Conditions of the resource.
|
||||
items:
|
||||
description: A Condition that may apply to a resource.
|
||||
properties:
|
||||
lastTransitionTime:
|
||||
description: LastTransitionTime is the last time this condition transitioned from one status to another.
|
||||
format: date-time
|
||||
type: string
|
||||
message:
|
||||
description: A Message containing details about this condition's last transition from one status to another, if any.
|
||||
type: string
|
||||
reason:
|
||||
description: A Reason for this condition's last transition from one status to another.
|
||||
type: string
|
||||
status:
|
||||
description: Status of this condition; is it currently True, False, or Unknown?
|
||||
type: string
|
||||
type:
|
||||
description: Type of this condition. At most one of each condition type may apply to a resource at any point in time.
|
||||
type: string
|
||||
required:
|
||||
- lastTransitionTime
|
||||
- reason
|
||||
- status
|
||||
- type
|
||||
type: object
|
||||
type: array
|
||||
currentBatch:
|
||||
description: The current batch the rollout is working on/blocked it starts from 0
|
||||
format: int32
|
||||
type: integer
|
||||
lastAppliedPodTemplateIdentifier:
|
||||
description: lastAppliedPodTemplateIdentifier is a string that uniquely represent the last pod template each workload type could use different ways to identify that so we cannot compare between resources We update this field only after a successful rollout
|
||||
type: string
|
||||
lastTargetAppRevision:
|
||||
description: LastUpgradedTargetAppRevision contains the name of the app that we upgraded to We will restart the rollout if this is not the same as the spec
|
||||
type: string
|
||||
rollingState:
|
||||
description: RollingState is the Rollout State
|
||||
type: string
|
||||
rolloutOriginalSize:
|
||||
description: RolloutTargetSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
|
||||
format: int32
|
||||
type: integer
|
||||
rolloutTargetSize:
|
||||
description: RolloutTargetSize is the size of the target resources. This is determined once the initial spec verification and does not change until the rollout is restarted
|
||||
format: int32
|
||||
type: integer
|
||||
targetGeneration:
|
||||
description: NewPodTemplateIdentifier is a string that uniquely represent the new pod template each workload type could use different ways to identify that so we cannot compare between resources
|
||||
type: string
|
||||
upgradedReadyReplicas:
|
||||
description: UpgradedReadyReplicas is the number of Pods upgraded by the rollout controller that have a Ready Condition.
|
||||
format: int32
|
||||
type: integer
|
||||
upgradedReplicas:
|
||||
description: UpgradedReplicas is the number of Pods upgraded by the rollout controller
|
||||
format: int32
|
||||
type: integer
|
||||
required:
|
||||
- currentBatch
|
||||
- lastTargetAppRevision
|
||||
- rollingState
|
||||
- upgradedReadyReplicas
|
||||
- upgradedReplicas
|
||||
type: object
|
||||
services:
|
||||
description: Services record the status of the application services
|
||||
items:
|
||||
@@ -912,6 +1028,28 @@ spec:
|
||||
type: string
|
||||
name:
|
||||
type: string
|
||||
scopes:
|
||||
items:
|
||||
description: A TypedReference refers to an object by Name, Kind, and APIVersion. It is commonly used to reference cluster-scoped objects or objects where the namespace is already known.
|
||||
properties:
|
||||
apiVersion:
|
||||
description: APIVersion of the referenced object.
|
||||
type: string
|
||||
kind:
|
||||
description: Kind of the referenced object.
|
||||
type: string
|
||||
name:
|
||||
description: Name of the referenced object.
|
||||
type: string
|
||||
uid:
|
||||
description: UID of the referenced object.
|
||||
type: string
|
||||
required:
|
||||
- apiVersion
|
||||
- kind
|
||||
- name
|
||||
type: object
|
||||
type: array
|
||||
traits:
|
||||
items:
|
||||
description: ApplicationTraitStatus records the trait health status
|
||||
@@ -946,22 +1084,6 @@ spec:
|
||||
status:
|
||||
description: ApplicationPhase is a label for the condition of a application at the current time
|
||||
type: string
|
||||
targetGeneration:
|
||||
description: NewPodTemplateIdentifier is a string that uniquely represent the new pod template each workload type could use different ways to identify that so we cannot compare between resources
|
||||
type: string
|
||||
upgradedReadyReplicas:
|
||||
description: UpgradedReadyReplicas is the number of Pods upgraded by the rollout controller that have a Ready Condition.
|
||||
format: int32
|
||||
type: integer
|
||||
upgradedReplicas:
|
||||
description: UpgradedReplicas is the number of Pods upgraded by the rollout controller
|
||||
format: int32
|
||||
type: integer
|
||||
required:
|
||||
- currentBatch
|
||||
- rollingState
|
||||
- upgradedReadyReplicas
|
||||
- upgradedReplicas
|
||||
type: object
|
||||
type: object
|
||||
served: true
|
||||
|
||||
@@ -143,6 +143,22 @@ spec:
|
||||
required:
|
||||
- template
|
||||
type: object
|
||||
terraform:
|
||||
description: Terraform is the struct to describe cloud resources managed by Hashicorp Terraform
|
||||
properties:
|
||||
configuration:
|
||||
description: Configuration is Terraform Configuration
|
||||
type: string
|
||||
type:
|
||||
default: hcl
|
||||
description: Type specifies which Terraform configuration it is, HCL or JSON syntax
|
||||
enum:
|
||||
- hcl
|
||||
- json
|
||||
type: string
|
||||
required:
|
||||
- configuration
|
||||
type: object
|
||||
type: object
|
||||
status:
|
||||
description: Status defines the custom health policy and status message for workload
|
||||
@@ -209,6 +225,21 @@ spec:
|
||||
configMapRef:
|
||||
description: ConfigMapRef refer to a ConfigMap which contains OpenAPI V3 JSON schema of Component parameters.
|
||||
type: string
|
||||
latestRevision:
|
||||
description: LatestRevision of the component definition
|
||||
properties:
|
||||
name:
|
||||
type: string
|
||||
revision:
|
||||
format: int64
|
||||
type: integer
|
||||
revisionHash:
|
||||
description: RevisionHash record the hash value of the spec of ApplicationRevision object.
|
||||
type: string
|
||||
required:
|
||||
- name
|
||||
- revision
|
||||
type: object
|
||||
type: object
|
||||
type: object
|
||||
served: true
|
||||
@@ -339,6 +370,22 @@ spec:
|
||||
required:
|
||||
- template
|
||||
type: object
|
||||
terraform:
|
||||
description: Terraform is the struct to describe cloud resources managed by Hashicorp Terraform
|
||||
properties:
|
||||
configuration:
|
||||
description: Configuration is Terraform Configuration
|
||||
type: string
|
||||
type:
|
||||
default: hcl
|
||||
description: Type specifies which Terraform configuration it is, HCL or JSON syntax
|
||||
enum:
|
||||
- hcl
|
||||
- json
|
||||
type: string
|
||||
required:
|
||||
- configuration
|
||||
type: object
|
||||
type: object
|
||||
status:
|
||||
description: Status defines the custom health policy and status message for workload
|
||||
@@ -405,6 +452,21 @@ spec:
|
||||
configMapRef:
|
||||
description: ConfigMapRef refer to a ConfigMap which contains OpenAPI V3 JSON schema of Component parameters.
|
||||
type: string
|
||||
latestRevision:
|
||||
description: LatestRevision of the component definition
|
||||
properties:
|
||||
name:
|
||||
type: string
|
||||
revision:
|
||||
format: int64
|
||||
type: integer
|
||||
revisionHash:
|
||||
description: RevisionHash record the hash value of the spec of ApplicationRevision object.
|
||||
type: string
|
||||
required:
|
||||
- name
|
||||
- revision
|
||||
type: object
|
||||
type: object
|
||||
type: object
|
||||
served: true
|
||||
|
||||
487
charts/vela-core/crds/core.oam.dev_definitionrevisions.yaml
Normal file
487
charts/vela-core/crds/core.oam.dev_definitionrevisions.yaml
Normal file
@@ -0,0 +1,487 @@
|
||||
|
||||
---
|
||||
apiVersion: apiextensions.k8s.io/v1
|
||||
kind: CustomResourceDefinition
|
||||
metadata:
|
||||
annotations:
|
||||
controller-gen.kubebuilder.io/version: v0.2.4
|
||||
name: definitionrevisions.core.oam.dev
|
||||
spec:
|
||||
group: core.oam.dev
|
||||
names:
|
||||
categories:
|
||||
- oam
|
||||
kind: DefinitionRevision
|
||||
listKind: DefinitionRevisionList
|
||||
plural: definitionrevisions
|
||||
shortNames:
|
||||
- comprev
|
||||
singular: definitionrevision
|
||||
scope: Namespaced
|
||||
versions:
|
||||
- additionalPrinterColumns:
|
||||
- jsonPath: .spec.revision
|
||||
name: REVISION
|
||||
type: integer
|
||||
- jsonPath: .spec.revisionHash
|
||||
name: HASH
|
||||
type: string
|
||||
- jsonPath: .spec.definitionType
|
||||
name: TYPE
|
||||
type: string
|
||||
name: v1beta1
|
||||
schema:
|
||||
openAPIV3Schema:
|
||||
description: DefinitionRevision is the Schema for the DefinitionRevision API
|
||||
properties:
|
||||
apiVersion:
|
||||
description: 'APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources'
|
||||
type: string
|
||||
kind:
|
||||
description: 'Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds'
|
||||
type: string
|
||||
metadata:
|
||||
type: object
|
||||
spec:
|
||||
description: DefinitionRevisionSpec is the spec of DefinitionRevision
|
||||
properties:
|
||||
componentDefinition:
|
||||
description: ComponentDefinition records the snapshot of the created/modified ComponentDefinition
|
||||
properties:
|
||||
apiVersion:
|
||||
description: 'APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources'
|
||||
type: string
|
||||
kind:
|
||||
description: 'Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds'
|
||||
type: string
|
||||
metadata:
|
||||
type: object
|
||||
spec:
|
||||
description: ComponentDefinitionSpec defines the desired state of ComponentDefinition
|
||||
properties:
|
||||
childResourceKinds:
|
||||
description: ChildResourceKinds are the list of GVK of the child resources this workload generates
|
||||
items:
|
||||
description: A ChildResourceKind defines a child Kubernetes resource kind with a selector
|
||||
properties:
|
||||
apiVersion:
|
||||
description: APIVersion of the child resource
|
||||
type: string
|
||||
kind:
|
||||
description: Kind of the child resource
|
||||
type: string
|
||||
selector:
|
||||
additionalProperties:
|
||||
type: string
|
||||
description: Selector to select the child resources that the workload wants to expose to traits
|
||||
type: object
|
||||
required:
|
||||
- apiVersion
|
||||
- kind
|
||||
type: object
|
||||
type: array
|
||||
extension:
|
||||
description: Extension is used for extension needs by OAM platform builders
|
||||
type: object
|
||||
x-kubernetes-preserve-unknown-fields: true
|
||||
podSpecPath:
|
||||
description: PodSpecPath indicates where/if this workload has K8s podSpec field if one workload has podSpec, trait can do lot's of assumption such as port, env, volume fields.
|
||||
type: string
|
||||
revisionLabel:
|
||||
description: RevisionLabel indicates which label for underlying resources(e.g. pods) of this workload can be used by trait to create resource selectors(e.g. label selector for pods).
|
||||
type: string
|
||||
schematic:
|
||||
description: Schematic defines the data format and template of the encapsulation of the workload
|
||||
properties:
|
||||
cue:
|
||||
description: CUE defines the encapsulation in CUE format
|
||||
properties:
|
||||
template:
|
||||
description: Template defines the abstraction template data of the capability, it will replace the old CUE template in extension field. Template is a required field if CUE is defined in Capability Definition.
|
||||
type: string
|
||||
required:
|
||||
- template
|
||||
type: object
|
||||
helm:
|
||||
description: A Helm represents resources used by a Helm module
|
||||
properties:
|
||||
release:
|
||||
description: Release records a Helm release used by a Helm module workload.
|
||||
type: object
|
||||
x-kubernetes-preserve-unknown-fields: true
|
||||
repository:
|
||||
description: HelmRelease records a Helm repository used by a Helm module workload.
|
||||
type: object
|
||||
x-kubernetes-preserve-unknown-fields: true
|
||||
required:
|
||||
- release
|
||||
- repository
|
||||
type: object
|
||||
kube:
|
||||
description: Kube defines the encapsulation in raw Kubernetes resource format
|
||||
properties:
|
||||
parameters:
|
||||
description: Parameters defines configurable parameters
|
||||
items:
|
||||
description: A KubeParameter defines a configurable parameter of a component.
|
||||
properties:
|
||||
description:
|
||||
description: Description of this parameter.
|
||||
type: string
|
||||
fieldPaths:
|
||||
description: "FieldPaths specifies an array of fields within this workload that will be overwritten by the value of this parameter. \tAll fields must be of the same type. Fields are specified as JSON field paths without a leading dot, for example 'spec.replicas'."
|
||||
items:
|
||||
type: string
|
||||
type: array
|
||||
name:
|
||||
description: Name of this parameter
|
||||
type: string
|
||||
required:
|
||||
default: false
|
||||
description: Required specifies whether or not a value for this parameter must be supplied when authoring an Application.
|
||||
type: boolean
|
||||
type:
|
||||
description: 'ValueType indicates the type of the parameter value, and only supports basic data types: string, number, boolean.'
|
||||
enum:
|
||||
- string
|
||||
- number
|
||||
- boolean
|
||||
type: string
|
||||
required:
|
||||
- fieldPaths
|
||||
- name
|
||||
- type
|
||||
type: object
|
||||
type: array
|
||||
template:
|
||||
description: Template defines the raw Kubernetes resource
|
||||
type: object
|
||||
x-kubernetes-preserve-unknown-fields: true
|
||||
required:
|
||||
- template
|
||||
type: object
|
||||
terraform:
|
||||
description: Terraform is the struct to describe cloud resources managed by Hashicorp Terraform
|
||||
properties:
|
||||
configuration:
|
||||
description: Configuration is Terraform Configuration
|
||||
type: string
|
||||
type:
|
||||
default: hcl
|
||||
description: Type specifies which Terraform configuration it is, HCL or JSON syntax
|
||||
enum:
|
||||
- hcl
|
||||
- json
|
||||
type: string
|
||||
required:
|
||||
- configuration
|
||||
type: object
|
||||
type: object
|
||||
status:
|
||||
description: Status defines the custom health policy and status message for workload
|
||||
properties:
|
||||
customStatus:
|
||||
description: CustomStatus defines the custom status message that could display to user
|
||||
type: string
|
||||
healthPolicy:
|
||||
description: HealthPolicy defines the health check policy for the abstraction
|
||||
type: string
|
||||
type: object
|
||||
workload:
|
||||
description: Workload is a workload type descriptor
|
||||
properties:
|
||||
definition:
|
||||
description: Definition mutually exclusive to workload.type, a embedded WorkloadDefinition
|
||||
properties:
|
||||
apiVersion:
|
||||
type: string
|
||||
kind:
|
||||
type: string
|
||||
required:
|
||||
- apiVersion
|
||||
- kind
|
||||
type: object
|
||||
type:
|
||||
description: Type ref to a WorkloadDefinition via name
|
||||
type: string
|
||||
type: object
|
||||
required:
|
||||
- workload
|
||||
type: object
|
||||
status:
|
||||
description: ComponentDefinitionStatus is the status of ComponentDefinition
|
||||
properties:
|
||||
conditions:
|
||||
description: Conditions of the resource.
|
||||
items:
|
||||
description: A Condition that may apply to a resource.
|
||||
properties:
|
||||
lastTransitionTime:
|
||||
description: LastTransitionTime is the last time this condition transitioned from one status to another.
|
||||
format: date-time
|
||||
type: string
|
||||
message:
|
||||
description: A Message containing details about this condition's last transition from one status to another, if any.
|
||||
type: string
|
||||
reason:
|
||||
description: A Reason for this condition's last transition from one status to another.
|
||||
type: string
|
||||
status:
|
||||
description: Status of this condition; is it currently True, False, or Unknown?
|
||||
type: string
|
||||
type:
|
||||
description: Type of this condition. At most one of each condition type may apply to a resource at any point in time.
|
||||
type: string
|
||||
required:
|
||||
- lastTransitionTime
|
||||
- reason
|
||||
- status
|
||||
- type
|
||||
type: object
|
||||
type: array
|
||||
configMapRef:
|
||||
description: ConfigMapRef refer to a ConfigMap which contains OpenAPI V3 JSON schema of Component parameters.
|
||||
type: string
|
||||
latestRevision:
|
||||
description: LatestRevision of the component definition
|
||||
properties:
|
||||
name:
|
||||
type: string
|
||||
revision:
|
||||
format: int64
|
||||
type: integer
|
||||
revisionHash:
|
||||
description: RevisionHash record the hash value of the spec of ApplicationRevision object.
|
||||
type: string
|
||||
required:
|
||||
- name
|
||||
- revision
|
||||
type: object
|
||||
type: object
|
||||
type: object
|
||||
definitionType:
|
||||
description: DefinitionType
|
||||
enum:
|
||||
- Component
|
||||
- Trait
|
||||
type: string
|
||||
revision:
|
||||
description: Revision record revision number of DefinitionRevision
|
||||
format: int64
|
||||
type: integer
|
||||
revisionHash:
|
||||
description: RevisionHash record the hash value of the spec of DefinitionRevision object.
|
||||
type: string
|
||||
traitDefinition:
|
||||
description: TraitDefinition records the snapshot of the created/modified TraitDefinition
|
||||
properties:
|
||||
apiVersion:
|
||||
description: 'APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources'
|
||||
type: string
|
||||
kind:
|
||||
description: 'Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds'
|
||||
type: string
|
||||
metadata:
|
||||
type: object
|
||||
spec:
|
||||
description: A TraitDefinitionSpec defines the desired state of a TraitDefinition.
|
||||
properties:
|
||||
appliesToWorkloads:
|
||||
description: AppliesToWorkloads specifies the list of workload kinds this trait applies to. Workload kinds are specified in kind.group/version format, e.g. server.core.oam.dev/v1alpha2. Traits that omit this field apply to all workload kinds.
|
||||
items:
|
||||
type: string
|
||||
type: array
|
||||
conflictsWith:
|
||||
description: 'ConflictsWith specifies the list of traits(CRD name, Definition name, CRD group) which could not apply to the same workloads with this trait. Traits that omit this field can work with any other traits. Example rules: "service" # Trait definition name "services.k8s.io" # API resource/crd name "*.networking.k8s.io" # API group "labelSelector:foo=bar" # label selector labelSelector format: https://pkg.go.dev/k8s.io/apimachinery/pkg/labels#Parse'
|
||||
items:
|
||||
type: string
|
||||
type: array
|
||||
definitionRef:
|
||||
description: Reference to the CustomResourceDefinition that defines this trait kind.
|
||||
properties:
|
||||
name:
|
||||
description: Name of the referenced CustomResourceDefinition.
|
||||
type: string
|
||||
version:
|
||||
description: Version indicate which version should be used if CRD has multiple versions by default it will use the first one if not specified
|
||||
type: string
|
||||
required:
|
||||
- name
|
||||
type: object
|
||||
extension:
|
||||
description: Extension is used for extension needs by OAM platform builders
|
||||
type: object
|
||||
x-kubernetes-preserve-unknown-fields: true
|
||||
podDisruptive:
|
||||
description: PodDisruptive specifies whether using the trait will cause the pod to restart or not.
|
||||
type: boolean
|
||||
revisionEnabled:
|
||||
description: Revision indicates whether a trait is aware of component revision
|
||||
type: boolean
|
||||
schematic:
|
||||
description: Schematic defines the data format and template of the encapsulation of the trait
|
||||
properties:
|
||||
cue:
|
||||
description: CUE defines the encapsulation in CUE format
|
||||
properties:
|
||||
template:
|
||||
description: Template defines the abstraction template data of the capability, it will replace the old CUE template in extension field. Template is a required field if CUE is defined in Capability Definition.
|
||||
type: string
|
||||
required:
|
||||
- template
|
||||
type: object
|
||||
helm:
|
||||
description: A Helm represents resources used by a Helm module
|
||||
properties:
|
||||
release:
|
||||
description: Release records a Helm release used by a Helm module workload.
|
||||
type: object
|
||||
x-kubernetes-preserve-unknown-fields: true
|
||||
repository:
|
||||
description: HelmRelease records a Helm repository used by a Helm module workload.
|
||||
type: object
|
||||
x-kubernetes-preserve-unknown-fields: true
|
||||
required:
|
||||
- release
|
||||
- repository
|
||||
type: object
|
||||
kube:
|
||||
description: Kube defines the encapsulation in raw Kubernetes resource format
|
||||
properties:
|
||||
parameters:
|
||||
description: Parameters defines configurable parameters
|
||||
items:
|
||||
description: A KubeParameter defines a configurable parameter of a component.
|
||||
properties:
|
||||
description:
|
||||
description: Description of this parameter.
|
||||
type: string
|
||||
fieldPaths:
|
||||
description: "FieldPaths specifies an array of fields within this workload that will be overwritten by the value of this parameter. \tAll fields must be of the same type. Fields are specified as JSON field paths without a leading dot, for example 'spec.replicas'."
|
||||
items:
|
||||
type: string
|
||||
type: array
|
||||
name:
|
||||
description: Name of this parameter
|
||||
type: string
|
||||
required:
|
||||
default: false
|
||||
description: Required specifies whether or not a value for this parameter must be supplied when authoring an Application.
|
||||
type: boolean
|
||||
type:
|
||||
description: 'ValueType indicates the type of the parameter value, and only supports basic data types: string, number, boolean.'
|
||||
enum:
|
||||
- string
|
||||
- number
|
||||
- boolean
|
||||
type: string
|
||||
required:
|
||||
- fieldPaths
|
||||
- name
|
||||
- type
|
||||
type: object
|
||||
type: array
|
||||
template:
|
||||
description: Template defines the raw Kubernetes resource
|
||||
type: object
|
||||
x-kubernetes-preserve-unknown-fields: true
|
||||
required:
|
||||
- template
|
||||
type: object
|
||||
terraform:
|
||||
description: Terraform is the struct to describe cloud resources managed by Hashicorp Terraform
|
||||
properties:
|
||||
configuration:
|
||||
description: Configuration is Terraform Configuration
|
||||
type: string
|
||||
type:
|
||||
default: hcl
|
||||
description: Type specifies which Terraform configuration it is, HCL or JSON syntax
|
||||
enum:
|
||||
- hcl
|
||||
- json
|
||||
type: string
|
||||
required:
|
||||
- configuration
|
||||
type: object
|
||||
type: object
|
||||
status:
|
||||
description: Status defines the custom health policy and status message for trait
|
||||
properties:
|
||||
customStatus:
|
||||
description: CustomStatus defines the custom status message that could display to user
|
||||
type: string
|
||||
healthPolicy:
|
||||
description: HealthPolicy defines the health check policy for the abstraction
|
||||
type: string
|
||||
type: object
|
||||
workloadRefPath:
|
||||
description: WorkloadRefPath indicates where/if a trait accepts a workloadRef object
|
||||
type: string
|
||||
type: object
|
||||
status:
|
||||
description: TraitDefinitionStatus is the status of TraitDefinition
|
||||
properties:
|
||||
conditions:
|
||||
description: Conditions of the resource.
|
||||
items:
|
||||
description: A Condition that may apply to a resource.
|
||||
properties:
|
||||
lastTransitionTime:
|
||||
description: LastTransitionTime is the last time this condition transitioned from one status to another.
|
||||
format: date-time
|
||||
type: string
|
||||
message:
|
||||
description: A Message containing details about this condition's last transition from one status to another, if any.
|
||||
type: string
|
||||
reason:
|
||||
description: A Reason for this condition's last transition from one status to another.
|
||||
type: string
|
||||
status:
|
||||
description: Status of this condition; is it currently True, False, or Unknown?
|
||||
type: string
|
||||
type:
|
||||
description: Type of this condition. At most one of each condition type may apply to a resource at any point in time.
|
||||
type: string
|
||||
required:
|
||||
- lastTransitionTime
|
||||
- reason
|
||||
- status
|
||||
- type
|
||||
type: object
|
||||
type: array
|
||||
configMapRef:
|
||||
description: ConfigMapRef refer to a ConfigMap which contains OpenAPI V3 JSON schema of Component parameters.
|
||||
type: string
|
||||
latestRevision:
|
||||
description: LatestRevision of the component definition
|
||||
properties:
|
||||
name:
|
||||
type: string
|
||||
revision:
|
||||
format: int64
|
||||
type: integer
|
||||
revisionHash:
|
||||
description: RevisionHash record the hash value of the spec of ApplicationRevision object.
|
||||
type: string
|
||||
required:
|
||||
- name
|
||||
- revision
|
||||
type: object
|
||||
type: object
|
||||
type: object
|
||||
required:
|
||||
- definitionType
|
||||
- revision
|
||||
- revisionHash
|
||||
type: object
|
||||
type: object
|
||||
served: true
|
||||
storage: true
|
||||
subresources: {}
|
||||
status:
|
||||
acceptedNames:
|
||||
kind: ""
|
||||
plural: ""
|
||||
conditions: []
|
||||
storedVersions: []
|
||||
@@ -144,6 +144,22 @@ spec:
|
||||
required:
|
||||
- template
|
||||
type: object
|
||||
terraform:
|
||||
description: Terraform is the struct to describe cloud resources managed by Hashicorp Terraform
|
||||
properties:
|
||||
configuration:
|
||||
description: Configuration is Terraform Configuration
|
||||
type: string
|
||||
type:
|
||||
default: hcl
|
||||
description: Type specifies which Terraform configuration it is, HCL or JSON syntax
|
||||
enum:
|
||||
- hcl
|
||||
- json
|
||||
type: string
|
||||
required:
|
||||
- configuration
|
||||
type: object
|
||||
type: object
|
||||
status:
|
||||
description: Status defines the custom health policy and status message for trait
|
||||
@@ -193,6 +209,21 @@ spec:
|
||||
configMapRef:
|
||||
description: ConfigMapRef refer to a ConfigMap which contains OpenAPI V3 JSON schema of Component parameters.
|
||||
type: string
|
||||
latestRevision:
|
||||
description: LatestRevision of the trait definition
|
||||
properties:
|
||||
name:
|
||||
type: string
|
||||
revision:
|
||||
format: int64
|
||||
type: integer
|
||||
revisionHash:
|
||||
description: RevisionHash record the hash value of the spec of ApplicationRevision object.
|
||||
type: string
|
||||
required:
|
||||
- name
|
||||
- revision
|
||||
type: object
|
||||
type: object
|
||||
type: object
|
||||
served: true
|
||||
@@ -324,6 +355,22 @@ spec:
|
||||
required:
|
||||
- template
|
||||
type: object
|
||||
terraform:
|
||||
description: Terraform is the struct to describe cloud resources managed by Hashicorp Terraform
|
||||
properties:
|
||||
configuration:
|
||||
description: Configuration is Terraform Configuration
|
||||
type: string
|
||||
type:
|
||||
default: hcl
|
||||
description: Type specifies which Terraform configuration it is, HCL or JSON syntax
|
||||
enum:
|
||||
- hcl
|
||||
- json
|
||||
type: string
|
||||
required:
|
||||
- configuration
|
||||
type: object
|
||||
type: object
|
||||
status:
|
||||
description: Status defines the custom health policy and status message for trait
|
||||
@@ -373,6 +420,21 @@ spec:
|
||||
configMapRef:
|
||||
description: ConfigMapRef refer to a ConfigMap which contains OpenAPI V3 JSON schema of Component parameters.
|
||||
type: string
|
||||
latestRevision:
|
||||
description: LatestRevision of the component definition
|
||||
properties:
|
||||
name:
|
||||
type: string
|
||||
revision:
|
||||
format: int64
|
||||
type: integer
|
||||
revisionHash:
|
||||
description: RevisionHash record the hash value of the spec of ApplicationRevision object.
|
||||
type: string
|
||||
required:
|
||||
- name
|
||||
- revision
|
||||
type: object
|
||||
type: object
|
||||
type: object
|
||||
served: true
|
||||
|
||||
@@ -152,6 +152,22 @@ spec:
|
||||
required:
|
||||
- template
|
||||
type: object
|
||||
terraform:
|
||||
description: Terraform is the struct to describe cloud resources managed by Hashicorp Terraform
|
||||
properties:
|
||||
configuration:
|
||||
description: Configuration is Terraform Configuration
|
||||
type: string
|
||||
type:
|
||||
default: hcl
|
||||
description: Type specifies which Terraform configuration it is, HCL or JSON syntax
|
||||
enum:
|
||||
- hcl
|
||||
- json
|
||||
type: string
|
||||
required:
|
||||
- configuration
|
||||
type: object
|
||||
type: object
|
||||
status:
|
||||
description: Status defines the custom health policy and status message for workload
|
||||
@@ -338,6 +354,22 @@ spec:
|
||||
required:
|
||||
- template
|
||||
type: object
|
||||
terraform:
|
||||
description: Terraform is the struct to describe cloud resources managed by Hashicorp Terraform
|
||||
properties:
|
||||
configuration:
|
||||
description: Configuration is Terraform Configuration
|
||||
type: string
|
||||
type:
|
||||
default: hcl
|
||||
description: Type specifies which Terraform configuration it is, HCL or JSON syntax
|
||||
enum:
|
||||
- hcl
|
||||
- json
|
||||
type: string
|
||||
required:
|
||||
- configuration
|
||||
type: object
|
||||
type: object
|
||||
status:
|
||||
description: Status defines the custom health policy and status message for workload
|
||||
|
||||
@@ -116,8 +116,6 @@ webhooks:
|
||||
resources:
|
||||
- traitdefinitions
|
||||
scope: Cluster
|
||||
admissionReviewVersions:
|
||||
- v1beta1
|
||||
timeoutSeconds: 5
|
||||
- clientConfig:
|
||||
caBundle: Cg==
|
||||
@@ -140,5 +138,29 @@ webhooks:
|
||||
- UPDATE
|
||||
resources:
|
||||
- podspecworkloads
|
||||
|
||||
- clientConfig:
|
||||
caBundle: Cg==
|
||||
service:
|
||||
name: {{ template "kubevela.name" . }}-webhook
|
||||
namespace: {{ .Release.Namespace }}
|
||||
path: /validating-core-oam-dev-v1beta1-applications
|
||||
{{- if .Values.admissionWebhooks.patch.enabled }}
|
||||
failurePolicy: Ignore
|
||||
{{- else }}
|
||||
failurePolicy: {{ .Values.admissionWebhooks.failurePolicy }}
|
||||
{{- end }}
|
||||
name: validating.core.oam.dev.v1beta1.applications
|
||||
admissionReviewVersions:
|
||||
- v1beta1
|
||||
sideEffects: None
|
||||
rules:
|
||||
- apiGroups:
|
||||
- core.oam.dev
|
||||
apiVersions:
|
||||
- v1beta1
|
||||
operations:
|
||||
- CREATE
|
||||
- UPDATE
|
||||
resources:
|
||||
- applications
|
||||
{{- end -}}
|
||||
|
||||
@@ -8,8 +8,8 @@ metadata:
|
||||
namespace: {{.Values.systemDefinitionNamespace}}
|
||||
spec:
|
||||
appliesToWorkloads:
|
||||
- webservice
|
||||
- worker
|
||||
- deployments.apps
|
||||
podDisruptive: true
|
||||
schematic:
|
||||
cue:
|
||||
template: |-
|
||||
|
||||
@@ -3,7 +3,7 @@ apiVersion: core.oam.dev/v1beta1
|
||||
kind: TraitDefinition
|
||||
metadata:
|
||||
annotations:
|
||||
definition.oam.dev/description: "configure k8s HPA with CPU metrics for Deployment"
|
||||
definition.oam.dev/description: "Automatically scale the component based on CPU usage."
|
||||
name: cpuscaler
|
||||
namespace: {{.Values.systemDefinitionNamespace}}
|
||||
spec:
|
||||
@@ -13,7 +13,7 @@ spec:
|
||||
schematic:
|
||||
cue:
|
||||
template: |
|
||||
outputs: cpuhpa: {
|
||||
outputs: cpuscaler: {
|
||||
apiVersion: "autoscaling/v2beta2"
|
||||
kind: "HorizontalPodAutoscaler"
|
||||
metadata: name: context.name
|
||||
@@ -3,18 +3,23 @@ apiVersion: core.oam.dev/v1beta1
|
||||
kind: TraitDefinition
|
||||
metadata:
|
||||
annotations:
|
||||
definition.oam.dev/description: "Configures K8s ingress and service to enable web traffic for your service.
|
||||
Please use route trait in cap center for advanced usage."
|
||||
definition.oam.dev/description: "Enable public web traffic for the component."
|
||||
name: ingress
|
||||
namespace: {{.Values.systemDefinitionNamespace}}
|
||||
spec:
|
||||
status:
|
||||
customStatus: |-
|
||||
if len(context.outputs.ingress.status.loadBalancer.ingress) > 0 {
|
||||
message: "Visiting URL: " + context.outputs.ingress.spec.rules[0].host + ", IP: " + context.outputs.ingress.status.loadBalancer.ingress[0].ip
|
||||
let igs = context.outputs.ingress.status.loadBalancer.ingress
|
||||
if igs == _|_ {
|
||||
message: "No loadBalancer found, visiting by using 'vela port-forward " + context.appName + " --route'\n"
|
||||
}
|
||||
if len(context.outputs.ingress.status.loadBalancer.ingress) == 0 {
|
||||
message: "No loadBalancer found, visiting by using 'vela port-forward " + context.appName + " --route'\n"
|
||||
if len(igs) > 0 {
|
||||
if igs[0].ip != _|_ {
|
||||
message: "Visiting URL: " + context.outputs.ingress.spec.rules[0].host + ", IP: " + igs[0].ip
|
||||
}
|
||||
if igs[0].ip == _|_ {
|
||||
message: "Visiting URL: " + context.outputs.ingress.spec.rules[0].host
|
||||
}
|
||||
}
|
||||
healthPolicy: |
|
||||
isHealth: len(context.outputs.service.spec.clusterIP) > 0
|
||||
|
||||
@@ -8,8 +8,8 @@ metadata:
|
||||
namespace: {{.Values.systemDefinitionNamespace}}
|
||||
spec:
|
||||
appliesToWorkloads:
|
||||
- webservice
|
||||
- worker
|
||||
- deployments.apps
|
||||
podDisruptive: true
|
||||
schematic:
|
||||
cue:
|
||||
template: |-
|
||||
|
||||
@@ -3,7 +3,7 @@ apiVersion: core.oam.dev/v1beta1
|
||||
kind: TraitDefinition
|
||||
metadata:
|
||||
annotations:
|
||||
definition.oam.dev/description: "Configures replicas for your service by patch replicas field."
|
||||
definition.oam.dev/description: "Manually scale the component."
|
||||
name: scaler
|
||||
namespace: {{.Values.systemDefinitionNamespace}}
|
||||
spec:
|
||||
@@ -3,22 +3,24 @@ apiVersion: core.oam.dev/v1beta1
|
||||
kind: TraitDefinition
|
||||
metadata:
|
||||
annotations:
|
||||
definition.oam.dev/description: "inject a sidecar container into your app"
|
||||
definition.oam.dev/description: "Inject a sidecar container to the component."
|
||||
name: sidecar
|
||||
namespace: {{.Values.systemDefinitionNamespace}}
|
||||
spec:
|
||||
appliesToWorkloads:
|
||||
- webservice
|
||||
- worker
|
||||
- deployments.apps
|
||||
podDisruptive: true
|
||||
schematic:
|
||||
cue:
|
||||
template: |-
|
||||
patch: {
|
||||
// +patchKey=name
|
||||
spec: template: spec: containers: [{
|
||||
name: parameter.name
|
||||
image: parameter.image
|
||||
command: parameter.cmd
|
||||
name: parameter.name
|
||||
image: parameter.image
|
||||
if parameter.cmd != _|_ {
|
||||
command: parameter.cmd
|
||||
}
|
||||
if parameter["volumes"] != _|_ {
|
||||
volumeMounts: [ for v in parameter.volumes {
|
||||
{
|
||||
|
||||
@@ -36,15 +36,6 @@ spec:
|
||||
command: parameter.cmd
|
||||
}
|
||||
|
||||
if parameter["volumes"] != _|_ {
|
||||
volumeMounts: [ for v in parameter.volumes {
|
||||
{
|
||||
mountPath: v.mountPath
|
||||
name: v.name
|
||||
}
|
||||
}]
|
||||
}
|
||||
|
||||
if parameter["volumes"] != _|_ {
|
||||
volumeMounts: [ for v in parameter.volumes {
|
||||
{
|
||||
|
||||
@@ -107,6 +107,13 @@ spec:
|
||||
args:
|
||||
- "--metrics-addr=:8080"
|
||||
- "--enable-leader-election"
|
||||
{{ if ne .Values.logFilePath "" }}
|
||||
- "--log-file-path={{ .Values.logFilePath }}"
|
||||
- "--log-file-max-size={{ .Values.logFileMaxSize }}"
|
||||
{{ end }}
|
||||
{{ if .Values.logDebug }}
|
||||
- "--log-debug=true"
|
||||
{{ end }}
|
||||
{{ if .Values.admissionWebhooks.enabled }}
|
||||
- "--use-webhook=true"
|
||||
- "--webhook-port={{ .Values.webhookService.port }}"
|
||||
@@ -122,6 +129,7 @@ spec:
|
||||
{{ end }}
|
||||
- "--system-definition-namespace={{ .Values.systemDefinitionNamespace }}"
|
||||
- "--application-revision-limit={{ .Values.applicationRevisionLimit }}"
|
||||
- "--definition-revision-limit={{ .Values.definitionRevisionLimit }}"
|
||||
image: {{ .Values.image.repository }}:{{ .Values.image.tag }}
|
||||
imagePullPolicy: {{ quote .Values.image.pullPolicy }}
|
||||
resources:
|
||||
|
||||
@@ -79,6 +79,21 @@ admissionWebhooks:
|
||||
enabled: false
|
||||
|
||||
|
||||
#If non-empty, write log files in this path
|
||||
logFilePath: ""
|
||||
|
||||
#Defines the maximum size a log file can grow to. Unit is megabytes.
|
||||
#If the value is 0, the maximum file size is unlimited.
|
||||
logFileMaxSize: 1024
|
||||
|
||||
systemDefinitionNamespace: vela-system
|
||||
|
||||
applicationRevisionLimit: 10
|
||||
|
||||
definitionRevisionLimit: 20
|
||||
|
||||
# concurrentReconciles is the concurrent reconcile number of the controller
|
||||
concurrentReconciles: 4
|
||||
|
||||
# dependCheckWait is the time to wait for ApplicationConfiguration's dependent-resource ready
|
||||
dependCheckWait: 30s
|
||||
130
cmd/core/main.go
130
cmd/core/main.go
@@ -22,21 +22,17 @@ import (
|
||||
"fmt"
|
||||
"io"
|
||||
"os"
|
||||
"os/signal"
|
||||
"path/filepath"
|
||||
"strconv"
|
||||
"strings"
|
||||
"syscall"
|
||||
"time"
|
||||
|
||||
"github.com/crossplane/crossplane-runtime/pkg/logging"
|
||||
"go.uber.org/zap/zapcore"
|
||||
"gopkg.in/natefinch/lumberjack.v2"
|
||||
"k8s.io/klog/v2"
|
||||
ctrl "sigs.k8s.io/controller-runtime"
|
||||
"sigs.k8s.io/controller-runtime/pkg/healthz"
|
||||
"sigs.k8s.io/controller-runtime/pkg/log/zap"
|
||||
|
||||
standardcontroller "github.com/oam-dev/kubevela/pkg/controller"
|
||||
commonconfig "github.com/oam-dev/kubevela/pkg/controller/common"
|
||||
oamcontroller "github.com/oam-dev/kubevela/pkg/controller/core.oam.dev"
|
||||
oamv1alpha2 "github.com/oam-dev/kubevela/pkg/controller/core.oam.dev/v1alpha2"
|
||||
"github.com/oam-dev/kubevela/pkg/controller/utils"
|
||||
@@ -55,7 +51,6 @@ const (
|
||||
)
|
||||
|
||||
var (
|
||||
setupLog = ctrl.Log.WithName(kubevelaName)
|
||||
scheme = common.Scheme
|
||||
waitSecretTimeout = 90 * time.Second
|
||||
waitSecretInterval = 2 * time.Second
|
||||
@@ -63,8 +58,8 @@ var (
|
||||
|
||||
func main() {
|
||||
var metricsAddr, logFilePath, leaderElectionNamespace string
|
||||
var enableLeaderElection, logCompress, logDebug bool
|
||||
var logRetainDate int
|
||||
var enableLeaderElection, logDebug bool
|
||||
var logFileMaxSize uint64
|
||||
var certDir string
|
||||
var webhookPort int
|
||||
var useWebhook bool
|
||||
@@ -84,13 +79,14 @@ func main() {
|
||||
flag.StringVar(&leaderElectionNamespace, "leader-election-namespace", "",
|
||||
"Determines the namespace in which the leader election configmap will be created.")
|
||||
flag.StringVar(&logFilePath, "log-file-path", "", "The file to write logs to.")
|
||||
flag.IntVar(&logRetainDate, "log-retain-date", 7, "The number of days of logs history to retain.")
|
||||
flag.BoolVar(&logCompress, "log-compress", true, "Enable compression on the rotated logs.")
|
||||
flag.Uint64Var(&logFileMaxSize, "log-file-max-size", 1024, "Defines the maximum size a log file can grow to, Unit is megabytes.")
|
||||
flag.BoolVar(&logDebug, "log-debug", false, "Enable debug logs for development purpose")
|
||||
flag.IntVar(&controllerArgs.RevisionLimit, "revision-limit", 50,
|
||||
"RevisionLimit is the maximum number of revisions that will be maintained. The default value is 50.")
|
||||
flag.IntVar(&controllerArgs.AppRevisionLimit, "application-revision-limit", 10,
|
||||
"application-revision-limit is the maximum number of application useless revisions that will be maintained, if the useless revisions exceed this number, older ones will be GCed first.The default value is 10.")
|
||||
flag.IntVar(&controllerArgs.DefRevisionLimit, "definition-revision-limit", 20,
|
||||
"definition-revision-limit is the maximum number of component/trait definition useless revisions that will be maintained, if the useless revisions exceed this number, older ones will be GCed first.The default value is 20.")
|
||||
flag.StringVar(&controllerArgs.CustomRevisionHookURL, "custom-revision-hook-url", "",
|
||||
"custom-revision-hook-url is a webhook url which will let KubeVela core to call with applicationConfiguration and component info and return a customized component revision")
|
||||
flag.BoolVar(&controllerArgs.ApplicationConfigurationInstalled, "app-config-installed", true,
|
||||
@@ -103,29 +99,26 @@ func main() {
|
||||
flag.DurationVar(&syncPeriod, "informer-re-sync-interval", 60*time.Minute,
|
||||
"controller shared informer lister full re-sync period")
|
||||
flag.StringVar(&oam.SystemDefinitonNamespace, "system-definition-namespace", "vela-system", "define the namespace of the system-level definition")
|
||||
flag.Parse()
|
||||
flag.IntVar(&controllerArgs.ConcurrentReconciles, "concurrent-reconciles", 4, "concurrent-reconciles is the concurrent reconcile number of the controller. The default value is 4")
|
||||
flag.DurationVar(&controllerArgs.DependCheckWait, "depend-check-wait", 30*time.Second, "depend-check-wait is the time to wait for ApplicationConfiguration's dependent-resource ready."+
|
||||
"The default value is 30s, which means if dependent resources were not prepared, the ApplicationConfiguration would be reconciled after 30s.")
|
||||
|
||||
flag.Parse()
|
||||
// setup logging
|
||||
var w io.Writer
|
||||
if len(logFilePath) > 0 {
|
||||
w = zapcore.AddSync(&lumberjack.Logger{
|
||||
Filename: logFilePath,
|
||||
MaxAge: logRetainDate, // days
|
||||
Compress: logCompress,
|
||||
})
|
||||
} else {
|
||||
w = os.Stdout
|
||||
klog.InitFlags(nil)
|
||||
if logDebug {
|
||||
_ = flag.Set("v", strconv.Itoa(int(commonconfig.LogDebug)))
|
||||
}
|
||||
|
||||
logger := zap.New(func(o *zap.Options) {
|
||||
o.Development = logDebug
|
||||
o.DestWritter = w
|
||||
})
|
||||
ctrl.SetLogger(logger)
|
||||
if logFilePath != "" {
|
||||
_ = flag.Set("logtostderr", "false")
|
||||
_ = flag.Set("log_file", logFilePath)
|
||||
_ = flag.Set("log_file_max_size", strconv.FormatUint(logFileMaxSize, 10))
|
||||
}
|
||||
|
||||
setupLog.Info(fmt.Sprintf("KubeVela Version: %s, GIT Revision: %s.", version.VelaVersion, version.GitRevision))
|
||||
setupLog.Info(fmt.Sprintf("Disable Capabilities: %s.", disableCaps))
|
||||
setupLog.Info(fmt.Sprintf("core init with definition namespace %s", oam.SystemDefinitonNamespace))
|
||||
klog.InfoS("KubeVela information", "version", version.VelaVersion, "revision", version.GitRevision)
|
||||
klog.InfoS("Disable capabilities", "name", disableCaps)
|
||||
klog.InfoS("Vela-Core init", "definition namespace", oam.SystemDefinitonNamespace)
|
||||
|
||||
restConfig := ctrl.GetConfigOrDie()
|
||||
restConfig.UserAgent = kubevelaName + "/" + version.GitRevision
|
||||
@@ -142,91 +135,96 @@ func main() {
|
||||
SyncPeriod: &syncPeriod,
|
||||
})
|
||||
if err != nil {
|
||||
setupLog.Error(err, "unable to create a controller manager")
|
||||
klog.ErrorS(err, "Unable to create a controller manager")
|
||||
os.Exit(1)
|
||||
}
|
||||
|
||||
if err := registerHealthChecks(mgr); err != nil {
|
||||
setupLog.Error(err, "unable to register ready/health checks")
|
||||
klog.ErrorS(err, "Unable to register ready/health checks")
|
||||
os.Exit(1)
|
||||
}
|
||||
|
||||
if err := utils.CheckDisabledCapabilities(disableCaps); err != nil {
|
||||
setupLog.Error(err, "unable to get enabled capabilities")
|
||||
klog.ErrorS(err, "Unable to get enabled capabilities")
|
||||
os.Exit(1)
|
||||
}
|
||||
|
||||
switch strings.ToLower(applyOnceOnly) {
|
||||
case "", "false", string(oamcontroller.ApplyOnceOnlyOff):
|
||||
controllerArgs.ApplyMode = oamcontroller.ApplyOnceOnlyOff
|
||||
setupLog.Info("ApplyOnceOnly is disabled")
|
||||
klog.Info("ApplyOnceOnly is disabled")
|
||||
case "true", string(oamcontroller.ApplyOnceOnlyOn):
|
||||
controllerArgs.ApplyMode = oamcontroller.ApplyOnceOnlyOn
|
||||
setupLog.Info("ApplyOnceOnly is enabled, that means workload or trait only apply once if no spec change even they are changed by others")
|
||||
klog.Info("ApplyOnceOnly is enabled, that means workload or trait only apply once if no spec change even they are changed by others")
|
||||
case string(oamcontroller.ApplyOnceOnlyForce):
|
||||
controllerArgs.ApplyMode = oamcontroller.ApplyOnceOnlyForce
|
||||
setupLog.Info("ApplyOnceOnlyForce is enabled, that means workload or trait only apply once if no spec change even they are changed or deleted by others")
|
||||
klog.Info("ApplyOnceOnlyForce is enabled, that means workload or trait only apply once if no spec change even they are changed or deleted by others")
|
||||
default:
|
||||
setupLog.Error(fmt.Errorf("invalid apply-once-only value: %s", applyOnceOnly),
|
||||
"unable to setup the vela core controller",
|
||||
"valid apply-once-only value:", "on/off/force, by default it's off")
|
||||
klog.ErrorS(fmt.Errorf("invalid apply-once-only value: %s", applyOnceOnly),
|
||||
"Unable to setup the vela core controller",
|
||||
"apply-once-only", "on/off/force, by default it's off")
|
||||
os.Exit(1)
|
||||
}
|
||||
|
||||
dm, err := discoverymapper.New(mgr.GetConfig())
|
||||
if err != nil {
|
||||
setupLog.Error(err, "failed to create CRD discovery client")
|
||||
klog.ErrorS(err, "Failed to create CRD discovery client")
|
||||
os.Exit(1)
|
||||
}
|
||||
controllerArgs.DiscoveryMapper = dm
|
||||
pd, err := definition.NewPackageDiscover(mgr.GetConfig())
|
||||
if err != nil {
|
||||
setupLog.Error(err, "failed to create CRD discovery for CUE package client")
|
||||
os.Exit(1)
|
||||
klog.Error(err, "Failed to create CRD discovery for CUE package client")
|
||||
if !definition.IsCUEParseErr(err) {
|
||||
os.Exit(1)
|
||||
}
|
||||
}
|
||||
controllerArgs.PackageDiscover = pd
|
||||
|
||||
if useWebhook {
|
||||
setupLog.Info("vela webhook enabled, will serving at :" + strconv.Itoa(webhookPort))
|
||||
klog.InfoS("Enable webhook", "server port", strconv.Itoa(webhookPort))
|
||||
oamwebhook.Register(mgr, controllerArgs)
|
||||
velawebhook.Register(mgr, disableCaps)
|
||||
if err := waitWebhookSecretVolume(certDir, waitSecretTimeout, waitSecretInterval); err != nil {
|
||||
setupLog.Error(err, "unable to get webhook secret")
|
||||
klog.ErrorS(err, "Unable to get webhook secret")
|
||||
os.Exit(1)
|
||||
}
|
||||
}
|
||||
|
||||
if err = oamv1alpha2.Setup(mgr, controllerArgs, logging.NewLogrLogger(setupLog)); err != nil {
|
||||
setupLog.Error(err, "unable to setup the oam core controller")
|
||||
if err = oamv1alpha2.Setup(mgr, controllerArgs); err != nil {
|
||||
klog.ErrorS(err, "Unable to setup the oam core controller")
|
||||
os.Exit(1)
|
||||
}
|
||||
|
||||
if err = standardcontroller.Setup(mgr, disableCaps); err != nil {
|
||||
setupLog.Error(err, "unable to setup the vela core controller")
|
||||
klog.ErrorS(err, "Unable to setup the vela core controller")
|
||||
os.Exit(1)
|
||||
}
|
||||
if driver := os.Getenv(system.StorageDriverEnv); len(driver) == 0 {
|
||||
// first use system environment,
|
||||
err := os.Setenv(system.StorageDriverEnv, storageDriver)
|
||||
if err != nil {
|
||||
setupLog.Error(err, "unable to setup the vela core controller")
|
||||
klog.ErrorS(err, "Unable to setup the vela core controller")
|
||||
os.Exit(1)
|
||||
}
|
||||
}
|
||||
setupLog.Info("use storage driver", "storageDriver", os.Getenv(system.StorageDriverEnv))
|
||||
klog.InfoS("Use storage driver", "storageDriver", os.Getenv(system.StorageDriverEnv))
|
||||
|
||||
setupLog.Info("starting the vela controller manager")
|
||||
klog.Info("Start the vela controller manager")
|
||||
|
||||
if err := mgr.Start(makeSignalHandler()); err != nil {
|
||||
setupLog.Error(err, "problem running manager")
|
||||
if err := mgr.Start(ctrl.SetupSignalHandler()); err != nil {
|
||||
klog.ErrorS(err, "Failed to run manager")
|
||||
os.Exit(1)
|
||||
}
|
||||
setupLog.Info("program safely stops...")
|
||||
if logFilePath != "" {
|
||||
klog.Flush()
|
||||
}
|
||||
klog.Info("Safely stops Program...")
|
||||
}
|
||||
|
||||
// registerHealthChecks is used to create readiness&liveness probes
|
||||
func registerHealthChecks(mgr ctrl.Manager) error {
|
||||
setupLog.Info("creating readiness/health check")
|
||||
klog.Info("Create readiness/health check")
|
||||
if err := mgr.AddReadyzCheck("ping", healthz.Ping); err != nil {
|
||||
return err
|
||||
}
|
||||
@@ -245,8 +243,8 @@ func waitWebhookSecretVolume(certDir string, timeout, interval time.Duration) er
|
||||
if time.Since(start) > timeout {
|
||||
return fmt.Errorf("getting webhook secret timeout after %s", timeout.String())
|
||||
}
|
||||
setupLog.Info(fmt.Sprintf("waiting webhook secret, time consumed: %d/%d seconds ...",
|
||||
int64(time.Since(start).Seconds()), int64(timeout.Seconds())))
|
||||
klog.InfoS("Wait webhook secret", "time consumed(second)", int64(time.Since(start).Seconds()),
|
||||
"timeout(second)", int64(timeout.Seconds()))
|
||||
if _, err := os.Stat(certDir); !os.IsNotExist(err) {
|
||||
ready := func() bool {
|
||||
f, err := os.Open(filepath.Clean(certDir))
|
||||
@@ -268,8 +266,8 @@ func waitWebhookSecretVolume(certDir string, timeout, interval time.Duration) er
|
||||
return nil
|
||||
})
|
||||
if err == nil {
|
||||
setupLog.Info(fmt.Sprintf("webhook secret is ready (time consumed: %d seconds)",
|
||||
int64(time.Since(start).Seconds())))
|
||||
klog.InfoS("Webhook secret is ready", "time consumed(second)",
|
||||
int64(time.Since(start).Seconds()))
|
||||
return true
|
||||
}
|
||||
return false
|
||||
@@ -280,21 +278,3 @@ func waitWebhookSecretVolume(certDir string, timeout, interval time.Duration) er
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
func makeSignalHandler() (stopCh <-chan struct{}) {
|
||||
stop := make(chan struct{})
|
||||
c := make(chan os.Signal, 2)
|
||||
|
||||
signal.Notify(c, os.Interrupt, syscall.SIGTERM)
|
||||
|
||||
go func() {
|
||||
<-c
|
||||
close(stop)
|
||||
|
||||
// second signal. Exit directly.
|
||||
<-c
|
||||
os.Exit(1)
|
||||
}()
|
||||
|
||||
return stop
|
||||
}
|
||||
|
||||
64
cmd/core/main_e2e_test.go
Normal file
64
cmd/core/main_e2e_test.go
Normal file
@@ -0,0 +1,64 @@
|
||||
/*
|
||||
Copyright 2021 The KubeVela Authors.
|
||||
Licensed under the Apache License, Version 2.0 (the "License");
|
||||
you may not use this file except in compliance with the License.
|
||||
You may obtain a copy of the License at
|
||||
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing, software
|
||||
distributed under the License is distributed on an "AS IS" BASIS,
|
||||
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
||||
See the License for the specific language governing permissions and
|
||||
limitations under the License.
|
||||
*/
|
||||
|
||||
package main
|
||||
|
||||
import (
|
||||
"fmt"
|
||||
"os"
|
||||
"os/signal"
|
||||
"strings"
|
||||
"syscall"
|
||||
"testing"
|
||||
)
|
||||
|
||||
func TestE2EMain(t *testing.T) {
|
||||
fmt.Println("this is e2e test")
|
||||
var (
|
||||
args []string
|
||||
run bool
|
||||
)
|
||||
|
||||
for _, arg := range os.Args {
|
||||
switch {
|
||||
case strings.HasPrefix(arg, "__DEVEL__E2E"):
|
||||
run = true
|
||||
case strings.HasPrefix(arg, "-test"):
|
||||
default:
|
||||
args = append(args, arg)
|
||||
}
|
||||
}
|
||||
|
||||
if !run {
|
||||
return
|
||||
}
|
||||
|
||||
waitCh := make(chan int, 1)
|
||||
|
||||
//args=append(args, "leader-election-namespace='someNS'")
|
||||
os.Args = args
|
||||
go func() {
|
||||
main()
|
||||
close(waitCh)
|
||||
}()
|
||||
|
||||
signalCh := make(chan os.Signal, 1)
|
||||
signal.Notify(signalCh, syscall.SIGINT, syscall.SIGQUIT, syscall.SIGTERM, syscall.SIGHUP)
|
||||
select {
|
||||
case <-signalCh:
|
||||
case <-waitCh:
|
||||
}
|
||||
fmt.Println("exit test e2e main")
|
||||
}
|
||||
@@ -2,5 +2,7 @@ coverage:
|
||||
status:
|
||||
project:
|
||||
default:
|
||||
threshold: 0.5%
|
||||
patch: off
|
||||
threshold: 0.1%
|
||||
patch:
|
||||
default:
|
||||
target: 70%
|
||||
|
||||
@@ -27,7 +27,7 @@ This design is based on and tries to resolve the following use cases:
|
||||
|
||||
The overall architecture diagram:
|
||||
|
||||

|
||||

|
||||
|
||||
Here's some explanation of the diagram:
|
||||
|
||||
@@ -39,13 +39,13 @@ Here's some explanation of the diagram:
|
||||
|
||||
The above architecture implies that the Vela APIServer could be used to multiple k8s clusters and catalogs. Below is what a deployment of Vela platform would look like:
|
||||
|
||||

|
||||

|
||||
|
||||
### 2. API Design
|
||||
|
||||
Below is the overall architecture of API grouping and storage:
|
||||
|
||||

|
||||

|
||||
|
||||
There are two distinguished layers:
|
||||
- **API layer**: It defines the API discovery and serving endpoints that Vela APIServer implementation must follow. This is the integration point for external system components (e.g. UI) to contact.
|
||||
@@ -313,7 +313,7 @@ Under the hood, APIServer will rescan the catalog.
|
||||
|
||||
Vela APIServer aggregates package information from multiple catalog servers. To download a package, the user first requests the APIServer to find the location of the catalog and the package. Then the user visits the catalog repo directly to download the package data. The workflow is shown as below:
|
||||
|
||||

|
||||

|
||||
|
||||
In our future roadmap, we will build a catalog controller for each k8s cluster. Then we will add API endpoint to install the package in APIServer which basically creates a CR to trigger the controller to reconcile package installation into the cluster. We choose this instead of APIServer installing the package because in this way we can bypass the APIServer in the package data transfer path and avoid APIServer becoming a single point of failure.
|
||||
|
||||
|
||||
@@ -293,7 +293,7 @@ the following fields:
|
||||
## State Transition
|
||||
Here is the state transition graph
|
||||
|
||||

|
||||

|
||||
|
||||
Here are the various top-level states of the rollout
|
||||
```go
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
# KubeVela
|
||||
|
||||
KubeVela is a modern application engine that adapts to your application's needs, not the other way around.
|
||||
KubeVela is a modern application platform that makes deploying and managing applications across today's hybrid, multi-cloud environments easier and faster.
|
||||
|
||||
## Community
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Advanced Topics for Installation
|
||||
title: Other Install Topics
|
||||
---
|
||||
|
||||
## Install KubeVela with cert-manager
|
||||
@@ -108,7 +108,6 @@ Then clean up CRDs (CRDs are not removed via helm by default):
|
||||
appdeployments.core.oam.dev \
|
||||
applicationconfigurations.core.oam.dev \
|
||||
applicationcontexts.core.oam.dev \
|
||||
applicationdeployments.core.oam.dev \
|
||||
applicationrevisions.core.oam.dev \
|
||||
applications.core.oam.dev \
|
||||
approllouts.core.oam.dev \
|
||||
|
||||
@@ -1,149 +0,0 @@
|
||||
---
|
||||
title: Deploy Application
|
||||
---
|
||||
|
||||
This documentation will walk through a full application deployment workflow on KubeVela platform.
|
||||
|
||||
## Introduction
|
||||
|
||||
KubeVela is a fully self-service platform. All capabilities an application deployment needs are maintained as building block modules in this platform. Specifically:
|
||||
- Components - deployable/provisionable entities that composed your application deployment
|
||||
- e.g. a Kubernetes workload, a MySQL database, or a AWS OSS bucket
|
||||
- Traits - attachable operational features per your needs
|
||||
- e.g. autoscaling rules, rollout strategies, ingress rules, sidecars, security policies etc
|
||||
|
||||
## Step 1: Check Capabilities in the Platform
|
||||
|
||||
As user of this platform, you could check available components you can deploy, and available traits you can attach.
|
||||
|
||||
```console
|
||||
$ kubectl get componentdefinitions -n vela-system
|
||||
NAME WORKLOAD-KIND DESCRIPTION AGE
|
||||
task Job Describes jobs that run code or a script to completion. 5h52m
|
||||
webservice Deployment Describes long-running, scalable, containerized services that have a stable network endpoint to receive external network traffic from customers. 5h52m
|
||||
worker Deployment Describes long-running, scalable, containerized services that running at backend. They do NOT have network endpoint to receive external network traffic. 5h52m
|
||||
```
|
||||
|
||||
```console
|
||||
$ kubectl get traitdefinitions -n vela-system
|
||||
NAME APPLIES-TO DESCRIPTION AGE
|
||||
ingress ["webservice","worker"] Configures K8s ingress and service to enable web traffic for your service. Please use route trait in cap center for advanced usage. 6h8m
|
||||
cpuscaler ["webservice","worker"] Configure k8s HPA with CPU metrics for Deployment 6h8m
|
||||
```
|
||||
|
||||
To show the specification for given capability, you could use `vela` CLI. For example, `vela show webservice` will return full schema of *Web Service* component and `vela show webservice --web` will open its capability reference documentation in your browser.
|
||||
|
||||
## Step 2: Design and Deploy Application
|
||||
|
||||
In KubeVela, `Application` is the main API to define your application deployment based on available capabilities. Every `Application` could contain multiple components, each of them can be attached with a number of traits per needs.
|
||||
|
||||
Now let's define an application composed by *Web Service* and *Worker* components.
|
||||
|
||||
```yaml
|
||||
# sample.yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: website
|
||||
spec:
|
||||
components:
|
||||
- name: frontend
|
||||
type: webservice
|
||||
properties:
|
||||
image: nginx
|
||||
traits:
|
||||
- type: cpuscaler
|
||||
properties:
|
||||
min: 1
|
||||
max: 10
|
||||
cpuPercent: 60
|
||||
- type: sidecar
|
||||
properties:
|
||||
name: "sidecar-test"
|
||||
image: "fluentd"
|
||||
- name: backend
|
||||
type: worker
|
||||
properties:
|
||||
image: busybox
|
||||
cmd:
|
||||
- sleep
|
||||
- '1000'
|
||||
```
|
||||
|
||||
In this sample, we also attached `sidecar` and `cpuscaler` traits to the `frontend` component.
|
||||
So after deployed, the `frontend` component instance (a Kubernetes Deployment workload) will be automatically injected
|
||||
with a `fluentd` sidecar and automatically scale from 1-10 replicas based on CPU usage.
|
||||
|
||||
### Deploy the Application
|
||||
|
||||
Apply application YAML to Kubernetes:
|
||||
|
||||
```shell
|
||||
$ kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/enduser/sample.yaml
|
||||
application.core.oam.dev/website created
|
||||
```
|
||||
|
||||
You'll get the application becomes `running`.
|
||||
|
||||
```shell
|
||||
$ kubectl get application website -o yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: website
|
||||
....
|
||||
status:
|
||||
components:
|
||||
- apiVersion: core.oam.dev/v1alpha2
|
||||
kind: Component
|
||||
name: backend
|
||||
- apiVersion: core.oam.dev/v1alpha2
|
||||
kind: Component
|
||||
name: frontend
|
||||
....
|
||||
status: running
|
||||
|
||||
```
|
||||
|
||||
### Verify the Deployment
|
||||
|
||||
You could see a Deployment named `frontend` is running, with port exposed, and with a container `fluentd` injected.
|
||||
|
||||
```shell
|
||||
$ kubectl get deploy frontend
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
frontend 1/1 1 1 97s
|
||||
```
|
||||
|
||||
```shell
|
||||
$ kubectl get deploy frontend -o yaml
|
||||
...
|
||||
spec:
|
||||
containers:
|
||||
- image: nginx
|
||||
imagePullPolicy: Always
|
||||
name: frontend
|
||||
ports:
|
||||
- containerPort: 80
|
||||
protocol: TCP
|
||||
- image: fluentd
|
||||
imagePullPolicy: Always
|
||||
name: sidecar-test
|
||||
...
|
||||
```
|
||||
|
||||
Another Deployment is also running named `backend`.
|
||||
|
||||
```shell
|
||||
$ kubectl get deploy backend
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
backend 1/1 1 1 111s
|
||||
```
|
||||
|
||||
An HPA was also created by the `cpuscaler` trait.
|
||||
|
||||
```shell
|
||||
$ kubectl get HorizontalPodAutoscaler frontend
|
||||
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
|
||||
frontend Deployment/frontend <unknown>/50% 1 10 1 101m
|
||||
```
|
||||
35
docs/en/cli/vela_system_cue-packages.md
Normal file
35
docs/en/cli/vela_system_cue-packages.md
Normal file
@@ -0,0 +1,35 @@
|
||||
## vela system cue-packages
|
||||
|
||||
List cue package
|
||||
|
||||
### Synopsis
|
||||
|
||||
List cue package
|
||||
|
||||
```
|
||||
vela system cue-packages
|
||||
```
|
||||
|
||||
### Examples
|
||||
|
||||
```
|
||||
vela system cue-packages
|
||||
```
|
||||
|
||||
### Options
|
||||
|
||||
```
|
||||
-h, --help help for cue-packages
|
||||
```
|
||||
|
||||
### Options inherited from parent commands
|
||||
|
||||
```
|
||||
-e, --env string specify environment name for application
|
||||
```
|
||||
|
||||
### SEE ALSO
|
||||
|
||||
* [vela system](vela_system.md) - System management utilities
|
||||
|
||||
###### Auto generated by spf13/cobra on 2-May-2021
|
||||
39
docs/en/cli/vela_system_live-diff.md
Normal file
39
docs/en/cli/vela_system_live-diff.md
Normal file
@@ -0,0 +1,39 @@
|
||||
## vela system live-diff
|
||||
|
||||
Dry-run an application, and do diff on a specific app revison
|
||||
|
||||
### Synopsis
|
||||
|
||||
Dry-run an application, and do diff on a specific app revison. The provided capability definitions will be used during Dry-run. If any capabilities used in the app are not found in the provided ones, it will try to find from cluster.
|
||||
|
||||
```
|
||||
vela system live-diff
|
||||
```
|
||||
|
||||
### Examples
|
||||
|
||||
```
|
||||
vela live-diff -f app-v2.yaml -r app-v1 --context 10
|
||||
```
|
||||
|
||||
### Options
|
||||
|
||||
```
|
||||
-r, --Revision string specify an application Revision name, by default, it will compare with the latest Revision
|
||||
-c, --context int output number lines of context around changes, by default show all unchanged lines (default -1)
|
||||
-d, --definition string specify a file or directory containing capability definitions, they will only be used in dry-run rather than applied to K8s cluster
|
||||
-f, --file string application file name (default "./app.yaml")
|
||||
-h, --help help for live-diff
|
||||
```
|
||||
|
||||
### Options inherited from parent commands
|
||||
|
||||
```
|
||||
-e, --env string specify environment name for application
|
||||
```
|
||||
|
||||
### SEE ALSO
|
||||
|
||||
* [vela system](vela_system.md) - System management utilities
|
||||
|
||||
###### Auto generated by spf13/cobra on 2-May-2021
|
||||
@@ -2,103 +2,46 @@
|
||||
title: How it Works
|
||||
---
|
||||
|
||||
*"KubeVela is a scalable way to create PaaS-like experience on Kubernetes"*
|
||||
|
||||
In this documentation, we will explain the core idea of KubeVela and clarify some technical terms that are widely used in the project.
|
||||
|
||||
## Overview
|
||||
## API
|
||||
|
||||
First of all, KubeVela introduces a workflow with separate of concerns as below:
|
||||
On control plane, KubeVela introduces [Open Application Model (OAM)](https://oam.dev) as the main API to model a full deployment of modern microservices application. This API could be explained as below:
|
||||
|
||||

|
||||
|
||||
In detail:
|
||||
- Components - deployable/provisionable entities that compose your application.
|
||||
- e.g. a Helm chart, a Kubernetes workload, a Terraform module, or a cloud database instance etc.
|
||||
- Traits - attachable features that will *overlay* given component with operational behaviors.
|
||||
- e.g. autoscaling rules, rollout strategies, ingress rules, sidecars, security policies etc.
|
||||
- Application - full description of your application deployment assembled with components and traits.
|
||||
- Environment - the target environments to deploy this application.
|
||||
|
||||
We also reference components and traits as *"capabilities"* in KubeVela.
|
||||
|
||||
## Workflow
|
||||
|
||||
To ensure simple yet consistent user experience across hybrid environments. KubeVela introduces a workflow with separate of concerns as below:
|
||||
- **Platform Team**
|
||||
- Defining templates for deployment environments and reusable capability modules to compose an application, and registering them into the cluster.
|
||||
- **End Users**
|
||||
- Choose a deployment environment, model and assemble the app with available modules, and deploy the app to target environment.
|
||||
- Model and manage platform capabilities as components or traits, together with target environments specifications.
|
||||
- **Application Team**
|
||||
- Choose a environment, assemble the application with components and traits per needs, and deploy it to target environment.
|
||||
|
||||
> Note that either platform team or application team application will only talk to the control plane cluster. KubeVela is designed to hide the details of runtime infrastructures except for debugging or verifying purpose.
|
||||
|
||||
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.
|
||||
|
||||
## `Application`
|
||||
The *Application* is the core API of KubeVela. It allows developers to work with a single artifact to capture the complete application deployment with simplified primitives.
|
||||
|
||||
In application delivery platform, having an "application" concept is important to simplify administrative tasks and can serve as an anchor to avoid configuration drifts during operation. Also, it provides a much simpler path for on-boarding Kubernetes capabilities to application delivery process without relying on low level details. For example, a developer will be able to model a "web service" without defining a detailed Kubernetes Deployment + Service combo each time, or claim the auto-scaling requirements without referring to the underlying KEDA ScaleObject.
|
||||
|
||||
### Example
|
||||
|
||||
An example of `website` application with two components (i.e. `frontend` and `backend`) could be modeled as below:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: website
|
||||
spec:
|
||||
components:
|
||||
- name: backend
|
||||
type: worker
|
||||
properties:
|
||||
image: busybox
|
||||
cmd:
|
||||
- sleep
|
||||
- '1000'
|
||||
- name: frontend
|
||||
type: webservice
|
||||
properties:
|
||||
image: nginx
|
||||
traits:
|
||||
- type: autoscaler
|
||||
properties:
|
||||
min: 1
|
||||
max: 10
|
||||
- type: sidecar
|
||||
properties:
|
||||
name: "sidecar-test"
|
||||
image: "fluentd"
|
||||
```
|
||||
|
||||
## Building the Abstraction
|
||||
|
||||
The `Application` resource in KubeVela is a LEGO-style object and does not even have fixed schema. Instead, it is composed by building blocks (app components and traits etc.) that allow you to on-board platform capabilities to this application definition via your own abstractions.
|
||||
|
||||
The building blocks to abstraction and model platform capabilities named `ComponentDefinition` and `TraitDefinition`.
|
||||
|
||||
### ComponentDefinition
|
||||
|
||||
`ComponentDefinition` is a pre-defined *template* for the deployable workload. It contains template, parametering and workload characteristic information as a declarative API resource.
|
||||
|
||||
Hence, the `Application` abstraction essentially declares how the user want to **instantiate** given component definitions in target cluster. Specifically, the `.type` field references the name of installed `ComponentDefinition` and `.properties` are the user set values to instantiate it.
|
||||
|
||||
Some typical component definitions are *Long Running Web Service*, *One-time Off Task* or *Redis Database*. All component definitions expected to be pre-installed in the platform, or provided by component providers such as 3rd-party software vendors.
|
||||
|
||||
### TraitDefinition
|
||||
|
||||
Optionally, each component has a `.traits` section that augments the component instance with operational behaviors such as load balancing policy, network ingress routing, auto-scaling policies, or upgrade strategies, etc.
|
||||
|
||||
Traits are operational features provided by the platform. To attach a trait to component instance, the user will declare `.type` field to reference the specific `TraitDefinition`, and `.properties` field to set property values of the given trait. Similarly, `TraitDefiniton` also allows you to define *template* for operational features.
|
||||
|
||||
We also reference component definitions and trait definitions as *"capability definitions"* in KubeVela.
|
||||
All the capability building blocks can be updated or extended easily at any time since they are fully programmable via CUE.
|
||||
|
||||
## Environment
|
||||
Before releasing an application to production, it's important to test the code in testing/staging workspaces. In KubeVela, we describe these workspaces as "deployment environments" or "environments" for short. Each environment has its own configuration (e.g., domain, Kubernetes cluster and namespace, configuration data, access control policy, etc.) to allow user to create different deployment environments such as "test" and "production".
|
||||
Before releasing an application to production, it's important to test the code in testing/staging workspaces. In KubeVela, we describe these workspaces as "environments". Each environment has its own configuration (e.g., domain, Kubernetes cluster and namespace, configuration data, access control policy, etc.) to allow user to create different deployment environments such as "test" and "production".
|
||||
|
||||
Currently, a KubeVela `environment` only maps to a Kubernetes namespace, while the cluster level environment is work in progress.
|
||||
## What's Next
|
||||
|
||||
### Summary
|
||||
Here are some recommended next steps:
|
||||
|
||||
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.
|
||||
- Learn KubeVela's [core concepts](./concepts)
|
||||
- Learn how to [deploy an application](end-user/application) in detail and understand how it works.
|
||||
|
||||
@@ -55,7 +55,7 @@ Introduce how to automatically scale workloads by cron.
|
||||
timezone: "America/Los_Angeles"
|
||||
```
|
||||
|
||||
> The full specification of `autoscale` could show up by `$ vela show autoscale` or be found on [its reference documentation](../references/traits/autoscale)
|
||||
> The full specification of `autoscale` could show up by `$ vela show autoscale`.
|
||||
|
||||
2. Deploy an application
|
||||
|
||||
|
||||
@@ -55,7 +55,7 @@ The app will emit random latencies as metrics.
|
||||
EOF
|
||||
```
|
||||
|
||||
> The full specification of `metrics` could show up by `$ vela show metrics` or be found on [its reference documentation](../references/traits/metrics)
|
||||
> The full specification of `metrics` could show up by `$ vela show metrics`.
|
||||
|
||||
2. Deploy the application:
|
||||
|
||||
|
||||
@@ -26,7 +26,7 @@ services:
|
||||
domain: "example.com"
|
||||
```
|
||||
|
||||
> The full specification of `rollout` could show up by `$ vela show rollout` or be found on [its reference documentation](../references/traits/rollout)
|
||||
> The full specification of `rollout` could show up by `$ vela show rollout`.
|
||||
|
||||
Apply this `appfile.yaml`:
|
||||
|
||||
|
||||
@@ -42,7 +42,7 @@ services:
|
||||
rewriteTarget: /
|
||||
```
|
||||
|
||||
> The full specification of `route` could show up by `$ vela show route` or be found on [its reference documentation](../references/traits/route)
|
||||
> The full specification of `route` could show up by `$ vela show route`.
|
||||
|
||||
Apply again:
|
||||
|
||||
|
||||
@@ -72,7 +72,7 @@ services:
|
||||
|
||||
```
|
||||
|
||||
> To learn about how to set the properties of specific workload type or trait, please check the [reference documentation guide](./check-ref-doc).
|
||||
> To learn about how to set the properties of specific workload type or trait, please use `vela show <TYPE | TRAIT>`.
|
||||
|
||||
## Example Workflow
|
||||
|
||||
@@ -221,7 +221,7 @@ spec:
|
||||
|
||||
### [Optional] Configure another workload type
|
||||
|
||||
By now we have deployed a *[Web Service](references/component-types/webservice)*, which is the default workload type in KubeVela. We can also add another service of *[Task](references/component-types/task)* type in the same app:
|
||||
By now we have deployed a *[Web Service](../end-user/components/webservice)*, which is the default workload type in KubeVela. We can also add another service of *[Task](../end-user/components/task)* type in the same app:
|
||||
|
||||
```yaml
|
||||
services:
|
||||
|
||||
@@ -1,113 +0,0 @@
|
||||
---
|
||||
title: Overview
|
||||
---
|
||||
|
||||
In this documentation, we will show how to check the detailed schema of a given capability (i.e. component type or trait).
|
||||
|
||||
This may sound challenging because every capability is a "plug-in" in KubeVela (even for the built-in ones), also, it's by design that KubeVela allows platform administrators to modify the capability templates at any time. In this case, do we need to manually write documentation for every newly installed capability? And how can we ensure those documentations for the system is up-to-date?
|
||||
|
||||
## Using Browser
|
||||
|
||||
Actually, as a important part of its "extensibility" design, KubeVela will always **automatically generate** reference documentation for every workload type or trait registered in your Kubernetes cluster, based on the template in its definition of course. This feature works for any capability: either built-in ones or your own workload types/traits.
|
||||
|
||||
Thus, as an end user, the only thing you need to do is:
|
||||
|
||||
```console
|
||||
$ vela show COMPONENT_TYPE or TRAIT --web
|
||||
```
|
||||
|
||||
This command will automatically open the reference documentation for given component type or trait in your default browser.
|
||||
|
||||
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:
|
||||
|
||||
```yaml
|
||||
name: helloworld
|
||||
|
||||
services:
|
||||
backend: # copy-paste from the webservice ref doc above
|
||||
image: oamdev/testapp:v1
|
||||
cmd: ["node", "server.js"]
|
||||
port: 8080
|
||||
cpu: "0.1"
|
||||
|
||||
autoscale: # copy-paste and modify from autoscaler ref doc above
|
||||
min: 1
|
||||
max: 8
|
||||
cron:
|
||||
startAt: "19:00"
|
||||
duration: "2h"
|
||||
days: "Friday"
|
||||
replicas: 4
|
||||
timezone: "America/Los_Angeles"
|
||||
```
|
||||
|
||||
## Using Terminal
|
||||
|
||||
This reference doc feature also works for terminal-only case. For example:
|
||||
|
||||
```shell
|
||||
$ vela show webservice
|
||||
# Properties
|
||||
+-------+----------------------------------------------------------------------------------+---------------+----------+---------+
|
||||
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
|
||||
+-------+----------------------------------------------------------------------------------+---------------+----------+---------+
|
||||
| cmd | Commands to run in the container | []string | false | |
|
||||
| env | Define arguments by using environment variables | [[]env](#env) | false | |
|
||||
| image | Which image would you like to use for your service | string | true | |
|
||||
| port | Which port do you want customer traffic sent to | int | true | 80 |
|
||||
| cpu | Number of CPU units for the service, like `0.5` (0.5 CPU core), `1` (1 CPU core) | string | false | |
|
||||
+-------+----------------------------------------------------------------------------------+---------------+----------+---------+
|
||||
|
||||
|
||||
## env
|
||||
+-----------+-----------------------------------------------------------+-------------------------+----------+---------+
|
||||
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
|
||||
+-----------+-----------------------------------------------------------+-------------------------+----------+---------+
|
||||
| name | Environment variable name | string | true | |
|
||||
| value | The value of the environment variable | string | false | |
|
||||
| valueFrom | Specifies a source the value of this var should come from | [valueFrom](#valueFrom) | false | |
|
||||
+-----------+-----------------------------------------------------------+-------------------------+----------+---------+
|
||||
|
||||
|
||||
### valueFrom
|
||||
+--------------+--------------------------------------------------+-------------------------------+----------+---------+
|
||||
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
|
||||
+--------------+--------------------------------------------------+-------------------------------+----------+---------+
|
||||
| secretKeyRef | Selects a key of a secret in the pod's namespace | [secretKeyRef](#secretKeyRef) | true | |
|
||||
+--------------+--------------------------------------------------+-------------------------------+----------+---------+
|
||||
|
||||
|
||||
#### secretKeyRef
|
||||
+------+------------------------------------------------------------------+--------+----------+---------+
|
||||
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
|
||||
+------+------------------------------------------------------------------+--------+----------+---------+
|
||||
| name | The name of the secret in the pod's namespace to select from | string | true | |
|
||||
| key | The key of the secret to select from. Must be a valid secret key | string | true | |
|
||||
+------+------------------------------------------------------------------+--------+----------+---------+
|
||||
```
|
||||
|
||||
## For Built-in Capabilities
|
||||
|
||||
Note that for all the built-in capabilities, we already published their reference docs below based on the same doc generation mechanism.
|
||||
|
||||
|
||||
- Workload Types
|
||||
- [webservice](component-types/webservice)
|
||||
- [task](component-types/task)
|
||||
- [worker](component-types/worker)
|
||||
- Traits
|
||||
- [route](traits/route)
|
||||
- [autoscale](traits/autoscale)
|
||||
- [rollout](traits/rollout)
|
||||
- [metrics](traits/metrics)
|
||||
- [scaler](traits/scaler)
|
||||
@@ -1,27 +0,0 @@
|
||||
---
|
||||
title: Task
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
Describes jobs that run code or a script to completion.
|
||||
|
||||
## Specification
|
||||
|
||||
List of all configuration options for a `Task` workload type.
|
||||
|
||||
```yaml
|
||||
...
|
||||
image: perl
|
||||
count: 10
|
||||
cmd: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
|
||||
```
|
||||
|
||||
## Properties
|
||||
|
||||
Name | Description | Type | Required | Default
|
||||
------------ | ------------- | ------------- | ------------- | -------------
|
||||
cmd | Commands to run in the container | []string | false |
|
||||
count | specify number of tasks to run in parallel | int | true | 1
|
||||
restart | Define the job restart policy, the value can only be Never or OnFailure. By default, it's Never. | string | true | Never
|
||||
image | Which image would you like to use for your service | string | true |
|
||||
@@ -1,61 +0,0 @@
|
||||
---
|
||||
title: Webservice
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
Describes long-running, scalable, containerized services that have a stable network endpoint to receive external network traffic from customers. If workload type is skipped for any service defined in Appfile, it will be defaulted to `webservice` type.
|
||||
|
||||
## Specification
|
||||
|
||||
List of all configuration options for a `Webservice` workload type.
|
||||
|
||||
```yaml
|
||||
...
|
||||
image: oamdev/testapp:v1
|
||||
cmd: ["node", "server.js"]
|
||||
port: 8080
|
||||
cpu: "0.1"
|
||||
env:
|
||||
- name: FOO
|
||||
value: bar
|
||||
- name: FOO
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
name: bar
|
||||
key: bar
|
||||
```
|
||||
|
||||
## Properties
|
||||
|
||||
Name | Description | Type | Required | Default
|
||||
------------ | ------------- | ------------- | ------------- | -------------
|
||||
cmd | Commands to run in the container | []string | false |
|
||||
env | Define arguments by using environment variables | [[]env](#env) | false |
|
||||
image | Which image would you like to use for your service | string | true |
|
||||
port | Which port do you want customer traffic sent to | int | true | 80
|
||||
cpu | Number of CPU units for the service, like `0.5` (0.5 CPU core), `1` (1 CPU core) | string | false |
|
||||
|
||||
|
||||
### env
|
||||
|
||||
Name | Description | Type | Required | Default
|
||||
------------ | ------------- | ------------- | ------------- | -------------
|
||||
name | Environment variable name | string | true |
|
||||
value | The value of the environment variable | string | false |
|
||||
valueFrom | Specifies a source the value of this var should come from | [valueFrom](#valueFrom) | false |
|
||||
|
||||
|
||||
#### valueFrom
|
||||
|
||||
Name | Description | Type | Required | Default
|
||||
------------ | ------------- | ------------- | ------------- | -------------
|
||||
secretKeyRef | Selects a key of a secret in the pod's namespace | [secretKeyRef](#secretKeyRef) | true |
|
||||
|
||||
|
||||
##### secretKeyRef
|
||||
|
||||
Name | Description | Type | Required | Default
|
||||
------------ | ------------- | ------------- | ------------- | -------------
|
||||
name | The name of the secret in the pod's namespace to select from | string | true |
|
||||
key | The key of the secret to select from. Must be a valid secret key | string | true |
|
||||
@@ -1,24 +0,0 @@
|
||||
---
|
||||
title: Worker
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
Describes long-running, scalable, containerized services that running at backend. They do NOT have network endpoint to receive external network traffic.
|
||||
|
||||
## Specification
|
||||
|
||||
List of all configuration options for a `Worker` workload type.
|
||||
|
||||
```yaml
|
||||
...
|
||||
image: oamdev/testapp:v1
|
||||
cmd: ["node", "server.js"]
|
||||
```
|
||||
|
||||
## Properties
|
||||
|
||||
Name | Description | Type | Required | Default
|
||||
------------ | ------------- | ------------- | ------------- | -------------
|
||||
cmd | Commands to run in the container | []string | false |
|
||||
image | Which image would you like to use for your service | string | true |
|
||||
@@ -1,44 +0,0 @@
|
||||
---
|
||||
title: Autoscale
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
Automatically scales workloads by resource utilization metrics or cron triggers.
|
||||
|
||||
## Specification
|
||||
|
||||
List of all configuration options for a `Autoscale` trait.
|
||||
|
||||
```yaml
|
||||
...
|
||||
min: 1
|
||||
max: 4
|
||||
cron:
|
||||
startAt: "14:00"
|
||||
duration: "2h"
|
||||
days: "Monday, Thursday"
|
||||
replicas: 2
|
||||
timezone: "America/Los_Angeles"
|
||||
cpuPercent: 10
|
||||
```
|
||||
|
||||
## Properties
|
||||
|
||||
Name | Description | Type | Required | Default
|
||||
------------ | ------------- | ------------- | ------------- | -------------
|
||||
min | Minimal replicas of the workload | int | true |
|
||||
max | Maximal replicas of the workload | int | true |
|
||||
cpuPercent | Specify the value for CPU utilization, like 80, which means 80% | int | false |
|
||||
cron | Cron type auto-scaling. Just for `appfile`, not available for Cli usage | [cron](#cron) | false |
|
||||
|
||||
|
||||
### cron
|
||||
|
||||
Name | Description | Type | Required | Default
|
||||
------------ | ------------- | ------------- | ------------- | -------------
|
||||
startAt | The time to start scaling, like `08:00` | string | true |
|
||||
duration | For how long the scaling will last | string | true |
|
||||
days | Several workdays or weekends, like "Monday, Tuesday" | string | true |
|
||||
replicas | The target replicas to be scaled to | int | true |
|
||||
timezone | Timezone, like "America/Los_Angeles" | string | true |
|
||||
@@ -1,25 +0,0 @@
|
||||
---
|
||||
title: Ingress
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
Configures K8s ingress and service to enable web traffic for your service. Please use route trait in cap center for advanced usage.
|
||||
|
||||
## Specification
|
||||
|
||||
List of all configuration options for a `Ingress` trait.
|
||||
|
||||
```yaml
|
||||
...
|
||||
domain: testsvc.example.com
|
||||
http:
|
||||
/: 8000
|
||||
```
|
||||
|
||||
## Properties
|
||||
|
||||
Name | Description | Type | Required | Default
|
||||
------------ | ------------- | ------------- | ------------- | -------------
|
||||
domain | | string | true |
|
||||
http | | map[string]int | true |
|
||||
@@ -1,23 +0,0 @@
|
||||
---
|
||||
title: Scaler
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
Configures replicas for your service.
|
||||
|
||||
## Specification
|
||||
|
||||
List of all configuration options for a `Scaler` trait.
|
||||
|
||||
```yaml
|
||||
...
|
||||
scaler:
|
||||
replicas: 100
|
||||
```
|
||||
|
||||
## Properties
|
||||
|
||||
Name | Description | Type | Required | Default
|
||||
------------ | ------------- | ------------- | ------------- | -------------
|
||||
replicas | Replicas of the workload | int | true | 1
|
||||
220
docs/en/end-user/application.md
Normal file
220
docs/en/end-user/application.md
Normal file
@@ -0,0 +1,220 @@
|
||||
---
|
||||
title: Application
|
||||
---
|
||||
|
||||
This documentation will walk through how to use KubeVela to design a simple application without any polices or placement rule defined.
|
||||
|
||||
> Note: since you didn't declare placement rule, KubeVela will deploy this application directly to the control plane cluster (i.e. the cluster your `kubectl` is talking to). This is also the same case if you are using local cluster such as KinD or MiniKube to play KubeVela.
|
||||
|
||||
## Step 1: Check Available Components
|
||||
|
||||
Components are deployable or provisionable entities that compose your application. It could be a Helm chart, a simple Kubernetes workload, a CUE or Terraform module, or a cloud database etc.
|
||||
|
||||
Let's check the available components in fresh new KubeVela.
|
||||
|
||||
```shell
|
||||
kubectl get comp -n vela-system
|
||||
NAME WORKLOAD-KIND DESCRIPTION
|
||||
task Job Describes jobs that run code or a script to completion.
|
||||
webservice Deployment Describes long-running, scalable, containerized services that have a stable network endpoint to receive external network traffic from customers.
|
||||
worker Deployment Describes long-running, scalable, containerized services that running at backend. They do NOT have network endpoint to receive external network traffic.
|
||||
```
|
||||
|
||||
To show the specification for given component, you could use `vela show`.
|
||||
|
||||
```shell
|
||||
$ kubectl vela show webservice
|
||||
# Properties
|
||||
+------------------+----------------------------------------------------------------------------------+-----------------------+----------+---------+
|
||||
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
|
||||
+------------------+----------------------------------------------------------------------------------+-----------------------+----------+---------+
|
||||
| cmd | Commands to run in the container | []string | false | |
|
||||
| env | Define arguments by using environment variables | [[]env](#env) | false | |
|
||||
| addRevisionLabel | | bool | true | false |
|
||||
| image | Which image would you like to use for your service | string | true | |
|
||||
| port | Which port do you want customer traffic sent to | int | true | 80 |
|
||||
| cpu | Number of CPU units for the service, like `0.5` (0.5 CPU core), `1` (1 CPU core) | string | false | |
|
||||
| volumes | Declare volumes and volumeMounts | [[]volumes](#volumes) | false | |
|
||||
+------------------+----------------------------------------------------------------------------------+-----------------------+----------+---------+
|
||||
... // skip other fields
|
||||
```
|
||||
|
||||
> Tips: `vela show xxx --web` will open its capability reference documentation in your default browser.
|
||||
|
||||
You could always [add more components](components/more) to the platform at any time.
|
||||
|
||||
## Step 2: Declare an Application
|
||||
|
||||
Application is the full description of a deployment. Let's define an application that deploys a *Web Service* and a *Worker* components.
|
||||
|
||||
```yaml
|
||||
# sample.yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: website
|
||||
spec:
|
||||
components:
|
||||
- name: frontend
|
||||
type: webservice
|
||||
properties:
|
||||
image: nginx
|
||||
- name: backend
|
||||
type: worker
|
||||
properties:
|
||||
image: busybox
|
||||
cmd:
|
||||
- sleep
|
||||
- '1000'
|
||||
```
|
||||
|
||||
## Step 3: Attach Traits
|
||||
|
||||
Traits are platform provided features that could *overlay* a given component with extra operational behaviors.
|
||||
|
||||
```shell
|
||||
$ kubectl get trait -n vela-system
|
||||
NAME APPLIES-TO DESCRIPTION
|
||||
cpuscaler [webservice worker] Automatically scale the component based on CPU usage.
|
||||
ingress [webservice worker] Enable public web traffic for the component.
|
||||
scaler [webservice worker] Manually scale the component.
|
||||
sidecar [webservice worker] Inject a sidecar container to the component.
|
||||
```
|
||||
|
||||
Let's check the specification of `sidecar` trait.
|
||||
|
||||
```shell
|
||||
$ kubectl vela show sidecar
|
||||
# Properties
|
||||
+---------+-----------------------------------------+----------+----------+---------+
|
||||
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
|
||||
+---------+-----------------------------------------+----------+----------+---------+
|
||||
| name | Specify the name of sidecar container | string | true | |
|
||||
| image | Specify the image of sidecar container | string | true | |
|
||||
| command | Specify the commands run in the sidecar | []string | false | |
|
||||
+---------+-----------------------------------------+----------+----------+---------+
|
||||
```
|
||||
|
||||
Note that traits are designed to be *overlays*.
|
||||
|
||||
This means for `sidecar` trait, your `frontend` component doesn't need to have a sidecar template or bring a webhook to enable sidecar injection. Instead, KubeVela is able to patch a sidecar to its workload instance after it is generated by the component (no matter it's a Helm chart or CUE module) but before it is applied to runtime cluster.
|
||||
|
||||
Similarly, the system will assign a HPA instance based on the properties you set and "link" it to the target workload instance, the component itself is untouched.
|
||||
|
||||
Now let's attach `sidecar` and `cpuscaler` traits to the `frontend` component.
|
||||
|
||||
```yaml
|
||||
# sample.yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: website
|
||||
spec:
|
||||
components:
|
||||
- name: frontend # This is the component I want to deploy
|
||||
type: webservice
|
||||
properties:
|
||||
image: nginx
|
||||
traits:
|
||||
- type: cpuscaler # Automatically scale the component by CPU usage after deployed
|
||||
properties:
|
||||
min: 1
|
||||
max: 10
|
||||
cpuPercent: 60
|
||||
- type: sidecar # Inject a fluentd sidecar before applying the component to runtime cluster
|
||||
properties:
|
||||
name: "sidecar-test"
|
||||
image: "fluentd"
|
||||
- name: backend
|
||||
type: worker
|
||||
properties:
|
||||
image: busybox
|
||||
cmd:
|
||||
- sleep
|
||||
- '1000'
|
||||
```
|
||||
|
||||
## Step 4: Deploy the Application
|
||||
|
||||
```shell
|
||||
$ kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/enduser/sample.yaml
|
||||
application.core.oam.dev/website created
|
||||
```
|
||||
|
||||
You'll get the application becomes `running`.
|
||||
|
||||
```shell
|
||||
$ kubectl get application
|
||||
NAME COMPONENT TYPE PHASE HEALTHY STATUS AGE
|
||||
website frontend webservice running true 4m54s
|
||||
```
|
||||
|
||||
Check the details of the application.
|
||||
|
||||
```shell
|
||||
$ kubectl get app website -o yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
generation: 1
|
||||
name: website
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: frontend
|
||||
properties:
|
||||
image: nginx
|
||||
traits:
|
||||
- properties:
|
||||
cpuPercent: 60
|
||||
max: 10
|
||||
min: 1
|
||||
type: cpuscaler
|
||||
- properties:
|
||||
image: fluentd
|
||||
name: sidecar-test
|
||||
type: sidecar
|
||||
type: webservice
|
||||
- name: backend
|
||||
properties:
|
||||
cmd:
|
||||
- sleep
|
||||
- "1000"
|
||||
image: busybox
|
||||
type: worker
|
||||
status:
|
||||
...
|
||||
latestRevision:
|
||||
name: website-v1
|
||||
revision: 1
|
||||
revisionHash: e9e062e2cddfe5fb
|
||||
services:
|
||||
- healthy: true
|
||||
name: frontend
|
||||
traits:
|
||||
- healthy: true
|
||||
type: cpuscaler
|
||||
- healthy: true
|
||||
type: sidecar
|
||||
- healthy: true
|
||||
name: backend
|
||||
status: running
|
||||
```
|
||||
|
||||
Specifically:
|
||||
|
||||
1. `status.latestRevision` declares current revision of this deployment.
|
||||
2. `status.services` declares the component created by this deployment and the healthy state.
|
||||
3. `status.status` declares the global state of this deployment.
|
||||
|
||||
### List Revisions
|
||||
|
||||
When updating an application entity, KubeVela will create a new revision for this change.
|
||||
|
||||
```shell
|
||||
$ kubectl get apprev -l app.oam.dev/name=website
|
||||
NAME AGE
|
||||
website-v1 35m
|
||||
```
|
||||
|
||||
Furthermore, the system will decide how to/whether to rollout the application based on the attached [rollout plan](scopes/rollout-plan).
|
||||
@@ -1,242 +0,0 @@
|
||||
---
|
||||
title: Provision and Consume Cloud Resources
|
||||
---
|
||||
|
||||
> ⚠️ This section requires your platform builder has already installed the [cloud resources related capabilities](../platform-engineers/cloud-services).
|
||||
|
||||
## Provision and consume cloud resource in a single application v1 (one cloud resource)
|
||||
|
||||
Check the parameters of cloud resource component:
|
||||
|
||||
```shell
|
||||
$ kubectl vela show alibaba-rds
|
||||
|
||||
# Properties
|
||||
+---------------+------------------------------------------------+--------+----------+--------------------+
|
||||
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
|
||||
+---------------+------------------------------------------------+--------+----------+--------------------+
|
||||
| engine | RDS engine | string | true | mysql |
|
||||
| engineVersion | The version of RDS engine | string | true | 8.0 |
|
||||
| instanceClass | The instance class for the RDS | string | true | rds.mysql.c1.large |
|
||||
| username | RDS username | string | true | |
|
||||
| secretName | Secret name which RDS connection will write to | string | true | |
|
||||
+---------------+------------------------------------------------+--------+----------+--------------------+
|
||||
```
|
||||
|
||||
Use the service binding trait to bind cloud resources into workload as ENV.
|
||||
|
||||
Create an application with a cloud resource provisioning component and a consuming component as below.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: webapp
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: zzxwill/flask-web-application:v0.3.1-crossplane
|
||||
ports: 80
|
||||
traits:
|
||||
- type: service-binding
|
||||
properties:
|
||||
envMappings:
|
||||
# environments refer to db-conn secret
|
||||
DB_PASSWORD:
|
||||
secret: db-conn
|
||||
key: password # 1) If the env name is different from secret key, secret key has to be set.
|
||||
endpoint:
|
||||
secret: db-conn # 2) If the env name is the same as the secret key, secret key can be omitted.
|
||||
username:
|
||||
secret: db-conn
|
||||
|
||||
- name: sample-db
|
||||
type: alibaba-rds
|
||||
properties:
|
||||
name: sample-db
|
||||
engine: mysql
|
||||
engineVersion: "8.0"
|
||||
instanceClass: rds.mysql.c1.large
|
||||
username: oamtest
|
||||
secretName: db-conn
|
||||
|
||||
```
|
||||
|
||||
Apply it and verify the application.
|
||||
|
||||
```shell
|
||||
$ kubectl get application
|
||||
NAME AGE
|
||||
webapp 46m
|
||||
|
||||
$ kubectl port-forward deployment/express-server 80:80
|
||||
Forwarding from 127.0.0.1:80 -> 80
|
||||
Forwarding from [::1]:80 -> 80
|
||||
Handling connection for 80
|
||||
Handling connection for 80
|
||||
```
|
||||
|
||||

|
||||
|
||||
## Provision and consume cloud resource in a single application v2 (two cloud resources)
|
||||
|
||||
Based on the section `Provisioning and consuming cloud resource in a single application v1 (one cloud resource)`,
|
||||
|
||||
Update the application to also consume cloud resource OSS.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: webapp
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: zzxwill/flask-web-application:v0.3.1-crossplane
|
||||
ports: 80
|
||||
traits:
|
||||
- type: service-binding
|
||||
properties:
|
||||
envMappings:
|
||||
# environments refer to db-conn secret
|
||||
DB_PASSWORD:
|
||||
secret: db-conn
|
||||
key: password # 1) If the env name is different from secret key, secret key has to be set.
|
||||
endpoint:
|
||||
secret: db-conn # 2) If the env name is the same as the secret key, secret key can be omitted.
|
||||
username:
|
||||
secret: db-conn
|
||||
# environments refer to oss-conn secret
|
||||
BUCKET_NAME:
|
||||
secret: oss-conn
|
||||
key: Bucket
|
||||
|
||||
- name: sample-db
|
||||
type: alibaba-rds
|
||||
properties:
|
||||
name: sample-db
|
||||
engine: mysql
|
||||
engineVersion: "8.0"
|
||||
instanceClass: rds.mysql.c1.large
|
||||
username: oamtest
|
||||
secretName: db-conn
|
||||
|
||||
- name: sample-oss
|
||||
type: alibaba-oss
|
||||
properties:
|
||||
name: velaweb
|
||||
secretName: oss-conn
|
||||
```
|
||||
|
||||
Apply it and verify the application.
|
||||
|
||||
```shell
|
||||
$ kubectl port-forward deployment/express-server 80:80
|
||||
Forwarding from 127.0.0.1:80 -> 80
|
||||
Forwarding from [::1]:80 -> 80
|
||||
Handling connection for 80
|
||||
Handling connection for 80
|
||||
```
|
||||
|
||||

|
||||
|
||||
## Provision and consume cloud resource in different applications
|
||||
|
||||
In this section, cloud resource will be provisioned in one application and consumed in another application.
|
||||
|
||||
### Provision Cloud Resource
|
||||
|
||||
Instantiate RDS component with `alibaba-rds` workload type in an [Application](../application.md) to provide cloud resources.
|
||||
|
||||
As we have claimed an RDS instance with ComponentDefinition name `alibaba-rds`.
|
||||
The component in the application should refer to this type.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: baas-rds
|
||||
spec:
|
||||
components:
|
||||
- name: sample-db
|
||||
type: alibaba-rds
|
||||
properties:
|
||||
name: sample-db
|
||||
engine: mysql
|
||||
engineVersion: "8.0"
|
||||
instanceClass: rds.mysql.c1.large
|
||||
username: oamtest
|
||||
secretName: db-conn
|
||||
```
|
||||
|
||||
Apply the application to Kubernetes and a RDS instance will be automatically provisioned (may take some time, ~2 mins).
|
||||
|
||||
A secret `db-conn` will also be created in the same namespace as that of the application.
|
||||
|
||||
```shell
|
||||
$ kubectl get application
|
||||
NAME AGE
|
||||
baas-rds 9h
|
||||
|
||||
$ kubectl get rdsinstance
|
||||
NAME READY SYNCED STATE ENGINE VERSION AGE
|
||||
sample-db-v1 True True Running mysql 8.0 9h
|
||||
|
||||
$ kubectl get secret
|
||||
NAME TYPE DATA AGE
|
||||
db-conn connection.crossplane.io/v1alpha1 4 9h
|
||||
|
||||
$ ✗ kubectl get secret db-conn -o yaml
|
||||
apiVersion: v1
|
||||
data:
|
||||
endpoint: xxx==
|
||||
password: yyy
|
||||
port: MzMwNg==
|
||||
username: b2FtdGVzdA==
|
||||
kind: Secret
|
||||
```
|
||||
|
||||
### Consume the Cloud Resource
|
||||
|
||||
In this section, we will show how another component consumes the RDS instance.
|
||||
|
||||
> Note: we recommend defining the cloud resource claiming to an independent application if that cloud resource has
|
||||
> standalone lifecycle.
|
||||
|
||||
Now create the Application to consume the data.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: webapp
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webconsumer
|
||||
properties:
|
||||
image: zzxwill/flask-web-application:v0.3.1-crossplane
|
||||
ports: 80
|
||||
dbSecret: db-conn
|
||||
```
|
||||
|
||||
```shell
|
||||
$ kubectl get application
|
||||
NAME AGE
|
||||
baas-rds 10h
|
||||
webapp 14h
|
||||
|
||||
$ kubectl get deployment
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
express-server-v1 1/1 1 1 9h
|
||||
|
||||
$ kubectl port-forward deployment/express-server 80:80
|
||||
```
|
||||
|
||||
We can see the cloud resource is successfully consumed by the application.
|
||||
|
||||

|
||||
186
docs/en/end-user/components/cloud-services.md
Normal file
186
docs/en/end-user/components/cloud-services.md
Normal file
@@ -0,0 +1,186 @@
|
||||
---
|
||||
title: Cloud Services
|
||||
---
|
||||
|
||||
KubeVela allows you to declare cloud services your application needs in consistent API. Currently, we support both Terraform and Crossplane.
|
||||
|
||||
> Please check [the platform team guide for cloud services](../../platform-engineers/cloud-services) if you are interested in how these capabilities are maintained in KubeVela.
|
||||
|
||||
The cloud services will be consumed by the application via [Service Binding Trait](../traits/service-binding).
|
||||
|
||||
## Terraform
|
||||
|
||||
> ⚠️ This section assumes [Terraform related capabilities](../../platform-engineers/terraform) have been installed in your platform.
|
||||
|
||||
Check the parameters of cloud resource components and trait.
|
||||
|
||||
```shell
|
||||
$ kubectl vela show alibaba-rds
|
||||
# Properties
|
||||
+----------------------------+-------------------------------------------------------------------------+-----------------------------------------------------------+----------+---------+
|
||||
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
|
||||
+----------------------------+-------------------------------------------------------------------------+-----------------------------------------------------------+----------+---------+
|
||||
| bucket | OSS bucket name | string | true | |
|
||||
| acl | OSS bucket ACL, supported 'private', 'public-read', 'public-read-write' | string | true | |
|
||||
| writeConnectionSecretToRef | The secret which the cloud resource connection will be written to | [writeConnectionSecretToRef](#writeConnectionSecretToRef) | false | |
|
||||
+----------------------------+-------------------------------------------------------------------------+-----------------------------------------------------------+----------+---------+
|
||||
|
||||
|
||||
## writeConnectionSecretToRef
|
||||
+-----------+-----------------------------------------------------------------------------+--------+----------+---------+
|
||||
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
|
||||
+-----------+-----------------------------------------------------------------------------+--------+----------+---------+
|
||||
| name | The secret name which the cloud resource connection will be written to | string | true | |
|
||||
| namespace | The secret namespace which the cloud resource connection will be written to | string | false | |
|
||||
+-----------+-----------------------------------------------------------------------------+--------+----------+---------+
|
||||
|
||||
|
||||
$ kubectl vela show service-binding
|
||||
# Properties
|
||||
+-------------+------------------------------------------------+------------------+----------+---------+
|
||||
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
|
||||
+-------------+------------------------------------------------+------------------+----------+---------+
|
||||
| envMappings | The mapping of environment variables to secret | map[string]{...} | true | |
|
||||
+-------------+------------------------------------------------+------------------+----------+---------+
|
||||
```
|
||||
|
||||
### Alibaba Cloud RDS and OSS
|
||||
|
||||
A sample [application](https://github.com/oam-dev/kubevela/tree/master/docs/examples/terraform/cloud-resource-provision-and-consume/application.yaml) is as below.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: webapp
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: zzxwill/flask-web-application:v0.3.1-crossplane
|
||||
ports: 80
|
||||
traits:
|
||||
- type: service-binding
|
||||
properties:
|
||||
envMappings:
|
||||
# environments refer to db-conn secret
|
||||
DB_PASSWORD:
|
||||
secret: db-conn # 1) If the env name is the same as the secret key, secret key can be omitted.
|
||||
endpoint:
|
||||
secret: db-conn
|
||||
key: DB_HOST # 2) If the env name is different from secret key, secret key has to be set.
|
||||
username:
|
||||
secret: db-conn
|
||||
key: DB_USER
|
||||
# environments refer to oss-conn secret
|
||||
BUCKET_NAME:
|
||||
secret: oss-conn
|
||||
|
||||
- name: sample-db
|
||||
type: alibaba-rds
|
||||
properties:
|
||||
instance_name: sample-db
|
||||
account_name: oamtest
|
||||
password: U34rfwefwefffaked
|
||||
writeConnectionSecretToRef:
|
||||
name: db-conn
|
||||
|
||||
- name: sample-oss
|
||||
type: alibaba-oss
|
||||
properties:
|
||||
bucket: vela-website
|
||||
acl: private
|
||||
writeConnectionSecretToRef:
|
||||
name: oss-conn
|
||||
|
||||
|
||||
```
|
||||
|
||||
## Crossplane
|
||||
|
||||
> ⚠️ This section assumes [Crossplane related capabilities](../../platform-engineers/crossplane) have been installed in your platform.
|
||||
|
||||
### Alibaba Cloud RDS and OSS
|
||||
|
||||
Check the parameters of cloud service component:
|
||||
|
||||
```shell
|
||||
$ kubectl vela show alibaba-rds
|
||||
|
||||
# Properties
|
||||
+---------------+------------------------------------------------+--------+----------+--------------------+
|
||||
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
|
||||
+---------------+------------------------------------------------+--------+----------+--------------------+
|
||||
| engine | RDS engine | string | true | mysql |
|
||||
| engineVersion | The version of RDS engine | string | true | 8.0 |
|
||||
| instanceClass | The instance class for the RDS | string | true | rds.mysql.c1.large |
|
||||
| username | RDS username | string | true | |
|
||||
| secretName | Secret name which RDS connection will write to | string | true | |
|
||||
+---------------+------------------------------------------------+--------+----------+--------------------+
|
||||
```
|
||||
A sample application is as below.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: webapp
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: zzxwill/flask-web-application:v0.3.1-crossplane
|
||||
ports: 80
|
||||
traits:
|
||||
- type: service-binding
|
||||
properties:
|
||||
envMappings:
|
||||
# environments refer to db-conn secret
|
||||
DB_PASSWORD:
|
||||
secret: db-conn
|
||||
key: password # 1) If the env name is different from secret key, secret key has to be set.
|
||||
endpoint:
|
||||
secret: db-conn # 2) If the env name is the same as the secret key, secret key can be omitted.
|
||||
username:
|
||||
secret: db-conn
|
||||
# environments refer to oss-conn secret
|
||||
BUCKET_NAME:
|
||||
secret: oss-conn
|
||||
key: Bucket
|
||||
|
||||
- name: sample-db
|
||||
type: alibaba-rds
|
||||
properties:
|
||||
name: sample-db
|
||||
engine: mysql
|
||||
engineVersion: "8.0"
|
||||
instanceClass: rds.mysql.c1.large
|
||||
username: oamtest
|
||||
secretName: db-conn
|
||||
|
||||
- name: sample-oss
|
||||
type: alibaba-oss
|
||||
properties:
|
||||
name: velaweb
|
||||
secretName: oss-conn
|
||||
```
|
||||
|
||||
## Verify
|
||||
|
||||
Deploy and verify the application (by either provider is OK).
|
||||
|
||||
```shell
|
||||
$ kubectl get application
|
||||
NAME AGE
|
||||
webapp 46m
|
||||
|
||||
$ kubectl port-forward deployment/express-server 80:80
|
||||
Forwarding from 127.0.0.1:80 -> 80
|
||||
Forwarding from [::1]:80 -> 80
|
||||
Handling connection for 80
|
||||
Handling connection for 80
|
||||
```
|
||||
|
||||

|
||||
12
docs/en/end-user/components/more.md
Normal file
12
docs/en/end-user/components/more.md
Normal file
@@ -0,0 +1,12 @@
|
||||
---
|
||||
title: Want More?
|
||||
---
|
||||
|
||||
Components in KubeVela are designed to be brought by users.
|
||||
|
||||
Check below documentations about how to bring your own components to the system in various approaches.
|
||||
|
||||
- [Helm](../../platform-engineers/helm/component) - Helm chart is a natural form of component, note that you need to have a valid Helm repository (e.g. GitHub repo or a Helm hub) to host the chart in this case.
|
||||
- [CUE](../../platform-engineers/cue/component) - CUE is powerful approach to encapsulate a component and it doesn't require any repository.
|
||||
- [Simple Template](../../platform-engineers/kube/component) - Not a Helm or CUE expert? A simple template approach is also provided to define any Kubernetes API resource as a component. Note that only key-value style parameters are supported in this case.
|
||||
- [Cloud Services](../../platform-engineers/cloud-services) - KubeVela allows you to declare cloud services as part of the application and provision them in consistent API.
|
||||
38
docs/en/end-user/components/task.md
Normal file
38
docs/en/end-user/components/task.md
Normal file
@@ -0,0 +1,38 @@
|
||||
---
|
||||
title: Task
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
Describes jobs that run code or a script to completion.
|
||||
|
||||
## Samples
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: app-worker
|
||||
spec:
|
||||
components:
|
||||
- name: mytask
|
||||
type: task
|
||||
properties:
|
||||
image: perl
|
||||
count: 10
|
||||
cmd: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
|
||||
```
|
||||
|
||||
## Specification
|
||||
|
||||
```console
|
||||
# Properties
|
||||
+---------+--------------------------------------------------------------------------------------------------+----------+----------+---------+
|
||||
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
|
||||
+---------+--------------------------------------------------------------------------------------------------+----------+----------+---------+
|
||||
| cmd | Commands to run in the container | []string | false | |
|
||||
| count | specify number of tasks to run in parallel | int | true | 1 |
|
||||
| restart | Define the job restart policy, the value can only be Never or OnFailure. By default, it's Never. | string | true | Never |
|
||||
| image | Which image would you like to use for your service | string | true | |
|
||||
+---------+--------------------------------------------------------------------------------------------------+----------+----------+---------+
|
||||
```
|
||||
@@ -1,107 +1,82 @@
|
||||
---
|
||||
title: Explore Applications
|
||||
title: Web Service
|
||||
---
|
||||
|
||||
We will introduce how to explore application related resources in this section.
|
||||
## Description
|
||||
|
||||
## List Application
|
||||
Describes long-running, scalable, containerized services that have a stable network endpoint to receive external network traffic from customers.
|
||||
|
||||
```shell
|
||||
$ kubectl get application
|
||||
NAME COMPONENT TYPE PHASE HEALTHY STATUS AGE
|
||||
app-basic app-basic webservice running true 12d
|
||||
website frontend webservice running true 4m54s
|
||||
```
|
||||
## Samples
|
||||
|
||||
You can also use the short name `kubectl get app`.
|
||||
|
||||
### View Application Details
|
||||
|
||||
```shell
|
||||
$ kubectl get app website -o yaml
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
generation: 1
|
||||
name: website
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: frontend
|
||||
properties:
|
||||
image: nginx
|
||||
traits:
|
||||
- properties:
|
||||
cpuPercent: 60
|
||||
max: 10
|
||||
min: 1
|
||||
type: cpuscaler
|
||||
- properties:
|
||||
image: fluentd
|
||||
name: sidecar-test
|
||||
type: sidecar
|
||||
type: webservice
|
||||
- name: backend
|
||||
properties:
|
||||
cmd:
|
||||
- sleep
|
||||
- "1000"
|
||||
image: busybox
|
||||
type: worker
|
||||
status:
|
||||
...
|
||||
latestRevision:
|
||||
name: website-v1
|
||||
revision: 1
|
||||
revisionHash: e9e062e2cddfe5fb
|
||||
services:
|
||||
- healthy: true
|
||||
name: frontend
|
||||
traits:
|
||||
- healthy: true
|
||||
type: cpuscaler
|
||||
- healthy: true
|
||||
type: sidecar
|
||||
- healthy: true
|
||||
name: backend
|
||||
status: running
|
||||
- name: frontend
|
||||
type: webservice
|
||||
properties:
|
||||
image: oamdev/testapp:v1
|
||||
cmd: ["node", "server.js"]
|
||||
port: 8080
|
||||
cpu: "0.1"
|
||||
env:
|
||||
- name: FOO
|
||||
value: bar
|
||||
- name: FOO
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
name: bar
|
||||
key: bar
|
||||
```
|
||||
|
||||
Here are some highlight information that you need to know:
|
||||
### Declare Volumes
|
||||
|
||||
1. `status.latestRevision` declares current revision of this application.
|
||||
2. `status.services` declares the component created by this application and the healthy state.
|
||||
3. `status.status` declares the global state of this application.
|
||||
The `Web Service` component exposes configurations for certain volume types including `PersistenVolumeClaim`, `ConfigMap`, `Secret`, and `EmptyDir`.
|
||||
|
||||
### List Application Revisions
|
||||
|
||||
When we update an application, if there's any difference on spec, KubeVela will create a new revision.
|
||||
|
||||
```shell
|
||||
$ kubectl get apprev -l app.oam.dev/name=website
|
||||
NAME AGE
|
||||
website-v1 35m
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: website
|
||||
spec:
|
||||
components:
|
||||
- name: frontend
|
||||
type: webservice
|
||||
properties:
|
||||
image: nginx
|
||||
volumes:
|
||||
- name: "my-pvc"
|
||||
mountPath: "/var/www/html1"
|
||||
type: "pvc" # PersistenVolumeClaim volume
|
||||
claimName: "myclaim"
|
||||
- name: "my-cm"
|
||||
mountPath: "/var/www/html2"
|
||||
type: "configMap" # ConfigMap volume (specifying items)
|
||||
cmName: "myCmName"
|
||||
items:
|
||||
- key: "k1"
|
||||
path: "./a1"
|
||||
- key: "k2"
|
||||
path: "./a2"
|
||||
- name: "my-cm-noitems"
|
||||
mountPath: "/var/www/html22"
|
||||
type: "configMap" # ConfigMap volume (not specifying items)
|
||||
cmName: "myCmName2"
|
||||
- name: "mysecret"
|
||||
type: "secret" # Secret volume
|
||||
mountPath: "/var/www/html3"
|
||||
secretName: "mysecret"
|
||||
- name: "my-empty-dir"
|
||||
type: "emptyDir" # EmptyDir volume
|
||||
mountPath: "/var/www/html4"
|
||||
```
|
||||
|
||||
## Explore Components
|
||||
## Specification
|
||||
|
||||
You can explore what kinds of component definitions supported in your system.
|
||||
|
||||
```shell
|
||||
kubectl get comp -n vela-system
|
||||
NAME WORKLOAD-KIND DESCRIPTION
|
||||
task Job Describes jobs that run code or a script to completion.
|
||||
webservice Deployment Describes long-running, scalable, containerized services that have a stable network endpoint to receive external network traffic from customers.
|
||||
worker Deployment Describes long-running, scalable, containerized services that running at backend. They do NOT have network endpoint to receive external network traffic.
|
||||
```
|
||||
|
||||
The component definition objects are namespace isolated align with application, while the `vela-system` is a common system namespace of KubeVela,
|
||||
definitions laid here can be used by every application.
|
||||
|
||||
You can use [vela kubectl plugin](./kubectlplugin) to view the detail usage of specific component definition.
|
||||
|
||||
```shell
|
||||
$ kubectl vela show webservice
|
||||
```console
|
||||
# Properties
|
||||
+------------------+----------------------------------------------------------------------------------+-----------------------+----------+---------+
|
||||
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
|
||||
@@ -151,34 +126,4 @@ $ kubectl vela show webservice
|
||||
| name | The name of the secret in the pod's namespace to select from | string | true | |
|
||||
| key | The key of the secret to select from. Must be a valid secret key | string | true | |
|
||||
+------+------------------------------------------------------------------+--------+----------+---------+
|
||||
```
|
||||
|
||||
## Explore Traits
|
||||
|
||||
You can explore what kinds of trait definitions supported in your system.
|
||||
|
||||
```shell
|
||||
$ kubectl get trait -n vela-system
|
||||
NAME APPLIES-TO DESCRIPTION
|
||||
cpuscaler [webservice worker] configure k8s HPA with CPU metrics for Deployment
|
||||
ingress [webservice worker] Configures K8s ingress and service to enable web traffic for your service. Please use route trait in cap center for advanced usage.
|
||||
scaler [webservice worker] Configures replicas for your service.
|
||||
sidecar [webservice worker] inject a sidecar container into your app
|
||||
```
|
||||
|
||||
The trait definition objects are namespace isolated align with application, while the `vela-system` is a common system namespace of KubeVela,
|
||||
definitions laid here can be used by every application.
|
||||
|
||||
You can use `kubectl vela show` to see the usage of specific trait definition.
|
||||
|
||||
```shell
|
||||
$ kubectl vela show sidecar
|
||||
# Properties
|
||||
+---------+-----------------------------------------+----------+----------+---------+
|
||||
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
|
||||
+---------+-----------------------------------------+----------+----------+---------+
|
||||
| name | Specify the name of sidecar container | string | true | |
|
||||
| image | Specify the image of sidecar container | string | true | |
|
||||
| command | Specify the commands run in the sidecar | []string | false | |
|
||||
+---------+-----------------------------------------+----------+----------+---------+
|
||||
```
|
||||
37
docs/en/end-user/components/worker.md
Normal file
37
docs/en/end-user/components/worker.md
Normal file
@@ -0,0 +1,37 @@
|
||||
---
|
||||
title: Worker
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
Describes long-running, scalable, containerized services that running at backend. They do NOT have network endpoint to receive external network traffic.
|
||||
|
||||
## Samples
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: app-worker
|
||||
spec:
|
||||
components:
|
||||
- name: myworker
|
||||
type: worker
|
||||
properties:
|
||||
image: "busybox"
|
||||
cmd:
|
||||
- sleep
|
||||
- "1000"
|
||||
```
|
||||
|
||||
## Specification
|
||||
|
||||
```console
|
||||
# Properties
|
||||
+-------+----------------------------------------------------+----------+----------+---------+
|
||||
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
|
||||
+-------+----------------------------------------------------+----------+----------+---------+
|
||||
| cmd | Commands to run in the container | []string | false | |
|
||||
| image | Which image would you like to use for your service | string | true | |
|
||||
+-------+----------------------------------------------------+----------+----------+---------+
|
||||
```
|
||||
@@ -1,8 +1,8 @@
|
||||
---
|
||||
title: Debug and Test
|
||||
title: Dry-Run and Live-Diff
|
||||
---
|
||||
|
||||
You can make further debug and test for your application by using [vela kubectl plugin](./kubectlplugin).
|
||||
KubeVela allows you to dry-run and live-diff your application.
|
||||
|
||||
## Dry-Run the `Application`
|
||||
|
||||
@@ -1,74 +0,0 @@
|
||||
---
|
||||
title: Labels and Annotations
|
||||
---
|
||||
|
||||
We will introduce how to add labels and annotations to your Application.
|
||||
|
||||
## List Traits
|
||||
|
||||
```bash
|
||||
$ kubectl get trait -n vela-system
|
||||
NAME APPLIES-TO DESCRIPTION
|
||||
annotations ["webservice","worker"] Add annotations for your Workload.
|
||||
cpuscaler ["webservice","worker"] configure k8s HPA with CPU metrics for Deployment
|
||||
ingress ["webservice","worker"] Configures K8s ingress and service to enable web traffic for your service. Please use route trait in cap center for advanced usage.
|
||||
labels ["webservice","worker"] Add labels for your Workload.
|
||||
scaler ["webservice","worker"] Configures replicas for your service by patch replicas field.
|
||||
sidecar ["webservice","worker"] inject a sidecar container into your app
|
||||
```
|
||||
|
||||
You can use `label` and `annotations` traits to add labels and annotations for your workload.
|
||||
|
||||
## Apply Application
|
||||
|
||||
Let's use `label` and `annotations` traits in your Application.
|
||||
|
||||
```shell
|
||||
# myapp.yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: myapp
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
traits:
|
||||
- type: labels
|
||||
properties:
|
||||
"release": "stable"
|
||||
- type: annotations
|
||||
properties:
|
||||
"description": "web application"
|
||||
```
|
||||
|
||||
Apply this Application.
|
||||
|
||||
```shell
|
||||
kubectl apply -f myapp.yaml
|
||||
```
|
||||
|
||||
Check the workload has been created successfully.
|
||||
|
||||
```bash
|
||||
$ kubectl get deployments
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
express-server 1/1 1 1 15s
|
||||
```
|
||||
|
||||
Check the `labels` trait.
|
||||
|
||||
```bash
|
||||
$ kubectl get deployments express-server -o jsonpath='{.spec.template.metadata.labels}'
|
||||
{"app.oam.dev/component":"express-server","release": "stable"}
|
||||
```
|
||||
|
||||
Check the `annotations` trait.
|
||||
|
||||
```bash
|
||||
$ kubectl get deployments express-server -o jsonpath='{.spec.template.metadata.annotations}'
|
||||
{"description":"web application"}
|
||||
```
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Rollout
|
||||
title: Canary
|
||||
---
|
||||
|
||||
## Description
|
||||
89
docs/en/end-user/scopes/health.md
Normal file
89
docs/en/end-user/scopes/health.md
Normal file
@@ -0,0 +1,89 @@
|
||||
---
|
||||
title: Aggregated Health Probe
|
||||
---
|
||||
|
||||
The `HealthyScope` allows you to define an aggregated health probe for all components in same application.
|
||||
|
||||
1.Create health scope instance.
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1alpha2
|
||||
kind: HealthScope
|
||||
metadata:
|
||||
name: health-check
|
||||
namespace: default
|
||||
spec:
|
||||
probe-interval: 60
|
||||
workloadRefs:
|
||||
- apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
name: express-server
|
||||
```
|
||||
2. Create an application that drops in this health scope.
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: vela-app
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8080 # change port
|
||||
cpu: 0.5 # add requests cpu units
|
||||
scopes:
|
||||
healthscopes.core.oam.dev: health-check
|
||||
```
|
||||
3. Check the reference of the aggregated health probe (`status.service.scopes`).
|
||||
```shell
|
||||
$ kubectl get app vela-app -o yaml
|
||||
```
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: vela-app
|
||||
...
|
||||
status:
|
||||
...
|
||||
services:
|
||||
- healthy: true
|
||||
name: express-server
|
||||
scopes:
|
||||
- apiVersion: core.oam.dev/v1alpha2
|
||||
kind: HealthScope
|
||||
name: health-check
|
||||
```
|
||||
4.Check health scope detail.
|
||||
```shell
|
||||
$ kubectl get healthscope health-check -o yaml
|
||||
```
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1alpha2
|
||||
kind: HealthScope
|
||||
metadata:
|
||||
name: health-check
|
||||
...
|
||||
spec:
|
||||
probe-interval: 60
|
||||
workloadRefs:
|
||||
- apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
name: express-server
|
||||
status:
|
||||
healthConditions:
|
||||
- componentName: express-server
|
||||
diagnosis: 'Ready:1/1 '
|
||||
healthStatus: HEALTHY
|
||||
targetWorkload:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
name: express-server
|
||||
scopeHealthCondition:
|
||||
healthStatus: HEALTHY
|
||||
healthyWorkloads: 1
|
||||
total: 1
|
||||
```
|
||||
|
||||
It shows the aggregated health status for all components in this application.
|
||||
@@ -2,7 +2,7 @@
|
||||
title: Progressive Rollout RoadMap
|
||||
---
|
||||
|
||||
Here are some workitems on the roadmap
|
||||
Here are some working items on the roadmap
|
||||
|
||||
## Embed rollout in an application
|
||||
|
||||
66
docs/en/end-user/scopes/rollout-plan.md
Normal file
66
docs/en/end-user/scopes/rollout-plan.md
Normal file
@@ -0,0 +1,66 @@
|
||||
---
|
||||
title: Rollout Plan
|
||||
---
|
||||
In this documentation, we will show how to use the rollout plan to rolling update an application.
|
||||
|
||||
## Overview
|
||||
|
||||
By default, when we update the properties of application, KubeVela will update the underlying instances directly. The availability of the application will be guaranteed by rollout traits (if any).
|
||||
|
||||
Though KubeVela also provides a rolling style update mechanism, you can specify the `spec.rolloutPlan` in application to do so.
|
||||
|
||||
## Example
|
||||
|
||||
1. Deploy application to the cluster
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: test-rolling
|
||||
spec:
|
||||
components:
|
||||
- name: metrics-provider
|
||||
type: worker
|
||||
properties:
|
||||
cmd:
|
||||
- ./podinfo
|
||||
- stress-cpu=1.0
|
||||
image: stefanprodan/podinfo:4.0.6
|
||||
port: 8080
|
||||
rolloutPlan:
|
||||
rolloutStrategy: "IncreaseFirst"
|
||||
rolloutBatches:
|
||||
- replicas: 50%
|
||||
- replicas: 50%
|
||||
targetSize: 6
|
||||
```
|
||||
|
||||
2. User can modify the application container command and apply
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: test-rolling
|
||||
spec:
|
||||
components:
|
||||
- name: metrics-provider
|
||||
type: worker
|
||||
properties:
|
||||
cmd:
|
||||
- ./podinfo
|
||||
- stress-cpu=2.0
|
||||
image: stefanprodan/podinfo:4.0.6
|
||||
port: 8080
|
||||
rolloutPlan:
|
||||
rolloutStrategy: "IncreaseFirst"
|
||||
rolloutBatches:
|
||||
- replicas: 50%
|
||||
- replicas: 50%
|
||||
targetSize: 6
|
||||
```
|
||||
|
||||
User can check the status of the application and see the rollout completes, and the
|
||||
application's `status.rollout.rollingState` becomes `rolloutSucceed`.
|
||||
|
||||
|
||||
|
||||
58
docs/en/end-user/traits/annotations-and-labels.md
Normal file
58
docs/en/end-user/traits/annotations-and-labels.md
Normal file
@@ -0,0 +1,58 @@
|
||||
---
|
||||
title: Labels and Annotations
|
||||
---
|
||||
|
||||
|
||||
## List Traits
|
||||
|
||||
The `label` and `annotations` traits allows you to append labels and annotations to the component.
|
||||
|
||||
```shell
|
||||
# myapp.yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: myapp
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
traits:
|
||||
- type: labels
|
||||
properties:
|
||||
"release": "stable"
|
||||
- type: annotations
|
||||
properties:
|
||||
"description": "web application"
|
||||
```
|
||||
|
||||
Deploy this application.
|
||||
|
||||
```shell
|
||||
kubectl apply -f myapp.yaml
|
||||
```
|
||||
|
||||
On runtime cluster, check the workload has been created successfully.
|
||||
|
||||
```bash
|
||||
$ kubectl get deployments
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
express-server 1/1 1 1 15s
|
||||
```
|
||||
|
||||
Check the `labels`.
|
||||
|
||||
```bash
|
||||
$ kubectl get deployments express-server -o jsonpath='{.spec.template.metadata.labels}'
|
||||
{"app.oam.dev/component":"express-server","release": "stable"}
|
||||
```
|
||||
|
||||
Check the `annotations`.
|
||||
|
||||
```bash
|
||||
$ kubectl get deployments express-server -o jsonpath='{.spec.template.metadata.annotations}'
|
||||
{"description":"web application"}
|
||||
```
|
||||
@@ -1,12 +1,10 @@
|
||||
---
|
||||
title: Expose Application
|
||||
title: Ingress
|
||||
---
|
||||
|
||||
> ⚠️ This section requires your cluster has a working ingress.
|
||||
> ⚠️ This section requires your runtime cluster has a working ingress controller.
|
||||
|
||||
To expose your application publicly, you just need to add an `ingress` trait.
|
||||
|
||||
View ingress schema by [vela kubectl plugin](./kubectlplugin).
|
||||
The `ingress` trait exposes a component to public Internet via a valid domain.
|
||||
|
||||
```shell
|
||||
$ kubectl vela show ingress
|
||||
@@ -19,7 +17,7 @@ $ kubectl vela show ingress
|
||||
+--------+------------------------------------------------------------------------------+----------------+----------+---------+
|
||||
```
|
||||
|
||||
Then modify and deploy this application.
|
||||
Attach a `ingress` trait to the component you want to expose and deploy.
|
||||
|
||||
```yaml
|
||||
# vela-app.yaml
|
||||
@@ -56,7 +54,7 @@ first-vela-app express-server webservice healthChecking
|
||||
first-vela-app express-server webservice running true 42s
|
||||
```
|
||||
|
||||
You can also see the trait detail for the visiting url:
|
||||
Check the trait detail for the its visiting url:
|
||||
|
||||
```shell
|
||||
$ kubectl get application first-vela-app -o yaml
|
||||
@@ -78,7 +76,7 @@ spec:
|
||||
...
|
||||
```
|
||||
|
||||
Then you will be able to visit this service.
|
||||
Then you will be able to visit this application via its domain.
|
||||
|
||||
```
|
||||
$ curl -H "Host:testsvc.example.com" http://<your ip address>/
|
||||
7
docs/en/end-user/traits/more.md
Normal file
7
docs/en/end-user/traits/more.md
Normal file
@@ -0,0 +1,7 @@
|
||||
---
|
||||
title: Want More?
|
||||
---
|
||||
|
||||
Traits in KubeVela are designed as modularized building blocks, they are fully customizable and pluggable.
|
||||
|
||||
Check [this documentation](../../platform-engineers/cue/trait) about how to design and enable your own traits in KubeVela platform.
|
||||
@@ -1,12 +1,8 @@
|
||||
---
|
||||
title: Scale
|
||||
title: Manual Scaling
|
||||
---
|
||||
|
||||
In the [Deploy Application](../application) section, we use `cpuscaler` trait as an auto-scaler for the sample application.
|
||||
|
||||
## Manuel Scale
|
||||
|
||||
You can use scale your application manually by using `scaler` trait.
|
||||
The `scaler` trait allows you to scale your component instance manually.
|
||||
|
||||
```shell
|
||||
$ kubectl vela show scaler
|
||||
@@ -18,7 +14,7 @@ $ kubectl vela show scaler
|
||||
+----------+--------------------------------+------+----------+---------+
|
||||
```
|
||||
|
||||
Deploy the application.
|
||||
Declare an application with scaler trait.
|
||||
|
||||
```yaml
|
||||
# sample-manual.yaml
|
||||
@@ -49,14 +45,14 @@ spec:
|
||||
- '1000'
|
||||
```
|
||||
|
||||
Change and Apply the sample application:
|
||||
Apply the sample application:
|
||||
|
||||
```shell
|
||||
$ kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/enduser/sample-manual.yaml
|
||||
application.core.oam.dev/website configured
|
||||
```
|
||||
|
||||
After a while, you can see the underlying deployment of `frontend` component has two replicas now.
|
||||
In runtime cluster, you can see the underlying deployment of `frontend` component has 2 replicas now.
|
||||
|
||||
```shell
|
||||
$ kubectl get deploy -l app.oam.dev/name=website
|
||||
@@ -65,4 +61,4 @@ backend 1/1 1 1 19h
|
||||
frontend 2/2 2 2 19h
|
||||
```
|
||||
|
||||
To scale up or scale down, you can just modify the `replicas` field of `scaler` trait and apply the application again.
|
||||
To scale up or scale down, you just need to modify the `replicas` field of `scaler` trait and re-apply the YAML.
|
||||
92
docs/en/end-user/traits/service-binding.md
Normal file
92
docs/en/end-user/traits/service-binding.md
Normal file
@@ -0,0 +1,92 @@
|
||||
---
|
||||
title: Service Binding
|
||||
---
|
||||
|
||||
Service binding trait will bind data from Kubernetes `Secret` to the application container's ENV.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: TraitDefinition
|
||||
metadata:
|
||||
annotations:
|
||||
definition.oam.dev/description: "binding cloud resource secrets to pod env"
|
||||
name: service-binding
|
||||
spec:
|
||||
appliesToWorkloads:
|
||||
- webservice
|
||||
- worker
|
||||
schematic:
|
||||
cue:
|
||||
template: |
|
||||
patch: {
|
||||
spec: template: spec: {
|
||||
// +patchKey=name
|
||||
containers: [{
|
||||
name: context.name
|
||||
// +patchKey=name
|
||||
env: [
|
||||
for envName, v in parameter.envMappings {
|
||||
name: envName
|
||||
valueFrom: {
|
||||
secretKeyRef: {
|
||||
name: v.secret
|
||||
if v["key"] != _|_ {
|
||||
key: v.key
|
||||
}
|
||||
if v["key"] == _|_ {
|
||||
key: envName
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
]
|
||||
}]
|
||||
}
|
||||
}
|
||||
|
||||
parameter: {
|
||||
// +usage=The mapping of environment variables to secret
|
||||
envMappings: [string]: [string]: string
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
With the help of this `service-binding` trait, you can explicitly set parameter `envMappings` to mapping all
|
||||
environment names with secret key. Here is an example.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: webapp
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: zzxwill/flask-web-application:v0.3.1-crossplane
|
||||
ports: 80
|
||||
traits:
|
||||
- type: service-binding
|
||||
properties:
|
||||
envMappings:
|
||||
# environments refer to db-conn secret
|
||||
DB_PASSWORD:
|
||||
secret: db-conn
|
||||
key: password # 1) If the env name is different from secret key, secret key has to be set.
|
||||
endpoint:
|
||||
secret: db-conn # 2) If the env name is the same as the secret key, secret key can be omitted.
|
||||
username:
|
||||
secret: db-conn
|
||||
|
||||
- name: sample-db
|
||||
type: alibaba-rds
|
||||
properties:
|
||||
name: sample-db
|
||||
engine: mysql
|
||||
engineVersion: "8.0"
|
||||
instanceClass: rds.mysql.c1.large
|
||||
username: oamtest
|
||||
secretName: db-conn
|
||||
|
||||
```
|
||||
@@ -1,8 +1,8 @@
|
||||
---
|
||||
title: Attach Sidecar
|
||||
title: Attaching Sidecar
|
||||
---
|
||||
|
||||
In this section, we will show you how to use `sidecar` trait to collect logs.
|
||||
The `sidecar` trait allows you to attach a sidecar container to the component.
|
||||
|
||||
## Show the Usage of Sidecar
|
||||
|
||||
@@ -28,7 +28,7 @@ $ kubectl vela show sidecar
|
||||
+-----------+-------------+--------+----------+---------+
|
||||
```
|
||||
|
||||
## Apply the Application
|
||||
## Deploy the Application
|
||||
|
||||
In this Application, component `log-gen-worker` and sidecar share the data volume that saves the logs.
|
||||
The sidebar will re-output the log to stdout.
|
||||
@@ -71,13 +71,13 @@ spec:
|
||||
path: /var/log
|
||||
```
|
||||
|
||||
Apply this Application.
|
||||
Deploy this Application.
|
||||
|
||||
```shell
|
||||
kubectl apply -f app.yaml
|
||||
```
|
||||
|
||||
Check the workload generate by Application.
|
||||
On runtime cluster, check the name of running pod.
|
||||
|
||||
```shell
|
||||
$ kubectl get pod
|
||||
@@ -85,7 +85,7 @@ NAME READY STATUS RESTARTS AGE
|
||||
log-gen-worker-76945f458b-k7n9k 2/2 Running 0 90s
|
||||
```
|
||||
|
||||
Check the output of sidecar.
|
||||
And check the logging output of sidecar.
|
||||
|
||||
```shell
|
||||
$ kubectl logs -f log-gen-worker-76945f458b-k7n9k count-log
|
||||
51
docs/en/end-user/traits/volumes.md
Normal file
51
docs/en/end-user/traits/volumes.md
Normal file
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: Cloud Volumes
|
||||
---
|
||||
|
||||
This section introduces how to attach cloud volumes to the component. For example, AWS ElasticBlockStore,
|
||||
Azure Disk, Alibaba Cloud OSS, etc.
|
||||
|
||||
Cloud volumes are not built-in capabilities in KubeVela so you need to enable these traits first. Let's use AWS EBS as example.
|
||||
|
||||
Install and check the `TraitDefinition` for AWS EBS volume trait.
|
||||
|
||||
```shell
|
||||
$ kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/app-with-volumes/td-awsEBS.yaml
|
||||
```
|
||||
|
||||
```shell
|
||||
$ kubectl vela show aws-ebs-volume
|
||||
+-----------+----------------------------------------------------------------+--------+----------+---------+
|
||||
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
|
||||
+-----------+----------------------------------------------------------------+--------+----------+---------+
|
||||
| name | The name of volume. | string | true | |
|
||||
| mountPath | | string | true | |
|
||||
| volumeID | Unique id of the persistent disk resource. | string | true | |
|
||||
| fsType | Filesystem type to mount. | string | true | ext4 |
|
||||
| partition | Partition on the disk to mount. | int | false | |
|
||||
| readOnly | ReadOnly here will force the ReadOnly setting in VolumeMounts. | bool | true | false |
|
||||
+-----------+----------------------------------------------------------------+--------+----------+---------+
|
||||
```
|
||||
|
||||
Then we can now attach a `aws-ebs` volume to a component.
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: app-worker
|
||||
spec:
|
||||
components:
|
||||
- name: myworker
|
||||
type: worker
|
||||
properties:
|
||||
image: "busybox"
|
||||
cmd:
|
||||
- sleep
|
||||
- "1000"
|
||||
traits:
|
||||
- type: aws-ebs-volume
|
||||
properties:
|
||||
name: "my-ebs"
|
||||
mountPath: "/myebs"
|
||||
volumeID: "my-ebs-id"
|
||||
```
|
||||
@@ -1,8 +0,0 @@
|
||||
---
|
||||
title: Attach Volumes
|
||||
---
|
||||
|
||||
TBD, Content Overview:
|
||||
|
||||
1. attach basic volume for application.
|
||||
2. Extend custom volume types and attach.
|
||||
@@ -7,13 +7,13 @@ import TabItem from '@theme/TabItem';
|
||||
|
||||
> For upgrading existing KubeVela, please read the [upgrade guide](./advanced-install#upgrade).
|
||||
|
||||
## 1. Choose Kubernetes Cluster
|
||||
## 1. Choose Control Plane Cluster
|
||||
|
||||
Requirements:
|
||||
- Kubernetes cluster >= v1.15.0
|
||||
- `kubectl` installed and configured
|
||||
|
||||
KubeVela is a simple custom controller that can be installed on any Kubernetes cluster including managed offerings or your own clusters. The only requirement is please ensure [ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/) is installed and enabled.
|
||||
KubeVela relies on Kubernetes as control plane. The control plane could be any managed Kubernetes offering or your own cluster. The only requirement is please ensure [ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/) is installed and enabled.
|
||||
|
||||
For for local deployment and test, you could use `minikube` or `kind`.
|
||||
|
||||
@@ -78,11 +78,11 @@ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/mast
|
||||
</Tabs>
|
||||
|
||||
|
||||
## 2. Install KubeVela Controller
|
||||
## 2. Install KubeVela
|
||||
|
||||
1. Add helm chart repo for KubeVela
|
||||
```shell script
|
||||
helm repo add kubevela https://kubevelacharts.oss-cn-hangzhou.aliyuncs.com/core
|
||||
helm repo add kubevela https://kubevelacharts.oss-accelerate.aliyuncs.com/core
|
||||
```
|
||||
|
||||
2. Update the chart repo
|
||||
@@ -130,9 +130,9 @@ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/mast
|
||||
|
||||
## 3. Get KubeVela CLI
|
||||
|
||||
Using KubeVela CLI gives you a simplified workflow with optimized output comparing to using `kubectl`. It is not mandatory though.
|
||||
KubeVela CLI gives you a simplified workflow to manage applications with optimized output. It is not mandatory though.
|
||||
|
||||
Here are three ways to get KubeVela Cli:
|
||||
KubeVela CLI could be [installed as kubectl plugin](./kubectl-plugin.mdx), or install as standalone binary.
|
||||
|
||||
<Tabs
|
||||
className="unique-tabs"
|
||||
@@ -188,7 +188,6 @@ sudo mv ./vela /usr/local/bin/vela
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
## 4. Enable Helm Support
|
||||
|
||||
KubeVela leverages Helm controller from [Flux v2](https://github.com/fluxcd/flux2) to deploy [Helm](https://helm.sh/) based components.
|
||||
@@ -196,7 +195,7 @@ KubeVela leverages Helm controller from [Flux v2](https://github.com/fluxcd/flux
|
||||
You can enable this feature by installing a minimal Flux v2 chart as below:
|
||||
|
||||
```shell
|
||||
$ helm install --create-namespace -n flux-system helm-flux http://oam.dev/catalog/helm-flux2-0.1.0.tgz
|
||||
helm install --create-namespace -n flux-system helm-flux http://oam.dev/catalog/helm-flux2-0.1.0.tgz
|
||||
```
|
||||
|
||||
Or you could install full Flux v2 following its own guide of course.
|
||||
|
||||
@@ -8,64 +8,77 @@ slug: /
|
||||
|
||||
## Motivation
|
||||
|
||||
The trend of cloud-native technology is moving towards pursuing consistent application delivery across clouds and on-premises infrastructures using Kubernetes as the common abstraction layer. Kubernetes, although excellent in abstracting low-level infrastructure details, does introduce extra complexity to application developers, namely understanding the concepts of pods, port exposing, privilege escalation, resource claims, CRD, and so on. We’ve seen the nontrivial learning curve and the lack of developer-facing abstraction have impacted user experiences, slowed down productivity, led to unexpected errors or misconfigurations in production. People start to question the value of this revolution: "why am I bothered with all these details?".
|
||||
The trend of cloud-native technology is moving towards pursuing consistent application delivery across clouds and on-premises infrastructures using Kubernetes as the common layer. Kubernetes, although excellent in abstracting low-level infrastructure details, does not introduce abstractions to model software deployment on top of hybrid environments. We’ve seen the lack of such application level context have impacted user experiences, slowed down productivity, led to unexpected errors or misconfigurations in production.
|
||||
|
||||
On the other hand, abstracting Kubernetes to serve developers' requirements is a highly opinionated process, and the resultant abstractions would only make sense had the decision makers been the platform builders. Unfortunately, the platform builders today face the following dilemma:
|
||||
|
||||
*There is no tool or framework for them to easily build user friendly yet highly extensible abstractions*.
|
||||
|
||||
Thus, many platforms today are essentially restricted abstractions with in-house add-on mechanisms despite the extensibility of Kubernetes. This makes extending such platforms for developers' requirements or to wider scenarios almost impossible, not to mention taking the full advantage of the rich Kubernetes ecosystems.
|
||||
|
||||
In the end, developers complain those platforms are too rigid and slow in response to feature requests or improvements. The platform builders do want to help but the engineering effort is daunting: any simple API change in the platform could easily become a marathon negotiation around the opinionated abstraction design.
|
||||
On the other hand, modeling a deployment of a modern microservice application is a highly opinionated and fragmented process today. Thus, most solutions aim to solve above problem (although built with Kubernetes) are essentially restricted systems and barely extensible. As the needs of your application grow, they are almost certain to outgrow the capabilities of such systems. Application teams complain they are too rigid and slow in response to feature requests or improvements. The platform team do want to help but the engineering effort is daunting: any simple API change in the platform could easily become a marathon negotiation around the opinionated abstraction design.
|
||||
|
||||
## What is KubeVela?
|
||||
|
||||
For platform builders, KubeVela serves as a framework that relieves the pains of building developer focused platforms by doing the following:
|
||||
KubeVela is a modern application platform that aims to make deploying and managing applications across hybrid, multi-cloud environments easier and faster by doing the following:
|
||||
|
||||
- Developer Centric. KubeVela introduces the Application as the main API to capture a full deployment of microservices, and builds features around the application needs only. Progressive rollout and multi-cluster deployment are provided out-of-box. No infrastructure level concerns, simply deploy.
|
||||
|
||||
- Extending Natively. In KubeVela, all platform features (such as workloads, operational behaviors, and cloud services) are defined as reusable [CUE](https://github.com/cuelang/cue) and/or [Helm](https://helm.sh) components, per needs of the application deployment. And when application's needs grow, your platform capabilities expand naturally in a programmable approach.
|
||||
**Application Centric** - KubeVela introduces consistent yet application centric API to capture a full deployment of microservices on top of hybrid environments. No infrastructure level concern, simply deploy.
|
||||
|
||||
- Simple yet Reliable. Perfect in flexibility though, X-as-Code may lead to configuration drift (i.e. the running instances are not in line with the expected configuration). KubeVela solves this by modeling its capabilities as code but enforce them via Kubernetes control loop which will never leave inconsistency in your clusters. This also makes KubeVela work with any CI/CD or GitOps tools via declarative API without integration burden.
|
||||
**Natively Extensible** - KubeVela uses CUE to glue capabilities provided by runtime infrastructure and expose them to users via self-service API. When users' needs grow, these API can naturally expand in programmable approach.
|
||||
|
||||
With KubeVela, the platform builders finally have the tooling supports to design easy-to-use abstractions and ship them to end-users with high confidence and low turn around time.
|
||||
**Runtime Agnostic** - KubeVela is built with Kubernetes as control plane but adaptable to any runtime as data-plane. It can deploy (and manage) diverse workload types such as container, cloud functions, databases, or even EC2 instances across hybrid environments.
|
||||
|
||||
For end-users (e.g. app developers and operators), these abstractions will enable them to design and ship applications to Kubernetes clusters with minimal effort, and instead of managing a handful infrastructure details, a simple application definition that can be easily integrated with any CI/CD pipeline is all they need.
|
||||
## Architecture
|
||||
|
||||
The overall architecture of KubeVela is shown as below:
|
||||
|
||||

|
||||
|
||||
### Control Plane
|
||||
|
||||
Control plane is where KubeVela itself lives in. As the project's name implies, KubeVela by design leverages Kubernetes as control plane. This is the key of how KubeVela brings full *automation* and strong *determinism* to application delivery at scale. Users will interact with KubeVela via the application centric API to model the application deployment, and KubeVela will distribute it to target *runtime infrastructure* per policies and rules declared by users.
|
||||
|
||||
### Runtime Infrastructures
|
||||
|
||||
Runtime infrastructures are where the applications are actually running on. KubeVela allows you to model and deploy applications to any Kubernetes based infrastructure (either local, managed offerings, or IoT/Edge/On-Premise ones), or to public cloud platforms.
|
||||
|
||||
## Comparisons
|
||||
|
||||
### KubeVela vs. Platform-as-a-Service (PaaS)
|
||||
|
||||
The typical examples are Heroku and Cloud Foundry. They provide full application management capabilities and aim to improve developer experience and efficiency. In this context, KubeVela shares the same goal.
|
||||
The typical examples are Heroku and Cloud Foundry. They provide full application deployment and management capabilities and aim to improve developer experience and efficiency. In this context, KubeVela shares the same goal.
|
||||
|
||||
Though the biggest difference lies in **flexibility**.
|
||||
|
||||
KubeVela is a Kubernetes add-on that enabling you to serve end users with programmable building blocks which are fully flexible and coded by yourself. Comparing to this mechanism, traditional PaaS systems are highly restricted, i.e. they have to enforce constraints in the type of supported applications and capabilities, and as application needs grows, you always outgrow the capabilities of the PaaS system - this will never happen in KubeVela platform.
|
||||
KubeVela enables you to serve end users with programmable building blocks (based on [CUE](https://cuelang.org/)) which are fully flexible and can be extended at any time. Comparing to this mechanism, traditional PaaS systems are highly restricted, i.e. they have to enforce constraints in the type of supported applications and capabilities, and as application needs grows, you always outgrow the capabilities of the PaaS system - this will never happen in KubeVela platform.
|
||||
|
||||
So think of KubeVela as a Heroku that is fully extensible to serve your needs as you grow.
|
||||
So think of KubeVela as a Heroku but it is fully extensible when your needs grow.
|
||||
|
||||
### KubeVela vs. Serverless
|
||||
|
||||
Serverless platform such as AWS Lambda provides extraordinary user experience and agility to deploy serverless applications. However, those platforms impose even more constraints in extensibility. They are arguably "hard-coded" PaaS.
|
||||
|
||||
Kubernetes based serverless platforms such as Knative, OpenFaaS can be easily integrated with KubeVela by registering themselves as new workload types and traits. Even for AWS Lambda, there is a success story to integrate it with KubeVela by the tools developed by Crossplane.
|
||||
KubeVela can easily deploy both Kubernetes based serverless workloads such as Knative/OpenFaaS, or cloud functions such as AWS Lambda. Simply register what you want to deploy as a "component".
|
||||
|
||||
### KubeVela vs. Platform agnostic developer tools
|
||||
|
||||
The typical example is Hashicorp's Waypoint. Waypoint is a developer facing tool which introduces a consistent workflow (i.e., build, deploy, release) to ship applications on top of different platforms.
|
||||
|
||||
KubeVela can be integrated into such tools as an application platform. In this case, developers could use the Waypoint workflow to manage applications with leverage of abstractions (e.g. application, rollout, ingress, autoscaling etc) you built via KubeVela.
|
||||
KubeVela can be integrated with such tools seamlessly. In this case, developers would use the Waypoint workflow as the UI to deploy and manage applications across hybrid environments with KubeVela's abstractions (e.g. applications, components, traits etc).
|
||||
|
||||
### KubeVela vs. Helm
|
||||
|
||||
Helm is a package manager for Kubernetes that provides package, install, and upgrade a set of YAML files for Kubernetes as a unit. KubeVela can patch, deploy and rollout Helm packaged application components, and it also leverages Helm to manage the capability dependencies in system level.
|
||||
Helm is a package manager for Kubernetes that provides package, install, and upgrade a set of YAML files for Kubernetes as a unit.
|
||||
|
||||
Though KubeVela itself is not a package manager, it's a core engine for platform builders to create developer-centric deployment system with easy and repeatable approach.
|
||||
KubeVela as a modern deployment system can naturally deploys Helm charts across hybrid environments. For example, you could easily use KubeVela to declare and deploy an application which is composed by a WordPress Helm chart and a AWS RDS instance defined by Terraform, or distribute the Helm chart to multiple clusters.
|
||||
|
||||
KubeVela also leverages Helm to manage the capability addons in runtime clusters.
|
||||
|
||||
### KubeVela vs. Kubernetes
|
||||
|
||||
KubeVela is a Kubernetes add-on for building developer-centric deployment system. It leverages [Open Application Model](https://github.com/oam-dev/spec) and the native Kubernetes extensibility to resolve a hard problem - making shipping applications enjoyable on Kubernetes.
|
||||
|
||||
## Getting Started
|
||||
|
||||
Now let's [get started](./quick-start.md) with KubeVela!
|
||||
## What's Next
|
||||
|
||||
Here are some recommended next steps:
|
||||
- [Get started](./quick-start) with KubeVela.
|
||||
- Learn KubeVela's [core concepts](./concepts).
|
||||
- Learn how to [deploy an application](end-user/application) in detail and understand how it works.
|
||||
- Join `#kubevela` channel in CNCF [Slack](https://cloud-native.slack.com) and/or [Gitter](https://gitter.im/oam-dev/community)
|
||||
|
||||
Welcome onboard and sail Vela!
|
||||
@@ -1,6 +1,8 @@
|
||||
---
|
||||
title: Install kubectl plugin
|
||||
---
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
Install vela kubectl plugin can help you to ship applications more easily!
|
||||
|
||||
@@ -8,6 +10,28 @@ Install vela kubectl plugin can help you to ship applications more easily!
|
||||
|
||||
You can install kubectl plugin `kubectl vela` by:
|
||||
|
||||
<Tabs
|
||||
className="unique-tabs"
|
||||
defaultValue="krew"
|
||||
values={[
|
||||
{label: 'Krew', value: 'krew'},
|
||||
{label: 'Script', value: 'script'},
|
||||
]}>
|
||||
<TabItem value="krew">
|
||||
|
||||
1. [Install and set up](https://krew.sigs.k8s.io/docs/user-guide/setup/install/) Krew on your machine.
|
||||
2. Discover plugins available on Krew:
|
||||
```shell
|
||||
kubectl krew update
|
||||
```
|
||||
3. install kubectl vela:
|
||||
```shell script
|
||||
kubectl krew install vela
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="script">
|
||||
|
||||
**macOS/Linux**
|
||||
```shell script
|
||||
curl -fsSl https://kubevela.io/script/install-kubectl-vela.sh | bash
|
||||
@@ -16,6 +40,11 @@ curl -fsSl https://kubevela.io/script/install-kubectl-vela.sh | bash
|
||||
You can also download the binary from [release pages ( >= v1.0.3)](https://github.com/oam-dev/kubevela/releases) manually.
|
||||
Kubectl will discover it from your system path automatically.
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
|
||||
## Usage
|
||||
|
||||
```shell
|
||||
@@ -1,355 +1,22 @@
|
||||
---
|
||||
title: Crossplane
|
||||
title: Overview
|
||||
---
|
||||
|
||||
Cloud services is also part of your application deployment.
|
||||
Cloud services are important components of your application, and KubeVela allows you to provision and consume them in a consistent experience.
|
||||
|
||||
## Should a Cloud Service be a Component or Trait?
|
||||
## How Does KubeVela Manage Cloud Services?
|
||||
|
||||
The following practice could be considered:
|
||||
- Use `ComponentDefinition` if:
|
||||
- you want to allow your end users explicitly claim a "instance" of the cloud service and consume it, and release the "instance" when deleting the application.
|
||||
- Use `TraitDefinition` if:
|
||||
- you don't want to give your end users any control/workflow of claiming or releasing the cloud service, you only want to give them a way to consume a cloud service which could even be managed by some other system. A `Service Binding` trait is widely used in this case.
|
||||
|
||||
In this documentation, we will define an Alibaba Cloud's RDS (Relational Database Service), and an Alibaba Cloud's OSS (Object Storage System) as example. This mechanism works the same with other cloud providers.
|
||||
In a single application, they are in form of Traits, and in multiple applications, they are in form of Components.
|
||||
In KubeVela, the needed cloud services are claimed as *components* in an application, and consumed via *Service Binding Trait* by other components.
|
||||
|
||||
## Install and Configure Crossplane
|
||||
## Does KubeVela Talk to the Clouds?
|
||||
|
||||
This guide will use [Crossplane](https://crossplane.io/) as the cloud service provider. Please Refer to [Installation](https://github.com/crossplane/provider-alibaba/releases/tag/v0.5.0)
|
||||
to install Crossplane Alibaba provider v0.5.0.
|
||||
KubeVela relies on [Terraform Controller](https://github.com/oam-dev/terraform-controller) or [Crossplane](http://crossplane.io/) as providers to talk to the clouds. Please check the documentations below for detailed steps.
|
||||
|
||||
If you'd like to configure any other Crossplane providers, please refer to [Crossplane Select a Getting Started Configuration](https://crossplane.io/docs/v1.1/getting-started/install-configure.html#select-a-getting-started-configuration).
|
||||
- [Terraform](./terraform.md)
|
||||
- [Crossplane](./crossplane.md)
|
||||
|
||||
```
|
||||
$ kubectl crossplane install provider crossplane/provider-alibaba:v0.5.0
|
||||
## Can a Instance of Cloud Services be Shared by Multiple Applications?
|
||||
|
||||
# Note the xxx and yyy here is your own AccessKey and SecretKey to the cloud resources.
|
||||
$ kubectl create secret generic alibaba-account-creds -n crossplane-system --from-literal=accessKeyId=xxx --from-literal=accessKeySecret=yyy
|
||||
Yes. Though we currently defer this to providers so by default the cloud service instances are not shared and dedicated per `Application`. A workaround for now is you could use a separate `Application` to declare the cloud service only, then other `Application` can consume it via service binding trait in a shared approach.
|
||||
|
||||
$ kubectl apply -f provider.yaml
|
||||
```
|
||||
|
||||
`provider.yaml` is as below.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Namespace
|
||||
metadata:
|
||||
name: crossplane-system
|
||||
|
||||
---
|
||||
apiVersion: alibaba.crossplane.io/v1alpha1
|
||||
kind: ProviderConfig
|
||||
metadata:
|
||||
name: default
|
||||
spec:
|
||||
credentials:
|
||||
source: Secret
|
||||
secretRef:
|
||||
namespace: crossplane-system
|
||||
name: alibaba-account-creds
|
||||
key: credentials
|
||||
region: cn-beijing
|
||||
```
|
||||
|
||||
Note: We currently just use Crossplane Alibaba provider. But we are about to use [Crossplane](https://crossplane.io/) as the
|
||||
cloud resource operator for Kubernetes in the near future.
|
||||
|
||||
## Register ComponentDefinition and TraitDefinition
|
||||
|
||||
### Register ComponentDefinition `alibaba-rds` as RDS cloud resource producer
|
||||
|
||||
Register the `alibaba-rds` workload type to KubeVela.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: ComponentDefinition
|
||||
metadata:
|
||||
name: alibaba-rds
|
||||
namespace: vela-system
|
||||
annotations:
|
||||
definition.oam.dev/description: "Alibaba Cloud RDS Resource"
|
||||
spec:
|
||||
workload:
|
||||
definition:
|
||||
apiVersion: database.alibaba.crossplane.io/v1alpha1
|
||||
kind: RDSInstance
|
||||
schematic:
|
||||
cue:
|
||||
template: |
|
||||
output: {
|
||||
apiVersion: "database.alibaba.crossplane.io/v1alpha1"
|
||||
kind: "RDSInstance"
|
||||
spec: {
|
||||
forProvider: {
|
||||
engine: parameter.engine
|
||||
engineVersion: parameter.engineVersion
|
||||
dbInstanceClass: parameter.instanceClass
|
||||
dbInstanceStorageInGB: 20
|
||||
securityIPList: "0.0.0.0/0"
|
||||
masterUsername: parameter.username
|
||||
}
|
||||
writeConnectionSecretToRef: {
|
||||
namespace: context.namespace
|
||||
name: parameter.secretName
|
||||
}
|
||||
providerConfigRef: {
|
||||
name: "default"
|
||||
}
|
||||
deletionPolicy: "Delete"
|
||||
}
|
||||
}
|
||||
parameter: {
|
||||
// +usage=RDS engine
|
||||
engine: *"mysql" | string
|
||||
// +usage=The version of RDS engine
|
||||
engineVersion: *"8.0" | string
|
||||
// +usage=The instance class for the RDS
|
||||
instanceClass: *"rds.mysql.c1.large" | string
|
||||
// +usage=RDS username
|
||||
username: string
|
||||
// +usage=Secret name which RDS connection will write to
|
||||
secretName: string
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
|
||||
### Register ComponentDefinition `alibaba-oss` as OSS cloud resource producer
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: ComponentDefinition
|
||||
metadata:
|
||||
name: alibaba-oss
|
||||
namespace: vela-system
|
||||
annotations:
|
||||
definition.oam.dev/description: "Alibaba Cloud RDS Resource"
|
||||
spec:
|
||||
workload:
|
||||
definition:
|
||||
apiVersion: oss.alibaba.crossplane.io/v1alpha1
|
||||
kind: Bucket
|
||||
schematic:
|
||||
cue:
|
||||
template: |
|
||||
output: {
|
||||
apiVersion: "oss.alibaba.crossplane.io/v1alpha1"
|
||||
kind: "Bucket"
|
||||
spec: {
|
||||
name: parameter.name
|
||||
acl: parameter.acl
|
||||
storageClass: parameter.storageClass
|
||||
dataRedundancyType: parameter.dataRedundancyType
|
||||
writeConnectionSecretToRef: {
|
||||
namespace: context.namespace
|
||||
name: parameter.secretName
|
||||
}
|
||||
providerConfigRef: {
|
||||
name: "default"
|
||||
}
|
||||
deletionPolicy: "Delete"
|
||||
}
|
||||
}
|
||||
parameter: {
|
||||
// +usage=OSS bucket name
|
||||
name: string
|
||||
// +usage=The access control list of the OSS bucket
|
||||
acl: *"private" | string
|
||||
// +usage=The storage type of OSS bucket
|
||||
storageClass: *"Standard" | string
|
||||
// +usage=The data Redundancy type of OSS bucket
|
||||
dataRedundancyType: *"LRS" | string
|
||||
// +usage=Secret name which RDS connection will write to
|
||||
secretName: string
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
### Register ComponentDefinition `webconsumer` with Secret Reference
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: ComponentDefinition
|
||||
metadata:
|
||||
name: webconsumer
|
||||
annotations:
|
||||
definition.oam.dev/description: A Deployment provides declarative updates for Pods and ReplicaSets
|
||||
spec:
|
||||
workload:
|
||||
definition:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
schematic:
|
||||
cue:
|
||||
template: |
|
||||
output: {
|
||||
apiVersion: "apps/v1"
|
||||
kind: "Deployment"
|
||||
spec: {
|
||||
selector: matchLabels: {
|
||||
"app.oam.dev/component": context.name
|
||||
}
|
||||
|
||||
template: {
|
||||
metadata: labels: {
|
||||
"app.oam.dev/component": context.name
|
||||
}
|
||||
|
||||
spec: {
|
||||
containers: [{
|
||||
name: context.name
|
||||
image: parameter.image
|
||||
|
||||
if parameter["cmd"] != _|_ {
|
||||
command: parameter.cmd
|
||||
}
|
||||
|
||||
if parameter["dbSecret"] != _|_ {
|
||||
env: [
|
||||
{
|
||||
name: "username"
|
||||
value: dbConn.username
|
||||
},
|
||||
{
|
||||
name: "endpoint"
|
||||
value: dbConn.endpoint
|
||||
},
|
||||
{
|
||||
name: "DB_PASSWORD"
|
||||
value: dbConn.password
|
||||
},
|
||||
]
|
||||
}
|
||||
|
||||
ports: [{
|
||||
containerPort: parameter.port
|
||||
}]
|
||||
|
||||
if parameter["cpu"] != _|_ {
|
||||
resources: {
|
||||
limits:
|
||||
cpu: parameter.cpu
|
||||
requests:
|
||||
cpu: parameter.cpu
|
||||
}
|
||||
}
|
||||
}]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
parameter: {
|
||||
// +usage=Which image would you like to use for your service
|
||||
// +short=i
|
||||
image: string
|
||||
|
||||
// +usage=Commands to run in the container
|
||||
cmd?: [...string]
|
||||
|
||||
// +usage=Which port do you want customer traffic sent to
|
||||
// +short=p
|
||||
port: *80 | int
|
||||
|
||||
// +usage=Referred db secret
|
||||
// +insertSecretTo=dbConn
|
||||
dbSecret?: string
|
||||
|
||||
// +usage=Number of CPU units for the service, like `0.5` (0.5 CPU core), `1` (1 CPU core)
|
||||
cpu?: string
|
||||
}
|
||||
|
||||
dbConn: {
|
||||
username: string
|
||||
endpoint: string
|
||||
password: string
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
The key point is the annotation `//+insertSecretTo=dbConn`, KubeVela will know the parameter is a K8s secret, it will parse
|
||||
the secret and bind the data into the CUE struct `dbConn`.
|
||||
|
||||
Then the `output` can reference the `dbConn` struct for the data value. The name `dbConn` can be any name.
|
||||
It's just an example in this case. The `+insertSecretTo` is keyword, it defines the data binding mechanism.
|
||||
|
||||
### Prepare TraitDefinition `service-binding` to do env-secret mapping
|
||||
|
||||
As for data binding in Application, KubeVela recommends defining a trait to finish the job. We have prepared a common
|
||||
trait for convenience. This trait works well for binding resources' info into pod spec Env.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: TraitDefinition
|
||||
metadata:
|
||||
annotations:
|
||||
definition.oam.dev/description: "binding cloud resource secrets to pod env"
|
||||
name: service-binding
|
||||
spec:
|
||||
appliesToWorkloads:
|
||||
- webservice
|
||||
- worker
|
||||
schematic:
|
||||
cue:
|
||||
template: |
|
||||
patch: {
|
||||
spec: template: spec: {
|
||||
// +patchKey=name
|
||||
containers: [{
|
||||
name: context.name
|
||||
// +patchKey=name
|
||||
env: [
|
||||
for envName, v in parameter.envMappings {
|
||||
name: envName
|
||||
valueFrom: {
|
||||
secretKeyRef: {
|
||||
name: v.secret
|
||||
if v["key"] != _|_ {
|
||||
key: v.key
|
||||
}
|
||||
if v["key"] == _|_ {
|
||||
key: envName
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
]
|
||||
}]
|
||||
}
|
||||
}
|
||||
|
||||
parameter: {
|
||||
// +usage=The mapping of environment variables to secret
|
||||
envMappings: [string]: [string]: string
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
With the help of this `service-binding` trait, developers can explicitly set parameter `envMappings` to mapping all
|
||||
environment names with secret key. Here is an example.
|
||||
|
||||
```yaml
|
||||
...
|
||||
traits:
|
||||
- type: service-binding
|
||||
properties:
|
||||
envMappings:
|
||||
# environments refer to db-conn secret
|
||||
DB_PASSWORD:
|
||||
secret: db-conn
|
||||
key: password # 1) If the env name is different from secret key, secret key has to be set.
|
||||
endpoint:
|
||||
secret: db-conn # 2) If the env name is the same as the secret key, secret key can be omitted.
|
||||
username:
|
||||
secret: db-conn
|
||||
# environments refer to oss-conn secret
|
||||
BUCKET_NAME:
|
||||
secret: oss-conn
|
||||
key: Bucket
|
||||
...
|
||||
```
|
||||
|
||||
You can see [the end user usage workflow](../end-user/cloud-resources) to know how it used.
|
||||
In the future, we are considering making this part as a standard feature of KubeVela so you could claim whether a given cloud service component should be shared or not.
|
||||
|
||||
155
docs/en/platform-engineers/crossplane.md
Normal file
155
docs/en/platform-engineers/crossplane.md
Normal file
@@ -0,0 +1,155 @@
|
||||
---
|
||||
title: Crossplane
|
||||
---
|
||||
|
||||
In this documentation, we will use Alibaba Cloud's RDS (Relational Database Service), and Alibaba Cloud's OSS (Object Storage System) as examples to show how to enable cloud services as part of the application deployment.
|
||||
|
||||
These cloud services are provided by Crossplane.
|
||||
|
||||
## Prepare Crossplane
|
||||
|
||||
<details>
|
||||
Please Refer to [Installation](https://github.com/crossplane/provider-alibaba/releases/tag/v0.5.0)
|
||||
to install Crossplane Alibaba provider v0.5.0.
|
||||
|
||||
> If you'd like to configure any other Crossplane providers, please refer to [Crossplane Select a Getting Started Configuration](https://crossplane.io/docs/v1.1/getting-started/install-configure.html#select-a-getting-started-configuration).
|
||||
|
||||
```
|
||||
$ kubectl crossplane install provider crossplane/provider-alibaba:v0.5.0
|
||||
|
||||
# Note the xxx and yyy here is your own AccessKey and SecretKey to the cloud resources.
|
||||
$ kubectl create secret generic alibaba-account-creds -n crossplane-system --from-literal=accessKeyId=xxx --from-literal=accessKeySecret=yyy
|
||||
|
||||
$ kubectl apply -f provider.yaml
|
||||
```
|
||||
|
||||
`provider.yaml` is as below.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Namespace
|
||||
metadata:
|
||||
name: crossplane-system
|
||||
|
||||
---
|
||||
apiVersion: alibaba.crossplane.io/v1alpha1
|
||||
kind: ProviderConfig
|
||||
metadata:
|
||||
name: default
|
||||
spec:
|
||||
credentials:
|
||||
source: Secret
|
||||
secretRef:
|
||||
namespace: crossplane-system
|
||||
name: alibaba-account-creds
|
||||
key: credentials
|
||||
region: cn-beijing
|
||||
```
|
||||
</details>
|
||||
|
||||
## Register `alibaba-rds` Component
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: ComponentDefinition
|
||||
metadata:
|
||||
name: alibaba-rds
|
||||
namespace: vela-system
|
||||
annotations:
|
||||
definition.oam.dev/description: "Alibaba Cloud RDS Resource"
|
||||
spec:
|
||||
workload:
|
||||
definition:
|
||||
apiVersion: database.alibaba.crossplane.io/v1alpha1
|
||||
kind: RDSInstance
|
||||
schematic:
|
||||
cue:
|
||||
template: |
|
||||
output: {
|
||||
apiVersion: "database.alibaba.crossplane.io/v1alpha1"
|
||||
kind: "RDSInstance"
|
||||
spec: {
|
||||
forProvider: {
|
||||
engine: parameter.engine
|
||||
engineVersion: parameter.engineVersion
|
||||
dbInstanceClass: parameter.instanceClass
|
||||
dbInstanceStorageInGB: 20
|
||||
securityIPList: "0.0.0.0/0"
|
||||
masterUsername: parameter.username
|
||||
}
|
||||
writeConnectionSecretToRef: {
|
||||
namespace: context.namespace
|
||||
name: parameter.secretName
|
||||
}
|
||||
providerConfigRef: {
|
||||
name: "default"
|
||||
}
|
||||
deletionPolicy: "Delete"
|
||||
}
|
||||
}
|
||||
parameter: {
|
||||
// +usage=RDS engine
|
||||
engine: *"mysql" | string
|
||||
// +usage=The version of RDS engine
|
||||
engineVersion: *"8.0" | string
|
||||
// +usage=The instance class for the RDS
|
||||
instanceClass: *"rds.mysql.c1.large" | string
|
||||
// +usage=RDS username
|
||||
username: string
|
||||
// +usage=Secret name which RDS connection will write to
|
||||
secretName: string
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
|
||||
## Register `alibaba-oss` Component
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: ComponentDefinition
|
||||
metadata:
|
||||
name: alibaba-oss
|
||||
namespace: vela-system
|
||||
annotations:
|
||||
definition.oam.dev/description: "Alibaba Cloud RDS Resource"
|
||||
spec:
|
||||
workload:
|
||||
definition:
|
||||
apiVersion: oss.alibaba.crossplane.io/v1alpha1
|
||||
kind: Bucket
|
||||
schematic:
|
||||
cue:
|
||||
template: |
|
||||
output: {
|
||||
apiVersion: "oss.alibaba.crossplane.io/v1alpha1"
|
||||
kind: "Bucket"
|
||||
spec: {
|
||||
name: parameter.name
|
||||
acl: parameter.acl
|
||||
storageClass: parameter.storageClass
|
||||
dataRedundancyType: parameter.dataRedundancyType
|
||||
writeConnectionSecretToRef: {
|
||||
namespace: context.namespace
|
||||
name: parameter.secretName
|
||||
}
|
||||
providerConfigRef: {
|
||||
name: "default"
|
||||
}
|
||||
deletionPolicy: "Delete"
|
||||
}
|
||||
}
|
||||
parameter: {
|
||||
// +usage=OSS bucket name
|
||||
name: string
|
||||
// +usage=The access control list of the OSS bucket
|
||||
acl: *"private" | string
|
||||
// +usage=The storage type of OSS bucket
|
||||
storageClass: *"Standard" | string
|
||||
// +usage=The data Redundancy type of OSS bucket
|
||||
dataRedundancyType: *"LRS" | string
|
||||
// +usage=Secret name which RDS connection will write to
|
||||
secretName: string
|
||||
}
|
||||
|
||||
```
|
||||
@@ -22,7 +22,7 @@ The reasons for KubeVela supports CUE as a first-class solution to design abstra
|
||||
|
||||
Please make sure below CLIs are present in your environment:
|
||||
* [`cue` >=v0.2.2](https://cuelang.org/docs/install/)
|
||||
* [`vela` (>v1.0.0)](../install#4-optional-get-kubevela-cli)
|
||||
* [`vela` (>v1.0.0)](../../install#3-get-kubevela-cli)
|
||||
|
||||
## CUE CLI Basic
|
||||
|
||||
@@ -4,7 +4,7 @@ title: How-to
|
||||
|
||||
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](../platform-engineers/definition-and-templates) in KubeVela.
|
||||
> Before reading this part, please make sure you've learned the [Definition CRD](../definition-and-templates.md) in KubeVela.
|
||||
|
||||
## Declare `ComponentDefinition`
|
||||
|
||||
@@ -221,7 +221,7 @@ output: {
|
||||
|
||||
It's common that a component definition is composed by multiple API resources, for example, a `webserver` component that is composed by a Deployment and a Service. CUE is a great solution to achieve this in simplified primitives.
|
||||
|
||||
> Another approach to do composition in KubeVela of course is [using Helm](/docs/helm/component).
|
||||
> Another approach to do composition in KubeVela of course is [using Helm](../helm/component.md).
|
||||
|
||||
## How-to
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
---
|
||||
title: Define resources located in defferent namespace with application
|
||||
title: Render Resource to Other Namespaces
|
||||
---
|
||||
|
||||
In this section, we will introduce how to use cue template create resources (workload/trait) in different namespace with the application.
|
||||
In this section, we will introduce how to use cue template create resources in different namespace with the application.
|
||||
|
||||
By default, the `metadata.namespace` of K8s resource in CuE template is automatically filled with the same namespace of the application.
|
||||
By default, the `metadata.namespace` of K8s resource in CUE template is automatically filled with the same namespace of the application.
|
||||
|
||||
If you want to create K8s resources running in a specific namespace witch is different with the application, you can set the `metadata.namespace` field.
|
||||
KubeVela will create the resources in the specified namespace, and create a resourceTracker object as owener of those resources.
|
||||
@@ -26,7 +26,7 @@ spec:
|
||||
parameter: {
|
||||
name: string
|
||||
image: string
|
||||
namespace: string # make this parameter `namespace` as keyword which represents the resource maybe located in defferent namespace with application
|
||||
namespace: string # make this parameter `namespace` as keyword which represents the resource maybe located in different namespace with application
|
||||
}
|
||||
output: {
|
||||
apiVersion: "apps/v1"
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user