Ao criar um cluster Kubernetes, podem surgir dúvidas: quantos nós de trabalho configurar e que tipo? O que é melhor para um cluster local: comprar vários servidores poderosos ou usar uma dúzia de máquinas antigas em seu data center? É melhor usar oito instâncias de núcleo único ou duas instâncias de núcleo quádruplo na nuvem?
As respostas a essas perguntas estão no artigo. na tradução do comando .
Capacidade do cluster
Em geral, um cluster Kubernetes pode ser considerado um grande “supernó”. Seu poder computacional total é a soma dos poderes de todos os seus nós constituintes.
Existem várias maneiras de atingir a meta de capacidade de cluster desejada. Por exemplo, precisamos de um cluster com capacidade total de 8 núcleos de processador e 32 GB de RAM porque um conjunto de aplicativos requer muitos recursos. Então você pode instalar dois nós com 16 GB de memória ou quatro nós com 8 GB de memória, dois processadores quad-core ou quatro dual-core.
Aqui estão apenas duas maneiras possíveis de criar um cluster:
Ambas as opções produzem um cluster com a mesma capacidade, mas a configuração inferior possui quatro nós menores e a configuração superior possui dois nós maiores.
Qual opção é melhor?
Para responder a essa pergunta, vejamos as vantagens de ambas as opções. Nós os resumimos em uma tabela.
Vários nós grandes
Muitos nós pequenos
Gerenciamento de cluster mais fácil (se for local)
Escalonamento automático suave
Mais barato (se estiver no local)
O preço é um pouco diferente (na nuvem)
Pode executar aplicativos que consomem muitos recursos
Replicação completa
Os recursos são usados de forma mais eficiente (menos sobrecarga nos daemons do sistema
Maior tolerância a falhas de cluster
Observe que estamos falando apenas de nós de trabalho. Escolher o número e o tamanho dos nós principais é um tópico completamente diferente.
Então, vamos discutir cada ponto da tabela com mais detalhes.
Primeira opção: vários nós grandes
A opção mais extrema é um nó de trabalho para toda a capacidade do cluster. No exemplo acima, seria um único nó de trabalho com 16 núcleos de CPU e 16 GB de RAM.
Prós
Mais nº 1. Gerenciamento mais fácil
É mais fácil gerenciar algumas máquinas do que uma frota inteira. É mais rápido implementar atualizações e correções e é mais fácil sincronizar. O número de falhas em números absolutos também é menor.
Observe que tudo o que foi dito acima se aplica ao seu hardware, aos seus servidores e não às instâncias da nuvem.
A situação é diferente na nuvem. Lá, o gerenciamento é feito pelo provedor de serviços em nuvem. Assim, gerenciar dez nós na nuvem não é muito diferente de gerenciar um nó.
Roteamento de tráfego e distribuição de carga entre pods na nuvem : o tráfego proveniente da Internet é enviado para o balanceador de carga principal, que encaminha o tráfego para a porta de um dos nós (o serviço NodePort define a porta no intervalo 30000-32767 em cada nó do cluster). As regras definidas pelo kube-proxy redirecionam o tráfego do nó para o pod. Esta é a aparência de dez pods em dois nós:
Pró nº 2: Menos custo por nó
Um carro potente é mais caro, 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 é mais barato do que dez servidores de núcleo único com a mesma quantidade de memória.
Mas observe que esta regra geralmente não funciona em serviços em nuvem. Nos atuais esquemas de preços de todos os principais fornecedores de nuvem, os preços aumentam linearmente com a capacidade.
Assim, na nuvem normalmente você não consegue economizar em servidores mais potentes.
Pró nº 3: você pode executar aplicativos que consomem muitos recursos
Alguns aplicativos exigem servidores poderosos em um cluster. Por exemplo, se um sistema de aprendizado de máquina exigir 8 GB de memória, você não poderá executá-lo em nós de 1 GB, mas apenas com pelo menos um nó de trabalho grande.
Contras
Desvantagem nº 1. Muitos pods por nó
Se a mesma tarefa for executada em menos nós, cada um deles terá naturalmente mais pods.
Isto poderia ser um problema.
O motivo é que cada módulo introduz alguma sobrecarga no tempo de execução do contêiner (por exemplo, Docker), bem como no kubelet e no cAdvisor.
Por exemplo, um kubelet testa regularmente todos os contêineres em um nó quanto à capacidade de sobrevivência – quanto mais contêineres, mais trabalho o kubelet terá de realizar.
O CAdvisor coleta estatísticas de uso de recursos para todos os contêineres em um nó, e o kubelet consulta regularmente essas informações e as fornece por meio de uma API. Novamente, mais contêineres significam mais trabalho para o cAdvisor e o kubelet.
Se o número de módulos aumentar, isso pode tornar o sistema mais lento e até prejudicar sua confiabilidade.
No repositório Kubernetes alguns que os nós saltem entre os status Ready/NotReady porque as verificações regulares do kubelet de todos os contêineres em um nó demoram muito.
Por esta razão, o Kubernetes . Dependendo do desempenho do nó, você pode executar mais pods por nó, mas é difícil prever se haverá problemas ou se tudo funcionará bem. Vale a pena testar o trabalho com antecedência.
Desvantagem nº 2. Limitação na replicação
Poucos nós limitam a extensão efetiva da replicação do aplicativo. Por exemplo, se você tiver um aplicativo de alta disponibilidade com cinco réplicas, mas apenas dois nós, o grau efetivo de replicação do aplicativo será reduzido para dois.
Cinco réplicas só podem ser distribuídas em dois nós e, se um deles falhar, várias réplicas serão desativadas de uma só vez.
Se você tiver cinco nós ou mais, cada réplica será executada em um nó separado e a falha de um nó removerá no máximo uma réplica.
Assim, os requisitos de alta disponibilidade podem exigir um determinado número mínimo de nós no cluster.
Desvantagem nº 3. Piores consequências do fracasso
Com um pequeno número de nós, cada falha tem consequências mais graves. Por exemplo, se você tiver apenas dois nós e um deles falhar, metade dos seus módulos desaparecerá imediatamente.
Obviamente, o Kubernetes migrará a carga de trabalho do nó com falha para outros. Mas se houver poucos deles, pode não haver capacidade livre suficiente. Como resultado, alguns de seus aplicativos ficarão indisponíveis até que você abra o nó com falha.
Assim, quanto mais nós, menor será o impacto das falhas de hardware.
Desvantagem nº 4: mais etapas de escalonamento automático
Kubernetes possui um sistema de escalonamento automático de cluster para infraestrutura em nuvem, que permite adicionar ou remover nós automaticamente dependendo de suas necessidades atuais. Com nós maiores, o escalonamento automático se torna mais abrupto e desajeitado. Por exemplo, em dois nós, adicionar um nó adicional aumentará imediatamente a capacidade do cluster em 50%. E você terá que pagar por esses recursos, mesmo que não precise deles.
Assim, se você planeja usar o escalonamento automático de cluster, quanto menores os nós, mais flexível e econômico você obterá.
Agora vamos examinar as vantagens e desvantagens de um grande número de nós pequenos.
Segunda opção: muitos nós pequenos
As vantagens desta abordagem decorrem essencialmente das desvantagens da opção oposta com vários nós grandes.
Prós
Pró nº 1: Menos impacto de falhas
Quanto mais nós, menos pods em cada nó. Por exemplo, se você tiver cem módulos por dez nós, cada nó terá em média dez módulos.
Dessa forma, se um dos nós falhar, você perderá apenas 10% da carga de trabalho. Provavelmente, apenas um pequeno número de réplicas será afetado e o aplicativo geral permanecerá operacional.
Além disso, os nós restantes provavelmente terão recursos livres suficientes para lidar com a carga de trabalho do nó com falha, para que o Kubernetes possa reprogramar livremente os pods e seus aplicativos retornarão a um estado funcional de forma relativamente rápida.
Pró nº 2: boa replicação
Se houver nós suficientes, o agendador do Kubernetes poderá atribuir nós diferentes a todas as réplicas. Dessa forma, caso um nó falhe, apenas uma réplica será afetada e a aplicação permanecerá disponível.
Contras
Desvantagem nº 1. Difícil de controlar
Um grande número de nós é mais difícil de gerenciar. Por exemplo, cada nó do Kubernetes deve se comunicar com todos os outros, ou seja, o número de conexões cresce quadraticamente e todas essas conexões precisam ser rastreadas.
O controlador de nó no Kubernetes Controller Manager percorre regularmente todos os nós do cluster para verificar a integridade - quanto mais nós, mais carga no controlador.
A carga no banco de dados etcd também está crescendo - cada chamada kubelet e kube-proxy para etcd (através da API), para o qual o etcd deve transmitir atualizações de objetos.
Em geral, cada nó de trabalho impõe carga adicional aos componentes do sistema dos nós mestres.
Kubernetes oferece suporte oficial a clusters com . No entanto, na prática já existem 500 nós .
Para gerenciar um grande número de nós de trabalho, você deve escolher nós principais mais poderosos. Por exemplo, kube-up o tamanho correto da VM para o nó mestre, dependendo do número de nós de trabalho. Ou seja, quanto mais nós trabalhadores, mais produtivos deverão ser os nós mestres.
Para resolver estes problemas específicos existem desenvolvimentos especiais, como . Este sistema permite contornar restrições e construir clusters com um grande número de nós de trabalho.
Desvantagem nº 2: Mais custos indiretos.
Em cada nó de trabalho, o Kubernetes executa um conjunto de daemons do sistema - incluindo o tempo de execução do contêiner (como Docker), kube-proxy e kubelet, incluindo cAdvisor. Juntos, eles consomem uma certa quantidade fixa de recursos.
Se você tiver muitos nós pequenos, a proporção dessa sobrecarga em cada nó será maior. Por exemplo, imagine que todos os daemons do sistema em um único nó usem 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 daemons consumirão 1% da capacidade do cluster. Por outro lado, em dez nós de núcleo único com 1 GB de memória, os daemons ocuparão 10% da capacidade do cluster.
Assim, quanto menos nós, mais eficientemente a infraestrutura é utilizada.
Desvantagem nº 3. Uso ineficiente de recursos
Em nós pequenos, pode ser que os pedaços de recursos restantes sejam pequenos demais para serem atribuídos a qualquer carga de trabalho e, portanto, permaneçam sem uso.
Por exemplo, cada pod requer 0,75 GB de memória. Se você tiver dez nós, cada um com 1 GB de memória, poderá executar dez pods, deixando cada nó com 0,25 GB de memória não utilizada.
Isso significa que 25% de toda a memória do cluster é desperdiçada.
Em um nó grande com 10 GB de memória, você pode executar 13 desses módulos - e haverá apenas um fragmento não utilizado de 0,25 GB.
Neste caso, apenas 2,5% da memória é desperdiçada.
Assim, os recursos são usados de forma mais otimizada em nós maiores.
Alguns nós grandes ou muitos pequenos?
Então, o que é melhor: alguns nós grandes em um cluster ou muitos nós pequenos? Como sempre, não há uma resposta clara. Depende muito do tipo de aplicação.
Por exemplo, se um aplicativo requer 10 GB de memória, nós maiores são uma escolha óbvia. E se o aplicativo exigir replicação dez vezes maior para alta disponibilidade, dificilmente vale a pena correr o risco de colocar réplicas em apenas dois nós - deve haver no mínimo dez nós no cluster.
Em situações intermediárias, faça uma escolha com base nas vantagens e desvantagens de cada opção. Talvez alguns argumentos sejam mais relevantes para a sua situação do que outros.
E não é necessário fazer com que todos os nós tenham o mesmo tamanho. Nada impede que você experimente primeiro nós do mesmo tamanho e depois adicione nós de tamanhos diferentes a eles, combinando-os em um cluster. Os nós de trabalho em um cluster Kubernetes podem ser completamente heterogêneos. Portanto, você pode tentar combinar as vantagens de ambas as abordagens.
Não existe uma receita única e cada situação tem suas nuances, e só a produção mostrará a verdade.
Tradução preparada pela equipe da plataforma em nuvem .
Mais sobre Kubernetes: .
Fonte: habr.com