為了將運行在 Kubernetes 集群內部 Pod 上的應用程序投入使用，需要啟用 K8S 集群上的服務(Service)：NodePort 或 ClusterIP，然后再經過外部 LoadBalancer 或 Ingress 功能，將服務發布為可被集群外部客戶端訪問的 IP 地址或者FQDN。

NodePort 是在 Kubernetes 集群上提供的一種簡便的服務發布方式：

1.在每個 Node 上公開一個 Port(即使 Pod 不在該 Node上)，對應到實際 Pod 的服務端口，客戶端需要訪問應用時，流量被發送到特定的NodeIP:Port;

2.對 Node IP:Port 的訪問流量，由運行在每個節點上的 kube-proxy 負責 Pod 之間重新分配流量。

雖然，NodePort 類型的服務是創建用于外部連接的(和任何應用程序容器)的快捷解決方案，不需要額外規劃 IP 地址空間，但它具有以下缺點：

1.如果配置允許由 Kube-Proxy 在集群范圍內進行外部流量的負載均衡( externalTrafficPolicy=Cluster )，那么目標 Pod 有可能不在第一跳 Node 上，需要進行節點間的第二跳路由轉發;這種情況下，需要對傳入流量執行源地址翻譯( SNAT )，外部負載均衡器無法保證會話持久性。

02.如果配置僅允許 Kube-Proxy 在節點內部進行負載均衡( externalTrafficPolicy=Local )，那么由外部負載均衡器傳入到節點上的流量，將僅限于被發送到運行在本節點上的 Pod ;這種情況下，Pod 在節點上的實際分布情況可能會導致不均衡的負載分擔。如下圖：外部負載均衡器只將2個后端節點作為服務池成員，所有進入的訪問請求按照50：50比例分配給這2個節點;但 Node -1上有2個 Pod 分擔這50%的任務，而 Node -2 上僅有1個 Pod 承擔50%的任務量。

03.出于簡單配置和使用的目的，在每個 Node 上對外曝露相同的 Port，即便是該節點上并沒有運行Pod實例。如在上圖中增加一個空載的“ Node-3 ”，外部負載均衡器發送給 Node-3 的流量將由 Kube-Proxy 轉發給 Node-1 或 Node-2 ，增加了轉發步驟;而且，外部負載均衡器無法通過健康檢查的方式發現， Node -3上并沒有運行應用 Pod 實例。

04.出于簡單配置和使用的目的，在每個 Node 上對外曝露相同的 Port ，但存在給定 Port 在某個 Node 上已被占用的可能性，此時就需要在所有節點上尋找并使用下一個可用的端口號。隨著(采用NodePort 類型的)服務數量的不斷增加，最終將很快達到 Port 范圍限制。

NodePortLocal 解決方案

VMware 提出了一種解決方案，使用 CNI Antrea 和NSX 高級負載均衡(以下簡稱 NSX-ALB)相結合，實現稱為“ NodePortLocal ”( NPL )的技術方案來解決上述問題。NodePortLocal 提供了一種在 Kubernetes 集群的每個節點上、為每個 Pod 提供專屬“ NodeIP:Port ”映射來曝露后端服務的方法。

注：

· Antrea 項目是一個 VMware 貢獻的開源 Kubernetes CNI 網絡插件解決方案，基于 Open vSwitch(OVS)， 旨在提供 Kubernetes 原生的、高效、安全、跨平臺的 CNI 和 NetworkPolicy 。2021年5月6日，經過云原生計算基金會( CNCF )技術監督委員會( TOC )投票通過， VMware 開源項目 Antrea 正式成為沙箱級項目( Sandbox Level Project )。

· NSX-ALB AKO 是一個Kubernetes 環境中的 Operator，用作 LoadBalancer 和 Ingress Controller，它作為集群中的 pod 運行，并通過 NSX-ALB 控制器將所需的 Kubernetes 服務轉換為 NSX-ALB 配置，在NSX-ALB的轉發服務引擎 (SE) 上自動實現 Ingresses/Routes/Services。

· Antrea 和 AKO 在原生 Kubernetes、VMware Tanzu 和 Openshift Container Platform 環境中均可以使用。

配置步驟

為了完成此任務，需要以下步驟完成NPL的配置。(略過 Antrea 和 AKO 的基本安裝、配置和使用方法的介紹)

1. 在 K8S 環境中進入 Antrea ConfigMap 編輯模式：kubectl edit -n kube-system cm antrea-config-xxxxxxxxxx

2. 啟用 NodePortLocal

3.(可選)設定用于 NPL 映射的端口范圍，避免與仍在使用的 NodePort 服務沖突;

