You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »




Autoscaling이란?

  • Application의 확장 → pod scaling
  • 효율적인 Container 운영
  • 지속적으로 변하는 사용자 workload 처리

가. HPA (Horizontal Pod Autoscler)

가-1. HPA 개요

  • Pod replica의 갯수를 변경하여 scaling.
  • CPU와 memory의 metrics를 base로 하여 scaling을 trigger.
  • Multiple metrics, Custom metrics, external metrics를 base로 사용하는 것도 가능.

가-2. HPA Workflow

가-3. HPA에 대하여 알아야 할 것들

  • 기본 HPA sync 주기는 30초.
    → controller manager의 --horizontal-pod-autoscaler-sync-period flag로 변경 가능.
  • HPA는 metrics가 안정되도록 HPA event 후에 3분을 기다린 후에 scale-up event를 발생시킨다.
    → kube-controller-manage의 --horizontal-pod-autoscaler-upscale-delay flag로 변경 가능.
  • HPA는 replica의 개수가 요동치는 변동을 겪지 않도록 HPA event 후에 5분을 기다린 후에 scaledown event를 발생 시킨다.
    → kube-controller-manage의 --horizontal-pod-autoscaler-downscale-delay flag로 변경 가능.
  • HPA는 Deployment object에서 최적으로 동작한다. HPA에서 target으로 설정된 Deployment의 replica를 직접적으로 수정하는 것은 바람직 하지 않다.


Custom Metrics를 사용하는 HPA
• autoscaling/v2alpha1 API object를 사용.
• 별도의 configuration 과정이 다수 필요.
• GKE에서는 Stackdriver adapter를 정식으로 지원.
• 이외의 환경에서는 Prometheus adapter를 사용해야 하지만 개발 상태는 초기 상태.
• application에서 Prometheus format으로 custom metrics를 expose 해야 한다.


나. VPA (Vertical Pod Autoscaler)



나-1. VPA 개요

  • Pod의 CPU와 memory를 변경하여 할당.
  • Pod의 restart되어 resource 변경.
  • OOM(Out Of Memory) event에 반응.
  • Pod에 할당할 수 있는 Min/Max resource를 설정 가능.
  • 현재 alpha 개발 상태.

나-2. VPA Workflow

나-3. VPA에 대하여 알아야 할 것들

  • VPA의 metrics check 간격은 10초.
  • VPA의 변경으로 인해 모든 Pod들이 restart되는 것을 방지하기 위해 Pods Distribution Budget(PDB)가 반영.
  • Pod를 restart하지 않고 resource를 변경할 수 없음.
    → Pod는 stop된 후에 새로 할당된 resource들을 기반으로 rescheduling된다.
  • VPA와 HPA는 아직 서로 호환되지 않으며 동일한 pod에서 동작되지 않는다.
    → cluster 내에서 이 둘을 사용하기 위해서는 구성할 때 사용범위를 확실하게 분리해야 한다.
  • VPA는 resource request만 조정하고 limit은 설정하지 않으므로 오동작하는 application이 resource를 잠식할 수 있음에 주의.

다. CA (Cluster Pod Autoscaler)

다-1. CA 개요

  • Pending pod들을 기반으로 cluster node들을 scaling.
  • Cloud provider와 통신하여 node 증가 또는 idle node들의 회수를 진행
  • 현재 GCP, AWS, Azure를 지원.
  • Kubernetes 1.8 version에서 CA 1.0(G.A)이 release.

다-2. CA Workflow

다-3. CA 대해 알아야 할 것들

  • CA가 pending pod들을 check하는 간격은 10초이며 30초마다 필요한 추가 node를 계산.
  • CA는 사용률이 높지 않은 node들의 scale down은 10분을 대기하고 수행.
  • Annotation의 "cluster-autoscaler.kubernetes.io/safe-to-evict": "true".
    → 적절히 사용. 남용하여 대다수의 pod들이 사용되면 scale down에 대한 flexibility가 떨어짐.
  • scale down에서 pod들이 quorum을 유지하도록 PodDisruptionBudgets를 사용.


다-4. Autoscaler 결합 workflow


실제 동작

  • CA에서 node를 join 시키는데는 시간이 발생.
    → AWS + kops 환경에서는 5분 정도의 시간이 발생.
  • Node resource가 여유가 있다면 HPA, VPA의 scaling은 수십초 내에 완료.



  • No labels