Pods and Services

To be part of a mesh, Kubernetes pods and services must satisfy the following requirements:

  • Service association: A pod must belong to at least one Kubernetes service even if the pod does NOT expose any port. If a pod belongs to multiple Kubernetes services, the services cannot use the same port number for different protocols, for instance HTTP and TCP.

  • Application UIDs: Ensure your pods do not run applications as a user with the user ID (UID) value of 1337.

  • NET_ADMIN and NET_RAW capabilities: If your cluster enforces pod security policies, they must allow injected pods to add the NET_ADMIN and NET_RAW capabilities. If you use the Istio CNI Plugin, this requirement no longer applies. To learn more about the NET_ADMIN and NET_RAW capabilities, see Required pod capabilities, below.

  • Deployments with app and version labels: We recommend adding an explicit app label and version label to deployments. Add the labels to the deployment specification of pods deployed using the Kubernetes Deployment. The app and version labels add contextual information to the metrics and telemetry Istio collects.

    • The app label: Each deployment specification should have a distinct app label with a meaningful value. The app label is used to add contextual information in distributed tracing.

    • The version label: This label indicates the version of the application corresponding to the particular deployment.

  • Named service ports: Service ports may optionally be named to explicitly specify a protocol. See Protocol Selection for more details.

Ports used by Istio

The following ports and protocols are used by Istio.

PortProtocolUsed byDescription
15000TCPEnvoyEnvoy admin port (commands/diagnostics)
15001TCPEnvoyEnvoy Outbound
15006TCPEnvoyEnvoy Inbound
15008TCPEnvoyEnvoy Tunnel port (Inbound)
15020HTTPEnvoyIstio agent Prometheus telemetry
15021HTTPEnvoyHealth checks
15090HTTPEnvoyEnvoy Prometheus telemetry
15010GRPCIstiodXDS and CA services (plaintext)
15012GRPCIstiodXDS and CA services (TLS)
8080HTTPIstiodDebug interface
443HTTPSIstiodWebhooks
15014HTTPMixer, IstiodControl plane monitoring
15443TLSIngress and Egress GatewaysSNI
9090HTTPPrometheusPrometheus
42422TCPMixerTelemetry - Prometheus
15004HTTPMixer, PilotPolicy/Telemetry - mTLS
9091HTTPMixerPolicy/Telemetry

Required pod capabilities

If pod security policies are enforced in your cluster and unless you use the Istio CNI Plugin, your pods must have the NET_ADMIN and NET_RAW capabilities allowed. The initialization containers of the Envoy proxies require these capabilities.

To check if the NET_ADMIN and NET_RAW capabilities are allowed for your pods, you need to check if their service account can use a pod security policy that allows the NET_ADMIN and NET_RAW capabilities. If you haven’t specified a service account in your pods’ deployment, the pods run using the default service account in their deployment’s namespace.

To list the capabilities for a service account, replace <your namespace> and <your service account> with your values in the following command:

  1. $ for psp in $(kubectl get psp -o jsonpath="{range .items[*]}{@.metadata.name}{'\n'}{end}"); do if [ $(kubectl auth can-i use psp/$psp --as=system:serviceaccount:<your namespace>:<your service account>) = yes ]; then kubectl get psp/$psp --no-headers -o=custom-columns=NAME:.metadata.name,CAPS:.spec.allowedCapabilities; fi; done

For example, to check for the default service account in the default namespace, run the following command:

  1. $ for psp in $(kubectl get psp -o jsonpath="{range .items[*]}{@.metadata.name}{'\n'}{end}"); do if [ $(kubectl auth can-i use psp/$psp --as=system:serviceaccount:default:default) = yes ]; then kubectl get psp/$psp --no-headers -o=custom-columns=NAME:.metadata.name,CAPS:.spec.allowedCapabilities; fi; done

If you see NET_ADMIN and NET_ADMIN or * in the list of capabilities of one of the allowed policies for your service account, your pods have permission to run the Istio init containers. Otherwise, you will need to provide the permission.

See also

Installing the Sidecar

Install the Istio sidecar in application pods automatically using the sidecar injector webhook or manually using istioctl CLI.

Demystifying Istio’s Sidecar Injection Model

De-mystify how Istio manages to plugin its data-plane components into an existing deployment.

Install Istio with the Istio CNI plugin

Install and use Istio with the Istio CNI plugin, allowing operators to deploy services with lower privilege.

Using MOSN with Istio: an alternative data plane

An alternative sidecar proxy for Istio.

Provision a certificate and key for an application without sidecars

A mechanism to acquire and share an application certificate and key through mounted files.

DNS Certificate Management

Provision and manage DNS certificates in Istio.