Added doc for Ztunnel inpod mode + updated ztunnel L4 guide for 1.21 function (#14611)

* Additional docs for ambient/ ztunnel user guides updated for 1.21.0 functions esp inpod traffic redirection

* Update content/en/docs/ops/ambient/usage/inpod/index.md

Co-authored-by: Ben Leggett <854255+bleggett@users.noreply.github.com>

* Update content/en/docs/ops/ambient/usage/inpod/index.md

Co-authored-by: Ben Leggett <854255+bleggett@users.noreply.github.com>

* Update content/en/docs/ops/ambient/usage/inpod/index.md

Co-authored-by: Ben Leggett <854255+bleggett@users.noreply.github.com>

* Update content/en/docs/ops/ambient/usage/inpod/index.md

* Update content/en/docs/ops/ambient/usage/inpod/index.md

* Update content/en/docs/ops/ambient/usage/inpod/index.md

* Update content/en/docs/ops/ambient/usage/inpod/index.md

* Update content/en/docs/ops/ambient/usage/inpod/index.md

Co-authored-by: Peter Jausovec <peterj@users.noreply.github.com>

* Update content/en/docs/ops/ambient/usage/inpod/index.md

Co-authored-by: Peter Jausovec <peterj@users.noreply.github.com>

* Update content/en/docs/ops/ambient/usage/inpod/index.md

Co-authored-by: Peter Jausovec <peterj@users.noreply.github.com>

* Update content/en/docs/ops/ambient/usage/inpod/index.md

Co-authored-by: Peter Jausovec <peterj@users.noreply.github.com>

* Update content/en/docs/ops/ambient/usage/inpod/index.md

Co-authored-by: Ben Leggett <854255+bleggett@users.noreply.github.com>

* Update content/en/docs/ops/ambient/usage/inpod/index.md

Co-authored-by: Ben Leggett <854255+bleggett@users.noreply.github.com>

* Update content/en/docs/ops/ambient/usage/ztunnel/index.md

Co-authored-by: Ben Leggett <854255+bleggett@users.noreply.github.com>

* Update content/en/docs/ops/ambient/usage/ztunnel/index.md

Co-authored-by: Ben Leggett <854255+bleggett@users.noreply.github.com>

* Update content/en/docs/ops/ambient/usage/ztunnel/index.md

Co-authored-by: Ben Leggett <854255+bleggett@users.noreply.github.com>

* Update content/en/docs/ops/ambient/usage/inpod/index.md

Co-authored-by: Ben Leggett <854255+bleggett@users.noreply.github.com>

* rewrite

* further updates, including the alpha warning and
the ztunnel guide.

* fix heading level

* pre-fix some lint errors

* change indents & add netns to spelling

* I think it's time to rename istio-cni myself

* Update content/en/boilerplates/ambient-alpha-warning.md

* Update content/en/docs/ops/ambient/usage/ztunnel/index.md

Co-authored-by: Daniel Hawton <daniel@hawton.org>

* Update content/en/docs/ops/ambient/usage/traffic-redirection/index.md

Co-authored-by: Lin Sun <lin.sun@solo.io>

* Update content/en/docs/ops/ambient/usage/traffic-redirection/index.md

* Update content/en/docs/ops/ambient/usage/traffic-redirection/index.md

* Update content/en/docs/ops/ambient/usage/traffic-redirection/index.md

* Update content/en/docs/ops/ambient/usage/traffic-redirection/index.md

* Update content/en/docs/ops/ambient/usage/ztunnel/index.md

* Update content/en/docs/ops/ambient/usage/ztunnel/index.md

* Update content/en/docs/ops/ambient/usage/ztunnel/index.md

---------

Co-authored-by: Craig Box <craig.box@gmail.com>
Co-authored-by: Ben Leggett <854255+bleggett@users.noreply.github.com>
Co-authored-by: Peter Jausovec <peterj@users.noreply.github.com>
Co-authored-by: Daniel Hawton <daniel@hawton.org>
Co-authored-by: Lin Sun <lin.sun@solo.io>

.spelling

@@ -784,6 +784,7 @@ natively
 Neeraj
 netfilter
 netmask
+netns
 network1
 network2
 networking.istio.io

content/en/boilerplates/ambient-alpha-warning.md

@@ -1,10 +1,11 @@
 ---
 ---
 {{< warning >}}
-Ambient is currently in [alpha status](/docs/releases/feature-stages/#feature-phase-definitions).
+Ambient mode is currently in the [Alpha](/docs/releases/feature-stages/#feature-phase-definitions) phase.
 
-Please **do not run ambient in production** and be sure to thoroughly review the [feature phase definitions](/docs/releases/feature-stages/#feature-phase-definitions) before use.
-In particular, there are known performance, stability, and security issues in the `alpha` release.
+Please **do not use ambient mode in production**, and be sure to thoroughly review the [feature phase definitions](/docs/releases/feature-stages/#feature-phase-definitions) before use.
+
+In particular, there are known performance, stability, and security issues in the alpha release.
 There are also planned breaking changes, including some that will prevent upgrades.
-These are all limitations that will be addressed before graduation to `beta`.
+These limitations will be addressed before ambient mode moves to Beta.
 {{< /warning >}}

content/en/docs/ops/ambient/usage/traffic-redirection/index.md

@@ -0,0 +1,133 @@
+---
+title: Ztunnel traffic redirection
+description: Understand how traffic is redirected between pods and the ztunnel node proxy.
+weight: 2
+owner: istio/wg-networking-maintainers
+test: no
+---
+
+In the context of ambient mode, _traffic redirection_ refers to data plane functionality that intercepts traffic sent to and from ambient-enabled workloads, routing it through the {{< gloss >}}ztunnel{{< /gloss >}} node proxies that handle the core data path. Sometimes the term _traffic capture_ is also used.
+
+{{< boilerplate ambient-alpha-warning >}}
+
+{{< tip >}}
+The method described in this guide was first included in Istio version 1.21.0, and [replaces previous methods](/blog/2024/inpod-traffic-redirection-ambient/).
+{{< /tip >}}
+
+## Istio's in-pod traffic redirection model
+
+The core design principle underlying ambient mode's in-pod traffic redirection is that the ztunnel proxy has the ability to perform data path capture inside the Linux network namespace of the workload pod. This is achieved via a cooperation of functionality between the [`istio-cni` node agent](/docs/setup/additional-setup/cni/) and the ztunnel node proxy. A key benefit of this model is that it enables Istio's ambient mode to work alongside any Kubernetes CNI plugin, transparently, and without impacting Kubernetes networking features.
+
+The following figure illustrates the sequence of events when a new workload pod is started in (or added to) an ambient-enabled namespace.
+
+{{< image width="100%"
+link="./pod-added-to-ambient.svg"
+alt="pod added to the ambient mesh flow"
+>}}
+
+The `istio-cni` node agent responds to CNI events such as pod creation and deletion, and also watches the underlying Kubernetes API server for events such as the ambient label being added to a pod or namespace.
+
+The `istio-cni` node agent additionally installs a chained CNI plugin that is executed by the container runtime after the primary CNI plugin within that Kubernetes cluster executes. Its only purpose is to notify the `istio-cni` node agent when a new pod is created by the container runtime in a namespace that is already enrolled in ambient mode, and propagate the new pod context to `istio-cni`.
+
+Once the `istio-cni` node agent is notified that a pod needs to be added to the mesh (either from the CNI plugin, if the pod is brand new, or from the Kubernetes API server, if the pod is already running but needs to be added), the following sequence of operations is performed:
+
+- `istio-cni` enters the pod’s network namespace and establishes network redirection rules, such that packets entering and leaving the pod are intercepted and transparently redirected to the node-local ztunnel proxy instance listening on [well-known ports](https://github.com/istio/ztunnel/blob/master/ARCHITECTURE.md#ports) (15008, 15006, 15001).
+
+- The `istio-cni` node agent then informs the ztunnel proxy, over a Unix domain socket, that it should establish local proxy listening ports inside the pod’s network namespace (on ports 15008, 15006, and 15001), and provides ztunnel with a low-level Linux [file descriptor](https://en.wikipedia.org/wiki/File_descriptor) representing the pod’s network namespace.
+    - While typically sockets are created within a Linux network namespace by the process actually running inside that network namespace, it is perfectly possible to leverage Linux’s low-level socket API to allow a process running in one network namespace to create listening sockets in another network namespace, assuming the target network namespace is known at creation time.
+
+- The node-local ztunnel internally spins up a new proxy instance and listen port set, dedicated to the newly-added pod.
+
+- Once the in-pod redirect rules are in place and the ztunnel has established the listen ports, the pod is added in the mesh and traffic begins flowing through the node-local ztunnel.
+
+Traffic to and from pods in the mesh will be fully encrypted with mTLS by default.
+
+Data will now enter and leave the pod network namespace encrypted. Every pod in the mesh has the ability to enforce mesh policy and securely encrypt traffic, even though the user application running in the pod has no awareness of either.
+
+Here’s a diagram to illustrate how encrypted traffic flows between pods in the ambient mesh in the new model:
+
+{{< image width="100%"
+    link="./traffic-flows-between-pods-in-ambient.svg"
+    alt="HBONE traffic flows between pods in the ambient mesh"
+    >}}
+
+## Observing and debugging traffic redirection in ambient mode
+
+If traffic redirection is not working correctly in ambient mode, some quick checks can be made to help narrow down the problem. To demonstrate traffic redirection in action, first follow the steps described in the [ztunnel L4 networking guide](/docs/ops/ambient/usage/ztunnel), including deployment of Istio with ambient mode enabled in a Kubernetes cluster, and the deployment of `httpbin` and `sleep` in the namespace tagged for ambient mode. Once you have verified that the application is successfully running in the ambient mesh, you can use the following steps to observe the traffic redirection.
+
+### Check the ztunnel proxy logs
+
+When an application pod is part of an ambient mesh, you can check the ztunnel proxy logs to confirm the mesh is redirecting traffic. As shown in the example below, the ztunnel logs related to `inpod` indicate that in-pod redirection mode is enabled, the proxy has received the network namespace (netns) information about an ambient application pod, and has started proxying for it.
+
+{{< text bash >}}
+$ kubectl logs ds/ztunnel -n istio-system  | grep inpod
+Found 3 pods, using pod/ztunnel-hl94n
+inpod_enabled: true
+inpod_uds: /var/run/ztunnel/ztunnel.sock
+inpod_port_reuse: true
+inpod_mark: 1337
+2024-02-21T22:01:49.916037Z  INFO ztunnel::inpod::workloadmanager: handling new stream
+2024-02-21T22:01:49.919944Z  INFO ztunnel::inpod::statemanager: pod WorkloadUid("1e054806-e667-4109-a5af-08b3e6ba0c42") received netns, starting proxy
+2024-02-21T22:01:49.925997Z  INFO ztunnel::inpod::statemanager: pod received snapshot sent
+2024-02-21T22:03:49.074281Z  INFO ztunnel::inpod::statemanager: pod delete request, draining proxy
+2024-02-21T22:04:58.446444Z  INFO ztunnel::inpod::statemanager: pod WorkloadUid("1e054806-e667-4109-a5af-08b3e6ba0c42") received netns, starting proxy
+{{< /text >}}
+
+### Confirm the state of sockets
+
+Follow the steps below to confirm that the sockets on ports 15001, 15006, and 15008 are open and in the listening state.
+
+{{< text bash >}}
+$ kubectl debug $(kubectl get pod -l app=sleep -n ambient-demo -o jsonpath='{.items[0].metadata.name}') -it -n ambient-demo  --image nicolaka/netshoot  -- ss -ntlp
+Defaulting debug container name to debugger-nhd4d.
+State  Recv-Q Send-Q Local Address:Port  Peer Address:PortProcess
+LISTEN 0      128        127.0.0.1:15080      0.0.0.0:*
+LISTEN 0      128                *:15006            *:*
+LISTEN 0      128                *:15001            *:*
+LISTEN 0      128                *:15008            *:*
+{{< /text >}}
+
+### Check the iptables rules setup
+
+To view the iptables rules setup inside one of the application pods, execute this command:
+
+{{< text bash >}}
+$ kubectl debug $(kubectl get pod -l app=sleep -n ambient-demo -o jsonpath='{.items[0].metadata.name}') -it --image gcr.io/istio-release/base --profile=netadmin -n ambient-demo -- iptables-save
+
+Defaulting debug container name to debugger-m44qc.
+# Generated by iptables-save v1.8.7 on Wed Feb 21 20:38:16 2024
+*mangle
+:PREROUTING ACCEPT [320:53261]
+:INPUT ACCEPT [23753:267657744]
+:FORWARD ACCEPT [0:0]
+:OUTPUT ACCEPT [23352:134432712]
+:POSTROUTING ACCEPT [23352:134432712]
+:ISTIO_OUTPUT - [0:0]
+:ISTIO_PRERT - [0:0]
+-A PREROUTING -j ISTIO_PRERT
+-A OUTPUT -j ISTIO_OUTPUT
+-A ISTIO_OUTPUT -m connmark --mark 0x111/0xfff -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff
+-A ISTIO_PRERT -m mark --mark 0x539/0xfff -j CONNMARK --set-xmark 0x111/0xfff
+-A ISTIO_PRERT -s 169.254.7.127/32 -p tcp -m tcp -j ACCEPT
+-A ISTIO_PRERT ! -d 127.0.0.1/32 -i lo -p tcp -j ACCEPT
+-A ISTIO_PRERT -p tcp -m tcp --dport 15008 -m mark ! --mark 0x539/0xfff -j TPROXY --on-port 15008 --on-ip 0.0.0.0 --tproxy-mark 0x111/0xfff
+-A ISTIO_PRERT -p tcp -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
+-A ISTIO_PRERT ! -d 127.0.0.1/32 -p tcp -m mark ! --mark 0x539/0xfff -j TPROXY --on-port 15006 --on-ip 0.0.0.0 --tproxy-mark 0x111/0xfff
+COMMIT
+# Completed on Wed Feb 21 20:38:16 2024
+# Generated by iptables-save v1.8.7 on Wed Feb 21 20:38:16 2024
+*nat
+:PREROUTING ACCEPT [0:0]
+:INPUT ACCEPT [0:0]
+:OUTPUT ACCEPT [175:13694]
+:POSTROUTING ACCEPT [205:15494]
+:ISTIO_OUTPUT - [0:0]
+-A OUTPUT -j ISTIO_OUTPUT
+-A ISTIO_OUTPUT -d 169.254.7.127/32 -p tcp -m tcp -j ACCEPT
+-A ISTIO_OUTPUT -p tcp -m mark --mark 0x111/0xfff -j ACCEPT
+-A ISTIO_OUTPUT ! -d 127.0.0.1/32 -o lo -j ACCEPT
+-A ISTIO_OUTPUT ! -d 127.0.0.1/32 -p tcp -m mark ! --mark 0x539/0xfff -j REDIRECT --to-ports 15001
+COMMIT
+{{< /text >}}
+
+The command output shows that additional Istio-specific chains are added to the NAT and Mangle tables in netfilter/iptables within the application pod's network namespace. All TCP traffic coming into the pod is redirected to the ztunnel proxy for ingress processing. If the traffic is plaintext (source port != 15008), it will be redirected to the in-pod ztunnel plaintext listening port 15006. If the traffic is HBONE (source port == 15008), it will be redirected to the in-pod ztunnel HBONE listening port 15008. Any TCP traffic leaving the pod is redirected to ztunnel's port 15001 for egress processing, before being sent out by ztunnel using HBONE encapsulation.

content/en/docs/ops/ambient/usage/ztunnel/index.md

@@ -37,17 +37,17 @@ Some use cases of Istio in ambient mode may be addressed solely via the L4 secur
 
 ## Current Caveats {#caveats}
 
-Ztunnel proxies are automatically installed when one of the supported installation methods is used to install Istio ambient mesh. The minimum Istio version required for Istio ambient mode is `1.18.0`. In general Istio in ambient mode supports the existing Istio APIs that are supported in sidecar proxy mode. Since the ambient functionality is currently at an alpha release level, the following is a list of feature restrictions or caveats in the current release of Istio's ambient functionality (as of the `1.19.0` release). These restrictions are expected to be addressed/removed in future software releases as ambient graduates to beta and eventually General Availability.
+{{< boilerplate ambient-alpha-warning >}}
 
-1. **Kubernetes (K8s) only:** Istio in ambient mode is currently only supported for deployment on Kubernetes clusters. Deployment on non-Kubernetes endpoints such as virtual machines is not currently supported.
+The following is a list of feature restrictions or caveats in ambient mode alpha. These restrictions are planned to be addressed or removed in future releases.
+
+1. **Kubernetes only:** Istio in ambient mode is currently only supported for deployment on Kubernetes clusters. Deployment on non-Kubernetes endpoints such as virtual machines is not currently supported.
 
 1. **No Istio multi-cluster support:** Only single cluster deployments are currently supported for Istio ambient mode.
 
-1. **K8s CNI restrictions:** Istio in ambient mode does not currently work with every Kubernetes CNI implementation. Additionally, with some plugins, certain CNI functions (in particular Kubernetes `NetworkPolicy` and Kubernetes Service Load balancing features) may get transparently bypassed in the presence of Istio ambient mode. The exact set of supported CNI plugins as well as any CNI feature caveats are currently under test and will be formally documented as Istio's ambient mode approaches the beta release.
-
 1. **TCP/IPv4 only:** In the current release, TCP over IPv4 is the only protocol supported for transport on an Istio secure overlay tunnel (this includes protocols such as HTTP that run between application layer endpoints on top of the TCP/ IPv4 connection).
 
-1. **No dynamic switching to ambient mode:** ambient mode can only be enabled on a new Istio mesh control plane that is deployed using ambient profile or ambient helm configuration. An existing Istio mesh deployed using a pre-ambient profile for instance can not be dynamically switched to also enable ambient mode operation.
+1. **Cannot transparently convert existing Istio deployments to ambient mode:** Ambient mode can only be enabled on a new Istio mesh control plane that is deployed using the ambient `istioctl` profile or Helm configuration. An existing Istio mesh deployed using a sidecar profile cannot currently be dynamically switched to enable ambient mode.
 
 1. **Restrictions with Istio `PeerAuthentication`:** as of the time of writing, the `PeerAuthentication` resource is not supported by all components (i.e. waypoint proxies) in Istio ambient mode. Hence it is recommended to only use the `STRICT` mTLS mode currently. Like many of the other alpha stage caveats, this shall be addressed as the feature moves toward beta status.
 
@@ -55,9 +55,9 @@ Ztunnel proxies are automatically installed when one of the supported installati
 
 ### Environment used for this guide
 
-The examples in this guide used a deployment of Istio version `1.19.0` on a `kind` cluster of version `0.20.0` running Kubernetes version `1.27.3`.
+The examples in this guide used a deployment of Istio version `1.21.0` on a `kind` cluster of version `0.20.0` running Kubernetes version `1.27.3`.
 
-The minimum Istio version needed for ambient functions is 1.18.0 and the minimum Kubernetes version needed is `1.24.0`. The examples below require a cluster with more than 1 worker node in order to explain how cross-node traffic operates. Refer to the [installation user guide](/docs/ops/ambient/install/) or [getting started guide](/docs/ops/ambient/getting-started/) for information on installing Istio in ambient mode on a Kubernetes cluster.
+The examples below require a cluster with more than 1 worker node in order to explain how cross-node traffic operates. Refer to the [installation user guide](/docs/ops/ambient/install/) or [getting started guide](/docs/ops/ambient/getting-started/) for information on installing Istio in ambient mode on a Kubernetes cluster.
 
 ## Functional Overview {#functionaloverview}
 
@@ -91,7 +91,11 @@ caption="Basic ztunnel L4-only datapath"
 
 The figure depicts ambient pod workloads running on two nodes W1 and W2 of a Kubernetes cluster. There is a single instance of the ztunnel proxy on each node. In this scenario, application client pods C1, C2 and C3 need to access a service provided by pod S1 and there is no requirement for advanced L7 features such as L7 traffic routing or L7 traffic management so no Waypoint proxy is needed.
 
-The figure shows that pods C1 and C2 running on node W1 connect with pod S1 running on node W2 and their TCP traffic is tunneled through a single shared HBONE tunnel instance that has been created between the ztunnel proxy pods of each node. Mutual TLS (mTLS) is used for encryption as well as mutual authentication of traffic being tunneled. SPIFFE identities are used to identify the workloads on each side of the connection. The term `HBONE` (for HTTP Based Overlay Network Encapsulation) is used in Istio ambient to refer to a technique for transparently and securely tunneling TCP packets encapsulated within HTTPS packets. Some brief additional notes on HBONE are provided in a following subsection.
+The figure shows that pods C1 and C2 running on node W1 connect with pod S1 running on node W2 and their TCP traffic is tunneled through HBONE tunnel instances that have been created by the ztunnel proxy pods of each node. Mutual TLS (mTLS) is used for encryption as well as mutual authentication of traffic being tunneled. SPIFFE identities are used to identify the workloads on each side of the connection. The term `HBONE` (for HTTP Based Overlay Network Encapsulation) is used in Istio ambient to refer to a technique for transparently and securely tunneling TCP packets encapsulated within HTTPS packets. For more details on the datapath, including HBONE and the traffic redirection details, refer to the [ztunnel traffic redirection](/docs/ops/ambient/usage/traffic-redirection) guide.
+
+{{< tip >}}
+Note: Although the figure shows the HBONE tunnels to be between the two ztunnel proxies, in the in-pod redirection implementation introduced in Istio 1.21.0 the tunnels are in fact between the source and destination pods. Traffic is HBONE encapsulated and encrypted in the network namespace of the source pod itself, and eventually decapsulated and decrypted in the network namespace of the destination pod on the destination worker node. The ztunnel proxy still logically handles both the control plane and data plane needed for HBONE transport, however it is able to do that from inside the network namespaces of the source and destination pods.
+{{< /tip >}}
 
 Note that the figure shows that local traffic - from pod C3 to destination pod S1 on worker node W2 - also traverses the local ztunnel proxy instance so that L4 traffic management functions such as L4 Authorization and L4 Telemetry are enforced identically on traffic, whether or not it crosses a node boundary.
 
@@ -124,14 +128,14 @@ caption="Ztunnel traffic hair-pinning"
 
 ### Note on HBONE {#hbonesection}
 
-HBONE (HTTP Based Overlay Network Encapsulation) is an Istio-specific term. It refers to the use of standard HTTP tunneling via the [HTTP CONNECT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/CONNECT) method to transparently tunnel application packets/ byte streams. In its current implementation within Istio, it transports TCP packets only by tunneling these transparently using the HTTP CONNECT method, uses [HTTP/2](https://httpwg.org/specs/rfc7540.html), with encryption and mutual authentication provided by [mutual TLS](https://www.cloudflare.com/learning/access-management/what-is-mutual-tls/) and the HBONE tunnel itself runs on TCP port 15008. The overall HBONE packet format from IP layer onwards is depicted in the following figure.
+HBONE (HTTP Based Overlay Network Encapsulation) is an Istio-specific term. It refers to the use of standard HTTP tunneling via the [HTTP CONNECT](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/CONNECT) method to transparently tunnel application packets/ byte streams. In its current implementation within Istio, it transports TCP packets by tunneling these transparently using the HTTP CONNECT method, uses [HTTP/2](https://httpwg.org/specs/rfc7540.html), with encryption and mutual authentication provided by [mutual TLS](https://www.cloudflare.com/learning/access-management/what-is-mutual-tls/) and the HBONE tunnel itself runs on TCP port 15008. The overall HBONE packet format from IP layer onwards is depicted in the following figure.
 
 {{< image width="100%"
 link="hbone-packet.png"
 caption="HBONE L3 packet format"
 >}}
 
-In future Istio Ambient may also support [HTTP/3 (QUIC)](https://datatracker.ietf.org/doc/html/rfc9114) based transport and will be used to transport all types of L3 and L4 packets including native IPv4, IPv6, UDP by leveraging new standards such as CONNECT-UDP and CONNECT-IP being developed as part of the [IETF MASQUE](https://ietf-wg-masque.github.io/) working group. Such additional use cases of HBONE and HTTP tunneling in Istio's ambient mode are currently for further investigation.
+Additional use cases of HBONE and HTTP tunneling (such as support for IPv6 and UDP packets) will be investigated in the future as ambient mode evolves.
 
 ## Deploying an Application {#deployapplication}
 
@@ -192,7 +196,7 @@ sleep-69cfb4968f-mhccl     1/1     Running   0          78m
 sleep-69cfb4968f-rhhhp     1/1     Running   0          78m
 {{< /text >}}
 
-Note that after ambient is enabled for the namespace, every application pod still only has 1 container, and the uptime of these pods indicates these were not restarted in order to enable ambient mode (unlike `sidecar` mode which does restart application pods when the sidecar proxies are injected). This results in better user experience and operational performance since ambient mode can seamlessly be enabled (or disabled) completely transparently as far as the application pods are concerned.
+Note that after ambient is enabled for the namespace, every application pod still only has 1 container, and the uptime of these pods indicates these were not restarted in order to enable ambient mode (unlike sidecar mode, which requires pods to be restarted when the sidecar proxies are injected). This results in better user experience and operational performance since ambient mode can seamlessly be enabled (or disabled) completely transparently as far as the application pods are concerned.
 
 Initiate a `curl` request again from one of the client pods to the service to verify that traffic continues to flow while ambient mode.
 
@@ -277,7 +281,7 @@ $ kubectl exec -n istio-system deploy/istiod -- curl localhost:15014/debug/confi
 Send some traffic from a client `sleep` pod to the `httpbin` service.
 
 {{< text bash >}}
-$ kubectl -n ambient-demo exec deploy/sleep -- sh -c 'for i in $(seq 1 10); do curl -s -I http://httpbin:8000/; done'
+$ kubectl -n ambient-demo exec deploy/sleep -- sh -c "for i in $(seq 1 10); do curl -s -I http://httpbin:8000/; done"
 HTTP/1.1 200 OK
 Server: gunicorn/19.9.0
 --snip--
@@ -323,7 +327,7 @@ deployment.apps/httpbin condition met
 {{< /text >}}
 
 {{< text bash >}}
-$ kubectl -n ambient-demo exec deploy/sleep -- sh -c 'for i in $(seq 1 10); do curl -s -I http://httpbin:8000/; done'
+$ kubectl -n ambient-demo exec deploy/sleep -- sh -c "for i in $(seq 1 10); do curl -s -I http://httpbin:8000/; done"
 {{< /text >}}
 
 {{< text bash >}}