入口控制器：Kubernetes的瑞士軍刀

入口控制器可能看起來隻是Kubernetes領域中的一個小部件。許多人認為它們是低價值的商品，但實際上它們可以成為你堆棧中的一個強大工具。正确部署和配置後，入口控制器可以從根本上簡化Kubernetes叢集的運維，同時增強安全性并提高性能和彈性。

入口控制器通過其他工具或解決方案提供的許多功能來實作這一點。由于入口控制器是專門為Kubernetes設計的，是以它們可以更輕松地承擔這些功能，而不是試圖将現有的技術結構（如負載均衡器、API網關和應用程式傳遞控制器（ADC））調整到Kubernetes的奇特世界。入口控制器的多功能性是其如此強大的部分原因。

為什麼需要入口控制器？

入口控制器對于定義和管理Kubernetes中的入口（南北）流量至關重要，Kubernetes是一個比非Kubernetes應用程式更複雜的入口環境。

預設情況下，外部網絡和流量無法通路Kubernetes pod（和容器）中運作的應用程式。Kubernetes内部的pod隻能在它們之間進行交流。Kubernetes确實有一個用于HTTP（第7層）負載均衡的内置配置對象，稱為入口。此對象定義Kubernetes叢集之外的實體如何連接配接到标有一個或多個Kubernetes服務的pod。當需要提供對Kubernetes服務的外部通路時，可以建立入口資源來定義連接配接規則。這包括URI路徑、支援服務名稱和其他資訊。然而，入口資源本身不做任何事情。必須部署和配置入口控制器應用程式（使用Kubernetes API）以實作入口資源中定義的規則。

換句話說，你确實需要部署一個入口控制器來利用Kubernetes的現有資源和對象結構。不這樣做意味着要更加努力地使用服務對象和外部裝置的組合來建立更詳細的規則。無入口控制器方法不可擴充，成本昂貴，需要大量時間。

入口控制器如何使用（或替代）負載均衡器

入口控制器可以獨立工作以均衡和控制流量，也可以與負載均衡器一起工作以釋放Kubernetes的強大功能并提供更好的應用程式性能。

需要注意的是：“LoadBalancer”服務與專用負載均衡器不同。

入口控制器有時被描述為Kubernetes的“專用負載均衡器”。這就引出了一個問題：你需要負載均衡器和入口控制器嗎？答案是：視情況而定。有時你需要根據使用該工具的使用者和部署位置進行一些功能複制。

對于許多用例，特别是當要擴充Kubernetes或在高合規性環境中時，組織同時部署入口控制器和負載均衡器。盡管它們部署在不同的地方，用于不同的目的，由不同的團隊管理。

負載均衡器（或ADC）：

管理人：NetOps（或SecOps）團隊

部署：在Kubernetes之外，作為向叢集之外的使用者提供的服務和應用程式的唯一面向公衆的端點。用作更通用的裝置，旨在促進安全性并提供更進階别的網絡管理。

入口控制器：

管理人：平台運維或DevOps團隊

部署：在Kubernetes内部實作細粒度南北負載均衡功能（HTTP2、HTTP/HTTPS、SSL/TLS終端、TCP/UDP、WebSocket、gRPC）。讓應用程式團隊配置的某些方面，如URI或路徑，以及進階反向代理或API網關功能。

在這個圖中，負載均衡器處理多個叢集之間的流量分布，而叢集具有入口控制器，以確定服務的平均分布。

入口控制器=安全工具

入口控制器可以為應用程式安全提供一個粒度和內建的層，用于“左移”安全狀态，并更好地與應用程式團隊（而不是NetOps或全球安全團隊）使用的低級安全工具內建。

入口控制器可以成為安全武庫中的關鍵工具，幫助你将安全性轉移到左側，更好地滿足微服務和現代應用程式的需求和風險。入口控制器的一些關鍵安全優勢包括：

阻止通過配置不當的負載均衡器直接通路pod——入口控制器充當第二層通路控制，以防全局負載均衡器配置漂移到不安全的設定。

強制執行MTL——由于入口控制器設計為在節點和pod級别運作，并且是運作在服務之上的控制回路，是以它們是實施加密行為的最佳位置，最接近實際應用程式。

異常檢測和執行——入口控制器使處理異常（可能是不良行為的訓示）的邏輯規則變得更容易。在全球層面上，這些異常現象可能難以了解或衡量。盡管對于管理微服務的小型團隊來說，生成這種邏輯的最佳場所是DevOps和服務開發人員自己；他們知道自己的流量應該是什麼樣子，應該應用什麼規則。

