Siguiendo con presentamos a su hermano mayor — . Este es un proyecto de código abierto que se utiliza para instalar en el clúster de Kubernetes los componentes del sistema que se pueden denominar en conjunto como complementos.
¿Por qué necesitamos algún complemento?
No es un secreto que Kubernetes no es un producto listo para usar todo en uno, y para construir un clúster 'maduro' se necesitarán varios complementos. Addon-operator ayudará a instalar, configurar y mantener estos complementos actualizados.
La necesidad de componentes adicionales en el clúster se revela en colegas . En resumen, la situación con Kubernetes en este momento es tal que para una instalación sencilla, para 'jugar', se puede prescindir de los componentes de serie, para desarrolladores y pruebas se puede agregar Ingress, pero para una instalación completa, de la que se puede decir 'su producción está lista', es necesario añadir alrededor de una docena de complementos diferentes: algo para monitoreo, algo para registros, no olvidar ingress y cert-manager, asignar grupos de nodos, agregar políticas de red, añadir configuraciones de sysctl y pod autoscaler...
¿Cuál es la especificidad del trabajo con ellos?
Como muestra la práctica, no se trata solo de una instalación. Para trabajar cómodamente con el clúster, será necesario actualizar los complementos, desactivarlos (eliminarlos del clúster), y puede que algo se quiera probar antes de instalar en el clúster de producción.
Entonces, ¿quizás aquí sería suficiente con Ansible? Puede ser. Pero los complementos completos en general no funcionan sin configuraciones. Estas configuraciones pueden variar dependiendo de la variante del clúster (aws, gce, azure, bare-metal, do, ...). Algunas configuraciones no se pueden establecer de antemano, es necesario obtenerlas del clúster. Y el clúster no es estático: para algunas configuraciones será necesario vigilar los cambios. Y aquí Ansible no es suficiente: se necesita un programa que viva en el clúster, es decir, Kubernetes Operator.
Aquellos que lo han probado en acción , dirán que las tareas de instalación y actualización de complementos y seguimiento de configuraciones se pueden resolver bastante bien con para shell-operator. Se puede escribir un script que realice un supuestos kubectl apply y vigile, por ejemplo, ConfigMap, donde se almacenarán las configuraciones. Esto es aproximadamente lo que se implementa en addon-operator.
¿Cómo está organizado en addon-operator?
Al crear una nueva solución, partimos de los siguientes principios:
- El instalador de complementos debe soportar plantillas y configuración declarativa. No hacemos scripts mágicos que instalen complementos. El operador de complementos utiliza Helm para instalar complementos. Para la instalación, es necesario crear un chart y especificar los values que se usarán para la configuración.
- Las configuraciones se pueden generar durante la instalación, se pueden obtener del clúster, o recibir actualizaciones, supervisando los recursos del clúster. Estas operaciones se pueden implementar usando hooks.
- Las configuraciones se pueden almacenar en el clúster. Para almacenar configuraciones en el clúster se crea un ConfigMap/addon-operator y el Addon-operator supervisa los cambios de este ConfigMap. El Addon-operator proporciona acceso a la configuración a los hooks mediante acuerdos simples.
- El complemento depende de la configuración. Si la configuración cambia, el Addon-operator despliega el Helm-chart con nuevos values. La combinación del Helm-chart, los values para este y los hooks lo hemos llamado módulo (más detalles a continuación).
- Fase de staging. No hay scripts mágicos de lanzamiento. El mecanismo de actualización es similar al de una aplicación normal: construir los complementos y el addon-operator en una imagen, etiquetarlos y desplegarlos.
- Control de resultados. El Addon-operator puede proporcionar métricas para Prometheus.
¿Qué es un complemento en el addon-operator?
Un complemento se puede considerar cualquier cosa que añada nuevas funciones al clúster. Por ejemplo, la instalación de Ingress es un gran ejemplo de un complemento. Puede ser cualquier operador o controlador con su CRD: prometheus-operator, cert-manager, kube-controller-manager, etc. O algo pequeño, pero que simplifique la operación, como un copión de secretos que copia secretos de registro a nuevos espacios de nombres, o un ajustador de sysctl que configura parámetros de sysctl en nuevos nodos.
Para implementar complementos, el Addon-operator proporciona varios conceptos:
- Helm-chart se usa para instalar diferentes software en el clúster, como Prometheus, Grafana, nginx-ingress. Si el componente necesario tiene un Helm-chart, será muy fácil instalarlo con el Addon-operator.
- Almacenamiento de values. Los Helm-charts suelen tener muchas configuraciones diferentes que pueden cambiar con el tiempo. El Addon-operator admite el almacenamiento de estas configuraciones y puede supervisar sus cambios para reinstalar el Helm-chart con nuevos valores.
- Hooks son archivos ejecutables que el Addon-operator activa en función de eventos y que tienen acceso al almacenamiento de valores. Un hook puede supervisar los cambios en el clúster y actualizar los valores en el almacenamiento de valores. Esto significa que, a través de hooks, se puede realizar un descubrimiento para recopilar valores del clúster al inicio o mediante programación, o también un descubrimiento continuo, recopilando valores del clúster según los cambios en el mismo.
- Módulo es una combinación de un chart de Helm, un almacenamiento de valores y hooks. Los módulos se pueden activar y desactivar. Desactivar un módulo significa eliminar todos los lanzamientos del chart de Helm. Los módulos pueden activarse dinámicamente, por ejemplo, si están habilitados todos los módulos necesarios o si el discovery en los hooks encontró los parámetros requeridos; esto se logra mediante un script auxiliar habilitado.
- Hooks globales. Son hooks "por sí mismos", no están incluidos en módulos y tienen acceso al almacenamiento global de valores, cuyos valores están disponibles para todos los hooks en los módulos.
¿Cómo trabajan estas partes juntas? Veamos la imagen de la documentación:
Hay dos escenarios de funcionamiento:
- El hook global se activa por un evento, por ejemplo, al cambiar un recurso en el clúster. Este hook procesa los cambios y registra nuevos valores en el almacenamiento global de valores. El Addon-operator nota que el almacenamiento global ha cambiado y activa todos los módulos. Cada módulo, a través de sus hooks, determina si necesita activarse y actualiza su almacenamiento de valores. Si el módulo está habilitado, el Addon-operator inicia la instalación del chart de Helm. Al chart de Helm le son accesibles los valores del almacenamiento del módulo y del almacenamiento global.
- El segundo escenario es más sencillo: el hook modular se activa por un evento y modifica los valores en el almacenamiento de valores del módulo. El Addon-operator lo nota y activa el chart de Helm con los valores actualizados.
El complemento puede ser implementado como un solo hook o como un solo chart de Helm, o incluso como varios módulos dependientes , esto depende de la complejidad del componente que se está instalando en el clúster y del nivel de flexibilidad de la configuración que se requiere. Por ejemplo, en el repositorio () hay un complemento sysctl-tuner, que se implementa tanto como un simple módulo con un hook y un chart de Helm, como utilizando un almacenamiento de valores, lo que permite agregar configuraciones a través de la edición de ConfigMap.
Entrega de actualizaciones
Algunas palabras sobre la organización de las actualizaciones de los componentes que instala el Addon-operator.
Para ejecutar el Addon-operator en el clúster, se necesita compilar una imagen con complementos en forma de archivos de ganchos y gráficos de Helm, agregar el archivo binario addon-operator y todo lo que se necesite para los ganchos: bash, kubectl, jq, python etc. Luego, esta imagen se puede desplegar en el clúster como una aplicación normal y probablemente querrás organizar algún tipo de esquema de etiquetado. Si hay pocos clústeres, puede que el mismo enfoque que con las aplicaciones funcione: nuevo lanzamiento, nueva versión, ir a todos los clústeres y actualizar la imagen en los pods. Sin embargo, en caso de un despliegue en una cantidad considerable de clústeres, la conceptualización de autoactualización desde el canal es más adecuada.
Esto está organizado así:
- El canal es, en esencia, un identificador que se puede asignar a cualquiera (por ejemplo, dev/stage/ea/stable).
- El nombre del canal es la etiqueta de la imagen. Cuando se necesita desplegar actualizaciones en el canal, se compila una nueva imagen y se etiqueta con el nombre del canal.
- Cuando aparece una nueva imagen en el registro, el Addon-operator se reinicia y se inicia con la nueva imagen.
Esto no es una buena práctica, como se indica en . No se recomienda hacerlo, pero se trata de una aplicación normal que vive en un solo clúster. En el caso del Addon-operator, la aplicación es un conjunto de despliegues dispersos en los clústeres, y la autoactualización simplifica mucho la vida.
Los canales ayudan también en las pruebas: si hay un clúster auxiliar, se puede configurarlo en el canal stage y probar las actualizaciones en él antes de lanzarlas en los canales ea y stable. Si ocurre un error con el clúster en el canal, se puede cambiar a ea , mientras se investiga el problema con ese clúster. Si el clúster se ha sacado de soporte activo, se cambia a su canal de "congelación" - por ejemplo, stablefreeze-2019-03-20 . Además de las actualizaciones de ganchos y gráficos de Helm, puede ser necesario.
actualizar un componente externo . Por ejemplo, si has notado un error en el node-exporter condicional y hasta has ideado cómo parchearlo. Luego, abriste un PR y esperas el nuevo lanzamiento para recorrer todos los clústeres y aumentar la versión de la imagen. Para no esperar un tiempo indefinido, puedes compilar tu propio node-exporter y cambiar a él hasta que se acepte el PR..
De hecho, esto se puede hacer sin el Addon-operator, pero con el Addon-operator, el módulo para instalar node-exporter estará en un único repositorio, se puede mantener el Dockerfile para construir su propia imagen justo aquí, y resulta más fácil para todos los participantes entender lo que está sucediendo... ¡Y si hay varios clústeres, se simplifica tanto la prueba de su PR como la implementación de una nueva versión!
Este sistema de actualización de componentes funciona con éxito para nosotros, pero se puede implementar cualquier otro esquema adecuado, ya que en este caso, el Addon-operator es un simple archivo binario..
Conclusión
Los principios implementados en el Addon-operator permiten establecer un proceso transparente para crear, probar, instalar y actualizar complementos en el clúster, similar a los procesos de desarrollo de aplicaciones comunes.
Los complementos para el Addon-operator en formato de módulos (Helm chart + hooks) se pueden hacer accesibles al público. Nosotros, la empresa Flant, planeamos publicar nuestras contribuciones en forma de tales complementos durante el verano. Únase al desarrollo en GitHub (, ), intente crear su propio complemento basado en y , espere novedades en Habr y en nuestro !
P.D.
También puedes leer en nuestro blog:
- «»;
- «».
Fuente: habr.com
