使用 Dapr 与 Cilium 打造无 Sidecar 服务网格：新一代分布式应用运行时

weixin_38754564

于 2024-08-27 11:30:43 发布

阅读量103

点赞数

原文链接：https://mp.weixin.qq.com/s?__biz=MzIwNDIzODExOA==&mid=2650169438&idx=1&sn=27621ee146cbd6089230f2fc69219576&chksm=8fc3ff74fe9baa6932588e006eb65b767333d308d75ea0c4a08542bf794cf76008500c7f8fef&scene=126&sessionid=0

版权

本文探讨了将 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 服务网格。

基于 Cilium 的服务网格

这种服务网格旨在广泛利用 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 的整合代表了构建下一代分布式应用的重要一步。

获取更多云原生社区资讯，加入微信群，请加入云原生社区，点击阅读原文了解更多。