当谈到Helm时,我们经常会做这样的类比:Helm之于Kubernetesredhat 集群文件系统,如同apt之基于debian的系统,yum或rpm之于基于RedHat的系统一样。不仅包管理之外,Helm还外置了配置管理的许多内容。
Helm是针对Kubernetes的一款包管理工具,最初是由一家名为Deis的公司开发的,后来被谷歌竞购。谷歌竭力支持Helm,推动了它的开发速率,如今它是云本地估算基金会(CNCF)的一部份。
图片来源:“Helmhistory”——2018年5月,在CNCFTOC上Helm项目的演示幻kt板
作为CNCF的一部份,Helm得到了诸多组织的积极开发和支持,并由此发展出一个庞大而活跃的社区。以下是Helm截止2021年10月的项目贡献统计数据示例:
Contributors
CodeCommits
PullRequests
Contributions
15,449
17,079
16,897
152,442
表资料来源:中国石油天然气基金发展统计项目《项目总体统计表》
为何Kubernetes须要一个包管理器?
大多数技术都是以“HelloWorld”的示例来引入关键概念,Kubernetes也不例外。除最简单的组件以外,将任何组件布署到Kubernetes集群都须要跨多个组件进行协调。
例如,管理Kubernetes集群外的应用程序布署的过程并不复杂,但是因为存在依赖关系和依赖版本、配置锥面、部署前和布署后的步骤、验证等,这就弄成一项繁杂的工作了。正如apt和yum是为Linux管理该过程一样,Helm为Kubernetes处理这个过程。
总的说来,Helm特点具有以下特点:
Helm的结构
使用Helm只须要安装一个可执行文件。helm命令提供了20多个参数,用于建立、部署、删除、回滚等,将应用程序布署到Kubernetes集群中。
Helm布署预制构件是HelmChart。HelmChart由用于将组件或应用程序布署到Kubernetes集群的资源组成。Chart中最常见的资源是YAML文件,它遵守标准的Kubernetes资源描述。假如你就能很熟练地使用kubectlcreate或则kubectlapply命令布署到Kubernetes集群redhat 集群文件系统,这么都会认为HelmChart中的YAML文件看上去很熟悉。HelmChart一般包含额外的资源,如README文件、默认参数文件和布署所需的额外文件(如证书)。
开发HelmChart须要使用预定义的目录结构组织文件。可以用Helm命令helmcreate创建一个Helmchart,它是预定义的目录结构,包含一些示例文件。生成的chart包含几个YAML文件。一个Kubernetes布署一般须要多个要布署的Kubernetes资源描述,在许多情况下,这种布署必须有一个优先级次序。当自动布署时linux课程,必须晓得次序。而Helm则毋须这么,由于Helm晓得Kubernetes资源描述的优先次序。
Helm布署过程的一个关键特点是ChartHooks。在HelmChart的布署生命周期中,Charthook是一种执行额外任务的机制。Helm支持以下几点来引入图ChartHook:
ChartHook
描述
pre-install
在布署应用程序之前执行任务
post-install
在应用程序布署以后执行任务
pre-delete
在将应用程序从集群中移除之前执行任务
post-delete
在将应用程序从集群中移除以后执行任务
pre-upgrade
在执行已布署应用程序的升级过程之前执行任务
post-upgrade
在执行已布署应用程序的升级过程以后执行任务
pre-rollback
在执行已布署的应用程序回滚流程之前执行任务
post-rollback
在执行已布署的应用程序回滚流程以后执行任务
test
执行HelmChart中定义的Helm测试
表格来源:“有用的钩子——ChartHook”,HelmChart可以依赖于其他HelmChart
比如,一个应用程序可能包含对一组微服务的依赖,其中的微服务由他自己的HelmChart定义。当应用程序布署时,Helm会管理这种依赖项。为了与微服务模式保持一致,每位组件都可以独立于其他组件进行更新linux版qq,因而它依然是内聚的应用程序的集合的定义。
规划Helm布署
Helm在应用程序开发和布署的各个方面都还能发挥作用,这须要工程和营运团队紧密合作,以设计解决方案并回答布署问题。通过团队协调,可以迭代地作出布署决策,以使用单个布署包来支持每位环境的目标以适应每位布署环境中的差别。
不仅后面描述的钩子概念之外,Helm还提供了一种粗壮的模板机制,使团队能否解决单一布署包的挑战。一般,HelmChart中的YAML文件看上去不像手写的YAMLKubernetes资源描述。
相反,HelmChart中的YAML文件是使用Helm的模板语言开发的:
{{- if .Values.ingress.enabled -}}
{{- $fullName := include "helm-demo.fullname" . -}}
{{- $svcPort := .Values.service.port -}}
{{- if semverCompare ">=1.14-0" .Capabilities.KubeVersion.GitVersion -}}
apiVersion: networking.k8s.io/v1beta1
{{- else -}}
apiVersion: extensions/v1beta1
{{- end }}
kind: Ingress
metadata:
name: {{ $fullName }}
labels:
{{- include "helm-demo.labels" . | nindent 4 }}
{{- with .Values.ingress.annotations }}
annotations:
{{- toYaml . | nindent 4 }}
{{- end }}
spec:
{{- if .Values.ingress.tls }}
tls:
{{- range .Values.ingress.tls }}
- hosts:
{{- range .hosts }}
- {{ . | quote }}
{{- end }}
secretName: {{ .secretName }}
{{- end }}
{{- end }}
rules:
{{- range .Values.ingress.hosts }}
- host: {{ .host | quote }}
http:
paths:
{{- range .paths }}
- path: {{ .path }}
backend:
serviceName: {{ $fullName }}
servicePort: {{ $svcPort }}
{{- end }}
{{- end }}
{{- end }}
复制代码
这个由helmcreate生成的被模板化的ingress描述示例,提供了几个变量,拿来定义和配置ingress资源,包括是否应当创建ingress资源。通过模板,Helm提供了对Kubernetes资源怎么布署的大量控制。规划良好的模板模式可以生成单个布署包,使HelmChart才能成功布署,范围从开发人员工作站上的单节点Kubernetes集群到生产Kubernetes集群。
HelmChart和CI/CD
作为组织持续集成/持续交付管线的一部份,Helm饰演着促使者和组件的角色。作为一个促进者,它通过成为跨环境(工程、质保、交付、认证、生产等)布署应用程序或组件的机制来提高管线。在CI/CD管线中,手动化的HelmChart布署十分简单。
HelmChart作为一个应用程序组件,也像应用程序代码一样是迭代开发和布署的。这意味着CI/CD管线在验证HelmChart本身时是不可或缺的。事实上,HelmChart应当被视为应用程序代码的一部份,而不是应用程序开发过程的外围部份——甚至应当将HelmChart作为应用程序源代码的一部份列入管理。与应用程序建立生成版本化的容器映像并将其推送到镜像注册表的方法类似,helmpackage将chart绑定到版本化的归档文件中。生成的归档文件被递交到HelmChart储存库,可以从该储存库访问它以进行布署。
上图突出指出了应用程序软件开发生命周期中的各个阶段。无论使用哪种模式来管理HelmChart的源代码,它在应用程序CI/CD管路中与应用程序本身一样不可或缺。
结束语
Helm仍然是Kubernetes生态系统炒作曲线的一部份,随着Kubernetes炒作曲线开始变平,Helm也早已成熟。Helm的方式是革命性的吗?不完全是。Helm借助多年积累了大量的软件包和配置管理工具的知识,如今将这种经验带给Kubernetes。同时,Helm通过HelmChart定义布署包的观点对组织CI/CD管线的效率形成了直接影响,最明显的是配置模式和布署灵活性。设计良好的HelmChart是有效交付的重要组成部份。
原文链接:
kubernetes-package-management-with-helm