Closed marcelser closed 5 years ago
Charts support referencing namespaces using the .Release.Namespace
template variable, and Kubecrt supports this by providing --namespace
as a CLI argument or by defining a top-level namespace
key in your charts configuration file (see kubecrt --example-config
).
I don't consider it to be a good practice to manipulate the resulting resource files in Kubecrt in unsurprising ways other than what's already supported in charts.
At Blendle we use Kubecrt in all of our automated deployments through our CI, here's an example of how a deployment script could work:
kubecrt --namespace foo --name bar charts.yml | \
kubectl apply --namespace foo --filename -
Given the existing support for namespaces, and the fact that we're using it for many of our automated deployments, I can't see anything crucially missing here to do what you want to do.
If I'm wrong, feel free to provide an example of what you are trying to achieve, and I can see if that is indeed a case that is lacking support currently.
I'm a bit surprised what the existing support for namespaces really does in kubecrt if you have to set the namespace also when calling kubectl that's what I actually don't get.
Also your example only works if you're controlling kubectl command in your CI pipeline. But in other deployment tools for example aws-cdk which requires json converted yamls for deployments you can not set a namespace it has to be in the yamls (jsons). I think other tools like terraform also don't necessarily support this.
So for deployment on AWS using aws tools having namespace in the yamls is absolutely crucial. I do see your argument that it can be more flexible if you don't have the namespace in the yamls but not all tools support setting the namespace during deployment. So it would be nice to actually have the option to have it set automatically otherwise I have to manually modify the scripts which makes renewing yamls from time to time very hard and limit the usefulness of kubecrt a lot. I now way I can use it directly to have it convert charts and feed them without modification to aws-cdk.
I'm a bit surprised what the existing support for namespaces really does in kubecrt if you have to set the namespace also when calling kubectl that's what I actually don't get.
This support is there because it is a variable that is exposed to chart authors. If a chart references .Release.Namespace
in their template, then whatever value you give in --namespace
is inserted into the template of that chart.
So for deployment on AWS using aws tools having namespace in the yamls is absolutely crucial. I do see your argument that it can be more flexible if you don't have the namespace in the yamls but not all tools support setting the namespace during deployment.
As long as you have control over what gets sent to AWS, you can manipulate the data coming out of Kubecrt in whatever way you see fit.
There actually is a --json
flag that makes Kubecrt output JSON instead of YAML, you could combine this with jq
to insert the namespace in every resource generated by Kubecrt.
The goal of Kubecrt is very narrow-minded: have a simple way to combine one or more charts and convert them to Kubernetes resources given a set of configuration values. Whatever you do after getting back those resources is up to you.
Here's another example from one of our deployment scripts to show you the flexibility this provides you:
kubecrt --json --namespace foo --name bar charts.yml | \
jq 'if .kind == "Deployment" then (.spec.template.spec.containers[0].readinessProbe.httpGet.path = "/login" | .) else . end' | \
kubectl apply --namespace foo --filename -
You could manipulate the above Jq command to insert the required fields with the correct namespace value before sending it to AWS.
Hi,
I think to really make use of kubecrt in a proper way it should set the namespace by creating it first through:
and then reference it in the various other yamls by the metadata/namespace key. For automated deployment this is necessary because the yamls are automatically applied and not manually through kubectl with namespace beeing defined there.