👊 🥑 👉🏽 Projetando Clusters Kubernetes: Quantos Devem Ser? 🎥 👧🏻 🌵

Nota perev. : Este material do projeto educacional do learnk8s é a resposta para uma pergunta popular ao projetar infraestrutura baseada no Kubernetes. Esperamos que descrições suficientemente detalhadas dos prós e contras de cada opção ajudem a fazer a melhor escolha para o seu projeto.

TL; DR : o mesmo conjunto de cargas de trabalho pode ser executado em vários clusters grandes (cada cluster terá um grande número de cargas de trabalho) ou em muitos pequenos (com um pequeno número de cargas em cada cluster).

A tabela abaixo resume os prós e contras de cada abordagem:

Ao usar o Kubernetes como uma plataforma para aplicativos operacionais, muitas vezes surgem várias questões fundamentais sobre os meandros da configuração de cluster:

Quantos clusters para usar?
Quão grande eles fazem?
O que cada cluster deve incluir?

Neste artigo, tentarei responder a todas essas perguntas analisando os prós e contras de cada abordagem.

Declaração de uma pergunta

Como criador de software, é provável que você desenvolva e opere muitos aplicativos em paralelo.

Além disso, muitas instâncias desses aplicativos provavelmente são executadas em vários ambientes - por exemplo, podem ser dev , test e prod .

O resultado é toda uma matriz de aplicativos e ambientes:

Aplicativos e ambientes

No exemplo acima, 3 aplicativos e 3 ambientes são apresentados, o que fornece 9 opções possíveis.

Cada instância do aplicativo é uma unidade de implantação independente que pode ser operada independentemente de outras.

Observe que uma instância de aplicativo pode consistir em muitos componentes.como front-end, back-end, banco de dados etc. No caso de um aplicativo de microsserviço, a instância incluirá todos os microsserviços.

Como resultado, os usuários do Kubernetes têm várias perguntas:

Devo colocar todas as instâncias do aplicativo em um cluster?
Devo criar um cluster separado para cada instância do aplicativo?
Ou talvez você deva usar uma combinação das abordagens acima?

Todas essas opções são bastante viáveis, porque o Kubernetes é um sistema flexível que não limita o usuário em possibilidades.

Aqui estão algumas das maneiras possíveis:

um grande cluster comum;
muitos pequenos grupos altamente especializados;
um cluster para cada aplicativo;
um cluster para cada ambiente.

Como mostrado abaixo, as duas primeiras abordagens estão nas extremidades opostas da escala de opções:

de vários clusters grandes (à esquerda) a muitos pequenos (à direita)

Em geral, um cluster é considerado "maior" que o outro se tiver uma quantidade maior de nós e pods. Por exemplo, um cluster com 10 nós e 100 pods é maior que um cluster com 1 nó e 10 pods.

Bem, vamos começar!

1. Um cluster comum grande

A primeira opção é colocar todas as cargas de trabalho em um cluster:

Um cluster grande

Como parte dessa abordagem, o cluster é usado como uma plataforma de infraestrutura universal - basta implantar tudo o que você precisa em um cluster Kubernetes existente.

Namespace'y Kubernetes permite separar logicamente parte do cluster uma da outra, para que seu espaço de nome possa ser usado para cada instância do aplicativo.

Vamos dar uma olhada nos prós e contras dessa abordagem.

+ Uso eficiente de recursos

No caso de um único cluster, apenas uma cópia de todos os recursos necessários para iniciar e gerenciar o cluster Kubernetes é necessária.

Por exemplo, isso é verdade para nós principais. Geralmente, existem 3 nós principais para cada cluster do Kubernetes; portanto, para um único cluster, seu número permanecerá assim (para comparação, 10 clusters precisarão de 30 nós principais).

A sutileza acima se aplica a outros serviços que operam em escala de cluster, como balanceadores de carga, controladores do Ingress, autenticação, sistemas de log e monitoramento.

Em um único cluster, todos esses serviços podem ser usados imediatamente para todas as cargas de trabalho (não é necessário criar cópias deles, como no caso de vários clusters).

+ Barato

Como conseqüência do exposto, um número menor de clusters geralmente é mais barato porque não há custos para o excesso de recursos.

