Ao criar um cluster Kubernetes, podem surgir questões: quantos nós de trabalho configurar e que tipo? O que é melhor para um cluster on-premise: comprar alguns servidores poderosos ou utilizar uma dezena de máquinas antigas no seu data center? E na nuvem, é melhor optar por oito instâncias de um núcleo ou duas instâncias de quatro núcleos?
As respostas para essas perguntas estão no artigo na tradução da equipe .
Capacidade do cluster
De modo geral, um cluster Kubernetes pode ser visto como um grande "super nó". Sua capacidade computacional total é a soma das capacidades de todos os nós que o compõem.
Existem várias maneiras de alcançar a capacidade desejada do cluster. Por exemplo, precisamos de um cluster com uma capacidade total de 8 núcleos de CPU e 32 GB de RAM, porque o conjunto de aplicativos requer essa quantidade de recursos. Então, podemos configurar dois nós com 16 GB de RAM ou quatro nós com 8 GB de RAM, dois processadores quad-core ou quatro dual-core.
Aqui estão apenas duas possíveis maneiras de criar um cluster:
Ambas as opções resultam em um cluster com a mesma capacidade, mas na configuração inferior estão quatro nós menores, enquanto na configuração superior estão dois nós maiores.
Qual opção é melhor?
Para responder a essa pergunta, vamos considerar as vantagens de ambas as opções. Compilamos em uma tabela.
Vários grandes nós
Muitos pequenos nós
Gerenciamento mais simples do cluster (se for on-premise)
Autoescalonamento suave
Mais barato (se for on-premise)
O preço é quase o mesmo (na nuvem)
É possível rodar aplicativos que consomem muitos recursos
Replicação completa
Os recursos são utilizados de forma mais eficiente (menor sobrecarga em demônios de sistema)
Maior resiliência do cluster
Observe que estamos falando apenas sobre nós de trabalho. A escolha da quantidade e do tamanho dos nós principais é um assunto completamente diferente.
Então, vamos discutir em detalhes cada ponto da tabela.
Primeira opção: vários grandes nós
A opção mais extrema é ter um único nó de trabalho para toda a capacidade do cluster. No exemplo acima, isso seria um nó de trabalho com 16 núcleos de CPU e 16 GB de RAM.
Prós
Ponto positivo nº 1. Gerenciamento mais fácil
É mais fácil gerenciar várias máquinas do que um parque inteiro. É mais rápido aplicar atualizações e correções, e mais simples sincronizar. O número de falhas em números absolutos também é menor.
Observe que tudo o que foi dito se refere ao seu próprio hardware, seus próprios servidores, e não a instâncias em nuvem.
Na nuvem, a situação é diferente. A gestão é realizada pelo provedor de serviços em nuvem. Assim, administrar dez nós na nuvem não é muito diferente de administrar um único nó.
O roteamento de tráfego e a distribuição de carga entre pods na nuvem : o tráfego vindo da internet é direcionado para o balanceador de carga principal, que encaminha o tráfego para a porta de um dos nós (o serviço NodePort expõe uma porta na faixa de 30000-32767 em cada nó do cluster). As regras estabelecidas pelo kube-proxy redirecionam o tráfego do nó para o pod. Veja como isso fica para dez pods em dois nós:
Princípio nº 2. Menor custo por nó
Uma máquina poderosa é mais cara, mas o aumento de preço não é necessariamente linear. Em outras palavras, um servidor de dez núcleos com 10 GB de memória geralmente custa menos do que dez servidores de um núcleo com a mesma quantidade de memória.
Mas note que essa regra geralmente não se aplica a serviços em nuvem. Nos modelos de precificação atuais, todos os principais provedores de serviços em nuvem aumentam os preços de forma linear com a capacidade.
Portanto, na nuvem, geralmente não é possível economizar em servidores mais potentes.
Princípio nº 3. É possível rodar aplicações que consomem muitos recursos
Algumas aplicações exigem servidores potentes em um cluster. Por exemplo, se um sistema de aprendizado de máquina precisa de 8 GB de memória, você não conseguirá executá-lo em nós com 1 GB, apenas se houver pelo menos um nó de trabalho grande.
Desvantagens
Princípio nº 1. Muitos pods por nó
Se a mesma tarefa é executada em um número menor de nós, haverá naturalmente mais pods em cada um deles.
Isso pode se tornar um problema.
A razão é que cada módulo gera alguma sobrecarga no ambiente de execução do container (por exemplo, Docker), assim como no kubelet e no cAdvisor.
Por exemplo, o kubelet monitora regularmente a vivacidade de todos os containers no nó — quanto mais containers, mais trabalho para o kubelet.
O CAdvisor coleta estatísticas de uso de recursos de todos os containers no nó, enquanto o kubelet solicita regularmente essas informações e as disponibiliza através da API. Novamente, quanto mais containers houver, mais trabalho haverá para o cAdvisor e para o kubelet.
Se o número de módulos aumentar, isso pode desacelerar o sistema e até comprometer sua confiabilidade.
No repositório do Kubernetes, alguns , que os nós estão alternando entre os status Pronto/Não Pronto, uma vez que as verificações regulares do kubelet em todos os containers do nó consomem muito tempo.
Por esse motivo, o Kubernetes . Dependendo do desempenho do nó, você pode executar mais pods por nó, mas é difícil prever se surgirão problemas ou se tudo funcionará bem. É recomendável testar a operação previamente.
Desvantagem nº 2. Limitação na replicação
Um número muito pequeno de nós limita a eficácia da replicação de aplicativos. Por exemplo, se você tem um aplicativo de alta disponibilidade com cinco réplicas, mas apenas dois nós, a eficácia da replicação do aplicativo reduz para duas.
As cinco réplicas só podem ser distribuídas em dois nós, e se um deles falhar, isso imediatamente derruba várias réplicas.
Se você tiver cinco nós ou mais, cada réplica será executada em um nó separado, e a falha de um nó eliminará não mais do que uma réplica.
Portanto, os requisitos de alta disponibilidade podem exigir um número mínimo específico de nós no cluster.
Desvantagem nº 3. Consequências mais severas da falha
Com um número pequeno de nós, cada falha tem consequências mais sérias. Por exemplo, se você tiver apenas dois nós e um deles falhar, imediatamente metade de seus módulos desaparece.
Claro, o Kubernetes moverá a carga de trabalho do nó com falha para outros. Mas se houver poucos, pode não haver capacidade livre suficiente. Como resultado, parte de seus aplicativos ficará indisponível até que você recupere o nó com falha.
Assim, quanto mais nós houver, menor será o impacto das falhas de hardware.
Desvantagem nº 4. Mais passos para autoescalonamento
No Kubernetes, existe um sistema de dimensionamento automático de clusters para infraestrutura em nuvem, que permite adicionar ou remover nós automaticamente de acordo com as necessidades atuais. Com grandes nós, o dimensionamento torna-se mais abrupto e desajeitado. Por exemplo, em dois nós, adicionar um nó extra aumentará a capacidade do cluster em 50% de imediato. E você terá que pagar por esses recursos, mesmo que não os precise.
Assim, se você planeja utilizar o dimensionamento automático do cluster, quanto menores os nós, mais flexível e econômico será o dimensionamento que você obterá.
Agora vamos considerar as vantagens e desvantagens de ter muitos nós pequenos.
Segunda opção: muitos nós pequenos
As vantagens dessa abordagem decorrem essencialmente das desvantagens da opção oposta com poucos nós grandes.
Prós
Pró: Menores consequências de falha
Quanto mais nós houver, menos pods haverá em cada nó. Por exemplo, se você tiver cem módulos em dez nós, haverá uma média de dez módulos em cada nó.
Assim, se um dos nós falhar, você perde apenas 10% da carga de trabalho. Há a probabilidade de que apenas um pequeno número de réplicas seja afetado e que os aplicativos, em geral, permaneçam operacionais.
Além disso, nos nós restantes, provavelmente haverá recursos livres suficientes para a carga de trabalho do nó com falha, permitindo que o Kubernetes reatribua livremente os pods e que seus aplicativos retornem ao estado funcional relativamente rápido.
Pró: Boa replicação
Se houver nós suficientes, o planejador Kubernetes pode designar diferentes nós para todas as réplicas. Assim, em caso de falha de um nó, apenas uma réplica será afetada e o aplicativo permanecerá disponível.
Desvantagens
Contras: Mais difícil de gerenciar
Gerenciar um grande número de nós é mais complicado. Por exemplo, cada nó Kubernetes deve interagir com todos os outros, o que significa que o número de conexões cresce quadraticamente, e todas essas conexões precisam ser monitoradas.
O controlador de nós no gerenciador de controladores Kubernetes verifica regularmente todos os nós no cluster para verificar a integridade - quanto mais nós houver, maior será a carga no controlador.
A carga no banco de dados etcd também aumenta - cada kubelet e kube-proxy faz chamadas ao para etcd (através da API), que etcd deve transmitir atualizações de objeto.
No geral, cada nó de trabalho impõe uma carga adicional aos componentes do sistema dos nós principais.
Oficialmente, o Kubernetes suporta clusters com No entanto, na prática, já 500 nós .
Para gerenciar um grande número de nós de trabalho, deve-se escolher nós principais mais potentes. Por exemplo, o kube-up o tamanho correto da VM para o nó principal, dependendo do número de nós de trabalho. Ou seja, quanto mais nós de trabalho, mais potentes devem ser os nós principais.
Para resolver esses problemas específicos, existem desenvolvimentos especializados, como Esse sistema permite contornar as limitações e construir clusters com um enorme número de nós de trabalho.
Desvantagem nº 2: Mais sobrecarga.
Em cada nó de trabalho, o Kubernetes executa um conjunto de demônios do sistema — incluindo o ambiente de execução de contêiner (como Docker), kube-proxy e kubelet, incluindo cAdvisor. Todos juntos consomem uma quantidade fixa de recursos.
Se você tiver muitos nós pequenos, a parte dessa sobrecarga em cada nó é maior. Por exemplo, imagine que todos os demônios de sistema de um nó consomem juntos 0,1 núcleos de CPU e 0,1 GB de memória. Se você tiver um nó de dez núcleos com 10 GB de memória, os demônios consomem 1% da capacidade do cluster. Por outro lado, em dez nós de um núcleo com 1 GB de memória, os demônios levarão 10% da capacidade do cluster.
Assim, quanto menos nós, mais eficiente é o uso da infraestrutura.
Desvantagem nº 3: Uso ineficiente de recursos.
Em nós pequenos, pode ocorrer a situação em que os fragmentos restantes de recursos são muito pequenos para serem atribuídos a qualquer carga de trabalho, portanto, permanecem não utilizados.
Por exemplo, cada pod requer 0,75 GB de memória. Se você tiver dez nós, e em cada um deles 1 GB de memória, pode executar dez pods — no final, em cada nó restará 0,25 GB de memória não utilizada.
Isso significa que 25% da memória de todo o cluster está sendo desperdiçada.
Em um grande nó com 10 GB de memória, você pode executar 13 desses módulos — e sobrará apenas um fragmento não utilizado de 0,25 GB.
Nesse caso, apenas 2,5% da memória é desperdiçada.
Dessa forma, os recursos são utilizados de maneira mais eficiente em grandes nós.
Vários grandes nós ou muitos pequenos?
Então, o que é melhor: vários grandes nós em um cluster ou muitos pequenos? Como sempre, não há uma resposta definitiva. Muito depende do tipo de aplicação.
Por exemplo, se a aplicação requer 10 GB de memória, a escolha clara é a favor dos grandes nós. E se a aplicação exige replicação dez vezes para alta disponibilidade, é arriscado colocar réplicas apenas em dois nós — o cluster deve ter no mínimo dez nós.
Em situações intermediárias, faça sua escolha com base nas vantagens e desvantagens de cada opção. É possível que alguns argumentos sejam mais relevantes para a sua situação do que outros.
E não é necessário que todos os nós tenham o mesmo tamanho. Não há nada que impeça você de começar experimentando com nós de um mesmo tamanho e, em seguida, adicionar nós de tamanhos diferentes, combinando-os no cluster. Os nós de trabalho do cluster Kubernetes podem ser totalmente heterogêneos. Assim, você pode tentar combinar as vantagens de ambas as abordagens.
Não existe uma receita única, e cada situação possui suas nuances, que só a produção revelará a verdade.
A tradução foi preparada pela equipe da plataforma de nuvem .
Mais sobre Kubernetes: .
Fonte: habr.com
