Entender o gerenciamento de estado no Kubernetes

Concluído

Ao falar sobre aplicativos em geral, você pode ouvir falar frequentemente sobre o estado do aplicativo. Nesta unidade, analisamos a definição de estado e os diferentes tipos de estados para que você possa preparar melhor seu aplicativo para lidar com eles.

Estado

O estado do aplicativo é tudo que é armazenado na memória no momento em que o aplicativo é executado. O estado pode envolver várias coisas, mas nos concentramos principalmente nos dados do usuário.

Para dar um exemplo de estado do aplicativo, imagine que você tem um player de música aberto. Esse aplicativo tem um estado. Ele sabe quem você é, o que gosta de ouvir e quais músicas você baixou. Todas essas informações fazem parte do estado do aplicativo.

O estado na memória são as informações que o aplicativo não precisa procurar em nenhum outro lugar. O estado do disco contém as informações que o aplicativo não tem disponíveis, precisando, portanto, recuperá-las de outra fonte de dados.

Tipos de estados

Há dois tipos de estados do aplicativo. O primeiro tipo é o estado efêmero, que não é persistente e desaparece assim que o aplicativo é fechado.

Os contêineres têm um estado efêmero. Todos os dados armazenados dentro deles são perdidos instantaneamente quando o contêiner é excluído. Alguns aplicativos podem trabalhar com isso sozinho, porque podem regenerar o estado de outras fontes e não precisam do estado para serem armazenados localmente. Esses aplicativos são chamados de aplicativos stateless.

Todo o estado restante que não é efêmero é chamado de estado persistente. O estado persistente continua a existir após o ciclo de vida de um contêiner. A maioria das tecnologias de contêiner que usamos tem o conceito de volume, um local em disco onde o estado existe. Mesmo que você remova o contêiner e ligue-o de novo, o estado permanece armazenado em uma localização segura, podendo ser usado novamente.

Os aplicativos que dependem de um estado externo ser recuperado são chamados de aplicativos stateful.

Estados e o Kubernetes

O Kubernetes pode lidar com aplicativos sem estado e com estado. Aplicativos sem estado são mais fáceis porque podemos nos concentrar apenas no aplicativo em si e não em seu estado (já que ele não existe).

Para a maioria dos aplicativos sem estado, uma carga de trabalho de implantação simples com um pod é suficiente para que você tenha um sistema totalmente funcional e aproveite ao máximo o seu cluster.

Lidar com aplicativos com estado é o oposto. Nesses casos, você precisa considerar o aplicativo e seu estado, onde o estado está armazenado e como você pode armazenar o estado de forma segura e confiável.

É por isso que o Kubernetes também tem o conceito de PVs (PersistentVolumes) e PVCs (PersistentVolumeClaims).

Dica

Este módulo não aborda ainda mais os conceitos de armazenamento, mas você pode consultar os recursos do Serviço de Kubernetes do Azure no resumo para saber mais.

PersistentVolumes são discos alocados em nós para armazenar estados do contêiner de um pod. Como o Kubernetes é melhor para aplicativos distribuídos, todos os volumes criados residem em um pool de volumes disponíveis. Em seguida, os contêineres reivindicam esse espaço para si mesmos. Use PersistentVolumeClaims para associar um PersistentVolume a um pod e usar o espaço dele para armazenar os dados necessários.

Todos os provedores de banco de dados são aplicativos com estado. Se você estiver implantando um provedor de banco de dados em seu cluster, precisará de um PV e um PVC para armazenar os dados do banco de dados em um local seguro e permitir que o provedor recupere esses dados mesmo que seus contêineres tenham sido excluídos.

Melhores práticas de tratamento do estado

O estado está presente na maioria dos aplicativos. No entanto, uma melhor prática de tratamento do estado é não lidar com ele.

Você cria qualquer aplicativo eficiente com a meta de torná-lo altamente disponível e escalonável. O estado vai na direção oposta. Apesar das opções fornecidas pelos provedores de armazenamento e da facilidade de implantação e uso, o estado não é dimensionado facilmente. Ele também não é altamente disponível.

Estado altamente disponível

Para ser altamente disponível, um aplicativo precisa estar sempre online. Isso é feito por meio da replicação de zona e de região. O Kubernetes tem reconhecimento de zona na maioria das cargas de trabalho. Isso significa que você pode ter várias instâncias de um aplicativo que são implantadas em diferentes zonas. No entanto, os discos não têm reconhecimento de zona.

Quando você implanta um novo objeto PersistentVolume no Kubernetes, ele é associado a um disco em um nó. Esse disco também é associado a uma zona específica em determinada região. Usar a replicação de zona ou região com PVs é complexo e requer muita manutenção, tanto para replicar quanto para sincronizar dados.

Estado altamente escalonável

Para ser altamente escalonável, um aplicativo deve aumentar sua taxa de transferência junto com o número de usuários conectados a ele. Isso é complicado no gerenciamento de estado porque, essencialmente, qualquer estado externo é um disco, e um disco tem uma taxa de entrada e saída limitada. O gerenciamento de taxa de transferência ajuda a resolver esse problema.

As soluções de banco de dados surgiram com a ideia de ReplicaSets, que replica todo o banco de dados em várias instâncias. A replicação aumenta o número de discos e a E/S para o estado.

Em cada alteração de banco de dados, o estado precisa ser sincronizado, de modo que todos os discos contenham os mesmos dados. Essa sincronização também é complexa.

Como externalizar o estado

O Azure tem soluções de plataforma como serviço (PaaS), como o Azure Cosmos DB, que são altamente disponíveis e escalonáveis e resolvem a maioria dos problemas de gerenciamento de estado para você.

Armazenar o estado externamente e remover a necessidade de manutenção podem ajudar você a se concentrar no aplicativo e reduzir a sobrecarga de lidar com a integridade dos dados na sua infraestrutura.

Verificar seu conhecimento

1.

Qual é o estado persistente de um aplicativo?

2.

Como o Kubernetes lida com os estados?

3.

Qual é uma melhor prática de tratamento do estado em aplicativos do Kubernetes?