云原生部署之Helm最佳实践(下)

这是《云原生部署之Helm最佳实践》的下部分。本部分包含生产环境可用代码，可以先收藏，再读。

正片开始：

使用template子命令快速调试chart

当我们在开始chart时，每次修改都要执行一次helm upgrade来验证正确性是很不经济的。Helm提供了template子命令，用于验证我们的chart的语法的正确性。示例：helm template。

定义一个全局的values.yaml

chart中的values.yaml文件为我们提供了chart的默认配置。同时，我们可以在执行helm upgrade —install部署chart时，加入-f values.yaml来指定另外的values文件，比如：

helm upgrade --install -f ./abc.yaml abc ./abc-chart.tgz

但是，有些配置，是全局性的，比如mysql的url。我们不希望它重复写在不同的应用的配置中。所以，我们定义一个全局的values.yaml。比如：global-value.yaml。helm的命令将变成：

helm upgrade --install -f ./global-value.yaml -f ./abc.yaml abc ./abc-chart.tgz

利用helm的-f参数的顺序实现配置的优先级

当全局values文件与应用的values存在配置冲突的时候，通过会采用应用的values文件中的配置。需要注意的是 -f 参数的顺序。后一个 -f 参数的配置会覆盖前一个-f参数的配置。

多版本的实现

过去，我们通常是一个应用一个版本。但是，现在我们更多的是一个应用线上同时存在多个版本。所以，一个chart能同时部署多个版本的应用。

helm upgrade --install -f ./global-value.yaml -f ./abc.yaml  --set 'image.tag={1.2.1,1.2.3}'  abc ./abc-chart.tgz

chart中的deployment文件：

{{/* globle变量缓存全局变量, 遍历tag的同时，再将全局变量变回 */}}
{{- $global := . -}}
{{- range .Values.image.tag }}
{{- $version := . -}}
{{- with $global }}
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "abc.fullname" . }}-{{ $version }}
  labels:
    version: {{ $version }}
spec:
# 注意此处，我们可以针对不同的版本设置不同的副本数
{{- if not .Values.autoscaling.enabled }}
  replicas: {{ .Values.replicoCount }}
{{- end }}
  selector:
    matchLabels:
      {{- include "abc.selectorLabels" . | nindent 6 }}
      version: {{ $version }}
  template:
    ...省略无关代码...
      containers:
        - name: {{ .Chart.Name }}
      ...省略无关代码...
          image: "{{ .Values.image.repository }}:{{ $version | default .Chart.AppVersion }}"
  {{- end }}
{{- end }}

所有的内容都通过chart进行部署

也许你会觉得创建一个namespace就是一个命令的事情，不需要使用helm了。但是，基于持续交付的原则——一切版本化，一切自动化——我们强烈建议，任何操作都应该通过helm进行。比如，我们可以专门创建一个管理Kubernetes的chart。这个chart中，我们就可以实现根据配置创建namespace。再说说Istio这个流行的网格服务的框架。它本身提供了，istioctl命令行进行部署。但是，我们还是建议你使用helm的方式进行部署。因为这样，你才能获得更多的可控性。

往期好文推荐：

云原生部署之Helm最佳实践(上)

Golang整洁接口最佳实践

SpringBoot在K8s下实现优雅停机