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

集群服務暴露的需求

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

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

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

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

集群服務的暴露方式

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

這些方式的實現(xiàn)方式各有不同，各有優(yōu)劣，適用于不同的場景。

LoadBalancer

圖片

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

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

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

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

圖片

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

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

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

NodePort

圖片

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

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

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

Ingress

圖片

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

所以這里我們以大家最為熟悉的 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 的定位是集群的單一入口，通過這個入口管理多個服務。通過基于域名、路徑進行流量轉發(fā)。與 LoadBalancer 和 NodePort 不同，Ingress

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

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

零暴露面網(wǎng)絡 ZTM

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

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

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

ZTM 的架構

圖片

ZTM 的架構非常簡單，

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

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

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

ZTM 的特性

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

ZTM  App

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

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

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

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

隧道 zt-tunnel

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

• 出口 Outbound：隧道的出口，位于目標設備的網(wǎng)絡中。
• 入口 Inbound：隧道的入口，位于訪問方的網(wǎng)絡中。

圖片

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

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

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

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

代理 zt-proxy

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

圖片

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

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

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

使用 ZTM 暴露集群服務

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

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

使用 zt-tunnel 暴露集群服務

圖片

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

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

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

使用 zt-proxy 暴露集群服務

圖片

如果有大量的服務需要對外暴露，我們可以借助 zt-proxy 來簡化這個過程。在連通 mesh 網(wǎng)絡之后，在集群內部可以配置 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 創(chuàng)建了兩個網(wǎng)絡完全隔離的集群，接著通過 ZTM 連通兩個集群。然后，分別演示了如何通過 ZTM 的隧道和代理來進行跨集群的服務訪問。

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

方案對比

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

ZTM 更多應用場景

遠程執(zhí)行命令 zt-terminal

圖片

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

在遠端的網(wǎng)絡配置可以執(zhí)行命令的用戶。

ztm terminal config --add-user zt-user1

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

ztm terminal open ep-office

分布式文件共享 zt-cloud

圖片

在 mesh 網(wǎng)絡中，可以通過 zt-cloud 來實現(xiàn)分布式文件共享。在某個 Agent 上發(fā)布的文件，可以通過 mesh 網(wǎng)絡廣播到其他的 Agent，實現(xiàn)文件的分發(fā)。

其他場景

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

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

總結

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

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

參考資料

[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