Observação. trad.: este material é de um projeto educacional é a resposta a uma pergunta popular ao projetar uma infraestrutura baseada em Kubernetes. Esperamos que descrições bastante detalhadas dos prós e contras de cada opção ajudem você 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 clusters pequenos (com um pequeno número de cargas em cada cluster).
Abaixo está uma tabela que avalia os prós e os contras de cada abordagem:
Ao usar o Kubernetes como plataforma para executar aplicativos, muitas vezes surgem várias questões fundamentais sobre as complexidades da configuração de clusters:
- Quantos clusters devo usar?
- Quão grande devo torná-los?
- O que cada cluster deve incluir?
Neste artigo, tentarei responder a todas essas questões analisando os prós e os contras de cada abordagem.
Declaração de uma pergunta
Como desenvolvedor de software, você provavelmente desenvolve e opera muitos aplicativos ao mesmo tempo.
Além disso, muitas instâncias desses aplicativos provavelmente serão executadas em ambientes diferentes - por exemplo, podem ser dev, teste и estímulo.
O resultado é toda uma matriz de aplicações e ambientes:
Aplicações e Ambientes
O exemplo acima representa 3 aplicações e 3 ambientes, resultando num total de 9 opções possíveis.
Cada instância de aplicativo é uma unidade de implantação independente que pode ser trabalhada independentemente de outras.
Note-se que instância do aplicativo pode consistir em muitos componentes, como frontend, backend, banco de dados, etc. No caso de uma aplicação de microsserviços, a instância incluirá todos os microsserviços.
Como resultado, os usuários do Kubernetes têm várias dúvidas:
- Todas as instâncias de aplicativos devem ser colocadas em um cluster?
- Vale a pena ter um cluster separado para cada instância de aplicação?
- Ou talvez uma combinação das abordagens acima deva ser usada?
Todas essas opções são bastante viáveis, já que o Kubernetes é um sistema flexível que não limita as capacidades do usuário.
Aqui estão algumas das maneiras possíveis:
- um grande cluster comum;
- muitos pequenos clusters altamente especializados;
- um cluster por aplicação;
- um cluster por ambiente.
Conforme mostrado abaixo, as duas primeiras abordagens estão em extremos opostos da escala de opções:
De alguns clusters grandes (esquerda) a muitos pequenos (direita)
Em geral, um cluster é considerado “maior” que outro se possuir uma soma 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 grande cluster comum
A primeira opção é colocar todas as cargas de trabalho em um cluster:
Um grande aglomerado
Dentro desta abordagem, o cluster é usado como um plataforma de infraestrutura — você simplesmente implanta tudo o que precisa em um cluster Kubernetes existente.
O Kubernetes permite que partes do cluster sejam separadas logicamente umas das outras, para que cada instância do aplicativo possa ter seu próprio namespace.
Vejamos os prós e os contras dessa abordagem.
+ Uso eficiente de recursos
Com um único cluster, você só precisa de uma cópia de todos os recursos necessários para executar e gerenciar o cluster Kubernetes.
Por exemplo, isso é verdade para nós mestres. Normalmente, cada cluster Kubernetes tem 3 nós mestres, portanto, para um único cluster, seu número permanecerá assim (para comparação, 10 clusters precisarão de 30 nós mestres).
A sutileza acima também se aplica a outros serviços que operam em todo o cluster, como balanceadores de carga, controladores Ingress, sistemas de autenticação, registro e monitoramento.
Em um único cluster, todos esses serviços podem ser usados de uma só vez para todas as cargas de trabalho (não há necessidade de criar cópias deles, como é o caso de vários clusters).
+ Barato
Como consequência do acima exposto, menos clusters são geralmente mais baratos porque não há custos indiretos.
Isto é especialmente verdadeiro para nós mestres, que podem custar uma quantia significativa de dinheiro, independentemente de como estão hospedados (no local ou na nuvem).
Alguns serviços gerenciados do Kubernetes, como ou , forneça a camada de controle gratuitamente. Neste caso, a questão do custo é menos aguda.
Existem também serviços gerenciados que cobram uma taxa fixa pela operação de cada cluster Kubernetes (por exemplo, ).
+ Administração eficiente
Gerenciar um cluster é mais fácil do que gerenciar vários.
A administração pode incluir as seguintes tarefas:
- Atualização de versão do Kubernetes;
- configurar um pipeline de CI/CD;
- instalando o plugin CNI;
- configurar um sistema de autenticação de usuário;
- instalação de controlador de acesso;
e muitos outros…
No caso de um cluster, você terá que fazer tudo isso apenas uma vez.
Para muitos clusters, as operações terão que ser repetidas muitas vezes, o que provavelmente exigirá alguma automação de processos e ferramentas para garantir consistência e consistência no processo.
E agora algumas palavras sobre os contras.
− Ponto único de falha
Em caso de recusa o único o cluster irá parar de funcionar imediatamente todos cargas de trabalho!
Há muitas maneiras pelas quais as coisas podem dar errado:
- atualizar o Kubernetes leva a efeitos colaterais inesperados;
- Um componente de todo o cluster (por exemplo, um plugin CNI) começa a não funcionar conforme o esperado;
- um dos componentes do cluster não está configurado corretamente;
- falha na infra-estrutura subjacente.
Um desses incidentes pode causar sérios danos a todas as cargas de trabalho hospedadas em um cluster compartilhado.
− Sem isolamento rígido
A execução em um cluster compartilhado significa que os aplicativos compartilham o hardware, os recursos de rede e o sistema operacional nos nós do cluster.
De certa forma, dois contêineres com dois aplicativos diferentes rodando no mesmo nó são como dois processos rodando na mesma máquina rodando o mesmo kernel do sistema operacional.
Os contêineres Linux fornecem alguma forma de isolamento, mas não é 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.
Isto pode ser um problema de segurança: este arranjo permite, teoricamente, que aplicações não relacionadas se comuniquem entre si (intencionalmente ou acidentalmente).
Além disso, todas as cargas de trabalho em um cluster Kubernetes compartilham alguns serviços de todo o cluster, como - isso permite que os aplicativos encontrem serviços de outros aplicativos no cluster.
Todos os pontos acima podem ter significados diferentes dependendo dos requisitos de segurança da aplicação.
Kubernetes fornece várias ferramentas para evitar problemas de segurança, como и . No entanto, configurá-los corretamente requer alguma experiência; além disso, eles não são capazes de fechar absolutamente todas as falhas de segurança.
É importante sempre lembrar que o Kubernetes foi originalmente projetado para compartilhamento, não para isolamento e segurança.
− Falta de multilocação estrita
Dada a abundância de recursos compartilhados em um cluster Kubernetes, há muitas maneiras pelas quais diferentes aplicativos podem interferir uns nos outros.
Por exemplo, um aplicativo pode monopolizar um recurso compartilhado (como CPU ou memória) e negar acesso a ele a outros aplicativos em execução no mesmo nó.
O Kubernetes fornece vários mecanismos para controlar esse comportamento, como (veja também o artigo “"- Aproximadamente. trad.), и . No entanto, como no caso da segurança, a sua configuração não é trivial e não é capaz de evitar absolutamente todos os efeitos secundários imprevistos.
− Grande número de usuários
No caso de um único cluster, é necessário abrir o acesso a ele para muitas pessoas. E quanto maior o seu número, maior o risco de “quebrarem” alguma coisa.
Dentro do cluster você pode controlar quem pode fazer o quê usando (ver artigo “"- Aproximadamente. trad.). No entanto, isso não impedirá que os usuários “quebrem” algo dentro dos limites de sua área de responsabilidade.
− Os 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 clusters no Kubernetes não podem crescer indefinidamente.
Existe um limite teórico para o tamanho do cluster. No Kubernetes é aproximadamente .
Contudo, na vida real, os problemas podem começar muito mais cedo - por exemplo, apenas com .
O fato é que grandes clusters colocam uma carga elevada na camada de controle do Kubernetes. Em outras palavras, manter o cluster funcionando com eficiência requer um ajuste cuidadoso.
Esse problema é explorado em um artigo relacionado no blog original chamado "".
Mas vamos considerar a abordagem oposta: muitos pequenos clusters.
2. Muitos clusters pequenos e especializados
Com essa abordagem, você usa um cluster separado para cada elemento implantado:
Muitos pequenos clusters
Para os fins deste artigo, sob elemento implantável refere-se a uma instância de um aplicativo - por exemplo, uma versão de desenvolvimento de um aplicativo separado.
Esta estratégia usa Kubernetes como uma ferramenta especializada tempo de execução para instâncias de aplicativos individuais.
Vejamos os prós e os contras dessa abordagem.
+ “Raio de explosão” limitado
Quando um cluster falha, as consequências negativas são limitadas apenas às cargas de trabalho que foram implementadas nesse cluster. Todas as outras cargas de trabalho permanecem intactas.
+ Isolamento
As cargas de trabalho hospedadas em clusters individuais não compartilham recursos como processador, memória, sistema operacional, rede ou outros serviços.
O resultado é um isolamento rígido entre aplicativos não relacionados, o que pode ser benéfico para sua segurança.
+ Pequeno número de usuários
Dado que cada cluster contém apenas um conjunto limitado de cargas de trabalho, o número de utilizadores com acesso ao mesmo é reduzido.
Quanto menos pessoas tiverem acesso ao cluster, menor será o risco de algo “quebrar”.
Vejamos os contras.
− Uso ineficiente de recursos
Conforme mencionado anteriormente, cada cluster Kubernetes requer um conjunto específico de recursos de gerenciamento: nós mestres, componentes da camada de controle, soluções de monitoramento e registro.
No caso de um grande número de pequenos clusters, uma parcela maior de recursos deve ser alocada à gestão.
− Caro
A utilização ineficiente de recursos implica automaticamente custos elevados.
Por exemplo, manter 30 nós mestres em vez de três com o mesmo poder computacional afetará necessariamente os custos.
− Dificuldades na administração
Gerenciar vários clusters Kubernetes é muito mais difícil do que gerenciar apenas um.
Por exemplo, você terá que configurar a autenticação e autorização para cada cluster. A versão do Kubernetes também deverá ser atualizada diversas vezes.
Provavelmente, você precisará usar a automação para tornar todas essas tarefas mais eficientes.
Agora vamos examinar cenários menos extremos.
3. Um cluster por aplicação
Nesta abordagem, você cria um cluster separado para todas as instâncias de um aplicativo específico:
Cluster por aplicativo
Este caminho pode ser considerado como uma generalização do princípio “cluster separado por equipe”, já que normalmente uma equipe de engenheiros desenvolve uma ou mais aplicações.
Vejamos os prós e os contras dessa abordagem.
+ O cluster pode ser ajustado à aplicação
Se uma aplicação tiver necessidades especiais, elas poderão ser implementadas em um cluster sem afetar outros clusters.
Essas necessidades podem incluir trabalhadores de GPU, certos plug-ins CNI, uma malha de serviço ou algum outro serviço.
Cada cluster pode ser adaptado ao aplicativo em execução nele, para que contenha apenas o que é necessário.
− Diferentes ambientes em um cluster
A desvantagem dessa abordagem é que instâncias de aplicativos de ambientes diferentes 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 operam no mesmo cluster em que a versão de produção do aplicativo é operada.
Se, devido às ações dos desenvolvedores ou falhas na versão de desenvolvimento, ocorrer uma falha no cluster, a versão de produção também poderá sofrer - uma grande desvantagem dessa abordagem.
E por fim, o último cenário da nossa lista.
4. Um cluster por ambiente
Este cenário envolve a alocação de um cluster separado para cada ambiente:
Um cluster por ambiente
Por exemplo, você pode ter clusters dev, teste и estímulo, no qual você executará todas as instâncias do aplicativo dedicadas a um ambiente específico.
Aqui estão os prós e os contras dessa abordagem.
+ Isolamento do ambiente de produção
Dentro desta abordagem, todos os ambientes são isolados uns dos outros. No entanto, na prática, isso é especialmente importante em um ambiente de produção.
As versões de produção do aplicativo agora são independentes do que está acontecendo em outros clusters e ambientes.
Dessa forma, se surgir um problema repentino no cluster de desenvolvimento, as versões de produção dos aplicativos continuarão funcionando como se nada tivesse acontecido.
+ O cluster pode ser ajustado ao ambiente
Cada cluster pode ser ajustado ao seu ambiente. Por exemplo, você pode:
- instalar ferramentas para desenvolvimento e depuração no cluster de desenvolvimento;
- instalar estruturas e ferramentas de teste no cluster teste;
- use hardware e canais de rede mais poderosos no cluster estímulo.
Isso permite aumentar a eficiência do desenvolvimento e da operação de aplicativos.
+ Restringindo o acesso ao cluster de produção
Raramente surge a necessidade de trabalhar diretamente com um cluster de produção, portanto, você pode limitar significativamente o círculo de pessoas que têm acesso a ele.
Você pode ir ainda mais longe e negar totalmente o acesso das pessoas a esse cluster e realizar todas as implantações usando uma ferramenta automatizada de CI/CD. Tal abordagem minimizará o risco de erros humanos exatamente onde é mais relevante.
E agora algumas palavras sobre os contras.
− Sem 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: núcleo do sistema, processador, memória e alguns outros serviços.
Como mencionado, isso pode ser potencialmente perigoso.
− Incapacidade de localizar dependências de aplicativos
Se um aplicativo tiver requisitos especiais, eles deverão ser atendidos em todos os clusters.
Por exemplo, se um aplicativo exigir uma GPU, cada cluster deverá conter pelo menos um trabalhador com GPU (mesmo que seja usado apenas por esse aplicativo).
Como resultado, corremos o risco de custos mais elevados e de utilização ineficiente de recursos.
Conclusão
Se você tiver um conjunto específico de aplicativos, eles poderão ser colocados em vários clusters grandes ou em vários clusters pequenos.
O artigo discute os prós e os contras de diversas abordagens, desde um cluster global até vários clusters pequenos e altamente especializados:
- um grande cluster geral;
- muitos pequenos clusters altamente especializados;
- um cluster por aplicação;
- um cluster por ambiente.
Então, qual abordagem você deve adotar?
Como sempre, a resposta depende do caso de uso: você precisa pesar os prós e os contras das diferentes abordagens e escolher a opção mais adequada.
No entanto, a escolha não se limita aos exemplos acima – você pode usar qualquer combinação deles!
Por exemplo, você pode organizar alguns clusters para cada equipe: um cluster de desenvolvimento (no qual haverá ambientes dev и teste) e cluster para produção (onde ficará localizado o ambiente de produção).
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!
PS
Leia também em nosso blog:
- «";
- «";
- «";
- «".
Fonte: habr.com