Every kustomize deployment has a set of tags assigned to it. These tags are defined in multiple places, which is
. Look for the
tags field, which is available in multiple places per
Tags are useful when only one or more specific kustomize deployments need to be deployed or deleted.
deployment items in deployment projects can have an optional list of tags assigned.
If this list is completely omitted, one single entry is added by default. This single entry equals to the last element
path in the
Consider the following example:
deployments: - path: nginx - path: some/subdir
In this example, two kustomize deployments are defined. The first would get the tag
nginx while the second
would get the tag
In most cases this heuristic is enough to get proper tags with which you can work. It might however lead to strange
or even conflicting tags (e.g.
subdir is really a bad tag), in which case you’d have to explicitly set tags.
Deployment projects and deployments items inherit the tags of their parents. For example, if a deployment project
property defined, all
deployments entries would
inherit all these tags. Also, the sub-deployment projects included via deployment items of type
inherit the tags of the deployment project. These included sub-deployments also
specified by the deployment item itself.
Consider the following example
deployments: - include: sub-deployment1 tags: - tag1 - tag2 - include: sub-deployment2 tags: - tag3 - tag4 - include: subdir/subsub
Any kustomize deployment found in
sub-deployment1 would now inherit
any further includes, these would also inherit these two tags. Inheriting is additive and recursive.
The last sub-deployment project in the example is subject to the same default-tags logic as described
, meaning that it will get the default tag
Deploying with tag inclusion/exclusion
Special care needs to be taken when trying to deploy only a specific part of your deployment which requires some base resources to be deployed as well.
Imagine a large deployment is able to deploy 10 applications, but you only want to deploy one of them. When using tags
to achieve this, there might be some base resources (e.g. Namespaces) which are needed no matter if everything or just
this single application is deployed. In that case, you’d need to set
Deleting with tag inclusion/exclusion
Also, in most cases, even more special care has to be taken for the same types of resources as decribed before.
Imagine a kustomize deployment being responsible for namespaces deployments. If you now want to delete everything except
deployments that have the
persistency tag assigned, the exclusion logic would NOT exclude deletion of the namespace.
This would ultimately lead to everything being deleted, and the exclusion tag having no effect.
In such a case, you’d need to set
true as well.
In most cases, setting
true also requires setting