4. 保存 Antrea ConfigMap 配置，重新啟動 Antrea 代理 Pod;

5. 在 NSX-ALB AKO 的 yaml 配置文件中，設定啟用 NPL 服務類型：

6. 保存 AKO 配置并更新到 AKO Pod。

采用NPL進行L4服務發布

1. 在 Kubernetes 集群中創建 Deployment 。本例在具有3個工作節點的集群上部署了4個 httpd Pod：

2. 通過 ServiceType=LoadBalancer 參數，將此應用曝露出去( Antrea 代理在后臺監聽這一服務的創建，按照 NodePortLocal 的模式工作)：

3. NSX-ALB 的 AKO 感知到集群上的服務變化，并生成對應的負載均衡配置，在 NSX-ALB 控制器的管理界面上，可以看到 AKO 已經將上述服務發布出去(下圖)。

NPL 有以下特點：

a. 將每個 Pod 對外曝露為一個專屬的 NodeIP:Port 組合方式。本例中，worker-node-23(192.168.30.23)節點上部署了2個 Pod ，因此將它們分別映射為192.168.30.23:40000和192.168.30.23:40001。NodePortLocal 可以在不同節點上使用不同的 Port 曝露同一應用(而 NodePort 要求在所有節點上為同一應用綁定同樣的 Port ，即便這個節點上沒有運行該應用的 Pod)。對比之下，NodePortLocal 更加靈活地使用每個節點上的可用 Port，降低了端口資源消耗。

b. NSX-ALB 作為 Kubernetes 的外部負載均衡器，將4個 NodeIP:Port 作為后端服務池，進行負載均衡決策和轉發，避免了多個 Pod 上的任務量不均衡。

c. 不需要像 ClusterIP 方式那樣單獨設置服務地址范圍，不需要針對 ClusterIP 或 Pod IP 的靜態路由——所有流量指向每個 NodeIP:Port，NSX-ALB 只需按照節點地址進行一跳路由，集群內不對此流量進行東西向轉發。

d. NPL 在每個節點上編寫了 iptable DNAT (目的地址翻譯)規則來完成 NodeIP:Port<->PodIP:Port 的映射和轉換，外部負載均衡器只感知并使用 NodeIP:Port，因此，可以在多個 K8S 集群上支持重疊的 Pod 網絡地址段。

e. NSX-ALB 作為外部負載均衡器，對進入集群的流量只進行目的地址翻譯( DNAT)，不進行源地址翻譯(SNAT)，應用程序 Pod 看到的是原始客戶端 IP，因實現會話持久性是可能的。

f. NSX-ALB 負載均衡器可以通過 NodeIP:Port 直達每個 Pod上 的應用端口，可以直接監控每個應用的健康狀況，并可以據此做出負載均衡決策。

采用NPL輔助L7應用發布

在 Kubernetes 集群上使用 Ingress 進行 L7 應用發布時，應先創建 L4 服務(比如， NodePort )，再通過 Ingress Controller 識別L4服務，并按照管理員配置的策略，創建 L7 Ingress ，實現對應用的L7路由(比如，依據 URI 規則選擇后端服務器)。

VMware NSX-ALB 應用交付方案可以與 CNI Antrea 中的 NodePortLocal 功能配合使用，將 NodePortLocal 創建的L4服務通過 Ingress 發布出去。

配置步驟要點如下：

1. 在 Kubernetes 集群中創建 Deployment。本例在具有3個節點的集群上部署了4個 httpd Pod：

2. 通過 ServiceType=ClusterIP 參數，將此應用曝露出去，服務名稱為“svc-lb-httpd”(Antrea 代理在后臺監聽這一服務的創建，按照 NodePortLocal 的模式工作)：

3. NSX-ALB 在集群上安裝 AKO Pod，作為 Ingress Controller，默認采用“avi-lb”作為 ingressClassName，為服務“svc-lb-httpd”創建 Ingress，使用 yaml 文件示例如下：

4. 在 NSX 應用交付控制器上，可以看到為上述應用創建了 L7 虛擬服務，后端服務器池中 NodeIP:Port 映射方式表明，這采用的是 NodePortLocal 模式。

總結，“ NodePortLocal”( NPL )是 CNI 項目 Antrea 中提出的，可以提高在節點上通過端口映射的方式對外發布應用的效率，簡化云原生應用投入生成過程的配置步驟。NPL 與 NSX AKO 相結合，將 NSX 應用交付平臺上作為 Kubernetes 集群的外部負載均衡器 /Ingress Controller，這種“一步到位”的 做法是 VMware 對云原生應用的最新貢獻。