쿠버네티스의 HPA/VPA 오토스케일링을 위한 모니터링 아키텍처
조대협 (http://bcho.tistory.com)
쿠버네티스에서 HPA/VPA는 내부 메트릭을 이용하여 오토스케일링을 판단하는데, 이를 위해서 내부 메트릭을 수집하고 서빙하기 위한 모니터링 아키텍쳐가 어떻게 구현되었는지에 대해서 알아본다.
- 각 노드에서 동작하는 컨테이너에 대한 리소스 정보 (CPU,메모리, 네트워크 사용량)은 cAdvisor를 통하여 수집되어 Kubelet을 통해서, 컨트롤 플레인에 전달된다.
- cAdvisot는 컨테이너에 대한 리소스 정보만 수집하지만, Kubelet은 컨테이너 이외의 노드나 애플리케이션에 대한 정보를 수집한다.
- 이렇게 Kubelet에 저장된 정보는 metric server로 전달되고, metric api 에 의해서 스케쥴러나 HPA/VPA와 같은 오토스케일러에 전달되서 사용된다.
Metric server는 히스토리 정보를 저장하지 않고, 그때 순간에 대한 정보만 가지고 있으며, 특히 쿠버네티스 내부에 메트릭 정보를 전달하기 위한 용도이기 때문에, 히스토릭칼한 타임 시리즈 정보를 저장하고 이를 그라파나와 같은 대쉬 보드 시스템을 이용해서 시각화하기 위해서는 별도의 모니터링 시스템이 필요한데, 이때 프로메테우스가 사용된다.
프로메테우스는 Kublet에서 CPU,메노리, 네트워크와 같은 리소스에 대한 기본 메트릭 (Resource metric)을 수집하지만, 이외에도 워크로드 (Pod 안에서 기동되는 애플리케이션)으로 부터 코드로 구현된 다양한 메트릭을 추가로 수집할 수 있다. 예를 들어서 특정 API에 대한 응답 시간등을 커스텀 메트릭 (Custom metric)으로 구현하여 모니터링으로 사용할 수 도 있다
Custom Metrics을 이용한 오토스케일링
프로메테우스에서 수집된 메트릭을 단순 모니터링이 아니라 HPA/VPA의 오토스케일링용 메트릭으로 사용이 가능하다. HPA/VPA는 오토스케일링을 위해서 Metric API만을 사용하기 때문에, HPA/VPA가 프로메테우스내의 메트릭을 읽어올 수 있게 하려면 프로메테우스의 메트릭을 Metric API로 서빙할 수 있도록 해줘야 하고, 이 역할을 하는 것이 프로메테우스 아답터이다. (https://github.com/kubernetes-sigs/prometheus-adapter)
프로메테우스는 CPU/메모리와 같은 리소스 메트릭뿐 아니라, API응답 시간과 같은 애플리케이션단의 메트릭 수집이 가능하기 때문에, 오토 스케일링시 ”API 응답시간이 5초 이상이 될때 오토스케일링을 해라"와 같은 애플리케이션 관점의 설정이 가능하다.
Cloud 서비스에서 오토 스케일링
클라우드 서비스에서 쿠버네티스의 경우, 클라우드 서비스의 매트릭을 수집하여, 이를 오토 스케일링에 활용할 수 있다. 이를 External metric이라고 한다.
예를 들어 메시지 큐의 길이가 00 이상이 되면 HPA를 통해서 Pod의 수를 늘리게 하거나 로드 밸런서의 트래픽이 000 QPS 이상이 되면 VPA를 통해서 CPU양을 조정하는 등의 역할을 할 수 있다.
이렇게 하려면, 클라우스 서비스에 대한 메트릭을 수집하여 Metric API로 서빙을 해야 하는데, 클라우드 모니터링 시스템의 메트릭을 Metric API로 연결해주는 역할을 하는 것이 Adapter이다. 클라우드에서 제공되는 매니지드 쿠버네티스의 경우 이와 유사한 아키텍쳐를 취하고 있다.
종종 클라우드 모니터링 시스템의 비용이 높아서, 클라우드 모니터링 시스템을 disable 한 상태에서 VPA/HPA를 사용할 수 있는가 에 대한 질문이 있는데, 대부분의 경우 가능하다. 이유는 HPA/VPA는 metric server가 수집한 CPU/메모리/네트워크 와 같은 리소스 메트릭을 사용하여 오토스케일링을 하기 때문에, 클라우드 모니터링 시스템에서 수집한 정보를 필요로 하지 않는다.
그러나 애플리케이션에서 올라오는 Custom metric을 사용하거나 또는 클라우드 서비스내의 메트릭 (External metric)을 사용할 경우 클라우드 모니터링을 비활성화 할 경우 사용할 수 없다.
(노트 : 클라우드 모니터링은 클라우드내의 매니지드 서비스에 대한 매트릭을 수집하기도 하지만, 대부분 애플리케이션단의 Custom metric을 수집하는 기능을 지원한다. 그래서 프로메테우스 없이도 애플리케이션의 Custom metric 수집이 가능하다. 그럼에도 불구하고 클라우드 상에서 프로메테우스를 사용하는 경우는 벤더락인을 제거하기위해서 프로메테우스 인터페이스로 코딩을 통일하고, 모니터링 대쉬보드를 오픈소스를 이용하는 등의 이유이다)
Prometheus 중앙 집중형 아키텍처
만약에 클라우드 상에서, 모니터링 인터페이스를 클라우드 모니터링을 사용하지 않고, 프로메테우스로 일원하고자 할 경우에는 아래와 같은 아키텍처 구성이 가능하다.
이를 위해서는 클라우드 모니터링에서 모니터링하는 메트릭을 프로메테우스로 수집해야 하는데, 프로메테우스에서 외부에서 메트릭을 수집하는 방법중 하나가 Exporter를 이용하는 방법이다. 각 클라우드 벤더의 모니터링 솔루션에 맞는 Exporter를 이용하게 되면, 클라우드 모니터링상의 지표를 프로메테우스로 수집하여, 프로메테우스 상에서 클라우드와 쿠버네티스의 모든 메트릭을 수집하여 서빙할 수 있게 할 수 있다.
참고 자료 :
http://blog.itaysk.com/2019/01/15/Kubernetes-metrics-and-monitoring
'클라우드 컴퓨팅 & NoSQL > 도커 & 쿠버네티스' 카테고리의 다른 글
간단하게 알아보는 Kubernetes Operator의 개념과 Kopf 프레임웍 (1) | 2022.12.28 |
---|---|
이벤트 베이스 쿠버네티스 오토스케일링 KEDA (3) | 2022.08.05 |
도커 컨테이너 파일 포맷 및 Image Pull Time (0) | 2022.01.25 |
Prometheus 를 스케일링 하기 위한 Thanos (타노스) (1) | 2020.02.08 |
오픈소스 모니터링 툴 - Prometheus #3 그라파나를 이용한 시각화 (0) | 2020.01.18 |