5주차 - EKS Autoscaling - (Pod Autoscaling)

 

 

Autoscaling이란

오토스케일링(autoscaling)은 서버 팜의 컴퓨팅 리소스 양(일반적으로 활성 서버 수로 측정)을 동적으로 조정하는 클라우드 컴퓨팅에 사용되는 한 방식이다. (위키백과)

 

클라우드를 배우면서 클라우드의 장점이라고 배우는 내용 중 "Autoscaling"은 빠질 수 가 없다.

웹 서비스를 운영한다고 했을 경우, 트래픽이 증가하게 되면 이에 적절하게 서버의 스펙 증가 (Scale-UP/Down)을 하거나, 서버의 수를 증가(Scale-In/Out)하여 대처를 하게 된다.

 

Kubernetes 환경에서도 동일하게 트래픽이 증가한다면 어떻게 해결해야 할까?

 

클러스터의  Node를 추가하거나 또는 Pod추가하여 해결 할 수 있다.  

 

이번 5주차 Autoscaling에서는 AWS EKS 환경에서 Pod Autoscaling과 Node Autoscaling의 내용을 다룬다.

 

첫번째 포스트는 Pod Autoscaling에 대해서 알아보자!

 

이번 Autoscaling 실습에 앞서 Node들의 리소스 사용률을 볼 수 있는 "eks-node-viewer"를 설치하여 사용할 예정이다.

# go 설치
wget https://go.dev/dl/go1.22.1.linux-amd64.tar.gz
tar -C /usr/local -xzf go1.22.1.linux-amd64.tar.gz
export PATH=$PATH:/usr/local/go/bin
go version
go version go1.22.1 linux/amd64

# EKS Node Viewer 설치 : 약 2분 이상 소요
go install github.com/awslabs/eks-node-viewer/cmd/eks-node-viewer@latest

# [신규 터미널] EKS Node Viewer 접속
cd ~/go/bin && ./eks-node-viewer
혹은
cd ~/go/bin && ./eks-node-viewer --resources cpu,memory

명령 샘플
# Standard usage
./eks-node-viewer

# Display both CPU and Memory Usage
./eks-node-viewer --resources cpu,memory

# Karenter nodes only
./eks-node-viewer --node-selector "karpenter.sh/provisioner-name"

# Display extra labels, i.e. AZ
./eks-node-viewer --extra-labels topology.kubernetes.io/zone

# Specify a particular AWS profile and region
AWS_PROFILE=myprofile AWS_REGION=us-west-2

기본 옵션
# select only Karpenter managed nodes
node-selector=karpenter.sh/provisioner-name

# display both CPU and memory
resources=cpu,memory

 

eks-node-viewer 화면

 

또한  프로메테우스 & 그라파나 설치하여 Scaling 과정을 모니터링 할 예정이다. (추천 대시보드: 15757, 17900, 15172) 

 

 

HPA: Horizontal Pod Autoscaling

 

HPA란 Pod의 수량을 조절하는(Scale In/Out) Pod Autoscaling이다.

Metric-Server에서 클러스터의 리소스 사용 데이터를 확인하여 동작!

 

실습 시나리오

 

1. php-apache.yaml을 배포 (Web Server Pod)

2. HPA 생성 및 부하를 발생하여 Pod Autoscaling 확인

 

1. php-apache.yaml 배포

# Run and expose php-apache server
curl -s -O https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/application/php-apache.yaml
cat php-apache.yaml | yh
kubectl apply -f php-apache.yaml

# 확인
kubectl exec -it deploy/php-apache -- cat /var/www/html/index.php
...

# 모니터링 : 터미널2개 사용
watch -d 'kubectl get hpa,pod;echo;kubectl top pod;echo;kubectl top node'
kubectl exec -it deploy/php-apache -- top

# 접속
PODIP=$(kubectl get pod -l run=php-apache -o jsonpath={.items[0].status.podIP})
curl -s $PODIP; echo

 

2. HPA 생성 및 부하 발생

 

kubectl "autoscale" 명령어를 사용하여 HPA 설정

• cpu-percent=50 : Pod의 CPU 사용률을 확인 후 50%넘어가면 HPA 작동
• min=1 / max=10 : Pod의 최소/최대 수량 설정
• scaleTargetRef: autoscale 대상 선택 → 현재 php-apache Deployment를 Target으로 선택

kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10

# HPA 설정 확인
kubectl get hpa php-apache -o yaml | kubectl neat | yh
spec: 
  minReplicas: 1               # [4] 또는 최소 1개까지 줄어들 수도 있습니다
  maxReplicas: 10              # [3] 포드를 최대 5개까지 늘립니다
  scaleTargetRef: 
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache           # [1] php-apache 의 자원 사용량에서
  metrics: 
  - type: Resource
    resource: 
      name: cpu
      target: 
        type: Utilization
        averageUtilization: 50  # [2] CPU 활용률이 50% 이상인 경우

# 반복 접속 2 (서비스명 도메인으로 파드들 분산 접속) >> 증가 확인(몇개까지 증가되는가? 그 이유는?) 후 중지 >> 중지 5분 후 파드 갯수 감소 확인
# Run this in a separate terminal
# so that the load generation continues and you can carry on with the rest of the steps
kubectl run -i --tty load-generator --rm --image=busybox:1.28 --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"

 

부하 발생 시 Pod가 증가하는 것을 확인 할 수 있음

 

Grafana 대시보드를 통해 Pod 추가 생성 및 부하를 끄면 Pod가 감소하는 것을 확인 할 수 있음

 

KEDA: Kubernetes based Event Driven Autoscaler

HPA의 경우 기준이 CPU, MEM이여서 Autoscaling 사용의 한계가 있음.
KEDA의 경우 다양한 Application의 이벤트에 대해서 Kubernetes Autoscaling을 지원

KEDA 동작 과정

 

KEDA 공식 홈페이지에서 다양한 Scalers를 지원하는 것을 확인 할 수 있음

 

실습 시나리오

 

1. KEDA 설치

2. php-apache.yaml을 배포 (Web Server Pod) / keda namespace

3. ScaledObject 정책 생성 : cron

4. 위 Cron 설정을 통해 정해진 시간에 Pod 생성 및 삭제 확인

 

1. KEDA 설치

# KEDA 설치
cat <<EOT > keda-values.yaml
metricsServer:
  useHostNetwork: true

prometheus:
  metricServer:
    enabled: true
    port: 9022
    portName: metrics
    path: /metrics
    serviceMonitor:
      # Enables ServiceMonitor creation for the Prometheus Operator
      enabled: true
    podMonitor:
      # Enables PodMonitor creation for the Prometheus Operator
      enabled: true
  operator:
    enabled: true
    port: 8080
    serviceMonitor:
      # Enables ServiceMonitor creation for the Prometheus Operator
      enabled: true
    podMonitor:
      # Enables PodMonitor creation for the Prometheus Operator
      enabled: true

  webhooks:
    enabled: true
    port: 8080
    serviceMonitor:
      # Enables ServiceMonitor creation for the Prometheus webhooks
      enabled: true
EOT

kubectl create namespace keda
helm repo add kedacore https://kedacore.github.io/charts
helm install keda kedacore/keda --version 2.13.0 --namespace keda -f keda-values.yaml

# KEDA 설치 확인
kubectl get all -n keda
kubectl get validatingwebhookconfigurations keda-admission
kubectl get validatingwebhookconfigurations keda-admission | kubectl neat | yh
kubectl get crd | grep keda

 

• HPA, VPA는 metric-server를 통하여 자원의 상태를 확인하지만, KEDA의 경우 별도의 keda-operator-metircs-apiserver를 설치하여 사용

 

2. php-apache.yaml을 배포 (Web Server Pod) / keda namespace

# keda 네임스페이스에 디플로이먼트 생성
kubectl apply -f php-apache.yaml -n keda
kubectl get pod -n keda

 

3. ScaledObject 정책 생성 : cron

• triggers: cron trigger 설정 → 00분, 15분, 30분, 45분 Pod 생성 / 05분, 20분, 35분, 50분 Pod 삭제
  • desiredReplicas: 희망하는 Pod 수량 / 1개