Isso é especialmente verdadeiro para nós principais, que podem custar dinheiro significativo, independentemente do método de posicionamento (local ou na nuvem).

Alguns serviços gerenciados do Kubernetes, como o Google Kubernetes Engine (GKE) ou o Azure Kubernetes Service (AKS) , fornecem uma camada de controle gratuitamente. Nesse caso, a questão dos custos é menos aguda.

Também existem serviços gerenciados que cobram uma taxa fixa por cada cluster do Kubernetes (por exemplo, Amazon Elastic Kubernetes Service, EKS ).

+ Administração eficaz

Gerenciar um único cluster é mais fácil do que vários.

A administração pode incluir as seguintes tarefas:

atualize a versão do Kubernetes;
Configuração de pipeline de CI / CD
Instalação de plugin CNI;
configurar um sistema de autenticação de usuário;
configuração do controlador de acesso;

e muitos outros ...

No caso de um cluster, tudo isso terá que ser feito apenas uma vez.

Para muitos clusters, as operações terão que ser repetidas várias vezes, o que provavelmente exigirá alguma automação de processos e ferramentas para garantir um processo sistemático e uniforme.

E agora algumas palavras sobre os contras.

- Ponto unico de falha

No caso de uma falha de cluster único , todas as cargas de trabalho param de funcionar imediatamente !

Existem inúmeras opções quando algo pode dar errado:

atualizar o Kubernetes leva a efeitos colaterais inesperados;
o componente de todo o cluster (por exemplo, o plugin CNI) não funciona conforme o esperado;
Um dos componentes do cluster não está configurado corretamente.
uma falha na infraestrutura subjacente.

Um desses incidentes pode causar sérios danos a todas as cargas de trabalho localizadas em um cluster comum.

- Falta de isolamento rígido

Trabalhar em um cluster compartilhado significa que os aplicativos compartilham hardware, recursos de rede e o sistema operacional nos nós do cluster.

De certa forma, dois contêineres com dois aplicativos diferentes em execução no mesmo host são semelhantes a dois processos em execução na mesma máquina executando o mesmo kernel do sistema operacional.

Os contêineres Linux fornecem alguma forma de isolamento, mas está longe de ser tão forte quanto o fornecido por, digamos, máquinas virtuais. Em essência, um processo em um contêiner é o mesmo processo em execução no sistema operacional host.

Isso pode ser um problema de segurança: uma organização como essa permite teoricamente que aplicativos não relacionados interajam (intencionalmente ou acidentalmente).

Além disso, todas as cargas de trabalho no cluster Kubernetes compartilham alguns serviços em todo o cluster, como o DNS - isso permite que os aplicativos encontrem os Serviços de outros aplicativos no cluster.

Todos os itens acima podem ter significados diferentes, dependendo dos requisitos de segurança do aplicativo.

O Kubernetes fornece várias ferramentas para evitar problemas de segurança, como PodSecurityPolicies e NetworkPolicies . No entanto, para que sua configuração adequada exija alguma experiência, eles não conseguem fechar absolutamente todas as falhas de segurança.

É importante lembrar sempre que o Kubernetes foi originalmente projetado para compartilhamento.e não para isolamento e segurança .

- Falta de multilocação apertada

Dada a abundância de recursos compartilhados no cluster Kubernetes, há muitas maneiras pelas quais aplicativos diferentes podem "atingir os outros".

Por exemplo, um aplicativo pode monopolizar algum recurso compartilhado (como um processador ou memória) e privar outros aplicativos em execução no mesmo nó de acesso a ele.

O Kubernetes fornece vários mecanismos para controlar esse comportamento, como solicitações e limites de recursos (consulte também o artigo “ Limites de CPU e limitação agressiva no Kubernetes ” - aprox. Transl.) , ResourceQuotas e LimitRanges . No entanto, como no caso da segurança, sua configuração é bastante trivial e eles não são capazes de impedir absolutamente todos os efeitos colaterais imprevistos.

- Um grande número de usuários

No caso de um único cluster, muitas pessoas precisam abrir o acesso a ele. E quanto maior seu número, maior o risco de que eles “quebrem alguma coisa”.

