Una introducción práctica al administrador de paquetes para Kubernetes - Helm



El artículo es una continuación lógica de nuestra reciente publicación sobre la historia del administrador de paquetes para Kubernetes - Helm . Esta vez abordaremos nuevamente los problemas del dispositivo y el funcionamiento del Helm actual ( versión 2.x ), así como sus gráficos y repositorios administrados, después de lo cual pasaremos a la práctica de instalar Helm en el clúster de Kubernetes y usar los gráficos.

Entrada


Helm es una herramienta de gestión de gráficos.

El gráfico describe el conjunto de datos necesario para crear instancias de la aplicación en el clúster de Kubernetes. Puede tener gráficos incrustados y puede usarse tanto para describir servicios completos, que consisten en muchos recursos dependientes, como para describir componentes independientes individuales. Por ejemplo, el gráfico estable / gitlab-ce describe una solución completa utilizando los gráficos independientes redis y postgresql.

Se puede establecer un gráfico un número ilimitado de veces en el mismo clúster. Por lo tanto, la descripción de la lógica de implementación de la aplicación en diferentes entornos puede y debe almacenarse en el mismo gráfico.

El lado del cliente de Helm es responsable de crear el gráfico y transferir el componente Tiller al clúster de Kubernetes junto con los parámetros del usuario. A su vez, Tiller es responsable del ciclo de vida de la instancia del gráfico lanzado, lanzamiento. (Por si acaso, permítame recordarle que la próxima actualización importante de Helm, la versión 3, ya no tendrá Tiller).

Y ahora, lo primero es lo primero.

Instalación y actualización


Helm requiere que Kubernetes funcione. Puede usar un Minikube instalado localmente (consulte también " Introducción en Kubernetes con Minikube ") o cualquier otro clúster disponible.

Comencemos con la instalación del cliente: seleccione la versión , descargue y descomprima el archivo de su sistema, transfiera el archivo ejecutable ...

$ curl https://storage.googleapis.com/kubernetes-helm/helm-v2.10.0-linux-amd64.tar.gz | tar -zxv $ sudo mv linux-amd64/helm /usr/local/bin/helm 

A continuación, instale Tiller en el clúster. De manera predeterminada, Tiller se instala en el kubectl contexto de kubectl ( kubectl config current-context ), en el espacio de nombres del kube-system , pero esto se puede cambiar utilizando las opciones apropiadas y las variables de entorno; se describen en la ayuda ( helm init --help ). Completemos la instalación y observemos los recursos creados en el clúster:

 $ helm init $HELM_HOME has been configured at /home/habr/.helm. (Use --client-only to suppress this message, or --upgrade to upgrade Tiller to the current version.) Happy Helming! $ kubectl get all --selector=name=tiller --namespace kube-system NAME READY STATUS RESTARTS AGE po/tiller-deploy-df4fdf55d-h5mvh 0/1 Running 0 5s NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE svc/tiller-deploy 10.107.191.68 <none> 44134/TCP 5s NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE deploy/tiller-deploy 1 1 1 0 5s NAME DESIRED CURRENT READY AGE rs/tiller-deploy-df4fdf55d 1 1 0 5s 

Ahora Tiller está instalado en el clúster y está listo para la administración de versiones, la interacción con la API de Kubernetes.

Nota : Durante la instalación y actualización (opción - actualización) de Tiller, puede especificar una imagen específica en lugar de utilizar la última versión estable de forma predeterminada. El nombre de una imagen arbitraria está determinado por la opción --tiller-image , y con la opción --canary-image , se usará una --canary-image cuando Tiller se despliegue. La imagen canaria le permite utilizar Tiller, cuya versión del código corresponde a la rama maestra.

Los datos de servicio se almacenan en un clúster en recursos especiales, ConfigMaps , por lo que desinstalar y reinstalar Tiller no conduce a la pérdida de datos de versiones instaladas previamente.

Repositorios de cartas


Repositorio de gráficos: un servidor HTTP para almacenar y distribuir gráficos. La información sobre gráficos en el repositorio se almacena en el archivo index.yaml . También indica desde dónde se puede cargar cada gráfico. Con mayor frecuencia, los gráficos se almacenan con el archivo index.yaml , pero nada impide que se coloquen en otro servidor. Por lo general, la estructura del archivo se reduce a una forma plana:

 . ├── index.yaml ├── artifactory-7.3.0.tgz ├── docker-registry-1.5.2.tgz ... └── wordpress-2.1.10.tgz 

Por defecto, Helm usa el repositorio oficial de gráficos de Kubernetes . Contiene gráficos actuales cuidadosamente diseñados para resolver muchos problemas aplicados. Este repositorio se llama estable :

 $ helm repo list NAME URL stable https://kubernetes-charts.storage.googleapis.com 

Si es necesario, crear su propio repositorio no será ningún problema. Los requisitos del servidor son mínimos, por lo que, como la mayoría de los repositorios de gráficos públicos, se puede alojar en las páginas de GitHub. Puede leer más sobre las herramientas y los pasos necesarios para esto en la documentación .

Cuando se utilizan repositorios de gráficos, se pueden agregar y eliminar. Para que las versiones del gráfico estén actualizadas, debe actualizar periódicamente el índice. Daré un ejemplo para el repositorio público de bitnami , la mayoría de los cuales se utilizan en el repositorio oficial de Helm:

 $ helm repo add bitnami https://charts.bitnami.com/bitnami "bitnami" has been added to your repositories $ helm repo update Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "bitnami" chart repository ...Successfully got an update from the "stable" chart repository Update Complete. Happy Helming! $ helm repo remove bitnami "bitnami" has been removed from your repositories 

Siguiente: busca en los repositorios. Una llamada de helm search sin argumentos muestra todos los gráficos disponibles:

 $ helm search NAME CHART VERSION APP VERSION DESCRIPTION stable/acs-engine-autoscaler 2.2.0 2.1.1 Scales worker nodes within agent pools stable/aerospike 0.1.7 v3.14.1.2 A Helm chart for Aerospike in Kubernetes stable/anchore-engine 0.2.1 0.2.4 Anchore container analysis and policy evaluation engine s... stable/apm-server 0.1.0 6.2.4 The server receives data from the Elastic APM agents and ... stable/ark 1.2.1 0.9.1 A Helm chart for ark stable/artifactory 7.3.0 6.1.0 Universal Repository Manager supporting all major packagi... ... stable/weave-cloud 0.2.2 0.2.0 Weave Cloud is a add-on to Kubernetes which provides Cont... stable/weave-scope 0.9.3 1.6.5 A Helm chart for the Weave Scope cluster visualizer. stable/wordpress 2.1.10 4.9.8 Web publishing platform for building blogs and websites. stable/xray 0.4.1 2.3.0 Universal component scan for security and license invento... stable/zeppelin 1.0.1 0.7.2 Web-based notebook that enables data-driven, interactive ... stable/zetcd 0.1.9 0.0.3 CoreOS zetcd Helm chart for Kubernetes 

En el campo opcional de keywords en Chart.yaml desarrolladores especifican etiquetas que se utilizan para simplificar la búsqueda en los repositorios de gráficos:

 $ helm search web NAME CHART VERSION APP VERSION DESCRIPTION stable/cerebro 0.3.1 0.8.1 A Helm chart for Cerebro - a web admin tool that replaces... stable/chronograf 0.4.5 1.3 Open-source web application written in Go and React.js th... stable/jasperreports 2.0.4 7.1.0 The JasperReports server can be used as a stand-alone or ... stable/joomla 2.0.9 3.8.12 PHP content management system (CMS) for publishing web co... stable/kubernetes-dashboard 0.7.2 1.8.3 General-purpose web UI for Kubernetes clusters stable/odoo 2.0.7 11.0.20180815 A suite of web based open source business apps. stable/phabricator 2.1.9 2018.34.0 Collection of open source web applications that help soft... stable/redmine 4.1.0 3.4.6 A flexible project management web application. stable/rethinkdb 0.1.4 0.1.0 The open-source database for the realtime web stable/schema-registry-ui 0.1.0 v0.9.4 This is a web tool for the confluentinc/schema-registry i... stable/superset 0.1.2 0.24.0 Apache Superset (incubating) is a modern, enterprise-read... stable/testlink 2.0.3 1.9.17 Web-based test management system that facilitates softwar... stable/tomcat 0.1.0 7 Deploy a basic tomcat application server with sidecar as ... stable/wordpress 2.1.10 4.9.8 Web publishing platform for building blogs and websites. ... $ helm search cms blog NAME CHART VERSION APP VERSION DESCRIPTION stable/drupal 1.1.3 8.5.6 One of the most versatile open source content management ... stable/joomla 2.0.9 3.8.12 PHP content management system (CMS) for publishing web co... stable/wordpress 2.1.10 4.9.8 Web publishing platform for building blogs and websites 

