Hello folks，我是 Luga，今天我們繼續來聊一下云原生生態領域相關的技術 - 云原生網關 Traefik ，本文將繼續聚焦在針對 Kubernetes 入口網絡體系技術進行剖析，使得大家能夠了解為什么常見的入口訪問以及如何更好地對利用其進行應用及市場開發。

一、關于 Kubernetes 入口網絡的一點簡要解析

眾所周知，Kubernetes 作為領先的容器編排平臺，為構建和管理分布式應用提供了強大的功能。然而，在不同的業務場景下，對網絡的需求也存在著差異。為了滿足這些差異化的需求，我們需要創建不同的 Kubernetes Cluster 網絡模式，以提供定制化的網絡解決方案。

通常情況下，Kubernetes 中的集群網絡需要滿足以下幾點核心要求，具體如下所示：

• 服務的安全和隔離：確保不同服務之間能夠相互隔離，并杜絕惡意訪問。
• Pod 的連接、網絡和 IP：為 Pod 提供網絡連接和 IP 地址分配，并支持動態分配和管理。
• 設置網絡以從多個物理集群部署集群抽象：將多個物理節點虛擬化為一個統一的網絡，方便應用的部署和管理。
• 跨服務的多個實例的流量負載平衡：將流量均勻分配到多個服務實例，提高系統的負載能力和可靠性。
• 控制對服務的外部訪問：限制對服務的訪問權限，保證服務的安全性。

在公共和非云環境中使用 Kubernetes 網絡：支持在不同的云環境中部署和運行 Kubernetes Cluster。

二、Pod 內訪問

針對一個有兩個節點的簡單 Kubernetes Cluster，當 Kubernetes 創建及運行一個 Pod 時，它會為該 Pod 構建一個獨立的網絡命名空間，提供了網絡層面的隔離環境。

在這個隔離環境中，Pod 可以像運行在獨立的服務器上一樣，擁有獨立的網絡棧，包括獨立的網卡、IP 地址、路由表、iptables 規則等。這種隔離機制確保了不同 Pod 之間的網絡流量互不干擾，保證了網絡通信的安全性和可靠性。

除了網絡隔離之外，Kubernetes 還為每個 Pod 分配了一個唯一的 IP 地址，使得 Cluster 內的所有 Pod 都可以通過 IP 地址相互訪問。這些 IP 地址可以是從專門的子網中靜態分配的，也可以通過 DHCP 等動態分配方式獲取，由集群自動管理。無論采用何種分配方式，Kubernetes 都會確保整個 Cluster 內不會出現 IP 沖突的情況，從而保證了通信的順暢和可靠。

具體可參考如下所示：

Pod 網絡的隔離性雖然保證了服務的安全性，但也給服務的訪問帶來了一定的挑戰。由于 Pod 內部的 IP 地址在 Cluster 外部是不可訪問，因此外部客戶端無法直接與該服務通信。這對服務意味著什么?服務在 Pod 網絡中的 Pod 內運行。在該 Pod 網絡上分配的 IP 地址(用于服務)在 Pod 外部則不可訪問。那么如何訪問該服務呢?

三、跨 Nodes 訪問

在實際的業務場景中，一個服務通常會由多個 Pod 實例組成，這些 Pod 可能分布在集群的不同節點上。比如，某個服務由兩個 Pod 構成，分別運行在兩個不同的物理節點上。當外部客戶端需要訪問該服務時，Kubernetes 如何在這兩個 Pod 之間進行負載均衡，確保請求能夠公平地分發到每個實例上呢?

Kubernetes 采用了 Cluster IP(集群 IP)的抽象機制來解決這個問題。具體來說，Kubernetes 為每個服務分配一個 Cluster IP，作為對外統一的入口點。當客戶端發起對該服務的請求時，只需要連接到這個 Cluster IP 即可，而不需要關心后端具體的 Pod 實例。

接下來，Kubernetes 會根據預先設定的負載均衡策略，將接入的請求流量分發到運行該服務的所有 Pod 實例上。常用的負載均衡算法包括基于權重的輪詢調度、最少連接調度等,用戶也可以根據自身需求自定義調度算法。無論采用何種策略，Kubernetes 都能夠確保請求流量在各個 Pod 實例之間合理分配，實現高可用和負載均衡。

值得注意的是，這種負載均衡過程對客戶端來說是完全透明的。客戶端只需連接集群 IP 即可，而無需關心后端 Pod 的實際分布情況。這不僅簡化了客戶端的訪問邏輯，也實現了服務的高度抽象化，將客戶端與底層基礎設施解耦。

Cluster IP (集群 IP)是 Kubernetes 實現服務發現和負載均衡的核心機制，其背后依賴于 kube-proxy 組件和一系列網絡技術的支持。

通過 kube-proxy、iptables/IPVS、網絡插件等多個組件的緊密配合，Kubernetes 為用戶提供了一個高度抽象且功能強大的服務網絡解決方案，既能夠實現高效的流量負載均衡，又支持豐富的網絡策略控制，真正釋放了云原生應用的潛力，推動了微服務架構的廣泛應用。

四、Cluster 外部訪問

ClusterIP (集群IP)提供了一種方便的方式來訪問運行在 Kubernetes Cluster 內的服務，但它默認情況下只能在集群內部訪問，對外部流量是不可見。這是出于安全性的考慮，避免服務被外部直接訪問而遭受攻擊。

但在某些場景下，我們可能需要將服務暴露給集群外部的客戶端訪問。比如，某些面向公網的 Web 服務，或者需要跨集群通信的微服務等。為了滿足這種需求，Kubernetes 提供了 NodePort 類型的服務。

NodePort 服務通過在每個節點上開放一個指定的端口，將集群外部的流量引入到集群內部，并通過 ClusterIP 將這些流量轉發到后端的 Pod 實例上。具體來說，當客戶端訪問任意一個節點的 NodePort 端口時，Nodes 會將該請求轉發到相應的 ClusterIP ，再由ClusterIP 進行負載均衡，將流量分發到提供該服務的所有 Pod 實例上。

這種模式相當于在集群的邊緣設置了一個入口網關，為外部流量提供了一個合法的入口點。與直接暴露服務的 ClusterIP 相比，此種方式提供了更好的安全性和靈活性。管理員可以精細化地控制哪些服務可以通過 NodePort 對外開放，同時，還可以根據需要調整 NodePort 的端口映射策略。

值得注意的是，NodePort 服務需要在每個節點上開放一個端口，這意味著該端口在集群的所有節點上都不可復用。為了避免端口資源的浪費，Kubernetes 會自動分配一個可用的高位端口(默認范圍為30000-32767)作為 NodePort。當然，用戶也可以根據實際需求自定義 NodePort 的端口號。

除了 NodePort 之外，Kubernetes 還支持 LoadBalancer 和 Ingress 等更為高級的服務暴露方式。LoadBalancer 服務通過云服務商提供的負載均衡器，為服務提供一個外部可訪問的IP地址;而I ngress 則允許用戶自定義配置服務的外部訪問規則，實現更精細化的路由和流量管理。

這里，我們撇開公有云不談，僅聊聊私有云環境下的入口網絡...

在私有云中運行時，創建 LoadBalancer 類型的服務需要一個可以配置負載均衡器的 Kubernetes 控制器。在目前的解決方案中，一種這樣的實現便是 MetalLb 。MetalLB 是裸機 Kubernetes 集群的負載均衡器實現，使用標準路由協議。其基于分配的 IP 地址來路由集群內的外部流量。從本質上來講，MetalLB 旨在通過提供與標準網絡設備集成的網絡 LoadBalancer 實現來糾正這種不平衡，以便使得裸機集群上的外部服務也盡可能地正常發揮作用。

MetalLB 實現了一個實驗性的 FRR 模式，它使用 FRR 容器作為處理 BGP 會話的后端。它提供了原生 BGP 實現所不具備的功能，例如將 BGP 會話與 BFD 會話配對，以及發布 IPV6 地址。

MetalLB 是一種可用于裸機環境的 Kubernetes 外部負載均衡器實現。它是谷歌開發的一個簡單的負載均衡器，具有為負載均衡器類型的 Service 分配公共 IP 地址(External IP)和向 External IP 公開路由信息等兩個功能。基于 MetalLb 設計特性，其主要涉及以下 2 種核心功能：

• 地址分配：當創建 LoadBalancer Service 時，MetalLB 會為其分配 IP 地址。這個 IP 地址是從預先配置的 IP 地址庫獲取的。同樣，當 Service 刪除后，已分配的 IP 地址會重新回到地址庫。
• 對外廣播：分配了 IP 地址之后，需要讓集群外的網絡知道這個地址的存在。MetalLB 使用了標準路由協議實現：ARP、NDP 或者 BGP。

廣播的方式有兩種，第一種是 Layer 2 模式，使用 ARP(ipv4)/NDP(ipv6) 協議;第二種是 BPG。

我們來看一下 MetalLB 網絡參考示意圖，如下所示：

