Après avoir vu notre facture mensuelle AWS grimper constamment au fur et à mesure que nos charges de travail Kubernetes grandissaient, je savais que nous avions besoin d'une approche plus intelligente de la fourniture de nœuds. J'avais entendu parler de Karpenter, mais je ne l'avais pas essayé. Cet incident m'a poussé à le faire enfin. Dans ce guide, je vais partager comment j'ai construit un cluster EKS multi-architecture prêt à la production qui réduit nos coûts de calcul de 70% tout en rendant l'échelle presque instantanée. Le code source complet est disponible sur GitHub. Le code source complet est disponible sur GitHub. Passage de Cluster Autoscaler à Karpenter Réduisez les coûts de calcul de 70% en utilisant Spot + Graviton Réduction de la latence de programmation du pod de 3 minutes à 20 secondes Cluster multi-arch EKS intégré avec AMD64 + ARM64 Pipe Terraform + CI / CD complète sur GitHub L’autoscaling traditionnel Voici ce que je n'ai pas aimé au sujet de l'Autoscaler de cluster Kubernetes standard: j'aurais des pods assis dans l'état "Pending" pendant 2-3 minutes en attente de nouveaux nœuds, tout en payant pour un tas d'instances m5.large surprovisionnées qui atteignaient à peine 20% de l'utilisation de la CPU la plupart du temps. Je me souviens d'un incident particulièrement frustrant où un pic de trafic a frappé notre application à 2 heures du matin.L'autoscaler de cluster a pris plus de 4 minutes pour fournir de nouveaux nœuds, et par la suite nos utilisateurs ont eu des temps d'arrêt. Ce qui rend Karpenter différent, c’est qu’il ne pense pas en termes de groupes de nœuds fixes. Au lieu de cela, il regarde vos pods en attente et dit : « Ok, vous avez besoin de 2 vCPU et de 4 Go de RAM ? laissez-moi trouver l’instance spot la moins chère qui correspond à ces exigences. » Après la mise en œuvre, j'ai vu nos temps de fourniture de nœuds chuter de 3+ minutes à moins de 20 secondes.Et les économies de coûts - environ une réduction de 70% de notre facture de calcul, ce qui a libéré le budget pour d'autres améliorations de l'infrastructure. Notre architecture multifonctionnelle J’avais quelques applications PHP anciennes qui avaient besoin d’instances x86, mais je voulais aussi expérimenter avec les instances ARM64 Graviton pour nos microservices plus récents. L’architecture avec laquelle j’ai terminé est celle-ci : ┌─────────────────────────────────────────────────────────────┐
│                     EKS Cluster                             │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐          │
│  │   AMD64     │  │    ARM64    │  │  Karpenter  │          │
│  │  NodePool   │  │  NodePool   │  │ Controller  │          │
│  └─────────────┘  └─────────────┘  └─────────────┘          │
│                                                             │
│  ┌─────────────────────────────────────────────────────┐    │
│  │              Spot Instance Handling                 │    │
│  │    SQS Queue + EventBridge Rules                    │    │
│  └─────────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────────┘
 The architecture consists of several key components: VPC Infrastructure: Obtenir le réseau correct a été crucial. J'ai passé un certain temps à obtenir le tagging de sous-réseau parfait - ces balises karpenter.sh/discovery ne sont pas seulement agréables à avoir, elles sont essentielles pour Karpenter pour trouver vos sous-réseaux. J'ai oublié le tag karpenter.sh/discovery une fois - il a fallu une heure pour déboguer pourquoi il ne lancerait pas les nœuds. EKS Cluster: L'intégration des fournisseurs OIDC a probablement été la partie la plus difficile à obtenir correctement au début. C'est ce qui permet à Karpenter de parler en toute sécurité avec les APIs AWS sans codes d'identification durs. Karpenter Controller: C'est là que la magie se produit. Une fois déployé, il surveille constamment les pods non planifiés et fournit intelligemment les instances appropriées. Prise en charge de multi-architecture : disposer de pools de nœuds séparés pour AMD64 et ARM64 nous permet d’exécuter différentes charges de travail sur le matériel le plus rentable. Gestion des instances sur place: La gestion des interruptions m’a d’abord inquiété, mais l’intégration SQS d’AWS le rend étonnamment robuste. La structure terrestre qui fonctionne réellement Ma première tentative de structurer cela était un désordre. j'avais tout dans un seul géant Après quelques refactoring (et quelques nuits tardives), j'ai atterri sur cette approche modulaire: 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 Right (Réduire la fondation du réseau) La configuration du VPC m’a pris quelques itérations pour m’orienter.Le point de vue clé était que la stratégie d’étiquetage n’est pas seulement de la documentation – elle est fonctionnelle. 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 et Karpenter : le cœur du système La configuration de l'EKS était simple, mais obtenir le bon fournisseur de l'OIDC était crucial. C'est ce qui permet à Karpenter d'assumer les rôles de l'IAM en toute sécurité: 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
}
 Pour le déploiement de Karpenter, j'ai utilisé l'approche du diagramme Helm. Une chose que j'ai apprise est que vous devez d'abord installer les CRD, puis le diagramme principal. La configuration de la queue d'interruption était cruciale - c'est ce qui empêche vos charges de travail de se terminer brusquement lorsque les instances de spot sont récupérées: # 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
  }
}
 Architecture multiforme NodePools Au début, j’étais sceptique quant à ARM64. « Nos applications fonctionneront-elles même ? » Mais après quelques tests, j’ai constaté que nos services Node.js et Python fonctionnaient parfaitement sur les instances Graviton – souvent avec une meilleure performance par dollar. Voici comment j'ai configuré les pôles de nœuds: AMD64 avec 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 : l'expérience Graviton J'ai ajouté des taints pour empêcher les charges de travail incompatibles d'atterrir accidentellement sur les nœuds 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
 J'ai appris que spécifier des ID AMI exacts vous donne plus de contrôle sur ce qui est déployé, en particulier lors du test de différentes configurations ARM64. Vous pouvez également utiliser les exigences de nodeSelector pour cibler des architectures spécifiques sans avoir besoin de taints si vos applications sont conscientes de l'architecture. Des économies avec cette approche Avant Karpenter, nous exécutions un mélange d’instances à la demande sur plusieurs groupes de nœuds – environ 15-20 instances m5.large et c5.xlarge fonctionnant 24/7. Après avoir passé à Karpenter avec environ 70% d'utilisation d'instances spot, nos coûts de calcul mensuels ont chuté de 70%. Les avantages d’ARM64 Les instances ARM64 ont fourni un bonus supplémentaire. Au-delà des économies de coûts de ~20% par rapport aux instances x86 équivalentes, j'ai vu une meilleure performance sur certaines de nos charges de travail intensives en CPU. Voici ce que je vois typiquement à travers nos clusters: Réduction de 70% des coûts informatiques Scalage sous 20 secondes au lieu de minutes Une meilleure utilisation des ressources – pas plus de paiement pour les cycles de CPU inutiles Le suivi des performances a montré que nous avons passé d'une utilisation moyenne de 25% de la CPU sur nos nœuds fixes à une utilisation de 70% avec le dimensionnement à droite de Karpenter. Les leçons de production apprises Sécurité : IRSA est votre ami J'utilise IAM Roles for Service Accounts (IRSA) partout, ce qui signifie qu'il n'y a plus d'informations AWS hardcodées flottant dans notre 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"
          }
        }
      }
    ]
  })
}
 Surveillance Après quelques essais et erreurs, j'ai décidé de surveiller ces mesures clés.Trop de tableaux de bord deviennent bruyants, mais ces quatre me disent tout ce que je dois savoir sur la performance de notre cluster: karpenter_nodes_created_total: Les nœuds augmentent-ils quand ils devraient être? karpenter_nodes_terminated_total : Est-ce que les nœuds se réduisent de manière appropriée ? karpenter_pods_state: Les pods sont-ils programmés rapidement? karpenter_node_utilization : les instances sont-elles correctement dimensionnées ? Nous sommes allés de ~25% utilisation moyenne jusqu'à 70% après Karpenter a commencé à dimensionner nos instances. CD / CD Mon pipeline de déploiement est assez simple. j'utilise GitHub Actions avec l'authentification OIDC à AWS (pas plus de clés d'accès en secret!). 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 
 Ce que j’aime à propos de cette configuration, c’est la sélection dynamique de l’environnement et l’utilisation de variables GitHub pour différentes étapes. Step assure la cohérence du code dans toute notre équipe. terraform fmt -check Résumé J'ai eu quelques hiccups initiales avec des interruptions d'instance spot (protip: assurez-vous que vos applications gèrent SIGTERM gracieusement), et obtenir les charges de travail ARM64 correctement a pris une certaine itération. Mais les résultats parlent d’eux-mêmes.Nous mettons en œuvre une infrastructure plus résiliente et rentable qui évolue de manière intelligente.Les économies de coûts considérables seuls ont payées pour le temps d’ingénierie que j’ai consacré à cette migration au cours du premier mois. Si vous avez affaire à des charges de travail imprévisibles, à la hausse des factures AWS, ou si vous voulez simplement essayer quelque chose qui ressemble à "l'avenir de Kubernetes", je vous recommande vivement de donner un coup de pouce à Karpenter. La mise en œuvre complète est disponible sur J'ai inclus tous les modules Terraform, des scripts de test et un guide de dépannage basé sur les problèmes auxquels j'ai été confronté. 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

Cet audio est produit dans la langue originale de l'histoire !

Comment réduire les coûts de calcul AWS de 70% avec un cluster EKS Multi-Arch et Karpenter

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Valhalla de Floki se joint en tant que sponsor associé de la tournée indienne au Sri Lanka

Les couches invisibles : pourquoi les entretiens avec les utilisateurs sont un atout irremplaçable

Le modèle Bitcoin UTXO, alimentant un écosystème unique

Libérer la puissance de l’IA. Une revue systématique des techniques de pointe : résumé et introduction

Valhalla de Floki se joint en tant que sponsor associé de la tournée indienne au Sri Lanka

Les couches invisibles : pourquoi les entretiens avec les utilisateurs sont un atout irremplaçable

Le modèle Bitcoin UTXO, alimentant un écosystème unique

Libérer la puissance de l’IA. Une revue systématique des techniques de pointe : résumé et introduction

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps