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：

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

• 本地chart开发。

• 管理仓库。

• 管理发布。

• 与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资源和控制器概念构建，但又涵盖了特定领域或应用的知识，用于实现其所管理软件的整个生命周期的自动化。