编者注：截止 2021 年 5 月 10 日， GKE Dataplane V2 已正式可用于 GKE 版本 1.20.6-gke.700 及后续版本。随着 Dataplane V2 的发布， Kubernetes Network Policy logging 也已在 Google Kubernetes Engine (GKE)  正式可用。

Kubernetes 真正的“超能力”之一在于其以开发者为先的网络连接模型。它提供了大量易于使用的功能（如 L3/L4 service以及 L7 Ingress），可在让网络流量进入集群的同时通过网络策略隔离不同租户的工作负载。随着越来越多的企业开始采用 Kubernetes ，使用范围不断扩大，用户围绕多云、安全性、可见性以及可扩展性提出了新的要求。此外，诸如服务网格  (Service Mesh)  和无服务器等新技术要求在 Kubernetes 基础层上进行更多定制。这些新要求有一个共同点：需要一种可编程能力更强的数据平面，借此在不牺牲性能的前提下执行可被 Kubernetes 感知的数据包操作。

欢迎使用 Extended Berkeley Packet Filter (eBPF) ， 这是一种全新 Linux 网络连接模型，能将可编程的钩子暴露给 Linux 内核内部的网络栈。无需在用户空间和内核空间来回跳跃，这样的能力可以用极高速度实现网络数据包的上下文感知操作。

今天，我们正式推出了 GKE Dataplane V2 ，这是一种能充分发挥 eBPF 和 Cilium 威力的数据平面，也是一种通过 eBPF 让 Linux 内核能够感知 Kubernetes 的开源项目。同时我们还会借助 Dataplane V2 让 Google Kubernetes Engine (GKE)  支持 Kubernetes Network Policy logging 。


eBPF 和 Cilium 是什么？


eBPF 是一种革命性的技术，可在无需重新编译内核或加载内核模块的前提下，在 Linux 内核中运行沙盒化的程序。为解决某些问题，以往只能更改内核或内核模块，而过去几年里， eBPF 已成为解决此类问题的标准化方法。此外， eBPF 还在网络连接、安全、应用程序性能分析等领域催生了一种全新的工具开发方法。这些工具不再依赖现有内核功能，而是可以主动对运行时的行为进行重编程，同时这一切完全不会影响程序执行效率或安全性。

Cilium 是一个以 eBPF 为基础设计的开源项目，旨在解决容器化工作负载在可扩展性、安全性和可见性等方面提出的新要求。Cilium 远超传统 Container Networking Interface  (CNI)  的能力，提供了服务解析 (Service resolution)、策略实施等功能，详见下图所示。

在 Cilium 项目的启动方面， Cilium 社区投入了大量精力，这也是目前 Kubernetes 领域最成熟的 eBPF 实现。 Google 也在积极为 Cilium 项目做贡献，借此整个 Kubernetes 社区均能充分利用我们在 eBPF 领域取得的成果。


使用 eBPF 构建 Kubernetes Network Policy Logging


让我们通过一个具体应用，一起看看 eBPF 如何解决一位真实客户所遇到的痛点。注重安全性的客户会使用 Kubernetes 网络策略来声明 Pod 之间如何相互通信。然而无法通过可扩展的方式对这些策略的行为进行排错和审核，这进一步阻碍了企业客户对相关技术的采用。随着 GKE 开始支持 eBPF ，我们已经可以支持实时策略实施，并将策略操作（允许/拒绝）关联给特定 Pod 、名称空间和策略名称，同时还能将对节点 CPU 和内存资源的影响降至最低。

上图所示的一个高度专业化的 eBPF 程序已安装到 Linux 内核中，借此强制实施网络策略并上报操作日志。随着数据包抵达虚拟机，内核中安装的这个 eBPF 程序会决定如何对数据包进行路由。与 IPTables 不同， eBPF 程序可以访问与 Kubernetes 有关的元数据，包括网络策略信息。借此，该程序不仅可以允许或拒绝数据包，还能将包含注解的操作回报给用户空间。这些事件使得我们能够生成对 Kubernetes 用户有更多意义的网络策略日志。例如，从下文所示的日志片段中可以看出，哪些源 Pod 正试图连接哪些目标 Pod，以及具体是哪条网络策略允许了该操作。

原理方面， Network Policy logging 利用了 GKE Dataplane V2 。 GKE Dataplane V2 不仅提供了策略日志所需的信息，还针对用户完全抽象了所实施网络策略的配置细节。也就是说，在使用 Dataplane V2 时，用户不再需要考虑是否要明确启用网络策略或为 GKE 集群选择使用网络策略所需的正确 CNI 。这使得 Kubernetes 变得更加易用！

除了网络策略， Kubernetes 负载均衡也可以使用 eBPF 实现 Direct Server Return  (DSR)  模式。 DSR 避免了在使用 Kubernetes LoadBalancer 服务时导致客户端 IP 地址丢失的附加 NAT 问题。 eBPF 能够即时将元数据编码到网络数据包中，借此我们可以为目标节点提供更多信息，使其能直接与原客户端交流。在 DSR 的帮助下，我们还能降低每个节点的带宽要求，并避免端口耗尽。

eBPF 能够使用自定义元数据扩充网络数据包，这也能催生出大量全新用例。我们与您一样，都对 Kubernetes 和 eBPF 的未来感到兴奋，敬请期待这方面的更多创新。


您如何从中获益


企业始终在设法改善安全态势，希望对自己的基础架构获得更深入的可见性。他们希望能快速识别异常流量模式，例如 Pod 产生了意料外的互联网通信，或者拒绝服务攻击等。借助 Kubernetes Network Policy logging 功能，您现在可以在 Cloud Logging 控制台直接查看所有允许和拒绝的网络连接，借此对策略问题进行排错并发现可疑的网络活动。


“在 K8S 中实施网络策略是个很麻烦的任务，需要大量的猜测和反复试验，因为需要尽可能了解应用程序在网络连接方面所表现出的各种行为。此外，很多合规与监管框架需要以控制配置和违规日志的形式提供有关防御态势的相关证据。在 GKE Network Policy Logging 的帮助下，我们可以快速隔离并解决问题，并在审计期间提供所需证据。这大幅简化了网络策略的实施和操作。”—— Credit Karma


如果希望自行尝试 Kubernetes Network Policy logging ，请使用下列命令新建一个基于 Dataplane V2 的 GKE 集群。 

  gcloud container clusters create <cluster-name>

    --enable-dataplane-v2

    --enable-ip-alias

    --release-channel rapid

    {--region region-name | --zone zone-name}


文章信息

相关推荐