Dentro do cluster, você pode controlar quem e o que pode ser feito usando o controle de acesso baseado em função (RBAC) (consulte o artigo “ Usuários e autorização RBAC no Kubernetes ” - aproximadamente transferência ) . No entanto, isso não impedirá que os usuários “quebrem” algo dentro dos limites de sua área de responsabilidade.

- Clusters não podem crescer indefinidamente

O cluster usado para todas as cargas de trabalho provavelmente será bastante grande (em termos de número de nós e pods).

Mas aqui surge outro problema: os agrupamentos em Kubernetes não podem crescer indefinidamente.

Há um limite teórico no tamanho do cluster. Na Kubernetes, são aproximadamente 5.000 nós, 150 mil pods e 300 mil contêineres .

No entanto, na vida real, os problemas podem começar muito mais cedo - por exemplo, em apenas 500 nós .

O fato é que grandes clusters exercem uma alta carga na camada de controle do Kubernetes. Em outras palavras, para manter o cluster operacional e usar eficientemente os recursos, é necessário um ajuste cuidadoso.

Esta edição é explorada em um artigo relacionado no blog original intitulado " Arquitetura de clusters do Kubernetes - escolhendo o tamanho do nó do trabalhador ".

Mas vamos olhar para a abordagem oposta: muitos pequenos grupos.

2. Muitos pequenos grupos especializados

Com essa abordagem, você usa um cluster separado para cada elemento implantado:

Muitos pequenos clusters

Para os fins deste artigo, um elemento implantado refere-se a uma instância de um aplicativo - por exemplo, a versão dev de um aplicativo separado.

Essa estratégia usa o Kubernetes como um tempo de execução especializado para instâncias de aplicativos individuais.

Vamos dar uma olhada nos prós e contras dessa abordagem.

+ "Raio de explosão" limitado

Quando um cluster quebra, as consequências negativas são limitadas apenas às cargas de trabalho que foram implantadas nesse cluster. Todas as outras cargas de trabalho permanecem intactas.

+ Isolação

As cargas de trabalho hospedadas em clusters individuais não compartilham recursos como processador, memória, sistema operacional, rede ou outros serviços.

Como resultado, temos um isolamento rígido entre aplicativos não relacionados, o que pode afetar favoravelmente sua segurança.

+ Pequeno número de usuários

Como cada cluster contém apenas um conjunto limitado de cargas de trabalho, o número de usuários com acesso a ele é reduzido.

Quanto menos pessoas tiverem acesso ao cluster, menor o risco de algo "quebrar".

Vamos olhar para os contras.

- Uso ineficiente de recursos

Como mencionado anteriormente, cada cluster Kubernetes requer um certo conjunto de recursos de controle: nós principais, componentes da camada de controle, soluções para monitoramento e registro.

No caso de um grande número de pequenos clusters, é necessário alocar uma parcela maior de recursos para o gerenciamento.

- Alto custo

O uso ineficiente de recursos implica automaticamente altos custos.

Por exemplo, a manutenção de 30 nós principais em vez de três com o mesmo poder de computação afetará necessariamente os custos.

- dificuldades de administração

Gerenciar vários clusters do Kubernetes é muito mais difícil do que gerenciar um.

Por exemplo, você precisará configurar a autenticação e a autorização para cada cluster. A atualização da versão do Kubernetes também precisará ser feita várias vezes.

Provavelmente, você precisará aplicar a automação para aumentar a eficácia de todas essas tarefas.

Agora considere cenários menos extremos.

3. Um cluster por aplicativo

Como parte dessa abordagem, você cria um cluster separado para todas as instâncias de um aplicativo específico:

Cluster por aplicativo

Dessa maneira, pode ser considerada uma generalização do princípio de “ cluster separado por equipe ”, pois geralmente uma equipe de engenheiros está envolvida no desenvolvimento de um ou mais aplicativos.

Vamos dar uma olhada nos prós e contras dessa abordagem.

+ O cluster pode ser personalizado para o aplicativo

Se o aplicativo tiver necessidades especiais, ele poderá ser implementado em um cluster sem afetar outros clusters.

Essas necessidades podem incluir trabalhadores da GPU, plugins CNI específicos, malha de serviço ou algum outro serviço.

