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 後帶來的好處
有興趣的別忘了參閱全文
「ingress nginx」的推薦目錄:
- 關於ingress nginx 在 矽谷牛的耕田筆記 Facebook 的最佳解答
- 關於ingress nginx 在 矽谷牛的耕田筆記 Facebook 的最讚貼文
- 關於ingress nginx 在 矽谷牛的耕田筆記 Facebook 的最佳解答
- 關於ingress nginx 在 Welcome - NGINX Ingress Controller - Kubernetes 的評價
- 關於ingress nginx 在 NGINX Ingress Controller for Kubernetes - GitHub 的評價
- 關於ingress nginx 在 Adding Headers to NGINX Ingress using ConfigMap not working 的評價
- 關於ingress nginx 在 mandatory.yaml - GitHub 的評價
- 關於ingress nginx 在 Kubernetes Ingress: NGINX Explained - YouTube 的評價
ingress nginx 在 矽谷牛的耕田筆記 Facebook 的最讚貼文
本篇文章是一個深度介紹文,除了探討 K3S 與 K3D 的關係之外,還針對 K3D 的架構與使用方法很詳細的介紹一番,包含了
1. K3D v3 的特色與架構
2. 如何替換 K3D 裡面的 CNI
3. 如何替換 k3D 預設的 Ingress Controller
4. 使用 private registry 來處理
Kubernetes 的變化版本很多,除了 k3s 之外後來還有 k0s 的出現,每個版本都有自己想要解決的問題,而 k3s 則是一個非常輕量的 Kubernetes 版本,其特色有
1. 使用 Flannel 作為其預設 CNI,不講求太多複雜功能,單純用 VXLAN 打造一個 L2 的 overlay 網路
2. 使用 CoreDNS,與原生一樣
3. 使用 SQLite3 當作預設的 DB,而非 etcd3
4. 使用 Traefik 當作預設的 Ingress Controller,原生 K8s 則把這個主動權交給使用者
5. 使用 Containerd 當作預設的 Container Runtime
而 K3D 就是基於 K3S 的測試環境, K3S in Docker,跟 KIND 類似,只是運行的 Kubernetes 發行版本不同。
相較於 KIND 而已, K3D 的架構稍微複雜一點
1. 為了方便測試與存取,k3D 部署的時候也會部署一個 Nginx Server 來當作簡易的 Load-Balacner,讓 K3D 內的 Ingress 服務可以更簡易的被存取。使用者只需要存取該 Load-Balancer 即可,不需要去針對 Node(Docker) 的 IP 存取
2. 可以支援動態加入與刪除節點
本篇文章算是非常詳細的介紹各種參數用法,對於 K3D 這種測試環境有興趣的可以參考看看
https://yannalbou.medium.com/k3s-k3d-k8s-a-new-perfect-match-for-dev-and-test-e8b871aa6a42
ingress nginx 在 矽谷牛的耕田筆記 Facebook 的最佳解答
今天這篇文章也是一個入門介紹文,雖說是一個入門介紹文,但是我覺得期主題滿好的,主要是針對 Ingress 這個架構來探討。我個人認為 Kubernetes 的架構加上 Yaml 安裝一切的結果很容易導致大家其實不知道 Kubernetes 做了什麼,也不知道架構到底是什麼,總之 Yaml 寫寫功能就通了。因此如果本來對於 Ingress 背後含義與架構的讀者是可以參考這篇文章重新複習一下對於 Ingress/Ingress Controller 的差異與概念。
Ingress: 其實從抽象層面來看, Ingress 就如同過往使用的 reverse proxy 一樣,根據不同的方式來轉發不同的請求封包到不同的後端服務。然而這個抽象概念於 Kubernetes 被拆分為二,分別為資訊定義端以及真正實作端。
舉例來說,假如我們採用 Nginx 作為 Ingress 的解決方案
資訊定義端(Ingress Yaml Definition): Ingress 的物件描述,也就是大家最常看到的 Ingress Yaml 資源格式,這個格式是由 kubernetes 所定義,本身沒有任何實作功能,完全是一群規則的描述。
真正實作端(Ingress Controller): 負責將 Ingress 物件轉換成 Nginx.conf,並且動態的告知 Nginx 伺服器去載入最新的設定檔案
這也是我們為什麼都要先安裝一個 deployment之類的服務到 k8s 之中,該 deployment 會扮演 Ingress Controller 的角色
接者我們根據需求部署各種 Ingress 規則到系統中,然後先前部署的 Ingress Controller 就會去抓取這些資源,並且轉換成真正可行的 nginx.conf 這種資源
本文使用的是 Kong 這套解決方案,但是整體運作邏輯跟上述提到用 Nginx 的邏輯一樣,因為這邊遵循的都是 k8s Ingress 的運作模式,因此只要搞懂其背後邏輯,未來學習任何一套解決方案的時候,都會有相同的脈絡跟模式可以參考,比較不會瞎子摸象的感覺
原文: https://medium.com/swlh/kubernetes-ingress-simplified-e0b9dc32f9fd
ingress nginx 在 NGINX Ingress Controller for Kubernetes - GitHub 的推薦與評價
ingress -nginx is an Ingress controller for Kubernetes using NGINX as a reverse proxy and load balancer. Learn more about Ingress on the main Kubernetes ... ... <看更多>
ingress nginx 在 Welcome - NGINX Ingress Controller - Kubernetes 的推薦與評價
On clusters with more than one instance of the Ingress-NGINX controller, all instances of the controllers must be aware of which Ingress object they must serve. ... <看更多>
相關內容