Skip to content

For the complete documentation index, see llms.txt. Markdown versions of all docs pages are available by appending .md to any docs URL.

System and app requirements

Page as Markdown

    

Review cluster topology options, platform-specific prerequisites, and deployment considerations before installing ambient mesh.

Number of clusters

Single cluster

Ambient mesh runs in a single Kubernetes cluster and secures all enrolled workloads within it. Ambient mesh gives you automatic mTLS between workloads, Layer 4 (L4) authorization policy, and optional Layer 7 (L7) policy and traffic management through waypoint proxies with no sidecar injection required.

Multicluster

Solo Enterprise for Istio

This feature is available as an enterprise feature of Solo Enterprise for Istio, an enterprise distribution of ambient mesh.

Solo Enterprise for Istio extends ambient mesh across multiple clusters by peering each cluster’s istiod control plane over mTLS-secured xDS, without requiring remote Kubernetes API access or shared kubeconfig secrets. Each cluster runs its own istiod and east-west gateway, and services are discoverable across clusters using simple global naming and routing.

Key capabilities include:

  • Cross-cluster service discovery: Export services for global consumption and route traffic across clusters, with locality-aware load balancing to prefer local endpoints when available.
  • Zero-trust data plane: Cross-cluster traffic flows over HBONE through east-west gateways, maintaining the same mTLS guarantees as within a single cluster.
  • Flexible network topology: Supports both standard setups (separate cluster networks, traffic via east-west gateways) and flat network setups for clusters that share a network.
  • Extreme scale: Tested to 100 million pods across 2,000 clusters, with sub-100ms propagation and minimal control plane resource usage.

For more information, see the multicluster ambient mesh documentation.

Platform-specific prerequisites

Some Kubernetes environments require additional configuration before you install ambient mesh. The quickstart guide attempts to detect and automatically apply these configurations. For production or manual installations, review the required changes in the Istio documentation.

Cloud providers

Amazon Elastic Kubernetes Service (EKS)

If you use EKS with all of the following conditions, you must set POD_SECURITY_GROUP_ENFORCING_MODE to standard:

  • Amazon’s VPC CNI
  • Pod ENI trunking enabled
  • EKS pod-attached SecurityGroups via SecurityGroupPolicy

Istio uses a link-local SNAT address to identify kubelet health probes. In strict enforcing mode, the VPC CNI does not exempt link-local addresses from policy enforcement, which causes pod health probes to fail.

For more information, see the Istio documentation.

Google Kubernetes Engine (GKE)

On GKE, you must set global.platform=gke in your Helm installation commands, because GKE uses nonstandard locations for CNI binaries.

GKE also requires a ResourceQuota in any namespace where components with the system-node-critical priority class run. When installing in the default istio-system namespace, the ambient profile creates this automatically. If you install Istio into a different namespace, you must create the ResourceQuota manually.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: gcp-critical-pods
  namespace: istio-system
spec:
  hard:
    pods: 1000
  scopeSelector:
    matchExpressions:
    - operator: In
      scopeName: PriorityClass
      values:
      - system-node-critical

For more information, see the Istio documentation.

Red Hat OpenShift

On OpenShift, istio-cni and ztunnel must both be installed in the kube-system namespace, and all Helm installation commands must include --set global.platform=openshift.

If your workloads use liveness or readiness probes (which most do), you must also set routingViaHost: true in the Cluster Network Operator to enable OVN-Kubernetes local gateway mode. This ensures probe traffic is routed through the host network namespace, where the Istio CNI’s iptables rules apply. Without this, probe packets bypass the host netfilter stack via OVS and fail to reach the pod.

By default, kubelet and Kubernetes nodes do not have their own cryptographic identity. Ambient mesh uses a combination of iptables rules and SNAT to rewrite packets from the local node with a fixed link-local IP, so that Istio does not categorize kubelet traffic as insecure. For more information, see Considerations for Kubernetes network policy.

For more information, see the Istio documentation.

Local installation

No extra configuration is required when installing ambient mesh on kind.

k3d
Add --set global.platform=k3d to your Helm installation commands to set the required configuration for k3d. For more information, see the Istio documentation.
k3s
Add --set global.platform=k3s to your Helm installation commands to set the required configuration for k3s. For more information, see the Istio documentation.
Microk8s
Add --set global.platform=microk8s to your Helm installation commands to set the required configuration for Microk8s. For more information, see the Istio documentation.
Minikube
Add --set global.platform=minikube to your Helm installation commands to set the required configuration for Minikube. For more information, see the Istio documentation.

CNI-specific prerequisites

Cilium

If you use Cilium as your CNI, review the following requirements:

  • Cilium defaults to proactively deleting other CNI plugins and their configuration. You must set cni.exclusive = false to support chaining with the Istio CNI. For more information, see the Cilium documentation.

  • Cilium’s BPF masquerading is disabled by default and is not currently supported with Istio ambient. Enabling it via bpf.masquerade=true results in non-functional pod health checks. The default iptables masquerading implementation works correctly.

  • If you apply a default-deny NetworkPolicy or CiliumNetworkPolicy in your cluster, kubelet health probes will be blocked. Istio uses a link-local SNAT address for kubelet health probes that Cilium does not exempt from policy enforcement. To resolve this, apply the following CiliumClusterwideNetworkPolicy:

    apiVersion: "cilium.io/v2"
    kind: CiliumClusterwideNetworkPolicy
    metadata:
      name: "allow-ambient-hostprobes"
    spec:
      description: "Allows SNAT-ed kubelet health check probes into ambient pods"
      enableDefaultDeny:
        egress: false
        ingress: false
      endpointSelector: {}
      ingress:
      - fromCIDR:
        - "169.254.7.127/32"

    This policy is not required unless you have default-deny NetworkPolicies or CiliumNetworkPolicies in your cluster. For more information, see issue #49277 and the CiliumClusterwideNetworkPolicy documentation.

Application compatibility

Ambient mesh works without any modification to your existing Kubernetes deployments. You can label a namespace to add all of its workloads to the mesh, or opt in specific deployments as needed. Compared to sidecar-based service mesh, ambient mesh removes several previous restrictions: server-send-first protocols work, most reserved ports are available, and containers can no longer bypass the mesh, whether intentionally or not.

Deployment guidance

It is safe to deploy ambient mesh to a running cluster. Installing the Istio components does not affect traffic routing. Adding workloads to the mesh is a separate step and is easily reverted.

Start by installing ambient mesh and becoming familiar with the secure overlay mode before adding waypoint proxies. For many users, secure overlay mode alone meets their needs and can deliver mTLS and L4 authorization at as low as 10% of the cost of running Istio in sidecar mode.