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á.
# Karpenter
**dica**
[Explore as ](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) melhores práticas por meio de workshops do Amazon EKS.
[O Karpenter ](https://karpenter.sh/) é um projeto de código aberto projetado para aprimorar o gerenciamento do ciclo de vida dos nós nos clusters Kubernetes. Ele automatiza o provisionamento e o desprovisionamento de nós com base nas necessidades específicas de agendamento dos pods, permitindo escalabilidade eficiente e otimização de custos. Suas principais funções são:
+ Monitore pods que o agendador do Kubernetes não pode programar devido a restrições de recursos.
+ Avalie os requisitos de agendamento (solicitações de recursos, seletores de nós, afinidades, tolerâncias etc.) dos pods não programáveis.
+ Provisione novos nós que atendam aos requisitos desses pods.
+ Remova os nós quando eles não forem mais necessários.
Com o Karpenter, você pode definir NodePools com restrições no provisionamento de nós, como manchas, rótulos, requisitos (tipos de instância, zonas etc.) e limites no total de recursos provisionados. Ao implantar cargas de trabalho, você pode especificar várias restrições de agendamento nas especificações do pod, como recursos requests/limits, seletores de nós, node/pod afinidades, tolerâncias e restrições de distribuição de topologia. A Karpenter então provisionará nós do tamanho certo com base nessas especificações.
**Razões para usar o Karpenter **
Antes do lançamento do Karpenter, os usuários do Kubernetes dependiam principalmente dos grupos do [ Amazon EC2 Auto Scaling ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroup.html) e do [ Kubernetes Cluster Autoscaler ](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) (CAS) para ajustar dinamicamente a capacidade computacional de seus clusters. Com o Karpenter, você não precisa criar dezenas de grupos de nós para obter a flexibilidade e a diversidade que você obtém com o Karpenter. Ao contrário do CAS, o Karpenter não está tão estreitamente acoplado às versões do Kubernetes e não exige que você alterne entre as APIs da AWS e do Kubernetes.
A Karpenter consolida as responsabilidades de orquestração de instâncias em um único sistema, que é mais simples, mais estável e com reconhecimento de clusters. O Karpenter foi projetado para superar alguns dos desafios apresentados pelo Cluster Autoscaler, fornecendo maneiras simplificadas de:
+ Provisione nós com base nos requisitos de carga de trabalho.
+ Crie diversas configurações de nós por tipo de instância, usando NodePool opções flexíveis. Em vez de gerenciar muitos grupos de nós personalizados específicos, o Karpenter pode permitir que você gerencie diversas capacidades de carga de trabalho com uma única e flexível. NodePool
+ Obtenha um agendamento aprimorado de pods em grande escala lançando nós e agendando pods rapidamente.
Para obter informações e documentação sobre o uso do Karpenter, visite o site [ karpenter.sh](https://karpenter.sh/).
## Recomendações
As melhores práticas são divididas em seções sobre o próprio Karpenter e agendamento NodePools de pods.
## Melhores práticas da Karpenter
As melhores práticas a seguir abrangem tópicos relacionados ao próprio Karpenter.
### Bloqueie AMIs em clusters de produção
É altamente recomendável que você fixe as conhecidas imagens de máquina da Amazon (AMIs) usadas pela Karpenter para clusters de produção. Usar `amiSelector` com um alias definido como`@latest`, ou usar algum outro método que resulte na implantação de AMIs não testadas à medida que elas são lançadas, oferece o risco de falhas na carga de trabalho e tempo de inatividade em seus clusters de produção. Como resultado, é altamente recomendável fixar versões funcionais testadas das AMIs em seus clusters de produção enquanto você testa versões mais novas em clusters que não são de produção. Por exemplo, você pode definir um alias em seu da NodeClass seguinte forma:
```
amiSelectorTerms
- alias: al2023@v20240807
```
Para obter informações sobre como gerenciar e definir AMIs no Karpenter, consulte [ Gerenciando ](https://karpenter.sh/docs/tasks/managing-amis/) AMIs na documentação do Karpenter.
### Use o Karpenter para cargas de trabalho com necessidades variáveis de capacidade
O Karpenter aproxima o gerenciamento de escalabilidade das APIs nativas do Kubernetes do que os grupos de [ escalonamento automático ](https://aws.amazon.com/blogs/containers/amazon-eks-cluster-multi-zone-auto-scaling-groups/) (ASGs) e os grupos de nós gerenciados (MNGs). [https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html) ASGs e MNGs são AWS-native abstrações em que a escalabilidade é acionada com base nas métricas de nível da AWS, como a carga de CPU do EC2. [O Cluster Autoscaler ](https://docs.aws.amazon.com/eks/latest/userguide/autoscaling.html#cluster-autoscaler) une as abstrações do Kubernetes às abstrações da AWS, mas perde alguma flexibilidade por causa disso, como o agendamento para uma zona de disponibilidade específica.
O Karpenter remove uma camada de abstração da AWS para trazer parte da flexibilidade diretamente para o Kubernetes. O Karpenter é melhor usado para clusters com cargas de trabalho que enfrentam períodos de alta demanda ou têm diversos requisitos de computação. MNGs e ASGs são bons para clusters que executam cargas de trabalho que tendem a ser mais estáticas e consistentes. Você pode usar uma combinação de nós gerenciados de forma dinâmica e estática, dependendo de seus requisitos.
### Considere outros projetos de escalonamento automático quando...
Você precisa de recursos que ainda estão sendo desenvolvidos no Karpenter. Como o Karpenter é um projeto relativamente novo, considere outros projetos de escalonamento automático por enquanto, se precisar de recursos que ainda não fazem parte do Karpenter.
### Execute o controlador Karpenter no EKS Fargate ou em um nó de trabalho que pertença a um grupo de nós
O Karpenter é instalado usando um gráfico [ Helm. ](https://karpenter.sh/docs/getting-started/getting-started-with-karpenter/#4-install-karpenter) O gráfico Helm instala o controlador Karpenter e um pod de webhook como uma implantação que precisa ser executada antes que o controlador possa ser usado para escalar seu cluster. Recomendamos no mínimo um pequeno grupo de nós com pelo menos um nó de trabalho. Como alternativa, você pode executar esses pods no EKS Fargate criando um perfil Fargate para o namespace. `karpenter` Isso fará com que todos os pods implantados nesse namespace sejam executados no EKS Fargate. Não execute o Karpenter em um nó gerenciado pelo Karpenter.
### Não há suporte para modelos de lançamento personalizados com o Karpenter
Não há suporte para modelos de lançamento personalizados com APIs v1. Você pode usar dados personalizados do usuário especificando and/or diretamente AMIs personalizadas no. EC2NodeClass Mais informações sobre como fazer isso estão disponíveis em [ NodeClasses](https://karpenter.sh/docs/concepts/nodeclasses/).
### Exclua os tipos de instância que não se ajustam à sua carga de trabalho
Considere excluir tipos específicos de instâncias com a `node.kubernetes.io/instance-type` chave se elas não forem exigidas pelas cargas de trabalho em execução no seu cluster.
O exemplo a seguir mostra como evitar o provisionamento de grandes instâncias do Graviton.
```
- key: node.kubernetes.io/instance-type
operator: NotIn
values:
- m6g.16xlarge
- m6gd.16xlarge
- r6g.16xlarge
- r6gd.16xlarge
- c6g.16xlarge
```
### Ative o tratamento de interrupções ao usar o Spot
O Karpenter suporta o tratamento [ nativo de interrupções ](https://karpenter.sh/docs/concepts/disruption/#interruption) e pode lidar com eventos de interrupção involuntária, como interrupções de instâncias spot, eventos de manutenção programados e eventos de instância que podem interromper suas cargas de trabalho. termination/stopping Quando o Karpenter detecta esses eventos em nós, ele automaticamente mancha, drena e encerra os nós afetados com antecedência para iniciar uma limpeza normal das cargas de trabalho antes da interrupção. Para interrupções pontuais com 2 minutos de antecedência, o Karpenter inicia rapidamente um novo nó para que os pods possam ser movidos antes que a instância seja recuperada. Para habilitar o tratamento de interrupções, você configura o argumento `--interruption-queue` CLI com o nome da fila SQS provisionada para essa finalidade. Não é aconselhável usar o tratamento de interrupções do Karpenter junto com o Node Termination Handler, conforme explicado aqui. [https://karpenter.sh/docs/faq/#interruption-handling](https://karpenter.sh/docs/faq/#interruption-handling)
Os pods que exigem pontos de verificação ou outras formas de drenagem normal, exigindo 2 minutos antes do desligamento, devem permitir o tratamento de interrupções do Karpenter em seus clusters.
### **Cluster privado do Amazon EKS sem acesso externo à Internet**
Ao provisionar um cluster EKS em uma VPC sem rota para a Internet, você precisa se certificar de que configurou seu ambiente de acordo com os [ requisitos de cluster privado ](https://docs.aws.amazon.com/eks/latest/userguide/private-clusters.html#private-cluster-requirements) que aparecem na documentação do EKS. Além disso, você precisa ter certeza de ter criado um endpoint regional STS VPC em sua VPC. Caso contrário, você verá erros semelhantes aos que aparecem abaixo.
```
{"level":"FATAL","time":"2024-02-29T14:28:34.392Z","logger":"controller","message":"Checking EC2 API connectivity, WebIdentityErr: failed to retrieve credentials\ncaused by: RequestError: send request failed\ncaused by: Post \"https://sts..amazonaws.com/\": dial tcp 54.239.32.126:443: i/o timeout","commit":"596ea97"}
```
Essas mudanças são necessárias em um cluster privado porque o controlador Karpenter usa funções do IAM para contas de serviço (IRSA). Os pods configurados com o IRSA adquirem credenciais chamando a API do AWS Security Token Service (AWS STS). Se não houver acesso externo à Internet, você deverá criar e usar um endpoint VPC ** * AWS STS em sua VPC. * **
Os clusters privados também exigem que você crie um endpoint ** * VPC para SSM. * ** Quando o Karpenter tenta provisionar um novo nó, ele consulta as configurações do modelo Launch e um parâmetro SSM. Se você não tiver um endpoint SSM VPC em sua VPC, isso causará o seguinte erro:
```
{"level":"ERROR","time":"2024-02-29T14:28:12.889Z","logger":"controller","message":"Unable to hydrate the AWS launch template cache, RequestCanceled: request context canceled\ncaused by: context canceled","commit":"596ea97","tag-key":"karpenter.k8s.aws/cluster","tag-value":"eks-workshop"}
...
{"level":"ERROR","time":"2024-02-29T15:08:58.869Z","logger":"controller.nodeclass","message":"discovering amis from ssm, getting ssm parameter \"/aws/service/eks/optimized-ami/1.27/amazon-linux-2/recommended/image_id\", RequestError: send request failed\ncaused by: Post \"https://ssm..amazonaws.com/\": dial tcp 67.220.228.252:443: i/o timeout","commit":"596ea97","ec2nodeclass":"default","query":"/aws/service/eks/optimized-ami/1.27/amazon-linux-2/recommended/image_id"}
```
Não há endpoint de ** * VPC para a API de consulta da lista de [ preços. ](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/using-pelong.html) * ** Como resultado, os dados de preços ficarão obsoletos com o tempo. O Karpenter contorna isso incluindo dados de preços sob demanda em seu binário, mas só atualiza esses dados quando o Karpenter é atualizado. Solicitações falhadas de dados de preços resultarão nas seguintes mensagens de erro:
```
{"level":"ERROR","time":"2024-02-29T15:08:58.522Z","logger":"controller.pricing","message":"retreiving on-demand pricing data, RequestError: send request failed\ncaused by: Post \"https://api.pricing..amazonaws.com/\": dial tcp 18.196.224.8:443: i/o timeout; RequestError: send request failed\ncaused by: Post \"https://api.pricing..amazonaws.com/\": dial tcp 18.185.143.117:443: i/o timeout","commit":"596ea97"}
```
Consulte esta [ documentação ](https://karpenter.sh/docs/getting-started/getting-started-with-karpenter/#private-clusters) para usar o Karpenter em clusters EKS totalmente privados e para saber quais endpoints VPC devem ser criados.
## Criando NodePools
As práticas recomendadas a seguir abrangem tópicos relacionados à criação NodePools.
### Crie vários NodePools quando...
Quando equipes diferentes estiverem compartilhando um cluster e precisarem executar suas cargas de trabalho em diferentes nós de trabalho ou tiverem requisitos diferentes de sistema operacional ou tipo de instância, crie vários NodePools. Por exemplo, uma equipe pode querer usar o Bottlerocket, enquanto outra pode querer usar o Amazon Linux. Da mesma forma, uma equipe pode ter acesso a um hardware de GPU caro que não seria necessário para outra equipe. O uso de vários NodePools garante que os ativos mais apropriados estejam disponíveis para cada equipe.
### Crie NodePools que sejam mutuamente exclusivos ou ponderados
É recomendável criar NodePools que sejam mutuamente exclusivos ou ponderados para fornecer um comportamento de agendamento consistente. Se não estiverem e vários NodePools forem combinados, o Karpenter escolherá aleatoriamente qual usar, causando resultados inesperados. Exemplos úteis para criar vários NodePools incluem o seguinte:
Criando um NodePool com GPU e permitindo que cargas de trabalho especiais sejam executadas apenas nesses nós (caros):
```
# NodePool for GPU Instances with Taints
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
disruption:
consolidateAfter: 1m
consolidationPolicy: WhenEmptyOrUnderutilized
template:
metadata: {}
spec:
nodeClassRef:
group: karpenter.k8s.aws
kind: EC2NodeClass
name: default
expireAfter: Never
requirements:
- key: node.kubernetes.io/instance-type
operator: In
values:
- p3.8xlarge
- p3.16xlarge
- key: kubernetes.io/os
operator: In
values:
- linux
- key: kubernetes.io/arch
operator: In
values:
- amd64
- key: karpenter.sh/capacity-type
operator: In
values:
- on-demand
taints:
- effect: NoSchedule
key: nvidia.com/gpu
value: "true"
```
Implantação com tolerância à contaminação:
```
# Deployment of GPU Workload will have tolerations defined
apiVersion: apps/v1
kind: Deployment
metadata:
name: inflate-gpu
spec:
spec:
tolerations:
- key: "nvidia.com/gpu"
operator: "Exists"
effect: "NoSchedule"
```
Para uma implantação geral para outra equipe, a NodePool especificação pode incluir o NodeAffinity. Uma implantação poderia então usar o node SelectorTerms para combinar`billing-team`.
```
# NodePool for regular EC2 instances
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: generalcompute
spec:
template:
metadata:
labels:
billing-team: my-team
spec:
nodeClassRef:
group: karpenter.k8s.aws
kind: EC2NodeClass
name: default
expireAfter: Never
requirements:
- key: node.kubernetes.io/instance-type
operator: In
values:
- m5.large
- m5.xlarge
- m5.2xlarge
- c5.large
- c5.xlarge
- c5a.large
- c5a.xlarge
- r5.large
- r5.xlarge
- key: kubernetes.io/os
operator: In
values:
- linux
- key: kubernetes.io/arch
operator: In
values:
- amd64
- key: karpenter.sh/capacity-type
operator: In
values:
- on-demand
```
Implantação usando NodeAffinity:
```
# Deployment will have spec.affinity.nodeAffinity defined
kind: Deployment
metadata:
name: workload-my-team
spec:
replicas: 200
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: "billing-team"
operator: "In"
values: ["my-team"]
```
### Use temporizadores (TTL) para excluir automaticamente os nós do cluster
Você pode usar temporizadores em nós provisionados para definir quando excluir nós que estão desprovidos de pods de carga de trabalho ou que atingiram um prazo de validade. A expiração dos nós pode ser usada como um meio de atualização, para que os nós sejam retirados e substituídos por versões atualizadas. Consulte [ Expiração ](https://karpenter.sh/docs/concepts/disruption/) na documentação do Karpenter para obter informações sobre como usar para configurar `spec.template.spec` a expiração do nó.
### Evite restringir excessivamente os tipos de instância que o Karpenter pode provisionar, especialmente ao utilizar o Spot
Ao usar o Spot, a Karpenter usa a estratégia de [ alocação de capacidade otimizada de ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-allocation-strategy.html) preço para provisionar instâncias do EC2. Essa estratégia instrui o EC2 a provisionar instâncias dos pools mais profundos para o número de instâncias que você está iniciando e ter o menor risco de interrupção. O EC2 Fleet então solicita instâncias spot do menor preço desses pools. Quanto mais tipos de instância você permitir que o Karpenter utilize, melhor o EC2 poderá otimizar o tempo de execução da sua instância spot. Por padrão, a Karpenter usará todos os tipos de instância que o EC2 oferece na região e nas zonas de disponibilidade em que seu cluster está implantado. O Karpenter escolhe de forma inteligente entre o conjunto de todos os tipos de instâncias com base nos pods pendentes para garantir que seus pods sejam programados em instâncias equipadas e de tamanho adequado. Por exemplo, se seu pod não exigir uma GPU, o Karpenter não programará seu pod para um tipo de instância EC2 compatível com uma GPU. Quando não tiver certeza sobre quais tipos de instância usar, você pode executar o Amazon [ ec2-instance-selector ](https://github.com/aws/amazon-ec2-instance-selector) para gerar uma lista de tipos de instância que correspondam aos seus requisitos de computação. Por exemplo, a CLI usa memória, vCPU, arquitetura e região como parâmetros de entrada e fornece uma lista de instâncias do EC2 que satisfazem essas restrições.
```
$ ec2-instance-selector --memory 4 --vcpus 2 --cpu-architecture x86_64 -r ap-southeast-1
c5.large
c5a.large
c5ad.large
c5d.large
c6i.large
t2.medium
t3.medium
t3a.medium
```
Você não deve impor muitas restrições ao Karpenter ao usar instâncias Spot, pois isso pode afetar a disponibilidade de seus aplicativos. Digamos, por exemplo, que todas as instâncias de um tipo específico sejam recuperadas e não haja alternativas adequadas disponíveis para substituí-las. Seus pods permanecerão em um estado pendente até que a capacidade spot dos tipos de instância configurados seja reabastecida. Você pode reduzir o risco de erros de capacidade insuficiente distribuindo suas instâncias em diferentes zonas de disponibilidade, porque os pools spot são diferentes entre as AZs. Dito isso, a melhor prática geral é permitir que o Karpenter use um conjunto diversificado de tipos de instância ao usar o Spot.
## Pods de agendamento
As práticas recomendadas a seguir estão relacionadas à implantação de pods em um cluster usando o Karpenter para provisionamento de nós.
### Siga as melhores práticas do EKS para alta disponibilidade
Se você precisar executar aplicativos altamente disponíveis, siga as [ recomendações gerais de melhores práticas do EKS](https://docs.aws.amazon.com/eks/latest/best-practices/application.html#_recommendations). Consulte a documentação do [ Topology Spread ](https://karpenter.sh/docs/concepts/scheduling/#topology-spread) na Karpenter para obter detalhes sobre como distribuir pods entre nós e zonas. Use os orçamentos de [ interrupção ](https://karpenter.sh/docs/troubleshooting/#disruption-budgets) para definir os pods mínimos disponíveis que precisam ser mantidos, caso haja tentativas de despejar ou excluir pods.
### Use restrições em camadas para restringir os recursos de computação disponíveis no seu provedor de nuvem
O modelo de restrições em camadas da Karpenter permite que você crie um conjunto complexo de restrições de implantação de NodePool pods para obter as melhores combinações possíveis para o agendamento de pods. Exemplos de restrições que uma especificação de pod pode solicitar incluem o seguinte:
+ Precisa ser executado em zonas de disponibilidade nas quais somente aplicativos específicos estão disponíveis. Digamos, por exemplo, que você tenha um pod que precisa se comunicar com outro aplicativo executado em uma instância do EC2 que reside em uma zona de disponibilidade específica. Se seu objetivo é reduzir o tráfego cross-AZ em sua VPC, talvez você queira co-localizar os pods na AZ onde a instância do EC2 está localizada. Esse tipo de segmentação geralmente é realizado usando seletores de nós. Para obter informações adicionais sobre os seletores de [ nós](https://karpenter.sh/docs/concepts/scheduling/#selecting-nodes), consulte a documentação do Kubernetes.
+ Exigindo certos tipos de processadores ou outro hardware. Consulte a [ seção ](https://karpenter.sh/docs/concepts/scheduling/#acceleratorsgpu-resources) Aceleradores da documentação do Karpenter para ver um exemplo de especificação de pod que exige que o pod seja executado em uma GPU.
### Crie alarmes de cobrança para monitorar seus gastos com computação
Ao configurar seu cluster para escalar automaticamente, você deve criar alarmes de cobrança para avisá-lo quando seu gasto ultrapassar um limite e adicionar limites de recursos à sua configuração do Karpenter. Definir limites de recursos com o Karpenter é semelhante a definir a capacidade máxima de um grupo de escalonamento automático da AWS, pois representa a quantidade máxima de recursos computacionais que podem ser instanciados por um Karpenter. NodePool
**nota**
Não é possível definir um limite global para todo o cluster. Os limites se aplicam a determinados NodePools.
O trecho abaixo diz ao Karpenter para provisionar apenas um máximo de 1000 núcleos de CPU e 1000Gi de memória. O Karpenter deixará de adicionar capacidade somente quando o limite for atingido ou excedido. Quando um limite é excedido, o controlador Karpenter grava uma mensagem semelhante nos registros do controlador. `memory resource usage of 1001 exceeds limit of 1000` Se você estiver roteando seus registros de contêiner para CloudWatch registros, poderá criar um filtro de [ métricas ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) para procurar padrões ou termos específicos em seus registros e, em seguida, criar um [ CloudWatch alarme ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) para alertá-lo quando o limite de métricas configurado for violado.
Para obter mais informações sobre como usar limites com o Karpenter, consulte [ Definindo limites de recursos ](https://karpenter.sh/docs/concepts/nodepools/#speclimits) na documentação do Karpenter.
```
spec:
limits:
cpu: 1000
memory: 1000Gi
```
Se você não usar limites ou restringir os tipos de instância que a Karpenter pode provisionar, a Karpenter continuará adicionando capacidade computacional ao seu cluster conforme necessário. Embora a configuração do Karpenter dessa forma permita que seu cluster seja escalado livremente, ela também pode ter implicações de custo significativas. É por esse motivo que recomendamos a configuração de alarmes de cobrança. Os alarmes de cobrança permitem que você seja alertado e notificado proativamente quando as cobranças estimadas calculadas em sua (s) conta (s) excederem um limite definido. Consulte [ Configuração de um alarme de CloudWatch cobrança da Amazon para monitorar proativamente as cobranças estimadas ](https://aws.amazon.com/blogs/mt/setting-up-an-amazon-cloudwatch-billing-alarm-to-proactively-monitor-estimated-charges/) para obter informações adicionais.
Você também pode ativar a detecção de anomalias de custo, que é um recurso de gerenciamento de custos da AWS que usa aprendizado de máquina para monitorar continuamente seu custo e uso a fim de detectar gastos incomuns. Mais informações podem ser encontradas no [ guia de introdução à detecção de anomalias de custo da ](https://docs.aws.amazon.com/cost-management/latest/userguide/getting-started-ad.html) AWS. Se você chegou ao ponto de criar um orçamento nos orçamentos da AWS, também pode configurar uma ação para notificá-lo quando um limite específico for violado. Com as ações orçamentárias, você pode enviar um e-mail, publicar uma mensagem em um tópico do SNS ou enviar uma mensagem para um chatbot como o Slack. Para obter mais informações, consulte [ Configurando ações do AWS Budgets. ](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-controls.html)
### Use o karpenter. sh/do-not-interrompa a anotação para evitar que o Karpenter desprovisione um nó
Se você estiver executando um aplicativo crítico em um Karpenter-provisioned nó, como um trabalho em * lote de * longa execução ou um aplicativo com estado, * e * o TTL do nó tiver expirado, o aplicativo será interrompido quando a instância for encerrada. Ao adicionar uma `karpenter.sh/do-not-disrupt` anotação ao pod, você está instruindo Karpenter a preservar o nó até que o pod seja encerrado ou a anotação seja removida. `karpenter.sh/do-not-disrupt` Consulte a [ documentação ](https://karpenter.sh/docs/concepts/disruption/#node-level-controls) de destruição para obter mais informações.
Se os únicos pods que não são de daemonset restantes em um nó forem aqueles associados a trabalhos, o Karpenter poderá direcionar e encerrar esses nós, desde que o status do trabalho seja bem-sucedido ou falho.
### Configure solicitações=limites para todos os recursos que não são da CPU ao usar a consolidação
A consolidação e o agendamento em geral funcionam comparando as solicitações de recursos dos pods com a quantidade de recursos alocáveis em um nó. Os limites de recursos não são considerados. Por exemplo, os pods que têm um limite de memória maior do que a solicitação de memória podem ultrapassar a solicitação. Se vários pods no mesmo nó estourarem ao mesmo tempo, isso pode fazer com que alguns deles sejam encerrados devido a uma condição de falta de memória (OOM). A consolidação pode aumentar a probabilidade de isso ocorrer, pois funciona para empacotar pods em nós considerando apenas suas solicitações.
### Use LimitRanges para configurar padrões para solicitações e limites de recursos
Como o Kubernetes não define solicitações ou limites padrão, o consumo de recursos do host, da CPU e da memória subjacentes de um contêiner é ilimitado. O agendador do Kubernetes analisa o total de solicitações de um pod (quanto maior o total de solicitações dos contêineres do pod ou o total de recursos dos contêineres Init do pod) para determinar em qual node de trabalho programar o pod. Da mesma forma, Karpenter considera as solicitações de um pod para determinar qual tipo de instância ele provisiona. Você pode usar um intervalo limite para aplicar um padrão sensato para um namespace, caso as solicitações de recursos não sejam especificadas por alguns pods.
Consulte [ Configurar solicitações e limites de memória padrão para um namespace ](https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
### Aplique solicitações de recursos precisas a todas as cargas de trabalho
O Karpenter é capaz de iniciar nós que melhor se adaptam às suas cargas de trabalho quando as informações sobre os requisitos de suas cargas de trabalho são precisas. Isso é particularmente importante se estiver usando o recurso de consolidação do Karpenter.
Consulte [ Configurar e dimensionar o recurso Requests/Limits para todas as cargas de trabalho ](https://docs.aws.amazon.com/eks/latest/best-practices/data-plane.html#_recommendations)
## Recomendações do CoreDNS
### Atualize a configuração do CoreDNS para manter a confiabilidade
Ao implantar pods CoreDNS em nós gerenciados pela Karpenter, dada a natureza dinâmica da Karpenter em nós rapidamente terminating/creating novos para se alinhar à demanda, é aconselhável seguir as seguintes práticas recomendadas:
[Duração do CoreDNS lamduck ](https://docs.aws.amazon.com/eks/latest/best-practices/scale-cluster-services.html#_coredns_lameduck_duration)
[Sonda de prontidão CoreDNS ](https://docs.aws.amazon.com/eks/latest/best-practices/scale-cluster-services.html#_coredns_readiness_probe)
Isso garantirá que as consultas de DNS não sejam direcionadas a um pod CoreDNS que ainda não esteja pronto ou tenha sido encerrado.
## Plantas de Karpenter
Como a Karpenter adota uma abordagem que prioriza o aplicativo para provisionar capacidade computacional para o plano de dados do Kubernetes, há cenários comuns de carga de trabalho nos quais você pode estar se perguntando como configurá-los adequadamente. [O Karpenter Blueprints ](https://github.com/aws-samples/karpenter-blueprints) é um repositório que inclui uma lista de cenários comuns de carga de trabalho seguindo as melhores práticas descritas aqui. Você terá todos os recursos necessários até mesmo para criar um cluster EKS com o Karpenter configurado e testar cada um dos esquemas incluídos no repositório. Você pode combinar diferentes esquemas para finalmente criar o que você precisa para sua (s) carga (s) de trabalho.
## Recursos adicionais
+ [Workshop do Dia de Imersão em Karpenter ](https://catalog.workshops.aws/karpenter/en-US)
+ [Workshop de otimização de custos em Karpenter ](https://ec2spotworkshops.com/karpenter.html)
+ [Workshop EKS - Karpenter ](https://www.eksworkshop.com/docs/autoscaling/compute/karpenter/)
+ [Karpenter vs Cluster Autoscaler ](https://youtu.be/FIBc8GkjFU0)
+ [Sessão Karpenter no re:Invent 2023 ](https://youtu.be/lkg_9ETHeks)
+ [Tutorial: execute clusters Kubernetes por menos com o Amazon EC2 Spot e o Karpenter ](https://community.aws/tutorials/run-kubernetes-clusters-for-less-with-amazon-ec2-spot-and-karpenter#step-6-optional-simulate-spot-interruption)