使用 Dapr 與 Cilium 打造無 Sidecar 服務網格：新一代分佈式應用運行時

本文探討了將 Dapr 與 Cilium 集成的無 Sidecar 服務網格方法，強調了其高性能和安全性。

閱讀原文請轉到：https://jimmysong.io/trans/integrating-dapr-with-cilium/

幾周前，我們介紹了 Dapr，並討論了它與服務網格的重疊功能，儘管 Dapr 本身並不是一個服務網格。如之前的博客所述，近年來服務網格已成爲現代雲原生應用的關鍵組成部分，提供了諸如流量管理、安全性和可觀測性等關鍵功能。傳統的服務網格依賴於 sidecar 代理，這可能會引入複雜性和性能開銷。而 Cilium 的無 sidecar 服務網格功能通過利用 eBPF 實現高效的內核級網絡處理，結合 Dapr 這一強大的分佈式應用運行時，這種集成承諾提供高性能、增強的安全性和簡化的操作。

無 Sidecar 服務網格的需求

正如這篇文章所討論的，Cilium 最初作爲 Kubernetes 的一種 eBPF 驅動的容器網絡接口（CNI）開始。隨着時間的推移，Cilium 演變成了 Kubernetes 內部網絡的多功能工具。2022 年 7 月，Cilium 服務網格的首個版本發佈，引入了一種利用 eBPF 並在 Linux 內核中運行的無 sidecar 服務網格。

這種服務網格旨在廣泛利用 eBPF，專注於較低層次的網絡（直到第 4 層）以提供其功能。然而，對於一個功能齊全的服務網格，較高層次的功能如服務調用依賴於第 7 層。通常，這些功能需要一個代理來實現重試和斷路等功能。

考慮到 Dapr 及其第 7 層功能，它傳統上運行在基於 sidecar 的模型上。雖然這是準確的，但有一個與無 sidecar 架構相一致的替代方法。

介紹 Dapr 共享

Dapr 共享提供了 Dapr 的另一種部署模型。雖然默認的方法仍然使用 sidecars，但 Dapr 共享允許用戶輕鬆地將 Dapr 運行時（Daprd）部署爲 Kubernetes 內的 DaemonSet（每個節點一個）或 Deployment（每個集羣一個）。這種方法的顯著優勢在於，它在一定程度上將 Daprd 實例的生命週期與實際應用的生命週期解耦。你可能會問：這有什麼好處？有幾種情況下，這種方法是有利的：

• 函數即服務（FaaS）集成：在 FaaS 中，實際函數的一個實例可能只在執行期間存在幾秒鐘。然而，你可能仍然希望使用 PubSub 進行異步消息傳遞。
• 無 Sidecar 服務網格集成：當主要使用 Dapr 的構建模塊時，類似於 FaaS 的示例，將 Daprd 的生命週期與其應用解耦是有益的。通過控制 Daprd 實例（"代理"）的數量，這種方法與無 sidecar 服務網格很好地集成。

通過在這些情況下使用 Dapr 共享，我們仍然可以利用所有構建塊和高級功能，如 mTLS 與服務調用結合使用。

我們的示例案例和架構

理論介紹完畢，現在是時候進行實踐了。我們將設置一個簡單而強大的架構，以演示 Dapr 和 Cilium 服務網格如何協同工作。

在這個設置中，我們將採用前沿技術。Cilium 將處理一般的網絡層，並使用其 Gateway API 實現來管理流入我們演示集羣的南北流量。對於東西流量，我們將利用 Cilium GAMMA 實現，通過 Dapr 共享運行時進行增強，以確保全面的集成。

通過整合這些技術，我們將能夠爲我們的設置添加彈性和其他高級功能。這種架構將展示 Dapr 和 Cilium 之間的無縫協作，爲 Kubernetes 環境提供強大而可擴展的網絡解決方案。

要求

如果你想跟進，你將需要訪問一個 Kubernetes 集羣。這個集羣應該安裝了 Cilium 版本 1.16，配置如下：

