Nachdem ich beobachtet hatte, wie unsere monatliche AWS-Rechnung stetig steigt, als unsere Kubernetes-Workloads wuchsen, wusste ich, dass wir einen intelligenteren Ansatz zur Knotenversorgung benötigten. In diesem Leitfaden werde ich teilen, wie ich einen produktionsfertigen, multi-architektur EKS-Cluster gebaut habe, der unsere Rechenkosten um 70% senkt und gleichzeitig das Skalieren nahezu sofort macht. Der vollständige Quellcode ist auf GitHub verfügbar. Der vollständige Quellcode ist verfügbar . Github Wechsel von Cluster Autoscaler zu Karpenter Reduzieren Sie die Rechenkosten um 70% mit Spot + Graviton Reduzierte Pod-Planungslatenz von 3 Minuten auf 20 Sekunden Integrierter Multi-Arch EKS Cluster mit AMD64 + ARM64 Vollständige Terraform + CI/CD Pipeline auf GitHub Traditionelles Autoskaling Hier ist, was mir am Standard-Kubernetes-Cluster-Autoscaler nicht gefiel: Ich hätte Pods, die 2-3 Minuten lang im "Pending" -Zustand saßen und auf neue Knoten warteten, während ich für eine Reihe von übermäßig ausgestatteten m5.großen Instanzen bezahlte, die die meiste Zeit kaum 20% der CPU-Nutzung erreichten. Ich erinnere mich an einen besonders frustrierenden Vorfall, in dem um 2 Uhr morgens ein Traffic-Spike unsere App getroffen hat.Der Cluster-Autoscaler dauerte mehr als 4 Minuten, um neue Knoten bereitzustellen, und bis dahin bekamen unsere Benutzer Timeouts. Was Karpenter unterscheidet, ist, dass es nicht in Bezug auf feste Knotengruppen denkt. stattdessen betrachtet es Ihre abhängigen Pods und sagt: "OK, Sie benötigen 2 vCPUs und 4 GB RAM? Nachdem ich es implementiert hatte, sah ich, dass unsere Node-Bereitstellungszeiten von 3+ Minuten auf weniger als 20 Sekunden sinken und die Kosteneinsparungen – etwa eine 70%ige Reduzierung unserer Rechnung, die das Budget für andere Infrastrukturverbesserungen freigab. Unser Multi-Architektur Setup Ich hatte einige veraltete PHP-Anwendungen, die x86-Instanzen benötigten, aber ich wollte auch mit ARM64 Graviton-Instanzen für unsere neueren Microservices experimentieren. Die Architektur, mit der ich endete, sieht so aus: ┌─────────────────────────────────────────────────────────────┐
│                     EKS Cluster                             │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐          │
│  │   AMD64     │  │    ARM64    │  │  Karpenter  │          │
│  │  NodePool   │  │  NodePool   │  │ Controller  │          │
│  └─────────────┘  └─────────────┘  └─────────────┘          │
│                                                             │
│  ┌─────────────────────────────────────────────────────┐    │
│  │              Spot Instance Handling                 │    │
│  │    SQS Queue + EventBridge Rules                    │    │
│  └─────────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────────┘
 The architecture consists of several key components: VPC-Infrastruktur: Die richtige Vernetzung war entscheidend. Ich habe einige Zeit damit verbracht, das Subnetz-Tagging perfekt zu machen - diese karpenter.sh/discovery-Tags sind nicht nur schön zu haben, sie sind für Karpenter wichtig, um Ihre Subnetze zu finden. EKS Cluster: Die OIDC-Provider-Integration war wahrscheinlich der schwierigste Teil, um anfangs richtig zu werden. Karpenter Controller: Hier geschieht die Magie.Einmal eingesetzt, beobachtet es ständig ungeplante Pods und bietet intelligent die richtigen Instanzen. Multi-Architektur-Unterstützung: Mit getrennten Knotenpools für AMD64 und ARM64 können wir unterschiedliche Workloads auf der kosteneffizientesten Hardware ausführen. Spot Instance Management: Das Unterbrechungsmanagement war etwas, worüber ich mich zunächst Sorgen machte, aber die SQS-Integration von AWS macht es überraschend robust. Die Terraform-Struktur, die tatsächlich funktioniert Mein erster Versuch, dies zu strukturieren, war ein Chaos.Ich hatte alles in einem Riesen Nach einigen Refaktoring (und ein paar späte Nächte), landete ich auf diesem modularen Ansatz: 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 Richtig Die VPC-Einstellung nahm mir ein paar Iterationen, um richtig zu werden.Der Schlüsselwissen war, dass die Tagging-Strategie nicht nur Dokumentation ist - sie ist funktional. 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 und Karpenter: Das Herz des Systems Die EKS-Einstellung war einfach, aber es war entscheidend, den OIDC-Anbieter richtig zu bekommen. Dies ist, was es Karpenter ermöglicht, IAM-Rollen sicher zu übernehmen: 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
}
 Für die Karpenter-Implementierung ging ich mit dem Helm-Chart-Ansatz.Eine Sache, die ich gelernt habe, ist, dass Sie zuerst die CRDs installieren müssen, dann das Hauptchart.Die Einstellung der Unterbrechungsschlange war entscheidend - es ist das, was verhindert, dass Ihre Workloads plötzlich beendet werden, wenn Spot-Instances zurückgefordert werden: # 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
  }
}
 Multi-Architektur NodePools Zuerst war ich skeptisch zu ARM64. „Wollen unsere Anwendungen überhaupt funktionieren?“ Aber nach einigen Tests fand ich heraus, dass unsere Node.js- und Python-Dienste auf Graviton-Instanzen perfekt laufen – oft mit besserer Leistung pro Dollar. So habe ich die Node Pools eingerichtet: AMD64 für 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: Das Graviton-Experiment Ich habe Taints hinzugefügt, um zu verhindern, dass inkompatible Workloads versehentlich auf ARM64-Knoten landen: 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
 Ich habe gelernt, dass die Angabe genauer AMI-IDs Ihnen mehr Kontrolle darüber gibt, was eingesetzt wird, insbesondere beim Testen verschiedener ARM64-Konfigurationen. Kosteneinsparungen mit diesem Ansatz Vor Karpenter laufen wir eine Mischung von On-Demand-Instanzen über mehrere Knotengruppen – etwa 15-20 m5.große und c5.xlarge-Instanzen, die 24/7 laufen. Nach dem Wechsel auf Karpenter mit etwa 70% Spot-Instance-Nutzung sank unsere monatlichen Rechenkosten um 70%. Das ist eine signifikante Reduzierung, die ein erhebliches Budget für neue Funktionen und Infrastrukturverbesserungen freigab. Die Vorteile von ARM64 Neben den ~20% Kosteneinsparungen im Vergleich zu gleichwertigen x86-Instanzen sah ich bei einigen unserer CPU-intensiven Workloads eine bessere Leistung. Hier ist, was ich typischerweise in unseren Clustern sehe: 70 % Reduzierung der Computerkosten Sub-20-Sekunden Skalierung statt Minuten Bessere Ressourcennutzung – keine Zahlung für leere CPU-Zyklen mehr Die Leistungsüberwachung zeigte, dass wir von einer durchschnittlichen CPU-Auslastung von 25% auf unseren fixen Knoten bis zu einer Auslastung von 70% mit Karpenter's Right-Sizeing gegangen sind. Produktionsunterricht gelernt Sicherheit: IRSA ist Ihr Freund Ich verwende überall IAM Roles for Service Accounts (IRSA), was bedeutet, dass in unserem Cluster keine mehr hardcodierten AWS-Anmeldeinformationen herumschwimmen: 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"
          }
        }
      }
    ]
  })
}
 Überwachung Nach einigen Versuchen und Fehlern setzte ich mich auf die Überwachung dieser Schlüsselmetriken ein. Zu viele Dashboards werden zu Lärm, aber diese vier sagen mir alles, was ich über unsere Clusterleistung wissen muss: karpenter_nodes_created_total: Werden Knoten erhöht, wenn sie sein sollten? karpenter_nodes_terminated_total: Werden die Knoten angemessen skaliert? karpenter_pods_state: Werden Pods schnell geplant? karpenter_node_utilization: Werden Instanzen in der richtigen Größe verwendet? Wir gingen von ~25% Durchschnittsnutzung bis zu 70% nachdem Karpenter begann, unsere Instanzen richtig zu dimensionieren. Sie / CD Ich benutze GitHub Actions mit OIDC-Authentifizierung für AWS (keine weiteren Zugriffsschlüssel in Geheimnissen!). Der Workflow unterstützt Funktionszweige für die Entwicklung, Staging für die Prüfung und Main für die Produktion: 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 
 Was mir an dieser Installation gefällt, ist die dynamische Umweltwahl und die Verwendung von GitHub-Variablen für verschiedene Stufen. Schritt sorgt für Code-Konsistenz in unserem Team. terraform fmt -check Zusammenfassung Ich hatte einige anfängliche Hiccups mit Spot-Instance-Unterbrechungen (protip: stellen Sie sicher, dass Ihre Anwendungen SIGTERM graziös handhaben), und die ARM64-Arbeitsbelastungen richtig zu bekommen, dauerte einige Iteration. Aber die Ergebnisse sprechen für sich.Wir betreiben eine widerstandsfähigere, kostengünstigere Infrastruktur, die intelligent skaliert.Die erheblichen Kosteneinsparungen allein haben sich für die Ingenieurzeit bezahlt, die ich innerhalb des ersten Monats auf diese Migration verbrachte. Wenn Sie mit unvorhersehbaren Workloads zu tun haben, steigende AWS-Rechnungen oder einfach nur etwas ausprobieren möchten, das sich wie "die Zukunft von Kubernetes" anfühlt, würde ich definitiv empfehlen, Karpenter einen Schuss zu geben. Die vollständige Umsetzung ist verfügbar Ich habe alle Terraform-Module, Testskripte und einen Fehlerbehebungsleitfaden auf der Grundlage der Probleme aufgenommen, mit denen ich konfrontiert bin. 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

Dieses Audio ist in der Originalsprache der Geschichte produziert!

Wie ich die AWS-Compute-Kosten mit einem Multi-Arch-EKS-Cluster und Karpenter um 70% senke

About Author

KOMMENTARE

Hängeetiketten

DIESER ARTIKEL WURDE VORGESTELLT IN

Related Stories

HackerNoon Decoded 2024: Wir feiern unsere Gaming-Community!

Starting 2025 with New Features: Settings Dashboard, HackerNoon Decoded, Updated Search UI, and More

HackerNoon Decoded 2024: Celebrating Our AI Community!

HackerNoon Decoded 2024: Wir feiern die Community unserer Technologieunternehmen!

HackerNoon Decoded 2024: Wir feiern unsere Gaming-Community!

Starting 2025 with New Features: Settings Dashboard, HackerNoon Decoded, Updated Search UI, and More

HackerNoon Decoded 2024: Celebrating Our AI Community!

HackerNoon Decoded 2024: Wir feiern die Community unserer Technologieunternehmen!

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps