使用Kubernetes设备插件和RuntimeClass的入口控制器中的硬件加速SSL / TLS终止

作者: Mikko Ylinen(Intel)

抽象

Kubernetes入口是一种将集群服务连接到集群外部的方法。为了 为了将流量正确路由到服务后端,群集需要一个Ingress控制器。的 入口控制器负责根据以下信息为后端设置正确的目的地 入口API对象的信息。实际流量是通过代理服务器路由的, 负责负载平衡和SSL / TLS之类的任务(后来的SSL指SSL 或TLS)终止。 SSL终止是由于加密操作而导致的CPU繁重操作 参与。要从CPU上卸载一些CPU密集型工作,请使用基于OpenSSL的代理 服务器可以利用OpenSSL Engine API和专用加密硬件的优势。这释放 CPU会为其他事情循环运行,并提高了代理服务器的整体吞吐量。

在这篇博客文章中,我们将展示使硬件加速加密变得容易的事情 使用最近创建的一些Kubernetes运行Ingress控制器代理的容器 构建块:设备插件框架和RuntimeClass。最后,给出了参考设置 使用基于HAproxy的Ingress控制器,该控制器通过Intel®QuickAssist Technology卡加速。

关于代理,OpenSSL引擎和加密硬件

代理服务器在Kubernetes Ingress Controller功能中起着至关重要的作用。它代理 每个Ingress对象路由的后端流量。在高流量负载下,性能 变得至关重要,尤其是在代理涉及CPU密集型操作(例如SSL加密)的情况下。

OpenSSL项目提供了广泛采用的用于实现SSL协议的库。的 Kubernetes Ingress控制器使用的常用代理服务器,Nginx和HAproxy的使用 OpenSSL。 CNCF毕业的Envoy代理使用BoringSSL,但似乎有 社区利益 使用OpenSSL作为替代 为此。

OpenSSL SSL协议库依赖于实现加密功能的libcrypto。 在相当长的一段时间内(在0.9.6版本中首次引入),OpenSSL提供了 发动机 concept 允许将这些加密操作卸载到专用加密中 加速硬件。后来,特别 动态 引擎启用了特定于加密硬件 可以在独立的可加载模块中实现的模块,可以在模块外部开发 OpenSSL代码库和单独分发。从应用程序的角度来看,这也是 非常理想,因为他们不需要了解如何使用硬件以及硬件的详细信息 当硬件可用时,可以加载/使用特定的模块。

基于硬件的基于硬件的加密可以极大地提高云应用程序的性能 讨论过的SSL操作中的加速处理,并可以提供其他加密 密钥/随机数生成之类的服务。云可以使硬件轻松可用 使用动态ENGINE并存在几种可加载模块实现,用于 example, 云HSM, IBMCA, 要么 QAT引擎.

对于云部署,理想的方案是将这些模块作为 容器工作量。工作负载将安排在提供以下功能的节点上 模块需要访问的基础硬件。另一方面,工作量 无论加密加速如何,都应以相同的方式运行且无需修改代码 硬件是否可用。 OpenSSL动态引擎启用了此功能。图1 以典型的Ingress Controller容器为例说明了这两种情况。 红色框表示带有加密硬件的容器之间的区别 支持引擎的容器与“标准”容器。值得指出的是 显示的更改不一定需要容器的另一个版本,因为配置 例如可以使用ConfigMaps进行管理。

图1. Ingress控制器容器的示例

图1. Ingress控制器容器的示例

硬件资源和隔离

为了能够部署具有硬件依赖性的工作负载,Kubernetes提供了出色的扩展 和可配置性机制。让我们仔细看看Kubernetes 设备插件框架(1.14中的beta)和 运行时类 (1.14中的beta版),并了解如何利用它们公开加密货币 硬件到工作负载。

设备插件框架(最早在Kubernetes 1.8中引入)为硬件供应商提供了一种方法 向Kubelets注册和分配节点硬件资源。插件实现硬件 具体的初始化逻辑和资源管理。吊舱可以在以下位置请求硬件资源 他们的PodSpec,这也可以确保将Pod安排在可以提供这些资源的节点上。

容器的设备资源分配非常重要。对于涉及安全性的应用, 硬件级别的隔离至关重要。基于PCIe的加密加速设备功能可以 通过I / O内存管理单元(IOMMU)从IO硬件虚拟化中受益,以提供 the isolation: an IOMMU集团 设备所属的设备为工作负载提供隔离的资源 (假设加密卡不与其他设备共享IOMMU组)。隔离数 如果PCIe设备支持单根I / O虚拟化,则可以进一步增加资源 (SR-IOV)规范。 SR-IOV允许将PCIe设备进一步拆分为 虚拟功能 (VF), derived from 身体机能 (PF)设备,每个设备都属于自己的IOMMU组。揭露 将这些IOMMU隔离的设备功能绑定到用户空间和容器,主机内核应绑定 它们到特定的设备驱动程序。在Linux中,此驱动程序是vfio-pci,它使每个设备 可通过用户空间中的字符设备获得。内核vfio-pci驱动程序提供用户空间 使用IOMMU支持的机制直接访问PCIe设备和功能的应用程序 called PCI直通。用户空间框架可以利用该接口,例如 数据平面开发套件(DPDK)。此外,虚拟机(VM)管理程序可以提供 这些用户空间设备节点连接到VM,并将它们作为PCI设备公开给来​​宾内核。 假设来自来宾内核的支持,VM将接近本机性能直接访问 基础主机设备。

