deploy: cloudnativeto/cloudnative.to@e1a0052

Author: rootsongjc

404.html

@@ -756,6 +756,8 @@ <h1>找不到页面</h1>
   <h2>最新</h2>
   <ul>
 
+      <li><a href="/blog/ambient-vs-cilium/">云原生对比：Istio Ambient 模式与 Cilium 的扩展性能分析</a></li>
+    
       <li><a href="/blog/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect/">AWS 宣布将停用 App Mesh，鼓励用户迁移至 Amazon ECS Service Connect</a></li>
 
       <li><a href="/blog/istio-aws-private-ca/">如何将 Istio 与 AWS 私有证书颁发机构（Private CA）无缝集成</a></li>
@@ -774,8 +776,6 @@ <h2>最新</h2>
 
       <li><a href="/blog/sapwned-sap-ai-vulnerabilities-ai-security/">SAPwned：SAP AI 漏洞暴露客户云环境和私有 AI 工件</a></li>
 
-      <li><a href="/blog/istio-keycloak-authentication-authorization/">使用 Istio 和 Keycloak 实现身份验证和授权</a></li>
-    
   </ul>
 
 

author/istio/index.html

@@ -861,6 +861,10 @@ <h3>
       <h3>最新</h3>
       <ul>
 
+        <li>
+          <a href="/blog/ambient-vs-cilium/">云原生对比：Istio Ambient 模式与 Cilium 的扩展性能分析</a>
+        </li>
+        
         <li>
           <a href="/blog/istio-1-23-release/">Istio 1.23 发布：环境模式升级与重要功能更新</a>
         </li>

author/istio/index.xml

@@ -12,6 +12,104 @@
       <link>https://cloudnative.to/author/istio/</link>
     </image>
 
