[AEWS] 2기 스터디: Autoscaling 의 다양한 방법

⭐ 가시다(gasida) 님이 진행하는 AWS EKS Workshop 실습 스터디 게시글입니다.

이번 게시글은 Autoscaling 에 관한 내용을 설명합니다.

 

 

0. 사전 정보

DNS 호스팅 정보(Route53)

#게시글에서 사용하는 DNS 주소
jjongguet.com

 

 

사전 배포 내역

• 참고링크: https://jjongguet.tistory.com/205

#AWS LoadBalancer
AWS LB Controller

#Monitoring
kube-ops-view
Prometheus
Grafana

 

kube-ops-view, Prometheus, Grafna

 

 

 

모니터링: 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

# 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 --resources cpu,memory

EKS Node Viewer

 

 

모니터링 : K9s 배포

• 공식문서 : https://k9scli.io/

#설치
curl -sS https://webinstall.dev/k9s | bash

#적용
source ~/.config/envman/PATH.env

#실행
k9s

k9s (kuberenetes cli)

 

 

 

 

 

1. Kubernetes Autoscaling 의 대분류

Autoscaling 의 개념을 이해하기 전에, Scaling 을 먼저 이해하고자 합니다.

 

흔히 IT에서 Scale 을 다루는 가장 대표적인건 개발 인프라입니다.

인프라의 Scale 을 증가시킨다면, 크게는 Scale Up, Scale Out 으로 구분할 수 있습니다.

 

 

각각의 방식은 다음의 방법을 사용합니다.

Scale Up 은 ‘인프라를 구성하는 하드웨어의 Spec 을 높이는 방식’ 으로 인프라의 Scale 을 증가시킵니다.

전체 인프라의 성능은 올라가지만, 인프라를 구성하는 하드웨어의 갯수 는 변함이 없습니다.

Scale Out 은 ‘인프라를 구성하는 하드웨어의 갯수 를 높이는 방식’ 으로 인프라의 Scale 을 증가시킵니다.

전체 인프라의 성능은 올라가지만, 인프라를 구성하는 하드웨어 낱개의 성능 은 변함이 없습니다.

 

여기서 알 수 있는건, Scale 을 높이는데에는 크게 두가지 방식으로 구분된다는것입니다.

하드웨어의 단위 처리량을 늘리거나, 처리하는 하드웨어의 갯수를 늘려, 전체 Scale 을 높이는것입니다.

 

위에서 설명한 Scale의 개념은 Kubernetes 에서 동일하게 적용 할 수 있습니다.

일반적인 Kubernetes 에서는 Container, Node의 Scale을 다루거나

클라우드공급자(AWS EKS, GCP GKE…) 에서는 NodeGroup, NodePool 을 다룰 수 있습니다.

 

 

 

Kubernetes Autoscaling 의 종류

1. HPA(Horizontal Pod Autoscaling, 수평적)
   배치되는 Pod의 갯수 를 늘려서, 전체 트래픽을 감당하는 Pod의 갯수를 늘리는 구조
2. VPA(Vertical Pod Autoscaling, 수직적)
   배치되는 Pod의 용량 을 늘려서, 하나의 Pod가 조금 더 많은 트래픽을 감당하게 하는 구조
3. Cluster Autoscaling(CAS)
   배치되는 Node의 갯수를 늘려서, 전체 트래픽을 감당하는 Node의 갯수를 늘리는 구조

 

 

 

HPA Architecutre :

 

• HPA Controller Manager 는 Replicaset(or Deployment) 의 Scale 을 바꾸는 트리거링만 진행한다.

 

1-1 누가 Resource 를 노출시키는가?

위에서 Kubernetes의 Autoscaling 은 3가지 종류가 있으며 HPA, VPA, CA 라고 설명했습니다.

위 3가지 방식은 하나의 공통점이 있습니다.

‘특정한 조건이 충족되었을때에 작동하는’ Trigger 방식 이라는 것입니다.

 

Kubernetes에서는 다양한 조건을 사용하여 Trigger 시킬 수 있습니다.

가장 대표적인것은 Resource(CPU, MEM)입니다. 예를들면 ‘특정 Pod의 CPU 사용률이 n이 되었을때, Pod의 갯수를 m 으로 변화시킨다’ 같은 형태입니다.

 

따라서, Kubernetes에서 Resource 를 기반으로 Scaling 을 진행하려면, 현재 Resource 사용량을 알아야합니다. 해당 기능을 해주는 Object 는 metrics-server 입니다.

