Redis Enterprise for Kubernetes 架构

本节概述了 Redis Enterprise for Kubernetes 的架构和注意事项。

Redis 的 Kubernetes 架构基于几个重要概念。

分层架构

Kubernetes 是一款出色的编排工具，但它并不是为了处理与运营 Redis Enterprise 相关的所有细微差别而设计的。因此，它可能无法对内部 Redis Enterprise 边缘情况或故障情况做出准确反应。此外，Kubernetes 编排在 Redis 集群部署之外运行，可能无法触发故障转移事件，例如，在拆分网络场景中。

为了克服这些问题，Redis 创建了一种分层架构方法，该方法在 Kubernetes 擅长的作、Redis Enterprise Cluster 擅长的程序以及两者可以一起编排的流程之间分配职责。下图说明了这种分层编排架构：

基于 Operator 的部署

Operator 允许 Redis 跨各种 Kubernetes 环境维护统一的部署解决方案，即 RedHat OpenShift、VMware Tanzu（Tanzu Kubernetes Grid 和 Tanzu Kubernetes Grid 集成版，以前称为 PKS）、Google Kubernetes Engine （GKE）、Azure Kubernetes Service （AKS） 和香草（上游）Kubernetes。Statefulset 和 anti-affinity 保证每个 Redis Enterprise 节点都驻留在托管在不同 VM 或物理服务器上的 Pod 上。请参阅下图所示的此设置：

网络连接的持久性存储

Kubernetes 和云原生环境要求将存储卷网络附加到计算实例，以保证数据持久性。否则，如果使用本地存储，数据可能会在 Pod 故障事件中丢失。见下图：

在左侧（标记为 #1），Redis Enterprise 使用本地临时存储来实现持久性。当一个 Pod 发生故障时，Kubernetes 会启动另一个 Pod 作为替代，但这个 Pod 会提供空的本地临时存储，并且原始 Pod 中的数据现在已经丢失。

在图的右侧（标记为 #2），Redis Enterprise 使用网络连接存储来实现数据持久性。在这种情况下，当一个 Pod 发生故障时，Kubernetes 会启动另一个 Pod 并自动将其连接到发生故障的 Pod 使用的存储设备。然后，Redis Enterprise 会指示在新创建的节点上运行的 Redis Enterprise 数据库实例从网络连接存储加载数据，从而保证持久设置。

Redis Enterprise 不仅作为内存数据库非常出色，而且在使用持久存储的方式上也非常高效，即使用户选择将 Redis Enterprise 配置为将每项更改写入磁盘时也是如此。与每次读取或写入作都需要与存储设备进行多次交互（在大多数情况下）的基于磁盘的数据库相比，Redis Enterprise 在大多数情况下对写入作使用单个 IOPS，对读取作使用零 IOPS。因此，在典型的 Kubernetes 环境中可以看到显著的性能改进，如下图所示：

每个 Pod 上有多个服务

每个 Pod 包括多个 Redis Enterprise 实例（多个服务）。我们发现，在 Kubernetes 上部署 Redis Enterprise 数据库的传统方法，即每个 Pod 仅包含一个 Redis Enterprise 实例，同时保留一个专用 CPU，效率明显低下。Redis Enterprise 的速度非常快，在许多情况下，只需使用一小部分 CPU 资源即可提供请求的吞吐量。此外，当跨多个 Pod 运行具有多个 Redis Enterprise 实例的 Redis Enterprise Cluster 时，Kubernetes 网络及其多个 vSwitch 可能很快成为部署的瓶颈。因此，Redis 采取了不同的方法来管理 Kubernetes 环境中的 Redis Enterprise。在单个 Pod 上部署多个 Redis Enterprise 数据库实例，使我们能够更好地利用 Pod 使用的硬件资源，例如 CPU、内存和网络，同时保持相同的隔离级别。见下图：