Toda a comunidade de desenvolvedores da Web está empolgada com o Kubernetes (K8s). Não é de se admirar que esse seja o tópico mais quente nas conferências e nos eventos para desenvolvedores dos quais participei no ano passado.
Ele não é apenas uma ferramenta para gerenciar contêineres; na verdade, o K8s permite adicionar facilmente balanceamento de carga e evita a necessidade de um camada de descoberta de serviços (você não precisa mais de eureca por exemplo). Os K8s também automatizam as implementações e atualizações de aplicativos e, o mais importante, permitem que você conecte/grave um controlador personalizado para a sua infraestrutura.
Fantástico, não é? Mas gerenciar contêineres sem estado não é tão complicado, afinal de contas, eles são essencialmente efêmeros e você pode eliminar e ativar instâncias como quiser sem nenhum efeito colateral considerável.
Mas isso é apenas metade da história: em geral, os aplicativos não podem ser totalmente sem estado e, na maioria dos casos, simplesmente transferimos o estado para as camadas inferiores. Então, como lidamos com aplicativos com estado no K8s? Felizmente, desde a versão 1.5, existe algo chamado StatefulSets.
Contêineres com estado
O Kubernetes StatefulSets fornece um conjunto de recursos para lidar com contêineres com estado, como: volumes, IDs de rede estáveis, índices ordinais de 0 a N etc. Os volumes são um dos principais recursos que nos permitem executar aplicativos com estado no Kubernetes. Vamos ver os dois principais tipos suportados atualmente:
Armazenamentos efêmeros vvolumes
O comportamento dos armazenamentos efêmeros é diferente do que você está acostumado no Docker. No Kubernetes, o volume sobrevive a todos os contêineres executados no pod e os dados são preservados durante as reinicializações do contêiner. Mas se o pod for eliminado, o volume será removido automaticamente.
Volumes de armazenamento persistentes
Em um armazenamento persistente, como o nome sugere, o tempo de vida dos dados é independente do tempo de vida do pod. Portanto, mesmo quando o pod morre ou é movido para outro nó, esses dados ainda persistem até que sejam explicitamente excluídos pelo usuário. Nesses tipos de volumes, os dados são armazenados normalmente remotamente.
Estamos ansiosos pelo suporte do Kubernetes para Armazenamentos persistentes locais pois ele será definitivamente o mais adequado para a execução de bancos de dados, mas, enquanto isso, usamos armazenamentos efêmeros por padrão. A esta altura, você deve estar se perguntando por que estamos usando armazenamentos efêmeros em vez de persistentes. Não é de surpreender que existam muitos motivos para isso:
- Os armazenamentos efêmeros são mais rápidos e mais baratos do que os persistentes; o uso de armazenamentos persistentes exigiria mais infraestrutura/rede, pois é necessário enviar os dados para frente e para trás
- Lançamento do K8s 1.9 Suporte a blocos brutosque permite acessar discos físicos em sua instância de VM para usá-los em seu aplicativo.
- A manutenção de sistemas de armazenamento em rede não é trivial
- Você sempre pode tentar reiniciar o contêiner primeiro, em vez de eliminar o Pod inteiro:
1kubectl executar POD_NAME -c CONTAINER_NAME reinicialização - Você pode configurar o Couchbase para replicar automaticamente seus dados, portanto, mesmo que N Pods morra, nenhum dado será perdido.
- Parte do trabalho do K8 é executar os pods em racks diferentes para evitar falhas em massa.
No entanto, há alguns cenários em que o uso do Remote Persistent Storages valeria o custo extra da latência, como em bancos de dados enormes, por exemplo, quando o processo de rebalanceamento leva vários minutos para ser concluído. É por isso que também adicionaremos suporte a armazenamentos persistentes remotos.
Uma das desvantagens dos Statefulsets é o gerenciamento limitado, por isso decidimos eestender a API do Kubernetes por meio do uso de uma definição de recurso personalizado (CRD), que nos permite criar um recurso nativo personalizado no Kubernetes semelhante a um StatefulSet ou uma implantação, mas projetado especificamente para gerenciar instâncias do Couchbase.
Excelente! Então, com os StatefulSets/CRDs, temos todas as operações de hardware organizadas, mas falta apenas uma "pequena" coisa: e o estado do próprio aplicativo? Em um banco de dados, por exemplo, adicionar um novo nó ao cluster não é suficiente; ainda seria necessário acionar alguns processos, como o rebalanceamento para mover/replicar alguns dos dados para o nó recém-adicionado para torná-lo totalmente operacional. É exatamente por isso que os operadores da K8s entraram no jogo.
Operadores de Kubernetes
Kubernetes 1.7 adicionou um recurso importante chamado Controladores personalizados. Em resumo, ele permite desenvolvedores para estender e adicionar novas funcionalidades, substituir as existentes (como substituir o kube-proxy, por exemplo) e, é claro, automatizar tarefas administrativas como se fossem um componente nativo do Kubernetes.
Um Operator nada mais é do que um conjunto de controladores personalizados específicos do aplicativo. Então, por que ele é um divisor de águas? Bem, os controladores têm acesso direto à API do Kubernetes, o que significa que podem monitorar o cluster, alterar pods/serviços, aumentar/diminuir a escala e chamar endpoints dos aplicativos em execução, tudo de acordo com regras personalizadas escritas dentro desses controladores.
Para ilustrar esse comportamento, vamos ver como o Operator do Couchbase funciona quando um Pod é eliminado:
Você pode saber mais sobre as operadoras aqui
Como você pode ver na figura acima, o Operator monitora e analisa o cluster e, com base em um conjunto de parâmetros, aciona uma série de ações para atingir o estado desejado. Esse processo de reconciliação está em todo lugar no K8s. Mas nem todas as ações são iguais. Em nosso exemplo, temos duas categorias distintas:
- Infraestrutura - adicionar um novo nó: O operador solicita, por meio da API do Kubernetes, o lançamento de um novo pod executando o Couchbase Server.
- Específico do domínio - Adicionar nó ao cluster/ Acionar rebalanceamento de dados: O operador sabe como o Couchbase funciona e chama o endpoint rest correto para adicionar o novo nó ao cluster e acionar o rebalanceamento de dados.
Esse é o verdadeiro poder dos Operadores, Eles permitem que você escreva um aplicativo para gerenciar totalmente outroe adivinhe que tipo de aplicativos com estado são os mais difíceis de gerenciar? Você está certo: Os bancos de dados.
Os desenvolvedores sempre esperaram que os bancos de dados funcionassem imediatamente, quando, na verdade, historicamente, eles são exatamente o oposto. Temos até um nome específico para a pessoa responsável por cuidar do banco de dados, nossos queridos DBAs.
O Operator do Couchbase foi criado como um esforço para mudar esse cenário e tornar os bancos de dados fáceis de gerenciar sem prendê-lo a um fornecedor de nuvem específico. Atualmente, ele oferece suporte ao provisionamento automatizado de clusters, escalabilidade elástica, recuperação automática, registro em log e acesso ao console da Web, mas muitos outros recursos serão lançados no futuro. Se quiser saber mais sobre ele, consulte este artigo ou consulte a documentação oficial do Couchbase aqui.
Também devo mencionar que é o primeiro operador oficial lançado para um banco de dados, e há alguns pequenos projetos comunitários que já estão tentando criar operadores para o MySQL, Postrgres e outros bancos de dados.
O ecossistema da Operadora está crescendo rapidamente, torre por exemplo, permite que você implemente algo muito semelhante ao AWS S3. O operador do Apache Kafka Kubernetes será lançado em breve e há muitas outras iniciativas por aí. Esperamos um grande aumento no número de operadores nos próximos meses, agora que todos os principais provedores de nuvem oferecem suporte ao K8s.
Por fim, o Kubernetes oferece implantação e gerenciamento de aplicativos independentes da nuvem. Ele é tão avançado que pode nos levar a tratar os provedores de nuvem quase como uma commodity, pois você poderá migrar livremente entre eles.
No futuro, escolher um provedor de nuvem pode ser apenas uma questão de saber qual deles oferece o melhor desempenho/custo. O impacto dessa mudança radical no mercado ainda não está claro, mas, como desenvolvedores, certamente seremos os maiores vencedores.
ATUALIZAÇÃO: Embora este artigo tenha sido escrito há pouco tempo, muitas coisas já mudaram. Agora temos o Operador autônomo do Couchbase 1.2, Armazenamento local persistente é GA, e há um Hub de operadores para centralizar todos os operadores de código aberto.
Se você tiver alguma dúvida, sinta-se à vontade para me enviar um tweet para @deniswsrosa
Blog muito informativo e sucinto!