Cilium 系列-3-Cilium 的基本组件和重要概念

系列文章

Cilium 系列文章

前言

安装完了，我们看看 Cilium 有哪些组件和重要概念。

Cilium 组件

如上所述，安装 Cilium 时，会安装几个运行组件（有些是可选组件）, 它们各是什么用途？

Cilium Operator

Cilium Operator 可以理解为 Cilium 的管理平面或操作运维平面。Cilium Operator 不处于任何转发或网络策略决策的关键路径上。如果 Operator 暂时不可用，集群一般也能继续运行。

Cilium Agent

Cilium Agent 以 daemonset 的形式运行，因此 Kubernetes 集群的每个节点上都有一个 Cilium agent pod 在运行。该 agent 执行与 Cilium 相关的大部分工作：

与 Kubernetes API 服务器交互，同步集群状态
与 Linux kernel 交互--加载 eBPF 程序并更新 eBPF map
通过文件系统 socket 与 Cilium CNI 插件可执行文件交互，以获得新调度工作负载的通知
根据要求的网络策略，按需创建 DNS 和 Envoy Proxy 服务器
启用 Hubble 时创建 Hubble gRPC 服务

Cilium Client

Cilium Agent 守护进程中的每个 pod 都带有一个 Cilium Client 可执行文件，可用于检查该节点上安装的 Cilium Agent 和 eBPF map 资源的状态。Client 通过守护进程 pod 与 Cilium Agent 的 REST API 通信。

Warning:

上图图上没有画。

Cilium Client 不是 Cilium CLI.

这与安装在操作机/堡垒机上的 Cilium CLI 工具可执行文件不同。Cilium Client 可执行文件包含在每个 Cilium Agent pod 中，必要时可用作诊断工具，帮助排除 Cilium Agent 运行故障。在正常操作中，你很少会与 Cilium Client 交互，但在某些实验中，当我们使用某些 Cilium 功能时，我们会使用它来帮助我们查看 Cilium 网络状态的内部结构。

Cilium CNI Plugin

Cilium Agent 守护进程还会将 Cilium CNI 插件可执行文件安装到 Kubernetes 主机文件系统中，并重新配置节点的 CNI 以使用该插件。CNI 插件可执行文件与 Cilium Agent 分开，作为 Agent 守护程序初始化的一部分进行安装（即 install-cni-binaries init container)。需要时，Cilium CNI 插件将使用主机文件系统 socket 与运行中的 Cilium Agent 通信。

Hubble Relay

当 Hubble（哈勃望远镜）作为 Cilium 管理集群的一部分启用时，每个节点上运行的 Cilium Agent 将重新启动，以启用 Hubble gRPC 服务，提供节点本地可观测性（会损耗一部分性能，但这是值得的）。为了实现集群范围内的可观测性，集群中将添加 hubble relay deploy 以及两个附加服务：Hubble Observer 服务和 the Hubble Peer 服务。

Hubble Relay Deploy 通过充当整个集群的 Hubble Observer 服务和每个 Cilium Agent 提供的 Hubble gRPC 服务之间的中介，提供集群范围内的可观测性。Hubble Peer 服务可让 Hubble Relay 在集群中启用新的 Hubble Cilium 代理时进行检测。作为用户，通常会使用 Hubble CLI 工具或 Hubble UI 与 Hubble Observer 服务交互，以便深入了解 Hubble 提供的群集网络流量。

Cluster Mesh API Server

Cluster Mesh API 服务器是一种可选部署，只有在启用 Cilium Cluster Mesh 功能时才会安装。Cilium Cluster Mesh 允许多个群集共享 Kubernetes 服务。

Cilium Cluster Mesh 会在每个群集中部署一个 etcd 键值存储，以保存有关 Cilium 身份的信息。它还为每个 etcd 存储提供代理服务。在同一集群网中的任何成员中运行的 Cilium 代理都可以使用该服务在整个集群网中读取有关 Cilium 身份状态的全局信息。这样就可以创建和访问跨越群集网格的全局服务。一旦 Cilium Cluster Mesh API 服务可用，在作为 Cluster Mesh 成员的任何 Kubernetes 集群中运行的 Cilium 代理就能安全地从每个集群的 etcd 代理中读取信息，从而了解整个集群的 Cilium 身份状态。这样就有可能创建跨越集群网状结构的全局服务。