• 替換 Kube-proxy 或 NodePort 服務
• 啓用 GatewayAPI
• 可訪問的 Hubble 和 Hubble UI

你可以按照官方文檔安裝 Cilium。

設置 Gateway API 和網關

如前所述，我們將使用 GatewayAPI 來路由流量進入我們的集羣。這可以通過定義一個 Gateway 資源輕鬆實現，如下所示：

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: default-gateway
  namespace: default
spec:
  gatewayClassName: cilium
  listeners:
  - allowedRoutes:
      namespaces:
        from: All
    name: default-http
    port: 80
    protocol: HTTP

有了這個資源並正確安裝 Cilium，你可以運行以下命令來驗證 Gateway 是否已成功編程並具有外部 IP：

kubectl get gateway default-gateway

這應該輸出類似於：

NAME              CLASS    ADDRESS          PROGRAMMED   AGE
default-gateway   cilium   18.192.114.200   True         27h

現在我們已經設置好了 Gateway，我們可以繼續運行一個虛擬應用。

虛擬應用和簡單路由

爲了測試我們的設置，我們將部署由 Traefik Labs 創建的 whoami 鏡像。這個應用顯示 HTTP 請求頭和其他相關信息，這對於驗證我們的配置非常有用。讓我們開始部署並使虛擬應用可訪問。

爲 whoami 應用創建一個服務、部署和 HTTPRoute：

apiVersion: v1
kind: Service
metadata:
  name: whoami
  labels:
    app: whoami
spec:
  ports:
    - name: http
      targetPort: 80
      port: 80
  selector:
    app: whoami
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: whoami-v1
spec:
  replicas: 2
  selector:
    matchLabels:
      app: whoami
      version: v1
  template:
    metadata:
      labels:
        app: whoami
        version: v1
    spec:
      serviceAccountName: whoami
      containers:
        - image: traefik/whoami
          imagePullPolicy: IfNotPresent
          name: whoami
          ports:
            - containerPort: 80
          env:
            - name: WHOAMI_NAME
              value: "v1"
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: whoami-route-service
spec:
  parentRefs:
  - group: ""
    kind: Service
    name: whoami
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: whoami
      port: 80

部署這些資源後，你可以使用一個簡單的 curl 命令來驗證設置：

curl -v http://18.192.114.200

預期輸出應類似於：

*   Trying 18.192.114.200:80...
* Connected to 18.192.114.200 (18.192.114.200) port 80
> GET / HTTP/1.1
> Host: 18.192.114.200
> User-Agent: curl/8.4.0
> Accept: */*
>
< HTTP/1.1 200 OK
< date: Tue, 30 Jul 2024 14:16:41 GMT
< content-length: 350
< content-type: text/plain; charset=utf-8
< x-envoy-upstream-service-time: 6
< server: envoy
<
Name: v1
Hostname: whoami-v1-cd9b4bdf7-ht6dc
IP: 127.0.0.1
IP: ::1
IP: 10.42.0.101
IP: fe80::e0d3:4fff:fe30:95ef
RemoteAddr: 10.42.1.170:35911
GET / HTTP/1.1
Host: 18.192.114.200
User-Agent: curl/8.4.0
Accept: */*
X-Envoy-Internal: true
X-Forwarded-For: 10.42.1.82
X-Forwarded-Proto: http
X-Request-Id: bc928d69-06e2-427b-89f1-fab7c8bfb7e9

* Connection #0 to host 18.192.114.200 left intact

這確認了 whoami 應用是可訪問的，且 GatewayAPI 正確路由流量進入我們的集羣。

安裝 Dapr 運行時

接下來，我們需要在我們的 Kubernetes 集羣中安裝 Dapr 運行時。這可以通過使用現有的 Helm chart 快速完成。執行以下命令安裝 Dapr：

helm upgrade --install dapr dapr/dapr \
--version=1.13 \
--namespace dapr-system \
--create-namespace \
--wait

成功安裝的輸出看起來像這樣：

Release "dapr" has been upgraded. Happy Helming!
NAME: dapr
LAST DEPLOYED: Tue Jul 30 16:09:45 2024
NAMESPACE: dapr-system
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Thank you for installing Dapr: High-performance, lightweight serverless runtime for cloud and edge

Your release is named dapr.

To get started with Dapr, we recommend using our quickstarts:
https://github.com/dapr/quickstarts

For more information on running Dapr, visit:
https://dapr.io

要驗證所有 Dapr 組件是否正確運行，檢查 dapr-system 命名空間中的 pods：

kubectl get pods -n dapr-system

典型的輸出應顯示所有 Dapr 組件處於運行狀態：

NAME                                    READY   STATUS    RESTARTS   AGE
dapr-operator-c449df54-px8q2            1/1     Running   0          25h
dapr-placement-server-0                 1/1     Running   0          25h
dapr-sentry-774c876df5-h2nhh            1/1     Running   0          25h
dapr-sidecar-injector-78769c6d9-zh2jw   1/1     Running   0          25h

Dapr 成功安裝並且所有組件健康後，我們可以繼續安裝我們的共享實例。

部署 Dapr 共享實例

現在，讓我們設置我們的 Dapr 共享實例。我們需要部署兩個實例：一個用於入口（Cilium Gateway）和一個用於虛擬的 whoami 應用。入口實例將作爲 DaemonSet 部署，而 whoami 實例將作爲 Deployment 部署。

helm upgrade --install ingress-shared oci://registry-1.docker.io/daprio/dapr-shared-chart --set shared.appId=ingress --set shared.strategy=daemonset --set shared.remoteURL=cilium-gateway-default-gateway.default.svc.cluster.local --set shared.remotePort=80 --set shared.daprd.mtls.enabled=true --namespace default

helm upgrade --install whoami-shared  oci://registry-1.docker.io/daprio/dapr-shared-chart --set shared.appId=whoami --set shared.strategy=deployment --set shared.remoteURL=whoami.default.svc.cluster.local --set shared.remotePort=80 --set shared.daprd.mtls.enabled=true --namespace default

執行這些命令後，你可以使用以下命令驗證 Dapr 共享實例是否正在正確運行：

kubectl get pods

你應該看到類似於這樣的輸出：

NAME                                               READY   STATUS    RESTARTS   AGE
ingress-shared-dapr-shared-chart-bfnxc             1/1     Running   0          29s
ingress-shared-dapr-shared-chart-lg62n             1/1     Running   0          21s
whoami-shared-dapr-shared-chart-69fd8658db-kmzph   1/1     Running   0          26s

有了這些共享實例的運行，我們已經成功建立了一個強大的設置來處理應用流量和服務調用。

Daprise 操作

現在來到了有趣的部分："Dapr 化" 我們的設置！我們將 Dapr 與 Cilium Gateway 和 whoami 應用整合，充分利用 Dapr 的功能。爲了確保所有請求都通過專門的網關的 Dapr 共享實例流動，我們將配置 HTTPRoute 以針對這個 Dapr 實例。Dapr 期望特定的 URL 格式用於服務調用，因此我們將使用 Gateway API 中的 URLRewrite 過濾器來調整請求路徑。

使用以下配置更新之前的 HTTPRoute 資源：

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: whoami-route
spec:
  parentRefs:
  - name: default-gateway
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    filters:
    - type: URLRewrite
      urlRewrite:
        path: 
          type: ReplacePrefixMatch
          replacePrefixMatch: /v1.0/invoke/whoami.default/method//
    backendRefs:
    - name: ingress-dapr
      port: 3500

我們是如何 "Dapr 化" 它的？

• filters: URLRewrite 過濾器重寫 URL 以匹配 Dapr 的服務調用格式。（是的，// 是正確的）
• backendRefs: 指向處理網關請求的 ingress-dapr 實例。

爲了驗證一切是否正常工作，對網關的外部 IP 執行 curl 請求：

curl -v http://18.192.114.200

你應該看到類似於這樣的輸出：

*   Trying 18.192.114.200:80...
* Connected to 18.192.114.200 (18.192.114.200) port 80
> GET / HTTP/1.1
> Host: 18.192.114.200
> User-Agent: curl/8.4.0
> Accept: */*
>
< HTTP/1.1 200 OK
< content-length: 719
< content-type: text/plain; charset=utf-8
< date: Tue, 30 Jul 2024 14:38:18 GMT
< traceparent: 00-00000000000000000000000000000000-0000000000000000-00
< x-envoy-upstream-service-time: 18
< server: envoy
<
Name: v1
Hostname: whoami-v1-cd9b4bdf7-4tmvr
IP: 127.0.0.1
IP: ::1
IP: 10.42.1.30
IP: fe80::7f:66ff:fe14:15ad
RemoteAddr: 10.42.0.60:55178
GET / HTTP/1.1
Host: whoami.default.svc.cluster.local:80
User-Agent: curl/8.4.0
Accept: */*
Accept-Encoding: gzip
Dapr-Callee-App-Id: whoami
Dapr-Caller-App-Id: ingress
Forwarded: for=10.42.0.131;by=10.42

.0.131;host=ingress-shared-dapr-shared-chart-bfnxc
Traceparent: 00-00000000000000000000000000000000-0000000000000000-00
X-Envoy-Internal: true
X-Envoy-Original-Path: /
X-Forwarded-For: 10.42.1.110
X-Forwarded-For: 10.42.0.131
X-Forwarded-Host: ingress-shared-dapr-shared-chart-bfnxc
X-Forwarded-Proto: http
X-Request-Id: 5556df41-f78f-4c98-9526-f5025a787a1e

* Connection #0 to host 18.192.114.200 left intact

從頭文件中，你可以看到 Dapr-Callee-App-Id 和 Dapr-Caller-App-Id，表明流量正確通過 Dapr 實例路由。這個設置確保連接默認通過 mTLS（傳輸）加密，爲我們的通信增加了額外的安全層。我們已經成功地將 Dapr 與 Cilium 的服務網格整合在一起，利用其先進的功能增強了應用的網絡和服務調用。

實現流量轉移使用 Gamma

Dapr 不提供的一個功能，但 Cilium 提供的是流量轉移。幸運的是，通過我們的集成，我們可以利用 Cilium 的 GAMMA（服務網格的 Gateway API）來啓用這個功能。GAMMA 擴展了 Gateway API 以支持集羣內的東西向流量管理，補充其用於南北向流量的用途。要設置流量轉移，我們需要創建一個 HTTPRoute 配置，以便在應用的不同版本之間進行負載平衡。通過利用 GAMMA，你可以在不同版本的應用之間轉移流量，使得部署新功能或進行金絲雀發佈更容易，最小化中斷。首先，我們將部署 whoami 應用的新版本併爲其創建額外的服務。以下是部署 whoami 版本 2 並設置必要服務的 YAML 配置：

apiVersion: v1
kind: Service
metadata:
  name: whoami-v1
  labels:
    app: whoami
    version: v1
spec:
  ports:
    - name: http
      targetPort: 80
      port: 80
  selector:
    app: whoami
    version: v1
---
apiVersion: v1
kind: Service
metadata:
  name: whoami-v2
  labels:
    app: whoami
    version: v2
spec:
  ports:
    - name: http
      targetPort: 80
      port: 80
  selector:
    app: whoami
    version: v2
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: whoami-v2
spec:
  replicas: 2
  selector:
    matchLabels:
      app: whoami
      version: v2
  template:
    metadata:
      labels:
        app: whoami
        version: v2
    spec:
      serviceAccountName: whoami
      containers:
        - image: traefik/whoami
          imagePullPolicy: IfNotPresent
          name: whoami
          ports:
            - containerPort: 80
          env:
            - name: WHOAMI_NAME
              value: "v2"

接下來，我們配置一個 HTTPRoute 來啓用在 whoami-v1 和 whoami-v2 之間的流量轉移。HTTPRoute 將根據定義的權重將一定比例的流量路由到每個應用版本。

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: whoami-route-service
spec:
  parentRefs:
  - group: ""
    kind: Service
    name: whoami
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: whoami-v1
      port: 80
      weight: 50
    - name: whoami-v2
      port: 80
      weight: 50

這裏重要的部分是 parentRefs。雖然在傳統的 Gateway API 中，我們使用這個來綁定該 HTTPRoute 到一個網關，我們在這裏將其綁定到 whoami 服務，啓用 GAMMA 案例。

此外，通過在 backendRef 中定義 weight，我們可以調整我們希望如何轉移流量。爲了確保流量轉移工作正確，你可以進行多次 curl 請求並檢查響應，以驗證流量是否按照指定在 whoami-v1 和 whoami-v2 之間分配。

curl http://18.192.114.200
Name: v1
Hostname: whoami-v1-cd9b4bdf7-4tmvr
IP: 127.0.0.1
IP: ::1
IP: 10.42.1.30
IP: fe80::7f:66ff:fe14:15ad
RemoteAddr: 10.42.0.60:55178
GET / HTTP/1.1
Host: whoami.default.svc.cluster.local:80
User-Agent: curl/8.4.0
Accept: */*
Accept-Encoding: gzip
Dapr-Callee-App-Id: whoami
Dapr-Caller-App-Id: ingress
Forwarded: for=10.42.0.131;by=10.42.0.131;host=ingress-shared-dapr-shared-chart-bfnxc
Traceparent: 00-00000000000000000000000000000000-0000000000000000-00
X-Envoy-Internal: true
X-Envoy-Original-Path: /
X-Forwarded-For: 10.42.1.110
X-Forwarded-For: 10.42.0.131
X-Forwarded-Host: ingress-shared-dapr-shared-chart-bfnxc
X-Forwarded-Proto: http
X-Request-Id: e9d8ab85-8ae7-46a9-8b44-42240d1d6833
---
curl http://18.192.114.200
Name: v2
Hostname: whoami-v2-766bb5fbd5-bfx9j
IP: 127.0.0.1
IP: ::1
IP: 10.42.1.181
IP: fe80::d441:87ff:fea1:d123
RemoteAddr: 10.42.1.27:32774
GET / HTTP/1.1
Host: whoami.default.svc.cluster.local:80
User-Agent: curl/8.4.0
Accept: */*
Accept-Encoding: gzip
Dapr-Callee-App-Id: whoami
Dapr-Caller-App-Id: ingress
Forwarded: for=10.42.0.131;by=10.42.0.131;host=ingress-shared-dapr-shared-chart-bfnxc
Traceparent: 00-00000000000000000000000000000000-0000000000000000-00
X-Envoy-Internal: true
X-Envoy-Original-Path: /
X-Forwarded-For: 10.42.1.64
X-Forwarded-For: 10.42.0.131
X-Forwarded-Host: ingress-shared-dapr-shared-chart-bfnxc
X-Forwarded-Proto: http
X-Request-Id: f1df7207-098c-4a98-8a97-858ce1f9c0ed

你應該會看到基於配置的流量權重，從兩個應用版本收到響應。此外，我們可以查閱 hubble flow 日誌來檢查實際連接情況：

Jul 29 15:18:13.883: kube-system/svclb-cilium-gateway-default-gateway-f455e04d-jljl8:54047 (ingress) -> default/ingress-shared-dapr-shared-chart-g2596:3500 (ID:33809) http-request FORWARDED (HTTP/1.1 GET http://whoami.cloud-native.rocks/v1.0/invoke/whoami.default/method/something)
Jul 29 15:18:13.884: 10.42.1.170:39105 (ingress) <> default/ingress-shared-dapr-shared-chart-g2596:3500 (ID:33809) to-overlay FORWARDED (TCP Flags: ACK, PSH)
Jul 29 15:18:13.884: 10.42.1.170:39105 (ingress)

 -> default/ingress-shared-dapr-shared-chart-g2596:3500 (ID:33809) to-endpoint FORWARDED (TCP Flags: ACK, PSH)
Jul 29 15:18:13.890: default/ingress-shared-dapr-shared-chart-g2596:55194 (ID:33809) -> default/whoami-shared-dapr-shared-chart-crmxz:50002 (ID:14274) to-endpoint FORWARDED (TCP Flags: ACK, PSH)
Jul 29 15:18:13.890: default/ingress-shared-dapr-shared-chart-g2596:55194 (ID:33809) <- default/whoami-shared-dapr-shared-chart-crmxz:50002 (ID:14274) to-endpoint FORWARDED (TCP Flags: ACK)
Jul 29 15:18:13.891: default/whoami-shared-dapr-shared-chart-crmxz:46028 (ID:14274) -> default/whoami-v1-cd9b4bdf7-gxkvt:80 (ID:26920) to-endpoint FORWARDED (TCP Flags: ACK, PSH)
Jul 29 15:18:13.891: default/whoami-shared-dapr-shared-chart-crmxz:46028 (ID:14274) <- default/whoami-v1-cd9b4bdf7-gxkvt:80 (ID:26920) to-endpoint FORWARDED (TCP Flags: ACK, PSH)
Jul 29 15:18:13.893: 10.42.1.170:39105 (ingress) <> default/ingress-shared-dapr-shared-chart-g2596:3500 (ID:33809) to-overlay FORWARDED (TCP Flags: ACK)
Jul 29 15:18:13.895: kube-system/svclb-cilium-gateway-default-gateway-f455e04d-jljl8:54047 (ingress) <- default/ingress-shared-dapr-shared-chart-g2596:3500 (ID:33809) http-response FORWARDED (HTTP/1.1 200 15ms (GET http://whoami.cloud-native.rocks/v1.0/invoke/whoami.default/method/something))
Jul 29 15:18:14.405: kube-system/svclb-cilium-gateway-default-gateway-f455e04d-jljl8:54048 (ingress) -> default/ingress-shared-dapr-shared-chart-zxv74:3500 (ID:33809) http-request FORWARDED (HTTP/1.1 GET http://whoami.cloud-native.rocks/v1.0/invoke/whoami.default/method/something)
Jul 29 15:18:14.406: 10.42.1.170:38391 (ingress) -> default/ingress-shared-dapr-shared-chart-zxv74:3500 (ID:33809) to-endpoint FORWARDED (TCP Flags: ACK, PSH)
Jul 29 15:18:14.414: default/ingress-shared-dapr-shared-chart-zxv74:55876 (ID:33809) -> default/whoami-shared-dapr-shared-chart-g572c:50002 (ID:14274) to-endpoint FORWARDED (TCP Flags: ACK, PSH)
Jul 29 15:18:14.414: default/whoami-shared-dapr-shared-chart-g572c:58854 (ID:14274) -> default/whoami-v2-766bb5fbd5-jvtcd:80 (ID:2184) to-endpoint FORWARDED (TCP Flags: ACK, PSH)
Jul 29 15:18:14.414: default/ingress-shared-dapr-shared-chart-zxv74:55876 (ID:33809) <- default/whoami-shared-dapr-shared-chart-g572c:50002 (ID:14274) to-endpoint FORWARDED (TCP Flags: ACK, PSH)
Jul 29 15:18:14.415: default/whoami-shared-dapr-shared-chart-g572c:58854 (ID:14274) <- default/whoami-v2-766bb5fbd5-jvtcd:80 (ID:2184) to-endpoint FORWARDED (TCP Flags: ACK, PSH)

這個日誌顯示，流量被重定向到 whoami-v1 以及 whoami-v2。在 hubble UI 中，這也是可見的。

使用網絡策略進行訪問控制

有了 Cilium 處理到 Dapr 的流量，我們可以利用 Cilium 的網絡策略來配置訪問控制。與 Dapr 的訪問控制在第 7 層（應用層）操作不同，Cilium 的方法在更低的網絡堆棧層次上工作，提供更細粒度的控制。

下面是如何使用 Cilium 的 CiliumNetworkPolicy 配置訪問控制：

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: "allow-ingress-shared-to-whoami"
spec:
  endpointSelector:
    matchLabels:
      dapr.io/app-id: whoami
  ingress:
  - fromEndpoints:
    - matchLabels:
         dapr.io/app-id: ingress
    toPorts:
    - ports:
      - port: "50002"
        protocol: TCP
---
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "allow-ingress-to-ingress-shared"
spec:
  endpointSelector:
    matchLabels:
      dapr.io/app-id: ingress
  ingress:
  - fromEntities:
    - ingress
    toPorts:
    - ports:
      - port: "3500"
        protocol: TCP

這兩個策略將限制我們集羣中的流量流向。它們確保只允許 cilium-gateway 連接到 ingress-dapr 實例。類似地，ingress-dapr 實例是唯一允許與 whoami-dapr 實例通信的實體。這個設置確保 Dapr 共享實例是彼此唯一的通信者，增強了安全性和控制。Cilium 在第 3 層和第 4 層應用網絡策略，提供了在流量到達應用層之前的更細粒度控制。這通過在網絡堆棧的早期阻止未經授權的訪問來減少不必要的流量，並通過提升性能來增強性能。

優勢 1 - 本地重定向策略

Cilium 1.16 引入了一個名爲 Local Redirect Policy 的 beta 功能。這個功能允許你將流量重定向到同一節點上的本地端點，而不是在整個集羣中路由。這對於優化流量流和確保某些連接保持本地特別有用。

apiVersion: "cilium.io/v2"
kind: CiliumLocalRedirectPolicy
metadata:
  name: "redirect-ingress"
spec:
  redirectFrontend:
    serviceMatcher:
      serviceName: ingress-dapr
      namespace: default
  redirectBackend:
    localEndpointSelector:
      matchLabels:
        dapr.io/app-id: ingress
    toPorts:
      - port: "3500"
        protocol: TCP

我們將使用這個策略確保從 cilium-gateway 到其 Dapr 共享實例的流量保持在節點上。這種方法將連接保持在同一節點上，確保在流量離開節點之前建立並維持 mTLS。請注意，由於這是一個 beta 功能，你需要在 Cilium 中啓用它。有關啓用此功能的指南，請參閱 Cilium 文檔。

優勢 2 - mTLS 和強身份

將 Cilium 整合到你的設置中的另一個優勢是使用 Cilium 的 mTLS 功能，而不是 Dapr 的。Cilium 通過節點間的 Wireguard 或 IPSec 隧道提供 mTLS，與 Dapr 通過雙向 gRPC 連接使用 mTLS 的方法相比，提供了明顯的好處。

• 內核級執行：Cilium 的 mTLS 可以直接在 Linux 內核中執行，利用 Wireguard 或 IPSec。這種方法通常比 Dapr 通過 gRPC 的用戶空間實現的 mTLS 提供更好的性能。
• 廣泛的加密覆蓋：Cilium 確保所有服務到服務的連接都
• 加密，而不僅僅是那些通過 Dapr 進行的。這提供了一個更全面的安全模型。

一旦在 Cilium 本身啓用了 mTLS，你可以通過將其附加到 CiliumNetworkPolicy 來在 Cilium 中強制執行 mTLS：

authentication:
    mode: "required"

Cilium 將檢查匹配的強身份以及 mTLS 驗證。

總結

總之，Dapr 與 Cilium 的無 sidecar 服務網格的整合爲微服務架構打開了新的可能性。通過利用 Dapr 共享，我們可以將 Dapr 運行時的生命週期與應用解耦，允許更靈活的部署。Dapr 的強大服務調用能力與 Cilium 的高效、基於 eBPF 的網絡和服務網格功能的結合，使得微服務交互具有高性能、安全性和彈性。

這次演示展示了這些技術如何協調一致，創造了一個簡化服務管理的前沿基礎設施，同時增強了可擴展性和可靠性。Dapr 和 Cilium 的整合代表了構建下一代分佈式應用的重要一步。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/OtjUzi6UfGmAa7Z8gaG2LQ