metrics-server를 배포하여 Pod 의 Resource 사용량을 알 수 있으며, 이를 기반으로 HPA, VPA 등의 Resource Based Autoscaling 이 가능합니다.

 

 

 

Metric 을 수집하는 원리는 간단합니다.

cAdviser 가 Container 의 Mem/CPU 수집 → kubelet에 전달 → kubelet 에 붙어서 Resource 를 확인하고 → Metrics API 를 통해 api-server 로 Resource 를 노출합니다.

metrics-server는 아쉽게도 Kubernetes 에서는 기본설치 컴포넌트로 취급하지 않으며, 추가적인 Object 로 배포해주어야합니다.

 

 

 

 

 

설치는 아래의 명령어를 통해 가능합니다.

#Kubernetes 1.21+ 
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/high-availability-1.21+.yaml

#Kubernetes 1.19~1.21
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/high-availability.yaml

더 궁금하다면 아래의 공식링크를 확인해주세요.

• 공식링크 : https://github.com/kubernetes-sigs/metrics-server

GitHub - kubernetes-sigs/metrics-server: Scalable and efficient source of container resource metrics for Kubernetes built-in aut

 

 

 

 

 

 

 

2. HPA - Horizontal Pod Autoscaler

세부 워크로드: HPA

 

 

그라파나 대시보드 링크(17125)

https://grafana.com/grafana/dashboards/17125-kubernetes-horizontal-pod-autoscaler

 

 

php-apache.yaml

apiVersion: apps/v1
kind: Deployment
metadata: 
  name: php-apache
spec: 
  selector: 
    matchLabels: 
      run: php-apache
  template: 
    metadata: 
      labels: 
        run: php-apache
    spec: 
      containers: 
      - name: php-apache
        image: registry.k8s.io/hpa-example
        ports: 
        - containerPort: 80
        resources: 
          limits: 
            cpu: 500m
          requests: 
            cpu: 200m
---
apiVersion: v1
kind: Service
metadata: 
  name: php-apache
  labels: 
    run: php-apache
spec: 
  ports: 
  - port: 80
  selector: 
    run: php-apache

 

• php-apache.yaml 에서 사용하는 registry.k8s.io/hpa-example 도커 이미지는 아래의 형태임

<?php
$x = 0.0001;
for ($i = 0; $i <= 1000000; $i++) {
            $x += sqrt($x);
}
echo "OK!";
?>

 

 

 

실습

# 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

• autoscale 명령어 : 특정 Object 를 Trigger 하는 HPA 를 배포하는 명령어

# Create the HorizontalPodAutoscaler : requests.cpu=200m - 알고리즘
# Since each pod requests 200 milli-cores by kubectl run, this means an average CPU usage of 100 milli-cores.

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% 이상인 경우

# 반복 접속 1 (파드1 IP로 접속) >> 증가 확인 후 중지
while true;do curl -s $PODIP; sleep 0.5; done

# 반복 접속 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"

 

 

Autoscaler 배포 하기 전

 

 

 

 

Autoscaler 배포한 이후

 

 

 

 

반복접속1 테스트

• php Object 가 추가적으로 생긴 모습

 

반복접속 종료

 

 

여기서 알 수 있는 점 :

• HPA 는 trigger 되는 특정 Resource가 trigger의 수치 이하가 되어도, 즉시 Object 가 Scale in 되지 않는다.
• 이유: HPA Autosclaer가 Trigger 명령을 내리기 위해 Resource 상태를 확인하는 시간이 정해져있다.

실습 이후 리소스제거 명령어

kubectl delete deploy,svc,hpa,pod --all

 

 

 

3. KEDA

HPA: 리소스(CPU, Memory) 메트릭을 기반으로 Scaling 여부를 결정한다.

KEDA: 특정 이벤트를 기반으로 Scaling 여부를 결정한다.

• 관련 게시글: https://jjongguet.tistory.com/197

 

 

 

KEDA Scaler : Kafka Trigger for an Apache Kafka Topic

triggers:
- type: kafka
  metadata:
    bootstrapServers: kafka.svc:9092 # Comma separated list of Kafka brokers “hostname:port” to connect to for bootstrap.
    consumerGroup: my-group          # Name of the consumer group used for checking the offset on the topic and processing the related lag.
    topic: test-topic                # Name of the topic on which processing the offset lag. (Optional, see note below)
    lagThreshold: '5'                # Average target value to trigger scaling actions. (Default: 5, Optional)
    offsetResetPolicy: latest        # The offset reset policy for the consumer. (Values: latest, earliest, Default: latest, Optional)
    allowIdleConsumers: false        # When set to true, the number of replicas can exceed the number of partitions on a topic, allowing for idle consumers. (Default: false, Optional)
    scaleToZeroOnInvalidOffset: false 
    version: 1.0.0                   # Version of your Kafka brokers. See samara version (Default: 1.0.0, Optional)

 

 

 

Grafana KEDA Dashboard

https://github.com/kedacore/keda/blob/main/config/grafana/keda-dashboard.json

 

 

 

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

 

 

 

KEDA 실습

# keda 네임스페이스에 디플로이먼트 생성(위에서 사용했던 php-apache.yaml)
kubectl apply -f php-apache.yaml -n keda
kubectl get pod -n keda

# 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 
#00, 15, 30, 45 분에 트리거 시작되고
#05, 20, 35, 50분에 트리거 종료되는 스케쥴으로 설정

# 그라파나 대시보드 추가
# 모니터링
watch -d 'kubectl get ScaledObject,hpa,pod -n keda'
kubectl get ScaledObject -w

# 확인
kubectl get ScaledObject,hpa,pod -n keda
kubectl get hpa -o jsonpath={.items[0].spec} -n keda | jq

 

 

 

 

cron 트리거링 되기 전(서울시간 26분)

 

 

cron 트리거링 시작 (서울시간 30분)

• keda(namespace) 에 Php-apache 생성된것 확인

 

 

 

cron 트리거링 진행 중(서울시간 36분)

• 30분 넘은 시점에 Current replicas 가 1로 증가 확인
• 35분에 cron job 종료이지만, 아직까지 Scale in 이 되지 않는 모습

 

 

 

 

cron 트리거링 종료된 시점(서울시간 41분)

• 35분에 cron job 은 종료되었으나, 실제로 scale in 이 된 시점은 이 시간이 지난 40분.
• 이유(추측) : kubernetes 는 명령을 받는 Object 에 1초단위로 모니터링을 진행하지 않음. 일정 주기로 모니터링을 진행하게 되는거 때문.

 

 

실습완료 후 리소스 제거

# KEDA 및 deployment 등 삭제
kubectl delete -f keda-cron.yaml -n keda && kubectl delete deploy php-apache -n keda && helm uninstall keda -n keda
kubectl delete namespace keda

 

 

 

 

4. VPA : Vertical Pod Autoscaler

세부 워크로드: VPA

 

 

VPA : Pod 의 resources.request를 최대한 최적값으로 수정, HPA와 같이 사용 불가능, 수정 시 파드 재실행

 

그라파나 대시보드 링크(대시보드 14588)

https://grafana.com/grafana/dashboards/14588-vpa-recommendations/

 

 

프로메테우스 쿼리 설정

#아래 중 하나
kube_customresource_vpa_containerrecommendations_target{resource="cpu"}
kube_customresource_vpa_containerrecommendations_target{resource="memory"}

 

 

실습 배포

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

# 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

 

 

배포된 모습

공식예제

• Pod가 실행되면 약 2~3분 뒤에 pod resource.request가 VPA에 의해 수정된다
  • VPA에 spec.updatePolicy.updateMode 를 off로 변경 시, Spec 을 자동으로 변경, 재실행하지않는다(기본값 Auto)

# 모니터링
watch -d "kubectl top pod;echo "----------------------";kubectl describe pod | grep Requests: -A2"

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

# 파드 리소스 Requestes 확인
kubectl describe pod | grep Requests: -A2

# VPA에 의해 기존 파드 삭제되고 신규 파드가 생성됨
kubectl get events --sort-by=".metadata.creationTimestamp" | grep VPA

 

 

 

배포 직후

 

 

배포 2-3분 이후

• 갑자기 Requests 200m짜리 pod 생성됨

 

 

 

실습 종료 후 리소스 삭제 스크립트

kubectl delete -f examples/hamster.yaml **&&** cd ~/autoscaler/vertical-pod-autoscaler/ && ./hack/vpa-down.sh

 

 

 

 

 

5. CA : Cluster Autoscaler

세부 워크로드 : CA

 

 

• Cluster Autoscale 동작을 하기 위한 cluster-autoscaler 파드(디플로이먼트)를 배치합니다.
• Cluster Autoscaler(CA)는 pending 상태인 파드가 존재할 경우, 워커 노드를 스케일 아웃합니다.
• 특정 시간을 간격으로 사용률을 확인하여 스케일 인/아웃을 수행합니다.
  • AWS에서는 Auto Scaling Group(ASG)을 사용하여 Cluster Autoscaler를 적용합니다.

설정 전 확인

# EKS 노드에 이미 아래 tag가 들어가 있음
# k8s.io/cluster-autoscaler/enabled : true
# k8s.io/cluster-autoscaler/myeks : owned
aws ec2 describe-instances  --filters Name=tag:Name,Values=$CLUSTER_NAME-ng1-Node --query "Reservations[*].Instances[*].Tags[*]" --output yaml | yh

 

 

 

CA 설정

# 현재 autoscaling(ASG) 정보 확인
# aws autoscaling describe-auto-scaling-groups --query "AutoScalingGroups[? Tags[? (Key=='eks:cluster-name') && Value=='클러스터이름']].[AutoScalingGroupName, MinSize, MaxSize,DesiredCapacity]" --output table
aws autoscaling describe-auto-scaling-groups \
    --query "AutoScalingGroups[? Tags[? (Key=='eks:cluster-name') && Value=='myeks']].[AutoScalingGroupName, MinSize, MaxSize,DesiredCapacity]" \
    --output table
-----------------------------------------------------------------
|                   DescribeAutoScalingGroups                   |
+------------------------------------------------+----+----+----+
|  eks-ng1-44c41109-daa3-134c-df0e-0f28c823cb47  |  3 |  3 |  3 |
+------------------------------------------------+----+----+----+

# MaxSize 6개로 수정
export ASG_NAME=$(aws autoscaling describe-auto-scaling-groups --query "AutoScalingGroups[? Tags[? (Key=='eks:cluster-name') && Value=='myeks']].AutoScalingGroupName" --output text)
aws autoscaling update-auto-scaling-group --auto-scaling-group-name ${ASG_NAME} --min-size 3 --desired-capacity 3 --max-size 6

# 확인
aws autoscaling describe-auto-scaling-groups --query "AutoScalingGroups[? Tags[? (Key=='eks:cluster-name') && Value=='myeks']].[AutoScalingGroupName, MinSize, MaxSize,DesiredCapacity]" --output table
-----------------------------------------------------------------
|                   DescribeAutoScalingGroups                   |
+------------------------------------------------+----+----+----+
|  eks-ng1-c2c41e26-6213-a429-9a58-02374389d5c3  |  3 |  6 |  3 |
+------------------------------------------------+----+----+----+

# 배포 : Deploy the Cluster Autoscaler (CA)
curl -s -O https://raw.githubusercontent.com/kubernetes/autoscaler/master/cluster-autoscaler/cloudprovider/aws/examples/cluster-autoscaler-autodiscover.yaml
sed -i "s/<YOUR CLUSTER NAME>/$CLUSTER_NAME/g" cluster-autoscaler-autodiscover.yaml
kubectl apply -f cluster-autoscaler-autodiscover.yaml

# 확인
kubectl get pod -n kube-system | grep cluster-autoscaler
kubectl describe deployments.apps -n kube-system cluster-autoscaler
kubectl describe deployments.apps -n kube-system cluster-autoscaler | grep node-group-auto-discovery
      --node-group-auto-discovery=asg:tag=k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/myeks

 

 

 

SCALE A CLUSTER WITH Cluster Autoscaler (CA)

# 모니터링 
kubectl get nodes -w
while true; do kubectl get node; echo "------------------------------" ; date ; sleep 1; done
while true; do aws ec2 describe-instances --query "Reservations[*].Instances[*].{PrivateIPAdd:PrivateIpAddress,InstanceName:Tags[?Key=='Name']|[0].Value,Status:State.Name}" --filters Name=instance-state-name,Values=running --output text ; echo "------------------------------"; date; sleep 1; done

# Deploy a Sample App
# We will deploy an sample nginx application as a ReplicaSet of 1 Pod
cat <<EoF> nginx.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-to-scaleout
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        service: nginx
        app: nginx
    spec:
      containers:
      - image: nginx
        name: nginx-to-scaleout
        resources:
          limits:
            cpu: 500m
            memory: 512Mi
          requests:
            cpu: 500m
            memory: 512Mi