Cilium 重要概念

Cilium Endpoints

简单理解就是一个 Pod, 以及 pod 被分配的 ip.

简单理解为基本等价于 Kubernetes 的 endpoints, 但是包含的信息更多。

示例如下：

$ k3s kubectl get ciliumendpoints.cilium.io -A

NAMESPACE     NAME                                      ENDPOINT ID   IDENTITY ID   INGRESS ENFORCEMENT   EGRESS ENFORCEMENT   VISIBILITY POLICY   ENDPOINT STATE   IPV4         IPV6

default       my-nginx-754c4d44b4-949p2                 1238          30982         <status disabled>     <status disabled>    <status disabled>   ready            10.0.0.77

kube-system   local-path-provisioner-76d776f6f9-d75kl   2157          12431         <status disabled>     <status disabled>    <status disabled>   ready            10.0.0.133

default       my-nginx-754c4d44b4-zs6fl                 205           30982         <status disabled>     <status disabled>    <status disabled>   ready            10.0.0.125

kube-system   coredns-59b4f5bbd5-9q24h                  646           55256         <status disabled>     <status disabled>    <status disabled>   ready            10.0.0.82

kube-system   svclb-traefik-29b9c193-67lk8              2511          4457          <status disabled>     <status disabled>    <status disabled>   ready            10.0.0.211

kube-system   traefik-57c84cf78d-wqq48                  1515          52140         <status disabled>     <status disabled>    <status disabled>   ready            10.0.0.218

kube-system   metrics-server-566c578db4-h59fh           4083          892           <status disabled>     <status disabled>    <status disabled>   ready            10.0.0.158

kube-system   hubble-ui-68fb44f6f5-69ggm                2960          40657         <status disabled>     <status disabled>    <status disabled>   ready            10.0.0.6

kube-system   hubble-relay-5f68b89b76-pzkb5             483           37481         <status disabled>     <status disabled>    <status disabled>   ready            10.0.0.119

这里可以看到，两个 my-nginx pod 的 endpoint id 不同，但是身份是同一个，都是 30982.

Cilium Identity（身份）

使 Cilium 能够高效工作的一个关键概念是 Cilium 的身份概念。所有 Cilium Endpoints 都有一个基于标签的标识。

Cilium 身份由标签决定，在整个集群中是唯一的。端点会被分配与端点安全相关标签相匹配的身份，也就是说，共享同一组安全相关标签的所有端点将共享相同的身份。与每个身份相关的唯一数字标识符会被 eBPF 程序用于网络数据路径中的快速查找，这也是 Hubble 能够提供 Kubernetes 感知网络可观察性的基础。

当网络数据包进入或离开节点时，Cilium 的 eBPF 程序会将源地址和目标 IP 地址映射到相应的数字身份标识符，然后根据引用这些数字身份标识符的策略配置来决定应采取哪些数据路径行动。每个 Cilium Agent 负责通过观察相关 Kubernetes 资源的更新，用与节点上本地运行的端点相关的数字标识符更新与身份相关的 eBPF 映射。

示例如下：

$ k3s kubectl get ciliumidentities.cilium.io -A

NAME    NAMESPACE     AGE

55256   kube-system   2d23h

892     kube-system   2d23h

12431   kube-system   2d23h

4457    kube-system   2d23h

52140   kube-system   2d23h

30982   default       33h

40657   kube-system   37m

37481   kube-system   37m

总结

本文趁热打铁介绍了 Cilium 的基本组件和重要概念。为我们后续 Cilium 的深入使用做好铺垫。

三人行, 必有我师; 知识共享, 天下为公. 本文由东风微鸣技术博客 EWhisper.cn 编写.