容器 & 服务：Helm Charts 配置文件分析

一 简介

chart 是 Helm 的应用打包格式。chart 由一系列文件组成，这些文件描述了 K8s 部署应用时所需要的资源，比如 Service、Deployment、PersistentVolumeClaim、Secret、ConfigMap 等。

chart可繁可简，即可以只用于部署一个单独的服务，例如mysql、nginx等等，也可以用于部署整个应用，例如由HTTP服务、数据库、缓存、中间件等共同构成的复杂应用。

在我们的应用中，chart的整个目录通常会被打成压缩包（tgz or tar等），并带有版本等信息，用于Helm执行部署。

二 chart示例

如下，test-0.1-1862.tgz就是一个chart的产出压缩包：

我们把这个文件解压后。得到目录内容如下图所示：

其中包含了configmap，deployment，service，以及chart和values.yaml配置。包含了从依赖服务，到所需变量，以及部署和service相关的配置。

更完整的目录组成如下：

?Chart.yaml: 包括仓库地址,版本信息等，描述 chart 的概要信息；

?values.yaml: chart 支持在安装的时根据参数进行定制化配置，而 values.yaml 则提供了这些配置参数的默认值；

?values.schema.json 验证values.yaml

?charts: 依赖其他包的charts文件

?requirements.yaml: 依赖的charts(v1 api)

?requirements.lock v1 api具体依赖的版本

?README.md: 开发人员自己阅读的文件

?LICENSE：版权文件

?crd目录,存放crd资源文件

templates 目录 各类 Kubernetes 资源的配置模板都放置在这里。Helm 会将 values.yaml 中的参数值注入到模板中生成标准的 YAML 配置文件。

模板是 chart 最重要的部分，也是 Helm 最强大的地方。模板增加了应用部署的灵活性，能够适用不同的环境

–deployment.yaml 创建k8s资源的yaml文件

另一个例子，mysql的chart目录结构：

三 文件内容解析

通过二中的两个例子，可见Chart文件中，比较重要的文件可以认为是5个：Chart.yaml，values.yaml，templates下的：configmap.yaml，deployment.yaml，service.yaml。接下来我们详细分析这5个文件。

3.1 Chart.yaml

内容与规则：

apiVersion: # K8s API版本，目前是用的是“v1”（必需）name: # 工程的包名（必需）version: # Chart版本 ，需要符合 SemVer 2：http://semver.org/(语义化版本规范)（必需）kubeVersion: # 一系列兼容的Kubernetes版本（可选）description: # Chart描述，通常用一句话描述项目（可选）keywords:  - # 有关此项目的关键字列表，便于检索（可选）home: # 项目主页URL（可选）sources:  - # 指向此项目源代码的URL列表（可选）maintainers: # 维护人员信息(可选)  - name: # 维护者姓名（每个维护者必须填写）    email: # 维护者电子邮件（每个维护者可选）    url: # 维护者URL（每个维护者可选）engine: gotpl # 模板引擎名称（可选，默认为gotpl）icon: # 要用作图标的SVG或PNG图像的URL（可选）appVersion: # 包含的应用程序版本（可选）。这不必是SemVerdeprecated: # 此“chart”是否已弃用（可选，布尔值）tillerVersion: 此“chart”所需的“Tiller”版本。这应该表示为SemVer范围：“>2.0.0”（可选）

示例：

apiVersion: v1appVersion: "1.0"description: A Helm chart for projectname: projectversion: 0.1.0

3.2 templates

templates目录中存放了Kubernetes部署文件的模版。

3.2.1 deployment

这里先再介绍一下deployment：

Deployment 为 Pod 和 ReplicaSet 提供了一个声明式定义 (declarative) 方法，用来替代以前的 ReplicationController 更方便的管理应用。

作为最常用的 Kubernetes 对象，Deployment 经常会用来创建 ReplicaSet 和 Pod，我们往往不会直接在集群中使用 ReplicaSet 部署一个新的微服务，一方面是因为 ReplicaSet 的功能其实不够强大，一些常见的更新、扩容和缩容运维操作都不支持，Deployment 的引入就是为了支持这些复杂的操作。

3.2.2 deployment.yaml

deployment文件包括以下四个部分：

示例：

apiVersion: extensions/v1kind: Deploymentmetadata:  name: {{ template "fullname" . }}  labels:    chart: "{{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}"spec:  replicas: {{ .Values.replicaCount }}  template:    metadata:      labels:        app: {{ template "fullname" . }}    spec:      containers:      - name: {{ .Chart.Name }}        image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"        imagePullPolicy: {{ .Values.image.pullPolicy }}        ports:        - containerPort: {{ .Values.service.internalPort }}        livenessProbe:          httpGet:            path: /            port: {{ .Values.service.internalPort }}        readinessProbe:          httpGet:            path: /            port: {{ .Values.service.internalPort }}        resources:{{ toyaml .Values.resources | indent 12 }}

需要注意的是，上面的yaml配置文件中有双大括 包扩起来的部分，这些是Go template，其中的Values是在values.yaml文件中定义的变量内容。

3.2.3 values.yaml

我们以nginx的某版本values.yaml为例：

# Default values for mychart.# This is a yaml-formatted file.# Declare variables to be passed into your templates.replicaCount: 1image:  repository: nginx  tag: stable  pullPolicy: IfNotPresentservice:  name: nginx  type: ClusterIP  externalPort: 80  internalPort: 80resources:  limits:    cpu: 100m    memory: 128Mi  requests:    cpu: 100m    memory: 128Mi

这样，通过values.yaml文件，以及变量映射规则，就可以把deployment.yaml中的变量替换成values.yaml中的值。另外考虑到不同环境的差异，我们也可以通过定义values-dev.yaml、values-qa.yaml、values-online.yaml来区分开发、测试、线上集中环境的变量值，结合流水线来实现不同环境的持续集成。

四 附录：关于apiVersion

关于apiVersion：

apiVersion指的是kubernetes的api版本，相关资料可以查看 Which Kubernetes apiVersion Should I Use? 这篇文章。

Kubernetes API的稳定版本，包含很多核心对象：pod、service等

#头条创作挑战赛##互联 #