После того, как наши ежемесячные счета AWS неуклонно поднимались по мере роста рабочей нагрузки Kubernetes, я знал, что нам нужен более умный подход к предоставлению узлов.Традиционное автоматическое масштабирование кластеров сжигалось через наш бюджет с переобеспеченными узлами, сидящими без работы, в то время как продолжалось вечно, чтобы масштабироваться, когда мне нужна была мощность. В этом руководстве я расскажу, как я построил готовый к производству многоархитектурный кластер EKS, который сокращает наши расходы на вычисления на 70% и делает масштабирование практически мгновенным. Полный исходный код доступен на GitHub. Полный исходный код доступен на . GitHub Переход от Cluster Autoscaler к Karpenter Сократите расходы на вычисление на 70% с помощью Spot + Graviton Сокращенная латентность планирования с 3 минут до 20 секунд Встроенный многофункциональный кластер EKS с поддержкой AMD64 + ARM64 Полный трубопровод Terraform + CI/CD на GitHub Традиционное автоскалирование Вот то, что мне не понравилось в стандартном автоскалере кластера Kubernetes: у меня были бы подшипники, сидящие в состоянии "Пендинг" в течение 2-3 минут, ожидая новых узлов, в то время как я платил за кучу избыточных м5.больших экземпляров, которые в большинстве случаев едва достигали 20% использования процессора. Я помню один особенно разочаровывающий инцидент, когда пик трафика ударил по нашему приложению в 2 часа ночи.Автоскалеру кластера потребовалось более 4 минут, чтобы предоставить новые узлы, и к тому времени наши пользователи получали отсрочки. Что делает Karpenter другим, так это то, что он не думает в терминах фиксированных групп узлов. Вместо этого он смотрит на ваши подвесные подвески и говорит: «Хорошо, вам нужно 2 vCPU и 4 ГБ оперативной памяти? После его внедрения я увидел, что время предоставления наших узлов сократилось с 3+ минут до менее 20 секунд.И экономия затрат — около 70% сокращения нашего вычислительного счета, что освободило бюджет для других улучшений инфраструктуры. Наша многофункциональная архитектура Одна вещь, которая произвела на меня впечатление в отношении Karpenter, заключалась в том, как легко она справлялась с нашими требованиями к смешанной рабочей нагрузке.У меня были некоторые прежние приложения PHP, которые нуждались в инстанциях x86, но я также хотел экспериментировать с инстанциями ARM64 Graviton для наших более новых микросервисов. Архитектура, с которой я закончил, выглядит так: ┌─────────────────────────────────────────────────────────────┐
│                     EKS Cluster                             │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐          │
│  │   AMD64     │  │    ARM64    │  │  Karpenter  │          │
│  │  NodePool   │  │  NodePool   │  │ Controller  │          │
│  └─────────────┘  └─────────────┘  └─────────────┘          │
│                                                             │
│  ┌─────────────────────────────────────────────────────┐    │
│  │              Spot Instance Handling                 │    │
│  │    SQS Queue + EventBridge Rules                    │    │
│  └─────────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────────┘
 The architecture consists of several key components: Я потратил некоторое время, чтобы сделать подсеть ярлыком идеальной — эти теги karpenter.sh/discovery не просто приятны, они необходимы для Karpenter, чтобы найти ваши подсети. Кластер EKS: Интеграция провайдеров OIDC, вероятно, была самой сложной частью, чтобы получить правильное первоначально. Karpenter Controller: Это место, где происходит магия.Однажды развернутый, он постоянно следит за незапланированными поддонами и интеллектуально обеспечивает правильные инстанции. Поддержка мультиархитектуры: наличие отдельных пулов узлов для AMD64 и ARM64 позволяет нам запускать различные рабочие нагрузки на самом экономичном оборудовании. Spot Instance Management: обработка прерываний была чем-то, о чем я изначально беспокоился, но интеграция AWS в SQS делает ее удивительно прочной. Терраформная структура, которая на самом деле работает Моя первая попытка структурировать это было хаосом.У меня было все в одном гиганте После некоторого переосмысления (и нескольких поздних ночей), я приземлился на этом модульном подходе: 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 Right Настройка VPC потребовала от меня нескольких итераций, чтобы получить правильное представление. Ключевое понимание заключалось в том, что стратегия маркировки — это не просто документация — она функциональна. 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 и Карпентер: сердце системы Настройка 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 chart.One thing I learned is that you need to install the CRDs first, then the main chart.The interruption queue setup was crucial — 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 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: Гравитонский эксперимент Установка ARM64 требует немного большего размышления.Я добавил тойнты, чтобы предотвратить случайное приземление несовместимых рабочих нагрузок на узлы 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
 Я узнал, что определение точных идентификаторов AMI дает вам больше контроля над тем, что развертывается, особенно при тестировании различных конфигураций ARM64. Экономия денег с помощью этого подхода До Karpenter мы работали со смесью инстанций по запросу по нескольким группам узлов — примерно 15-20 инстанций m5.large и c5.xlarge, работающих 24/7. После перехода на Karpenter с использованием около 70% локальных инстанций наши ежемесячные расходы на вычисление снизились на 70%. Преимущества ARM64 В дополнение к экономии затрат ~20% по сравнению с эквивалентными x86-инстанциями, я увидел лучшую производительность на некоторых наших рабочих нагрузках, интенсивных на процессоры. Вот что я обычно вижу через наши кластеры: Снижение затрат на вычисление на 70% Под 20-секундное масштабирование вместо минут Лучшее использование ресурсов — больше не нужно платить за пустые циклы процессора Мониторинг производительности показал, что мы перешли от среднего 25% использования процессора на наших фиксированных узлах до 70% использования с праворазмерным Karpenter. Уроки производства, полученные Безопасность: 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"
          }
        }
      }
    ]
  })
}
 мониторинг Слишком много панелей становится шумом, но эти четыре рассказывают мне все, что мне нужно знать о производительности нашего кластера: karpenter_nodes_created_total: Узлы расширяются, когда они должны быть? karpenter_nodes_terminated_total: Подходят ли узлы к уменьшению масштабов? karpenter_pods_state: Планируются ли поддоны быстро? karpenter_node_utilization: Используются ли инстанции в правильном размере? Мы перешли от ~25% среднего использования до 70% после того, как Карпентер начал правильно размещать наши экземпляры. CD / CD Я использую GitHub Actions с аутентификацией OIDC на AWS (не более ключей доступа в секрете!). 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 Резюме У меня были некоторые первоначальные перебои с прерываниями на месте (противоположность: убедитесь, что ваши приложения грациозно обрабатывают SIGTERM), и получить рабочие нагрузки ARM64 правильно потребовало некоторой итерации. Но результаты говорят сами за себя.Мы управляем более устойчивой, экономически эффективной инфраструктурой, которая масштабируется интеллектуально. Если вы имеете дело с непредсказуемыми рабочими нагрузками, растущими счетами AWS или просто хотите попробовать что-то, что чувствует себя как «будущее Kubernetes», я определенно рекомендую дать Карпентеру удар. Полная реализация доступна на Я включил все модули 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

Этот звук создан на языке оригинала истории!

Как сократить затраты на вычисление AWS на 70% с помощью кластера Multi-Arch EKS и Karpenter

About Author

КОММЕНТАРИИ

БИРКИ

ЭТА СТАТЬЯ БЫЛА ПРЕДСТАВЛЕНА В

Related Stories

Хотите выиграть конкурс HackerNoon? Вот что рекомендуют победители конкурса #crypto-api

Невидимые слои: почему интервью с пользователями являются незаменимым активом

Утечка информации о системе Claude Sonnet 3.5: судебно-медицинский анализ

Создание криптопродуктов, ориентированных на пользователя: важность отзывов клиентов

Хотите выиграть конкурс HackerNoon? Вот что рекомендуют победители конкурса #crypto-api

Невидимые слои: почему интервью с пользователями являются незаменимым активом

Утечка информации о системе Claude Sonnet 3.5: судебно-медицинский анализ

Создание криптопродуктов, ориентированных на пользователя: важность отзывов клиентов

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps