Kubernetes & Amazon EKS Training

中文

한국어
English
日本語
Español

中文

한국어
English
日本語
Español

Appearance

Amazon EKS 成本优化测验 ​

本测验检验你对在 Amazon EKS 集群中优化成本的策略、工具和最佳实践的理解。

测验概览 ​

  • 计算资源优化
  • 存储成本优化
  • 网络成本优化
  • 集群管理成本优化
  • 成本监控和分析
  • 成本优化工具和最佳实践

多项选择题 ​

1. 在 Amazon EKS 中优化计算成本的最有效策略是什么？ ​

A. 始终使用最大的 instance types B. 对所有 workloads 只使用 on-demand instances C. 结合 Spot Instances、right-sizing 和 auto-scaling D. 将所有 workloads 合并到单个 node group 中

显示答案

答案：C. 结合 Spot Instances、right-sizing 和 auto-scaling

说明： 在 Amazon EKS 中优化计算成本的最有效策略是结合 Spot Instances、right-sizing 和 auto-scaling。这种集成方法可提供与 workload 特征匹配的高性价比计算资源，同时满足性能要求。

关键计算优化策略：

  1. Spot Instance 利用率：

    • 与 on-demand 相比，最多可节省 90% 的成本
    • 适合 fault-tolerant workloads
    • 实施 interruption 处理机制

  2. Right-sizing：

    • 根据实际资源使用情况选择 instances
    • 消除 over-provisioned resources
    • 优化 resource requests 和 limits

  3. Auto-scaling 实施：

    • 通过 Cluster Autoscaler 或 Karpenter 进行 node-level scaling
    • 通过 Horizontal Pod Autoscaler 进行 Pod-level scaling
    • 根据需求调整资源

实施方法：

  1. 使用 Spot Instances 创建 Node Group：

    bash
    # Create Spot Instance node group using eksctl
eksctl create nodegroup \
  --cluster my-cluster \
  --name spot-ng \
  --node-type m5.large \
  --nodes-min 2 \
  --nodes-max 10 \
  --spot \
  --asg-access

  2. 部署并配置 Karpenter：

    yaml
    # Karpenter NodePool
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["spot"]
        - key: "kubernetes.io/arch"
          operator: In
          values: ["amd64"]
        - key: "kubernetes.io/os"
          operator: In
          values: ["linux"]
        - key: "node.kubernetes.io/instance-type"
          operator: In
          values: ["m5.large", "m5a.large", "m5d.large", "m5ad.large", "m4.large"]
      nodeClassRef:
        name: default
  limits:
    resources:
      cpu: 1000
      memory: 1000Gi
  disruption:
    consolidationPolicy: WhenEmpty
    consolidateAfter: 30s
---
# Karpenter NodeClass
apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
  name: default
spec:
  amiFamily: AL2
  role: KarpenterNodeRole
  subnetSelector:
    karpenter.sh/discovery: my-cluster
  securityGroupSelector:
    karpenter.sh/discovery: my-cluster
  tags:
    karpenter.sh/discovery: my-cluster

  3. 配置 Horizontal Pod Autoscaler：

    yaml
    apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80

  4. 配置 Vertical Pod Autoscaler：

    yaml
    apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: web-app-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: web-app
  updatePolicy:
    updateMode: "Auto"
  resourcePolicy:
    containerPolicies:
    - containerName: '*'
      minAllowed:
        cpu: 50m
        memory: 100Mi
      maxAllowed:
        cpu: 1
        memory: 1Gi
      controlledResources: ["cpu", "memory"]

按 Workload 类型划分的优化策略：

  1. Stateless Applications：

    • 优先使用 Spot Instances
    • 实施 horizontal scaling
    • 跨多个 availability zones 部署

  2. Stateful Applications：

    • 混合使用 on-demand 和 Spot Instances
    • 选择合适的 instance types
    • 平衡存储性能和成本

  3. Batch Jobs：

    • 最大化 Spot Instance 使用率
    • 实施 job retry 机制
    • 在高性价比时间窗口运行

