为什么要在 Pivotal Container Service 上使用 Redis Enterprise Kubernetes 版本？

在过去的几个月里，我们的团队一直在忙于在 Kubernetes 上部署 Redis Enterprise。我们的旅程始于编写一个简单的 控制器，用于 Kubernetes 版本的 Redis Enterprise。几个月后，我们引入了 Helm Chart 支持，在过去的几个月里，我们一直在为 Kubernetes 版本编写一个 操作员。

通过这篇博文，我想介绍我们在 Pivotal Container Service® 集群上部署 Kubernetes 版本的 Redis Enterprise 所使用的原则。

为什么要选择 PKS？

以云原生方式管理容器化微服务至关重要，Kubernetes 已成为微服务架构的事实上的部署单元。PKS 是一个经过认证的 Kubernetes 发行版，可以与 Pivotal Application System® (PAS) 结合使用来管理您的整个应用程序生命周期。这两个平台都由 Cloud Foundry® 和 BOSH（一个云编排工具）管理。它们共同提供了一种有效的方法来管理有状态服务（例如您的数据库）以及无状态服务（例如您的应用程序）。

PKS 的三个主要组件是

• Pivotal Ops Manager – 用于部署 BOSH Director 和 PKS 磁贴；
• PKS 客户端 VM – 用于 UAA CLI、PKS CLI 和 Kubectl CLI 等子组件，通常部署在单独的 VM 上
• “Stemcell” – 用于 BOSH 管理的虚拟机的自定义操作系统映像。

为了这篇博文的目的，让我们假设这些组件已成功安装在 vSphere 等底层基础设施上。

为什么要选择 Redis Enterprise？

Redis Enterprise 结合了世界一流的数据库技术的优势和充满活力的开源 Redis 社区的创新，从而获得

• 强大的高可用性，故障转移时间为个位数
• 真正的线性可扩展性，为集群中添加的每个节点提供额外的 100 万次以上操作/秒
• 基于无冲突复制数据类型 (CRDT) 技术 的分布式主动-主动
• 通过 Redis 模块实现多模型，这通过 RediSearch、ReJSON、Redis Graph、Redis-ML 等扩展了 Redis 的功能
• 使用闪存/SSD 扩展 DRAM 以节省基础设施成本。

为什么要选择 PKS 上的 Redis Enterprise？

我们在 PKS 上的 Redis Enterprise 中使用四个重要原则，以最大限度地提高部署的稳健性

1. 基于操作员的部署，使用 Statefulset 和反亲和性：操作员使我们能够在所有 Kubernetes 环境中维护统一的部署。Kubernetes Statefulset 和反亲和性使 Redis Enterprise 节点能够驻留在托管在不同 VM 或物理服务器上的 POD 上。此设置如下图所示
   |
2. 用于数据持久性的网络附加持久存储：为了避免在每次 POD 故障事件中丢失本地数据，PKS 要求存储卷与计算实例网络连接。此外，由于 Redis 在使用持久存储的方式上非常高效（即使用户选择配置 Redis 将每次更改写入磁盘），因此我们在典型的 PKS 环境中看到了显着的性能提升。与基于磁盘的数据库相比，基于磁盘的数据库需要与存储设备进行多次交互（在大多数情况下）才能进行每次读或写操作，Redis 使用单个 IOPS（在大多数情况下）进行写操作，而读操作则使用零 IOPS。
   
   
3. 分层编排架构：我们使用这种方法来处理与在 Kubernetes 集群上运行 Redis 相关的所有细微差别。Kubernetes 是一个很棒的编排工具，但不是为特定的 Redis 任务而设计的，有时会对内部 Redis 问题做出错误的反应。此外，Kubernetes 编排在 Redis 集群部署之外运行，并且可能无法在网络拆分情况下触发故障转移事件。我们的分层架构方法通过将职责划分为 Kubernetes 擅长的工作、Redis Enterprise 集群擅长的工作以及两者都可以一起编排的工作来克服这些问题。此分层架构如下所示：
4. 多实例部署：我们发现，在 PKS 上部署 Redis 的传统方式（每个 POD 包含一个 Redis 实例，同时保留一个专用 CPU）非常低效！Redis 速度非常快，在许多情况下只需使用一小部分 CPU 即可提供所需的吞吐量。此外，当在多个 POD 上运行包含多个 Redis 实例的 Redis 集群时，PKS 网络（及其多个 vSwitch）可能会成为您的瓶颈。因此，我们对 PKS 上的 Redis Enterprise 采取了不同的方法，其中每个 POD 包含多个 Redis 实例（多个服务）。这使每个 POD 能够更好地利用硬件资源（CPU、内存和网络），同时保持相同级别的隔离。这种方法如下图所示：

在 PKS 上使用 Redis Enterprise 入门

用于 PKS 部署的 Redis Enterprise 的 docker 映像位于 此处。您可以阅读有关 Redis Enterprise Kubernetes 版本架构的更多信息 此处。

开始使用

1. 通过检查以下设置来验证 PKS 集群是否正常运行。
   

   $ pks 集群 redis
   名称	redis
   计划名称	large
   UUID	5f4af2c0-5330-4dae-bdfc-6251ea3eecf2
   最后操作	创建
   最后操作状态	已成功
   最后操作说明	实例供应已完成
   Kubernetes 主机	104.196.4.15
   Kubernetes 主机端口	8443
   工作节点	4
   Kubernetes 主机 IP(s)	192.168.20.46, 192.168.20.47, 192.168.20.45

    

2. 验证 BOSH 管理的 PKS 节点是否已供应。例如，此图像显示了一个具有四个节点的 PKS 集群
   
3. 在 PKS 上部署您的 Redis Enterprise 集群：为 PKS 上的 Redis Enterprise 创建自定义资源定义 (CRD)
   kubectl  apply -f redis-enterprise-crd.yml在 PKS 上部署 Redis Enterprise 操作员
   kubectl apply -f redis-enterprise-operator.yml使用操作员和 CRD 在 PKS 上部署 Redis Enterprise 集群
   kubectl apply -f redis-enterprise-cluster.yml
4. 使用 Redis Enterprise Web 界面验证您的 Redis Enterprise 集群是否处于健康状态，该界面在端口 8443 上公开。这显示了运行在 PKS 集群之上的三个节点的 Redis Enterprise 集群：
5. 验证在 PKS 集群上部署的所有 Redis Enterprise 资源。此图像显示了三个节点的 Redis Enterprise 部署占用空间

在 PKS 上对 Redis Enterprise 进行基准测试

为了衡量性能，您可以使用 Redis Enterprise UI（或 API）创建一个 Redis 数据库，并使用以下参数（注意：此设置假设 Kubernetes 节点中有足够的内核来支持 Redis Enterprise 集群。在下面的示例中，我们使用了 14 个分片的数据库）

接下来，将 memtier_benchmark 部署到同一 Kubernetes 集群上的另一个 POD 上，并使用以下参数运行 memtier_benchmark

-d 100 –pipeline=35 -c 10 -t 8 -n 2000000 –ratio=1:5 –key-pattern=G:G –key-stddev=3 –distinct-client-seed –randomize

使用 Redis Enterprise UI 中的指标屏幕监控数据库在负载下的性能。正如您在下面的图中看到的，Redis Enterprise 可以轻松地使用 Kubernetes 基础设施上的一个集群节点达到 0.5M 次操作/秒以上，同时将延迟保持在亚毫秒级别。

下一步是什么？

在这篇博文中，我们演示了通过在平面网络上部署所有资源来简化 PKS 的部署。为了撰写这篇博文，我们使用了 PKS 的 Redis Enterprise 版本的技术预览版。随着我们努力实现普遍可用性，我们将继续探索我们围绕网络分段以及 Kubernetes 入口原语的 PKS 集成工作。此外，我们将很快添加对 主动-主动 PKS 上的地理分布式 Redis CRDT 的支持，以服务全球分布式应用程序。

如果您想开始尝试使用我们的 Redis Enterprise 版本，请与我们 联系，以便我们能够帮助您满足 Redis 需求。