쿠버네티스의 경우 클러스터 안에 다수의 노드, 그리고 그 안에 파드를 비롯한 다양한 워크로드가 많게는 수백 개가 실행되는 형태로 구성되어 있습니다.
단일 노드의 경우 리눅스 명령어를 이용하여 하드웨어의 상황을 파악하고, 각 프로세스 모니터링을 했다면, 쿠버네티스의 경우 각 노드는 전적으로 컨트롤 플레인에 의해 관리되므로 우리는 모니터링에 대해 다른 접근 방법을 가져야 합니다
클러스터 환경에서의 문제 해결의 어려움
단일 노드와 비슷하게, 클러스터 모니터링에서도 노드가 사용하는 리소스를 확인할 수 있습니다.
대표적으로 kubectl top 명령어가 있습니다.
이 명령어는 노드와 파드가 각각 얼마만큼의 CPU/메모리 리소스를 사용하고 있는지 확인할 수 있습니다.
한편 쿠버네티스 환경에서는, 여러 개의 마이크로서비스가 워크로드로서 실행되고, 또한 클러스터 안에서 서로 연결되어 있는 경우가 대부분일 것입니다. 이 경우 문제의 원인을 찾아내는 것이 조금 더 복잡합니다.
예를 들어 백엔드 영역의 파드 하나에서 문제가 발생한 경우, 파드를 연결한 서비스 역시 제대로 작동하지 않을 것입니다. 사용자는 UI에서 그저 뭔가 문제가 있다는 정도만 확인할 뿐, 실제로 어떤 곳에서 무슨 원인에 의해 발생한 지는 알기 어렵습니다.
-> 이 경우에 각 파드에서 사용하는 리소스에 문제가 발생할 경우 미리 경고를 준다거나, Liveness Probe를 통해 애플리케이션에서 발생하는 응답이 오류로 전달되는 경우 이를 즉시 모니터링할 수 있다면 좋을 것입니다.
추가적으로 노드가 물리적으로 멀리 떨어진 상황일 경우 네트워크에 대한 문제가 발생할 수 있습니다.
따라서 응답 대기 시간(Response Latency)에 대한 점검도 중요합니다.
다음은 클러스터 환경에서의 주요 이슈를 설명합니다.
- 쿠버네티스 환경 그 자체
- 제어판(컨트롤 플레인)의 주요 컴포넌트 상태가 비정상적인 경우
- 노드의 리소스 가용량 (CPU, 메모리 요청에 대한 비율)
- 노드의 가용한 리소스보다, 리소스 요청량이 커서 파드가 배포되지 않은 경우
- 노드의 리소스 사용량
- 노드 리소스가 부족하여 컨테이너에 크래시가 발생한 경우
- 워크로드 이슈
- 마운트한 파일 시스템의 용량이 부족한 경우
- 특정 컨테이너가 반복적으로 재시작하는 경우
'DevOps BootCamp > 모니터링' 카테고리의 다른 글
모니터링 시스템의 메트릭 수집 방식 (0) | 2023.06.05 |
---|---|
Prometheus + Grafana (0) | 2023.06.02 |
Auto Scaling + CloudWatch를 이용한 알림 with terraform (0) | 2023.06.01 |
모니터링의 목표와 측정 항목 (0) | 2023.05.31 |
쿠버네티스 모니터링 (0) | 2023.05.31 |