쿠버네티스를 처음 접했을 때의 난관은 Pod가 무엇인가를 이해하는 것이었습니다. Docker Container에 대한 기본 이해를 전제로, Pod는 컨테이너인가? 동일 유형 컨테이너의 집합 개념인가?에 대한 혼란이 시작되었습니다.
쿠버네티스는 컨테이너 그룹을 오케스트레이션을 수행하는 도구라는 점은 의외로 쉽게 이해됩니다. 대규모 컨테이너 그룹의 역할을 분할하고 이를 조화롭게 관리하기 위한 도구의 필요성은 쉽게 납득이 되기 때문이죠.
쿠버네티스 내부의 복잡한 구조는 차치하고 아주 단순화해서 생각해 보면 물리적인 부분과 논리적인 부분으로 나누어 볼 수 있을 듯합니다. 물리적으로는 Node와 Container로 구분해 보려 합니다. 가상화 레벨의 자원을 물리의 범주에 포함시키는 것이 무리가 있을 수 있겠습니다만, 쿠버네티스에서는 이 둘을 물리적 범주에 포함시키는 것이 조금 더 개념을 빠르게 이해하는 데 도움이 될 듯싶습니다.
Node는 단위 서버(박스)로, Container는 Node의 공유 자원을 활용하는 Node 상에 탑재된 가상의 패키징 단위를 의미합니다. VM은 OS 레이어까지 가상화하는 반면에 Container는 Host OS의 자원 중 필요한 부분을 공유해 사용하고, 개별 Container가 필요로 하는 부분만 별도로 패키징 하는 점이 다른 부분입니다. 어찌 되었든 Node, Container로 구분되는 개념만 이해하고 넘어갑니다.
그리고 나면 논리적 개념인 Pod가 등장합니다. Pod의 정의는 다음과 같습니다.
Pod는 애플리케이션 컨테이너(또는, 몇몇의 경우, 다중 컨테이너), 저장소 리소스, 특정 네트워크 IP 그리고, 컨테이너가 동작하기 위해 만들어진 옵션들을 캡슐화한다. Pod는 배포의 단위를 말한다. 아마 단일 컨테이너로 구성되어 있거나, 강하게 결합되어 리소스를 공유하는 소수의 컨테이너로 구성되어 있는 쿠버네티스에서의 애플리케이션 단일 인스턴스를 의미함.
출처: https://kubernetes.io/ko/docs/concepts/workloads/pods/
여기서 중요한 것은 Pod와 Container의 관계입니다. Pod:Container = 1:N의 관계를 가집니다. 동일한 역할을 수행하는 단위로의 컨테이너 집합이 곧 Pod이기 때문입니다. 그리고 나면 ReplicaSet이 등장합니다. 동일한 역할을 수행하는 단위로의 Pod라면, 이를 다시 다중화하기 위한 개념이 필요하기 때문이죠.
여기까지가 개념에 해당하는 부분입니다.
글로만 봐서는 잘 이해가 되지 않기도 합니다. 개념을 잘 정리해 놓은 블로그의 이미지들을 활용하면 한 발 더 쉽게 다가설 수 있습니다만, 엔지니어 입장에서는 말보다 테스트가 더 빠른 이해를 도울 수 있을 듯싶습니다. 그리고 이를 잘 시각화해서 보여줄 수 있는 시스템이 있다면 더할 나위 없겠죠. 쿠버네티스에 대한 학습과 이를 보조하는 모니터링이란 관점에서 와탭의 쿠버네티스 모니터링을 소개해 볼까 합니다.
GKE(Google Kubernetes Engine)에 간단한 애플리케이션을 탑재하여 3개 노드로 환경을 구성해 보았더니 디폴트로 50개 이상의 컨테이너가 구성되더군요.
우선 컨테이너 수 먼저 보겠습니다. 아래 이미지에서 외곽의 사각 박스가 Node를 나타냅니다. 박스의 우상단에는 각 Node에 배치된 Container의 개수를 표현합니다.
Node 단위로 얼마나 많은 컨테이너가 배치되어 있는지를 가능할 수 있겠죠?
2단 분류를 Pod로 선택하면 각 Node에 배치된 Container를 Replicaset 단위로 인접 배치하여 표현합니다.
이 단계에서 각 Node에 어떤 유형의 Container가 배치되어 있는지에 대한 파악이 용이해집니다. kubectl을 통해서 테이블 형태로 보는 것도 가능하겠습니다만, 대규모 Container를 집합 모니터링할 때 커맨드 콘솔로 보기가 쉽지도 않을뿐더러 직관적이지 않은 부분을 고려하면 많이 편해지지 않을까 싶기도 합니다.
와탭 모니터링에 익숙한 사용자라면, 서버 모니터링에서 활용하시던 방식과 동일한 인터페이스로 각 Node 및 Container의 자원 모니터링이 가능합니다.
와탭의 애플리케이션 모니터링 기능을 통합했습니다. 또 하나 필요한 것이 Service 또는 ReplicaSet 단위의 집합 모니터링이죠. 개별 Pod 단위로 보거나, ReplicaSet 단위로 볼 수 있도록 그룹 기능을 통해 지원하게 되었습니다.
그리고 나니 필요한 것이 구성 관리 데이터입니다. 쿠버네티스가 제공하는 기본 셋으로 인해 YAML 또는 JSON 형식으로 정의 또는 추출되는 정보를 일일이 읽고 파악하는 것이 여간 복잡한 것이 아닙니다. 이미 시장에는 이들은 토폴로지 형태로 시각화하여 보여주거나, 구성 관리 데이터를 관리하고 쿠버네티스 환경에 적용할 수 있도록 지원하는 솔루션들이 이미 출현하여 시장을 구축해 나아가고 있습니다.
와탭은 이들 정보를 쿠버네티스 요소(?)별로 정보를 추출하여 확인하실 수 있는 기능을 제공합니다.
저는 이 정보 역시 테이블 형태로 보는 것이 조금 불편하더라고요. 그래서 이렇게 준비해 보았습니다.
Deployment, DaemonSet, ReplicaSet, Pod, Node, Service, Ingress 가 어떤 관계로 연관되어 있는지를 다이어그램으로 제공합니다. 그리고 Persistent Volume은 별도로...
어떠세요? 이 정도면 쿠버네티스 실습 환경 구축해서 테스트하면서 모니터링하기에 좋지 않을까요? 본 글을 통해서 와탭 쿠버네티스 모니터링에 관심이 생겼다면, 와탭이 활용하는 채널에 관심을 가져봐 주시면 감사하겠습니다.
컨테이너 모니터링은 YAML 파일로 쿠버네티스가 사용자가 아주 쉽게 대응할 수 있는 방법으로 안내하고 있습니다.
쿠버네티스 환경의 JAVA 애플리케이션 모니터링의 적용 절차는 와탭의 애플리케이션 모니터링의 기존 설치 절차와 동일합니다. Docker Image에 패키징 하는 절차만 빼고요.