[Karpenter] 노드의 Deprovisioning 을 좀 더 아름답게~

 

매우매우매우 중요!

Karpenter v0.32 버전부터 리소스 이름들이 변경되어 참고 바랍니다. 개념은 똑같습니다.
(ex. Provisioners -> NodePools)

 

 

Karpenter 의 개념을 알고 싶다면 여기 참고!

 

Karpenter 를 파면 팔수록 정말 유용한 오픈소스인거 같아요. ASG 를 넘어서 훨씬 효율적이고 유동적으로 노드와 파드를 관리할 수 있게 해주거든요.

 

스케줄링 시스템을 개발하고 있는데, Karpenter 가 없었다면 많이 힘들었을 겁니다...

 

이번 글에서는 Karpenter 의 Deprovisioning 에 대해 알아보려고 합니다. 가장 핵심이라고 볼 수 있죠.

 

Deprovisioning 관련 옵션은 크게 2가지로 나눌 수 있어요.

 

- ttlSecondsAfterEmpty 와 ttlSecondsUntilExpired

- consolidation

 

이 옵션들은 사용하면 각각 어떻게 동작하는 지 한번 바로 알아보도록 하죠.

 

렛츠두더코드~

 

 

 

 

 

ttlSecondsAfterEmpty 와 ttlSecondsUntilExpired

---

ttlSecondsAfterEmpty 와 ttlSecondsUntilExpired 를 사용한 provisioner 의 샘플 yaml 입니다.

apiVersion: karpenter.k8s.aws/v1alpha1
kind: AWSNodeTemplate
metadata:
  name: aws-node-template
spec:
  blockDeviceMappings:
    - deviceName: /dev/xvda
      ebs:
        volumeSize: 12Gi
        volumeType: gp2
        encrypted: false
        
  securityGroupSelector:
    Name: "eks"
    
  subnetSelector:
    karpenter.sh/discovery: eks
    
  tags:
    karpenter.sh/discovery: eks
---
apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: provisioner
spec:
  providerRef:
    name: aws-node-template

  requirements:
    - key: "node.kubernetes.io/instance-type"
      operator: In
      values: [ "t3.small", "t3.medium" ]
    - key: "topology.kubernetes.io/zone"
      operator: In
      values: [ "ap-northeast-2a", "ap-northeast-2b", "ap-northeast-2c", "ap-northeast-2d" ]
    - key: "karpenter.sh/capacity-type"
      operator: In
      values: [ "on-demand"]
    - key: "kubernetes.io/arch"
      operator: In
      values: [ "amd64" ]

  limits:
    resources:
      cpu: "100"
      memory: 100Gi


  ttlSecondsUntilExpired: 2592000 # 30 Days = 60 * 60 * 24 * 30 Seconds;
  ttlSecondsAfterEmpty: 30

  # 모든 노드에 적용되는 label
  labels:
    role: container-scheduler-system
    provision: karpenter
    kubernetes.io/arch: amd64

  # 모든 노드에 적용되는 taints
  taints:
    - key: container-scheduler-system
      value: "true"
      effect: NoSchedule
    - key: kubernetes.io/arch
      value: "amd64"
      effect: NoSchedule
    - key: nvidia.com/gpu
      value: "false"
      effect: NoSchedule

위 코드를 .limit.resources 의 cpu 와 memory 를 각각 100, 100Gi 를 주었는데 생성된 모든 t3.small, t3.medium 의 cpu 와 memory 를 합친 값입니다.

t3.medium 으로만 따져보자면, t3.medium 은 2 cpu, 4 memory 이므로 최대 25 개의 t3.medium 가 생성됩니다.
limit 의 memory 가 100Gi 이기 때문이죠.

 

ttlSecondsAfterEmpty 은 provisioner 로 생성된 노드에 더 이상 파드가 없으면 (리소스가 없으면) 지정된 시간 후에 자동으로 노드를 종료시킵니다. 

 

위 코드라면 30초 뒤에 아무 리소스가 없으면 자동으로 종료되지요.

 

아래 이미지는 자동으로 종료되는 노드를 보여줍니다. 상태를 보면 SchedulingDisabled 인데 이 노드는 종료되기 때문에 더 이상 파드를 스케줄링 하지 않겠다는 겁니다.

 

그리고 EC2 콘솔를 확인해보면 역시나 종료 중인 것을 확인 할 수 있습니다.

 

30초라고는 하지만 정확히 30초 뒤에 종료되진 않고 30~40초 내에 종료됩니다.

 

ttlSecondsUntilExpired 은 provisioner 로 생성된 노드에 대해서 지정된 시간이 지나면 노드를 종료하고 다시 새롭게 생성합니다. 

 

이런 옵션이 왜 필요한거지? 라는 생각이 드실 수도 있지만, 오래된 노드를 새로운 노드로 교체하려는 것이 주 목적입니다.

 

구 버전의 노드를 삭제하고, 새로운 버전의 노드로 교체하는 것이지요. 즉, 노드를 자동으로 업데이트하려고 할 때 사용합니다.

 

위 코드라면 30일 뒤에 해당 노드는 삭제되고 새로운 버전의 노드가 다시 생성될 것입니다.

 

만약 아래처럼 ttlSecondsUntilExpired 을 더 높게 지정하면 어떻게 될까요?

  ttlSecondsUntilExpired: 30 
  ttlSecondsAfterEmpty: 300

 

보통 인스턴스를 프로비저닝 되는데 30초보다는 오래 걸립니다. 따라서 위와 같이 ttlSecondsUntilExpired 을 낮게 설정한다면, 정상적인 노드를 얻을 수 없습니다. 왜냐하면 프로비저닝 되는 과정 중에 30초(ttlSecondsUntilExpired의 값)가 지나버려 Karpenter 가 종료시켜버리고 또 새로운 노드를 프로비저닝 하기 때문입니다.

 

즉, 무한루프에 빠져 버려요!

 

아래 이미지처럼 동시에 노드를 프로비저닝하면서 디프로비저닝 시켜버립니다.

첫번째 줄의 노드가 생성되었지만 바로 종료되고, 두번째 줄의 노드가 생성되고 있죠.

 

노드에 배포된 파드 또한 계속 삭제되고 생성되는 걸 반복합니다.

 

EC2 콘솔을 확인해보면 종료 중, 실행 중이 계속해서 반복됩니다.

 

ttlSecondsAfterEmpty 와 ttlSecondsUntilExpired 을 이용하면 확실히 클러스터의 비용을 낮출 수 있어 보입니다.

필요할 때만 노드를 사용하고, 더 이상 필요하지 않으면 자동으로 종료해주기 때문이죠. 그리고 구 버전의 노드도 자동으로 새로운 버전의 노드로 교체할 수도 있습니다.

 

하지만 ttlSecondsAfterEmpty 와 ttlSecondsUntilExpired 보다 비용을 효율적으로 할 수 있는 방법이 있는데,

그것이 바로 consolidation 입니다.

 

 

consolidation

---

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

 

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

 

consolidation 기능은 클러스터의 안정성과 성능을 향상시키고, 스팟 인스턴스나 온디맨드 인스턴스와 같은 다양한 용량 유형을 혼합하여 사용할 수 있게 해줍니다.

 

 

 

적용 방법은 아래와 같습니다.

...

  consolidation:
    enabled: true

...

 

consolidation과 ttlSecondsAfterEmpty는 같이 사용할 수 없습니다.

두 기능은 서로 배타적인 방식으로 노드를 삭제하기 때문입니다. consolidation은 새로운 노드를 생성하고 기존의 노드에 있는 파드를 옮긴 후에 노드를 삭제합니다.

반면에 ttlSecondsAfterEmpty은 노드가 비어있는 상태에서 일정 시간이 지나면 바로 노드를 삭제합니다.

따라서 consolidation과 ttlSecondsAfterEmpty을 같이 사용하면 충돌이 발생할 수 있습니다. karpenter는 provisioner 단위로 consolidation과 ttlSecondsAfterEmpty 중 하나만 설정할 수 있도록 제한하고 있습니다.

 

consolidation 은 한번 실습을 해보죠!

 

 

consolidation 실습

---

실습에 사용할 deployment.yaml 입니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: inflate
spec:
  replicas: 5
  selector:
    matchLabels:
      app: inflate
  template:
    metadata:
      labels:
        app: inflate
    spec:
      terminationGracePeriodSeconds: 0
      containers:
        - name: inflate
          image: public.ecr.aws/eks-distro/kubernetes/pause:3.7
          resources:
            requests:
              cpu: 500m
              memory: 500Mi
            limits:
              cpu: 500m
              memory: 500Mi              
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                  - key: topology.kubernetes.io/zone
                    operator: In
                    values:
                      - ap-northeast-2a
                      - ap-northeast-2b
                      - ap-northeast-2c
                      - ap-northeast-2d
                  - key: karpenter.sh/capacity-type
                    operator: In
                    values:
                      - on-demand
                  - key: kubernetes.io/arch
                    operator: In
                    values:
                      - amd64
                  - key: node.kubernetes.io/instance-type
                    operator: In
                    values:
                      - t3.small
                      - t3.medium
      tolerations:
        - effect: NoSchedule
          key: container-scheduler-system
          value: "true"
        - effect: NoSchedule
          key: kubernetes.io/arch
          value: amd64
        - effect: NoSchedule
          key: nvidia.com/gpu
          value: "false"

 

.spec.resources.requests 의 cpu, memory 를 각각 500m, 500Mi 로 주어서 미리 노드에 리소스를 예약해두었습니다.

이로써 Karpenter 는 노드가 꽉 찼다는 걸 알 수 있고, 추가로 새롭게 노드를 생성할 수 있죠.

 

 

 

replica 를 5 로 지정했기 때문에 필요한 리소스는 총 2500m CPU, 2.5Gi Memory 입니다.

맨 처음 provisioner.yaml 대로라면, t3.small 이 2개 생성될 것입니다.

 

t3.small 의 memory 는 최대 2G 이므로 t3.small  2개로 충분히 커버가 가능합니다.

 

그럼 만약 provisioner.yaml 을 아래와 같이 수정하고 replica 를 10개로 늘리면 어떨까요?

(t3.small, t3.medium 을 지정하는 것이 아니고 t 로 시작하는 모든 인스턴스가 가능함)

requirements:
#    - key: "node.kubernetes.io/instance-type"
#      operator: In
#      values: [ "t3.small", "t3.medium" ]
    - key: "karpenter.k8s.aws/instance-category"
      operator: In
      values: ["t"]

 

총 5G CPU, 5Gi Memory 가 필요합니다. 그리고 t 유형의 인스턴스는 아래와 같죠.

 

t3 유형

t3a 유형

 

 

결과값을 먼저 보여드리면 아래와 같습니다.

 

t3.small 은 2 cpu, 2 memory

t3a.medium 은 2 cpu, 4 memory

t3a.xlarge 은 4 cpu, 16 memory

 

총 8 cpu, 22 memory 가 생성됩니다.

 

어? 이상합니다. 분명 필요한 리소스는 5G CPU, 5Gi Memory 입니다. 그럼 왜 Karpenter 를 위와 같이 생성을 했을까요?

 

이유는 각 노드들에는 해당 deployment pod 만 실행되고 있는 것이 아닙니다. aws controller, ebs-csi, prometheus 등 데몬셋이 띄어져있죠. 그래서 데몬셋을 제외한 나머지 리소스로 계산하기 때문에 실제로 필요한 리소스보다 더 많은 리소스를 가진 노드들이 생성된 것이죠.

 

그리고 t3.small, t3a.medium, t3a.xlarge 가 비용면에서 가장 효율적이라고 Karpenter 가 생각했기 때문에 이와 같은 결과가 나타났습니다.

 

Karpenter 는 어떻게 동적으로 노드를 생성하고 이 노드가 가장 합리적이라고 생각할 수 있을까요?

바로 EC2 Fleet 이라는 기능 덕분이죠. 이는 EC2 에서 개발한 기능으로 필요한 리소스에 대해 최적의 효율성을 계산해줍니다.

EC2 Fleet 이 궁금하다면 여기 참고!
Karpenter 의 Fleet 이 궁금하다면 여기 참고!

 

 

오늘은 Karpenter 의 Deprovisioning 옵션에 대해 알아봤습니다. Karpenter 를 이용하면 굳이 ASG 를 쓸 필요가 없어지면 비용을 매우 효율적으로 할 수 있죠.

 

더 자세한 정보가 알고 싶다면 Karpenter 의 공식 문서를 참고하시길 바랍니다 :)

 

그럼 오늘은 여기까지!