系列文章
- 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 ready 10.0.0.77
kube-system local-path-provisioner-76d776f6f9-d75kl 2157 12431 ready 10.0.0.133
default my-nginx-754c4d44b4-zs6fl 205 30982 ready 10.0.0.125
kube-system coredns-59b4f5bbd5-9q24h 646 55256 ready 10.0.0.82
kube-system svclb-traefik-29b9c193-67lk8 2511 4457 ready 10.0.0.211
kube-system traefik-57c84cf78d-wqq48 1515 52140 ready 10.0.0.218
kube-system metrics-server-566c578db4-h59fh 4083 892 ready 10.0.0.158
kube-system hubble-ui-68fb44f6f5-69ggm 2960 40657 ready 10.0.0.6
kube-system hubble-relay-5f68b89b76-pzkb5 483 37481 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 编写.
