Cilium eBPF 网络策略怎样同时覆盖服务与节点

Cilium eBPF 网络策略要同时覆盖服务与节点，关键不是把两个名字写进同一段 YAML，而是先分清三个作用域：工作负载由 endpointSelector 选中，Service 由 toServices 引用，主机侧节点由 CiliumClusterwideNetworkPolicy.nodeSelector 选中。Pod 与节点之间的流量关系，还可以用 fromNodes 或 toNodes 表达。

官方地址：https://docs.cilium.io/

下面按“从仅 Pod 规则扩展到服务与节点范围”的变更单来组织，示例是配置说明，不把静态图或 YAML 当作已在本机执行的结果。

先把服务范围和节点范围拆开

第一步先画清对象关系。CiliumNetworkPolicy 通常在命名空间内工作，endpointSelector 负责选中被保护的 Pod；出站访问某个 Kubernetes Service 时，使用 toServices，它可以按命名空间加服务名引用，也可以按 Service 标签选择。

Service 没有 selector 时，Cilium 会按 EndpointSlice 中发现的地址处理，这和“按 Pod 标签选择后端”不是同一条语义。因此迁移时要把 Service 的身份、后端发现方式和端口限制分开记录。

用 toServices 限定工作负载能访问的服务

例如只允许 checkout 工作负载访问 payments/payment-api 的 HTTPS 端口，可以把 Service 引用和四层端口限制写在同一条 egress 规则里：

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: checkout-to-payment-api
  namespace: shop
spec:
  # 只选中 shop 命名空间中带 app=checkout 的工作负载
  endpointSelector:
    matchLabels:
      app: checkout
  egress:
  - toServices:
    - k8sService:
        # Service 的命名空间和名称是服务身份
        serviceName: payment-api
        namespace: payments
    toPorts:
    - ports:
      - port: "443"
        protocol: TCP  # 只放行 HTTPS 对应的 TCP 端口

如果一组服务使用共同标签，可以改用 k8sServiceSelector。不要把 toServices 误写成“固定某个 ClusterIP”；它表达的是 Service 选择，后端变化由 Cilium 观察到的服务对象和 EndpointSlice 关系承接。

节点策略不是 Service 选择器的别名

节点相关需求又分两种。若问题是“哪些节点上的流量可以到达某个 Pod”，可以在 CiliumNetworkPolicy 的 ingress/egress 中使用 fromNodes 或 toNodes。这类规则仍然围绕 Pod endpoint 生效，并且需要启用节点选择标签能力；节点标签写错时，策略不会因为 Service 名称正确而自动命中。

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-from-control-plane
  namespace: shop
spec:
  # 保护 API Pod，而不是选择 Kubernetes Service
  endpointSelector:
    matchLabels:
      app: api
  ingress:
  - fromNodes:
    - matchLabels:
        # 节点标签是节点关系的选择条件
        node-role.kubernetes.io/control-plane: ""
    toPorts:
    - ports:
      - port: "8443"
        protocol: TCP  # 示例只限制 API 的入口端口

如果需求已经变成“限制节点本身的主机网络”，就不要继续堆叠 fromNodes。Cilium 的 Host Policy 使用 CiliumClusterwideNetworkPolicy，用 nodeSelector 选择节点，再对 Host endpoint 配置 L3/L4 规则。它与 Pod 间通信、Pod 访问集群外部的规则边界不同。

主机网络策略要单独准备运行前提

主机策略的配置入口通常还需要在安装 Cilium 时启用 Host Firewall，并明确要接管的网络设备。下面只展示资源形状，实际部署前要按官方安装参数补齐设备配置：

apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: protect-ssh-nodes
spec:
  # cluster-scoped 资源用 nodeSelector 选择目标节点
  nodeSelector:
    matchLabels:
      node-access: ssh
  ingress:
  - fromEntities:
    - cluster  # 允许集群内实体进入主机策略范围
  - toPorts:
    - ports:
      - port: "22"
        protocol: TCP  # 仅示意主机侧允许的 SSH 端口

这份规则和前面的 Service egress 可以并存，但它们回答的是不同问题：前者限制工作负载到服务的访问，后者限制匹配节点的 Host endpoint。若把主机策略误当成 Pod 策略，常见结果是节点端口仍未受控，或者排查时只看到了命名空间内的 CiliumNetworkPolicy。

迁移回归清单：先确认作用域，再确认命中对象

最后可以把配置拆成三份变更记录：工作负载到 Service 的 egress、节点到 Pod 的 from/toNodes，以及节点 Host endpoint 的主机策略。这样既能保留 eBPF 策略的精确范围，也能让后续排查快速定位到底是服务发现、节点标签还是主机防火墙边界出了问题。

相关问题

toServices 能直接选择没有 selector 的 Service 吗？

可以引用该 Service，但 Cilium 会按其 EndpointSlice 地址处理；不要把这种规则理解为按后端 Pod 标签筛选。

fromNodes 和 nodeSelector 有什么区别？

fromNodes/toNodes 描述 Pod 流量与节点之间的关系；nodeSelector 是 CiliumClusterwideNetworkPolicy 选择主机策略目标节点的入口。

为什么 Service 规则生效，节点 SSH 规则却没有效果？

两者的执行边界不同。优先检查 Host Firewall、设备配置、节点标签和 Host endpoint，而不是反复修改 toServices。