高级 Helm 技术

本节解释了使用 Helm 的各种高级功能和技术。本节中的信息适用于希望对图表和版本进行高级定制和操作的 Helm "高级用户"。这些高级功能都有其自己的权衡和注意事项,因此每个功能都必须谨慎使用,并对 Helm 有深入的了解。换句话说,请记住 彼得·帕克原则

渲染后处理

渲染后处理使图表安装程序能够在 Helm 安装渲染后的清单之前,手动操作、配置和/或验证渲染后的清单。这允许具有高级配置需求的用户能够使用诸如 kustomize 之类的工具应用配置更改,而无需分叉公共图表或要求图表维护者为软件指定所有配置选项。在企业环境中注入常用工具和辅助程序,或在部署之前分析清单,也有一些用例。

先决条件

  • Helm 3.1+

用法

渲染后处理器可以是任何可执行文件,它接受 STDIN 上的渲染后的 Kubernetes 清单,并在 STDOUT 上返回有效的 Kubernetes 清单。它应该在发生错误时返回非 0 的退出代码。这是两个组件之间的唯一 "API"。它允许您在渲染后处理过程中进行高度灵活的操作。

渲染后处理器可与 installupgradetemplate 一起使用。要使用渲染后处理器,请使用 --post-renderer 标志,并在其中指定要使用的渲染器可执行文件的路径

$ helm install mychart stable/wordpress --post-renderer ./path/to/executable

如果路径不包含任何分隔符,它将在 $PATH 中搜索,否则它会将任何相对路径解析为完全限定路径

如果您希望使用多个渲染后处理器,请在一个脚本中或在您构建的任何二进制工具中将它们全部调用。在 bash 中,这将与 renderer1 | renderer2 | renderer3 一样简单。

您可以查看一个使用 kustomize 作为渲染后处理器的示例 此处

注意事项

在使用渲染后处理器时,有几件重要的事情需要牢记。其中最重要的是,当使用渲染后处理器时,所有修改该版本的人员 **必须** 使用相同的渲染器才能获得可重复的构建。此功能的目的是允许任何用户切换他们使用的渲染器或停止使用渲染器,但这应该是有意为之,以避免意外修改或数据丢失。

另一个重要事项是安全问题。如果您正在使用渲染后处理器,您应该确保它来自可靠来源(就像任何其他任意可执行文件一样)。不建议使用不可信或未经验证的渲染器,因为它们可以完全访问渲染后的模板,这些模板通常包含秘密数据。

自定义渲染后处理器

在 Go SDK 中使用渲染后处理步骤可以提供更大的灵活性。任何渲染后处理器只需要实现以下 Go 接口

type PostRenderer interface {
    // Run expects a single buffer filled with Helm rendered manifests. It
    // expects the modified results to be returned on a separate buffer or an
    // error if there was an issue or failure while running the post render step
    Run(renderedManifests *bytes.Buffer) (modifiedManifests *bytes.Buffer, err error)
}

有关使用 Go SDK 的更多信息,请参阅 Go SDK 部分

Go SDK

Helm 3 推出了一个完全重构的 Go SDK,以在构建使用 Helm 的软件和工具时提供更好的体验。完整的文档可在 https://pkg.go.dev/helm.sh/helm/v3 找到,但以下是一些最常用包的简要概述和一个简单的示例。

包概述

这是一个最常用包的列表,以及对每个包的简单解释

  • pkg/action:包含执行 Helm 操作的主要 "客户端"。这是 CLI 在后台使用的同一个包。如果您只需要从另一个 Go 程序执行基本的 Helm 命令,那么这个包适合您
  • pkg/{chart,chartutil}:用于加载和操作图表的方法和助手
  • pkg/cli 及其子包:包含标准 Helm 环境变量的所有处理程序,其子包包含输出和值文件处理
  • pkg/release:定义 Release 对象和状态

显然,除了这些之外还有许多其他包,所以请查看文档以了解更多信息!

简单示例

这是一个使用 Go SDK 执行 helm list 的简单示例

package main

import (
    "log"
    "os"

    "helm.sh/helm/v3/pkg/action"
    "helm.sh/helm/v3/pkg/cli"
)

func main() {
    settings := cli.New()

    actionConfig := new(action.Configuration)
    // You can pass an empty string instead of settings.Namespace() to list
    // all namespaces
    if err := actionConfig.Init(settings.RESTClientGetter(), settings.Namespace(), os.Getenv("HELM_DRIVER"), log.Printf); err != nil {
        log.Printf("%+v", err)
        os.Exit(1)
    }

    client := action.NewList(actionConfig)
    // Only list deployed
    client.Deployed = true
    results, err := client.Run()
    if err != nil {
        log.Printf("%+v", err)
        os.Exit(1)
    }

    for _, rel := range results {
        log.Printf("%+v", rel)
    }
}

存储后端

Helm 3 将默认版本信息存储更改为版本所在命名空间中的 Secrets。Helm 2 默认将版本信息存储为 Tiller 实例命名空间中的 ConfigMaps。以下各节将介绍如何配置不同的后端。此配置基于 HELM_DRIVER 环境变量。它可以设置为以下值之一:[configmap, secret, sql]

ConfigMap 存储后端

要启用 ConfigMap 后端,您需要将环境变量 HELM_DRIVER 设置为 configmap

您可以在 shell 中按如下方式设置它

export HELM_DRIVER=configmap

如果您想从默认后端切换到 ConfigMap 后端,则必须自己进行迁移。您可以使用以下命令检索版本信息

kubectl get secret --all-namespaces -l "owner=helm"

生产说明:版本信息包括图表和值文件的内容,因此可能包含需要保护免受未经授权访问的敏感数据(如密码、私钥和其他凭据)。在管理 Kubernetes 授权时,例如使用 RBAC,可以向 ConfigMap 资源授予更广泛的访问权限,同时限制对 Secret 资源的访问权限。例如,默认的 面向用户的角色 "view" 授予对大多数资源的访问权限,但不能访问 Secrets。此外,可以将机密数据配置为 加密存储。如果您决定切换到 ConfigMap 后端,请牢记这一点,因为它可能会暴露应用程序的敏感数据。

SQL 存储后端

存在一个 beta SQL 存储后端,它将版本信息存储在 SQL 数据库中。

如果您的版本信息超过 1MB(在这种情况下,由于 Kubernetes 底层 etcd 键值存储的内部限制,它无法存储在 ConfigMaps/Secrets 中),那么使用这样的存储后端将特别有用。

要启用 SQL 后端,您需要部署一个 SQL 数据库并将环境变量 HELM_DRIVER 设置为 sql。数据库详细信息通过环境变量 HELM_DRIVER_SQL_CONNECTION_STRING 设置。

您可以在 shell 中按如下方式设置它

export HELM_DRIVER=sql
export HELM_DRIVER_SQL_CONNECTION_STRING=postgresql://helm-postgres:5432/helm?user=helm&password=changeme

注意:目前仅支持 PostgreSQL。

生产说明:建议您

  • 使您的数据库适合生产环境。对于 PostgreSQL,请参阅 服务器管理 文档以了解更多详细信息
  • 启用 权限管理 以镜像 Kubernetes RBAC 的版本信息

如果您想从默认后端切换到 SQL 后端,则必须自己进行迁移。您可以使用以下命令检索版本信息

kubectl get secret --all-namespaces -l "owner=helm"