Depois de assistir a nossa fatura mensal da AWS subir consistentemente à medida que as nossas cargas de trabalho da Kubernetes cresciam, eu sabia que precisávamos de uma abordagem mais inteligente para a provisão de nós. Eu tinha ouvido falar de Karpenter, mas eu não tinha tentado.Este incidente me levou a finalmente dar um tiro.Neste guia, eu vou compartilhar como eu construí um cluster EKS multi-arquitetura pronto para produção que reduziu nossos custos de computação em 70% ao mesmo tempo que tornou a escalação quase instantânea. O código fonte completo está disponível no GitHub. O código fonte completo está disponível em . GitHub Mudança do Cluster Autoscaler para Karpenter Reduza os custos de computação em 70% usando o Spot + Graviton Redução da latência de agendamento do pod de 3 min a 20 segundos Cluster multi-arch construído com AMD64 + ARM64 Total Terraform + CI / CD pipeline no GitHub Dicas de Autoscaling tradicional Aqui está o que eu não gostei sobre o Kubernetes Cluster Autoscaler padrão: eu teria pods sentado no estado "Pending" por 2-3 minutos esperando por novos nós, enquanto pagava por um monte de instâncias m5.large que estavam apenas atingindo 20% da utilização da CPU a maior parte do tempo. Eu me lembro de um incidente particularmente frustrante onde um pico de tráfego atingiu nosso aplicativo às 2 da manhã. O cluster autoscaler levou mais de 4 minutos para fornecer novos nós, e até então nossos usuários estavam recebendo timeouts. O que torna o Karpenter diferente é que ele não pensa em termos de grupos de nós fixos. Em vez disso, olha para seus pods pendentes e diz: "OK, você precisa de 2 vCPUs e 4GB de RAM? Depois de implementá-lo, vi nosso tempo de provisão de nós cair de 3+ minutos para menos de 20 segundos.E a poupança de custos – cerca de uma redução de 70% em nossa conta de computação, o que liberou o orçamento para outras melhorias de infraestrutura. Nossa arquitetura multifacetada Eu tinha alguns aplicativos PHP legados que precisavam de instâncias x86, mas eu também queria experimentar com instâncias ARM64 Graviton para nossos microservices mais recentes. A arquitetura com a qual terminamos é assim: ┌─────────────────────────────────────────────────────────────┐
│                     EKS Cluster                             │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐          │
│  │   AMD64     │  │    ARM64    │  │  Karpenter  │          │
│  │  NodePool   │  │  NodePool   │  │ Controller  │          │
│  └─────────────┘  └─────────────┘  └─────────────┘          │
│                                                             │
│  ┌─────────────────────────────────────────────────────┐    │
│  │              Spot Instance Handling                 │    │
│  │    SQS Queue + EventBridge Rules                    │    │
│  └─────────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────────┘
 The architecture consists of several key components: Infraestrutura de VPC: Obter a rede certa foi crucial. Passei algum tempo obtendo a marcação de sub-rede perfeita - essas tags de karpenter.sh/discovery não são apenas agradáveis, elas são essenciais para a Karpenter encontrar suas sub-redes. Esqueci a tag karpenter.sh/discovery uma vez - levou uma hora para depurar por que não lançaria nós. EKS Cluster: A integração do provedor OIDC foi provavelmente a parte mais difícil de se obter bem inicialmente. É o que permite que a Karpenter converse com segurança com as APIs da AWS sem credenciais de código rígido. Controlador Karpenter: É aqui que a magia acontece.Uma vez implantado, ele constantemente vigia por pods não agendados e fornece inteligentemente as instâncias certas. Suporte multi-arquitetura: Ter pools de nós separados para AMD64 e ARM64 nos permite executar cargas de trabalho diferentes no hardware mais rentável. Spot Instance Management: O gerenciamento de interrupções era algo que eu estava preocupado inicialmente, mas a integração SQS da AWS o torna surpreendentemente robusto. A estrutura de terraforma que realmente funciona Minha primeira tentativa de estruturar isso foi uma bagunça. eu tinha tudo em um gigante Depois de algum refactoring (e algumas noites tardias), eu desci nesta abordagem modular: main.tf ├── eks-module/            # EKS cluster creation
├── karpenter/             # Karpenter autoscaler setup
├── vpc/                   # VPC infrastructure
├── root/                  # Main Terraform execution
└── .github/workflows/     # CI/CD pipeline
 VPC: Getting the Networking Foundation Direito A configuração do VPC levou-me algumas iterações para ficar certo.O insight chave foi que a estratégia de etiquetagem não é apenas documentação – é funcional. Here's what I learned works: resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr_block
  enable_dns_support   = true
  enable_dns_hostnames = true
  
  tags = {
    Name                                        = "${var.project_name}-vpc"
    "kubernetes.io/cluster/${var.project_name}" = "shared"
  }
}

