Cilium是什么？

Cilium是一款开源软件，用于透明地保护使用Docker和Kubernetes等Linux容器管理平台部署的应用程序服务之间的网络连接。

Cilium基于一种名为eBPF的新的Linux内核技术实现，它支持在Linux本身中动态插入强大的安全可见性和控制逻辑。因为eBPF在Linux内核内部运行，所以，可以无需更改应用程序代码或容器配置应用便可更新Cilium安全策略。

Hubble是什么？

Hubble是一个完全分布式的网络和安全可观测平台。它构建在Cilium和eBPF之上，以完全透明的方式支持对服务的通信和行为以及网络基础设施的深度可见性。

通过在Cilium的顶部建造，Hubble可以利用eBPF来提高能见度。通过依赖于eBPF，所有的可见性都是可编程的，并允许采用动态方法，在根据用户的要求提供深度和详细的可见性的同时最小化开销。 Hubble的诞生和设计就是为了充分利用eBPF的新能力。

Hubble具备以下能力：

服务依赖关系和通信映射

哪些服务在相互通信?通信频率?服务依赖关系图是什么样子的?
正在进行哪些HTTP调用?服务从哪些Kafka主题中消费或产生?

网络监控&告警

是否有网络通信故障?为什么通信失败了?DNS存在问题吗?是应用程序问题还是网络问题?通信中断是在第4层(TCP)还是第7层(HTTP)?
最近5分钟内，哪些服务出现DNS解析问题?哪些服务最近经历过TCP连接中断或连接超时?TCP SYN请求的未应答率是多少?

应用程序监控

对于特定服务或跨所有集群的5xx或4xx HTTP响应码的比率是多少?
集群内，HTTP请求和响应之间的第95和99个百分位延迟是多少?哪些服务表现最差?两个服务之间的延迟是多少?

安全可观测性

由于网络策略，哪些服务的连接被阻塞?从集群外部访问了哪些服务?哪些服务解析了特定的DNS名称?

为什么要选择Cilium与Hubble?

eBPF在粒度和效率上实现了对系统和应用程序的可观测性和控制，这在以前是不可能的。它以一种完全透明的方式做到这一点，不需要应用程序以任何方式进行更改。 eBPF同样能够很好地处理现代的容器化工作负载以及更传统的工作负载(如虚拟机和标准Linux进程)。

现代数据中心应用程序的开发已转向面向服务的体系结构，通常称为微服务，其中大型应用程序被分割为小型独立服务，这些服务通过使用HTTP等轻量级协议的api彼此通信。微服务应用程序往往是高度动态的，随着应用程序向外/向内扩展以适应负载变化，以及在作为持续交付的一部分部署的滚动更新期间，单个容器被启动或销毁。

这种向高度动态微服务的转变在确保微服务之间的连接方面既是挑战，也是机遇。传统的Linux网络安全方法(例如，iptables)过滤IP地址和TCP/UDP端口，但IP地址在动态微服务环境中经常变动。容器的高度不稳定的生命周期导致这些方法难以与应用程序同时扩展，因为负载平衡表和访问控制列表包含数十万条规则，需要以不断增长的频率更新。协议端口(例如用于HTTP流量的TCP端口80)不再用于出于安全目的区分应用程序流量，因为该端口用于跨服务的大量消息。

另一个挑战是提供精确可见性的能力，因为传统系统使用IP地址作为主要识别工具，这可能会大大缩短微服务体系结构中的生命周期，只有几秒钟。

通过利用Linux eBPF, Cilium保留了透明插入安全可见性和强制的能力，但这是以一种基于服务/pod/容器标识(与传统系统中的IP地址标识相反)的方式进行的，并且可以在应用层(例如HTTP)进行过滤。因此，Cilium不仅通过解耦安全性与寻址使得在高度动态的环境中应用安全策略变得简单，而且除了提供传统的第3层和第4层分割之外，还可以通过在http层操作提供更强的安全隔离。

eBPF的使用使Cilium能够以一种即使在大规模环境中也具有高度可伸缩性的方式实现所有这些。（对比iptables等）

功能概述

透明地保护API

能够保护现代应用协议，如REST/HTTP, gRPC和Kafka。传统的防火墙在第3层和第4层运行。在特定端口上运行的协议要么是完全信任的，要么是完全阻塞的。Cilium提供了过滤单个应用协议请求的能力，例如:

允许所有使用GET方法和/public/.*路径的HTTP请求，拒绝所有其他请求。
允许service1在Kafka主题topic1上生产，允许service2在topic1上消费，拒绝所有其他Kafka消息。
要求HTTP报头X-Token:[0-9]+出现在所有REST调用中。

基于身份的服务与服务之间的安全通信

现代分布式应用程序依赖于容器等技术来促进部署的敏捷性和按需向外扩展。这将导致在短时间内启动大量应用程序容器。典型的容器防火墙通过对源IP地址和目的端口进行过滤来保护工作负载。这个概念要求在集群中的任何位置启动容器时，都要操纵所有服务器上的防火墙。

为了避免这种限制规模的情况，Cilium将一个安全标识分配给共享相同安全策略的应用程序容器组。然后，该标识与应用程序容器发出的所有网络数据包相关联，允许在接收节点验证该标识。安全标识管理使用键值存储来执行。

对外部服务的安全访问

基于标签的安全性是集群内部访问控制的首选工具。为了保证对外部服务的安全访问，支持基于传统CIDR的入口和出口安全策略。这允许将对应用程序容器的访问限制在特定的IP范围内。

简单网络

具有跨多个集群能力的简单平面第三层网络连接了所有应用程序容器。通过使用主机作用域分配器，IP分配变得简单。这意味着每台主机无需协调就可以分配ip。

支持以下多节点组网模式:

1.Overlay: 基于封装的虚拟网络，跨越所有主机。

使用场景: 该模式对基础设施和集成的需求最小。它适用于几乎所有的网络基础设施，因为唯一的要求是主机之间的IP连接。

2.本地路由: Linux主机的常规路由表的使用。网络需要能够路由应用程序容器的IP地址。

使用场景: 此模式适用于高级用户，需要了解底层网络基础设施。此模式适用于:

IPv6
结合云网络路由器
如果您已经在运行路由守护进程

负载均衡

Cilium为应用程序容器之间和与外部服务之间的通信实现分布式负载平衡，并且能够完全替换kube-proxy等组件。负载平衡是在eBPF中使用高效的哈希表实现的，允许几乎无限的规模。

带宽管理

Cilium通过高效的EDT-based (最早出发时间)的速率限制实现带宽管理，并使用eBPF对出口节点的容器流量进行限速。相比于传统的方法，例如在带宽CNI插件中使用的HTB(层次令牌桶)或TBF(令牌桶过滤器)，Cilium显著降低应用程序的传输尾延迟，并避免在多队列网卡下的锁定。

监控和故障诊断

提供优于tcpdump和ping网络诊断方式:

基于元数据的事件监控：当数据包被丢弃时，该工具不仅报告数据包的源和目的IP，还提供发送方和接收方的完整标签信息和许多其他信息。
关键指标通过Prometheus导出，以便与现有的仪表板集成。
Hubble：专门为Cilium编写的可观察性平台。它基于流日志提供服务依赖关系映射、操作监视和警报，以及应用程序和安全可见性。

01介绍Cilium与Hubble