search

GoogleCloudPlatform / flink-on-k8s-operator

[DEPRECATED] Kubernetes operator for managing the lifecycle of Apache Flink and Beam applications.
Apache License 2.0
658 stars 266 forks source link

Improve to make easier enhancing the Helm chart. #352

Open elanv opened 3 years ago

elanv commented 3 years ago

Currently, helm charts seem to be maintained in a rather complicated way. First, k8s manifest files are generated via kustomize, and they are processed once again via shell script to generate helm chart.

The advantage is that if kustomize manifests are maintained well, the helm chart is automatically generated. On the one hand, the release.sh script should be modified to generate new helm chart reflecting the new features. Therefore the process of improving the helm chart is not intuitive.

Both have their pros and cons. Given that helm charts are widely used for distributing kubernetes applications, it would be nice to also consider separating the helm charts from the kustomize manifests to make helm charts easier to improve.

hongyegong commented 3 years ago

The fact that we right now heavily rely on Kustomize even for helm chart is mostly because we use it for the regular operator install process, there are 3 major reasons we kind of need to keep it this way, unless some big refactoring

  1. All resources and configs currently are wired up by Kustomize and this is not easy to change unless we fundamentally change how we manifest a lot of stuff right now.
  2. At each release, we try to make sure what's in Helm chart(all the CRDs, configs etc.,) is at par with what's in the code base.
  3. As you said the pipeline is fully automated through CI tool and no further manual stitches required in order to achieve 1)

Having said that, it's absolutely possible to separate helm chart out and manage the helm chart without Kustomize tool. As I said it will need some non-trivial changes to our current install/release process. So any detailed proposal will be welcomed.