Application Requirements

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

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

    • NET_ADMIN and NET_RAW capabilities: If are enforced in your cluster and unless you use the , 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:

      For example, to check for the default service account in the 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

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

      • 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 for more details.

    The following ports and protocols are used by the Istio sidecar proxy (Envoy).

    To avoid port conflicts with sidecars, applications should not use any of the ports used by Envoy.

    The following ports and protocols are used by the Istio control plane (istiod).

    Both of these features work by inspecting the initial bytes of a connection to determine the protocol, which is incompatible with server first protocols.

    In order to support these cases, follow the Explicit protocol selection steps to declare the protocol of the application as .

    The following ports are known to commonly carry server first protocols, and are automatically assumed to be TCP:

    Because TLS communication is not server first, TLS encrypted server first traffic will work with automatic protocol detection as long as you make sure that all traffic subjected to TLS sniffing is encrypted:

    1. Configure mTLS mode STRICT for the server. This will enforce TLS encryption for all requests.
    2. Configure mTLS mode DISABLE for the server. This will disable the TLS sniffing, allowing server first protocols to be used.
    3. Configure your application to send TLS traffic directly.

    In order to support Istio’s traffic routing capabilities, traffic leaving a pod may be routed differently than when a sidecar is not deployed.

    For HTTP based traffic, traffic is routed based on the Host header. This may lead to unexpected behavior if the destination IP and Host header are not aligned. For example, a request like curl 1.2.3.4 -H "Host: httpbin.default" will be routed to the httpbin service, rather than 1.2.3.4.

    For Non-HTTP based traffic (including HTTPS), Istio does not have access to an Host header, so routing decisions are based on the Service IP address.