了解数据在系统中的路径，可以揭示低于预期性能的潜在来源及其解决方案。
本文译自 Running Containers At Scale – The Best Data Path to Success[1]。作者：Kirill Shoikhet
K8s和其他容器编排平台正在迅速下沉到主流的基础设置中，对于大多数面向业务的应用，从传统的数据中心迁移到容器部署还算独立和简单。然而，当遇到需要像数据库或快速数据分析工作负载这样要求更高的核心应用时，事情不那么简单了。
首先，应用容器化对底层基础设施提出了更高的要求，包括网络、存储和容错。虽然K8s在这些方面取得了很大的进步，但无论是在本地还是云场景中运行，应用仍然会出现性能下降的问题。其次，即使是中等规模的应用，K8s网络也不能为其提供低且可预测的延迟。
我们认为一个平稳运行的IT系统所需的CPU、带宽和存储容量，对于优化部署很重要。所以，了解数据在系统中的路径，可以揭示出低于预期性能的潜在来源及其解决方案。
为容器化工作负载提供存储的三种方法
私有云和并置设备/存储集群
虽然本地存储通常是功能最丰富、拓展最便捷的方式的存储方式，但在容器原生的部署下可能就不那么完美了。在这些本地实例中，存储与K8s系统并行存在，K8s通过一个容器存储接口(CSI)插件将应用与存储连接起来，其工作原理是将应用程序容器直接连接到外部存储，完全绕过K8s控制的网络。
容器存储软件
以容器形式诞生并使用容器实施的解决方案，具有专为容器而生的优势。这些产品采取了 “功能优先 “的方法，这有助于确保IT团队保留精简配置和重复数据删除等功能。然而，无论是在规模上还是在生产中，性能再次取决于数据路径。这些解决方案通过存储控制器提供对存储设备的访问，而存储控制器本身是作为容器实现的，所以整个数据路径都要经过K8s网络，影响延迟。
在K8s中原生运行的软件定义存储
市场上有一些纯软件定义的存储选择，其中只有少数几个在K8s中原生运行。其中包括独立的裸机软件定义存储产品，这些产品被移植到K8s中使用，也支持私有云和混合云部署。
K8s中原有的软件定义存储利用上述两种方法的优点来实现最佳性能以和扩展。它是容器原生的，根据实现方式，有些将数据路径与K8s隔离，因此性能比仅容器存储软件方法中的CSP更好。
这使数据中心架构师能够获得最好的传统本地架构和仅容器存储的最佳效果。为了确保延迟可预测性，数据路径在K8s之下——在容器和NVMe SSD之间——从内核移动到客户端设备驱动程序，再到目标驱动，然后直接访问NVMe驱动。
用这种方式，客户端是完全独立的，不需要跨客户端通信就可以直接与目标通信。这种方式，减少了网络跳跃点数量和通信线路的数量，使得该模式可以用于大规模环境，其中连接的数量是域大小的小倍数。
Elasticsearch 应用程序
几个允许系统在K8s中原生运行的用例，展示了软件定义的方法的好处。例如欧洲、中东和非洲地区的一家主要电信供应商为大型K8s中的Elasticsearch试用了三种存储方法。外部的、基于iSCSI的SDS是可扩展的，但延迟在毫秒级，导致索引性能更差，而K8s原生的存储解决方案则无法满足数百个节点的规模要求。这两种方法都导致了最终用户的体验明显变差。第三种方法是基于NVMe的可扩展SDS，使用嵌入K8s节点的NVMe驱动器，结合原生集成到 K8s 控制和管理平面，实现了显着更好的性能和延迟。
K8s的 NVMe 原生共享存储的系统架构，具有裸机性能
CI/CD 应用
在另一个例子中，一家顶级网络公司在一个拥有数万个节点的数据中心的CI/CD应用程序中，在K8s中原生运行了一个SDS，为编译、构建和本地测试提供一个强大的控制环境。图1显示了SDS的基于NVMe 的客户端和横向扩展架构是如何实现CI/CD工作负载向K8s的过渡，同时保留了裸机性能。
当在K8s下运行时，该方法用特权容器控制客户端和目标设备驱动程序的部署，使数据路径不受K8s环境的容器化性质的影响，并将所有控制和管理平面组件转移到基于原生容器API的操作。在这家顶级网络公司的生产环境中，应用程序性能比裸机情况高15%-20%，因为存储软件将多个远程NVMe驱动器聚集在一个虚拟卷中，呈现给运行应用程序的容器。
通往成功的最佳数据路径
寻找合适的存储来满足应用程序对可扩展性和性能的需求并不是一个放之四海而皆准的方法。当存储架构师通过了解数据路径的含义，为容器选择存储时，能够在容器化混合部署中让应用更加流畅，获得可扩展、高性能、敏捷的存储。
引用链接
[1]
原文链接: https://www.networkcomputing.com/cloud-infrastructure/running-containers-scale-%E2%80%93-best-data-path-success