You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+7-20Lines changed: 7 additions & 20 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -43,37 +43,24 @@ Istio configures an envoy proxy using a set of
43
43
We can hook into this mechanism and insert additional configuration, which
44
44
further limits the access to a specific cluster.
45
45
46
-
Broadly speaking, there are three different external traffic flows:
46
+
Broadly speaking, there are two different external traffic flows:
47
47
48
48
1. Kubernetes API Listener (via SNI name)
49
-
1. Kubernetes Service Listener (internal flow)
50
-
1. VPN Listener
49
+
2. Apiserver-Proxy / Reversed-VPN Listener
50
+
51
+
*Please note that this changed with [GEP-30](https://github.com/gardener/gardener/blob/master/docs/proposals/30-apiserver-proxy.md) as the dedicated Kubernetes Service Listener for the apiserver-proxy was removed.*
51
52
52
53
These ways are described in more detail in the aforementioned GEP. Essentially,
53
-
these three ways are all represented by a specific Envoy listener with filters.
54
+
these two ways are all represented by a specific Envoy listener with filters.
54
55
The extension needs to hook into each of these filters (and their filter chains)
55
-
to implement the desired behavior. Unfortunately, all three types of access
56
+
to implement the desired behavior. Unfortunately, all types of access
56
57
require a unique way of handling them, respectively.
0 commit comments