eBPF赋能！ Kubernetes网络策略精细化管控之道

背景：传统Kubernetes网络策略的局限性？

各位 K8s 运维老铁，有没有遇到过这种场景？明明配置了 NetworkPolicy，集群内部服务间的访问还是“畅通无阻”，该禁止的流量照样进出，让人防不胜防。这其实暴露了传统 Kubernetes 网络策略的一些局限性：

1. 基于IP/端口的粗粒度控制：NetworkPolicy 主要依赖 IP 地址、端口和协议进行流量过滤。在云原生环境下，Pod 的 IP 地址经常变化，基于 IP 的策略维护成本高，且容易出错。
2. 缺乏应用层感知能力：NetworkPolicy 无法识别 HTTP 的 URI、Header 等应用层信息，难以实现更精细的访问控制，例如禁止某个 Pod 访问特定 URI。
3. 性能瓶颈：大规模集群中，大量的 NetworkPolicy 规则会显著增加 kube-proxy 的负担，影响网络性能。

那么，如何突破这些限制，实现更灵活、高效、安全的 Kubernetes 网络策略呢？eBPF (extended Berkeley Packet Filter) 闪亮登场！

eBPF：网络策略的瑞士军刀

eBPF 最初是 Linux 内核中用于网络包过滤和监控的技术，现在已经发展成为一个强大的可编程框架，可以在内核运行时动态地注入和执行用户定义的代码。这使得 eBPF 能够实现：

• 高性能的网络包处理：eBPF 程序运行在内核态，可以直接访问网络包数据，避免了用户态和内核态之间的数据拷贝，大大提高了网络处理效率。
• 细粒度的流量控制：eBPF 可以解析网络包的各个层次，包括 TCP/UDP 头部、HTTP 头部等，从而实现基于应用层信息的访问控制。
• 动态策略更新：eBPF 程序可以动态加载和卸载，无需重启内核或 Kubernetes 组件，方便策略更新和维护。

将 eBPF 应用于 Kubernetes 网络策略，可以带来以下优势：

1. 基于服务身份的访问控制：eBPF 可以结合 Kubernetes 的 Service Account、Namespace 等概念，实现基于服务身份的访问控制，例如只允许特定 ServiceAccount 的 Pod 访问某个服务。
2. 应用层策略：通过解析 HTTP 头部，eBPF 可以实现基于 URI、Header 等信息的访问控制，例如禁止某个 Pod 访问特定 URI 或修改请求 Header。
3. 增强的网络监控和审计：eBPF 可以收集网络流量的各种指标，例如延迟、丢包率等，并生成详细的审计日志，帮助我们了解网络行为并及时发现安全问题。

实战：使用 Cilium 实现 eBPF 网络策略

Cilium 是一个基于 eBPF 的 Kubernetes 网络和安全解决方案，它提供了强大的网络策略功能，可以实现上述各种高级特性。

安装 Cilium

首先，我们需要安装 Cilium。官方文档提供了详细的安装指南，这里不再赘述。推荐使用 Helm 进行安装，方便快捷。

定义 CiliumNetworkPolicy

Cilium 使用 CiliumNetworkPolicy (CNP) CRD (Custom Resource Definition) 来定义网络策略。CNP 提供了比 Kubernetes NetworkPolicy 更丰富的配置选项。

下面是一个简单的 CNP 示例，它只允许来自 frontend Namespace 的 Pod 访问 backend Namespace 中的 Pod：

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-frontend-to-backend
spec:
  endpointSelector:
    matchLabels:
      app: backend
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      fromNamespaces:
        - matchLabels:
            name: frontend

这个 CNP 的关键字段解释如下：

• endpointSelector：指定策略应用的目标 Pod，这里选择所有具有 app: backend 标签的 Pod。
• ingress：定义入站流量规则。
• fromEndpoints：指定允许访问目标 Pod 的源 Pod，这里选择所有具有 app: frontend 标签的 Pod。
• fromNamespaces：进一步限制源 Pod 必须位于 frontend Namespace 中。

应用层策略示例

Cilium 还支持应用层策略，例如基于 HTTP URI 的访问控制。下面的 CNP 示例只允许来自 frontend Namespace 的 Pod 访问 backend Namespace 中 Pod 的 /api/v1/users URI：

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-frontend-to-backend-api
spec:
  endpointSelector:
    matchLabels:
      app: backend
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      fromNamespaces:
        - matchLabels:
            name: frontend
      toPorts:
        - ports:
            - port: "80"
              protocol: TCP
          rules:
            http:
              - method: GET
                path: "/api/v1/users"

这个 CNP 的关键字段解释如下：

• toPorts：指定允许访问的目标端口和协议，这里选择 80 端口和 TCP 协议。
• rules.http：定义 HTTP 规则，这里只允许 GET 方法访问 /api/v1/users 路径。

验证策略

应用 CNP 后，可以使用 cilium policy get 命令查看策略是否生效。

cilium policy get allow-frontend-to-backend

还可以使用 cilium monitor 命令实时监控网络流量，验证策略是否按照预期工作。

高级技巧：Cilium Hubble 实现可视化监控

除了强大的网络策略功能，Cilium 还提供了 Hubble，一个基于 eBPF 的网络可观测性工具。Hubble 可以实时监控 Kubernetes 集群中的网络流量，并提供可视化的界面，帮助我们了解网络行为、排查网络问题。

安装 Hubble

Hubble 可以通过 Helm 安装：

helm install hubble --namespace kube-system cilium/hubble

使用 Hubble UI

安装完成后，可以通过 cilium hubble ui 命令启动 Hubble UI。在 UI 界面上，可以看到集群中各个 Pod 之间的网络流量关系，以及策略生效情况。

Hubble UI 还提供了强大的过滤功能，可以根据 Namespace、Pod、Service、HTTP 方法、URI 等条件过滤流量，方便我们快速定位问题。

总结与展望

eBPF 为 Kubernetes 网络策略带来了革命性的变化，它使得我们可以实现更精细、更高效、更安全的网络访问控制。Cilium 作为 eBPF 在 Kubernetes 领域的代表性项目，提供了强大的网络策略和可观测性功能，值得我们深入研究和应用。

当然，eBPF 也存在一些挑战，例如学习曲线较陡峭、调试困难等。但随着 eBPF 技术的不断发展和完善，相信这些问题会逐步得到解决。

未来，eBPF 将在 Kubernetes 网络安全领域发挥越来越重要的作用，为云原生应用保驾护航。