AEWS Study 5 주차 (Autoscailing, hpa, keda, karpenter)

이어서 5주차 Autoscailing을 정리해본다.

마찬가지로 구축 내용은 스킵하고 그 외 자세한 내용을 정리한다

 

---

pod Autoscailing

 

kubernetes는 아래와 같이 2개의 Pod Autoscailing을 지원한다.

 

HorizontalPodAutoscaler : 줄여서 HPA는 워크로드 리소스 수요에 맞게 워크로드를 자동으로  수평 확장하는 것이다.

VerticalPodAutoscaler : 줄여서 VPA는 워크로드 리소스 수요에 맞게 워크로드를 수직 확장하는 것이다.

 

 

 

hpa 테스를 위하여 아래와 같이 연산작업을 이미지로 생성하고 파드, svc, hpa 생성 해준다

<?php
$x = 0.0001;
for ($i = 0; $i <= 1000000; $i++) {
			$x += sqrt($x);
}
echo "OK!";
?>
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata: 
  name: php-apache
  namespace: default
spec: 
  maxReplicas: 10
  metrics: 
  - resource: 
      name: cpu
      target: 
        averageUtilization: 50
        type: Utilization
    type: Resource
  minReplicas: 1
  scaleTargetRef: 
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache

 

해당 명령어로 Pod는 0.01초마다 http://php-apache로 요청을 보내어 성능 테스트 작업을 수행한다.

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"

위와 같이 CPU 활용률이 50% 이상인 경우 트래픽에 맞게 파드가 증설되는것을 확인 가능하다.

해당 성능테스트가 끝나고 cpu 사용률이 돌아오면 다시 파드가 줄어든것을 확인 가능하다

 

vpa 같은 경우는 helm chart를 따로 지원해주지 않아 git에서 코드를 가져오면 된다.

중요한게 openssl11 version 이상을 사용해야한다고 한다.

 

아까와 같이 성능 테스트를 해보면 vpa가 작동되어 provided 되어지는것을 확인 가능

파드 리소스 Requestes 확인해보면 아래와 같이 기존 100m에서 548m로 증가된것을 확인할 수 있다.

 

VPA에 의해 기존 파드 삭제되고 신규 파드가 생성되어졌다

 

이제까지 vpa는 stateful한 성격으로 파드각 삭제되지않고 스케일 업되는것으로 이해했는데 파드가 삭제되고 새로운 파드가 생성되었다.

강의에서 말한거처럼 해당 리소스를 사용하기에는 어려움이 있고 hpa가 더 좋아보인다

 

KEDA - Kubernetes based Event Driven Autoscaler

msa환경에서 이벤트 기반 아키텍쳐는 자주 사용하는 모델로서 KEDA는 기존 hpa와는 다르게 리소스(CPU, Memory) 메트릭을 기반으로 스케일 여부를 결정하는것이 아닌 특정 이벤트를 기반으로 스케일 여부를 결정할 수 있다.

 

예를 들어 airflow는 metadb를 통해 현재 실행 중이거나 대기 중인 task가 얼마나 존재하는지 알 수 있습니다.

이러한 이벤트를 활용하여 worker의 scale을 결정한다면 queue에 task가 많이 추가되는 시점에 더 빠르게 확장할 수 있다 한번 사용하고 싶었던 리소스인데 테스트해.

 

공식문서에 cron 사용해서 부하 테스트를 작업한다고한다.

 

keda는 전용 메트릭 서버를 가지있다. cpu기반이 아니기 때문에 다른 메트릭 서버를 가지고 있는것 같다

 

성능 테스트 파드인 apache server를 15분마다 5분 동안 실행한 후 종료하는 cron을 생성

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"

