The Namespace Onboarding Workflow is a feature in which you select namespaces to be injected with a proxy sidecar.
Under the previously used "exclusion" model, any new namespace that was created would automatically be injected with a sidecar, and it was up to the customer to choose which namespaces they want to exclude. However, this posed a challenge for customers when installing system applications into Kubernetes clusters that they did not want to have a sidecar injected into.
You can select namespaces to be "included" for Istio injection from the UI or through the API when you onboard a cluster or by editing the cluster, or you can set the Cluster admin owned option to delegate labeling to the cluster administrator. In that case, the cluster administrator needs to run the command kubectl label namespace_name istio-injection=enabled --overwrite. The command must include the overwrite flag because each new namespace is labeled as istio-injection=disabled by default.
The following sections discuss these methods in more detail.
Select Namespaces Option
At onboarding, you can select namespaces for inclusion, using the Select Namespaces option. This option allows you to choose the namespaces that you want to include for sidecar injection. After you select a namespace, it will be labeled with the istio-injection=enabled label, and the sidecar injection process will begin.
When onboarding a cluster to Tanzu Service Mesh whether it already had Istio before or it is a clean cluster, you must select which namespaces on the cluster are included for Istio sidecar injection. Old istio-injection labels on the namespaces will not carry over to Tanzu Service Mesh.
Create Namespace Inclusion Rule Option
Alternatively, you can define namespace inclusion rules based on a namespace naming pattern using the Create Namespace Inclusion Rule option. This option allows you to set rules for automatic namespace inclusion based on the naming pattern of the namespace. Any new namespace that matches the naming pattern will be automatically labeled with istio-inclusion=enabled, and sidecar injection will be performed.
Customer-Managed Namespace Labeling
You can also manually label any namespace with istio-injection=enabled in Kubernetes. This will have the same effect as including the namespace. You can perform this manual labeling at any time, even after the namespace has been created.
By default, Tanzu Service Mesh overrides the manual labeling changes that you make to a namespace in Kubernetes according to the namespace inclusions set in the UI or through the Tanzu Service Mesh API. For example, if you set istio-injection=disabled for a namespace in Kubernetes, and then someone creates a namespace inclusion rule in the UI that the namespace matches, Tanzu Service Mesh overrides your manual change and sets istio-injection=enabled for the namespace in Kubernetes.
To take control over namespace labeling for Istion injection and prevent Tanzu Service Mesh from overriding the labeling changes you make in Kubernetes, select the Cluster admin owned option for a cluster when you onboard it or when you edit a cluster. When you select Cluster admin owned , you delegate all responsibility for namespace labeling, including selection for inclusion, to the cluster administrator who operates the cluster. This is useful when the person operating Tanzu Service Mesh and the person on the cluster are two different people. The cluster administrator can then create and label namespaces on the cluster as needed, without having the changes overridden by Tanzu Service Mesh. This means that the Select Namespaces option and namespace inclusion rules will no longer be visible or available for the cluster in the UI, and namespace inclusion rules cannot be set for the cluster through the API.
If the cluster administrator wants to enable Istio injection in the pods of a namespace, they must run the command kubectl label namespace_name istio-injection=enabled --overwrite. The command must include the overwrite flag because each new namespace is labeled as istio-injection=disabled by default.
If you want to be able to set namespace inclusions in the UI or through the API, deselect Cluster admin owned by editing the cluster configuration.
When the Cluster admin owned option is selected for a cluster, Tanzu Service Mesh delegates namespace labeling to the cluster administrator, so labeling for sidecar injection will be performed with kubectl. In this case, Tanzu Service Mesh no longer owns namespace labeling on the cluster and does not have visibility into the actual namespace labeling state.
If the Cluster admin owned option is deselected at a later stage, Tanzu Service Mesh may not have the most up-to-date state of labels on the namespaces. Consider the following example:
A user selects the Cluster admin owned option for a cluster to delegate all responsibility for namespace labeling to the cluster administrator.
The cluster administrator performs labeling on the cluster and sets
istio-injection=enabledfor a namespace on the cluster or removes a label that was previously set.If at a later stage the Tanzu Service Mesh administrator deselects the Cluster admin owned option for the cluster to return control over namespace labeling to Tanzu Service Mesh, the namespace inclusions list in the Edit Cluster dialog box for the cluster may not show the most up-to-date namespace inclusion state for Istio injection.
If the Cluster admin owned option is deselected, it is up to the Tanzu Service Meshadministrator to make sure that the namespaces that need to be injected with sidecars are selected and that no labels have been accidentally removed by Tanzu Service Mesh due to lack of constant visibility of the labeling state.
In a later release, a mechanism will be provided to reconcile the inclusions list when the ownership of namespace labeling is switched back and forth between Tanzu Service Mesh and the cluster administrator.
Automatic Namespace Inclusion Rules
If an automatic namespace inclusion rule is set on a cluster and the Cluster admin owned option is not selected, the rule overrides any manual labeling on the namespaces themselves. This means that if a namespace is automatically included based on the rule, Tanzu Service Mesh controls the sidecar injection labeling, regardless of any manual labeling performed.
Conclusion
Sidecar injection in a namespace can be performed in multiple ways, including selecting namespaces for inclusion, defining namespace inclusion rules based on naming patterns, and manual labeling. For more information about these options, see Namespace Inclusions.
