Timón sin exageración. Mirada sobria
Helm es un administrador de paquetes para Kubernetes.
A primera vista, no está mal. Esta herramienta simplifica enormemente el proceso de lanzamiento, pero a veces puede ser una molestia, ¡no hará nada!
Recientemente, Helm fue reconocido oficialmente como el principal proyecto @CloudNativeFdn , es ampliamente utilizado por la comunidad. Esto dice mucho, pero me gustaría hablar brevemente sobre los momentos desagradables asociados con este administrador de paquetes.
¿Cuál es el verdadero valor de Helm?
Todavía no puedo responder esta pregunta con confianza. Helm no proporciona ninguna característica especial. ¿Qué beneficios aporta Tiller (lado del servidor)?
Muchos gráficos de Helm están lejos de ser perfectos, y se necesita un esfuerzo adicional para usarlos en el clúster de Kubernetes. Por ejemplo, carecen de RBAC, límites de recursos y políticas de red. Simplemente agarrar e instalar el gráfico Helm en forma binaria, sin pensar en cómo funcionará, no funcionará.
No es suficiente alabar a Helm, dando los ejemplos más simples. Explicará por qué es tan bueno, especialmente en términos de un entorno de trabajo seguro para múltiples inquilinos.
Las palabras están vacías ¡Muéstrame el código!
—Linus Torvalds
Un nivel adicional de autorización y control de acceso.
Recuerdo que alguien comparó a Tiller con un "gran servidor de sudo". En mi opinión, este es solo el siguiente nivel de autorización, que al mismo tiempo requiere certificados TLS adicionales, pero no proporciona capacidades de control de acceso. ¿Por qué no utilizar la API de Kubernetes y el modelo de seguridad existente que admite auditorías y RBAC?
¿Una herramienta de procesamiento de plantillas sobrevalorada?
El hecho es que para el procesamiento y el análisis estático de los archivos de plantilla Go, se values.yaml la configuración del archivo values.yaml , y luego el manifiesto Kubernetes procesado se usa con los metadatos correspondientes almacenados en ConfigMap.
Y puede usar algunos comandos simples:
$ # render go-template files using golang or python script $ kubectl apply --dry-run -f . $ kubectl apply -f .
Noté que los desarrolladores usualmente usaban un archivo values.yaml por entorno, o incluso lo obtenían de values.yaml.tmpl antes de usarlo.
Esto no tiene sentido cuando se trabaja con secretos de Kubernetes, que a menudo están encriptados y tienen varias versiones en el repositorio. Para evitar esta limitación, deberá usar el complemento helm-secrets o el --set key=value . En cualquier caso, se agrega otro nivel de complejidad.
Helm como herramienta de gestión del ciclo de vida de la infraestructura
Olvídalo. Esto no es posible, especialmente si hablamos de los componentes principales de Kubernetes, como kube-dns, el proveedor de CNI, el autoescalador de clúster, etc. Los ciclos de vida de estos componentes varían y Helm no encaja en ellos.
Mi experiencia con Helm muestra que esta herramienta es ideal para implementaciones simples en los recursos centrales de Kubernetes, implementadas fácilmente desde cero y sin un proceso de lanzamiento complicado.
Desafortunadamente, con implementaciones más complejas y frecuentes, incluyendo Namespace, RBAC, NetworkPolicy, ResourceQuota y PodSecurityPolicy, Helm no puede hacer frente.
Entiendo que a los fanáticos de Helm pueden no gustarles mis palabras, pero esta es la realidad.
Timón estatal
El servidor Tiller almacena información en archivos ConfigMap dentro de Kubernetes. No necesita su propia base de datos.
Desafortunadamente, el tamaño de ConfigMap no puede exceder 1 MB debido a limitaciones de etcd .
Esperemos que alguien encuentre una manera de mejorar el controlador de almacenamiento de ConfigMap para comprimir la versión serializada antes de pasar al almacenamiento. Sin embargo, creo que el verdadero problema aún no se puede resolver.
Accidentes aleatorios y manejo de errores
Para mí, el mayor problema de Helm es su inseguridad.
Error: ERROR DE ACTUALIZACIÓN: "foo" no tiene lanzamientos implementados
Esto, en mi humilde opinión, es uno de los problemas más molestos de Helm.
Si no fue posible crear la primera versión, cada intento posterior fallará con un error que indica la imposibilidad de actualizar desde un estado desconocido.
La siguiente solicitud de inclusión de cambios "corrige" el error al agregar el indicador --force , que en realidad solo enmascara el problema ejecutando el helm delete & helm install —replace .
Sin embargo, en la mayoría de los casos, deberá realizar una limpieza completa de la versión.
helm delete --purge $RELEASE_NAME
Error: error de liberación: se agotó el tiempo de espera esperando la condición
Si falta la cuenta de servicio o RBAC no permite la creación de un recurso específico, Helm devolverá el siguiente mensaje de error:
Error: release foo failed: timed out waiting for the condition
Desafortunadamente, la causa raíz de este error no se puede ver:
kubectl -n foo get events --sort-by='{.lastTimestamp}'
Error creating: pods "foo-5467744958" is forbidden: error looking up service account foo/foo: serviceaccount "foo" not found
Fallar de la nada
En los casos más avanzados, Helm arroja un error sin realizar ninguna acción. Por ejemplo, a veces no actualiza los límites de recursos.
helm init ejecuta la barra timón con una copia, no en la configuración HA
Tiller por defecto no implica una alta disponibilidad, y la solicitud para habilitar los cambios por referencia aún está abierta.
Algún día conducirá al tiempo de inactividad ...
Timón 3? Operadores? El futuro?
La próxima versión de Helm agregará algunas características prometedoras:
- Arquitectura de servicio único sin separación entre cliente y servidor. No más timón;
- motor de secuencias de comandos Lua incorporado;
- Flujo de trabajo de DevOps basado en solicitudes de inclusión y el nuevo proyecto Helm Controller.
Consulte las Propuestas de proyectos de Helm 3 para obtener más información.
Realmente me gusta la idea de la arquitectura sin Tiller, pero los guiones basados en Lua están en duda, porque pueden complicar los gráficos.
Me di cuenta de que recientemente los operadores que son mucho más adecuados para Kubernetes que los gráficos Helm han ganado popularidad.
Realmente espero que la comunidad se ocupe pronto de los problemas de Helm (con nuestra ayuda, por supuesto), pero por ahora trataré de usar esta herramienta lo menos posible.
Entienda esto: este artículo es mi opinión personal, a la que llegué al crear una plataforma de nube híbrida para implementaciones basadas en Kubernetes.