Using Helm and Kubernetes – 使用Helm和Kubernetes

最后修改: 2019年 3月 10日

中文/混合/英文(键盘快捷键:t)

1. Overview

1.概述

Helm is a package manager for Kubernetes applications. In this tutorial, we’ll understand the basics of Helm and how they form a powerful tool for working with Kubernetes resources.

Helm是一个用于Kubernetes应用程序的软件包管理器。在本教程中,我们将了解Helm的基础知识,以及它们如何形成一个强大的工具来处理Kubernetes资源。

Over the past years, Kubernetes has grown tremendously, and so has the ecosystem supporting it. Recently, Helm has been awarded the graduated status by Cloud Native Computing Foundation (CNCF), which shows its growing popularity amongst Kubernetes users.

在过去的几年里,Kubernetes得到了巨大的发展,支持它的生态系统也是如此。最近,Helm被云原生计算基金会(CNCF)授予毕业资格,这表明它在Kubernetes用户中越来越受欢迎。

2. Background

2. 背景

Although these terms are fairly common these days, particularly amongst those working with cloud technologies, let’s go through them quickly for those unaware:

尽管这些术语如今已经相当普遍,尤其是在那些从事云技术工作的人中间,但让我们为那些不了解的人快速浏览一下它们。

  1. Container: Container refers to operating system-level virtualization. Multiple containers run within an operating system in isolated user spaces. Programs running within a container have access only to resources assigned to the container.
  2. Docker: Docker is a popular program to create and run containers. It comes with Docker Daemon, which is the main program managing containers. Docker Daemon offers access to its features through Docker Engine API, used by Docker Command-Line Interface (CLI). Please refer to this article for a more detailed description of Docker.
  3. Kubernetes: Kubernetes is a popular container orchestration program. Although it’s designed to work with different containers, Docker is most often used. It offers a wide selection of features, including deployment automation, scaling, and operations across a cluster of hosts. There is excellent coverage of Kubernetes in this article for further reference.

3. Helm Architecture

3.舵手结构

Helm has undergone a significant architecture uplift as part of Helm 3. It has some of the significant and long-awaited changes as compared to Helm 2. Apart from packing a new set of capabilities, Helm 3 also features changes in its internal plumbing. We’ll examine some of these changes.

作为Helm 3的一部分,Helm经历了一次重大的架构提升。与Helm 2相比,它有一些人们期待已久的重大变化。除了包含一系列新的功能外,Helm 3还对其内部管道进行了修改。我们将研究其中的一些变化。

Helm 2 was primarily on a client-server architecture that comprises of a client and an in-cluster server:

Helm 2主要采用客户机-服务器架构,由一个客户机和一个集群内的服务器组成。

  • Tiller Server: Helm manages the Kubernetes application through Tiller Server installed within a Kubernetes cluster. Tiller interacts with the Kubernetes API server to install, upgrade, query, and remove Kubernetes resources.
  • Helm Client: Helm provides a command-line interface for users to work with Helm Charts. It is responsible for interacting with the Tiller server to perform various operations like install, upgrade and rollback charts.

Helm 3 has moved onto a completely client-only architecture, where the in-cluster server has been removed:

Helm 3已经转为完全的纯客户端架构,其中集群内的服务器已经被删除。

As we can see, the client in Helm 3 works pretty much the same but interacts directly with the Kubernetes API server instead of the Tiller server. This move has simplified the architecture of Helm and allowed it to leverage the Kubernetes user cluster security.

我们可以看到,Helm 3中的客户端工作原理基本相同,但直接与Kubernetes API服务器互动,而不是Tiller服务器。此举简化了Helm的架构,使其能够利用Kubernetes用户集群的安全性。

4. Helm Charts, Releases, and Repositories

4.舵手图、发布和储存库

Helm manages Kubernetes resource packages through Charts. Charts are basically the packaging format for Helm. The chart infrastructure has also gone some changes as part of Helm 3 compared to Helm 2.

Helm通过Charts管理Kubernetes资源包。Charts基本上是Helm的打包格式。与Helm 2相比,作为Helm 3的一部分,图表基础设施也有了一些变化。

