Cilium CNI 深度指南

Cilium 是基于 eBPF 的功能强大的 CNI 插件，为云原生环境提供了强大的网络和安全支持。原文: Cilium CNI: A Comprehensive Deep Dive Guide for Networking and Security Enthusiasts!

🌓简介

欢迎阅读为网络和安全爱好者提供的全面深入的指南！

本文将以一种初学者也能理解的方式解析Cilium的概念和复杂性，如果你对如何通过 Cilium 网络性能和安全性感到好奇，那就来对地方了！

Cilium 是一个功能强大的容器网络接口(CNI)插件，已经成为领先的解决方案，彻底改变了云原生环境中的网络和安全。

但是 Cilium 到底是什么，是如何工作的呢？不要害怕，我们会用简单易懂的语言一步一步引导你走完这段旅程。无论你是开发人员、系统管理员，还是仅仅是对尖端网络和安全技术着迷的人，本指南都将为你打下探索 Cilium 功能的坚实基础。

🔭目标

本文将介绍 Cilium 基础知识，包括核心功能、如何与 Kubernetes 等容器编排系统集成，以及如何利用 eBPF 技术来增强网络可见性和安全性。最后你将清楚了解 Cilium 如何帮助我们为应用构建健壮、可扩展、安全的网络解决方案。

准备好进入 Cilium 的世界了吗？让我们一起踏上这段激动人心的旅程吧！

TLDR;

服务网格(Service Mesh): 🐝

Cilium 支持 Service Mesh 相关的各种用例。本节将探讨 Cilium 需要什么，如何配置，以及通过 eBPF 管理这些组件的好处。

Ingress:

Cilium 可以作为Ingress Controller，如果进行了相应配置，就可以管理 Ingress(Cilium 文档提供了根据需求启用不同参数的详细信息)。

将 Cilium 部署为 Ingress Controller，可以像其他 Ingress Controller 一样定义 Ingress。只需在规范中指定ingressClassName: cilium即可依赖 Cilium。

除了简单的 Ingress 之外，Cilium 还支持相对较新的Gateway API。🎉[最佳功能😃]

Gateway API: 🚪

Kubernetes Gateway API是针对不同 Kubernetes 资源的规范，通过提供接口来扩展集群功能，该接口可以由各种 k8s 服务提供者(如 Cilium)以不同方式实现。

这是一个可以遵循的标准，可以为 Kubernetes 集群提供更容易的外部服务互操作性。

一旦服务在集群和 Cilium 的 Helm Chart 中启用(- set gatewayAPI.enabled=true)，就可以创建符合 Gateway API 规范的资源(Gateway, HTTPRoute 等):

Cilium 现在可以提供了完全一致的 Gateway API 实现，这是 Kubernetes 集群中 North-South Load-Balancing(南北负载均衡) 和流量路由的新标准。在保持和扩展 Ingress 支持的同时，Gateway API 代表了流量管理的未来。

Gateway API 的发展是由 Ingress API 的局限性所驱动的。Ingress 缺乏高级负载平衡功能，只支持基本的基于内容的 HTTP 流量请求路由。此外，管理 Ingress 越来越具有挑战性，供应商依赖注解来处理功能差异，从而导致不一致。

为了克服这些限制，Gateway API 从头开始设计，解决了核心路由需求，并结合多年来从 Ingress 中学到的经验。该 API 遵循面向角色的方法，允许网络架构师为多个团队构建共享的网络基础设施，而不会出现协调问题。🕸

✅在 Cilium 1.13 中，Gateway API 通过了所有一致性测试，并支持各种用例，例如:

• HTTP Routing(HTTP 路由)

• TLS Termination(TLS 终结)

• HTTP Traffic Splitting / Weighting(HTTP 流量拆分/加权)

• HTTP Header Modification(HTTP 报头修改)

L7 负载均衡和流量管理与 Cilium:🚥

Cilium 由Envoy技术驱动，在服务网格架构中提供先进的L7流量管理功能。

它允许开发人员和运维人员在命名空间或全局级别定义 Envoy 配置，从而启用负载均衡、流量分割、镜像、修改和加密等特性。通过启用正确配置，Cilium 使用户能够优化性能、增强安全性，并获得有关 L7 流量的宝贵见解。

