如何在 10 分钟内制作 Helm Chart

在约 10 分钟内为 Kubernetes 编写一个简单的 Helm Chart。
212 位读者喜欢这篇文章。
People working together to build
图片来源

Opensource.com

我日常工作的大部分时间都涉及到创建、修改和部署 Helm Chart，以管理应用程序的部署。Helm 是 Kubernetes 的应用程序包管理器，它协调应用程序的下载、安装和部署。Helm Chart 是我们将应用程序定义为相关 Kubernetes 资源集合的方式。

那么，为什么有人会使用 Helm 呢？Helm 通过模板化的方法，使 Kubernetes 内部应用程序的部署管理更加容易。所有 Helm Chart 都遵循相同的结构，同时仍然具有足够的灵活性来表示您可以在 Kubernetes 上运行的任何类型的应用程序。Helm 还支持版本控制，因为部署需求肯定会随着时间的推移而变化。另一种选择是使用多个配置文件，您需要手动将这些文件应用于 Kubernetes 集群以启动应用程序。如果我们从看到基础设施即代码中学到任何东西，那就是手动流程不可避免地会导致错误。Helm Chart 使我们有机会将同样的教训应用于 Kubernetes 的世界。

在本示例中，我们将演练如何将 Helm 与 minikube（Kubernetes 的单节点测试环境）一起使用。我们将创建一个小型 Nginx Web 服务器应用程序。在本示例中，我的 Linux 笔记本电脑上安装了 minikube 1.9.2 版本和 Helm 3.0.0 版本。要进行设置，请执行以下操作。

  • 按照此处优秀的文档下载并配置 minikube。
  • 使用您喜欢的软件包管理器此处列出或从版本手动下载并配置 Helm。

创建 Helm Chart

首先确认我们已安装必备组件：

$ which helm ## this can be in any folder as long as it returns in the path
/usr/local/bin/helm 
$ minikube status ## if it shows Stopped, run `minikube start`
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

启动新的 Helm Chart 需要一个简单的命令

$ helm create mychartname

在本教程中，将 Chart 命名为 buildachart

$ helm create buildachart
Creating buildachart
$ ls buildachart/
Chart.yaml   charts/      templates/   values.yaml

检查 Chart 的结构

现在您已经创建了 Chart，请查看其结构以了解其内部结构。您看到的头两个文件—Chart.yaml 和 values.yaml—定义了 Chart 是什么以及部署时将包含哪些值。

查看 Chart.yaml，您可以看到 Helm Chart 结构的轮廓

apiVersion: v2
name: buildachart
description: A Helm chart for Kubernetes

# A chart can be either an 'application' or a 'library' chart.
#
# Application charts are a collection of templates that can be packaged into versioned archives
# to be deployed.
#
# Library charts provide useful utilities or functions for the chart developer. They're included as
# a dependency of application charts to inject those utilities and functions into the rendering
# pipeline. Library charts do not define any templates and therefore cannot be deployed.
type: application

# This is the chart version. This version number should be incremented each time you make changes
# to the chart and its templates, including the app version.
version: 0.1.0

# This is the version number of the application being deployed. This version number should be
# incremented each time you make changes to the application.
appVersion: 1.16.0

第一部分包括 Chart 正在使用的 API 版本（这是必需的）、Chart 的名称以及 Chart 的描述。下一部分描述了 Chart 的类型（默认为应用程序）、您将部署的 Chart 版本以及应用程序版本（您进行更改时应递增）。

Chart 最重要的部分是模板目录。它包含将部署到集群中的应用程序的所有配置。如下所示，此应用程序具有基本部署、Ingress、服务帐户和服务。此目录还包括一个测试目录，其中包含应用程序连接的测试。这些应用程序功能的每一个在 templates/ 下都有其自己的模板文件

$ ls templates/
NOTES.txt            _helpers.tpl         deployment.yaml      ingress.yaml         service.yaml         serviceaccount.yaml  tests/

更多关于 Kubernetes 的信息

还有一个名为 charts 的目录，它是空的。它允许您添加部署应用程序所需的依赖 Chart。应用程序的一些 Helm Chart 最多有四个额外的 Chart 需要与主应用程序一起部署。发生这种情况时，values 文件将使用每个 Chart 的值进行更新，以便同时配置和部署应用程序。这是一种更高级的配置（我不会在本入门文章中介绍），因此请将 charts/ 文件夹留空。

理解并编辑值

模板文件使用格式设置，该格式从 values.yaml 文件收集部署信息。因此，要自定义 Helm Chart，您需要编辑 values 文件。默认情况下，values.yaml 文件如下所示

# Default values for buildachart.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

replicaCount: 1

image:
  repository: nginx
  pullPolicy: IfNotPresent

imagePullSecrets: []
nameOverride: ""
fullnameOverride: ""

serviceAccount:
  # Specifies whether a service account should be created
  create: true
  # Annotations to add to the service account
  annotations: {}
  # The name of the service account to use.
  # If not set and create is true, a name is generated using the fullname template
  name:

podSecurityContext: {}
  # fsGroup: 2000

securityContext: {}
  # capabilities:
  #   drop:
  #   - ALL
  # readOnlyRootFilesystem: true
  # runAsNonRoot: true
  # runAsUser: 1000

service:
  type: ClusterIP
  port: 80

ingress:
  enabled: false
  annotations: {}
    # kubernetes.io/ingress.class: nginx
    # kubernetes.io/tls-acme: "true"
  hosts:
    - host: chart-example.local
      paths: []
  tls: []
  #  - secretName: chart-example-tls
  #    hosts:
  #      - chart-example.local

resources: {}
  # We usually recommend not to specify default resources and to leave this as a conscious
  # choice for the user. This also increases chances charts run on environments with little
  # resources, such as Minikube. If you do want to specify resources, uncomment the following
  # lines, adjust them as necessary, and remove the curly braces after 'resources:'.
  # limits:
  #   cpu: 100m
  #   memory: 128Mi
  # requests:
  #   cpu: 100m
  #   memory: 128Mi

nodeSelector: {}

tolerations: []

affinity: {}

基本配置

从顶部开始，您可以看到 replicaCount 自动设置为 1，这意味着只会启动一个 Pod。此示例只需要一个 Pod，但您可以看到告诉 Kubernetes 运行多个 Pod 以实现冗余是多么容易。

image 部分有两个需要注意的地方：您从中拉取镜像的 repository 和 pullPolicy。pullPolicy 设置为 IfNotPresent；这意味着如果集群中尚不存在该镜像，则镜像将下载新版本的镜像。还有另外两个选项：Always，这意味着它将在每次部署或重启时拉取镜像（我始终建议使用此选项以防镜像失败），以及 Latest，它将始终拉取可用的最新版本的镜像。如果您信任您的镜像仓库与您的部署环境兼容，则 Latest 可能很有用，但情况并非总是如此。

将值更改为 Always。

之前

image:
  repository: nginx
  pullPolicy: IfNotPresent

之后

image:
  repository: nginx
  pullPolicy: Always

命名和密钥

接下来，查看 Chart 中的覆盖。第一个覆盖是 imagePullSecrets，它是一个用于拉取密钥的设置，例如您生成的密码或 API 密钥，作为私有注册表的凭据。接下来是 nameOverride 和 fullnameOverride。从您运行 helm create 的那一刻起，它的名称 (buildachart) 就被添加到许多配置文件中—从上面的 YAML 文件到 templates/helper.tpl 文件。如果您需要在创建 Chart 后重命名 Chart，则此部分是执行此操作的最佳位置，这样您就不会错过任何配置文件。

使用覆盖更改 Chart 的名称。

之前

imagePullSecrets: []
nameOverride: ""
fullnameOverride: ""

之后

imagePullSecrets: []
nameOverride: "cherry-awesome-app"
fullnameOverride: "cherry-chart"

帐户

服务帐户为在集群内部 Pod 中运行的用户提供用户身份。如果留空，则名称将根据使用 helpers.tpl 文件的全名生成。我建议始终设置服务帐户，以便应用程序将直接与 Chart 中控制的用户关联。

作为管理员，如果您使用默认服务帐户，您将拥有过少或过多的权限，因此请更改此设置。

之前

serviceAccount:
  # Specifies whether a service account should be created
  create: true
  # Annotations to add to the service account
  annotations: {}
  # The name of the service account to use.
  # If not set and create is true, a name is generated using the fullname template
  Name:

之后

serviceAccount:
  # Specifies whether a service account should be created
  create: true
  # Annotations to add to the service account
  annotations: {}
  # The name of the service account to use.
  # If not set and create is true, a name is generated using the fullname template
  Name: cherrybomb

安全性

您可以配置 Pod 安全性以设置文件系统组类型或可以使用和不能使用的用户的限制。理解这些选项对于保护 Kubernetes Pod 非常重要，但对于本示例，我将保持不变。

podSecurityContext: {}
  # fsGroup: 2000

securityContext: {}
  # capabilities:
  #   drop:
  #   - ALL
  # readOnlyRootFilesystem: true
  # runAsNonRoot: true
  # runAsUser: 1000

网络

此 Chart 中有两种不同的网络选项。一种使用具有 ClusterIP 地址的本地服务网络，该地址在集群内部 IP 上公开服务。选择此值会使与您的应用程序关联的服务只能从集群内部访问（并通过默认设置为 false 的 ingress 访问）。另一个网络选项是 NodePort，它在每个 Kubernetes 节点的 IP 地址上通过静态分配的端口公开服务。建议对运行 minikube 使用此选项，因此在本操作指南中使用它。

之前

service:
  type: ClusterIP
  port: 80

ingress:
  enabled: false

之后

service:
  type: NodePort
  port: 80

ingress:
  enabled: false

资源

Helm 允许您显式分配硬件资源。您可以配置 Helm Chart 可以请求的最大资源量以及它可以接收的最高限制。由于我在笔记本电脑上使用 Minikube，因此我将通过删除花括号和井号来将注释转换为命令来设置一些限制。

之前

resources: {}
  # We usually recommend not to specify default resources and to leave this as a conscious
  # choice for the user. This also increases chances charts run on environments with little
  # resources, such as Minikube. If you do want to specify resources, uncomment the following
  # lines, adjust them as necessary, and remove the curly braces after 'resources:'.
  # limits:
  #   cpu: 100m
  #   memory: 128Mi
  # requests:
  #   cpu: 100m
  #   memory: 128Mi

之后

resources:
  # We usually recommend not to specify default resources and to leave this as a conscious
  # choice for the user. This also increases chances charts run on environments with little
  # resources, such as Minikube. If you do want to specify resources, uncomment the following
  # lines, adjust them as necessary, and remove the curly braces after 'resources:'.
   limits:
     cpu: 100m
     memory: 128Mi
   requests:
     cpu: 100m
     memory: 128Mi

容忍度、节点选择器和亲和性

最后三个值基于节点配置。虽然我无法在本地配置中使用它们中的任何一个，但我仍然会解释它们的用途。

当您想将应用程序的一部分分配给 Kubernetes 集群中的特定节点时，nodeSelector 会派上用场。如果您有特定于基础设施的应用程序，则设置节点选择器名称并在 Helm Chart 中匹配该名称。然后，当部署应用程序时，它将与与选择器匹配的节点关联。

容忍度、污点和 亲和性 协同工作以确保 Pod 在不同的节点上运行。节点亲和性是 Pod 的属性，它将 Pod 吸引到一组节点（作为首选项或硬性要求）。污点则相反—它们允许节点排斥一组 Pod。

实际上，如果节点被污点，则意味着它无法正常工作或可能没有足够的资源来容纳应用程序部署。容忍度设置为调度程序监视的键/值对，以确认节点将与部署一起工作。

节点亲和性在概念上类似于 nodeSelector：它允许您根据节点上的标签约束 Pod 有资格调度的节点。但是，标签有所不同，因为它们匹配适用于调度的规则。

nodeSelector: {}

tolerations: []

affinity: {}

部署，起航！

现在您已经对 Helm Chart 进行了必要的修改，您可以使用 Helm 命令部署它，向 Chart 添加名称点，添加值文件，并将其发送到命名空间

$ helm install my-cherry-chart buildachart/ --values buildachart/values.yaml 
Release “my-cherry-chart” has been upgraded. Happy Helming!

该命令的输出将为您提供连接到应用程序的后续步骤，包括设置端口转发，以便您可以从本地主机访问该应用程序。要按照这些说明操作并连接到 Nginx 负载均衡器

$ export POD_NAME=$(kubectl get pods -l "app.kubernetes.io/name=buildachart,app.kubernetes.io/instance=my-cherry-chart" -o jsonpath="{.items[0].metadata.name}")
$ echo "Visit http://127.0.0.1:8080 to use your application"
Visit http://127.0.0.1:8080 to use your application
$ kubectl port-forward $POD_NAME 8080:80
Forwarding from 127.0.0.1:8080 -> 80
Forwarding from [::1]:8080 -> 80

查看已部署的应用程序

要查看您的应用程序，请打开您的 Web 浏览器

Nginx welcome screen

恭喜！您已使用 Helm Chart 部署了 Nginx Web 服务器！

在您探索 Helm Chart 可以做什么时，有很多东西需要学习。如果您想仔细检查您的工作，请访问我在 GitHub 上的示例存储库。

接下来阅读什么
标签
Kubernetes
杰西卡·切里
User profile image.
技术游民，从事我能找到的任何工作。IT 领域孤岛预防的倡导者，与所有团队共享信息的重要性。相信教育所有人并开源开发。热爱所有技术事物。关于 K8s、混沌以及我可以找到的任何新的和闪亮的东西！Mastodon ID
更多关于我

3 条评论

Avatar
拉詹·巴德瓦杰 | 2020 年 5 月 14 日
尚无读者喜欢这篇文章。

Helm v2 配置的迁移是否可能？

Avatar
拉詹·巴德瓦杰 | 2020 年 5 月 14 日
尚无读者喜欢这篇文章。

我的意思是我想将 Helm V2 迁移到 V3

Avatar
MG | 2020 年 7 月 30 日
尚无读者喜欢这篇文章。

感谢这份简单的指南。非常有帮助！

相关内容

Creative Commons License本作品根据知识共享署名-相同方式共享 4.0 国际许可协议获得许可。
© . All rights reserved.