{"id":355,"date":"2026-01-08T05:15:55","date_gmt":"2026-01-08T05:15:55","guid":{"rendered":"https:\/\/blog.ngocha.biz\/?p=355"},"modified":"2026-01-08T05:15:55","modified_gmt":"2026-01-08T05:15:55","slug":"setup-istio-ambient-mode","status":"publish","type":"post","link":"https:\/\/blog.ngocha.biz\/?p=355","title":{"rendered":"How to Set Up Istio in Ambient Mode (Detailed Guide)"},"content":{"rendered":"

In this blog, you will learn how to set up Istio Ambient Mode and validate Layer 4 (ztunnel) and Layer 7 (waypoint proxy) traffic on a Kubernetes cluster.<\/a><\/p>\n

By the end of this tutorial, you will have learned the following.<\/p>\n

    \n
  1. What is Istio Ambient Mode and how it differs from traditional sidecar architecture<\/a><\/li>\n
  2. Install Istio Ambient Mode using Helm charts<\/a><\/li>\n
  3. Core components (ztunnel, waypoint proxy, Istio CNI) and their specific roles<\/li>\n
  4. How ztunnel handles L4 traffic at the node level for all pods.<\/li>\n
  5. Deploy and configure waypoint proxies using Gateway API resources to handle L7 traffic<\/li>\n<\/ol>\n

    and more..<\/p>\n

    Lets gets started.<\/p>\n

    What is Istio Ambient Mode?<\/h2>\n

    Istio Ambient Mode<\/strong> is a sidecar-less architecture for the Istio service mesh<\/a>. Traditionally, Istio injects a sidecar in to every pod that is part of the mesh.<\/p>\n

    However, Ambient Mode uses the new data plane architecture in <\/strong>Istio service mesh that does not require sidecar proxies<\/strong> for each workload. <\/p>\n

    Instead, all the L4 traffic <\/strong>is managed by a light weight ztunnel <\/strong>(Zero Trust tunnel) proxy at the node level. Meaning all the ingress and egress connectivity from pods are intercepted by the ztunnel<\/strong> proxy.<\/p>\n

    All the the L7 traffic<\/strong> is handled by the waypoint proxies at namespace level.<\/p>\n

    \"Istio<\/figure>\n

    By eliminating per-pod sidecar proxies, it significantly reduces CPU and memory consumption<\/strong> (up to 70% savings).<\/p>\n

    Now that you have an idea about Ambient mode, lets get started with the setup.<\/p>\n

    Istio Ambient Mode Installation via Helm (Step-by-Step)<\/h2>\n

    For this setup, we use will use the official Helm<\/a> chart to install the Istio ambient mesh components one by one.<\/p>\n

    \n
    \ud83d\udca1<\/div>\n
    If you want to install all components using a single chart, you can use the istio\/ambient<\/code> chart. This is mainly useful for testing purposes<\/p>\n

    You can also set up the whole Ambient environment using Istioctl install --set profile=ambient<\/code><\/div>\n<\/div>\n

    Lets get started with the setup.<\/p>\n

    Step 1: Initialize the Istio Repository<\/h3>\n

    The first step is adding the whole Istio repo on our local machine and using the update command to ensure that we have all the latest charts.<\/p>\n

    helm repo add istio https:\/\/istio-release.storage.googleapis.com\/charts \n\nhelm repo update<\/code><\/pre>\n
    The installation begins with the base chart.<\/p>\n
    Step 2: Install Istio Base Chart <\/h3>\n
    The Istio base chart contains all the Istio-related Custom Resource Definitions.<\/p>\n
    \"selecting<\/figure>\n
    To install the base chart, use the following command.<\/p>\n
    helm install istio-base istio\/base -n istio-system --create-namespace --wait<\/code><\/pre>\n
    Once the installation is completed, use the following command to list them.<\/p>\n
    $ kubectl get crds | grep istio.io\n\nauthorizationpolicies.security.istio.io         2025-11-28T04:33:38Z\ndestinationrules.networking.istio.io            2025-11-28T04:33:39Z\nenvoyfilters.networking.istio.io                2025-11-28T04:33:38Z\ngateways.networking.istio.io                    2025-11-28T04:33:38Z\npeerauthentications.security.istio.io           2025-11-28T04:33:38Z\nproxyconfigs.networking.istio.io                2025-11-28T04:33:38Z\nrequestauthentications.security.istio.io        2025-11-28T04:33:38Z\nserviceentries.networking.istio.io              2025-11-28T04:33:38Z\nsidecars.networking.istio.io                    2025-11-28T04:33:38Z\ntelemetries.telemetry.istio.io                  2025-11-28T04:33:38Z\nvirtualservices.networking.istio.io             2025-11-28T04:33:38Z\nwasmplugins.extensions.istio.io                 2025-11-28T04:33:38Z\nworkloadentries.networking.istio.io             2025-11-28T04:33:38Z\nworkloadgroups.networking.istio.io              2025-11-28T04:33:38Z<\/code><\/pre>\n
    The output shows that the CRDs are installed.<\/p>\n
    Next,  we need to install the Gateway API<\/a> resources to create routing rules.<\/p>\n
    Step 3: Install Gateway API CRDs<\/h3>\n
    \n
    \ud83d\udca1<\/div>\n
    You might be used to VirtualService<\/code> and DestinationRule<\/code> resources. <\/p>\n
    While Istio Ambient mesh still supports them, it heavily favors the Kubernetes Gateway API<\/strong><\/b><\/a> for Layer 7 configuration using waypoint proxy.<\/p>\n
    That is why we are setting up the Gateway API CRDs.<\/p><\/div>\n<\/div>\n
    We need to use the Gateway API Custom Resources to create and configure the Waypoint proxy.<\/p>\n
    To install the Gateway API CRDs, use the following command. Please refer official gateway API installation page<\/a> to get the latest version of the Gateway API CRDs<\/p>\n
    kubectl apply --server-side -f https:\/\/github.com\/kubernetes-sigs\/gateway-api\/releases\/download\/v1.4.1\/standard-install.yaml<\/code><\/pre>\n
    Once the installation is completed, use the following command to list the installed custom resource definitions.<\/p>\n
    $ kubectl get crds | grep gateway.networking.k8s.io\n\nbackendtlspolicies.gateway.networking.k8s.io    2025-12-17T05:26:49Z\ngatewayclasses.gateway.networking.k8s.io        2025-12-17T05:26:49Z\ngateways.gateway.networking.k8s.io              2025-12-17T05:26:50Z\ngrpcroutes.gateway.networking.k8s.io            2025-12-17T05:26:50Z\nhttproutes.gateway.networking.k8s.io            2025-12-17T05:26:51Z\nreferencegrants.gateway.networking.k8s.io       2025-12-17T05:26:52Z<\/code><\/pre>\n
    Now, the Gateway API resources are installed, so the next step is to install the Istio Daemon with the ambient mode.<\/p>\n
    Step 4: Deploy Istiod with Ambient Profile<\/h3>\n
    We need to install the Istiod and enable the ambient mode. We can enable the ambient mode during the installation.<\/p>\n
    The following marked Istio chart we use to install the Istio Daemon.<\/p>\n
    \"selecting<\/figure>\n
    During the installation, we use the flag --set-profile=ambient<\/code> to tell Istiod to enable the Ambient Mode feature. <\/p>\n
    Use the following command to install istiod in ambient mode.<\/p>\n
    helm install istiod istio\/istiod --namespace istio-system --create-namespace --set profile=ambient --wait<\/code><\/pre>\n
    Once the installation is completed, ensure that the Istiod pod is running.<\/p>\n
    $ kubectl -n istio-system get po,svc\n\nNAME                          READY   STATUS    RESTARTS   AGE\npod\/istiod-6547d75b5f-wd696   1\/1     Running   0          46s\n\nNAME             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)                                 AGE\nservice\/istiod   ClusterIP   10.100.88.243   <none>        15010\/TCP,15012\/TCP,443\/TCP,15014\/TCP   3h45m<\/code><\/pre>\n
    On the next step, we need to install Istio CNI to redirect the incoming pod traffic to the traffic management component.<\/p>\n
    Step 5: Deploy Istio CNI<\/h3>\n
    \n
    \ud83d\udca1<\/div>\n
    Istio CNI is not a full Kubernetes CNI plugin that replaces your cluster CNI. It is CNI chaining plugin that works alongside your existing cluster CNI (like Calico, Cilium, Flannel, etc.) rather than replacing it. <\/div>\n<\/div>\n
    Istio CNI is an Ambient Mode component that inserts iptables rules<\/strong> so that pod traffic gets redirected through Istio ambient Ztunnel proxies.<\/p>\n
    To install it, we need to choose the istio\/cni<\/code> chart from the repo.<\/p>\n
    \"selecting<\/figure>\n
    Install the Istio CNI using the following helm command.<\/p>\n
    helm install istio-cni istio\/cni -n istio-system --set profile=ambient --wait\n<\/code><\/pre>\n
    Once the installation is completed, we need to list the Pods<\/a> of the Istio CNI<\/p>\n
    $ kubectl get all -n istio-system -l app.kubernetes.io\/instance=istio-cni\n\nNAME                       READY   STATUS    RESTARTS   AGE\npod\/istio-cni-node-br6pd   1\/1     Running   0          3m47s\npod\/istio-cni-node-f58ck   1\/1     Running   0          3m47s\n\nNAME                            DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE\ndaemonset.apps\/istio-cni-node   2         2         2       2            2           kubernetes.io\/os=linux   3m48s<\/code><\/pre>\n
    Step 6: Deploy Ztunnel<\/h3>\n
    The final component is the Ztunnel proxy.<\/p>\n
    The Ztunnel proxy is an Istio data plane component in Ambient mode that is the similar to the sidecar containers in the sidecar mode.<\/p>\n
    To install Ztunnel, you need to choose the istio\/ztunnel<\/code> chart from the repo.<\/p>\n
    \"selecting<\/figure>\n
    Install Ztunnel using the following command.<\/p>\n
    helm install ztunnel istio\/ztunnel -n istio-system --wait<\/code><\/pre>\n
    Once the installation is done, use the following command to list the Ztunnel pods.<\/p>\n
    $ kubectl get all -n istio-system | grep -i ztunnel\n\npod\/ztunnel-frjjv             1\/1     Running   0          79s\npod\/ztunnel-jzzx2             1\/1     Running   0          79s\n\ndaemonset.apps\/ztunnel          2         2         2       2            2           kubernetes.io\/os=linux   80s<\/code><\/pre>\n
    As you can see in the output, the ztunnel is deployed as a Daemonset<\/a>.<\/p>\n
    Using  istioctl<\/code> we can verify if the Ztunnel (data planes) are linked with the Istio Daemon (control plane)<\/p>\n
    $ istioctl proxy-status \n\nNAME                           CLUSTER        ISTIOD                      VERSION     SUBSCRIBED TYPES\nztunnel-flpfw.istio-system     Kubernetes     istiod-6547d75b5f-99tbh     1.28.0      2 (WADS,WDS)\nztunnel-mzmtj.istio-system     Kubernetes     istiod-6547d75b5f-99tbh     1.28.0      2 (WADS,WDS)<\/code><\/pre>\n
    In the output, you can see two subscriptions, such as WADS<\/code> and WDS<\/code>. It means, the control plane is actively “listening” for live updates<\/strong>.<\/p>\n
    Now, the entire Istio Ambient Mode setup is ready. Next step is to create a namespace and enable ambient mode in it. <\/p>\n
    Enabling Ambient Mode for Workloads<\/h2>\n
    To make workloads part of the Istio ambient mesh, we need to enable it in the namespace level using the istio.io\/dataplane-mode=ambient<\/code> label. This way all the pods that gets deployed in that namespace will be part of the mesh.<\/p>\n
    Lets create a istio-test<\/code><\/strong> namespace where we can deploy sample workloads for testing.<\/p>\n
    kubectl create ns istio-test<\/code><\/pre>\n
    Use the following command to set the Ambient Mode label to the namespace.<\/p>\n
    kubectl label namespace istio-test istio.io\/dataplane-mode=ambient\n<\/code><\/pre>\n
    \n
    \ud83d\udca1<\/div>\n
    If you want to enable the Ambient mode for only one Pod, then you can use the same label to label only the pod.<\/div>\n<\/div>\n
    Now, verify the label using the following command.<\/p>\n
    $ kubectl get ns -L istio.io\/dataplane-mode\n\nNAME              STATUS   AGE   DATAPLANE-MODE\ndefault           Active   22h   \nistio-system      Active   21h   \nistio-test        Active   23s   ambient<\/code><\/pre>\n
    We have enabled the ambient mode for the istio-test namespace. So any application we deploy in it will automatically be part of the Ambient mesh.<\/p>\n
    The next step is deploy workloads<\/strong> in the ambient mesh enabled namespace for testing.<\/p>\n
    \n
    \ud83d\udca1<\/div>\n
    We can still use the Sidecar Mode is Ambient setup. For that, we only need use the sidecar label (istio-injection=enabled<\/code>) in that particular namespace.<\/div>\n<\/div>\n
    Deploy Demo Applications<\/h2>\n
    To test all the ambient mode features, we will deploy two sample apps (v1 & v2) that expose a simple API.<\/p>\n
    The following diagram illustrates l4 and l7 traffic workflow that we are going to test with the sample deployments.<\/p>\n
    \"\"
    l4 and l7 traffic workflow in Istio ambient mode using ztunnel and waypoint proxy<\/span><\/figcaption><\/figure>\n
    Now lets deploy the sample APIs.<\/p>\n
    Use the following manifest directly to create the deployments and relates services.<\/p>\n
    cat <<'EOF' | kubectl apply -f -\napiVersion: apps\/v1\nkind: Deployment\nmetadata:\n  name: backend-v1\n  namespace: istio-test\nspec:\n  replicas: 3\n  selector:\n    matchLabels: { app: backend, version: v1 }\n  template:\n    metadata:\n      labels: { app: backend, version: v1 }\n    spec:\n      containers:\n      - name: echo\n        image: hashicorp\/http-echo\n        args: [\"-text=hello from backend v1\"]\n        ports:\n        - containerPort: 5678\n---\napiVersion: apps\/v1\nkind: Deployment\nmetadata:\n  name: backend-v2\n  namespace: istio-test\nspec:\n  replicas: 2\n  selector:\n    matchLabels: { app: backend, version: v2 }\n  template:\n    metadata:\n      labels: { app: backend, version: v2 }\n    spec:\n      containers:\n      - name: echo\n        image: hashicorp\/http-echo\n        args: [\"-text=hello from backend v2\"]\n        ports:\n        - containerPort: 5678\n---\napiVersion: v1\nkind: Service\nmetadata:\n  name: backend-v1\n  namespace: istio-test\nspec:\n  selector:\n    app: backend\n    version: v1\n  ports:\n  - name: http\n    port: 80\n    targetPort: 5678\n---\napiVersion: v1\nkind: Service\nmetadata:\n  name: backend-v2\n  namespace: istio-test\nspec:\n  selector:\n    app: backend\n    version: v2\n  ports:\n  - name: http\n    port: 80\n    targetPort: 5678\nEOF<\/code><\/pre>\n
    Once the deployment is completed, ensure that the deployments and services are properly created.<\/p>\n
    $ kubectl -n istio-test get po,svc\n\nNAME                              READY   STATUS    RESTARTS   AGE\npod\/backend-v1-7c88547fc6-62skp   1\/1     Running   0          33s\npod\/backend-v1-7c88547fc6-rstb7   1\/1     Running   0          33s\npod\/backend-v1-7c88547fc6-w5s45   1\/1     Running   0          33s\npod\/backend-v2-86c767bf6b-2k8jq   1\/1     Running   0          32s\npod\/backend-v2-86c767bf6b-2nl4d   1\/1     Running   0          32s\n\nNAME                 TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE\nservice\/backend-v1   ClusterIP   10.100.121.209   <none>        80\/TCP    31s\nservice\/backend-v2   ClusterIP   10.100.227.24    <none>        80\/TCP    31s<\/code><\/pre>\n
    Now that the applications are running, lets validate if the applications are configured to serve traffic via Istio mesh.<\/p>\n
    Validate Application Mesh Configurations<\/h2>\n
    To ensure that the ambient mode is enabled for our deployed workload, describe one of the workload pods using the following command. Replace <BACKEND POD><\/code> with the pod name.<\/p>\n
    kubectl -n istio-test describe po <BACKEND POD> | grep Annotations<\/code><\/pre>\n
    You will get an output with annotation added by the Istio CNI as shown below. This annotation indicates that the traffic to this Pod is redirected to the Ztunnel proxy.<\/p>\n
    $ kubectl -n istio-test describe po backend-v1-6997699946-9wlzq\n\n...\nAnnotations:      ambient.istio.io\/redirection: enabled\n...<\/code><\/pre>\n
    Another way to validate is using the istioctl<\/code><\/strong> command. The following command lists the pods that are registered with ztunnel<\/strong> using HBONE<\/code><\/strong> protocol.<\/p>\n
    $ istioctl ztunnel-config workload | grep HBONE\n\nistio-test   backend-v1-567bfdcf7-6rp4q          172.31.36.187 ip-172-31-40-209.us-west-2.compute.internal None     HBONE\nistio-test   backend-v1-567bfdcf7-r79hx          172.31.21.17  ip-172-31-26-127.us-west-2.compute.internal None     HBONE\nistio-test   backend-v1-567bfdcf7-tlzsx          172.31.42.98  ip-172-31-40-209.us-west-2.compute.internal None     HBONE\nistio-test   backend-v2-95d4845d7-fh2gg          172.31.38.186 ip-172-31-40-209.us-west-2.compute.internal None     HBONE\nistio-test   backend-v2-95d4845d7-nrv7g          172.31.22.17  ip-172-31-26-127.us-west-2.compute.internal None     HBONE<\/code><\/pre>\n
    The above output means, all the listed workloads are in ambient mesh mode, and their traffic is being handled by ztunnel using the HBONE protocol.<\/p>\n
    \n
    \ud83d\udca1<\/div>\n
    HBONE<\/strong><\/b><\/a> stands for HTTP-Based Overlay Network Environment<\/strong><\/b>. It is a tunneling protocol used to securely transport traffic between pods in the mesh.<\/div>\n<\/div>\n
    Now we have apps running in the Istio mesh ready for testing. First, we will test the layer 4 traffic<\/strong> with ztunnel proxy.<\/p>\n
    Testing L4 Connectivity with Ztunnel<\/h2>\n
    To test the l4 traffic, we will deploy a simple curl pod<\/strong> that sends request to the backend-v1<\/code> service endpoint.<\/p>\n
    The following diagram shows how traffic flows from a client pod to the destination pods via Ztunnel proxy.<\/p>\n
    \"L4<\/figure>\n
    Execute the following command to generate traffic from the client pod.<\/p>\n
    $ kubectl run test-client -n istio-test \\\n       --image=curlimages\/curl:latest \\\n       --restart=Never --rm -it \\\n       -- sh -c \"while true; do curl -s http:\/\/backend-v1 && sleep 2; done\"\n\n\nhello from backend v1\nhello from backend v1\nhello from backend v1\nhello from backend v1<\/code><\/pre>\n
    Now, keep in running.<\/p>\n
    In a different terminal, lets check the logs of the Ztunnel proxy to see how the traffic is handled by it. <\/p>\n
    Use the following command to stream new logs from the ztunnel DaemonSet pods<\/p>\n
    $ kubectl logs -n istio-system daemonset\/ztunnel -f --all-containers=true\n\n2025-12-17T06:10:01.553894Z info access connection complete src.addr=172.31.42.213:45010 src.workload=\"test-client\" src.namespace=\"istio-test\" src.identity=\"spiffe:\/\/cluster.local\/ns\/istio-test\/sa\/default\" dst.addr=172.31.36.187:15008 dst.hbone_addr=172.31.36.187:5678 dst.service=\"backend-v1.istio-test.svc.cluster.local\" dst.workload=\"backend-v1-567bfdcf7-6rp4q\" dst.namespace=\"istio-test\" dst.identity=\"spiffe:\/\/cluster.local\/ns\/istio-test\/sa\/default\" direction=\"outbound\" bytes_sent=74 bytes_recv=184 duration=\"1ms\" \n\n2025-12-17T06:10:03.561041Z info access connection complete src.addr=172.31.42.213:43500 src.workload=\"test-client\" src.namespace=\"istio-test\" src.identity=\"spiffe:\/\/cluster.local\/ns\/istio-test\/sa\/default\" dst.addr=172.31.42.98:15008 dst.hbone_addr=172.31.42.98:5678 dst.service=\"backend-v1.istio-test.svc.cluster.local\" dst.workload=\"backend-v1-567bfdcf7-tlzsx\" dst.namespace=\"istio-test\" dst.identity=\"spiffe:\/\/cluster.local\/ns\/istio-test\/sa\/default\" direction=\"inbound\" bytes_sent=184 bytes_recv=74 duration=\"0ms\"\n\n<\/code><\/pre>\n
    The log output shows that the source traffic from 172.31.42.213<\/code><\/strong> (ie, test-client pod) is passing through the ztunnel along with the amount of data transferred and the latency.<\/p>\n
    Now that our L4 traffic testing is done, lets validate L7 traffic using Ztunnel and Waypoint proxy.<\/p>\n
    Advanced L7 Traffic Management with Waypoint Proxies<\/h2>\n
    To handle L7 features like HTTP\/gRPC routing, Load balancing, Retries, timeouts, circuit breaking, L7 observability<\/strong> (HTTP metrics, access logs, tracing) etc., you need to have the waypoint proxy implementation.<\/strong><\/p>\n
    The following diagram illustrates how the waypoint proxy works alongside Ztunnel to manage the L7 traffic.<\/p>\n
    \"L7<\/figure>\n
    Here is how it works.<\/p>\n
    When we generate L7 traffic from the client pod, the local ztunnel<\/strong> on the source node intercepts traffic and provides L4 functions. <\/p>\n
    But when a request needs L7 processing, the source ztunnel wraps the raw TCP\/HTTP traffic into an HBONE tunnel<\/strong> (mTLS-encrypted over port 15008) and sends it to the Waypoint Proxy.<\/p>\n
    The waypoint proxy then applies the L7 rules (e.g., “10% of traffic to v2) and then wraps the traffic back into a new HBONE tunnel and sends it to the destination ztunnel<\/strong> on the node where the target Pod actually lives.<\/p>\n
    \n
    \ud83d\udca1<\/div>\n
    One Waypoint proxy is usually enough for an entire namespace or a service.<\/div>\n<\/div>\n
    Now, lets get started with the waypoint proxy setup.<\/p>\n
    Default Waypoint Gateway Class<\/h3>\n
    We need Kubernetes Gateway API<\/strong> to implement Waypoint proxies. <\/p>\n
    The GatewayClass<\/code> for waypoint proxy named istio-waypoint<\/code><\/strong> is automatically created when you install the Istiod in ambient mode.<\/p>\n
    To view the waypoint GatewayClass<\/code>, use the following command.<\/p>\n
    $ kubectl get gc\n\nNAME             CONTROLLER                    ACCEPTED   AGE\nistio            istio.io\/gateway-controller   True       6h37m\nistio-remote     istio.io\/unmanaged-gateway    True       6h37m\nistio-waypoint   istio.io\/mesh-controller      True       6h37m<\/code><\/pre>\n
    As you can see the istio-waypoint gateway class is associated with the istio.io\/mesh-controller<\/code>. Meaning this is the controllers that spins up the required waypoint envoy pods.<\/p>\n
    With the default GatewayClass in place, the next step is to create a Gateway.
    The Gateway is what deploys the waypoint proxy.<\/p>\n
    Create a Waypoint Gateway<\/h3>\n
    When we create a Gateway API Gateway object<\/strong>, a namespace-scoped Waypoint proxy is created.<\/p>\n
    \"The<\/figure>\n
    When creating a Gateway, we need to HBONE (Port 15008) listener. <\/strong>It handles the encrypted mesh traffic coming from the Ztunnel.<\/p>\n
    We also need to mention the GatewayClass<\/code>, that is, the default istio-waypoint<\/code> <\/strong>GatewayClass.<\/p>\n
    Use the following to create the Gateway manifest with the above-mentioned details.<\/p>\n
    cat << EOF > test-waypoint.yaml\napiVersion: gateway.networking.k8s.io\/v1\nkind: Gateway\nmetadata:\n  labels:\n    istio.io\/waypoint-for: all\n  name: test-waypoint\n  namespace: istio-test\nspec:\n  gatewayClassName: istio-waypoint\n  listeners:\n  - name: mesh\n    port: 15008\n    protocol: HBONE\n    allowedRoutes:\n      namespaces:\n        from: Same\nEOF<\/code><\/pre>\n
    \n
    \u26a0\ufe0f<\/div>\n
    When a Gateway object is labeled with istio.io\/waypoint-for: all<\/code>, all traffic from Ztunnel passes through Waypoint for both services<\/strong><\/b> and Pods<\/strong><\/b>.<\/p>\n
    Instead of all<\/code>, we can use workload<\/code>, services,<\/code> or even none<\/code> to control this.<\/div>\n<\/div>\n
    To apply this, use the following command.<\/p>\n
    kubectl apply -f test-waypoint.yaml<\/code><\/pre>\n
    Once the Gateway is created, verify it using the following command.<\/p>\n
    $ kubectl -n istio-test get gateway\n\nNAME            CLASS            ADDRESS          PROGRAMMED   AGE\ntest-waypoint   istio-waypoint   10.100.255.236   True         60s<\/code><\/pre>\n
    As mentioned earlier, the Gateway object will deploy a envoy based waypoint proxy as Deployment with a ClusterIP service. <\/p>\n
    Use the following command to validate it.<\/p>\n
    $ kubectl get deploy,po,svc -n istio-test -l gateway.networking.k8s.io\/gateway-name=test-waypoint    \n\nNAME                            READY   UP-TO-DATE   AVAILABLE   AGE\ndeployment.apps\/test-waypoint   1\/1     1            1           3m4s\n\nNAME                                 READY   STATUS    RESTARTS   AGE\npod\/test-waypoint-6bf8c7b68b-6v5rc   1\/1     Running   0          3m4s\n\nNAME                    TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)               AGE\nservice\/test-waypoint   ClusterIP   10.100.255.236   <none>        15021\/TCP,15008\/TCP   3m5s<\/code><\/pre>\n
    Enrolling a Namespace with the Waypoint Proxy<\/h3>\n
    Now we have the waypoint proxy deployed and running in the istio namespace. To use it for our 7 based workloads, we need to enroll the namespace<\/strong>.<\/p>\n
    To enroll a namespace with the waypoint proxy, you need to label the namespace <\/strong>with the waypoint Gateway name. In our case, the Gateway name is test-waypoint<\/code><\/strong><\/p>\n
    Execute the following command to add the label to the namespace.<\/p>\n
    kubectl label ns istio-test istio.io\/use-waypoint=test-waypoint<\/code><\/pre>\n
    With the above Label the traffic goes Client Pod<\/code> -> Ztunnel<\/code> -> Waypoint Proxy<\/code> -> Destination Pod<\/code>.<\/p>\n
    Here is where it gets interesting. By labeling the namespace this way, you are essentially opting all workloads<\/strong> and services in that namespace to use the waypoint proxy. It means, now all the L4 and L7 traffic<\/strong> will be intercepted by the waypoint proxy. <\/p>\n
    For example, a database operating on L4 will also use waypoint and adds a bit of latency.<\/strong><\/p>\n
    \n
    \ud83d\udca1<\/div>\n
    To optimize performance, you can limit the waypoint proxy usage by using the label istio.io\/use-waypoint:<\/code> over service, or pod.<\/p>\n
    For example, if you only want to enable Waypoint for a particular service, then set lbel to that service as istio.io\/use-waypoint: backend-svc-1<\/code><\/p>\n
    This way we can avoid the unnecessary pod to pod traffic routing to the waypoint proxy <\/p><\/div>\n<\/div>\n
    Now, how do we know if Waypoint Proxy is now fully aware of and ready to manage traffic for our services?<\/p>\n
    Well, we can check the proxy configurations using the following  istioctl<\/code>  command. It will list the endpoints<\/strong> that the Waypoint Proxy is currently tracking.<\/p>\n
    $ istioctl proxy-config endpoints deployment\/test-waypoint -n istio-test\n\nENDPOINT                                                STATUS      OUTLIER CHECK     CLUSTER\n127.0.0.1:15000                                         HEALTHY     OK                prometheus_stats\n127.0.0.1:15020                                         HEALTHY     OK                agent\nenvoy:\/\/connect_originate\/                              HEALTHY     OK                encap\nenvoy:\/\/connect_originate\/172.31.21.17:5678             HEALTHY     OK                inbound-vip|80|http|backend-v1.istio-test.svc.cluster.local\nenvoy:\/\/connect_originate\/172.31.22.17:5678             HEALTHY     OK                inbound-vip|80|http|backend-v2.istio-test.svc.cluster.local\nenvoy:\/\/connect_originate\/172.31.36.187:5678            HEALTHY     OK                inbound-vip|80|http|backend-v1.istio-test.svc.cluster.local\nenvoy:\/\/connect_originate\/172.31.38.186:5678            HEALTHY     OK                inbound-vip|80|http|backend-v2.istio-test.svc.cluster.local\nenvoy:\/\/connect_originate\/172.31.42.98:5678             HEALTHY     OK                inbound-vip|80|http|backend-v1.istio-test.svc.cluster.local\nenvoy:\/\/main_internal\/                                  HEALTHY     OK                main_internal\nunix:\/\/.\/etc\/istio\/proxy\/XDS                            HEALTHY     OK                xds-grpc\nunix:\/\/.\/var\/run\/secrets\/workload-spiffe-uds\/socket     HEALTHY     OK                sds-grpc<\/code><\/pre>\n
    In the above output HEALTHY status means, the Waypoint is successfully communicating with these pods. It ensures that all our backends are configured with the Waypoint proxy. <\/p>\n
    Now we can create an HTTPRoute object <\/strong>for L7 routing.<\/p>\n
    \n
    Note: <\/strong><\/b>All the Gateway setup steps and the namespace enrollment using labels can be done using the following single istioctl<\/code> command<\/p>\n
    istioctl waypoint apply -n default --enroll-namespace<\/code><\/p>\n
    However, for a production setup, this approach is not ideal. Production environments should be declarative<\/strong><\/b> and versioned in Git<\/strong><\/b>.<\/p>\n
    That is why we chose the Gateway CRD based approach<\/strong><\/b> with explicit configuration and custom labels, instead of relying on an imperative istioctl<\/code> command.<\/div>\n<\/div>\n
    Create a Shared Service for HTTPRoute<\/h3>\n
    For our demo application, we deployed two deployments and two services to test weighted routing.<\/p>\n
    For HTTPRoute<\/code>, as discussed in the GAMMA approach for east-west traffic<\/a>, we need a shared Service endpoint<\/strong> that can be referenced in the HTTPRoute<\/code> configuration. <\/p>\n
    Use the following command to create the manifest for shared Service<\/strong> named backend<\/code> .<\/p>\n
    cat << EOF> shared-svc.yaml\napiVersion: v1\nkind: Service\nmetadata:\n  name: backend\n  namespace: istio-test\nspec:\n  ports:\n  - name: http\n    port: 80\n    targetPort: 80\n  selector:\n    app: backend\nEOF<\/code><\/pre>\n
    To apply this, use the following command.<\/p>\n
    kubectl apply -f shared-svc.yaml<\/code><\/pre>\n
    Now that we have the shared service endpoint, lets create the HTTPRoute.<\/p>\n
    Create an HTTPRoute<\/h3>\n
    Using HTTPRoute<\/code>, we will perform a weighted canary deployment<\/strong> that splits traffic in a 90\/10<\/strong> ratio between the demo applications we deployed.<\/p>\n
    All these HTTP-based Layer 7 configurations<\/strong> will be handled by the waypoint proxy.<\/p>\n
    Use the following configuration to create an HTTPRoute<\/code><\/p>\n
    cat << EOF > istio-httproute.yaml\napiVersion: gateway.networking.k8s.io\/v1\nkind: HTTPRoute\nmetadata:\n  name: backend-route\n  namespace: istio-test\nspec:\n  parentRefs:\n  - name: backend\n    kind: Service\n    group: \"\"\n    namespace: istio-test\n  rules:\n  - matches:\n    - path:\n        type: PathPrefix\n        value: \/\n    backendRefs:\n    - name: backend-v1\n      port: 80\n      weight: 90\n    - name: backend-v2\n      port: 80\n      weight: 10\nEOF<\/code><\/pre>\n
    As you can see, we have used the shared service backend<\/code><\/strong> as the parentRefs<\/code><\/strong>.<\/p>\n
    To apply this, use the following command.<\/p>\n
    kubectl apply -f istio-httproute.yaml<\/code><\/pre>\n
    Verify the HTTPRoute<\/code> using the following command.<\/p>\n
    $ kubectl -n istio-test get httproutes\n\nNAME            HOSTNAMES   AGE\nbackend-route               48s<\/code><\/pre>\n
    Next we will enable access logging for Waypoint Proxy<\/strong> using the istio Telemetry CRD. It will record a detailed log entry for every single request it process.<\/p>\n
    Enable Access Logging Using Telemetry<\/h3>\n
    Telemetry is one of the Istio Custom Resources that enables the logs and other observability features for all Istio-managed traffic in the proxies.<\/p>\n
    Here, we are using this to generate the logs in Waypoint about the Layer 7 testing.<\/p>\n
    Use the following manifest to enable access logging for istio-test<\/code> namespace.<\/p>\n
    cat << EOF > telemetry-log.yaml\napiVersion: telemetry.istio.io\/v1alpha1\nkind: Telemetry\nmetadata:\n  name: enable-logs\n  namespace: istio-test\nspec:\n  accessLogging:\n    - providers:\n      - name: envoy\nEOF<\/code><\/pre>\n
    To apply this, use the following command.<\/p>\n
    kubectl apply -f telemetry-log.yaml<\/code><\/pre>\n
    To list the Telemetry resources, use the following command.<\/p>\n
    $ kubectl -n istio-test get telemetries\n\nNAME          AGE\nenable-logs   7m1s<\/code><\/pre>\n
    Now, we are ready for testing.<\/p>\n
    Validate Layer 7 Traffic Through the Waypoint Proxy<\/h3>\n
    To generate traffic, we will use the same curl based test-client pod and send request to the shared backend service endpoint. Ideally we should see the 90\/10 traffic split in the response.<\/p>\n
    Execute the following command.<\/p>\n
    $ kubectl run test-client -n istio-test \\\n       --image=curlimages\/curl:latest \\\n       --restart=Never --rm -it \\\n       -- sh -c \"while true; do curl -s http:\/\/backend && sleep 2; done\"\n\nhello from backend v1\nhello from backend v1\nhello from backend v1\nhello from backend v1\nhello from backend v1\nhello from backend v2  <-- 10% Canary Traffic\nhello from backend v1\nhello from backend v1\nhello from backend v1\nhello from backend v1\nhello from backend v1\nhello from backend v2  <-- 10% Canary Traffic\nhello from backend v1<\/code><\/pre>\n
    From the output, you can see that the traffic split is happening in 90\/10 way<\/strong>. It means waypoint proxy is handling the traffic.<\/p>\n
    To further verify if waypoint proxy is handling this traffic, open another terminal to watch the logs.<\/p>\n
    Use the following command to stream the live logs of the Waypoint proxy.<\/p>\n
    $ kubectl logs -n istio-test -l gateway.networking.k8s.io\/gateway-name=test-waypoint -f\n\n[2025-12-01T12:59:44Z] \"GET \/\" 200 via_upstream \n  src=172.31.26.126:46074 (client)\n  dst=backend-v2.istio-test.svc.cluster.local\n  hbone_target=172.31.23.1:5678\n  gateway=istio-waypoint-gateway (inbound-vip|80)\n\n[2025-12-01T12:59:46Z] \"GET \/\" 200 via_upstream\n  src=172.31.26.126:54482 (client)\n  dst=backend-v1.istio-test.svc.cluster.local\n  hbone_target=172.31.30.34:5678\n  gateway=istio-waypoint-gateway (inbound-vip|80)\n<\/code><\/pre>\n
    The output shows that the traffic is passing through the Waypoint Proxy, where we defined the L7 policies.<\/p>\n
    That\u2019s it! We have successfully set up Istio Ambient Mode and tested its key features, covering both Layer 4 and Layer 7 traffic.<\/p>\n
    Now, do not leave any resources running, as they may cost you money.<\/p>\n
    If you are done with your learning and testing, lets clean up all the Istio system components from the cluster.<\/p>\n
    Cleanup the Setup<\/h2>\n
    To delete Ztunnel.<\/p>\n
    helm delete ztunnel -n istio-system<\/code><\/pre>\n
    To delete Istio CNI.<\/p>\n
    helm delete istio-cni -n istio-system<\/code><\/pre>\n
    To delete the Istio daemon.<\/p>\n
    helm delete istiod -n istio-system<\/code><\/pre>\n
    To delete the Istio base.<\/p>\n
    helm delete istio-base -n istio-system<\/code><\/pre>\n
    Is Istio ambient mode production ready?<\/h2>\n
    One key question everyone has is the production readiness of ambient mode.<\/p>\n
    Well, Ambient mode is officially Generally Available (GA).<\/strong><\/p>\n
    In our testing on a standard EKS cluster, we noticed that the Ztunnel resource footprint was significantly lighter than the sidecars we previously implemented. Which means, the core is stable enough<\/strong> for single cluster <\/strong>production use in many scenarios today. <\/p>\n
    That said, this does not automatically mean you should move everything to production today.<\/p>\n
    You should validate limits and test workloads<\/strong> carefully for your exact use case before any kind of production rollout.<\/p>\n
    \n
    \ud83d\udca1<\/div>\n
    Coexistence Architecture: <\/strong><\/b>You can run both sidecar and Ambient Mode in the same cluster, where some namespaces operate in Ambient Mode and others continue to use the sidecar model.<\/div>\n<\/div>\n
    Now the “million dollar question” Is anyone actually using Ambient Mode in production today?<\/em><\/p>\n
    Well, Tetrate, an enterprise service mesh platform has made a secure, government-ready version of Istio Ambient Mode<\/a>, tested with the U.S. Air Force, and is now offering it to customers who need high security and compliance.<\/p>\n
    Also, the Multi-cluster ambient mesh is not production ready yet. It is still in alpha. So if you are looking for multi cluster mesh, ambient mesh is not a good choice today.<\/p>\n
    If you looking at adoption, the ztunnel image<\/a> in dockerhub has more than 10 million downloads.<\/p>\n
    \n
    Note:<\/strong><\/b> If you want to set up Istio in sidecar mode, please refer to our detailed blog on installing Istio using the sidecar mode<\/a>.<\/div>\n<\/div>\n
    Conclusion<\/h2>\n
    This blog covered the setup and configuration of Istio Ambient Mode.<\/p>\n
    Unlike the traditional sidecar model, Ambient Mesh follows a layered approach by separating Layer 4 and Layer 7 traffic handling.<\/p>\n
    One important thing to give more attention to is waypoint proxy labeling. You should design your services and namespaces in a way that only workloads that really need Layer 7 features use a waypoint proxy.<\/p>\n
    For production setups that involve multiple clusters and multiple environments, it is recommended to use Helm along with a GitOps controller like ArgoCD<\/a> or Flux to manage Istio ambient mesh components.<\/p>\n
    In the upcoming blogs, we will look at how to migrate from sidecars to the ambient mesh architecture.<\/p>\n
    If you face any issues during the setup, drop a comment below. We will help you.<\/p>\n
    \n
    Ngu\u1ed3n:<\/strong> How to Set Up Istio in Ambient Mode (Detailed Guide) \u2014 DevOpsCube<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
    Source: https:\/\/devopscube.com\/setup-istio-ambient-mode\/<\/p>\n","protected":false},"author":1,"featured_media":356,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-355","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops"],"_links":{"self":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/355","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=355"}],"version-history":[{"count":0,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/355\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/media\/356"}],"wp:attachment":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=355"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=355"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=355"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}