Aylık AWS faturamızın Kubernetes iş yüklerimizin büyüdüğünde sürekli yükseldiğini izledikten sonra, düğme tedarikine daha akıllı bir yaklaşım gerektiğini biliyordum.Geleneksel kümelenme otomatik ölçeklenmesi bütçemizi yaktı ve aşırı tedarikli düğümler boş kaldı, ancak kapasiteye ihtiyaç duyduğumda daima ölçeklenmeye devam etti. Karpenter hakkında duymuştum, ama denememiştim.Bu olay sonunda bir atış yapmamı sağladı.Bu kılavuzda, hesaplama maliyetlerimizi neredeyse anında ölçüm yaparken% 70 oranında azaltan üretime hazır, çok mimari EKS kümesini nasıl inşa edeceğimi paylaşacağım. Tüm kaynak kodları GitHub’da mevcuttur. Tüm kaynak kodları mevcuttur . GitHub için Cluster Autoscaler'dan Karpenter'a geçiş Spot + Graviton ile %70 hesaplama maliyetlerini azaltın 3 dakikadan 20 saniyeye kısaltılmış pod programlama gecikmesi AMD64 + ARM64 ile oluşturulan multi-arch EKS kümesi Tam Terraform + CI / CD pipeline GitHub'da Geleneksel Autoscaling Standart Kubernetes Cluster Autoscaler'da beğenmediklerim şunlardır: Yeni düğmeleri bekleyen 2-3 dakika boyunca "Pending" durumunda otoparklarım vardı, çoğu zaman CPU kullanımının% 20'sini asla vurmayan çok fazla sağlanan m5.büyük bir sürü için ödeme yaparken. Sabah 2'de bir trafik artışı uygulamamızı vurduğunda özellikle hayal kırıklığına uğrayan bir olayı hatırlıyorum.Kluster autoscaler yeni düğümleri sağlamak için 4 dakikadan fazla sürdü ve o zamana kadar kullanıcılarımız zaman kaybetti. Karpenter'ı farklı kılan şey, sabit düğüm grupları açısından düşünmemesidir. Bunun yerine, bekleyen pods'larınızı inceler ve "OK, 2 vCPU'ya ve 4 GB RAM'a ihtiyacınız var mı? Bu gereksinimleri karşılayacak en ucuz spot örneğini bulayım." Uygulamayı uyguladıktan sonra, düğme tedarik süremizin 3+ dakikadan 20 saniyeye kadar düştüğünü gördüm. ve maliyet tasarrufu - bilgisayar faturamızda yaklaşık% 70 azalma, bu da diğer altyapı geliştirmeleri için bütçeyi serbest bıraktı. Multi-Architectural Tasarımımız Karpenter hakkında beni etkileyen bir şey, karışık iş yük gereksinimlerimizi ne kadar kolayca ele aldı. x86 örneğine ihtiyaç duyan bazı eski PHP uygulamaları vardı, ancak yeni microservicesimiz için de ARM64 Graviton örneğiyle deneyimlemek istedim. Benimle bitirdiğim mimarlık şu şekildedir: ┌─────────────────────────────────────────────────────────────┐
│                     EKS Cluster                             │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐          │
│  │   AMD64     │  │    ARM64    │  │  Karpenter  │          │
│  │  NodePool   │  │  NodePool   │  │ Controller  │          │
│  └─────────────┘  └─────────────┘  └─────────────┘          │
│                                                             │
│  ┌─────────────────────────────────────────────────────┐    │
│  │              Spot Instance Handling                 │    │
│  │    SQS Queue + EventBridge Rules                    │    │
│  └─────────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────────┘
 The architecture consists of several key components: VPC Altyapısı: Doğru ağ oluşturmak çok önemliydi. alt ağ etiketlemeyi mükemmel hale getirmek için biraz zaman harcadım - bu karpenter.sh/discovery etiketleri sadece güzel değil, Karpenter'ın alt ağlarınızı bulması için önemlidir. bir kez karpenter.sh/discovery etiketini unuttum - neden düğmeleri başlatmayacağını düzeltmek bir saat sürdü. EKS Cluster: OIDC sağlayıcı entegrasyonu muhtemelen başlangıçta doğru gitmek için en zor kısmıydı. Karpenter Controller: Sihirbazın gerçekleştiği yer burası. bir kez dağıtıldıktan sonra, sürekli olarak planlanmamış pods'ları izler ve akıllıca doğru örnekleri sağlar. Multi-Architecture Desteği: AMD64 ve ARM64 için ayrı düğme havuzları olması, farklı çalışma yüklerini en maliyetli donanım üzerinde çalıştırmamızı sağlar. Spot Örnek Yönetimi: Başlangıçta endişelendiğim bir şeydi, ancak AWS'in SQS entegrasyonu şaşırtıcı derecede sağlam hale getiriyor. Gerçekten Çalışan Terraform Yapısı Bu yapılandırmaya ilk denemem bir karışıklık oldu.Bir devde her şeyi vardı. Bazı refactoring (ve birkaç geç gece) sonra, ben bu modüler yaklaşım üzerine düştü: main.tf ├── eks-module/            # EKS cluster creation