resource "aws_subnet" "private_subnets" {
  # ... configuration
  tags = {
    Name                              = "private-subnet-${count.index}"
    "karpenter.sh/discovery"          = var.project_name
    "kubernetes.io/role/internal-elb" = "1"
  }
}
 EKS e Karpenter: O coração do sistema A configuração do EKS foi simples, mas ter o provedor OIDC certo foi crucial. Isto é o que permite que Karpenter assuma os papéis do IAM com segurança: resource "aws_eks_cluster" "project" {
  name     = var.cluster_name
  role_arn = aws_iam_role.cluster_role.arn

  vpc_config {
    subnet_ids              = var.private_subnet_ids
    endpoint_private_access = true
    endpoint_public_access  = true
  }

  access_config {
    authentication_mode = "API"
  }
}

resource "aws_iam_openid_connect_provider" "eks" {
  client_id_list  = ["sts.amazonaws.com"]
  thumbprint_list = [data.tls_certificate.eks.certificates[0].sha1_fingerprint]
  url             = aws_eks_cluster.project.identity[0].oidc[0].issuer
}
 Para a implantação do Karpenter, fui com a abordagem do gráfico Helm. Uma coisa que aprendi é que você precisa instalar os CRDs primeiro, depois o gráfico principal. A configuração da fila de interrupção foi crucial – é o que impede que suas cargas de trabalho sejam repentinamente encerradas quando as instâncias spot são recuperadas: # Install CRDs first
resource "helm_release" "karpenter_crd" {
  name       = "karpenter-crd"
  chart      = "oci://public.ecr.aws/karpenter/karpenter-crd"
  version    = var.karpenter_version
  namespace  = var.namespace
}

# Then install the main Karpenter chart
resource "helm_release" "karpenter" {
  depends_on = [helm_release.karpenter_crd]
  
  name       = "karpenter"
  chart      = "oci://public.ecr.aws/karpenter/karpenter"
  version    = var.karpenter_version
  namespace  = var.namespace

  set {
    name  = "settings.clusterName"
    value = var.cluster_name
  }
  
  set {
    name  = "settings.aws.interruptionQueueName"
    value = aws_sqs_queue.karpenter_interruption_queue.name
  }
  
  set {
    name  = "serviceAccount.annotations.eks\\.amazonaws\\.com/role-arn"
    value = var.controller_role_arn
  }
}
 Arquitetura NodePools Inicialmente, eu estava cético sobre o ARM64. "Nossos aplicativos até funcionarão?" Mas depois de algumas testes, eu descobri que nossos serviços Node.js e Python funcionavam perfeitamente em instâncias Graviton - muitas vezes com melhor desempenho por dólar. Aqui está como eu configuro os pools de nós: Descrição do AMD64 NodePool apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: amd64-nodepool
spec:
  template:
    spec:
      requirements:
      - key: kubernetes.io/arch
        operator: In
        values: ["amd64"]
      - key: karpenter.sh/capacity-type
        operator: In
        values: ["spot", "on-demand"]
      - key: node.kubernetes.io/instance-type
        operator: In
        values: ["m5.large", "m5.xlarge", "c5.large", "c5.xlarge"]
  limits:
    cpu: 1000
  disruption:
    consolidationPolicy: WhenEmpty
    consolidateAfter: 1m
 ARM64 NodePool: O Experimento Gravitônico A configuração do ARM64 requer um pouco mais de pensamento. adicionei taints para evitar que cargas de trabalho incompatíveis acidentalmente pousem nos nós do ARM64: apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: arm64-nodepool
