视频

了解更多
手动部署 Kubernetes 集群可能会非常麻烦。除非有自动化流程来加速,否则安装和维护集群是一项复杂的任务,且出错的风险很高。为了减轻这些复杂性,我们有 Helm——一个 Kubernetes 包管理器,以及 Helm charts——一个定义集群如何部署的蓝图。本文将探讨 Redis Helm chart 的优缺点,以及新的用于 Kubernetes 的 Redis Enterprise Operator 如何解决使用 Helm 包管理器时出现的大多数痛点。
开发人员依赖像 Kubernetes 这样的开源接口来管理和部署容器化应用程序。应用程序和服务运行在**容器**中,并部署在**集群**中。要确保一切正常运行,这是一个需要关注细节的过程。有很多事情需要跟踪:管理配置、使用正确的命令、选择正确的值以及打包正确的应用程序文件。很容易出错。
Helm 是一个开源的 Kubernetes 包管理器,它使用配置和清单文件中的定义值来实现应用程序或服务在集群中的高效部署和安装。
开发人员使用这些清单文件来指定成功部署所需的每个配置。这些配置通过命令行界面 (CLI) 使用命令执行。
但要部署单个容器,开发人员只需要简单的手动过程。一旦需要多个容器,最好开始使用配置文件来执行。如果您的架构需要一个集群(可能需要多个容器或 Pod),这些配置文件最好整合到 Helm chart 中。
通过执行 Helm 安装开始。
要在 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 已经在 Kubernetes 中部署了数百个集群。从一开始,我们就意识到手动过程是不可行的。第一个问题是让 Redis 集群部署更容易复制;这也是一个扩展操作的问题。我们需要能够在单行 Helm CLI 命令中部署一个 Redis 集群。
到目前为止,我们已经介绍了 chart 如何提高生产力,让开发人员可以无愧地“偷懒”。以下是其他一些值得强调的优点。
应用程序在其生命周期的每个阶段都需要一个集群,这并不罕见——而且应用程序越复杂,这些生命周期就越具挑战性。
Helm 包管理器是为集群建立一个可行、可重现的基础的绝佳工具。然而,当集群资源达到上限时,它不会提供自动故障转移。集群会随时间变化。也许是增加了 Redis 节点、Pod 或 Kubernetes 应用程序……但集群很少保持固定状态。这些状态变化无法反映在 Helm chart 中,除非您为所有内容都创建 chart,而这又变成了手动过程。
我们将部署应用程序到 Kubernetes 容器中学到的一切转化为用于 Kubernetes 的 Redis Enterprise Operator。
Operator 是一个为需要大规模管理 Kubernetes 中 Redis 实例的企业提供的工具。它控制 Redis 集群的配置、扩展和可用性,并在任何基础设施中管理容器的生命周期。
Redis Enterprise Operator 了解应用程序的生命周期,并创建新资源来维护应用程序。例如——您是否曾设置过礼品卡在资金用尽后自动充值?Operator 会自动为集群配置所需的资源以保持运行,无论是添加 Redis 节点还是负载均衡Redis 缓存以保持亚毫秒级延迟。
使用 Helm charts,团队可以快速启动并运行应用程序,并依赖 Operator 确保应用程序生命周期的每个阶段都有继续运行所需的资源。
简而言之,用于 Kubernetes 的 Redis Enterprise Operator 通过确保集群始终拥有实现最佳性能所需的一切来“保持所有球都在空中”(比喻,指多任务并行顺利进行)。
命名空间在 Kubernetes 中用于将集群逻辑上分离和分散到子集群中。这是一种使用唯一名称隔离和识别资源的方式。命名空间对于在多个部门有强大运营的团队特别有用。这是各种用户访问特定集群资源而不干扰其他资源的一种有用方式,从而降低了任何系统复杂性。
是的。REC 可以运行多个数据库,即使在高容量下也不会出现性能下降。
是的。每个 REC 由一个命名空间管理,每个命名空间需要自己的 operator。