일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- 헬름
- 클라우드 네이티브 자바
- Algorithm
- Spring
- nGrinder
- MySQL
- 쿠버네티스
- Kotlin
- 마이크로서비스
- 클라우드 네이티브
- CRD
- spring microservice
- 자바
- decorator 패턴
- Microservice
- devops
- cloud native
- ingress
- cloud native java
- Stress test
- 코틀린
- 익명클래스
- Semaphore
- 동기화
- Adapter 패턴
- ansible
- 머신러닝
- MSA
- java
- kubernetes
- Today
- Total
카샤의 만개시기
쿠버네티스 오토스케일러 본문
쿠버네티스에서는 리소스 부족을 처리하기 위하여
- 쿠버네티스 메트릭(metrics.k8s.io)
- 외부 정의 메트릭(external.metrics.k8s.io)
- 사용자 정의 메트릭 (custom.metrics.k8s.io)
위 메트릭 정보를 참고하여 하기 3가지 방식의 오토 스케일러를 사용한다.
Horizontal Pod Autoscaler (HPA)
클러스터의 Pod 수를 조정하여 오토스케일하는 방법이다.
HPA의 메트릭 허용 오차 값의 default 값은 10%이다.
- Metrics 값을 지속적으로(default 30sec) 체크한다.
- 임계치를 넘으면 Pod 수를 늘리기 위한 이벤트가 시작된다.
- Deployment / Replication Controller에 레플리카 수를 갱신한다.
- Deployment / Replication Controller는 필요한 Pod를 롤아웃한다.
Vertical Pod Autoscaler (VPA)
기존 Pod에 CPU나 메모리를 조정하여 오토스케일하는 방법이다.
다만 오토스케일시, 해당 파드는 새로운 리소스를 받아 재시작합니다.
VPA는 OOM에러가 발생하였을때도 반응하여 오토스케일할 수 있습니다.
- Metrics 값을 지속적으로(default 10sec) 체크한다.
- 임계치를 넘으면 할당된 CPU/Memory를 변경하기 위한 이벤트가 시작된다.
- Deployment / Replication Controller에 리소스 사양을 갱신한다.
- Pod은 재시작되고 새로 생성된 인스턴스에 리소스가 할당됩니다.
VPA는 updatePolicy.updateMode
에서 다음 2가지 모드를 지정할 수 있다.
Auto 모드
Pod의 리소스 사용량을 일정 주기 이상 모니터링한 후, 자동으로 Pod의 request 값을 변경하는 방식이다. 이 경우 원하지 않는 Pod의 리스타트가 발생할 수 있다.
Manual 모드
VPA가 직접 request 값을 변경하지 않고, 적절한 값을 추천해준다.
Manual 모드를 지정한 VPA로 운영하다가 kubetctl get vpa
명령어를 이용하면 추천되는 request 값을 볼 수 있다.
kubetctl get vpa [VPA name] --output yaml
현재 HPA와 VPA가 같이 사용될 수 없기 때문에 테스트 환경에서 VPA를 이용해 적절 리소스를 측정하고 운영환경에서 HPA를 적용하는 것이 좋다.
Cluster Autoscaler (CA)
위 2개의 오토스케일러는 리소스나 Pod의 수를 제어하는 방식이라면, CA는 Node의 수를 제어하는 방식이다.
AWS, Azure, Google Cloud 등 클라우드 인프라와 연동해서 동작하도록 되어 있고 각 벤더사마다 동작 방식의 차이가 있어 각 도큐먼트를 참고해야 한다.
클러스터의 용량이 충분하지 않아 Pod가 pending 상태로 유지되는 경우 Node의 수를 늘려 pending 상태인 Pod들 추가된 Node에 할당할 수 있다.
CA는 일정 주기로 scale up이 필요한지 체크하고 필요하지 않으면 scale down이 가능한지 체크하는데 노드의 리소스 사용량 총합이 기준치(default 50%)보다 작으면 scale down 절차를 고려한다. (노드를 축소하기 전에 기본적으로 10분은 대기하는 시간을 갖습니다.)
- 로컬 디스크를 사용하는 Pod은 옮길 수 없음.
- 컨트롤러 (ReplicationSet,Job 등)에 의해 관리되지 않는 naked pod는 옮길 수 없음.
cluster-autoscaler.kubernetes.io/safe-to-evict:True
옵션을 이용하여 CA에 의해 Pod가 옮겨지는 것을 막는 경우.- Affinity,Taint 등의 조건에 의해서 옮길 수 없는 경우.
조건에 부합하여 모든 Pod를 옮길 수 있다면, 삭제 될 대상의 노드에서 파드를 삭제하고, 해당 파드들은 다른 노드에서 생성되고 빈 노드는 삭제된다.
특정 Node를 CA에 의해 자동으로 제거되는 것을 막으려면 "cluster-autoscaler.kubernetes.io/scale-down-disabled": "true"
해당 레이블을 적용하면 된다.
- CA는 지속적으로(default 10sec) pending 상태의 파드를 체크한다.
- 파드를 할당 할 클러스터의 리소스가 부족하면 추가 노드를 프로비저닝합니다.
- 클라우드 공급자가 노드를 부여하면 클러스터에 연결되고 파드가 할당됩니다.
참고
'DevOps > Docker & K8S' 카테고리의 다른 글
쿠버네티스 레이블 vs 어노테이션 (0) | 2020.02.12 |
---|---|
쿠버네티스 디스케줄러(descheduler) (0) | 2020.01.29 |
쿠버네티스 리소스 관리하기 (0) | 2020.01.29 |
쿠버네티스 프로브 (활성 프로브, 준비성 프로브) (0) | 2020.01.29 |
쿠베네티스 헬름(Helm) (0) | 2020.01.22 |