Skip to content

v1.7.0
Compare
Choose a tag to compare
@wonderflow wonderflow released this 13 Jan 09:17
· 47 commits to release-1.7 since this release
v1.7.0
8ef2513
This commit was created on GitHub.com and signed with GitHubโ€™s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.

We're excited to announce the KubeVela v1.7 has released now !! Happy New Year!! ๐ŸŽ‰ ๐ŸŽ‰

In this release, we are mainly focus on issues about user adoptions, such as adopting exist workload as vela applications, performance tunning, VelaUX enhancements and so on.

Thanks to all our contributors! We can't release so many powerful features without your great work! โค๏ธโค๏ธ

Highlight Features

Workloads Adoption

This feature adopt resources as a KubeVela application. This command is useful when you already have resources applied in your Kubernetes cluster. These resources could be applied natively or with other tools, such as Helm. This command will automatically find out the resources to be adopted and assemble them into a new application which won't trigger any damage such as restart on the adoption.

There are two types of adoption supported by far, native Kubernetes resources (by default) and helm releases.

  1. For native type, you can specify a list of resources you want to adopt in the application. Only resources in local cluster are supported for now.
  2. For helm type, you can specify a helm release name. This helm release should be already published in the local cluster. The command will find the resources managed by the helm release and convert them into an adoption application.

There are two working mechanism (called modes here) for the adoption by far, read-only mode (by default) and take-over mode.

  1. In read-only mode, adopted resources will not be touched. You can leverage vela tools (like Vela CLI or VelaUX) to observe those resources and attach traits to add new capabilities. The adopted resources will not be recycled or updated. This mode is recommended if you still want to keep using other tools to manage resources updates or deletion, like Helm.
  2. In take-over mode, adopted resources are completely managed by application which means they can be modified. You can use traits or directly modify the component to make edits to those resources. This mode can be helpful if you want to migrate existing resources into KubeVela system and let KubeVela to handle the life-cycle of target resources.

Detail docs: https://kubevela.net/docs/next/end-user/policies/resource-adoption

Thanks to @Somefive for contributing this powerful features in:

  • Feat: takeover & readonly policy #5102
  • Feat: vela adopt command #5197
  • Feat: gc orphan resources #4847

Performance Tunning

In this release, we optimized the default Helm chart values for 5-10x better performance and capacity increase:

Tunning values that can cause break changes
  • applicationRevisionLimit changes from 10 to 2, by default it will reserve only 2 app revisions instead of 10, which mean you don't have many revisions as options for rolling back. If you want to keep the value, you can specify by: 
    helm upgrade --set applicationRevisionLimit=10
  • optimize.disableComponentRevision by default, we'll turn off component revision, it will affect users who use the older rollout addon, users who're using kruise-rollout won't be affected. If you still want to use it, please specify the paramter when installing/upgrading. 
    helm upgrade --set optimize.disableComponentRevision=false
Other tunning values
  • definitionRevisionLimit changes from 20 to 2, by default it will reserve only 2 revisions for each definitions instead of 10.
  • featureGates.zstdResourceTracker by default, the controller will use zstd for resourceTracker compression.
  • featureGates.zstdApplicationRevision by default, the controller will use zstd for applicationRevision compression.
  • kubeClient.qps and kubeClient.burst changes to 100 and 200, double sized from older ones.
  • enableFluxcdAddon deprecated as it's already widely used as being installed as addon.

Thanks to @charlie0129 and @wonderflow for contributing this feature:

  • Feat: add support for compressing apprev using gzip and zstd by @charlie0129 in #5090
  • Feat: optimize controller default value for better performance by @wonderflow in #5194

Dry Run Enhancement

Dry run with policy and workflow files

With this feature, you can you can specify different policy and workflow with application files, for example:

Run application for test environment:

vela dry-run  -f app.yaml -f test-policy.yaml -f test-workflow.yaml

Run application for production environment:

