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流量管理[1]功能。
它允许开发人员和运维人员在命名空间或全局级别定义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能够执行以下操作:
-
拦截来自Cilium端点的新创建请求,该请求由使用Cilium认可的内部证书颁发机构生成。 -
终结TLS,从而获得对请求内容的访问权。 -
执行网络策略和其他相关操作。 -
使用公共证书颁发机构(或至少为组织集群内的出站流量批准的证书颁发机构)重新创建新的TLS请求。 -
向原始目标发出新创建的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的合作[2]中,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",并设个星标吧,如果能一键三连(转发、点赞、在看),则能给我带来更多的支持和动力,激励我持续写下去,和大家共同成长进步!
Cilium L7 Traffic Management: https://docs.cilium.io/en/stable/network/servicemesh/l7-traffic-management
[2]Grafana Labs Partners with Isovalent to Bring Best-in-Class Grafana Observability to Cilium's Service Connectivity on Kubernetes: https://grafana.com/about/press/2022/10/24/grafana-labs-partners-with-isovalent-to-bring-best-in-class-grafana-observability-to-ciliums-service-connectivity-on-kubernetes/?pg=blog&plcmt=body-txt
本文由 mdnice 多平台发布