基于上述參考拓撲結構圖，我們可以看到：當有外部流量請求訪問時，路由器和 ipvs 會根據設置的路由信息調整連接目的地。因此，從某種角度而言，MetalLB 本身并非是一種負載均衡組件設施，而是基于負載均衡場景而設計。

那么，其實，像 Traefik 這樣的代理可以通過將其作為服務運行并定義此 LoadBalancer 類型的服務來接收進入集群的所有外部流量。這些代理可以使用 L7 路由和安全規則進行配置。這些規則的集合形成了 Ingress 規則。

基于 Ingress - 將服務置于可通過負載均衡器從外部訪問的代理后面。可以在服務之前放置一層 L7 代理，以應用 L7 路由和策略。為此，需要一個入口控制器。Ingress Controller 是 Kubernetes 集群內的服務，配置為 LoadBalancer 類型以接收外部流量。

Ingress Controller 使用定義的 L7 路由規則和 L7 策略將流量路由到服務。具體可參考如下示意圖所示：

其實，從本質上來講，在 Ingress 運行 Ingress Controller 和執行策略有幾個明顯的優勢，具體：

• Ingress 提供了一種可移植的機制來在 Kubernetes 集群內執行策略。在集群內實施的策略更容易跨云移植。可以使用 Kubernetes 服務擴展來水平擴展。
• 多個代理可以使用 Kubernetes 服務進行水平擴展，L7 結構的彈性使其更易于操作和擴展。
• L7 策略可以與集群內的服務一起托管，具有集群原生狀態存儲。
• 讓 L7 策略更接近服務可以簡化服務和 API 的策略執行和故障排除。

在 Kubernetes Cluster 中選擇 Ingress 控制器 是一個非常重要的決策，直接關系到 Cluster 的網絡性能、安全性和可擴展性。作為一款備受推崇的開源 Ingress 控制器，Traefik憑借其卓越的設計理念和強大的功能特性,成為了許多用戶的首選之一。

那么，為什么要選擇 Traefik 作為首選的 Kubernetes Ingress 呢?具體如下所示：

1.易于使用和維護

Traefik 的安裝和配置過程極為簡單流暢，使用 YAML 或 TOML 格式的聲明式配置文件，可讀性和可維護性極佳。與此同時，Traefik 還提供了基于 Web UI 的直觀管理界面，用戶可以在其中實時查看和管理路由規則、中間件等配置項，極大降低了運維的復雜度。

2.自動化服務發現能力

Traefik 擁有強大的自動服務發現功能，可以自動監測 Kubernetes Cluster 中服務的變化，并基于這些變化動態生成相應的路由規則，無需人工介入。這種自動化能力不僅極大地簡化了配置流程，還確保了路由規則的實時更新，保證了服務發現的準確性和及時性。此外，Traefik 支持多種服務發現機制，包括 Kubernetes Ingress、Docker 等，可以適應各種復雜的部署環境。

3.智能動態負載均衡

Traefik 內置了高性能的負載均衡模塊，可以根據服務實例的實時狀態動態調整后端權重，實現真正意義上的智能負載均衡。同時，Traefik 還支持會話親和性、熔斷機制、重試策略等高級功能，從而確保了服務的高可用性和可靠性，為應用提供了穩定、高效的運行環境。

4.豐富的中間件生態

Traefik 擁有數十種內置的中間件，涵蓋了身份認證、速率限制、熔斷、重試、緩存等多個方面，用戶可以根據實際需求，通過簡單的配置即可啟用這些中間件，快速構建出功能強大的邊緣服務。除了內置中間件之外，Traefik還提供了良好的擴展性，支持用戶自行開發和集成定制化的中間件，滿足各種復雜場景的需求。

5.卓越的可擴展性

作為一款生產級別的 Ingress 控制器，Traefik 天生具備出色的可擴展性。它支持多種部署模式，包括單實例、集群等，在集群模式下，多個 Traefik 實例可以無縫協作，實現高可用和水平擴展。同時，Traefik 還支持多種后端服務器類型，如 HTTP、gRPC 等，能夠滿足各種復雜的應用場景需求。

6.全方位的安全保障

安全性是 Traefik 設計時的重中之重，支持 HTTPS/TLS、基于角色的訪問控制(RBAC )等多種安全特性。Traefik 可以通過 Let's Encrypt 等方式自動獲取和更新 SSL/TLS 證書,確保數據傳輸的端到端加密。同時，它還提供了完善的身份認證機制，如基本認證、JWT 等，有效保護服務免受未經授權的訪問。