與WAFs的更緊密內建——在大多數情況下，任何在Kubernetes部署生産應用程式的人都需要使用web應用程式防火牆（WAF）來保護應用程式和叢集。WAFs可以過濾壞流量并保護暴露的應用程式。這就是說，與異常檢測一樣，配置為在企業環境的全局級别進行保護的WAF就像鈍的工具，不适合在應用層實作更細粒度的安全性。是以，許多團隊現在在入口層的Kubernetes内部運作自己的WAF，并與全局WAF分開管理。這些特定于應用程式的WAF更易于在入口控制器級别進行管理、內建和配置，了解該應用程式的團隊可以在該級别設定入口/出口和安全政策。

入口控制器=API網關

入口控制器以Kubernetes原生方式結合了大多數API網關功能，在提高性能的同時降低了複雜性和成本。

采用入口控制器的最佳原因之一是成本節約和簡單。因為入口控制器是一個專門的代理，它有可能滿足更多傳統代理（負載均衡器/反向代理或ADC）可以實作的許多相同的用例。這包括許多負載均衡和API網關功能，例如：TLS/SSL終端、用戶端身份驗證、速率限制、重新啟動和逾時、細粒度通路控制、第4層和第7層的按請求路由、藍/綠和金絲雀部署、傳統協定（UDP、TCP）的路由、新協定的路由（gRPC）、标題和請求/響應操作、SNI路由、基于進階服務/pod健康規則的路由。

注意：“API網關”經常被當作一個獨特的産品來讨論。事實上，這是一組可以通過代理完成的用例。通常，負載均衡器、ADC或反向代理被實作為API網關。然而，在NGINX，我們越來越多地看到入口控制器和服務網格被用于API網關功能。

你不必在入口控制器和标記為API網關的工具之間找到功能奇偶性，這沒關系。在Kubernetes中，你實際上并不需要所有這些額外的功能，嘗試實作它們可能會帶來麻煩。Kubernetes中兩個最适用的API網關用例是流量管理（協定、整形、拆分）和安全性（身份驗證、端到端加密）。考慮到這一點，你需要一個入口控制器來處理以下事項：

方法級路由/比對；

身份驗證/授權解除安裝；

基于授權的路由；

協定相容性（HTTP、HTTP/2、HTTP/3、WebSocket、gRPC）。

開發人員會感謝你，因為入口控制器允許他們以Kubernetes原生方式（聲明式/指令式YAML）定義API網關或負載均衡器函數，這很容易适應他們的工作流。法律和财務團隊也會感謝您，因為成本更低，要跟蹤的許可更少。最後，客戶和使用者可以獲得更好的體驗，因為從流量路徑中删除額外的控制元素必然會帶來更好的性能。

入口控制器=可觀察性和監控性

入口控制器監控所有進出的流量，這意味着入口控制器有可能提供一個輕量級、內建且易于管理的監控和可觀察層。

因為它位于叢集前面，控制L4-L7流量和傳統或非HTTP協定流量，是以入口控制器有權檢視應用程式和基礎設施的運作狀況。這是強大和有用的。你可以輕松地将流量監控從現有的資料和控制平面擴充到可觀測工具，如Prometheus。事實上，大多數入口控制器都與著名的CNCF監控和可觀測工具（如Prometheus和Grafana）進行了原生內建。你可以使用入口控制器解決兩個用例：

慢速應用程式：如果你的應用程式速度慢或崩潰，具有實時監控功能的入口控制器可以幫助準确定位問題所在。每秒請求數低可能表示配置錯誤，而響應時間延遲可能表示上遊應用程式存在問題。

HTTP錯誤：如果叢集或平台資源不足，你可以使用入口控制器中的曆史資料來查找趨勢。這就是Grafana這樣的工具對于可視化資料特别有用的地方。

對于一些服務網格、負載均衡器和其他Kubernetes風格的網絡工具，建立監控和可觀察性會增加負載和延遲。此外，它們無法以與入口控制器相同的粒度級别解析流量。由于入口控制器不需要向配置檔案和Kubernetes堆棧添加額外的CRD或對象，是以可以避免不必要的複雜性和延遲。畢竟，部署的CRD越多，Kubernetes就越複雜。

結論：入口控制器不僅僅控制入口

希望現在你能更了解為什麼入口控制器是Kubernetes網絡的無名英雄，不使用它是一個錯誤。以下是一些注意事項：

并非所有的入口控制器都能夠服務于本文讨論的各種用例。NGINX部落格系列“入口控制器選擇指南”可以幫助你确定需求、避免風險、經得起未來考驗并在複雜的入口控制器環境中自如。

如果你的入口規則設計不好，并且pod資源不足，那麼入口控制器可能會減慢應用程式的速度。但是，如果設計好了規則，那麼在叢集邊緣安裝入口控制器的名義成本将隻是在性能方面所能實作的改進的一小部分。