blendle / kubecrt

Convert Helm charts to Kubernetes resources.
ISC License
115 stars 11 forks source link

add namespace to generated kuberenetes output #24

Closed marcelser closed 5 years ago

marcelser commented 5 years ago

Hi,

I think to really make use of kubecrt in a proper way it should set the namespace by creating it first through:

 apiVersion: v1
    kind: Namespace
    metadata:
      name: weave
      annotations:
        cloud.weave.works/version: v1.0.0-259-g2850b85

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.

JeanMertz commented 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.

marcelser commented 5 years ago

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.

JeanMertz commented 5 years ago

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.