Siguiendo al
operador de shell, presentamos a su hermano mayor:
operador de complemento . Este es un proyecto de código abierto que se utiliza para instalar componentes del sistema en el clúster de Kubernetes, que se puede llamar una palabra común: complementos.
¿Por qué hacer alguna adición?
No es ningún secreto que Kubernetes no es un producto terminado todo en uno, y se necesitarán varias adiciones para construir un clúster "adulto". Addon-operator ayudará a instalar, configurar y mantener estos complementos actualizados.
La necesidad de componentes adicionales en el clúster se revela en un
informe de colegas
driusha . En resumen, la situación con Kubernetes en este momento es que para una instalación simple puede "jugar" con componentes listos para usar, para desarrolladores y pruebas puede agregar Ingress, pero para una instalación completa, que puede decir "su producción está lista", necesita agregar una docena de complementos diferentes: algo para monitorear, algo para registros, no olvide ingresar y cert-manager, seleccionar grupos de hosts, agregar políticas de red, condimentar con configuraciones de sysctl y pod autoscaler ...
¿Cuáles son los detalles de trabajar con ellos?
Como muestra la práctica, el caso no se limita a una instalación. Para un trabajo cómodo con el clúster, los complementos deberán actualizarse, deshabilitarse (eliminarse del clúster) y deberá probar algo antes de instalarlo en el clúster de producción.
Entonces, ¿tal vez Ansible es suficiente aquí? Posiblemente Pero
las adiciones completas en el caso general no viven sin configuraciones . Esta configuración puede variar según la opción del clúster (aws, gce, azure, bare-metal, do, ...). Algunas configuraciones no se pueden establecer de antemano; deben obtenerse del clúster. Y el clúster no es estático: para algunas configuraciones tendrá que seguir los cambios. Y aquí ya falta Ansible: necesitamos un programa que viva en un clúster, es decir Operador Kubernetes.
Quienes hayan probado el
operador de shell en funcionamiento dirán que las tareas de instalación y actualización de complementos y configuraciones de seguimiento se pueden resolver completamente con la ayuda de
ganchos para el operador de shell. Puede escribir una secuencia de comandos que haga que
kubectl apply condicional se
kubectl apply y monitoree, por ejemplo, ConfigMap, donde se guardará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 admitir la configuración de plantillas y declarativa . No hacemos scripts mágicos que instalen complementos. El operador de complementos usa Helm para instalar complementos. Para instalar, debe crear un gráfico y resaltar los valores que se utilizarán para configurar.
- Las configuraciones se pueden generar durante la instalación , se pueden obtener del clúster o recibir actualizaciones al monitorear los recursos del clúster. Estas operaciones se pueden implementar utilizando ganchos.
- La configuración se puede almacenar en un clúster . Para almacenar la configuración en el clúster, se crea un ConfigMap / addon-operator y Addon-operator monitorea los cambios de este ConfigMap. Addon-operator le da a los ganchos acceso a la configuración usando convenciones simples.
- La adición depende de la configuración . Si la configuración ha cambiado, entonces Addon-operator despliega el Helm-chart con nuevos valores. La unión de la tabla Helm, los valores y los ganchos que llamamos módulo (ver más abajo para más detalles).
- Puesta en escena . No hay guiones de lanzamiento mágico. El mecanismo de actualización es similar a una aplicación normal: recopile complementos y operador de complementos en una imagen, pruebe y despliegue.
- Control del resultado . Addon-operator puede proporcionar métricas para Prometheus.
¿Cuál es el complemento en addon-operator?
Una adición se puede considerar todo lo que agrega nuevas funciones al clúster. Por ejemplo, instalar Ingress es un gran complemento. Puede ser cualquier operador o controlador con su propio CRD: prometheus-operator, cert-manager, kube-controller-manager, etc. O algo pequeño, pero que simplifica la operación, por ejemplo, copiadora secreta, copia de secretos de registro en nuevos espacios de nombres o sintonizador sysctl, configuración de parámetros sysctl en nuevos nodos.
Addon-operator proporciona varios conceptos para implementar complementos:
- El diagrama Helm se usa para instalar varios programas en el clúster, por ejemplo, Prometheus, Grafana, nginx-ingress. Si el componente requerido tiene una tabla Helm, entonces instalarlo usando el operador Addon será muy simple.
- Tienda de valores . Los gráficos de timón generalmente tienen muchas configuraciones diferentes que pueden cambiar con el tiempo. Addon-operator admite el almacenamiento de estas configuraciones y puede monitorear sus cambios para restablecer el Helm-chart con nuevos valores.
- Los ganchos son archivos ejecutables que Addon-operator ejecuta en eventos y que acceden al almacén de valores. El enlace puede monitorear los cambios en el clúster y actualizar los valores en el almacén de valores. Es decir Con la ayuda de ganchos, puede realizar un descubrimiento para recopilar valores del clúster al inicio o de acuerdo con una programación, o un descubrimiento continuo, mediante la recopilación de valores del clúster mediante cambios en el clúster.
- Un módulo es una unión de un gráfico Helm, almacenamiento de valores y ganchos. Los módulos se pueden encender y apagar. La desactivación de un módulo es la eliminación de todas las versiones del gráfico Helm. Los módulos pueden activarse dinámicamente, por ejemplo, si se incluyen todos los módulos que necesita o si el descubrimiento encuentra los parámetros necesarios en los ganchos, esto se hace utilizando un script habilitado auxiliar.
- Ganchos globales Estos son ganchos "por sí mismos", no están incluidos en los módulos y tienen acceso al almacenamiento de valores globales, cuyos valores están disponibles para todos los ganchos en los módulos.
¿Cómo funcionan juntas estas partes? Considere la imagen de la documentación:
Dos escenarios de trabajo:
- Un evento global desencadena un enlace global, por ejemplo, cuando cambia un recurso en un clúster. Este enlace procesa los cambios y escribe los nuevos valores en el almacenamiento de valores globales. Addon-operator nota que el almacenamiento global ha cambiado y lanza todos los módulos. Cada módulo, usando sus ganchos, determina si necesita ser activado y actualiza su almacén de valores. Si el módulo está habilitado, entonces Addon-operator comienza la instalación del Helm-chart. En este caso, los valores del almacenamiento del módulo y del almacenamiento global son accesibles para el diagrama Helm.
- El segundo escenario es más simple: un evento de activación de un enlace de módulo cambia los valores en el almacenamiento de valores del módulo. Addon-operator lo nota y lanza el gráfico Helm con valores actualizados.
El complemento se puede implementar como un enlace único o como un diagrama de Helm, o
incluso como varios módulos dependientes ; esto depende de la complejidad del componente instalado en el clúster y del nivel deseado de flexibilidad de configuración. Por ejemplo, en el repositorio (
/ ejemplos ) hay un complemento sysctl-tuner, que se implementa como un módulo simple con un gancho y un gráfico Helm, y que usa el almacenamiento de valores, lo que permite agregar configuraciones mediante la edición de ConfigMap.
Actualización de entrega
Algunas palabras sobre la organización de actualizaciones de componentes que instala Addon-operator.
Para ejecutar Addon-operator en un clúster, debe
recopilar una imagen con adiciones en forma de archivos de gráfico de gancho y timón, agregar el archivo binario
addon-operator y todo lo que se necesita para ganchos:
bash ,
kubectl ,
jq ,
python , etc. Además, esta imagen se puede implementar en el clúster como una aplicación normal, y lo más probable es que desee organizar este o aquel esquema de etiquetado. Si hay pocos grupos, el mismo enfoque que con las aplicaciones puede ser adecuado: una nueva versión, una nueva versión, revise todos los grupos y corrija la imagen para Pods. Sin embargo, en el caso de un lanzamiento a un número notable de grupos, el concepto de autorrenovación del canal fue más adecuado para nosotros.
Lo tenemos organizado así:
- Un canal es esencialmente un identificador que puede establecer cualquier persona (por ejemplo, dev / stage / ea / stable).
- El nombre del canal es la etiqueta de la imagen. Cuando necesite implementar actualizaciones para el canal, se recopila una nueva imagen y se etiqueta con el nombre del canal.
- Cuando aparece una nueva imagen en el registro, Addon-operator se reinicia y comienza con la nueva imagen.
Esta no es una práctica recomendada, como se describe en la
documentación de Kubernetes . Esto no se recomienda, pero estamos hablando de una
aplicación regular que vive en un clúster . En el caso de Addon-operator, una aplicación es una gran cantidad de implementaciones dispersas en clústeres, y la actualización automática es muy útil y simplifica la vida.
Los canales ayudan
en las pruebas : si hay un clúster auxiliar, puede configurarlo en el canal del
stage y actualizarlo antes de desplegarlo en
ea y canales
stable . Si se produce un error con el clúster en el canal
ea , puede cambiarlo a
stable mientras se lleva a cabo una investigación del problema con este clúster. Si el clúster se retira 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 deba
actualizar un componente de terceros . Por ejemplo, notó un error en el exportador de nodos condicional e incluso descubrió cómo parcharlo. Luego abrimos PR y esperamos que una nueva versión pase por todos los clústeres y aumente la versión de la imagen. Para no esperar indefinidamente, puede recopilar su exportador de nodos y cambiar a él antes de aceptar el RP.
En general, esto se puede hacer sin Addon-operator, pero con Addon-operator el módulo para instalar node-exporter estará visible en un repositorio, puede mantener el Dockerfile para construir su imagen allí mismo, se hace más fácil para todos los participantes en el proceso comprender que sucede ... Y si hay varios grupos, ¡será más fácil probar tu PR y enrollar una nueva versión!
Esta organización de actualizaciones de componentes funciona con éxito con nosotros, pero puede implementar cualquier otro esquema adecuado, porque
en este caso Addon-operator es un archivo binario simple .
Conclusión
Los principios implementados en Addon-operator le permiten construir un proceso transparente de creación, prueba, instalación y actualización de complementos en un clúster, similar a los procesos de desarrollo de aplicaciones ordinarias.
Los complementos para Addon-operator en el formato de módulos (Helm-chart + hooks) se pueden cargar al público. Nosotros, la compañía Flant, planeamos exponer nuestros logros durante el verano en forma de tales adiciones. Únase al desarrollo en GitHub (
shell-operator ,
addon-operator ), intente hacer su adición basada en
ejemplos y
documentación , ¡espere noticias sobre Habré y en nuestro
canal de YouTube !
ACTUALIZADO (14 de junio) : si tiene colegas de habla inglesa que puedan estar interesados en el operador adicional, entonces el anuncio correspondiente para ellos está disponible en nuestro blog en Medium .PS
Lea también en nuestro blog: