在观察我们每月的 AWS 账单随着我们的 Kubernetes 工作负载的增长而稳步上升之后,我知道我们需要一个更智能的方法来提供节点。 我听说过Karpenter,但我没有尝试过它,这起事件促使我终于把它拍下来. 在本指南中,我将分享我如何构建一个生产准备的多架构EKS集群,使我们的计算成本降低70%,同时使扩展几乎立即。 完整的源代码在GitHub上可用。 完整的源代码在GitHub上可用。 从集群 Autoscaler 转到 Karpenter 使用Spot + Graviton 降低 70% 的计算成本 缩短了从 3 分钟到 20 秒的 pod 编程延迟 使用 AMD64 + ARM64 构建的多档 EKS 集群 完整的Terraform + CI/CD管道在GitHub上 传统的自动升级 这里是我对标准的Kubernetes集群自动扩展器不喜欢的:我会在“倾斜”状态下坐 2-3 分钟等待新的节点,同时为大量过度提供的 m5 大型实例付费,这些实例几乎几乎没有击中 20% 的CPU利用率。 我记得一个特别令人沮丧的事件,当一个流量飙升击中我们的应用于上午2点时。 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 集群:OIDC 提供商集成可能是最棘手的部分,可以得到正确的最初. 这是 Karpenter 允许安全地与 AWS API 交谈,而没有硬代码的凭证。 Karpenter 控制器:这是魔法发生的地方.一旦部署,它会不断监控未安排的 pods,并明智地提供正确的实例。 多架构支持:为 AMD64 和 ARM64 提供单独的节点池允许我们在最具成本效益的硬件上运行不同的工作负载。 Spot 实例管理:中断处理是我最初担心的,但 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:获得网络基础权利 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和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,然后安装主图表。 # 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: 重力实验 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 ID 可以让您更好地控制部署的内容,尤其是在测试不同的 ARM64 配置时。 通过这种方法节省成本 在Karpenter之前,我们在多个节点组中运行了一组按需实例,大约有 15-20 个 m5.large 和 c5.xlarge 实例运行 24/7. 在切换到 Karpenter 后,我们的每月计算成本下降了 70%;这是一种显著的减少,为新功能和基础设施改进释放了大量预算。 ARM64 的优点 ARM64 实例提供了额外的奖励,除了与同等 x86 实例相比节省 ~20% 的成本之外,我看到我们一些 CPU 密集型工作负载的性能更好,例如,我们的图像处理服务在 Graviton 实例中运行速度快约 15%。 以下是我通常在我们的集群中看到的: 计算机成本的70%降低 低于20秒的缩放,而不是分钟 更好的资源利用 - 不再为无聊的CPU周期支付费用 性能监测显示,我们从固定节点的平均25%的CPU利用率到Karpenter的右尺寸利用率的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"
          }
        }
      }
    ]
  })
}
 监控 经过一些尝试和错误后,我决定监控这些关键指标。太多的仪表板变得噪音,但这四个告诉我关于我们的集群性能所需的一切: karpenter_nodes_created_total:节点在何时升级? karpenter_nodes_terminated_total:节点是否适当缩小? karpenter_pods_state: Pods 是否会快速预订? karpenter_node_utilization:实例是否被正确大小? 节点利用指标几乎是开放的,我们从 ~ 25% 的平均利用率上升到 70% 之后,Karpenter 开始对我们的实例进行大小调整。 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的未来”的东西,我绝对建议给Karpenter一张照片,从开发集群开始,熟悉概念,然后逐步迁移您的生产工作负载。 完整的实施可在 我已经包括了所有Terraform模块,测试脚本和基于我遇到的问题的故障排除指南。 吉普赛

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

該音頻是用故事的原始語言製作的！

如何通过多方方 EKS 集群和 Karpenter 将 AWS 计算成本降低 70%

About Author

註釋

標籤

这篇文章刊登在

Related Stories

看不见的层面：为什么用户访谈是不可替代的资产

扬帆起航：利用数据湖开发生产级 RAG 应用程序

Telegram：加密岛通往大陆的桥梁

架构师指南：构建 AI/ML 数据湖参考架构

看不见的层面：为什么用户访谈是不可替代的资产

扬帆起航：利用数据湖开发生产级 RAG 应用程序

Telegram：加密岛通往大陆的桥梁

架构师指南：构建 AI/ML 数据湖参考架构

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps