4 ms·

Gosh, I wish the author wouldn't sound so arrogant presenting me his reinvented wheel. What your Ansible is doing (looping over the inventory, imperatively exe

Gosh, I wish the author wouldn't sound so arrogant presenting me his reinvented wheel. What your Ansible is doing (looping over the inventory, imperatively executing tasks) is reinventing what a Kubernetes-internal Operator is doing after you asked it to reconcile your changes. Thing is: You're not only reinventing the internal thing, you will eventually recreate internal logic, e.g. some internal dependencies and knowledge "what to do in which order". Good luck with further developments on the Kubernetes upstream. Not cool. Kubernetes does what it can, to give the user a declarative DX. You might not want to fight this. kustomize and some _trivial_ scripting is usually all you'll need. If you need more, consider writing custom Operators.

MuffinFlavored 4y ago
> kustomize and some _trivial_ scripting is usually all you'll need. So not just k8s alone, k8s + kustomize, no Helm charts, right? or can you do k8s + Helm, no kustomize? or can you do kustomize to deploy Helm charts which abstracts away and translates to underlying k8s API calls/generated YAML?
- nijave 4y ago
  Yes
- nforgerit 4y ago
  Hm take it with a grain of salt, but I'm not really a fan of Helm. It might make sense in some bigger corps where you have something like "Platform" teams with dozens of consuming teams to consolidate and version some kind of service. But I lack trust and frequently same-mindedness with Helm chart authors on how to deploy and configure certain things such that I'll use my own thingy anyway. I forgot to mention the CD tools we have, e.g. Flux or ArgoCD. Use customize to render a "final" yaml for your env/version/whatever and throw it at Flux/Argo (e.g. using GitOps) and be happy. That's imho the Kubernetes way of life.
  - schaum 4y ago
    couldn't agree more, but we are "stuck" in managed ansible + k8s although i think kustomize wouldn't make a nicer picture than ansible, but push vs pull .. i prefer pull
- kryptn 4y ago
  My preference is to use kustomize with argocd applicationsets. If helm is how some application is distributed we just render the template with our values file and store that in git, even though argocd can also use helm charts. We'd just prefer to see the diff in git instead of argocd so the deployment is still automated.

MuffinFlavored 4y ago

> kustomize and some _trivial_ scripting is usually all you'll need. So not just k8s alone, k8s + kustomize, no Helm charts, right? or can you do k8s + Helm, no kustomize? or can you do kustomize to deploy Helm charts which abstracts away and translates to underlying k8s API calls/generated YAML?

nijave 4y ago
Yes
nforgerit 4y ago
Hm take it with a grain of salt, but I'm not really a fan of Helm. It might make sense in some bigger corps where you have something like "Platform" teams with dozens of consuming teams to consolidate and version some kind of service. But I lack trust and frequently same-mindedness with Helm chart authors on how to deploy and configure certain things such that I'll use my own thingy anyway. I forgot to mention the CD tools we have, e.g. Flux or ArgoCD. Use customize to render a "final" yaml for your env/version/whatever and throw it at Flux/Argo (e.g. using GitOps) and be happy. That's imho the Kubernetes way of life.
- schaum 4y ago
  couldn't agree more, but we are "stuck" in managed ansible + k8s although i think kustomize wouldn't make a nicer picture than ansible, but push vs pull .. i prefer pull
kryptn 4y ago
My preference is to use kustomize with argocd applicationsets. If helm is how some application is distributed we just render the template with our values file and store that in git, even though argocd can also use helm charts. We'd just prefer to see the diff in git instead of argocd so the deployment is still automated.