Kubernetes Ingress簡單入門

做者：Nick Ramirez

原文連接：https://thenewstack.io/kubernetes-ingress-for-beginners/

本文轉載自Rancher Labs

不知道你是否注意到一個奇怪的現象，儘管Kubernetes Ingress API仍然處於beta狀態，可是已經有許多公司使用它來暴露Kubernetes服務。從事相關項目的工程師表示，Kubernetes Ingress API愈來愈有可能摘下其beta標籤。實際上，Kubernetes Ingress API處於beta狀態已經持續了幾年的時間，準確來講，是在2015年秋季開始進入該階段的。可是，漫長的beta階段可讓Kubernetes貢獻者有時間來完善規範並使其與已經搭建好的實施軟件（HAProxy、NGINX、Traefik等）保持一致，從而使API標準化以反映最多見而且有需求的功能。

隨着該功能GA的臨近，那麼如今應該是一個合適的時機能夠幫助新手快速瞭解Ingress的工做方式。簡而言之，Ingress是一個規則，能夠繪製出在集羣內部的服務如何彌合鴻溝，暴露到客戶可使用它的外部世界。同時，稱爲Ingress controller的代理在集羣網絡的邊緣進行偵聽（監視要添加的規則），並將每一個服務映射到特定的URL路徑或域名以供公衆使用。在Kubernetes維護者開發API的同時，其餘開源項目也實現了Ingress Controller併爲其代理添加了本身的獨特功能。

在本文中，我將介紹這些概念，並幫助你瞭解Ingress模式背後的驅動力。

路由問題

在Kubernetes中建立Pod時，須要爲其分配selector標籤，如Deployment manifest的如下片斷所示：

該Deployment建立了運行Docker鏡像my-app的三個副本，併爲其分配app=foo標籤。除了直接訪問Pod，一般將它們分組在Service下，這使它們能夠在單個集羣IP地址上使用（可是隻能在同一集羣中使用）。Service充當抽象層，隱藏了pod的週期短暫特性，能夠隨時增長或減小或替換它們。它還能夠執行基本的循環負載均衡。

例如，如下Service定義收集全部帶有selector標籤app = foo的Pod，並在其中平均路由流量。

可是，只能從集羣內部以及運行在附近的其餘Pod訪問此服務。Kubernetes Operator正在努力解決如何爲集羣外部的客戶端提供訪問權限。該問題在早期就已經出現，而且將兩種機制直接集成到Service規範中進行處理。編寫service manifest時，包括一個名爲type的字段，該字段的值爲NodePort或LoadBalancer。這是一個將類型設置爲NodePort的示例：

NodePort類型的服務使用起來很簡單。本質上，這些服務但願Kubernetes API爲他們分配一個隨機的TCP端口，並將其暴露到集羣以外。這樣作的方便之處在於，客戶端可使用該端口將集羣中的任何節點做爲目標，而且他們的消息將被中轉到正確的位置。這就相似於你能夠撥打美國境內的任何電話，而接聽電話的人都會確保爲你轉接到合適的人。

缺點在於，該端口的值必須介於30000到32767之間，雖然這個範圍安全地避開了經常使用端口地範圍，可是與常見的HTTP端口80和HTTPS 443相比，該端口顯然不是很標準。此外，隨機性自己也是一個障礙，由於它意味着你事先不知道值是什麼，這使得配置NAT、防火牆規則更具挑戰性——尤爲是須要爲每項服務設置不一樣的隨機端口。

另外一個選項是將類型設置爲LoadBalancer。可是，這有一些前提條件——僅當你在GKE或EKS之類的雲託管環境中運行而且可使用該雲供應商的負載均衡器技術時，它纔有效，由於它是自動選擇並配置的。其缺點是比較昂貴，由於使用這種類型的服務會爲每一個服務啓動一個託管的負載均衡器以及一個新的公共IP地址，這會產生額外的費用。

Ingress路由

分配一個隨機端口或外部負載均衡器是很容易操做的，但也帶來了獨特的挑戰。定義許多NodePort服務會形成隨機端口混亂，而定義許多負載均衡器服務會致使須要支付比實際所需更多的雲資源費用。這些狀況不可能徹底避免，但也許能夠減小它的使用範圍，甚至你只須要分配1個隨機端口或1個負載均衡器就可以暴露許多內部服務。所以，這一平臺須要一個新的抽象層，該層能夠在入口點（entrypoint）後面整合許多服務。

那時，Kubernetes API引入了一種稱爲Ingress的新型manifest，它爲路由問題提供了新的思路。它的工做方式是這樣的：你編寫一個Ingress manifest，聲明你但願客戶端如何路由到服務。manifest實際上並不自行執行任何操做，你必須將Ingress Controller部署到你的集羣中，以監視這些聲明並對其執行操做。

與其餘任何應用程序同樣，Ingress controller是Pod，所以它們是集羣的一部分而且能夠看到其餘Pod。它們是使用在市場上已經發展了多年的反向代理搭建的，所以，你能夠選擇HAProxy Ingress Controller、NGINX Ingress Controller等。底層代理爲其提供了第7層路由和負載均衡功能。不一樣的代理將本身的功能集放到表中。例如，HAProxy Ingress Controller不須要像NGINX Ingress Controller那樣頻繁地從新加載，由於它爲服務器分配了slot，並使用Runtime API在運行時填充slot。這使得該Ingress Controller擁有更好的性能。

Ingress Controller自己位於集羣內部，與其餘Kubernetes Pod同樣，也容易受到同一「監獄」的「監禁」。你須要經過NodePort或LoadBalancer類型的服務將它們暴露到外部。可是，如今你只有一個入口點，全部流量都將經過此處：一個服務鏈接到一個Ingress Controller，Ingress Controller依次鏈接到許多內部Pod。Controller具備檢查HTTP請求的功能，能夠根據其發現的特徵（例如URL路徑或域名）將客戶端定向到正確的Pod。

參考這個Ingress的示例，該示例定義了URL路徑/foo應該如何鏈接到名爲foo-service的後端服務，而URL路徑/bar被定向到名稱爲bar-service的服務。

如上文所示，你依舊須要爲你的Pod設置服務，可是你不須要在Pod上設置類型字段，由於路由和負載均衡將由Ingress層處理。服務的做用被簡化爲以通用名稱對Pod進行分組。最終，兩個路徑，/foo和/bar，將由一個公共IP地址和域名提供服務，例如example.com/foo 和 example.com/bar 。本質上，這是API網關模式，在API網關中，單個地址將請求路由到多個後端應用程序。

添加Ingress Controller

Ingress manifest的聲明式方法是你能夠指定所需的內容，而無需知道如何實現。Ingress Controller的工做之一是執行，它須要監控新的ingress規則並配置其底層代理以制定相應的路由。

你可使用Kubernetes包管理工具Helm安裝HAProxy Ingress Controller。首先，經過下載Helm二進制文件並將其複製到PATH環境變量中包含的文件夾（例如/usr/local/bin/）中來安裝Helm。接下來，添加HAProxy Technologies Helm庫，並使用helm install命令部署Ingress Controller。

經過運行命令kubectl get service列出全部正在運行的服務來驗證是否已建立Ingress Controller。

HAProxy Ingress Controller在集羣的pod中運行，並使用NodePort類型的Service資源發佈對外部客戶端的訪問。在上面顯示的輸出中，你能夠看到爲HTTP選擇了端口31704，爲HTTPS選擇了端口32255。你還能夠在端口30347上查看HAProxy信息統計頁面。HAProxy Ingress Controller會提供有關流經它的流量的詳細指標，所以你能夠更好地觀察到進入集羣的流量。

在controller建立類型爲NodePort的服務時，這意味着須要分配一個隨機的端口而且端口編號每每很高，可是如今你只需管理幾個此類端口，也就是隻需管理鏈接到Ingress Controller的端口，無需再爲每一個服務建立一個端口。你也能夠將其配置爲使用LoadBalancer類型，只要在雲端進行操做便可。它看起來以下：

整體而言，不須要管理太多Ingress Controller。安裝後，它基本上會在後臺執行其工做。你只須要定義Ingress manifest，controller就會當即將它們鏈接起來。Ingress manifest的定義與引用的服務有所區別，所以你能夠控制什麼時候暴露服務。

結 論

Ingress資源經過容許API網關樣式的流量路由，整合了外部客戶端如何訪問Kubernetes集羣中的服務。代理服務經過公共入口點（entrypoint）進行中轉，你可使用intent-driven、YAML聲明來控制什麼時候以及如何公開服務。

當Ingress API這一功能GA以後，你必定會看到這種模式變得愈來愈流行。固然，可能產生一些細微的變化，主要是爲了使API與現有controller中已經實現的功能保持一致。其餘改進可能會指導controller如何繼續發展以符合Kubernetes維護者的願景。總而言之，如今是開始使用此功能的好時機！