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

作者：Mikko Ylinan（英特尔）

摘要

Kubernetes入口（Ingress）是一种将集群服务连接到集群外部的方法。为了正确地将流量路由到服务后端，集群需要一个入口控制器。Ingress控制器负责根据Ingress API对象的信息为后端设置正确的目的地。实际流量通过代理服务器路由，代理服务器负责诸如负载平衡和SSL/TLS（稍后的“SSL”指SSL或TLS）终止等任务。由于涉及加密操作，SSL终止是一个CPU密集型操作。为了从CPU中卸载一些CPU密集型工作，基于OpenSSL的代理服务器可以利用OpenSSL引擎API和专用加密硬件的优势。这将为其他事情释放CPU周期，并提高代理服务器的总体吞吐量。

在这篇博客文章中，我们将展示使用最近创建的Kubernetes构建块（设备插件框架和RuntimeClass）为运行Ingress控制器代理的容器提供硬件加速加密是多么容易。最后，给出了一个参考设置使用基于HAproxy的入口控制器加速使用英特尔®QuickAssist技术卡。

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

代理服务器在Kubernetes入口控制器功能中起着至关重要的作用。它将流量代理到每个入口对象路由的后端。在高流量负载下，性能变得至关重要，特别是当代理涉及到诸如SSL加密之类的CPU密集型操作时。

OpenSSL项目为实现SSL协议提供了广泛采用的库。Kubernetes入口控制器使用的常用代理服务器中，Nginx和HAproxy使用OpenSSL。CNCF毕业项目Envoy使用BoringSSL，但是社区似乎也有兴趣使用OpenSSL作为替代。

https://github.com/envoyproxy/envoy/pull/5161#issuecomment-446374130

OpenSSL SSL协议库依赖于实现加密功能的libcrypto。很长一段时间以来（在0.9.6版本中首次引入），OpenSSL提供了一个引擎概念，允许将这些加密操作卸载到专用的加密加速硬件。后来，一个特殊的动态引擎使加密硬件的特定部分能够在一个独立的可加载模块中实现，该模块可以在OpenSSL代码库之外开发并单独分发。从应用程序的角度来看，这也是理想的，因为他们不需要知道如何使用硬件的细节，并且当硬件可用时，可以加载/使用特定于硬件的模块。

https://github.com/openssl/openssl/blob/master/README.ENGINE

如前所述，由于SSL操作中的硬件加速处理，基于硬件的加密可以极大地提高云应用程序的性能，并且可以提供密钥/随机数生成等其他加密服务。云可以使用动态引擎轻松地提供硬件，并且存在几种可加载模块实现，例如CloudHSM、IBMCA或QAT引擎。

对于云部署，理想的场景是将这些模块作为容器工作负载的一部分交付。工作负载将在提供模块需要访问的底层硬件的节点上调度。另一方面，不管加密加速硬件是否可用，工作负载都应该以相同的方式运行，并且不需要修改代码。OpenSSL动态引擎支持这一点。下面的图1以一个典型的Ingress Controller容器为例说明了这两个场景。红色的框表示启用了加密硬件引擎的容器与“标准”容器之间的区别。值得指出的是，所显示的配置更改并不一定需要容器的另一个版本，因为配置可以被管理，例如，使用ConfigMaps。

图1. 入口控制器容器的例子

硬件资源和隔离

为了能够部署具有硬件依赖关系的工作负载，Kubernetes提供了优秀的扩展和可配置机制。让我们进一步研究Kubernetes设备插件框架（beta 1.14）和RuntimeClass （beta 1.14），并了解如何利用它们向工作负载暴露加密硬件。

在Kubernetes 1.8中首次引入的设备插件框架为硬件供应商提供了一种向Kubelets注册和分配节点硬件资源的方法。插件实现了特定于硬件的初始化逻辑和资源管理。这些pod可以请求它们的PodSpec中的硬件资源，这也保证了pod被调度到能够提供这些资源的节点上。

