九月線上研討會精彩大爆發，周周提供如何適應數位轉型的關鍵議題!免費報名．精彩任你看！
2021/9/17 l 14:40 l【NGINX DevOps 講堂 - 從入門到精通】第十五堂
精選議題： NGINX 安裝與設定 - Ｗeb server 反向代理與負載平衡】
講師陣容：陳廣融 / F5 台灣區 資深技術顧問
內容摘要：NGINX Plus 是唯一提供軟體型態的負載平衡器、API 閘道、內容快取和 網站伺服器等功能於一體的軟體。動態、快速移動您的應用程式從未如此輕而易舉。模組化特性使您能調整以獲得最高效能，與任何 CI/CD 無縫整合交付的能力可實現自動化。在本次線上研討會中，我們透過實際操作演示帶您安裝和配置 NGINX，以作為 Web 服務器反向代理與負載平衡。
在本次網絡研討會中，我們將介紹：
• 如何安裝 NGINX 並驗證它是否正常運行
• 如何將 NGINX 配置為反向代理、Web 服務器和負載平衡器
• 關於零停機配置重新加載
• 如何透過內置的即時活動監控儀表板監控您的 NGINX Plus 生態系統
了解更多：https://webinar.ithome.com.tw/
上線好禮：每日準時上線連續超過 45 分鐘，前 150 名即可獲得【7-11 $45元拿鐵咖啡購物金】

ref: https://lwn.net/Articles/853637/

如果對 SO_REUSEPORT 這個能夠提供網路服務吞吐量的 socket options 不陌生的話，那這篇文章強烈推薦看看。
本篇文章是從討論開啟 SO_REUSEPORT 這個選項會出現的一些行為以及可能可以怎麼做

最直得看的應該是留言區本身，有很多不同層級的討論，大家最愛講的 Google SRE 人也都出來分享自己的經驗了。

正常情況下，每個 TCP Port 只能被一個 process 給使用來聽取封包，但是對於一些網路重度使用的系統來說，就算讓該 process 將連線給分散到其他的 process 去處理，該 process 依然可能是系統的效能瓶頸。
Linux Kernel 3.9 後引入的 SO_REUSEPORT 參數就是為了解決這個效能問題而來的，這個參數允許多個 Process 同時使用一個 TCP Port，每當底層有一條新的連線請求時， Kernel 會從眾多的候選人之一中挑選一個可用來處理。
這種情況下，網路應用程式就可以專心處理連線工作，然後實務上同時執行多個 Process 即可。底層的 Kernel 會幫忙做連線的負載分配。

當眾多候選 process 其中之一掛掉了(可能是 crash，也有可能是有意的重啟)， kernel 會注意到這個候選人要說掰掰，這候選人處理的所有 connection 都會被移除，比較糟糕的是其他待在 Accept-Queue 那些還沒被建立連線的連線請求也會一併被移除。
作者認為 Kernel 應該要有能力可以轉移那些 Accept-queue 中的連線到其他還工作的候選 process 下去處理，這樣使用者/Client 的連線就不會需要處理太多重連的問題。

文章後面都在探討可行的做法以及這個問題可能會導致什麼問題。

留言區滿熱鬧的，譬如說
1. 有人認為 server 重啟的情況實在太少見，有需要為這麽少見的情況導入這麼複雜的修改到 Kernel 中?
a. 有人回答使用 Let's Encrypt 你可能每幾週就要重啟一次。
b. Google SRE 回答其內部因為調整設定的緣由，幾乎無時無刻都需要重啟服務，不過這問題已經從別的層級去處理掉，所以修改 Kernel 對他們的用途不太大。
2. 有人提出 Nginx 本身有 live migration 的功能，可以將 fd 給轉移到其他的 process 去處理。
a. 有人提出這邊談的是 socket/connection 的層級，這些東西都還沒發生到 userspace process 同時也不是 userspace 應用程式可以接觸處理的。
b. 本文探討的是 bind(), accept(), listen() 這類型 function call 之間 kernel 會幫忙做的事情。

有興趣的別忘了閱讀留言區

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 後帶來的好處

有興趣的別忘了參閱全文