.. _intro_cilium: =============== cilium技术简介 =============== .. figure:: ../../../_static/kubernetes/network/cilium/cilium.png Cilium =========== Cilium是提供透明、安全网络链接和应用层(容器或进程)负载均衡的开源软件。Cilium工作在3/4层，提供了传统网络和诸如7层安全服务，以及对现代应用协议如HTTP, gRPC 和 :ref:`kafka` 提供安全防护。Cilium被集成到现代调度框架，如Kubernetes中。 Cilium的底层基础是现代化Linux内核提供的 :ref:`ebpf` ，支持动态插入eBPF字节码到Linux内核来实现集成: 网络IO, 应用sockets, 跟踪安全实现, 网络以及可视化逻辑。由于 :ref:`ebpf` 运行在Linux内核，所以Cilium安全策略可以应用和更新而无需修改应用代码或者容器配置。 .. figure:: ../../../_static/kubernetes/network/cilium/cilium_func.png :scale: 70 .. note:: cilium 英文含义是 ``纤毛`` : 细胞表面上伸出的微小毛状突起，其有节律的运动可产生其周围的液体移动，或帮助单细胞生物的移动 ( `剑桥词典cilium `_ ) 可以看出cilium开源项目就和细胞上的 ``纤毛`` 一样，细微而重要的循环基础。 Hubble ======== .. note:: Hubble 也就是著名的 ``哈勃空间望远镜`` ( NASA `Hubble Space Telescope `_ ) .. figure:: ../../../_static/kubernetes/network/cilium/hubble_telescope.png :scale: 70 NASA `Hubble Space Telescope `_ 将为你打开新的世界: .. figure:: ../../../_static/kubernetes/network/cilium/hubble_m51.jpg :scale: 70 Hubble是一个分布式网络和安全可观测系统，基于Cilium和eBPF，能够以完全透明的方式深入了解服务的通信和行为以及网络基础设施。 你可以看到 ``Hubble`` 开源项目的Logo就是 ``哈勃空间望远镜`` ，象征着对网络系统的观测: .. figure:: ../../../_static/kubernetes/network/cilium/hubble.png 通过 :ref:`ebpf` 所有可见行都是可编程的，通过动态方法最大程度减少开销，同时根据用户要求提供深入和详细的可见性: - 服务依赖和通讯地图 - 服务之间如何通讯、频率以及服务之间的依赖关系图 - HTTP通讯、 :ref:`kafka` 的主题消费以及来去关系 - 网络监控和告警 - 提供网络层4到层7的通讯分析 - 当出现网络异常时提供告警，例如达到5分钟的DNS解析问题，TCP连接中断，TCP SYN请求无应答等异常情况 - 应用监控 - HTTP服务的响应码分析(比例) - 对HTTP请求的95或99延迟分析，服务之间的响应分析 - 安全可观测性 - 网络策略导致的阻塞 - 那些服务访问了外部网络 - 服务是否解析了特定DNS名字 Cilium + Hubble 的优势 ======================== 现代数据中心应用服务器架构已经转向面向服务的架构，也就是微服务: - 大型程序被拆分成小型独立服务 - 服务之间通过API交互(使用HTTP等轻量级协议) - 高度动态化: 随着负载变化扩展或收缩应用程序，以及 :ref:`kubernetes_ci_cd` 实现部署等滚动更新 由于微服务的高度动态化，IP地址在动态微服务环境会频繁变化，所以很难使用传统的Linux网络安全方法(如 :ref:`iptables` )过滤IP地址和TCP/UDP端口。传统的网络安全需要在负载均衡表和访问控制表存储不断增长且频繁更新的数十万条规则，并且在微服务中为了安全，协议端口不再用于区分应用程序流量(端口被用于跨服务的各种消息)。在新的微服务架构中，IP变动是如此频繁，甚至生命周期只有几秒钟。再加上以往观测服务通常以IP地址作为识别标记，但是现在IP地址时刻变化且变化速度极快，已经不再能够通过IP来做安全标识了。 Cilium通过Linux :ref:`ebpf` 获得了透明插入安全可见性和强制执行能力。基于 服务pod容器身份 来标识代替了传统的IP地址识别方法，并且可过滤应用服务层(如HTTP)以及传统的第3层和第4层进行应用安全策略部署。这些都是通过 :ref:`ebpf` 实现，并且能够高度扩展，满足大规模环境。 功能概述 =========== 透明保护API ------------- Cilium能够保护现代应用程序协议: - REST/HTTP - gRPC - Kafka Cilium提供了过滤单个应用程序协议请求的能力: - HTTP请求可以在7层上进行过滤，类似反向代理的防火墙7层内容过滤 - 能够解析HTTP头部以及所支持协议的分析 基于身份标识(identities)的服务到服务通讯的安全加固 --------------------------------------------------- 由于现代化分布式应用需要采用应用容器等技术实现部署敏捷性和按需扩展。所以会在短时间内启动大量应用程序容器。传统的iptables防火墙通过过滤IP地址和目标端口，而容器会在集群的任何地方任何时候启动，这会导致难以维护动态容器的防火墙。 为避免上述规模限制，Cilium为共享相同安全策略的应用程序容器组分配一个安全身份，然后这个身份与应用程序容器发出的所有网络数据包相关联，从而允许在接收节点验证身份。 安全访问外部服务 ---------------- - 基于标签的安全性，作为集群内部访问控制首选方式 - 支持传统基于CIDR的入口和出口安全策略 简化网络 -------- cilium实现了一个能够跨越多个集群的简单平面的第3层网络连接所有应用程序容器: - 通过使用主机范围分配器，使得IP分配保持简化 - 每个主机都可以分配IP而无需主机之间任何协调 所采用以下的多节点网络模型: - Overlay模式: 基于虚拟网络封装的虚拟网络，目前内置了 :ref:`vxlan` 和 Geneve，但是Linux支持的所有封装格式都可以启用。Overlay模式对基础架构和集成的要求最低，几乎适合任何网络基础设施，因为唯一的要求是已经完成了主机间的IP连接。 - 原生路由模式: 使用Linux主机的常规路由表，网络需要能够路由应用程序容器的IP地址。这种模式需要对底层网络 基础设置有所了解。原生路由模式适用于: - 原生IPv6网络 - 结合云网络路由器使用 - 如果已经运行了路由守护服务 - 负载均衡模式: Cilium实现了应用程序容器和外部服务之间的分布式负载均衡，并且能够完全替换 ``kube-proxy`` 等组件。负载均衡是在 :ref:`ebpf` 中使用高效的哈希表实现的，允许几乎无限的规模。 - 对于南北向类型的负载均衡，Cilium的eBPF实现针对最大性能的优化，可以附加到XDP(eXpress数据路径)，并且支持直接服务器返回(DSR)以及在不执行负载均衡操作的情况下支持Maglev一致性哈希到源主机上。 - 对于东西向类型的负载均衡，Cilium在Linux内核的套接字层(例如在TCP连接时)执行高效的服务到后端转换，这样可以避免较低层中每个数据包NAT操作开销。 .. note:: `南北流量和东西流量——它们是什么意思? `_ : - 南北流量是指客户端到服务器端的网络流量，经过了多层:负载均衡、应用服务器、数据库等 - 东西流量是指服务器到服务器的网络流量，也就是服务器之间互相调用 - 之所以命名为南北流量和东西流量，是因为典型的网络拓扑图(network diagrams)的习惯: 通常核心网络设备绘制在顶部(north)，而客户端绘制在底部(south)，而数据中心的不同服务器水平绘制(east-west) - 带宽管理: Cilium通过高效的基于EDT(最早出发时间)的速率限制和eBPF来实现带宽管理，用于出口节点的容量流量。 - 监控和故障排除: 实现可见性和解决问题的能力，通过使用元数据进行事件监控: - 当数据包被丢弃时，报告发送方和接收方完整标签信息以及其他信息 - 通过Prometheus导出指标 - Hibble: 可观测平台，提供基于流日志的服务依赖关系图、操作监控和告警以及应用程序和安全可见性 参考 ===== - `GitHub cilium `_ - `Introduction to Cilium & Hubble `_