Autoscaler do cluster

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Visão geral

O Kubernetes Cluster Autoscaler é uma solução popular de escalonamento automático de clusters mantida pelo SIG Autoscaling. Ele é responsável por garantir que seu cluster tenha nós suficientes para programar seus pods sem desperdiçar recursos. Ele observa os pods que falham no agendamento e os nós que estão subutilizados. Em seguida, ele simula a adição ou remoção de nós antes de aplicar a alteração ao seu cluster. A implementação do AWS Cloud Provider no Cluster Autoscaler controla o .DesiredReplicas campo dos seus grupos de Auto EC2 Scaling.

Este guia fornecerá um modelo mental para configurar o autoescalador de cluster e escolher o melhor conjunto de compensações para atender aos requisitos da sua organização. Embora não exista uma única melhor configuração, há um conjunto de opções de configuração que permitem que você troque desempenho, escalabilidade, custo e disponibilidade. Além disso, este guia fornecerá dicas e melhores práticas para otimizar sua configuração para a AWS.

Glossário

A terminologia a seguir será usada com frequência em todo este documento. Esses termos podem ter um significado amplo, mas estão limitados às definições abaixo para os fins deste documento.

A escalabilidade se refere ao desempenho do autoescalador de cluster à medida que seu cluster Kubernetes aumenta em número de pods e nós. À medida que os limites de escalabilidade são atingidos, o desempenho e a funcionalidade do Cluster Autoscaler diminuem. Como o autoescalador de cluster excede seus limites de escalabilidade, ele não pode mais adicionar ou remover nós em seu cluster.

O desempenho se refere à rapidez com que o autoescalador de cluster é capaz de tomar e executar decisões de escalabilidade. Um autoescalador de cluster com desempenho perfeito tomaria instantaneamente uma decisão e acionaria uma ação de escalonamento em resposta a estímulos, como um pod se tornando não programável.

A disponibilidade significa que os pods podem ser programados rapidamente e sem interrupções. Isso inclui quando os pods recém-criados precisam ser programados e quando um nó reduzido encerra todos os pods restantes programados nele.

O custo é determinado pela decisão por trás da expansão e da escala nos eventos. Recursos são desperdiçados se um nó existente for subutilizado ou se for adicionado um novo nó grande demais para os pods de entrada. Dependendo do caso de uso, pode haver custos associados ao encerramento prematuro dos pods devido a uma decisão agressiva de redução de escala.

Grupos de nós são um conceito abstrato do Kubernetes para um grupo de nós em um cluster. Ele não é um verdadeiro recurso do Kubernetes, mas existe como uma abstração no autoescalador de cluster, na API de cluster e em outros componentes. Os nós dentro de um grupo de nós compartilham propriedades como rótulos e manchas, mas podem consistir em várias zonas de disponibilidade ou tipos de instância.

EC2 Os grupos de Auto Scaling podem ser usados como uma implementação do Node Groups on. EC2 EC2 Os grupos de Auto Scaling são configurados para iniciar instâncias que se juntam automaticamente aos clusters do Kubernetes e aplicam rótulos e contaminações ao recurso Node correspondente na API do Kubernetes.

EC2 Os grupos de nós gerenciados são outra implementação dos grupos de nós emEC2. Eles eliminam a complexidade da configuração manual dos grupos de EC2 escalabilidade automática e fornecem recursos adicionais de gerenciamento, como atualização da versão do nó e encerramento normal do nó.

Operando o escalador automático de cluster

O Cluster Autoscaler é normalmente instalado como uma implantação no cluster. Ele usa a eleição do líder para garantir alta disponibilidade, mas o trabalho é feito por meio de uma única réplica por vez. Não é escalável horizontalmente. Para configurações básicas, o padrão deve funcionar imediatamente, usando as instruções de instalação fornecidas, mas há algumas coisas que você deve ter em mente.

Certifique-se de que:

Empregue o acesso menos privilegiado à função do IAM

Quando a Descoberta Automática é usada, é altamente recomendável que você empregue o acesso com privilégios mínimos limitando as Ações autoscaling:SetDesiredCapacity e os grupos de autoscaling:TerminateInstanceInAutoScalingGroup Auto Scaling que têm como escopo o cluster atual.

Isso impedirá que um autoescalador de cluster executado em um cluster modifique grupos de nós em um cluster diferente, mesmo que o --node-group-auto-discovery argumento não tenha sido reduzido aos grupos de nós do cluster usando tags (por exemplo). k8s.io/cluster-autoscaler/<cluster-name>

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "autoscaling:SetDesiredCapacity",
                "autoscaling:TerminateInstanceInAutoScalingGroup"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/k8s.io/cluster-autoscaler/enabled": "true",
                    "aws:ResourceTag/k8s.io/cluster-autoscaler/<my-cluster>": "owned"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": [
                "autoscaling:DescribeAutoScalingGroups",
                "autoscaling:DescribeAutoScalingInstances",
                "autoscaling:DescribeLaunchConfigurations",
                "autoscaling:DescribeScalingActivities",
                "autoscaling:DescribeTags",
                "ec2:DescribeImages",
                "ec2:DescribeInstanceTypes",
                "ec2:DescribeLaunchTemplateVersions",
                "ec2:GetInstanceTypesFromInstanceRequirements",
                "eks:DescribeNodegroup"
            ],
            "Resource": "*"
        }
    ]
}

Configurando seus grupos de nós

O escalonamento automático eficaz começa com a configuração correta de um conjunto de grupos de nós para seu cluster. Selecionar o conjunto certo de grupos de nós é fundamental para maximizar a disponibilidade e reduzir os custos em suas cargas de trabalho. A AWS implementa grupos de nós usando grupos de EC2 Auto Scaling, que são flexíveis para um grande número de casos de uso. No entanto, o escalador automático de clusters faz algumas suposições sobre seus grupos de nós. Manter as configurações do EC2 Auto Scaling Group consistentes com essas suposições minimizará o comportamento indesejado.

Certifique-se de que:

Observação: recomendamos o uso de grupos de nós gerenciados do EKS. Os grupos de nós gerenciados vêm com recursos de gerenciamento poderosos, incluindo recursos para o escalador automático de cluster, como descoberta automática de grupos de Auto EC2 Scaling e encerramento de nós sem problemas.

Otimizando o desempenho e a escalabilidade

Compreender a complexidade do tempo de execução do algoritmo de escalonamento automático ajudará você a ajustar o autoescalador de cluster para continuar operando sem problemas em grandes clusters com mais de 1.000 nós.

Os botões principais para ajustar a escalabilidade do autoescalador de cluster são os recursos fornecidos ao processo, o intervalo de varredura do algoritmo e o número de grupos de nós no cluster. Há outros fatores envolvidos na verdadeira complexidade do tempo de execução desse algoritmo, como a complexidade do plug-in de agendamento e o número de pods. Esses parâmetros são considerados não configuráveis, pois são naturais à carga de trabalho do cluster e não podem ser facilmente ajustados.

O escalador automático de cluster carrega todo o estado do cluster na memória, incluindo pods, nós e grupos de nós. Em cada intervalo de varredura, o algoritmo identifica pods não programáveis e simula o agendamento para cada grupo de nós. O ajuste desses fatores vem com diferentes compensações que devem ser cuidadosamente consideradas para seu caso de uso.

Escalonamento automático vertical do escalonador automático do cluster

A maneira mais simples de escalar o autoescalador de cluster para clusters maiores é aumentar as solicitações de recursos para sua implantação. Tanto a memória quanto a CPU devem ser aumentadas para clusters grandes, embora isso varie significativamente com o tamanho do cluster. O algoritmo de escalonamento automático armazena todos os pods e nós na memória, o que pode resultar em um espaço de memória maior que um gigabyte em alguns casos. O aumento de recursos geralmente é feito manualmente. Se você achar que o ajuste constante de recursos está criando uma carga operacional, considere usar o Addon Resizer ou o Vertical Pod Autoscaler.

Reduzindo o número de grupos de nós

Minimizar o número de grupos de nós é uma forma de garantir que o autoescalador de clusters continue funcionando bem em clusters grandes. Isso pode ser um desafio para algumas organizações que estruturam seus grupos de nós por equipe ou por aplicativo. Embora isso seja totalmente suportado pela API Kubernetes, isso é considerado um antipadrão do autoescalador de cluster com repercussões na escalabilidade. Há muitos motivos para usar vários grupos de nós (por exemplo, Spot ou GPUs), mas em muitos casos existem designs alternativos que alcançam o mesmo efeito ao usar um pequeno número de grupos.

Certifique-se de que:

Reduzindo o intervalo de varredura

Um intervalo de varredura baixo (por exemplo, 10 segundos) garantirá que o escalador automático de cluster responda o mais rápido possível quando os pods não puderem ser programados. No entanto, cada verificação resulta em muitas chamadas de API para a API Kubernetes e o EC2 Auto Scaling Group ou o EKS Managed Node Group. APIs Essas chamadas de API podem resultar na limitação da taxa ou até mesmo na indisponibilidade do serviço para seu plano de controle do Kubernetes.

O intervalo de verificação padrão é de 10 segundos, mas na AWS, a execução de um nó leva muito mais tempo para iniciar uma nova instância. Isso significa que é possível aumentar o intervalo sem aumentar significativamente o tempo geral para o aumento da escala. Por exemplo, se forem necessários 2 minutos para iniciar um nó, alterar o intervalo para 1 minuto resultará em uma troca de chamadas de API reduzidas em 6 vezes por aumentos de escala 38% mais lentos.

Fragmentação entre grupos de nós

O escalador automático de cluster pode ser configurado para operar em um conjunto específico de grupos de nós. Usando essa funcionalidade, é possível implantar várias instâncias do autoescalador de cluster, cada uma configurada para operar em um conjunto diferente de grupos de nós. Essa estratégia permite que você use números arbitrariamente grandes de grupos de nós, trocando o custo pela escalabilidade. Recomendamos usar isso apenas como último recurso para melhorar o desempenho.

O escalador automático de cluster não foi originalmente projetado para essa configuração, portanto, há alguns efeitos colaterais. Como os fragmentos não se comunicam, é possível que vários autoescaladores tentem programar um pod não programável. Isso pode resultar em escalabilidade desnecessária de vários grupos de nós. Esses nós extras voltarão a ser ampliados após scale-down-delay o.

metadata:
  name: cluster-autoscaler
  namespace: cluster-autoscaler-1

...

--nodes=1:10:k8s-worker-asg-1
--nodes=1:10:k8s-worker-asg-2

---

metadata:
  name: cluster-autoscaler
  namespace: cluster-autoscaler-2

...

--nodes=1:10:k8s-worker-asg-3
--nodes=1:10:k8s-worker-asg-4

Certifique-se de que:

Otimizando o custo e a disponibilidade

Instâncias spot

Você pode usar Instâncias Spot em seus grupos de nós e economizar até 90% do preço sob demanda. Com a desvantagem, as Instâncias Spot podem ser interrompidas a qualquer momento quando EC2 precisar recuperar a capacidade. Erros de capacidade insuficiente ocorrerão quando seu grupo de EC2 Auto Scaling não puder ser ampliado devido à falta de capacidade disponível. Maximizar a diversidade selecionando muitas famílias de instâncias pode aumentar sua chance de alcançar a escala desejada explorando vários pools de capacidade spot e diminuir o impacto das interrupções de instâncias spot na disponibilidade do cluster. Políticas de instâncias mistas com instâncias spot são uma ótima maneira de aumentar a diversidade sem aumentar o número de grupos de nós. Lembre-se de que, se você precisar de recursos garantidos, use instâncias sob demanda em vez de instâncias spot.

É fundamental que todos os tipos de instância tenham capacidade de recursos semelhante ao configurar políticas de instância mista. O simulador de agendamento do autoescalador usa o primeiro no. InstanceType MixedInstancePolicy Se os tipos de instância subsequentes forem maiores, os recursos poderão ser desperdiçados após um aumento de escala. Se forem menores, seus pods podem não ser programados nas novas instâncias devido à capacidade insuficiente. Por exemplo, todas as instâncias M4, M5, M5a e M5n têm quantidades semelhantes de CPU e memória e são ótimas candidatas para a. MixedInstancePolicy A ferramenta EC2 Instance Selector pode ajudar você a identificar tipos de instância semelhantes.

É recomendável isolar a capacidade sob demanda e spot em grupos separados de Auto EC2 Scaling. Isso é preferível ao uso de uma estratégia de capacidade básica porque as propriedades de agendamento são fundamentalmente diferentes. Como as instâncias spot são interrompidas a qualquer momento (quando é EC2 necessário recuperar a capacidade), os usuários geralmente contaminam seus nós preemptivos, exigindo uma tolerância explícita do pod ao comportamento de preempção. Essas manchas resultam em propriedades de agendamento diferentes para os nós, portanto, eles devem ser separados em vários grupos de Auto EC2 Scaling.

