Siguiente presentamos a su hermano mayor - . Este es un proyecto de código abierto que se utiliza para instalar componentes del sistema en un clúster de Kubernetes, que pueden denominarse complementos.
¿Por qué alguna adición?
No es ningún secreto que Kubernetes no es un producto todo en uno ya preparado y que para crear un clúster "adulto" necesitará varias adiciones. Addon-operator lo ayudará a instalar, configurar y mantener estos complementos actualizados.
La necesidad de componentes adicionales en el clúster se describe en colegas . En resumen, la situación con Kubernetes en este momento es tal que para una instalación simple de "jugar" puede arreglárselas con los componentes listos para usar, para los desarrolladores y las pruebas puede agregar Ingress, pero para una instalación completa, sobre la cual puede decir "su producción está lista", debe agregar una docena de complementos diferentes: algo para monitorear, algo para registrar, no olvide el ingreso y el administrador de certificados, seleccione grupos de nodos, agregue políticas de red, temporada con configuración de escalador automático de sysctl y pod...
¿Cuáles son las características específicas de trabajar con ellos?
Como muestra la práctica, el asunto no se limita a una sola instalación. Para trabajar cómodamente con el clúster, será necesario actualizar, deshabilitar (eliminar del clúster) los complementos y deberá probar algunos antes de instalarlos en el clúster de producción.
Entonces, ¿tal vez Ansible sea suficiente aquí? Tal vez. Pero En general, los complementos completos no viven sin configuraciones. Estas configuraciones pueden diferir según la variante del clúster (aws, gce, azure, bare-metal, do, ...). Algunas configuraciones no se pueden especificar de antemano; deben obtenerse del clúster. Y el clúster no es estático: para algunas configuraciones tendrás que monitorear los cambios. Y aquí ya falta Ansible: necesita un programa que viva en un clúster, es decir. Operador de Kubernetes.
Quienes lo probaron en el trabajo. , dirán que las tareas de instalación y actualización de complementos y configuraciones de monitoreo se pueden resolver completamente usando para operador de shell. Puedes escribir un script que haga un condicional. kubectl apply y monitorear, por ejemplo, ConfigMap, donde se almacenarán las configuraciones. Esto es aproximadamente lo que se implementa en addon-operator.
¿Cómo se organiza esto en addon-operator?
Al crear una nueva solución, partimos de los siguientes principios:
- El instalador del complemento debe ser compatible creación de plantillas y configuración declarativa. No creamos scripts mágicos que instalen complementos. El operador de complementos usa Helm para instalar complementos. Para instalar, debe crear un gráfico y seleccionar los valores que se utilizarán para la configuración.
- Los ajustes pueden ser generar en la instalación, ellos pueden ser obtener del grupoO recibir actualizaciones, monitorear los recursos del clúster. Estas operaciones se pueden implementar mediante ganchos.
- Los ajustes pueden ser almacenar en un cluster. Para almacenar la configuración en el clúster, se crea un ConfigMap/addon-operator y el Addon-operator monitorea los cambios en este ConfigMap. El operador complementario brinda a los ganchos acceso a la configuración mediante convenciones simples.
- La adición depende de la configuración.. Si la configuración ha cambiado, el operador del complemento despliega el gráfico de Helm con nuevos valores. Llamamos módulo a la combinación del gráfico Helm, sus valores y enlaces (consulte a continuación para obtener más detalles).
- Puesta en escena. No existen guiones de lanzamiento mágicos. El mecanismo de actualización es similar al de una aplicación normal: recopile complementos y operadores de complementos en una imagen, etiquételos y ejecútelos.
- Control de resultados. El operador de complementos puede proporcionar métricas para Prometheus.
¿Qué es el relleno en el operador complemento?
Se puede considerar una adición cualquier cosa que agregue nuevas funciones al clúster. Por ejemplo, instalar Ingress es un gran ejemplo de complemento. Puede ser cualquier operador o controlador con su propio CRD: prometheus-operator, cert-manager, kube-controller-manager, etc. O algo pequeño, pero más fácil de usar, por ejemplo, una copiadora secreta, que copia los secretos del registro en nuevos espacios de nombres, o un sintonizador sysctl, que configura los parámetros de sysctl en nuevos nodos.
Para implementar complementos, Addon-operator proporciona varios conceptos:
- Carta de timón se utiliza para instalar varios programas en el clúster, por ejemplo, Prometheus, Grafana, nginx-ingress. Si el componente requerido tiene un gráfico Helm, instalarlo usando el operador Addon será muy simple.
- Almacenamiento de valores. Los gráficos de timón suelen tener muchas configuraciones diferentes que pueden cambiar con el tiempo. Addon-operator admite el almacenamiento de estas configuraciones y puede monitorear sus cambios para reinstalar el gráfico Helm con nuevos valores.
- Manos Son archivos ejecutables que el operador Addon ejecuta en eventos y que acceden al almacén de valores. El gancho puede monitorear los cambios en el clúster y actualizar los valores en el almacén de valores. Aquellos. Con los ganchos, puede realizar un descubrimiento para recopilar valores del clúster al inicio o según un cronograma, o puede realizar un descubrimiento continuo, recopilando valores del clúster en función de los cambios en el clúster.
- Módulo es una combinación de un gráfico Helm, un almacén de valores y ganchos. Los módulos se pueden habilitar o deshabilitar. Deshabilitar un módulo significa eliminar todas las versiones de gráficos de Helm. Los módulos pueden habilitarse dinámicamente, por ejemplo, si todos los módulos que necesita están habilitados o si el descubrimiento ha encontrado los parámetros necesarios en los enlaces; esto se hace mediante un script auxiliar habilitado.
- Ganchos globales. Estos son ganchos "por sí solos", no están incluidos en los módulos y tienen acceso a un almacén de valores global, cuyos valores están disponibles para todos los ganchos de los módulos.
¿Cómo funcionan juntas estas partes? Miremos la imagen de la documentación:
Existen dos escenarios de trabajo:
- El enlace global se activa mediante un evento, por ejemplo, cuando cambia un recurso en el clúster. Este gancho procesa los cambios y escribe los nuevos valores en el almacén de valores globales. El operador del complemento nota que el almacenamiento global ha cambiado e inicia todos los módulos. Cada módulo, utilizando sus ganchos, determina si es necesario habilitarlo y actualiza su almacén de valores. Si el módulo está habilitado, el operador del complemento inicia la instalación del gráfico Helm. En este caso, el gráfico Helm tiene acceso a los valores del almacenamiento del módulo y del almacenamiento global.
- El segundo escenario es más simple: un evento activa un enlace de módulo y cambia los valores en el almacén de valores del módulo. El operador del complemento se da cuenta de esto y lanza el gráfico Helm con valores actualizados.
La adición se puede implementar como un solo gancho, o como un gráfico Helm, o incluso como varios módulos dependientes - esto depende de la complejidad del componente que se instala en el clúster y del nivel deseado de flexibilidad de configuración. Por ejemplo, en el repositorio () hay un complemento sysctl-tuner, que se implementa como un módulo simple con un gancho y un gráfico Helm, y usando el almacén de valores, lo que permite agregar configuraciones editando ConfigMap.
Entrega de actualizaciones
Algunas palabras sobre la organización de las actualizaciones de componentes que instala el operador de complementos.
Para ejecutar Addon-operator en un clúster, necesita construir una imagen con adiciones en forma de archivos de gráfico de gancho y Helm, agregue un archivo binario addon-operator y todo lo necesario para los anzuelos: bash, kubectl, jq, python etc. Luego, esta imagen se puede implementar en el clúster como una aplicación normal y lo más probable es que desee organizar uno u otro esquema de etiquetado. Si hay pocos clústeres, puede ser adecuado el mismo enfoque que con las aplicaciones: nueva versión, nueva versión, ir a todos los clústeres y corregir la imagen de los Pods. Sin embargo, en el caso de una implementación en un número significativo de clusters, el concepto de actualización automática desde un canal nos resultó más adecuado.
Así es como lo hacemos:
- Un canal es esencialmente un identificador que se puede configurar con cualquier valor (por ejemplo, dev/stage/ea/stable).
- El nombre del canal es la etiqueta de la imagen. Cuando necesita implementar actualizaciones en un canal, se crea una nueva imagen y se etiqueta con el nombre del canal.
- Cuando aparece una nueva imagen en el registro, el operador Addon se reinicia y se inicia con la nueva imagen.
Esta no es una buena práctica, como está escrito en . No es recomendable hacer esto, pero estamos hablando de una aplicación normal que vive en el mismo clúster. En el caso del operador de complementos, una aplicación consta de muchas implementaciones repartidas en clústeres y la actualización automática ayuda mucho y hace la vida más fácil.
Los canales ayudan y en pruebas: si hay un cluster auxiliar, puedes configurarlo en el canal stage e implementar actualizaciones en él antes de implementarlo en los canales ea и stable. Si con un cluster en el canal. ea se produjo un error, puede cambiarlo a stable, mientras se investiga el problema con este clúster. Si el clúster sale del soporte activo, cambia a su canal "congelado", por ejemplo, freeze-2019-03-20.
Además de actualizar los ganchos y los gráficos de Helm, es posible que necesites actualización y componente de terceros. Por ejemplo, notó un error en el exportador de nodos condicional e incluso descubrió cómo solucionarlo. A continuación, abrió el PR y está esperando que la nueva versión revise todos los grupos y aumente la versión de la imagen. Para no esperar indefinidamente, puede crear su exportador de nodos y cambiarlo antes de aceptar el PR.
En general, esto se puede hacer sin Addon-operator, pero con Addon-operator el módulo para instalar node-exporter será visible en un repositorio, el Dockerfile para construir su imagen se puede guardar allí mismo, se vuelve más fácil para todos los participantes en el proceso para comprender lo que sucede... Y si hay varios grupos, entonces será más fácil probar su PR y lanzar una nueva versión.
Esta organización de la actualización de componentes nos funciona con éxito, pero se puede implementar cualquier otro esquema adecuado; después de todo en este caso Addon-operator es un archivo binario simple.
Conclusión
Los principios implementados en Addon-operator le permiten crear un proceso transparente para crear, probar, instalar y actualizar complementos en un clúster, similar a los procesos de desarrollo de aplicaciones normales.
Los complementos para el operador de complementos en formato de módulo (gráfico de timón + ganchos) se pueden poner a disposición del público. Nosotros, la empresa Flant, planeamos publicar nuestros desarrollos en forma de ampliaciones durante el verano. Únase al desarrollo en GitHub (, ), intenta hacer tu propia suma basada en и , espere noticias sobre Habré y sobre nuestro !
PS
Lea también en nuestro blog:
- «";
- «".
Fuente: habr.com