最佳实践：

  1. 优化 Resource Requests 和 Limits：

    yaml
    # Resource requests and limits example
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: web-app
        image: web-app:1.0
        resources:
          requests:
            cpu: 100m
            memory: 256Mi
          limits:
            cpu: 500m
            memory: 512Mi

  2. 优化 Node Affinity 和 Pod 分布：

    yaml
    # Node affinity and pod distribution example
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  template:
    spec:
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 1
            preference:
              matchExpressions:
              - key: node.kubernetes.io/instance-type
                operator: In
                values:
                - m5.large
                - m5a.large
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - web-app
              topologyKey: "kubernetes.io/hostname"

  3. 处理 Spot Instance Interruptions：

    yaml
    # Spot Instance interruption handling example
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  template:
    spec:
      terminationGracePeriodSeconds: 60
      containers:
      - name: web-app
        image: web-app:1.0
        lifecycle:
          preStop:
            exec:
              command: ["/bin/sh", "-c", "sleep 10; /app/cleanup.sh"]

其他选项的问题：

  • A. 始终使用最大的 instance types：这会导致 over-provisioning，产生不必要的成本，并且可能不匹配 workload 要求。
  • B. 对所有 workloads 只使用 on-demand instances：on-demand instances 的成本高于 Spot Instances，而且许多 workloads 可以在 Spot Instances 上有效运行。
  • D. 将所有 workloads 合并到单个 node group 中：这会使满足不同 workload 要求变得困难，缺乏资源隔离，并使成本分配和优化更具挑战性。

2. 在 Amazon EKS 中优化存储成本的最有效方法是什么？ ​

A. 对所有 workloads 使用最便宜的存储类型 B. 将所有数据迁移到 S3 C. 选择与 workload 要求匹配的存储类型并实施生命周期管理 D. 最小化所有 volume 大小

显示答案

答案：C. 选择与 workload 要求匹配的存储类型并实施生命周期管理

说明： 在 Amazon EKS 中优化存储成本的最有效方法是选择与 workload 要求匹配的存储类型并实施生命周期管理。这种方法在满足性能要求的同时最大限度降低成本，并根据数据价值和访问模式利用合适的存储层级。

关键存储优化策略：

  1. 为 Workloads 选择合适的存储类型：

    • 高性能需求：io2、gp3 (EBS)
    • 共享访问需求：EFS
    • 大规模数据处理：FSx for Lustre
    • 归档数据：S3、S3 Glacier

  2. 存储生命周期管理：

    • 频繁访问的数据：高性能存储
    • 偶尔访问的数据：标准存储
    • 很少访问的数据：低成本归档存储

  3. 高效 Volume 管理：

    • 设置合适的 volume 大小
    • 识别并移除未使用的 volumes
    • 管理 snapshot 生命周期

实施方法：

  1. EBS Volume 优化：

    yaml
    # gp3 StorageClass configuration
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ebs-gp3
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  iops: "3000"
  throughput: "125"
allowVolumeExpansion: true

  2. EFS 生命周期管理：

    bash
    # Set lifecycle policy when creating EFS file system
aws efs create-file-system \
  --creation-token eks-efs \
  --performance-mode generalPurpose \
  --throughput-mode bursting \
  --lifecycle-policies '[{"TransitionToIA":"AFTER_30_DAYS"}]'

  3. S3 生命周期策略：

    json
    {
  "Rules": [
    {
      "ID": "Move to IA after 30 days, Glacier after 90 days",
      "Status": "Enabled",
      "Prefix": "eks-backups/",
      "Transitions": [
        {
          "Days": 30,
          "StorageClass": "STANDARD_IA"
        },
        {
          "Days": 90,
          "StorageClass": "GLACIER"
        }
      ],
      "Expiration": {
        "Days": 365
      }
    }
  ]
}

  4. EBS Snapshot 生命周期管理：

    yaml
    # VolumeSnapshotClass configuration
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: ebs-snapshot
  annotations:
    snapshot.storage.kubernetes.io/is-default-class: "true"
driver: ebs.csi.aws.com
deletionPolicy: Delete

