我們的 EKS 架構中有使用 appmesh ，但其實在規模及架構的評估下，我們並不需要用到這麼複雜，這邊來做個整理

Pod 間的溝通

想像一下，我們寫了兩個服務， Generally 各別放在兩個 pod 中。他們之間的溝通很簡單，靠著各自的唯一的內部 IP 地址(Pod 在創建時都會分配一個)即可。但 pod 總是被開開關關，所以 Kubernetes 為一組具有相同功能的 Pod 提供一個穩定且可靠的接入點。服務會為其後端 Pod 提供一個固定的虛擬 IP 地址以及 DNS 名稱。這使其他 Pod 可以通過服務名稱進行發現和連接，而無需關心單個 Pod 的 IP 地址。

但在某些特定時候，僅僅只是讓流量可以進入到對應的 pod 並不能滿足我們的需求。像是金絲雀部署（Canary Deployment）、A/B 測試和故障注入等流量路由和管理。

什麼是 service mesh

想像今天我們在每個 pod 的流量進入前，新增一層 layer(關卡、或是轉介人)，這層 layer 有一個 king of layer 在管理，確保流量進入 pod 之前我們可以做更多事情，這就是 Service Mesh。

Service Mesh 是一種基於微服務架構的獨立通信層，用於管理服務之間的通信。在 Service Mesh 中，代理（通常稱為 sidecar 代理）中攔截並將流量引導至相應的目的地。這種方法使您能夠集中管理和控制流量，而無需修改或編排您的應用程序本身。

沒有 service mesh 的世界

如果沒有 service mesh，會變得很麻煩，以下舉例：

1. 金絲雀部署：可以使用 Kubernetes 自定義資源（Custom Resource Definition, CRD）如 Argo Rollouts 或 Flagger 實現金絲雀部署。
2. A/B 測試：利用 Kubernetes 的 Ingress 資源，結合 Ingress 控制器（如 Nginx ingress controller 或 Traefik），以及按需進行自定義配置和權重分配實現 A/B 測試。
3. 故障注入：這個場景較為複雜，在不使用 Service Mesh 的情況下，您可能需要在應用層面引入第三方庫以模擬故障或網絡延遲。

如何實踐 service mesh

Service Mesh 解決方案包括：

• Istio: 這是一個開源的 Service Mesh，可以與 Kubernetes 和其他平台集成。Istio 提供了豐富的特性，如流量管理、安全性、觀察性和策略執行。
• Linkerd: 也是一個開源的 Service Mesh，專注於輕量級與高性能。與 Istio 相比，Linkerd 通常具有更簡單的運行和學習曲線。
• AWS App Mesh: 如上所述，App Mesh 是 Amazon Web Services（AWS）提供的一個託管 Service Mesh 解決方案，專為 AWS 服務（例如 Amazon EKS、AWS Fargate 和 EC2）而設計。