Merge branch 'istio:master' into ambient_waypoint_guide

.devcontainer/devcontainer.json

@@ -1,6 +1,6 @@
 {
   "name": "istio build-tools",
-  "image": "gcr.io/istio-testing/build-tools:master-f36e91a6385155b2c42ee673f0c666e7894e2f58",
+  "image": "gcr.io/istio-testing/build-tools:master-d5b39ac8e423b269748c9c1e9692a853db960fc9",
   "privileged": true,
   "remoteEnv": {
     "USE_GKE_GCLOUD_AUTH_PLUGIN": "True",
@@ -11,5 +11,23 @@
   "features": {
     "ghcr.io/devcontainers/features/docker-outside-of-docker:1": {},
     "ghcr.io/mpriscella/features/kind:1": {}
+  },
+  "customizations": {
+    "vscode": {
+      "extensions": [
+        "golang.go",
+        "rust-lang.rust-analyzer",
+        "eamodio.gitlens",
+        "zxh404.vscode-proto3",
+        "ms-azuretools.vscode-docker",
+        "redhat.vscode-yaml",
+        "IBM.output-colorizer"
+      ],
+      "settings": {
+        "files.eol": "\n",
+        "go.useLanguageServer": true,
+        "go.lintTool": "golangci-lint"
+      }
+    }
   }
 }

.spelling

@@ -205,6 +205,7 @@ CDNs
 CFP
 CentOS
 Cernich
+Chaomeng
 checksum
 Chrony
 Chun
@@ -243,6 +244,7 @@ configurability
 conformant
 containerID
 ControlZ
+Coraza
 CoreDNS
 coreos
 Costin
@@ -380,6 +382,7 @@ Devirtualization
 devops
 devstats
 Dhir
+Dhiyaulhaq
 discoverability
 discuss.istio.io
 distro
@@ -477,6 +480,7 @@ GlueCon
 Gmail
 googleapis.com
 googlegroups.com
+GoTo
 Grafana
 grafana-istio-dashboard
 Graphviz
@@ -508,6 +512,7 @@ https
 Hu
 Huabing
 Huawei
+Huailong
 Huayuan
 hyperkube
 hypervisor
@@ -704,6 +709,7 @@ microservices
 middleboxes
 middleware
 minikube
+MirageDebug
 misconfiguration
 misconfigurations
 misconfigured
@@ -743,6 +749,7 @@ nginx
 NICs
 NiFi
 Nikhita
+Ning
 NLBs
 no-brainer
 Node.js
@@ -770,6 +777,7 @@ onboard
 Onboard
 onboarding
 Onboarding
+OneCloud
 onsite
 onwards
 OpenAPI
@@ -856,6 +864,7 @@ Pub/Sub
 PubNub
 pwd
 px.dev
+Qin
 qps
 quay.io
 quo
@@ -940,10 +949,13 @@ sharded
 sharding
 Sharding
 Shi
+Shilin
+Shivanshu
 shortcode
 shortcodes
 Shray
 Shriram
+Shrivastava
 sidebar_multicard
 sidebar_none
 sidecar
@@ -960,6 +972,7 @@ SNI
 SolarWinds
 Solo.io
 Solo.io.
+SongYang
 SPIFFE
 SPIFFE-compliant
 Splunk
@@ -1146,6 +1159,8 @@ xDS
 Xeon
 Xia
 Xiao
+Xiaopeng
+Xie
 Xining
 xRoute
 Xu
@@ -1160,11 +1175,14 @@ Yizhou
 Yoichi
 Yossi
 Yuval
+Yuxing
 Zack
 Zehuan
+Zeng
 Zhang
 Zhao
 zhaohuabing
+Zheng
 Zhenni
 Zhihan
 Zhong
@@ -1177,3 +1195,4 @@ Zolotusky
 Zsh
 ztunnel
 ztunnels
+Zufar

common/.commonfiles.sha

@@ -1 +1 @@
-970b1b83e2ec81844a0e4567ddb0e19e8deadba8
+37b1df7c218df019feaa525e91c35265ba9a06f7

common/scripts/setup_env.sh

@@ -75,7 +75,7 @@ fi
 TOOLS_REGISTRY_PROVIDER=${TOOLS_REGISTRY_PROVIDER:-gcr.io}
 PROJECT_ID=${PROJECT_ID:-istio-testing}
 if [[ "${IMAGE_VERSION:-}" == "" ]]; then
-  IMAGE_VERSION=master-f36e91a6385155b2c42ee673f0c666e7894e2f58
+  IMAGE_VERSION=master-d5b39ac8e423b269748c9c1e9692a853db960fc9
 fi
 if [[ "${IMAGE_NAME:-}" == "" ]]; then
   IMAGE_NAME=build-tools

content/en/blog/2023/istiocon-china/index.md

@@ -0,0 +1,84 @@
+---
+title: "IstioCon China 2023 wrap-up"
+description: A quick recap of Istio at KubeCon + CloudNativeCon + Open Source Summit China in Shanghai.
+publishdate: 2023-09-29
+attribution: "IstioCon China 2023 Program Committee"
+keywords: [Istio Day,IstioCon,Istio,conference,KubeCon,CloudNativeCon]
+---
+
+It’s great to be able to safely get together in person again.  After two years of only running virtual events, we have filled the calendar for 2023. [Istio Day Europe](/blog/2023/istio-at-kubecon-eu/) was held in April, and [Istio Day North America](https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/co-located-events/istio-day/) is coming this November.
+
+IstioCon is committed to the industry-leading service mesh that provides a platform to explore insights gained from real-world Istio deployments, engage in interactive hands-on activities, and connect with maintainers across the entire Istio ecosystem.
+
+Alongside our [virtual IstioCon 2023](https://events.istio.io/) event, [IstioCon China 2023](https://www.lfasiallc.com/kubecon-cloudnativecon-open-source-summit-china/co-located-events/istiocon-cn/) was held on September 26 in Shanghai, China. Part of the KubeCon + CloudNativeCon + Open Source Summit China, the event was arranged and hosted by the Istio maintainers and the CNCF. We were very proud to have a strong program for IstioCon in Shanghai and pleased to bring together members of the Chinese Istio community. The event was a testament to Istio’s immense popularity in the Asia-Pacific ecosystem.
+
+{{< image link="./group-pic.jpg"
+    caption="IstioCon China 2023"
+    >}}
+
+IstioCon China kicked off with an opening keynote from Program Committee members Jimmy Song and Zhonghu Xu. The event was packed with great content, ranging from new features to end user talks, with major focus on the new Istio ambient mesh.
+
+{{< image width="75%"
+    link="./opening-keynote.jpg"
+    caption="IstioCon China 2023, Welcome"
+    >}}
+
+The welcome speech was followed by a sponsored keynote from Justin Pettit from Google, on "Istio Ambient Mesh as a Managed Infrastructure" which highlighted the importance and priority of the ambient model in the Istio community, especially for our top supporters like Google Cloud.
+
+{{< image width="75%"
+    link="./sponsored-keynote-google.jpg"
+    caption="IstioCon China 2023, Google Cloud Sponsored Keynote"
+    >}}
+
+Perfectly placed after the keynote, Huailong Zhang from Intel and Yuxing Zeng from Alibaba discussed configurations for the co-existence of Ambient and Sidecar: a very relevant topic for existing users who want to experiment with the new ambient model.
+
+{{< image width="75%"
+    link="./ambient-l4.jpg"
+    caption="IstioCon China 2023, Deep Dive into Istio Network Flows and Configurations for the co-existence of Ambient and Sidecar"
+    >}}
+
+Huawei's new Istio data plane based on eBPF intends to implement the capabilities of L4 and L7 in the kernel,to avoid kernel-state and user-mode switching and reduce the latency of the data plane. This was explained by an interesting talk from Xie SongYang and Zhonghu Xu. Chun Li and Iris Ding from Intel also integrated eBPF with Istio, with their talk "Harnessing eBPF for Traffic Redirection in Istio ambient mode", leading to more interesting discussions. DaoCloud also had a presence at the event, with Kebe Liu sharing Merbridge’s innovation in eBPF and Xiaopeng Han presenting about MirageDebug for localized Istio development.
+
+{{< image width="75%"
+    link="./users-engaging.jpg"
+    alt="interaction with audience"
+    >}}
+
+The talk from Tetrate’s Jimmy Song, about the perfect union of different GitOps and Observability tools, was also very well received. Chaomeng Zhang from Huawei presented on how cert-manager helps enhance the security and flexibility of Istio's certificate management system, and Xi Ning Wang and Zehuan Shi from Alibaba Cloud shared the idea of using VK (Virtual Kubelet) to implement serverless mesh.
+
+While Shivanshu Raj Shrivastava gave a perfect introduction to WebAssembly through his talk "Extending and Customizing Istio with Wasm", Zufar Dhiyaulhaq from GoTo Financial, Indonesia shared the practice of using Coraza Proxy Wasm to extend Envoy and quickly implement custom Web Application Firewalls.
+Huabing Zhao from Tetrate shared Aeraki Mesh's Dubbo service governance practices with Qin Shilin from Boss Direct. While multi-tenancy is always a hot topic with Istio, John Zheng from HP described in detail about multi-tenant management in HP OneCloud Platform.
+
+The slides for all the sessions can be found in the [IstioCon China 2023 schedule](https://istioconchina2023.sched.com/) and all the presentations will be available in the CNCF YouTube Channel soon for the audience in other parts of the world.
+
+## On the show floor
+
+Istio had a full time kiosk in the project pavilion at KubeCon + CloudNativeCon + Open Source Summit China 2023 , with the majority of questions asked around ambient mesh. Many of our members and maintainers offered support at the booth, where a lot of interesting discussions happened.
+
+{{< image width="75%"
+    link="./istio-support-at-the-booth.jpg"
+    caption="KubeCon + CloudNativeCon + Open Source Summit China 2023, Istio Kiosk"
+    >}}
+
+Another highlight was the Istio Steering Committee members and authors of the Istio books "Cloud Native Service Mesh Istio" and "Istio: the Definitive Guide", Zhonghu Xu and Chaomeng Zhang, spent time at the Istio booth interacting with our users and contributors.
+
+{{< image width="75%"
+    link="./meet-the-authors.jpg"
+    caption="Meet the Authors"
+    >}}
+
+We would like to express our heartfelt gratitude to our diamond sponsors Google Cloud, for supporting IstioCon 2023!
+
+{{< image width="40%"
+    link="./diamond-sponsor.jpg"
+    caption="IstioCon 2023, Our Diamond Sponsor"
+    >}}
+
+Last but not least, we would like to thank our IstioCon China Program Committee members for all their hard work and support!
+
+{{< image width="75%"
+    link="./istiocon-program-committee.jpg"
+    caption="IstioCon China 2023, Program Committee Members (Not Pictured: Iris Ding)"
+    >}}
+
+[See you all in Chicago in November!](https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/co-located-events/istio-day/)

content/en/blog/2023/traffic-for-ambient-and-sidecar/index.md

@@ -12,16 +12,16 @@ There are 2 deployment modes for Istio: ambient mode and sidecar mode. The forme
 
 In the architecture of modern microservices, communication and management among services is critical. To address the challenge, Istio emerged as a service mesh technology. It provides traffic control, security, and superior observation capabilities by utilizing the sidecar. In order to further improve the adaptability and flexibility of Istio, the Istio community began to explore a new mode - ambient mode. In this mode, Istio no longer relies on explicit sidecar injection, but achieves communication and mesh management among services through ztunnel and waypoint proxies. Ambient also brings a series of improvements, such as lower resource consumption, simpler deployment, and more flexible configuration options. When enabling ambient mode, we don't have to restart pods anymore which enables Istio to play a better role in various scenarios.
 
-There are many blogs, which can be found in `Reference Resources` section of this blog, to introduce and analyze ambient mode in community and technology forums, and this blog will analyze the network traffic path in Istio ambient and sidecar modes. We will analyze the network traffic path between services in these two modes.
+There are many blogs, which can be found in the [Reference Resources](#reference-resources) section of this blog, that introduce and analyze ambient, and this blog will analyze the network traffic path in Istio ambient and sidecar modes.
 
 To clarify the network traffic paths and make it easier to understand, this blog post explores the following two scenarios with corresponding diagrams:
 
 - **The network path of services in ambient mode to services in sidecar mode**
 - **The network path of services in sidecar mode to services in ambient mode**
 
-_Note 1: The following analysis is based on Istio 1.18.2, where ambient mode uses iptables for redirection._
+## Information about the analysis
 
-_Note 2: The communications between sidecar and ztunnel/waypoint proxy uses `[HTTP Based Overlay Network (HBONE)](https://docs.google.com/document/d/1Ofqtxqzk-c_wn0EgAXjaJXDHB9KhDuLe-W3YGG67Y8g/edit)`._
+The analysis is based on Istio 1.18.2, where ambient mode uses iptables for redirection.
 
 ## Ambient mode `sleep` to sidecar mode `httpbin`
 
@@ -49,15 +49,15 @@ All network traffic coming in/out of the pod with ambient mode enabled will go t
 
 According to above diagram, the details of network traffic path is demonstrated as below:
 
-**(1) (2) (3)**  Request traffic of the `sleep` service is sent out from the `veth` of the `sleep` pod where it will be marked and forwarded to the `istioout` device in the node by following the iptables rules and route rules. The `istioout` device in the node A is a `[geneve](https://www.rfc-editor.org/rfc/rfc8926.html)` tunnel, and the other end of the tunnel is `pistioout`, which is inside the ztunnel pod on the same node.
+**(1) (2) (3)** Request traffic of the `sleep` service is sent out from the `veth` of the `sleep` pod where it will be marked and forwarded to the `istioout` device in the node by following the iptables rules and route rules. The `istioout` device on node A is a [Geneve](https://www.rfc-editor.org/rfc/rfc8926.html) tunnel, and the other end of the tunnel is `pistioout`, which is inside the ztunnel pod on the same node.
 
-**(4) (5)**  When the traffic arrives through the `pistioout` device, the iptables rules inside the pod intercept and redirect it through the `eth0` interface in the pod to port `15001`.
+**(4) (5)** When the traffic arrives through the `pistioout` device, the iptables rules inside the pod intercept and redirect it through the `eth0` interface in the pod to port `15001`.
 
-**(6)** According to the original request information, ztunnel can obtain the endpoint list of the target service. It will then handle sending the request to the endpoint, such as one of the `httpbin` pods. At last, the request traffic would get into the `httpbin` pod via the container network.
+**(6)** According to the original request information, ztunnel can obtain the endpoint list of the target service. It will then handle sending the request to the endpoint, such as one of the `httpbin` pods. Finally, the request traffic would get into the `httpbin` pod via the container network.
 
-**(7)**  The request traffic arriving in `httpbin` pod will be intercepted and redirected through port `15006` of the sidecar by its iptables rules.
+**(7)** The request traffic arriving in `httpbin` pod will be intercepted and redirected through port `15006` of the sidecar by its iptables rules.
 
-**(8)**  Sidecar handles the inbound request traffic coming in via port 15006, and forwards the traffic to the `httpbin` container in the same pod.
+**(8)** Sidecar handles the inbound request traffic coming in via port 15006, and forwards the traffic to the `httpbin` container in the same pod.
 
 ## Sidecar mode `sleep` to ambient mode `httpbin` and `helloworld`
 
@@ -86,19 +86,19 @@ With the above description, the deployment and network traffic paths are:
 
 Network traffic path of a request from the `sleep` pod (sidecar mode) to the `httpbin` pod (ambient mode) is depicted in the top half of the diagram above.
 
-**(1) (2) (3) (4)** the `sleep` container sends a request to `httpbin`. The request is intercepted by iptables rules and directed to port `15001` on the sidecar in the `sleep` pod. Then, the sidecar handles the request and routes the traffic based on the configuration received from istiod (control plane). Next, the sidecar forwards the traffic to an IP address corresponding to the `httpbin` pod on node B.
+**(1) (2) (3) (4)** the `sleep` container sends a request to `httpbin`. The request is intercepted by iptables rules and directed to port `15001` on the sidecar in the `sleep` pod. Then, the sidecar handles the request and routes the traffic based on the configuration received from istiod (control plane) forwarding the traffic to an IP address corresponding to the `httpbin` pod on node B.
 
-**(5) (6)**  After the request is sent to the device pair (`veth httpbin <-> eth0 inside httpbin pod`), the request is intercepted and forwarded using the iptables and route rules to the `istioin` device on the node B where `httpbin` pod is running by following its iptables and route rules. The `istioin` device on node B and the `pistion` device inside the ztunnel pod on the same node are connected by a `[geneve](https://www.rfc-editor.org/rfc/rfc8926.html)` tunnel.
+**(5) (6)** After the request is sent to the device pair (`veth httpbin <-> eth0 inside httpbin pod`), the request is intercepted and forwarded using the iptables and route rules to the `istioin` device on node B where `httpbin` pod is running by following its iptables and route rules. The `istioin` device on node B and the `pistion` device inside the ztunnel pod on the same node are connected by a [Geneve](https://www.rfc-editor.org/rfc/rfc8926.html) tunnel.
 
 **(7) (8)** After the request enters the `pistioin` device of the ztunnel pod, the iptables rules in the ztunnel pod intercept and redirect the traffic through port 15008 on the ztunnel proxy running inside the pod.
 
-**(9)** The traffic getting into the port 15008 would be considered as a inbound request, then ztunnel will forward the request to the `httpbin` pod in the same node B.
+**(9)** The traffic getting into the port 15008 would be considered as a inbound request, and the ztunnel will then forward the request to the `httpbin` pod in the same node B.
 
 ### Network traffic path analysis of sidecar mode `sleep` to ambient mode `httpbin` via waypoint proxy
 
-Comparing with the top part of the diagram, the bottom part inserts a waypoint proxy in the path between `sleep`, ztunnel and `httpbin` pods. The Istio control plane has all information of service and configuration of the service mesh. When `helloworld` pod is deployed with a waypoint proxy, the EDS configuration of `helloworld` service received by sidecar of `sleep` pod will be changed to the type of `envoy_internal_address`. This causes that the request traffic going through the sidecar to be forwarded to port 15008 of the waypoint proxy on node C via the `[HBONE](https://docs.google.com/document/d/1Ofqtxqzk-c_wn0EgAXjaJXDHB9KhDuLe-W3YGG67Y8g/edit)` protocol.
+Comparing with the top part of the diagram, the bottom part inserts a waypoint proxy in the path between the `sleep`, ztunnel and `httpbin` pods. The Istio control plane has all the service information and configuration of the service mesh. When `helloworld` pod is deployed with a waypoint proxy, the EDS configuration of `helloworld` service received by the `sleep` pod sidecar will be changed to the type of `envoy_internal_address`. This causes that the request traffic going through the sidecar to be forwarded to port 15008 of the waypoint proxy on node C via the [HTTP Based Overlay Network (HBONE)](https://docs.google.com/document/d/1Ofqtxqzk-c_wn0EgAXjaJXDHB9KhDuLe-W3YGG67Y8g/edit) protocol.
 
-Waypoint proxy is an instance of the Envoy proxy and forwards the request to the `helloworld` pod based on the routing configuration received from the control plane. Once traffic reaches the `veth` on node D, it follows the same path as the previous scenario
+Waypoint proxy is an instance of Envoy proxy and forwards the request to the `helloworld` pod based on the routing configuration received from the control plane. Once traffic reaches the `veth` on node D, it follows the same path as the previous scenario.
 
 ## Wrapping up
 
@@ -107,5 +107,5 @@ The sidecar mode is what made Istio a great service mesh. However, the sidecar m
 ## Reference Resources
 
 - [Traffic in ambient mesh: Istio CNI and node configuration](https://www.solo.io/blog/traffic-ambient-mesh-istio-cni-node-configuration/)
-- [Traffic in ambient mesh: Redirection using iptables and GENEVE tunnels](https://www.solo.io/blog/traffic-ambient-mesh-redirection-iptables-geneve-tunnels/)
+- [Traffic in ambient mesh: Redirection using iptables and Geneve tunnels](https://www.solo.io/blog/traffic-ambient-mesh-redirection-iptables-geneve-tunnels/)
 - [Traffic in ambient mesh: ztunnel, eBPF configuration, and waypoint proxies](https://www.solo.io/blog/traffic-ambient-mesh-ztunnel-ebpf-waypoint/)

content/en/docs/ops/configuration/traffic-management/dns/index.md

@@ -35,7 +35,7 @@ Istio uses this information to determine the intended destination.
 [Understanding Traffic Routing](/docs/ops/configuration/traffic-management/traffic-routing/) gives a deep dive into how this behavior works.
 
 If the client was unable to resolve the DNS request, the request would terminate before Istio receives it.
-This means that if a request is sent to a hostname which is known to Istio (for example, by a `VirtualService`) but not to the DNS server, the request will fail.
+This means that if a request is sent to a hostname which is known to Istio (for example, by a `ServiceEntry`) but not to the DNS server, the request will fail.
 Istio [DNS proxying](#dns-proxying) can change this behavior.
 
 Once Istio has identified the intended destination, it must choose which address to send to.