云原生部署之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.replicaCount }}
{{- 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最佳实践(下))