Cilium和Hubble的部署包括在集群中运行的以下组件:
Cilium
Agent
cilium-agent在集群中的每个节点上运行。cilium-agent 通过watch Kubernetes api接受配置描述网络、服务负载平衡、网络策略以及可见性。
cilium-agent 侦听来自编排系统(如Kubernetes)的事件,以了解容器或工作负载何时启动和停止。它管理eBPF程序,Linux内核使用这些程序来控制这些容器中的所有网络访问。
Client(CLI)
Cilium CLI客户端(Cilium)是一个命令行工具,与Cilium agent一起安装。它与在同一节点上运行的Cilium agent 通过REST API进行交互。CLI允许检查本地agent的状态。它还提供了直接访问eBPF映射以验证其状态的工具。
Operator
Cilium operator负责管理集群,在逻辑上应该为整个集群处理一次,而不是为集群中的每个节点处理一次。Cilium operator不在任何转发或网络策略决策的关键路径中。如果operator暂时不可用,集群通常还能继续工作。
然而,根据配置,operator的可用性故障可能导致:
- 如果要求operator分配新的IP地址,则IP地址管理(IPAM)延迟,可能延迟新工作负载的调度和启动。
- 无法更新kvstore的 heartbeat 键,会导致agent声明一个unhealthiness
CNI Plugin
当pod在节点上调度或终止时,Kubernetes调用CNI插件(cilium CNI)。它与节点的Cilium API交互,以触发必要的数据路径配置,为pod提供网络、负载平衡和网络策略。
Hubble
server
在每个节点上运行,并从Cilium检索基于eBPF的可见性。它被嵌入cilium agent中,以实现高性能和低开销。它提供了一个gRPC服务来检索flows和prometheus metrics。
relay
Relay(hubble-relay)是一个独立的组件,它可以识别所有正在运行的hubble-server,并通过连接到其各自的gRPC API并提供一个表示集群中所有服务器的API,提供集群范围的可见性。
Client(CLI)
哈勃CLI(hubble)是一种命令行工具,能够连接到hubble-relay的gRPC API或本地服务器以检索流事件。
Graphical UI(GUI)
图形用户界面(hubble-ui)利用基于relay的可见性来提供可视化的服务依赖关系和连接图。
eBPF
eBPF是一个Linux内核字节码解释器,最初用于过滤网络数据包,例如tcpdump和套接字过滤器。此后,它被扩展为额外的数据结构,如哈希表和数组,以及额外的操作,以支持数据包损坏、转发、封装等。内核内验证器确保eBPF程序安全运行,JIT编译器将字节码转换为CPU体系结构特定的指令,以提高本机执行效率。eBPF程序可以在内核中的各种挂钩点上运行,例如用于传入和传出数据包。
随着每一个新的Linux版本的发布,eBPF将继续发展并获得更多的功能。Cilium利用eBPF执行核心数据路径过滤、篡改、监视和重定向,并且需要Linux内核4.8.0或更新版本中的eBPF功能。在4.8.x的已经被宣布为寿命终止,4.9.x被提名为稳定版本,我们建议至少运行内核4.9.17(截至本文撰写时,最新的稳定Linux内核是4.10.x)。
Cilium能够探测Linux内核中的可用功能,并在检测到最新功能时自动利用这些功能。
关于内核版本的更多信息,请查看Linux Kernel 。
Data Store
Cilium需要一个数据存储来在agent之间传播状态。它支持以下数据存储:
kubernetes CRDs(默认)
默认使用Kubernetes自定义资源定义(CRD)来存储和传播状态。Kubernetes为集群组件提供了CRD,以通过Kubernetes资源表示配置和状态。
Key-Value 存储
按照Cilium的默认配置,Kubernetes CRD可以满足状态存储和传播的所有要求。键值存储可以选择性地用作优化,以提高集群的可扩展性,因为通过直接使用键值存储,更改通知和存储需求更高效。
当前仅支持使用etcd作为键值存储。
可以直接利用Kubernetes的etcd集群或维护专用的etcd集群。