Cilium
Cilium
目录
简介
参考：
- 官网文档：https://docs.cilium.io/en/stable/overview/intro/
- 官网论坛：https://cilium.slack.com/
什么是 Cilium？
Cilium 是开源软件，用于透明地保护使用 Docker 和 Kubernetes 等 Linux 容器管理平台部署的应用程序服务之间的网络连接。
Cilium 的基础是一种名为 eBPF 的新 Linux 内核技术，它可以在 Linux 本身内动态插入强大的安全可见性和控制逻辑。由于 eBPF 在 Linux 内核内部运行，因此可以应用和更新 Cilium 安全策略，而无需对应用程序代码或容器配置进行任何更改。
如果您想观看 Cilium 的视频介绍，请观看 Cilium 联合创始人 Thomas Graf 的解释： explanation by Thomas Graf, Co-founder of 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 名称？
如果您想要了解哈勃的视频介绍，请观看 eCHO 第 2 集：哈勃简介：eCHO episode 2: Introduction to Hubble
为什么选择 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 能够以高度可扩展的方式实现所有这一切，即使对于大规模环境也是如此。
功能概述
透明地保护 API 的安全
能够保护 REST/HTTP、gRPC 和 Kafka 等现代应用程序协议。传统防火墙在第 3 层和第 4 层运行。在特定端口上运行的协议要么完全信任，要么完全阻止。 Cilium 提供了过滤单个应用程序协议请求的能力，例如：
- 允许所有具有方法
GET和路径/public/.*的 HTTP 请求。拒绝所有其他请求。 - 允许
service1在 Kafka 主题topic1上生成，并允许service2在topic1上消费。拒绝所有其他 Kafka 消息。 - 要求所有 REST 调用中都存在 HTTP 标头
X-Token: [0-9]+。
请参阅我们文档中的 Layer 7 Policy 策略部分，了解支持的协议的最新列表以及如何使用它的示例。
基于身份的安全服务间通信
现代分布式应用程序依赖应用程序容器等技术来促进部署的敏捷性和按需扩展。这导致短时间内会启动大量的应用容器。典型的容器防火墙通过过滤源 IP 地址和目标端口来保护工作负载。这个概念要求每当容器在集群中的任何位置启动时，都可以操纵所有服务器上的防火墙。
为了避免这种限制规模的情况，Cilium 为共享相同安全策略的应用程序容器组分配一个安全身份。然后，该身份与应用程序容器发出的所有网络数据包相关联，从而允许在接收节点验证身份。安全身份管理是使用键值存储来执行的。
安全地访问和访问外部服务
基于标签的安全性是集群内部访问控制的首选工具。为了保护对外部服务的访问和从外部服务的访问，支持基于传统 CIDR 的入口和出口安全策略。这允许将应用程序容器的访问限制到特定的 IP 范围。
简单的组网
一个简单的扁平第 3 层网络能够跨越多个集群，连接所有应用程序容器。通过使用主机范围分配器，IP 分配变得简单。这意味着每个主机都可以分配 IP，而无需主机之间进行任何协调。
支持以下多节点网络模型：
Overlay：跨越所有主机的基于封装的虚拟网络。目前已内置 VXLAN 和 Geneve，但可以启用 Linux 支持的所有封装格式。
何时使用此模式：此模式具有最低的基础架构和集成要求。它几乎适用于任何网络基础设施，因为唯一的要求是主机之间的 IP 连接，而这通常已经给出。
本机路由：使用 Linux 主机的常规路由表。网络需要能够路由应用程序容器的 IP 地址。
何时使用此模式：此模式适用于高级用户，需要对底层网络基础设施有一定的了解。此模式适用于：
- 与云网络路由器结合
- 如果您已经在运行路由守护程序
负载均衡
Cilium 为应用程序容器之间和外部服务之间的流量实现分布式负载均衡，并且能够完全替代 kube-proxy 等组件。负载平衡是在 eBPF 中使用高效的哈希表实现的，允许几乎无限的规模。
对于南北向类型的负载平衡，Cilium 的 eBPF 实现针对最大性能进行了优化，可以附加到 XDP（eXpress 数据路径），并且支持直接服务器返回（DSR）以及 Maglev 一致性哈希（如果不执行负载平衡操作）在源主机上。
对于东西向类型的负载平衡，Cilium 直接在 Linux 内核的套接字层（例如在 TCP 连接时）执行高效的服务到后端转换，以便在较低层中避免每个数据包的 NAT 操作开销。
带宽管理
Cilium 通过基于 EDT（最早出发时间）的高效速率限制以及 eBPF 对流出节点的容器流量实施带宽管理。与带宽 CNI 插件中使用的 HTB（层次结构令牌桶）或 TBF（令牌桶过滤器）等传统方法相比，这可以显着减少应用程序的传输尾延迟，并避免在多队列 NIC 下锁定。
监控和故障排除
获得可见性和解决问题的能力是任何分布式系统运行的基础。虽然我们学会了喜欢 tcpdump 和 ping 这样的工具，并且它们总是在我们心中占据特殊的位置，但我们努力提供更好的故障排除工具。这包括提供以下工具：
- 使用元数据进行事件监控：当数据包丢失时，该工具不仅报告数据包的源和目标 IP，还提供发送者和接收者的完整标签信息以及许多其他信息。
- 通过 Prometheus 导出指标：通过 Prometheus 导出关键指标，以便与现有仪表板集成。
- Hubble: 专门为 Cilium 编写的可观测平台。它提供服务依赖关系图、操作监控和警报以及基于流日志的应用程序和安全可见性。