1.3　Helm架构

在本节中，我们将简要介绍Helm的高级架构。除了对云原生Kubernetes应用程序和软件包管理的概念性讨论外，本节还为第2章铺平了道路，在第2章中，我们将深入讨论如何使用Helm。

1.3.1　Kubernetes资源

我们已经看过了几种Kubernetes资源：Pod、ConfigMap、Deployment和Service。Kubernetes还提供了几十种。你甚至可以使用自定义资源定义（CRD）来定义自己的自定义资源类型。主要的Kubernetes文档提供了关于每种类型的可访问指南和详细的API文档。

在本书中，我们将使用许多不同的Kubernetes资源类型。当我们在上下文中讨论它们时，你可能会发现在浏览新的资源定义时浏览主要的Kubernetes文档是有益的。

如前所述，资源定义是声明性的。用户为Kubernetes描述所需的资源状态。例如，你可以将我们在本章前面创建的Pod定义理解为“我希望Kubernetes为我制作一个具有这些特性的Pod”的语句，这取决于Kubernetes如何根据你的规范配置和运行Pod。

所有Kubernetes资源定义共享一个共同的元素子集。下面的清单使用Deployment来说明资源定义的主要结构元素：

❶　此资源的API系列和版本。

❷　资源的种类。结合apiVersion，得到资源类型。

❸　metadata（元数据）部分包含关于资源的顶级数据。

❹　几乎每种资源类型都需要一个name（名称）。

❺　标签（labels）用于为你的资源提供Kubernetes可查询的“句柄”。

❻　注解（annotations）为作者提供了一种将自己的键和值附加到资源的方法。

特别要注意的是，Kubernetes中的资源类型由三块信息组成：

API组（或家族）

一些基本资源类型（如Pod和ConfigMap）忽略了此名称。

API版本

表示为v，后跟主要版本和可选的稳定性标记。例如，v1是一个稳定的“version 1”，而v1alpha表示一个不稳定的“version 1 alpha 1”。

资源类型

API组中特定资源的（大写）名称。

虽然完整的资源类型名称类似于apps/v1 Deployment或v1 Pod（对于核心类型），但Kubernetes用户在谈论或编写已知类型时通常会忽略组和版本。例如，在本书中，我们只是写Deployment，而不是apps/v1 Deployment。在指定确切的版本或讨论CRD中定义的资源类型时，将使用完全限定名。

因此，apps/v1 Deployment表示API组“apps”有一个名为“Deployment”的“version 1”（稳定）资源类型。

Kubernetes支持两种主要格式来声明所需的资源：JSON和YAML。严格地说，YAML是JSON的超集（superset）。所有JSON文档都是有效的YAML，但是YAML添加了许多附加特性。

在这本书中，我们坚持使用YAML格式。它更容易读写，几乎所有Helm用户都选择YAML而不是JSON。但是，如果你的偏好与此不同，Kubernetes和Helm也都支持纯JSON。

早些时候，我们引入了术语清单。清单只是序列化为JSON或YAML格式的Kubernetes资源。我们可以将前面的Pod、ConfigMap、Deployment和Service示例分别称为一个Kubernetes清单，因为它们是用YAML表示的资源。

1.3.2　chart

我们已经在本章中讨论了Helm软件包。在Helm的词汇表中，有一个软件包叫作chart（航海图）。这个名字是对Kubernetes（在希腊语中是“船长”的意思）和Helm（舵，船舶的操纵机构）的航海性质的一种诠释。chart描绘了Kubernetes应用程序的安装方式。

chart是遵循chart规范的一组文件和目录，用于描述要安装到Kubernetes中的资源。第4章详细解释了chart结构，但这里我们将介绍一些高级概念。

chart包含一个名为chart.yaml的文件，它描述了该chart，包含有关chart版本、chart名称和说明以及chart作者的信息。

chart也包含模板。这些也是Kubernetes清单，可能用模板指令进行注解。详见第5章。

chart也可以包含提供默认配置的values.yaml文件。此文件包含安装和升级期间可以覆盖的参数。

这些是你将在Helm chart中找到的基本文件，更多文件参见第4章。不过，当你看到一个Helm chart时，它可能是以未打包或打包的形式呈现的。

一个未打包的Helm chart只是一个目录。在里面，它会有一个Chart.yaml、一个values.yaml、一个templates/目录等。打包的Helm chart包含与未打包的Helm chart相同的信息，但它被tar打包并用gzip压缩到单个文件中。

未打包的chart由一个带有chart名称的目录表示。例如，名为mychart的chart将被解压到名为mychart/的目录中。相比之下，打包的chart有chart的名称和版本，以及tgz后缀：mychart-1.2.3.tgz。

chart存储在chart存储库中，我们将在第7章中介绍它们。Helm知道如何从存储库下载和安装chart。

1.3.3　资源、安装和发布

为了将本节中介绍的术语联系起来，当某个Helm chart被安装到Kubernetes中时，会发生以下情况：

1.Helm读取chart（必要时下载）。

2.它将值发送到模板中，生成Kubernetes清单。

3.清单被送到Kubernetes。

4.Kubernetes在集群内创建请求的资源。

当一个Helm chart被安装时，Helm将根据需要生成尽可能多的资源定义。有些chart可能创造一个或两个定义，其他的可能创造数百个定义。当Kubernetes收到这些定义时，将为它们创建资源。

Helm chart可能有许多资源定义。Kubernetes认为每个资源定义都是独立的。但在Helm看来，chart定义的所有资源都是相关的。例如，我的WordPress应用程序可能有一个Deployment、一个ConfigMap、一个Service等。但它们都是一个chart的一部分。安装它们时，它们都是同一个安装的一部分。同一chart可以安装多次（每次使用不同的名称）。因此，我可能拥有相同chart的多个安装，就像我可能拥有相同Kubernetes资源类型的多个资源一样。

这带来了最后一个术语。一旦安装了WordPress chart，我们就拥有了一个该chart的安装。然后我们用helm upgrade来升级该chart。现在，这个安装有两个版本。每次使用Helm修改安装时，都会创建一个新的安装版本。

当安装新版本的WordPress时，会创建一个版本。但是，当我们仅仅更改安装的配置或者回滚安装时，也会创建一个版本。这是Helm的一个重要特征，我们将在第7章中再次看到。

1.3.4　关于Helm 2的简要说明

熟悉Helm 2的人可能会注意到本书中缺少某些概念：Tiller或gRPC。这些东西已从Helm 3中删除，而本书的主题是讲述Helm 3。此外，本书着重讲述第2版Helm chart。因为Helm chart版本与Helm版本的递增是不一致的。所以Helm v2使用Helm Charts v1，Helm v3使用Helm Charts v2。它们在一些重要的方面与第1版的Helm Charts不同，最显著的是在声明依赖项的方式上。Helm 2和Helm Charts v1被认为已弃用。