Meu nome é Sergey, sou do ITSumma e quero lhe contar como abordamos a reserva em Kubernetes. Recentemente, tenho realizado muitos trabalhos de consultoria na implementação de uma variedade de soluções de devops para várias equipes e, em particular, trabalho de perto em projetos usando K8s. Na conferência Uptime day 4, dedicada à redundância em arquiteturas complexas, fiz uma apresentação em cubo redundante e aqui está sua recontagem livre. Apenas avisarei com antecedência que ele não é um guia direto para a ação, mas uma generalização de pensamentos sobre esse tópico.
Em princípio, monitoramento e redundância são as duas principais ferramentas para aumentar a resiliência de qualquer projeto. Mas no cubador, tudo é equilibrado por si só, você diz, tudo é dimensionado por si só, e se algo acontecer, ele aumentará por si mesmo ... Ou seja, durante o primeiro estudo superficial do tópico, a Internet me respondeu a pergunta "Como funciona o backup do K8s?" ? " Muitas pessoas pensam que um cubo é uma coisa tão mágica que elimina todos os problemas de infraestrutura e faz com que o projeto nunca caia. Mas ... o mundo não é o que parece.
Como abordamos o processo de backup antes? Tínhamos plataformas idênticas para posicionamento - eram máquinas virtuais ou servidores de ferro, às quais aplicamos três práticas básicas:
- sincronização de código e estática
- sincronização de configuração
- replicação de banco de dados
E pronto: a qualquer momento, mudamos para o site de reservas, todo mundo está feliz, acordamos e discordamos.
E o que eles nos oferecem para aumentar a disponibilidade constante de nosso aplicativo kubernetes? A primeira coisa que a documentação não oficial diz é colocar muitas máquinas, criar muitos mestres - o número deles deve satisfazer as condições para obter um quorum dentro do cluster e para que o agendador etcd, api, MC seja gerado em cada um dos mestres ... E, parece, está tudo bem : quando vários nós ou mestres de trabalho falham, nosso cluster será reequilibrado e o aplicativo continuará funcionando. Parece mágica de novo! Porém, muitas vezes nosso cluster está localizado no mesmo datacenter e isso pode causar certas perguntas. E se uma escavadeira chegasse e desenterrasse um cabo, com um raio, houvesse uma inundação universal? Tudo está coberto, nosso cluster não existe mais. Como abordar a reserva levando em consideração esse lado do problema?
Antes de tudo, você deve ter outro cluster na reserva quente, ou seja, um cluster para o qual você possa alternar a qualquer momento. Ao mesmo tempo, do ponto de vista do cubador, as infraestruturas devem ser completamente idênticas. Ou seja, se houver algum plug-in não-padrão para trabalhar com o sistema de arquivos, soluções personalizadas para entrada, eles deverão ser completamente idênticos nos seus dois (ou três ou dez, há dinheiro e força de administrador suficientes). É necessário definir claramente dois conjuntos de aplicativos (deployment'ov, statefulset'ov, daemonset'ov, cronjob'ov etc.): quais deles podem trabalhar em uma reserva constantemente e quais são melhores para não iniciar antes da troca direta.
Então, nosso cluster de backup deve ser completamente idêntico ao nosso cluster de combate? Não. Anteriormente, na estrutura de trabalho com projetos monolíticos, com infraestrutura de ferro, mantivemos um ambiente quase completamente idêntico, mas na estrutura do cubador, acho que não deveria ser. Vamos ver o porquê.
Por exemplo, vamos começar com as entidades básicas do kubernetes - implantações - elas devem ser idênticas. Devem ser lançados aplicativos que podem interceptar o processamento do tráfego a qualquer momento e permitir que o nosso projeto continue ativo. Se estamos falando sobre arquivos de configuração, precisamos verificar aqui se eles devem ser idênticos ou não. Ou seja, se nós, pessoas inteligentes, não usarmos substâncias proibidas e não mantivermos a base nos K8s, nos configmaps, deveremos ter configurações de acesso à base de combate (cujo processo de backup é construído separadamente). Portanto, para garantir o acesso à instância do banco de dados de backup, precisamos ter um arquivo de configuração separado (configmap). Exatamente da mesma maneira que trabalhamos com segredos: senhas para acessar o banco de dados, chaves api; a qualquer momento, um segredo de combate ou uma reserva pode ser trabalhada conosco. No total, já temos duas entidades kubernetes cujas versões de backup não devem ser idênticas às de combate. A próxima entidade que vale a pena se concentrar é o cronjob. Cronjobs em reserva não devem ser de forma alguma idênticos ao conjunto de clusters de produção do cronjob! Se aumentarmos o cluster de backup e aumentarmos completamente com todo o cronjob ativado, então, por exemplo, as pessoas receberão duas cartas suas ao mesmo tempo, em vez de uma. Ou algum tipo de sincronização de dados com fontes externas ocorrerá duas vezes, respectivamente, começamos a magoar, chorar, gritar e xingar.
Mas como as pessoas da Internet nos oferecem a organização de um cluster de backup? A segunda resposta mais popular depois de "por quê?" - uso da Federação Kubernetes.
O que é isso Este é, digamos, um grande meta cluster. Se imaginarmos a arquitetura do cubo - onde temos um mestre, vários nós -, do ponto de vista da federação, também temos um mestre e vários nós, apenas cada nó é um cluster separado. Ou seja, trabalhamos com as mesmas entidades, com as mesmas primitivas que com um único cubador, mas torcemos e giramos não nossas máquinas físicas, mas aglomerados inteiros. No âmbito da federação, estamos em completa sincronização de recursos federais, de pais para descendentes. Por exemplo, se lançarmos alguma implantação por meio da federação, ela será implantada em cada um de nossos clusters subsidiários. Se pegarmos qualquer mapa de configuração, o segredo é lançá-lo na federação - ele se espalhará por todos os nossos clusters filhos; ao mesmo tempo, a federação nos permite personalizar nossos recursos para crianças. Ou seja, pegamos um mapa de configuração, implantamos na federação e, em seguida, se precisarmos corrigir algo em clusters específicos, vamos editar em um cluster separado, e essa alteração não será sincronizada em nenhum lugar.
A Federação Kubernetes não é há muito tempo uma ferramenta existente e não suporta todo o conjunto de recursos que o próprio K8s fornece: no momento da publicação de uma das primeiras versões da documentação, estava falando sobre o suporte apenas a mapas de configuração, implantação para conjunto de réplicas e entrada. Segredos não eram suportados, o trabalho com volume também não era suportado. Conjunto muito limitado. Especialmente se gostarmos de nos divertir, por exemplo, através da definição de recursos personalizados para transferir nossos próprios recursos para os kubernetes, não os enviaremos para a federação. Isto é, por assim dizer ... uma decisão muito semelhante à verdade, mas nos faz periodicamente dar um tiro no pé. Por outro lado, a federação permite que você gerencie com flexibilidade nosso conjunto de réplicas. Por exemplo, queremos que 10 réplicas de nosso aplicativo sejam iniciadas. Por padrão, a federação dividirá esse número proporcionalmente entre o número de clusters. E tudo isso também pode ser configurado! Ou seja, você pode especificar que precisa manter 6 réplicas de nosso aplicativo no cluster de combate e apenas 4 réplicas de nosso aplicativo no cluster de backup, para economizar recursos ou para seu próprio entretenimento. O que também é bastante conveniente. Mas com a federação, precisamos usar algumas soluções novas, finalizar algo em movimento e nos forçar a pensar um pouco mais ...
É possível abordar o processo de reservar um cubador de alguma forma mais simples? Quais ferramentas nós temos?
Primeiramente, sempre temos algum tipo de sistema ci / cd, ou seja, não andamos manualmente, não escrevemos criar / aplicar nos servidores. O sistema gera yaml'ics para nossos contêineres.
Em segundo lugar, existem vários clusters, temos um ou vários (se formos inteligentes) registro, que também utilizamos e reservamos. E existe um maravilhoso utilitário kubectl que pode trabalhar com vários clusters simultaneamente.
Então: na minha opinião, a solução mais simples e correta para criar um cluster de backup é uma implantação paralela primitiva. Existe algum tipo de pipeline no sistema ci / cd; primeiro, construímos nossos contêineres, testamos e implementamos aplicativos através do kubectl para vários clusters independentes. Podemos construir cálculos simultâneos em vários clusters. Dessa forma, também decidimos fornecer configurações nesta fase. É possível pré-definir o conjunto de configurações para nosso cluster de combate, o conjunto de configurações para o cluster de backup e, no nível ci / cd do sistema, rolar o pró-ambiente para o pró-cluster, o ambiente de backup para o cluster de backup. Comparado com a federação, você não precisa definir um recurso federal para cada cluster filho e redefinir algo. Fizemos isso com antecedência. Que bons companheiros somos.
Mas ... existe ... eu escrevi, existe a "raiz de todo mal", mas na verdade existem duas delas. O primeiro é o sistema de arquivos. Existe algum tipo de PV, ou usamos armazenamento externo. Se armazenarmos arquivos dentro do cluster, precisaremos seguir as práticas antigas remanescentes da época das infraestruturas de ferro: por exemplo, sincronize com o lsync. Bem, ou qualquer outra muleta que você pessoalmente prefira. Nós rolamos tudo para outros carros e ao vivo.
Em segundo lugar, e, de fato, um obstáculo ainda mais importante é o banco de dados. Se somos pessoas inteligentes e não mantemos o banco de dados no cubo, o processo de backup de dados de acordo com o mesmo esquema antigo é a replicação mestre-escravo e, em seguida, alternamos, acompanharemos a réplica e viveremos bem. Porém, se mantivermos nosso banco de dados dentro do cluster, em princípio, existem muitas soluções prontas para organizar a mesma réplica mestre-escravo, muitas soluções para aumentar o banco de dados dentro do cubo.
Um bilhão de relatórios já foi lido sobre backups de bancos de dados, um bilhão de artigos foram escritos, nada de novo é necessário aqui, na verdade. Em geral, siga seu sonho, viva como quiser, invente algumas muletas complicadas também, mas não deixe de pensar em como você reservará tudo isso.
E agora, sobre como, em princípio, teremos o processo de mudar para o site de backup em caso de incêndio. Primeiro, implantamos aplicativos sem estado em paralelo. Eles não afetam a lógica de negócios de nossos aplicativos, nosso projeto, podemos manter constantemente dois conjuntos de aplicativos em execução e podem começar a receber tráfego. É muito importante no processo de mudança para o site de backup para ver definitivamente se as configurações precisam ser redefinidas? Por exemplo, temos um cluster de vendas kubernetes, existe um cluster de backup kubernetes, há um banco de dados mestre externo e um banco de dados mestre de backup. Temos quatro opções para como esses aplicativos no produto podem começar a interagir entre si. Nossa base pode mudar, e acontece que precisamos mudar o tráfego para a nova base no cluster de produtos, ou podemos obter o cluster e nos mudamos para a reserva, mas continuamos trabalhando com a base profissional, bem, a terceira opção, quando a obtivemos , ele está ferrado e alternamos os dois aplicativos, redefinimos nossa configuração para que novos aplicativos já funcionem com o novo banco de dados.
Bem, na verdade, que conclusões podem ser tiradas disso tudo?
A primeira conclusão: viver bem com uma reserva. Mas caro. Mas, idealmente, vivendo com mais de uma reserva. Idealmente, você geralmente precisa viver com várias reservas. Em primeiro lugar, a reserva deve estar pelo menos não em um CD e, em segundo lugar, pelo menos, em outro host. Muitas vezes acontecia - e na minha prática era. Infelizmente, não posso citar os projetos, exatamente quando houve um incêndio no data center ... sou assim: estamos mudando para a reserva! E os servidores de backup no mesmo rack estavam ...
Ou imagine que a Amazon tenha sido banida na Rússia (e isso foi). E tudo: a sensação de que em outra amazônia reside nossa reserva? Também não está disponível. Por isso, repito: mantemos a reserva, pelo menos, em outro CD e, de preferência, com outro host.
A segunda conclusão: se seu aplicativo se comunicar com algumas fontes externas (pode ser um banco de dados ou alguma API externa), defina-o como um serviço com um ponto de extremidade externo, para que você não precise corrigi-lo no momento da alternância 15 de seus aplicativos que estão batendo na mesma base. Defina o banco de dados como um serviço separado, bata nele como se estivesse dentro do cluster: se você tiver um banco de dados, mude o ip em um local e continue a viver feliz.
E finalmente: eu amo o “cubo”, bem como experimentos com ele. Também gosto de compartilhar os resultados desses experimentos e, em geral, minha experiência pessoal. Portanto, gravei uma série de seminários on-line sobre K8s, bem no
nosso canal do youtube para obter detalhes.