+    <item>
+      <title>云原生对比：Istio Ambient 模式与 Cilium 的扩展性能分析</title>
+      <link>https://cloudnative.to/blog/ambient-vs-cilium/</link>
+      <pubDate>Tue, 22 Oct 2024 10:49:22 +0800</pubDate>
+      <guid>https://cloudnative.to/blog/ambient-vs-cilium/</guid>
+      <description>&lt;p&gt;潜在的 Istio 用户经常会问：“Istio 与 Cilium 相比如何？”虽然 Cilium 最初仅提供 L3/L4 功能（如网络策略），但近来的版本增加了基于 Envoy 的服务网格功能以及 WireGuard 加密。与 Istio 一样，Cilium 也是 CNCF 认证的毕业项目，并在社区中存在多年。&lt;/p&gt;
+&lt;p&gt;尽管表面上看这两个项目提供的功能相似，但它们的架构却有着显著不同，尤其是 Cilium 使用 eBPF 和 WireGuard 在内核中处理和加密 L4 流量，而 Istio 在用户空间通过其 ztunnel 组件处理 L4 流量。这些差异导致了关于 Istio 与 Cilium 在大规模下性能的广泛讨论。&lt;/p&gt;
+&lt;p&gt;尽管已有关于租户模型、安全协议和基本性能的比较，但尚未有全面的企业级评估报告。与其强调理论性能，我们对 Istio 的 Ambient 模式和 Cilium 进行了测试，聚焦于延迟、吞吐量和资源消耗等关键指标。通过模拟一个繁忙的 Kubernetes 环境，我们施加了高负载场景，最后将 AKS 集群的规模扩展到 1000 个节点、11000 个核心，以了解这些项目在大规模下的表现。结果显示，两者各有需要改进的地方，但 Istio 明显表现更佳。&lt;/p&gt;
+&lt;h2 id=&#34;测试场景&#34;&gt;测试场景&lt;/h2&gt;
+&lt;p&gt;为了将 Istio 和 Cilium 推向极限，我们创建了 500 个不同的服务，每个服务支持 100 个 Pod。每个服务位于单独的命名空间中，且包含一个&lt;a href=&#34;https://fortio.org/&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;Fortio&lt;/a&gt;负载生成客户端。我们将客户端限制在一个由 100 台 32 核机器组成的节点池中，以消除共同定位的客户端的干扰，并为服务分配了剩余的 900 台 8 核实例。&lt;/p&gt;
+&lt;p&gt;
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+&lt;figure  id=&#34;figure-测试场景&#34;&gt;
+  &lt;div class=&#34;d-flex justify-content-center&#34;&gt;
+    &lt;div class=&#34;w-100&#34; &gt;&lt;img alt=&#34;测试场景&#34; srcset=&#34;
+               /blog/ambient-vs-cilium/scale-scenario_huec253fa9f5f30c0ca9e840581fd1c007_49811_3c38f7b358801a02ead6c8af748bb0d4.webp 400w,
+               /blog/ambient-vs-cilium/scale-scenario_huec253fa9f5f30c0ca9e840581fd1c007_49811_c0e5c10a290de018ae31c432499f385b.webp 760w,
+               /blog/ambient-vs-cilium/scale-scenario_huec253fa9f5f30c0ca9e840581fd1c007_49811_1200x1200_fit_q75_h2_lanczos_3.webp 1200w&#34;
+               src=&#34;https://cloudnative.to/blog/ambient-vs-cilium/scale-scenario_huec253fa9f5f30c0ca9e840581fd1c007_49811_3c38f7b358801a02ead6c8af748bb0d4.webp&#34;
+               width=&#34;760&#34;
+               height=&#34;598&#34;
+               loading=&#34;lazy&#34; data-zoomable /&gt;&lt;/div&gt;
+  &lt;/div&gt;&lt;figcaption&gt;
+      测试场景
+    &lt;/figcaption&gt;&lt;/figure&gt;
+&lt;/p&gt;
+&lt;p&gt;在 Istio 测试中，我们使用了 Ambient 模式，在每个服务命名空间中部署了&lt;a href=&#34;https://istio.io/latest/docs/ambient/usage/waypoint/&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;waypoint 代理&lt;/a&gt;，并使用默认的安装参数。为了使测试场景尽可能相似，我们在 Cilium 中启用了几个非默认功能，包括 WireGuard 加密、L7 代理和节点初始化。我们还在每个命名空间中创建了一个 Cilium 网络策略，带有基于 HTTP 路径的规则。在两种场景下，我们通过随机地将一个服务扩展到 85 至 115 个实例并每分钟重新标记一个命名空间，生成了变化。要查看我们使用的精确设置并重现结果，请参阅&lt;a href=&#34;https://github.com/therealmitchconnors/tools/blob/2384dc26f114300687b21f921581a158f27dc9e1/perf/load/many-svc-scenario/README.md&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;我的笔记&lt;/a&gt;。&lt;/p&gt;
+&lt;h2 id=&#34;可扩展性评分&#34;&gt;可扩展性评分&lt;/h2&gt;
+&lt;p&gt;
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+&lt;figure  id=&#34;figure-可扩展性评分&#34;&gt;
+  &lt;div class=&#34;d-flex justify-content-center&#34;&gt;
+    &lt;div class=&#34;w-100&#34; &gt;&lt;img alt=&#34;可扩展性评分&#34; srcset=&#34;
+               /blog/ambient-vs-cilium/scale-scorecard_hu389d7aaf3d9429f79fac819b6f3351d4_76562_c13474ad5f94c5aa07e4ca5199eb3865.webp 400w,
+               /blog/ambient-vs-cilium/scale-scorecard_hu389d7aaf3d9429f79fac819b6f3351d4_76562_d85835363c13f30508d6d5cfa5432832.webp 760w,
+               /blog/ambient-vs-cilium/scale-scorecard_hu389d7aaf3d9429f79fac819b6f3351d4_76562_1200x1200_fit_q75_h2_lanczos_3.webp 1200w&#34;
+               src=&#34;https://cloudnative.to/blog/ambient-vs-cilium/scale-scorecard_hu389d7aaf3d9429f79fac819b6f3351d4_76562_c13474ad5f94c5aa07e4ca5199eb3865.webp&#34;
+               width=&#34;760&#34;
+               height=&#34;426&#34;
+               loading=&#34;lazy&#34; data-zoomable /&gt;&lt;/div&gt;
+  &lt;/div&gt;&lt;figcaption&gt;
+      可扩展性评分
+    &lt;/figcaption&gt;&lt;/figure&gt;
+&lt;/p&gt;
+&lt;p&gt;Istio 能够以 20% 的较低尾延迟提供 56% 更多的查询。Cilium 的 CPU 使用率低 30%，但我们的测量并不包括 Cilium 用于加密的内核核心。&lt;/p&gt;
+&lt;p&gt;考虑到资源使用情况，Istio 每核心处理 2178 个查询，而 Cilium 则是 1815 个，提升了 20%。&lt;/p&gt;
+&lt;ul&gt;
+&lt;li&gt;&lt;strong&gt;Cilium 减速：&lt;/strong&gt; Cilium 在默认安装参数下展示了令人印象深刻的低延迟，但当启用 Istio 的基准功能（如 L7 策略和加密）时，其速度大幅下降。此外，即使网格中没有流量流动，Cilium 的内存和 CPU 利用率仍然较高，这可能会影响集群的整体稳定性和可靠性，尤其是在扩展时。&lt;/li&gt;
+&lt;li&gt;&lt;strong&gt;Istio 稳健表现：&lt;/strong&gt; 相比之下，Istio 的 Ambient 模式在稳定性方面展示了其优势，即使增加了加密的开销，也能保持不错的吞吐量。在测试中，Istio 确实比 Cilium 消耗了更多的内存和 CPU，但在没有负载时其 CPU 利用率下降到 Cilium 的一小部分。&lt;/li&gt;
+&lt;/ul&gt;
+&lt;h2 id=&#34;幕后原因为何表现差异&#34;&gt;幕后原因：为何表现差异？&lt;/h2&gt;
+&lt;p&gt;要理解这些性能差异的关键在于各工具的架构和设计。&lt;/p&gt;
+&lt;ul&gt;
+&lt;li&gt;&lt;strong&gt;Cilium 的控制平面难题：&lt;/strong&gt; Cilium 在每个节点上运行一个控制平面实例，随着集群扩展，这导致 API 服务器压力增加和配置开销增加。这经常导致我们的 API 服务器崩溃，接着 Cilium 变得不可用，整个集群陷入不响应状态。&lt;/li&gt;
+&lt;li&gt;&lt;strong&gt;Istio 的效率优势：&lt;/strong&gt; Istio 通过集中控制平面和基于身份的方式简化了配置，减少了 API 服务器和节点的负担，将关键资源用于处理和保护流量，而不是处理配置。Istio 通过运行尽可能多的 Envoy 实例来进一步利用未在控制平面中使用的资源，而 Cilium 则限制为每个节点共享一个 Envoy 实例。&lt;/li&gt;
+&lt;/ul&gt;
+&lt;h3 id=&#34;更深入探讨&#34;&gt;更深入探讨&lt;/h3&gt;
+&lt;p&gt;虽然这个项目的目标是比较 Istio 和 Cilium 的可扩展性，但一些限制使得直接比较变得困难。&lt;/p&gt;
+&lt;h3 id=&#34;l4-不总是-l4&#34;&gt;L4 不总是 L4&lt;/h3&gt;
+&lt;p&gt;尽管 Istio 和 Cilium 都提供 L4 策略强制，但它们的 API 和实现存在显著差异。Cilium 实现了 Kubernetes NetworkPolicy，它使用标签和命名空间来阻止或允许 IP 地址的访问。Istio 提供了一个 AuthorizationPolicy API，并根据签署每个请求的 TLS 身份做出允许和拒绝决定。大多数深度防御策略需要同时使用 NetworkPolicy 和基于 TLS 的策略来实现全面的安全性。&lt;/p&gt;
+&lt;h3 id=&#34;加密的差异&#34;&gt;加密的差异&lt;/h3&gt;
+&lt;p&gt;Cilium 提供了用于 FIPS 兼容加密的 IPsec，但大多数 Cilium 功能（如 L7 策略和负载均衡）与 IPsec 不兼容。Cilium 在使用 WireGuard 加密时具有更好的功能兼容性，但 WireGuard 无法在 FIPS 合规的环境中使用。另一方面，Istio 严格遵守 TLS 协议标准，默认情况下始终使用 FIPS 兼容的 mTLS。&lt;/p&gt;
+&lt;h3 id=&#34;隐藏的成本&#34;&gt;隐藏的成本&lt;/h3&gt;
+&lt;p&gt;虽然 Istio 完全在用户空间中运行，但 Cilium 的 L4 数据平面在 Linux 内核中使用 eBPF。Prometheus 的资源消耗指标仅测量用户空间资源，这意味着 Cilium 使用的所有内核资源在此测试中都未计入。&lt;/p&gt;
+&lt;h2 id=&#34;建议选择合适的工具&#34;&gt;建议：选择合适的工具&lt;/h2&gt;
+&lt;p&gt;那么，最终结论是什么？这取决于您的具体需求和优先事项。对于小型集群以及纯 L3/L4 用例且无需加密的情况，Cilium 提供了一个经济高效且性能良好的解决方案。然而，对于大型集群，以及注重稳定性、可扩展性和高级功能的情况，Istio 的 Ambient 模式配合替代的 NetworkPolicy 实现才是首选。许多客户选择将 Cilium 的 L3/L4 功能与 Istio 的 L4/L7 和加密功能结合，以实现深度防御策略。&lt;/p&gt;
+&lt;p&gt;请记住，云原生网络的世界在不断发展。密切关注 Istio 和 Cilium 的进展，它们将继续改进和应对这些挑战。&lt;/p&gt;
+</description>
+    </item>
+    
     <item>
       <title>Istio 1.23 发布：环境模式升级与重要功能更新</title>
       <link>https://cloudnative.to/blog/istio-1-23-release/</link>