월간 AWS 청구서가 Kubernetes 워크로드가 증가함에 따라 꾸준히 상승하는 것을 보았을 때, 우리는 노드 공급에 대한 더 똑똑한 접근 방식을 필요로한다는 것을 알았습니다.전통적인 클러스터 자동 스케일링은 과도한 공급 노드가 앉아있는 예산을 통해 불타고 있었고, 여전히 용량이 필요할 때 영원히 확장 할 필요가있었습니다. 나는 Karpenter에 대해 들었지만 시도하지 않았습니다.그 사건은 마침내 그것을 촬영하도록 저를 밀어 냈습니다.이 가이드에서, 나는 확장 거의 즉각적인 동시에 우리의 컴퓨팅 비용을 70% 절감하는 생산 준비, 멀티 아키텍처 EKS 클러스터를 구축하는 방법을 공유 할 것입니다. 전체 소스 코드는 GitHub에서 사용할 수 있습니다. 전체 소스 코드가 사용할 수 있습니다 on . Github Cluster Autoscaler에서 Karpenter로 전환 스팟 + Graviton을 사용하여 70%의 컴퓨팅 비용 절감 3 분에서 20 초까지 짧은 pod 스케줄링 지연 시간 AMD64 + ARM64와 함께 구축 된 멀티 아크 EKS 클러스터 GitHub에서 완전한 Terraform + CI/CD 파이프라인 전통적인 Autoscaling 일반 Kubernetes 클러스터 자동 스케일러에 대해 내가 좋아하지 않는 것은 다음과 같습니다 : 나는 새로운 노드를 기다리는 2-3 분 동안 ""상태에 앉아있는 팟을 가지고 있었고, 대부분의 시간 동안 CPU 사용량의 20 %를 거의 칠하지 않은 과도한 m5.large 인스턴스의 무리를 지불했습니다. 오전 2시에 트래픽이 우리의 앱에 도달 한 특히 좌절스러운 사건을 기억합니다.클러스터 오토 스케일러는 새로운 노드를 제공하는 데 4 분 이상 걸렸고, 그때까지 사용자들은 타임 아웃을 받았습니다. Karpenter가 다른 것은 고정 노드 그룹의 관점에서 생각하지 않는다는 것입니다.그 대신, 그것은 당신의 기다리고있는 pods를보고 "OK, 당신은 2 vCPU와 4GB RAM을 필요로합니까?이 요구 사항에 맞는 가장 저렴한 스팟 인스턴스를 찾을 수 있습니다."그것은 실제로 당신의 워크로드 패턴을 이해하는 정말로 똑똑한 공급 보조자가있는 것과 같습니다. 그것을 구현 한 후에, 나는 우리의 노드 공급 시간을 3 분 이상에서 20 초 이하로 감소시켰다.그리고 비용 절감 - 우리의 컴퓨팅 청구서의 약 70 % 감소, 다른 인프라 개선을위한 예산을 해방. 우리의 다중 아키텍처 설계 Karpenter에 대해 나에게 인상적이었던 것은 그것이 우리의 혼합 된 워크로드 요구 사항을 얼마나 쉽게 처리했는지였습니다.나는 x86 인스턴스를 필요로하는 몇 가지 오래된 PHP 응용 프로그램을 가지고 있었지만 새로운 마이크로 서비스에 대한 ARM64 Graviton 인스턴스를 실험하고 싶었습니다. 내가 끝냈던 아키텍처는 이렇게 생겼다: ┌─────────────────────────────────────────────────────────────┐
│                     EKS Cluster                             │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐          │
│  │   AMD64     │  │    ARM64    │  │  Karpenter  │          │
│  │  NodePool   │  │  NodePool   │  │ Controller  │          │
│  └─────────────┘  └─────────────┘  └─────────────┘          │
│                                                             │
│  ┌─────────────────────────────────────────────────────┐    │
│  │              Spot Instance Handling                 │    │
│  │    SQS Queue + EventBridge Rules                    │    │
│  └─────────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────────┘
 The architecture consists of several key components: VPC 인프라: 네트워크를 올바르게 만드는 것이 중요했습니다. subnet 태그를 완벽하게 만드는 데 시간이 걸렸습니다. karpenter.sh/discovery 태그는 단순히 좋은 것이 아니라 Karpenter가 당신의 subnet을 찾는 데 필수적입니다. EKS 클러스터: OIDC 공급자 통합은 아마도 처음에 올바른 부분이었을 것입니다.Karpenter는 하드코딩 된 인증서없이 AWS API와 안전하게 대화를 할 수 있습니다. Karpenter 컨트롤러: 이것이 마법이 일어나는 곳입니다.일단 배포하면 일정이없는 pods를 지속적으로 모니터링하고 올바른 인스턴스를 지능적으로 제공합니다. 다중 아키텍처 지원: AMD64 및 ARM64에 대한 별도의 노드 풀을 사용하면 가장 비용 효율적인 하드웨어에서 다른 워크로드를 실행할 수 있습니다. 스팟 인스턴스 관리: 중단 처리는 내가 처음에 걱정했던 것이었지만 AWS의 SQS 통합은 놀랍게도 강력합니다. 실제로 작동하는 Terraform 구조 이것을 구조화하려는 나의 첫 번째 시도는 혼란이었다.나는 하나의 거인에 모든 것을 가지고있었습니다. 일부 재현 후 (그리고 늦은 밤 몇 번), 나는이 모듈적인 접근법에 착륙 : main.tf ├── eks-module/            # EKS cluster creation
