华为云云原生钻石集训营 第十一课：Kubernetes应用管理深度剖析

学完本课程后，您将能够:

1.了解几种主流K8S应用管理生态的使用场景。

2.了解Helm chart模板机制

3.了解Operator机制

目录：

1. K8S应用模板的使用场景介绍

2. Helm chart模板机制详解

3. Operator机制详解

前言：

在云原生的理念被越来越多的人所熟知，Kubernetes慢慢成为容器编排平台的事实标准以后，如何更好地在容器集群上运行和管理应用，特别是复杂应用如何完成多资源间的编排、打包发布、标准化交付等，是大家尤为关心的问题。Helm通过模板-参数的形式来支持对应用的多种资源进行编排，成为k8s领域最热门的应用包管理工具

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

1. K8S应用模板的使用场景介绍

Helm 能给我们带来什么？

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

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

什么是Operator?

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

Operator其实并不是一个工具，而是为了解决一个问题而存在的一个思路，将特定于应用程序的操作知识编码到软件中，利用功能强大的Kubernetes抽象来正确地运行和管理应用程序

Helm Vs Operator

对比:

Helm是一种标准化的普适性工具，目标是把你的K8S资源模板化，方便共享，进而在不同的配置中重用;

Operator本质上是针对特定的场景去做有状态服务，或者说针对拥有复杂应用的应用场景去简化其运维管理的工具，Operator与特定应用是一对一的关系;

关系:

Helm与Operator并不是完全独立的，很多Operator能做的事情，如应用集群初始化配置、监控更新等通过一些init Container，以及Helm的Hook机制等，最终也能够达到同等效果。只不过这些配置可能显得极为复杂且不易维护，得不偿失;

此外，两者还可能有结合的场景，比如市面上很多开源项目的Operator本身就是通过Helm进行部署和管理的

总结：

helm是为了配置分离，operator则是针对复杂应用的自动化管理，两者的出发点和面向的主要目标场景不同

2.了解Helm chart模板机制

核心组件:

Chart Repository: Chart包存储仓库

Helm Client:是终端用户的命令行客户端，负责:本地chart开发

管理仓库

管理发布

与K8S Server端交互，发送chart (release)安装、升级或卸载请求

Chart包示例

关键要素:

Chart.yaml:包含了chart信息的YAML文件

requirements.yaml:可选，列举chart的依赖关系

charts目录:可选,chart依赖的其他chart

crds目录:可选，自定义资源的定义

templates目录:模板目录，内含go template格式的模板文件

values.yaml文件: chart的默认配置值，与template结合，生成有效的kubernetes manifest文件

values.schema.json文件:可选,JSON schema格式的value规格描述

Chart.yaml示例

apiVersion: chart API版本(必需)

name: chart名称(必需)

version:语义化版本（必需)

kubeVersion:兼容Kubernetes版本的语义化版本(可选)

description:一句话对这个项目的描述（可选)

type: chart类型(可选)

keywords:

 关于项目的一组关键字(可选)

home:项目home页面的URL(可选)

sources:项目源码的URL列表（可选)

maintainers: #(可选)

name:维护者名字(每个维护者都需要)

email:维护者邮箱(每个维护者可选)

url:维护者URL(每个维护者可选)

icon:用做icon的SVG或PNG图片URL(可选)

appVersion:包含的应用版本（可选)。不需要是语义化,建议使用引号

deprecated: 不被推荐的chart(可选，布尔值)

annotations:

example:按名称输入的批注列表(可选)

内置对象

Release:代表Release对象，属性包含: Release.Name、Release.Namespace、Release.Revision等

Values:表示values.yaml文件数据

Chart:表示Chart.yaml数据

Files:用于访问chart中非标准文件

Capabilities:用于获取k8s集群的一些信息

- Capabilities.KubeVersion.Major: K8s的主版本

Template:表示当前被执行的模板

- Name:表示模板名，如: mychart/templates/mytemplate.yaml

- BasePath:表示路径，如: mychart/templates

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

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

Release.Time - release安装时间

Release.Namespace - k8s名字空间

Release.Revision - release版本号，是一个递增值，每次更新都会加一

Release.IsUpgrade - true代表，当前release是一次更新.

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

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

子模板

在chart中以“下划线”开头的文件，称为”子模版”。

例如在_helper.tpl中定义子模块，格式: {{- define "模版名字"-}}模版内容ff- end -.}

引用模板，格式: {{include "模版名字"作用域}}

3.Operator机制详解

通过了解helm和CRD，我们就知道helm没法管理资源的完整生命期，它就是推送YAML就拍拍屁股走人了；而只有CRD才能持续的监听K8S资源对象的变化事件，进行全生命期的监控响应，高可靠的完成部署交付。

Operator的场景就是专门给有状态应用而设计的。

为什么只给有状态应用？

因为无状态应用简单啊，没有服务间的交互，要再开一家火锅店，跟k8s说一声，开一家一样的就可以了。

有状态不一样，你开了一家火锅店以后，客户的信息怎么同步，就涉及到与别的火锅店交涉的问题，当然你也可以写个别的程序做这个数据同步的操作。

但是operator做的事情就是能自动识别到火锅店客户信息的不对称，主动同步，你只用告诉operator我要再开一家连锁火锅店就好了。

关键组件和概念:

Operator Lifecycle Manager:负责管理具体应用Operator的生命周期

应用业务Operator:由开发者针对特定应用业务开发的Operator本身

Operator Registry:存储CSV   

(ClusterServiceVersion )和自定义资源定义(CRD)等构成的应用配置

ClusterServiceVersion(CSV):由Operator元数据创建的YAML清单，可OLM在集群中运行Operator

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

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

本课总结：

Helm：我们可以将Helm看作Kubernetes下的apt-get/yum。Helm是Deis(https://deis.com/)开发的一个用于kubernetes的包管理器:

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

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

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

Operator：

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

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

参考链接：

Helm官方文档: https://helm.sh/docs

GO Template链接: https://golang.org/pkg/text/template

Operator文档: https://operatorhub.io/what-is-an-operator