EoF

kubectl apply -f nginx.yaml
kubectl get deployment/nginx-to-scaleout

 

 

Scale 변경

# Scale our ReplicaSet
# Let’s scale out the replicaset to 15
kubectl scale --replicas=15 deployment/nginx-to-scaleout && date

# 확인
kubectl get pods -l app=nginx -o wide --watch
kubectl -n kube-system logs -f deployment/cluster-autoscaler

 

 

상태확인

# 노드 자동 증가 확인
kubectl get nodes
aws autoscaling describe-auto-scaling-groups \
    --query "AutoScalingGroups[? Tags[? (Key=='eks:cluster-name') && Value=='myeks']].[AutoScalingGroupName, MinSize, MaxSize,DesiredCapacity]" \
    --output table

#eks-node-viewer 로 확인 
./eks-node-viewer --resources cpu,memory

# 디플로이먼트 삭제
kubectl delete -f nginx.yaml && date

 

 

 

리소스 삭제

# size 수정 
aws autoscaling update-auto-scaling-group --auto-scaling-group-name ${ASG_NAME} --min-size 3 --desired-capacity 3 --max-size 3
aws autoscaling describe-auto-scaling-groups --query "AutoScalingGroups[? Tags[? (Key=='eks:cluster-name') && Value=='myeks']].[AutoScalingGroupName, MinSize, MaxSize,DesiredCapacity]" --output table

# Cluster Autoscaler 삭제
kubectl delete -f cluster-autoscaler-autodiscover.yaml

 

 

 

6. CPA: Cluster Proportional Autoscaler

노드 수 증가에 비례하여 성능 처리가 필요한 Application을 수평으로 자동확장

 

 

#
helm repo add cluster-proportional-autoscaler https://kubernetes-sigs.github.io/cluster-proportional-autoscaler

# CPA규칙을 설정하고 helm차트를 릴리즈 필요
helm upgrade --install cluster-proportional-autoscaler cluster-proportional-autoscaler/cluster-proportional-autoscaler

# nginx 디플로이먼트 배포
cat <<EOT > cpa-nginx.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        resources:
          limits:
            cpu: "100m"
            memory: "64Mi"
          requests:
            cpu: "100m"
            memory: "64Mi"
        ports:
        - containerPort: 80
EOT
kubectl apply -f cpa-nginx.yaml

# CPA 규칙 설정
cat <<EOF > cpa-values.yaml
config:
  ladder:
    nodesToReplicas:
      - [1, 1]
      - [2, 2]
      - [3, 3]
      - [4, 3]
      - [5, 5]
options:
  namespace: default
  target: "deployment/nginx-deployment"
EOF
kubectl describe cm cluster-proportional-autoscaler

# 모니터링
watch -d kubectl get pod

# helm 업그레이드
helm upgrade --install cluster-proportional-autoscaler -f cpa-values.yaml cluster-proportional-autoscaler/cluster-proportional-autoscaler

# 노드 5개로 증가
export ASG_NAME=$(aws autoscaling describe-auto-scaling-groups --query "AutoScalingGroups[? Tags[? (Key=='eks:cluster-name') && Value=='myeks']].AutoScalingGroupName" --output text)
aws autoscaling update-auto-scaling-group --auto-scaling-group-name ${ASG_NAME} --min-size 5 --desired-capacity 5 --max-size 5
aws autoscaling describe-auto-scaling-groups --query "AutoScalingGroups[? Tags[? (Key=='eks:cluster-name') && Value=='myeks']].[AutoScalingGroupName, MinSize, MaxSize,DesiredCapacity]" --output table

 

 

# 노드 4개로 축소
aws autoscaling update-auto-scaling-group --auto-scaling-group-name ${ASG_NAME} --min-size 4 --desired-capacity 4 --max-size 4
aws autoscaling describe-auto-scaling-groups --query "AutoScalingGroups[? Tags[? (Key=='eks:cluster-name') && Value=='myeks']].[AutoScalingGroupName, MinSize, MaxSize,DesiredCapacity]" --output table

 

 

리소스 제거

helm uninstall cluster-proportional-autoscaler && kubectl delete -f cpa-nginx.yaml

 

-1. 실습 마무리(리소스 삭제)

실습마무리: EKS 리소스 삭제

eksctl delete cluster --name $CLUSTER_NAME && aws cloudformation delete-stack --stack-name $CLUSTER_NAME