其他选项的问题：

  • A. 对所有 workloads 使用最便宜的存储类型：最便宜的存储可能无法满足性能要求，可能导致 application 性能下降并影响业务。
  • B. 将所有数据迁移到 S3：S3 适合某些数据类型，但不适合 latency-sensitive workloads 或需要 block storage 的 applications。
  • D. 最小化所有 volume 大小：过度最小化 volume 大小可能导致空间不足问题，而且某些 volume types（例如 gp2）的性能由大小决定。

3. 在 Amazon EKS 中优化网络成本的最有效策略是什么？ ​

A. 对所有流量使用最昂贵的网络带宽 B. 将所有 services 放在单个 availability zone 中 C. 优化流量模式、最小化数据传输成本并利用 VPC endpoints D. 阻止所有网络流量

显示答案

答案：C. 优化流量模式、最小化数据传输成本并利用 VPC endpoints

说明： 在 Amazon EKS 中优化网络成本的最有效策略是优化流量模式、最小化数据传输成本并利用 VPC endpoints。此方法通过考虑 AWS 网络成本模型，提高网络流量效率并减少不必要的成本。

关键网络成本优化策略：

  1. 流量模式优化：

    • 最小化跨 availability zone 流量
    • 最小化跨 region 流量
    • 实施 locality-aware routing

  2. 最小化数据传输成本：

    • 使用压缩和高效的数据格式
    • 实施缓存策略
    • 消除不必要的数据传输

  3. VPC Endpoint 利用率：

    • 到 AWS services 的私有连接
    • 绕过 internet gateways
    • 降低数据传输成本

实施方法：

  1. Availability Zone-Aware Pod 放置：

    yaml
    # Deployment with topology spread constraints
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 6
  template:
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: web-app

  2. Service Topology Routing：

    yaml
    # Topology-aware service configuration
apiVersion: v1
kind: Service
metadata:
  name: web-app
spec:
  selector:
    app: web-app
  ports:
  - port: 80
    targetPort: 8080
  topologyKeys:
  - "kubernetes.io/hostname"
  - "topology.kubernetes.io/zone"
  - "*"

  3. VPC Endpoint 配置：

    bash
    # Create S3 VPC endpoint
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-12345678 \
  --service-name com.amazonaws.us-west-2.s3 \
  --route-table-ids rtb-12345678

# Create DynamoDB VPC endpoint
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-12345678 \
  --service-name com.amazonaws.us-west-2.dynamodb \
  --route-table-ids rtb-12345678

# Create ECR API VPC endpoint
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-12345678 \
  --service-name com.amazonaws.us-west-2.ecr.api \
  --vpc-endpoint-type Interface \
  --subnet-ids subnet-12345678 subnet-87654321 \
  --security-group-ids sg-12345678

  4. 使用 Istio 的 Locality Routing：

    yaml
    # Istio locality routing configuration
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: web-app
spec:
  host: web-app
  trafficPolicy:
    loadBalancer:
      localityLbSetting:
        enabled: true
        failover:
        - from: us-west-2a
          to: us-west-2b
        - from: us-west-2b
          to: us-west-2c
        - from: us-west-2c
          to: us-west-2a

其他选项的问题：

  • A. 对所有流量使用最昂贵的网络带宽：这会产生不必要的成本，而且并非所有 workloads 都需要高带宽。
  • B. 将所有 services 放在单个 availability zone 中：这会显著降低可用性和 fault tolerance，违反 AWS 高可用设计原则。
  • D. 阻止所有网络流量：这不切实际，并会严重限制 application 功能。

4. 优化 Amazon EKS 集群管理成本的最有效方法是什么？ ​

A. 创建尽可能多的 clusters B. 将所有 workloads 合并到单个 cluster 中 C. 根据 workload 要求优化 cluster 数量并最小化管理开销 D. 手动管理 clusters

显示答案

答案：C. 根据 workload 要求优化 cluster 数量并最小化管理开销

说明： 优化 Amazon EKS 集群管理成本的最有效方法是根据 workload 要求优化 cluster 数量并最小化管理开销。此方法在满足 workload 隔离和安全要求的同时，平衡 cluster 管理成本和运营复杂性。

