從 LB Ingress 到 ZTM：集群服務暴露新思路

作者：張曉輝Addo 2024-12-30 12:34:27

Service 為 Pod 提供了一個穩定的 DNS 名稱和虛擬 IP 地址，而不依賴于 Pod 的臨時 IP。因此在集群內部的通信，通過 Service 的 ClusterIP 訪問完全不存在問題。

12 月 28 日，上周六有幸參與了 KubeSphere 社區和 Higress 社區聯合舉辦的「云原生 + AI Meetup 廣州站」的活動。在會上，我分享了一篇關于「從 LB Ingress 到 ZTM：集群服務暴露新思路」的主題演講。在這里，我將分享一下演講的內容，同時將文章標題做了小調整。

集群服務暴露的需求

集群服務暴露的需求來自 Kubernetes 服務的虛擬化和網絡隔離。眾所周知，Kubernetes 的 Pod 是動態的，可能會頻繁的刪除、重建，重新調度到不同的節點，IP 地址也會隨之變化。Kubernetes 使用 Service 來提供訪問 Pod 的穩定接口，實現對服務的抽象。

不過 Service 的 ClusterIP 只能在集群內部訪問，外部無法直接訪問。Service DNS 名稱的解析，只能在集群內部進行。這種網絡隔離作為網絡保護機制，確保 Pod 和 Service 的訪問受限于集群內部。

然而，我們在實際應用中，往往需要將服務暴露到集群外部，以便外部用戶訪問。這時，我們就需要額外的組件來實現集群服務的暴露。尤其是在一些高級應用場景下，如多集群、多云等，更需要一種靈活、動態的方式來暴露集群服務。

集群服務的暴露方式

Kubernetes 對集群服務的抽象，提供了多種方式，設計外部訪問的有 LoadBalancer^[1]、NodePort^[2]，以及更高級的 Ingress^[3]。（Ingress 可能逐漸被 Gateway API^[4] 所取代，而二者實現上基本一致。我們下面討論的 Ingress 泛指 Kubernetes 高級入口流量管理。）

這些方式的實現方式各有不同，各有優劣，適用于不同的場景。

LoadBalancer

圖片

LoadBalancer 是常見的暴露集群服務的方式之一。在云環境中通過云提供商的負載均衡器，可以將流量分發到集群內的多個 Pod 上；在 On-Prem 環境中，可以使用開源負載均衡器。咱們這里主要討論開源負載均衡器。

kubectl get service
NAME         TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
nginx        LoadBalancer   10.43.177.15   192.168.2.1    80:32186/TCP   2m18s

在開源的服務均衡器中，有兩類比較常見的實現。第一種的實現比較多，如 MetaLB^[5]、青云的 OpenELB^[6]、kube-vip^[7] 以及 PureLB^[8]。這幾種的實現方式基本類似，都會在集群的每個節點上運行一個控制器 Pod。這個控制器 Pod 會監聽 LoadBalancer 類型 Service 的變化，然后為其配置 VIP，并將 VIP 綁定到節點的網卡上。最后這個 VIP 會通過 ARP（二層）或者 BGP（三層）協議通知外部網絡。

如果到某個 VIP 存在多條路由，通常會使用等價多路徑（ECMP）路由測量將流量分發到多個節點上，以實現負載均衡。

圖片

第二種的實現方式相對簡單不少，如 K3s 的 ServiceLB 也就是以前 Klipper^[9]，基于 iptables 和 HostNetwork。當監控到有 LoadBalancer 類型的 Service 創建時，ServiceLB 會為該 Service 創建一個 DS（DaemonSet），DS 在每個 Node 上創建代理容器，代理容器使用 hostNetwork 網絡模式，hostPort

訪問的入口是每個節點的 IP 地址，代理容器接收到流量后通過 iptables 轉發到 Service 的 clusterIP，最終到達 Pod。

這種實現方式的優點是輕量級，不需要依賴云供應商的負載均衡器，成本低，簡單易用，非常適合網絡和資源受限的場景；缺點也明顯，全節點監聽端口，缺乏 TLS 終止等高級功能，轉發需要節點網絡高并發場景下成為瓶頸。

