Kubernetes 应用管理深度剖析

本篇我们会聊到 Kubernetes，也简称 K8s。那么 Kubernetes 到底是什么呢？

简单来说，它就是一个容器集群管理系统，是 Google 开源的一个项目。可能这时会有人想到另外一个容器管理引擎 Docker，我们可以使用 K8S 来管理大规模的 Docker 容器，这里不过多描述。接下来将进入到 K8S 的世界。

本篇文章详细介绍主流 K8S 应用管理生态的使用场景 ，深入了解 Helm chart 模板机制和 Operator 机制。

目录：

一、K8S 应用模板有哪些使用场景？

1.应用管理生态的使用场景

2.Helm chart 模板机制

3.Operator 机制

二、工具：Helm chart 模板机制

     1.Helm chart 架构

     2.Hook 机制

三、大脑：Operator 机制

1.Operator 原理

2.Operator 管理

四、总结

     1.Helm 小结

     2.Operator 小结

一、K8S 应用模板有哪些使用场景？

1.应用管理生态的使用场景

当容器和云原生的理念被更多人认可，也会有更多的企业和软件工程师将自己的应用搬到云原生或者容器上面来，那么在搬到容器或者容器集群上来，我们应该如何去更好的管理这些复杂应用以及相关的进程呢？特别是复杂应用需要完成资源间的编排、打包发布，标准化交付等。在 Kubernetes 里，我们可以使用 Helm 的模板-参数形式来支持对应用的多种资源进行编排，使之成为 K8S 领域最热门的应用包管理工具。

2.Helm chart 模板机制

Helm 能够很好的帮助我们实现 K8s 应用打包和标准化交付，对于实例运行态的生命周期管理，则通过资源的基础生命周期动作来驱动。然而，对于一些复杂应用的生命周期管理，基本的资源操作是无法很好的能够胜任，也需要根据应用它自身的特点，在一些关键生命周期结点上补充额外的动作。因此，CoreOS 首先倡导了 Operator 的理念，即将特定应用的操作知识编码到软件中，利用功能强大的 Kubernetes 抽象来正确地运行和管理应用程序。

那么 Helm 能给我们带来什么呢？

完整的应用通常不只是简单的 deployment，StatefulSet 等负载资源，通常还包括配置的（服务）service，（数据交互）PV/PVC，（证书）configmap 等一系列资源，我们在进行实例下发、升级、更新迭代等一系列生命周期操作时，这些资源都是需要我们统筹考虑的。

To：Helm 可以帮助开发者完成应用打包、版本管理、应用的创建删除、升级更新等生命周期管理操作。

3.Operator 机制

以分布式系统为代表的有状态应用，并不像 Web 应用一样“开箱即用”，这些系统需要特定应用领域的知识才能扩展、升级和重新配置，同时防止数据丢失或者不可用。

怎么说呢，Operator 算不上一个工具，只是我们为解决问题而存在的一种思路，将特定应用程序的操作知识编码到软件中，然后利用功能强大的 Kubernetes 抽象来正确的运行和管理应用程序。

那么 Helm 和 Operator 有什么区别或者不同的地方呢？

对比：Helm 是一种标准化的普适性工具，主要目标是将 K8S 资源模块化，以方便我们用来管理以及共享，并且在不同的配置中重用；Operator 本质上是针对特定的场景去做有状态服务，或者说针对拥有复杂应用的应用场景去简化其运维管理的工具，Operator 与特定应用是一对一的关系。

关系：Helm 与 Operator 并不是完全独立的，很多 Operator 能做的事情如应用集群初始化配置，监控更新等通过一些 init Container，以及 Helm 的 Hook 机制，最终也能够达到同等效果，不过这些配置可能显得极为复杂且不易维护，得不偿失。两者实际上也有可以结合的场景，比如市面上很多开源项目的 Operator 本省就是通过 Helm 进行部署和管理的。

小结：Helm 是为了配置分离，Operator 则是通过复杂应用的自动化管理，两者的出发点和面向的主要目标场景不同。

二、工具：Helm chart 模板机制

1.Helm chart 架构

这里我们先来看一下它的核心组件：

Chart Repository：Chart 包储存仓库，可以是公共也可以是内部搭建的，只要符合通信协议的标准就可以。

Helm Client：终端用户的命令行仓库，可以用命令本地化初始一个包的框架，再往里面塞一些需要的模板，最后组合打包成一个业务包，然后去发布。

1. 本地 chart 开发。

2. 管理仓库。

3. 管理发布。

4. 与 K8S Server 端交互，发送 chart（releas）安装、升级或卸载请求。

其中，最重要的 Chart 包实例：

其中 chart 包文件中的关键要素：

• Chart.yaml：chart 包的元数据， 包含了 chart 信息(比如名称、版本号)的 YAML 文件。

• Requirement：可选，列举 chart 的依赖关系。

• Chart 目录：可选，列举 chart 的依赖关系。

• Crds 目录：可选，自定义资源的定义，比如 Crds 的一些模板。

• Template 目录：模板目录，内含 go templa 格式的模板文件。

• Value.yaml 文件：chart 的默认配置值，与 templa 结合，生成有效的 kubernetes manifest 文件。

• Values.schema.json 文件：可选，JSON schema 格式的 value 属性和规格描述。

包文件内容实例：

这里我们将讲到 Template-Value 的示例：

• Chart：创建 Kubernetes 应用程序所需的一组信息。Chart 目录：可选，chart 依赖的其他 chart。

• Config：包含了可以合并到 chart 中的配置信息，用于创建一个可发布的对象。

• Release：是一个与特定配置相结合的运行实例。

其中的内置对象有：

• Release：代表 Release 对象，属性包括：Release.Name、Relaese.Namespace、Release.Revision 等。

• Values:表示 Values.yaml 文件数据。

• Chart：表示 Chart.yaml 数据。

• Files：用于访问 chart 中非标准文件。

• Capabilities：用于获取 K8S 集群的一些信息 。

• -Capabilities.KubeVersion.Major：K8s 的主版本。

• Template：表示当前被执行的模板。

• -Name：表示模板名。

• -BasePath：表示路径。

其中 Release 代表一次应用发布，下面是 Release 对象包含的属性字段：

1.Release.Name-release 的名字，一般通过 Chart.yaml 定义，或者通过 heml 命令在安装应用的时候指定。

2. Release.Time-release 安装时间。

3.Release.Namespace-K8s 名字空间。

4.Release.Revision-release 版本号，每次更新都会加一。

5.Release.lsUpgrade-true 代表当前 release 是一次更新。

6.Release.lsInstall-true 代表当前 release 是一次安装。

7.Release.Service-release 服务的名称(始终是 Helm)。

To：在 chart 中以下划线开头的文件，成为子模板。

2.Hook 机制

Kubernetes 为容器在其生命周期内提供了两种钩子（hook），分别是 postStart 与 preStop 两种事件：

PostStart：在容器启动之后，PostStart hook 会立即被执行，需要注意的是，容器里的 ENTRYPOINT 与 PostStart hook 的执行顺序谁先谁后并不是确定的。

PreStop：在容器被终止之前被执行，会采用一种阻塞式的方式，也就是必须在 PreStop hook 执行完毕之后，销毁容器的动作才会被执行。

Chart 依赖管理：

Requirement.yaml 文件会列出 chart 之间的依赖关系，有了依赖关系文件，就可以通过运行 helm dependency update，将依赖关系文件所有指定的 chart 下载到 chart/目录下。

To：chart 目录的内容可以手动管理维护。

三、大脑：Operator 机制

1.Operator 原理——扩展 Kubernetes API，定义应用

标准的 API 定义：/apis/{group}/{version}/namespace/{namespace}/{kind}${name}

Operator 原理-Kubernetes Controller 机制（如图）

Operator 原理-实现 Operator，管理应用（如图）

实际上机制都是差不多的，只是思路有些变化。

2.Operator 自身管理-Operator Framework

其中关键组件和概念：

1.Operator Lifecycle Manager：负责管理具体应用和 Operator 的生命周期。

2.应用业务 Operator：由开发者针对特定应用业务开发的 Operator 本身。

3.Operator Registry：存储 CSV 和自定义资源定义等构成的应用配置。

4.ClusterServiceVersion（CSV）：由 Operator 元数据创建的 YAML 清单，可在集群中运行 Operator。

5.Subscription:通过跟踪安装包中的 channel 保证 CSV 版本更新。

6.InstallPlan：计算自动安装或升级 CSV 过程中需创建的资源集合。

四、总结

1.Helm 小结：

我们可以将 Helm 看作 Kubernetes 下的 apt-get/yum。Helm 是 Deist 开发的一个用于 Kubernetes 的包管理器。

1.对于应用发布者而言，可以通过 Helm 打包应用，管理应用依赖关系，管理应用版本并发布到应用软件仓库。

2.对于使用者而言，使用 Helm 后不用需要了解 Kubernetes 的 yaml 语法并编写应用部署文件，可以通过 Helm 下载并在 Kubernetes 上安装需要的应用。

3.除此之外，Helm 还提供了 Kubernetes 上的软件部署、删除、升级、回滚应用的能力

2.Operator 小结：

Kubernetes Operator 是一种封装、部署、和管理 Kubernetes 应用的方法。

Kubernetes Operator 是一种特定用于应用的控制器，可扩展 Kubernetes API 的功能，来代表 Kubernetes 用户创建、配置和管理复杂应用的实例。

Operator 基于基本 Kubernetes 资源和控制器概念构建，但又涵盖了特定领域或应用的知识，用于实现其所管理软件的整个生命周期的自动化。