关键 Cluster 管理成本优化策略：

  1. 保持适当的 Cluster 数量：

    • 根据业务要求进行 cluster 分离
    • 根据环境进行 cluster 分离（development、staging、production）
    • 考虑安全和合规要求

  2. 最小化管理开销：

    • 利用自动化 cluster 管理工具
    • 实施 Infrastructure as Code (IaC)
    • 集中式监控和日志记录

  3. 优化 Cluster 资源：

    • 合适的 control plane 配置
    • 高效的 node group 管理
    • 利用共享 services

实施方法：

  1. 优化的 EKS Cluster 配置：

    bash
    # Create optimized cluster using eksctl
eksctl create cluster \
  --name optimized-cluster \
  --region us-west-2 \
  --version 1.28 \
  --nodegroup-name standard-workers \
  --node-type m5.large \
  --nodes-min 2 \
  --nodes-max 10 \
  --managed \
  --asg-access \
  --external-dns-access \
  --full-ecr-access \
  --appmesh-access \
  --alb-ingress-access

  2. 使用 Terraform 进行 Cluster 管理自动化：

    hcl
    module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "~> 19.0"

  cluster_name    = "optimized-cluster"
  cluster_version = "1.28"

  cluster_endpoint_public_access  = true
  cluster_endpoint_private_access = true

  cluster_addons = {
    coredns = {
      most_recent = true
    }
    kube-proxy = {
      most_recent = true
    }
    vpc-cni = {
      most_recent = true
    }
  }

  vpc_id     = module.vpc.vpc_id
  subnet_ids = module.vpc.private_subnets

  eks_managed_node_groups = {
    general = {
      min_size     = 1
      max_size     = 10
      desired_size = 2

      instance_types = ["m5.large"]
      capacity_type  = "ON_DEMAND"
    }

    spot = {
      min_size     = 1
      max_size     = 10
      desired_size = 2

      instance_types = ["m5.large", "m5a.large", "m5d.large", "m4.large"]
      capacity_type  = "SPOT"
    }
  }

  tags = {
    Environment = "production"
    Terraform   = "true"
  }
}

  3. 使用 GitOps 进行 Cluster 配置管理：

    yaml
    # ArgoCD Application example
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: cluster-config
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/myorg/cluster-config.git
    targetRevision: HEAD
    path: configs
  destination:
    server: https://kubernetes.default.svc
    namespace: default
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
    - CreateNamespace=true

  4. Multi-tenant Cluster 配置：

    yaml
    # Namespace resource quota
apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "10"
    requests.memory: 20Gi
    limits.cpu: "20"
    limits.memory: 40Gi
    pods: "50"
    services: "20"
    persistentvolumeclaims: "30"

其他选项的问题：

  • A. 创建尽可能多的 clusters：这会增加每个 cluster 的 control plane 成本和管理开销，降低资源利用率。
  • B. 将所有 workloads 合并到单个 cluster 中：这在某些环境中可能适用，但没有考虑安全要求、workload 隔离和故障 blast radius。
  • D. 手动管理 clusters：手动管理会增加出错可能性、降低一致性并增加运营开销。

5. 在 Amazon EKS 中进行成本监控和分配的最有效方法是什么？ ​

A. 只查看 AWS 账单 B. 实施 tagging 策略、成本分配工具和持续监控 C. 为所有资源分配相同成本 D. 在没有成本监控的情况下使用资源

显示答案

答案：B. 实施 tagging 策略、成本分配工具和持续监控

说明： 在 Amazon EKS 中进行成本监控和分配的最有效方法是实施 tagging 策略、成本分配工具和持续监控。此方法有助于准确跟踪成本，按团队或项目分配成本，并识别成本优化机会。

关键成本监控和分配策略：

  1. 全面 Tagging 策略：

    • 按业务部门、团队、项目、环境设置 tags
    • 应用一致的 tagging 规则
    • 实施自动化 tagging

  2. 成本分配工具利用率：

    • AWS Cost Explorer 和 AWS Budgets
    • Kubecost 或 CloudHealth 等专用工具
    • 自定义 dashboards 和 reports

  3. 持续监控和优化：

    • 定期成本审查和分析
    • 异常检测和告警
    • 实施优化建议

实施方法：

  1. 实施 Tagging 策略：

    yaml
    # Namespace tagging
apiVersion: v1
kind: Namespace
metadata:
  name: team-a
  labels:
    team: team-a
    cost-center: cc-123
    environment: production
    project: project-x

