Known Limitations

Here are some known limitations for using Helm chart as application component.

Following best practices of microservice, KubeVela recommends only one workload resource present in one Helm chart. Please split your “super” Helm chart into multiple charts (i.e. components). Essentially, KubeVela relies on the filed in component definition to indicate the workload type it needs to take care, for example:

The name of the workload should be templated with fully qualified application name and please do NOT assign any value to . As a best practice, Helm also highly recommend that new charts should be created via command so the template names are automatically defined as per this best practice.

Changes made to the component will trigger a Helm release upgrade. This process is handled by Flux v2 Helm controller, hence you can define remediation strategies in the schematic based on and specification in case failure happens during this upgrade.

Though one issue is for now it’s hard to get helpful information of a living Helm release to figure out what happened if upgrading failed. We will enhance the observability to help users track the situation of Helm release in application level.

Issues

The known issues will be fixed in following releases.

Changes on traits properties may impact the component instance and Pods belonging to this workload instance will restart. In CUE based components this is avoidable as KubeVela has full control on the rendering process of the resources, though in Helm based components it’s currently deferred to Flux v2 controller.