[EKS 모범 사례] - karpenter

쿠버네티스에서 인프라는 컨트롤 플레인과 데이터 플레인으로 구성됩니다.

EKS는 가용성과 내결함성을 제공하도록 설계된 프로덕션 등급의 Kubernetes 컨트롤 플레인을 제공합니다.

AWS는 쿠버네티스 컨트롤 플레인의 신뢰성을 책임집니다.

EKS는 AWS 리전의 세 가용 영역에서 쿠버네티스 컨트롤 플레인을 실행합니다.

쿠버네티스 API 서버 및 etcd 클러스터의 가용성과 확장성을 자동으로 관리합니다.

 

EKS는 Kubernetes 데이터 플레인에 대한 세 가지 옵션을 제공

• Fargate - 데이터 플레인의 프로비저닝 및 확장을 처리
• 관리형 노드 그룹화 
• 자체 관리형 노드 - 데이터 플레인에 대한 관리가 가장 적은 옵션

 

Karpenter

데몬셋이 아닌 파드가 없는 인스턴스를 자동으로 확장하거나 종료하여 낭비를 줄입니다.

Karpenter는 단일 시스템 내 인스턴스 오케스트레이션 기능을 통합적으로 수행하며 더 간단하고 안정적입니다.

 

특징)

• 워크로드 요구 사항에 따라 노드를 프로비저닝합니다.
• 유연한 워크로드 프로비저너 옵션을 사용하여 인스턴스 유형별로 다양한 노드 구성을 생성합니다. Karpenter를 사용하면 많은 특정 사용자 지정 노드 그룹을 관리하는 대신 유연한 단일 프로비저너로 다양한 워크로드 용량을 관리할 수 있습니다.
• 노드를 빠르게 시작하고 파드를 스케줄링하여 대규모 파드 스케줄링을 개선합니다.

 

주의)

1. EKS Fargate 또는 노드 그룹에 속한 워커 노드에서 Karpenter 컨트롤러를 실행
   1. Karpenter가 관리하는 노드에서는 Karpenter를 실행하지 말 것
2. Karpenter에서 사용자 지정 시작 템플릿(launch template)을 사용하지 말 것
3. 워크로드에 맞지 않는 인스턴스 유형은 제외

CA

 

pod auto scaling -> pending pods -> CA(Cluster autoscaler) -> ASG(Auto Scaling Group) -> EC2 Fleet(instant)

 

CA와 ASG 사이에 통신이 필요했음.

 

 

대신 카펜터를 사용하면

pod auto scaling -> pending pods  -> karpenter -> EC2

 

Ec2 api 랑 바로 통신, 훨씬 빠름. 

Nodepool, Ec2nodeclass 사용

spot instance사용 가능. (기존 인스턴스의 최대 90% 할인된 가격)

 

cost optimization!

help upgrade patching.

 

 

 

계층화된 제약 조건을 사용하여 컴퓨팅 기능을 제한

 

• Global Constraints: 클러스터 전체에 적용되는 제약 조건 (예: 특정 리전이나 가용 영역에서만 노드를 프로비저닝).
• Provisioning Constraints: 새로운 노드를 프로비저닝할 때 적용되는 제약 조건 (예: 특정 인스턴스 유형, 리소스 요구 사항).
• Scheduling Constraints: 이미 존재하는 노드에 파드를 배치할 때 적용되는 제약 조건 (예: nodeAffinity, nodeSelector).

 

 

Karpenter의 계층형 제약 조건 모델을 사용하면 복잡한 프로비저너 및 파드 배포 제약 조건 세트를 생성하여 파드 스케줄링에 가장 적합한 조건을 얻을 수 있습니다. 

 

예시)

• 특정 애플리케이션만 사용할 수 있는 가용영역에서 실행해야 합니다. 예를 들어 특정 가용영역에 있는 EC2 인스턴스에서 실행되는 다른 애플리케이션과 통신해야 하는 파드가 있다고 가정해 보겠습니다. VPC의 AZ 간 트래픽을 줄이는 것이 목표라면 EC2 인스턴스가 위치한 AZ에 파드를 같은 위치에 배치하는 것이 좋습니다. 이런 종류의 타겟팅은 대개 노드 셀렉터를 사용하여 수행됩니다. 노드 셀렉터에 대한 추가 정보는 쿠버네티스 설명서를 참조하십시오.
• 특정 종류의 프로세서 또는 기타 하드웨어가 필요합니다. GPU에서 파드를 실행해야 하는 팟스펙 예제는 Karpenter 문서의 액셀러레이터섹션을 참조하십시오.

apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: global-provisioner
spec:
  # 클러스터 전체에 적용되는 제약 조건
  constraints:
    zones:
      - us-west-2a
      - us-west-2b
    instanceTypes:
      - m5.large
      - m5.xlarge
  limits:
    resources:
      cpu: "1000"
      memory: "2000Gi"

 

 

do-not-evict 

apiVersion: v1
kind: Pod
metadata:
  name: important-application
  annotations:
    karpenter.sh/do-not-evict: "true"  # 이 어노테이션을 추가하여 노드 종료 방지
spec:
  containers:
  - name: my-container
    image: my-application-image
    resources:
      requests:
        memory: "1Gi"
        cpu: "500m"
      limits:
        memory: "2Gi"
        cpu: "1000m"

이 어노테이션은 카펜터가 해당 파드가 종료되거나 어노테이션이 제거될 때까지 노드를 보존하게 만듭니다.

중요한 애플리케이션이 중단되는 것을 방지하는 데 유용합니다.

 

 

Drift

Karpenter 0.33 버전부터 Drift가 기본적으로 활성화됩니다. Karpenter의 CLI argument에서 —feature-gates Drift=false를 지정하여 Drift 기능을 비활성화할 수 있습니다.

 

Drift는 실행 중인 Worker Node와 Nodepool/EC2NodeClass 설정과의 차이를 자동으로 맞춰주는 기능입니다.

예를 들어 EC2NodeClass의 태그 설정을 변경하면 자동으로 Launch Template을 수정하고 Worker Node를 다시 생성합니다. 이로 인해 해당 EC2NodeClass을 사용하는 Nodepool의 Worker Node들은 모두 즉시 재시작 되어집니다!

강력한 기능이지만 모든 Worker Node가 동시에 재시작 되기 때문에 서비스 장애를 일으킬 수 있습니다.

 

잘 모르면.. 사용하지 말기..!!

 

 

drift 로 노드 업그레이드

Amazon EKS가 새 쿠버네티스 버전을 지원하는 경우, 단일 API 호출을 통해 Amazon Elastic Kubernetes Service (Amazon EKS) 클러스터 컨트롤 플레인을 다음 버전으로 업그레이드할 수 있습니다. 쿠버네티스 데이터 플레인을 업그레이드하려면 쿠버네티스 워커 노드에 대한 Amazon Machine Image(AMI)를 업데이트해야 합니다.

 

Karpenter는 롤링 배포 이후 Drift를 사용하여 쿠버네티스 노드를 업그레이드합니다. 노드가 디프로비저닝되면 새 파드 스케줄링을 방지하기 위해 노드가 cordon 상태가 되고 쿠버네티스 Eviction API를 사용하여 파드가 제거됩니다.

 

Karpenter로 프로비저닝된 쿠버네티스 노드가 원하는 spec에서 벗어난 경우, Karpenter는 신규 노드를 먼저 프로비저닝하고 이전 노드에서 파드를 제거한 다음 종료합니다. 

 

 

 

consolidation

consolidation  은 노드의 리소스 활용도를 높이고 비용을 절감하기 위해 작업 부하를 다른 노드로 이동시키는 기능입니다.

새로운 인스턴스 타입이나 용량 유형으로 적합한 노드를 생성하고, 기존의 비효율적인 노드에 있는 파드를 새로운 파드로 옮긴 후 기존의 노드를 삭제합니다.

 

consolidation은 ttlsecondsafterempy 와 같이 사용할 수 없습니다.

consolidation은 새로운 노드를 생성하고 기존의 노드에 있는 파드를 옮긴 후에 노드를 삭제하고, ttlsecondsafterempty 는 노드가 비어있는 상태에서 일정시간이 지나면 바로 노드를 삭제하는 서로다른 방식으로 노드를 삭제하기 때문에 같이 사용하면 충돌이 발생할 수 있습니다.

karpenter 는 프로비저너 단위로 consolidation 과 ttlsecondsafterempty 중 하나만 설정할 수 있도록 제한하고 있습니다.

 

apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: express-test
spec:
  # 워크로드 통합을 활성화하여 불필요한 노드를 제거하고, 제거할 수 없는 경우에는 그 크기를 줄여 클러스터의 비용을 절감합니다. 
  # ttlSecondsAfterEmpty 설정과는 상호 배타적입니다.
  consolidation:
    enabled: true
  requirements:
    - key: "karpenter.sh/capacity-type" # 지정하지 않으면 AWS cloud provider 웹훅이 기본값으로 on-demand 설정 합니다.
      operator: In
      values: ["spot", "on-demand"]
    - key: "karpenter.k8s.aws/instance-cpu"
      operator: In 
      values: ["c", "m", "r"]
  provider:
    instanceProfile: KarpenterNodeInstanceProfile-alpha
    subnetSelector:
      karpenter.sh/discovery: 'alpha'
    securityGroupSelector:
      karpenter.sh/discovery/alpha: 'alpha'
  labels:
    managedBy: carpenter

conslidation 설정은 프로비저너에서 설정 가능!

 

카펜터는 프로비저너를 기반으로 노드를 제어합니다.

각각의 사용에 따라 클러스터에 여러 프로비저너 설정들을 배포할 수 있습니다.

 

 

Consolidation 을 사용할 때 메모리에 대해 requests=limits 으로 구성

 

apiVersion: v1
kind: Pod
metadata:
  name: memory-sensitive-application
spec:
  containers:
  - name: my-container
    image: my-application-image
    resources:
      requests:
        memory: "1Gi"  # 요청
        cpu: "500m"
      limits:
        memory: "1Gi"  # 제한 (요청과 동일하게 설정)
        cpu: "1000m"

karpenter 의 consolidation 기능은 파드의 리소스 요청을 기준으로 노드를 최적화합니다.

하지만 파드가 요청보다 더 많은 리소스를 사용할 수 있도록 제한을 설정하지 않으면 메모리 부족 상황이 발생할 수 있으므로 메모리에 대해 requests 와 limits을 동일하게 설정하는 것이 좋습니다.