vela dry-run  -f app.yaml -f prod-policy.yaml -f prod-workflow.yaml

Additionally, if the provided policy and workflow files are not referenced by application file, warning message will show up
and those files will be ignored. You can use "merge" flag to make those standalone files effective:

vela dry-run  -f app-with-no-reference-policy-and-workflow.yaml -f prod-policy.yaml -f prod-workflow.yaml --merge

Detail design can be check here: #5184

Thanks to @cezhang for contributing this powerful feature: #4815.

Dry run check before any resource dispatch

Previously, when application contains objects that should not be dispatched (like invalid resource, target cluster disconnected, authorization failed), the dispatch of the resources are recorded in ResourceTracker, which will trigger these resources to be recycled and state-kept afterwards. However, since these dispatch are not successful, we will encounter errors during gc or state-keep.

This feature add pre-dispatch DryRun check for the to-dispatch resources before recording them into ResourceTrackers. Therefore, invalid resources will not be recorded if they are detected during the dryrun process. It will greatly reduce the possibility of recording not-dispatched resources into ResourceTrackers.

Thanks to @Somefive for contributing this feature in #5277

Interactive Resource Delete

The interactive resource delete allow you to delete part of your aplication resources in the vela delete command.

Now we support delete application in various modes. Natively, you can use it like "kubectl delete app [app-name]".

  • In the cases you only want to delete the application but leave the resources there, you can use the --orphan parameter.
  • In the cases the server-side controller is uninstalled, or you want to manually skip some errors in the deletion process (like lack privileges or handle cluster disconnection), you can use the --force parameter.
  • In the case you want to delete resources partially, you can use -i parameter to delete in interactive mode.

Thanks to @Somefive for contributing this feature in #5266

Allow Specified Privileged Users

This feature allows us to configure some accounts as privileged users without creating accounts in managed clusters, this can help protect privileges leaking. We're using the PrivilegedIdentityExchanger Mechanism from cluster-gateway.

Thanks to @Somefive for contributing this feature in #5284

Component orchestration with multi-clusters

Previously, we can't use deploy workflow step to handle component level parameter input and output, which means we can't support component level parameter input/output in multi-cluster scenarios. This feature allow us this feature, to define component input/output with multi-cluster policies.

Docs: https://kubevela.net/docs/next/end-user/workflow/component-dependency-parameter#multi-cluster-orchestration

Thanks to @chivalryq for contributing this feature in #5161

Dynamic Notification for Addon Installation

The NOTES.cue file allows you to display dynamic notifications once the addon has been enabled, based on specified parameters.

For example, you can write the NOTES.cue as shown below:

info: string
if !parameter.pluginOnly {
	info: """
		By default, the backstage app is strictly serving in the domain `127.0.0.1:7007`, check it by:
		            
		    vela port-forward addon-backstage -n vela-system
		
		You can build your own backstage app if you want to use it in other domains. 
		"""
}
if parameter.pluginOnly {
	info: "You can use the endpoint of 'backstage-plugin-vela' in your own backstage app by configuring the 'vela.host', refer to example https://github.com/wonderflow/vela-backstage-demo."
}
notes: (info)

and parameter.cue as shown below:

paramters: {
	pluginOnly: *false | string 
}

Once the addon is enabled using the CLI, you will see different results according to the parameters from end users.

This example is from the backstage addon, you can find more information by visiting this link.

Thanks to @wonderflow in #5195

Workflow Enhancement

Feature Enhancement

  • Support workflow to restart from a specified failed step like: 
     vela workflow restart <app-name> --step=<step-name>
  • Support automatic generation of name for workflow step if it is empty.
  • Previously, if the key in inputs.parameterKey is also specified in parameter, it will cause conflict. In the new version, the inputs will replace the value in parameter and there will be no confict like: 
       workflow:
     steps:
     - inputs:
       - from: context.name
         parameterKey: slack.message.text
       name: slack-message
       properties:
         slack:
           message:
             text: myText
           url:
             value: placeholder
       type: notification
  • Support patch in op.#Apply, you can use it to patch resources in workflow step.