We’ll see more about charts and the changes in Helm 3 as we create them shortly. But for now, a chart is nothing but a set of information necessary to create a Kubernetes application, given a Kubernetes cluster:

我们将看到更多关于图表和Helm 3的变化,因为我们很快就会创建它们。但现在,图表只不过是在给定Kubernetes集群的情况下,创建Kubernetes应用程序所需的一组信息。

  • A chart is a collection of files organized in a specific directory structure
  • The configuration information related to a chart is managed in the configuration
  • Finally, a running instance of a chart with a specific config is called a release

Helm 3 also introduced the concept of library charts. Basically, library charts enable support for common charts that we can use to define chart primitives or definitions. This can help to share snippets of code that we can re-use across charts.

Helm 3还引入了库图表的概念。基本上,库图表使我们能够支持常用的图表,我们可以用它来定义图表基元或定义。这有助于共享代码片段,我们可以在图表之间重复使用。

Helm tracks an installed chart in the Kubernetes cluster using releases. This allows us to install a single chart multiple times with different releases in a cluster. Until Helm 2, releases were stored as ConfigMaps or Secrets in the cluster under the Tiller namespace. Starting with Helm 3, releases are stored as Secrets by default in the namespace of the release directly.

Helm 使用版本追踪Kubernetes集群中安装的图表。这使得我们可以在集群中用不同的版本多次安装一个图表。在Helm 2之前,版本被存储为Tiller命名空间下集群中的ConfigMaps或Secrets。从Helm 3开始,发布版本默认为Secrets,直接存储在发布版本的命名空间中。

Finally, we can share charts as archives through repositories. It is basically a location where packages charts can be stored and shared. There is a distributed community chart repository by the name Artifact Hub where we can collaborate. We can also create our own private chart repositories. We can add any number of chart repositories to work with.

最后,我们可以通过资源库将图表作为档案共享。它基本上是一个可以存储和共享软件包图表的位置。有一个名为Artifact Hub的分布式社区图表库,我们可以在那里进行协作。我们还可以创建我们自己的私人图表库。我们可以添加任何数量的图表存储库来工作。

5. Prerequisites

5.先决条件

We’ll need a few things to be set up beforehand to develop our first Helm chart.

我们需要事先设置一些东西来制定我们的第一张舵手图。

Firstly, to begin working with Helm, we need a Kubernetes cluster. For this tutorial, we’ll use Minikube, which offers an excellent way to work with a single-node Kubernetes cluster locally. On Windows, it’s now possible to use Hyper-V as the native Hypervisor to run Minikube. Refer to this article to understand setting up Minikube in more detail.

首先,要开始使用Helm,我们需要一个Kubernetes集群。在本教程中,我们将使用Minikube,它提供了一种在本地使用单节点Kubernetes集群的绝佳方式。在Windows上,现在可以使用Hyper-V作为本地管理程序来运行Minikube。请参考这篇文章,以更详细地了解Minikube的设置

It is often advisable to install the most compatible version of the Kubernetes as supported by Helm. We should also install and configure the Kubernetes command-line tool kubectl, enabling us to work with our cluster efficiently.

通常建议安装最兼容的Kubernetes版本,因为由Helm支持。我们还应该安装和配置Kubernetes命令行工具kubectl,使我们能够有效地使用我们的集群。

And, we’ll need a basic application to manage within the Kubernetes cluster. For this tutorial, we’ll use a simple Spring Boot application packaged as a Docker container. For a more detailed description of how to package such an application as a Docker container, please refer to this article.

而且,我们需要一个基本的应用程序来管理Kubernetes集群。在本教程中,我们将使用一个简单的Spring Boot应用打包成Docker容器。有关如何将此类应用程序打包成Docker容器的更详细描述,请参考这篇文章

6. Installing Helm

6.安装Helm

There are several ways to install Helm that are neatly described on the official install page on Helm. The quickest way to install helm on Windows is using Chocolaty, a package manager for Windows platforms.

有几种安装Helm的方法,在Helm的官方安装页面上都有整齐的描述。在Windows上安装Helm的最快方法是使用Chocolaty,这是一个用于Windows平台的软件包管理器。

Using Chocolaty, it’s a simple one-line command to install Helm:

使用Chocolaty,这是一个简单的单行命令来安装Helm。

choco install kubernetes-helm

This installs the Helm client locally. This also provides us with the Helm command-line tool that we’ll use to work with Helm in this tutorial.

这就在本地安装了Helm客户端。这也为我们提供了Helm命令行工具,我们将在本教程中使用该工具来处理Helm。

Before proceeding further, we should ensure that the Kubernetes cluster is running and accessible using the kubectl command:

在进一步行动之前,我们应该确保Kubernetes集群正在运行,并且可以使用kubectl 命令进行访问。

kubectl cluster-info

Now, until Helm 2, it was also necessary to initialize Helm. This effectively installs the Tiller server and sets up the Helm state onto a Kubernetes cluster. We could initialize Helm through the Helm CLI using the command:

现在,直到Helm 2,还需要初始化Helm。这实际上是在Kubernetes集群上安装Tiller服务器并设置Helm状态。我们可以通过Helm CLI使用以下命令初始化Helm。

helm init

But, starting with Helm 3, since there is no more Tiller server, it’s unnecessary to initialize Helm. In fact, this command has been removed. Consequently, the Helm state is created automatically when required.

但是,从Helm 3开始,由于不再有Tiller服务器,没有必要初始化Helm了。事实上,这个命令已被删除。因此,在需要时,Helm状态会自动创建。

7. Developing Our First Chart

7.制定我们的第一个图表

Now we are ready to develop our first Helm Chart with templates and values. We’ll use the Helm CLI that was installed earlier to perform some of the common activities related to a chart.

现在我们已经准备好用模板和数值开发我们的第一个Helm图表。我们将使用之前安装的Helm CLI来执行一些与图表相关的常见活动。

7.1. Creating a Chart

7.1.创建一个图表

The first step, of course, would be to create a new chart with a given name:

当然,第一步是创建一个有指定名称的新图表。

helm create hello-world

Please note that the name of the chart provided here will be the directory’s name where the chart is created and stored.

请注意,这里提供的图表名称将是创建和存储该图表的目录名称。

Let’s quickly see the directory structure created for us:

让我们快速看看为我们创建的目录结构。

hello-world /
  Chart.yaml
  values.yaml
  templates /
  charts /
  .helmignore

Let’s understand the relevance of these files and folders created for us:

让我们了解一下为我们创建的这些文件和文件夹的相关性。

  • Chart.yaml: This is the main file that contains the description of our chart
  • values.yaml: this is the file that contains the default values for our chart
  • templates: This is the directory where Kubernetes resources are defined as templates
  • charts: This is an optional directory that may contain sub-charts
  • .helmignore: This is where we can define patterns to ignore when packaging (similar in concept to .gitignore)

7.2. Creating Template

7.2.创建模板

If we see inside the template directory, we’ll notice that few templates for common Kubernetes resources have already been created for us:

如果我们看到模板目录里面,我们会注意到,几个常见的Kubernetes资源的模板已经为我们创建好了

hello-world /
  templates /
    deployment.yaml
    service.yaml
    ingress.yaml
    ......

We may need some of these and possibly other resources in our application, which we’ll have to create ourselves as templates.

在我们的应用程序中,我们可能需要其中的一些资源,也可能需要其他资源,我们必须自己创建模板。

For this tutorial, we’ll create a deployment and service to expose that deployment. Please note that the emphasis here is not to understand Kubernetes in detail. Hence we’ll keep these resources as simple as possible.

在本教程中,我们将创建一个部署和服务来暴露该部署。请注意,这里的重点不是要详细了解Kubernetes。因此,我们将尽可能地保持这些资源的简单性。

Let’s edit the file deployment.yaml inside the templates directory to look like:

让我们编辑deployment.yaml目录内的文件templates,使其看起来像。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "hello-world.fullname" . }}
  labels:
    app.kubernetes.io/name: {{ include "hello-world.name" . }}
    helm.sh/chart: {{ include "hello-world.chart" . }}
    app.kubernetes.io/instance: {{ .Release.Name }}
    app.kubernetes.io/managed-by: {{ .Release.Service }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app.kubernetes.io/name: {{ include "hello-world.name" . }}
      app.kubernetes.io/instance: {{ .Release.Name }}
  template:
    metadata:
      labels:
        app.kubernetes.io/name: {{ include "hello-world.name" . }}
        app.kubernetes.io/instance: {{ .Release.Name }}
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          ports:
            - name: http
              containerPort: 8080
              protocol: TCP

Similarly, let’s edit the file service.yaml to look like:

同样地,让我们编辑文件service.yaml,使其看起来像。

apiVersion: v1
kind: Service
metadata:
  name: {{ include "hello-world.fullname" . }}
  labels:
    app.kubernetes.io/name: {{ include "hello-world.name" . }}
    helm.sh/chart: {{ include "hello-world.chart" . }}
    app.kubernetes.io/instance: {{ .Release.Name }}
    app.kubernetes.io/managed-by: {{ .Release.Service }}
spec:
  type: {{ .Values.service.type }}
  ports:
    - port: {{ .Values.service.port }}
      targetPort: http
      protocol: TCP
      name: http
  selector:
    app.kubernetes.io/name: {{ include "hello-world.name" . }}
    app.kubernetes.io/instance: {{ .Release.Name }}

Now, with our knowledge of Kubernetes, these template files look quite familiar except for some oddities. Note the liberal usage of text within double parentheses {{}}. This is what is called a template directive.

现在,以我们对Kubernetes的了解,这些模板文件看起来很熟悉,除了一些奇怪的地方。注意双括号{{}}内文本的自由使用。这就是所谓的模板指令。

Helm makes use of the Go template language and extends that to something called Helm template language. During the evaluation, every file inside the template directory is submitted to the template rendering engine. This is where the template directive injects actual values into the templates.

Helm利用Go模板语言,并将其扩展为名为Helm模板语言的东西。在评估过程中,模板目录内的每个文件都被提交给模板渲染引擎。这就是模板指令将实际值注入模板的地方。

7.3. Providing Values

7.3.提供价值

In the previous sub-section, we saw how to use the template directive in our templates. Now, let’s understand how we can pass values to the template rendering engine. We typically pass values through Built-in Objects in Helm.

在前面的小节中,我们看到了如何在我们的模板中使用模板指令。现在,让我们了解一下我们如何向模板渲染引擎传递值。我们通常通过Helm中的内置对象传递数值。

There are many such objects available in Helm, like Release, Values, Chart, and Files.

在Helm中,有许多这样的对象,如Release、Values、Chart和Files。

We can use the file values.yaml in our chart to pass values to the template rendering engine through the Built-in Object Values. Let’s modify the values.yaml to look like:

我们可以在图表中使用values.yaml文件,通过内置对象值向模板渲染引擎传递数值。让我们修改一下values.yaml,使之看起来像。

replicaCount: 1
image:
  repository: "hello-world"
  tag: "1.0"
  pullPolicy: IfNotPresent
service:
  type: NodePort
  port: 80

However, note how these values have been accessed within templates using dots separating namespaces. We have used the image repository and tag as “hello-world” and “1.0”, this must match the docker image tag we created for our Spring Boot application.

然而,请注意这些值是如何在模板中使用点来分隔命名空间的。我们使用了 “hello-world “和 “1.0 “的图像库和标签,这必须与我们为Spring Boot应用程序创建的docker图像标签相匹配。

8. Managing Charts

8.管理图表

With everything done so far, we’re now ready to play with our chart. Let’s see what the different commands available in Helm CLI to make this fun are! Please note that we’ll only cover some of the commands available in Helm.

到目前为止,一切都完成了,我们现在准备玩我们的图表了。让我们看看Helm CLI里有哪些不同的命令可以让我们玩得更开心请注意,我们将只介绍Helm中的一些可用命令。

8.1. Helm Lint

8.1.头盔丝带

Firstly, this is a simple command that takes the path to a chart and runs a battery of tests to ensure that the chart is well-formed:

首先,这是一个简单的命令,它接收到一个图表的路径,并运行一系列测试,以确保该图表是良好的形式。

helm lint ./hello-world
==> Linting ./hello-world
1 chart(s) linted, no failures

The output displays the result of the linting with issues that it identifies.

输出结果显示了它所识别的问题的品头论足的结果。

8.2. Helm Template

8.2.舵手模板

Also, we’ve this command to render the template locally for quick feedback:

此外,我们还有这个命令,可以在本地渲染模板,以便快速反馈。

helm template ./hello-world
---
# Source: hello-world/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: release-name-hello-world
  labels:
    app.kubernetes.io/name: hello-world
    helm.sh/chart: hello-world-0.1.0
    app.kubernetes.io/instance: release-name
    app.kubernetes.io/managed-by: Tiller
spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: http
      protocol: TCP
      name: http
  selector:
    app.kubernetes.io/name: hello-world
    app.kubernetes.io/instance: release-name

---
# Source: hello-world/templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: release-name-hello-world
  labels:
    app.kubernetes.io/name: hello-world
    helm.sh/chart: hello-world-0.1.0
    app.kubernetes.io/instance: release-name
    app.kubernetes.io/managed-by: Tiller
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: hello-world
      app.kubernetes.io/instance: release-name
  template:
    metadata:
      labels:
        app.kubernetes.io/name: hello-world
        app.kubernetes.io/instance: release-name
    spec:
      containers:
        - name: hello-world
          image: "hello-world:1.0"
          imagePullPolicy: IfNotPresent
          ports:
            - name: http
              containerPort: 8080
              protocol: TCP

Please note that this command fakes the values that are otherwise expected to be retrieved in the cluster.

请注意,这个命令伪造了原本预计在集群中检索到的数值。

8.3. Helm Install

8.3 头盔安装

Once we’ve verified the chart to be fine, finally, we can run this command to install the chart into the Kubernetes cluster:

一旦我们验证了图表没有问题,最后,我们可以运行这个命令将图表安装到Kubernetes集群中。

helm install --name hello-world ./hello-world
NAME:   hello-world
LAST DEPLOYED: Mon Feb 25 15:29:59 2019
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/Service
NAME         TYPE      CLUSTER-IP     EXTERNAL-IP  PORT(S)       AGE
hello-world  NodePort  10.110.63.169  <none>       80:30439/TCP  1s

==> v1/Deployment
NAME         DESIRED  CURRENT  UP-TO-DATE  AVAILABLE  AGE
hello-world  1        0        0           0          1s

==> v1/Pod(related)
NAME                          READY  STATUS   RESTARTS  AGE
hello-world-7758b9cdf8-cs798  0/1    Pending  0         0s

This command also provides several options to override the values in a chart. Note that we’ve named the release of this chart with the flag –name. The command responds with the summary of Kubernetes resources created in the process.

这个命令还提供了几个选项来覆盖图表中的数值。请注意,我们已经用标志-name命名了这个图表的发布。该命令响应的是在这个过程中创建的Kubernetes资源的摘要。

8.4. Helm Get

8.4.头盔获取

Now, we would like to see which charts are installed as what release. This command lets us query the named releases:

现在,我们想看看哪些图表是作为什么版本安装的。这条命令让我们查询命名的版本。

helm ls --all
NAME            REVISION        UPDATED                         STATUS          CHART               APP VERSION NAMESPACE
hello-world     1               Mon Feb 25 15:29:59 2019        DEPLOYED        hello-world-0.1.0   1.0         default

There are several sub-commands available for this command to get the extended information. These include All, Hooks, Manifest, Notes, and Values.

这个命令有几个子命令可以用来获取扩展信息。这些命令包括全部、钩子、清单、注释和值。

8.5. Helm Upgrade

8.5 头盔升级

What if we’ve modified our chart and need to install the updated version? This command helps us to upgrade a release to a specified or current version of the chart or configuration:

如果我们修改了我们的图表,需要安装更新的版本怎么办?这个命令可以帮助我们将一个版本升级到指定的或当前版本的图表或配置。

helm upgrade hello-world ./hello-world
Release "hello-world" has been upgraded. Happy Helming!
LAST DEPLOYED: Mon Feb 25 15:36:04 2019
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/Service
NAME         TYPE      CLUSTER-IP     EXTERNAL-IP  PORT(S)       AGE
hello-world  NodePort  10.110.63.169  <none>       80:30439/TCP  6m5s

==> v1/Deployment
NAME         DESIRED  CURRENT  UP-TO-DATE  AVAILABLE  AGE
hello-world  1        1        1           1          6m5s

==> v1/Pod(related)
NAME                          READY  STATUS   RESTARTS  AGE
hello-world-7758b9cdf8-cs798  1/1    Running  0         6m4s

Please note that with Helm 3, the release upgrade uses a three-way strategic merge patch. Here, it considers the old manifest, cluster live state, and new when generating a patch. Helm 2 used a two-way strategic merge patch that discarded changes applied to the cluster outside of Helm.

请注意,在Helm 3中,发布升级使用的是三方战略合并补丁。这里,它在生成补丁时考虑了旧的清单、集群的实时状态和新的清单。Helm 2使用的是双向战略合并补丁,摒弃了应用于Helm之外的集群的变化。

8.6. Helm Rollback

8.6 头盔回滚

It can always happen that a release went wrong and needs to be taken back. This is the command to roll back a release to the previous versions:

总是会发生这样的情况:一个版本出了问题,需要回滚。这就是将一个版本回滚到以前版本的命令。

helm rollback hello-world 1
Rollback was a success! Happy Helming!

We can specify a specific version to roll back to or leave this argument black, in which case it rolls back to the previous version.

我们可以指定一个特定的版本来回滚,或者把这个参数设为黑色,在这种情况下,它会回滚到以前的版本。

8.7. Helm Uninstall

8.7.Helm卸载

Although less likely, we may want to uninstall a release completely. We can use this command to uninstall a release from Kubernetes:

虽然不太可能,但我们可能想完全卸载一个版本。我们可以使用这个命令从Kubernetes卸载一个版本。

helm uninstall hello-world
release "hello-world" deleted

It removes all of the resources associated with the last release of the chart and the release history.

它删除了所有与上次发布的图表和发布历史相关的资源。

9. Distributing Charts

9.分发图表

While templating is a powerful tool that Helm brings to the world of managing Kubernetes resources, it’s not the only benefit of using Helm. As we saw in the previous section, Helm acts as a package manager for the Kubernetes application and makes installing, querying, upgrading, and deleting releases pretty seamless.

虽然模板化是Helm为管理Kubernetes资源世界带来的强大工具,但这并不是使用Helm的唯一好处。正如我们在上一节看到的,Helm作为Kubernetes应用程序的包管理器,使安装、查询、升级和删除版本相当无缝。

In addition to this, we can also use Helm to package, publish, and fetch Kubernetes applications as chart archives. We can also use the Helm CLI for this as it offers several commands to perform these activities. As before, we’ll not cover all the available commands.

除此之外,我们还可以使用Helm将Kubernetes应用程序打包、发布和获取图表档案。我们也可以为此使用Helm CLI,因为它提供了几个命令来执行这些活动。和以前一样,我们不会涵盖所有可用的命令。

9.1. Helm Package

9.1.头盔套餐

Firstly, we need to package the charts we’ve created to be able to distribute them. This is the command to create a versioned archive file of the chart:

首先,我们需要对我们创建的图表进行打包,以便能够分发它们。这是创建图表的版本存档文件的命令。

helm package ./hello-world
Successfully packaged chart and saved it to: \hello-world\hello-world-0.1.0.tgz

Note that it produces an archive on our machine that we can distribute manually or through public or private chart repositories. We also have an option to sign the chart archive.

请注意,它在我们的机器上产生一个存档,我们可以手动或通过公共或私人图表库分发。我们还有一个选项可以对图表存档进行签名。

9.2. Helm Repo

9.2 头盔回购

Finally, we need a mechanism to work with shared repositories to collaborate. There are several sub-commands available within this command that we can use to add, remove, update, list, or index chart repositories. Let’s see how we can use them.

最后,我们需要一个机制来与共享资源库进行协作。在这个命令中,有几个子命令可用,我们可以用来添加、删除、更新、列出或索引图表存储库。让我们来看看我们如何使用它们。

We can create a git repository and use that to function as our chart repository. The only requirement is that it should have an index.yaml file.

我们可以创建一个git仓库,用它来作为我们的图表仓库。唯一的要求是,它应该有一个index.yaml文件。

We can create index.yaml for our chart repo:

我们可以为我们的图表 repo创建index.yaml

helm repo index my-repo/ --url https://<username>.github.io/my-repo

This generates the index.yaml file, which we should push to the repository along with the chart archives.

这将生成index.yaml文件,我们应该将其与图表存档一起推送到版本库。

After successfully creating the chart repository, subsequently, we can remotely add this repo:

在成功创建图表仓库后,随后,我们可以远程添加这个仓库。

helm repo add my-repo https://my-pages.github.io/my-repo

Now, we should be able to install the charts from our repo directly:

现在,我们应该能够直接从我们的 repo 中安装图表。

helm install my-repo/hello-world --name=hello-world

There are quite a several commands available to work with the chart repositories.

有相当多的命令可用来与图表库一起工作。

9.3. Helm Search

9.3.舵手搜索

Finally, we should search for a keyword within a chart that can be present on any public or private chart repositories.

最后,我们应该在图表中搜索一个关键词,这个关键词可以出现在任何公共或私人图表库中。

helm search repo <KEYWORD>

There are sub-commands available for this command that allows us to search different locations for charts. For instance, we can search for charts in the Artifact Hub or our own repositories. Further, we can search for a keyword in the charts available in all the repositories we’ve configured.

这个命令有一些子命令,允许我们搜索不同位置的图表。例如,我们可以在Artifact Hub或我们自己的存储库中搜索图表。此外,我们可以在我们配置的所有资源库中的图表中搜索一个关键词。

10. Migration from Helm 2 to Helm 3

10.从Helm 2迁移到Helm 3

Since Helm has been in use for a while, it’s obvious to suspect the future of Helm 2 with the significant changes as part of Helm 3. While it’s advisable to start with Helm 3 if we are starting fresh, support for Helm 2 will continue in Helm 3 for the near future. Although, there are caveats, and hence will have to make necessary accommodations.

由于Helm已经使用了一段时间,很明显,作为Helm 3的一部分,我们怀疑Helm 2的未来会有重大变化。虽然如果我们要重新开始,最好从Helm 3开始,但在不久的将来,Helm 3将继续支持Helm 2。虽然,有一些注意事项,因此必须做出必要的调整。

Some of the important changes to note include that Helm 3 no longer automatically generates the release name. However, we’ve got the necessary flag that we can use to generate the release name. Moreover, the namespaces are no longer created when a release is created. We should create the namespaces in advance.

一些需要注意的重要变化包括:Helm 3不再自动生成发布名称。然而,我们已经有了必要的标志,我们可以用它来生成发布名称。此外,命名空间不再是在创建版本时创建的。我们应该提前创建命名空间。

But there are a couple of options for a project that uses Helm 2 and wishes to migrate to Helm 3. First, we can use Helm 2 and Helm 3 to manage the same cluster and slowly drain away Helm 2 releases while using Helm 3 for new releases. Alternatively, we can decide to manage Helm 2 releases using Helm 3. While this can be tricky, Helm provides a plugin to handle this type of migration.

但是,对于使用Helm 2并希望迁移到Helm 3的项目,有几个选择。首先,我们可以使用Helm 2和Helm 3来管理同一个集群,慢慢地耗尽Helm 2的发布,同时使用Helm 3来发布新版本。另外,我们也可以决定用Helm 3来管理Helm 2的发布。虽然这可能很麻烦,但Helm提供了一个插件来处理这种类型的迁移

11. Conclusion

11.结语

To sum up, in this tutorial, we discussed the core components of Helm, a package manager for Kubernetes applications. We understood the options to install Helm. Furthermore, we went through creating a sample chart and templates with values.

综上所述,在本教程中,我们讨论了Helm的核心组件,它是Kubernetes应用程序的一个软件包管理器。我们了解了安装Helm的选项。此外,我们经历了创建一个样本图表和带值的模板。

Then, we went through multiple commands available as part of Helm CLI to manage the Kubernetes application as a Helm package. Finally, we discussed the options for distributing Helm packages through repositories. In the process, we saw the changes that have been done as part of Helm 3 compared to Helm 2.

然后,我们浏览了作为Helm CLI一部分的多个命令,以管理作为Helm包的Kubernetes应用。最后,我们讨论了通过存储库分发Helm包的选项。在这个过程中,我们看到了作为Helm 3的一部分,与Helm 2相比所做的改变。