容器的设备资源分配非常重要。对于处理安全性的应用程序，硬件级别隔离是至关重要的。作为PCIe基于加密加速设备功能可以受益于IO硬件虚拟化，通过I/O内存管理单元（IOMMU），提供隔离：IOMMU将设备分组，为工作负载提供隔离的资源（假设加密卡不与其他设备共享IOMMU组）。如果PCIe设备支持单根I/O虚拟化（SR-IOV）规范，则可以进一步增加隔离资源的数量。SR-IOV允许将PCIe设备从物理函数（PF）设备进一步拆分为虚拟函数（VF），并且每个设备都属于自己的IOMMU组。要将这些IOMMU隔离的设备函数暴露给用户空间和容器，主机内核应该将它们绑定到特定的设备驱动程序。在Linux中，这个驱动程序是vfio-pci，它通过用户空间中的一个字符设备使每个设备可用。内核vfio-pci驱动程序使用一种称为PCI透传（passthrough）的机制，为用户空间应用程序提供了对PCIe设备和函数的直接、IOMMU支持的访问。用户空间框架，如数据平面开发工具包（Data Plane Development Kit，DPDK）可以利用该接口。此外，虚拟机（VM）管理程序可以向VM提供这些用户空间设备节点，并将它们作为PCI设备暴露给客户内核。假设有来自客户内核的支持，VM将接近于直接访问底层主机设备的本机性能。

为了向Kubernetes宣传这些设备资源，我们可以使用一个简单的Kubernetes设备插件来运行初始化（绑定），调用kublet的注册（Registration）gRPC服务，并实现kublet调用的DevicePlugin gRPC服务，例如，在Pod创建时分配（Allocate）资源。

设备分配和Pod部署

此时，你可能会问容器可以使用VFIO设备节点做什么？我们首先快速查看Kubernetes RuntimeClass之后，答案会出现。

创建Kubernetes RuntimeClass是为了对集群中可用的各种运行时提供更好的控制和可配置性（前面的一篇博客文章详细介绍了它的需求、状态和路线图）。本质上，RuntimeClass为集群用户提供了更好的工具来选择和使用最适合pod用例的运行时。

https://kubernetes.io/blog/2018/10/10/kubernetes-v1.12-introducing-runtimeclass/

OCI兼容的Kata容器运行时为工作负载提供了一个硬件虚拟化隔离层。除了工作负载隔离之外，Kata容器VM还有一个额外的好处，即VFIO设备，由设备插件分配（Allocate’d），可以作为硬件隔离设备传递给容器。惟一的要求是，Kata容器内核启用了暴露设备的驱动程序。

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

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

图2显示了使用前面演示的容器的总体设置。

图2. 部署概述

参考设置

最后，我们描述构建图2中描述的功能设置所需的构建块和步骤，该功能设置使用Intel® QuickAssist技术（QAT） PCIe设备在入口控制器中启用硬件加速SSL终止。应该注意的是，用例并不局限于Ingress控制器，任何基于OpenSSL的工作负载都可以加速。

集群配置：

• Kubernetes 1.14（RuntimeClass和DevicePlugin特性门已启用（两者在1.14中都是true）
• 配置了RuntimeClass就绪运行时和Kata容器

主机配置：

• Intel® QAT驱动程序发行版，内核驱动程序同时安装在主机内核和Kata容器内核（或在rootfs上作为可加载模块）
• 已部署QAT设备插件DaemonSet

入口控制器配置和部署：

• 一个修改后的HAproxy-ingress入口控制器的容器
  • QAT HW HAL用户空间库（Intel® QAT SW发行版的一部分）和
  • 内置OpenSSL QAT引擎
• 使用Haproxy-ingress ConfigMap启用QAT引擎
  • ssl-engine="qat"
  • ssl-mode-async=true
• Haproxy-ingress部署.yaml
  • 请求qat.intel.com: n资源
  • 请求runtimeClassName: kata-containers（名称值取决于集群配置）
• （容器中配置了可用的OpenSSL引擎的QAT设备配置文件）

一旦构建块可用，就可以按照TLS终止示例步骤测试硬件加速SSL/TLS。为了验证硬件的使用，你可以检查主机上的/sys/kernel/debug/*/fw_counter文件，它们会由Intel® QAT固件更新。

https://github.com/jcmoraisjr/haproxy-ingress/tree/master/examples/tls-termination

使用HAproxy-ingress和HAproxy，是因为可以使用ssl-engine <name> [algo ALGOs]配置标志直接配置HAproxy来使用OpenSSL引擎，而无需修改全局OpenSSL配置文件。此外，HAproxy可以使用异步调用（使用ssl-mode-async）卸载已配置的算法，以进一步提高性能。

行动呼吁

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

我们团队的下一步是对Envoy重复相同的步骤（使用一个基于OpenSSL的TLS传输套接字作为扩展构建）。此外，我们正在努力增强Envoy功能，使其能够将BoringSSL异步私钥操作卸载到加密加速硬件。感谢你的反馈和帮助！

https://github.com/envoyproxy/envoy/issues/6248

当将加密处理卸载到专用加速器时，加密应用程序可以为其他任务节省多少CPU周期？