NodePort、LoadBalancer、Ingress controller（Ingress 控制器） ……，Kubernetes 元件簡直令人眼花繚亂。
當我們與客戶和社區討論生產級 Kubernetes 部署時，他們經常會問的一個問題是：我需要 Ingress controller 嗎？ 這個問題不能簡單地用“是”或“否”來回答，我們要先瞭解將流量路由到 pod 的幾種不同方式。
本文介紹了 Kubernetes 網路的基礎知識，可説明您就是否以及何時需要 Ingress controller 做出明智的決策。
Kubernetes 提供了多種方法和層級用於將外部流量路由到 pod —— 但它們各有不同。 默認的模型是kube-proxy，不過它既不是代理，也不是為實施流量負載均衡、控制 API 或監控 service 行為而設計。 幸運的是，我們還可以使用其他方法來管理外部流量。
但在展開討論之前，我們先來快速回顧一下 Kubernetes 元件：
- Kubernetes 部署由節點（node）組成，這些節點或為物理機或為虛擬機。
- 節點相互連接構成一個集群（cluster）。
- 每個集群都會管理pod。 從 Kubernetes 網路和基礎架構級別來看，pod 是可部署的最小計算單元。 一個或多個 pod 可構成一個 service。
- 每個 pod 內部都有一個或多個容器（取決於應用的大小）。
Kubernetes 負責監測構成 service 的 pod，並根據需要對其進行擴展以滿足應用的需求。 但是如何將流量路由到pod呢？ 這就要用到兩種類型的 Kubernetes 物件：service 和 Ingress controller。
什麼是 Kubernetes Service？
根據 Kubernetes 文件，一個 service 是「用於暴露運行應用的一組 pod的一種抽象方式」。 service 連接著一個集群或一個容器網路中的所有 pod，這使得 pod 在任意節點都不會有影響。 也就是說即使它們的位置發生變化，甚至被銷毀或重啟，外部流量也可以被路由到特定的 pod。 可以說 service 就像一個具有最基本功能的反向代理。
Kubernetes 中有多種類型的 service，而 service 物件的類型與將外部流量路由到 Kubernetes 相關。 不同類型的 service 物件經常被混淆，但實際上它們的功能大不相同，因此我們有必要回顧一下它們的功能、用途和缺點。
01 ClusterIP
ClusterIP 是預設的 service，它在 Kubernetes 內提供了集群內其他 service 可以訪問的 service。ClusterIP 不支援從集群外部訪問。 暴露 ClusterIP service 的唯一方法是使用 kube-proxy 之類的模型，但有必要這樣做的場景不多。 少數幾個這樣的情況包括訪問筆記型電腦上的 service、調試 service 或查看一些監控和指標。
02 NodePort
NodePort service 會在集群中的每個節點上打開一個特定埠，並將發送到該埠節點的任何流量轉發到相應的應用。 這是將流量路由到應用的一個非常基本的方法，但在實際的流量管理用例中，這種方法存在許多局限性。
比如每個 NodePort 只能對應一個 service，並且只能使用 30000 到 32767 範圍的埠。 2768 個埠雖然聽起來很多，但大規模運行 Kubernetes 的企業很快就能用完。
此外，NodePort 使用四層路由規則和 Linux iptables 實用程式，七層應用路由受限。 除了路由限制之外，使用 NodePort 還有三大缺點：
三大缺點
- 下游客戶端必須知道節點的IP位址才能與其連接 —— 如果節點的IP位址或虛擬機主機發生變化，則無法建立連接。
- NodePort 無法將流量轉發到多個IP位址。
- 如下圖所示，NodePort 沒有在 Kubernetes 集群中提供負載均衡，因此流量會被隨機分發給各個 service。這可能會導致 service 過載和埠耗盡。
03 LoadBalancer
LoadBalancer service 能夠接受外部流量，但需要使用外部負載均衡器作為該流量的介面。 在外部負載均衡器經過正確調試和重新配置，可映射到正在運行的 pod的前提下，LoadBalancer service 支援七層路由（即路由流量到 pod 的 IP 位址）。
LoadBalancer 是最受歡迎的對外暴露 service 的方式之一。 它在雲平臺中的使用最為廣泛，對於小型靜態部署環境來說是不錯的選擇。
如果您使用的是託管 Kubernetes service，那麼您會自動獲得雲供應商選擇的負載均衡器。 您暴露的每個 service 都有自己的公共 IP 位址來轉發所有流量，但這些流量並沒有經過任何過濾或路由，這意味著您可以發送幾乎任何類型的流量（HTTP、TCP/UDP、WebSocket 等）。
如果您不想使用雲供應商的工具（例如，如果您需要功能更強大或獨立於平臺的工具），那麼您可以換成類似於 F5 BIG-IP（作為外部負載均衡器）和 F5 Container Ingress Services（作為執行LoadBalancer 功能的 operator）這樣的工具。
有關此模式的進一步討論，請參閱我們的博文《在同一架構中部署 BIG-IP 和 NGINX Ingress Controller》。
在動態多變的環境中，應用的pod需要通過擴展來滿足不斷變化的需求。 在這種情況下使用LoadBalancer暴露應用就變得有挑戰性了。 由於每個 service 都有自己的 IP 位址，一個熱門應用可能需要管理數百甚至數千個 IP 位址。
在大多數情況下，外部負載均衡器可通過 NodePort 連接到 service（如下圖所示）——雖然這可以保證流量均勻地分發到各個節點上，但仍然無法對 service 進行負載均衡，因此仍然會出現 service 過載和埠耗盡的問題。
什麼是 Kubernetes Ingress Controller？
根據 Kubernetes 文件，「控制器 （controller） 是監控集群狀態的控制回路，能夠在需要時做出更改或請求做出更改。 每個控制器都會努力讓當前集群狀態接近所期望的狀態。 “控制器用於管理 Kubernetes 中許多種任務的狀態，包括正確分配資源、指定持久化存儲和管理 cron 作業。
在路由的上下文中，Ingress controller 能夠消除 NodePort 和 LoadBalancer 的局限性。
針對特定 service 的 pod，Ingress controller 用於配置和管理其外部交互。 Ingress controller 將動態七層路由視為“一等公民”。 這意味著 Ingress controller 能夠更輕鬆地提供更細粒度的控制和管理。 借助Ingress controller，您既可以輕鬆地控制入向流量，也可以提供 service 級的性能指標，並將其作為安全策略的一部分。
Ingress controller 還具有傳統外部負載均衡器的許多特性，例如 TLS 終止、處理多個域和命名空間，當然還有負載均衡流量。 Ingress controller 可以按請求而不是按 service 對流量進行負載均衡，因此能夠支援您更有效地監看七層流量並且更好地實施 SLA。
Ingress controller 還有一個優勢！ 它還可以執行出向規則，這些規則可以做到只允許來自某些 pod 的流量傳輸到特定的外部 service，或者確保使用 mTLS 對流量進行相互加密。 mTLS 加密對於在醫療、金融、電信和政府等行業提供受監管的服務至關重要，這也是端到端加密 （E2EE） 策略的關鍵組成部分。
控制來自同一工具的出站流量還能夠簡化業務邏輯在 service的應用。 當入向和出向可以在同一個控制平面中統一調配時，設置適當的資源規則就容易得多了。
下圖展示了 Ingress controller 是如何降低客戶端的複雜性的——用戶端不再需要知道 service 的 IP 位址或埠。 不同 service 之間的流量分發得到了保障。 一些 Ingress controller 支援多個負載均衡演算法，以獲得更好的靈活性和控制性。
部署帶有Ingress controller 的負載均衡器
正如我們在《在同一架構中部署 BIG-IP 和 NGINX Ingress Controller》 中所討論的，許多企業的案例都會因部署帶 Ingress controller（或在大多數情況下，多個 Ingress controller 實例）的外部負載均衡器而受益。
當企業需要擴展 Kubernetes 或在高度合規環境中運營時，這種部署尤為常見。 這些工具通常由不同的團隊管理並用於不同的目的：
負載均衡器（或稱 ADC）
擁有者：NetOps（也可能是 SecOps）團隊
用例：位於 Kubernetes 外部，作為唯一面向公眾的終端，為集群之外的使用者提供服務和應用。 作為一種更通用的應用，旨在提高安全性，並促進交付更高級別的網路管理。
Ingress controller
擁有者：Platform Ops 或 DevOps 團隊
用例：位於 Kubernetes 內部，支援細粒度的南北流量（HTTP2、HTTP/HTTPS、SSL/TLS 終止、TCP/UDP、WebSocket、gRPC）負載均衡、API 網關功能以及集中式安全防護和身份驗證。
下圖展示了負載均衡器處理跨多個集群流量分發的過程，同時集群部署了 Ingress controllers 來確保對service 的平均分發。
後續步驟
有關如何使用 Ingress controller 以及如何選擇最能滿足您需求的 Ingress controller 的更多資訊，歡迎閱讀我們的文章：
Ingress Controller 選型指南，第一部分：確定需求
Ingress Controller 選型指南，第二部分：評估風險和技術前瞻性