Resource Labels

Automatically added to all resources automatically created by Istio Gateway controller, to indicate which controller created the resource. Users should not set this label themselves.

Automatically added to all resources automatically created by Istio Gateway controller to indicate which Gateway resulted in the object creation. Users should not set this label themselves.

When set on a resource, indicates the data plane mode to use. Possible values: ambient, none. Note: users wishing to use sidecar mode should see the istio-injection label; there is no value on this label to configure sidecars.

Istio control plane revision associated with the resource; e.g. canary

Istio control plane tag name associated with the resource; e.g. canary

When set on a resource, indicates the resource has an associated waypoint with the given name. The waypoint is assumed to be in the same namespace; for cross-namespace, see istio.io/use-waypoint-namespace.

When set or a Pod or a Service, this binds that specific resource to the waypoint. When set on a Namespace, this applies to all Pod/Service in the namespace.

Note: the waypoint must allow the type, see stio.io/waypoint-for.

When set on a resource, indicates the resource has an associated waypoint in the provided namespace. This must be set in addition to istio.io/use-waypoint, when a cross-namespace reference is desired.

When set on a waypoint (either by its specific Gateway, or for the entire collection on the GatewayClass), indicates the type of traffic this waypoint can handle.

Valid options: service, workload, all, and none.

Configures whether a ServiceEntry without any spec.addresses set should get an IP address automatically allocated for it.

Valid options: true, false

IstioGatewayPortLabel overrides the default 15443 value to use for a multi-network gateway’s port

The name of the canonical service a workload belongs to

The name of a revision within a canonical service that the workload belongs to

Specifies whether or not an Envoy sidecar should be automatically injected into the workload.

This label is applied to a workload internally that identifies the Kubernetes cluster containing the workload. The cluster ID is specified during Istio installation for each cluster via values.global.multiCluster.clusterName. It should be noted that this is only used internally within Istio and is not an actual label on workload pods. If a pod contains this label, it will be overridden by Istio internally with the cluster ID specified during Istio installation. This label provides a way to select workloads by cluster when using DestinationRules. For example, a service owner could create a DestinationRule containing a subset per cluster and then use these subsets to control traffic flow to each cluster independently.

A label used to identify the network for one or more pods. This is used internally by Istio to group pods resident in the same L3 domain/network. Istio assumes that pods in the same network are directly reachable from one another. When pods are in different networks, an Istio Gateway (e.g. east-west gateway) is typically used to establish connectivity (with AUTO_PASSTHROUGH mode). This label can be applied to the following resources to help automate Istio’s multi-network configuration.

• Istio System Namespace: Applying this label to the system namespace establishes a default network for pods managed by the control plane. This is typically configured during control plane installation using an admin-specified value.

• Pod: Applying this label to a pod allows overriding the default network on a per-pod basis. This is typically applied to the pod via webhook injection, but can also be manually specified on the pod by the service owner. The Istio installation in each cluster configures webhook injection using an admin-specified value.

• Gateway Service: Applying this label to the Service for an Istio Gateway, indicates that Istio should use this service as the gateway for the network, when configuring cross-network traffic. Istio will configure pods residing outside of the network to access the Gateway service via spec.externalIPs, status.loadBalancer.ingress[].ip, or in the case of a NodePort service, the Node’s address. The label is configured when installing the gateway (e.g. east-west gateway) and should match either the default network for the control plane (as specified by the Istio System Namespace label) or the network of the targeted pods.

User-provided node label for identifying the locality subzone of a workload. This allows admins to specify a more granular level of locality than what is offered by default with Kubernetes regions and zones.