```

 

cron 통해 30분에 apache server 생성되는것을 확인 가능

 

node Autoscailing

 

방금은 Pod 단위의 Scale In/Out이며, CA, Karpenter는 Node 단위의 Scale In/Out 기능이다.
CA는 Pending 상태의 Pod가 발생하면 , Work Node를 Scale Out을 하며, 이 때의 Work node는 AWS의 ASG를 사용한다.

 

우선 시작에 앞서 해당 테그 2개가 있어야 자동으로 검색? 된다한다.

 

또한 시작전에 현재는 max가 3인 설정에서 6으로 변경

현재 3개의 노드가 구성 테스트 deployment를 생성하고 replica를 15로 늘리면 아래와이 5개의 노드로 확장된것을 확인 가능하다.

 

ca는 살짝 레거시한 느낌이 있고 현재는 많은 기업에서 karpenter를 도입하고 poc과정이라 한다.

비용, 성능 등 다양한 방면에서 karpenter가 월등히 좋은것 같다.

 

아래 영상에서 정말 자세하게 설명을 잘해주었다

https://youtu.be/FPlCVVrCD64

 

 

karpenter

Auto Scaler의 기능은 같지만 CA는 이미 EC2 Spec이 결정된 ASG의 Node를 바탕으로 Node의 Scale In/Out을 하는 반면, Karpenter는 Provisioner CRD를 통해 시작 템플릿의 대부분의 설정 부분을 대신하여 Pod의 자원 수요를 계산하여 여기에 맞는 Node를 Provisioning한다. 

• Provisioner CRD : 시작 템플릿이 필요 없습니다! ← 시작 템플릿의 대부분의 설정 부분을 대신함
  • 필수 : 보안그룹, 서브넷
  • 리소스 찾는 방식 : 태그 기반 자동, 리소스 ID 직접 명시
  • 인스턴스 타입은 가드레일 방식으로 선언 가능! : 스팟(우선) vs 온디멘드, 다양한 인스턴스 type 가능
• Pod에 적합한 인스턴스 중 가장 저렴한 인스턴스로 증설 됩니다
• PV를 위해 단일 서브넷에 노드 그룹을 만들 필요가 없습니다 → 자동으로 PV가 존재하는 서브넷에 노드를 만듭니다
• 사용 안하는 노드를 자동으로 정리, 일정 기간이 지나면 노드를 자동으로 만료 시킬 수 있음
  • ttlSecondsAfterEmpty : 노드에 데몬셋을 제외한 모든 Pod이 존재하지 않을 경우 해당 값 이후에 자동으로 정리됨
  • ttlSecondsUntilExpired : 설정한 기간이 지난 노드는 자동으로 cordon, drain 처리가 되어 노드를 정리함
    • 이때 노드가 주기적으로 정리되면 자연스럽게 기존에 여유가 있는 노드에 재배치 되기 때문에 좀 더 효율적으로 리소스 사용 가능 + 최신 AMI 사용 환경에 도움
  • 노드가 제때 drain 되지 않는다면 비효율적으로 운영 될 수 있습니다
• 노드를 줄여도 다른 노드에 충분한 여유가 있다면 자동으로 정리해줌!
• 큰 노드 하나가 작은 노드 여러개 보다 비용이 저렴하다면 자동으로 합쳐줌!
• → 기존에 확장 속도가 느려서 보수적으로 운영 하던 부분을 해소
• 오버 프로비저닝 필요 : 카펜터를 쓰더라도 EC2가 뜨고 데몬셋이 모두 설치되는데 최소 1~2분이 소요 → 깡통 증설용 Pod를 만들어서 여유 공간을 강제로 확보!
• 오버 프로비저닝 Pod x KEDA : 대규모 증설이 예상 되는 경우 미리 준비

설치 과정 생략

Provisioner을 아래와 같이 생성

apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: default
spec:
  requirements:
    - key: karpenter.sh/capacity-type
      operator: In
      values: ["spot"]
  limits:
    resources:
      cpu: 1000
  providerRef:
    name: default
  ttlSecondsAfterEmpty: 30
---
apiVersion: karpenter.k8s.aws/v1alpha1
kind: AWSNodeTemplate
metadata:
  name: default
spec:
  subnetSelector:
    karpenter.sh/discovery: ${CLUSTER_NAME}
  securityGroupSelector:
    karpenter.sh/discovery: ${CLUSTER_NAME}

AWSNodeTemplate을  통하여 노드에 최소한 서브넷과 보안그룹 정보를 제공

values를 spot을 생성했으며 따로 타입을 지정하지 않아서 제일 싸고 알맞은 타입으로 생성될것이다

ttlSecondsAfterEmpty : 미사용 노드 정리, 데몬셋 제외

ttlSecondsUntilExpired에 의한 Deprovisioning에 대비해서 PodDisruptionBudget(PDB) 설정을 통해 워크로드 중단 속도를 조절할 수 있다

 

Provisioner을 배포하면 아래와 같이 spot인스턴스의 노드가 생성되는것을 확인 가능

 

여러 Node가 떠 있을 경우, 비용 계산을 해서 비용이 큰 Node 1개가 더 저렴할 경우, 작은 Node 여러개가 더 저렴한 경우  Node 교체를 해주는 Consolidation 기능도 제공해주고 있다.

apiVersion: karpenter.sh/v1alpha5
kind: Provisioner
metadata:
  name: default
spec:
  consolidation:
    enabled: true
  labels:
    type: karpenter
  limits:
    resources:
      cpu: 1000
      memory: 1000Gi
  providerRef:
    name: default
  requirements:
    - key: karpenter.sh/capacity-type
      operator: In
      values:
        - on-demand
    - key: node.kubernetes.io/instance-type
      operator: In
      values:
        - c5.large
        - m5.large
        - m5.xlarge

 

이와 같이 비용, 속도 측면에서 월등히 ca를 앞도한다

물론 참조한 영상과 같이 예상 오토스케일링 같은 기능은 없지만 이 부분도 오버 프로비저닝을 한다던가 운영을 잘하면 해결할 수 있을거같다 이런 단점에도 비용을 줄일 수 있는게 최고의 장점같다