Helm Library Charts & Helm Unit test
Thi
What is Helm?
If Kubernetes were an operating system, Helm would be the package manager.
Ubuntu uses apt, CentOS uses yum, and Kubernetes uses helm.
Helm deploys packaged applications to Kubernetes and structures them into charts. The charts contain all pre-configured application resources along with all the versions into one easily manageable package.
Helm streamlines installing, upgrading, fetching dependencies, and configuring deployments on Kubernetes with simple CLI commands. Software packages are found in repositories or are created.
What is Helm Chart?
Helm uses a packaging format called charts. A chart is a collection of files that describe a related set of Kubernetes resources. A single chart might be used to deploy something simple, like a “memcached” pod, or something complex, like a full web app stack with HTTP servers, databases, caches, and so on. Charts are created as files laid out in a particular directory tree. They can be packaged into versioned archives to be deployed.
What is Library Charts?
A library chart is a type of Helm chart that defines chart primitives or definitions which can be shared by Helm templates in other charts. This allows users to share snippets of code that can be re-used across charts, avoiding repetition and keeping charts DRY..
A chart maintainer can define a common chart as a library chart and now be confident that Helm will handle the chart in a standard consistent fashion. It also means that definitions in an application chart can be shared by changing the chart type.
Since this blog only focus on Helm Library Chart and some unittest, so I assumed that all charts was ready.
Library chart for Services
In this chart, we have these templates of components, and which was included in a app-template define like this
Configmap
secrect
pdb
serviceaccount
deployment
service
...
These code will be stored in _app.yaml file in template folder
{{- define "util.app" -}}
{{ include "util.configMap" . }}
---
{{ include "util.secret" . }}
---
{{ include "util.pdb" . }}
---
{{ include "util.serviceAccount" . }}
---
{{ include "util.deployment" . }}
---
{{ include "util.service" . }}
{{- if .Values.apiHttp }}
---
{{ include "virtualservice.api.tpl" . }}
{{- end }}
{{- if .Values.webHttp }}
---
{{ include "virtualservice.web.tpl" . }}
{{- end }}
{{- if .Capabilities.APIVersions.Has "autoscaling.k8s.io/v1" }}
{{- if .Values.vpa }}
---
{{ include "util.vpa" . }}
{{- end }}
{{- end }}
---
{{- if .Capabilities.APIVersions.Has "autoscaling/v2beta2" }}
{{- if .Values.hpa }}
{{ include "util.hpa" . }}
{{- end }}
{{- end }}
{{- end -}}
After that, for each component, we will create a common template for that kind of resource to read some information like chart name, value file. Pls note that I wont put the whole code to here.
{{- /*Definitions for the blocks above.*/}}
{{- define "util.pdb" -}}
{{- if .Capabilities.APIVersions.Has "policy/v1/PodDisruptionBudget" }}
apiVersion: policy/v1
{{- else }}
apiVersion: policy/v1beta1
{{- end }}
kind: PodDisruptionBudget
metadata:
name: {{ include "util.fullname" . }}
spec:
maxUnavailable: {{ default 1 .Values.pdbMaxUnavailable }}
selector:
matchLabels:
app.kubernetes.io/name: {{ include "util.name" . }}
app.kubernetes.io/instance: {{ .Release.Name }}
{{- end -}}