OPSaid – Cilium

Docs: Overview

Mon, 08 Jan 2024 09:52:32 +0800

简要概述

Cilium 的基础是一种名为 eBPF 的新 Linux 内核技术，它使得在 Linux 内核内部动态插入强大的安全可见性和控制逻辑成为可能。由于 eBPF 运行在 Linux 内核内部，因此可以在不修改应用程序代码或容器配置的情况下应用和更新 Cilium 安全策略。

Hubble 是一个完全分布式的网络和安全可观察性平台，它构建在 Cilium 和 eBPF 之上，以实现对服务通信和行为以及网络基础设施的深度可见性，完全透明地实现这一目标。

通过构建在 Cilium 之上，Hubble 可以利用 eBPF 来实现可见性。通过依赖 eBPF，所有的可见性都是可编程的，这使得可以采用一种动态的方法，最小化开销同时提供用户所需的深度和详细的可见性。Hubble 已经被创建并专门设计，以充分发挥这些新的 eBPF 功能。

主要特性成熟度

eBPF Networking

功能	状态
Kubernetes CNI	稳定
Load Balancing	稳定
Network Policy	稳定
Kube-proxy Replacement	稳定
Egress Gateway	稳定
Transparent Encryption (IPSec and WireGuard)	稳定
Bandwidth Manager	稳定

Cilium Mesh

功能	状态
Multi-Cluster (ClusterMesh)	稳定
External Workloads	Beta

Hubble Observability

功能	状态
Hubble CLI	稳定
Service Map & Hubble UI	稳定
Prometheus metrics	稳定

Cilium Service Mesh

功能	状态
Kubernetes Ingress Support	稳定
Gateway API Support	Beta
L7-Aware Traffic Management	Beta
Mutual Authentication (Beta)	Beta
SPIFFE integration	Beta

详见 cilium roadmap。

为什么需要它

Cilium 通过 eBPF（Extended Berkeley Packet Filter）技术使得以前无法实现的对系统和应用程序进行细粒度和高效的可见性和控制成为可能。

它在完全透明的情况下实现这一点，无需对应用程序进行任何更改。eBPF 同样适用于处理现代容器化工作负载以及更传统的工作负载，如虚拟机和标准的Linux进程。

在面向高度动态的微服务的转变中，连接微服务之间的安全性既是挑战也是机遇。传统的Linux网络安全方法（例如，iptables）基于IP地址和TCP/UDP端口进行过滤，但在动态微服务环境中，IP地址经常变动。容器的高度不稳定的生命周期导致这些方法难以与应用程序一起进行横向扩展，因为负载均衡表和携带数十万规则的访问控制列表需要以不断增长的频率进行更新。协议端口（例如，用于HTTP流量的TCP端口80）不再能够用于安全目的来区分应用程序流量，因为该端口用于跨服务的广泛消息范围。

存在哪些功能

透明地保护应用

相比传统防火墙保护在第3、4层协议，要求在特定端口上运行的协议要么完全受信任，要么被完全阻止，而 cilium 可同时具备保护应用层协议的能力，如 HTTP、gRPC、Kafka，提供了过滤单个应用程序协议请求的能力，例如：

允许所有使用 GET 方法且路径为 /public/.* 的 HTTP 请求，拒绝所有其他请求；
允许 service1 在 Kafka 主题 topic1 上生成，允许 service2 在 topic1 上消费，拒绝所有其他 Kafka 消息；
要求所有 REST 调用中必须存在 HTTP 头 X-Token: [0-9]+。

其他参考官方示例。

基于身份进行安全的服务间通信

现代分布式应用程序依赖于诸如应用容器等技术，以促进在部署时的灵活性和按需的扩展。这导致在短时间内启动大量应用容器。典型的容器防火墙通过过滤源IP地址和目标端口来保护工作负载。这一概念要求在集群中的任何地方启动容器时，所有服务器上的防火墙都要进行操作。

为了避免这种限制规模的情况，Cilium为共享相同安全策略的应用容器组分配了安全身份。然后，该身份与应用容器发出的所有网络数据包关联，允许在接收节点验证身份。安全身份管理是通过键值存储来执行的。

安全访问和从外部服务中获取数据

基于标签的安全性是集群内部访问控制的首选工具。

为了保护对外部服务的访问，传统的 CIDR 基于的安全策略在入口和出口方向都得到支持。这允许限制对应用容器的访问，以及从特定IP范围进行访问。

简单的组网

简单的扁平3层网络，具有跨多个集群的能力，连接了所有应用容器。

通过使用主机范围分配器，IP分配保持简单。这意味着每个主机都可以在主机之间无需协调地分配IP地址。

多节点支持以下网络模型：

Overlay

基于封装的虚拟网络，覆盖所有主机。目前内置支持 VXLAN 和 Geneve，但所有 Linux 支持的封装格式都可以启用。

何时使用这种模式：这种模式具有最小的基础设施和集成要求。它在几乎任何网络基础设施上都可以工作，因为唯一的要求是主机之间通常已经存在IP连接。

Native Routing

本地路由，使用 Linux 主机的常规路由表，网络需要能够路由应用容器的IP地址。

何时使用这种模式：这种模式适用于高级用户，并需要对底层网络基础设施有一定的了解。这种模式与以下情况配合良好：

本地IPv6网络
与云网络路由器一起使用
如果已经在运行路由守护程序

负载均衡

可完全替代 kube-proxy 组件，支持应用容器之间以及与外部服务之间的负载均衡，它是通过使用高效的哈希表在 eBPF 中实现的，允许几乎无限的扩展。

对于南北向负载均衡（集群内流量），Cilium 的 eBPF 实现被优化以实现最大性能，可以附加到 XDP（eXpress Data Path），并且当不在源主机上执行负载均衡操作时，可支持直接由该服务器返回（DSR）以及 Maglev 一致性哈希。

对于东西向负载均衡（集群外流量），Cilium 在Linux 内核的套接字层（例如在TCP连接时）执行高效的服务到后端的转换，从而避免在更低层中执行每数据包 NAT 操作的开销。

带宽管理

通过使用 eBPF 实现高效的 EDT（Earliest Departure Time）用于速率限制，对从节点出口的容器流量进行带宽管理。

与传统方法，如在带宽 CNI 插件中使用的 HTB（Hierarchy Token Bucket）或 TBF（Token Bucket Filter）相比，可以显著降低应用程序的传输延迟，并避免在多队列网卡下出现锁定问题。

监控和故障排查

提供原生可观测性数据，这对于运行在集群上的分布式应用故障时，对排障定位至关重要。

包括以下技术要点：

事件监控与元数据

当数据包被丢弃时，工具不仅报告数据包的源和目标IP，还提供发送方和接收方的完整标签信息等信息。

通过 Prometheus 导出指标

关键指标通过 Prometheus 标准导出，以与现有的仪表板集成。

Hubble

专为 Cilium 编写的可观察性平台，它提供服务依赖图、操作监控和警报、基于流日志的应用程序和安全可见性。

包含哪些组件

cilium-agent

cilium-agent

以 “DaemonSet” 资源名 “cilium” 在集群中的每个节点上运行：

/usr/bin/cilium-agent --config-dir=/tmp/cilium/config-map

监听来自 Kubernetes 的事件，以了解容器或工作负载何时启动和停止，它管理 eBPF 程序，这些程序由 Linux 内核用于控制这些容器的所有网络访问。

cilium cli

cilium

客户端工具 cilium 是与运行在同一节点上的 cilium-agent 进行交互，命令行界面允许检查本地代理的状态，它还提供工具来直接访问 eBPF 映射以验证其状态。

注意在 cilium-agent 容器内也存在一个命名为 cilium 的二进制文件，二者不要混淆。

cilium-operator

负责管理在集群中一次性处理的任务，而不是在集群中的每个节点上都进行处理，它不转发任何网络数据包，如果暂时不可用，集群仍然会正常运行。

根据不通的配置，服务不可用时，以下操作可能会失败：

IP 地址管理（IPAM）不可用，可能导致新工作负载的调度延迟，尤其是 Pod 需要分配新的 IP 地址；
无法更新 kvstore 心跳键可能导致代理宣告 kvstore 不健康并重新启动。

CNI Plugin

当 Pod 被调度或从宿主上移除时，cilium-cni 将会被 k8s 启动，它跟 cilium api 交互，以便更新网络、负载均衡、安全策略等。

hubble server

Hubble 服务端已内嵌到 cilium-agent 以实现高性能和低开销，它对 eBPF 提供可见性，并提供了 gRPC 服务用于检索数据流跟 Prometheus 标准的性能数据，相关配置如下：

 # An additional address for Hubble server to listen to (e.g. ":4244").
 hubble-listen-address: ":4244"
 hubble-disable-tls: "true"
 #hubble-tls-cert-file: /var/lib/cilium/tls/hubble/server.crt
 #hubble-tls-key-file: /var/lib/cilium/tls/hubble/server.key
 #hubble-tls-client-ca-files: /var/lib/cilium/tls/hubble/client-ca.crt

hubble-relay

hubble-relay 是一个独立的组件，它知道所有运行中的 hubble 服务器，并通过连接到它们各自的 gRPC API 并提供代表集群中所有服务器的API，提供了集群范围的可见性。

hubble cli

Hubble CLI（hubble）是一个命令行工具，能够连接到hubble-relay的gRPC API或本地服务器以检索流事件。

hubble-ui

图形用户界面（hubble-ui）利用基于 relay 的可见性，提供了图形化的服务依赖和连接图。

eBPF

eBPF 是一个最初引入用于过滤网络数据包的 Linux 内核字节码解释器，例如用于 tcpdump 和套接字过滤。

后来，它通过添加额外的数据结构，如哈希表和数组，以及支持数据包篡改、转发、封装等的附加操作而得到扩展。

内核中的验证器确保 eBPF 程序在运行时是安全的，并且即时编译器将字节码转换为特定CPU架构的指令，以实现本机执行效率。

eBPF 程序可以在内核的各种挂钩点上运行，例如用于处理传入和传出的数据包。

Kubernetes CRD

在 cilium 也需要持久化保存一些状态数据，默认是通过 k8s crd 实现，有以下类型：

ciliumcidrgroups.cilium.io
ciliumclusterwidenetworkpolicies.cilium.io
ciliumendpoints.cilium.io
ciliumexternalworkloads.cilium.io
ciliumidentities.cilium.io
ciliuml2announcementpolicies.cilium.io
ciliumloadbalancerippools.cilium.io
ciliumnetworkpolicies.cilium.io
ciliumnodeconfigs.cilium.io
ciliumnodes.cilium.io
ciliumpodippools.cilium.io

Key-Value Store

在 cilium 默认持久化状态是通过使用 Kubernetes CRD 来实现。

作为一种优化，可以选择使用键值存储来提高集群的可伸缩性，因为直接使用键值存储可以更高效地处理变更通知和存储需求。

当前仅支持 etcd。

关键术语

Label

标签是由键和值组成的一对字符串。

标签可以格式化为一个带有 “key=value” 格式的字符串，键部分是必需且唯一的，一般使用反向域名的概念来实现，例如：

io.cilium.mykey=myvalue

值部分是可选的，可以省略，例如：

io.cilium.mykey

键名通常应由字符集 “[a-z0-9-.]” 组成，在使用标签选择资源时，键和值都必须匹配，例如当一个策略应用于所有带有标签 my.corp.foo 的端点时，标签 my.corp.foo=bar 将不匹配选择器。

Label Source

标签可以从各种来源派生。

例如，一个端点将通过本地容器运行时派生与容器关联的标签，以及由 Kubernetes 提供的与 Pod 关联的标签。

由于这两个标签命名空间不知道对方的存在，这可能导致标签键的冲突。

为解决这种潜在的冲突，cilium 在导入标签时给所有标签键添加了前缀 “source:” 以指示标签的来源，例如

k8s:app.kubernetes.io/name=metrics-server
k8s:io.cilium.k8s.namespace.labels.kubernetes.io/metadata.name=kube-system
k8s:io.cilium.k8s.policy.cluster=fake
k8s:io.cilium.k8s.policy.serviceaccount=metrics-server
k8s:io.kubernetes.pod.namespace=kube-system
reserved:health

为每个标签来源固定分配唯一的名称，目前支持以下：

“container”: 用于从本地容器运行时派生的标签；
“k8s”: 用于从 Kubernetes 派生的标签；
“reserved”: 用于特殊保留标签，见以下特殊标识表；
“unspec”: 用于未指定来源的标签；
“any”: 表示匹配所有标签，不考虑以上来源。

当使用标签标识其他资源时，可以包含源以限制标签匹配到特定类型。

如果未提供源，则标签源默认为 any:，这将匹配所有标签，如果提供了源，则选择和匹配标签的源需要匹配。

特殊标识：

编号	标识	描述
0	reserved:unknown	x
1	reserved:host	本地主机。任何源自或指定给本地主机IP的流量
2	reserved:world	集群外的任何网络端点
3	reserved:unmanaged	未由Cilium管理的端点，例如在安装Cilium之前启动的Kubernetes Pod
4	reserved:health	由 cilium-agent 生成的ip, 用于健康检查
5	reserved:init	尚未解析身份的端点被分配init身份。表示端点处于某种阶段
6	reserved:remote-node	集群排除本节点，其他远程主机集合
7	reserved:kube-apiserver	运行 kube-apiserver 后端服务的节点
8	reserved:ingress	用作 ingress 代理连接的源地址的IP

Endpoint

Cilium 为容器分配 IP 地址，而同一个 Pod 内多个容器共享同一个地址，他们则称为一个端点（Endpoint），如：

$ kubectl get ciliumendpoints.cilium.io -n kube-system
NAME ENDPOINT ID IDENTITY ID INGRESS ENFORCEMENT EGRESS ENFORCEMENT VISIBILITY POLICY ENDPOINT STATE IPV4 IPV6
hubble-relay-69dc7ffc7c-nbd94 1339 46722 <status disabled> <status disabled> <status disabled> ready 192.168.201.6
hubble-ui-56969ff7db-4kkbx 646 10752 <status disabled> <status disabled> <status disabled> ready 192.168.201.4
metrics-server-844d95488f-8whf6 1464 14083 <status disabled> <status disabled> <status disabled> ready 192.168.201.35
metrics-server-844d95488f-9ctrp 1083 59399 <status disabled> <status disabled> <status disabled> ready 192.168.201.14
metrics-server-844d95488f-mcjkl 6 59399 <status disabled> <status disabled> <status disabled> ready 192.168.201.24

分配独立的 IP 地址使得每个端点可以使用独立的网络协议栈，默认行为是为每个端点分配 IPv4 和 IPv6 地址，可以通过配置单独开启或关闭。

同时为了标识目的，cilium 为每个集群节点上的所有端点分配一个内部端点ID，且 ID 在单个集群节点的上下文中是唯一的。

端点会自动从与其关联的容器拉取标签作为元数据，然后使用这些元数据来标识端点，以用于安全策略、负载均衡和路由等目的。这些元数据的来源取决于正在使用的编排系统，目前支持以下元数据检索机制：

编排系统	获取方式
Kubernetes	Pod labels (via k8s API)
Docker	Container labels (via Docker API)

Identity

所有端点（Endpoint）都被分配一个身份（Identity），用于强制执行端点之间的基本连接。在传统的网络术语中，这相当于第3层的强制执行。

身份通过标签进行识别，并被赋予一个在整个集群中唯一的标识符。端点被分配与其安全相关标签匹配的身份，即所有共享相同安全相关标签集的端点将共享相同的身份。这个概念允许将策略执行扩展到大量的端点，因为许多个体端点通常会共享与应用程序扩展相同的安全标签集。

端点的身份是根据派生到端点的Pod或容器的标签来推导的。当启动Pod或容器时，Cilium将根据容器运行时接收到的事件创建一个端点，以在网络上表示Pod或容器。然后，Cilium将解析创建的端点的身份。每当Pod或容器的标签发生变化时，身份将被重新确认，并根据需要自动修改。

与容器或 Pod 相关联的并非所有标签在推导身份时都是有意义的。标签可能用于存储元数据，例如容器启动的时间戳。Cilium 需要知道哪些标签是有意义的，并在推导身份时将其考虑在内。为此，用户需要指定一个有意义的标签字符串前缀列表。标准行为是包括所有以 id. 前缀开头的标签，例如 id.service1、id.service2、id.groupA.service44。在启动代理时可以指定有意义的标签前缀列表。

TODO;

Node

Cilium 将节点称为集群的一个个体成员，每个节点必须运行 cilium-agent，并且将以大多数自治的方式运行。为了简化和提高可伸缩性，不同节点上运行的 cilium-agent 之间的状态同步被保持到最小。它仅通过键值存储或数据包元数据进行。