# Deployment tagging
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  namespace: team-a
  labels:
    app: web-app
    team: team-a
    cost-center: cc-123
    environment: production
    project: project-x

  2. AWS Tag Policy 配置：

    json
    {
  "tags": {
    "team": {
      "tag_key": {
        "@@assign": "team"
      },
      "tag_value": {
        "@@assign": [
          "team-a",
          "team-b",
          "platform"
        ]
      },
      "enforced_for": {
        "@@assign": [
          "ec2:instance",
          "ec2:volume",
          "eks:cluster"
        ]
      }
    },
    "cost-center": {
      "tag_key": {
        "@@assign": "cost-center"
      },
      "enforced_for": {
        "@@assign": [
          "ec2:instance",
          "ec2:volume",
          "eks:cluster"
        ]
      }
    },
    "environment": {
      "tag_key": {
        "@@assign": "environment"
      },
      "tag_value": {
        "@@assign": [
          "production",
          "staging",
          "development"
        ]
      },
      "enforced_for": {
        "@@assign": [
          "ec2:instance",
          "ec2:volume",
          "eks:cluster"
        ]
      }
    }
  }
}

  3. Kubecost 安装和配置：

    bash
    # Install Kubecost using Helm
helm repo add kubecost https://kubecost.github.io/cost-analyzer/
helm install kubecost kubecost/cost-analyzer \
  --namespace kubecost \
  --create-namespace \
  --set kubecostToken="<YOUR_KUBECOST_TOKEN>" \
  --set prometheus.server.persistentVolume.size=100Gi \
  --set prometheus.nodeExporter.enabled=true \
  --set serviceMonitor.enabled=true

  4. AWS Cost Explorer Report 设置：

    bash
    # Create cost and usage report
aws cur put-report-definition \
  --report-definition '{
    "ReportName": "eks-cost-report",
    "TimeUnit": "HOURLY",
    "Format": "Parquet",
    "Compression": "Parquet",
    "AdditionalSchemaElements": ["RESOURCES"],
    "S3Bucket": "my-cost-reports",
    "S3Prefix": "eks-costs",
    "S3Region": "us-east-1",
    "AdditionalArtifacts": ["ATHENA"],
    "RefreshClosedReports": true,
    "ReportVersioning": "OVERWRITE_REPORT"
  }'

其他选项的问题：

  • A. 只查看 AWS 账单：AWS 账单只提供高层级成本信息，难以识别详细的成本分配或优化机会。
  • C. 为所有资源分配相同成本：这不能准确反映实际资源使用和成本产生情况，无法明确团队或项目的成本责任。
  • D. 在没有成本监控的情况下使用资源：没有成本监控，就无法及早发现成本增加或识别优化机会，使预算管理变得困难。

6. 用于 Amazon EKS 成本优化的最有效工具组合是什么？ ​

A. 只使用手动资源管理 B. 只使用 AWS Cost Explorer C. 集成 Kubecost、Karpenter、AWS Cost Explorer 和 Kubernetes auto-scaling tools D. 只使用 third-party cost management tools

显示答案

答案：C. 集成 Kubecost、Karpenter、AWS Cost Explorer 和 Kubernetes auto-scaling tools

说明： 用于 Amazon EKS 成本优化的最有效工具组合是集成 Kubecost、Karpenter、AWS Cost Explorer 和 Kubernetes auto-scaling tools。这种集成方法可在 cluster、workload 和 infrastructure 层面优化成本，提供可见性，并实现自动化优化。

关键成本优化工具和功能：

  1. Kubecost：

    • Kubernetes resource 成本可见性
    • 按 namespace、deployment、service 进行成本分配
    • 成本优化建议
    • 成本预测和预算管理

  2. Karpenter：

    • 智能 node provisioning 和管理
    • 选择与 workload 要求匹配的最优 instances
    • 快速 scaling 和高效资源利用
    • Spot Instance 利用率优化

  3. AWS Cost Explorer：

    • 跨 AWS services 的成本分析
    • 基于 tag 的成本分配
    • 成本趋势和预测
    • Reserved Instance 和 Savings Plans 建议

  4. Kubernetes Auto-scaling Tools：

    • Horizontal Pod Autoscaler (HPA)
    • Vertical Pod Autoscaler (VPA)
    • Cluster Autoscaler
    • Cluster Proportional Autoscaler