├── karpenter/             # Karpenter autoscaler setup
├── vpc/                   # VPC infrastructure
├── root/                  # Main Terraform execution
└── .github/workflows/     # CI/CD pipeline
 VPC : 네트워킹 기초를 올바르게 얻기 VPC 설정은 나에게 옳은 것을 얻기 위해 몇 번의 반복을 필요로했습니다.The key insight was that the tagging strategy is not just documentation – it’s functional. 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와 Karpenter : 시스템의 심장 EKS 설정은 간단했지만 OIDC 공급자를 올바르게 얻는 것이 중요했습니다.이것은 Karpenter가 IAM 역할을 안전하게 수행 할 수있는 것입니다. 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 배포를 위해 Helm 차트 접근법을 사용했습니다. 하나의 방법은 CRD를 먼저 설치해야 하며, 다음은 메인 차트를 설치해야 한다는 것입니다.interruption queue setup는 중요했습니다.It's what prevents your workloads from getting abruptly terminated when spot instances are reclaimed. # 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
  }
}
 다중 아키텍처 NodePools 처음에는 ARM64에 대해 의심스러웠습니다. "우리의 응용 프로그램은 실제로 작동합니까?"하지만 몇 가지 테스트 후에 Node.js 및 Python 서비스가 Graviton 인스턴스에서 완벽하게 작동했음을 발견했습니다. 이것은 내가 노드 폴을 설정하는 방법입니다 : AMD64 노드 폴 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: Graviton 실험 ARM64 설치는 약간 더 많은 생각을 필요로 합니다.I added taints to prevent incompatible workloads from accidentally landing on ARM64 nodes: 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
 정확한 AMI ID를 지정하면 다양한 ARM64 구성을 테스트할 때 특히 배포되는 것에 대한 더 많은 통제력을 제공한다는 것을 알게되었습니다.You can also use nodeSelector requirements to target specific architectures without needing taints if your applications are architecture-aware. 이 방법으로 비용 절감 Karpenter 이전에는 여러 노드 그룹에 걸쳐 수요상 인스턴스의 혼합을 실행하고 있었는데, 이는 약 15-20m5.large 및 c5.xlarge 인스턴스가 24/7. 약 70%의 스팟 인스턴스 사용으로 Karpenter로 전환한 후, 우리의 월간 컴퓨팅 비용은 70% 감소했습니다.이것은 새로운 기능과 인프라 개선에 대한 상당한 예산을 자유롭게하는 중요한 감소입니다. ARM64의 장점 ARM64 인스턴스는 추가 보너스를 제공했습니다. x86 인스턴스에 비해 ~20%의 비용 절감 이외에 CPU 집중적인 워크로드 중 일부에서 더 나은 성능을 보았습니다. 다음은 우리가 일반적으로 우리의 클러스터를 통해 볼 수있는 것입니다 : 70% 컴퓨팅 비용 절감 분 대신 20초 미만 스케일링 더 나은 리소스 사용 – 더 이상 빈번한 CPU 사이클을 지불하지 않음 성능 모니터링은 우리가 Karpenter의 오른쪽 크기를 사용하여 고정 노드에서 평균 25% CPU 사용량에서 70% 사용량으로 갔음을 보여주었습니다. 배운 생산 교훈 보안: IRSA는 당신의 친구입니다 IAM Roles for Service Accounts (IRSA)는 모든 곳에서 사용되며, 이는 클러스터에서 더 이상 하드코딩된 AWS 인증서가 움직이지 않는다는 것을 의미합니다. 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"
          }
        }
      }
    ]
  })
}
 감시 몇 가지 시도와 실수 후, 나는 이러한 핵심 매개 변수를 모니터링하기로 결정했다.더 많은 대시보드가 소음이되었지만,이 4 개는 내가 클러스터 성능에 대해 알아야 할 모든 것을 말합니다 : karpenter_nodes_created_total: 노드가 언제 해야 하는가? karpenter_nodes_terminated_total : 노드가 적절하게 확장되는가? karpenter_pods_state: 팟이 빨리 예약되나요? karpenter_node_utilization: 인스턴스가 올바른 크기입니까? 노드 사용 측정은 눈을 뜨게 했습니다.우리는 ~25% 평균 사용에서부터 Karpenter가 우리의 인스턴스를 올바르게 크기 시작한 후에 70%로 갔습니다. CD / CD GitHub Actions with OIDC authentication to AWS (no more access keys in secrets!).The workflow supports feature branches for development, staging for testing, and main for production: 내 배포 파이프라인은 매우 간단합니다. 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 
 이 설치에 대해 내가 좋아하는 것은 동적 환경 선택과 다른 단계에서 GitHub 변수를 사용하는 것입니다. step는 팀 전체에서 코드 일관성을 보장합니다. terraform fmt -check 요약 나는 스포트 인스턴스 중단 (protip: 귀하의 응용 프로그램이 SIGTERM을 우아하게 처리하도록하십시오)과 ARM64 워크로드를 올바르게 얻는 데 약간의 반복이 필요했습니다.I had some initial hiccups with spot instance interruptions (protip: make sure your applications handle SIGTERM gracefully), and getting the ARM64 workloads right took some iteration. 그러나 결과는 스스로를 말합니다.우리는 똑똑하게 규모를 확장하는 더 탄력적이고 비용 효율적인 인프라를 실행하고 있습니다.상당한 비용 절감만이 첫 달 내에이 마이그레이션에 사용한 엔지니어링 시간을 지불했습니다. 예측할 수없는 워크로드를 다루고 있거나 AWS 요금이 상승하고 있거나 "쿠버네티스의 미래"처럼 느껴지는 무언가를 시도하고 싶다면, 나는 확실히 Karpenter에게 샷을 제공하는 것이 좋습니다. 완전한 구현은 사용할 수 있습니다 on 모든 Terraform 모듈, 테스트 스크립트 및 내가 겪은 문제를 기반으로 한 문제 해결 가이드를 포함했습니다. 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

이 오디오는 이야기의 원래 언어로 제작되었습니다!

Multi-Arch EKS 클러스터와 Karpenter를 사용하여 AWS 컴퓨팅 비용을 70% 절감하는 방법

About Author

코멘트

태그 걸기

이 기사는 다음에서 발표되었습니다.

Related Stories

이 18가지 개발자 도구로 생산성을 높이세요 🚀🔥

바다 항해: 데이터 레이크를 사용하여 프로덕션 등급 RAG 애플리케이션 개발

사용자 중심의 암호화 제품 만들기: 고객 피드백의 중요성

AI/ML 데이터레이크용 참조 아키텍처 구축을 위한 설계자 가이드

이 18가지 개발자 도구로 생산성을 높이세요 🚀🔥

바다 항해: 데이터 레이크를 사용하여 프로덕션 등급 RAG 애플리케이션 개발

사용자 중심의 암호화 제품 만들기: 고객 피드백의 중요성

AI/ML 데이터레이크용 참조 아키텍처 구축을 위한 설계자 가이드

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps