Cilium 是一个开源的云原生解决方案，用于提供、保护(安全功能)和观察(监控功能)工作负载之间的网络连接，由革命性的内核技术 eBPF 提供动力。Cilium 主要使用场景是在 Kubernetes中，但 Cilium 的优势并不仅限于 Kubernetes 环境。
在 Kubernetes 环境中，Cilium 可充当网络插件，提供 pod 之间的连接。它通过执行网络策略(network policy)和透明加密来提供安全性，而 Cilium 的 Hubble 组件则提供了网络流量流的深度可见性(监控功能)。
得益于 eBPF，Cilium 的网络、安全和可观察性逻辑可以直接编程到内核中，从而使 Cilium 和 Hubble 的功能对应用工作负载完全透明。这些将是 Kubernetes 集群中的容器化工作负载，不过 Cilium 也能连接虚拟机和标准 Linux 进程等传统工作负载。
关于 Cilium 可观察性, 典型的案例是: pod 中的应用无需启用 Tracing 功能, 也无需通过 exporter 将 http requests metrics 发给 Prometheus, 仅通过 Cilium 的 Hubble 功能, 就能直接获取到该应用的 http requests 的 RED(Requests, Errors, Durations).
在高度动态和复杂的微服务世界中，主要从 IP 地址和端口的角度考虑网络问题可能会导致挫败感。使用传统的网络工具(通过五元组)实施可能会非常低效，只能提供粗粒度的可见性和过滤，从而限制了排除故障和保护容器网络安全的能力。这些都是 Cilium 要解决的难题。
从一开始，Cilium 就是为大规模、高动态的容器化环境而设计的。它能原生理解容器和 Kubernetes 身份，并解析 HTTP、gRPC 和 Kafka 等 API 协议，提供比传统防火墙更简单、更强大的可视性和安全性。
所以, Cilium 的功能要点集中在以下 3 点:
eBPF 使 Cilium 强大的安全可视性和控制逻辑能够动态插入 Linux 内核。eBPF 使 Linux 内核可编程，因此 Cilium 等应用可以 hook Linux 内核子系统，将用户空间应用上下文引入内核操作。
📝Notes:
也因此, 要使用完整的 Cilium 功能, 需要非常新版本的 Linux 内核. 目前官方推荐的 Linux Kernel 是 ≥ 5.10.
由于 eBPF 在 Linux 内核中运行，因此 Cilium 安全策略的应用和更新无需更改应用程序代码或容器配置。eBPF 程序与 Linux 网络数据路径挂钩，可用于在数据包进入网络套接字时，根据网络策略规则采取丢弃数据包等操作。
eBPF 能够以前所未有的粒度和效率实现对系统和应用程序的可见性和控制。它以完全透明的方式实现了这一点，而无需以任何方式更改应用程序。Cilium 利用 eBPF 的强大功能，将高效身份识别概念分层；将 Kubernetes 上下文信息（如元数据标签）引入 eBPF 驱动的网络逻辑。
接下来就让我们来谈谈 Cilium 能做些什么。
Cilium 提供网络连接，允许 pod 和其他组件（Kubernetes 集群内部或外部）进行通信。Cilium 实现了一个简单的扁平 3 层网络，能够跨越多个集群连接所有应用容器(ClusterMesh 功能)。
默认情况下，Cilium 支持 overlay 网络模型，其中一个虚拟网络跨越所有主机。Overlay 网络中的流量经过封装，可在不同主机之间传输。之所以选择这种模式作为默认模式，是因为它对基础设施和集成的要求最低，只需要主机之间的 IP 连接。
Cilium 还提供本地路由(native routing)网络模式选项，使用每台主机上的常规路由表将流量路由到 pod（或外部）IP 地址。这种模式适用于高级用户，需要对底层网络基础设施有一定的了解。它与本地 IPv6 网络、云网络路由器或预先存在的路由守护程序配合使用效果很好。
网络策略定义允许哪些工作负载相互通信，通过防止意外流量来确保部署安全。Cilium 可同时执行本地 Kubernetes NetworkPolicies 和增强型 CiliumNetworkPolicy 资源(CRD)类型。
传统防火墙通过过滤 IP 地址和目标端口来保护工作负载。在 Kubernetes 环境中，每当集群中的 pod 启动时，都需要对所有节点主机上的防火墙（或 iptables 规则）进行操作，以便重建与所需网络策略执行相对应的防火墙规则。这并不能很好地扩展。
为了避免这种情况，Cilium 根据 Kubernetes 标签等相关元数据为应用容器组分配一个身份(identity)。然后将该身份与应用容器发出的所有网络数据包关联起来，使 eBPF 程序能够在接收节点有效验证身份，而无需使用任何 Linux 防火墙规则。例如，当扩展部署并在集群中创建新 pod 时，新 pod 与现有 pod 共享相同的身份。与网络策略执行相对应的 eBPF 程序规则无需再次更新，因为它们已经知道 pod 的身份！
传统防火墙在第 3 层和第 4 层运行，而 Cilium 还能确保 REST/HTTP、gRPC 和 Kafka 等现代第 7 层应用协议的安全（除了在第 3 层和第 4 层执行外）。它能根据应用协议请求条件执行网络策略，例如
/public/.* 的所有 HTTP 请求。拒绝所有其他请求。X-Token:[0-9]+。现在，服务之间的数据加密已成为 PCI 或 HIPAA 等许多监管框架的要求。Cilium 支持使用 IPSec 或 WireGuard 进行简单配置的透明加密，启用后无需重新配置任何工作负载即可确保节点之间流量的安全。
Cilium 的 Cluster Mesh 功能可让工作负载轻松与不同 Kubernetes 集群中托管的服务进行通信。您可以在不同区域的群集中运行服务，并使用 Cilium Cluster Mesh 将它们连接起来，从而实现服务的高可用性。
Cilium 为应用程序容器和外部服务之间的流量实现分布式负载平衡。事实上，Cilium 可以完全替代 kube-proxy 等组件，也可以用作独立的负载均衡器。eBPF 使用高效的哈希表实现负载平衡，几乎可以无限扩展。
虽然我们对 tcpdump 和 ping 等工具情有独钟，它们在我们心中永远占据着特殊的位置，但它们无法胜任在动态 Kubernetes 集群环境中排除网络问题的任务。Cilium 致力于提供可观察性工具，让您能够快速识别和修复集群网络问题。
为此，Cilium 推出了名为 Hubble 的专用网络可观察性组件。Hubble 利用 Cilium 的身份概念，以可操作的方式轻松过滤流量，并提供以下功能：
具体效果如下:
如前文提到的那样, Cilium 和 Hubble 通过 Prometheus 输出有关网络性能和延迟的指标，因此您可以将 Cilium 指标集成到现有的 Grafana 仪表板中。
📝Notes:
最新消息, Cilium 和 Grafana 合作有初步成果了 —— Grafana Hubble 数据源.
具体可以阅读这篇文章: Monitor Kubernetes network and security events with Hubble and Grafana
如上所述，Cilium 支持服务间的负载平衡、应用层可见性和各种与安全相关的功能，所有这些都是 Kubernetes 服务网格的功能。Cilium 还支持 Kubernetes 的 Ingress 和 Gateway API，可提供全套服务网格功能，但不需要在每个 pod 中注入 sidecar 的开销。
Cilium 是一个开源的云原生解决方案，用于提供、保护(安全功能)和观察(监控功能)工作负载之间的网络连接，由革命性的内核技术 eBPF 提供动力。Cilium 主要使用场景是在 Kubernetes中.
Cilium 最主要的特点是:
Cilium 除了作为 Kubernetes CNI 之外, 还有很多其他功能, 包括不限于:
让我们继续前进! 💪
三人行, 必有我师; 知识共享, 天下为公. 本文由东风微鸣技术博客 EWhisper.cn 编写.