HomePtNotíciaVocê deve executar aplicativos com estado no Kubernetes?

Você deve executar aplicativos com estado no Kubernetes?

- Advertisement -
- Advertisement -
- Advertisement -
- Advertisement -

[ad_1]

Shutterstock.com/o_m

O Kubernetes é frequentemente abordado da perspectiva de sistemas sem estado. Um aplicativo sem estado é fácil de conter, distribuir e dimensionar porque não precisa armazenar nenhum dado fora de seu ambiente. Não importa se o container foi parado ou movido para um host diferente: as novas instâncias podem substituir as antigas sem nenhuma repercussão.

No entanto, a maioria das aplicações reais não é assim. Todos, exceto os sistemas mais simples, têm estado que geralmente é armazenado em um banco de dados ou sistema de arquivos persistente. Os dados que configuram seu serviço ou são criados pelos usuários devem ser preservados e disponibilizados para todos os seus contêineres, independentemente de onde estejam.

A maioria das organizações enfrenta o desafio de manter o estado em ambientes transitórios que usam contêineres, orquestração e práticas de trabalho nativas da nuvem. O Kubernetes pode acomodar cargas de trabalho com estado, mas também existem alternativas externas. Neste artigo, você aprenderá algumas das abordagens que fazem o Kubernetes funcionar com aplicativos com estado.

problemas com o estado

O termo “estado” descreve os dados associados a um aplicativo em um determinado momento. Essas são informações de longa duração, como conteúdo de banco de dados e contas de usuário, que precisarão ser recuperadas durante a vida útil do sistema. O estado muda continuamente à medida que os dados são criados e modificados enquanto seu serviço está em uso.

O correto funcionamento da aplicação depende de cada instância poder acessar o estado persistente. Se você distribuir quatro réplicas de um componente em dois hosts físicos, ambas as máquinas precisarão acessar seu armazenamento de dados. Isso significa que as instâncias do aplicativo têm dependências inter-relacionadas que não podem ser substituídas automaticamente.

As restrições em torno dos serviços com estado entram em conflito com o modelo Kubernetes de contêineres efêmeros que podem ser substituídos a qualquer momento. Ao trabalhar com um aplicativo com estado, você deve executar etapas especiais para que seus contêineres possam acessar com segurança o estado de que precisam. Isso requer configuração adicional para fornecer persistência de dados confiável que permanece estável à medida que seu aplicativo é dimensionado.

Executando serviços com estado no Kubernetes

O suporte do Kubernetes para sistemas com estado cresceu nos últimos anos, apoiado pelo aumento do interesse da comunidade. Aplicativos com estado podem ser montados a partir de recursos com suporte oficial, como conjuntos com estado e volumes persistentes. Eles oferecem métodos integrados para armazenar e gerenciar seus dados.

Volumes persistentes fornecem armazenamento de dados para seus pods. Os arquivos gravados em um volume persistente são armazenados independentemente do pod que os cria. O conteúdo do volume persiste em seu cluster depois que os pods são destruídos, permitindo que suas substituições acessem o estado armazenado.

StatefulSets são objetos de API que representam aplicativos com estado. Eles funcionam de maneira semelhante às implantações, mas atribuem um identificador exclusivo a cada pod que encapsulam. Os pods mantêm seus identificadores mesmo se forem reiniciados ou programados em outro nó. Isso permite implementar procedimentos em que a ordem e a identidade dos pods são importantes. Identificadores confiáveis ​​permitem que você faça uma nova correspondência de volumes com pods após um evento de agendamento e libere atualizações de aplicativos em sequência.

Esses recursos significam que agora é possível executar aplicativos com estado em seu cluster Kubernetes. Você pode gravar dados em volumes persistentes e usar StatefulSets em vez de implementações quando os pods precisarem lembrar suas identidades.

Estado de gerenciamento fora do Kubernetes

Uma rota popular para executar serviços com estado no Kubernetes é localizar fora de Seu grupo Você projeta seu sistema para que seus componentes sejam desacoplados do armazenamento de que necessitam. Eles podem acessar dados persistentes em serviços separados pela rede.

Você pode manter seu próprio servidor de banco de dados, conectar-se a compartilhamentos de arquivos de rede existentes ou usar um serviço totalmente gerenciado de seu provedor de nuvem. Os aplicativos em seu cluster Kubernetes devem ser configurados para interagir com seus sistemas de armazenamento usando suas APIs ou protocolos de acesso direto.

Essa é uma boa maneira de promover a dissociação em seus serviços. A remoção do acesso persistente ao sistema de arquivos de seus aplicativos em contêiner os torna mais portáteis entre ambientes. Os contêineres podem ser lançados usando modelos de implantação sem estado, pois suas dependências de armazenamento são reduzidas a chamadas de rede básicas. Você pode se beneficiar da flexibilidade do Kubernetes sem incorrer no custo da complexidade de usar volumes persistentes e conjuntos com estado para armazenar o estado em seu cluster.

Evite Kubernetes para serviços com estado

Uma terceira escola de pensamento é evitar completamente o Kubernetes para serviços com estado. Isso geralmente é uma reação exagerada: se você não se sentir à vontade para manter o estado em seu cluster, ainda poderá usar o método descrito acima para implantar seus aplicativos usando um provedor de armazenamento adjacente.

No entanto, ainda existem alguns sistemas que podem não fazer sentido no Kubernetes. Arquiteturas extremamente dependentes do sistema de arquivos que funcionam com um grande número de arquivos podem ser difíceis de implementar e dimensionar usando volumes persistentes. Um sistema de armazenamento externo gerenciado em conjunto com o Kubernetes pode adicionar latência inaceitável quando as interações de arquivos são a função principal do seu serviço.

Nessas circunstâncias, talvez seja necessário procurar abordagens alternativas de implantação que ofereçam mais controle sobre o armazenamento de dados e as operações de E/S. No entanto, o trabalho está sendo feito no ecossistema para melhorar as opções de armazenamento para sistemas em contêineres. As soluções de armazenamento nativas da nuvem estão surgindo como abstrações de alto nível de conceitos como volumes persistentes e conjuntos com estado, implementando sistemas de arquivos distribuídos que continuam a funcionar quando usados ​​em vários nós. Ceph, Minio e Portworx são alguns dos concorrentes neste espaço.

Você deve executar aplicativos com estado no Kubernetes?

A maioria dos aplicativos com estado pode ser implantada com sucesso com o Kubernetes. A principal decisão é manter seus dados persistentes em seu cluster, usando volumes persistentes e conjuntos com estado ou interagindo com um armazenamento de dados gerenciado externamente.

Os volumes persistentes funcionam para a maioria dos casos de uso, mas têm algumas limitações. Nem todos os modos de acesso a volume são compatíveis com todas as implementações, portanto, é importante verificar quais recursos sua distribuição do Kubernetes oferece suporte.

Relativamente poucos motoristas oferecem o ReadWriteMany modo que permite que o volume seja anexado a vários nós simultaneamente, cada um capaz de ler e gravar dados. a ReadWriteOnce O modo é o mais amplamente suportado, permitindo que cada nó leia os dados, mas apenas um deles escreva. Essas restrições podem afetar o agendamento do seu aplicativo: um sistema com vários pods que precisam gravar em uma instância de banco de dados compartilhada precisará executá-los em um único nó, a menos que ReadWriteMany está disponível. Isso limita sua capacidade de dimensionar seus serviços.

Usar um banco de dados gerenciado externamente ou um sistema de armazenamento de objetos é uma maneira eficaz de mitigar esses problemas persistentes enquanto se beneficia da flexibilidade do Kubernetes. Isso exige que seu aplicativo seja completamente desacoplado do armazenamento, portanto, pode não ser uma opção se você estiver migrando um serviço herdado.

Trabalhar com aplicativos mais antigos apresenta o argumento mais forte para Não executando um aplicativo com estado no Kubernetes. Você pode encontrar obstáculos se não puder ser intencional sobre onde o estado é armazenado e como ele é gerenciado. Nessas situações, geralmente é melhor refatorar seu sistema antes de tentar distribuí-lo aos nós de implementação.

Resumo

Embora os aplicativos com estado e o Kubernetes não sejam um ajuste natural, é possível acomodar dados persistentes em seu cluster combinando conjuntos com estado e volumes persistentes. Eles fornecem métodos com suporte oficial para orquestrar sistemas com estado usando o Kubernetes, mas você deve estar ciente das restrições de programação que eles impõem.

Como o gerenciamento de estado no cluster aumenta a complexidade, manter os dados persistentes em um serviço externo é uma maneira popular de otimizar suas implantações. Bancos de dados gerenciados, plataformas de armazenamento de objetos e redes privadas permitem provisionar armazenamento fora de seu cluster e consumi-lo com segurança de dentro. Você precisará adaptar seu aplicativo para oferecer suporte a interfaces de armazenamento externas, mas poderá se beneficiar de uma maior flexibilidade de implementação.

Os aplicativos em que o estado consiste em arquivos de configuração simples podem usar o ConfigMaps para executar no Kubernetes sem precisar adotar o armazenamento de arquivos persistente. ConfigMaps são objetos de primeira classe que são fornecidos automaticamente aos seus pods quando são necessários, seja como variáveis ​​de ambiente ou como arquivos montados. Eles eliminam a necessidade de volumes persistentes quando você armazena apenas algumas configurações de longa duração.

[ad_2]

- Advertisement -
- Advertisement -
Stay Connected
16,985FansLike
2,458FollowersFollow
61,453SubscribersSubscribe
Must Read
- Advertisement -
Related News
- Advertisement -