De alguna manera en los comentarios hicieron la pregunta de cómo la participación en el Slurm difiere de la lectura de manuales en Kubernetes. Le pedí a Pavel Selivanov, orador de Slurm-2 y MegaSlurm, que diera un pequeño ejemplo de lo que contará sobre Slurms. Le doy la palabra.
Estoy administrando el clúster de Kubernetes. Recientemente, necesitaba actualizar la versión de k8s e, incluso, reiniciar todas las máquinas en el clúster. Comencé el proceso a las 12:00 y al final de la jornada laboral todo estaba listo. Y por primera vez, seguí el progreso de la actualización, y la segunda vez me fui a almorzar durante 1,5 horas (para ser justos, agarrando una computadora portátil). El clúster en sí se actualizó, sin mi participación e invisible para los clientes, el desarrollo no notó nada, las implementaciones continuaron, el servicio funcionó como de costumbre.
Lo que parecía.
Problemas probables
Al reiniciar las máquinas, hay dos escenarios malos.
- El desarrollador lanzó la aplicación / redis en una instancia. No importa cuán cuidadosamente saque el automóvil del servicio, el tiempo de inactividad ocurrirá.
- Hay 2 réplicas de la aplicación, y una está implementada. Ella salió, solo había una réplica, y luego el administrador llega y apaga la última réplica. Nuevamente, hasta que la réplica aumente después de la implementación, habrá tiempo de inactividad.
Podría coordinar el reinicio con el desarrollo, dicen, detener la implementación, verificar las instancias, reiniciaré las máquinas, pero me gusta la idea de DevOps de que la comunicación humana debe ser minimizada. Es mejor configurar la automatización una vez que coordinar sus acciones cada vez.
Condiciones de la tarea
Yo uso Amazon con su comodidad y estabilidad. Todo está automatizado, puede crear y extinguir máquinas virtuales, verificar su disponibilidad, etc.
El clúster de Kubernetes se implementa, administra y actualiza a través de la utilidad kops, que realmente me encanta.
Al actualizar kops, drena automáticamente un nodo (nodo de drenaje kubectl), espera hasta que todo haya sido evacuado de este nodo, lo elimina, crea un nuevo nodo en Amazon con la versión correcta de los componentes de Kubernetes, lo conecta al clúster, verifica que el nodo haya ingresado bien al clúster, y así con todos los nodos en un círculo hasta que la versión deseada de Kubernetes esté en todas partes.
Solución
En CI, uso kube-lint para verificar todos los manifiestos que se lanzarán en Kubernetes. Helm Template arroja todo lo que se va a lanzar, configuré un linter para descargar, que evalúa todo de acuerdo con las reglas dadas.
Por ejemplo, una de las reglas dice que para cualquier aplicación en el clúster de Kubernetes, el número de réplicas debe ser al menos 2.
Si no hay réplicas en absoluto (que por defecto es 1), hay 0 o 1 de ellas, kube-lint prohíbe la implementación en el clúster para evitar problemas futuros.
Digamos que la implementación por diseño está diseñada para que solo haya una réplica. Para este caso, hay un presupuesto de interrupción de pod, donde max_unavailable y min_available se configuran para una aplicación que se ejecuta en Kubernetes. Si desea tener siempre al menos 1 réplica, establezca min_available = 1.
Hubo 2 réplicas, el despliegue comenzó, 1 réplica murió, quedaba 1. En la máquina donde vive la réplica, el administrador inicia el nodo de drenaje kubectl. En teoría, Kubernetes debería comenzar a eliminar esta réplica en vivo y transportarla a otro nodo. Pero el presupuesto de interrupción de pod funciona. Kubernetes le dice al administrador: lo siento, la réplica vive aquí, si la eliminamos, violaremos el presupuesto de interrupción de pod. El nodo de drenaje inteligente se cuelga antes de que expire el tiempo de espera e intenta derivar el nodo. Si finaliza la implementación y ambas réplicas están disponibles, se mostrará la réplica en este nodo.
En MegaSlerme, mostraré un conjunto completo de reglas que me permiten tomar café en una cafetería mientras el clúster de Kubernetes se actualiza con un reinicio de todos los nodos.
Mis temas sobre Slurm :
- Presentación de Kubernetes, componentes clave
- Dispositivo de clúster, componentes principales, tolerancia a fallas, red k8s
- Abstracciones de Kubernetes avanzadas
- Registro y Monitoreo
Mis temas sobre MegaSlerme :
- Proceso de clúster de conmutación por error interno
- Autorización de clúster con un proveedor externo
- Aplicaciones seguras y altamente disponibles en el clúster
- Implementación de estrategias de implementación que no sean RollingUpdate
- Solución de problemas en Kubernetes