8. Horizontal Pod Autoscaler(HPA)
• Pod replica의 갯수를 변경하여 scaling.
• CPU와 memory의 metrics를 base로 하여 scaling을 trigger.
• Multiple metrics, Custom metrics, external metrics를 base로
사용하는 것도 가능.
10. 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분을 기다린 후에 scale-
down event를 발생 시킨다.
→ kube-controller-manage의 --horizontal-pod-autoscaler-downscale-delay flag로 변경 가능.
• HPA는 Deployment object에서 최적으로 동작한다. HPA에서 target으로 설정된 Deployment의
replica를 직접적으로 수정하는 것은 바람직 하지 않다.
11. Custom Metrics를 사용하는 HPA
• autoscaling/v2alpha1 API object를 사용.
• 별도의 configuration 과정이 다수 필요.
• GKE에서는 Stackdriver adapter를 정식으로 지원.
• 이외의 환경에서는 Prometheus adapter를 사용해야 하지만 개발 상태는 초기 상
태.
• application에서 Prometheus format으로 custom metrics를 expose 해야 한다.
13. Vertical Pod Autoscaler(VPA)
• Pod의 CPU와 memory를 변경하여 할당.
• Pod의 restart되어 resource 변경.
• OOM(Out Of Memory) event에 반응.
• Pod에 할당할 수 있는 Min/Max resource를 설정 가능.
• 현재 alpha 개발 상태.
15. 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
를 잠식할 수 있음에 주의.
22. 실질적인 동작
• CA에서 node를 join 시키는데는 시간이 발생.
→ AWS + kops 환경에서는 5분 정도의 시간이 발생.
• Node resource가 여유가 있다면 HPA, VPA의 scaling은 수십초 내에 완료.
Solution?
Priority and Preemption
• Kubernetes 1.8에서 alpha feature로 소개.
• 1.11에서 beta로 변경, 기본적으로 enable.