私たちのKubernetesのワークロードが成長するにつれて、毎月のAWSの請求書がどんどん上昇しているのを見た後、ノードプロビジョニングのよりスマートなアプローチが必要だと知りました。 私はKarpenterについて聞いたことがありますが、試したことはありませんでした。その出来事は、ようやくショットをあげるように私を促しました。このガイドでは、私は、コンピューティングコストを70%削減し、スケーリングをほぼ瞬時に実現するプロダクションの準備ができ、複数のアーキテクチャ EKSクラスターを構築する方法を共有します。 完全なソースコードはGitHubで入手できます。 完全なソースコードはこちらで入手できます。 . GitHub Cluster AutoscalerからKarpenterに切り替えました。 コンピューティングコストをスポット+Gravitonを使用して70%削減 Pod スケジュールの遅延を 3 分から 20 秒に減らす AMD64 + ARM64で構築されたマルチアーキ EKSクラスター Full Terraform + CI/CD パイプライン on GitHub 伝統的な自動スケーリング 標準のKubernetes Cluster Autoscalerについて私は気に入らなかったこと:私は新しいノードを待つために2〜3分間「傾いている」状態に座っているポットを持っていたが、ほとんどの時間にCPUの利用率20%をほぼ打ち負かす超過供給されたm5.大インスタンスのバンドを支払っていた。 特に、トラフィックのピークが午前2時に当社のアプリに当たった一例を思い出します。クラスタ・オートスケーラーは新しいノードを提供するのに4分以上かかり、その時点で当社のユーザーはタイムアウトを得ていました。 Karpenter が異なるのは、固定ノードグループの観点から考えないということです。代わりに、あなたが待っているポッドを見て、「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 インフラストラクチャ:ネットワークを正しく作ることは重要でした. 私はサブネットのタグ化を完璧にするためにしばらく時間を費やしました - karpenter.sh/discovery タグは、Karpenter があなたのサブネットを見つけるために必要不可欠です。 EKS Cluster: OIDC プロバイダーの統合は、おそらく最初に正解を得るために最も困難な部分でした。それは、Karpenter がハードコードされた認証情報なしで、AWS API と安全に話すことを可能にするものです。 Karpenter Controller:ここで魔法が起こります. 一度展開すると、予定されていないポッドを常に監視し、正しいインスタンスをスマートに提供します。 複数のアーキテクチャのサポート:AMD64とARM64のための別々のノードプールを持つことで、最もコスト効率の高いハードウェアで異なるワークロードを実行できます。 スポットインスタンス管理:中断処理は、最初は心配していましたが、AWS の SQS 統合により驚くほど強力です。 実際に機能するテラフォーム構造 私の最初の構造化の試みは混乱でした. I had everything in one giant. いくつかのリファクタリング(そしていくつかの夜遅く)、私はこのモジュールアプローチに着陸しました: 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(ネットワーク財団の権利を得る) 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 and Karpenter: The Heart of the System (エクスとカルペンター:システムのハート) 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 デプロイに関しては、ヘルム チャートアプローチで行きました。私が学んだことの一つは、まず CRD をインストールし、次にメイン チャートをインストールする必要があります。 # 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 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: The Graviton Experiment(ノードポール:グラビトン実験) 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 の異なる構成をテストする際には、何が展開されるのかをよりコントロールできます。 このアプローチでコストを節約 Karpenter 以前は、複数のノードグループにわたってオンデマンドインスタンスの組み合わせを実行していました - 約 15-20 m5.large と c5.xlarge インスタンスが 24/7. 約70%のスポットインスタンス使用量でKarpenterに切り替えた後、毎月のコンピューティングコストは70%減少しました。 ARM64の利点 ARM64 インスタンスは追加のボーナスを提供しました。 同等の x86 インスタンスと比較して ~20% のコスト節約を超えて、私たちの CPU 密集したワークロードのいくつかでより良いパフォーマンスを見ました。 以下は、我々のクラスターを通して通常見るもの: コンピュータコストの70%削減 20秒未満のスケーリング 代わりに数分 より良いリソース利用 — 無駄な CPU サイクルに支払う必要はありません パフォーマンスモニタリングでは、固定ノードの平均25%のCPU利用から、Karpenterの右サイズ利用で70%の利用まで進みました。 生産学習レッスン セキュリティ:IRSA Is Your Friend 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"
          }
        }
      }
    ]
  })
}
 監視 いくつかの試行錯誤の後、私はこれらの重要なメトリクスを監視することに決めました. Too many dashboards become noise, but these four tell me everything I need to know about our cluster performance: karpenter_nodes_created_total: nodes are scaling up when they should be. ノードは、いつスケーラアップする必要がありますか? karpenter_nodes_terminated_total: ノードは適切にスケールダウンしていますか? karpenter_pods_state: Pods はすぐにスケジュールされますか? karpenter_node_utilization: インスタンスのサイズは正しいですか? Node utilization metric はほぼ目開きでした. We went from ~25% average utilization up to 70% after Karpenter began right-sizeing our instances. 私たちは、Karpenterが私たちのインスタンスを右サイズ化し始めた後、平均利用率から70%まで移動しました。 CI/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 概要 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. 私は、スポットインスタンスの中断を伴う最初のヒックアップ(プロティップ:アプリケーションがSIGTERMを優雅に処理することを確認するつもりはありません)があり、ARM64ワークロードを正しく取得するには、いくつかのイテレーションが必要でした。 しかし、結果はそれ自体を語っています。我々は、より強力でコスト効率の高いインフラストラクチャを実行し、スマートにスケールする。 あなたが予測できないワークロードに取り組んでいる場合、AWSの請求書が上昇している場合、または単に「Kubernetesの未来」のように感じる何かを試したい場合、私は間違いなくKarpenterにショットを与えることをお勧めします。 完全な実装が利用可能 私はすべての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 Cluster と Karpenter で AWS コンピューティングコストを 70% 削減する方法

About Author

コメント

ラベル

この記事は

Related Stories

暗号通貨の成長: 効果的なユーザーペルソナの作成

AI/ML データレイクのリファレンスアーキテクチャを構築するためのアーキテクトガイド

目に見えない層: ユーザーインタビューがかけがえのない資産である理由

Telegram: クリプト島と本土を結ぶ橋

暗号通貨の成長: 効果的なユーザーペルソナの作成

AI/ML データレイクのリファレンスアーキテクチャを構築するためのアーキテクトガイド

目に見えない層: ユーザーインタビューがかけがえのない資産である理由

Telegram: クリプト島と本土を結ぶ橋

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps