转载自公众号：云计算地理学101报告
ID：gh_f5828f903045
原文地址：
https://mp.weixin.qq.com/s?__biz=Mzg2MDY3NjA3NQ==&mid=2247483974&idx=1&sn=ef91cddc0314b654b9d4839727bfd641&chksm=ce2388c2f95401d4a7f7778f731be4e2e42b06dd7fb02f7dc14b0dc5fae15370b54200b077f1&token=1060090878&lang=zh_CN#rd
Cilium 是一个开源项目，旨在透明地提供和保护使用 Kubernetes 以及其他容器编排平台部署的应用程序之间的网络连接。Cilium 的基础是 eBPF，它是一种新的 Linux 内核技术，能够将强大的安全性、可见性和网络控制逻辑动态插入到 Linux 内核中，实现了在不更改应用程序代码或容器配置的情况下应用和更新 Cilium 安全策略。
Cilium Service Mesh 的第一个版本已经可以在 Cilium 1.12 版本中使用，它允许用户通过配置选项选择在没有 Sidecar 的情况下运行服务网格，同时支持各种控制平面。它补充了现有的基于 Sidecar 的 Istio 集成方式，这样做的目标是为了降低服务网格层的复杂性和开销。用户可以在运行服务网格时根据自己的需要，以最能满足其平台要求的方式来选择是否带有 Sidecar。
企业级服务网格
随着越来越多的企业采用 Kubernetes，我们看到企业级服务网格的需求也变得越来越重要。这给最初由 Web 应用程序团队衍生出来的服务网格概念带来了许多新的企业网络需求，这些新的需求使 Kubernetes 网络/CNI 层和服务网格层更紧密地结合在一起，并产生了一个新的服务层级，用于将两者组合起来，同时提供以下功能：
- 公共云和本地基础设施集成：与 Kubernetes 类似，服务网格主要专注于支持在公共云中部署的基础设施。随着企业开始考虑采用这一技术，对本地的基础设施以及将云和本地连接在一起的需求正在迅速增长。在多云和多集群的情况下，屏蔽底层基础设施服务，提供跨云连接的安全性和可观察性。
- 网络层的控制：网络层控制的关键不仅是与本地现有企业网络组件集成，而且还必须满足云中网络分割、加密和可见性的合规性要求。这包括提供网络策略、出口网关、透明加密、BGP、SRv6 以及与传统防火墙集成等功能。
应用程序协议级别的控制：需要了解 HTTP 和 gRPC 等应用程序协议，以通过实现流量管理、金丝雀发布、跟踪和 L7 授权等功能来满足现代应用程序开发原则的要求。这是通过实现像 Ingress 和 APIGateway 这样的标准来实现的。
作为 Isovalent，我们创建了非常成功的 CNCF 项目 Cilium，它已成为云原生网络和安全的事实标准。Cilium 正在为 Adobe、Bell Canada、Capital One 和 IKEA 等主要企业的基础设施以及 Google Cloud 和 AWS 这样的 Kubernetes 托管平台提供支持，并且也是众多 Kubernetes 发行版中的默认 CNI。随着 Cilium Service Mesh 的引入，我们正在扩展应用协议级别的功能。
什么是服务网格？
随着分布式应用程序的引入，额外的可见性、连接性和安全性需求也出现了。应用程序组件在不受信任的网络上跨云和服务边界进行通信时，需要负载均衡来解析应用程序协议，这个过程中弹性变得至关重要，同时安全性方面也必须改变为发送方和接收方可以相互验证身份的模型。在分布式应用程序的早期，这些需求是通过将所需的逻辑直接嵌入到应用程序中来解决的。服务网格将这些特性从应用程序中提取出来，并将它们作为基础设施的一部分提供给所有应用程序使用，因此不再需要更改每个应用程序。
现在看一下服务网格的特性，可以总结如下：
- 弹性连接：服务到服务的通信必须能够跨越云、集群等边界。通信必须具有弹性和容错性。
- L7 流量管理：负载均衡、速率限制和弹性必须支持 L7（HTTP、REST、gRPC、WebSocket 等）。
- 基于身份的安全性：依靠网络标识符来实现安全性已经不够了，发送和接收服务必须能够基于身份而不是网络标识符来验证彼此。
- 可观察性和跟踪：跟踪（Tracing）和指标（Metrics）形式的可观察性对于理解、监控应用程序稳定性、性能和可用性至关重要。
透明度：功能必须以透明的方式提供给应用程序，即无需更改应用程序代码。
为什么选择 Cilium 服务网格？
从早期开始，Cilium 就通过在网络层和应用程序协议层运行来提供连接性、负载均衡、安全性和可观察性，从而很好的与服务网格概念保持一致。对于所有网络处理（包括 IP、TCP 和 UDP 等协议），Cilium 使用 eBPF 作为高效的内核数据路径。应用层的 HTTP、Kafka、gRPC 和 DNS 等协议使用 Envoy 等代理进行解析。最后，对于超出 Cilium 功能的服务网格用例，Cilium 提供了 Istio 集成。它将所有 Istio 功能带入 Cilium，同时允许 Cilium 通过 Istio 管理的 Sidecar 执行 L7 策略。Cilium 也提供了一些自动化功能，例如缩短 Sidecar 网络注入路径，防止暴露应用程序和 Sidecar 之间的未加密数据等。
当 Cilium 社区开始讨论和辩论提供 Cilium 原生服务网格的话题时，我们进行了各种最终用户调查并听取了客户的意见。我们收到的反馈是一致且明确的：
- Kubernetes-native：我们的团队已经知道如何使用 Kubernetes。我们希望在不学习很多新概念的情况下使用服务网格功能，并提供 Kubernetes 原生用户体验，就像 Cilium Cluster Mesh 使用 Kubernetes 服务和 NetworkPolicy 来操作多集群连接以及安全策略一样。
降低复杂性和开销：Sidecar 的复杂性和开销对用户的影响是非常严重的。为我们提供一个简单的数据路径模型，在支持任意网络协议的同时避免开销。Kelsey Hightower 将此称为“服务混乱”。
选择 Sidecar 或 Sidecar-free
在 Cilium Service Mesh 的第一个版本中，用户现在可以选择运行带有或不带有 Sidecar 的服务网格。何时使用哪种模型能够达到最佳效果取决于各种因素，包括开销、资源管理、故障域和安全考虑。事实上，这种权衡与虚拟机和容器非常相似。VM 提供更严格的隔离，容器更轻量，能够共享资源并提供可用资源的公平分配。正因为如此，容器通常会增加部署密度，同时还要权衡额外的安全性和资源管理挑战。使用 Cilium Service Mesh，你可以在你的平台上同时使用这两种方式，甚至可以混合使用。
Sidecar 的性能影响
除了避免需要在 Sidecar 模型中运行的大量代理之外，无 Sidecar 模型的一个显著优势是我们可以避免在任何连接之间运行两个代理。这可以通过在网络/节点级别使用 Cilium 进行加密和身份验证或使用即将推出的新 mTLS 模型来实现，该模型将身份验证与传输分开（更多细节可参阅：使用 Cilium 服务网格的下一代相互身份验证[1]）
网络路径中的代理数量和 Envoy 过滤器的类型对性能有显著影响。上面的基准测试说明了运行 Cilium Envoy 过滤器（棕色）的单个 Envoy 代理与运行 Istio Envoy 过滤器（蓝色）的双向 Envoy 模型相比的 HTTP 处理延迟成本。黄色是没有代理且没有执行 HTTP 处理的基线延迟。
使用 eBPF-Native
除了删除 Sidecar 的选项外，Cilium Service Mesh 还可以直接在 eBPF 中执行各种服务网格功能，从而进一步减少开销。一般情况下，尽可能在 eBPF 中以较低的成本执行处理。如果 eBPF 无法处理请求，例如当需要拼接连接、限制请求的速率或执行 TLS 终止时，则处理会退回到运行在 Sidecar 或 Sidecar-free 模型中的 Envoy。这提供了两全其美的方式——在一般情况下进行 eBPF 处理以提高性能和减少延迟，并始终能够根据需要回退到 Envoy。
一个特别强大的用例是支持跟踪 HTTP/2 的可见性和指标用例，例如，使用 Prometheus 和 Grafana 构建黄金信号仪表板。能够显著降低延迟和计算方面的成本：
您可以在上面看到测量 P95 延迟的 HTTP 请求/响应基准。它比较了运行基于 eBPF 的 HTTP/2 解析器（棕色）、Sidecar 方法（蓝色）和未启用可见性的基线（黄色）时对延迟的影响。基于 eBPF 的 HTTP/2 解析器在 Isovalent Cilium Enterprise 中可用。Sidecar 代理的选择并不重要（本例中使用了 Envoy），但我们测试的其他代理的结果几乎相同，因为主要成本源于代理的注入以及终止连接和遍历上下游之间的数据。
在 eBPF 中可以做什么？什么时候需要代理？
下表列出了最常见的服务网格特性，以及它们是否需要通过在 Sidecar 或 Sidecar-free 模式下运行的代理进行路由：
扩展控制平面
Kubernetes 一直非常擅长在不同的复杂程度提供不同的抽象，而 Cilium Service Mesh 也允许用户这样做，这能够解决用户的第二大需求，即降低采用服务网格时的复杂度和学习曲线。除了现有的 Istio 集成之外，我们正在扩展支持的服务网格控制平面的数量，以将新的无 Sidecar 数据路径选项引入现有的服务网格标准。
服务网格控制平面支持情况如下：
- Istio（已支持）
Istio 是已经支持的服务网格控制平面，它目前需要使用基于 Sidecar 的模式运行。如果有兴趣，我们正在考虑将无 Sidecar 的数据路径引入 Istio。如果您认为这很有趣，请与我们联系。
- Prometheus / OpenTelemetry（已支持）
L7 可观测性一直是 Cilium 的一个特点。使用标准 Prometheus 和 OpenTelemetry 以指标和跟踪数据的形式提供可见性。
- Kubernetes Ingress（新增支持）
Cilium Service Mesh 的第一个版本包括一个完全兼容的 Kubernetes Ingress 控制器，使应用程序团队能够通过标准化的 Kubernetes 流量入口使用 L7 负载均衡和流量管理功能。Kubernetes Ingress 负载均衡可以应用于集群入口、集群内部和跨集群的流量。（请参阅 Kubernetes Ingress 入门[2]）
- Envoy 配置 CRD（新增支持）
一个新的令人兴奋的 Envoy 配置 CRD 可用，使整个 Envoy 代理功能可以在网络中的任何地方使用。这使用户能够直接编写 Envoy 配置，并将其应用到网络中的任何地方，以启用甚至没有被 Istio 等服务网格覆盖的高级用例。
- Gateway API（正在进行中）
我们正在努力支持 Kubernetes Gateway API 标准作为下一个受支持的控制平面。它在 Kubernetes Ingress 之上带来了额外的功能，并且对于许多应用程序和平台团队来说可能是一个可行的选择，因为它在功能和复杂性之间取得了很好的平衡。
- SPIFFE（规划中）
对 SPIFFE 的支持已经在规划中，可以提供服务证书和基于代理的 mTLS。
适用于任何网络协议的 mTLS
通过将身份验证握手与负载传输分开，我们可以使用 TLS 1.3 作为握手协议，同时依赖 IPsec 或 WireGuard 作为性能更好、更透明的负载通道：
这两种模型实现了许多出色的特性：
- 不再需要终止连接：基于 Sidecar 的方法需要将每个 TCP 连接转换为 3 个阶段以注入 TLS。无 Sidecar 方法不需要终止或操作连接。
- 无需注入 Sidecar：服务的身份验证可以由单个节点代理执行，无需运行额外的代理。在使用 Cilium 的情况下，这个代理默认存在并且能够获取所有需要的上下文。这简化了管理、改善了资源占用并提高了可扩展性。
- 支持非 TCP 和多播：在受益于 TLS 1.3 的强大特性（例如低延迟握手）的同时，能够支持 UDP、ICMP 和任何其他 IP 可承载的协议。
- 支持现有的身份和证书管理：任何基于 mTLS 的身份验证控制平面或身份管理系统都可以插入并用于为服务提供证书。这包括 SPIFFE、Vault、SMI、Istio 等。
握手缓存和定期身份验证：握手可以一次完成并进行缓存，在经过身份验证的服务之间进行访问时不会引入额外的延迟。另外，可以定期进行身份验证，以定期重新对服务进行身份验证。
结论
我们对 Cilium Service Mesh 的初始版本发布感到兴奋，它在 Cilium 现有功能的基础之上，还为用户提供了更多的选择：
- 控制平面：选择不同的控制平面以实现复杂性和丰富性的平衡。从 Ingress 和 Gateway API 等简单的选项，到 Istio 丰富选项，再到通过 Envoy CRD 发挥 Envoy 的全部功能。
Sidecar vs Sidecar-free：可以选择带或不带 Sidecar 的模式。具有 VM 风格资源隔离的 Sidecar 模式会增加成本和开销，具有容器风格的不带 Sidecar 模式需要管理共享资源的使用。
参考资料
[1] Next-Generation Mutual Authentication with Cilium Service Mesh: https://isovalent.com/blog/post/2022-05-03-servicemesh-security/
[2] Getting Started with Kubernetes Ingress: https://docs.cilium.io/en/latest/gettingstarted/servicemesh/ingress/
[3] Cilium 1.12 – Ingress, Multi-Cluster, Service Mesh, External Workloads, and much more: https://isovalent.com/blog/post/cilium-release-112/
[4] A Guided Tour of Cilium Service Mesh – Liz Rice – KubeCon 2022: https://www.youtube.com/watch?v=e10kDBEsZw4&ab_channel=CNCF%5BCloudNativeComputingFoundation%5D
[5] Cilium Service Mesh – Getting Started Guides: https://docs.cilium.io/en/latest/gettingstarted/#service-mesh
[6] How eBPF will solve Service Mesh – Goodbye Sidecars: https://isovalent.com/blog/post/2021-12-08-ebpf-servicemesh/
[7] eCHO Episode 32 – Hands-On with Cilium Service Mesh: https://www.youtube.com/watch?v=s-tgbD7wN3U&ab_channel=eBPF%26CiliumCommunity
