基于微服务的现代云原生应用程序通常使用来自开源软件的应用程序运行时和支持服务，例如缓存、数据库、日志记录、监视、消息传递等。这种做法背后的关键目标是标准化、社区杠杆和上市时间。但是在企业软件开发中使用开源有其自身的挑战。虽然可以实现速度和敏捷性，但如果开源依赖项存在漏洞并且未提前扫描，则安全性和合规性状况可能会受到影响。
这篇文章提供了有关如何使用 Helm 图表在基于 Kubernetes 的环境中以安全、可靠和一致的方式大规模自定义、部署和管理开源软件的指导。Helm 是一个 Kubernetes 包管理器，它使用 Helm 图表促进 Kubernetes 工件的打包、部署和生命周期管理。开源 Helm 项目由云原生计算基金会支持。
在这篇文章中，我们将使用 Apache Kafka Helm 图表，尽管我们将解释的过程可以应用于任何 Helm 图表。Apache Kafka 是一个社区分布式事件流平台，每天能够大规模处理数万亿个事件。Apache Kafka 的常见用例包括消息传递、网站活动跟踪、指标、日志聚合、流处理和事件溯源。
为了演示如何自定义、部署和管理开源 Kafka Helm 图表，我们将使用以下内容：
- 用于配置和自定义 Helm 目录的 VMware Tanzu 应用程序目录
- 用于部署 Helm 图表的 Helm 命令行界面 （CLI）
- 掌舵 CLI 以管理已部署工作负载的生命周期
- 可观测性集成，为工作负载提供日志记录、监控和扩展
部署概述
对于下图，我们使用两个关键角色：开发人员和操作员。开发人员角色是典型的微服务开发人员，负责设计、实现业务逻辑以及所有相应的持续集成 （CI） 活动。操作员角色负责部署、标准化和管理 Kubernetes 环境的生命周期以及在其上运行的微服务。实际上，每个组织中都有许多更细粒度的角色，但为了简单起见，我们使用这两个角色。
使用 Tanzu 应用程序目录服务在 Kubernetes 集群中部署基于 Helm 的工作负载的典型工作流如下所示：
操作员了解团队的开发需求。她使用本文档中描述的步骤在 Tanzu 应用程序目录中设置专用目录。可以创建可遵循企业安全性和隔离规则的自定义目录。例如，操作员可能决定为各种业务应用程序使用的前端组件创建一个应用程序目录，为集成组件创建另一个目录，为后端组件创建另一个目录。或者，可以为为不同业务部门部署的应用程序创建不同的自定义目录。运营商通常寻求在隔离和标准化之间取得适当的平衡。
操作员使用特选的 Helm 图表填充目录。为了创建这些精选的 Helm 图表，操作员指定了需要在 Kubernetes 中部署的基本操作系统映像和所需的开源软件。如下图所示，Tanzu 应用程序目录服务附带了用于基本操作系统映像的标准 Linux 发行版。或者，正如企业方案中常见的那样，操作员可以导入根据其企业标准构建的自定义基础 OS 映像，以跨所有工作负载进行部署。
选择基本操作系统和相应的软件包后，Tanzu 应用程序目录服务将生成并打包特选的 Helm 图表。例如，下面是 Apache Kafka Helm 图表的摘要信息。
Tanzu 应用程序目录服务还会生成验证、生成和测试报告。这些与映像一起打包。这种测试和验证自动化通过将打包合规软件所花费的时间重新分配给创造业务价值，从而提高了开发人员的工作效率。例如，Kafka Helm 图表产生：
- 验证报告，包括功能和集成测试
- 构建报告，包括有关资产内容的详细信息
Kafka 的 Asset-spec.json 如下所示。如您所见，它枚举了软件资产及其相应的可审核详细信息，可用于跟踪已部署的软件清单，以及标准化企业内给定范围内的软件组件使用。
Kafka 版本的集成测试结果如下所示。集成测试在所有云提供商上运行，包括Azure AKS，Google Cloud的Google Kubernetes Engine和本地VMware Tanzu Kubernetes Grid。
这些经过精心策划、审查和测试的 Helm 图表映像将推送到专用 Helm 注册表。Tanzu 应用程序目录服务监视上游社区存储库中容器映像中使用的开源软件和基本操作系统映像的更新，并根据需要重新生成 Helm 图表，从而使它们保持最新。可以使用标准 Helm CLI 工具更新已部署的 Helm 图表实例（称为 Helm 版本）。
您可以使用 Tanzu 应用程序目录 CLI 查看 Kafka Helm 图表元数据。例如，可以通过 Kafka 应用程序 ID 获取 Kafka 元数据，如下所示。Tanzu 应用程序目录 CLI 可以通过此文档下载。
掌舵图部署
我们将使用 Helm CLI 将这个由 Tanzu 应用程序目录服务创建的经过审查、测试和策划的 Kafka Helm 图表部署到标准 Kubernetes 集群。
我们将首先添加 Helm 图表存储库。
我们还启用了 Zookeeper 图表安装以及 Kafka。用于Zookeeper的配置如下。请注意，如果未指定存储类，则使用默认的存储类。
接下来，我们部署 Kafka Helm 图表。
然后我们创建 Helm 发布 kafka-my-demo。
为了部署并运行 Kafka 客户端，我们将部署 Kafka 客户端 Pod。
部署并运行 Kafka 客户端后，将创建以下 Pod 和持久卷声明。Helm CLI 还部署了 Zookeeper。
让我们执行到 Kafka 客户端 pod 并启动 Kafka 生产者和消费者。
为了确保我们的部署正常工作，我们将测试向生产者发布消息，并确保使用者通过订阅主题来接收这些消息。
然后，Kafka 使用者订阅此主题并检索其上发布的消息。
我们现在已经成功部署了 Apache Kafka 企业级 Helm 图表。
企业级 Helm 图表部署最佳实践
为确保成功部署企业级 Helm 图表，我们建议执行以下步骤：
- 创建适当的基于角色的访问控制，用于管理 Kubernetes 工件，包括 Helm 图表
- 参数化 Helm 图表（通过 values.yaml），以确保容器以非根身份运行
- 使用内置的 Kubernetes 实践进行活动性和就绪性探测，在向 Pod 发送流量之前检查它们的运行状况
- 确保容器到容器的流量使用 TLS 进行加密
- 将部署的图表与日志记录和监视工具集成
这些最佳实践可以在这个开源的Apache Kafka图表中看到。若要确保适当的参数化，请参阅 Helm 图表的 values.yaml 文件。默认情况下，由 Kafka Helm 图表创建的容器以非根用户身份运行。启用 serviceAccount.create 可为 Kafka Pod 启用适当的服务帐户创建，进而可用于实施适当的基于角色的访问控制。
您还可以配置活动和就绪情况探测。检查 Kafka 部署是否已准备好为客户端请求提供服务，以及 。并设置为启用 TLS 加密，以便 Kafka pod 与其他服务进行通信。set livenessProbe.enabledreadinessProbe.enabledauth.tls.autoGenerated: true
要部署具有三个 Kafka 代理和 TLS 身份验证的 Kafka 集群，以便进行代理间和客户端通信，请使用以下参数。
启用参数以创建独立的 Kafka 导出器以公开 Kafka 指标。要向 Prometheus 公开 JMX 指标，请使用参数 。要启用 Zookeeper 图表指标，请使用参数 .metrics.kafka.enabled: truemetrics.jmx.enabled : truezookeeper.metrics.enabled: true
已部署 Helm 图表的生命周期管理
Helm CLI 支持升级和删除已部署的 Helm 实例（称为 Helm 版本）。由于 Tanzu 应用程序目录通过监视图表依赖项的上游修订来构建较新版本的 Helm 图表，因此操作员可以通过升级现有部署来部署较新版本的 Helm 图表。
您还可以升级、删除和启用 Kafka 的生命周期管理活动。
升级生命周期管理活动
使用以下 Helm CLI 命令升级版本。
删除发行版
使用以下 Helm 命令删除发布。如果要永久删除部署和所有数据，还需要删除永久性卷声明。默认情况下，Helm 不会删除永久性卷声明，以防止意外丢失数据。
实现操作化
启用参数以创建独立的 Kafka Prometheus 导出器以公开 Kafka 指标，然后 Prometheus 可以抓取这些指标。要向 Prometheus 公开 JMX 指标，请使用参数 。要启用 Zookeeper 图表指标，请使用参数 .metrics.kafka.enabled: truemetrics.jmx.enabled : truezookeeper.metrics.enabled: true
虽然 Tanzu 应用程序目录允许您构建具有审计就绪功能的精选 Helm 图表，但标准 Helm 工具允许您部署和管理 Helm 图表的生命周期，并扩展它们打包的开源软件。