摘要：本文是 Kubernetes Ingress Controller 選型指南系列部落格中的第二篇。
1.Ingress Controller 選型指南，第一部分：確定需求（☜已發佈）
2.Ingress Controller 選型指南，第二部分：評估風險和技術前瞻性（本文）
3.Ingress Controller 選型指南，第三部分：開源、默認和商用版本能力對比（即將發佈）
4.Ingress Controller 選型指南，第四部分：NGINX Ingress Controller 選項（即將發布）
歡迎閱讀 Ingress Controller 選購指南系列部落格的第二部分。 您現在已經確定了需求，但還不是測試產品的時候！ 在本部落格中，我們將向大家說明為何不合適的 Ingress Controller 將會降低您的發佈速度，甚至對客戶造成損失。 同其他工具一樣，Ingress Controller 也存在著風險並可能影響未來的可擴充性。 下面我們來看看如何避免做出弊大於利的選擇。
Ingress Controller 的風險
在選擇 Kubernetes 流量管理工具時，您應考慮三個特定風險：複雜性、延遲和安全性。 這些風險盤根錯節，往往牽一髮而動全身。 Ingress Controller 可能會引發其中的任何一個問題，能否容忍這些風險就要看企業自己的選擇了。 現在的消費者都很”薄情”，只要感到數據體驗不好，那麼無論功能多麼強大，他們也會一去不回頭。
►複雜性 —— Ingress Controller 是否與微服務架構的目標背道而馳？
能夠滿足微服務架構目標（設計簡單、輕量化）的工具才是一款好的 Kubernetes 工具。 開發一種功能豐富且遵循這些原則的 Ingress Controller是有可能的，但並不是所有時候都能如願。 設計人員有時會添加過多的功能，或使用複雜腳本來擴展底層引擎的非原生功能，導致 Ingress Controller 因不必要的複雜性而臃腫不堪。
為什麼必須要降低複雜性？ 在 Kubernetes 中，過於複雜的工具不僅會影響應用性能，而且還會限制您橫向擴展部署的能力。 我們通常可以通過大小來看複雜性：Ingress Controller 佔用空間越大就意味著其越複雜。
► 延遲 ——Ingress Controller 是否會減緩應用速度？
Ingress Controller 可能會因資源使用、錯誤和超時而增加延遲。 您需要了解靜態和動態部署中因Ingress Controller而增加的延遲，並根據您的內部需求消除導致延遲過長的相關選項。
► 安全性 ——Ingress Controller 是否為駭客提供了可乘之機？
在當今的互聯網中，通用漏洞披露 （CVE） 在如今的互聯網中十分猖獗，Ingress Controller 提供者提供 CVE 補丁的速度決定了 Ingress Controller 的安全性能。 根據企業的風險承受能力，您可能想要棄用補丁發佈時間超過幾天（或最多幾周）的解決方案。
除了 CVE 中的漏洞之外，一些 Ingress Controller 還會存在另一個潛在漏洞。 假設您為一家在線零售商工作，您的開源 Ingress Controller 的配置出現了問題，極需別人的説明。 由於沒有購買商業支援服務，您將問題發佈到了 Stack Overflow 等論壇。 有人向您伸出了援手，他想要看一下是否是 Ingress Controller 及其他 Kubernetes 元件的配置和日誌文件出現了問題。 迫於儘快解決問題的壓力，您共用了檔。
這個「好心人」幫您解決了問題，但六個月後公司遭到入侵了，客戶記錄里的信用卡號碼被盜了。 這是怎麼回事？ 原來是您共用的檔中包含一些資訊，被居心叵測的攻擊者用來入侵應用了。 這也恰好反映了企業選擇購買支援服務的主要原因之一：它能保證機密性。
►關於基於 OpenResty 的 Ingress Controller 的說明
OpenResty 是一個基於 NGINX 開源軟體構建的 Web 平臺，它包含了 LuaJIT、Lua 腳本和第三方NGINX 模組，可擴展 NGINX 開源軟體的功能。 市面上有幾種 Ingress Controller 是基於OpenResty 構建的，我們認為與我們基於 NGINX 開源軟體和 NGINX Plus 構建的 Ingress Controller 相比，它們可能會額外帶來兩個風險：
- 超時 —— 如上文所述，OpenResty 使用 Lua 腳本來實現高級功能，就像基於商用 NGINX Plus 的Ingress Controller 中的功能一樣。 其中一項功能是動態重新配置，這消除了 NGINX 開源軟體中原本會降低可用性的一項要求，即當服務端點發生變化時必須重新載入 NGINX 配置。 為了使OpenResty 能夠實現動態重新配置，Lua handler 需要選擇將請求路由到哪個上行服務，從而消除重新載入 NGINX 配置的需要。
但是，Lua 必須持續檢查後端的變更情況，十分消耗資源。 處理入站請求的時間延長，導致部分請求被擱置，從而增加了超時的可能性。 隨著使用者和服務規模的不斷擴大，每秒入站請求的數量與Lua 可以處理的請求數量之間的差距呈指數級擴大，最終導致延遲、複雜性和成本的增加。
- CVE 補丁延遲 —— 由於 OpenResty 實際上是基於 NGINX 開源軟體的，與 NGINX 團隊自己開發的 Ingress Controller 相比，CVE 補丁推送到基於 OpenResty 等工具的 Ingress Controller 中的時間更長，這一點無法避免。 當在 NGINX 中發現 CVE 漏洞時，我們作為廠商通常會在 CVE 公開披露之前得到通知。 因此，我們能夠在 CVE 發佈後立即發佈 NGINX 開源軟體和 NGINX Plus 的補丁。
在此之前，使用 NGINX 開源軟體的技術群體可能不會知曉這個 CVE 漏洞的存在。 根據我們的經驗，OpenResty 補丁的發佈時間比我們晚得多（最近一次晚了四個月）。 基於 OpenResty 的Ingress Controller 的補丁發佈時間不可避免的更滯後，這為攻擊者提供了可乘之機。
面向未來的 Ingress Controller
即使您只是剛開始使用 Kubernetes，您可能也希望有朝一日將其投入生產。 隨著時間的推移，您在基礎架構、安全性、技術支援和多租戶等四個主要領域的需求可能會有所增長。
►基礎架構 —— 您是否會在混合或多雲環境中使用 Kubernetes？
很少有企業會一直完全使用一種環境，反而是本地和雲端的混合環境更為常見。 這種環境一般包含私有雲、公有雲、混合雲和多雲。
我們在本系列部落格第一部分中提到過，企業一般會選擇每種環境預設的工具，但預設的 Ingress Controller 本身存在許多問題。 我們將在本系列部落格的第三部分討論這樣做的所有弊端，但與前瞻性最有關係的問題是廠商鎖定，即您無法在所有環境中使用特定雲廠商的 Ingress Controller。 使用預設的特定雲端工具將會影響您的擴展能力，因為您只有兩個毫無吸引力的替代方案：
- 嘗試讓現有的雲滿足所有需求
- 在每個新環境中重寫 Ingress Controller 的所有配置，不僅包括負載均衡，而且還包括安全防護！
第一種方案出於商業原因通常不可行，第二種同樣也很棘手，因為它會導致工具無序漫延、引發新的安全漏洞，並需要員工學習大量新知識。 第三種，也是最有效的替代方案，就是從一開始就選擇一種獨立於基礎架構的 Ingress Controller，以便在所有環境中使用相同的工具。
涉及到基礎架構，我們還要考慮認證這個因素。 我們以紅帽 OpenShift 容器平臺 （OCP） 為例。 如果您是 OCP 使用者，那麼您可能已經知道 Red Hat Marketplace 為 OCP 提供認證的operator，其中包括NGINX Ingress Operator。 紅帽認證標準意味著該工具適用於您的部署環境，甚至紅帽與廠商聯合提供支援，從而讓您高枕無憂。 出於安全性和穩定性的原因，許多企業都要求使用經過認證的工具，因此即使您目前只處於測試階段，牢記公司的生產環境要求也是有好處的。
► 安全性 ——您將如何從內部保護 Kubernetes？
僅靠邊界安全就足以保護應用與客戶安全的日子已經成為過去式。 現在，只有在靠近 Kubernetes 應用的地方實施安全防護（包括身份驗證和授權），才能為其提供最強大的保護。 隨著越來越多的企業在Kubernetes 中強制採用端到端加密方法和零信任網路模型，服務網格可能將會成為您未來計劃的一部分。
所有這些又與 Ingress Controller 有什麼關係呢？ 關係很大！ 成本和效率的角度來看，在 Ingress 中集中管理安全防護措施（身份驗證、授權、DoS 防護、Web 應用防火牆）具有重要意義。 雖然大多數服務網格能夠與大多數 Ingress Controller 集成，但它們的集成方式很重要。 符合您的安全策略的Ingress Controller 可防止您在應用開發過程中遇到重大問題。
► 支援 ——您「自力更生」的能力有多強？
對於只是試用 Kubernetes 的團隊來說，無論是來自社區或是公司的支援通常都不是最重要的。 因為如果您的團隊時間充足，就能夠制定自己的解決方案和應變方法。 但進入生產環境後，這就行不通了。 即使您現在不需要支援，您可以明智地選擇一種允許您在未來添加支援的 Ingress Controller，或者選擇一種價格經濟並且可以隨著您的擴展而升級的支援。
►多租戶 —— 多個團隊和應用如何安全可靠地共用容器環境？
企業發展之初，很多都只有一個團隊和一個應用。 隨著這個團隊成功開發出一個 Kubernetes 應用，企業開始在 Kubernetes 上運行更多服務。 當然，更多的服務意味著更多的團隊以及更高的複雜性。
為了最大限度地提高效率，企業採用多租戶和 Kubernetes 模型，以支援業務流程所需的訪問和隔離，同時提供運營商所需的安全性和控制力。 一些 Ingress Controller 可以通過多種功能和概念説明您劃分這些集群，其中包括支援設置基於角色的訪問控制 （RBAC） 的多個入口（ingress）、類（class）、命名空間（namespace）和限定資源（scoped resources）。
下一步行動：鎖定（縮小）選擇範圍
既然您已確定了您的需求、風險承受能力和前瞻性，那麼這說明您掌握了足夠的資訊，可以開始縮小Ingress Controller 的選擇範圍了。 您可以按類別劃分範圍，這有助於快速完成選擇，在本系列部落格的第三部分，我們將探討三種不同類別的 Ingress Controller 以及每種類別的優缺點。
作者：Jenn Gile
職位：NGINX 產品營銷經理