This is excellent. I may copy the rough format for tracking things internally at my company!
Btw, I agree with most of your decisions in here with just a few exceptions.
kustomize > helm
Argo > flux
My last thought is less clear though. There are good observability solutions besides datadog. Grafana Cloud is great. Honeycomb has a similar offering. But all are pretty expensive though.
If you aren’t using OpenTelemetry, you’re probably doing observability wrong!
First is complexity. A simple helm chart works great but more elaborate charts can turn into a maintenance problem. This is especially when managing a large number of apps and need to establish and maintain standards across them. E.g. you want to add a new label to every helm chart you use. You now get to making 60 PRs for 60 charts. Or you can tie them all together with chart dependencies. This can be done well but almost never is. It’s just too easy to build a bad helm chart. Kustomize allows you to do this from a “top-down” perspective
Second is modifications. Consider as an example that you want to run filebeat as a sidecar container on some pod to capture its logs. But the helm chart you’re using doesn’t include this feature. You have two choices: modify the pod when it’s created with a mutatingwebhook or similar (super complicated solution) or you can copy/fork the chart, add the functionality, and maintain it going forward. Kustomize just doesn’t have this problem. You can just modify a base manifest with overlays.
Last is the nature of Go templates which helm charts are based on. Everything outside of {{ }} is just plaintext. This leads to a ton of limitations. Got a whitespace issue? You’ll probably find out at runtime. Want your IDE to identify syntax issues, provide, intellisense, etc. on the final manifest? Good luck! You need to render that chart first. With Kustomize, every manifest is structured text (yaml). So you get the benefits of all standard tooling for yaml data in your IDEs and CI/CD pipelines.
Honestly, I could keep going (helm releases ugghhhh!). But helm definitely wins on one point and it’s a big one; Helm is the standard for distributing k8s manifests. So every meaningful project supplies helm charts. Kustomize doesn’t even come close on this one. That said, I think Kustomize manifests are just simpler to build. So having an official base manifest for every project just doesn’t matter too much.
Best I have used is Flux with helmrelease objects and kustomize. Only lacking some UI to get flux events and logs together.
I guess that Argocd can do the same with application onjects using charts as source but haven’t tested it yet
But managing both k8s external components (external-dns, external-secrests, CSI, etc etc) and your own apps with kustomizable charts makes so much more sense than having thousand of manifests that I would recommend everyone to try.
This is excellent. I may copy the rough format for tracking things internally at my company!
Btw, I agree with most of your decisions in here with just a few exceptions.
My last thought is less clear though. There are good observability solutions besides datadog. Grafana Cloud is great. Honeycomb has a similar offering. But all are pretty expensive though.
If you aren’t using OpenTelemetry, you’re probably doing observability wrong!
I’ve only used helm and hadn’t considered kustomize as an equivalent, what about kustomize makes it bette in your opinion?
First is complexity. A simple helm chart works great but more elaborate charts can turn into a maintenance problem. This is especially when managing a large number of apps and need to establish and maintain standards across them. E.g. you want to add a new label to every helm chart you use. You now get to making 60 PRs for 60 charts. Or you can tie them all together with chart dependencies. This can be done well but almost never is. It’s just too easy to build a bad helm chart. Kustomize allows you to do this from a “top-down” perspective
Second is modifications. Consider as an example that you want to run filebeat as a sidecar container on some pod to capture its logs. But the helm chart you’re using doesn’t include this feature. You have two choices: modify the pod when it’s created with a mutatingwebhook or similar (super complicated solution) or you can copy/fork the chart, add the functionality, and maintain it going forward. Kustomize just doesn’t have this problem. You can just modify a base manifest with overlays.
Last is the nature of Go templates which helm charts are based on. Everything outside of
{{ }}is just plaintext. This leads to a ton of limitations. Got a whitespace issue? You’ll probably find out at runtime. Want your IDE to identify syntax issues, provide, intellisense, etc. on the final manifest? Good luck! You need to render that chart first. With Kustomize, every manifest is structured text (yaml). So you get the benefits of all standard tooling for yaml data in your IDEs and CI/CD pipelines.Honestly, I could keep going (helm releases ugghhhh!). But helm definitely wins on one point and it’s a big one; Helm is the standard for distributing k8s manifests. So every meaningful project supplies helm charts. Kustomize doesn’t even come close on this one. That said, I think Kustomize manifests are just simpler to build. So having an official base manifest for every project just doesn’t matter too much.
Best I have used is Flux with helmrelease objects and kustomize. Only lacking some UI to get flux events and logs together. I guess that Argocd can do the same with application onjects using charts as source but haven’t tested it yet
But managing both k8s external components (external-dns, external-secrests, CSI, etc etc) and your own apps with kustomizable charts makes so much more sense than having thousand of manifests that I would recommend everyone to try.