spec:
  template:
    spec:
      requirements:
      - key: kubernetes.io/arch
        operator: In
        values: ["arm64"]
      - key: node.kubernetes.io/instance-type
        operator: In
        values: ["t4g.medium", "c6g.large", "m6g.large"]
      taints:
      - key: arm64
        value: "true"
        effect: NoSchedule
 Eu aprendi que especificar IDs AMI exatos dá-lhe mais controle sobre o que é implantado, especialmente quando testando diferentes configurações ARM64. Você também pode usar os requisitos do nodeSelector para direcionar arquiteturas específicas sem precisar de taints se seus aplicativos são arquitetura consciente. Poupança de custos com essa abordagem Antes de Karpenter, estávamos executando uma mistura de instâncias on-demand em vários grupos de nós – cerca de 15-20 instâncias de m5.large e c5.xlarge em execução 24/7. Depois de mudar para Karpenter com cerca de 70% de uso de instância spot, nossos custos mensais de computação caíram em 70%. Benefícios do ARM64 As instâncias ARM64 forneceram um bônus adicional.Além da economia de custos de ~20% em comparação com instâncias x86 equivalentes, vi um melhor desempenho em algumas das nossas cargas de trabalho intensivas em CPU. Aqui está o que eu normalmente vejo em nossos aglomerados: Redução de 70% nos custos de computação Sub-20-segundos de escala em vez de minutos Melhor utilização de recursos – não pague mais por ciclos de CPU inúteis O monitoramento de desempenho mostrou que passamos de uma média de 25% de utilização da CPU em nossos nós fixos a uma utilização de 70% com o dimensionamento direito da Karpenter. Lições de produção aprendidas Segurança: o IRSA é seu amigo Eu uso IAM Roles for Service Accounts (IRSA) em todos os lugares, o que significa que não há mais credenciais da AWS com código rígido flutuando em nosso cluster: resource "aws_iam_role" "karpenter_controller" {
  name = "KarpenterController-${var.cluster_name}"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRoleWithWebIdentity"
        Effect = "Allow"
        Principal = {
          Federated = var.oidc_provider_arn
        }
        Condition = {
          StringEquals = {
            "${replace(var.oidc_provider_url, "https://", "")}:sub" = "system:serviceaccount:karpenter:karpenter"
          }
        }
      }
    ]
  })
}
 Monitorização Depois de alguns ensaios e erros, resolvi monitorar essas métricas-chave.Muitos painéis tornam-se ruídos, mas estes quatro me dizem tudo o que preciso saber sobre o desempenho do nosso cluster: karpenter_nodes_created_total: Os nós estão escalando quando devem ser? karpenter_nodes_terminated_total: Os nós estão escalando adequadamente? karpenter_pods_state: Os pods estão sendo agendados rapidamente? karpenter_node_utilization: As instâncias estão sendo dimensionadas corretamente? A métrica de utilização do nó foi particularmente óbvia. passamos de ~25% de utilização média para 70% depois que Karpenter começou a dimensionar nossas instâncias. Cão / CD Eu uso GitHub Actions com autenticação OIDC para AWS (não mais chaves de acesso em segredo!). name: Terraform Deploy

on: 
  push:
    branches:
    - 'feature/**'
    - 'staging'
    - 'main'
  workflow_dispatch:

permissions:
  id-token: write # Required for OIDC JWT
  contents: read  # Required for checkout

jobs: 
  deploy:
    environment: ${{ (github.ref == 'refs/heads/main' && 'prod') || (github.ref == 'refs/heads/staging' && 'staging') || 'dev' }}
    runs-on: ubuntu-22.04
    
    defaults:
      run:
        working-directory: root/
        
    steps:
    - name: Clone repo
      uses: actions/checkout@v3
    
    - name: Configure AWS Credentials
      uses: aws-actions/configure-aws-credentials@v4
      with: 
        aws-region: us-east-1
        role-to-assume: ${{ vars.IAM_Role }}
        role-session-name: gha-assignment-session

    - name: Initialize Terraform
      run: terraform init -backend-config="bucket=${{ vars.TF_STATE_BUCKET }}"

    - name: Terraform Plan
      run: terraform plan -input=false -var-file=${{ vars.STAGE }}.tfvars 
    
    - name: Terraform Apply
      run: terraform apply -auto-approve -input=false -var-file=${{ vars.STAGE }}.tfvars 
 O que eu gosto sobre esta configuração é a seleção de ambiente dinâmico e o uso de variáveis GitHub para diferentes estágios. O passo garante a consistência do código em toda a nossa equipe. terraform fmt -check Resumo Eu tive alguns hiccups iniciais com interrupções de instância spot (protip: certifique-se de que seus aplicativos lidem com SIGTERM graciosamente), e obter as cargas de trabalho ARM64 certo levou alguma iteração. Mas os resultados falam por si mesmos.Estamos executando uma infraestrutura mais resiliente e rentável que escala de forma inteligente.A poupança substancial de custos sozinha pagou pelo tempo de engenharia que gastei nesta migração dentro do primeiro mês. Se você está lidando com cargas de trabalho imprevisíveis, aumentando as contas da AWS, ou apenas quer experimentar algo que se sinta como "o futuro do Kubernetes", eu definitivamente recomendaria dar a Karpenter um tiro. A implementação completa está disponível em Eu incluí todos os módulos Terraform, scripts de teste e um guia de resolução de problemas com base nos problemas que eu encontrei. GitHub

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

Read My Stories

Este áudio é produzido no idioma original da história!

Como reduzir os custos de computação da AWS em 70% com um cluster e Karpenter da Multi-Arch EKS

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

Aumente sua produtividade com estas 18 ferramentas para desenvolvedores 🚀🔥

Toque para ganhar: Telegram pode integrar os próximos 10 bilhões de usuários criptográficos antes de Solana

Modelo Bitcoin UTXO, alimentando um ecossistema único

Valhalla de Floki se junta como patrocinador associado da viagem da Índia ao Sri Lanka

Aumente sua produtividade com estas 18 ferramentas para desenvolvedores 🚀🔥

Toque para ganhar: Telegram pode integrar os próximos 10 bilhões de usuários criptográficos antes de Solana

Modelo Bitcoin UTXO, alimentando um ecossistema único

Valhalla de Floki se junta como patrocinador associado da viagem da Índia ao Sri Lanka

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps