Move egress tasks to examples (#2106)

* add Advanced Egress Control section in Examples

* move egress gateway and egress tls origination tasks to advanced egress examples

* fix the links and replace task with example

content/docs/examples/advanced-egress/_index.md

@@ -0,0 +1,8 @@
+---
+title: Advanced egress traffic control
+description: A variety of fully working examples for egress traffic control in Istio that you can experiment with.
+weight: 61
+type: section-index
+keywords: [egress, gateway]
+page_icon: /img/examples.svg
+---

content/docs/examples/advanced-egress/egress-gateway/index.md

@@ -7,9 +7,9 @@ keywords: [traffic-management,egress]
 
 The [Control Egress Traffic](/docs/tasks/traffic-management/egress/) task demonstrates how external (outside the Kubernetes cluster) HTTP and HTTPS services can be accessed from applications inside the mesh. A quick reminder: by default, Istio-enabled applications are unable to access URLs outside the cluster. To enable such access, a [service entry](/docs/reference/config/istio.networking.v1alpha3/#ServiceEntry) for the external service must be defined, or, alternatively, [direct access to external services](/docs/tasks/traffic-management/egress/#calling-external-services-directly) must be configured.
 
-The [TLS Origination for Egress Traffic](/docs/tasks/traffic-management/egress-tls-origination/) task demonstrates how to allow the applications to send HTTP requests to external servers that require HTTPS.
+The [TLS Origination for Egress Traffic](/docs/examples/advanced-egress/egress-tls-origination/) example demonstrates how to allow the applications to send HTTP requests to external servers that require HTTPS.
 
-This task describes how to configure Istio to direct the egress traffic through a dedicated service called _Egress Gateway_. We achieve the same functionality as described in the [TLS Origination for Egress Traffic](/docs/tasks/traffic-management/egress-tls-origination/) task, only this time we accomplish it with the addition of an egress gateway.
+This example describes how to configure Istio to direct the egress traffic through a dedicated service called _Egress Gateway_. We achieve the same functionality as described in the [TLS Origination for Egress Traffic](/docs/examples/advanced-egress/egress-tls-origination/) example, only this time we accomplish it with the addition of an egress gateway.
 
 ## Use case
 
@@ -91,7 +91,7 @@ First direct HTTP traffic without TLS origination
     {{< /text >}}
 
     The output should be the same as in the
-    [TLS Origination for Egress Traffic](/docs/tasks/traffic-management/egress-tls-origination/) task, without TLS
+    [TLS Origination for Egress Traffic](/docs/examples/advanced-egress/egress-tls-origination/) example, without TLS
     origination.
 
 1.  Create an egress `Gateway` for _edition.cnn.com_, port 80, and destination rules and virtual services to
@@ -256,8 +256,8 @@ $ kubectl delete destinationrule egressgateway-for-cnn
 
 ## Perform TLS origination with the egress `Gateway`
 
-Let's perform TLS origination with the egress `Gateway`, similar to the [TLS Origination for Egress Traffic](/docs/tasks/traffic-management/egress-tls-origination/) task.  Note that in this case the TLS origination will
-be done by the egress Gateway server, as opposed to by the sidecar in the previous task.
+Let's perform TLS origination with the egress `Gateway`, similar to the [TLS Origination for Egress Traffic](/docs/examples/advanced-egress/egress-tls-origination/) example.  Note that in this case the TLS origination will
+be done by the egress Gateway server, as opposed to by the sidecar in the previous example.
 
 1.  Define a `ServiceEntry` for `edition.cnn.com`:
 
@@ -440,7 +440,7 @@ be done by the egress Gateway server, as opposed to by the sidecar in the previo
     ...
     {{< /text >}}
 
-    The output should be the same as in the [TLS Origination for Egress Traffic](/docs/tasks/traffic-management/egress-tls-origination/) task, with TLS origination: without the _301 Moved Permanently_ message.
+    The output should be the same as in the [TLS Origination for Egress Traffic](/docs/examples/advanced-egress/egress-tls-origination/) example, with TLS origination: without the _301 Moved Permanently_ message.
 
 1.  Check the log of the `istio-egressgateway` pod and see a line corresponding to our request. If Istio is deployed in the `istio-system` namespace, the command to print the log is:
 

content/docs/examples/advanced-egress/egress-tls-origination/index.md

@@ -9,13 +9,13 @@ The [Control Egress Traffic](/docs/tasks/traffic-management/egress/) task demons
 Kubernetes cluster, HTTP and HTTPS services can be accessed from applications inside the mesh. As described in that topic, by
 default Istio-enabled applications are unable to access URLs outside the cluster. To enable external access, a [`ServiceEntry`](/docs/reference/config/istio.networking.v1alpha3/#ServiceEntry) for the external service must be defined, or alternatively, [direct access to external services](/docs/tasks/traffic-management/egress/#calling-external-services-directly) must be configured.
 
-This task describes how to configure Istio to perform [TLS origination](/help/glossary/#tls-origination) for egress traffic.
+This example describes how to configure Istio to perform [TLS origination](/help/glossary/#tls-origination) for egress traffic.
 
 ## Use case
 
 Consider a legacy application that performs HTTP calls to external sites. Suppose the organization that operates the application receives a new requirement which states that all the external traffic must be encrypted. With Istio, such a requirement can be achieved just by configuration, without changing the code of the application.
 
-In this task, you configure Istio to open HTTPS connections to external services in cases the original traffic was HTTP. The application will send unencrypted HTTP requests as previously and Istio will encrypt the requests for the application.
+In this example, you configure Istio to open HTTPS connections to external services in cases the original traffic was HTTP. The application will send unencrypted HTTP requests as previously and Istio will encrypt the requests for the application.
 
 ## Before you begin
 
@@ -182,7 +182,7 @@ proxy needs to know exactly which host to access using HTTPS:
 
 ## Additional security considerations
 
-Note that the traffic between the application pod and the sidecar proxy on the local host is still unencrypted. It means that if an attacker was able to penetrate the node of your application, they would still be able to see the unencrypted communication on the local network of the node. In some environments a strict security requirement might exist that would state that all the traffic must be encrypted, even on the local network of the nodes. With such a strict requirement the applications should use HTTPS (TLS) only, the TLS origination described in this task will not be sufficient.
+Note that the traffic between the application pod and the sidecar proxy on the local host is still unencrypted. It means that if an attacker was able to penetrate the node of your application, they would still be able to see the unencrypted communication on the local network of the node. In some environments a strict security requirement might exist that would state that all the traffic must be encrypted, even on the local network of the nodes. With such a strict requirement the applications should use HTTPS (TLS) only, the TLS origination described in this example will not be sufficient.
 
 Also note that even for HTTPS originated by the application, the attacker could know that the requests to _cnn.com_ are being sent, by inspecting [Server Name Indication (SNI)](https://en.wikipedia.org/wiki/Server_Name_Indication). The _SNI_ field is sent unencrypted during the TLS handshake. Using HTTPS prevents the attackers from knowing specific topics and articles, it does not prevent the attackers from learning that _cnn.com_ is accessed.