Nota: Al usar el helm search , puede encontrar una operación inestable de varios filtros: la disponibilidad del resultado depende del orden de indicación y el número de filtros.

Después de que el círculo de búsqueda se haya reducido a varias opciones, puede proceder a un análisis más detallado de los gráficos, utilizando el helm inspect . Muestra el contenido de los archivos de gráficos Chart.yaml , values.yaml y README.md . Cada sección se puede mostrar individualmente con los argumentos correspondientes: chart , values y readme .

En el repositorio oficial, los gráficos están bellamente documentados y contienen ejemplos de uso, y algunos gráficos incluso tienen configuraciones listas para su producción . Por ejemplo, estable / wordpress proporciona un buen readme (para su salida en la consola, consulte helm inspect readme stable/wordpress ) .

Buscar es una buena forma de encontrar paquetes asequibles. Después de encontrar el paquete, puede usarlo para instalar la aplicación en el clúster.

Primera aplicación


Por ejemplo, se selecciona el gráfico estable / wordpress ya mencionado.

Utiliza los parámetros descritos en el archivo values.yaml . Puede anular los parámetros en un archivo YAML y luego transferir este archivo durante la instalación (opciones -f , --values ). Además, se pueden anular directamente en la línea de comando (opciones --set , --set-string y --set-file ). Todas las opciones están disponibles para usar un número arbitrario de veces; Al mismo tiempo, la anulación en la línea de comando tiene prioridad sobre los archivos con parámetros.

Al configurar el gráfico, puede configurar el nombre de la versión con la opción --name o usar el nombre aleatorio generado por Helm.

Establezca el cuadro de configuración para la producción , cambie el nombre del blog, desactive el almacenamiento de datos de WordPress en PersistentVolumeClaim (para obtener más información sobre el almacenamiento persistente, consulte la documentación de Kubernetes ) :

 $ curl https://raw.githubusercontent.com/helm/charts/master/stable/wordpress/values-production.yaml --output values-production.yaml $ helm install --name habr --set "wordpressBlogName=Flant's Blog!" --set "persistence.enabled=false" -f values-production.yaml stable/wordpress NAME: habr LAST DEPLOYED: Fri Aug 31 15:17:57 2018 NAMESPACE: default STATUS: DEPLOYED RESOURCES: ==> v1/Secret NAME TYPE DATA AGE habr-mariadb Opaque 2 0s habr-wordpress Opaque 2 0s ==> v1/ConfigMap NAME DATA AGE habr-mariadb-init-scripts 1 0s habr-mariadb 1 0s habr-mariadb-tests 1 0s ==> v1/Service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE habr-mariadb ClusterIP 10.111.7.232 <none> 3306/TCP 0s habr-wordpress ClusterIP 10.106.129.88 <none> 80/TCP,443/TCP 0s ==> v1beta1/Deployment NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE habr-wordpress 3 3 3 0 0s ==> v1beta1/StatefulSet NAME DESIRED CURRENT AGE habr-mariadb 1 1 0s ==> v1beta1/Ingress NAME HOSTS ADDRESS PORTS AGE wordpress.local-habr wordpress.local 80, 443 0s ==> v1/Pod(related) NAME READY STATUS RESTARTS AGE habr-wordpress-7955b95fd-hh7b9 0/1 ContainerCreating 0 0s habr-wordpress-7955b95fd-tgsxk 0/1 ContainerCreating 0 0s habr-wordpress-7955b95fd-xjz74 0/1 ContainerCreating 0 0s habr-mariadb-0 0/1 ContainerCreating 0 0s NOTES: 1. Get the WordPress URL: You should be able to access your new WordPress installation through https://wordpress.local/admin 2. Login with the following credentials to see your blog echo Username: user echo Password: $(kubectl get secret --namespace default habr-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode) 

En el caso de trabajar con un clúster completo, puede seguir las recomendaciones del bloque NOTAS anterior. Si tiene Minikube, abra el sitio en un navegador de la siguiente manera:

 $ minikube service habr-wordpress Waiting, endpoint for service is not ready yet... Opening kubernetes service default/habr-wordpress in default browser... 

¡Felicidades, la aplicación está en un clúster!



Un cuadro detallado con WordPress apareció en la lista de todas las versiones de Helm:

 $ helm list NAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE habr 1 Fri Aug 31 15:17:57 2018 DEPLOYED wordpress-2.1.10 4.9.8 default 

El siguiente paso es actualizar nuestro lanzamiento y cambiar la imagen con el blog. Por ejemplo, se 4.9.8-ol-7 otra etiqueta del mismo repositorio de Docker ( 4.9.8-ol-7 ):

 $ helm upgrade habr --set "image.tag=4.9.8-ol-7" --set "wordpressBlogName=Flant's Blog!" --set "persistence.enabled=false" -f values-production.yaml stable/wordpress Release "habr" has been upgraded. Happy Helming! LAST DEPLOYED: Fri Aug 31 15:21:08 2018 NAMESPACE: default STATUS: DEPLOYED RESOURCES: ==> v1/Service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE habr-mariadb ClusterIP 10.111.7.232 <none> 3306/TCP 3m habr-wordpress ClusterIP 10.106.129.88 <none> 80/TCP,443/TCP 3m ==> v1beta1/Deployment NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE habr-wordpress 3 4 2 0 3m ==> v1beta1/StatefulSet NAME DESIRED CURRENT AGE habr-mariadb 1 1 3m ==> v1beta1/Ingress NAME HOSTS ADDRESS PORTS AGE wordpress.local-habr wordpress.local 80, 443 3m ==> v1/Pod(related) NAME READY STATUS RESTARTS AGE habr-wordpress-66f4fd6b74-gqwhh 0/1 Pending 0 0s habr-wordpress-66f4fd6b74-mf6vj 0/1 Pending 0 0s habr-wordpress-7955b95fd-hh7b9 1/1 Running 2 3m habr-wordpress-7955b95fd-tgsxk 1/1 Running 2 3m habr-wordpress-7955b95fd-xjz74 0/1 Terminating 2 3m habr-mariadb-0 1/1 Running 0 3m ==> v1/Secret NAME TYPE DATA AGE habr-mariadb Opaque 2 3m habr-wordpress Opaque 2 3m ==> v1/ConfigMap NAME DATA AGE habr-mariadb-init-scripts 1 3m habr-mariadb 1 3m habr-mariadb-tests 1 3m NOTES: 1. Get the WordPress URL: You should be able to access your new WordPress installation through https://wordpress.local/admin 2. Login with the following credentials to see your blog echo Username: user echo Password: $(kubectl get secret --namespace default habr-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode) 

Tenga en cuenta que al actualizar Tiller compara el gráfico recibido con los parámetros con el último guardado y realiza las solicitudes correspondientes en la API de Kubernetes, y el estado actual de los recursos de la versión no se tiene en cuenta . Es importante comprender esta característica y no cometer errores:

  • La actualización no es diferente de la instalación: el cliente Helm envía la tabla Tiller junto con los parámetros, por lo que debe tener cuidado y recordar especificar los parámetros y archivos con los parámetros que se establecieron durante la instalación (o durante la actualización anterior) y que no deben ignorarse. En el ejemplo anterior, esto es --set "wordpressBlogName=Flant's Blog!" --set "persistence.enabled=false" -f values-production.yaml --set "wordpressBlogName=Flant's Blog!" --set "persistence.enabled=false" -f values-production.yaml .
  • Las aplicaciones que se implementan con Helm solo deben servirse con Helm: Helm no tendrá en cuenta los cambios manuales realizados con kubectl y pueden tener consecuencias irreversibles.

De ahí la conclusión lógica: el proceso debe automatizarse y los cambios deben realizarse solo mediante la confirmación en el repositorio de Git, cambiando los archivos de gráficos y el archivo de configuración de CI.

El estado de los componentes de lanzamiento de la aplicación en un clúster siempre se puede verificar de la siguiente manera:

 $ helm status habr LAST DEPLOYED: Fri Aug 31 15:21:08 2018 NAMESPACE: default STATUS: DEPLOYED RESOURCES: ==> v1/Secret NAME TYPE DATA AGE habr-mariadb Opaque 2 4m habr-wordpress Opaque 2 4m ==> v1/ConfigMap NAME DATA AGE habr-mariadb-init-scripts 1 4m habr-mariadb 1 4m habr-mariadb-tests 1 4m ==> v1/Service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE habr-mariadb ClusterIP 10.111.7.232 <none> 3306/TCP 4m habr-wordpress ClusterIP 10.106.129.88 <none> 80/TCP,443/TCP 4m ==> v1beta1/Deployment NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE habr-wordpress 3 4 2 3 4m ==> v1beta1/StatefulSet NAME DESIRED CURRENT AGE habr-mariadb 1 1 4m ==> v1beta1/Ingress NAME HOSTS ADDRESS PORTS AGE wordpress.local-habr wordpress.local 80, 443 4m ==> v1/Pod(related) NAME READY STATUS RESTARTS AGE habr-wordpress-66f4fd6b74-gqwhh 0/1 Pending 0 1m habr-wordpress-66f4fd6b74-mf6vj 1/1 Running 0 1m habr-wordpress-7955b95fd-hh7b9 1/1 Running 3 4m habr-wordpress-7955b95fd-tgsxk 1/1 Running 3 4m habr-mariadb-0 1/1 Running 1 4m NOTES: 1. Get the WordPress URL: You should be able to access your new WordPress installation through https://wordpress.local/admin 2. Login with the following credentials to see your blog echo Username: user echo Password: $(kubectl get secret --namespace default habr-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode) 

Helm le permite retroceder a una revisión de lanzamiento específica . Actualmente hay dos revisiones:

 $ helm history habr REVISION UPDATED STATUS CHART DESCRIPTION 1 Fri Aug 31 15:17:57 2018 SUPERSEDED wordpress-2.1.10 Install complete 2 Fri Aug 31 15:21:08 2018 DEPLOYED wordpress-2.1.10 Upgrade complete 

Regrese la aplicación a su estado original:

 $ helm rollback habr 1 Rollback was a success! Happy Helming! 

Ahora el historial de revisiones se ha rellenado con un registro:

 $ helm history habr REVISION UPDATED STATUS CHART DESCRIPTION 1 Fri Aug 31 15:17:57 2018 SUPERSEDED wordpress-2.1.10 Install complete 2 Fri Aug 31 15:21:08 2018 SUPERSEDED wordpress-2.1.10 Upgrade complete 3 Fri Aug 31 15:25:06 2018 DEPLOYED wordpress-2.1.10 Rollback to 1 

¿El artículo está llegando a su fin y ya no se requiere el lanzamiento?

 $ helm delete habr release "habr" deleted 

¿Está realmente eliminado? ..

El comando elimina los recursos de Kubernetes asociados con la versión, pero no la versión en sí . Toda la información sobre el lanzamiento permanece disponible, incluido su historial:

 $ helm list --all NAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE habr 3 Fri Aug 31 15:25:06 2018 DELETED wordpress-2.1.10 4.9.8 default 

 $ helm history habr REVISION UPDATED STATUS CHART DESCRIPTION 1 Fri Aug 31 15:17:57 2018 SUPERSEDED wordpress-2.1.10 Install complete 2 Fri Aug 31 15:21:08 2018 SUPERSEDED wordpress-2.1.10 Upgrade complete 3 Fri Aug 31 15:25:06 2018 DELETED wordpress-2.1.10 Deletion complete 

Nota : Según lo planeado, la versión remota se puede revertir a versiones anteriores, pero en versiones recientes esta característica no funciona; consulte el número 3722 para obtener más detalles.

Para eliminar completamente la versión, use la opción --purge :

 $ helm delete --purge habr release "habr" deleted 

Resumiendo


Este artículo habla sobre la arquitectura básica de Helm 2, sus componentes y sus funciones, así como las primitivas básicas, gráficos, versiones y repositorios de gráficos. Instalamos Helm en el clúster de Kubernetes y entendimos el ciclo de vida de la versión y los comandos básicos para trabajar con él.

El siguiente material de esta serie estará dedicado al tema de crear su propio gráfico : en él hablaré sobre la estructura del gráfico, las herramientas de estandarización y depuración. ACTUALIZADO : Un nuevo artículo está disponible en este enlace .

PS


Source: https://habr.com/ru/post/es420437/


All Articles