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 後帶來的好處
有興趣的別忘了參閱全文
jwt 問題 在 Re: [問題] 使用JWT 的時機- 看板NetSecurity - 批踢踢實業坊 的推薦與評價
※ 引述《CMJ0121 (不要偷 Q)》之銘言：
: 強者我朋友又問了我 JWT 的問題 每次提到 JWT 我都不能理解使用 JWT 的時機點
: 請問有大大可以分享使用 JWT 的時機點與好處嗎？
沒有大大願意回答我這個問題之餘 我又想到新的問題了 QQ
在使用 JWT 的前提之下 在瀏覽器端要把 JWT 存在哪邊比較適合呢？
上網查了一下 瀏覽器可以將資料存在 cookie / session storage / local storage
當然 有一派說法[0] 還是說放在 cookie
不知道有沒有大大可以現身說法一下呢
https://stackoverflow.com/questions/54258233/do-i-have-to-store-tokens-in-cookies-or-localstorage-or-session/54258744#54258744
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 106.1.229.215 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/NetSecurity/M.1582534295.A.97A.html
... <看更多>