대세는 쿠버네티스 [초급~중급] 강의를 보고 정리한 글입니다. [중급 편] Autoscaler
Autoscaler 종류
replicas가 1인 Controller가 관리하는 Pod가 있고 Service 트래픽의 100%가 이 Pod로 들어온다. 이 상태에서 트래픽이 증가한다면 어떻게 될까? Pod의 Memory, CPU 리소스가 고갈되고 심지어 죽을 수도 있다. 아래 3가지 방법으로 이를 대비해보자.
HPA(Horizontal Pod Autoscaler) : Pod 개수 증가
HPA는 Pod의 리소스 상태를 감지하고 있다가 위험한 상황 발생 시 Controller의 replicas를 1 -> 2로 증가시킨다. Controller는 Pod를 하나 더 만들게 되고 Pod는 수평적으로 증가하게 된다. 이를 Scale Out(<-> Scale In)이라고 한다. 결과적으로 Service의 트래픽은 50%, 50%로 분산돼서 Pod로 전달된다.
기동이 빠른 앱, Stateless 앱에 사용한다. (Stateful 앱은 Pod마다 역할이 있는데 HPA는 이 역할을 상관없이 Pod를 만들기 때문)
VPA(Vertical Pod Autoscaler) : Pod 리소스 증가
VPA는 Pod의 리소스 상태를 감지하고 있다가 Pod의 리소스를 증가시킨다. 이를 Scale Up(<-> Scale Down)이라고 한다. 예) Memory 1G -> 2G, CPU 1C -> 2C
Stateful App에 사용한다.
하나의 Controller에 HPA, VPA를 동시에 사용할 수 없다.
CA(Cluster Autoscaler) : Cluster에 Worker Node 추가
Pod Scheduler에 의해 pod가 Node1, Node 2에 생성된다. Pod가 계속 생성되어 각 Node의 자원이 고갈된다면 어떻게 될까? CA를 이용해 이 상황을 대비해보자.
Scheduler는 CA에 Node 생성을 요청하고 사전에 CA에 연결해둔 Clode Provider(AWS)에 Node를 만든다. Scheduler는 이제 Cloud Provider Node에 Pod를 만들게 된다.
로컬 Node의 자원에 다시 여유가 생긴다면 Scheduler는 CA에 Node 삭제를 요청하고 Node가 삭제되며 안에 있던 Pod는 로컬 Node로 옮겨진다.
HPA Architecture
k8s 주요 컴포넌트는 Pod 형태로 돌아가고 Controller Manager의 Deployment, ReplicaSet 등은 스레드 형태로 돌아간다.
apiserver는 모든 통신의 길목 역할을 한다. 사용자뿐만 아니라 k8s 컴포넌트도 db, 타 컴포넌트 접근 시 사용한다.
워커 노드 컴포넌트에 설치되는 kubelet은 agent 역할을 하며 pod를 관리한다.
Controller Runtime(docker)은 실제로 컨테이너를 생성/삭제하는 구현체다.