要将这些设备资源发布给Kubernetes,我们可以有一个简单的Kubernetes设备插件 that runs 的 initialization (i.e., binding), calls kubelet’s Registration gRPC service, and implements 的 DevicePlugin gRPC service that kubelet calls to, e.g., to Allocate 的 resources upon Pod creation.

设备分配和Pod部署

此时,您可能会问容器可以对VFIO设备节点做什么?答案来了 在我们首先快速浏览了Kubernetes 运行时类之后。

创建Kubernetes 运行时类是为了提供更好的控制和可配置性 over a variety of 运行时 (更早 博客文章 深入了解需求, 状态和路线图)。本质上,RuntimeClass 为集群用户提供了更好的工具来选择和使用最适合Pod用例的运行时。

兼容OCI Kata容器运行时 通过虚拟化的硬件为工作负载提供支持 隔离层。除了工作负载隔离之外,Kata Containers VM还添加了 side benefit that 的 VFIO devices, as Allocate’d by 的 device plugin, can be passed 直到作为硬件隔离设备的容器。唯一的要求是 Kata Containers内核已为裸露设备启用了驱动程序。

这就是为容器工作负载启用硬件加速加密所需的全部内容。总结一下:

  1. 群集需要在提供硬件的节点上运行的设备插件
  2. 设备插件使用VFIO驱动程序将硬件暴露给用户空间
  3. Pod在PodSpec中请求设备资源和Kata容器作为RuntimeClass
  4. 该容器具有硬件适配库和OpenSSL引擎模块

图2显示了使用前面说明的Container A的总体设置。

图2.部署概述

图2.部署概述

参考设置

最后,我们描述了构建功能的必要构建基块和步骤 图2中描述的设置可以启用硬件加速的SSL终止 使用英特尔®QuickAssist Technology(QAT)PCIe设备的入口控制器。 应该注意的是,用例不仅限于Ingress控制器,还包括 任何基于OpenSSL的工作负载都可以加速。

集群配置:

  • Kubernetes 1.14 (运行时类 and DevicePlugin feature gates enabled (both are true in 1.14)
  • 运行时类准备好运行时并配置了Kata容器

主机配置:

  • 英特尔®QAT驱动程序版本,同时为主机内核和Kata Containers内核(或在rootfs上作为可加载模块)安装了内核驱动程序
  • QAT设备插件 部署DaemonSet

入口控制器配置和部署:

  • 代理人 修改后的容器中的入口控制器
    • QAT HW HAL用户空间库(英特尔®QAT SW版本的一部分)和
    • OpenSSL QAT引擎 内置
  • Haproxy-inress ConfigMap启用QAT引擎使用
    • ssl-engine=”qat”
    • ssl-mode-async=true
  • Haproxy-ingress deployment .yaml to
    • Request qat.intel.com: n resources
    • Request runtimeClassName: kata-containers (name value depends on cluster config)
  • (容器中可用的配置了OpenSSL引擎的每个请求的设备资源的QAT设备配置文件)

一旦有了构建块,就可以按照以下步骤测试硬件加速的SSL / TLS: TLS终止 example steps. In order to verify 的 hardware is used, you can check /sys/kernel/debug/*/fw_counters files on host as 的 y 通过英特尔®QAT固件进行更新。

使用Haproxy-inress和HAproxy是因为可以将HAproxy直接配置为使用OpenSSL引擎, ssl-engine <name> [algo ALGOs] 配置标志,无需修改全局openssl配置文件。 Moreover, HAproxy can offload configured algorithms using asynchronous calls (with ssl-mode-async) to further improve performance.

呼吁采取行动

在这篇博客文章中,我们展示了如何使用Kubernetes设备插件和RuntimeClass提供隔离的硬件 访问Pod中的应用程序,以将加密操作转移给硬件加速器。可以使用硬件加速器 加快加密操作,并节省CPU周期执行其他任务。我们已经使用HAproxy演示了设置 通过OpenSSL支持异步加密卸载。

我们团队的下一步是对Envoy重复相同的步骤(内置基于OpenSSL的TLS传输套接字 作为扩展)。此外,我们正在努力使Envoy能够 卸载BoringSSL异步 私钥操作 到加密加速硬件。任何评论反馈或帮助表示赞赏!

将加密处理卸载到专用加速器时,您的加密应用程序可以为其他任务节省多少个CPU周期?