Sau khi xem hóa đơn AWS hàng tháng của chúng tôi tăng đều đặn khi khối lượng công việc Kubernetes của chúng tôi tăng lên, tôi biết chúng tôi cần một cách tiếp cận thông minh hơn để cung cấp nút. tự động quy mô cluster truyền thống đang đốt cháy ngân sách của chúng tôi với các nút được cung cấp quá mức ngồi yên tĩnh, trong khi vẫn mất vĩnh viễn để mở rộng khi tôi cần công suất. Trong hướng dẫn này, tôi sẽ chia sẻ cách tôi đã xây dựng một cụm EKS sẵn sàng sản xuất, đa kiến trúc mà cắt giảm chi phí tính toán của chúng tôi bằng 70% trong khi làm cho quy mô gần như ngay lập tức. Mã nguồn đầy đủ có sẵn trên GitHub. Mã nguồn đầy đủ có sẵn tại . GitHub Chuyển từ Cluster Autoscaler sang Karpenter Giảm 70% chi phí tính toán bằng cách sử dụng Spot + Graviton Giảm độ trễ lập kế hoạch pod từ 3 phút đến 20 giây Xây dựng cụm multi-arch EKS với AMD64 + ARM64 Hoàn toàn Terraform + CI / CD pipeline trên GitHub Autoscaling truyền thống Đây là những gì tôi không thích về Kubernetes Cluster Autoscaler tiêu chuẩn: Tôi sẽ có pods ngồi trong trạng thái "Pending" trong 2-3 phút chờ đợi cho các nút mới, trong khi trả tiền cho một loạt các phiên bản m5.large quá cung cấp hầu như không đạt được 20% sử dụng CPU hầu hết thời gian. Tôi nhớ một sự cố đặc biệt thất vọng khi một đợt tăng lưu lượng truy cập đã tấn công ứng dụng của chúng tôi vào lúc 2 giờ sáng.Chuyển động cụm mất hơn 4 phút để cung cấp các nút mới, và đến lúc đó người dùng của chúng tôi đã nhận được thời gian.Đó là khi tôi bắt đầu nghiêm túc nhìn vào Karpenter. Điều làm cho Karpenter khác biệt là nó không nghĩ về các nhóm nút cố định. Thay vào đó, nó nhìn vào các pods đang chờ của bạn và nói, "OK, bạn cần 2 vCPU và 4GB RAM? Hãy để tôi tìm thấy phiên bản spot rẻ nhất phù hợp với các yêu cầu đó." Sau khi thực hiện nó, tôi thấy thời gian cung cấp nút của chúng tôi giảm từ 3+ phút xuống dưới 20 giây. và tiết kiệm chi phí - khoảng 70% giảm hóa đơn tính toán của chúng tôi, giúp giải phóng ngân sách cho các cải tiến cơ sở hạ tầng khác. Thiết kế Multi-Architecture Một điều gây ấn tượng với tôi về Karpenter là nó dễ dàng xử lý các yêu cầu khối lượng công việc hỗn hợp của chúng tôi. tôi có một số ứng dụng PHP cũ cần các phiên bản x86, nhưng tôi cũng muốn thử nghiệm với các phiên bản ARM64 Graviton cho các microservices mới hơn của chúng tôi. Kiến trúc mà tôi kết thúc với trông như thế này: ┌─────────────────────────────────────────────────────────────┐
│                     EKS Cluster                             │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐          │
│  │   AMD64     │  │    ARM64    │  │  Karpenter  │          │
│  │  NodePool   │  │  NodePool   │  │ Controller  │          │
│  └─────────────┘  └─────────────┘  └─────────────┘          │
│                                                             │
│  ┌─────────────────────────────────────────────────────┐    │
│  │              Spot Instance Handling                 │    │
│  │    SQS Queue + EventBridge Rules                    │    │
│  └─────────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────────┘
 The architecture consists of several key components: VPC Infrastructure: Có được mạng đúng là rất quan trọng.Tôi đã dành một thời gian để có được các thẻ subnet hoàn hảo - những thẻ karpenter.sh/discovery không chỉ là tốt đẹp để có, họ là điều cần thiết cho Karpenter để tìm các mạng con của bạn.Tôi đã quên thẻ karpenter.sh/discovery một lần - mất một giờ để gỡ lỗi tại sao nó sẽ không khởi động các nút. EKS Cluster: Việc tích hợp nhà cung cấp OIDC có lẽ là phần khó khăn nhất để có được đúng lúc đầu.Đó là những gì cho phép Karpenter để nói chuyện an toàn với AWS API mà không cần mã hóa xác thực cứng. Karpenter Controller: Đây là nơi sự kỳ diệu xảy ra. một khi được triển khai, nó liên tục theo dõi các pods không lên lịch và cung cấp thông minh các trường hợp phù hợp. Hỗ trợ đa kiến trúc: Có các nhóm node riêng biệt cho AMD64 và ARM64 cho phép chúng tôi chạy tải công việc khác nhau trên phần cứng hiệu quả nhất. Spot Instance Management: Việc xử lý sự gián đoạn là điều tôi lo lắng ban đầu, nhưng tích hợp SQS của AWS làm cho nó đáng ngạc nhiên mạnh mẽ. Cấu trúc Terraform thực sự hoạt động Cố gắng đầu tiên của tôi để cấu trúc điều này là một mớ hỗn độn.Tôi có tất cả mọi thứ trong một con khổng lồ Sau một số refactoring (và một vài đêm muộn), tôi hạ cánh trên cách tiếp cận mô-đun này: main.tf ├── eks-module/            # EKS cluster creation
├── karpenter/             # Karpenter autoscaler setup
├── vpc/                   # VPC infrastructure
├── root/                  # Main Terraform execution
└── .github/workflows/     # CI/CD pipeline
 VPC: Có được nền tảng mạng đúng Các thiết lập VPC đã mất tôi một vài lần để có được chính xác. khái niệm quan trọng là chiến lược đánh dấu không chỉ là tài liệu - nó là chức năng. 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 và Karpenter: Trái tim của hệ thống Việc thiết lập EKS rất đơn giản, nhưng việc có được nhà cung cấp OIDC đúng là rất quan trọng.Đây là những gì cho phép Karpenter đảm nhận vai trò IAM một cách an toàn: 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
}
 Đối với việc triển khai Karpenter, tôi đã đi với cách tiếp cận biểu đồ Helm. Một điều tôi học được là bạn cần cài đặt CRD đầu tiên, sau đó là biểu đồ chính. Cài đặt hàng đợi gián đoạn là rất quan trọng - đó là những gì ngăn chặn tải công việc của bạn đột ngột chấm dứt khi các trường hợp địa điểm được thu hồi: # 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
  }
}
 Kiến trúc đa NodePools Ban đầu, tôi hoài nghi về ARM64. "Các ứng dụng của chúng tôi thậm chí còn hoạt động không?" Nhưng sau một số thử nghiệm, tôi thấy rằng các dịch vụ Node.js và Python của chúng tôi hoạt động hoàn hảo trên các trường hợp Graviton - thường với hiệu suất tốt hơn cho mỗi đô la. Đây là cách tôi thiết lập các node pool: Cấu hình 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
 Tên sản phẩm: ARM64 NodePool: The Graviton Experiment Thiết lập ARM64 đòi hỏi phải suy nghĩ thêm một chút.Tôi đã thêm các lỗi để ngăn chặn tải công việc không tương thích vô tình hạ cánh trên các nút 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
 Tôi đã học được rằng chỉ định ID AMI chính xác cho phép bạn kiểm soát nhiều hơn về những gì được triển khai, đặc biệt là khi thử nghiệm các cấu hình ARM64 khác nhau. Tiết kiệm chi phí với phương pháp này Trước khi Karpenter, chúng tôi đã chạy một hỗn hợp các phiên bản theo yêu cầu trên nhiều nhóm nút - khoảng 15-20 phiên bản m5.large và c5.xlarge chạy 24/7. Sau khi chuyển sang Karpenter với khoảng 70% sử dụng phiên bản tại chỗ, chi phí tính toán hàng tháng của chúng tôi giảm 70%.Đó là một sự giảm đáng kể đã giải phóng ngân sách đáng kể cho các tính năng mới và cải tiến cơ sở hạ tầng. Lợi ích của ARM64 Ngoài việc tiết kiệm chi phí ~20% so với các phiên bản x86 tương đương, tôi thấy hiệu suất tốt hơn trên một số khối lượng công việc cần CPU của chúng tôi. ví dụ, dịch vụ xử lý hình ảnh của chúng tôi chạy nhanh hơn khoảng 15% trên các phiên bản Graviton. Đây là những gì tôi thường thấy trên các cụm của chúng tôi: Giảm 70% chi phí máy tính Sub-20-second scaling thay vì phút Sử dụng tài nguyên tốt hơn – không còn phải trả tiền cho chu kỳ CPU vắng vẻ Theo dõi hiệu suất cho thấy chúng tôi đã đi từ mức sử dụng CPU trung bình 25% trên các nút cố định của chúng tôi đến mức sử dụng 70% với quy mô phải của Karpenter. Bài học sản xuất đã học An ninh: IRSA là bạn của bạn Tôi sử dụng IAM Roles for Service Accounts (IRSA) ở khắp mọi nơi, điều đó có nghĩa là không có thông tin xác thực AWS được mã hóa cứng nào nữa nổi trong cụm của chúng tôi: 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"
          }
        }
      }
    ]
  })
}
 giám sát Sau một số thử nghiệm và lỗi, tôi quyết định theo dõi các số liệu quan trọng này.Quá nhiều bảng điều khiển trở nên ồn ào, nhưng bốn điều này cho tôi biết mọi thứ tôi cần biết về hiệu suất cụm của chúng tôi: karpenter_nodes_created_total: Các nút có được mở rộng khi nào? karpenter_nodes_terminated_total: Các nút có được giảm quy mô phù hợp không? karpenter_pods_state: Các pods có được lên lịch nhanh không? karpenter_node_utilization: Các trường hợp có được kích thước đúng không? Đo lường sử dụng nút gần như mở mắt.Chúng tôi đã đi từ ~25% sử dụng trung bình lên đến 70% sau khi Karpenter bắt đầu kích thước đúng các trường hợp của chúng tôi. CĐ / CD Tôi sử dụng GitHub Actions với xác thực OIDC để AWS (không còn khóa truy cập trong bí mật!). luồng công việc hỗ trợ các chi nhánh tính năng để phát triển, sắp xếp để thử nghiệm và chính để sản xuất: 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 
 Điều tôi thích về thiết lập này là sự lựa chọn môi trường năng động và việc sử dụng các biến GitHub cho các giai đoạn khác nhau. Step đảm bảo sự nhất quán của mã trên toàn đội của chúng tôi. terraform fmt -check Kết luận Tôi đã có một số hiccups ban đầu với sự gián đoạn trường hợp tại chỗ (phản ứng: đảm bảo các ứng dụng của bạn xử lý SIGTERM một cách lịch sự), và nhận được các khối lượng công việc ARM64 đúng đắn mất một số lặp lại. Nhưng kết quả nói lên điều đó.Chúng tôi đang chạy một cơ sở hạ tầng có khả năng phục hồi hơn, hiệu quả về chi phí, có quy mô thông minh.Các khoản tiết kiệm chi phí đáng kể chỉ trả cho thời gian kỹ thuật tôi đã dành cho việc di chuyển này trong tháng đầu tiên. Nếu bạn đang đối phó với khối lượng công việc không thể đoán trước, tăng hóa đơn AWS, hoặc chỉ muốn thử một cái gì đó cảm thấy như "tương lai của Kubernetes", tôi chắc chắn khuyên bạn nên cho Karpenter một cú đánh. Việc thực hiện đầy đủ có sẵn trên Tôi đã bao gồm tất cả các mô-đun Terraform, các kịch bản thử nghiệm và một hướng dẫn khắc phục sự cố dựa trên các vấn đề mà tôi đã gặp phải. 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

Nghe bài viết này bằng Tiếng Anh, đọc bởi robot thông minh của HackerNoon

Làm thế nào tôi cắt giảm chi phí tính toán AWS 70% với một cụm EKS Multi-Arch và Karpenter

About Author

BÌNH LUẬN

chuyên mục

BÀI VIẾT NÀY CŨNG CÓ MẶT TẠI

Related Stories

85 Stories To Learn About Travel

178 Stories To Learn About Essay

240 Stories To Learn About Astounding Stories

184 Stories To Learn About Psychology

85 Stories To Learn About Travel

178 Stories To Learn About Essay

240 Stories To Learn About Astounding Stories

184 Stories To Learn About Psychology

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps