O que é container-driven autoscaling?
Esteja você usando um serviço gerenciado do Kubernetes, como AWS EKS, GCP GKE ou Azure AKS, ou gerenciando por conta própria um cluster criado do zero e implantado com ferramentas de código aberto, como Kops e Kubespray, o hardware subjacente pode variar de contêiner para contêiner. Cada contêiner requer recursos específicos (CPU/memória/GPU/rede/disco) e, desde que a infraestrutura subjacente possa fornecer esses recursos, o contêiner poderá executar sua lógica de negócios.
Na prática, ao lançar os contêineres, o Scheduler do Kubernetes verifica se seus requisitos foram atendidos, mas não leva em consideração o tamanho, tipo ou preço das instâncias em que um contêiner é executado, apenas que elas têm recursos suficientes para fazê-lo. Muitas vezes, os usuários “super-provisionam” a infraestrutura para garantir que os aplicativos continuem funcionando, mas isso resulta em um enorme desperdício de recursos computacionais na nuvem e gastos desnecessários.
O container-driven autoscaling é uma abordagem que visa reduzir o provisionamento excessivo e permitir alto desempenho, fornecendo aos contêineres a infraestrutura mais otimizada possível, com base nos requisitos e restrições especificados a nível de aplicação. As características do contêiner e do pod, como labels, taints e tolerations, definem o tipo de instância com a qual ele corresponde.
A importância de escolher o melhor tipo de máquina
Plataformas de orquestração de contêiner, como o Kubernetes, exigem que os usuários cuidem da escalabilidade da capacidade computacional (por exemplo, adicionar/remover nós do cluster) e dos pods a nível de carga de trabalho. O Kubernetes oferece serviços de escalabilidade de pods para adicionar e remover contêineres (HPA) e modificar recursos para contêineres específicos (VPA), mas não possui recursos de escalabilidade ou gerenciamento de infraestrutura nativa.
Gerenciar a infraestrutura de um cluster Kubernetes é uma tarefa desafiadora e geralmente requer suporte de vários tipos de máquinas com diferentes recursos de hardware para atender às necessidades das aplicações. Para fazer isso com eficiência, os usuários acabam gerenciando vários node groups que suportam um tipo de máquina cada (ou vários tipos de máquina com capacidade de hardware semelhante). Cada aplicação tem seus próprios requisitos para tipos e tamanhos de instância e, à medida que o número de node groups aumenta, aumenta também a quantidade de recursos de infraestrutura desperdiçados.
Leia mais sobre esse desafio e explore exemplos de como a escolha do melhor tipo de máquina pode levar a uma redução drástica de custos na postagem do blog a seguir.
Como o Ocean funciona?
O Ocean, a engine de infraestrutura serverless para contêineres da Spot by NetApp, adota a abordagem de escalabilidade orientada a contêiner e permite que os usuários ofereçam suporte a um número ilimitado de tipos e tamanhos de máquinas em um único grupo de nós. Isso simplifica drasticamente o gerenciamento de infraestrutura e resulta em uma redução substancial de custos. Ao monitorar eventos a nível de contêiner, o Ocean pode dimensionar automaticamente o tamanho e o tipo corretos de instâncias para atender aos requisitos das aplicações, com o menor custo possível.
Neste artigo, abordaremos como o Ocean implementa a infraestrutura do “Container Driven Autoscaling”.
O Ocean se integra ao cluster de Kubernetes usando um Pod controlador (Controller), que se comunica com a API do Kubernetes em uma extremidade e o back-end do SaaS do Ocean na outra.
O Controller busca os metadados dos recursos do Kubernetes sendo executados no cluster (por exemplo, Pods, Nodes, Deployments, DaemonSets, Jobs, StatefulSets, PersistentVolumes, PersistentVolumeClaims etc.) e os envia para o SaaS do Ocean. O SaaS do Ocean analisa os requisitos de carga de trabalho em tempo real e toma decisões inteligentes para aumentar e/ou diminuir o cluster.
Na verdade, o Ocean Autoscaler simula constantemente as ações do Scheduler do Kubernetes e agirá de forma a satisfazer todas as necessidades de recursos do Kubernetes.
O Ocean considera as seguintes configurações do Kubernetes:
Resources requests (CPU, Memory, and GPU)
nodeSelectors
Regras de affinity & anti-affinity obrigatórias
Taints & tolerations
Labels & taints proprietárias da Spot
Label cluster-autoscaler.kubernetes.io/safe-to-evict: false
PersistentVolumes & PersistentVolumeClaims
Scale Up
Quando necessário, a Ocean decidirá aumentar a capacidade dos worker nodes do cluster adicionando novos nós ao cluster.
Há duas razões principais para um evento de Scale Up:
Pods pendentes que o Kubernetes Scheduler não consegue lançar nos nós existentes.
Headroom com capacidade inferior à configurada
Processo de Scale Up
O Pod controlador (Controller) envia metadados de pod/s pendentes assim que aparecem a nível de cluster.
A cada minuto, o Ocean determina se há pods pendentes e verifica o headroom para garantir que esteja na capacidade desejada.
Ocean SaaS irá:
Analisar os recursos necessários: para cada Pod pendente, verificar os recursos solicitados (vCPU e Memória) e suas restrições definidas. Em seguida,irá identificar o Virtual Node Group (VNG) relevante que pode acomodar o pod (em termos de node labels suportadas, taints/tolerations e tipos de instância). Por fim, uma solicitação de nós é acionada. Essa solicitação será feita de acordo com o conjunto de instâncias selecionadas no momento da especificação da lista de tipos e tamanhos de máquinas compatíveis com as aplicações que serão executadas no cluster.
Seleção de instâncias: este processo é responsável por maximizar a eficiência de custos. Ele prioriza a seleção de instâncias em ordem de:
Instâncias Reservadas (RIs) ou Savings Plans (SPs) não utilizados.
Instâncias spot usando o processo exclusivo de seleção de instâncias spot do Spot.io, que considera a pontuação do mercado spot (Combinação de Tipo,Tamanho e Zona de Disponibilidade), custo e atual distribuição de instâncias no cluster.
Em caso de indisponibilidade de instâncias spot, o sistema faz o Fall-back to On Demand (OD) automaticamente o que garante o SLA de 99,99% para garantir que as cargas de trabalho continuem em execução.
Quando a capacidade spot estiver disponível novamente, o Ocean voltará automaticamente a utilizar instâncias spot substituindo os nós OD normalmente. Isso permite a otimização contínua da infraestrutura, permitindo que os usuários obtenham economia de custos sem precisar intervir manualmente a todo instante.
Encerramento das Instâncias
O Ocean trabalha para garantir um encerramento harmonioso de nós e pods no cluster. Os cenários a seguir causam o término de nós ao usar o Ocean:
Eventos de Scale-down
Como um cluster Kubernetes geralmente tem muitas cargas de trabalho dinâmicas, normalmente haverá um momento em que os nós em execução no cluster não serão mais necessários. Quando isso acontecer, o Ocean identificará os nós pouco usados e fará a compactação do cluster com o algoritmo de bin-pack com mais eficiência para obter uma alocação de recursos mais alta. A cada minuto, o Ocean simula se há pods em execução (começando pelos nós menos utilizados) que podem ser movidos normalmente para outros nós dentro do cluster. Em caso afirmativo, o Ocean drena esses nós (“cordonando” os nós, drenando os pods normalmente) respeitando os PDBs (Pod Disruption Budgets), para garantir a otimização contínua da infraestrutura e o aumento da economia na nuvem.
Comportamento do Scale down
Ao desligar um nó, o Ocean usa um tempo limite de drenagem configurável de pelo menos 300 segundos. Neste momento, o Ocean marca o nó como inapto a receber pods e ejeta todos os pods (respeitando o parâmetro terminationGracePeriodSeconds configurado) em execução no nó.
Ao ejetar um pod, um outro pod do mesmo deployment será criado em um nó diferente no cluster.
Após o tempo limite de drenagem expirar, o Ocean encerrará o nó e removerá qualquer pod que não for removido com êxito.
O processo de drenagem do Ocean leva em consideração PodDisruptionBudgets e realizará a ejeção de pods respeitando os PDBs configurados (quando possível)
Algumas cargas de trabalho não são tão resilientes a substituições de instâncias quanto outras, portanto, você pode querer evitar a substituição de nós, enquanto ainda obtém o benefício dos preços de instâncias spot. Um bom exemplo desses casos são os processos de jobs/batch que precisam terminar seu trabalho sem término pelo autoescaler do Ocean.
O Ocean facilita a prevenção do scale down de nós executando pods configurados com uma das seguintes labels:
spotinst.io/restrict-scale-down:true – esta label é uma label proprietária do Spot (Labels adicionais da Spot), pode ser configurada a nível de pod. Quando configurada, ela instrui o autoscaler do Ocean a evitar o scale down de um nó que executa qualquer pod que possua essa label.
cluster-autoscaler.kubernetes.io/safe-to-evict: false – label do cluster-autoscaler, funciona de forma parecida com a label restrict-scale-down. O Ocean suporta esta label para garantir uma migração simples do cluster-autoscaler para o Ocean.
Substituição das Instâncias
Existem vários cenários nos quais o Ocean trabalha ativamente para substituir os nós existentes no cluster:
Retornado a instâncias spot – O Ocean lançou nós On-Demand devido à indisponibilidades de instâncias spot. Assim que a capacidade spot estiver disponível novamente, o Ocean trabalha para substituir esses nós On-Demand por capacidade spot para maximizar a economia.
Utilizar RIs/Savings Plans – A Ocean reconhece quando existem instâncias reservadas não utilizadas ou planos de economia que podem ser utilizados e trabalha para substituir os nós existentes por nós On-Demand que utilizarão essas reservas.
Auto-healing – O Ocean detecta quando os nós não estão saudáveis e trabalha para substituí-los.
Predictive rebalancing – Ocean prevê que uma interrupção está prestes a ocorrer e substitui gradualmente o nó.
Interrupção de Instâncias Spot– A instância é recuperada pelo provedor de nuvem.
Cluster roll – Um usuário ou uma tarefa agendada aciona um cluster roll e todos os (ou um subconjunto dos) nós no cluster serão substituídos gradualmente.
O Ocean toma decisões inteligentes para otimizar ainda mais o cluster e garantir a disponibilidade da capacidade necessária.
Comportamento da substituição de instâncias:
Primeiro, o Ocean lançará uma nova instância para substituir a antiga.
Depois que a máquina for registrada no cluster, o Ocean começará a drenar a instância antiga semelhante a um evento de down scaling.
Em caso de interrupção de instâncias spot, o Ocean substituirá a instância e iniciará o processo de drenagem da instância antiga imediatamente, sem esperar que a nova instância seja registrada como íntegra no cluster. Em casos como este, ter um pouco de capacidade ociosa na forma de headroom é muito útil para permitir a drenagem segura dos pods.
Resumo
O Ocean fornece um autoscaler orientado por contêiner continuamente otimizado, trabalhando para garantir a disponibilidade da infraestrutura com o menor custo possível. Para saber mais sobre o Ocean, confira esta demo ou acesse https://www.realcloud.systems/spot-ocean para começar.
Comentário da RealCloud
“O Ocean oferece aos seus usuários a tranquilidade de não precisar se preocupar com a escalabilidade e onde seus workloads estão sendo executados, em outras palavras, o Ocean promove uma experiência serverless para ambientes conteinerizados. Entretanto, o Ocean também permite ao time de DevOps customizar muito mais o seu cluster a fim de atender a necessidade de todas as aplicações com o mínimo de overhead operacional. Com o Ocean o usuário terá o melhor dos dois mundos.”
- Marcos Porto, Solutions Architect na RealCloud
