We have some ordering constraints in our YAML configs. For example, we currently need a namespace config to be applied before we deploy our main deployments.
How should we be managing this?
We have some ordering constraints in our YAML configs. For example, we currently need a namespace config to be applied before we deploy our main deployments.
How should we be managing this?
Can you share some examples of the Namespace YAML and what you are trying to do? kubectl apply
command does not have a notion of ordering. Are you trying to create something separately? If so, why?
Sure. We (currently) use Istio template injection, which means we need to configure a label on the default namespace: istio-injection: enabled
. However, Istio can only inject itself into pods that are created after that label is applied. (Istio / Installing the Sidecar)
Thus, we need to configure the namespace to have the label, before our deployments are applied.
AFAIUI the same pattern exists for many helm charts (e.g. Istio again, but others too), where CRDs must be applied to Kubernetes before the main helm chart is installed.
When applying, KOTS uses the default Kustomize ordering, which puts namespaces and CRDS first, with one exception: we first run through and detect all CRDs, then we apply just those CRDs first before applying any other objects in a separate, follow-up apply.
To answer your labeling question, I think you might be able to get away with including a Namespace
object in your yaml stream, and apply
will patch the label in:
apiVersion: v1
kind: Namespace
metadata:
name: default # or repl{{ Namespace }} if you also have existing-cluster installs
labels:
istio-injection: enabled
Thanks, this is helpful.
I’m confused though: you say that KOTS first applies namespaces and CRDs, except that it applies CRDs first. To clarify, do you mean always KOTS applies: CRDS → namespaces → everything else?
I believe it is
Although since CRDs are not namespaced I’d imagine that the order of (1) internally should not matter.