Compreender o gerenciamento de estado no Kubernetes
Ao falar sobre aplicações em geral, muitas vezes pode ouvir sobre o estado da aplicação . Nesta unidade, revisamos a definição de estado e os diferentes tipos de estados para que você possa preparar melhor seu pedido para lidar com eles.
Estado
O estado do aplicativo é tudo o que está armazenado na memória no momento em que o aplicativo está sendo executado. O estado pode envolver várias coisas, mas nos concentramos principalmente nos dados do usuário.
Para dar um exemplo do estado da aplicação, imagine que tem um leitor de música aberto. Esta aplicação tem um estado. Ele sabe quem você é, o que você gosta de ouvir e que música você baixou. Todas essas informações fazem parte do estado do aplicativo.
O estado na memória é a informação 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 à mão, portanto, ele precisa recuperá-las de outra fonte de dados.
Tipos de estados
Existem dois tipos de estados de aplicação. O primeiro tipo é o estado efêmero, que não é persistente e desaparece assim que o aplicativo é fechado.
Os contentores têm um estado efémero. Todos os dados armazenados neles são perdidos instantaneamente quando o contêiner é excluído. Alguns aplicativos podem trabalhar apenas com isso, porque podem regenerar o estado de outras fontes e não precisam que o estado seja armazenado localmente. Esses aplicativos são chamados de aplicativos stateless.
Todo o estado restante que não é efêmero é chamado 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 no disco onde o estado existe. Mesmo que você remova o contêiner e o ligue novamente, o estado permanece armazenado em um local seguro e pode ser usado novamente.
Os aplicativos que dependem de um estado externo para serem recuperados são chamados de aplicativos stateful.
Estados e Kubernetes
O Kubernetes pode lidar com aplicações sem estado e com estado. Os 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 das aplicações sem estado, uma tarefa de implementação simples com um pod seria suficiente para ter um sistema totalmente funcional e aproveitar 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 PersistentVolumes (PVs) e PersistentVolumeClaims (PVCs).
Dica
Este módulo não discute mais os conceitos de armazenamento, mas você pode consultar os recursos do Serviço 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 estão em um pool de volumes disponíveis. Os contentores ocupam então esse espaço para si. Você pode usar PersistentVolumeClaims para vincular um PersistentVolume a um pod e usar seu espaço para armazenar os dados necessários.
Todos os provedores de banco de dados são aplicações 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.
Práticas recomendadas para a gestão do estado
O estado está presente na maioria das aplicações. No entanto, uma boa prática para lidar com o Estado é não lidar com ele.
Você projeta qualquer aplicativo eficiente com o objetivo de torná-lo altamente disponível e escalá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. Também não está altamente disponível.
Estado altamente disponível
Para estar altamente disponível, uma candidatura deve estar sempre online. Isso é feito por meio da replicação de zona e região. O Kubernetes reconhece a zona na maioria de suas cargas de trabalho. Isso significa que você pode ter várias instâncias de um aplicativo que são implantadas em zonas diferentes. No entanto, os discos não reconhecem zonas.
Quando você implanta um novo objeto PersistentVolume no Kubernetes, ele é vinculado a um disco em um nó. Esse disco também está vinculado a uma zona específica em uma região específica. O uso da replicação de zona ou região com PVs é complexo e requer muita manutenção, tanto para replicar quanto para sincronizar dados.
Estado altamente escalável
Para ser altamente escalável, um aplicativo deve aumentar sua taxa de transferência juntamente com o número de usuários conectados a ele. Isso é complicado no gerenciamento de estado porque qualquer estado externo é essencialmente um disco e um disco tem uma taxa de entrada e saída limitada. A gestão de capacidade ajuda a resolver este problema.
As soluções de banco de dados tiveram a ideia do ReplicaSets, que replica todo o banco de dados em várias instâncias. A replicação aumenta o número de discos e para a E/S do estado.
Em cada alteração de banco de dados, o estado precisa ser sincronizado para que todos os discos contenham os mesmos dados. Essa sincronização também é complexa.
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 escaláveis e resolvem a maioria dos problemas de gerenciamento de estado para você.
Armazenar o estado externamente e remover a necessidade de manutenção pode ajudá-lo a se concentrar no aplicativo e reduzir a sobrecarga de lidar com a integridade dos dados em sua infraestrutura.