Cilium 面试题

35 道题

分类: Kubernetes
子分类: cni
题目数: 35 道

已阅读 0 / 35 题

1 Cilium 的核心架构由哪些组件组成？

答案：

Cilium 基于 eBPF 实现，核心组件包括 Cilium Agent、Cilium Operator、CNI Plugin、Hubble 和 Cilium CLI。

Cilium Agent：运行在每个节点上的 DaemonSet，负责加载 eBPF 程序、管理网络策略、分配 IP 地址、处理 Service 规则。通过 eBPF 直接在内核层面控制数据包转发。
Cilium Operator：负责集群级管理任务，包括身份管理（Security Identity）、端点健康检查（CEP/CES）、IP 池分配协调、ClusterMesh 配置同步。
CNI Plugin（cilium-cni）：标准 CNI 插件实现，接收 kubelet 请求后调用 Agent 完成容器网络接口创建和 eBPF 程序挂载。
Hubble：基于 eBPF 的可观测性层，提供网络流捕获、服务依赖图、L7 协议解析（HTTP/gRPC/Kafka/DNS）和实时监控。通过 Hubble Relay 聚合多节点数据，Hubble UI 提供可视化界面。
Cilium CLI（cilium/cilium install）：用于安装、升级、调试 Cilium 集群的命令行工具。

组件	职责	部署方式
Cilium Agent	eBPF 程序管理、策略执行、IPAM	DaemonSet（每节点）
Cilium Operator	身份管理、健康检查、IP 池协调	Deployment（1~2 副本）
CNI Plugin	容器网络接口创建	二进制文件（每节点）
Hubble Relay	多节点流数据聚合	Deployment（集群级）
Hubble UI	网络可视化	Deployment（可选）

2 eBPF 在 Cilium 中扮演什么角色？为什么选择 eBPF 而非 iptables？

答案：

eBPF（Extended Berkeley Packet Filter）是 Cilium 的核心技术基础，允许在内核沙箱中运行用户定义的程序，无需修改内核源码或加载内核模块。

eBPF 在 Cilium 中的关键作用：

数据包处理：在 XDP（网卡驱动层）和 TC（流量控制层）挂载 eBPF 程序，直接决定数据包的转发、丢弃或重定向
Service 负载均衡：替代 kube-proxy 的 iptables/IPVS 规则，通过 eBPF 实现高效 Service 后端选择（Maglev 一致性哈希）
网络策略执行：基于 Security Identity（而非 IP 地址）进行 L3/L4/L7 策略决策
可观测性：通过 eBPF 捕获网络事件、DNS 请求、HTTP 调用和系统调用

相比 iptables 的关键优势：

维度	iptables	eBPF
规则匹配	线性遍历，大规模 Service 下 O(n) 性能衰减	哈希映射（Map）查询，O(1) 性能
数据路径	多表多链，长路径多次遍历	单次 eBPF 程序执行，短路径
更新方式	每次规则变更需要整表替换，引发连接抖动	Map 原子更新，无连接断开
L7 协议	不支持原生 L7，需配合 sidecar	内核空间原生解析 HTTP/gRPC/Kafka
可观测性	无内置捕获能力	原生提供流量捕获和指标

3 Cilium 如何实现 kube-proxy 替代？

答案：

Cilium 通过 eBPF 程序完全替代 kube-proxy 的功能，实现 ClusterIP、NodePort、LoadBalancer 和 ExternalIP 的 Service 转发。

实现原理：

Cilium Agent 监听 Kubernetes Service 和 EndpointSlice 变更，通过 eBPF Map 维护 Service 到后端 Pod 的映射关系
在 XDP/TC 层挂载 eBPF 程序，根据数据包目的 IP：Port 查询 Service Map，直接重定向到后端 Pod
使用 Maglev 一致性哈希算法进行负载均衡，保证会话稳定性

配置方式：

# values.yaml
kubeProxyReplacement: "true"  # 启用完整 kube-proxy 替代
k8sServiceHost: <API_SERVER_IP>
k8sServicePort: 6443

验证命令：

cilium status | grep KubeProxyReplacement
# 输出: KubeProxyReplacement: Strict   [eth0 可直接更新 XDP/TC eBPF 程序]

优势：

无需 iptables 规则，消除大规模 Service 下的性能衰减
支持 DSR（Direct Server Return）模式，避免请求和响应路径不一致时的额外跳转
NodePort 场景下通过 eBPF 直接转发到目标 Pod，无需经过本节点 iptables DNAT
启动速度更快，规则同步无连接抖动

4 Cilium 的 Security Identity 机制是如何工作的？

答案：

Cilium 使用 Security Identity（安全身份）而非 IP 地址作为网络策略的决策依据，这是其区别于传统 NetworkPolicy 实现的核心设计。

工作流程：

身份分配：当 Pod 启动时，Cilium Agent 根据 Pod 的 Label 组合（由 Identity Selector 配置决定）计算 Identity，通过 Operator 进行全局唯一身份注册
身份存储：Identity 存储在 Cilium 的全局 eBPF Map 中，每个节点同步相关身份
策略映射：CiliumNetworkPolicy 中定义的 EndpointSelector 和 FromEndpoints 被解析为对应的 Security Identity
包标记：出站数据包通过 eBPF 程序标记 Security Identity，入站端基于该身份进行策略决策

示例 Identity 格式：

ID=1673   Labels: k8s:app=frontend, k8s:role=web
ID=4521   Labels: k8s:app=backend, k8s:role=api

核心价值：

动态适应：Pod 重建或迁移后 IP 变化不影响已有策略规则，Identity 保持不变
规模化策略：策略规则数量与 Pod IP 数量解耦，集群扩容不增加策略管理复杂度
跨节点一致性：多节点间通过 Identity 而非 IP CIDR 进行策略匹配，消除 IP 漂移问题

5 CiliumNetworkPolicy 和标准 Kubernetes NetworkPolicy 有什么差异？

答案：

CiliumNetworkPolicy（CNP）是 Cilium CRD 提供的增强版网络策略，在兼容标准 NetworkPolicy 的基础上扩展了大量功能。

能力维度	Kubernetes NetworkPolicy	CiliumNetworkPolicy
L3/L4 策略	支持（IP/CIDR/Port）	支持
L7 策略	不支持	支持（HTTP/gRPC/Kafka/DNS）
身份选择	IP 或 Label	Security Identity + Label
FQDN 规则	不支持	支持（egress 到域名）
规则方向	Ingress/Egress	Ingress/Egress + 双向
规则优先级	隐式 AND	显式 priority 字段
跨命名空间	需 namespaceSelector	原生支持
集群范围策略	不支持	CCNP（CiliumClusterWideNetworkPolicy）
ICMP/ICMPv6	不支持	支持
规则审计模式	不支持	支持（Audit Mode）

CNP 示例（L7 HTTP 策略）：

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: payment-api-policy
spec:
  endpointSelector:
    matchLabels:
      app: payment-api
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: GET
          path: "/v1/orders/.*"
        - method: POST
          path: "/v1/payments"
          headers:
          - "X-API-Version: 2"

6 Hubble 在 Cilium 生态中的定位是什么？提供了哪些能力？

答案：

Hubble 是 Cilium 的可观测性层，基于 eBPF 实现零侵入的网络安全和服务通信监控。

核心能力：

网络流监控：实时捕获节点间的网络流记录（源/目的 IP、端口、协议、Verdict）
L7 协议解析：原生解析 HTTP、gRPC、Kafka 和 DNS 协议的请求/响应内容
服务依赖图：自动生成集群内服务间通信拓扑图（通过 Hubble UI）
网络策略审计：查看哪些策略 DROP 了特定流量，验证策略有效性
DNS 监控：捕获 Pod 发出的所有 DNS 查询及响应，排查 DNS 解析问题
网络延迟分析：提供 TCP RTT（往返时间）指标，辅助诊断网络性能

架构组件：

graph LR
    A[Cilium Agent] -->|eBPF 事件| B[Hubble Observer]
    C[Hubble Relay] -->|聚合多节点数据| D[Hubble UI]
    C -->|CLI 查询| E[`hubble observe`]
    F[Prometheus] -->|抓取| A

使用示例：

# 查看所有网络流
hubble observe --from-pod default/frontend

# 查看被策略拒绝的流量
hubble observe --verdict DROPPED

# 查看 HTTP 请求详情
hubble observe --protocol http --to-namespace production

# 实时追踪特定 Pod 的 DNS 查询
hubble observe --pod default/frontend --protocol dns --follow

7 Cilium 支持哪些 Service 负载均衡算法？

答案：

Cilium 使用 Maglev 一致性哈希算法作为默认的 Service 后端选择器，同时支持随机和轮询模式。

Maglev 一致性哈希：

Google 在 2016 年论文中提出，专为大型负载均衡器设计
核心机制：将每个 Service 后端映射到大小为 65537 的哈希表中，查找时直接索引
特点：后端变化时最小化重新映射的流量（最小扰动），连接稳定的同时具备快速收敛能力
优势：相比标准一致性哈希，Maglev 的查找表填充速度更快，内存占用更低

后端选择模式：

# 通过 Service Annotation 配置
apiVersion: v1
kind: Service
metadata:
  annotations:
    service.cilium.io/lb-algorithm: "maglev"  # 默认
    # 可选: random, round_robin, maglev

DSR（Direct Server Return）模式：

请求经节点转发到后端 Pod，但响应直接从 Pod 返回客户端，不经过中间节点
消除请求和响应路径不一致的瓶颈，减少节点网络吞吐开销
在 XDP 层实现，性能接近原生转发（接近线速）

8 Cilium 的 ClusterMesh 是如何实现多集群网络互联的？

答案：

ClusterMesh 是 Cilium 的多集群互联方案，允许跨 Kubernetes 集群的 Pod 直接通信并统一管理网络策略。

架构原理：

每个集群运行独立的 Cilium 实例，通过 ClusterMesh API Server 进行集群间服务发现
使用轻量级隧道（默认 WireGuard 加密）或直接路由连接不同集群的节点网络
跨集群的 Pod IP 通过 ClusterMesh 同步到各集群的 eBPF Map 中

部署要求：

# 在每个集群的 values.yaml 中启用
cluster:
  name: cluster-1
  id: 1
clusterMesh:
  enabled: true
  config:
    clusters:
    - name: cluster-2
      domain: cluster-2.example.com

关键工作机制：

服务镜像：每个集群的 Service 在 ClusterMesh 拓扑中可见，但由本地 DNS 决定解析到哪个集群
Global Service：通过 Annotation service.cilium.io/global: "true" 标记的服务会被其他集群发现和路由访问
策略跨集群：CiliumClusterWideNetworkPolicy 可以统一应用于所有集群的端点
身份隔离：每个集群的安全身份空间独立，集群间通过 Cluster ID 前缀区分

适用场景：

跨区域应用部署，Pod 直接通信无需 API Gateway
全局负载均衡（Global Service），就近访问减少跨区域延迟
多集群统一安全策略管理

9 Cilium 的加密通信支持哪些方案？

答案：

Cilium 支持 WireGuard 和 IPsec 两种节点间加密方案，以及通过 eBPF 实现的透明加密。

WireGuard（推荐）：

使用 Linux 内核内置的 WireGuard，提供现代加密协议（ChaCha20Poly1305）
每对节点之间建立 WireGuard 隧道，节点间所有 Pod 流量自动加密
配置简单，性能开销低（约 5-10% 吞吐量损耗）
不需要额外的密钥管理基础设施

# 启用 WireGuard 加密
encryption:
  type: wireguard
  nodeEncryption: true  # 节点间所有流量加密（含 Host Network）

IPsec：

使用标准 IPsec ESP（Encapsulating Security Payload，封装安全载荷）协议
支持 AES-GCM 和 AES-CBC 加密算法
通过 eBPF 在数据路径上处理加密，避免额外的用户态上下文切换

by Pod Label 加密策略：

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: encrypt-pci-traffic
spec:
  endpointSelector:
    matchLabels:
      data-classification: pci
  egress:
  - toEntities:
    - cluster
    encrypt: {}  # 启用加密

价值：

满足 PCI-DSS、HIPAA 等合规场景的传输加密要求
零应用改造：Pod 无感知，业务无需修改代码或配置
相比服务网格 mTLS 加密，eBPF 级加密在性能开销方面显著更低

10 Cilium 的 BGP 功能是如何实现的？

