Después de ver nuestra factura mensual de AWS subir constantemente a medida que crecían nuestras cargas de trabajo de Kubernetes, supe que necesitábamos un enfoque más inteligente para el suministro de nodos. Había oído hablar de Karpenter, pero no lo había probado.Este incidente me impulsó a darle finalmente un disparo.En esta guía, voy a compartir cómo construí un clúster EKS multi-arquitectura listo para la producción que redujo nuestros costes de computación en un 70% al tiempo que hacía que la escalación fuera casi instantánea. El código fuente completo está disponible en GitHub. El código fuente completo está disponible en . GitHub Cambio de Cluster Autoscaler a Karpenter Reduce los costos de computación en un 70% con Spot + Graviton Reducción de la latencia de programación del pod de 3 minutos a 20 segundos Clúster multi-arco construido con AMD64 + ARM64 Pipe Terraform + CI / CD completo en GitHub Descargar Autoscaling Tradicional Aquí está lo que no me gustó del Kubernetes Cluster Autoscaler estándar: Tendría pods sentados en el estado "Pending" durante 2-3 minutos esperando nuevos nodos, mientras que pagaba por un montón de instancias m5.large sobreprovisionadas que apenas golpeaban el 20% de la utilización de la CPU la mayor parte del tiempo. Recuerdo un incidente particularmente frustrante donde un pico de tráfico golpeó nuestra aplicación a las 2 de la mañana.El autoscaler de clúster tomó más de 4 minutos para proporcionar nuevos nodos, y por entonces nuestros usuarios estaban recibiendo temporadas. Lo que hace que Karpenter sea diferente es que no piensa en términos de grupos de nodos fijos. En cambio, mira a sus pods pendentes y dice: "Ok, ¿necesitas 2 vCPUs y 4GB de RAM? Después de implementarlo, vi que nuestros tiempos de provisión del nodo cayeron de 3+ minutos a menos de 20 segundos.Y el ahorro de costes - aproximadamente una reducción del 70% en nuestra factura de computación, lo que liberó el presupuesto para otras mejoras de infraestructura. Nuestra arquitectura multidimensional Una cosa que me impresionó sobre Karpenter fue la facilidad con la que manejaba nuestros requisitos de carga de trabajo mixta.Tenía algunas aplicaciones PHP antiguas que necesitaban instancias x86, pero también quería experimentar con instancias de ARM64 Graviton para nuestros microservicios más recientes. La arquitectura con la que terminé es la siguiente: ┌─────────────────────────────────────────────────────────────┐
│                     EKS Cluster                             │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐          │
│  │   AMD64     │  │    ARM64    │  │  Karpenter  │          │
│  │  NodePool   │  │  NodePool   │  │ Controller  │          │
│  └─────────────┘  └─────────────┘  └─────────────┘          │
│                                                             │
│  ┌─────────────────────────────────────────────────────┐    │
│  │              Spot Instance Handling                 │    │
│  │    SQS Queue + EventBridge Rules                    │    │
│  └─────────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────────┘
 The architecture consists of several key components: Infraestructura de VPC: Obtener la red correcta fue crucial. Pasé algún tiempo obteniendo la etiqueta de subred perfecta - esas etiquetas de karpenter.sh/discovery no son sólo buenas para tener, son esenciales para que Karpenter encuentre sus subredes. Olvidé la etiqueta karpenter.sh/discovery una vez - tomó una hora para deshabilitar por qué no lanzaría nodos. EKS Cluster: La integración de los proveedores de OIDC fue probablemente la parte más difícil de conseguirlo inicialmente. Es lo que permite a Karpenter hablar de forma segura con las APIs de AWS sin credenciales de código duro. Controlador Karpenter: Aquí es donde ocurre la magia.Una vez desplegado, constantemente vigila los pods no programados y provee de forma inteligente las instancias correctas. Soporte para múltiples arquitecturas: Tener puertos de nodos separados para AMD64 y ARM64 nos permite ejecutar diferentes cargas de trabajo en el hardware más rentable. Gestión de instancias de punto: El manejo de interrupciones era algo que inicialmente me preocupaba, pero la integración de SQS de AWS lo hace sorprendentemente robusto. La estructura terrestre que realmente funciona Mi primer intento de estructurar esto fue un caos.Tengo todo en un gigante Después de un poco de refactoring (y unas pocas noches tardías), aterrizé en este enfoque 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: Obtener la Fundación de Redes Derecho La configuración de VPC me tomó unas pocas iteraciones para obtener la corrección.La idea clave fue que la estrategia de etiquetado no es solo documentación, es 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 y Karpenter: El corazón del sistema La configuración de EKS fue sencilla, pero obtener el proveedor OIDC correcto fue crucial. Esto es lo que permite a Karpenter asumir los roles de IAM de forma segura: 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 la implementación de Karpenter, fui con el enfoque del gráfico de Helm. Una cosa que aprendí es que necesitas instalar primero los CRDs, luego el gráfico principal. La configuración de la cola de interrupción fue crucial – es lo que evita que tus cargas de trabajo se terminen abruptamente cuando se recuperan las instancias spot: # 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
  }
}
 Arquitectura Multi-NodePools Inicialmente, estaba escéptico acerca de ARM64. "¿Todavía funcionarán nuestras aplicaciones?", pero después de algunas pruebas, encontré que nuestros servicios Node.js y Python funcionaban perfectamente en las instancias de Graviton, a menudo con un mejor rendimiento por dólar. Aquí está cómo configuré los nodos polares: Procesador 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: El experimento gravitón La configuración de ARM64 requiere un poco más de reflexión. he añadido tonos para evitar que cargas de trabajo incompatibles aterrizen accidentalmente en los nodos de 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
 He aprendido que especificar ID AMI exactos le da más control sobre lo que se implementa, especialmente cuando se prueban diferentes configuraciones de ARM64. También puede utilizar los requisitos de nodeSelector para orientarse a arquitecturas específicas sin necesidad de taints si sus aplicaciones son conscientes de la arquitectura. Ahorro de costes con este método Antes de Karpenter, estábamos ejecutando una mezcla de instancias on-demand en varios grupos de nodos: alrededor de 15-20 instancias de m5.large y c5.xlarge funcionaban 24/7. Después de cambiar a Karpenter con aproximadamente el 70% de uso de instancias spot, nuestros costes mensuales de computación disminuyeron en un 70%; esto es una reducción significativa que liberó un presupuesto sustancial para nuevas características y mejoras de infraestructura. Beneficios del ARM64 Las instancias ARM64 proporcionaron un bono adicional. Más allá de los ahorros de costes del ~20% en comparación con las instancias x86 equivalentes, vi un mejor rendimiento en algunas de nuestras cargas de trabajo intensivas en CPU. Aquí está lo que normalmente veo a través de nuestros clústeres: Reducción del 70% en costes de computación Sub-20 segundos de escala en lugar de minutos Mejora de la utilización de los recursos: no pagar más por ciclos de CPU inútiles El seguimiento del rendimiento mostró que pasamos de un uso promedio del 25% de la CPU en nuestros nodos fijos a un uso del 70% con el tamaño correcto de Karpenter. Lecciones de producción aprendidas Seguridad: IRSA es tu amigo Utilizo IAM Roles for Service Accounts (IRSA) en todas partes, lo que significa que no hay más credenciales AWS codificadas flotando en nuestro clúster: 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"
          }
        }
      }
    ]
  })
}
 Monitorización Después de un poco de ensayo y error, me fijé en monitorear estas métricas clave.Muchos dashboards se vuelven ruidosos, pero estos cuatro me dicen todo lo que necesito saber sobre el rendimiento de nuestro cluster: karpenter_nodes_created_total: ¿Los nodos se escalan cuando deben ser? karpenter_nodes_terminated_total: ¿Los nodos se reducen adecuadamente? karpenter_pods_state: ¿Se están programando los pods rápidamente? karpenter_node_utilization: ¿Las instancias son correctamente dimensionadas? La métrica de utilización del nodo fue particularmente abriendo los ojos. Pasamos de ~25% de utilización media hasta el 70% después de que Karpenter comenzó a dimensionar correctamente nuestras instancias. CI / CD Yo uso GitHub Actions con autenticación OIDC a AWS (no más claves de acceso en secretos!). 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 
 Lo que me gusta de esta configuración es la selección dinámica del entorno y el uso de variables de GitHub para diferentes etapas. El paso garantiza la coherencia del código en todo nuestro equipo. terraform fmt -check Resumen He tenido algunos hiccups iniciales con interrupciones de instancia de punto (protip: asegúrese de que sus aplicaciones manejen SIGTERM graciosamente), y obtener las cargas de trabajo de ARM64 correctas tomó alguna iteración. Pero los resultados hablan por sí mismos.Estamos ejecutando una infraestructura más resiliente y rentable que escala de manera inteligente.Los ahorros sustanciales en costos solo pagaron por el tiempo de ingeniería que pasé en esta migración dentro del primer mes. Si está tratando con cargas de trabajo impredecibles, aumentando las facturas de AWS, o simplemente quiere probar algo que se sienta como "el futuro de Kubernetes", definitivamente recomendaría darle a Karpenter un disparo. La implementación completa está disponible en He incluido todos los módulos de Terraform, los scripts de prueba y una guía de resolución de problemas basada en los problemas en los que me encontré. ¡Siéntate libre de usarlo como punto de partida para tu propia implementación - y déjame saber cómo va! 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 audio es producido en el idioma original de la historia!

Cómo reducir los costos de computación de AWS en un 70% con un clúster EKS de múltiples arcos y Karpenter

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Valhalla de Floki se une como patrocinador asociado de la gira de la India por Sri Lanka

De los foros a los feeds: cómo los algoritmos de las redes sociales influyen en la interacción digital

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Crecimiento de las criptomonedas: creación de perfiles de usuarios eficaces

Valhalla de Floki se une como patrocinador asociado de la gira de la India por Sri Lanka

De los foros a los feeds: cómo los algoritmos de las redes sociales influyen en la interacción digital

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

Crecimiento de las criptomonedas: creación de perfiles de usuarios eficaces

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps