Helm es una poderosa herramienta para aplicar, actualizar y administrar aplicaciones en Kubernetes. La comunidad de Helm crea muchos gráficos de código abierto. Puede implementar Redis, Nginx o Prometheus Operator con un solo comando. Y vienen con todo lo que necesitas, como Ingress.
El equipo de Mail.ru Cloud Solutions hatraducido un artículo que describe una forma rápida de crear un gráfico básico, que muestra comandos útiles y comparte las mejores prácticas. No se detiene en aspectos del lenguaje de plantillas Go, ya que la mayoría de ellos se tratan en la documentación de Helm. Este tutorial proporciona aspectos e ideas más abstractos para mejorar su flujo de trabajo.
Crear una estructura gráfica básica
Comience con un comando simple que creará una estructura de gráfico de ejemplo:
$ helm create basic
Creating basic
$ tree basic
basic/
├── charts
├── Chart.yaml
├── templates
│ ├── deployment.yaml
│ ├── _helpers.tpl
│ ├── ingress.yaml
│ ├── NOTES.txt
│ ├── serviceaccount.yaml
│ ├── service.yaml
│ └── tests
│ └── test-connection.yaml
└── values.yaml
Eso es todo lo que se necesita para crear un gráfico listo para la implementación. Este gráfico le permite implementar una aplicación con todos los componentes necesarios. Si echas un vistazo a values.yaml, puedes ver que esta aplicación implementará Nginx.
Expandir un gráfico es tan fácil como crear:
$ helm install basic
El equipo de plantillas es tu mejor amigo
Inmediatamente antes de la instalación y después de los cambios en el gráfico, debe verificar si todo se maneja correctamente en las plantillas.
Para verificar qué se implementará exactamente en el clúster, use el comando:
$ helm template basic
El comando generará todos los YAML generados por todas las plantillas. Si solo desea ver el resultado de una plantilla, use:
$ helm template basic -x templates/service.yaml
El resultado será algo como esto:
---
# Source: basic/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
name: release-name-basic
labels:
app.kubernetes.io/name: basic
helm.sh/chart: basic-0.1.0
app.kubernetes.io/instance: release-name
app.kubernetes.io/version: "1.0"
app.kubernetes.io/managed-by: Tiller
spec:
type: ClusterIP
ports:
- port: 80
targetPort: http
protocol: TCP
name: http
selector:
app.kubernetes.io/name: basic
app.kubernetes.io/instance: release-name
Para probar una plantilla con valores personalizados, use:
$ helm template basic -x templates/service.yaml -f \ mypath/tocustomvalues.yaml
La plantilla generada se puede probar en el clúster mediante el comando:
$ helm install basic --dry-run --debug
¡HILAS!
Antes de enviarlo al repositorio, puede agregar un paso más para verificar claramente el código: linting (análisis estadístico):
$ helm lint basic/
==> Linting basic/
[INFO] Chart.yaml: icon is recommended
1 chart(s) linted, no failures
Helm trabaja con funciones
Si busca en el directorio de plantillas de gráficos, puede ver _helpers.tpl. Aquí puede agregar sus funciones, estarán disponibles en todo el gráfico. Una función de ejemplo podría verse así:
{{/*
Expand the name of the chart.
*/}}
{{- define "basic.name" -}}
{{- default .Chart.Name .Values.nameOverride | trunc 63 | trimSuffix "-" -}}
{{- end -}}
El uso de una función en una plantilla se indica mediante una función
include:
app.kubernetes.io/name: {{ include "basic.name" . }}
Etiquetas meta
Una parte importante de Kubernetes es el uso correcto de etiquetas. Esto es muy importante si está utilizando Helm para implementar varios manifiestos. Para agregar etiquetas fácilmente para encontrar recursos administrados por Helm, puede usar sus propias funciones:
{{/*
Common labels
*/}}
{{- define "basic.labels" -}}
app.kubernetes.io/name: {{ include "basic.name" . }}
helm.sh/chart: {{ include "basic.chart" . }}
app.kubernetes.io/instance: {{ .Release.Name }}
{{- if .Chart.AppVersion }}
app.kubernetes.io/version: {{ .Chart.AppVersion | quote }}
{{- end }}
app.kubernetes.io/managed-by: {{ .Release.Service }}
{{- end -}}
Y ahora es fácil agregar algunas etiquetas al gráfico:
apiVersion: v1
kind: Service
metadata:
name: {{ include "basic.fullname" . }}
labels:
{{ include "basic.labels" . | indent 4 }}
...
Si desea encontrar servicios creados con este gráfico, utilice el comando:
$ kubectl get svc -l helm.sh/chart=basic-0.1.0
Los comentarios te salvarán
Hay dos tipos de comentarios:
- # Es un comentario simple que permanece en el YML resultante después del procesamiento.
- {{- / * ... * / -}} es un comentario que es descartado por el motor de plantillas.
# app files volume
{{- /*
App files are configmaps created by cloud-app-play-files chart.
App files contains files specific for app and environment.
App name should be same as in deployment of cloud-app-play-files chart.
*/ -}}
{{- if .Values.include.appDir }}
- name: {{ $appName }}-files
configMap:
name: {{ $appName }}-files
La salida de la plantilla será así:
# app files volume
- name: app-notification-files
configMap:
name: app-notification-files
Como puede ver, el manifiesto generado contiene solo un comentario de tipo simple. El tipo a utilizar depende de usted. Pero los comentarios de plantilla son útiles si está definiendo canalizaciones o dependencias más complejas en YAML.
También es importante recordar que los comentarios que comienzan con # también se analizan. Si coloca una plantilla Go en un comentario, se evaluará. Así que los comentarios también pueden ser plantillas.
Asegúrese de conservar la documentación
La documentación de gráficos es indispensable, especialmente si desea publicar un gráfico. La forma más sencilla de crear y mantener documentos es utilizar el paquete Golang llamado helm-docs . Con él, puede generar un README.md que contenga tablas de valores, versiones y descripciones de values.yaml y chart.yaml, o usar otros archivos personalizados.
Ejemplo tomado de https://github.com/norwoodj/helm-docs
Como puede ver, agregar el nombre con - en los comentarios da como resultado una fila en la tabla. Además, la tabla contiene información adicional, como la descripción, el nombre y la versión del gráfico. Helm-docs se puede integrar en un compromiso previo junto con linting. Es fácil hacer esto:
$ helm-docs
INFO[2020-07-23T15:30:38+02:00] Found Chart directories [.]
INFO[2020-07-23T15:30:38+02:00] Generating README Documentation for chart .
La magia de los subcartas
Cuando su gráfico se convierte en el monstruo de la arquitectura, es mejor dividir algunos de los componentes del gráfico en otros más pequeños. Estos se denominan subgráficos o gráficos secundarios.
Los subgráficos se despliegan al mismo tiempo que el gráfico principal. Los valores para los subgráficos se pueden proporcionar en el mismo archivo values.yaml que para el gráfico principal. También puede conectarlos desde GitHub, pero para el artículo crearé un subgráfico localmente.
Para comenzar con un nuevo subgráfico del que depende el gráfico principal, cree un directorio de gráficos dentro de la carpeta principal del gráfico. Luego crea un gráfico básico:
$ mkdir charts
$ cd charts
$ helm create subbasic
Para conectar un subgráfico, cambie la definición del gráfico principal:
apiVersion: v1
appVersion: "1.0"
description: A Helm chart for Kubernetes
name: basic
version: 0.1.0
dependencies:
- name: subbasic
Ahora, cada vez que se lanza el comando
helm install, no solo se expande el gráfico principal, sino también el subgráfico. Para anular el nombre de referencia del subgráfico al implementar el servicio, agregue los siguientes comandos al archivo values.yaml del gráfico principal:
subbasic:
service:
type: NodePort
nameOverride: "jojo"
Ahora ejecute el comando
templatey vea la salida modificada del servicio de subchart. El tipo de servicio cambiará junto con el nombre:
---
# Source: basic/charts/subbasic/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
name: release-name-jojo
labels:
app.kubernetes.io/name: jojo
helm.sh/chart: subbasic-0.1.0
app.kubernetes.io/instance: release-name
app.kubernetes.io/version: "1.0"
app.kubernetes.io/managed-by: Tiller
spec:
type: NodePort
ports:
- port: 80
targetPort: http
protocol: TCP
name: http
selector:
app.kubernetes.io/name: jojo
app.kubernetes.io/instance: release-name
Nota importante: los subgráficos no pueden tomar valores de los gráficos principales.
Momentos que a menudo se olvidan
Algunos puntos más:
- Nombres de recursos: 63 caracteres como máximo.
- Los nombres de los recursos solo pueden ser números, letras minúsculas, "-" o ".".
- Tamaño del gráfico: no más de 1 MB . Esto es especialmente importante si está utilizando archivos adjuntos.
- El gráfico tiene una función de análisis
.tpl. - Puede especificar los recursos que permanecerán después de que el comando haya eliminado la implementación del gráfico
helm delete.
¡Bueno eso es todo!
Ahora puedes escribir tu primer gráfico. Vale la pena mencionar adjuntar archivos: los gráficos no son adecuados para agregar archivos y guardar su estructura en directorios. Pero en la página de recomendaciones, no encontrará información sobre qué graficar y qué no.
Helm es una herramienta bastante joven, pero con mucho potencial. No olvide que la creación de pelusa, la generación de documentación e incluso las plantillas de ejecución en seco en un clúster pueden ser parte del CI. Helm Workflow ya está disponible para GitHub .
¡Buena suerte!
Qué más leer: