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
workload filed in component definition to indicate the workload type it needs to take care, for example:
Note that KubeVela won't fail if multiple workload types are packaged in one chart, the issue is for further operational behaviors such as rollout, revisions, and traffic management, they can only take effect on the indicated workload type.
The name of the workload should be templated with fully qualified application name and please do NOT assign any value to
.Values.fullnameOverride. As a best practice, Helm also highly recommend that new charts should be created via
$ helm create command so the template names are automatically defined as per this best practice.
Changes made to the component
properties 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 Helm Release
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.
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.