瞬时流量高峰场景下的高可用架构设计：Kubernetes集群如何调优？| Q推荐

作者 | 鲁冬雪

谈起瞬时流量高峰场景下的高可用架构设计，那首先要解决的肯定是高并发问题。

类似电商大促就是典型的高并发场景，当业务突发波动（如秒杀、限量抢购）时，无法准确预估流量，企业会苦恼需提前准备多少台机器，突发流量过后，这些机器往往又处于空载状态。这就意味着系统需要承担 100% 的业务和流量，需要具备超强的稳定性和容灾能力，并可以紧急处理各种故障：

• 应对快速增长的用户访问：流量短时间内达到峰值，系统面临宕机危险；

• 应对大量业务数据和用户数据：计算资源需求突增，技术上需做到弹性自如；

• 紧急故障处理能力：业务场景越来越复杂，宕机概率增加。

虽然这些是老生常谈的话题，但要解决并不容易，性能优化永无止境，系统高可用优化亦然。

1 实现系统的高可用，Kubernetes 集群是常见解决方案

想要实现系统的高可用，首先要明确，什么样的系统可以称之为“高可用”。简单来讲，就是不宕机。“高可用性”常常被定义为 IT 系统的运营综合指标，系统的稳定可靠程度越靠近 100%，就代表系统越稳定，这种“稳定”往往需要多方面技术调优才能实现。

而 Kubernetes 的核心特点就是能够自主地管理容器来保证容器按照用户的期望状态运行，现在 Kubernetes 更是聚焦于不间断的服务状态（如 web 服务器、缓存服务器）和原生云平台应用（Nosql），极大程度地保障系统的稳定性，所以 Kubernetes 被称为云原生时代实现系统高可用的最佳解决方案。

作为云原生时代的操作系统，Kubernetes 的采用率正在企业内不断攀升。京东是全球容器化最彻底的互联网企业之一，目前运营着全球最大规模的 Kubernetes 集群。为了应对 如618 的订单洪峰，京东容器云平台带宽扩容数百G，抵挡了数十次攻击，实现了订单百分百云上交易。

瞬时流量高峰场景下，京东通过在 Kubernetes 集群上运行业务，以最优成本处理突发流量，实现电商系统的高可用。Kubernetes 集群无需人工管理节点和容量规划，高效实现全自动容器无限弹性扩容，同时还可以做到在保持和降低系统响应时间的前提下，不断提高系统访问量、吞吐量，从而不断提升流量高峰时的服务可用性。

即便如京东这种研发实力强悍的互联网大厂也会发现软件层面的性能优化很容易达到瓶颈，当达到某一个值之后，就很难再有提升，这就需要在硬件层面寻求突破。作为京东云底层软件的服务商，为了应对系统高可用性能需求，英特尔从硬件层面给出了解决方案：使用第三代英特尔® 至强® 可扩展处理器提供更强算力来满足高并发需求，英特尔® 傲腾™ 持久内存提供更大容量内存或持久性数据存储，以及各种类型的软硬件加速技术，辅助实现高并发。针对高并发场景下的 HTTPS 请求和处理需求，还可使用英特尔® QAT 卡来卸载 TLS 请求和加解密处理，释放 CPU 应对关键计算，从而提高 HTTPS 高并发访问量、减少相应时间。

当以上这些底层硬件能力暴露给 Kuberntes 后，容器开发者或集群运维者可以充分利用资源实现并优化具体业务，还可以借助这些硬件能力来创新，收获不一样的业务、性能体验。除此之外，这些硬件能力还可帮助开发者快捷优化应用负载，确保预测性，并实现资源的可观察性。

坦率来讲，分布式系统相对会比较复杂，性能问题也并不那么容易解决，且系统层次比较深，相关性能问题的追踪和定位也不太容易，底层软件层面的优化也是个“慢活儿”，但硬件性能的提升对于 Kuberntes 技术架构体系的优化影响还是很大的。目前已经被验证的，英特尔软、硬结合的方式能够有效优化 Kuberntes 集群技术架构，以便充分利用硬件性能，通过释放硬件潜力来优化软件、提升服务性能。

2 对 Kubernetes 的美好期待，前提是完成集群的高效管理

Kubernetes 本身并没有提供一个高可用的、开箱即用的集群使用方式，实际构建和管理过程中产生的复杂度，往往会带来各种各样的问题和挑战。虽然 Kubernetes 集群可以解决单集群资源隔离、故障隔离的难题，打破可支持节点数、Pod 数的限制，但同时也带来了集群管理复杂度增加的问题，运维成本成倍增加。所以说，Kubernetes 确实能解决很多包括瞬时流量高峰场景在内的系统高可用问题，但这一切的前提是完成 Kubernetes 集群的顺利构建和高效管理。

Kubernetes 的插件模式给英特尔等各厂商带来了与 Kubernetes 兼容的便利，同时降低了用户的设备使用成本，并且可以一致访问、管理。Kubernetes 为了兼容业界各厂商的加速设备，通过扩展设备模式来管理设备，为此定义了一个支持硬件设备的设备插件框架（device plugin framework），只要厂商按照这个框架标准 API 来实现相应的函数接口，就可以在不修改现有 Kubernetes 代码的情况下，轻松安装，集成到 Kubernetes 集群环境中来使用这些设备。

在这个背景下，英特尔使用硬件设备插件、高级容器网络功能等技术，极大促进了 Kubernetes 集群高效管理。英特尔开发的所有硬件设备插件都是开源的，开发者可以访问（https://github.com/ intel / intel -device-plugins-for-kubernetes/） 获取详细信息。

从高级容器网络功能层面来看，为了方便集成，Kubernetes 支持英特尔等第三方网络提供商的网络技术方案，也定义和复用了容器网络接口（CNI），也就是说只要是符合 CNI 规范的网络解决方案都可以很方便的集成到 Kubernetes 环境中。

因为网络的使用模式非常多，场景也非常复杂，Kubernetes 基于英特尔硬件网络设备开发了多种 CNI 来满足其功能、性能等方面的需求。英特尔 为厂商和用户提供了更多的网络选项，比如用户需要聚合网络接口，可以部署 Bond CNI；如果需要多网络接口，可以安装 Multus CNI；如果是性能方面的需求，则可以使用 DPDK。

可以说，设备插件和网络模块极大地丰富和提升了集群的能力，同时也为这些设备的可观测性提供了机会。英特尔也使用多项数据中心关键技术，帮助 Kubernetes 构建功能模块和全栈解决方案，从而确保最终用户获得底层硬件的全部优势。

对于 Kubernetes 来说，其社区核心开发集中在应用编排上，对于底层硬件资源的对接。在架构设计上，Kubernetes 从兼容的角度出发，定义了相应的 API，如 CSI、CNI、CRI、Device Plugin 等，开发者无需修改代码便可快速构建功能模块。

对于运维人员来说，有了 Kubernetes 更高层的资源访问接口和管理能力，他们就可以实现其自动化全周期运维和监控，其可靠性和弹性得到大大提升，同时也获得了提高整个集群效率和资源利用率的能力。

当然了，探讨 Kubernetes 集群的高效管理的前提还是要保证其“稳定性”。只有保障了集群的稳定性，才能谈高效管理。如果想要有效避免云宕机事件的发生，首先要做到的是有效降低内存错误问题。因为在云场景下，一旦出现内存故障问题，往往会造成严重的灾难性后果，比如主机操作系统挂起、系统崩溃、宕机等，将严重影响企业用户的服务质量。

通常来讲，内存错误一般可分为可纠正错误和不可纠正错误，其中“可纠正错误”是可以通过纠错码克服双页值之差的内存模块的一些可纠正错误，而“不可纠正错误”又分为由于内存条实体硬件错误造成严重后果的（Fatal Error）、不需要处理的（UCNA）、必须处理的（SRAR）和选择处理的（SRAO）。然而，云主机出现内存错误的原因是多种多样的，而且很多时候难以复现，面对这种情况，就要具体事件具体分析。

当下解决“内存错误”问题比较理想的方案是应用英特尔® MCA Recovery 与 MFP 技术，目前第三代英特尔® 至强® 可扩展处理器已经支持这两项技术，这两项技术基于对内存错误的分析和了解，能够对 SRAR 和 SRAO 这两种错误进行预测和恢复，可以有效降低内存故障对主机的影响，可以帮助企业用户的云服务完善故障预警，并降低内存故障影响，为用户提供更稳定、更高效的云服务。

