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管理这些组件的好处。
Cilium可以作为Ingress Controller，如果进行了相应配置，就可以管理Ingress(Cilium文档提供了根据需求启用不同参数的详细信息)。
将Cilium部署为Ingress Controller，可以像其他Ingress Controller一样定义Ingress。只需在规范中指定ingressClassName: cilium即可依赖Cilium。
除了简单的Ingress之外，Cilium还支持相对较新的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 多平台发布
399
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
