Namespaces
When using Tanka, namespaces are handled slightly different compared to
kubectl, because environments offer more granular control than contexts used
by kubectl.
Default namespaces
In the spec.json of each environment, you can set the
spec.namespace field, which is the default namespace. The default namespace is
set for every resource that does not have a namespace set from Jsonnet.
| Scenario | Action | |
|---|---|---|
| 1. | Your resource lacks namespace information (metadata.namespace) unset or "" | Tanka sets metadata.namespace to the value of spec.namespace in spec.json |
| 2. | Your resource already has namespace information | Tanka does nothing, accepting the explicit namespace |
While we recommend keeping environments limited to a single namespace, there are legit cases where it's handy to have them span multiple namespaces, for example:
- Some other piece of software (Operators, etc) require resources to be in a specific namespace
- A rarely changing "base" environment holding resources deployed for many clusters in the same way
- etc.
Cluster-wide resources
Some resources in Kubernetes are cluster-wide, meaning they don't belong to a single namespace at all.
Tanka will make an attempt to not add namespaces to known cluster-wide types. It does this with a short list of types in the source code.
Tanka cannot feasibly maintain this list for all known custom resource types. In those cases, resources will have namespaces added to their manifests, and kubectl should happily apply them as non-namespaced resources.
If this presents a problem for your workflow, you can override this behavior
per-resource, by setting the tanka.dev/namespaced annotation to "false"
(must be of string type):
thing: clusterRole.new("myClusterRole")
+ clusterRole.mixin.metadata.withAnnotationsMixin({ "tanka.dev/namespaced": "false" })