Docs: kube-proxy

Fri, 12 Apr 2024 10:52:11 +0800

简要概述

在一定内核版本下，“cilium” 已经可以完全替代 “kube-proxy” 组件的功能了，如处理 k8s 服务类型为：ClusterIP, NodePort, LoadBalancer 等流量转发。

如何启用功能

更改配置

apiVersion: v1
kind: ConfigMap
metadata:
 name: cilium-config
 namespace: kube-system
data:

......
 kube-proxy-replacement: "true"
......

在配置中把 “kube-proxy-replacement” 设置为 “true” 开启。

验证状态

登录至 “cilium” 容器内运行以下指令查看状态：

cilium status --verbose

如下，各功能启用状态：

KubeProxyReplacement Details:
 Status: True
 Socket LB: Enabled
 Socket LB Tracing: Enabled
 Socket LB Coverage: Full
 Devices: enx0826ae396977 192.168.0.2 (Direct Routing), wlp0s20f3 192.168.0.2
 Mode: SNAT
 Backend Selection: Random
 Session Affinity: Enabled
 Graceful Termination: Enabled
 NAT46/64 Support: Disabled
 XDP Acceleration: Disabled
 Services:
 - ClusterIP: Enabled
 - NodePort: Enabled (Range: 30000-32767)
 - LoadBalancer: Enabled
 - externalIPs: Enabled
 - HostPort: Enabled

验证功能

创建以下资源：

---
apiVersion: v1
kind: Pod
metadata:
 creationTimestamp: null
 labels:
 run: nginx
 name: nginx
spec:
 containers:
 - image: registry.cn-hangzhou.aliyuncs.com/kube-image-repo/nginx:1.23.2
 name: nginx
 resources: {}
 ports:
 - containerPort: 80
 dnsPolicy: ClusterFirst
 restartPolicy: Always
status: {}

---
apiVersion: v1
kind: Service
metadata:
 creationTimestamp: null
 labels:
 run: nginx
 name: nginx
spec:
 ports:
 - port: 80
 protocol: TCP
 targetPort: 80
 selector:
 run: nginx
 type: NodePort

查看 Pod、Service 状态：

$ kubectl get pods,services -l run=nginx -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod/nginx 1/1 Running 0 79s 192.168.201.4 192.168.0.2 <none> <none>

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
service/nginx NodePort 10.233.90.187 <none> 80:32515/TCP 79s run=nginx
$

查看 cilium 转发状态：

$ kubectl exec -i -t cilium-mzzk6 -n kube-system -- cilium service list
ID Frontend Service Type Backend
1 10.233.0.1:443 ClusterIP 1 => 192.168.0.2:6443 (active)
11 10.233.0.10:9153 ClusterIP 1 => 192.168.201.3:9153 (active)
12 10.233.0.10:53 ClusterIP 1 => 192.168.201.3:53 (active)
13 10.233.166.209:443 ClusterIP 1 => 192.168.201.12:4443 (active)
25 10.233.2.226:2746 ClusterIP 1 => 192.168.201.7:2746 (active)
......
37 192.168.0.2:32515 NodePort 1 => 192.168.201.4:80 (active)
38 0.0.0.0:32515 NodePort 1 => 192.168.201.4:80 (active)
$

验证服务访问：

$ curl 'http://192.168.0.2:32515'
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
......
</body>
</html>
$

常见几种用法

指定网卡用于 NodePort 服务

应用场景：当宿主存在多网卡时，避免 “Service” 为 “NodePort” 类型的资源监听在非期望的网段上，如未配置好防火墙则可能导致意外数据暴露。

该实验宿主存在以下网卡

$ ip addr list
2: wlp0s20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
 inet 10.5.56.241/24 brd 10.5.56.255 scope global dynamic noprefixroute wlp0s20f3
3: enx0826ae396977: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
 inet 192.168.0.2/24 brd 192.168.0.255 scope global noprefixroute enx0826ae396977
$

网卡 “wlp0s20f3”、“enx0826ae396977” 分别配置了 “10.5.56.241/24”、“192.168.0.2/24” 地址。

创建 NodePort 类型的服务

apiVersion: v1
kind: Service
metadata:
 name: cilium-ingress
 namespace: kube-system
 labels:
 cilium.io/ingress: "true"
spec:
 ports:
 - name: http
 port: 80
 protocol: TCP
 nodePort: 30080
 type: NodePort

此时监听在 NodePort 的地址

$ cilium service list
ID Frontend Service Type Backend
10 10.233.0.1:443 ClusterIP 1 => 192.168.0.2:6443 (active)
11 10.233.124.160:80 ClusterIP
12 192.168.0.2:30080 NodePort
14 0.0.0.0:30080 NodePort
15 10.233.148.250:80 ClusterIP 1 => 192.168.0.2:4244 (active)
16 10.233.46.189:80 ClusterIP 1 => 192.168.201.4:4245 (active)
17 10.233.49.29:80 ClusterIP 1 => 192.168.201.14:8081 (active)
18 10.233.216.132:2746 ClusterIP 1 => 192.168.201.1:2746 (active)
19 10.5.56.241:30080 NodePort
$

也通过 “bpftool net” 查看当前绑定在 “tc” 阶段的网卡有哪些：

$ bpftool net
xdp:

