Aplicações de Estado Vs Estado de Estado de Estado em Kubernetes
Vamos começar com uma definição ingênua de 'apatridia' e depois progredir lentamente para uma visão mais rigorosa e do mundo real.
Uma aplicação sem estado é aquela que depende de nenhum armazenamento persistente. A única coisa pela qual seu cluster é responsável é o código e outro conteúdo estático, sendo hospedado nele. É isso, sem bancos de dados em mudança, sem gravações e não sobrando arquivos quando a vagem é excluída.
Uma aplicação com estado, por outro lado, tem vários outros parâmetros que deve cuidar no cluster. Existem bancos de dados dinâmicos que, mesmo quando o aplicativo está offline ou excluído, persiste no disco. Em um sistema distribuído, como Kubernetes, isso levanta vários problemas. Vamos olhar para eles em detalhes, mas primeiro vamos esclarecer alguns conceitos errôneos.
Serviços sem estado não são realmente "sem estado"
O que isso significa quando dizemos o estado de um sistema? Bem, vamos considerar o seguinte exemplo simples de uma porta automática.
A porta se abre quando o sensor detecta alguém se aproximando e fecha quando o sensor não obtém entrada relevante.
Na prática, seu aplicativo sem estado é semelhante a esse mecanismo acima. Pode ter muito mais estados do que apenas fechado ou aberto, e muitos tipos diferentes de entrada também tornam -o mais complexo, mas essencialmente o mesmo.
Ele pode resolver problemas complicados apenas recebendo uma entrada e executando ações que dependem da entrada e do 'estado' em que está em. O número de estados possíveis é predefinido.
Então a apatridia é um nome impróprio.
Aplicações sem estado, na prática, também podem trapacear um pouco, economizando detalhes sobre, digamos, as sessões do cliente no próprio cliente (os cookies HTTP são um ótimo exemplo) e ainda têm uma boa divisória que os faria funcionar perfeitamente no cluster.
Por exemplo, os detalhes da sessão de um cliente, como quais produtos foram salvos no carrinho e não check -out, todos podem ser armazenados no cliente e na próxima vez que uma sessão iniciar esses detalhes relevantes também forem lembrados.
Em um cluster de Kubernetes, um aplicativo sem estado não tem armazenamento ou volume persistente associado a ele. De uma perspectiva de operações, esta é uma ótima notícia. Diferentes vagens em todo o cluster podem funcionar de forma independente, com vários pedidos chegando a eles simultaneamente. Se algo der errado, você pode apenas reiniciar o aplicativo e ele voltará ao estado inicial com pouco tempo de inatividade.
Serviços Stateful e o Teorema do CAP
Os serviços com estado, por outro lado, terão que se preocupar com muitas e muitas casas de borda e problemas estranhos. Uma vagem está acompanhada de pelo menos um volume e se os dados nesse volume estiverem corrompidos, isso persiste mesmo que todo o cluster seja reiniciado.
Por exemplo, se você estiver executando um banco de dados em um cluster Kubernetes, todos os pods devem ter um volume local para armazenar o banco de dados. Todos os dados devem estar em perfeita sincronia.
Portanto, se alguém modificar uma entrada no banco de dados, e isso foi feito no pod A, e uma solicitação de leitura vem no pod B para ver que dados modificados, o pod B deve mostrar que os dados mais recentes ou fornecer uma mensagem de erro. Isso é conhecido como consistência.
Consistência, No contexto de um cluster de Kubernetes, significa Cada leitura recebe a gravação mais recente ou uma mensagem de erro.
Mas isso corta contra disponibilidade, Uma das razões mais importantes para ter um sistema distribuído. A disponibilidade implica que seu aplicativo funcione o mais próximo da perfeição como o Possbile, o tempo todo, com o mínimo de erro possível.
Pode -se argumentar que você pode evitar tudo isso se tiver apenas um banco de dados centralizado, responsável por lidar com todas as necessidades persistentes de armazenamento. Agora estamos de volta a ter um único ponto de falha, que é mais um problema que um Kubernetes Clusters deve resolver em primeiro lugar.
Você precisa ter uma maneira descentralizada de armazenar dados persistentes em um cluster. Comumente referido como particionamento de rede. Além disso, seu cluster deve ser capaz de sobreviver ao fracasso dos nós que executam o aplicativo com estado. Isso é conhecido como tolerância à partição.
Qualquer serviço (ou aplicativo) com estado de Estado, sendo executado em um cluster de Kubernetes, precisa ter um equilíbrio entre esses três parâmetros. No setor, é conhecido como Teorema do CAP, onde as compensações entre consistência e disponibilidade são consideradas na presença de particionamento de rede.
Outras referências
Para obter mais informações sobre o teorema do CAP, você pode querer ver esta excelente palestra dada por Bryan Cantill, que analisa muito mais de perto a execução de sistemas distribuídos em produção.