cilium 官方文档翻译(2) 组件概述

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集群。