NodePort

圖片

如果說 LoadBalancer 是比較高級的方式，那么 NodePort 就是最簡單直接的方式了。NodePort

針對每個 NodePort 類型的 Service，Kubernetes 會其分配一個端口。運行在每個節點上的 kube-proxy 會根據 Service 和 Pod 的信息，設置 iptables 規則。這樣，當有流量到達節點的 NodePort

場景上，NodePort 適用于小型集群、測試環境等，不需要負載均衡，直接暴露節點 IP 和端口即可。缺點是無自動負載均衡，暴露節點 IP，安全性較低。

Ingress

圖片

Ingress 是 Kubernetes 內置的流量管理對象，定義了 HTTP 或 HTTPS 路由規則。Ingress 通過 Ingress Controller 實現，Ingress Controller 會根據 Ingress 資源的配置，動態的更新負載均衡器的配置，以實現流量的分發。慢慢地 Ingress 可能會被 Gateway API^[10] 所取代，后者有著更加靈活的擴展能力。但二者實現基本類似，都是有代理和控制器組成。

所以這里我們以大家最為熟悉的 Ingress 為例。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example
spec:
  rules:
  - http:
      paths:
      - backend:
          service:
            name: foo
            port:
              number: 8080
        path: /foo
      - backend:
          service:
            name: bar
            port:
              number: 8080
        path: /bar

Ingress 的定位是集群的單一入口，通過這個入口管理多個服務。通過基于域名、路徑進行流量轉發。與 LoadBalancer 和 NodePort 不同，Ingress

場景上，Ingress 適用于復雜路由規則、HTTPS 支持等場景。缺點是配置可能相對復雜，還需要依賴 Ingress Controller。更主要的是，Ingress 的代理本身仍然需要對外暴露，需要額外的 LoadBalancer

介紹了這幾種方式后，我們看下是否還有其他的方式來暴露集群服務。

零暴露面網絡 ZTM

零暴露面網絡 ZTM（Zero Trust Mesh）^[11] 是基于 HTTP/2 隧道的去中心化的、面向遠程辦公和 IoT 邊緣網絡等場景的開源網絡基礎設施軟件。

ZTM 可以運行在任意的現存 IP 網絡之上，包括但不限于局域網、互聯網、容器網絡等。ZTM 為保障應用安全提供了必要的網絡基礎，包括網絡聯通性、基于端口的訪問控制、mTLS 加密的網絡通道、基于證書的身份識別與訪問控制、負載均衡等基礎網絡及安全能力。

ZTM 可以多種設備上運行，支持 CPU 架構：x86、ARM、MIPS、RISC-V、LoongArch 等，以及操作系統：Linux、Windows、macOS、FreeBSD、Android 等。

ZTM 的架構

圖片

ZTM 的架構非常簡單，

ZTM Agent：部署在需要接入零信任網絡的設備上，包括個人計算機、服務器或邊緣設備上，用于發起加密隧道，將設備的流量安全地轉發到 ZTM Hub。
ZTM Hub：分布式部署的接入點，與每個 Agent 建立加密隧道，轉發來自 Agent 的請求，實現多點接入和高可用性。

通過 ZTM Hub 的連通，Agent 之間可以在已有網絡（局域網、互聯網、容器網絡等）之上組建一個安全的零信任網絡，實現設備之間的安全通信。

這個網絡在 ZTM 中的術語 Mesh。Mesh 是一個邏輯網絡，由多個 Agent 組成，Agent 之間通過加密隧道連接。Agent 也可以加入多個 Mesh，實現與多個網絡之間的互聯。

ZTM 的特性

零防火墻：全鏈路無需防火墻配置，管理更加簡單。
零端口：沒有開放端口，輕松應對各種掃描。
零運維：終端網絡不需要虛擬網卡，不需要終端路由，不需要終端防火墻。
零特權：Agent 運行的用戶態，不需要特權配置，更加安全。
零路由：基于服務發現的訪問機制，無需復雜易錯的路由配置。
零信任：基于證書的身份識別，可信設備，全鏈路驗證身份和訪問控制。

