從 LB Ingress 到 ZTM：集群服務暴露新思路
12 月 28 日，上周六有幸參與了 KubeSphere 社區和 Higress 社區聯合舉辦的「云原生 + AI Meetup 廣州站」的活動。在會上，我分享了一篇關于「從 LB Ingress 到 ZTM：集群服務暴露新思路」的主題演講。在這里，我將分享一下演講的內容，同時將文章標題做了小調整。
集群服務暴露的需求
集群服務暴露的需求來自 Kubernetes 服務的虛擬化和網絡隔離。眾所周知，Kubernetes 的 Pod 是動態的，可能會頻繁的刪除、重建，重新調度到不同的節點，IP 地址也會隨之變化。Kubernetes 使用 Service 來提供訪問 Pod 的穩定接口，實現對服務的抽象。
Service 為 Pod 提供了一個穩定的 DNS 名稱和虛擬 IP 地址，而不依賴于 Pod 的臨時 IP。因此在集群內部的通信，通過 Service 的 ClusterIP 訪問完全不存在問題。
不過 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: /barIngress 的定位是集群的單一入口，通過這個入口管理多個服務。通過基于域名、路徑進行流量轉發。與 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
