Helm 工具和 Helm 图表简介

手动部署 Kubernetes 集群确实很麻烦。除非有自动化功能来加速此过程，否则安装和维护集群是一项复杂的任务，并且出错的可能性很高。为了减轻这些复杂性，引入了 Helm，它是一个 Kubernetes 软件包管理器，而 Helm 图表是一个蓝图，用于定义如何部署集群。我们探讨了 Redis Helm 图表的利弊，以及用于 Kubernetes 的新 Redis Enterprise Operator 如何解决使用 Helm 软件包管理器时出现的大多数痛点。

Helm 的工作原理

开发人员依赖于类似 Kubernetes 的开源接口，来管理和部署容器化应用程序。应用程序和服务在容器中运行，并部署在集群中。让一切正常工作是一个需要关注细节的过程。需要跟踪的内容有很多：管理配置、使用正确的命令、选择正确的值以及打包正确的应用程序文件。很容易出错。 

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

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

但是，要部署单个容器，开发人员只需要一个简单的手动过程。一旦需要多个容器，最好开始使用配置文件进行执行。如果你的体系结构需要一个集群（可能需要多个容器或 pod），则最好将这些配置文件折叠到Helm 图表中。  

通过执行 Helm 安装 来开始。

Helm 图表

要在 Kubernetes pod 或集群中正确安装应用程序，你需要Helm 图表中打包的一组预配置资源定义。此图表包含适用于许多场景的自定义信息：从在集群中运行小应用程序到运行复杂数据库的所有内容。

Helm 图表是开发团队的明智选择。开发人员可以绕过从头开始部署，并从减少了错误配置资源风险的定制配置开始。

Helm 图表存储在存储库中。通过将资源定义存储在中心集线器中，图表存储库使 Helm 能够打破阻碍开发团队的工作场所孤岛。

一个图表甚至可能依赖于另一个图表。在另一个图表内嵌套图表会创建一个同步依赖项。Helm 使开发人员可以轻松管理图表中的任何依赖项，该依赖项提供存储模板化文件的图表存储库服务器的 URL。

一旦图表运行一个实例（当其向网络添加一个 pod 时），它就会创建一个版本。对于每个运行的实例，都有一个版本。（我们将在下面详细探讨一个 Redis 实例和版本）。 

简言之：一张图表可简化在集群中常规使用和可重复的应用程序和服务的无缝部署。

Redis Enterprise 版本

Redis 已在 Kubernetes 中部署了数百个集群。从一开始，我们就意识到仅凭手动流程是不够的。第一个问题是让 Redis 集群部署更容易被复制；这也是一个扩展操作的问题。我们需要具备一行 Helm CLI 命令即可部署 Redis 集群的能力。

面向 Kubernetes 的 Redis Enterprise Operator

到目前为止，我们已了解图表如何提高生产力，让开发人员能够无忧无虑地走捷径。这里还有一些其他值得强调的好处。

使用 Helm 图表的优势

• 它们很简单：将部署复杂性简化为一条 Helm CLI 命令
• 它们是可复制的：允许在各种环境（包括云中）进行可重复的、可预测的和高效的部署
• 它们是简化的：使新团队成员能够快速了解现有项目
• 它们是有条理的：维护并自动生成使用 Helm 执行的过去配置的版本
• 它们是灵活的：‘Package’ 命令与 Helm 存储库共享一张图表，在该存储库中，项目中的任何人都可以轻松访问该图表

Helm 图表的不足之处

对于一个应用程序，在其生命周期的每个阶段都需要一个集群的情况并不少见——而随着应用程序变得越来越复杂，这些生命周期只会有更大的挑战。 

Helm 包管理器是一个极好的工具，可为集群设定一个可行的、可重复的基础。不过，当一个集群已用尽其资源时，它不会提供自动故障转移。集群会随着时间而变化。或许是添加了 Redis 节点、pod 或 Kubernetes 应用程序……但集群很少保持固定状态。除非您为所有内容都制定了图表，否则无法在 Helm 图表中反映这些状态变化，而且，它再次成为了一个手动流程。

面向 Kubernetes 的 Redis Enterprise Operator

在 Kubernetes 容器上部署应用程序时，我们吸取了所有经验，并将这些经验转化为面向 Kubernetes 的 Redis Enterprise Operator。 

对于需要更大规模地管理 Kubernetes 中的 Redis 实例的企业来说，Operator 是一个工具。它控制 Redis 集群的供应、扩展和可用性，并管理任何基础设施中的容器的生命周期。 

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

借助 Helm 图表，团队可以快速启动并运行应用程序，并依靠该操作员来确保应用程序生命周期的每个阶段都拥有继续运行所需的资源。 

简而言之，Redis Enterprise Kubernetes 操作员通过确保集群始终拥有实现最佳性能所需的一切来做到将众口难调的人维持一致。

常见问题解答

在 Kubernetes 上的 Redis Enterprise 常见问题解答中找到更多问题的答案。