O escalador automático de cluster tem um conceito de expansores, que fornecem estratégias diferentes para selecionar qual grupo de nós escalar. A estratégia --expander=least-waste é um bom padrão de uso geral e, se você for usar vários grupos de nós para diversificar instâncias spot (conforme descrito na imagem acima), ela poderá ajudar a otimizar ainda mais os custos dos grupos de nós ao escalar o grupo que seria melhor utilizado após a atividade de escalabilidade.

Priorizando um grupo de nós/ASG

Você também pode configurar o escalonamento automático baseado em prioridade usando o expansor de prioridade. --expander=prioritypermite que seu cluster priorize um grupo de nós /ASG e, se não conseguir escalar por algum motivo, ele escolherá o próximo grupo de nós na lista priorizada. Isso é útil em situações em que, por exemplo, você deseja usar tipos de instância P3 porque a GPU deles fornece desempenho ideal para sua carga de trabalho, mas, como segunda opção, você também pode usar tipos de instância P2.

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-autoscaler-priority-expander
  namespace: kube-system
data:
  priorities: |-
    10:
      - .*p2-node-group.*
    50:
      - .*p3-node-group.*

O Cluster Autoscaler tentará escalar o grupo Auto EC2 Scaling correspondente ao nome p3-node-group. Se essa operação não for bem-sucedida--max-node-provision-time, ela tentará escalar um grupo de EC2 Auto Scaling correspondente ao nome p2-node-group. Esse valor é padronizado para 15 minutos e pode ser reduzido para uma seleção de grupos de nós mais responsiva, mas se o valor for muito baixo, isso pode causar escalas desnecessárias.

Provisionamento excessivo

O escalador automático de cluster minimiza os custos ao garantir que os nós sejam adicionados ao cluster somente quando necessário e removidos quando não utilizados. Isso afeta significativamente a latência da implantação, pois muitos pods serão forçados a esperar pelo aumento da escala de um nó antes de poderem ser programados. Os nós podem levar vários minutos para ficarem disponíveis, o que pode aumentar a latência do agendamento do pod em uma ordem de grandeza.

Isso pode ser atenuado usando o provisionamento em excesso, o que troca o custo pela latência do agendamento. O superprovisionamento é implementado usando pods temporários com prioridade negativa, que ocupam espaço no cluster. Quando os pods recém-criados não puderem ser programados e tiverem maior prioridade, os pods temporários serão antecipados para liberar espaço. Os pods temporários então se tornam não programáveis, fazendo com que o autoescalador de cluster escale novos nós superprovisionados.

Há outros benefícios menos óbvios no provisionamento excessivo. Sem o provisionamento excessivo, um dos efeitos colaterais de um cluster altamente utilizado é que os pods tomarão decisões de agendamento menos ideais usando a preferredDuringSchedulingIgnoredDuringExecution regra de Pod ou Node Affinity. Um caso de uso comum para isso é separar pods para um aplicativo altamente disponível em todas as zonas de disponibilidade usando AntiAffinity. O provisionamento excessivo pode aumentar significativamente a chance de que um nó da zona correta esteja disponível.

A quantidade de capacidade superprovisionada é uma decisão comercial cuidadosa para sua organização. Em essência, é uma troca entre desempenho e custo. Uma forma de tomar essa decisão é determinar sua frequência média de aumento de escala e dividi-la pelo tempo necessário para escalar um novo nó. Por exemplo, se, em média, você precisar de um novo nó a cada 30 segundos e EC2 levar 30 segundos para provisionar um novo nó, um único nó de superprovisionamento garantirá que sempre haja um nó extra disponível, reduzindo a latência do agendamento em 30 segundos ao custo de uma única instância adicional. EC2 Para melhorar as decisões de agendamento zonal, provisione em excesso um número de nós igual ao número de zonas de disponibilidade em seu Grupo de EC2 Auto Scaling para garantir que o programador possa selecionar a melhor zona para os pods de entrada.

Evite o despejo em escala reduzida

