move architecture docs #15010
move architecture docs #15010
Conversation
istio-testing
added
the
size/L
| @@ -11,15 +11,22 @@ test: n/a | |||
|
|
|||
There was a problem hiding this comment.
We can leave the path as /architecture but can we do:
description: A deep dive into the dataplane of ambient mode.
There was a problem hiding this comment.
This page will eventually be a header for the whole section, and not all of it will be about the data plane - some of it will be about the control plane implementation, I would think
There was a problem hiding this comment.
Ambient should not have any unique control plane "how it works" docs (or we are doing something wrong) - those should be shared across sidecar and ambient.
Dataplane docs will not be shared, and must be unique.
There was a problem hiding this comment.
I meant things more like "what labels you set"
There was a problem hiding this comment.
Yeah, the "labels you set" feels like they belong more in "usage" than "architecture" anyway tho - architecture is just "things you do not absolutely need to know to use or follow our usage guides but which you or your compliance teams might want to have an understanding of" in my head.
| @@ -321,7 +317,7 @@ $ kubectl -n istio-system logs -l app=ztunnel | grep -E "inbound|outbound" | |||
| --snip-- | |||
| {{< /text >}} | |||
|
|
|||
| Here note the logs from the ztunnel proxies first indicating the http CONNECT request to the new destination pod (10.240.1.11) which indicates the setup of the HBONE tunnel to ztunnel on the node hosting the additional destination service pod. This is then followed by logs indicating the client traffic being sent to both 10.240.1.11 and 10.240.2.10 which are the two destination pods providing the service. Also note that the data path is performing client-side load balancing in this case and not depending on Kubernetes service load balancing. In your setup these numbers will be different and will match the pod addresses of the httpbin pods in your cluster. | |||
| Here note the logs from the ztunnel proxies first indicating the http CONNECT request to the new destination pod (10.240.1.11) which indicates the setup of the HBONE tunnel to ztunnel on the node hosting the additional destination service pod. This is then followed by logs indicating the client traffic being sent to both 10.240.1.11 and 10.240.2.10 which are the two destination pods providing the service. Also note that the datapath is performing client-side load balancing in this case and not depending on Kubernetes service load balancing. In your setup these numbers will be different and will match the pod addresses of the httpbin pods in your cluster. | |||
There was a problem hiding this comment.
| Here note the logs from the ztunnel proxies first indicating the http CONNECT request to the new destination pod (10.240.1.11) which indicates the setup of the HBONE tunnel to ztunnel on the node hosting the additional destination service pod. This is then followed by logs indicating the client traffic being sent to both 10.240.1.11 and 10.240.2.10 which are the two destination pods providing the service. Also note that the datapath is performing client-side load balancing in this case and not depending on Kubernetes service load balancing. In your setup these numbers will be different and will match the pod addresses of the httpbin pods in your cluster. | |
| Here note the logs from the ztunnel proxies first indicating the http CONNECT request to the new destination pod (10.240.1.11) which indicates the setup of the HBONE tunnel to ztunnel on the node hosting the additional destination service pod. This is then followed by logs indicating the client traffic being sent to both 10.240.1.11 and 10.240.2.10 which are the two destination pods providing the service. Also note that the dataplane is performing client-side load balancing in this case and not depending on Kubernetes service load balancing. In your setup these numbers will be different and will match the pod addresses of the httpbin pods in your cluster. |
Suggestion (for me too) - we should settle on dataplane or datapath (or data plane/data path) - but not both.
There was a problem hiding this comment.
I think "data path" is different to "data plane", especially in the sidecar case. And yes I would love consistency; I did a quick Google to try and figure out what is most popular
There was a problem hiding this comment.
I might be thinking about it weirdly - to me they seem pretty synonymous in istio
- Dataplane in sidecar is HTTPS + sidecar envoy
- Dataplane in ambient is HBONE + ztunnel
the rest is redirection, which isn't relevant for the context here (or anywhere, outside of the redirection doc, and even then you can make the argument it should fall under dataplane)
IDC too much which one tho, if we can use one everywhere let's do it.
| @@ -183,7 +179,7 @@ This indicates the traffic path is working. The next section looks at how to mon | |||
|
|
|||
| ## Monitoring the ztunnel proxy & L4 networking {#monitoringzt} | |||
|
|
|||
| This section describes some options for monitoring the ztunnel proxy configuration and data path. This information can also help with some high level troubleshooting and in identifying information that would be useful to collect and provide in a bug report if there are any problems. Additional advanced monitoring of ztunnel internals and advanced troubleshooting is out of scope for this guide. | |||
| This section describes some options for monitoring the ztunnel proxy configuration and datapath. This information can also help with some high level troubleshooting and in identifying information that would be useful to collect and provide in a bug report if there are any problems. Additional advanced monitoring of ztunnel internals and advanced troubleshooting is out of scope for this guide. | |||
There was a problem hiding this comment.
| This section describes some options for monitoring the ztunnel proxy configuration and datapath. This information can also help with some high level troubleshooting and in identifying information that would be useful to collect and provide in a bug report if there are any problems. Additional advanced monitoring of ztunnel internals and advanced troubleshooting is out of scope for this guide. | |
| This section describes some options for monitoring the ztunnel proxy configuration and dataplane. This information can also help with some high level troubleshooting and in identifying information that would be useful to collect and provide in a bug report if there are any problems. Additional advanced monitoring of ztunnel internals and advanced troubleshooting is out of scope for this guide. |
Ztunnel traffic redirectionguide underConcepts/Architectureheadings #14993 (traffic redirection)