Kubernetes架构的Redis企业版

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

Redis 的 Kubernetes 架构基于几个关键概念。

分层架构

Kubernetes 是一个优秀的编排工具，但它并非设计用于处理与操作 Redis Enterprise 相关的所有细微差别。因此，它可能无法准确应对 Redis Enterprise 内部的边缘情况或故障条件。此外，Kubernetes 编排运行在 Redis 集群部署之外，可能无法触发故障转移事件，例如在网络分裂的情况下。

为了克服这些问题，Redis创建了一种分层架构方法，将职责分配给Kubernetes擅长的操作、Redis Enterprise Cluster擅长的程序以及两者可以共同协调的流程。下图展示了这种分层协调架构：

基于操作员的部署

Operator 允许 Redis 在各种 Kubernetes 环境中保持统一的部署解决方案，即 RedHat OpenShift、VMware Tanzu（Tanzu Kubernetes Grid 和 Tanzu Kubernetes Grid Integrated Edition，以前称为 PKS）、Google Kubernetes Engine (GKE)、Azure Kubernetes Service (AKS) 和原生（上游）Kubernetes。Statefulset 和反亲和性确保每个 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集群时，Kubernetes网络及其多个vSwitch可能会迅速成为部署的瓶颈。因此，Redis采取了不同的方法来管理Kubernetes环境中的Redis Enterprise。在单个Pod上部署多个Redis Enterprise数据库实例使我们能够更好地利用Pod使用的硬件资源，如CPU、内存和网络，同时保持相同的隔离水平。见下图：