Empresas enfrentam desafios diários na gestão de infraestrutura Kubernetes, especialmente para manter eficiência e reduzir custos. Aqui na Softplan, descobrimos uma solução que transforma a maneira de gerenciar nossos clusters EKS na AWS: o Karpenter.
Desafios na gestão de instâncias
Antes de falar de Karpenter é preciso dar alguns passos atrás e explicar um pouco do que se trata um auto escalonamento de nodes. Suponha que temos nosso cluster com algumas máquinas (instâncias) disponíveis executando nossos workloads. O que acontece se por acaso houver um pico de uso em nossas aplicações e seja necessário subir mais instâncias (réplicas) de nossos pods? Sem um autoscaling precisaríamos provisionar um node, orientá-lo a juntar-se ao nosso cluster para aí sim nossos pods estarem aptos a serem iniciados nessa nova instância. Lembrando que o provisionamento de uma instância não é instantâneo, há todo um bootstrapping da máquina, configurações de rede e muitas outras coisas antes dela ficar totalmente disponível.
Certo, falamos sobre pico de usuários em nossas aplicações, mas e quando houver ociosidade? Queremos mesmo deixar esses nodes em pé com poder computacional subutilizado? Para resolver essa e outras questões, entra em cena o conceito de auto scalers.
Auto Scalers
As implementações de auto scalers são responsáveis basicamente pelo provisionamento e consolidação de nodes. Aqui estamos falando de escalonamento horizontal, ou seja, adicionando mais máquinas em nosso cluster. Há diversas implementações de node autoscaling, mas neste artigo o foco será na implementação da AWS e por que decidimos migrar para uma outra solução. Abaixo uma figura exemplificando o funcionamento do node autoscaling:
Figura 01: autoscaling
AWS – Auto Scaling Groups
Ao definir um grupo de escalonamento na AWS precisamos definir diversas propriedades, como o número mínimo/máximo de instâncias de nodes permitidas para este grupo, recursos utilizados, tipo de disco, configurações de rede (subnets, etc) e muitos outros detalhes. Por exemplo, para um determinado tipo de aplicação que utilize mais CPU vamos configurar um grupo que contenha tipos de instância com mais CPU do que memória. No fim possivelmente teremos alguns grupos distintos para certos tipos de aplicações.
Juntando as peças – Cluster Auto Scaler
Para que meu cluster consiga “conversar” com meu cloud provider (neste exemplo AWS), precisamos de um componente chamado Cluster Auto Scaler, ou CAS.Este componente foi criado pela própria comunidade que mantém o Kubernetes, e está disponível aqui.
Uma configuração padrão do CAS pode ser vista abaixo, utilizando o helm para instalação:
Com isso configurado e instalado e nossos autoscaling groups criados acabamos de habilitar o gerenciamento automático de nossos nodes!
Por que decidimos migrar para o Karpenter
Nosso caso de uso aqui na Projuris é o seguinte: temos um cluster de desenvolvimento e outro de produção. Depois da migração para o Gitlab SaaS tínhamos um desafio de como provisionar os runners para a execução de nossas pipelines. Ficou decidido que usaríamos o cluster de desenvolvimento para provisionamento desses runners. Na “primeira versão” optamos pelo cluster auto scaler por ser uma configuração mais simples e que já atendia nosso setup em produção. Mas aí começamos a enfrentar alguns problemas com esta escolha:
- Tempo de provisionamento: ao iniciar uma pipeline o tempo de provisionamento da máquina era um pouco lento. O grande ponto é que o cluster auto scaler paga um “pedágio” no cloud provider para provisionamento de um novo node
- Dificuldade na configuração de grupos: como temos alguns “perfis” de pipeline essa gestão ficou um pouco complicada, porque para cada novo perfil um novo node group precisa ser criado
- Custo: para mitigar o problema de lentidão no startup de um novo node tínhamos um perfil de máquina “online” que ficava o tempo todo de pé, mesmo sem executar nenhuma pipeline
O que é o Karpenter?
É uma solução de cluster autoscaling criada pela AWS, que promete o provisionamento e consolidação de nodes sempre com o menor custo possível. Ele é inteligente o suficiente para saber que por exemplo, ao comprar uma máquina na AWS do tipo on-demand, dependendo da situação, é mais em conta do que se fosse uma máquina spot. E essa é apenas uma das características dessa ferramenta.
O Karpenter também trabalha com a ideia de “grupos” de máquinas (que no mundo do Karpenter chamamos de NodePools), só que a diferença é que fazemos isso através de CRDs (custom resource definitions) do próprio Karpenter, ou seja, temos manifestos dentro de nosso cluster com todas essas configurações, eliminando a necessidade de qualquer node group criado na AWS. Exemplo de um NodePool no Karpenter:
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: karpenter-gitlab-runner-small-online
spec:
template:
metadata:
labels:
workload: gitlab-runners
environment: karpenter-nodes-gitlab-runner-build-small-online
spec:
requirements:
– key: “karpenter.sh/capacity-type”
operator: In
values: [“spot”, “on-demand”]
– key: “node.kubernetes.io/instance-type”
operator: In
values: [“m5d.large”, “m5n.large”, “m6id.large”, “m6in.large”]
nodeClassRef:
group: karpenter.k8s.aws
kind: EC2NodeClass
name: my-node-class
taints:
– key: “gitlab-runner-karpenter”
value: “true”
effect: NoSchedule
expireAfter: Never
disruption:
consolidationPolicy: WhenEmpty
consolidateAfter: 5m
budgets:
– nodes: “20%”
limits:
cpu: “500”
memory: 500Gi
Além do NodePool precisamos criar um NodeClass para definir detalhes específicos de instâncias AWS:
apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
name: my-node-class
spec:
amiFamily: AL2
role: “aws-role”
tags:
Name: nodes-k8s-nodes-gitlab-runner-small-online
subnetSelectorTerms:
– tags:
karpenter.sh/subnet: “my-subnet”
securityGroupSelectorTerms:
– id: “sg-123”
– id: “sg-456”
– id: “sg-789”
amiSelectorTerms:
– id: “imagem ami”
kubelet:
clusterDNS: [“111.222.333.44”]
blockDeviceMappings:
– deviceName: /dev/xvda
ebs:
volumeSize: 40Gi
volumeType: gp3
encrypted: true
OBS: Perceba que o nome “my-node-class” precisa bater com o node class configurado no node pool.
Como o Karpenter nos ajudou a superar os desafios apresentados?
- Tempo de provisionamento: como o Karpenter conversa diretamente com as APIs do cloud provider não é necessário pagar o pedágio do cluster auto scaler. Tínhamos muitos problemas de timeout no provisionamento de novos nodes, após a troca pelo Karpenter esse problema simplesmente desapareceu justamente porque o provisionamento é mais eficiente
- Dificuldade na configuração de grupos: com a solução de NodePools e NodeClass do Karpenter essa configuração ficou trivial, e o mais importante, versionada em nosso controle de versões no Gitlab. Ou seja, precisa incluir um perfil de máquina novo no NodePool? Sem problemas, basta um commit e o Karpenter já irá considerar isso nos novos provisionamentos
- Custo: Conseguimos utilizar a utilização de máquinas, pois agora runners com características semelhantes são alocados em nodes que suportem os requisitos de memória e cpu exigidos. Ou seja, estamos realmente usando todo o poder computacional que aquele node proporciona. Isso vale também para a consolidação de nodes. Com o cluster auto scaler haviam scripts complexos para fazer o drain dos nodes antes da consolidação. Com o Karpenter isso é configurado no NodePool de maneira muito simplificada.
Um ótimo argumento para a gestão que justifique o investimento nesse tipo de mudança é custo. Abaixo temos um comparativo do custo utilizando o Cluster AutoScaler e o Karpenter em Janeiro/25, onde conseguimos uma economia de 16% no total:
Figura 02: Período de 01/01 à 15/01 com ClusterAutoScaler
Figura 03: Período de 16/01 à 31/01 com o Karpenter
Considerações finais
A migração para o Karpenter foi uma escolha acertada. Conseguimos simplificar a gestão de nossos nodes com diferentes perfis de forma bastante simplificada. Ainda há espaço para algumas melhorias, como por exemplo a utilização de um único NodePool para simplificar ainda mais, e deixar que os runners configurem labels específicas para o perfil de máquina que deve ser provisionado para o runner (mais em https://kubernetes.io/docs/reference/labels-annotations-taints/).
Referências:
- Karpenter (doc oficial): https://karpenter.sh/
- Node Auto Scaling (doc oficial k8s): https://kubernetes.io/docs/concepts/cluster-administration/node-autoscaling/
Conteúdos relacionados
O que é UX Writing e tudo o que você precisa saber para criar experiências incríveis!
O que é UX Writing e como impacta positivamente o produto de um negócio? Veja boas práticas, responsabilidades, metodologias, e muito mais!
A Evolução Digital no Setor Público: Gestão de Produtos B2G
A transformação digital no setor público está a todo vapor e com ela, a gestão de produtos B2G (Business to Government) ganha um papel cada vez mais estratégico.
A força da colaboração e o cliente como protagonista: impactos da evolução de produtos no Grupo Softplan
Colaboração entre times, escuta ativa do cliente e evolução contínua de produto: uma combinação poderosa que impulsiona a inovação.
Embeddings: o que são e suas aplicações
Sabemos que com o surgimento de diversas tecnologias, há um grande aumento do número de termos que ouvimos falar, embeddings é um deles, mas o que são?