Tanzu Mission Control allows you to deploy Kustomizations and Helm charts in a GitOps way using an integrated FluxCD controller. If’ve written an introduction article about this topic in a previous post.

When adding Kustomizations (using Kustomize) you have two options when it comes to Kubernetes namespace creation:

• You let Kustomize (or the Kustomize configuraiton to be more precise) handle the namespaces.
• Let Tanzu Mission Control be responsible for namespace management.

Let Kustomize manage the namespaces

In this case you need to define the namespace you want to use and add this namespace to the kustomization.yaml file. Depending on your configuration:

• You create a base configuration without a namespace definition, and add a namespace definition (contained in a namespace.yaml for example) as a resource to your overlays.
• Or you add an intial namespace definition to your Kustomize base configuration (contained in a namespace.yaml for example) and add the resource to the kustomization.yaml. In the overlay(s) you define a patch to change the initial configured namespace definition in the base layer to a namespace-name of choice.

The second option is configured in the following example:

• The base layer folder contains a namespace definition in a namespace.yaml, that’s added as a resource in the kustomization.yaml.
• In the overlay folder(s) a namespace.yaml is defined, that points to the original namespace definition of the base layer. This file is added as a patch, and the kustomization.yaml contains the namespace definition that should be used. There’s an overlay for a development and production configuration.

Adding these configurations to Tanzu Mission Control, results in three deployments: a base, development and production deployment.

Let Tanzu Mission Control manage the namespaces

Another option is that TMC is responsible for the namespaces, that means you can set the namespace to be used in TMC.

The message tells that “if the namespace does not exist in the cluster, syncing the kustomization will fail”.

It looks, this is partially true. If creation of a namespace is not part of your Kustomization, the deployment will fail. After the namespace is created, either by an external process or by TMC, the Kustomization is applied. In this way you could control deployment of the Kustomization by creating the required namespace (or not).

However, I noticed that if your Kustomization contains the creation of a namespace (just like in our base layer example), TMC will “patch” this namespace and automatically create the namespace as defined in the “Target namespace”. To be honest, I didn’t expect this…but it might come in handy I would say.

The configuration as described above results in a deployment in the base-overwrite namespace (without creating the base-overwrite namespace first):

That’s it, I hope this is helpful. Feel free to leave a comment below.