O despejo de algumas workloads são caros. A análise de big data, as tarefas de aprendizado de máquina e os executores de testes acabarão sendo concluídos, mas deverão ser reiniciados se forem interrompidos. O escalador automático de cluster tentará reduzir qualquer nó abaixo do scale-down-utilization-threshold, o que interromperá todos os pods restantes no nó. Isso pode ser evitado garantindo que os pods caros de serem despejados sejam protegidos por um rótulo reconhecido pelo escalador automático de cluster.

Certifique-se de que:

Casos de uso avançados

Volumes do EBS

O armazenamento persistente é essencial para criar aplicativos com bom estado, como bancos de dados ou caches distribuídos. Os volumes do EBS permitem esse caso de uso no Kubernetes, mas estão limitados a uma zona específica. Esses aplicativos podem estar altamente disponíveis se fragmentados em vários AZs usando um volume EBS separado para cada AZ. O escalonador automático de cluster pode então equilibrar o escalonamento dos grupos de escalonamento automático. EC2

Certifique-se de que:

Co-agendamento

Treinamentos distribuídos de machine learning se beneficiam significativamente da latência minimizada das configurações de nós da mesma zona. Essas cargas de trabalho implantam vários pods em uma zona específica. Isso pode ser feito configurando o Pod Affinity para todos os pods co-programados ou usando o Node Affinity. topologyKey: failure-domain.beta.kubernetes.io/zone O escalonador automático de cluster então expandirá uma zona específica para atender às demandas. Talvez você queira alocar vários grupos de EC2 Auto Scaling, um por zona de disponibilidade, para permitir o failover de toda a carga de trabalho coagendada.

Certifique-se de que:

Aceleradores

Alguns clusters aproveitam aceleradores de hardware especializados, como a GPU. Ao escalar para baixo, o plug-in do dispositivo acelerador pode levar vários minutos para anunciar o recurso no cluster. O escalador automático de cluster simulou que esse nó terá o acelerador, mas até que o acelerador fique pronto e atualize os recursos disponíveis do nó, os pods pendentes não podem ser programados no nó. Isso pode resultar na repetição desnecessária do aumento de escala.

Além disso, nós com aceleradores e alta utilização de CPU ou memória não serão considerados para redução de escala, mesmo que o acelerador não seja usado. Esse comportamento pode ser caro devido ao custo relativo dos aceleradores. Em vez disso, o autoescalador de cluster pode aplicar regras especiais para considerar os nós a serem reduzidos se eles tiverem aceleradores desocupados.

Para garantir o comportamento correto nesses casos, você pode configurar o kubelet nos nós do acelerador para rotular o nó antes que ele se junte ao cluster. O autoescalador de cluster usará esse seletor de rótulos para acionar o comportamento otimizado do acelerador.

Certifique-se de que:

Escalando a partir de 0

O Cluster Autoscaler é capaz de escalar grupos de nós de e para zero, o que pode gerar economias de custo significativas. Ele detecta os recursos de CPU, memória e GPU de um grupo de Auto Scaling inspecionando InstanceType o especificado em seu ou. LaunchConfiguration LaunchTemplate Alguns pods requerem recursos adicionais, como WindowsENI ou específicos, PrivateIPv4Address NodeSelectors ou Taints, que não podem ser descobertos no. LaunchConfiguration O escalador automático de cluster pode explicar esses fatores ao descobri-los nas tags do Auto Scaling Group. EC2 Por exemplo:

Key: k8s.io/cluster-autoscaler/node-template/resources/$RESOURCE_NAME
Value: 5
Key: k8s.io/cluster-autoscaler/node-template/label/$LABEL_KEY
Value: $LABEL_VALUE
Key: k8s.io/cluster-autoscaler/node-template/taint/$TAINT_KEY
Value: NoSchedule

Observação: lembre-se de que, ao escalar para zero, sua capacidade é retornada EC2 e pode ficar indisponível no futuro.

Parâmetros adicionais

Há muitas opções de configuração que podem ser usadas para ajustar o comportamento e a performance do Cluster Autoscaler. Uma lista completa de parâmetros está disponível em GitHub.

Recursos adicionais

Esta página contém uma lista de apresentações e demonstrações do Cluster Autoscaler. Se você quiser adicionar uma apresentação ou demonstração aqui, envie um pull request.

Referências