tc:
wlp0s20f3(2) clsact/ingress cil_from_netdev-wlp0s20f3 id 19355
wlp0s20f3(2) clsact/egress cil_to_netdev-wlp0s20f3 id 19360
enx0826ae396977(3) clsact/ingress cil_from_netdev-enx0826ae396977 id 19340
enx0826ae396977(3) clsact/egress cil_to_netdev-enx0826ae396977 id 19341
cilium_net(4) clsact/ingress cil_to_host-cilium_net id 19325
cilium_host(5) clsact/ingress cil_to_host-cilium_host id 19304
cilium_host(5) clsact/egress cil_from_host-cilium_host id 19284
lxc96ee90fabd66(93) clsact/ingress cil_from_container-lxc96ee90fabd66 id 19327
lxc5f977feb7c71(95) clsact/ingress cil_from_container-lxc5f977feb7c71 id 19262
lxc442d93d4a07e(99) clsact/ingress cil_from_container-lxc442d93d4a07e id 19300
lxc3d8018e15dbd(101) clsact/ingress cil_from_container-lxc3d8018e15dbd id 19313
lxc_health(145) clsact/ingress cil_from_container-lxc_health id 19333

flow_dissector:

$

此时可以通过 “telnet 10.5.56.241 30080” 联通，当并不希望在该网卡上监听服务。

配置 “cilium-config” 中的 “devices” 参数

apiVersion: v1
kind: ConfigMap
metadata:
 name: cilium-config
 namespace: kube-system
data:
 ......
 devices: "lxc+ enx0826ae396977"
 ......

多网卡情况下 “devices” 中间使用空格隔开，如：“eth0 em3 bind1”。以上配置说明仅在 “lxc” 开头与名为 “enx0826ae396977” 网卡上处理。

在通过 “bpftool net” 或者 “cilium service list” 查看信息，是否满足需求：

$ bpftool net
xdp:

tc:
enx0826ae396977(3) clsact/ingress cil_from_netdev-enx0826ae396977 id 21450
enx0826ae396977(3) clsact/egress cil_to_netdev-enx0826ae396977 id 21447
cilium_net(4) clsact/ingress cil_to_host-cilium_net id 21434
cilium_host(5) clsact/ingress cil_to_host-cilium_host id 21355
cilium_host(5) clsact/egress cil_from_host-cilium_host id 21410
lxc96ee90fabd66(93) clsact/ingress cil_from_netdev-lxc96ee90fabd66 id 21500
lxc96ee90fabd66(93) clsact/egress cil_to_netdev-lxc96ee90fabd66 id 21502
lxc5f977feb7c71(95) clsact/ingress cil_from_netdev-lxc5f977feb7c71 id 21494
lxc5f977feb7c71(95) clsact/egress cil_to_netdev-lxc5f977feb7c71 id 21491
lxc442d93d4a07e(99) clsact/ingress cil_from_netdev-lxc442d93d4a07e id 21473
lxc442d93d4a07e(99) clsact/egress cil_to_netdev-lxc442d93d4a07e id 21475
lxc3d8018e15dbd(101) clsact/ingress cil_from_netdev-lxc3d8018e15dbd id 21463
lxc3d8018e15dbd(101) clsact/egress cil_to_netdev-lxc3d8018e15dbd id 21461
lxc_health(155) clsact/ingress cil_from_container-lxc_health id 21362

flow_dissector:

$

这里需注意下为什么要带上 “lxc” 开头的网卡，如果缺失 “bpftool net” 查看的数据为：

$ bpftool net
xdp:

tc:
enx0826ae396977(3) clsact/ingress cil_from_netdev-enx0826ae396977 id 19760
enx0826ae396977(3) clsact/egress cil_to_netdev-enx0826ae396977 id 19762
cilium_net(4) clsact/ingress cil_to_host-cilium_net id 19723
cilium_host(5) clsact/ingress cil_to_host-cilium_host id 19706
cilium_host(5) clsact/egress cil_from_host-cilium_host id 19665
lxc96ee90fabd66(93) clsact/ingress cil_from_container-lxc96ee90fabd66 id 19691
lxc5f977feb7c71(95) clsact/ingress cil_from_container-lxc5f977feb7c71 id 19682
lxc442d93d4a07e(99) clsact/ingress cil_from_container-lxc442d93d4a07e id 19733
lxc3d8018e15dbd(101) clsact/ingress cil_from_container-lxc3d8018e15dbd id 19670
lxc_health(147) clsact/ingress cil_from_container-lxc_health id 19747

flow_dissector:

$

可以看到在 “lxc” 开头的网卡仅剩 “clsact/ingress” hook 钩子了，丢失了 “clsact/egress” 这种情况下在使用 “cilium-envoy” 会无法路由到后端，观察到是 “reserved:ingress” 的 ip 无法与具体的 Pod 联通，具体原因待细查。

$ cilium ip list | grep reserved
0.0.0.0/0 reserved:world
10.5.56.241/32 reserved:host
 reserved:kube-apiserver
192.168.0.2/32 reserved:host
 reserved:kube-apiserver
192.168.201.4/32 reserved:health
192.168.201.12/32 reserved:ingress
192.168.201.13/32 reserved:host
 reserved:kube-apiserver
$

可在宿主上 “tcpdump” 具体 Pod 网卡数据包：

$ tcpdump -i lxc442d93d4a07e -nn
......
17:26:21.709985 IP 192.168.201.12.43687 > 192.168.201.1.2746: Flags [S], seq 3062515778, win 64240, options [mss 1460,sackOK,TS val 2429471181 ecr 0,nop,wscale 7], length 0
17:26:21.710010 IP 192.168.201.1.2746 > 192.168.201.12.43687: Flags [S.], seq 955549526, ack 3062515779, win 65160, options [mss 1460,sackOK,TS val 2974496186 ecr 2429468135,nop,wscale 7], length 0
17:26:21.710058 IP 192.168.201.1.2746 > 192.168.201.12.43687: Flags [S.], seq 955549526, ack 3062515779, win 65160, options [mss 1460,sackOK,TS val 2974496186 ecr 2429468135,nop,wscale 7], length 0
17:26:21.741919 IP 192.168.201.13 > 192.168.201.1: ICMP host 192.168.201.12 unreachable, length 68
17:26:21.741954 IP 192.168.201.13 > 192.168.201.1: ICMP host 192.168.201.12 unreachable, length 68
17:26:21.741973 IP 192.168.201.13 > 192.168.201.1: ICMP host 192.168.201.12 unreachable, length 68
17:26:21.741990 IP 192.168.201.13 > 192.168.201.1: ICMP host 192.168.201.12 unreachable, length 68
17:26:21.742008 IP 192.168.201.13 > 192.168.201.1: ICMP host 192.168.201.12 unreachable, length 68
......

其中 “reserved:ingress = 192.168.201.12” 无法与后端 “Pod 192.168.201.1” 建立 TCP 连接，错误 “ICMP unreachable”。

集群流量策略

internalTrafficPolicy	externalTrafficPolicy	南北向流量	东西向流量
Cluster	Cluster	所有节点可达	所有节点可达
Cluster	Local	仅被访问节点	所有节点可达
Local	Cluster	所有节点可达	仅被访问节点
Local	Local	仅被访问节点	仅被访问节点

Docs: 使用 BGP

Sun, 08 Dec 2024 12:23:14 +0800

简要概述

为什么需要 BGP

1. Service IP 宣告 (LoadBalancer 类型服务）

当在 Kubernetes 中创建一个 LoadBalancer 类型的 Service 资源时，Cilium 可以通过 BGP 将分配给该资源的 “External IP” 宣告给 ToR 交换机。这样，外部网络就知道如何将流量路由到这个 Service。

2. Pod IP 宣告 (当非 HTTP 协议需对外，如数据库实例等）

在某些网络架构中（需为了避免 NAT，实现 Pod IP 的直接可达性，提供效率），Cilium 可以将分配给每个节点的 Pod CIDR 或者甚至单个 Pod IP 宣告给外部网络。这使得外部网络可以直接路由到 Pod IP，而不需要经过 NAT 的转换。

3. 集群间路由（多集群组建为大规模 Mesh）

如果你有多个 Kubernetes 集群，BGP 可以用来在它们之间宣告路由，实现跨集群通信。

BGP 实现方式

Cilium 通过集成 gobgp 这样的外部 BGP Speaker 实现。

在组件 cilium-agent 中代码 “github.com/cilium/cilium/pkg/bgpv1/gobgp” 实现了 bgp 服务。

在宿主上

以下配置基于 “cilium/v1.14.17”、“cilium/v1.16.12” 分析。

确认开启 bgp 特性

确认已开启 cilium bgp 控制平面：

# cilium config view | grep bgp
enable-bgp-control-plane true
#

使用 crd 配置 bgp，在 cilium 中存在两种类型，分别为 CiliumBGPPeeringPolicy（v1.16 版本之前，现标记废弃）、CiliumBGPClusterConfig（v1.16 及之后版本）。

禁止同时使用两者资源，若两个资源同时存在且 cilium 通过节点选择器同时匹配到两者时，系统将优先采用 CiliumBGPPeeringPolicy 的配置。

配置 CiliumBGPPeeringPolicy

在 cilium v1.15 及以下版本使用。

创建 BGP Peer

apiVersion: "cilium.io/v2alpha1"
kind: CiliumBGPPeeringPolicy
metadata:
 name: cilium-bgp
spec:
 # 在哪些节点上开启与 peer 建立连接
 nodeSelector:
 matchLabels:
 bgp: test1
 virtualRouters:
 - localASN: 65415
 # 通告 pod 网段
 exportPodCIDR: true
 # 通告哪些 service 路由
 serviceSelector:
 matchLabels:
 cilium.io/announce-bgp-service: "true"
 neighbors:
 - peerAddress: '192.168.17.252/32'
 peerASN: 65415

对节点存在标签 “bgp=test1” 则与 bgp peer 地址为 “192.168.17.252” 且 “as=65415” 建立连接。

对特定接口打标签

kubectl label node 192.168.17.142 bgp=test1

对节点绑定标签以满足 bgp peer 建立连接，注意一个节点不能同时匹配多个 CiliumBGPPeeringPolicy 资源，否则无法启用。

配置 CiliumBGPClusterConfig

在 cilium v1.16 及以上版本新增 CiliumBGPClusterConfig 资源，同时废弃以上资源。

资源定义

CRD	用途
CiliumBGPClusterConfig	定义 bgp 实例，通过 `name` 唯一标识
CiliumBGPPeerConfig	每个 bgp 实例中关联 peer 的个性配置
CiliumBGPAdvertisement	通告路由的规则
CiliumBGPNodeConfig	-
CiliumBGPNodeConfigOverride	-

创建 bgp 实例

---
apiVersion: cilium.io/v2alpha1
kind: CiliumBGPClusterConfig
metadata:
 name: cilium-bgp
spec:
 nodeSelector:
 matchLabels:
 rack: rack0
 bgpInstances:
 - name: "instance-65000"
 localASN: 65000
 peers:
 - name: "peer-65000-tor1"
 peerASN: 65000
 peerAddress: 192.168.0.149
 peerConfigRef:
 name: "cilium-peer"
 - name: "peer-65000-tor2"
 peerASN: 65000
 peerAddress: 192.168.0.121
 peerConfigRef:
 name: "cilium-peer"

与两个 peer “192.168.0.149”, “192.168.0.121” 建立连接，各 peer 配置见资源 “cilium-peer”

BGP Peer 配置

---
apiVersion: cilium.io/v2alpha1
kind: CiliumBGPPeerConfig
metadata:
 name: cilium-peer
spec:
 timers:
 holdTimeSeconds: 9
 keepAliveTimeSeconds: 3
 #authSecretRef: bgp-auth-secret
 ebgpMultihop: 4
 gracefulRestart:
 enabled: true
 restartTimeSeconds: 15
 families:
 - afi: ipv4
 safi: unicast
 advertisements:
 # 匹配 CiliumBGPAdvertisement 的标签
 matchLabels:
 advertise: "bgp"
 transport:
 peerPort: 179

比如认证、超时、通告 ip 地址族等个性化配置。

BGP 通告

---
apiVersion: cilium.io/v2alpha1
kind: CiliumBGPAdvertisement
metadata:
 name: bgp-advertisements
 labels:
 advertise: bgp
spec:
 advertisements:
 # 通告 Service VIP
 - advertisementType: "Service"
 service:
 addresses:
 - ClusterIP
 - LoadBalancerIP
 # 通告 POD 网段
 - advertisementType: "PodCIDR"
 attributes:
 communities:
 standard: [ "65000:99" ]
 localPreference: 99

通告 Service

当类型为 “LoadBalancerIP” 时，需确保 k8s 集群能分配 IP，这里也使用 cilium LB IPAM 特性。

apiVersion: "cilium.io/v2alpha1"
kind: CiliumLoadBalancerIPPool
metadata:
 name: "default"
spec:
 blocks:
 - cidr: "192.168.253.0/24"

应用场景

配置 Router ID

如果集群运行的是 ipv4 或 ipv4/ipv6 双栈，cilium 会自动使用宿主 ipv4 上的 IP 作为 Router ID。

如果仅运行 ipv6 或者需要手工配置的话，需要添加注解：

kubectl annotate node 192.168.17.142 cilium.io/bgp-virtual-router.65415="router-id=192.168.17.142"

配置宿主监听端口

宿主通过随机端口与远端 179 通讯：

kubectl logs -f cilium-nlkxs -n kube-system --tail=10

level=info msg="type:STATE peer:{conf:{local_asn:65415 neighbor_address:\"192.168.17.252\" peer_asn:65415} state:{local_asn:65415 neighbor_address:\"192.168.17.252\" peer_asn:65415 session_state:OPENSENT router_id:\"<nil>\"} transport:{local_address:\"192.168.17.140\" local_port:50409 remote_port:179}}"
level=info msg="type:STATE peer:{conf:{local_asn:65415 neighbor_address:\"192.168.17.252\" peer_asn:65415} state:{local_asn:65415 neighbor_address:\"192.168.17.252\" peer_asn:65415 session_state:IDLE router_id:\"<nil>\"} transport:{local_address:\"192.168.17.140\" local_port:50409 remote_port:179}}"
level=info msg="type:STATE peer:{conf:{local_asn:65415 neighbor_address:\"192.168.17.252\" peer_asn:65415} state:{local_asn:65415 neighbor_address:\"192.168.17.252\" peer_asn:65415 session_state:ACTIVE router_id:\"<nil>\"} transport:{local_address:\"192.168.17.140\" local_port:50409 remote_port:179}}"
level=info msg="type:STATE peer:{conf:{local_asn:65415 neighbor_address:\"192.168.17.252\" peer_asn:65415} state:{local_asn:65415 neighbor_address:\"192.168.17.252\" peer_asn:65415 session_state:OPENSENT router_id:\"<nil>\"} transport:{local_address:\"192.168.17.140\" local_port:47671 remote_port:179}}"
level=info msg="Peer Up" Key=192.168.17.252 State=BGP_FSM_OPENCONFIRM Topic=Peer asn=65415 component=gobgp.BgpServerInstance subsys=bgp-control-plane
level=info msg="type:STATE peer:{conf:{local_asn:65415 neighbor_address:\"192.168.17.252\" peer_asn:65415} state:{local_asn:65415 neighbor_address:\"192.168.17.252\" peer_asn:65415 session_state:OPENCONFIRM router_id:\"192.168.17.252\"} transport:{local_address:\"192.168.17.140\" local_port:47671 remote_port:179}}"
level=info msg="type:STATE peer:{conf:{local_asn:65415 neighbor_address:\"192.168.17.252\" peer_asn:65415} state:{local_asn:65415 neighbor_address:\"192.168.17.252\" peer_asn:65415 session_state:ESTABLISHED router_id:\"192.168.17.252\"} transport:{local_address:\"192.168.17.140\" local_port:47671 remote_port:179}}"

通过主动标记设置本地端口：

kubectl annotate node 192.168.17.142 cilium.io/bgp-virtual-router.65415="local-port=61179"

通告 LoadBalancer IP

以下配置基于 “cilium/v1.14.17” 分析。

1. 创建示例服务

apiVersion: apps/v1
kind: Deployment
metadata:
 labels:
 app: nginx
 name: nginx
spec:
 replicas: 1
 selector:
 matchLabels:
 app: nginx
 template:
 metadata:
 labels:
 app: nginx
 spec:
 containers:
 - image: registry.cn-hangzhou.aliyuncs.com/opsaid/nginx:1.23-debian-11
 name: nginx
 securityContext:
 allowPrivilegeEscalation: false
 capabilities:
 drop:
 - ALL
 runAsNonRoot: true
 securityContext:
 seccompProfile:
 type: RuntimeDefault

创建 “nginx” 应用默认在 “8080” 端口监听。

2. 创建 “LoadBalancer” 类型 “Service”

apiVersion: v1
kind: Service
metadata:
 name: nginx
 labels:
 # 与 CiliumBGPPeeringPolicy 联动
 cilium.io/announce-bgp-service: "true"
spec:
 selector:
 app: nginx
 ports:
 - port: 80
 targetPort: 8080
 # 前提条件
 externalTrafficPolicy: Cluster
 # 如果存在多个提供方，明确使用 cilium bgp 分配
 loadBalancerClass: "io.cilium/bgp-control-plane"
 type: LoadBalancer

对 “default” 空间下标签为 “app=nginx” 创建 “LoadBalancer”，此时访问 “Service” 对外的端口为 “80” 会自动转发至应用 “8080” 服务。

# kubectl get service nginx
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx LoadBalancer 10.233.46.209 <pending> 80:31624/TCP 2m40s
#

创建成功后，因为集群本身不支持自动分配 IP，所以 “EXTERNAL-IP” 会一直处于 “pending” 状态。

3. 记录当前 TOR 交换机 BGP 路由

>display bgp routing-table
 BGP Local router ID is 192.168.17.252
 Status codes: * - valid, > - best, d - damped, a - add path,
 h - history, i - internal, s - suppressed, S - Stale
 Origin : i - IGP, e - EGP, ? - incomplete


 Total Number of Routes: 4
 Network NextHop MED LocPrf PrefVal Path/Ogn
 *>i 192.168.200.0/24 192.168.17.140 100 0 i
 *>i 192.168.201.0/24 192.168.17.141 100 0 i
 *>i 192.168.202.0/24 192.168.17.142 100 0 i
 *>i 192.168.203.0/24 192.168.17.143 100 0 i
>

仅到集群 POD CIDR 路由。

3. 手工更改 “Service” 中 “status” 地址

在 “cilium v1.14” 版本下需要更改，“v1.16” 版本会自动分配 IP。

cat <<EOF > patch.json
{
 "status": {
 "loadBalancer": {
 "ingress": [
 { "ip": "192.168.253.1" }
 ]
 }
 }
}
EOF

kubectl patch service nginx \
 --namespace default \
 --type merge \
 --patch-file patch.json \
 --subresource status

# kubectl get service nginx
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx LoadBalancer 10.233.46.209 192.168.253.1 80:31624/TCP 8m9s
# ^C

这里为什么需要手工更改 “status” 信息？

4. 再次验证 TOR 是否学到路由

>display bgp routing-table
BGP Local router ID is 192.168.17.252
Status codes: * - valid, > - best, d - damped, a - add path,
h - history, i - internal, s - suppressed, S - Stale
Origin : i - IGP, e - EGP, ? - incomplete
Total Number of Routes: 8
Network NextHop MED LocPrf PrefVal Path/Ogn
*>i 192.168.200.0/24 192.168.17.140 100 0 i
*>i 192.168.201.0/24 192.168.17.141 100 0 i
*>i 192.168.202.0/24 192.168.17.142 100 0 i
*>i 192.168.203.0/24 192.168.17.143 100 0 i
*>i 192.168.253.1/32 192.168.17.140 100 0 i
* i 192.168.17.141 100 0 i
* i 192.168.17.142 100 0 i
* i 192.168.17.143 100 0 i
>

可以观察到 TOR 交换机学习到对端通告的 “192.168.253.1/32” 路由并标记 “192.168.17.140” 为下一跳最优。

5. 通告 LoadBalancer IP 的前提条件

前提条件：

需 “externalTrafficPolicy” 为 “Cluster” 类型；
需 “LoadBalancer” 存在 “status.loadBalancer.ingress[].ip” 值；
如果存在多个负载均衡器，需明确 “loadBalancerClass” 值；

当集群本身不支持自动分配 LoadBalancer 类型 Service IP 时，需要手工添加。

此版本 “cilium/v1.14.17” 关键判断代码如下：

github.com/cilium/cilium/pkg/bgpv1/manager/reconcile.go

......

 // Ignore externalTrafficPolicy == Local && no local endpoints
 if svc.Spec.ExternalTrafficPolicy == slim_corev1.ServiceExternalTrafficPolicyLocal &&
 !hasLocalEndpoints(svc, ls) {
 return nil, nil
 }

 var desiredRoutes []netip.Prefix
 for _, ingress := range svc.Status.LoadBalancer.Ingress {
 if ingress.IP == "" {
 continue
 }

 addr, err := netip.ParseAddr(ingress.IP)
 if err != nil {
 continue
 }

 desiredRoutes = append(desiredRoutes, netip.PrefixFrom(addr, addr.BitLen()))
 }

......

分配 LoadBalancer IP

在通告 LoadBalancer IP 实验中可知，创建 LoadBalancer 资源后，会等待集群分配 “EXTERNAL-IP” 如果持续未分配则无法通告路由至上联 TOR 交换机。

LB IPAM 是一项允许 Cilium 为 LoadBalancer 类型的 Service 分配 IP 地址的功能。在公有云环境中，此类操作通常由云服务商自动处理；但在私有云部署场景下，往往缺乏现成的 IP 分配机制。

这里我们利用 cilium 特性，通告创建一个 CIDR 网络，允许自动分配 IP 地址：

apiVersion: "cilium.io/v2alpha1"
kind: CiliumLoadBalancerIPPool
metadata:
 name: "default"
spec:
 # 在 cilium/1.14 下参数配置
 cidrs:
 - cidr: "192.168.253.0/24"

 # 在 cilium/1.16 下参数配置
 #blocks:
 #- cidr: "192.168.253.0/24"

注意：

更新IP地址池可能导致IP地址重新分配，进而引发服务IP变更；
如果删除该资源则对已分配的 IP 也会同时回收，也就是删除已通告的 BGP 路由；
默认情况下，LB-IPAM 会使用给定 CIDR 中的所有IP地址，所以分配是记得保留。

其他参考

ToR 交换机架构