ref: https://engineering.hellofresh.com/ambassador-the-evolution-of-ingress-gateway-at-hellofresh-3889232cab6f
本篇文章是 HelloFresh 這個美國生鮮食材訂購服務想要分享其團隊中 Ingress gateway 的演化史。該團隊過往使用 VM 作為其底層基礎架構來部署應用程式，後來遷移到
kubernetes 改用容器來部署，然而其內部的其他元件並沒有隨者 kubernetes 轉移而一併更新，譬如文章要探討的 Ingress gateway。
因此文章後將探討原先的 Ingress gateway 架構以及相關問題，最後如何將其與 kubernetes 進行整合來解決前述問題。
再使用 kubernetes 之前，團隊使用兩種不同的方式來處理，分別是內部 API Gateway Janus 以及網頁處理的 Entry (基於 Nginx 的 Reverse-Proxy)
團隊遷移到 kubernetes 之後，這兩個服務都想要透過 kubernetes Nginx Ingress 來處理，不過處理的過程中卻遇到一些問題。
1. 一致性: 每個微服務一開始都透過 Ingress 讓外界存取，然而當團隊開始使用 istio 後有些服務就改使用 Istio Ingress-Gateway 來處理，其他想要使用 TCP 的服務則會改使用 AWS ELB 來處理。
2. 延遲性: 因為 API Gateway 的存取節點都是基於 FQDN 的方式來存取，所以每個封包都要經過更多的節點來到達最終目的，這會增加整個封包傳輸時間。
最大的困惱還是第一個一致性的問題，k8s中有太多的方式讓外界可以存取期服務，每個都有自己獨特的設定，監控以及警示。
為了針對這些問題去解決，團隊內部先期構思一下到底什麼是團隊中理想的 Ingress Gateway
1. Reverse Proxy (HTTP) for websites
2. Mixture of an API Gateway
3. Kubernetes native
4. Advanced routing : (headers, methods, path)-based
5. JWT scope validation
6. Reliability features: Rate-limiting, Retries, Circuit breaking
7. Traffic shadowing
8. Interface for extensions
9. Integration with service mesh
後續文章包含了一些內容，如
1. 作者接者談談為什麼不使用 Service Mesh 所提供的 Ingress gateway
2. 到底要自行開發還是購買解決方案?(最後選擇了 Ambassador Edge Stack)
3. 如何透過 Ambassador Edge Stack 來解決團隊問題
4. 透過 Ambassador Edge Stack 後帶來的好處
有興趣的別忘了參閱全文
