Service Proxy & Edge Proxy
矽谷牛的耕田筆記前言
今天來談 Kubernetes 上所用的幾種不同形式的七層代理（非 kube-proxy )，凡是 Kubernetes 上所有的流量都會經過幾層代理。
舉例來說：客戶端發送請求，進到 Kubernetes 上，經過第一層 Ingress 根據路由由代理轉發至某 Service 之後由 kub-proxy 打進應用的 Pod 內。最後再由這個 Pod 發送請求出去 Kubernetes Cluster 到外部上游 API Servers 時又經過了一層代理轉發。
在 Service Mesh 的範疇裡，中間更經過無數的代理做中轉，可見代理的角色在 Service Mesh 上十分重要，對 Service Mesh 有興趣的朋友不妨也可以參考看看。
代理
首先我們將根據代理的工作模式劃分為兩種常見的代理，兩種工作模式我們一言以敝之
我們常見的正反向代理應用在各種地方:
- 正向代理 (Forward Proxy)：組織或公司內部員工電腦 (客戶端) 所配好的內部 Proxy 用來訪問外網，IT 做到內部訪問外網控管，客戶端快取減少公司訪外頻寬等。Ex: 老牌的 Squid
- 反向代理 (Reverse Proxy)：公司對外提供某服務其服務端前面所配好的 Proxy 用來應對眾多客戶端請求做 LB ，服務端因為前面有一層代理作為單一入口，因此可以將服務器做水平擴展，根據其負載均衡演算法支撐大型流量。Ex: 常見的 HAProxy, NGINX, Envoy
上述兩種代理依照他們部署所在位置，即部署時皆會擺放在流量進出口地方 (Edge)，又會把它們稱為 Edge Proxy，放在 Service/Application 旁邊 (Sidecar) 又會把他們稱為 Service Proxy
回到前言的例子中，我們可以看到有兩種代理可能存在這個例子裡：
客戶端發送請求，進到 Kubernetes 上，經過第一層 Ingress 根據路由由代理轉發至某 Service 之後由 kub-proxy 打進應用的 Pod 內。最後再由這個 Pod 發送請求出去 Kubernetes Cluster 到外部上游 API Servers 時又經過了一層代理轉發
- Edge Proxy
- 第一層 Ingress 可以視為 Reverse Proxy 的一種，不論你使用哪一種 Ingress Controller 作為代理其作用在提供一個單一入口，必要時提供負載均衡。
- Pod 發送請求出去 Kubernetes 出口 (Egress) 流量可能因為某些安全策略需求，必須讓外部的 API Servers 是同一台 IP 訪問，此時就會配上 Forward Proxy 作為訪問白名單。
2. kube-proxy (非本文所討論的範圍)
- 如果沒有引入 Service Mesh 其在 Kubernetes 內部的流量(In-cluster traffic)都是由 (kube-proxy) 做轉發及負載均衡，屬於網路層 (Network Layer) 的 LB 及轉發。
3. Service Proxy
- 引入 Service Mesh 其流量在 不同應用 Pod 之間中轉，是本篇想討論的主題之一，即透過 Service Proxy 做轉發，屬於應用層 (Application Layer) 的 LB 及轉發，最後定義下流量的方向，俯瞰 Cluster 流量。
流量
Kubernetes 流量也根據其方向性，主要分成兩種：
- 南北向流量 (North/South traffic): 進出 Kubernetes Cluster 的流量，通常會經過 Edge Proxy
- 東西向流量 (East/West traffic): In-Cluster Pods 之間的流量，通常會經過 kube-proxy 或 Service Proxy
總結
以上可以理解 Edge Proxy 部署位於流量進出口處，負責處理南北向流量且根據其工作模式又可以分為正反向代理 ，而 Service Proxy 部署位於 Service/Applications 旁(sidecar)，負責處理東西向流量。
進階的 Edge Proxy 除了根據路由導引流量、負載均衡更提供用戶認證、ACLs ，南北流量統計... 等功能，而 Service Proxy 則根據使用哪一款 Service Mesh 的產品有不同特色，常見的東西向流量的 Traffic Split、 Traffic Metrics 更有請求超時重試、熔斷、mTLS ... 等功能。
下集預告
常見的 Service Proxy & Edge Proxy 應用於 Service Mesh 或 Ingress 中 ?