├── karpenter/             # Karpenter autoscaler setup
├── vpc/                   # VPC infrastructure
├── root/                  # Main Terraform execution
└── .github/workflows/     # CI/CD pipeline
 VPC: Networking Foundation Hakkı Almak VPC ayarlaması bana doğru gitmek için birkaç iterasyon aldı.Anahtar anlayış, etiketleme stratejisinin sadece belgelendirme olmadığını - işlevsel olduğunu. 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 ve Karpenter: Sistemin Kalbi EKS kurulumu basitti, ancak OIDC sağlayıcısını doğru bulmak çok önemliydi. İşte Karpenter'ın IAM rollerini güvenle üstlenmesine olanak sağlayan şey: 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
}
 Karpenter dağıtımı için, Helm grafik yaklaşımı ile gittim. Öğrendim bir şey CRD'leri ilk önce, sonra ana grafik kurmanız gerektiğidir. kesinti sırası kurulum çok önemliydi - iş yüklerinizin aniden sona ermesini engellediği şey, spot örneği geri alınırken: # 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-Architecture NodePools Hakkında Başlangıçta, ARM64 hakkında şüpheciydim. "Ağrı uygulamalarımız bile çalışacak mı?"Ama bazı testlerden sonra, Node.js ve Python hizmetlerimizin Graviton örneğinde mükemmel çalıştığını gördüm - genellikle dolar başına daha iyi performansla. İşte Node Pools'u nasıl kurdum: AMD64 NodePool Özellikleri 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: The Graviton Deney ARM64 kurulumunun biraz daha düşünülmesi gerekmektedir. uyumsuz çalışma yüklerini ARM64 düğmeleri üzerinde yanlışlıkla yerleştirmemesini önlemek için bozukluklar ekledim: 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
 Tam AMI kimliklerini belirtmek, özellikle de farklı ARM64 yapılandırmalarını test ederken neyi dağıtmanız üzerinde daha fazla kontrol sağladığınızı öğrendim. ayrıca uygulamalarınızın mimarisi bildikleri takdirde belirli mimarileri hedeflemek için nodeSelector gereksinimlerini de kullanabilirsiniz. Bu yaklaşımla maliyet tasarrufu Karpenter'dan önce, birden fazla düğme grubunda bir karışım on-demand örneğini çalıştırdık - yaklaşık 15-20 m5.large ve c5.xlarge örneğini 24/7. Yaklaşık %70 spot instance kullanımıyla Karpenter'a geçtikten sonra aylık hesaplama maliyetlerimiz %70 azaldı.Bu, yeni özellikler ve altyapı geliştirmeleri için önemli bir bütçe tasarrufu sağlayan önemli bir azalma. ARM64 Avantajları ARM64 varsayımları ek bir bonus sağladı. eşit x86 varsayımlarına kıyasla %20 maliyet tasarrufu ötesinde, bazı CPU yoğun çalışma yüklerimizde daha iyi performans gördüm. örneğin, görüntü işleme hizmetimiz Graviton varsayımlarında yaklaşık %15 daha hızlı çalıştı. İşte tipik olarak kümelerimizde gördüğüm şeyler: Bilgisayar maliyetlerinin %70 oranında azaltılması Dakikalar yerine 20 saniye boyutlandırma Daha iyi kaynak kullanımı - boş CPU döngüleri için daha fazla ödeme Performans izleme, sabit düğmelerdeki ortalama% 25 CPU kullanımından Karpenter'ın sağ boyutlama ile% 70 kullanımına kadar gittiğini gösterdi. Öğrenilen üretim dersleri Etiket: IRSA senin arkadaşın Her yerde IAM Roles for Service Accounts (IRSA) kullanıyorum, bu da clusterimizde daha fazla hardcoded AWS kimlik bilgileri dolaşmaması anlamına gelir: 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"
          }
        }
      }
    ]
  })
}
 İzleme Biraz deneme ve hata yaptıktan sonra, bu anahtar ölçütleri izlemeye karar verdim.Çok fazla kontrol paneli gürültüye dönüşüyor, ancak bu dört şey klavye performansımız hakkında bilmem gereken her şeyi bana anlatıyor: karpenter_nodes_created_total: düğümler ne zaman büyüyecek? karpenter_nodes_terminated_total: düğümler uygun bir şekilde ölçekleniyor mu? karpenter_pods_state: Pods hızlı bir şekilde planlanıyor mu? karpenter_node_utilization: Örnekler doğru boyutlandırılır mı? Karpenter örneklerimizi düz boyutlandırmaya başladıktan sonra% 25 ortalama kullanımdan% 70'e kadar gittik. CD / CD GitHub Actions'i AWS'e OIDC kimlik doğrulama ile kullanıyorum (daha fazla erişim anahtarları gizli değil!). Çalışma akışı, geliştirme, test için sahneye çıkma ve üretim için ana özellikler desteklemektedir: 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 
 Bu kurulumda sevdiğim şey, dinamik ortam seçimi ve farklı aşamalar için GitHub değişkenlerinin kullanımıdır. Step, tüm ekibimizde kod tutarlılığını sağlar. terraform fmt -check Özetle Biraz başlangıç hiccups vardı spot instance kesintileri (protip: uygulamalarınızın SIGTERM şık bir şekilde işlemek emin olun), ve ARM64 iş yüklerini doğru almak bazı iterasyon aldı. Ancak sonuçlar kendileri için konuşur. Daha dayanıklı, maliyet verimli bir altyapı çalışıyor ve akıllı bir şekilde ölçekleniyor. Tek başına önemli maliyet tasarrufu, ilk ay içinde bu geçişe harcadığım mühendislik süresinin maliyeti. Tahmin edilemez çalışma yükleriyle uğraşırsanız, AWS faturalarının artmasıyla uğraşırsanız veya sadece “Kubernetes’in geleceği” gibi hissettiren bir şey denemek istiyorsanız, Karpenter’a bir atış yapmanızı kesinlikle tavsiye ederim. Tam uygulaması mevcuttur Tüm Terraform modüllerini, test senaryolarını ve karşılaştığım sorunlara dayanan bir sorun giderme kılavuzunu dahil ettim. Kendi uygulamanız için bir başlangıç noktası olarak kullanmaktan çekinmeyin - ve nasıl gittiğini bana bildirin! GitHub için

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

Bu ses hikayenin orijinal dilinde üretilmiştir!

Multi-Arch EKS Cluster ve Karpenter ile AWS Hesaplama maliyetlerini %70 oranında nasıl düşürdüm

About Author

YORUMLAR

ETİKETLERİ ASIN

BU YAZI

Related Stories

Benzersiz Bir Ekosistemi Güçlendiren Bitcoin UTXO Modeli

Forumlardan Feed'lere: Sosyal Medya Algoritmaları Dijital Etkileşimi Nasıl Şekillendiriyor

Claude Sonnet 3.5 Sistem Bilgi Sızıntısı: Adli Analiz

Sulara Yelken Açmak: Data Lakes ile Üretim Sınıfında RAG Uygulamaları Geliştirme

Benzersiz Bir Ekosistemi Güçlendiren Bitcoin UTXO Modeli

Forumlardan Feed'lere: Sosyal Medya Algoritmaları Dijital Etkileşimi Nasıl Şekillendiriyor

Claude Sonnet 3.5 Sistem Bilgi Sızıntısı: Adli Analiz

Sulara Yelken Açmak: Data Lakes ile Üretim Sınıfında RAG Uygulamaları Geliştirme

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps