Mi nombre es Sergey, soy de ITSumma y quiero contarte cómo abordamos la reserva en Kubernetes. Recientemente, he estado haciendo mucho trabajo de asesoramiento sobre la implementación de una variedad de soluciones de desarrollo para varios equipos, y, en particular, trabajo de cerca en proyectos que utilizan K8. En la conferencia Uptime day 4, que se dedicó a la redundancia en arquitecturas complejas, hice una presentación sobre un cubo redundante, y aquí está su recuento gratuito. Solo advertiré de antemano que él no es una guía directa de acción, sino más bien una generalización de pensamientos sobre este tema.
En principio, el monitoreo y la redundancia son las dos herramientas principales para aumentar la capacidad de recuperación de cualquier proyecto. Pero en el cubo, todo se equilibra por sí solo, usted dice, todo se escala por sí mismo, y si algo sucede, se elevará por sí mismo ... Es decir, durante el primer estudio superficial del tema, Internet me respondió la pregunta "¿Cómo funciona el respaldo de K8?" ? " Mucha gente piensa que un cubo es una cosa tan mágica que elimina todos los problemas de infraestructura y hace que el proyecto nunca se caiga. Pero ... el mundo no es lo que parece.
¿Cómo abordamos el proceso de copia de seguridad antes? Teníamos plataformas idénticas para la colocación: o eran máquinas virtuales o servidores de hierro, a los que aplicamos tres prácticas básicas:
- sincronización de código y estática
- sincronización de configuración
- replicación de bases de datos
Y listo: en cualquier momento cambiamos al sitio de reserva, todos estamos felices, nos levantamos, no estamos de acuerdo.
¿Y qué nos ofrecen para aumentar la disponibilidad constante de nuestra aplicación kubernetes? Lo primero que dice la documentación no oficial es poner muchas máquinas, hacer muchos maestros: su número debe satisfacer las condiciones para lograr un quórum dentro del clúster, y para que etcd, api, MC, planificador se generen en cada uno de los maestros ... Y, al parecer, todo está bien : cuando varios nodos de trabajo o maestros fallan, nuestro clúster se reequilibrará y la aplicación continuará funcionando. ¡Parece magia otra vez! Pero a menudo nuestro clúster se encuentra dentro del mismo centro de datos y esto puede causar ciertas preguntas. ¿Qué pasa si una excavadora llegó y desenterró un cable, cayó un rayo y hubo una inundación universal? Todo está cubierto, nuestro grupo ya no existe. ¿Cómo abordar la reserva teniendo en cuenta este lado del problema?
En primer lugar, debe tener otro clúster en la reserva activa, es decir, un clúster al que pueda cambiar en cualquier momento. Además, desde el punto de vista del cubo, las infraestructuras deben ser completamente idénticas. Es decir, si hay complementos no estándar para trabajar con el sistema de archivos, soluciones personalizadas para el ingreso, deben ser completamente idénticos en sus dos (o tres, o diez, hay suficiente dinero y la fuerza de los administradores). Es necesario definir claramente dos conjuntos de aplicaciones (despliegue'ov, statefulset'ov, daemonset'ov, cronjob'ov, etc.): cuáles de ellas pueden trabajar constantemente en una reserva y cuáles son mejores para no comenzar antes del cambio directo.
Entonces, ¿nuestro grupo de respaldo debe ser completamente idéntico a nuestro grupo de combate? No Anteriormente, en el marco de trabajar con proyectos monolíticos, con infraestructura de hierro, manteníamos un entorno casi completamente idéntico, pero en el marco del cubo, creo que esto no debería ser así. Veamos por qué.
Por ejemplo, comencemos con las entidades básicas de kubernetes, implementaciones, que deben ser idénticas. Deben lanzarse aplicaciones que puedan interceptar el procesamiento del tráfico en cualquier momento y permitir que nuestro proyecto continúe vivo. Si estamos hablando de archivos de configuración, entonces debemos mirar aquí si deberían ser idénticos o no. Es decir, si nosotros, personas inteligentes, no usamos ninguna sustancia prohibida y no mantenemos la base en K8, entonces debemos tener configuraciones de acceso en los mapas de configuración para la base de combate (cuyo proceso de respaldo se construye por separado). En consecuencia, para garantizar el acceso a la instancia de la base de datos de respaldo, debemos tener un archivo de configuración separado (mapa de configuración). Exactamente de la misma manera que trabajamos con secretos: contraseñas para acceder a la base de datos, claves de API; en cualquier momento, ya sea un secreto de combate o uno de reserva, puede trabajar con nosotros. En total, ya tenemos dos entidades kubernetes cuyas versiones de respaldo no deberían ser idénticas a las de combate. La siguiente entidad en la que vale la pena detenerse es cronjob. ¡Cronjobs en reserva no debe ser idéntico al conjunto de clusters de producción de cronjob! Si levantamos el clúster de respaldo y lo levantamos completamente con todo el trabajo cron habilitado, entonces, por ejemplo, las personas recibirán dos cartas suyas al mismo tiempo en lugar de una. O algún tipo de sincronización de datos con fuentes externas tendrá lugar dos veces, respectivamente, comenzamos a lastimar, llorar, gritar y maldecir.
Pero, ¿cómo nos ofrecen las personas de Internet para organizar un clúster de respaldo? La segunda respuesta más popular después de "¿por qué?" - uso de la Federación de Kubernetes.
Que es esto Esto es, digamos, un gran meta cluster. Si imaginamos la arquitectura del cubo, donde tenemos un maestro, varios nodos, desde el punto de vista de la federación, también tenemos un maestro y varios nodos, solo cada nodo es un clúster separado. Es decir, trabajamos con las mismas entidades, con las mismas primitivas que con un único cubo, pero giramos y giramos no nuestras máquinas físicas, sino grupos completos. En el marco de la federación, estamos en completa sincronización de recursos federales de padres a descendientes. Por ejemplo, si lanzamos alguna implementación a través de la federación, se implementará en cada uno de nuestros grupos subsidiarios. Si tomamos un mapa de configuración, el secreto es llevarlo a la federación; se extenderá a todos nuestros grupos secundarios; Al mismo tiempo, la federación nos permite personalizar nuestros recursos para los niños. Es decir, tomamos un mapa de configuración, lo implementamos a través de la federación y luego, si necesitamos arreglar algo en grupos específicos, vamos a editar en un grupo separado, y este cambio no se sincronizará en ningún lado.
La Federación Kubernetes no es hace mucho tiempo una herramienta existente, y no es compatible con el conjunto completo de recursos que K8s mismo proporciona: en el momento de la publicación de una de las primeras versiones de la documentación, se refería a admitir solo mapas de configuración, implementación para conjunto de réplicas, ingreso. Los secretos no eran compatibles, el trabajo con volumen tampoco era compatible. Conjunto demasiado limitado. Especialmente si nos gusta divertirnos, por ejemplo, a través de la definición personalizada de recursos para transferir nuestros propios recursos a los kubernetes, no los empujaremos a la federación. Es decir, como si fuera ... una decisión muy similar a la verdad, pero nos hace periódicamente pegarnos un tiro en el pie. Por otro lado, la federación le permite administrar de manera flexible nuestro conjunto de réplicas. Por ejemplo, queremos que se inicien 10 réplicas de nuestra aplicación; de manera predeterminada, la federación dividirá este número proporcionalmente entre el número de clústeres. ¡Y todo esto también se puede configurar! Es decir, puede especificar que necesita mantener 6 réplicas de nuestra aplicación en el clúster de combate, y solo 4 réplicas de nuestra aplicación en el clúster de respaldo, para ahorrar recursos o para su propio entretenimiento. Lo cual también es bastante conveniente. Pero con la federación tenemos que usar algunas soluciones nuevas, terminar algo sobre la marcha y obligarnos a pensar un poco más ...
¿Es posible abordar el proceso de reservar un cubo de alguna manera más simple? ¿Qué herramientas tenemos en absoluto?
En primer lugar, siempre tenemos algún tipo de sistema ci / cd, es decir, no damos vueltas manualmente, no escribimos crear / aplicar en los servidores. El sistema genera yaml'ics para nuestros contenedores.
En segundo lugar, hay varios grupos, tenemos uno o varios registros (si somos inteligentes), que también tomamos y reservamos. Y hay una maravillosa utilidad kubectl que puede funcionar con múltiples clústeres simultáneamente.
Entonces: en mi opinión, la solución más simple y correcta para construir un clúster de respaldo es una implementación paralela primitiva. Hay algún tipo de tubería en el sistema ci / cd; Primero construimos nuestros contenedores, probamos y desarrollamos aplicaciones a través de kubectl a varios clústeres independientes. Podemos construir cálculos simultáneos en varios grupos. En consecuencia, también decidimos entregar configuraciones en esta etapa. Puedes predefinir el conjunto de configuraciones para nuestro clúster de combate, el conjunto de configuraciones para el clúster de respaldo y en el nivel ci / cd del sistema, pasar el pro-ambiente al pro-clúster, el entorno de respaldo al clúster de respaldo. En comparación con la federación, no es necesario ir después de definir un recurso federal para cada grupo de niños y redefinir algo. Hicimos esto de antemano. Qué buenos compañeros somos.
Pero ... hay ... escribí, existe la "raíz de todo mal", pero en realidad hay dos de ellos. El primero es el sistema de archivos. Hay algún tipo de PV, o usamos almacenamiento externo. Si almacenamos archivos dentro del clúster, entonces debemos seguir las viejas prácticas que quedaron desde el momento de las infraestructuras de hierro: por ejemplo, sincronizar con lsync. Bueno, o cualquier otra muleta que prefieras personalmente. Rodamos todo a otros autos y vivimos.
En segundo lugar, y, de hecho, un obstáculo aún más importante es la base de datos. Si somos personas inteligentes y no mantenemos la base de datos en el cubo, entonces el proceso de hacer una copia de seguridad de los datos de acuerdo con el mismo esquema anterior es la replicación maestro-esclavo, luego, al cambiar, nos pondremos al día con la réplica y viviremos bien. Pero si mantenemos nuestra base de datos dentro del clúster, entonces, en principio, hay muchas soluciones listas para organizar la misma réplica maestro-esclavo, muchas soluciones para elevar la base de datos dentro del cubo.
Ya se han leído mil millones de informes sobre copias de seguridad de bases de datos, se han escrito mil millones de artículos, de hecho, no se necesita nada nuevo aquí. En general, sigue tu sueño, vive como quieras, inventa algunas muletas complicadas también, pero asegúrate de pensar en cómo reservar todo esto.
Y ahora sobre cómo, en principio, tendremos el proceso de cambiar al sitio de respaldo en caso de incendio. Primero, implementamos aplicaciones sin estado en paralelo. No afectan la lógica de negocios de nuestras aplicaciones, nuestro proyecto, podemos mantener constantemente dos conjuntos de aplicaciones en ejecución y pueden comenzar a recibir tráfico. Es muy importante en el proceso de cambiar al sitio de respaldo para ver definitivamente si las configuraciones deben redefinirse Por ejemplo, tenemos un clúster de kubernetes, hay un clúster de kubernetes de respaldo, hay una base de datos maestra externa y hay una base de datos maestra de respaldo. Tenemos cuatro opciones sobre cómo estas aplicaciones en el producto pueden comenzar a interactuar entre sí. Nuestra base puede cambiar, y resulta que necesitamos cambiar el tráfico a la nueva base en el clúster prod, o podemos obtener el clúster y movernos a la reserva, pero seguimos trabajando con la base pro, bueno, la tercera opción, cuando la tenemos , luego se arruina, y cambiamos ambas aplicaciones, redefinimos nuestra configuración para que las nuevas aplicaciones ya funcionen con la nueva base de datos.
Bueno, en realidad, ¿qué conclusiones se pueden sacar de todo esto?
La primera conclusión: vivir bien con una reserva. Pero caro Pero idealmente, viviendo con más de una reserva. Idealmente, generalmente necesita vivir con varias reservas. En primer lugar, la reserva debe estar al menos no en un DC, y en segundo lugar, al menos, en otro hoster. A menudo sucedía, y en mi práctica lo fue. Desafortunadamente, no puedo nombrar los proyectos, justo cuando hubo un incendio en el centro de datos ... Estoy así: ¡nos estamos cambiando a la reserva! Y los servidores de respaldo en el mismo bastidor estaban ...
O imagine que Amazon fue prohibido en Rusia (y eso fue). Y todo: ¿la sensación del hecho de que en otro Amazonas se encuentra nuestra reserva? Tampoco está disponible. Entonces repito: mantenemos la reserva, al menos, en otro DC, y preferiblemente con otro host.
La segunda conclusión: si su aplicación se comunica con algunas fuentes externas (puede ser una base de datos o una API externa), asegúrese de definirla como un servicio con un Endpoint externo para que no tenga que volver a repararla en el momento del cambio 15 de sus aplicaciones que tocan la misma base. Defina la base de datos como un servicio separado, utilícela como si estuviera dentro de su clúster: si tiene una base de datos, cambie la dirección IP en un lugar y continúe viviendo felizmente.
Y finalmente: me encanta el "cubo", así como los experimentos con él. También me gusta compartir los resultados de estos experimentos y, en general, mi experiencia personal. Por lo tanto, grabé una serie de seminarios web sobre K8, bien en
nuestro canal de YouTube para más detalles.