答案：

Cilium 通过 CiliumBGPPeeringPolicy CRD 实现 BGP 路由发布，替代传统 BGP 组件（如 Calico 的 BIRD）。

BGP 实现原理：

Cilium Agent 内置 BGP 控制平面（基于 MetalLB 的 BGP 实现），无需额外组件
通过 CRD 声明 BGP 对等体配置，Agent 自动建立 BGP 会话并将 Service LoadBalancer IP / Pod CIDR 路由通告给网络设备
支持 BFD（Bidirectional Forwarding Detection，双向转发检测）实现 BGP 会话的快速故障检测

配置示例：

apiVersion: "cilium.io/v2alpha1"
kind: CiliumBGPPeeringPolicy
metadata:
  name: bgp-policy
spec:
  nodeSelector:
    matchLabels:
      bgp-peering: enabled
  virtualRouters:
  - localASN: 65001
    exportPodCIDR: true  # 通告 Pod 网段路由
    serviceSelector:
      matchLabels:
        svc-type: loadbalancer
    neighbors:
    - peerAddress: "10.0.0.1/32"
      peerASN: 65000
      gracefulRestart:
        enabled: true
      bfd:
        enabled: true
        minTxInterval: 300ms
        minRxInterval: 300ms

BGP 场景能力：

PodCIDR 通告：将每个节点的 Pod 网段通告给 ToR（Top of Rack，架顶交换机），实现 Underlay 直通路由
LB IP 通告：将 LoadBalancer Service 的 External IP 发布到 BGP 网络中，外部流量直接路由到集群节点
L2 Announcements：对于不支持 BGP 的网络环境，Cilium 也支持 L2 ARP/NDP 通告模式

11 Cilium 如何实现 L7（HTTP/gRPC/Kafka）协议感知策略？

答案：

Cilium 通过 eBPF 程序代理和 Envoy 代理的组合实现 L7 协议的解析和策略执行。

L7 策略执行机制：

透明代理：Cilium Agent 在每个节点上运行 Cilium Envoy 实例，当策略匹配 L7 规则时，eBPF 程序将流量重定向到本节点的 Envoy 进行协议解析
eBPF 加速：eBPF 直接解析 DNS 流量，无需经过代理，减少 DNS 策略的性能开销
协议支持：HTTP/1.1、HTTP/2、gRPC、Kafka 协议族

HTTP L7 策略示例：

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: l7-http-policy
spec:
  endpointSelector:
    matchLabels:
      app: api-service
  ingress:
  - toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: GET
          path: "/api/v1/public/.*"
        - method: POST
          path: "/api/v1/orders"
          headers:
          - "X-API-Version: 2"

Kafka L7 策略示例：

  rules:
    kafka:
    - apiKey: "produce"
      topic: "orders-events"
    - apiKey: "consume"
      topic: "orders-events"
      clientID: "order-processor"

性能考量：

纯 L3/L4 策略：完全通过 eBPF 执行，零上下文切换
L7 策略（HTTP/gRPC）：首次匹配后进入 Envoy 代理路径，增加约 0.5-2ms 延迟
DNS 策略：eBPF 直接解析，延迟增加 < 0.1ms

12 Cilium 的 IPAM 模式有哪些？如何选择？

答案：

Cilium 支持多种 IPAM（IP Address Management）模式，适应不同的网络基础设施需求。

IPAM 模式	分配方式	适用场景
Kubernetes	从 Node CIDR 分配，与 kube-controller-manager 一致	默认模式，与标准 K8s 网络兼容
ClusterPool	Cilium 从全局 CIDR 池分配，支持每个节点自定义子网大小	大规模集群，IP 灵活分配
CRD-backed	通过 CiliumNode CRD 手动指定每个节点的分配 CIDR	与外部 IPAM 系统集成
ENI（AWS）	直接分配 AWS VPC 弹性网卡 IP	AWS 环境，需要与 VPC 原生集成
Azure	分配 Azure VNET IP	Azure 环境
AlibabaCloud	分配阿里云 VPC IP	阿里云环境
Multi-Pool	多 IP 池叠加，每个池服务于特定 Pod Label	异构 IP 需求（如 GPU 节点使用独立网段）

ClusterPool 模式配置：

ipam:
  mode: cluster-pool
  operator:
    clusterPoolIPv4PodCIDRList: "10.200.0.0/16"
    clusterPoolIPv4MaskSize: 24  # 每个节点 256 个 IP

选择原则：

云原生部署（AWS/Azure/阿里云）：优先使用各云平台的原生 IPAM 模式，实现 VPC 内 Pod IP 直通
裸金属/私有云：ClusterPool 模式提供最大的灵活性
外部 IPAM 系统集成：CRD-backed 模式允许外部控制器管理 IP 分配

13 Cilium 的带宽管理功能是如何实现的？

答案：

Cilium 提供基于 eBPF 的带宽管理能力，通过 Bandwidth Manager 功能实现 Pod 级别的带宽限制和优先级调度。

实现原理：

使用 eBPF 的 EDT（Earliest Departure Time，最早发出时间）算法进行流量整形
在 TC（Traffic Control）层挂载 eBPF 程序，计算每个数据包的理想发出时间
支持 Cilium Egress 和 Cilium Ingress 两个方向的带宽限制

配置方式：

bandwidthManager:
  enabled: true
  bbr: true  # 启用 BBR TCP 拥塞控制

通过 Kubernetes Annotation 设置：

apiVersion: v1
kind: Pod
metadata:
  annotations:
    kubernetes.io/egress-bandwidth: "100M"   # 出站带宽限制
    kubernetes.io/ingress-bandwidth: "200M"  # 入站带宽限制
spec:
  containers:
  - name: app
    image: nginx

BBR 集成：Cilium 可以自动为 Pod 启用 BBR（Bottleneck Bandwidth and Round-trip propagation time，瓶颈带宽和往返传播时间）拥塞控制算法，特别适合跨区域和长距离网络连接，显著提升吞吐量并降低延迟。

14 CiliumNetworkPolicy 的 priority 字段是如何工作的？

答案：

CiliumNetworkPolicy 的 priority 字段用于定义多策略冲突时的匹配优先级，数值越小优先级越高。

优先级机制：

范围：0-65535，0 为最高优先级
当多个策略匹配同一个端点时，高优先级策略覆盖低优先级策略
相同优先级且同时匹配时，默认 Deny 优先于 Allow
不设置 priority 时，策略按默认优先级 0（最高）执行

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: deny-list
spec:
  priority: 10  # 高优先级
  endpointSelector:
    matchLabels:
      app: api
  ingress:
  - fromCIDR:
    - "10.0.0.0/8"
    deny: true  # 拒绝来自 10.0.0.0/8 的所有流量
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: allow-specific
spec:
  priority: 5  # 更高优先级，覆盖上面的 Deny
  endpointSelector:
    matchLabels:
      app: api
  ingress:
  - fromCIDR:
    - "10.0.1.0/24"
    toPorts:
    - ports:
      - port: "443"

最佳实践：

Deny 规则使用低优先级（大数值），Allow 白名单使用高优先级（小数值）
基础安全基线策略使用中等优先级，特定业务策略使用高优先级
保留 0-100 范围给关键安全策略（如全局黑名单）

15 Cilium Identity 和 CiliumEndpoint（CEP）的关系是什么？

答案：

CiliumIdentity 和 CiliumEndpoint（CEP）是 Cilium 的两个核心 CRD，共同管理 Pod 的安全身份和网络状态。

CiliumEndpoint（CEP）：

每个 Pod 对应一个 CEP 资源，命名与 Pod 相同且在同一命名空间
记录 Pod 的网络信息：IP 地址、Identity ID、节点信息、加密状态
Cilium Agent 负责实时更新 CEP

CiliumIdentity：

全局资源，不绑定到特定命名空间或节点
由 Operator 管理，根据 Pod Label 计算唯一 Identity
当 LoadBalancer IP 或外部工作负载也需要策略管理时，CiliumIdentity 也覆盖这些场景

关系示例：

# 查看 CEP
kubectl get cep -n default
# NAME          ENDPOINT ID   IDENTITY ID   IP             NODE
# frontend-x1   1234          1673          10.200.1.2     node-1

# 查看 Identity
kubectl get ciliumidentity 1673 -o yaml
# labels:
#   app: frontend
#   role: web

CiliumEndpointSlice（CES）：

大规模集群优化（500+ 节点）时启用
将多个 CEP 聚合为 CES 资源，减少 API Server 压力
通过 Cilium Agent 配置 enable-k8s-event-handover 和 CES 启用

16 Cilium 如何实现 Clusterwide NetworkPolicy（CCNP）？

答案：

CiliumClusterWideNetworkPolicy（CCNP）与 CiliumNetworkPolicy 的规则格式相同，但作用范围为整个集群，不受命名空间限制。

CCNP 的关键特性：

非命名空间资源，一个 CCNP 可以覆盖集群中所有符合条件的端点
EndpointSelector 依然使用 Label 匹配，但可以跨命名空间匹配 Pod
常用于安全基线和全局准入控制策略

CCNP 示例（全局禁止特定镜像启动并审计 DNS 查询）：

apiVersion: "cilium.io/v2"
kind: CiliumClusterWideNetworkPolicy
metadata:
  name: deny-privileged-escaping
spec:
  endpointSelector:
    matchLabels:
      "io.kubernetes.pod.namespace": "production"
  ingress:
  - fromCIDR:
    - "0.0.0.0/0"
    toPorts:
    - ports:
      - port: "53"
        protocol: UDP
      rules:
        dns:
        - matchPattern: "*"
      log: true  # 审计日志

典型用例：

基于环境 Label（env=production）的统一安全策略
关键基础设施组件（如 CoreDNS）的全局准入策略
合规审计策略（如记录所有对外 DNS 查询）
禁止特定网段访问集群（全局黑名单）

17 Cilium 的 Host Network 策略如何工作？

答案：

Cilium 支持对 Host Network（主机网络命名空间）的流量进行策略管理，覆盖节点本身的网络访问控制，而不仅限于 Pod。

Host Firewall 机制：

启用后，Cilium 在主机网络接口上挂载 eBPF 程序，控制进出主机命名空间的流量
策略匹配使用 CIDR 和 Node Label，而非 Security Identity
可以限制 SSH 访问、API Server 端口等主机级网络访问

启用配置：

hostFirewall:
  enabled: true

策略示例：

apiVersion: "cilium.io/v2"
kind: CiliumClusterWideNetworkPolicy
metadata:
  name: host-firewall
spec:
  nodeSelector:
    matchLabels:
      node-role: "worker"
  ingress:
  - fromCIDR:
    - "10.0.0.0/8"      # 内网
    toPorts:
    - ports:
      - port: "22"      # SSH
        protocol: TCP
    - ports:
      - port: "6443"    # K8s API
        protocol: TCP
  - fromCIDR:
    - "192.168.1.0/24"  # 堡垒机网段
    toPorts:
    - ports:
      - port: "22"

18 Cilium 的 Network Policy 审计模式有什么作用？

答案：

CiliumNetworkPolicy 的审计模式允许将策略设置为只记录（Audit）而不实际执行，用于安全策略的测试和验证。

配置方式：

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: audit-rule
spec:
  endpointSelector:
    matchLabels:
      app: api
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: legacy
    toPorts:
    - ports:
      - port: "8080"
  audit: true  # 审计模式：记录但不拒绝

审计模式的使用场景：

灰度上线策略：新策略先设置为审计模式，评估对现有流量的影响
合规审计：记录违反策略的流量作为安全审计日志
故障排查：临时将策略改为审计模式，确认策略是否是流量中断的原因
流量建模：了解当前集群中的通信模式，为精确策略设计提供依据

查看审计日志：

hubble observe --verdict AUDIT
# 仅查看审计模式下的策略命中记录

19 Cilium 的 NodePort 处理机制与传统方式有何不同？

答案：

Cilium 通过 eBPF 程序处理 NodePort 流量，避免了 iptables 规则链的线性遍历性能问题。

传统 iptables 模式的问题：

NodePort 流量到达节点后，iptables 需要遍历 KUBE-SERVICES → KUBE-NODEPORTS → KUBE-MARK-MASQ → KUBE-SVC-XXXX 等多条规则链
大规模集群（1000+ Service）时，DNAT 规则数量巨大，规则更新时可能引起连接重置
响应包需要经过与请求相同的节点（如果不使用 ExternalTrafficPolicy=Local）

Cilium eBPF NodePort 处理：

直接在 XDP（网卡驱动层）或 TC（流量控制层）完成 Service 查询和后端转发
通过 eBPF Map（哈希表）O(1) 查找 Service 对应的后端 Pod
支持 DSR 模式，响应直接从后端 Pod 返回客户端，无需经过入口节点

# NodePort 模式配置
nodePort:
  enabled: true
  mode: "dsr"  # 可选: "snat"（默认），"dsr"，"hybrid"

ExternalTrafficPolicy 兼容性：

Local 模式：eBPF 直接转发到本节点 Pod，保留源 IP
Cluster 模式：eBPF 根据负载均衡算法选择后端，可跨节点转发

20 Cilium 如何实现跨节点 Pod 通信？

答案：

Cilium 支持多种跨节点 Pod 通信模式：直接路由（Direct Routing）、VXLAN 隧道、Geneve 隧道和云原生 IPAM。

直接路由（默认）：

Cilium Agent 通过 BGP 或云平台 API 将 Pod CIDR 路由信息分发到各节点
数据包直接经过节点路由表转发，不经过隧道封装
性能最佳，延迟接近线速，适合高性能计算场景

VXLAN 覆盖网络：

使用 Linux VXLAN 设备封装 Pod 流量，支持跨越 L3 网络边界
通过 UDP 4789 端口传输，兼容性最好

配置对比：

模式	优势	劣势	适用场景
直接路由	性能最佳，零封装开销	需要底层网络支持 BGP 或路由同步	裸金属、公有云
VXLAN	跨 L3 网络，无需底层路由配置	封装带来 5-10% 吞吐量损耗	多子网环境
Geneve	扩展性好，支持更多元数据	需要较新的内核版本	需要丰富元数据的场景

跨节点数据路径示例（直接路由）：

Pod A (node-1: 10.200.1.2) → Pod B (node-2: 10.200.2.3)
  → veth → cilium_host → 节点路由表 → node-2 物理网卡
  → cilium_host → veth → Pod B

21 Cilium 安装和升级的方式有哪些？

答案：

Cilium 支持多种安装和升级方式，推荐使用 Helm 进行生产环境管理。

安装方式：

Helm（推荐）：

helm repo add cilium https://helm.cilium.io/
helm upgrade --install cilium cilium/cilium --namespace kube-system \
  --set kubeProxyReplacement=true \
  --set ipam.mode=cluster-pool \
  --set ipam.operator.clusterPoolIPv4PodCIDRList="10.200.0.0/16"

Cilium CLI：

cilium install --version 1.16.0 \
  --set kubeProxyReplacement=true

Cilium Operator 升级策略：

Helm upgrade 逐节点滚动升级 Cilium Agent DaemonSet
Operator Deployment 支持 podDisruptionBudget 设置最小可用副本
升级过程中已有连接不中断，eBPF Map 在 Agent 热重启时持久保留

版本升级注意事项：

跨大版本升级需要遵循官方升级文档（如 1.14→1.15 之间的特定升级步骤）
升级前通过 cilium preflight validate 验证集群兼容性
eBPF 程序的升级需要回滚旧版本 eBPF 程序再加载新版本，Cilium 自动处理此流程

22 Cilium Agent 启动失败时如何排查？

答案：

Cilium Agent 启动失败需要系统性地检查 eBPF 环境、内核配置和资源状态。

排查步骤：

1. 检查 Cilium Agent 日志：

kubectl -n kube-system logs daemonset/cilium -c cilium-agent --tail=100
# 或
kubectl -n kube-system logs -l k8s-app=cilium -c cilium-agent --tail=50

2. 运行 Cilium 健康状况检查：

cilium status  # 显示各组件健康状态
cilium sysdump  # 收集所有诊断信息（给支持团队用）

3. 检查 eBPF 可行性：

# 进入 Cilium Agent Pod
kubectl -n kube-system exec -it cilium-xxxxx -- cilium status --verbose
# 检查 eBPF 相关输出:
#   Kernel Version: 5.10.x
#   BPF: 是否已启用
#   BPF Map: min ${max} entries

4. 常见启动失败原因：

问题	排查方法	修复措施
内核版本过低	`uname -r` 检查，需要 5.10+	升级内核或启用兼容模式
eBPF 未启用	`cat /sys/kernel/security/enable_bpf`	内核启动参数 `bpf=1`
BPF 文件系统挂载失败	`mount	grep bpffs`
iptables 锁定冲突	Agent 日志显示 iptables 等待超时	配置 `--set iptables.lockTimeoutSecs=10`
MTU 不匹配	节点网卡 MTU < VXLAN 需要的最小 MTU	调整 Cilium MTU 配置 `mtu: 1400`
资源不足	Pod 状态 OOMKilled 或 CrashLoopBackOff	调整 Agent 资源限制

23 Cilium 的监控和指标暴露机制是什么？

答案：

Cilium 通过 Prometheus 格式暴露丰富的指标，覆盖 Agent、Operator、Hubble 和 eBPF Map 等多个维度。

关键指标分类：

Agent 指标：

# Agent 健康状态
cilium_agent_api_process_time_seconds  # API 处理延迟
cilium_controllers_running             # 当前运行的控制循环数
cilium_identity_count                  # 集群 Identity 总数

# 网络策略
cilium_policy_count                    # 策略规则数
cilium_policy_endpoint_enforcement_status  # 端点策略执行状态

# 数据路径
cilium_endpoint_count                  # 本地端点数
cilium_drop_count_total                # 丢包计数（按原因）
cilium_forward_count_total             # 转发计数

Operator 指标：

cilium_operator_identity_count         # 管理的 Identity 数
cilium_operator_ipam_allocation_ops    # IPAM 分配操作次数

Hubble 指标：

# 网络流指标
hubble_flows_processed_total           # 处理的网络流总数
hubble_tcp_dropped_total               # TCP 丢包数
hubble_dns_queries_total               # DNS 查询总数

集成 Prometheus：

# values.yaml
prometheus:
  enabled: true
  serviceMonitor:
    enabled: true  # 自动创建 ServiceMonitor CRD
operator:
  prometheus:
    enabled: true
    serviceMonitor:
      enabled: true
hubble:
  metrics:
    enabled:
    - dns
    - drop
    - tcp
    - flow
    - http

24 Cilium 如何处理 DNS 解析和安全策略？

答案：

Cilium 通过 eBPF 直接监听 DNS 请求和响应，实现基于 Domain Name 的网络策略（FQDN Policy）。

DNS 策略工作流程：

Cilium Agent 通过 eBPF 程序捕获 Pod 发出的 DNS 查询和响应
将 DNS 响应中解析到的 IP 地址缓存到 FQDN IP 缓存中
当 Pod 尝试访问这些 IP 时，匹配策略中定义的 FQDN 规则
DNS 缓存默认 TTL 跟随 DNS 响应中的 TTL，最大可配置

FQDN 策略示例：

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: fqdn-egress
spec:
  endpointSelector:
    matchLabels:
      app: worker
  egress:
  - toFQDNs:
    - matchName: "api.example.com"        # 精确域名
    - matchPattern: "*.trusted.io"         # 通配符匹配
    - matchPattern: "*.amazonaws.com"      # AWS 服务端点
    toPorts:
    - ports:
      - port: "443"
        protocol: TCP
  - toEndpoints:
    - matchLabels:
        "k8s:k8s-app": kube-dns
    toPorts:
    - ports:
      - port: "53"
        protocol: UDP
      rules:
        dns:
        - matchPattern: "*"                # 允许所有 DNS 查询

DNS 相关风险控制：

DNS 劫持防护：eBPF 层面的 DNS 监听可以检测 DNS 响应与策略定义的域名是否匹配，防止 DNS 欺骗
TTL 限制：maxTTL=3600s 确保缓存的 IP 地址不会过长时间固定，避免后端 IP 变更导致的访问问题

25 Cilium 在大规模集群（1000+ 节点）中有哪些性能优化措施？

答案：

Cilium 针对大规模集群设计了多项优化机制，确保控制面和数据面的稳定性。

控制面优化：

1. Typha 模式（虽然 Cilium 默认不使用 Typha，但通过 CiliumEndpointSlice 实现等效）：

CiliumEndpointSlice（CES）将多个 CEP 聚合到一个资源中
减少 API Server 的 Watch 连接数和资源变更事件数量
在 1000+ 节点集群中建议启用

# 启用 CES
ciliumEndpointSlice:
  enabled: true

2. Identity 回收和 GC：

Operator 定期扫描无效的 Security Identity 并清理
避免 Identity 空间耗尽（每个集群最多支持约 65535 个唯一 Identity）

3. Node Init 优化：

新节点加入时的 eBPF 程序加载和路由初始化异步执行，不阻塞 Pod 调度

数据面优化：

4. eBPF Map 大小预分配：

# 根据需要调整 Map 上限
bpf:
  mapDynamicSizeRatio: 0.002  # 动态 Map 大小
  preAllocateMaps: true       # 预分配 Map 条目

5. Hubble 流数据降采样：

大规模集群中 Hubble 流数据量巨大（每节点 ~10K flows/s）
配置 Hubble 流过滤规则，只保留关键流量（如 DROP 事件、DNS 查询）
使用 Hubble Flow 聚合减少存储和传输压力

6. 关键性能基线（参考 Cilium 官方测试）：

集群规模：500 节点，15000 Pod，3000 Service
网络延迟增幅：直接路由 < 5%（相对于无 CNI 时的网络延迟）
策略执行延迟：< 10μs（L3/L4），< 100μs（L7 HTTP）
Agent 内存占用：~100-200MB/节点（根据端点数量和管理策略数）

26 Cilium 的 Network Policy 如何处理 Pod 生命周期中的流量？

答案：

Cilium 在 Pod 创建和删除过程中对流量进行精细化管理，确保安全一致。

Pod 创建时的策略加载：

graph TD
    A[Pod 调度到节点] --> B[CNI 调用 Cilium 创建网络接口]
    B --> C[Agent 分配 IP 和 Identity]
    C --> D[Agent 加载 eBPF 程序到 Pod veth]
    D --> E[同步匹配该 Identity 的策略规则]
    E --> F[Pod Ready: 流量策略生效]

关键时序控制：

Agent 在 Pod 网络接口就绪后立即加载 eBPF 程序，此时策略已生效
未就绪（NotReady）状态的 Pod 默认只允许与 kube-apiserver 和 DNS 的通信
删除 Pod 时，Agent 先卸载 eBPF 程序再删除网络接口，保证删除过程中的流量不会绕过策略

Init 容器策略：

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: init-container-policy
spec:
  endpointSelector:
    matchLabels:
      app: myapp
  enableDefaultDeny:
    ingress: true
  ingress:
  - fromEndpoints:
    - matchLabels:
        "reserved:init": true  # Init 容器特殊身份
    toPorts:
    - ports:
      - port: "8080"

27 Cilium 如何支持 Egress Gateway 功能？

答案：

Cilium 的 Egress Gateway 功能允许 Pod 流量通过指定的节点（网关节点）访问外部网络，实现固定的出口 IP。

实现原理：

选择特定节点作为 Egress Gateway，在其上配置 SNAT
Pod 流量根据策略匹配自动重定向到网关节点
外部服务看到的是 Egress Gateway 节点的 IP，而非 Pod IP

配置示例：

apiVersion: "cilium.io/v2alpha1"
kind: CiliumEgressGatewayPolicy
metadata:
  name: aws-egress
spec:
  selectors:
  - podSelector:
      matchLabels:
        app: api-server
    namespaceSelector:
      matchLabels:
        env: production
  destinationCIDRs:
  - "10.100.0.0/16"       # VPC CIDR
  egressGateway:
    nodeSelector:
      matchLabels:
        node-role: "egress-gateway"
    egressIP: "192.168.1.100"  # 网关节点上的固定出口 IP

适用场景：

数据库白名单：应用 Pod 通过固定 IP 访问外部数据库
合规性要求：特定业务的出口流量必须经过审计节点
安全隔离：Egress Gateway 节点部署在独立安全组中，统一控制出口访问

28 Cilium 如何实现 L2 网络中的 LoadBalancer IP 通告？

答案：

Cilium 的 L2 Announcements 功能提供基于 ARP/NDP 协议的 LoadBalancer IP 通告，适用于不支持 BGP 的网络环境。

实现机制：

Cilium Agent 监听 LoadBalancer Service 变更，选择 Leader 节点负责响应 ARP 请求
Leader 选举基于 Leader Election 机制，保证同一 VIP 只有一个节点响应
当 Leader 节点宕机时，自动切换到备用节点

l2announcements:
  enabled: true
  leaseDuration: 15s
  leaseRenewDeadline: 10s
  leaseRetryPeriod: 2s

示例 Service：

apiVersion: v1
kind: Service
metadata:
  annotations:
    io.cilium/lb-ipam: "192.168.1.200-192.168.1.250"  # LB IP 池范围
spec:
  type: LoadBalancer
  ports:
  - port: 443
apiVersion: "cilium.io/v2alpha1"
kind: CiliumL2AnnouncementPolicy
metadata:
  name: l2-policy
spec:
  nodeSelector:
    matchLabels:
      kubernetes.io/os: linux
  externalIPs: true
  loadBalancerIPs: true
  interfaces:
  - "^eth[0-9]+"  # 接口正则匹配

与 BGP 模式的对比：

特性	L2 Announcements	BGP
协议	ARP/NDP	BGP
网络要求	L2 广播域可达	可路由到 BGP 对等体
规模限制	受广播域限制	理论上无限制
故障切换	Leader Election	BFD 或 BGP Keepalive
负载均衡	多 Service 分布在 Leader 节点上	ECMP 多路径负载均衡

29 Cilium 的 Tetragon 组件提供了哪些额外能力？

答案：

Tetragon 是 Cilium 生态中的运行时安全组件（原 Cilium Runtime Security），基于 eBPF 实现内核级别的安全监控和行为检测。

关键能力：

系统调用监控：捕捉 exec、open、connect 等系统调用事件
进程级安全策略：基于进程名称、二进制签名或路径进行策略匹配
流量侧写（Traffic Profiling）：记录每个进程的网络连接行为

Tetragon 策略示例：

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: block-non-curl-wget
spec:
  kprobes:
  - call: "sys_execve"
    syscall: true
    args:
    - index: 0
      type: "string"
    selectors:
    - matchArgs:
      - index: 0
        operator: "NotIn"
        values:
        - "/usr/bin/curl"
        - "/usr/bin/wget"
      matchActions:
      - action: Sigkill  # 阻止非 curl/wget 的 exec 调用

Hubble 与 Tetragon 的分工：

Hubble：网络层流量监控和 L7 协议解析
Tetragon：系统调用级安全监控，检测权限提升、恶意进程执行等行为

30 Cilium 的 Service Mesh 方案如何实现？

答案：

Cilium 提供基于 Envoy 代理的 Service Mesh 功能，实现 L7 流量管理、可观测性和安全能力，与传统 Istio/Linkerd 方案的关键区别在于 eBPF 加速。

Cilium Service Mesh 架构：

L7 负载均衡：通过 CiliumEnvoyConfig CRD 配置 Envoy，实现 HTTP/gRPC 流量管理
Ingress 支持：Cilium Ingress Controller 替代传统 Ingress Controller
Gateway API：原生支持 Kubernetes Gateway API

Envoy 集成方式：

Cilium 在每个节点上运行 Envoy 实例（非 sidecar 模式，减少资源开销）
eBPF 程序负责流量重定向到本节点 Envoy，避免 iptables 的流量拦截开销

# 启用 Service Mesh
l7Proxy: true
ingressController:
  enabled: true
  defaultSecretNamespace: kube-system
  defaultSecretName: cilium-ingress
gatewayAPI:
  enabled: true

Ingress 示例：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tls-ingress
spec:
  ingressClassName: cilium
  tls:
  - hosts:
    - app.example.com
    secretName: tls-secret
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-svc
            port:
              number: 8080

与 Istio 的差异：

维度	Istio	Cilium Service Mesh
数据平面	Envoy sidecar 每 Pod 注入	节点级 Envoy + eBPF 重定向
资源开销	每 Pod 1 sidecar（~50-100MB）	节点级共享 Envoy，每节点 + 少量 eBPF Map 开销
延迟提升	2-5ms（sidecar 跳转）	0.5-2ms（节点级转发）
策略一致性	Envoy 配置	eBPF + Envoy 双重策略引擎
功能覆盖度	成熟完善（mTLS、认证、熔断等）	核心功能已支持，部分高级功能待完善

31 Cilium 如何与 Prometheus 集成实现告警？

答案：

Cilium 提供完善的 Prometheus 指标暴露和预置告警规则，涵盖网络策略、数据路径、Agent 状态等关键维度。

指标暴露配置：

# values.yaml
prometheus:
  enabled: true
  serviceMonitor:
    enabled: true
    labels:
      release: prometheus-operator

核心告警规则（PrometheusRule CRD）：

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: cilium-alerts
  namespace: kube-system
spec:
  groups:
  - name: cilium
    rules:
    - alert: CiliumAgentDown
      expr: count(up{job="cilium"} == 1) by (cluster) < count(kube_node_info) by (cluster)
      for: 5m
      annotations:
        summary: "Cilium Agent 宕机"
    - alert: CiliumIdentityOverflow
      expr: cilium_identity_count > 30000
      for: 10m
      annotations:
        summary: "Identity 数量接近上限"
    - alert: HighPolicyDropRate
      expr: rate(cilium_drop_count_total{reason="Policy denied"}[5m]) > 100
      for: 5m
      annotations:
        summary: "策略拒绝流量过高"
    - alert: CiliumEndpointSyncDelay
      expr: cilium_endpoint_regeneration_time > 60
      for: 5m
      annotations:
        summary: "CEP 同步延迟过高"
    - alert: HubbleFlowLoss
      expr: rate(hubble_flows_dropped_total[5m]) / rate(hubble_flows_total[5m]) > 0.05
      for: 5m
      annotations:
        summary: "Hubble 流数据丢失率超过 5%"

32 Cilium 的 eBPF 数据路径工作流程是怎样的？

答案：

Cilium 的数据路径在 eBPF 层面分为多个 Hook 点：XDP、TC Ingress、TC Egress 和 CGroup，每个 Hook 点处理不同阶段的数据包。

出站数据路径（Pod 发送数据）：

Pod veth → TC Ingress (cilium_net) → 查找路由 → 
  → 如果目标 IP 是本地 Pod → 直接通过 veth 转发
  → 如果目标 IP 是远程节点 Pod → 
    → TC Egress (物理网卡) → 封装/路由 → 物理网卡发送
  → 如果目标 IP 是 Service IP → 
    → eBPF 查找 Service Map → 选择后端 → DNAT → 转发

入站数据路径（外部流量到达）：

物理网卡 → XDP (早期丢弃非目标流量) → 
  → TC Ingress → 查找 cilium_identity → 
  → 策略匹配 → 转发到 veth → Pod

eBPF Map 类型及用途：

eBPF Map	用途	作用域
cilium_lb4_services_v2	Service → 后端映射	全节点 Sync
cilium_ct4_global	连接跟踪（Connection Tracking）	全局
cilium_ep_to_ipcache	端点 IP → Identity 映射	全局
cilium_policy_*	策略规则缓存	本地
cilium_ipcache	IP → 节点映射	全局

关键 eBPF 程序函数：

tail_handle_ipv4：处理 IPv4 数据包的主逻辑
handle_policy：策略匹配检查
lb4_local：本地 Service 后端转发
lb4_remote：远程 Service 后端转发

33 Cilium 的 IPsec 加密实现细节是什么？

答案：

Cilium 的 IPsec 加密通过 Linux 内核的 XFRM（Transform）框架实现，由 eBPF 程序管理和触发。

加密流程：

Agent 生成加密密钥，通过 Kubernetes Secret 或 vsock 分发给各节点
在每个节点上配置 Linux XFRM 策略和状态（SPD 和 SAD）
出站时 eBPF 程序根据目的节点匹配对应的加密策略，触发 XFRM ESP 加密
入站时物理网卡接收 ESP 包后由内核 XFRM 解密，再交 eBPF 处理

# IPsec 配置
encryption:
  type: ipsec
  ipsecKeyRotationDuration: "90d"
  nodeEncryption: true

密钥轮换机制：

定期生成新密钥，通过 CiliumNode 状态分发到各节点
轮换期间新旧密钥同时有效，保证连接不断
Agent 负责协调密钥轮换时序，避免节点间密钥不一致

IPsec vs WireGuard 对比：

维度	IPsec	WireGuard
内核支持	XFRM 框架（2.6+）	5.6+
协议	ESP/AH	Noise Protocol
加密算法	AES-GCM/CBC	ChaCha20Poly1305
密钥管理	Cilium Agent 轮换	WireGuard 内核接口
CPU 开销	较高（SA 查找 + ESP 处理）	较低
配置复杂度	较高（策略和状态配置）	简单

34 Cilium 和 Calico 的核心差异是什么？

答案：

Cilium 和 Calico 是 Kubernetes 生态中两种主流的 CNI 方案，设计理念和技术路线有本质区别。

对比维度	Cilium	Calico
核心技术	eBPF（扩展伯克利包过滤器）	iptables + BGP（传统 Linux 网络栈）
数据平面	eBPF XDP/TC（内核编程）	iptables/ipset + 内核路由
网络策略	Security Identity + L7 协议解析	IP + Label + iptables
Service LB	原生 kube-proxy 替代（Maglev DSR）	依赖 kube-proxy 或 eBPF 模式
可观测性	Hubble（内置流捕获/ DNS / L7）	无内置可观测性，依赖外部工具
L7 策略	原生 HTTP/gRPC/Kafka 支持	需 Istio 等 sidecar 方案
多集群	ClusterMesh	Calico Enterprise 或 Fed
BGP	内置 Agent （无 BIRD）	BIRD 独立组件
加密	WireGuard / IPsec（内核级）	WireGuard（eBPF 模式）
性能	eBPF O(1) 查找，大规模优势显著	iptables O(n)，小规模无差异
内核依赖	5.10+ 推荐	3.10+（标准模式）
学习曲线	陡峭，需要理解 eBPF 概念	平缓，与传统网络理念一致

选型建议：

选 Cilium：需要 L7 策略、大规模集群（500+ 节点）、需要内置可观测性、新集群建设
选 Calico：内核版本较低、网络团队熟悉 BGP/iptables、小规模集群、需要快速上手运维

35 Cilium 在裸金属环境中部署的最佳实践是什么？

答案：

裸金属环境中 Cilium 部署需要针对物理网络特性和性能要求进行专项优化配置。

网络模式选择：

# 裸金属推荐配置
routingMode: "native"     # 直接路由模式，无隧道封装
kubeProxyReplacement: "true"  # 完整替代 kube-proxy
autoDirectNodeRoutes: true    # 自动配置节点直连路由
ipv4NativeRoutingCIDR: "10.200.0.0/16"  # Pod CIDR 直接路由

性能优化配置：

# eBPF 优化
bpf:
  preAllocateMaps: true
  masquerade: true               # BPF 伪装替代 iptables
  tproxy: true                   # BPF 透明代理

# XDP 优化
devices: eth0,eth1               # 明确指定数据面网卡
loadBalancer:
  mode: "dsr"                    # Direct Server Return
  acceleration: "native"         # XDP 硬件卸载

# BGP 路由通告
bgpControlPlane:
  enabled: true

BGP 与 ToR 交换机集成：

配置 CiliumBGPPeeringPolicy 将 Pod CIDR 和 LB IP 通告到物理交换机
使用 BFD 实现 300ms 级别的故障检测
每个拓扑机架（ToR）作为 BGP 对等体

硬件与内核要求：

内核版本：5.15+（推荐 6.x）
网卡要求：支持 XDP 硬件卸载（Mellanox/Intel 1000 系列以上）
MTU 配置：物理网卡 MTU 设置为 9000（Jumbo Frame）时，Cilium MTU 应为 8950
NUMA 亲和性：配置 calico-node 或 cilium-agent 的 CPU 亲和性，避免跨 NUMA 节点网络中断

运维工具：

# 裸金属环境关键验证
cilium status --verbose          # 检查 eBPF、XDP、kube-proxy 状态
cilium bpf lb list               # 查看 Service 映射表
cilium encrypt status            # 查看加密状态
cilium connectivity test         # 端到端连通性测试
hubble observe --drop            # 监控丢包事件