[k8s] 39. Autoscaler - HPA

Autoscaler - HPA

• 세 가지의 종류가 있음
• HPA: 파드의 개수를 늘림
• VPA: 파드의 리소스를 증가시킴
• CA: 클러스터에 노드를 추가
• 각 기능에 대해 간략히 알아보고 HPA에 대해 자세히 볼 예정

1. HPA

• 컨트롤러가 있고 replicas의 수치에 따라 파드가 운영
• 서비스도 파드에 연결이 돼서 모든 트래픽이 파드로 흐르는 상황
• 트래픽이 많아져서 어느 순간 파드내에 있는 리소스를 모두 사용하게 됨
• 조금 더 트래픽이 증가하면 파드는 죽을 수도 있음

• 사전에 HPA를 연결하고 컨트롤러에 연결했다면, HPA가 위험한 상황에 컨트롤러의 replicas를 2로 늘려줌
• 파드가 늘어나 자원이 수평적으로 늘어나는데 이를 Scale Out이라고 함
• 트래픽이 감소하여 리소스 사용량이 줄면 파드가 삭제되는데, 이를 Scale In이라 함
• 파드가 증가했기 때문에 트래픽은 각각 50%로 분산되고 자원이 배분

고려해야할 사항

• HPA는 장애를 처리하는 것이기 때문에 기동이 빨라야함
• Stateless App임, 쿠버네티스 1.9버전부터 StatefulSet에서도 HPA 지원
  • Stateful App에 사용하면 파드마다 역할이 있기때문에 HPA가 어느 파드를 늘리고 삭제할지 판단못함
  • 그러니까 Stateless App에다가 고고

2. VPA

• 컨트롤러에 replicas 1로 파드가 하나 만들어져 있음
• 메모리는 1G, CPU는 1C로 모두 사용되는 상황
• VPA를 컨트롤러에 달아놨으면, VPA는 이 상황에서 파드를 Restart 하면서 파드의 리소스 증가
• 리소스의 양이 수직적으로 증가하는 것을 Scale UP, 반대는 Scale Down

고려해야할 사항

• VPA는 Stateful App
• HPA와 VPA를 함께 사용하면 안 됨

3. CA

• 클러스터에 있는 모든 노드에 자원이 없을 경우 동적으로 worker node를 추가시킴
• 노드 2개가 있고 파드들이 운영되고 있음
• 이 때, 파드를 새로 만들면 스캐줄러를 통해 노드에 할당
• 노드들의 자원이 모두 사용된 상황이 되고 파드를 새로 생성하게 되면 파드를 로컬 노드에 배치 못하게 됨

• 이 때, scheduler는 CA에 worker node를 새로 생성해달라고 요청함
• CA를 사전에 특정 Cloud Provider에 연결하면 요청이 왔을 때, Provider에 노드를 만들어 스캐줄러는 파드를 그 노드에 배치

• 이렇게 운영하다 기존에 사용하는 파드가 없어져서 로컬에 자원이 남을 수가 있음
• scheduler는 CA에 Cloud Provider에 있는 파드를 삭제해달라고 함
• Cloud Provider에 있던 파드는 다시 로컬 노드로 옮겨짐

HPA Architecture

• 마스터와 워커노드들이 있음

마스터 노드

• 마스터에 Control Plane Component가 있음
• Control Plane Component에는 쿠버네티스에서 주요 기능을 하는 컴포넌트들이 파드 형태로 띄워져 있음
  • Controller Manager: Deployment, ..., HPA 등이 쓰레드 형태로 돌아감
  • kube-apiserver: 쿠버네티스의 모든 통신의 길목 역할

워커 노드

• Workor Node Component: 쿠버네티스 설치 시 kubelet 설치
• kubelet: 각각의 노드마다 설치되고 노드를 대표하는 에이전트 역할을 하여 자신의 노드에 있는 파드를 관리
• kubelet이 컨테이너를 만들진 않고 Controller Runtime이 실제 컨테이너를 생성하고 삭제함
• Controller Runtime에는 Docker, rkt, CoreOS 등이 있음

사용자가 ReplicaSet을 만들었을 때 과정

• ReplicaSet을 담당하는 쓰레드는 replicas가 1일 때 파드를 1개 만들어달라고 kube-apiserver를 통해 kubelet에 요청
• kublet은 파드에서 Container를 빼서 Controller Runtime에 만들어달라고 요청
• Contrller Runtime은 노드위에 Container를 만들어 줌

이 상황에서 HPA가 파드의 성능 정보를 어떻게 아는가

• Resource Estimator인 cAdvisor가 도커로부터 메모리나 CPU 성증정보를 측정
• 이 정보를 kubelet이 가져갈 수 있도록 함

AddOn Component

• AddOn Component로 metrics-server를 설치하면 이 서버가 각각의 노드에 있는 kubelet에 메모리와 CPU 정보를 저장
• 저장한 데이터들을 다른 컴포넌트들이 사용할 수 있도록 kube-apiserver에 등록
• 컴포넌트인 HPA가 kube-apiserver에서 이 정보를 가져옴
• 기본적으로 HPA는 15초마다 파드의 리소스 정보를 확인하다가 파드의 리소스 사용률이 높아지면 replicas를 증가
• kubectl top 명령어도 Resource API를 통해서 파드나 노드의 현재 리소스 상태를 알 수 있음
• Prometheus를 설치하면 단순 메모리나 CPU외에도 파드로 들어오는 패킷 수, Ingress로 들어오는 request 양 등을 측정
• HPA는 아무튼 이런 정보들을 바탕으로 컨트롤러의 replicas를 조정할 수 있음

HPA

 

• Replicas 2인 Deployment 생성, 파드 2개 생성
• HPA는 target으로 컨트롤러를 지정
• maxReplicas, minReplicas로 replicas의 max, minimum 지정
• metrics는 metric 정보에 어떤 조건을 통해서 replicas를 증가시킬지에 대한 부분
• type: Resource는 파드의 리소스를 가리킴
• 세부적으로 name에서 cpu를 볼지 메모리를 볼지 정할 수 있음
• 어떤 조건으로 증가시킬지에 대한 부분으로 type이 또 있음
• type에는 기본적으로 Utilization이 있음
  • averageUtilization이 50이면 파드의 requests 값을 기준으로 현 사용자원이 50%를 넘으면 replicas 증가
  • 수치를 넘을 때마다 하나씩 증가하는게 아니라 공식으로 결정

공식

• Utilization 말고 type에는 AverageValue, Value가 있음
  • AverageValue: 퍼센트가 아닌 원하는 성능의 실제 평균 값을 넣기
  • Value: 원하는 replicas의 값 넣기
• type: Resource외에 type: Pods, type: Object가 있음
• 파드에 서비스와 Ingress가 달려있다고 할 때, Custom API를 통해
  • type: Pods: 파드에 들어오는 패킷 수, 파드와 관련된 정보로 Scale In/Out
  • type: Object: 파드 외에 Ingress와 같은 정보를 사용할 때 사용
• Custom API를 사용하려면 Prometheus와 같은 플러그인이 설치되어 있어야 함

출처

인프런 - 대세는 쿠버네티스