今天這篇文章也是一個入門介紹文，雖說是一個入門介紹文，但是我覺得期主題滿好的，主要是針對 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
資訊定義 在 東吳創意思考社- 收集完資訊、定義出需求 - Facebook 的推薦與評價
收集完資訊、定義出需求、想出點子、做出原型後，我們要問「這個真的能夠讓問題得到改善嗎？」所以我們要回到使用者的身上，讓他們親自測試並給予回饋。 ... <看更多>