Chámome Sergey, son de ITSumma e quero contarche como abordamos a redundancia en Kubernetes. Recentemente, estiven facendo moito traballo de consultoría na implementación de varias solucións devops para varios equipos e, en particular, estiven traballando en estreita colaboración en proxectos usando K8s. Na conferencia do día 4 de Uptime, que se dedicou á redundancia en arquitecturas complexas, fixen unha presentación sobre a redundancia do "cubo" e aquí tes un relato gratuíto do mesmo. Só avisarei de antemán de que non é unha guía directa de acción, senón unha xeneralización de pensamentos sobre este tema.
En principio, o seguimento e a redundancia son as dúas principais ferramentas para aumentar a tolerancia a fallos de calquera proxecto. Pero no cuber, todo se equilibra, dis, todo se escala, e se pasa algo, subirase por si mesmo... É dicir, durante a primeira investigación superficial do tema, cando se lle pregunta quen se achega á reserva de K8s como , Internet contestoume "por que?" Moita xente pensa que cuber é unha cousa tan máxica que elimina todos os problemas de infraestrutura e fai que o proxecto nunca fracase. Pero... o mundo non é o que parece.
Como abordabamos o proceso de copia de seguridade antes? Tiñamos plataformas de aloxamento idénticas, xa fosen virtuais ou de hardware. servidores, ás que aplicamos tres prácticas básicas:
- sincronización de código e estática
- sincronización de configuración
- replicación de bases de datos
E listo: en calquera momento cambiamos ao sitio de reserva, todos contentos, erguémonos e marchamos.
Que nos ofrecen para aumentar a dispoñibilidade constante da nosa aplicación kubernetes? O primeiro que di a documentación non oficial é instalar moitas máquinas, facer moitos mestres: o seu número debe satisfacer as condicións para acadar un quórum dentro do clúster e para que etcd, api, MC, planificador estean instalados en cada un dos os mestres... E, ao parecer, todo está ben : se fallan varios nodos de traballo ou mestres, o noso clúster reequilibrarase e a aplicación seguirá funcionando. Parece maxia de novo! Pero moitas veces o noso clúster está situado dentro do mesmo centro de datos e isto pode suscitar certas preguntas. E se chegase unha escavadora e desenterrase o cable, caese un raio e se producise unha inundación global? Todo está cuberto, o noso cluster xa non existe. Como abordar as reservas tendo en conta este lado do problema?
En primeiro lugar, debes ter outro clúster en modo de espera, é dicir, un clúster ao que podes cambiar en calquera momento. Ademais, dende o punto de vista do cuber, as infraestruturas deben ser completamente idénticas. É dicir, se hai complementos non estándar para traballar co sistema de ficheiros, solucións personalizadas para a entrada, deberían ser completamente idénticos nos dous (ou tres, ou dez, dependendo de canto diñeiro e a forza dos administradores sexan suficientes). clusters. É necesario definir claramente dous conxuntos de aplicacións (desplegamentos, statefulsets, daemonsets, cronjobs, etc.): cales delas poden executarse en modo de espera constantemente e cales son mellor que non se inicien ata o cambio real.
Entón, o noso clúster de copia de seguridade debería ser completamente idéntico ao noso clúster de combate? Non. Se antes, cando traballamos con proxectos monolíticos, con infraestrutura de hardware, mantivemos un ambiente case completamente idéntico, entón no marco de cuber, creo que non debería ser o caso. Vexamos por que.
Por exemplo, comecemos coas entidades básicas de Kubernetes - os despregamentos - deben ser idénticas. Deben lanzarse aplicacións que poidan interceptar o procesamento do tráfico en calquera momento e que permitan que o noso proxecto siga funcionando. Se estamos a falar de ficheiros de configuración, hai que ver se deben ser idénticos ou non. É dicir, se nós, as persoas intelixentes, non usamos ningunha substancia prohibida e non mantemos unha base en K8, entón nos nosos mapas de configuración deberíamos ter unha configuración para o acceso á base de combate (o proceso de reserva está construído por separado). En consecuencia, para proporcionar acceso á instancia de base de datos de copia de seguridade, debemos ter un ficheiro de configuración separado (configmap). Traballamos exactamente do mesmo xeito con segredos: contrasinais para acceder á base de datos, chaves API; En calquera momento, podemos ter un segredo de combate ou un de reserva en execución. En total, xa temos dúas entidades kubernetes, cuxas versións de copia de seguridade non deberían ser idénticas ás de produción. A seguinte entidade na que vale a pena centrarse é cronjob. Os cronjobs da reserva non deben ser en ningún caso idénticos ao conxunto de cronjobs do clúster de produción. Se creamos un clúster de copia de seguridade e o elevamos completamente con todos os cronjobs activados, entón, por exemplo, a xente recibirá dúas cartas de ti ao mesmo tempo en lugar dunha. Ou algún tipo de sincronización de datos con fontes externas terá lugar dúas veces, polo que comezamos a enfermarnos, a chorar, a berrar e a xurar.
Como suxiren a xente de Internet que organicemos un clúster redundante? A segunda resposta máis popular despois de "por que?" - uso de Kubernetes Federation.
Que é? Este é, digamos, un gran metacluster. Se imaxinamos a arquitectura de Kuber -onde temos un mestre, varios nodos- entón desde o punto de vista da federación, tamén temos un mestre e varios nodos, só cada nodo é un clúster separado. É dicir, traballamos coas mesmas entidades, coas mesmas primitivas, como cun único cuber, só que torcemos e xiramos non coas nosas máquinas físicas, senón con clusters enteiros. No marco da federación, contamos cunha completa sincronización dos recursos federados de pais a descendentes. Por exemplo, se lanzamos algún tipo de despregamento a través da federación, implantarase en cada un dos nosos clústeres fillos. Se collemos algún mapa de configuración, un segredo, e o lanzamos á federación, estenderase a todos os nosos clústeres fillos; Ao mesmo tempo, a federación permítenos personalizar os nosos recursos para os máis pequenos. É dicir, collemos un mapa de configuración, despregámolo a través da federación e, despois, se necesitamos corrixir algo en clústeres específicos, imos editalo nun clúster separado e este cambio non se sincronizará en ningún lado.
Kubernetes Federation é unha ferramenta que existe recentemente, e non admite todo o conxunto de recursos que o propio K8s proporciona: no momento da publicación dunha das primeiras versións da documentación, falaba de admitir só mapas de configuración, despregamento para unha réplica. conxunto e entrada. Non se admitían os segredos, tampouco se admitía traballar con volume. Conxunto demasiado limitado. Especialmente se nos gusta divertirnos, por exemplo, transferir os nosos propios recursos a kubernetes mediante unha definición de recursos personalizada, non os empurraremos á federación. É dicir, é como... unha solución moi parecida á verdade, pero que nos obriga a dispararnos periodicamente no pé. Por outra banda, a federación permítenos xestionar de forma flexible o noso conxunto de réplicas. Por exemplo, queremos que se executen 10 réplicas da nosa aplicación, por defecto a federación dividirá este número proporcionalmente entre o número de clústeres. E todo isto tamén se pode configurar! É dicir, podes especificar que tes que gardar 6 réplicas da nosa aplicación no clúster de combate, e só 4 réplicas da nosa aplicación no clúster de copia de seguridade, para aforrar recursos ou para o teu propio entretemento. O que tamén é bastante cómodo. Pero coa federación, temos que utilizar algunhas solucións novas, desenvolver algo sobre a marcha, obrigarnos a pensar un pouco máis...
Existe unha forma máis sinxela de abordar o proceso de reserva de cuber? Que ferramentas temos?
En primeiro lugar, sempre temos algún tipo de sistema ci/cd, é dicir, non imos nin escribimos manualmente nos servidores de creación/aplicación. O sistema xera yamls para os nosos contedores.
En segundo lugar, hai varios clusters, temos un ou varios (se somos intelixentes) rexistro, que tamén levamos e reservamos. E hai unha utilidade marabillosa chamada kubectl, que pode funcionar con varios clústeres ao mesmo tempo.
Entón: na miña opinión, a solución máis sinxela e correcta para construír un clúster de copia de seguridade é unha implantación paralela primitiva. Hai algún tipo de canalización no sistema ci/cd; En primeiro lugar, construímos os nosos contedores, probamos e lanzamos aplicacións a través de kubectl a varios clústeres independentes. Podemos construír cálculos simultáneos para varios clusters. En consecuencia, tamén decidimos a entrega de configuracións nesta fase. Podemos definir de antemán un conxunto de configuracións para o noso clúster de combate, un conxunto de configuracións para un clúster de copia de seguridade e, a nivel de sistema ci/cd, podemos implementar o ambiente alimentario nun clúster de alimentos e o entorno de copia de seguridade nunha copia de seguridade. clúster. En comparación coa federación, despois de definir un recurso federado, non tes que ir a cada clúster secundario e redefinir algo. Fixémolo con antelación. Que grandes compañeiros somos.
Pero... hai... escribín, hai unha "raíz de todo mal", pero en realidade hai dous. En primeiro lugar, o sistema de ficheiros. Hai algún tipo de fotovoltaica ou usamos almacenamento externo. Se almacenamos ficheiros dentro dun clúster, entón necesitamos seguir prácticas antigas que sobraron dos tempos das infraestruturas de hardware: por exemplo, sincronizar con lsync. Ben, ou calquera outra muleta que prefires persoalmente. Distribuímos todo noutros coches e vivimos.
O segundo punto, e en realidade aínda máis importante, é a base de datos. Se somos persoas intelixentes e non mantemos a base de datos nun cuber, entón o proceso de copia de seguridade de datos segue o mesmo esquema antigo: replicación mestre-escravo, despois cambiando, poñerémonos ao día coa réplica e viviremos ben. Pero se mantemos a nosa base de datos dentro do clúster, entón, en principio, hai moitas solucións preparadas para organizar a mesma réplica mestre-escravo e moitas solucións para crear unha base de datos dentro do cuber.
Xa se leron mil millóns de informes sobre a copia de seguridade da base de datos, escribíronse mil millóns de artigos e, en rigor, non se necesita nada novo aquí. En xeral, segue o teu soño, vive como queiras, inventa unhas muletas complexas para ti, pero asegúrate de pensar como reservarás todo isto.
E agora imos falar de como, en principio, teremos o proceso de cambiar a un sitio de copia de seguridade en caso de incendio. En primeiro lugar, implementamos aplicacións sen estado en paralelo. Non afectan á lóxica empresarial das nosas aplicacións, do noso proxecto, podemos manter constantemente dous conxuntos de aplicacións en execución e poden comezar a recibir tráfico. É moi importante mirar o proceso de cambio a un sitio de copia de seguridade: cómpre redefinir as configuracións? Por exemplo, temos un clúster de Kubernetes de produción, un clúster de Kubernetes de reserva, unha base de datos mestra externa e unha base de datos mestra de copia de seguridade. Temos catro opcións sobre como estas aplicacións en produción poden comezar a interactuar entre si. A nosa base de datos pode cambiar, e resulta que necesitamos cambiar o tráfico no grupo de alimentos a unha nova base, ou o noso grupo pode fallar, e pasamos á reserva, pero seguimos traballando coa base de datos de alimentos, ben, o terceiro opción, cando nos pasou isto , pasou, e cambiamos ambas aplicacións, redefinimos a nosa configuración para que as novas aplicacións xa funcionen coa nova base de datos.
Ben, en realidade, que conclusións se poden sacar de todo isto?
Conclusión primeira: a vida é boa cunha reserva. Pero é caro. Pero o ideal é vivir con máis dunha reserva. O ideal é que, en xeral, teñas que vivir con varias reservas. En primeiro lugar, a reserva debe estar polo menos non nun DC e, en segundo lugar, polo menos noutro hoster. Acontecía moitas veces, e na miña práctica isto ocorreu. Por desgraza, non podo nomear os proxectos, xusto cando houbo un incendio no centro de datos... Eu estou como: imos cambiar a reserva! E os servidores de copia de seguridade estaban no mesmo rack...
Ou imaxina que Amazon foi prohibido en Rusia (e isto pasou). E iso é todo: para que serve que a nosa reserva estea noutra Amazonia? Tampouco está dispoñible. Así que repito: mantemos unha reserva, como mínimo, noutro DC, e preferiblemente con outro hoster.
Segunda conclusión: se a túa aplicación no cuber se comunica con algunhas fontes externas (esta pode ser unha base de datos ou algunha API externa), asegúrate de definila como un servizo cun Endpoint externo, para non volver implantarse no momento do cambio. 15 das túas aplicacións que están petando na mesma base. Define a base de datos como un servizo separado, tómaa coma se estivese dentro do teu clúster: se tes unha base de datos, cambias a IP nun só lugar e continúas vivindo feliz.
E para rematar: encántame o "cubo", así como os experimentos con el. Tamén me gusta compartir os resultados destes experimentos e a miña experiencia persoal en xeral. É por iso que gravei unha serie de seminarios web sobre os K8, benvido para os detalles.
Fonte: www.habr.com
