[5주차] EKS Autoscaling - KARPENTER - USING ALTERNATIVE PROVISIONERS

CloudNet@ 팀의 AWS EKS Workshop Study 5주차 정리입니다.
# Karpenter Workshop 의 내용입니다.

---

• 각 프로비저너 CRD(Custom Resource Definition)는 지원하는 리소스와 해당 프로비저너에 의해 생성된 새 리소스에 적용될 labels 및 taints 를 정의하는 일련의 고유한 구성을 제공합니다.
• 여러 애플리케이션이 있는 대규모 클러스터에서는 새 애플리케이션이 특정 taints 또는 특정 labels 을 가진 노드를 생성해야 할 수 있습니다. 이러한 시나리오에서는 대체 프로비저너를 구성할 수 있습니다.

 

• 이미 앞의 실습에서 team1 프로비저너를 정의했습니다.
• 다음 명령을 실행하여 사용 가능한 프로비저너를 나열할 수 있습니다:

kubectl get provisioners

---

team1 프로비저너를 사용하는 Deployment 생성

cat <<EOF > inflate-team1.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: inflate-team1
spec:
  replicas: 0
  selector:
    matchLabels:
      app: inflate-team1
  template:
    metadata:
      labels:
        app: inflate-team1
    spec:
      nodeSelector:
        intent: apps
        kubernetes.io/arch: amd64
        karpenter.sh/provisioner-name: team1
      containers:
      - image: public.ecr.aws/eks-distro/kubernetes/pause:3.2
        name: inflate-team1
        resources:
          requests:
            cpu: "1"
            memory: 256M
      tolerations:
      - key: team1
        operator: Exists
      topologySpreadConstraints:
      - labelSelector:
          matchLabels:
            app: inflate-team1
        maxSkew: 1
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: ScheduleAnyway
EOF
kubectl apply -f inflate-team1.yaml

• deployment 는 이 애플리케이션이 클러스터와 함께 생성된 관리형 노드 그룹과 겹치지 않도 NodeSelector intent: apps를 설정
  
  
• NodeSelector karpenter.sh/provisioner-name: team1도 설정됩니다. 이 NodeSelector 는 이 deployment에 대한 용량을 프로비저닝할 때 어떤 프로비저너 구성을 사용할지 선택하는 데 Karpenter에서 사용됩니다. 이를 통해 예를 들어 프로비저너마다 다른 Taint 섹션을 정의할 수 있습니다.
  
  
• NodeSelector kubernetes.io/arch는 amd64 인스턴스를 사용하도록 설정
  
  
• team1 프로비저너에는 team1 taint 를 정의하는 섹션이 있었습니다. deployment 는 Taint team1:NoSchedule 을 사용하여 새로 생성된 인스턴스에 배치할 수 있도록 해당 toleration 도 추가해야 합니다.:  NoSchedule은 team1에 대한 toleration 이 있는 애플리케이션만 허용된다는 것을 의미

  taints:
  - effect: NoSchedule
    key: team1

---

inflate-team1 deployment 를 4개의 replicas로 확장합니다.

kubectl scale deployment inflate-team1 --replicas 4

---

Karpenter는 어떤 프로비저너를 사용했습니까? 어떤 노드가 선택되었습니까?

kubectl get node --selector=intent=apps,karpenter.sh/provisioner-name=team1 --show-labels

• 아래 출력에서 선택된 인스턴스가 on-demand 이고 유형이 c5a.xlarge 임을 알 수 있습니다.

---

Karpenter가 이전 시나리오에서와 같이 bin-packing 대신 생성을 두 개의 다른 노드로 분할한 이유는 무엇입니까?

      topologySpreadConstraints:
      - labelSelector:
          matchLabels:
            app: inflate-team1
        maxSkew: 1
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: ScheduleAnyway

• 이는 배포 섹션의 topologySpreadConstraints: 섹션과 관련이 있을 수 있습니다.
• 최신 버전의 카펜터(>0.4.1)는 Kubernetes Topology Spread Constraints 을 지원합니다.
• 하나 또는 여러 개의 topologySpreadConstraint 를 정의하여 클러스터의 기존 Pods 와 관련하여 들어오는 각 Pods 를 배치하는 방법을 kube-scheduler 에 지시할 수 있습니다.
  
  
• bin-packing 은 여전히 일어나고 있지만, topologySpreadConstraint 가 적용되어 사용 가능한 kubernetes.io/zone 전체에 워크로드를 분산시키도록 하는 것 뿐입니다.

2023-05-25T07:39:59.437Z        DEBUG   controller.provisioner.cloudprovider    discovered new ami      {"commit": "982c35f", "provisioner": "team1", "ami": "ami-0adb2d953343322be", "query": "/aws/service/bottlerocket/aws-k8s-1.23/x86_64/latest/image_id"}
2023-05-25T07:39:59.572Z        DEBUG   controller.provisioner.cloudprovider    created launch template {"commit": "982c35f", "provisioner": "team1", "launch-template-name": "Karpenter-eksworkshop-eksctl-2932845908794371073", "launch-template-id": "lt-0d135637bf5363aab"}

• 로그에서 보면 team1 프로비저너의 프로바이더 섹션에 있는 노드 템플릿을 기억하신다면, 사용자 정의 추가 부트스트랩과 함께 Bottlerocket을 사용했습니다.

spec:
  amiFamily: Bottlerocket

• 로그에서 Karpenter가 Karpenter-eksworkshop-eksctl-2932845908794371073 실행 템플릿을 생성하고 최신 버전의 AMI와 구성에 추가된 부트스트래핑에 따라 이를 조정하는 과정을 확인할 수 있습니다. 이렇게 하면 EC2 인스턴스의 수명 주기 관리 및 패치가 크게 간소화됩니다.

---

두 deployment 를 replicas 를 0으로 변경합니다.

---

[ 정리 ]

• 특정 labels 또는 Taints 가 필요한 애플리케이션은 해당 애플리케이션 집합에 맞게 사용자 정의된 대체 프로비저너를 사용할 수 있습니다. 이는 대규모 클러스터의 일반적인 설정입니다.
  
  
• Pods 는 올바른 프로비저너를 가리키는 karpenter.sh/provisioner-name 레이블을 가진 nodeSelector 를 설정하여 프로비저너를 선택할 수 있다.
  
  
• Karpenter 는 topologySpreadConstraints 를 지원한다. Topology Spread constraints 은 클러스터의 기존 Pod 와 관련하여 들어오는 각 Pod 를 배치하는 방법을  kube-scheduler 에 알려줍니다.
  
  
• Launch Templates 을 관리할 필요 없이 추가 bootstrapping 매개변수를 구성할 수 있으므로 bootstrapping 추가 매개변수를 적용하는 데 필요한 과중한 작업을 제거하면서 EC2 인스턴스의 수명 주기 관리 및 패치를 간소화할 수 있습니다.