02-Traffic_management/README.md

@@ -1,23 +1 @@
-# Examples
-
-(almost) ALL NEEDS DOCUMENTATION / REVIEW
-
-- 01-2_deployments_method
-- 02-DirectResponse-HTTP-Body
-- 03-HTTPRewrite
-- 04-HTTPRedirect
-- 05a-FaultInjection-delay
-- 05b-FaultInjection-abort
-- 06-mTLS  (would need some documentation review, mainly go over the differences respective to the template/prior configuration used)
-- 07-HTTPS-Gateway-Simple-TLS   <- Doesn't respect the changelog format.
-- 08a-HTTPS-min-TLS-version
-- 08b-HTTPS-max-TLS-version
-- 09-HTTPS-backend
-- 10-TCP-FORWARDING
-- 11-TLS-PASSTHROUGH
-- 12-HTTP-to-HTTPS-traffic-redirect    -> Documented.  
-
-
-
-This will need some reorganization.
-
+This gloves the resources `Virtual Service` and `Destination Rule`

04-Backends/09-HTTPS-backend/README.md

@@ -5,7 +5,7 @@ include_toc: true
 
 # Based on
 
-- [08a-HTTPS-min-TLS-version](../08a-HTTPS-min-TLS-version)
+- [08a-HTTPS-min-TLS-version](../../03-Gateway_Ingress/08a-HTTPS-min-TLS-version)
 
 # Description
 
@@ -197,7 +197,7 @@ spec:
 ```
 
 > **Note**:\
-> As this configuration is very board, and targets the whole namespace, I would strongly recommend referring to the following example [06-Internal-Authentication/02-target-service-accounts](../../06-AuthorizationPolicy/02-target-service-accounts), which shows how to target service accounts set to resources, limiting the scope of this rule set.
+> As this configuration is very board, and targets the whole namespace, I would strongly recommend referring to the following example [06-Internal-Authentication/02-target-service-accounts](../../08-AuthorizationPolicy/02-target-service-accounts), which shows how to target service accounts set to resources, limiting the scope of this rule set.
 
 # Walkthrough
 

10-mTLS_PeerAuthentication/01-disable-mTLS/README.md

@@ -558,7 +558,7 @@ On this scenario, we met a fatal error, not allowing us to access the service, u
 
 From my understanding, not only from this interaction, but from investigating through Istio forums (yet I don't have the link handy, so take this words with some grains of salt), **the traffic cannot be double terminated**, for such if we have an `HTTPS` backend, we might require to disable `mTLS` in order to communicate with it. We also would need to set a [Destination Rule like we did further above](#destination-rule), to specify that the traffic must be terminated with the backend (`tls.mode: STRICT`).
 
-Yet this depends on which would be our architecture, due also being able to set up [TLS Passthrough](../../02-Traffic_management/11-TLS-PASSTHROUGH), or use a [TCP Forwarding](../../02-Traffic_management/10-TCP-FORWARDING).
+Yet this depends on which would be our architecture, due also being able to set up [TLS Passthrough](../../03-Gateway_Ingress/11-TLS-PASSTHROUGH), or use a [TCP Forwarding](../../03-Gateway_Ingress/10-TCP-FORWARDING).
 
 ```shell
 curl 192.168.1.50/https-mTLS

90-MixConfigs/06-HTTPS-Gateway_Service_Entry/README.md

@@ -8,7 +8,7 @@ The page used as a destination is my own [GitHub page](https://github.com/).
 
 # Based on
 
-- [05-hello_world_1_Service_Entry](../../02-Traffic_management/05-Service_Entry)
+- [05-hello_world_1_Service_Entry](../../04-Backends/05-Service_Entry)
 
 # Configuration
 
@@ -75,7 +75,7 @@ The path `/external` will forward the request towards the destination URL `githu
 
 Highlight that the destination is `github.com`, which is the same as the contents set on the field `host` from the [ServiceEntry resource configured above](#serviceentry).
 
-As seen [in the previous example, where the host that didn't have the `HOST` header wasn't able to receive a response by the destination](../../02-Traffic_management/05-Service_Entry/#external-noh), we configured the `HOST` header to match the URL from the external service.
+As seen [in the previous example, where the host that didn't have the `HOST` header wasn't able to receive a response by the destination](../../04-Backends/05-Service_Entry/#external-noh), we configured the `HOST` header to match the URL from the external service.
 
 ```yaml
 apiVersion: networking.istio.io/v1alpha3
@@ -108,7 +108,7 @@ spec:
 
 ## DestinationRule
 
-As seen in the example [02-Traffic_management/09-HTTPS-backend](../../02-Traffic_management/09-HTTPS-backend), where we configure Istio to use an `HTTPS` backend, the same configuration is applied on this case (yes, I am aware that a `ServiceEntry` is also a backend).
+As seen in the example [02-Traffic_management/09-HTTPS-backend](../../04-Backends/09-HTTPS-backend), where we configure Istio to use an `HTTPS` backend, the same configuration is applied on this case (yes, I am aware that a `ServiceEntry` is also a backend).
 
 For such, we deploy a `DestinationRule` setting to expect to terminate the TLS traffic, for the traffic with resource destination `github.com`, and port `8443`, which matches the settings set in our [ServiceEntry](#serviceentry) deployed.