skaffold render change for helm template namespace behavior

57 views
Skip to first unread message

Aran D

unread,
Jan 18, 2023, 12:44:59 PM1/18/23
to skaffold-users
`helm template`, and by extension skaffold render's direct use of it, has the behavior that the `namespace` parameter is not applied to resources managed by the helm chart. Can/should skaffold render's behavior be changed to solve this?

Helm's behavior means that `helm install ...` and `helm template ... | kubectl ...` have different behavior unless a user also adds the namespace argument to kubectl. For skaffold users, this affects gitops-style workflows built on `skaffold render`, with the difference being that a single skaffold configuration likely manages resources in more than one namespace. 

There are many issues about this in helm land, such as https://github.com/helm/helm/issues/3553, but the short version is that helm is not changing it. Helm leaves it up to deployment tools to apply a namespace to template output for philosophical and performance reasons. Helm has also established a "best practice" that explicitly discourages chart authors from parameterizing their namespace like other chart parameters. In practice a variety of post-processing helper tools and scripts are floating around for helm users to work around this. 

In Skaffold, it's normal to have something like:
some_root/skaffold.yaml:

[...]
requires:
- path: ./skaffold-module-using-a-helm-chart
- path: ./skaffold-module-using-another-helm-chart

With `skaffold render` on the root file, there's no way to set the two helm charts to different namespaces. 

`skaffold render` could be modified to read *.helm.releases.namespace and insert it into the helm template output's namespace-compatible resource metadata alongside other existing post-processing. Viewed as a bug fix, this change would be backward compatible except in pathological cases, and it might clean up the behavior in https://github.com/GoogleContainerTools/skaffold/issues/7101. (It is a good feature of `skaffold render` that its output can be consumed by standard tools other than `skaffold apply`). Viewed as a skaffold feature that streamlines a common task for helm gitops users, it could also be justifiably hidden behind a configuration variable. 
Reply all
Reply to author
Forward
0 new messages