You can use Kustomize and Helm together
Companies building and scaling microservices might run into the problem of needing to standardize their Kubernetes deployments.
For example, say your company’s primary tech stack is Java and Spring Boot. You’re using Kustomize because it’s easier for developers to reason about. Most configurations for a service to be deployed to your Kubernetes cluster must be copied and pasted between service repositories. Copy and paste works well initially, but it adds a lot of overhead as you need to make similar changes across repositories.
One way to solve this problem is by using Helm with Kustomize. I call this Kustomized Helm.
You build a Helm chart that you publish that will act as a base for your services. You can also use Helm’s templating features to get around where Kustomize falls short. Then, you replace the common Kustomize bits with the Helm chart in your services’ repositories. Anything that isn’t common to all services can still be added with Kustomize.
Now, if you need to make a cross-cutting change to all of the Kubernetes deployments, you can easily do so in the base Helm chart.
Here’s a link to a simple example of using a Helm chart with Kustomize: https://github.com/kubernetes-sigs/kustomize/blob/master/examples/chart.md
There wasn’t any support for OCI Helm repositories until this recent PR was merged.
Why should you care about OCI Helm repositories? Kustomize doesn’t support authentication to private Helm repositories. However, using an OCI-based Helm repository, such as AWS ECR lets you get around that by using AWS’ authentication.