• scaleTargetRef: autoscale 대상 선택 → 현재 php-apache Deployment를 Target으로 선택

# ScaledObject 정책 생성 : cron
cat <<EOT > keda-cron.yaml
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: php-apache-cron-scaled
spec:
  minReplicaCount: 0
  maxReplicaCount: 2
  pollingInterval: 30
  cooldownPeriod: 300
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  triggers:
  - type: cron
    metadata:
      timezone: Asia/Seoul
      start: 00,15,30,45 * * * *
      end: 05,20,35,50 * * * *
      desiredReplicas: "1"
EOT
kubectl apply -f keda-cron.yaml -n keda

 

4. 위 Cron 설정을 통해 정해진 시간에 Pod 생성 및 삭제 확인

• 설정된 Cron Trigger에 의해 Pod가 생성 및 삭제되는 것을 확인 할 수 있음

 

VPA: Vertical Pod Autoscaling

VPA란 Pod의 스펙을 조절하는(Scale Up/Down) Pod Autoscaling이다.

Pod의 resources.request을 최적값으로 수정 → 수정된 request값에 따라 Pod의 스펙이 조절

 

VPA의 경우 HPA와 같이 사용 할 수 없으며, resources.request을 최적값으로 수정하면 기존 Pod는 종료하고 새로운 Pod를 생성한다.

 

실습 시나리오

 

1. VPA 설치

2. hamster.yaml을 배포(공식 예제)

3. Pod 리소스 Requestes 확인 및 신규 Pod 생성 확인

 

1. VPA 설치

# 코드 다운로드
git clone https://github.com/kubernetes/autoscaler.git
cd ~/autoscaler/vertical-pod-autoscaler/

# openssl 버전 확인
openssl version
OpenSSL 1.0.2k-fips  26 Jan 2017

# openssl 1.1.1 이상 버전 확인
yum install openssl11 -y
openssl11 version
OpenSSL 1.1.1g FIPS  21 Apr 2020

# 스크립트파일내에 openssl11 수정
sed -i 's/openssl/openssl11/g' ~/autoscaler/vertical-pod-autoscaler/pkg/admission-controller/gencerts.sh

# Deploy the Vertical Pod Autoscaler to your cluster with the following command.
watch -d kubectl get pod -n kube-system
cat hack/vpa-up.sh
./hack/vpa-up.sh

kubectl get crd | grep autoscaling
kubectl get mutatingwebhookconfigurations vpa-webhook-config
kubectl get mutatingwebhookconfigurations vpa-webhook-config -o json | jq

 

2. hamster.yaml을 배포(공식 예제)

# 공식 예제 배포
cd ~/autoscaler/vertical-pod-autoscaler/
cat examples/hamster.yaml | yh
kubectl apply -f examples/hamster.yaml && kubectl get vpa -w

 

• resourcePolicy 설정 → 최소/최대 Pod의 cpu,mem 설정
  • controlledResources: cpu, memory → VPA가 조정 할 리소스 내용
• targetRef: autoscale 대상 선택 → 현재 hamster Deployment를 Target으로 선택

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

 

3. Pod 리소스 Requestes 확인 및 신규 Pod 생성 확인

• haster-vpa recommander가 생성되어 Pod의 최적 CPU/MEM 사용율 계산 - CPU: 548m

 

• hamster pod 생성 시 Requests CPU: 100m / MEM: 50Mi
• hamster pod 기동 시 실제 pod의 resource 사용률: CPU: 약 450 / MEM: 0Mi

•  VPA에 의해 신규 Pod 생성 - 위 recommander가 계산한 CPU: 548m로 Pod 생성

 

• Resource.Requests CPU: 100m인  Pod 1개 삭제 진행

 

• VPA에 의해 두번 째 신규 Pod 생성 - 위 recommander가 계산한 CPU: 548m로 Pod 생성

 

• Resource.Requests CPU: 100m인  두번 째 Pod 삭제 진행

 

→ 최종 VPA에 의해 생성된 Pod 2개를 확인 할 수 있음