Estou em um estado de descrença quando, em 2024, ouço com frequência operadores de plataformas afirmarem que o Kubernetes é apenas para cargas de trabalho stateless — ou que não exigem proteção de dados, como “todas as nossas aplicações são apátridas”. Neste artigo, vou oferecer um histórico sobre onde os estados existem em nossas aplicações, a ascensão do mito “Kubernetes = Stateless” e falar sobre as necessidades de proteção de dados em todos os ambientes Kubernetes.
Stateful vs. Stateless – O Básico
Stateless refere-se a uma carga de trabalho que não exige persistência de estado (stateful), o que significa que, ao reiniciar ou reimplantar a carga de trabalho, todos os dados coletados ou configurações alteradas são perdidos. Em contraste com as versões anteriores de máquinas virtuais (VMs) stateful, os contêineres são, por natureza, stateless. Ao reiniciar um contêiner, o usuário tem a certeza de que a carga de trabalho em execução é exatamente a mesma que foi definida na criação da imagem do contêiner.
Seguindo essa lógica, uma carga de trabalho stateful é aquela que mantém os dados de maneira que possam ser recuperados após reinicializações. Cargas de trabalho stateful comuns incluem bancos de dados como PostgreSQL, MySQL ou MongoDB.
Então, o que é um aplicativo stateless?
Normalmente, os aplicativos consistem em múltiplas cargas de trabalho. Até mesmo os aplicativos monolíticos baseados em VM costumam ser compostos por front-end, lógica de negócios e cargas de trabalho de banco de dados distintas. Os aplicativos baseados em microsserviços nativos da nuvem normalmente consistirão em muitas outras cargas de trabalho separadas, cada uma com sua função específica, com o objetivo de permitir que as organizações enviem novos recursos e serviços mais rápido do que nunca.
Isso implica que, na maioria das vezes, aplicativos completamente stateless não existem.
Seu aplicativo favorito de pedidos de comida, um aplicativo “a fazer” em seu telefone, um formulário que você preenche para marcar uma consulta médica – tudo isso seria efetivamente inútil se não houvesse algumas cargas de trabalho com estado responsáveis por persistir os dados críticos associados a cada um desses casos de uso.
Com o Kubernetes, é essencial entender onde os dados ou estado da sua aplicação residem: dentro ou fora do cluster.
Como chegamos aqui — Kubernetes = stateless?
Com o Docker se consolidando como a plataforma de contêineres líder no início e meio da década de 2010 para o empacotamento de software, era crucial ter uma solução capaz de orquestrar grupos de contêineres em larga escala para aproveitar ao máximo os benefícios operacionais da transição para microsserviços. E foi aí que o Kubernetes se destacou. Implantações declarativas, alta disponibilidade e escalabilidade automatizada foram vantagens importantes para cargas de trabalho stateless, que podiam ser interrompidas, reiniciadas e clonadas de maneira simples. Essas cargas de trabalho, que geralmente fornecem mais computação de front-end ou servidor de aplicativos, podem ser conectadas a serviços de dados em execução fora do cluster. A solução foi amplamente reconhecida como um sucesso. O Kubernetes foi, sem dúvida, desenvolvido para atender a cargas de trabalho stateless, não é mesmo?
No entanto, no Kubernetes v1.0, além de todos os recursos impressionantes voltados para cargas de trabalho stateless, também existiam os Persistent Volumes — uma funcionalidade nativa do Kubernetes que permite conectar storage persistente a pods efêmeros. Fica claro que o suporte a cargas de trabalho stateful foi uma preocupação desde o início, com várias melhorias importantes sendo implementadas ao longo do tempo:
- Dez 2017 (v1.9) Disponibilidade geral de StatefulSets — fornecendo persistência de características de identidade de pod e operações ordenadas
- Dezembro de 2018 (v1.13): disponibilidade geral da Container Storage Interface (CSI) — um padrão que permite a qualquer fornecedor de storage criar os próprios plug-ins para fornecer storage às cargas de trabalho do Kubernetes.
- maio de 2018 Introdução do Operator Framework — um Software Development Kit (SDK) para simplificar a implantação e o geranciamento de cargas de trabalho avançadas, como bancos de dados, no Kubernetes
- Dezembro de 2020 (v1.20): disponibilidade geral de snapshots de volume dentro da especificação CSI — oferecendo uma interface padronizada para realizar operações de snapshot de storage no Kubernetes.
Essas melhorias, combinadas com os esforços de muitos fornecedores e colaboradores de projetos diferentes, criaram um amplo ecossistema que dá aos usuários a liberdade de escolher quais serviços de dados fornecerão o estado de suas aplicações e onde essas cargas de trabalho serão executadas.
A ascensão do GitOps
Nesse período, a comunidade do Kubernetes viu surgir mais uma ideia para melhorar a orquestração de contêineres: o GitOps. O conceito é simples: Utilizar o controle de versão do código-fonte como a fonte da verdade, armazenando tudo o que é necessário para a implantação de uma aplicação, incluindo o código e os recursos do Kubernetes. Sempre que o código é mesclado no repositório para uma alteração, um controlador atualiza a implantação para refletir o estado desejado descrito no Git. As implementações de GitOps podem fornecer um mecanismo para controle de alterações, a capacidade de reimplantar um ambiente inteiro com um único clique e uma maneira de reverter alterações incorretas — às vezes.
Só porque o Kubernetes pode executar cargas de trabalho stateful, isso significa que você deve fazer isso?
Com a tarefa de criar uma aplicação de prova de conceito, um desenvolvedor geralmente pode optar por um banco de dados gerenciado hospedado na nuvem, ou DBaaS, para hospedar seus dados persistentes fora do cluster Kubernetes. As soluções DBaaS oferecem APIs intuitivas para desenvolvedores e proporcionam um rápido retorno de valor para os usuários, independentemente de sua experiência em administração de banco de dados. No entanto, como muitas vezes é verdade, o que é mais fácil nem sempre é o melhor. Vamos analisar os motivos para considerar a execução de cargas de trabalho stateful tanto dentro quanto fora do cluster:
- Latência — Colocalizar serviços de dados junto com outras cargas de trabalho em contêineres ajuda a garantir conectividade de baixa latência com seus dados para oferecer uma experiência de usuário consistente.
- Mobilidade – O Kubernetes fornece uma forte camada de abstração, permitindo que você mova a mesma carga de trabalho entre nuvens diferentes. Isso permite que as empresas atendam a necessidades de soberania de dados ou simplesmente aproveitem melhores condições de preço. No entanto, se seus serviços de dados estiverem vinculados a um DBaaS específico da nuvem, a migração entre ambientes se tornará significativamente mais complicada. As automações e políticas criadas para um DBaaS precisarão ser recriadas para o banco de dados gerenciado equivalente em sua nuvem de destino, presumindo que ele exista e atenda aos requisitos. Ferramentas e processamento separados serão necessários para reimplantar suas cargas de trabalho do Kubernetes a partir de seus serviços de dados externos.
- Gerenciamento de Cópia de Dados — Seus desenvolvedores precisam testar o aplicativo com dados atualizados e relevantes, o que exige processos distintos para gerenciar e conectar esses serviços de dados quando são executados fora do cluster. Como parte de uma solução totalmente declarativa que executa cargas de trabalho stateless e stateful dentro do cluster, os usuários podem simplesmente restaurar backups de aplicações completas como clones, usando uma interface nativa do Kubernetes como ‘kubectl’.
- Persistência poliglota — Uma forma refinada de expressar “usar o serviço de dados adequado para cada caso de uso”. Com a recriação de aplicações legadas em uma arquitetura de microsserviços, os desenvolvedores podem aproveitar o Kubernetes para implementar o serviço de dados mais adequado a cada necessidade, com uma implantação simplificada e gerenciamento contínuo realizado pelos operadores. As organizações que operam serviços de dados fora do Kubernetes podem não ser capazes de escalar para atender aos complexos requisitos operacionais de suporte a cada uma das seleções ideais de serviços de dados feitas pelos desenvolvedores.
- Custo — Com as soluções DBaaS, você paga pela conveniência. No entanto, parceiros como o EnterpriseDB demonstraram como hospedar seus próprios serviços de dados no Kubernetes pode gerar um custo total de propriedade (TCO) mais baixo, sem comprometer significativamente a experiência do usuário.
Consolidar cargas de trabalho stateless e stateful no Kubernetes pode proporcionar maior flexibilidade quanto aos ambientes em que as aplicações podem ser executadas. Ele também pode fornecer autosserviço adicional para DevOps, reduzir custos e simplificar ferramentas e processos. Isso possibilita a aplicação da metodologia GitOps a todos os componentes de um aplicativo. Não deve ser surpresa, então, de acordo com o relatório mais recente da Datadog sobre o uso de contêineres no mundo real, que os bancos de dados continuem a ser a categoria mais popular de cargas de trabalho em contêineres.
Mantendo seus dados do Kubernetes protegidos
Equipe stateful
Se você já está convencido de que as cargas de trabalho stateful no Kubernetes são o caminho a seguir, provavelmente já percebeu que oferecer backup e recuperação de desastres para essas aplicações exige uma ferramenta desenvolvida especialmente para essa finalidade. Cada aplicativo é formado por diversos recursos do Kubernetes (como ConfigMaps, Secrets, Deployments, etc.), além de dados armazenados em volumes persistentes. Além disso, todos esses recursos precisam ser devidamente descobertos, ter snapshots criados e ser exportados para um local seguro fora do cluster.
Apresentamos o Veeam Kasten for Kubernetes, uma solução nativa de proteção de dados e mobilidade de aplicativos para ambientes Kubernetes. A Kasten oferece às organizações uma forma simples, escalável e segura de criar backups imutáveis e recuperar aplicações completas de maneira rápida e confiável.
Como a Kasten fornece uma API declarativa nativa do Kubernetes para definir políticas, executar ações e mais, a proteção de dados pode ser totalmente integrada a qualquer implementação de GitOps. Isso é válido em uma ampla gama de casos de uso, desde a implantação e configuração do Kasten em um novo cluster até o aprimoramento do GitOps, automatizando os backups antes de realizar atualizações de código. O GitOps, por si só, oferece a capacidade de reverter alterações de configuração em um recurso do Kubernetes. No entanto, se uma dessas alterações afetar os dados em um volume persistente (como uma alteração incorreta de esquema ou a exclusão de uma tabela), será necessário ter um backup recente que possa ser restaurado rapidamente.
Equipe stateless
Ainda não está pronto para substituir seu DBaaS favorito por um novo e sofisticado banco de dados hospedado no Kubernetes e gerenciado por operador? A Kasten ainda está com você. Vamos ver por que a proteção de dados nativa para Kubernetes ainda é necessária:
- O estado deve residir em algum lugar — Independentemente de onde os dados estejam armazenados fora do cluster, é fundamental ser capaz de reproduzir implantações de aplicações em um determinado momento no tempo, geralmente por motivos de recuperação de desastres (DR) ou conformidade. Em sua essência, o Kasten é um mecanismo de orquestração projetado para operações de proteção de dados. As capacidades de design da Kasten oferecem controles robustos para pausar serviços de dados no cluster, além de possibilitar a orquestração de snapshots e backups de serviços de dados externos. Isso pode incluir a orquestração de dumps lógicos de um banco de dados ou a integração direta com APIs do DBaaS.
- O GitOps não é infalível — Muitos administradores e engenheiros já vivenciaram algum tipo de “teste em produção”. Isso significa que alterações foram feitas em uma instância de produção que <inserir o motivo importante aqui> contornaram o processo de gerenciamento de mudanças estabelecido. Assim, a única fonte de verdade do que foi implantado vem do próprio cluster em tempo de execução. Ter backups regulares dos manifestos associados a cada aplicação, conforme implantado, garante que qualquer uma dessas discrepâncias seja capturada, permitindo reproduções fiéis do ambiente original para suportar a DR e/ou quaisquer requisitos normativos.
- Proteção de imagens de contêiner— o Kasten se integra com muitos dos recursos avançados fornecidos pelo Red Hat OpenShift, incluindo o suporte para proteger e restaurar imagens de contêiner do ImageStream. Os fluxos de imagens adicionam uma riqueza de funcionalidades para criar e implantar imagens de contêiner em comparação com o Kubernetes upstream. Fontes que podem ser potencialmente ignoradas em um estado de cluster incluem as imagens ImageStream de contêiner, que, por padrão, são enviadas para o registro de contêiner interno do cluster. A reconstrução a partir do código fonte não fornece uma garantia de que as imagens resultantes serão as mesmas. Mais uma vez, ser capaz de reproduzir totalmente um ambiente ou se recuperar da perda de um cluster requer backups confiáveis.
- Máquinas virtuais no Kubernetes — Graças ao projeto KubeVirt e seus colaboradores, agora é possível executar VMs lado a lado com cargas de trabalho em contêineres no Kubernetes. Isso permite que as empresas simplifiquem as ferramentas e processos em torno do Kubernetes, ao mesmo tempo em que fornece uma rampa simples para cargas de trabalho que ainda não foram, ou simplesmente não serão, transformadas em aplicações totalmente nativas de nuvem. Mesmo no Kubernetes, as VMs são, por natureza, stateful, mas não podem ser protegidas pelas ferramentas tradicionais de backup de VMs. O Kasten V7.0 oferece o melhor suporte da categoria para backup e restauração de VMs no Kubernetes, executando a virtualização OpenShift.
Equipe de proteção de dados para Kubernetes
O Kubernetes evoluiu para aceitar todos os tipos de cargas de trabalho, desafiando a crença persistente de que ele seria adequado apenas para cargas de trabalho stateless. À medida que as organizações trabalham para extrair o máximo de valor de seus investimentos em nuvem nativa, uma mudança contínua em direção à execução de cargas de trabalho stateful é inevitável. Melhor desempenho e mobilidade, geranciamento simplificado de dados de cópia, persistência poliglota e economia de custos são benefícios que esperam ser realizados.
Seja executando cargas de trabalho stateful ou stateless, a proteção de dados continua sendo crucial. O Veeam Kasten for Kubernetes fornece uma solução nativa do Kubernetes para backup de aplicações e dados, recuperação de desastres, mobilidade de aplicações e proteção contra ransomware. Além disso, é possível aprimorar as metodologias de GitOps com a integração da proteção de dados às implantações de aplicativos. Em última análise, adotar cargas de trabalho stateful no Kubernetes não só desbloqueia oportunidades de receita, mas também traz mais flexibilidade, autosserviço, economia e operações simplificadas para as empresas.
Teste nossa solução Veeam Kasten Free ou nossa versão de avaliação Enterprise para começar hoje mesmo.