在 Cilium 1.13 中，引入了使用 Cilium 的嵌入式 Envoy 代理实现 Kubernetes 服务的 L7 负载均衡的新功能。通过在 Kubernetes 服务上应用一个简单的注解service.cilium.io/lb-l7: enabled，可以在集群内无缝启用 L7 负载均衡，支持基于 Cilium ClusterMesh 的多集群场景。

该功能解决了gRPC负载均衡的运维复杂性，并消除了对额外工具或服务网格的需求。

此外，Cilium 为 Ingress API 资源提供了改进功能。在 1.13 版本中，Cilium Ingress 支持共享 LoadBalancer 模式，即多个 Ingress 资源共享相同的 LoadBalancer 资源和 IP 地址。这大大降低了与云负载均衡器和公共 IP 相关的成本，从而为云工程师提供了更好的成本效益。

这些特性突出了 Cilium 在管理 L7 流量、与 Envoy 集成以及为 Kubernetes 服务提供高效负载均衡解决方案方面的强大功能。

在 L7 Ingress/Egress 流量控制和 SNI 支持下保护流量:

确保通信安全性是任何软件架构的基本面。Cilium 作为容器网络接口(CNI)，在保持简单而富有表现力的配置体验的同时，充分认识到了安全的重要性。

为了加强安全性，Cilium 基于网络策略(例如CiliumNetworkPolicy)，限制来自预批准的源的传入流量。通过应用策略，从标记为org=myorg的端点发出的流量可以限制为特定的完全限定域名(FQDN)，如secure.my-corp.com，确保没有其他流量离开这些端点并与外部 FQDN 通信。

要注意，将网络流量策略应用于出口并将端点策略从Default Allow(默认允许)模式转换为Default Deny(默认拒绝)模式，从而提供受控环境。

在网络策略上下文中，需要考虑kube-system/kubedns和端口 53，从而确保端点内的 pod 有效利用 DNS 解析。由于应用上述策略将端点转换为Default Deny模式，因此必须显式允许端点发送 DNS 查询。

此外，Cilium 1.13 在网络策略中引入了对 SNI (Server Name Indication) 的支持，进一步增强了网络安全性。SNI 是传输层安全(TLS) 协议的扩展，允许单个 IP 地址服务多个域名。

有了这个新功能，运营商可以限制其网络中允许的 TLS SNI 值，从而打造更安全的环境。在实现方面，SNI 支持是通过 Envoy 重定向实现的，根据客户端消息中存在的 SNI 值将连接重定向到不同的端点。

为了利用 Cilium 中的 SNI 支持，在 Cilium 网络策略中添加了一个名为ServerNames的新字段，该字段允许运营商指定允许的 TLS SNI 值列表。如果ServerNames字段不为空，则必须存在 TLS，并且必须在 TLS 握手期间指定 SNI。

使用以下策略，可以允许流量访问amit.cilium.rocks SNI:

使用 Cilium 检查 TLS 加密连接:

TLS 加密的广泛使用，特别是 HTTPS 这样的协议，已经成为日常交互中数据安全的基石，这些协议确保对承载的有价值数据提供安全保障。

因为加密使连接不透明，有人可能会认为这对网络流量的管理和可观察性提出了挑战。然而由于TLS inspection机制，情况并非如此，这种机制类似于由 Cilium 精心策划的中间人攻击。

与典型 egress 流程不同，Cilium 能够执行以下操作:

1. 拦截来自 Cilium 端点的新创建请求，该请求由使用 Cilium 认可的内部证书颁发机构生成。

2. 终结 TLS，从而获得对请求内容的访问权。

3. 执行网络策略和其他相关操作。

4. 使用公共证书颁发机构(或至少为组织集群内的出站流量批准的证书颁发机构)重新创建新的 TLS 请求。

5. 向原始目标发出新创建的 HTTPS 请求，然后执行其标准终结过程。

通过这个过程，Cilium 可以在不影响安全性的情况下检查 TLS 连接。它利用拦截和重新创建请求的能力，从而在加密流量中有效实施网络策略和可观察性。

通过使用 TLS 连接检测，Cilium 在安全加密和必要的网络流量管理和监控之间取得了平衡，确保了数据安全和运维可见性。

Cilium 服务网格中的双向认证: mTLS 支持介绍

双向认证受到服务网格用户的高度重视，被认为是至关重要的特性，这一功能在 Cilium Service Mesh 中的实现始终备受期待。在 Cilium 1.13 中，在数据路径级别引入了对 mTLS(双向传输层安全)的支持，使得 Cilium 能够对集群内对等节点上的端点进行身份验证，并基于成功的双向身份验证来控制数据平面的连通性。

虽然此实现可能不会立即面向用户发布，但为将来的开发奠定了基础，使 mTLS 为用户做好了准备。

现有双向身份验证实现通常会对用户施加各种限制，以增强安全性。这些限制包括使用 TCP+TLS 进行身份验证和加密，或者要求在数据平面中使用(sidecar)代理。然而，这样的限制增加了复杂性和处理成本。我们相信，通过结合基于会话的身份验证和基于网络的身份验证的优势，可以提供比以前的方法更快、更灵活的安全实现。

我们的长期目标包括为 pod 提供一种机制来选择对等身份验证，支持可插拔的证书管理系统(如 SPIFFE、Vault、SMI、Istio、cert-manager 等)，提供可配置的证书粒度，以及利用现有的对数据平面的加密协议支持。

Cilium 和 Grafana 合作: 增强网络可观测性

在 Grafana 和 Isovalent 的合作中，Cilium 与 Grafana 相互集成，能够全面监控 Kubernetes 中云原生应用之间的网络连接。该集成利用 Prometheus 指标、Grafana 仪表板和警报，以及 Grafana Tempo 跟踪来观察网络的健康状况和性能。

随着 Cilium 1.13 的发布，双方的合作关系取得了重大进展。一个显著的改进是通过合并跟踪对分布式系统进行故障排除的能力。以前，应用开发人员可以将跟踪发送到首选跟踪后端，例如Grafana Tempo。然而，网络指标并不包括在内。现在，有了 Cilium 1.13，这个鸿沟就被弥合了。

在 Cilium 1.13 中，Hubble 的 L7 HTTP 可见性功能从 L7 HTTP 请求中提取 OpenTelemetry traceParent 报头，并链接到 Hubble flow。这种集成允许用户在 Hubble 的 L7 HTTP 指标中查看其应用程序的 traceID，提供从指标到跟踪的无缝过渡。

此外，Cilium 1.13 引入了 Hubble 数据源插件，扩展了 Grafana 生态系统。该插件可以详细了解网络流量，允许与应用级遥测相关联。集成了存储 Hubble 指标的 Prometheus，存储分布式跟踪的 Tempo，以及 Hubble Timescape，等价于 Cilium 企业级可观测平台。

有了这些进步，用户可以利用 Grafana 获得数据源的全面视图，实现增强的网络可观察性以及网络流量和应用遥测之间的相关性。

在 Cilium 中使用 BIG TCP 增强性能:

Cilium 是云服务商、金融机构和电信服务商青睐的选择，由于能够最大限度提高网络性能，正在被广泛采用。这些组织都有一个共同目标，即寻求网络性能的增量收益，特别是当他们构建能够处理 100Gbps 及更高速度的网络时。

然而，采用高速 100Gbps 网络适配器带来了一个挑战: CPU 如何有效处理大量数据包？假设 MTU 为 1538 字节，每秒可以达到 800 万个数据包。系统处理每个数据包的可用时间只有 120 纳秒，很明显，现有方法是不现实的。此外，为了处理如此巨大的数据包负载，管理接口对上层协议层需要大量开销。

BIG TCP 是一个突破性解决方案。如果数据包有效负载可以组合成超大大小的数据包会怎么样？通过增加数据包大小，可以减少开销，从而潜在提高吞吐量并减少延迟。

在最新发布的 Cilium 1.13 版本中，现在可以在集群中使用 BIG TCP 令人兴奋的新特性，提供增强的性能优势。

🔚结论:

Cilium CNI 是 Kubernetes 强大的网络和安全解决方案。它基于 eBPF 的数据平面提供了高性能和灵活性。通过加密、负载均衡和分布式防火墙等特性，支持安全的微服务架构。

Cilium 的可观察性和安全能力提供了对网络流量和攻击防护的深刻见解，与 Kubernetes RBAC 的集成支持细粒度安全策略。

对于网络和安全爱好者来说，探索 Cilium 为 Kubernetes 的部署打开了令人兴奋的可能性。让我们深入了解 Cilium，利用 Cilium CNI 提升网络的性能和安全性！

你好，我是俞凡，在 Motorola 做过研发，现在在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。为了方便大家以后能第一时间看到文章，请朋友们关注公众号"DeepNoMind"，并设个星标吧，如果能一键三连(转发、点赞、在看)，则能给我带来更多的支持和动力，激励我持续写下去，和大家共同成长进步！