Thanks to @FogDong in serious of PRs like #5233.

New built-in Workflow Steps, Components and Traits

  • Support built-push-image step. You can use it to build image from your git repository, push it to your image registry, and use the new image in your component. During the building, you can also use vela workflow logs <name> --step <step-name> to check the step logs.
  • Support vela-cli step. You can use it to run vela commands in the job.
  • Support apply-terraform-provider and apply-terraform-config steps, you can use them to initialize your environment like creating a cloud cluster and use vela-cli to join the new cluster as a hub cluster. Please refer to Automatically initialize the environment with terraform
     for more.
  • Support requests step. You can use it to send HTTP requests with different methods like GET, PUT, POST, DELETE. Note that this step will fail if the response status code is bigger than 400. The response body will be wrapped in response, you can use it in the inputs/outputs.
  • Suport clean-jobs step. You can use it to clean jobs and their pods with label selectors.

Thanks to @FogDong in serious of PRs like #5199.

  • Feat: add topologySpreadConstraints traits by @jguionnet in #5081
  • Feat: Add startup probe trait by @jguionnet in #5093
  • Feat: support hostpath in storage trait and vela-cli workflow step by @FogDong in #5265
  • Feat: add trait to support HorizontalPodAutoscaler of CPU/MEM/CustomMetrics by @StevenLeiZhang in #5225
  • Feat: the webservice component support args parameter #5226 by @xingming01 in #5227

VelaUX and APIServer

Application Workflow

Now, VelaUX could provide a better experience for users editing the application workflow. You could edit the workflow via the visual studio or YAML editor.

Some new workflow features are available. Includes:

  1. Step group.
  2. Step inputs and outputs.
  3. Step timeout.
  4. Step condition.
  5. Step dependence.
  6. Custome workflow mode.

In addition to editing, the shown of the application workflow running status is better. You could view the historical workflow records and query every step's details, including the outputs, inputs, and logs.

Application Rollback

VelaUX saved every published version. You could check the difference between the history version with the deployed config. Then base the version to rollback the application if it is necessary.

Multiple tenants

Now, VelaUX support enables strict permission mode. It means every project only could deploy the application to the target belonging to this project. VelaUX will generate the RBAC role and role binding in the target namespace. Every request to the Kubernetes API will impersonate the login User to check the permission.

Check the release note there: https://github.com/kubevela/velaux/releases/tag/v1.7.0

User Experience Improvements

  • Feat: vela top supports custom theme features for your terminal by @Hanmengnan in #5180
  • Feat: support fallback to kubeconfig namespace when env not set by @wonderflow in #5182
  • Feat: Detect the correctness of the custom addon repository when adding a new registry by @suwliang3 in #5221
  • Feat: return notFound error when deleting app by @suwliang3 in #5189
  • Feat: add prestart-hook for vela-core and implement the apprev crd guard check by @Somefive in #5232
  • Fix: remove cluster field from pod view in vela top and optimize some ui by @Hanmengnan in #5237

Enhancement && Bugfixes

  • Feat: supports SSH for retrieving terraform modules in private git repo by @motilayo in #5059
  • Feat: versioned the context backend values to the app revision by @barnettZQG in #5231
  • Fix: dry run from revision application patch error by @LiuFang07 in #5246
  • Fix: apply label to pod for vela-cli workflow step definition. Fixes #5247 by @jamesdobson in #5248
  • Feat: enhance the workflow restful APIs by @barnettZQG in #5252
  • Feat: support outputs objects for custom policy by @wonderflow in #5183
  • Fix: fix inputs conflict for workflow by @FogDong in #5251
  • Fix: make the impersonation feature work by @barnettZQG in #5261
  • Fix: make the synced workflow name normative by @barnettZQG in #5278
  • Fix: keep the workflow data structure in MongoDB by @barnettZQG in #5276
  • Fix: the addon management APIs support the user impersonation by @barnettZQG in #5282
  • Fix: delete appplication fails if status.workflow.endTime not specified. by @LiuFang07 in #5287
  • Fix: don't return err if subresource type is not found when listing application resources. by @hnd4r7 in #5295
  • Fix: provide more explicit error when addon package hasn't a metadata.yaml by @wangyikewxgm in #5298
  • Fix: Index structure map[string]string,Mongo resulting in inconsistent results obtained by filtering non-string type by index. by @LiuFang07 in #5274
  • Fix: enhance the application synchronizer with publishVersion by @barnettZQG in #5299
  • Fix: create a config with the same name reported an incorrect error by @nuclearwu in #5270

