Introducción
Kubernetes ofrece de forma nativa las herramientas principales necesarias para administrar la implementación de aplicaciones. Sin embargo, aunque la aplicación de manifiestos YAML sin procesar es un proceso sencillo, el desarrollo en un entorno de microservicios rápidamente se sale de control con la cantidad de implementaciones necesarias para admitir un sistema completo.
Este artículo compara dos herramientas populares que tienen como objetivo simplificar la administración de la implementación de aplicaciones:Helm y Kustomize.
Helm:características clave
Helm es un administrador de paquetes para Kubernetes. Ayuda a instalar y administrar aplicaciones de Kubernetes mediante el uso de gráficos de timón, paquetes que contienen archivos YAML modificados con el lenguaje de plantilla Go y funciones de plantilla de la biblioteca Sprig.
Al emplear las plantillas y los valores dinámicos, Helm ofrece la capacidad de ajustar una configuración a lo largo del ciclo de vida del desarrollo de software.
Con la introducción de Helm 3, Helm dejó de depender de Tiller para la generación dinámica de archivos de configuración. Esto elimina una de las principales preocupaciones de seguridad de Helm 2:los amplios permisos otorgados de forma predeterminada para todos los que tienen acceso a Tiller. Helm ahora cuenta con componentes de administración de acceso privilegiado con control de acceso basado en roles (RBAC) y definiciones de recursos personalizadas (CRD).
Otra propiedad útil de las plantillas de Helm es la encapsulación. Las definiciones YAML de los objetos de Kubernetes, como Implementación, Servicio, ConfigMap o un secreto de Kubernetes, se pueden encapsular en una sola plantilla. Esta propiedad es útil para la configuración en tiempo de implementación.
Un gráfico de timón simple consta de:
- Un Gráfico.yaml archivo que declara el gráfico.
- Un valores.yaml archivo que contiene parámetros de gráfico para usar con plantillas.
- Un directorio de plantillas que contiene archivos de plantillas para crear el contenido del gráfico.
Un archivo de plantilla tiene la estructura de un archivo YAML, pero también contiene variables de plantilla que se reemplazan en la implementación con los valores proporcionados en values.yaml archivo.
Este es el contenido de un deployment.yaml típico parecerse a:
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ .Values.test }}
labels:
app: {{ .Values.test }}
spec:
selector:
matchLabels:
app: {{ .Values.test }}
template:
metadata:
labels:
app: {{ .Values.test }}
tier: web
spec:
containers:
- name: {{ .Values.test }}
image: {{ .Values.test }}
ports:
- containerPort: 8080
En el ejemplo anterior, Helm busca en values.yaml archivo para el valor de la test variable. Los valores.yaml relevantes El archivo contiene la definición de la variable:
test: defaultBasado en values.yaml definición, Helm crea el siguiente deployment.yaml archivo:
apiVersion: apps/v1
kind: Deployment
metadata:
name: default
labels:
app: default
spec:
selector:
matchLabels:
app: default
template:
metadata:
labels:
app: default
tier: web
spec:
containers:
- name: default
image: default
ports:
- containerPort: 8080
Helm presenta la capacidad de anular los valores en values.yaml usando el --set indicador al emitir comandos de compilación en la CLI.
También incluye el helm lint comando que examina un gráfico en busca de problemas y verifica que se haya diseñado de acuerdo con los estándares.
Personalizar:funciones clave
Kustomize es una herramienta que utiliza capas y parches en lugar de plantillas para personalizar los objetos de Kubernetes. Presenta el kustomization.yaml archivo de manifiesto, en el que los usuarios almacenan configuraciones específicas de implementación.
La herramienta está integrada en kubectl a partir de la versión 1.14, lo que significa que ahora es nativa en Kubernetes. Sin embargo, también puede instalarlo de forma independiente.
Con Kustomize, los usuarios pueden administrar cualquier cantidad de configuraciones de Kubernetes, cada una con su personalización distinta, utilizando el enfoque declarativo. Permite a los desarrolladores definir múltiples versiones de una aplicación y administrarlas en subdirectorios. El directorio base contiene las configuraciones comunes, mientras que los subdirectorios contienen parches específicos de la versión.
Cada directorio contiene su kustomization.yaml archivo que especifica qué cambios deben realizarse en la configuración y qué recursos deben utilizarse. Por ejemplo, el siguiente kustomization.yaml archivo agrega una etiqueta común app:test a ambos deployment.yaml y servicio.yaml en el directorio base:
commonLabels:
app: my-wordpress
resources:
- deployment.yaml
- service.yaml
Luego, los cambios se aplican escribiendo el siguiente comando en la línea de comando:
kubectl apply -k baseEl comando es diferente si Kustomize se usa como una herramienta independiente:
kustomize build base | kubectl apply -f -Helm y Kubernetes:pros y contras
Ventajas
- Helm ofrece muchas funciones que van más allá de la simple administración de configuración de implementación de aplicaciones, como empaquetado, enlaces y reversiones.
- Simplifica la instalación de la aplicación al permitir que los usuarios establezcan valores predeterminados que pueden configurar aún más con los valores si es necesario.
- Helm es bien conocido por los desarrolladores, tiene muchos usuarios y un excelente soporte en línea.
- Las funciones de plantilla de Helm permiten introducir condicionales y bucles, definir ayudantes y acceder a la biblioteca de funciones de Sprig.
- Las aplicaciones más utilizadas tienen sus gráficos de Helm disponibles en línea, lo que ahorra tiempo y aumenta la productividad.
Contras
- Helm agrega más capas de abstracción y tiene una curva de aprendizaje pronunciada.
- Limita la personalización de aplicaciones a opciones de configuración preexistentes.
- Las plantillas son propensas a errores, especialmente en términos de alineación adecuada de YAML.
- Helm no es compatible de forma nativa en Kubernetes, lo que crea una dependencia externa.
- A menudo es imperativo. Helm inyecta valores en las plantillas en tiempo de ejecución, por lo que si la plantilla cambia, el sistema puede diferir de lo que espera el usuario.
- Los gráficos aún requieren personalizaciones en tiempo de ejecución, lo que dificulta su administración al implementar la canalización de CI/CD.
- Las plantillas menos legibles conducen inevitablemente a una menor capacidad de personalización con el tiempo.
- Sufre de problemas de seguridad derivados de la falta de visibilidad y transparencia durante la instalación de las aplicaciones.
Personalizar y Kubernetes:pros y contras
Ventajas
- Personalizar es fácil de usar.
- Es declarativo, alineado con la filosofía de Kubernetes.
- Kustomize admite un modelo de base heredada, lo que lo hace escalar mejor que Helm.
- Usar la versión nativa integrada en kubectl elimina las dependencias externas.
- Facilita el uso de aplicaciones estándar.
- Utiliza solo archivos YAML sin formato.
Contras
- Personalizar no ofrece muchas funciones.
- No está diseñado para seguir el principio DRY (Don't Repeat Yourself).
- Los usuarios deben declarar manualmente los recursos y parches en kustomization.yaml y el archivo debe actualizarse manualmente cada vez que se agrega un nuevo archivo.
- La versión nativa integrada en kubectl es mucho más antigua que la versión independiente actual.
- Es difícil encontrar soporte en línea para Kustomize.
Kustomize vs Helm:tabla comparativa
| Característica | Helm | Personalizar |
|---|---|---|
| Plantillas | Sí | No |
| Superposiciones | No | Sí |
| Embalaje | Sí | No |
| ganchos de validación | Sí | No |
| Restauraciones | Sí | No |
| Integración nativa de K8s | No | Sí |
| Naturaleza declarativa | Principalmente imperativo | Sí |
| Visibilidad y transparencia | Débil | Fuerte |