云端扩展：Istio Ambient 与 Cilium
深入探讨大规模性能。
Istio 的潜在用户经常会问：“Istio 与 Cilium 相比如何？”虽然 Cilium 最初只提供 L3/L4 功能（包括网络策略），但最近的版本添加了使用 Envoy 的服务网格功能以及 WireGuard 加密。与 Istio 一样，Cilium 是一个 CNCF 毕业项目，并且在社区中存在多年。
尽管表面上提供了类似的功能集，但这两个项目具有截然不同的架构，最值得注意的是 Cilium 使用 eBPF 和 WireGuard 在内核中处理和加密 L4 流量，而 Istio 使用 ztunnel 组件在用户空间中处理 L4 流量。这些差异导致人们对 Istio 与 Cilium 相比在大规模环境下的性能表现产生大量猜测。
虽然已经对这两个项目的租户模型、安全协议和基本性能进行了许多比较，但尚未发布企业级规模的全面评估。我们没有强调理论性能，而是对 Istio 的 ambient 模式和 Cilium 进行了测试，重点关注延迟、吞吐量和资源消耗等关键指标。我们使用现实的负载场景施加压力，模拟一个繁忙的 Kubernetes 环境。最后，我们将 AKS 集群的大小扩展到 1000 个节点（11000 个内核），以了解这些项目在大规模环境下的性能表现。我们的结果显示了每个项目可以改进的领域，但也表明 Istio 是明显的赢家。
测试场景
为了将 Istio 和 Cilium 推至极限，我们创建了 500 个不同的服务，每个服务都由 100 个 Pod 支持。每个服务都在一个单独的命名空间中，该命名空间还包含一个 Fortio 负载生成器客户端。我们将客户端限制在 100 台 32 核机器的节点池中，以消除来自共置客户端的噪音，并将剩余的 900 台 8 核实例分配给我们的服务。
对于 Istio 测试，我们使用了 Istio 的 ambient 模式，在每个服务命名空间中都使用 中继代理，并使用默认的安装参数。为了使我们的测试场景相似，我们必须在 Cilium 中启用一些非默认功能，包括 WireGuard 加密、L7 代理和节点初始化。我们还在每个命名空间中创建了一个 Cilium 网络策略，其中包含基于 HTTP 路径的规则。在这两种情况下，我们通过每秒随机将一个服务扩展到 85 到 115 个实例之间并每分钟重新标记一个命名空间来生成变化。要查看我们使用的精确设置并重现我们的结果，请参阅 我的笔记。
可扩展性记分卡
考虑到使用的资源，Istio 处理了 2178 个查询/核心，而 Cilium 处理了 1815 个，提高了 20%。
- Cilium 速度下降：Cilium 在使用默认安装参数时拥有令人印象深刻的低延迟，但在启用 Istio 的基本功能（如 L7 策略和加密）时，速度会大幅下降。此外，即使网格中没有流量流动，Cilium 的内存和 CPU 利用率仍然很高。这可能会影响集群的整体稳定性和可靠性，尤其是在集群规模不断增大的情况下。
- Istio，稳定的执行者：另一方面，Istio 的 ambient 模式展示了其在稳定性和维持良好吞吐量方面的优势，即使增加了加密的开销。虽然 Istio 在测试期间确实消耗了比 Cilium 更多的内存和 CPU，但在空闲时，其 CPU 利用率下降到 Cilium 的一小部分。
幕后：为什么会有差异？
理解这些性能差异的关键在于每个工具的架构和设计。
- Cilium 的控制平面难题：Cilium 在每个节点上运行一个控制平面实例，导致随着集群扩展，API 服务器压力和配置开销增加。这经常导致我们的 API 服务器崩溃，然后 Cilium 变得不可用，整个集群也变得无响应。
- Istio 的效率优势：Istio 采用集中式控制平面和基于身份的方法，简化了配置并减少了 API 服务器和节点的负担，将关键资源引导到处理和保护您的流量，而不是处理配置。Istio 通过运行与工作负载需求数量相同的 Envoy 实例，进一步利用控制平面中未使用的资源，而 Cilium 则限于每个节点一个共享的 Envoy 实例。
更深入地挖掘
虽然本项目的目的是比较 Istio 和 Cilium 的可扩展性，但一些限制使直接比较变得困难。
第 4 层并不总是第 4 层
虽然 Istio 和 Cilium 都提供 L4 策略实施，但它们的 API 和实现却大不相同。Cilium 实现 Kubernetes 网络策略，该策略使用标签和命名空间来阻止或允许访问和来自 IP 地址的流量。Istio 提供 AuthorizationPolicy API，并根据用于签署每个请求的 TLS 身份做出允许和拒绝决策。大多数纵深防御策略将需要同时使用网络策略和基于 TLS 的策略来实现全面的安全性。
并非所有加密都是平等创建的
虽然 Cilium 为 FIPS 兼容加密提供 IPsec，但 Cilium 的大多数其他功能（如 L7 策略和负载均衡）与 IPsec 不兼容。当使用 WireGuard 加密时，Cilium 具有更好的功能兼容性，但 WireGuard 不能在符合 FIPS 的环境中使用。另一方面，Istio 由于严格遵守 TLS 协议标准，因此默认情况下始终使用符合 FIPS 的 mTLS。
隐藏成本
虽然 Istio 完全在用户空间中运行，但 Cilium 的 L4 数据平面使用 eBPF 在 Linux 内核中运行。资源消耗的 Prometheus 指标仅测量用户空间资源，这意味着本测试中没有考虑 Cilium 使用的所有内核资源。
建议：选择合适的工具
那么，结论是什么？好吧，这取决于您的具体需求和优先事项。对于具有纯 L3/L4 使用案例且不需要加密的小型集群，Cilium 提供了一种经济高效且高性能的解决方案。但是，对于大型集群以及关注稳定性、可扩展性和高级功能的场景，Istio 的 ambient 模式以及替代的网络策略实现是最佳选择。许多客户选择将 Cilium 的 L3/L4 功能与 Istio 的 L4/L7 和加密功能相结合，以实现纵深防御策略。
请记住，云原生网络的世界正在不断发展。密切关注 Istio 和 Cilium 的发展，因为它们将继续改进并解决这些挑战。
让我们继续对话
您是否使用过 Istio 的 ambient 模式或 Cilium？您的经验和见解是什么？在下面的评论中分享您的想法。让我们互相学习，共同探索 Kubernetes 的精彩世界！