How to install

Install Vela Core by Using Vela CLI

curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.7.0
vela install -v 1.7.0

Install Vela Core by Using Helm:

helm repo add kubevela https://charts.kubevela.net/core
helm repo update
helm install --create-namespace -n vela-system kubevela kubevela/vela-core --version 1.7.0 --wait

Install VelaUX addon

vela addon enable velaux --version=v1.7.0

How to upgrade from old version?

Refer to the docs( https://kubevela.net/docs/platform-engineers/system-operation/migration-from-old-version ) if you're migrating from older versions.

Upgrade by using Vela CLI

The install command will also handle the upgrade automatically๏ผš

curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.7.0
vela install -v 1.7.0 -r

Upgrade by using Helm

โš ๏ธ Please upgrade the CRD first if you're upgrading to this release.

  1. Upgrade the CRDs, please make sure you upgrade the CRDs first before upgrade the helm chart.
kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/release-1.7/charts/vela-core/crds/core.oam.dev_applicationrevisions.yaml
kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/release-1.7/charts/vela-core/crds/core.oam.dev_applications.yaml
kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/release-1.7/charts/vela-core/crds/core.oam.dev_resourcetrackers.yaml
kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/release-1.7/charts/vela-core/crds/core.oam.dev_componentdefinitions.yaml
kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/release-1.7/charts/vela-core/crds/core.oam.dev_definitionrevisions.yaml
  1. Upgrade your kubevela chart

Since we have migrated some workflowstep definitions and views from workflow addon to KubeVela core repo, so it may cause the following error if you upgrade:

Error: Could not install KubeVela control plane installation: error when installing/upgrading Helm Chart kubevela in namespace vela-system: rendered manifests contain a resource that already exists. Unable to continue with update: WorkflowStepDefinition "apply-deployment" in namespace "vela-system" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "kubevela"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "vela-system"

You can execute this script to solve it before upgrade helm chart:

curl -fsSl https://kubevela.net/script/checklegacy.sh | bash

The script will just help patch helm annotations for you, you can also do that manually one by one like:

kubectl patch -n vela-system workflowstepdefinition <item> --type=merge -p '{"metadata":{"annotations":{"meta.helm.sh/release-name":"kubevela","meta.helm.sh/release-namespace":"vela-system"},"labels":{"app.kubernetes.io/managed-by":"Helm"}}}'
kubectl patch -n vela-system configMap <item> --type=merge -p '{"metadata":{"annotations":{"meta.helm.sh/release-name":"kubevela","meta.helm.sh/release-namespace":"vela-system"},"labels":{"app.kubernetes.io/managed-by":"Helm"}}}'

Then you can upgrade the helm chart now:

helm repo add kubevela https://charts.kubevela.net/core
helm repo update
helm upgrade -n vela-system --install kubevela kubevela/vela-core --version 1.7.0 --wait
  1. Download the new CLI and enable velaux
curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.7.0
vela addon enable velaux

Upgrade VelaUX

vela addon upgrade velaux --version=v1.7.0

New Contributors

Full Changelog: v1.6.7...v1.7.0

Contributors

wonderflow, cezhang, and 21 other contributors
Assets 23
Loading