Escrito por:
La finalidad de este artículo es facilitar el inicio rápido del uso de helm (un gestor de paquetes para kubernetes), bajo la estrategia de aprender sobre la marcha. En otras palabras, una vez entendido el artículo se puede empezar a profundizar en cada comando que se mencionará, usando para ello las referencias y links presentes en el documento.
Para leer este artículo es preferible tener claro los conceptos básicos de kubernetes (k8s), sin ser necesario una experiencia amplia en este. Un artículo recomendado es este: https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/.
Sin embargo se dará una breve explicación sobre está tecnología para contextualizar a los recién llegados al mundo de los micro-servicios.
Se espera que este primer “vistazo” a helm sea de su agrado.
Un breve concepto, traído desde la página oficial, y que da un buen panorama es:
Kubernetes ofrece un entorno de administración centrado en contenedores. Kubernetes orquesta la infraestructura de cómputo, redes y almacenamiento para que las cargas de trabajo de los usuarios no tengan que hacerlo. Esto ofrece la simplicidad de las Plataformas como Servicio (PaaS) con la flexibilidad de la Infraestructura como Servicio (IaaS) y permite la portabilidad entre proveedores de infraestructura.
Podemos decir que kubernetes (k8s) se ha ganado un espacio en el mundo de los micro-servicios, al poder encargarlo de la gestión de estos y de su escalabilidad entre muchas otras cosas.
Kubernetes, como orquestador de servicios trae muchas facilidades y una de las más conocidas podría ser el “deploy” que puede gestionar pods con muchas opciones. Sin embargo, podemos ver que el despliegue de estas aplicaciones requieren de otros recursos como “configmaps”, “services” e “ingress”, entre otros; Para un usuario de kubernetes realizar esta labor no es ningún problema, sin embargo, muchos de estos despliegues y su implementación se puede estandarizar y automatizar, lo que trae consigo orden, seguridad(configuración de acceso a pods) y sobre todo productividad (reuso y agilidad).
Para esto se crea helm, un gestor de paquetes para kubernetes que va un paso más allá, al proporcionar una opción para automatizar el proceso completo de creación de todos los recursos kubernetes que se necesitan para dejar funcional una aplicación completa (despliegue).
Interacción de Helm con k8s
En la imagen podemos ver el funcionamiento de helm que se puede describir de la siguiente manera:
A través del cli de helm instalado en nuestro pc, ejecutamos un comando que va y busca el chart a instalar en un repositorio y luego lo instala en un servidor de kubernetes (en un context) a través de Tiller el cual se encarga de la gestión de los charts e interactua con la API de kubernetes.
Antes de continuar, te aconsejamos que instales localmente alguna versión de k8s como microk8s y helm; Para ello te recomendamos este link: https://openwebinars.net/blog/como-instalar-y-empezar-utilizar-helm/
Muy simple, con el comando anterior estamos trayendo la aplicación prometheus, desde un repositorio helm (en donde se les llama charts) y lo esta instalando en un servidor con kubernetes(a través de Tiller), creando todos los recursos necesarios:
Arriba podemos ver (usando un comando kubernetes) y filtrando por la palabra “prometheus”, que se han creado varios deployments con sus pods y también múltiples servicios que de otra manera tocaría crearlos uno a uno, sin mencionar todo el proceso posterior de actualizaciones, borrados, seguimiento a todo el grupo de recursos como tal; Estos escenarios “uno a uno” pueden presentar problemas como que dicho despliegue en otro proyecto se haga, pero olvidando uno de los ingress o que en la migración de un cluster deje de funcionar algo (entre otros casos), y asuntos por el estilo que pueden llegar a ser complejos de solucionar y desgastantes.
Se podría intentar automatizar esto con algún bash. Pero con el tiempo y paciencia que esto requiere y con los otros comandos que proporciona helm (como el helm upgrade, etc..) sería una perdida de tiempo innecesaria (pues podemos hacer un chart) o encontrar un chart público ya funcional que despliegue la aplicación (con todo lo necesario previamente configurado y probado) y que además da opciones de personalización (ej. instalarla en el “namespace” que se requiera, entre muchas otras posibilidades).
Otros ejemplos de comandos helm, son:
helm init(inicia helm, tanto en el cliente como en el servidor)helm repo update(actualiza registros de repositorios)helm install stable/prometheus(Instala prometheus desde un repositorio). Si se hacen varias instalaciones del mismo chart, cada una tendrá un nombre (manifiesto) diferente que es asignado por Tiller.helm repo add elastic https://helm.elastic.co(Agrega el repositorio para poder instalar elasticsearch posteriormente), después de este comando es necesario ejecutar: helm repo updatehelm --help(muestra todos los comandos disponibles)helm install stable/nginx-ingress(instala nginx desde un repositorio, también llamado "chart path")helm upgrade plundering-aardvark stable/elasticsearch(actualiza el release "plundering-aardvark" del chart-path(repositorio) llamado stable/elasticsearch )helm ls --all --short (muestra los nombres de todos los manifiestos)helm delete --purge <manifest or release name>(elimina un "release")helm ls --all --short | xargs -L1 helm delete --purge (elimina todos los “releases”)
Los nombres de los manifiestos son los “releases” de las aplicaciones.
Más información sobre estos y otros comandos, los puedes encontrar acá: https://helm.sh/docs/helm/.
Además, podemos crear nuestros propios charts, lo que permite aprovechar helm y su estructura (con plantillas), para automatizar nuestros propios despliegues en kubernetes siguiendo estándares confiables de esta herramienta, y compartiéndolo con la comunidad si así lo queremos (pues alternativamente podemos crear repositorios privados también).
El anterior comando crea una estructura de carpetas con unos archivos preestablecidos para un chart llamado my-chart-name, en donde hay:
Además, hay otros archivos importantes como Chart.yaml que sirve para indicar la metadata de nuestro Chart. Para profundizar en este aspecto, recomiendo este link: https://medium.com/google-cloud/kubernetes-and-helm-create-your-own-helm-chart-5f54aed894c2
Después de esto los comando a tener en cuenta son:
helm lint(Corre una serie de tests para verificar que el chart este bien formado)helm install --dry-run --debug ./my-chart-name (Debug de lo que sucedería en la instalación)helm template ./my-chart-name (Muestra lo que el tiller intentará correr con kubectl en el kubernetes)helm install ./my-chart-name (Instala el chart recien creado a traves de Tiller). Si se hacen varias instalaciones del mismo chart, cada una tendrá un nombre (manifiesto) diferente. el cual es asignado por Tiller.helm test <manifest name>(Corre los tests especificados en la carpeta ./templates/tests/)
En conclusión, Helm se puede considerar y resumir, como una capa extra (reiterando lo dicho) que nos permite tener más agilidad (un solo comando para instalar), seguridad (configuración óptima preestablecida), y automatización(fácilmente replicable), en despliegues sencillos o complejos que se tornen repetitivos y poder re-usar dichos procesos por completo, tanto propios como de los repositorios públicos, sin perder dinamismo en los valores cambiantes de la instalación.
Espero que este artículo les sirva para iniciar, desde un enfoque sencillo, pero práctico. Dejo algunas referencias:
-Más información sobre nuestros meetups K8s Medellín. https://www.meetup.com/Kubernetes-and-Cloud-Native-Medellin/events/264907734/
Incubado por
Miembros de
Hatchet Ventures 22 Cohort 1
Nuestras certificaciones
.svg)
.png)
© Copyright | Cuemby® 2024
.png)
.png)
.png)