From 002689d0c5ab94cc6206804d25a8745c73aad9c9 Mon Sep 17 00:00:00 2001
From: fykaa <97490463+fykaa@users.noreply.github.com>
Date: Tue, 26 Sep 2023 00:58:10 +0530
Subject: [PATCH 01/19] Initial skeleton for L7 waypoint proxy user guide
---
.../docs/ops/ambient/usage/waypoint/index.md | 420 ++++++++++++++++++
1 file changed, 420 insertions(+)
create mode 100644 content/en/docs/ops/ambient/usage/waypoint/index.md
diff --git a/content/en/docs/ops/ambient/usage/waypoint/index.md b/content/en/docs/ops/ambient/usage/waypoint/index.md
new file mode 100644
index 000000000000..10da22d54198
--- /dev/null
+++ b/content/en/docs/ops/ambient/usage/waypoint/index.md
@@ -0,0 +1,420 @@
+---
+title: L7 - waypoint proxy Layer
+description: User guide for L7 Processing.
+weight: 2
+owner: istio/wg-networking-maintainers
+test: n/a
+---
+
+{{}}
+Before you start with this guide, please make sure that you have already read the Ztunnel Networking sub-guide and have a basic understanding of Istio Ambient Mesh. This guide assumes that you have already completed the Installation, set up the ztunnel and enabled mtls.
+
+If you have not yet done these things, please go back to the Ztunnel Networking sub-guide and follow the instructions before proceeding with this guide.
+
+Once you have completed the Ztunnel Networking sub-guide, you will be ready to start setting up the L7 Waypoint Proxy layer in Istio Ambient Mesh.
+
+{{}}
+
+
+## Introduction
+
+This guide provides instructions on how to set up and use the L7 Waypoint Proxy layer in Istio Ambient Mesh. It assumes that you have already read the Ztunnel Networking sub-guide and have a basic understanding of Istio Ambient Mesh.
+
+L7 traffic routing is based on L4 with the addition of the Waypoint proxy, which is more complex to handle in Envoy. We can also create HPAs to scale it dynamically.
+
+**Overview of the Layer 7 Waypoint proxy**
+
+TODO
+
+**Benefits of using the Layer 7 Waypoint proxy**
+
+TODO
+
+## Pre-requisites & Supported Topologies
+
+Before you begin, make sure that you have the following prerequisites in place:
+1. Istio Ambient Mesh installed and configured
+2. Ztunnel proxy is installed and running
+3. Mutual TLS (mtls) enabled and configured
+
+## Understanding the L7 Waypoint Proxy Default Configuration
+
+<< Consider breaking this out into bullets for easier reading TODO >>
+
+The L7 Waypoint Proxy layer in Istio Ambient Mesh is designed to provide a usable configuration out of the box with a fixed feature set that does not require much, or any, custom configuration. Currently, there are no configuration options that need to be set other than the `waypoint` profile setting. Once this profile is used, this in turn sets two internal configuration parameters within the Istio Operator which eventually set the configuration of the L7 Waypoint Proxy.
+
+In the future, there may be some additional limited configurability for L7 Waypoint Proxies. However, for now, the following are all configured with fixed default configurations that are not customizable:
+
+* Networking between pods and L7 Waypoint Proxies
+* Networking between L7 Waypoint Proxies
+* Networking between L7 Waypoint Proxies and sidecar proxies
+
+In particular, the only option for pod to L7 Waypoint Proxy networking setup is currently via the `istio-cni` and only via an internal ipTables based L7 Waypoint Proxy traffic redirect option. There is no option to use `init-containers` unlike with sidecar proxies. Alternate forms of L7 Waypoint Proxy traffic redirect such as eBPF are also not currently supported, although may be supported in future.
+
+Of course, once the baseline L7 Waypoint Proxy layer is installed, features such as Authorization Policy (both L4 and L7) as well as other Istio functions such as PeerAuthentication options for mutual-TLS are fully configurable similar to standard Istio. In future release versions, some limited configurability may also be added to the L7 Waypoint Proxy layer.
+
+#### Additional Notes
+
+* The L7 Waypoint Proxy layer can coexist with sidecar proxies in the same cluster. This allows you to use the L7 Waypoint Proxy for services that require L7 functionality and sidecar proxies for services that do not.
+* The L7 Waypoint Proxy is implemented using Envoy. This means that you can use all of the features of Envoy in your L7 Waypoint Proxies.
+* The L7 Waypoint Proxy is still under development, but it is already a powerful tool for managing L7 traffic in Istio Ambient Mesh.
+
+For the examples in this guide, we used a deployment of Istio Ambient on a `kind` cluster, although these should apply for any Kubernetes cluster version 1.18.0 or later. Refer to the Getting started guide on how to download the `istioctl` client and how to deploy a `kind` cluster. It would be recommended to have a cluster with more than 1 worker node in order to fully exercise the examples described in this guide.
+
+## Functional Overview
+
+A figure showing an architecture summary of the L7 waypoint proxy.
+
+TODO
+
+## Install Gateway CRDs
+
+**Before Deploying the Waypoint proxy: Install Gateway CRDs**
+
+In L7 networking, a waypoint proxy is a lightweight Envoy proxy that runs on each node in the cluster. It is used to implement L7 functionality in Istio Ambient Mesh.
+
+Waypoint proxies are dependent on Gateway API CRDs to provide features such as traffic routing and service discovery.
+
+1. Install Kubernetes Gateway CRDs, which don’t come installed by default on most Kubernetes clusters:
+
+ {{< text bash >}}
+ $ kubectl get crd gateways.gateway.networking.k8s.io &> /dev/null || \
+ { kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd/experimental?ref={{< k8s_gateway_api_version >}}" | kubectl apply -f -; }
+ {{< /text >}}
+
+ {{< tip >}}
+ {{< boilerplate gateway-api-future >}}
+ {{< boilerplate gateway-api-choose >}}
+ {{< /tip >}}
+
+2. Verify the installed components using the following commands:
+
+ {{< text bash >}}
+ $ code
+ {{< /text >}}
+
+## Deploying an Application
+
+Lets first deploy a sample application composed of four separate microservices used to demonstrate various L7 feature without making it part of the Istio ambient mesh. We can pick from the apps in the samples folder of the istio repository. Execute the following examples from the top of a local Istio repository or istio folder created by downloading the istioctl client as described in istio guides.
+
+{{< text bash >}}
+$ code for bookinfo
+{{< /text >}}
+
+## Deploying a Waypoint Proxy
+
+Let's see how you can Deploy a sample application bookinfo to use the Waypoint proxy
+
+**How to deploy a Waypoint proxy using istioctl**
+TODO
+
+**How to deploy a Waypoint proxy using Helm**
+TODO
+
+## Verify the waypoint proxy is deployed
+
+{{< text bash >}}
+$ code for verification
+{{< /text >}}
+
+This indicates the L7 waypoint proxy is working. In the next section we look at how to monitor the confuguration and data plane of the L7 waypoint proxy to confirm that traffic is correctly using the L7 waypoint proxy.
+
+### Verify that the Waypoint proxy is routing traffic to the application
+
+## Configuring the Waypoint Proxy
+
+How to create a Virtual Service
+
+How to configure a Virtual Service for L7 routing
+
+How to configure a Virtual Service for load balancing
+
+How to configure a Virtual Service for rate limiting
+
+How to configure a Virtual Service for fault injection
+
+### Overview
+
+This section describes how to configure the waypoint proxy for the Bookinfo application. The Bookinfo application is a sample application that requires a virtual service to route traffic to its different services.
+
+Link to add: https://istio.io/latest/docs/reference/config/networking/virtual-service/
+
+FOR EACH SECTION:
+
+### Creating a Virtual Service
+
+To create a virtual service for the Bookinfo application, you can use the following YAML manifest:
+
+{{< text bash >}}
+$ yaml file
+{{< /text >}}
+
+This virtual service will route all traffic to the `bookinfo-v1` service.
+
+### Deploying the Virtual Service
+
+To deploy the virtual service, you can use the following command:
+
+{{< text bash >}}
+$ command
+{{< /text >}}
+
+### Verifying the Waypoint Proxy Configuration is working
+
+Once the virtual service is deployed, you can verify the waypoint proxy configuration by running the following command:
+
+{{< text bash >}}
+$ command
+{{< /text >}}
+
+This will output the configuration of the waypoint proxy, including the virtual service that is mapped to it.
+
+### Configuring L4 and L7 Virtual Services
+
+You can configure both L4 and L7 virtual services for waypoint proxies. L4 virtual services are used to route traffic to services based on port number. L7 virtual services are used to route traffic to services based on more complex criteria, such as HTTP method and path.
+
+### Example L4 Virtual Service
+
+The following YAML manifest shows an example of an L4 virtual service:
+
+{{< text bash >}}
+$ YAML
+{{< /text >}}
+
+This virtual service will route 100% of traffic to the `bookinfo-v1` service and 50% of traffic to the `bookinfo-v2` service.
+
+### Example L7 Virtual Service
+
+The following YAML manifest shows an example of an L7 virtual service:
+
+{{< text bash >}}
+$ YAML
+{{< /text >}}
+
+This virtual service will route traffic to the `bookinfo-v1` service for requests to the `/productpage` path and traffic to the `bookinfo-v2` service for requests to the `/reviews` path.
+
+### Verifying the Virtual Service
+
+Once the virtual service is set up, the HTTP route is mapped to the waypoint configuration. This means that all traffic that matches the virtual service's hosts and HTTP routes will be routed to the waypoint proxy.
+
+You can verify this by using the `istioctl proxy-config` command to dump the waypoint configuration. This will show you the virtual services that are mapped to the waypoint proxy.
+
+For example, the following command would dump the configuration for the waypoint proxy named `bookinfo-waypoint`:
+
+{{< text bash >}}
+$ istioctl proxy-config bookinfo-waypoint
+{{< /text >}}
+
+The output of this command would include a list of the virtual services that are mapped to the waypoint proxy. For example:
+
+{{< text bash >}}
+$ virtual_services:
+ - name: bookinfo
+ routes:
+ - match:
+ uri:
+ prefix: /productpage
+ - match:
+ uri:
+ prefix: /reviews
+{{< /text >}}
+
+This output shows that the `bookinfo` virtual service is mapped to the `bookinfo-waypoint` waypoint proxy. All traffic that matches the `bookinfo` virtual service's hosts and HTTP routes will be routed to the `bookinfo-waypoint` waypoint proxy.
+
+By understanding how virtual services are mapped to waypoint proxies, you can configure your Istio mesh to route traffic in the way that you need.
+
+## Monitoring the L7 waypoint proxy
+
+This section describes how to monitor the L7 waypoint proxy for the Bookinfo application.
+
+### Viewing the Waypoint Proxy Status
+
+You can use the following command to view the waypoint proxy status:
+
+{{< text bash >}}
+$ command
+{{< /text >}}
+
+This will output the status of the waypoint proxy, including its readiness and liveness probes.
+
+### Viewing the Waypoint Proxy Configuration
+
+You can use the following command to monitor the waypoint proxy configuration:
+
+{{< text bash >}}
+$ command
+{{< /text >}}
+
+This will output the configuration of the waypoint proxy, including the virtual services that are mapped to it.
+
+### Monitoring the Virtual Service Mapping
+
+You can use the following command to monitor the virtual service mapping to the waypoint proxy:
+
+{{< text bash >}}
+$ command
+{{< /text >}}
+
+This will output the virtual services that are mapped to the waypoint proxy.
+
+### Checking the Waypoint Proxy Traffic
+
+You can use the following command to monitor the waypoint proxy traffic:
+
+{{< text bash >}}
+$ command
+{{< /text >}}
+
+This will output the pods in your cluster. You can then use the `istioctl __` command to get the traffic statistics for each pod.
+
+### Verifying L7 proxy load balancing
+
+
+### Monitoring the AB Deployment and Canary Deployment
+
+You can use the following command to monitor the AB Deployment and Canary Deployment traffic:
+
+{{< text bash >}}
+$ command
+{{< /text >}}
+
+This will output the traffic split configuration for the virtual service.
+
+### Conclusion
+
+This section has described how to monitor the L7 waypoint proxy for the Bookinfo application. For more information on waypoint proxies, please see the Istio documentation.
+
+### Additional Details on Monitoring the Virtual Service Mapping
+
+You can also use the following methods to monitor the virtual service mapping to the waypoint proxy:
+
+* **Use the Istio telemetry dashboards:** The Istio telemetry dashboards provide a graphical view of the traffic flowing through your Istio mesh. You can use these dashboards to monitor the traffic flowing to your waypoint proxies and to identify any problems with the virtual service mapping.
+* **Use Prometheus and Grafana:** You can use Prometheus and Grafana to collect and visualize metrics from your Istio mesh. You can use these tools to monitor the metrics associated with the waypoint proxy configuration and the virtual service mapping.
+
+**Monitoring the Waypoint Configuration for How Those Virtual Services Get Mapped to the Waypoint**
+
+You can use the following methods to monitor the waypoint configuration for how virtual services get mapped to the waypoint:
+
+* **Use the Istio telemetry dashboards:** The Istio telemetry dashboards provide a graphical view of the traffic flowing through your Istio mesh. You can use these dashboards to monitor the traffic flowing to your waypoint proxies and to identify any problems with the virtual service mapping.
+* **Use the Istio `istioctl` command:** You can use the Istio `istioctl` command to view the waypoint configuration. This configuration includes the virtual services that are mapped to the waypoint.
+* **Use Prometheus and Grafana:** You can use Prometheus and Grafana to collect and visualize metrics from your Istio mesh. You can use these tools to monitor the metrics associated with the waypoint proxy configuration and the virtual service mapping.
+
+By monitoring the waypoint proxy and the virtual service mapping, you can ensure that your Istio mesh is operating as expected.
+
+## L7 Authorization Policy
+TODO
+
+## Monitoring and Telemetry with L7 Waypoint Proxy
+TODO
+
+## How to use the Waypoint proxy for hairpinning
+TODO
+
+## Co-existence of Ambient/ L7 with Side car proxies
+How to use the Waypoint proxy with sidecar proxies
+TODO
+
+## Control Traffic towards L7 waypoint Proxy
+
+Deploy a waypoint proxy for the review service, using the `bookinfo-review` service account, so that any traffic going to the review service will be mediated by the waypoint proxy.
+
+{{< text bash >}}
+$ istioctl x waypoint apply --service-account bookinfo-reviews
+waypoint default/bookinfo-reviews applied
+{{< /text >}}
+
+Configure traffic routing to send 90% of requests to `reviews` v1 and 10% to `reviews` v2:
+
+{{< tabset category-name="config-api" >}}
+
+{{< tab name="Istio APIs" category-value="istio-apis" >}}
+
+{{< text bash >}}
+$ kubectl apply -f @samples/bookinfo/networking/virtual-service-reviews-90-10.yaml@
+$ kubectl apply -f @samples/bookinfo/networking/destination-rule-reviews.yaml@
+{{< /text >}}
+
+{{< /tab >}}
+
+{{< tab name="Gateway API" category-value="gateway-api" >}}
+
+{{< text bash >}}
+$ kubectl apply -f @samples/bookinfo/platform/kube/bookinfo-versions.yaml@
+$ kubectl apply -f @samples/bookinfo/gateway-api/route-reviews-90-10.yaml@
+{{< /text >}}
+
+{{< /tab >}}
+
+{{< /tabset >}}
+
+Confirm that roughly 10% of the traffic from 100 requests goes to reviews-v2:
+
+{{< text bash >}}
+$ kubectl exec deploy/sleep -- sh -c "for i in \$(seq 1 100); do curl -s http://$GATEWAY_HOST/productpage | grep reviews-v.-; done"
+{{< /text >}}
+
+## Configuring AB Deployment and Canary Deployment
+
+To send traffic to an AB deployment for the sidecar model using a waypoint proxy, you can follow these steps:
+
+TODO
+
+Once you have completed these steps, traffic will be routed to the two versions of your application according to the traffic splitting configuration.
+
+Here is a concrete example of how to send traffic to an AB deployment for the sidecar model using a waypoint proxy for the Bookinfo application:
+
+{{< text bash >}}
+$ YAML file
+{{< /text >}}
+
+Once you have deployed these resources, traffic will be routed to the `bookinfo-v1` and `bookinfo-v2` versions of the Bookinfo application according to the traffic splitting configuration. You can adjust the weight of each route to control how much traffic is routed to each version of the application.
+
+By using waypoint proxies and traffic splitting, you can implement AB deployments for sidecar models in Istio. This allows you to gradually roll out new versions of your application to users and to monitor the performance of the new version before rolling it out to all users.
+
+You can use Istio's AB Deployment and Canary Deployment features to deploy and manage multiple versions of your application at the same time. To do this, you would create a virtual service for each version of your application. Then, you would use Istio's traffic splitting features to route traffic to the different versions of your application.
+
+For more information on AB Deployment and Canary Deployment, please see the Istio documentation.
+
+### Traffic splitting with Canary development
+TODO
+
+**Conclusion**
+
+This section has described how to configure the waypoint proxy for the Bookinfo application. For more information on waypoint proxies, please see the Istio documentation.
+
+
+## Remove L7 waypoint proxy layer
+
+To remove the `productpage-viewer` authorization policy, waypoint proxies and uninstall Istio:
+
+{{< text bash >}}
+$ kubectl delete authorizationpolicy productpage-viewer
+$ istioctl x waypoint delete --service-account bookinfo-reviews
+$ istioctl x waypoint delete --service-account bookinfo-productpage
+$ istioctl uninstall -y --purge
+$ kubectl delete namespace istio-system
+{{< /text >}}
+
+The label to instruct Istio to automatically include applications in the `default` namespace to ambient mesh is not removed by default. If no longer needed, use the following command to remove it:
+
+{{< text bash >}}
+$ kubectl label namespace default istio.io/dataplane-mode-
+{{< /text >}}
+
+To delete the Bookinfo sample application and its configuration, see [`Bookinfo` cleanup](/docs/examples/bookinfo/#cleanup).
+
+To remove the `sleep` and `notsleep` applications:
+
+{{< text bash >}}
+$ kubectl delete -f @samples/sleep/sleep.yaml@
+$ kubectl delete -f @samples/sleep/notsleep.yaml@
+{{< /text >}}
+
+If you installed the Gateway API CRDs for L7 waypoint proxy, remove them:
+
+{{< text bash >}}
+$ kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd/experimental?ref={{< k8s_gateway_api_version >}}" | kubectl delete -f -
+{{< /text >}}
+
+
+## Troubleshooting
\ No newline at end of file
From 7fcdfa3f707425dbcf677ce47c17fe356f5fd060 Mon Sep 17 00:00:00 2001
From: fykaa <97490463+fykaa@users.noreply.github.com>
Date: Fri, 29 Sep 2023 22:56:48 +0530
Subject: [PATCH 02/19] Initial skeleton of L7 Waypoint Proxy
---
.../docs/ops/ambient/usage/waypoint/index.md | 50 ++++++-------------
1 file changed, 15 insertions(+), 35 deletions(-)
diff --git a/content/en/docs/ops/ambient/usage/waypoint/index.md b/content/en/docs/ops/ambient/usage/waypoint/index.md
index 10da22d54198..8e910a6e5ba9 100644
--- a/content/en/docs/ops/ambient/usage/waypoint/index.md
+++ b/content/en/docs/ops/ambient/usage/waypoint/index.md
@@ -7,7 +7,7 @@ test: n/a
---
{{}}
-Before you start with this guide, please make sure that you have already read the Ztunnel Networking sub-guide and have a basic understanding of Istio Ambient Mesh. This guide assumes that you have already completed the Installation, set up the ztunnel and enabled mtls.
+Before you start with this guide, please make sure that you have already read the Ztunnel Networking sub-guide and have a basic understanding of Istio Ambient Mesh. This guide assumes that you have already completed the Installation, set up the ztunnel and enabled mTLS.
If you have not yet done these things, please go back to the Ztunnel Networking sub-guide and follow the instructions before proceeding with this guide.
@@ -35,7 +35,7 @@ TODO
Before you begin, make sure that you have the following prerequisites in place:
1. Istio Ambient Mesh installed and configured
2. Ztunnel proxy is installed and running
-3. Mutual TLS (mtls) enabled and configured
+3. Mutual TLS (mTLS) enabled and configured
## Understanding the L7 Waypoint Proxy Default Configuration
@@ -49,10 +49,6 @@ In the future, there may be some additional limited configurability for L7 Waypo
* Networking between L7 Waypoint Proxies
* Networking between L7 Waypoint Proxies and sidecar proxies
-In particular, the only option for pod to L7 Waypoint Proxy networking setup is currently via the `istio-cni` and only via an internal ipTables based L7 Waypoint Proxy traffic redirect option. There is no option to use `init-containers` unlike with sidecar proxies. Alternate forms of L7 Waypoint Proxy traffic redirect such as eBPF are also not currently supported, although may be supported in future.
-
-Of course, once the baseline L7 Waypoint Proxy layer is installed, features such as Authorization Policy (both L4 and L7) as well as other Istio functions such as PeerAuthentication options for mutual-TLS are fully configurable similar to standard Istio. In future release versions, some limited configurability may also be added to the L7 Waypoint Proxy layer.
-
#### Additional Notes
* The L7 Waypoint Proxy layer can coexist with sidecar proxies in the same cluster. This allows you to use the L7 Waypoint Proxy for services that require L7 functionality and sidecar proxies for services that do not.
@@ -67,9 +63,9 @@ A figure showing an architecture summary of the L7 waypoint proxy.
TODO
-## Install Gateway CRDs
+## Install Waypoint Proxy
-**Before Deploying the Waypoint proxy: Install Gateway CRDs**
+**Install Gateway CRDs**
In L7 networking, a waypoint proxy is a lightweight Envoy proxy that runs on each node in the cluster. It is used to implement L7 functionality in Istio Ambient Mesh.
@@ -121,23 +117,13 @@ This indicates the L7 waypoint proxy is working. In the next section we look at
### Verify that the Waypoint proxy is routing traffic to the application
-## Configuring the Waypoint Proxy
-
-How to create a Virtual Service
-
-How to configure a Virtual Service for L7 routing
-
-How to configure a Virtual Service for load balancing
-
-How to configure a Virtual Service for rate limiting
-
-How to configure a Virtual Service for fault injection
+## Configuring the Waypoint Proxy -
### Overview
This section describes how to configure the waypoint proxy for the Bookinfo application. The Bookinfo application is a sample application that requires a virtual service to route traffic to its different services.
-Link to add: https://istio.io/latest/docs/reference/config/networking/virtual-service/
+The core functionality of the waypoint L7 traffic management is identical to sidecar mode, hence to add more features refer to this link: https://istio.io/latest/docs/reference/config/networking/virtual-service/
FOR EACH SECTION:
@@ -169,26 +155,18 @@ $ command
This will output the configuration of the waypoint proxy, including the virtual service that is mapped to it.
-### Configuring L4 and L7 Virtual Services
+### Configuring Virtual Services
-You can configure both L4 and L7 virtual services for waypoint proxies. L4 virtual services are used to route traffic to services based on port number. L7 virtual services are used to route traffic to services based on more complex criteria, such as HTTP method and path.
+You can configure both L4 and L7 virtual services for waypoint proxies. If you want to do a Virtual Service with TCP that is effectively a L4 virtual services. This is used to route traffic to services based on port number. L7 virtual services are used to route traffic to services based on more complex criteria, such as HTTP method and path. In a Virtual service you can have only TCP, or only HTTP or Both.
-### Example L4 Virtual Service
+<< Considered merging L4 (TCP) and L7 (HTTP) virtual service >>
-The following YAML manifest shows an example of an L4 virtual service:
-
-{{< text bash >}}
-$ YAML
-{{< /text >}}
-
-This virtual service will route 100% of traffic to the `bookinfo-v1` service and 50% of traffic to the `bookinfo-v2` service.
-
-### Example L7 Virtual Service
+### Example
The following YAML manifest shows an example of an L7 virtual service:
{{< text bash >}}
-$ YAML
+$ yaml file
{{< /text >}}
This virtual service will route traffic to the `bookinfo-v1` service for requests to the `/productpage` path and traffic to the `bookinfo-v2` service for requests to the `/reviews` path.
@@ -202,7 +180,7 @@ You can verify this by using the `istioctl proxy-config` command to dump the way
For example, the following command would dump the configuration for the waypoint proxy named `bookinfo-waypoint`:
{{< text bash >}}
-$ istioctl proxy-config bookinfo-waypoint
+$ command
{{< /text >}}
The output of this command would include a list of the virtual services that are mapped to the waypoint proxy. For example:
@@ -223,6 +201,7 @@ This output shows that the `bookinfo` virtual service is mapped to the `bookinfo
By understanding how virtual services are mapped to waypoint proxies, you can configure your Istio mesh to route traffic in the way that you need.
+
## Monitoring the L7 waypoint proxy
This section describes how to monitor the L7 waypoint proxy for the Bookinfo application.
@@ -417,4 +396,5 @@ $ kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd/experimen
{{< /text >}}
-## Troubleshooting
\ No newline at end of file
+## Troubleshooting
+TODO
\ No newline at end of file
From 99750d36e477da9f509521850af933b3b5c49da2 Mon Sep 17 00:00:00 2001
From: fykaa <97490463+fykaa@users.noreply.github.com>
Date: Tue, 10 Oct 2023 02:52:24 +0530
Subject: [PATCH 03/19] reviews updated v1.0
---
.../ops/ambient/usage/{index.md => _index.md} | 0
.../docs/ops/ambient/usage/waypoint/index.md | 110 ++++++++++--------
2 files changed, 59 insertions(+), 51 deletions(-)
rename content/en/docs/ops/ambient/usage/{index.md => _index.md} (100%)
diff --git a/content/en/docs/ops/ambient/usage/index.md b/content/en/docs/ops/ambient/usage/_index.md
similarity index 100%
rename from content/en/docs/ops/ambient/usage/index.md
rename to content/en/docs/ops/ambient/usage/_index.md
diff --git a/content/en/docs/ops/ambient/usage/waypoint/index.md b/content/en/docs/ops/ambient/usage/waypoint/index.md
index 8e910a6e5ba9..bef21f2a8a3a 100644
--- a/content/en/docs/ops/ambient/usage/waypoint/index.md
+++ b/content/en/docs/ops/ambient/usage/waypoint/index.md
@@ -1,26 +1,26 @@
---
-title: L7 - waypoint proxy Layer
+title: Waypoint proxy Layer
description: User guide for L7 Processing.
weight: 2
owner: istio/wg-networking-maintainers
test: n/a
---
-{{}}
+
## Introduction
-This guide provides instructions on how to set up and use the L7 Waypoint Proxy layer in Istio Ambient Mesh. It assumes that you have already read the Ztunnel Networking sub-guide and have a basic understanding of Istio Ambient Mesh.
+This guide provides instructions on how to set up and use Waypoint proxy layer in Istio Ambient Mesh.
-L7 traffic routing is based on L4 with the addition of the Waypoint proxy, which is more complex to handle in Envoy. We can also create HPAs to scale it dynamically.
+L7 traffic routing is handled via the Waypoint proxy. The waypoint proxy is currently based on Envoy. The waypoint proxy can be deployed to scale dynamically using HPAs.
**Overview of the Layer 7 Waypoint proxy**
@@ -32,34 +32,42 @@ TODO
## Pre-requisites & Supported Topologies
+This guide assumes that you have already completed the [Ztunnel Networking sub-guide](../ztunnel/).
+
Before you begin, make sure that you have the following prerequisites in place:
1. Istio Ambient Mesh installed and configured
2. Ztunnel proxy is installed and running
3. Mutual TLS (mTLS) enabled and configured
-## Understanding the L7 Waypoint Proxy Default Configuration
-<< Consider breaking this out into bullets for easier reading TODO >>
+
+
+## Deciding if you need A Waypoint proxy
+TODO
+
+## Deciding the scope of your Waypoint proxy
+TODO
-* Networking between pods and L7 Waypoint Proxies
-* Networking between L7 Waypoint Proxies
-* Networking between L7 Waypoint Proxies and sidecar proxies
#### Additional Notes
-* The L7 Waypoint Proxy layer can coexist with sidecar proxies in the same cluster. This allows you to use the L7 Waypoint Proxy for services that require L7 functionality and sidecar proxies for services that do not.
-* The L7 Waypoint Proxy is implemented using Envoy. This means that you can use all of the features of Envoy in your L7 Waypoint Proxies.
-* The L7 Waypoint Proxy is still under development, but it is already a powerful tool for managing L7 traffic in Istio Ambient Mesh.
+* The Waypoint Proxy layer can coexist with sidecar proxies in the same cluster. This allows you to use Waypoint proxy for services that require L7 functionality and sidecar proxies for services that do not.
+* Waypoint proxy is implemented using Envoy. This means that you can use all of the features of Envoy in your Waypoint Proxies.
+* Waypoint proxy is still under development, but it is already a powerful tool for managing L7 traffic in Istio Ambient Mesh.
-For the examples in this guide, we used a deployment of Istio Ambient on a `kind` cluster, although these should apply for any Kubernetes cluster version 1.18.0 or later. Refer to the Getting started guide on how to download the `istioctl` client and how to deploy a `kind` cluster. It would be recommended to have a cluster with more than 1 worker node in order to fully exercise the examples described in this guide.
+For the examples in this guide, we used a deployment of Istio Ambient on a `kinD` cluster, although these should apply for any Kubernetes cluster version 1.18.0 or later. Refer to the Getting started guide on how to download the `istioctl` client and how to deploy a `kinD` cluster. It would be recommended to have a cluster with more than 1 worker node in order to fully exercise the examples described in this guide.
## Functional Overview
-A figure showing an architecture summary of the L7 waypoint proxy.
+A figure showing an architecture summary of Waypoint proxy.
TODO
@@ -67,11 +75,11 @@ TODO
**Install Gateway CRDs**
-In L7 networking, a waypoint proxy is a lightweight Envoy proxy that runs on each node in the cluster. It is used to implement L7 functionality in Istio Ambient Mesh.
+In L7 networking, a waypoint proxy is a lightweight Envoy proxy that can be configured for your entire namespace or for a service account. It is used to implement L7 functionality in Istio Ambient Mesh.
-Waypoint proxies are dependent on Gateway API CRDs to provide features such as traffic routing and service discovery.
+The reference implementation of a waypoint proxy is managed by the Kubernetes Gateway API `istio-waypoint` GatewayClass.
-1. Install Kubernetes Gateway CRDs, which don’t come installed by default on most Kubernetes clusters:
+1. Install Kubernetes Gateway API CRDs, which don’t come installed by default on most Kubernetes clusters:
{{< text bash >}}
$ kubectl get crd gateways.gateway.networking.k8s.io &> /dev/null || \
@@ -99,7 +107,7 @@ $ code for bookinfo
## Deploying a Waypoint Proxy
-Let's see how you can Deploy a sample application bookinfo to use the Waypoint proxy
+Let's see how you can Deploy a sample application bookinfo to use Waypoint proxy
**How to deploy a Waypoint proxy using istioctl**
TODO
@@ -107,21 +115,21 @@ TODO
**How to deploy a Waypoint proxy using Helm**
TODO
-## Verify the waypoint proxy is deployed
+## Verify Waypoint proxy is deployed
{{< text bash >}}
$ code for verification
{{< /text >}}
-This indicates the L7 waypoint proxy is working. In the next section we look at how to monitor the confuguration and data plane of the L7 waypoint proxy to confirm that traffic is correctly using the L7 waypoint proxy.
+This indicates Waypoint proxy is working. In the next section we look at how to monitor the confuguration and data plane of Waypoint proxy to confirm that traffic is correctly using Waypoint proxy.
-### Verify that the Waypoint proxy is routing traffic to the application
+### Verify that Waypoint proxy is routing traffic to the application
-## Configuring the Waypoint Proxy -
+## Configuring Waypoint proxy -
### Overview
-This section describes how to configure the waypoint proxy for the Bookinfo application. The Bookinfo application is a sample application that requires a virtual service to route traffic to its different services.
+This section describes how to configure Waypoint proxy for the Bookinfo application. The Bookinfo application is a sample application that requires a virtual service to route traffic to its different services.
The core functionality of the waypoint L7 traffic management is identical to sidecar mode, hence to add more features refer to this link: https://istio.io/latest/docs/reference/config/networking/virtual-service/
@@ -145,15 +153,15 @@ To deploy the virtual service, you can use the following command:
$ command
{{< /text >}}
-### Verifying the Waypoint Proxy Configuration is working
+### Verifying Waypoint proxy Configuration is working
-Once the virtual service is deployed, you can verify the waypoint proxy configuration by running the following command:
+Once the virtual service is deployed, you can verify Waypoint proxy configuration by running the following command:
{{< text bash >}}
$ command
{{< /text >}}
-This will output the configuration of the waypoint proxy, including the virtual service that is mapped to it.
+This will output the configuration of Waypoint proxy, including the virtual service that is mapped to it.
### Configuring Virtual Services
@@ -175,7 +183,7 @@ This virtual service will route traffic to the `bookinfo-v1` service for request
Once the virtual service is set up, the HTTP route is mapped to the waypoint configuration. This means that all traffic that matches the virtual service's hosts and HTTP routes will be routed to the waypoint proxy.
-You can verify this by using the `istioctl proxy-config` command to dump the waypoint configuration. This will show you the virtual services that are mapped to the waypoint proxy.
+In classic mode you can use `istioctl proxy-config cmds` to dump the envoy configuration. While `istioctl proxy-config cmds` will still work in ambient there are some differences because the envoy proxy is no longer configured for every sidecar.
For example, the following command would dump the configuration for the waypoint proxy named `bookinfo-waypoint`:
@@ -202,13 +210,13 @@ This output shows that the `bookinfo` virtual service is mapped to the `bookinfo
By understanding how virtual services are mapped to waypoint proxies, you can configure your Istio mesh to route traffic in the way that you need.
-## Monitoring the L7 waypoint proxy
+## Monitoring Waypoint proxy
-This section describes how to monitor the L7 waypoint proxy for the Bookinfo application.
+This section describes how to monitor Waypoint proxy for the Bookinfo application.
-### Viewing the Waypoint Proxy Status
+### Viewing Waypoint proxy Status
-You can use the following command to view the waypoint proxy status:
+You can use the following command to view Waypoint proxy status:
{{< text bash >}}
$ command
@@ -216,7 +224,7 @@ $ command
This will output the status of the waypoint proxy, including its readiness and liveness probes.
-### Viewing the Waypoint Proxy Configuration
+### Viewing Waypoint proxy Configuration
You can use the following command to monitor the waypoint proxy configuration:
@@ -224,19 +232,19 @@ You can use the following command to monitor the waypoint proxy configuration:
$ command
{{< /text >}}
-This will output the configuration of the waypoint proxy, including the virtual services that are mapped to it.
+This will output the configuration of Waypoint proxy, including the virtual services that are mapped to it.
### Monitoring the Virtual Service Mapping
-You can use the following command to monitor the virtual service mapping to the waypoint proxy:
+You can use the following command to monitor the virtual service mapping to Waypoint proxy:
{{< text bash >}}
$ command
{{< /text >}}
-This will output the virtual services that are mapped to the waypoint proxy.
+This will output the virtual services that are mapped to Waypoint proxy.
-### Checking the Waypoint Proxy Traffic
+### Checking Waypoint proxy Traffic
You can use the following command to monitor the waypoint proxy traffic:
@@ -261,7 +269,7 @@ This will output the traffic split configuration for the virtual service.
### Conclusion
-This section has described how to monitor the L7 waypoint proxy for the Bookinfo application. For more information on waypoint proxies, please see the Istio documentation.
+This section has described how to monitor the Waypoint proxy for the Bookinfo application. For more information on waypoint proxies, please see the Istio documentation.
### Additional Details on Monitoring the Virtual Service Mapping
@@ -283,19 +291,19 @@ By monitoring the waypoint proxy and the virtual service mapping, you can ensure
## L7 Authorization Policy
TODO
-## Monitoring and Telemetry with L7 Waypoint Proxy
+## Monitoring and Telemetry with Waypoint Proxy
TODO
-## How to use the Waypoint proxy for hairpinning
+## How to use Waypoint proxy for hairpinning
TODO
-## Co-existence of Ambient/ L7 with Side car proxies
-How to use the Waypoint proxy with sidecar proxies
-TODO
+% ## Co-existence of Ambient/ L7 with Side car proxies
+% How to use the Waypoint proxy with sidecar proxies
+% TODO
-## Control Traffic towards L7 waypoint Proxy
+## Control Traffic towards Waypoint Proxy
-Deploy a waypoint proxy for the review service, using the `bookinfo-review` service account, so that any traffic going to the review service will be mediated by the waypoint proxy.
+Deploy a waypoint proxy for the review service, using the `bookinfo-review` service account, so that any traffic going to the review service will be mediated by Waypoint proxy.
{{< text bash >}}
$ istioctl x waypoint apply --service-account bookinfo-reviews
@@ -359,10 +367,10 @@ TODO
**Conclusion**
-This section has described how to configure the waypoint proxy for the Bookinfo application. For more information on waypoint proxies, please see the Istio documentation.
+This section has described how to configure Waypoint proxy for the Bookinfo application. For more information on waypoint proxies, please see the Istio documentation.
-## Remove L7 waypoint proxy layer
+## Remove Waypoint proxy layer
To remove the `productpage-viewer` authorization policy, waypoint proxies and uninstall Istio:
@@ -389,7 +397,7 @@ $ kubectl delete -f @samples/sleep/sleep.yaml@
$ kubectl delete -f @samples/sleep/notsleep.yaml@
{{< /text >}}
-If you installed the Gateway API CRDs for L7 waypoint proxy, remove them:
+If you installed the Gateway API CRDs for Waypoint proxy, remove them:
{{< text bash >}}
$ kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd/experimental?ref={{< k8s_gateway_api_version >}}" | kubectl delete -f -
From 60cd1563ad1c58ce03f45d407c6885e143da3b15 Mon Sep 17 00:00:00 2001
From: fykaa
Date: Tue, 31 Oct 2023 23:53:06 +0530
Subject: [PATCH 04/19] added initial intro
---
.../docs/ops/ambient/usage/waypoint/index.md | 259 ++++++++++--------
1 file changed, 152 insertions(+), 107 deletions(-)
diff --git a/content/en/docs/ops/ambient/usage/waypoint/index.md b/content/en/docs/ops/ambient/usage/waypoint/index.md
index bef21f2a8a3a..6c3218f8f4cf 100644
--- a/content/en/docs/ops/ambient/usage/waypoint/index.md
+++ b/content/en/docs/ops/ambient/usage/waypoint/index.md
@@ -1,101 +1,122 @@
---
-title: Waypoint proxy Layer
-description: User guide for L7 Processing.
+title: L7 Networking & Services with Waypoint
+description: User guide for Istio Ambient L7 networking and services using waypoint proxy.
weight: 2
owner: istio/wg-networking-maintainers
-test: n/a
+test: no
---
-
+
+Before you begin, make sure that you have already read the [Ztunnel Networking sub-guide](../ztunnel/). This guide assumes that you have the following prerequisites in place:
+1. Istio Ambient Mesh installed and configured
+2. Ztunnel proxy is installed and running
+3. Mutual TLS (mTLS) enabled and configured
-## Introduction
+{{}}
-This guide provides instructions on how to set up and use Waypoint proxy layer in Istio Ambient Mesh.
+
-L7 traffic routing is handled via the Waypoint proxy. The waypoint proxy is currently based on Envoy. The waypoint proxy can be deployed to scale dynamically using HPAs.
+## Introduction
-**Overview of the Layer 7 Waypoint proxy**
+This guide provides instructions on how to set up and use the Waypoint proxy layer in Istio Ambient Mesh.
-TODO
+Istio Ambient Mesh is a new way to deploy and manage microservices. In Ambient Mesh, workloads are no longer required to run sidecar proxies to participate in the service mesh. Ambient splits Istio’s functionality into two distinct layers, a secure overlay layer and a Layer 7 processing layer.
-**Benefits of using the Layer 7 Waypoint proxy**
+Ztunnel proxy is used to handle L3 and L4 networking functions, such as mTLS authentication and L4 authorization. For workloads that require L7 networking features, such as HTTP load balancing and fault injection, a waypoint proxy can be deployed. The waypoint proxy is an optional component that is Envoy-based and is responsible for terminating workload HTTP traffic and parsing workload HTTP headers. They also enforce L7 policies and collect L7 metrics.
-TODO
+This guide describes the functionality and usage of the waypoint proxy and L7 networking functions using Istio Ambient Mesh. We use a sample user journey to describe these functions hence it would be useful to go through this guide in sequence. However we provide links to the sections below in case the reader would like to jump to the appropriate section.
-## Pre-requisites & Supported Topologies
+* [Introduction](#introduction)
+* [Deciding if you need A Waypoint proxy](#deciding-if-you-need-a-waypoint-proxy)
+* [Current Challenges](#current-challenges)
+* [Differences between Sidecar Mode and Ambient Mode for Waypoint Proxy](#differences)
+* [Deciding the scope of your Waypoint proxy](#differences-between-sidecar-mode-and-ambient-mode-for-waypoint-proxy)
+* [Functional Overview](#functional-overview)
+* [Deploying an Application](#deploying-an-application)
+* [Configuring Waypoint proxy](#configuring-waypoint-proxy)
+* [Monitoring the Waypoint Proxy & L7 Networking](#monitoring-the-waypoint-proxy--l7-networking)
+* [L7 Fault Injection](#l7-fault-injection)
+* [L7 Observability](#l7-observability)
+* [L7 Authorization Policy](#l7-authorization-policy)
+* [Control Traffic towards Waypoint Proxy](##control-traffic-towards-waypoint-proxy)
+* [Remove Waypoint proxy layer](#remove-waypoint-proxy-layer)
-This guide assumes that you have already completed the [Ztunnel Networking sub-guide](../ztunnel/).
+## Deciding if you need A Waypoint proxy
-Before you begin, make sure that you have the following prerequisites in place:
-1. Istio Ambient Mesh installed and configured
-2. Ztunnel proxy is installed and running
-3. Mutual TLS (mTLS) enabled and configured
+<>
+### Benefits of using the waypoint proxy and L7 networking features
-
+You should consider using the waypoint proxy and L7 networking features if your microservices architecture requires any of the following:
-## Deciding if you need A Waypoint proxy
-TODO
+1. L7 load balancing and routing: You need to distribute traffic across multiple instances of a workload based on factors such as request path, header values, or cookies.
+2. Waypoint provides a variety of L7 load balancing and routing algorithms, including round robin, weighted round robin, and least connections. It also supports path-based routing and other advanced routing rules.
+3. L7 fault injection: You need to simulate faults in your microservices architecture such as delays, errors, and circuit breaks to test its resilience and prepare for real-world failures.
+4. Rate limiting: You need to protect workloads against denial-of-service attacks and improve performance.
+5. L7 observability: You need to collect metrics and traces from your microservices architecture to monitor its performance and troubleshoot problems.
-## Deciding the scope of your Waypoint proxy
-TODO
+### Getting started with the waypoint proxy and L7 networking features
+To get started with the waypoint proxy and L7 networking features, you will need to deploy a waypoint proxy for each workload that requires L7 networking. You can do this using the Kubernetes Gateway resource. Once the waypoint proxy is deployed, you can configure L7 policies using the VirtualService, DestinationRule, and ServiceEntry resources.
-#### Additional Notes
+This guide will provide more detailed instructions on how to deploy and configure the waypoint proxy and L7 networking features.
-* The Waypoint Proxy layer can coexist with sidecar proxies in the same cluster. This allows you to use Waypoint proxy for services that require L7 functionality and sidecar proxies for services that do not.
-* Waypoint proxy is implemented using Envoy. This means that you can use all of the features of Envoy in your Waypoint Proxies.
-* Waypoint proxy is still under development, but it is already a powerful tool for managing L7 traffic in Istio Ambient Mesh.
+## Current Challenges
-For the examples in this guide, we used a deployment of Istio Ambient on a `kinD` cluster, although these should apply for any Kubernetes cluster version 1.18.0 or later. Refer to the Getting started guide on how to download the `istioctl` client and how to deploy a `kinD` cluster. It would be recommended to have a cluster with more than 1 worker node in order to fully exercise the examples described in this guide.
+<>
-## Functional Overview
+### Environment used for this guide
-A figure showing an architecture summary of Waypoint proxy.
+For the examples in this guide, we used a deployment of Istio version `1.19.0`` on a `kinD` cluster of version `0.20.0 running Kubernetes version `1.27.3`. However these should also work on any Kubernetes cluster at version `1.24.0` or later and Istio version `1.18.0` or later. It would be recommended to have a cluster with more than 1 worker node in order to fully exercise the examples described in this guide. Refer to the installation user guide or Getting started guide information on installing Istio in ambient mode on a Kubernetes cluster.
-TODO
+## Differences between Sidecar Mode and Ambient Mode for Waypoint Proxy
-## Install Waypoint Proxy
+## Deciding the scope of your Waypoint proxy
-**Install Gateway CRDs**
+
-In L7 networking, a waypoint proxy is a lightweight Envoy proxy that can be configured for your entire namespace or for a service account. It is used to implement L7 functionality in Istio Ambient Mesh.
+<< per workload level or Namespace or service account >>
-The reference implementation of a waypoint proxy is managed by the Kubernetes Gateway API `istio-waypoint` GatewayClass.
+In ambient, all policies are enforced by the destination waypoint. In many ways, the waypoint acts as a gateway into the namespace (default scope) or service account. Istio enforces that all traffic coming into the namespace goes through the waypoint, which then enforces all policies for that namespace. Because of this, each waypoint only needs to know about configuration for its own namespace
-1. Install Kubernetes Gateway API CRDs, which don’t come installed by default on most Kubernetes clusters:
- {{< text bash >}}
- $ kubectl get crd gateways.gateway.networking.k8s.io &> /dev/null || \
- { kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd/experimental?ref={{< k8s_gateway_api_version >}}" | kubectl apply -f -; }
- {{< /text >}}
+#### Additional Notes
- {{< tip >}}
- {{< boilerplate gateway-api-future >}}
- {{< boilerplate gateway-api-choose >}}
- {{< /tip >}}
+* The Waypoint Proxy layer can coexist with sidecar proxies in the same cluster. This allows you to use Waypoint proxy for services that require L7 functionality and sidecar proxies for services that do not.
+* Waypoint proxy is implemented using Envoy. This means that you can use all of the features of Envoy in your Waypoint Proxies.
+* Waypoint proxy is still under development, but it is already a powerful tool for managing L7 traffic in Istio Ambient Mesh.
-2. Verify the installed components using the following commands:
+For the examples in this guide, we used a deployment of Istio Ambient on a `kinD` cluster, although these should apply for any Kubernetes cluster version 1.18.0 or later. Refer to the Getting started guide on how to download the `istioctl` client and how to deploy a `kinD` cluster. It would be recommended to have a cluster with more than 1 worker node in order to fully exercise the examples described in this guide.
- {{< text bash >}}
- $ code
- {{< /text >}}
+## Functional Overview
+
+<>
+
+<>
## Deploying an Application
@@ -105,7 +126,7 @@ Lets first deploy a sample application composed of four separate microservices u
$ code for bookinfo
{{< /text >}}
-## Deploying a Waypoint Proxy
+### Deploying a Waypoint Proxy
Let's see how you can Deploy a sample application bookinfo to use Waypoint proxy
@@ -115,7 +136,7 @@ TODO
**How to deploy a Waypoint proxy using Helm**
TODO
-## Verify Waypoint proxy is deployed
+### Verify Waypoint proxy is deployed
{{< text bash >}}
$ code for verification
@@ -123,12 +144,36 @@ $ code for verification
This indicates Waypoint proxy is working. In the next section we look at how to monitor the confuguration and data plane of Waypoint proxy to confirm that traffic is correctly using Waypoint proxy.
+### Install Waypoint Proxy
+
+**Install Gateway CRDs**
+
+In L7 networking, a waypoint proxy is a lightweight Envoy proxy that can be configured for your entire namespace or for a service account. It is used to implement L7 functionality in Istio Ambient Mesh.
+
+The reference implementation of a waypoint proxy is managed by the Kubernetes Gateway API `istio-waypoint` GatewayClass.
+
+1. Install Kubernetes Gateway API CRDs, which don’t come installed by default on most Kubernetes clusters:
+
+ {{< text bash >}}
+ $ kubectl get crd gateways.gateway.networking.k8s.io &> /dev/null || \
+ { kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd/experimental?ref={{< k8s_gateway_api_version >}}" | kubectl apply -f -; }
+ {{< /text >}}
+
+ {{< tip >}}
+ {{< boilerplate gateway-api-future >}}
+ {{< boilerplate gateway-api-choose >}}
+ {{< /tip >}}
+
+2. Verify the installed components using the following commands:
+
+ {{< text bash >}}
+ $ code
+ {{< /text >}}
+
### Verify that Waypoint proxy is routing traffic to the application
## Configuring Waypoint proxy -
-### Overview
-
This section describes how to configure Waypoint proxy for the Bookinfo application. The Bookinfo application is a sample application that requires a virtual service to route traffic to its different services.
The core functionality of the waypoint L7 traffic management is identical to sidecar mode, hence to add more features refer to this link: https://istio.io/latest/docs/reference/config/networking/virtual-service/
@@ -153,6 +198,41 @@ To deploy the virtual service, you can use the following command:
$ command
{{< /text >}}
+### L7 Load Balancing
+
+<>
+
+### Configuring AB Deployment and Canary Deployment
+
+<>
+
+To send traffic to an AB deployment for the sidecar model using a waypoint proxy, you can follow these steps:
+
+TODO
+
+Once you have completed these steps, traffic will be routed to the two versions of your application according to the traffic splitting configuration.
+
+Here is a concrete example of how to send traffic to an AB deployment for the sidecar model using a waypoint proxy for the Bookinfo application:
+
+{{< text bash >}}
+$ YAML file
+{{< /text >}}
+
+Once you have deployed these resources, traffic will be routed to the `bookinfo-v1` and `bookinfo-v2` versions of the Bookinfo application according to the traffic splitting configuration. You can adjust the weight of each route to control how much traffic is routed to each version of the application.
+
+By using waypoint proxies and traffic splitting, you can implement AB deployments for sidecar models in Istio. This allows you to gradually roll out new versions of your application to users and to monitor the performance of the new version before rolling it out to all users.
+
+You can use Istio's AB Deployment and Canary Deployment features to deploy and manage multiple versions of your application at the same time. To do this, you would create a virtual service for each version of your application. Then, you would use Istio's traffic splitting features to route traffic to the different versions of your application.
+
+For more information on AB Deployment and Canary Deployment, please see the Istio documentation.
+
+### Traffic splitting with Canary development
+TODO
+
+**Conclusion**
+
+This section has described how to configure Waypoint proxy for the Bookinfo application. For more information on waypoint proxies, please see the Istio documentation.
+
### Verifying Waypoint proxy Configuration is working
Once the virtual service is deployed, you can verify Waypoint proxy configuration by running the following command:
@@ -167,7 +247,7 @@ This will output the configuration of Waypoint proxy, including the virtual serv
You can configure both L4 and L7 virtual services for waypoint proxies. If you want to do a Virtual Service with TCP that is effectively a L4 virtual services. This is used to route traffic to services based on port number. L7 virtual services are used to route traffic to services based on more complex criteria, such as HTTP method and path. In a Virtual service you can have only TCP, or only HTTP or Both.
-<< Considered merging L4 (TCP) and L7 (HTTP) virtual service >>
+<>
### Example
@@ -179,7 +259,7 @@ $ yaml file
This virtual service will route traffic to the `bookinfo-v1` service for requests to the `/productpage` path and traffic to the `bookinfo-v2` service for requests to the `/reviews` path.
-### Verifying the Virtual Service
+### Verifying Virtual Service
Once the virtual service is set up, the HTTP route is mapped to the waypoint configuration. This means that all traffic that matches the virtual service's hosts and HTTP routes will be routed to the waypoint proxy.
@@ -210,7 +290,7 @@ This output shows that the `bookinfo` virtual service is mapped to the `bookinfo
By understanding how virtual services are mapped to waypoint proxies, you can configure your Istio mesh to route traffic in the way that you need.
-## Monitoring Waypoint proxy
+## Monitoring the Waypoint Proxy & L7 Networking
This section describes how to monitor Waypoint proxy for the Bookinfo application.
@@ -256,7 +336,6 @@ This will output the pods in your cluster. You can then use the `istioctl __` co
### Verifying L7 proxy load balancing
-
### Monitoring the AB Deployment and Canary Deployment
You can use the following command to monitor the AB Deployment and Canary Deployment traffic:
@@ -288,18 +367,18 @@ You can use the following methods to monitor the waypoint configuration for how
By monitoring the waypoint proxy and the virtual service mapping, you can ensure that your Istio mesh is operating as expected.
-## L7 Authorization Policy
-TODO
-## Monitoring and Telemetry with Waypoint Proxy
-TODO
+## L7 Fault Injection: #l7faultinjection
+
+## L7 Observability: #l7observability
+
+## L7 Authorization Policy
+<>
## How to use Waypoint proxy for hairpinning
-TODO
+<>
-% ## Co-existence of Ambient/ L7 with Side car proxies
-% How to use the Waypoint proxy with sidecar proxies
-% TODO
+## Co-existence of Ambient/ L7 with Side car proxies
## Control Traffic towards Waypoint Proxy
@@ -340,36 +419,6 @@ Confirm that roughly 10% of the traffic from 100 requests goes to reviews-v2:
$ kubectl exec deploy/sleep -- sh -c "for i in \$(seq 1 100); do curl -s http://$GATEWAY_HOST/productpage | grep reviews-v.-; done"
{{< /text >}}
-## Configuring AB Deployment and Canary Deployment
-
-To send traffic to an AB deployment for the sidecar model using a waypoint proxy, you can follow these steps:
-
-TODO
-
-Once you have completed these steps, traffic will be routed to the two versions of your application according to the traffic splitting configuration.
-
-Here is a concrete example of how to send traffic to an AB deployment for the sidecar model using a waypoint proxy for the Bookinfo application:
-
-{{< text bash >}}
-$ YAML file
-{{< /text >}}
-
-Once you have deployed these resources, traffic will be routed to the `bookinfo-v1` and `bookinfo-v2` versions of the Bookinfo application according to the traffic splitting configuration. You can adjust the weight of each route to control how much traffic is routed to each version of the application.
-
-By using waypoint proxies and traffic splitting, you can implement AB deployments for sidecar models in Istio. This allows you to gradually roll out new versions of your application to users and to monitor the performance of the new version before rolling it out to all users.
-
-You can use Istio's AB Deployment and Canary Deployment features to deploy and manage multiple versions of your application at the same time. To do this, you would create a virtual service for each version of your application. Then, you would use Istio's traffic splitting features to route traffic to the different versions of your application.
-
-For more information on AB Deployment and Canary Deployment, please see the Istio documentation.
-
-### Traffic splitting with Canary development
-TODO
-
-**Conclusion**
-
-This section has described how to configure Waypoint proxy for the Bookinfo application. For more information on waypoint proxies, please see the Istio documentation.
-
-
## Remove Waypoint proxy layer
To remove the `productpage-viewer` authorization policy, waypoint proxies and uninstall Istio:
@@ -401,8 +450,4 @@ If you installed the Gateway API CRDs for Waypoint proxy, remove them:
{{< text bash >}}
$ kubectl kustomize "github.com/kubernetes-sigs/gateway-api/config/crd/experimental?ref={{< k8s_gateway_api_version >}}" | kubectl delete -f -
-{{< /text >}}
-
-
-## Troubleshooting
-TODO
\ No newline at end of file
+{{< /text >}}
\ No newline at end of file
From 945fad90787a82b7331fe43720e85da6ac96d431 Mon Sep 17 00:00:00 2001
From: fykaa
Date: Sat, 2 Dec 2023 23:48:44 +0530
Subject: [PATCH 05/19] added functional overview
---
.../docs/ops/ambient/usage/waypoint/index.md | 293 +++++++++++++++---
1 file changed, 242 insertions(+), 51 deletions(-)
diff --git a/content/en/docs/ops/ambient/usage/waypoint/index.md b/content/en/docs/ops/ambient/usage/waypoint/index.md
index 6c3218f8f4cf..c8b22b503768 100644
--- a/content/en/docs/ops/ambient/usage/waypoint/index.md
+++ b/content/en/docs/ops/ambient/usage/waypoint/index.md
@@ -13,6 +13,14 @@ Please **do not run ambient in production** and be sure to thoroughly review the
In particular, there are known performance, stability, and security issues in the `alpha` release. There are also functional caveats some of which are listed in the [Caveats section](#caveats) of this guide. There are also planned breaking changes, including some that will prevent upgrades. These are all limitations that will be addressed before graduation to `beta`. The current version of this guide is meant to assist early deployments and testing of the alpha version of `ambient`. The guide will continue to get updated as `ambient` itself evolves from alpha to beta status and beyond.
{{< /warning >}}
+## Introduction
+
+This guide provides instructions on how to set up and use the Waypoint proxy layer in Istio Ambient Mesh.
+
+Istio Ambient Mesh is a new way to deploy and manage microservices. In Ambient Mesh, workloads are no longer required to run sidecar proxies to participate in the service mesh. Ambient splits Istio’s functionality into two distinct layers, a secure overlay layer and a Layer 7 processing layer.
+
+Ztunnel proxy is used to handle L3 and L4 networking functions, such as mTLS authentication and L4 authorization. For workloads that require L7 networking features, such as HTTP load balancing and fault injection, a waypoint proxy can be deployed. The waypoint proxy is an optional component that is Envoy-based and is responsible for terminating workload HTTP traffic and parsing workload HTTP headers. They also enforce L7 policies and collect L7 metrics.
+
{{}}
@@ -24,26 +32,13 @@ Before you begin, make sure that you have already read the [Ztunnel Networking s
{{}}
-
-
-## Introduction
-
-This guide provides instructions on how to set up and use the Waypoint proxy layer in Istio Ambient Mesh.
-
-Istio Ambient Mesh is a new way to deploy and manage microservices. In Ambient Mesh, workloads are no longer required to run sidecar proxies to participate in the service mesh. Ambient splits Istio’s functionality into two distinct layers, a secure overlay layer and a Layer 7 processing layer.
-
-Ztunnel proxy is used to handle L3 and L4 networking functions, such as mTLS authentication and L4 authorization. For workloads that require L7 networking features, such as HTTP load balancing and fault injection, a waypoint proxy can be deployed. The waypoint proxy is an optional component that is Envoy-based and is responsible for terminating workload HTTP traffic and parsing workload HTTP headers. They also enforce L7 policies and collect L7 metrics.
-
This guide describes the functionality and usage of the waypoint proxy and L7 networking functions using Istio Ambient Mesh. We use a sample user journey to describe these functions hence it would be useful to go through this guide in sequence. However we provide links to the sections below in case the reader would like to jump to the appropriate section.
* [Introduction](#introduction)
-* [Deciding if you need A Waypoint proxy](#deciding-if-you-need-a-waypoint-proxy)
+* [Deciding if you need A Waypoint Proxy](#deciding-if-you-need-a-waypoint-proxy)
* [Current Challenges](#current-challenges)
-* [Differences between Sidecar Mode and Ambient Mode for Waypoint Proxy](#differences)
-* [Deciding the scope of your Waypoint proxy](#differences-between-sidecar-mode-and-ambient-mode-for-waypoint-proxy)
+
+* [Deciding the scope of your Waypoint Proxy](#Deciding-the-scope-of-your-Waypoint-Proxy)
* [Functional Overview](#functional-overview)
* [Deploying an Application](#deploying-an-application)
* [Configuring Waypoint proxy](#configuring-waypoint-proxy)
@@ -51,30 +46,37 @@ This guide describes the functionality and usage of the waypoint proxy and L7 ne
* [L7 Fault Injection](#l7-fault-injection)
* [L7 Observability](#l7-observability)
* [L7 Authorization Policy](#l7-authorization-policy)
+* [Co-existence of Ambient/ L7 with Side car proxies](#Co-existence-of-Ambient/-L7-with-Side-car-proxies)
* [Control Traffic towards Waypoint Proxy](##control-traffic-towards-waypoint-proxy)
* [Remove Waypoint proxy layer](#remove-waypoint-proxy-layer)
-## Deciding if you need A Waypoint proxy
+# Deciding if you need A Waypoint proxy
+
+It's possible that the features offered by the secure overlay doesn’t meet your requirements. For instance, you need a rich Layer 7 authorization policy that sets up access based on a certain method and path. Alternatively you may like to conduct a canary test on the updated version of your service or introduce a new version without affecting current traffic. Or, you would like to receive metrics, HTTP access logs, and distributed tracing for some of your services. In order to accomplish these common cases, we'll go over how you can choose to enforce L7 processing with ambient mesh in this section.
-<>
+## Benefits of using the waypoint proxy and L7 networking features
-### Benefits of using the waypoint proxy and L7 networking features
+In summary, the waypoint proxy approach for the L7 processing layer offers the following three main advantages:
+
+- Security - Rich L7 authorization policy
+- Observability - HTTP metrics, access logs, and tracing
+- Traffic management - Dark launch, canary test
The waypoint proxy and L7 networking features provide a number of benefits, including:
-1. Improved performance and scalability: Waypoint proxies are designed to be lightweight and efficient, which can improve the performance and scalability of your microservices architecture.
-2. Increased flexibility: The waypoint proxy allows you to implement a wide range of L7 networking features, such as HTTP load balancing, fault injection, and observability.
-3. Simplified operations: By deploying a waypoint proxy, you can simplify the operation of your microservices architecture by reducing the number of components that need to be managed.
+- Improved performance and scalability: Waypoint proxies are designed to be lightweight and efficient, which can improve the performance and scalability of your microservices architecture.
+- Increased flexibility: The waypoint proxy allows you to implement a wide range of L7 networking features, such as HTTP load balancing, fault injection, and observability.
+- Simplified operations: By deploying a waypoint proxy, you can simplify the operation of your microservices architecture by reducing the number of components that need to be managed.
-### When to use the waypoint proxy and L7 networking features
+## When to use the waypoint proxy and L7 networking features
You should consider using the waypoint proxy and L7 networking features if your microservices architecture requires any of the following:
-1. L7 load balancing and routing: You need to distribute traffic across multiple instances of a workload based on factors such as request path, header values, or cookies.
-2. Waypoint provides a variety of L7 load balancing and routing algorithms, including round robin, weighted round robin, and least connections. It also supports path-based routing and other advanced routing rules.
-3. L7 fault injection: You need to simulate faults in your microservices architecture such as delays, errors, and circuit breaks to test its resilience and prepare for real-world failures.
-4. Rate limiting: You need to protect workloads against denial-of-service attacks and improve performance.
-5. L7 observability: You need to collect metrics and traces from your microservices architecture to monitor its performance and troubleshoot problems.
+- L7 load balancing and routing: You need to distribute traffic across multiple instances of a workload based on factors such as request path, header values, or cookies.
+Waypoint provides a variety of L7 load balancing and routing algorithms, including round robin, weighted round robin, and least connections. It also supports path-based routing and other advanced routing rules.
+- L7 fault injection: You need to simulate faults in your microservices architecture such as delays, errors, and circuit breaks to test its resilience and prepare for real-world failures.
+- Rate limiting: You need to protect workloads against denial-of-service attacks and improve performance.
+- L7 observability: You need to collect metrics and traces from your microservices architecture to monitor its performance and troubleshoot problems.
### Getting started with the waypoint proxy and L7 networking features
@@ -82,45 +84,234 @@ To get started with the waypoint proxy and L7 networking features, you will need
This guide will provide more detailed instructions on how to deploy and configure the waypoint proxy and L7 networking features.
-## Current Challenges
+# Current Challenges: #current-challenges
-<>
+<>
-### Environment used for this guide
+Waypoint only supports Ambient workloads. It does not support sidecar proxy workloads. In addition to this general caveats, there are also some specific caveats to be aware of when using Waypoint with certain protocols:
-For the examples in this guide, we used a deployment of Istio version `1.19.0`` on a `kinD` cluster of version `0.20.0 running Kubernetes version `1.27.3`. However these should also work on any Kubernetes cluster at version `1.24.0` or later and Istio version `1.18.0` or later. It would be recommended to have a cluster with more than 1 worker node in order to fully exercise the examples described in this guide. Refer to the installation user guide or Getting started guide information on installing Istio in ambient mode on a Kubernetes cluster.
+- HTTP: Waypoint does not support all HTTP features, such as HTTP/2 and chunked encoding.
+- gRPC: Waypoint does not support all gRPC features, such as HTTP/2 transport and protocol multiplexing.
+- WebSocket: Waypoint does not support WebSocket.
-## Differences between Sidecar Mode and Ambient Mode for Waypoint Proxy
+Despite these caveats, Waypoint is a powerful tool for enabling L7 networking and services for Istio Ambient workloads. It is a good choice for users who are looking for a way to run microservices-based applications in Ambient mode.
-## Deciding the scope of your Waypoint proxy
+Here is a table summarizing the caveats of Waypoint:
-
+| Caveat | Description |
+| ------------- | ------------- |
+| Maturity | Waypoint is still under development |
+| Features | Waypoint only supports L7 load balancing and routing |
+|Integration | Waypoint is not yet fully integrated with the Istio control plane | Support | Waypoint only supports Ambient workloads | HTTP | Waypoint does not support all HTTP features |
+gRPC | Waypoint does not support all gRPC features | Websocket | Waypoint does not support WebSocket |
-<< per workload level or Namespace or service account >>
+In addition to these caveats, it is also important to note that Waypoint is a new feature, and it is not yet as mature as Istio's sidecar proxy. As a result, users may experience some performance or stability issues when using Waypoint. However, the Ambient mesh team is actively working to address these issues, and they are committed to making Waypoint a production-ready feature.
-In ambient, all policies are enforced by the destination waypoint. In many ways, the waypoint acts as a gateway into the namespace (default scope) or service account. Istio enforces that all traffic coming into the namespace goes through the waypoint, which then enforces all policies for that namespace. Because of this, each waypoint only needs to know about configuration for its own namespace
+Overall, Waypoint is a powerful tool for enabling L7 networking and services for Istio Ambient workloads. However, users should be aware of the caveats and limitations listed above before deploying Waypoint in production.
+## Environment used for this guide
-#### Additional Notes
+For the examples in this guide, we used a deployment of Istio version `1.19.0` on a `kinD` cluster of version `0.20.0` running Kubernetes version `1.27.3`. However these should also work on any Kubernetes cluster at version `1.24.0` or later and Istio version `1.18.0` or later. It would be recommended to have a cluster with more than 1 worker node in order to fully exercise the examples described in this guide. Refer to the [Installation user](https://deploy-preview-13635--preliminary-istio.netlify.app/latest/docs/ops/ambient/usage/install/) guide or [Getting started guide](https://deploy-preview-13635--preliminary-istio.netlify.app/latest/docs/ops/ambient/getting-started/) on installing Istio in ambient mode on a Kubernetes cluster.
-* The Waypoint Proxy layer can coexist with sidecar proxies in the same cluster. This allows you to use Waypoint proxy for services that require L7 functionality and sidecar proxies for services that do not.
-* Waypoint proxy is implemented using Envoy. This means that you can use all of the features of Envoy in your Waypoint Proxies.
-* Waypoint proxy is still under development, but it is already a powerful tool for managing L7 traffic in Istio Ambient Mesh.
+# Deciding the scope of your Waypoint proxy
-For the examples in this guide, we used a deployment of Istio Ambient on a `kinD` cluster, although these should apply for any Kubernetes cluster version 1.18.0 or later. Refer to the Getting started guide on how to download the `istioctl` client and how to deploy a `kinD` cluster. It would be recommended to have a cluster with more than 1 worker node in order to fully exercise the examples described in this guide.
+Waypoint proxies can be deployed at the namespace or service account level. The scope you choose depends on your specific needs and requirements.
-## Functional Overview
+## Namespace-level scope
-<>
+Deploying Waypoint proxies at the namespace level provides a number of benefits, including:
+- Simplified policy management: Policies are enforced at the namespace level, so you only need to define them once for all workloads in the namespace.
+- Improved performance: Waypoint proxies can cache routing and policy information, which can improve performance for workloads in the namespace.
+- Increased security: Waypoint proxies can enforce authorization policies at the namespace level, which can help to protect your workloads from unauthorized access.
-<>
+However, deploying Waypoint proxies at the namespace level also has some drawbacks, including:
+- Limited granularity: You cannot apply different policies to different workloads in the same namespace.
+- Increased resource consumption: Each namespace will require its own Waypoint proxy, which can consume more resources.
+
+## Service account-level scope
+
+Deploying Waypoint proxies at the service account level provides a number of benefits, including:
+- Increased granularity: You can apply different policies to different workloads based on their service account.
+- Reduced resource consumption: You only need to deploy a Waypoint proxy for each service account that has workloads that require L7 routing or policy enforcement.
+
+However, deploying Waypoint proxies at the service account level also has some drawbacks, including:
+
+- Increased complexity: Managing policies at the service account level can be more complex, especially if you have a large number of service accounts.
+- Reduced caching: Waypoint proxies cannot cache routing and policy information at the service account level, which can reduce performance.
+
+## How to choose the right scope for your Waypoint proxies
+
+The best scope for your Waypoint proxies will depend on your specific needs and requirements. If you have a simple application with a small number of workloads, then namespace-level scope may be a good choice. However, if you have a more complex application with a large number of workloads or if you need to apply different policies to different workloads, then service account-level scope may be a better choice.
+
+Here are some factors to consider when choosing the scope for your Waypoint proxies:
+- The number of workloads in your application
+- The complexity of your application
+- The need to apply different policies to different workloads
+- The performance requirements of your application
+- The resource requirements of your application
+
+# Functional Overview
+
+The functional behaviour of the waypoint proxy is dynamically configured by Istio to serve your applications configurations. This section takes a brief look at these functional aspects - detailed description of the internal design of the waypoint proxy is out of scope for this guide. The detailed functional overview from the Secure Overlay Networking was already discussed in the [Ztunnel L4 Networking Guide](https://deploy-preview-13635--preliminary-istio.netlify.app/latest/docs/ops/ambient/usage/ztunnel/#functionaloverview) hence this section only focuses on functionalities and features that Waypoint Proxy provides.
+
+<>
+
+What is unique about the waypoint proxy is that it runs either per-namespace (default) or per-service account. By running outside of the application pod, a waypoint proxy can install, upgrade, and scale independently from the application pod, providing a centralized approach to managing L7 traffic and enforcing policies as well as reduce operational costs.
+
+Upon deployment of a gateway resource using the `kubectl apply` command, Istio's control plane, IstioD, assumes the role of the Waypoint controller. Recognizing the gateway resource with the "istio.io/waypoint" gateway class name, istiod automatically deploys the Waypoint proxy based on the specified configuration in the gateway resource.
+
+The waypoint proxy's data plane operates at Layer 7, enabling it to fully parse connections into individual requests and apply policies based on request properties such as headers and credentials. This granular control over L7 traffic extends to a comprehensive suite of capabilities, including:
+- HTTP 1.x, 2, or 3
+- Request routing
+- Advanced load balancing
+- Request mirroring
+- Fault injection
+- Request retries
+- gRPC-specific capabilities
+
+Waypoint proxies are deployed either per-namespace or per-service account, providing granular control over L7 traffic management. This deployment model allows for independent scaling of waypoint proxies based on the request load for individual workloads. Unlike the traditional sidecar deployment approach, waypoint proxies can be scaled independently to better fit the incoming traffic for a service and match the actual workload usage, optimizing resource utilization and improving performance. You can think of these waypoint proxies as individual gateways per workload type as shown here -
+
+<>
+
+The deployment of waypoint proxies can be handled by namespace owners, platform operators, or automated systems. Once a waypoint proxy is deployed, and a corresponding L7 policy is configured for a destination represented by the waypoint proxy, the secure overlay layer ensures that connection is routed to the correct L7 waypoint proxy for processing and policy enforcement as shown here -
+
+<>
+
+Tenancy for Layer 7 capabilities in the Istio ambient mesh is similar to the sidecar deployment model. L7 capabilities are not shared across multiple identities within a single L7 proxy. Each application has its own dedicated waypoint proxy, ensuring isolation of configuration and extensions (plug-ins, extensions, etc.) specific to individual workloads. This isolation prevents interference between workloads and facilitates independent management of L7 configurations.
+
+Functionally, the Waypoint proxy resembles the sidecar proxy but operates independently of application pods. It has its own CA client and XDS client, enabling secure communication with istioD. To obtain its identity certificate, the Waypoint proxy establishes a secure connection with istioD, requesting certification. Upon validating the presented token, istioD signs the Waypoint proxy's certificate, granting it access to the Istio control plane.
+
+Subsequently, the Waypoint proxy initiates communication with istioD, requesting XDS configuration to govern its operation. This configuration defines the L7 routing rules, policy enforcement mechanisms, and other parameters essential for managing L7 traffic.
+
+In essence, the Waypoint proxy serves as an L7 traffic management hub, decoupled from application pods and centrally managed by istioD. This architecture simplifies L7 configuration and policy enforcement, enabling efficient and scalable L7 services within Istio Ambient deployments as shown in the figure -
+
+<>
+
+## Destination Only Waypoint
+
+In contrast to traditional sidecar proxies, which reside alongside application pods, Waypoint proxies operate solely on the server-side, acting as reverse proxies for L7 traffic. This approach streamlines L7 traffic management by centralising policy enforcement to the destination workload's namespace or service account.
+
+When a request originates from an application pod, it bypasses the client-side Waypoint proxy and directly reaches the server-side Waypoint proxy associated with the destination workload's namespace or service account. Istio enforces that all traffic coming into the namespace goes through the waypoint, which then enforces all policies for that namespace. Because of this, each waypoint only needs to know about configuration for its own namespace. Thus Waypoint proxy assumes responsibility for enforcing all L7 policies and routing rules applicable to the destination workload.
+
+<>
+
+Destination-only Waypoint simplifies the configuration process by eliminating the need for sidecar proxies and "exportTo" configurations. Waypoint proxies only need to be aware of the endpoints, pods, and workloads within their respective namespaces or service accounts. This streamlined approach reduces the complexity of L7 management and enables a more efficient use of resources.
+
+<>
+
+- **Policy Enforcement**: In traditional Istio deployments, both source-side and destination-side policies were employed, which often led to confusion for users regarding policy enforcement and troubleshooting. Destination-only Waypoint simplifies this process by enforcing all policies exclusively at the destination workload's namespace or service account. This centralized approach eliminates the need to track policies across multiple locations, making it easier to understand, manage, and troubleshoot L7 security configurations.
+
+<>
+
+- **Mixed Environment**: In a mixed environment where clients may reside inside or outside the Istio mesh, destination-only Waypoint ensures consistent policy enforcement regardless of the client's location. Since all policies are applied at the destination workload, users can be confident that security measures are consistently applied to all incoming traffic.
+
+<>
+
+## Handling Destinations without Waypoint Proxies
+
+While destination-only Waypoint offers centralized policy enforcement and simplified configuration, there may be instances where the destination workload doesn't have a waypoint proxy deployed. This could arise when connecting to external services beyond the control of the Istio mesh.
+
+To address this scenario, the Istio community is actively developing mechanisms to route traffic to the egress gateway and enable policy enforcement for destinations without waypoint proxies. This functionality will allow users to configure resilience-enhancing policies, such as timeouts, for external services.
+
+Please stay tuned for future blog posts and documentation updates that will provide detailed information on this evolving feature.
+
+# Deploying an Application
+
+When someone with Istio admin privileges sets up Istio mesh, it becomes available for all users in specific namespaces. The examples below shows how Istio can be used transparently once it's successfully deployed in ambient mode and the namespaces are annotated accordingly.
+
+## Basic application deployment without Ambient
+
+In this guide, we'll work with the sample [bookinfo application](https://istio.io/latest/docs/examples/bookinfo/) that comes with Istio. If you've downloaded Istio, you already have it. In ambient mode, deploying apps to your Kubernetes cluster is just like doing it without Istio. You can have your apps running in the cluster before turning on ambient mesh. They can seamlessly join the mesh without any need for restarting or reconfiguring.
+
+{{< warning >}}
+Make sure the default namespace does not include the label `istio-injection=enabled` because when using ambient you do not want Istio to inject sidecars into the application pods.
+ {{ warning >}}
+
+1. Deploy Sample Services
+
+{{< text bash >}}
+$ kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml
+{{< /text >}}
+
+{{< text bash >}}
+$ kubectl apply -f samples/sleep/sleep.yaml
+$ kubectl apply -f samples/sleep/notsleep.yaml
+{{< /text >}}
+
+2. Deploy an Ingress Gateway and a Virtual Service -
+This allows you to access the bookinfo app from outside the cluster
+
+{{< tip >}}
+To get IP address assignment for `Loadbalancer` service types in `kinD`, you may need to install a tool like [MetalLB](https://metallb.universe.tf/). Please consult [this guide](https://kind.sigs.k8s.io/docs/user/loadbalancer/) for more information.
+{{< /tip >}}
+
+{{< tabset category-name="config-api" >}}
+
+{{< tab name="Istio APIs" category-value="istio-apis" >}}
+
+Create an Istio [Gateway](/docs/reference/config/networking/gateway/) and
+[VirtualService](/docs/reference/config/networking/virtual-service/):
+
+{{< text bash >}}
+$ kubectl apply -f @samples/bookinfo/networking/bookinfo-gateway.yaml@
+{{< /text >}}
+
+Set the environment variables for the Istio ingress gateway:
+
+{{< text bash >}}
+$ export GATEWAY_HOST=istio-ingressgateway.istio-system
+$ export GATEWAY_SERVICE_ACCOUNT=ns/istio-system/sa/istio-ingressgateway-service-account
+{{< /text >}}
+
+{{< /tab >}}
+
+{{< tab name="Gateway API" category-value="gateway-api" >}}
+
+Create a [Kubernetes Gateway](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io%2fv1beta1.Gateway)
+and [HTTPRoute](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.HTTPRoute):
+
+{{< text bash >}}
+$ sed -e 's/from: Same/from: All/'\
+ -e '/^ name: bookinfo-gateway/a\
+ namespace: istio-system\
+' -e '/^ - name: bookinfo-gateway/a\
+ namespace: istio-system\
+' @samples/bookinfo/gateway-api/bookinfo-gateway.yaml@ | kubectl apply -f -
+{{< /text >}}
+
+Set the environment variables for the Kubernetes gateway:
+
+{{< text bash >}}
+$ kubectl wait --for=condition=programmed gtw/bookinfo-gateway -n istio-system
+$ export GATEWAY_HOST=bookinfo-gateway-istio.istio-system
+$ export GATEWAY_SERVICE_ACCOUNT=ns/istio-system/sa/bookinfo-gateway-istio
+{{< /text >}}
+
+{{< /tab >}}
+
+{{< /tabset >}}
+
+
+3. Test your bookinfo application, it should work with or without the gateway:
+
+ {{< text syntax=bash snip_id=verify_traffic_sleep_to_ingress >}}
+ $ kubectl exec deploy/sleep -- curl -s "http://$GATEWAY_HOST/productpage" | grep -o ".*"
+ Simple Bookstore App
+ {{< /text >}}
+
+ {{< text syntax=bash snip_id=verify_traffic_sleep_to_productpage >}}
+ $ kubectl exec deploy/sleep -- curl -s http://productpage:9080/ | grep -o ".*"
+ Simple Bookstore App
+ {{< /text >}}
+
+ {{< text syntax=bash snip_id=verify_traffic_notsleep_to_productpage >}}
+ $ kubectl exec deploy/notsleep -- curl -s http://productpage:9080/ | grep -o ".*"
+ Simple Bookstore App
+ {{< /text >}}
-## Deploying an Application
+## Enabling Ambient Mesh
-Lets first deploy a sample application composed of four separate microservices used to demonstrate various L7 feature without making it part of the Istio ambient mesh. We can pick from the apps in the samples folder of the istio repository. Execute the following examples from the top of a local Istio repository or istio folder created by downloading the istioctl client as described in istio guides.
+
\ No newline at end of file
From cc65453f45e94af0b536aa878fe410c5541ed217 Mon Sep 17 00:00:00 2001
From: fykaa
Date: Mon, 4 Dec 2023 05:06:13 +0530
Subject: [PATCH 06/19] func overview
---
.../waypoint/destination-only-waypoint.svg | 1 +
.../usage/waypoint/destinationonly.svg | 1 +
.../docs/ops/ambient/usage/waypoint/index.md | 462 ++----------------
.../usage/waypoint/mixed-environment.svg | 1 +
.../usage/waypoint/policies-enforced (1).svg | 1 +
.../usage/waypoint/policies-enforced.svg | 1 +
.../waypoint-architecture-deep-dive.svg | 1 +
.../usage/waypoint/waypoint-architecture.png | Bin 0 -> 83375 bytes
.../waypoint-gateway-architecture.svg | 1 +
.../usage/waypoint/waypoint-traffic-flow.svg | 1 +
10 files changed, 41 insertions(+), 429 deletions(-)
create mode 100644 content/en/docs/ops/ambient/usage/waypoint/destination-only-waypoint.svg
create mode 100644 content/en/docs/ops/ambient/usage/waypoint/destinationonly.svg
create mode 100644 content/en/docs/ops/ambient/usage/waypoint/mixed-environment.svg
create mode 100644 content/en/docs/ops/ambient/usage/waypoint/policies-enforced (1).svg
create mode 100644 content/en/docs/ops/ambient/usage/waypoint/policies-enforced.svg
create mode 100644 content/en/docs/ops/ambient/usage/waypoint/waypoint-architecture-deep-dive.svg
create mode 100644 content/en/docs/ops/ambient/usage/waypoint/waypoint-architecture.png
create mode 100644 content/en/docs/ops/ambient/usage/waypoint/waypoint-gateway-architecture.svg
create mode 100644 content/en/docs/ops/ambient/usage/waypoint/waypoint-traffic-flow.svg
diff --git a/content/en/docs/ops/ambient/usage/waypoint/destination-only-waypoint.svg b/content/en/docs/ops/ambient/usage/waypoint/destination-only-waypoint.svg
new file mode 100644
index 000000000000..20232b10d063
--- /dev/null
+++ b/content/en/docs/ops/ambient/usage/waypoint/destination-only-waypoint.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/content/en/docs/ops/ambient/usage/waypoint/destinationonly.svg b/content/en/docs/ops/ambient/usage/waypoint/destinationonly.svg
new file mode 100644
index 000000000000..6ac9f713cc04
--- /dev/null
+++ b/content/en/docs/ops/ambient/usage/waypoint/destinationonly.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/content/en/docs/ops/ambient/usage/waypoint/index.md b/content/en/docs/ops/ambient/usage/waypoint/index.md
index f4f6b710c0eb..6883ae9fb55d 100644
--- a/content/en/docs/ops/ambient/usage/waypoint/index.md
+++ b/content/en/docs/ops/ambient/usage/waypoint/index.md
@@ -154,7 +154,10 @@ Here are some factors to consider when choosing the scope for your Waypoint prox
The functional behaviour of the waypoint proxy is dynamically configured by Istio to serve your applications configurations. This section takes a brief look at these functional aspects - detailed description of the internal design of the waypoint proxy is out of scope for this guide. The detailed functional overview from the Secure Overlay Networking was already discussed in the [Ztunnel L4 Networking Guide](https://deploy-preview-13635--preliminary-istio.netlify.app/latest/docs/ops/ambient/usage/ztunnel/#functionaloverview) hence this section only focuses on functionalities and features that Waypoint Proxy provides.
-<>
+{{< image width="100%"
+link="waypoint-architecture.png"
+caption="Waypoint architecture"
+>}}
What is unique about the waypoint proxy is that it runs either per-namespace (default) or per-service account. By running outside of the application pod, a waypoint proxy can install, upgrade, and scale independently from the application pod, providing a centralized approach to managing L7 traffic and enforcing policies as well as reduce operational costs.
@@ -171,11 +174,17 @@ The waypoint proxy's data plane operates at Layer 7, enabling it to fully parse
Waypoint proxies are deployed either per-namespace or per-service account, providing granular control over L7 traffic management. This deployment model allows for independent scaling of waypoint proxies based on the request load for individual workloads. Unlike the traditional sidecar deployment approach, waypoint proxies can be scaled independently to better fit the incoming traffic for a service and match the actual workload usage, optimizing resource utilization and improving performance. You can think of these waypoint proxies as individual gateways per workload type as shown here -
-<>
+{{< image width="100%"
+link="waypoint-gateway-architecture.svg"
+caption="The waypoint proxy is deployed per service account/ workload identity and can be thought of as a “gateway per workload”"
+>}}
The deployment of waypoint proxies can be handled by namespace owners, platform operators, or automated systems. Once a waypoint proxy is deployed, and a corresponding L7 policy is configured for a destination represented by the waypoint proxy, the secure overlay layer ensures that connection is routed to the correct L7 waypoint proxy for processing and policy enforcement as shown here -
-<>
+{{< image width="100%"
+link="waypoint-traffic-flow.svg"
+caption="Traffic will flow through L7 waypoint proxies when there are L7 policies that need to be enforced for a particular service"
+>}}
Tenancy for Layer 7 capabilities in the Istio ambient mesh is similar to the sidecar deployment model. L7 capabilities are not shared across multiple identities within a single L7 proxy. Each application has its own dedicated waypoint proxy, ensuring isolation of configuration and extensions (plug-ins, extensions, etc.) specific to individual workloads. This isolation prevents interference between workloads and facilitates independent management of L7 configurations.
@@ -185,7 +194,10 @@ Subsequently, the Waypoint proxy initiates communication with istioD, requesting
In essence, the Waypoint proxy serves as an L7 traffic management hub, decoupled from application pods and centrally managed by istioD. This architecture simplifies L7 configuration and policy enforcement, enabling efficient and scalable L7 services within Istio Ambient deployments as shown in the figure -
-<>
+{{< image width="100%"
+link="waypoint-architecture-deep-dive.svg"
+caption="Waypoint Architecture Deep Dive"
+>}}
## Destination Only Waypoint
@@ -193,19 +205,31 @@ In contrast to traditional sidecar proxies, which reside alongside application p
When a request originates from an application pod, it bypasses the client-side Waypoint proxy and directly reaches the server-side Waypoint proxy associated with the destination workload's namespace or service account. Istio enforces that all traffic coming into the namespace goes through the waypoint, which then enforces all policies for that namespace. Because of this, each waypoint only needs to know about configuration for its own namespace. Thus Waypoint proxy assumes responsibility for enforcing all L7 policies and routing rules applicable to the destination workload.
-<>
+{{< image width="100%"
+link="destinationonly.svg"
+caption="Waypoint Proxies"
+>}}
Destination-only Waypoint simplifies the configuration process by eliminating the need for sidecar proxies and "exportTo" configurations. Waypoint proxies only need to be aware of the endpoints, pods, and workloads within their respective namespaces or service accounts. This streamlined approach reduces the complexity of L7 management and enables a more efficient use of resources.
-<>
+{{< image width="100%"
+link="destination-only-waypoint.svg"
+caption="Waypoint Proxies"
+>}}
- **Policy Enforcement**: In traditional Istio deployments, both source-side and destination-side policies were employed, which often led to confusion for users regarding policy enforcement and troubleshooting. Destination-only Waypoint simplifies this process by enforcing all policies exclusively at the destination workload's namespace or service account. This centralized approach eliminates the need to track policies across multiple locations, making it easier to understand, manage, and troubleshoot L7 security configurations.
-<>
+{{< image width="100%"
+link="policies-enforced (1).svg"
+caption="Policy Enforced on Destination Waypoint"
+>}}
- **Mixed Environment**: In a mixed environment where clients may reside inside or outside the Istio mesh, destination-only Waypoint ensures consistent policy enforcement regardless of the client's location. Since all policies are applied at the destination workload, users can be confident that security measures are consistently applied to all incoming traffic.
-<>
+{{< image width="100%"
+link="mixed-environment.svg"
+caption="Waypoint Proxies"
+>}}
## Handling Destinations without Waypoint Proxies
@@ -221,424 +245,4 @@ When someone with Istio admin privileges sets up Istio mesh, it becomes availabl
## Basic application deployment without Ambient
-In this guide, we'll work with the sample [bookinfo application](https://istio.io/latest/docs/examples/bookinfo/) that comes with Istio. If you've downloaded Istio, you already have it. In ambient mode, deploying apps to your Kubernetes cluster is just like doing it without Istio. You can have your apps running in the cluster before turning on ambient mesh. They can seamlessly join the mesh without any need for restarting or reconfiguring.
-
-{{< warning >}}
-Make sure the default namespace does not include the label `istio-injection=enabled` because when using ambient you do not want Istio to inject sidecars into the application pods.
- {{ warning >}}
-
-1. Deploy Sample Services
-
-{{< text bash >}}
-$ kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml
-{{< /text >}}
-
-{{< text bash >}}
-$ kubectl apply -f samples/sleep/sleep.yaml
-$ kubectl apply -f samples/sleep/notsleep.yaml
-{{< /text >}}
-
-2. Deploy an Ingress Gateway and a Virtual Service -
-This allows you to access the bookinfo app from outside the cluster
-
-{{< tip >}}
-To get IP address assignment for `Loadbalancer` service types in `kinD`, you may need to install a tool like [MetalLB](https://metallb.universe.tf/). Please consult [this guide](https://kind.sigs.k8s.io/docs/user/loadbalancer/) for more information.
-{{< /tip >}}
-
-{{< tabset category-name="config-api" >}}
-
-{{< tab name="Istio APIs" category-value="istio-apis" >}}
-
-Create an Istio [Gateway](/docs/reference/config/networking/gateway/) and
-[VirtualService](/docs/reference/config/networking/virtual-service/):
-
-{{< text bash >}}
-$ kubectl apply -f @samples/bookinfo/networking/bookinfo-gateway.yaml@
-{{< /text >}}
-
-Set the environment variables for the Istio ingress gateway:
-
-{{< text bash >}}
-$ export GATEWAY_HOST=istio-ingressgateway.istio-system
-$ export GATEWAY_SERVICE_ACCOUNT=ns/istio-system/sa/istio-ingressgateway-service-account
-{{< /text >}}
-
-{{< /tab >}}
-
-{{< tab name="Gateway API" category-value="gateway-api" >}}
-
-Create a [Kubernetes Gateway](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io%2fv1beta1.Gateway)
-and [HTTPRoute](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.HTTPRoute):
-
-{{< text bash >}}
-$ sed -e 's/from: Same/from: All/'\
- -e '/^ name: bookinfo-gateway/a\
- namespace: istio-system\
-' -e '/^ - name: bookinfo-gateway/a\
- namespace: istio-system\
-' @samples/bookinfo/gateway-api/bookinfo-gateway.yaml@ | kubectl apply -f -
-{{< /text >}}
-
-Set the environment variables for the Kubernetes gateway:
-
-{{< text bash >}}
-$ kubectl wait --for=condition=programmed gtw/bookinfo-gateway -n istio-system
-$ export GATEWAY_HOST=bookinfo-gateway-istio.istio-system
-$ export GATEWAY_SERVICE_ACCOUNT=ns/istio-system/sa/bookinfo-gateway-istio
-{{< /text >}}
-
-{{< /tab >}}
-
-{{< /tabset >}}
-
-
-3. Test your bookinfo application, it should work with or without the gateway:
-
- {{< text syntax=bash snip_id=verify_traffic_sleep_to_ingress >}}
- $ kubectl exec deploy/sleep -- curl -s "http://$GATEWAY_HOST/productpage" | grep -o ".*"
- Simple Bookstore App
- {{< /text >}}
-
- {{< text syntax=bash snip_id=verify_traffic_sleep_to_productpage >}}
- $ kubectl exec deploy/sleep -- curl -s http://productpage:9080/ | grep -o ".*"
- Simple Bookstore App
- {{< /text >}}
-
- {{< text syntax=bash snip_id=verify_traffic_notsleep_to_productpage >}}
- $ kubectl exec deploy/notsleep -- curl -s http://productpage:9080/ | grep -o ".*"
- Simple Bookstore App
- {{< /text >}}
-
-## Enabling Ambient Mesh
-
-
+This section is Under Construction...
\ No newline at end of file
diff --git a/content/en/docs/ops/ambient/usage/waypoint/mixed-environment.svg b/content/en/docs/ops/ambient/usage/waypoint/mixed-environment.svg
new file mode 100644
index 000000000000..1e15d5a6f390
--- /dev/null
+++ b/content/en/docs/ops/ambient/usage/waypoint/mixed-environment.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/content/en/docs/ops/ambient/usage/waypoint/policies-enforced (1).svg b/content/en/docs/ops/ambient/usage/waypoint/policies-enforced (1).svg
new file mode 100644
index 000000000000..c79afd97d580
--- /dev/null
+++ b/content/en/docs/ops/ambient/usage/waypoint/policies-enforced (1).svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/content/en/docs/ops/ambient/usage/waypoint/policies-enforced.svg b/content/en/docs/ops/ambient/usage/waypoint/policies-enforced.svg
new file mode 100644
index 000000000000..8331921578dc
--- /dev/null
+++ b/content/en/docs/ops/ambient/usage/waypoint/policies-enforced.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/content/en/docs/ops/ambient/usage/waypoint/waypoint-architecture-deep-dive.svg b/content/en/docs/ops/ambient/usage/waypoint/waypoint-architecture-deep-dive.svg
new file mode 100644
index 000000000000..76a544dbee76
--- /dev/null
+++ b/content/en/docs/ops/ambient/usage/waypoint/waypoint-architecture-deep-dive.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/content/en/docs/ops/ambient/usage/waypoint/waypoint-architecture.png b/content/en/docs/ops/ambient/usage/waypoint/waypoint-architecture.png
new file mode 100644
index 0000000000000000000000000000000000000000..38066816a0d2028ce3e6c1a43657600778a3ac92
GIT binary patch
literal 83375
zcmeFZXIPV2_cw~;<1mWAC<-zNj0KSz6s3lsqM{;#A_CIH2uKGbC4?k4Ktzd!CM6LO
zkls5a3POe&r1uyQ0t5&UQb$JTI;ueYwfl6
zO_b#&Q}JzoY!eX?5kG(K^c4{iQId$rX7AsA1%Bxpp4}uOa!=&^>62GOoaVGLlDYj_U2rTJfb1L)Tl!0(Y?WKHfPlSsP6uwdGE$XPRtgb
zu-JI}Dz?=5yeNmJ(k7}(?9rX4i@(r~`ay%oe-*t9^4pw2XfR6Ml^j3k;g`sIa^Y@s
z?A;rfcVNZ$>K5b=9^>l&n4$5)aJ_h};K^#)X&XTN1<||crZt*IThCFx#(5O_G5`LL
z6Fi=`?k@0o^Dfnq-r)FJqIzNzKeUYj$ylo;uP+*dzdkn+@Ru4Tg*1z>2`PF96}eVt
z+#>p;{-@u)g9|B`Ey;c@Tb|Nr(@qK!X!Rn-kJlnXeRK|$JQFhW*y(Nb*09(-(|_o-diXH
zD;6C?vjLSv*K|jX`KwvRMkwZ7-@x6wcP}o?%?(SRn%Vw+Q+&Yp#tjs~sGV^83h(NL
z7{f(QvpaBR_?%eRuprHmH#yIj2>
z>WR*PUk(s_#-LUkUmY^%TD!Zu2MWyl;_z+XrQUn;d8I)N1P-0c&Qe%oRT9=ouxbbT
z&iddNPKnO|aYh=SMU$cmPG{|Zx4De4QkSKNrX$Ea)2!5>;jBXzSiX0dR0du3yR4g$!l3=^nVW}OD)(d(Zg
z+D~YAMXHkGW&m;b<_p1es}wR|BjsZ{I-T3&Jw(6Bxp%~i+L>w{JPxOZ1J0-wXaaKB
z4#D>o+~3N$rOCtxV6?lS5lQz8!0uPgM8Do^TH7SLcPW0vw{~GBGcz;$WPrr?1wozc
z?d|(CDo5}18v=OT47hdV&X`iDiwe8p=wiUHq3!3~-!wvANPHUqX8Ha~Jk#7Ahh#-o
zcn_^y6&RIhBYVD!5`kI)y7Hqzc+S_#`UM|!T-%huy`c64#;p496;141JYv#u!se}Z
z&b!V2T`T;@2VywU`mkw-7ihoUEI;Y*l5Sk2In)L%z)bfBd~zW$3<(UGYKKMi*BbW?
z)hyiK5L|;}saGG}6=6B$)LR4yWYEhpeuBP26mu#jCMIsS_Fvxx?co_18YU~C`O9q*
zfd2@jKoSJAB{T)8Ahz0I)HS(If~u1*ojEW1<;2t)JvC$^N?4ndqpCUZw{_;Tu3x`?
zEsP47hHp>i_HXPaG*%5S%01CmsYa5G>%Ol$b7x_VKMnwGp{KT{Cg`2t-(znGKlk;O
zd(HJ`6GBOdahRoM0s^sNjnXbLz{Ry;h+&sgcJDU(y;%XPbxInocCkBC^cnY8pZ%Tk
z%%iW{+YhAPX;mTCPigqAwu
ztCE_UI?}DX<+}}voaaJUKbxYtF~N0{^gGp~&eIImC>HUCI7AKD%5GR$Ko=Rt`?&+V
zYxLgKny4}7qcMCc&ZhI3-@R4&|FssJr>CbA_k$?J|2Ck9DWHc%f*;1Ll32yoPrq*P
zrF&{vjBSAKNx-jWpgjP-c#fC-KL5RS8(@?6*x*;eFZvF;ng_L
z0p9ukxkTA`TRCx6vvcwuvMoCc%Pr?u`B{*E`#$>zfe+vT8zIwK$UIr?pxFuezHYV?
zzTThC&|QcD=2w-!{V<*?y4U}MVvM4(VC3U^=XbsDeVXn_b`IHa-#LJ%ovRl&W-kD5
zkcSW8w@yIg9j1Gisn*uk3Ge)V`CH@Z>FKx)Qi%cJBKnmfq}C+(fkt_J!a}Day;E_q
zGdWoK(#$iJSZZJX~pH^5|B-4Z)4b~tKeMf}QSKD{Z?ML;pA?n9dkWAoc@(?C2f@a+a7Thn0sF?rQ^Pmy
ziDu~iIr-(OSq0H`=lC5U3J?m5ivz;A8wZ4q=dlDZvlKucSMuOq#s0j-1l}{+3qa
z81NQD|4+d2LTdnYLR>8)tJdl;35^CAVBV?~_Wi{-w*WrK`Pj-3rqC2p{8|GOsA&Ju
z0Af7>k9YcCO0Lr0Je1&u0r<7>omt@%<~wN`0MXX%i=}>-a-!uhDf=qI9!va~1OCpm
zBERq)}DoMp~W1Ux@cRD(zLEYU4hgjV1zBtGg=UKsl
z^I+n~yYus^25wcex9JxZ@t6?J*&_#{XtqgJF&Qm0H8D-Z?Yhgwzgo@F_WX+Qa4eV{
zZw^#9cOZ7((pq+RuMwU*`ZdrS1aYg1Lc57K2aeW0?W65+9U$ic;K23M5Q1`I_!-dF_{FItv$YZ;1sl-A+WNnJ6KK;XHKZZo9uW
zZ!Kw+!W%5hDH|xxhd-xPm6qNXzPPnsvaevWEu%ID=Cp@z;H$nI=zUgrnpM>
z+-Urw@ykyz#fxDJvqu^`M)_>OCWs^j?U&nwg&alCcE5#2BnP;I&H>=yv~j;J(D_{Rl>>m?UUNTv87S5|bm7Gax=stp
zf!u`00_ykrd0F7zn%bLr6i%)x>t$`w&
zntL8P6A_xW4uJn)RFZUtB$+r*^?DK`dp>C{DAVF|dPZ8=K)|%0sPF@6j2Z_>3S9g$
z5YS(m9KG=lO%xv!U=Lt%Ckd&wT%NUIF2vEq*Q8jMLGuya=X%#Rj5$P-6l{v-I97r#tHysX^{6j
zg#|A+d`U17ce^g2-}pYh`w6=8A{$*_{q>7q?PT5EGXR{~_lpP0(*S$=UTfbApg-4F#lY>L3N>)Fra%b*{ue~PE|@^%JENu4$gSmp2`h*Q*|)_CrFW$jNA^&dT07&
z7ed28;)n1uJpfiX+BX4exCo?VM+YyGIi=bFP@;@SM5Tn@=Qd1_vwJvn<>SB+fg@CF
znXdW`{D!?ZCdePZZI1YNnD6F{auv3*3&bRyijS$wP0*V~rj9*b;Y)7NJ&@>q$M;Uh
zR7aQ3pL{5DR_+mMc(BnZUy;%Hs5YlW>7Z!xCLq7+!c~==;om!B28~3dZ+1-sXLY~Z
zoEr=m;O>lVzOuo&ymNJgwO(RwX~v0UQM-oSA|f{q2iOT|1c+MQQ515pChfRAa@&_@
z@4gK+`r*2{pzX$i-+*SrINIHy9&J~sPdt`IC7b6|f7
zgI)T2)b8xuTs8GDA1_WvFg1b^gWZK%uZO!VG=yq*-PhfSZmZ$I$s$;PN`Lo$dE1S+
zF(^8*-T}nh12@
z5q~jXyj;${#~cV6evdPHJR3omaPpmNtM8ULOtn)8TEShJdpoSKRvz8=Gk`F1@96N*
zxa>5(O3C3)L+?_%$+#?Ztel8;0}>M;%e{NpH>W-GZ4i0Fk&@JkuzMdLTZWb6AN
zE3c|q9;3k(hm&@aC1{QTC%&bK(CO(uN*z==l7V@>%QH7WVoPlNO3H;--#r(5-W1`U
zsOw@Dg!^cSD$zPNK))CaXc=PCB$TWc$dxwgn_k+EAs4BRZP(i03R5*VDB6gBmWP=3
zBMlwyosu>vcxd8!n0bw?h{zjtH*md5O7QAC|M4TQOsrBRnZIPD|Jz@#ztfefJOZtB
zX#4~+Rw}3>FtZlWE%pqxpunGL<93S;K`-2A&br-m`OzScUDwK#b;HGCQuivbR)8X?yYyN}Zf!vHaU!Ga5-2uXkJ{<(ugONn)(E)q1D5Yn~WH
zTfeMw{(|o2?a@Ds`52?&Ln#4W6w?iZ1`U??yj&0w`GA*+X24=n_T)(SWhIM5ocY1r
zZwfLs95_QNlnCwVcgcVjtSCcNjTV0%V0CM@k?4ifKfHW{H{I`j{`5vH(7N6p5(?!E
z?T~6jCa9YOEC0tTSkLl@Kp7h*{&2fE?5qzcLz3=9!;{fQlRj%K5N%VKO
zPUL)vSmOJ5H5ySt5*vZrA_^%eepRY8=8OUIaQ4i33f?SU!XVmlW6%2mg!n(^-#n#X
zM6fmTGp#DKIif%h#AoE_AEOVx*2o>dDnqv(Pg-ElYj~AR@P~Wc!sm8Bn>7(v)gVD9
z)L99{LNW6->KtZcYmWoY{GW~YE8tM{a&O@^*YFVj>)?%jw%*UWn{csiAf%DSDhg|6
z6@^^znVGxD-s6Ctf?rf8%2*6Z2LuH-m?
zvCL8A_=NxX=P@94&*+`>W_nS
z78zj0MzzTSS9Ty_gSM(lWgcarOAWloy1HSbIdH=U=s@9bl_|%K5e0^*3az@k^qQ`5
zgQdVIYCYWCDrBzNn$kIjNll&H5)Fi!+!azSb(vS{8(LGz%ETcWG6X!=74j4PXaO@$6fgotMR|pf&Ov^4X
zLci!fP}2mnk2TgASN&3<2x^a!XQzi#?zhE<%aXho+2xx>iZ;p-e`h0awoicOM(l&a
zQ+-SlHi^W|my7B=5;Gogyd_kZ9s*{iB^-ZO`^=WU!j~Z@$}7~OTv;RznJTZX0@n34
z*D0;9OlxIuN<(LRhx0Dh&%g7a@S%qyVUV%)llM5+CnA5*)OYc`_NXw$ae(%sHs8@!
z(UT
zf>FdQHgNXPJ(tV>!)YQS7Y>d0@LNIVbd~qeVp+3JXQaDt6}>ydg;_Vz4c7}zpy~>E
zDMhzDeL_&9!+Cl!&e0i*6D`ODKgAp{eQ;=Z0k^dsdsJ8YbMZMm<>?TmffNWjhcrB#@Jm<>d$pB*fw){FczLjsRgpV7N0^{sS*MHY3@ScOs7ZOI+2anj`3}7Dyq@|)~ZJSs7$7|Hu`3uu|VHm0cJK7Zq
zrsgsR>e
z-B*hm!cL62|DG)H&%u2cBfh2k*$y0TbfPPJjl!VxQl+{HDK6Bo@)$SYx!In#Om
zF(VVG<>Q|iUS31Hhm#CXIhxxi#u<~UjN%)EQ)>?kYwQs*IKkIU?CarxUqkBLmizY?
zgR{x~@%cObfx}C<3g()-Gd({Tu0X(n#;kUG<|H9Hk@kW=nqXpM$+U#H^!fjg7|6{R|FJbE~SaOjvXpU~nfzMVyc~Oy1ko
zQuhLmZQr)Sp*-5HUFlBlc|i5EAJMKg#x_>)1J%X{tTf+Obm#TbYB{UZuQdip@Y
z46_|5y7Jc)(TmU8gbu$R-tzBICGzIoM12vpz6>~tj$(J}nX8*lw$JG?;A1bjtNS8)
zo#6^*D^uFE261vq4`Xk!$g?T$V^`q{FFWWtF{-7R~b`7#Q{Mp=>zKY
z()wUHifQ8>@tWi-VTc$b8I7CqKC0EUQ4*^@@wge{$Zg}PKD7;nczO2-nFQ)G)5w3Q
zd!AN2`mC*nIMkax&5iN4AEmc~EJ%w4g{BAZ*n!d7eOAk%yB6KCaL6o0JWU^K
zUt+;8I_dBL&-=q%0wcWXid!(WH!Pj%O%9rGZ(SXqV7>-Y+$w(bn3~MDlgS+1Ftmc`
zwL9S>D5dc$QD@q@rvSpX!B7>WIU2O&(zt(x;<3U3Gh<^7Lru+SGPz_v04J{YM`N6F
zurXSlqMN^H$WyqHcNx1mYOHFoW>5Ou9>?1@E3ERhOQ*H5f?A
zU|LdFRecqhurM!ZV^r}&DTB68h#92Gi}QjjiAY5$I!!)78B>D5;vlu|_I&@3XNcw<
zZmvWndcvjr4mTJ(3)sqqQzvu^Jm<$jLS#KFSDWV@O->FWGdRd94rh@jCxsKH<;J@!
zzJ0vq5*X6ScY;7I;0o@o?rbxXU$TF&wT=nOujw@>-0Kgz49=-=Jc^AX6?C{CiZm@K
zzH6vep+dTU<=+P%;7qq)y011U$aQMIA!?){u6_|CpU{eBG)%8P-z0twYZ_3!pa-ii
zA{7!0LCM)*TllzbrMANzelJ$32Rifz8^b1Q#?~!E=E5i20GJG1)zdkIrQVxmQXYjk
zGxci0Pt4LmsZPned%_Woba>tQp>`I{0+)*H+Sge@_wj3Eu=+c(>ji?=r`SRwo%b$M
z=MivNPT5Uc-V2n~Z4@4}FJR0l8-a_`ie3;X0DN6qSupz=E)2C%t)f0?8lsKldR6jx
ziX_H;wfGFlEn1m}|Doi)qqhNub%T_us3(;HDQJ=NlZ-&-lL&u7@tEuFl=Db(6S8gQ
z<92H-(Y1O~eYxQ%xi}BW=k6Z5G8I1A4HVT;An#gr^k|LJ82bPwswp(AGdhSA7NZgj
z#|N62k%|MFLmU*=i)q&+UbkSbvfII=yMZ7Jg~B1|K>lB?DO+DzXY?V+7O2C7dXGT8V1W6WWU_WUrVCa+iRYH^`ZqsyZH2w*{W0;o+44JDrH@?i
zys0@!*21sTO;J)w;H^HI4DLLP2NI51&CNh90aQh8XtFy(w%X3Va2-p`Xq+6F?EWI=
ztR^V3QZJb_DiR|m)PgZ=7tmh01cgGoo?hDf7emDv8g;BM5qa~PVB$N|oKn|*F;*rR
zqqG)X8I1OuXkVe>A!@u(VrOU3QeVCik-WMNU&phoVZp0;d!ENr3r8#Q)JDl=4%197
zR9?Tz8b%9kKAAEraYA=W-_rBv^GGogW*=n1P{SWP;BDLgyFpM8^L4#L*XMCrY4g$H
z(%2w}0>g1JgdcELP!Jo=d%95m6u!>`?v%J&UTnRp4z4P_{guLa7c8v0jS(X6$34lO
z=jbu`+0KQnZr*I=#bh5doyy9^)(f2bG0DK;L4eS$Co^b{SWs$>5pO(mg3T-$Q#|#!
zkW#>qc6BBX^~<^$IrqTA>MBFflQ+jEA~wR;s2Ik<*bqKn*?=>MvezW(#_CWv1TPI`z@UEXx$B4B-iLZ(56oOtJ)+V9j
zMvPfF@l!@kmT`G@R$k1R89%%(NG*unKORs0%ulF{$i1|v`3M1EMT~s|WA@Mjea8xS
zQ%4%83@uRB0=y70Ab?%+lS*5onlT;K
zQl1SPxrVlmNVDpHgUau1Bm~IzWn9hdMY?UQ^Lm^tg__m=n+(dAgd{>gDwuWIEIQ*L
zqi>u5?lcOSD#3P_KQ99d7tFm%7*QiYPdHlHPppF}Z+CyM*_SMIeT_ToPCNcE3Hp)u
zWp`U>{GS+M-BkP9P~Q4fk5}U-(Sb;N2GM!xwaSoJqQ8wbsd$<6)^;0lV2`43xUgdz
zX|(Q;dJCa*cWFf=wK;#Q&AL}`fC7C1e|w?=qWI?wz?<~tY8-Y?fncuPpYd9(#I+Zs
zAHZIpVnivy>wc|oLR66bo9D-j(r6MII}DWn
ztSK^Cq|O2o(;2tBUvu;`?e(VSL;uaNI}&QKtWVAU0Fjj4vhu4v3mLJ=^S+G<<*l9PEAZY0_}^X?lIaaXrUeL
zGJPeC^2x{U^Ioyl)gu#7BJT~x42bUA>l
zMoJG6u56Tpcqh(M8YSwb3ddZX6QzOjX@^@KTUrQ?VFT^>FQ3UY8|9&7+ulp4TP9W0xup$#&adraZRf|)E!~!c^86Y6DB^%7$SEYRw$pJ}jzuy`D=7X#V5IP2>N%37*r8DdQyEoULMo;u=sW@%
zI4u=pKu4wsWoLq0_^hqF0G}UNB>$ciysGg&T@>UjT`-0mo2aklNtsdlV8M@^fg>3X
z_N;o5>=tQSXt%>N*Pg3xuh2ALZ`HR8Tjk}0B?MPu
zjf{D3PLrTth3hSRDDiEb@etfy@n|BM3Wx3xb{o-3y!ann+e!+@kb;T%&0E(!{Ak-j
z5l)DFLJf!K2V8LO<37``1rq%Acui!nMfQ^q1R&l
zoFV{jwVVZNqEMh5_Mbx*qvWnd0G+YFx-CbrzQ4Zt<-edpL?qqZo&gk@fhhmbM&0bE
zvg`egGTR=XpuoG~aFEYdHTQvxpUS-_zI6_s2L3bh0cGDCdH>GXz5x*U4VwBxVfmYE
zkv+5@L;trH@(0_jf1ih4Ei0=vQqc2XmuU2MpehVVdAjw-$?~7cQ-JzQxGZ5T))%-s
zFsKYf*$5lDv*L99M&k5ieHa*Ar0D50_m?l|_+q43_fJP}px3hRpA7PC08kP9$6@CG
z@oSd9E+~>&AP|uKLhk8k$a!d{{QFY8iU$~h^c2TBN6d;r9KpW?=gKZ
z-W~?JnIiX!e{2H%zYEhjoyu@AV?!nWG=c$u2za0mesIA_GpK3Ea%Ya#Ld&z+%$J_z
zKH0eu!-n|yR2L`|VN32(=gCd!L2hteHNPS?iI;rdI>uAV{(L-lM3KA>=B3%DrT_@ZhMw68|EP
z9yJW(EUr-oBNHAeUbK~J?kL(ap^}fgt<98eAr2B1lFh2OW;W9YZ{uDzr*#AnG|D+jBjW
z8$EZ(O4${ctF({x{_f;tFXNk9s}jbXouWJzm3B22orrXYuxDN_4Rg6g8E|(lbhF5t
z$Nyx?_gc#kqD5hjIMKM~Ab%{sw2=bLr>&f~RjR)?d`>>!#S5DJc;3{mF5}3kR;fYQ
zbXpUoescPjzTZSm(IFuN*u+{tQTc;Uh-C6nKbYR?_!f$yA5QKP>ZVDZQ(JQ
zA#&**dzc<0<2Xf%4cbn}y9VhoE7clW7q;CMxpCtsS*MPb(YIBC-nT5e3P`~nVpM#E
zPCL2R^6HzYzXZu0;`x+HHLu2ENzkHZ7tU$NwSJYZP4@&p5&fN+Z9vZKJ~P_)+IL88
zVQmt7z1(Oovuk20t#&%REi11r-t$tl_Kp`x5fxhSu^9i00%{X^%s@Ge7jErhWrg5E
zw}=2cC>FRs^*;^LlZdtgEnanpOUqZE+01=`Q`#^qC}-tWTf@mpk~o!cZMSsa;m$L+
zzIYe-iGvCX#Bp`#%N(NNbOg=qT4aR_DnwLdPwme%Fk`fKQdt>%V6>sW;KGbL+{uGAHj
zA8^p}a13EWjFrHNt%I31%ocKzzpsK?vmrtFg&FiuWV5dV=;f6CWD7aJQJZu+kxgBCye@F*Zd
zkPJ_5+}PM^_;_CrRn?}`rz2XMx&2Fn-T4%{U#irl(3^GuJ)A@L0x?SE=g0xvOt&{Q
zXgsc+Q>rvlh$~Ke|GS!NMbuvq3oc&W)y?}oDc;AJo7Utq9-p~N6bEeiQ{;2iN?EDP
z!E2cbrS(dG!wH5t-Hhw%
zmlnB?pXPjGyG|}1t-q?oZT0D(OtjD%j7N{?I_TFMtOslsna}zeQrok@=$mJJI5S3K
z4J{U$VujcG0KtX2Bgr*pu<+`0Q}41f5Qn(u5(1rV26p$~pkzoH+d
zcJ`C&Xr%oc;!0Q@kddAH8DE1oQ}8