实施方法：

  1. Kubecost 安装和配置：

    bash
    # Install Kubecost using Helm
helm repo add kubecost https://kubecost.github.io/cost-analyzer/
helm install kubecost kubecost/cost-analyzer \
  --namespace kubecost \
  --create-namespace \
  --set kubecostToken="<YOUR_KUBECOST_TOKEN>" \
  --set prometheus.server.persistentVolume.size=100Gi \
  --set prometheus.nodeExporter.enabled=true \
  --set serviceMonitor.enabled=true

  2. Karpenter 安装和配置：

    bash
    # Install Karpenter
helm repo add karpenter https://charts.karpenter.sh
helm upgrade --install karpenter karpenter/karpenter \
  --namespace karpenter \
  --create-namespace \
  --set serviceAccount.create=true \
  --set serviceAccount.name=karpenter \
  --set serviceAccount.annotations."eks\.amazonaws\.com/role-arn"="arn:aws:iam::123456789012:role/KarpenterControllerRole" \
  --set controller.clusterName=my-cluster \
  --set controller.clusterEndpoint=$(aws eks describe-cluster --name my-cluster --query "cluster.endpoint" --output text)
    yaml
    # Karpenter NodePool and NodeClass configuration
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
        - key: "karpenter.sh/capacity-type"
          operator: In
          values: ["spot", "on-demand"]
        - key: "kubernetes.io/arch"
          operator: In
          values: ["amd64"]
        - key: "kubernetes.io/os"
          operator: In
          values: ["linux"]
        - key: "node.kubernetes.io/instance-type"
          operator: In
          values: ["m5.large", "m5a.large", "m5d.large", "m4.large", "t3.large", "t3a.large"]
      nodeClassRef:
        name: default
  limits:
    resources:
      cpu: 1000
      memory: 1000Gi
  disruption:
    consolidationPolicy: WhenEmpty
    consolidateAfter: 30s
---
apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
  name: default
spec:
  amiFamily: AL2
  role: KarpenterNodeRole
  subnetSelector:
    karpenter.sh/discovery: my-cluster
  securityGroupSelector:
    karpenter.sh/discovery: my-cluster
  tags:
    karpenter.sh/discovery: my-cluster

  3. 配置 Horizontal Pod Autoscaler：

    yaml
    apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80

  4. 配置 Vertical Pod Autoscaler：

    yaml
    apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: web-app-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: web-app
  updatePolicy:
    updateMode: "Auto"
  resourcePolicy:
    containerPolicies:
    - containerName: '*'
      minAllowed:
        cpu: 50m
        memory: 100Mi
      maxAllowed:
        cpu: 1
        memory: 1Gi
      controlledResources: ["cpu", "memory"]

工具集成和工作流：

  1. 成本可见性和分析：

    • Kubecost：In-cluster resource 成本分析
    • AWS Cost Explorer：跨 AWS services 的成本分析
    • 集成 dashboards：总体成本概览和趋势

  2. 自动化资源优化：

    • Karpenter：最优 node provisioning 和管理
    • HPA/VPA：workload-level resource 优化
    • Spot Instance 利用率：高性价比计算资源

  3. 成本分配和责任：

    • 基于 tag 的成本分配
    • 按 namespace 和 label 进行成本分析
    • 按团队和项目生成成本报告

  4. 持续优化和改进：

    • 实施成本优化建议
    • 定期成本审查和分析
    • 设置并跟踪成本降低目标

其他选项的问题：

  • A. 只使用手动资源管理：手动管理缺乏可扩展性，出错可能性高，并可能错过优化机会。
  • B. 只使用 AWS Cost Explorer：AWS Cost Explorer 对 AWS service-level 成本分析很有用，但不提供详细的 Kubernetes resource-level 成本分析或自动化优化功能。
  • D. 只使用 third-party cost management tools：third-party tools 可能有用，但与 AWS native services 和 Kubernetes auto-scaling tools 的集成可能有限，并且可能产生额外成本。