ACMG 2.0 支持零信任网络模式

云布道师

在 ACMG 2.0 中，我们为用户提供了两种使用模式，第一种是无侵入转发模式，在这种模式下，ACMG 不会向 Pod 或者 Node 中插入 sidecar 或者 proxy 等代理对象，而是通过域名的方式将流量转发到 ACMG 集中式网关上，从而让集中式网关接管集群内的流量。另一种模式是零信任网络模式，此模式是专为构建零信任网络集群的，在此模式下，ACMG 在集群中的 Node 上插入 NodeProxy 代理对象，将流量转发到 ACMG 集中式网关上，自动构建出安全可靠的通信环境。

github链接：https://github.com/alibaba/alibaba-centralized-mesh-gateway/tree/acmg2.0

ACMG支持的转发方式

无侵入转发模式

  无侵入转发模式实际上是利用域名来进行流量转发。在域名转发模式下，流量路径相比无 ACMG 下，只多了集中式网关这一层代理，而相比 Sidecar 模式，少了一层Envoy 代理以及 iptables 等流量劫持规则。这意味着用户在访问服务时，只需要通过集中式网关，就可以访问到所对应的服务，域名转发模式更加简洁，易于管理与维护，简化网络的安全配置和管理，减少管理员的工作量。此外由于域名转发模式没有任何的侵入性组件，因此还可以更好的节省业务节点的资源。
1

优点

流量路径清晰，不占用业务单元资源

由于减少 sidecar 等中间代理，性能更高，延迟更低

运维负担轻，并且后续用户可以自由选择将 ACMG 网关托管或者自建 ACMG 网关

支持多种语言和框架，可以与各种后端服务和应用程序进行集成。无论是使用Kubernetes、VM、容器化、无服务器等环境

缺点

由于缺少 sidecar/nodeproxy 等流量节点，无法自动构建双向认证下的零信任网络，需要用户手动进行配置

由于缺少 sidecar/nodeproxy 等流量节点，在全链路追踪、指标输出等方面表现会略差一些

零信任网络模式

  随着网络安全攻击、数据泄漏的事件不断增加，企业和组织对网络安全的重视程度也在不断提高，而安全性是 Service Mesh 的重要组成部分之一。零信任网络（Zero Trust Network）在网络的每个层面上都进行身份验证和访问控制，确保只有授权的用户才能访问受保护的资源。通过零信任网络，企业用户可以更好地管理网络访问权限，降低攻击者利用漏洞进行攻击的风险。
1

优点

安全性大大提升，天然支持服务间的身份认证、流量加密、访问控制和审计等。开发人员可以轻松地为服务网格中的服务提供细粒度的访问控制，并检测和防止常见的网络攻击

提供了对服务网格中的流量和性能的全面可观察性。通过集成 Prometheus、Grafana 等监控工具，开发人员可以实时监控和可视化服务的指标、日志和跟踪数据，以便进行故障排除和性能优化

运维负担轻，并且后续用户可以自由选择将 ACMG 网关托管或者自建 ACMG 网关

支持多种语言和框架，可以与各种后端服务和应用程序进行集成。无论是使用Kubernetes、VM、容器化、无服务器等环境

缺点

由于 nodeproxy 模式使用了额外的 L4 代理来处理流量和执行功能，这可能会引入一定的性能开销。特别是在大规模的部署中，代理的数量和网络流量可能会对整体性能产生影响

多转发节点带来了更复杂的网络框架，配置和管理它需要一定的学习成本和技术知识。特别是对于小规模的项目来说，可能会增加不必要的复杂性

上手试一试

我们以无侵入转发模式为例，介绍下 ACMG 的使用方式

部署

istioctl install --set profile=acmg
1

在执行部署命令后，会在 istio-system 命名空间中看到 ACMG 的各个 Pod 都处于 Ready 状态。

NAME                                   READY   STATUS    RESTARTS   AGE
istio-cni-node-7hnzt                   1/1     Running   0          1m
istio-cni-node-r2rwx                   1/1     Running   0          1m
istio-cni-node-s8xz9                   1/1     Running   0          1m
coreproxy-mj2xp                        1/1     Running   0          1m
istiod-6f9c757686-hcm59                1/1     Running   0          1m
nodeproxy-d2xq7                        1/1     Running   0          1m
nodeproxy-snc9n                        1/1     Running   0          1m
nodeproxy-tb5f2                        1/1     Running   0          1m
1
2
3
4
5
6
7
8
9

使用

kubectl label namespace productpagens istio.io/dataplane-mode=acmg
1

高级用法

  同样的，ACMG 2.0 支持 Istio 中的路由规则 CRD，例如用于定义服务之间的流量转发和管理的 VirtualService，它可以帮助开发人员实现灵活的流量控制和路由策略；用于定义服务的网络规则，包括负载均衡、连接池、故障转移等策略的DestinationRule；用于定义对服务的访问控制策略。可以配置允许或拒绝特定用户或服务的请求访问的 AuthorizationPolicy 等。ACMG 2.0 提供了更精细的流量控制和管理能力，有助于开发人员提高服务的可用性、性能和弹性。

  以 bookinfo 为例，使用 VirtualService 和 DestinationRule 定义服务的路由策略：
1
2
3

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 80
    - destination:
        host: reviews
        subset: v2
      weight: 20
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  trafficPolicy:
    loadBalancer:
      simple: RANDOM
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
  - name: v3
    labels:
      version: v3
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

  以 bookinfo 为例，使用 AuthorizationPolicy 定义服务的访问控制策略：
1

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: productpage-client
 namespace: productpagens
spec:
 selector:
   matchLabels:
     app: productpage
 action: ALLOW
 rules:
 - from:
   - source:
       principals: ["cluster.local/ns/default/sa/sleep", "cluster.local/ns/default/sa/nosleep"]
   to:
   - operation:
       methods: ["GET","PUT"]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

卸载

istioctl uninstall --purge
1

和其他方案的对比数据

  下面是 acmg 与 sidecar、ambient 的模式对比，其中 acmg 测试是在托管模式下，其中托管模式中针对阿里云的场景，我们做了一些资源整合、容灾能力以及性能优化的工作。包括加解密卸载，资源快速倒换，资源动态伸缩等。(注：其中图中的 Canal 指的托管版的 ACMG)
  在资源占用上，我们测试了不同的吞吐下，三种不同的模式下的 CPU 利用率，以及最大吞吐：
1
2

ACMG 在 CPU 利用率上，相比 SIdeCar 大约提升了 8 倍，相比 Ambient 大约提升了 2.3 倍。ACMG 2.0 在架构设计上，首先在 Node 上应用了轻量的 L4 节点， L4 节点 NodeProxy 是一个轻量级的组件，仅负责身份认证和目标网络地址转换（DNAT），不需要进行深入的数据包分析和处理。相比于传统的完整的网络中间件，如负载均衡器或防火墙，L4 节点的资源消耗更低。它只需执行简单的任务，不需要维护复杂的 Session 表或执行深度数据包检查等操作。

  在转发时延上，我们测试了不同吞吐下，三种不同的模式下分配相同资源情况下的 P99 延时，当吞吐量较小时，三个模式的延时并没有呈现出巨大的差异：
1

当逐步加大压测量，逼近转发的极限值时，三种不同的模式的表现差异较大：

ACMG 在转发延时方面，相比 SideCar 大约提升了 4.1 倍，最大吞吐提升了 12倍，相比 Ambient 大约提升了 1.4 倍，最大吞吐提升了 3.2 倍。SideCar 的双重 L7 负载均衡在数据处理和资源利用方面都比较繁重，而 Ambient 的 L7 模式下， Ztunnel 的转发效率和资源利用也不及 ACMG。SideCar 模式在两层 L7 负载均衡下需要处理更多的数据和请求，因此其性能和延迟可能会受到影响。而 Ambient 在L7 模式下使用 Ztunnel 进行转发，会相对的轻量一些，但是转发效率和资源利用率还是不如 ACMG，而这种差异在越来越大的流量下，差异化也越来越明显。
在配置面上，我们测试了同等数量的 Pod 等弹缩时，三种模式下需要更新的配置量，这个与配置生效时间息息相关。

在相同的用户配置下，ACMG 相比 SideCar，南向配置减少了 10.6 倍，相比Ambient 减少了 3.1 倍。ACMG 对配置进行了裁剪和优化。而且 ACMG 只需将大部分配置下发到集中式转发网关，而不需要在每个节点上进行单独配置。这简化了配置管理的复杂性，也降低了配置推送的延迟和资源消耗。

  集中式转发网关的方式进一步提高了配置管理和南向配置推送的性能，可以减少对每个节点进行配置推送的工作量和延迟。这种集中式管理方式简化了配置管理，同时提高了配置推送的效率和一致性。这种优势在大规模部署服务的 Kubernetes 集群中尤为明显，显著减少配置管理的工作量和资源消耗，提高配置推送的效率和一致性。
1

后面我们还会做什么

更丰富的网络和安全特性：acmg 后面会引入更多的网络和安全特性，以满足不同流量场景下的需求。例如，进一步增强的访问控制、流量控制和审计功能，以及更灵活的网络配置选项。

多场景的支持；在复杂的多场景中提供统一的服务管理、通信和网络控制能力。帮助应用程序在混布环境、多 VPC、多 Region 和多集群中实现灵活、可靠和可观察的通信和管理。

性能优化；比如利用高效的数据传输以及压缩算法来提高性能并减少网络带宽的使用，在一定程度上减少数据传输的大小和时延，提高整体的性能和效率。