3 Kubernetes 从中心走向边缘，应用编排被重新定义

CNCF 在年度调研中提到，作为云原生最重要的编排工具之一的 Kubernetes 已经是无处不在，在包括边缘计算的不同场景里面均有使用。其调查显示，“在边缘计算领域，大概 76% 都会使用到 Kubernetes。”

多云环境在边缘计算领域已经变得越来越普遍，Kubernetes 也将云原生技术从中心拓展到边缘，云边基础设施技术架构实现统一，业务侧也实现了云边自由编排部署。举一个例子，在边缘计算场景下往往存在着大量异构设备，而且每种设备都具独特性，利用 Kubernetes 提供的扩展的 API 资源（如 CRD 功能）对这些设备进行数据建模，可以实现设备的统一管理。

Kubernetes 在边缘侧的优点确实很明显，但 Kubernetes 毕竟是从集中式数据中心的场景里诞生出来的技术，在边缘场景下也出现了水土不服，比如在“高效管理多云以进行应用程序编排”方面就出现了新挑战：

• 延迟：对新的低延迟应用程序用例（如 AR/VR）的要求。例如，IIOT 需要超低延迟响应。这需要在更靠近用户的边缘上支持一些应用程序功能；

• 带宽：在边缘处理数据避免了将数据传输到云中进行处理的相关成本；

• 上下文 /‍Promixity‍：当边缘服务器需要本地上下文时，在用户附近的边缘服务器上运行应用程序的某些部分；

• 隐私 / 法律：某些数据可能需要保留在某个地理位置。

面对这些新挑战，英特尔积极寻求解决方案，如今英特尔的边缘多集群编排器（EMCO）与 Kubernetes 的合作，已经可以很好地把这些问题解决掉。EMCO 是 Kubernetes 的地理分布式应用程序编排器，运行级别高于 Kubernetes，并与运行 Kubernetes 的多个边缘服务器 (和云）交互。

EMCO 的主要目标就是跨多个集群自动化应用程序和服务的部署，其充当中央协调器，可以跨不同第三方的地理分布边缘群集管理边缘服务和网络功能。与其他多集群编排相比，EMCO 侧重于以下功能：

• 注册多个地理上分布的群集；

• 跨不同集群编排组合应用程序（由多个单独的应用程序组成）；

• 将边缘服务和网络功能部署到分布在不同群集上的不同节点；

• 监视跨不同群集部署的边缘服务和网络功能的运行状况；

• 根据计算、加速和存储需求，通过部署意图协调边缘服务和网络功能；

• 支持来自不同企业的多个租户，同时确保租户之间的机密性和完全隔离。

在 EMCO 的加持下，从中心走到边缘的 Kubernetes，应用编排将重新被定义，编排能力变得更强壮。

4 写在最后

Kubernetes 的先进性和集群的高可用是毋庸置疑的，但当所有企业都选择 Kubernetes 后，却因为其复杂性陷入了新思考，甚至 Kubernetes 的创立者和核心推动者 Google 本身都逃避不开这个问题，“Kubernetes 就像一把双刃剑，既是最佳的容器编排技术，同时也存在相当高的复杂性和应用的高门槛，这个过程中往往会导致一些常见性错误”。

在实际的应用场景中，除了认知复杂性和开发复杂性，Kubernetes 带来的最重要的影响是其颠覆了传统的运维模式。Kubernetes 是一个非常复杂的系统，拥有多样的 API 及模块插件，这便直接增加了可被攻击面，让很多企业在安全性运维方面都无从下手。而且随着 Kubernetes 集群规模的增长，运维难度呈线性增长。

但我们要知道的是，所有技术都有双面性。容器革新了云计算的基础设施，而 Kubernetes 则搭建了一个统一的基础设施抽象层。通过 Kubernetes 集群，我们无需关心任何基础设施层的细节，就能快捷地构建出任何我们想要的且高可用的业务系统，这也是 Kubernetes 被称为云计算界的 Linux 以及 “Platform for Platforms” 的根本原因。

好在，随着英特尔等多家厂商不断提供硬件设备及技术供给，Kubernetes 的复杂性问题在逐渐弱化。在未来，集群的稳定性和系统的高可用将不是问题，在软件技术的调教下，硬件潜力将发挥到极致，软硬件的完美配合将交付最佳实践。