Compreender a gestão de estados no Kubernetes
Ao falar sobre aplicativos em geral, muitas vezes você pode ouvir sobre o estado do aplicativo. 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 da aplicação é tudo o que está armazenado na memória quando a aplicação está em execução. 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 o seu leitor de música aberto. A aplicação tem um estado. Sabe quem é, o que gosta de ouvir e que música transferiu. Todas essas informações fazem parte do estado do aplicativo.
O estado na memória são as informações que a aplicação não precisa de procurar noutros locais. O estado do disco contém as informações que a aplicação não tem disponíveis, pelo que precisa de as obter através de outra origem de dados.
Tipos de estado
Existem dois tipos de estados da 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. Algumas aplicações podem funcionar só com isso, uma vez que podem regenerar o estado a partir de outras origens, pelo que não precisam que o estado esteja armazenado localmente. Essas aplicações chamam-se aplicações 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 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.
As aplicações que dependem de um estado externo para serem obtidas chamam-se aplicações stateful.
Estados e o Kubernetes
O Kubernetes pode lidar com aplicativos sem e com monitoração de 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 carga de trabalho de implementação simples com um pod seria o suficiente para ter um sistema totalmente funcional e para tirar o máximo partido do seu cluster.
Lidar com aplicações 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).
Gorjeta
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 localizados em nós para armazenar estados do contentor de um pod. Uma vez que o Kubernetes foi concebido para aplicações distribuídas, todos os volumes criados encontram-se num conjunto de volumes disponíveis. Os contentores reivindicam então esse espaço para si. Pode utilizar PersistentVolumeClaims para vincular um PersistentVolume com um pod e utilizar o respetivo passo para armazenar os dados necessários.
Todos os fornecedores de base 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.
Melhores práticas de gestão de estados
O estado está presente na maioria das aplicações. No entanto, o ideal é mesmo não ter de gerir o estado.
Pode conceber qualquer aplicação eficiente com o objetivo de a tornar altamente disponível e dimensioná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. Além disso, não tem elevada disponibilidade.
Estado de elevada disponibilidade
Para ter uma elevada disponibilidade, uma aplicação tem de estar sempre online. Para tal, utiliza-se a replicação de zona e região. O Kubernetes tem deteção de zona na maioria das suas cargas de trabalho. Tal significa que pode ter várias instâncias de uma aplicação implementadas em diferentes zonas. No entanto, os discos não têm esta deteção.
Quando você implanta um novo PersistentVolume objeto no Kubernetes, ele é vinculado a um disco em um nó. Esse disco também fica vinculado a uma zona em particular, numa região em particular. 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 dimensioná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. Isto é complicado na gestão de estados, uma vez que, 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 tiveram a ideia do , que replica todo o banco de ReplicaSetsdados em várias instâncias. A replicação aumenta o número de discos e a E/S do estado.
A cada alteração da base de dados, o estado precisa de ser sincronizado para que todos os discos contenham os mesmos dados. Esta 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 ajuda-o a concentrar-se na aplicação e reduzir a sobrecarga da gestão da integridade dos dados na sua infraestrutura.