dot Redis 8 已发布——并且它是开源的

了解更多

Helm 工具和 Helm Charts 简介

手动部署 Kubernetes 集群可能会非常麻烦。除非有自动化流程来加速,否则安装和维护集群是一项复杂的任务,且出错的风险很高。为了减轻这些复杂性,我们有 Helm——一个 Kubernetes 包管理器,以及 Helm charts——一个定义集群如何部署的蓝图。本文将探讨 Redis Helm chart 的优缺点,以及新的用于 Kubernetes 的 Redis Enterprise Operator 如何解决使用 Helm 包管理器时出现的大多数痛点。

Helm 如何工作

开发人员依赖像 Kubernetes 这样的开源接口来管理和部署容器化应用程序。应用程序和服务运行在**容器**中,并部署在**集群**中。要确保一切正常运行,这是一个需要关注细节的过程。有很多事情需要跟踪:管理配置、使用正确的命令、选择正确的值以及打包正确的应用程序文件。很容易出错。 

Helm 是一个开源的 Kubernetes 包管理器,它使用配置和清单文件中的定义值来实现应用程序或服务在集群中的高效部署和安装。 

开发人员使用这些清单文件来指定成功部署所需的每个配置。这些配置通过命令行界面 (CLI) 使用命令执行。 

但要部署单个容器,开发人员只需要简单的手动过程。一旦需要多个容器,最好开始使用配置文件来执行。如果您的架构需要一个集群(可能需要多个容器或 Pod),这些配置文件最好整合到 Helm chart 中。  

通过执行 Helm 安装开始。

Helm charts

要在 Kubernetes pod 或集群中正确安装应用程序,您需要 Helm chart 中打包的一套预配置资源定义。这个 chart 包含许多场景的定制信息:从运行小型应用程序到集群中的复杂数据库。

Helm charts 是开发团队的明智选择。开发人员可以绕过从头开始部署,转而使用定制配置,这减少了资源配置错误的风险。

Helm charts 存储在**仓库**中。通过将资源定义存储在中央枢纽中,chart 仓库使 Helm 能够打破阻碍开发团队的工作孤岛。

一个 chart 甚至可能依赖于另一个 chart。将一个 chart 嵌套在另一个 chart 中会创建一个同步的**依赖**。Helm 使开发人员能够轻松管理 chart 中的任何依赖,并提供存储模板文件的 chart 仓库服务器的 URL。

一旦 chart 运行一个实例(当它向网络添加一个 pod 时),它就会创建一个**发布 (release)**。每个运行的实例都有一个发布。(我们将在下面更详细地探讨 Redis 实例和发布)。 

简而言之:chart 实现了集群中常用和可重复的应用程序和服务的流线型部署。

Redis Enterprise 发布

Redis 已经在 Kubernetes 中部署了数百个集群。从一开始,我们就意识到手动过程是不可行的。第一个问题是让 Redis 集群部署更容易复制;这也是一个扩展操作的问题。我们需要能够在单行 Helm CLI 命令中部署一个 Redis 集群。

用于 Kubernetes 的 Redis Enterprise Operator

到目前为止,我们已经介绍了 chart 如何提高生产力,让开发人员可以无愧地“偷懒”。以下是其他一些值得强调的优点。

使用 Helm charts 的优点

  • 它们很简单:将部署复杂性降低到单个 Helm CLI 命令
  • 它们可重现:允许在各种环境(包括)中进行重复、可预测和高效的部署
  • 它们流程化:使新团队成员能够快速了解现有项目
  • 它们有条理:维护并自动版本化使用 Helm 执行的过去配置
  • 它们灵活:‘Package’ 命令与 Helm 仓库共享 chart,项目中的任何人都可以轻松访问

Helm charts 的不足之处

应用程序在其生命周期的每个阶段都需要一个集群,这并不罕见——而且应用程序越复杂,这些生命周期就越具挑战性。 

Helm 包管理器是为集群建立一个可行、可重现的基础的绝佳工具。然而,当集群资源达到上限时,它不会提供自动故障转移。集群会随时间变化。也许是增加了 Redis 节点、Pod 或 Kubernetes 应用程序……但集群很少保持固定状态。这些状态变化无法反映在 Helm chart 中,除非您为所有内容都创建 chart,而这又变成了手动过程。

用于 Kubernetes 的 Redis Enterprise Operator

我们将部署应用程序到 Kubernetes 容器中学到的一切转化为用于 Kubernetes 的 Redis Enterprise Operator。 

Operator 是一个为需要大规模管理 Kubernetes 中 Redis 实例的企业提供的工具。它控制 Redis 集群的配置、扩展和可用性,并在任何基础设施中管理容器的生命周期。 

Redis Enterprise Operator 了解应用程序的生命周期,并创建新资源来维护应用程序。例如——您是否曾设置过礼品卡在资金用尽后自动充值?Operator 会自动为集群配置所需的资源以保持运行,无论是添加 Redis 节点还是负载均衡Redis 缓存以保持亚毫秒级延迟。 

使用 Helm charts,团队可以快速启动并运行应用程序,并依赖 Operator 确保应用程序生命周期的每个阶段都有继续运行所需的资源。 

简而言之,用于 Kubernetes 的 Redis Enterprise Operator 通过确保集群始终拥有实现最佳性能所需的一切来“保持所有球都在空中”(比喻,指多任务并行顺利进行)。

常见问题

什么是命名空间 (namespace)?

命名空间在 Kubernetes 中用于将集群逻辑上分离和分散到子集群中。这是一种使用唯一名称隔离和识别资源的方式。命名空间对于在多个部门有强大运营的团队特别有用。这是各种用户访问特定集群资源而不干扰其他资源的一种有用方式,从而降低了任何系统复杂性。

Redis Enterprise 集群 (REC) 可以包含多个数据库吗?

是的。REC 可以运行多个数据库,即使在高容量下也不会出现性能下降。

每个命名空间都需要部署一个 Redis Enterprise operator 吗?

是的。每个 REC 由一个命名空间管理,每个命名空间需要自己的 operator。

您可以通过哪些不同的方式在 Kubernetes 上使用 Redis Enterprise?

Kubernetes 上的 REC 可以通过云、本地部署、用于微服务架构,或任何组合以实现真正的混合云体验。

在这些常见问题中查找更多关于在 Kubernetes 上使用 Redis Enterprise 的问题的答案。