📌 Scaling resources for a workload the manual way

(수동 리소스 확장 방법)

$ kubectl top pod my-app-pod
NAME              CPU(cores)              MEMORY(bytes)
my-app-pod   450m                        350Mi

• 위 명령어로 리소스 소비 모니터링
• 이를 위해 메트릭 서버가 실행 중이어야 한다
• 특정 임계값에 도달하면 pod를 수직 확장을 위해 아래 예시

$ kubectl edit deployment my-app 

• 이후 resource 아래 requests와 limits 필드를 변경하고 저장
• 해당 pod가 죽고 새 pod가 만들어진다
• 하지만 수동은 바람직 하지 않고 VPA를 사용

📍Vertical Pod Autoscaler (VPA)

• HPA와 달리 VPA는 기본 제공 되지 않는다
• 따라서 GitHub 리포지토리에 있는 VPA 정의 파일을 apply -f 명령어로 적용

$ kubectl apply -f https://github.com/kubernetes/autoscler/release/latest/download/vertical-pod-autoscaler.yaml
$ kubectl get pods -n kube-system | grep vpa
   vpa-admission-controller-xxxx       Running
   vpa-recommender-xxxx                  Running
   vpa-updater-xxxx                             Running

• VPA Deployment는 여러 구성 요소로 이루어져 있음
• admission-controller, recommender, updater

🤝 recommender

• recommender는 K8S 메트릭 API에서 리소스 사용량을 지속적으로 모니터링하고 Pod의 과거 및 실시간 사용량 데이터를 수집하고 최적의 CPU 및 메모리 값에 대한 권장 사항 제공
• recommender 자체는 pod를 직접 수정하거나 변경 X

🔺updater

• updater는 최적이 아닌 리소스로 실행 중인 pod를 감지하고 업데이트가 필요할때 해당 pod를 제거
• recommender로 부터 정보를 가져와서 모니터링 함

👑 admission-controller

• pod 생성 프로세스에 개입하고 recommender 의 권장 사항을 사용하여 시작시 권장 CPU 및 메모리 값을 적용하도록 pod 사양을 변경
• 이렇게 하면 새로 생성된 pod가 올바른 리소스 요청으로 시작

💡VPA recommender 정보 수집 > updater 가 정보를 모니터링 and 실제 pod와 비교한 다음, 임계값 초과시 Pod 죽임 (정책에 따라 다르게 작동함, 이상적으로는 pod를 죽이고 admission-controller가 개입하는게 좋지만, pod가 죽으면 자동으로 deployment가 다시 생성함 > 어쨌든 pod가 죽고 `admission-controller가 리소스를 업데이트 하여 새로운 크기를 갖게 한다.

⚙️How to make

$ vi my-app-vpa.yaml

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: my-app-vpa
spec:
  targetRef:          // 모니터링 대상 정의
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  updatePolicy:
    updateMode: “Auto”
  resourcePolicy:
    containerPolicies:
    - containerName: “my-app”
      minAllowed:
        cpu: “250m”
      maxAllowed:
        cpu: “2”
      controlledResources: [“cpu”]

• updateMode는 네가지 모드로 작동

1. Off
   : 변경 사항만 권장하고 아무 작업도 하지 않음, 오직 recommender만 동작 (updater, admission-controller는 작동 X)
2. initial : 생성 시에만 pod를 변경하는 모드 recommender가 변경을 권장하고 새 pod가 생성되면 이때 admission-controller가 개입하여 리소스 정의를 변경한다. 이 경우 updater는 pod를 죽이거나 다운시키는데 작동하지 않는다?
3. Recreate : 리소스 소비가 지정된 범위를 초과하면 updater가 개입하여 기존 pod 종료
4. Auto : 기존 pod를 권장 수로 업데이트하는 자동 모드가 있다. recreate와 동작이 유사함 안정적인 쿠버네티스 버전에서 리소스의 in-place 업데이트를 사용할 수 있는 경우, Auto mode가 default가 된다.

# 권장 사항 확인
$ kubectl describe vpa my-app-vpa
    
   Recommendations:
      Target:
         Cpu:     1.5

🗝️ Key Differences

VPA

• 개별 pod 성능 최적화
• pod를 재시작하여 새 리소스 값을 적용 👉 다운타임이 발생
• pod가 재시작 되어 트래픽 폭증에 대응 불가능
• 비용 최적화 측면에서 실제 사용량에 맞게 CPU 및 메모리 할당을 조정하여 over-provisioning을 방지
• 상태 저장 워크로드 및 DB JVM 기반 애플리케이션, 미세 조정된 리소스가 필요한 AI ML 워크로드와같이 많은 리소스를 사용하는 애플리케이션에 적합

HPA

• 여러 인스턴스에 걸쳐 부하를 분산하는데 중점
• 기존 pod를 계속해서 실행하고 새 pod를 간단히 스핀업 하여 가용성 보장
• 트래픽 폭증에 대응 가능하다(빠른 확장이 필요한 애플리케이션에 선호)
• 불필요한 유휴 pod를 방지하여 과도한 인스턴스를 실행하지 않고 효율적으로 사용할 수 있도록 돕는다.
• 웹 앱, 마이크로 서비스, 웹 서버, 메시지 대기열, API 기반 애플리케이션 같이 변동하는 트래픽을 처리하기 위해 빠른 확장이 필요한 상태 비저장 서비스에 이상적

💡 올바른 오토스케일러를 선택하는 것은 워크로드 유형과 애플리케이션의 확장 방식에 따라 달라진다.

# CRDs (Custom Resource Definitions) 조회 명령어
$ kubectl get crds | grep verticalpodautoscaler
`
``