Cada cluster pode ser adaptado para o aplicativo em execução nele, para que ele contenha apenas o necessário.

- Diferentes ambientes em um cluster

A desvantagem dessa abordagem é que instâncias de aplicativos de diferentes ambientes coexistem no mesmo cluster.

Por exemplo, a versão prod do aplicativo é executada no mesmo cluster que a versão dev. Isso também significa que os desenvolvedores realizam suas atividades no mesmo cluster em que a versão de produção do aplicativo é operada.

Se, devido às ações dos desenvolvedores ou falhas da versão do desenvolvedor no cluster, ocorrer uma falha, a versão do produto poderá sofrer - uma enorme desvantagem dessa abordagem.

E, finalmente, o último script da nossa lista.

4. Um cluster para cada ambiente

Este cenário prevê a atribuição de um cluster separado para cada ambiente:

um cluster para o meio ambiente

Por exemplo, você pode ter dev , teste e prod aglomerados em que você vai correr todas as instâncias de aplicativos projetados para um ambiente específico.

Aqui estão os prós e contras dessa abordagem.

+ Isolamento do ambiente prod

Nesta abordagem, todos os ambientes são isolados um do outro. No entanto, na prática, isso é especialmente importante para o ambiente de prod.

As versões de produção do aplicativo agora são independentes do que está acontecendo em outros clusters e ambientes.

Portanto, se um problema surgir repentinamente no cluster de desenvolvimento, as versões de prod dos aplicativos continuarão funcionando como se nada tivesse acontecido.

+ O cluster pode ser ajustado ao ambiente

Cada cluster pode ser adaptado ao seu ambiente. Por exemplo, você pode:

instalar ferramentas de desenvolvimento e depuração no cluster de desenvolvimento;
instalar estruturas e ferramentas de teste no cluster de teste ;
Use mais poderosos canais de equipamentos de rede e na prod conjunto .

Isso permite aumentar a eficiência do desenvolvimento e da operação de aplicativos.

+ Restringir o acesso ao cluster de produção

A necessidade de trabalhar com um cluster de produtos surge com pouca frequência, para que você possa limitar significativamente o círculo de pessoas que têm acesso a ele.

Você pode ir ainda mais longe e geralmente privar as pessoas de acesso a esse cluster e executar todas as implantações usando a ferramenta CI / CD automatizada. Essa abordagem minimizará o risco de erro humano exatamente onde é mais relevante.

E agora algumas palavras sobre os contras.

- Falta de isolamento entre aplicativos

A principal desvantagem da abordagem é a falta de isolamento de hardware e recursos entre aplicativos.

Aplicativos não relacionados compartilham recursos de cluster: o núcleo do sistema, o processador, a memória e alguns outros serviços.

Como já mencionado, isso pode ser potencialmente perigoso.

- Incapacidade de localizar dependências de aplicativos

Se o aplicativo tiver requisitos especiais, eles deverão ser satisfeitos em todos os clusters.

Por exemplo, se um aplicativo precisar de uma GPU, cada cluster deverá conter pelo menos um trabalhador com uma GPU (mesmo que seja usado apenas por esse aplicativo).

Como resultado, corremos o risco de custos mais altos e uso ineficiente de recursos.

Conclusão

Se você tiver um conjunto específico de aplicativos, poderá colocá-los em vários clusters grandes ou em muitos pequenos.

O artigo discute os prós e contras de várias abordagens, variando de um cluster global a vários pequenos e altamente especializados:

um grande cluster comum;
muitos pequenos grupos altamente especializados;
um cluster para cada aplicativo;
um cluster para cada ambiente.

Então, qual abordagem escolher?

Como sempre, a resposta depende do caso de uso: você precisa avaliar os prós e os contras de diferentes abordagens e escolher a opção mais ideal.

No entanto, a escolha não se limita aos exemplos acima - você pode usar qualquer combinação deles!

Por exemplo, você pode organizar um par de clusters por equipe: um cluster para o desenvolvimento (que terá dev e teste ambientes ) e um cluster de produção (onde o ambiente de produção será localizado).

Com base nas informações deste artigo, você pode otimizar os prós e os contras de acordo com um cenário específico. Boa sorte

Projetando Clusters Kubernetes: Quantos Devem Ser?