本文是 Kubernetes Ingress Controller 選型指南系列部落格中的第一篇。 我們將向您介紹 Ingress Controller 的基礎知識，以及如何明智地選擇符合當今和未來的功能與安全性需求的控制器。
1.Ingress Controller 選型指南，第一部分：確定需求（本文）
2.Ingress Controller 選型指南，第二部分：評估風險和技術前瞻性（即將發佈）
3.Ingress Controller 選型指南，第三部分：開源、默認和商用版本能力對比（即將發佈）
4.Ingress Controller 選型指南，第四部分：NGINX Ingress Controller 選項（即將發佈）
首次使用 Kubernetes 的企業通常不會在 Ingress Controller 的選擇上花太多心思。 他們可能認為Ingress Controller 都大同小異，並且為了快速啟動和運行，最方便的就是直接使用當前 Kubernetes 框架預設的 Ingress Controller。的確，幾乎任何 Ingress Controller 在測試環境或小規模生產環境中都表現尚可。 但隨著業務集群規模的不斷擴大，您對 Ingress Controller 的選擇將變得愈發重要。 這是因為Ingress Controller 不僅限於提供將流量從 A 點移動到 B 點的基本功能。
通過提供高級流量管理、可視化及內置的安全防護，Ingress Controller可以成為 Kubernetes 堆棧中最強大的工具之一。 事實上，F5 NGINX 認為它是任何生產級 Kubernetes 部署的基礎。 但是，許多開發人員和平臺運營團隊都沒有認識到 Ingress Controller 的全部功能，也沒有意識到選擇一個無法擴展的控制器所帶來的後果。 如果您選擇的 Ingress Controller 無法有效地擴展或無法保護複雜的環境，那麼您的Kubernetes 可能無法從測試環境順利進入生產環境。 在本系列部落格中，我們將向您介紹 Ingress Controller 的基礎知識，以及如何明智地選擇符合當今和未來的功能與安全性需求的控制器。
什麼是 Ingress Controller？
Ingress Controller 是一種專用的負載均衡，用於管理進出Kubernetes 集群的四層和七層流量。 明確這一點後，我們來看看 NGINX 使用的術語（與業界所用術語基本相同）：
- 入向流量（Ingress traffic） — 進入 Kubernetes 集群的流量
- 出向流量（Egress traffic） — 離開 Kubernetes 集群的流量
- 南北向流量（North‑south traffic） — 進出 Kubernetes 集群的流量（也稱為“入向到出向的流量”）
- 東西向流量（East‑west traffic） — 在 Kubernetes 集群內的服務之間移動的流量（也稱為“從服務到服務流量”）
- 服務網格（Service mesh）— 一種針對服務到服務的流量進行路由和保護的流量管理工具
為什麼需要 Ingress Controller？
默認情況下，Kubernetes pod（容器）中運行的應用無法通過外部網路來訪問，只能通過 Kubernetes 集群内的其他 pod 訪問。Kubernetes 有一個用於 HTTP 負載均衡的內置配置對象，叫做 Ingress。不同的pod 可能由一個或多個 Kubernetes service代表，而 Ingress 則定義了 Kubernetes 集群外部的實體連接這些pod的方式。
當您需要向外部提供對 Kubernetes service的訪問時，您可以建立一個 Ingress 資源來定義連接規則，包括 URI 路徑、後端 service 名稱及其他資訊。 然而，Ingress 資源本身不執行任何操作。 您必須通過部署和配置 Ingress Controller 應用（使用 Kubernetes API）來實施在 Ingress 資源中定義的規則。
Ingress Controller 有何作用？
- Ingress Controller 會接受來自 Kubernetes 環境外部的流量，可能對其進行修改（塑造）並將其分發到在 Kubernetes 環境內部運行的 pod。 它取代了預設的 kube-proxy 流量分發模式，為您提供了額外的控制——就像是應用交付控制器 （ADC） 和反向代理在非 Kubernetes 環境中所提供的那類控制。
- 監控服務的各個 pod，確保智慧路由，防止請求“黑洞（black-holed）”。
- 實施出向規則，通過雙向 TLS （mTLS） 增強安全性，或限制從某些 pod 流向特定外部服務的出站流量。
在選擇 Ingress Controller 時，很多人可能會先看功能。 但這很容易導致最終選擇的 Ingress Controller 徒有花俏的功能，卻不能滿足實際的業務需求。 因此，您必須要了解影響您的團隊和應用能否有效使用Ingress Controller 的兩個要素：用例（要解決的問題）和資源（投入的成本）。 接下來我們將重點討論這兩個主題。
您希望 Ingress Controller 解決什麼問題？
Ingress Controller 的核心用例是流量管理，因此您可能想要 Ingress Controller 處理以下一個或多個常見用例：
- 負載均衡（HTTP2、HTTP/HTTPS、SSL/TLS 卸載、TCP/UDP、WebSocket、gRPC）
- 流量控制（速率限制、斷路、主動健康檢查）
- 流量分流（路由除錯、A/B 測試、灰度部署、藍綠部署）
但是大多數 Ingress Controller 可以做的不僅僅是管理流量，所以我們沒必要僅盯著這一項功能。Ingress Controller 能夠解決多種問題，不僅可以説明您減少堆疊的規模和複雜性，而且還可以將非功能需求從應用卸載到 Ingress Controller 上。 我們來看看四個非傳統的 Ingress Controller 用例，它們可以説明您提高 Kubernetes 部署的安全性、敏捷性和可擴充性以及資源的利用率。
➢監控和可視化
Kubernetes 集群可視性的缺乏是生產環境面臨的最大挑戰之一，因為這增加了故障排除和恢復的難度。 由於 Ingress Controller 在 Kubernetes 集群的邊緣運行並處理所有流量，它們能夠很好地提供一些數據來説明您解決（甚至避免）兩個常見的問題：Kubernetes 集群或平臺中的應用運行緩慢和資源耗盡問題。 為了提高可視化，Ingress Controller 需要：
- 即時提供指標，以便您可以「即時」診斷當下出現的問題
- 能夠將指標匯出到常用的可視化工具（例如 Prometheus 和 Grafana），繪製隨時間變化的數值，以説明您預測流量激增及其他趨勢
➢API 閘道
除非您希望在 Kubernetes 中執行請求回應操作，否則 Ingress Controller 很可能會兼作您的 API 閘道。 Ingress Controller 能夠提供核心 API 閘道功能，包括 TLS 終止、用戶端身份驗證、速率限制、精細的存取控制以及四至七層的請求路由，具體取決於它的功能特性。
➢身份驗證和單點登錄
通過將登錄憑證的身份驗證從 Kubernetes 服務卸載到 Ingress Controller，您可以解決兩個問題：
- 實施採用 OpenID Connect （OIDC） 的單點登錄 （SSO），允許使用者使用一組憑證登錄多個應用。
- 消除為每個應用構建身份驗證功能的需求，讓您的開發人員可以專注於應用的業務邏輯。
- Web 應用防火牆集成
準確地說，並不是 Ingress Controller 可以充當 Web 應用防火牆 （WAF），而是Ingress Controller可以和WAF集成。 儘管 WAF 可以部署在 Kubernetes 內外的許多地方，但對於大多數企業而言，最高效且最有效的部署位置是 Ingress Controller 所在的 pod。 此用例非常適合安全策略由 SecOps 或DevSecOps 指導的情況，也適合需要細粒度、按服務或按 URL 進行防護的案例。 這意味著您可以使用Kubernetes API 來定義策略並將它們與服務相關聯。 此外，Ingress Controller 基於角色的訪問控制 （RBAC） 功能支援 SecOps 按監聽器實施策略，並支援 DevOps 使用者為每個 Ingress 資源設置策略。
如何為 Ingress Controller 分配資源？
每個 Ingress Controller 都會產生成本，即使那些免費的開源控制器也不例外（您可能聽說過這個比喻：”就像養一隻免費的小狗一樣”）。 有些成本是預算中可預測的成本，有些成本則取決於您的團隊需要花費多少時間來處理您所選的 Ingress Controller 帶來的一系列問題（更多的複雜性、缺乏可移植性等問題）。 我們來看看在確定 Ingress Controller 預算時需要考慮的成本：時間和資金。
➢時間成本預算
確定人員預算可能比確定固定的專案成本更難，尤其是當您嘗試為不熟悉的領域分配項目資源。 您需要思考幾個問題：
- 誰負責配置和管理 Ingress Controller ？ 這是他們的專職工作（例如作為平臺運營團隊的成員）還是兼任的職責（作為開發人員）？
- 您的員工是否有時間接受正規培訓？或者您是否要求工具必須簡單易學，以便快速輕鬆地用於工作？
- 您是否準備好讓員工在需要新功能時進行修補，或者在出現問題時花大量時間進行解決？ 或者您是否需要他們來提供其他業務價值？
關於 Kubernetes 工具擁有權的說明
我們觀察到業界有一種趨勢，即在 NetOps 團隊的領域內整合工具和擁有權。 雖然這有助於簡化堆疊和提高安全性，但我們提倡根據團隊目標考慮選擇的工具。 NetOps 團隊專注於更廣泛的平臺，因此讓他們管理周邊工具（如外部負載均衡器）合情合理，而 DevOps 團隊最關心靠近應用代碼部署的服務，並且需要比 NetOps 工具更高的敏捷性和更細粒度的控制。 所以DevOps 選擇 Kubernetes 工具（包括 Ingress Controller ）最有可能取得成功。 但是這並不是說您必須完全放手讓開發人員自由選擇工具！ Kubernetes 中一些嚴苛的工具標準化要求依然是最佳實踐。
➢資本成本預算
首次使用 Kubernetes 的企業通常不會在工具或支援上投入太多預算。 如果您擁有足夠的人力資源來支援需要更多「人工操作」的 Ingress Controller，那麼初期可以不考慮資本成本預算。 但隨著Kubernetes 投資的增加，您可能會發現工具的功能不夠用，或者想要將團隊劃撥到其他優先事項。 這時，大家開始購買更易於使用、更穩定且具有企業級功能和支援的工具來進行擴展。
請注意，到了花錢這一步，許可模式就變的很重要。 Ingress Controller 採用的是不同於 Kubernetes 的傳統定價模式，通常”按實例”或”按 Ingress 代理”定價。 有時也可考慮”按集群”付費，這意味著您將根據應用租賃而不是”代理數量”購買 Ingress Controller 許可。
以下是我們針對不同場景的建議：
- Kubernetes 新手?選擇按集群許可。
如果您缺乏 Kubernetes 使用經驗，便很難準確預測您需要的 Ingress Controller 實例的數量。 如果非要選”按實例”的話，那麼您可能會低估實例數量，從而難以實現目標;或高估實例數量，浪費了本可以在Kubernetes 專案的其他部分發揮作用的資金。 為「小集群」爭取一個相對較低的固定價格將會增加您成功的機會。
- 正打算擴展 Kubernetes集群？ 選擇按集群許可。
您可能很難預測 Kubernetes 資源（激增和驟減）的調整規模和頻率。 在按實例模式下，您的團隊必須要設定任意閾值，確保不超出許可上限。 而在按集群許可中，您不需要跟蹤各個 Ingress 容器，並且取決於廠商（例如 NGINX），即使流量激增您也可能無需額外付費。
- 高級部署或靜態部署？ 選擇按實例許可。
如果您對 Kubernetes 足夠精通，準確地知道將如何使用 Ingress Controller和在每個集群中使用幾個 Ingress 代理，並且不需要Ingress Controller可能附帶的任何捆綁服務，那麼按實例模式可能是一個不錯的選擇。
下一步行動：風險承受能力和未來需求洞察
現在您已經瞭解了自己的需求，接下來是判斷整個團隊對 Ingress Controller 的風險承受能力，並弄清楚隨著 Kubernetes 部署的增長，您需要如何擴展 Ingress Controller。 我們會在即將發佈的第二部分中討論這些主題。
作者：Jenn Gile
職位：NGINX 產品營銷經理