ZTM App

zt-app 框架是一個基于 ZTM 的應用開發框架，提供了一套標準化的開發接口，使開發者能夠更輕松地構建去中心化的應用。zt-app 框架的設計目標是“簡單、易用、安全”，為開發者提供便捷的開發工具。

ZTM 是用 PipyJS^[12] 編寫的，PipyJS 是一種專為 Pipy^[13] 設計的定制版 JavaScript 。開發人員可以使用 PipyJS 輕松地開發 ZTM App。

在 ZTM 中內置了幾大關鍵 App：

zt-tunnel：在點對點之間建立安全的 TCP/UDP 隧道。
zt-proxy：SOCKS/HTTP 代理，從一個端點接收流量，另一個端點轉發出去。
zt-script：在端點上遠程執行腳本。
zt-terminal：遠程訪問端點上的 shell。

隧道 zt-tunnel

零信任隧道，消除了物理距離和網絡隔離的限制，可以從任何地方訪問設備。zt-tunnel

出口 Outbound：隧道的出口，位于目標設備的網絡中。
入口 Inbound：隧道的入口，位于訪問方的網絡中。

圖片

比如這個場景，我們有兩個隔離的網絡，通過 ZTM 打通組成了一個 ZTM 網絡。在我們的辦公網絡中有兩臺設備：Windows 設備支持遠程桌面訪問；Linux 設備支持 SSH 訪問。我們稱這兩個為遠端設備。

當我們需要從外面訪問這兩臺設備時，我們只需要在辦公網絡的 ZTM Agent 上創建名為 tcp/rdp 和 tcp/ssh-vm

在訪問側的 ZTM Agent 上創建兩個入口，分別指向上面創建的出口，并指定端口。當我們需要訪問遠端設備時，僅需訪問本地 Agent 的地址和入口端口即可。

如果需要訪問其他網絡的設備，只需要其網絡中運行 ZTM Agent 并連接到同一個 ZTM Hub 上，然后為設備添加出口和入口即可。

代理 zt-proxy

用 zt-tunnel 的方式訪問設備時需要為每個服務都創建隧道的出口和入口，可能會比較繁瑣。zt-proxy

圖片

zt-proxy 可以為訪問方提供一個 HTTP 或 SOCKS 代理，在目標網絡的 ZTM Agent 上，我們只需添加代理的目標地址（可以是 IP 網段，也可以是帶有通配符的域名），完成。在訪問方只需要目標的 IP 地址或者域名，通過代理即可訪問目標設備了。

通過 IP 網段或者域名，可以實現設備的批量添加，非常適合多設備的場景。并且代理的方式，可以讓我們像在同一個局域網中一樣訪問遠程設備。

在了解過 ZTM 的基本概念和特性之后，我們可以看下如何使用 ZTM 來暴露集群服務。

使用 ZTM 暴露集群服務

可能有人已經想到了，我們可以使用 ZTM 來打通集群內外、甚至是多個集群的網絡。

借助 ZTM Hub，我們可以在集群內外部署 ZTM Agent，打通與集群的連通性。這樣即使在兩個隔離的網絡，我們也能通過 ZTM 的 HTTP/2 隧道到訪問集群內的服務。

使用 zt-tunnel 暴露集群服務

圖片

在這個場景中，我們通過 ZTM 的 mesh 網絡連通了集群內外的隔離網絡。在集群內部，我們可以通過 zt-tunnel 為需要對外暴露的服務創建出口，然后在集群外部的 ZTM Agent 上創建入口，即可通過 ZTM 的隧道訪問集群內的服務。

配置隧道的出入口后，我們可以通過 Agent 的地址以及配置的隧道入口的端口里訪問集群內的服務 A 了，比如 curl http://192.168.1.30:8080。

如果需要訪問其他服務，只需要為其他服務創建出口和入口即可。

使用 zt-proxy 暴露集群服務

圖片

