为什么要在 Pivotal Container Service 上使用 Redis Enterprise Kubernetes 发布？

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

通过这篇博文，我想介绍一下我们用于在 Pivotal Container Service® 集群上部署 Kubernetes 发布的 Redis Enterprise 的原则。

为什么选择 PKS？

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

PKS 的三个主要组成部分是

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

出于本博文的目的，我们假设这些组件已成功安装在 vSphere 等底层基础架构上。

为什么选择 Redis Enterprise？

Redis Enterprise 将世界一流的数据库技术的优势与充满活力的开源 Redis 社区的创新相结合，以获得

• 具有个位数故障转移时间的强大高可用性
• 真正的线性可扩展性，为您添加到集群的每个节点提供额外的 100 万+ ops/秒
• 基于无冲突复制数据类型 (CRDT) 技术的分布式主动-主动
• 通过 Redis 模块实现多模型，从而通过 RediSearch、ReJSON、Redis Graph, Redis-ML 等丰富 Redis 功能
• 使用 Flash/SSD 扩展 DRAM，从而节省基础架构成本。

为什么在 PKS 上使用 Redis Enterprise？

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

1. 基于 Operator 的部署与 Statefulset 和反亲和性：Operator 允许我们跨所有 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 cluster redis
   名称	redis
   计划名称	large
   UUID	5f4af2c0-5330-4dae-bdfc-6251ea3eecf2
   上次操作	CREATE
   上次操作状态	成功
   上次操作说明	实例配置已完成
   Kubernetes Master 主机	104.196.4.15
   Kubernetes Master 端口	8443
   工作节点	4
   Kubernetes Master 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 Operator
   kubectl apply -f redis-enterprise-operator.yml使用 Operator 和 CRD 在 PKS 上部署 Redis Enterprise 集群
   kubectl apply -f redis-enterprise-cluster.yml
4. 使用通过端口 8443 公开的 Redis Enterprise Web 界面验证您的 Redis Enterprise 集群是否处于健康状态。 此图显示了一个在 PKS 集群之上运行的三节点 Redis Enterprise 集群：
5. 验证 PKS 集群上所有已部署的 Redis Enterprise 资源。 此图显示了一个三节点 Redis Enterprise 部署 footprint

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

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

接下来，在同一 Kubernetes 集群上的另一个 POD 上部署 memtier_benchmark，并使用以下参数运行 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 ops/秒，同时保持低于亚毫秒级的延迟。

下一步是什么？

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

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