如果有大量的服務需要對外暴露，我們可以借助 zt-proxy 來簡化這個過程。在連通 mesh 網絡之后，在集群內部可以配置 zt-proxy 的目標為集群內服務的 DNS，如 *.svc.cluster.local，這樣將集群內的所有服務作為代理的目標，也可以通過指定暴露某個命名空間下的服務。

然后通過集群外部 Agent 的代理來訪問集群內部服務了，比如 curl -x http://192.168.1.30:8080 http://svc-a.svc:8080。

通過控制暴露服務的 DNS，我們可以控制服務的暴露范圍。

Demo

為了展示 ZTM 如何暴露集群服務，準備了一個簡單的 Demo^[14]。

在這個 Demo 中通過 K3d 創建了兩個網絡完全隔離的集群，接著通過 ZTM 連通兩個集群。然后，分別演示了如何通過 ZTM 的隧道和代理來進行跨集群的服務訪問。

有興趣的朋友可以自己動手試試。

方案對比

在介紹過集群服務暴露的方式和 ZTM 后，我們可以對比一下這幾種方式。

特性	NodePort	LoadBalancer	ZTM
技術原理	iptables	DNAT（BGP/ARP）	HTTP/2 反向隧道
訪問方式	節點 IP + 固定端口	云、開源負載均衡器 + 外部 IP	隧道、代理
網絡依賴	節點需擁有固定或可訪問的 IP	外部 IP 地址、BGP/ARP 網絡環境	無需直接暴露網絡
適用場景	小型集群或測試環境，快速暴露服務	公有云集群，需高可用和穩定外部訪問服務	零暴露面安全場景，遠程和跨集群訪問
易用性	簡單直接，配置少	自動化配置，依賴云平臺或開源負載均衡器	需要部署 ZTM Agent 和 Hub

ZTM 更多應用場景

遠程執行命令 zt-terminal

圖片

zt-tunnel 零信任終端，基于“設備 + 證書”身份認證和訪問控制的遠程命令行工具。獲得授權后，一個設備可以在另一個設備上執行 shell 命令。

在遠端的網絡配置可以執行命令的用戶。

ztm terminal config --add-user zt-user1

在本地網路中就可以訪問指定設備上的 shell 了。

ztm terminal open ep-office

分布式文件共享 zt-cloud

圖片

在 mesh 網絡中，可以通過 zt-cloud 來實現分布式文件共享。在某個 Agent 上發布的文件，可以通過 mesh 網絡廣播到其他的 Agent，實現文件的分發。

其他場景

這里列出來 ZTM 的一些其他應用場景，還有更多的場景等待大家的探索。有興趣的朋友可以加入 ZTM 玩家交流群，后臺聯系我加入。

內網穿透
遠程辦公
安全訪問云資源
遠程調試
多集群網絡
設備遠程訪問
文件共享

總結

這次分享，我們介紹了集群服務暴露的需求，以及 Kubernetes 中常見的暴露方式。然后介紹了 ZTM 的基本概念和特性，以及如何使用 ZTM 來暴露集群服務。

希望通過本次的分享，大家可以了解到 ZTM 的基本概念和特性，以及如何使用 ZTM 來現集群服務的暴露。

參考資料

[1]LoadBalancer: https://kubernetes.io/docs/concepts/services-networking/service/#loadbalancer

[2]NodePort: https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport

[3]Ingress: https://kubernetes.io/docs/concepts/services-networking/ingress/

[4]Gateway API: https://kubernetes.io/docs/concepts/services-networking/gateway/

[5]MetaLB: https://metallb.io

[6]OpenELB: https://openelb.io/

[7]kube-vip: https://kube-vip.io

[8]PureLB: https://purelb.gitlab.io/purelb/

[9]Klipper: https://github.com/k3s-io/klipper-lb

[10]Gateway API: https://kubernetes.io/docs/concepts/services-networking/gateway/

[11]ZTM（Zero Trust Mesh）: https://github.com/flomesh-io/ztm

[12]PipyJS: https://flomesh.io/pipy/docs/en/reference/pjs

[13]Pipy: https://github.com/flomesh-io/pipy

[14]簡單的 Demo: https://github.com/flomesh-io/ztm-mcs-demo

責任編輯：武曉燕來源：云原生指北