안녕하세요, 디무브 입니다.
최근 많은 기업들이 서비스 구성 및 관리를 위해 사용하는 쿠버네티스(Kubernetes)는 컨테이너화된 가상화 리소스들을 손쉽게 배포하고 관리할 수 있는 오픈소스 컨테이너 오케스트레이션 플랫폼입니다.
쿠버네티스에서 일어날 수 있는 다양한 이슈들을 미리 방지하는 것은 중요하지만 모니터링하는 것은 쉽지 않은데요. Zabbix에서 제공하는 템플릿을 활용하여 손쉽게 쿠버네티스를 모니터링할 수 있습니다. 오늘 포스트에서는 Zabbix를 통해 쿠버네티스의 모니터링 메트릭을 수집 및 활용하는 방법을 설명드리겠습니다.
🔎 Zabbix에서 쿠버네티스를 모니터링 하는 방법
- Zabbix는 쿠버네티스 모니터링을 쉽게 구성할 수 있도록 두 가지 템플릿을 제공하고 있습니다.
| 1. 클러스터 노드 모니터링 |
| ‘Kubernetes nodes by HTTP’ 템플릿은 클러스터를 구성하는 노드(Node)를 자동으로 찾는 호스트 프로토타입 기능을 통해 호스트를 만들며 기본적으로 ‘Linux by Zabbix agent’ 템플릿과 연결됩니다. 이 템플릿은 기본적인 쿠버네티스 메트릭들을 Kubernetes API를 통해 수집합니다. |
| 2. 메인 클러스터 컴포넌트 모니터링 |
| ‘Kubernetes cluster state by HTTP’ 모니터링 템플릿을 기반으로 Kubernetes API를 통해 클러스터 구성요소와 컨트롤 플레인 정보들을 모니터링 할 수 있습니다. |
위 두 가지 템플릿을 사용하기 위해 Zabbix에서는 공식적으로 zabbix 헬름 차트를 배포하여 API 서버 혹은 각종 서비스에 데이터를 요청하여 받는 방식으로 모니터링하는 것을 권고하고 있습니다.
만약 헬름 차트를 활용하지 않을 경우 쿠버네티스 API 서버에 데이터를 요청하기 위한 구성을 수동으로 진행해야 하며 이 경우에는 템플릿에서 제공하는 일부 기능이 정상 동작하지 않을 수 있습니다.
템플릿 사용 전 헬름 차트 배포 구성
헬름 차트는 Zabbix의 쿠버네티스 클러스터 모니터링을 위한 구성 요소를 설치합니다.
쿠버네티스 각각의 Node에 Agent 서비스를 배포하고 Kubernetes API를 통해 정보를 받아와 각종 지표를 만듭니다. 아래는 Zabbix 헬름 차트 배포 후 Zabbix 서버에서 쿠버네티스를 모니터링하는 구성도입니다.
헬름 차트를 통해 Zabbix를 배포하면 아래와 같은 구성 요소들이 설치됩니다.
- kube-state-metric
Kubernetes API를 통해 클러스터 내의 오브젝트들의 메트릭을 수집하는 역할 - Zabbix Agent
DeamonSet 형태로 각 Node마다 배포되는 Passive mode 에이전트로 개별 Node들의 메트릭을 수집하는 역할 - Zabbix Proxy
Active 모드로 설치되며, Single replica의 Deployment로 배포됩니다. Zabbix proxy는 Zabbix server와 같이 kube-state-metric, Kubernetes API, Zabbix Agent를 통해 모니터링 메트릭을 수집하며 Zabbix Server가 통신이 불가능한 네트워크 상의 모니터링 메트릭 수집을 위해 사용합니다.
그럼 실제로 헬름 차트 배포 후 Zabbix에서 어떤 쿠버네티스 정보를 모니터링할 수 있는지 살펴보겠습니다. (✔ 참고 : Zabbix 6.4버전 기준)
🔴 MasterNode
Step 1 마스터 Node에서 헬름 차트 서비스를 설치한 다음 Zabbix 헬름 차트를 추가합니다.
helm repo add zabbix-chart-6.4 https://cdn.zabbix.com/zabbix/integrations/kubernetes-helm/6.4
Step 2 헬름 차트를 배포할 설정 파일을 가져온 후 값을 환경에 맞춰 설정합니다.
helm show values zabbix-chart-6.4/zabbix-helm-chrt > $HOME/zabbix_values.yaml- Zabbix_values.yaml에서 설정할 수 있는 요소는 다음과 같습니다.
1. rbac 설정
2. 서비스 어카운트 : Default → Zabbix-service-account
3. Zabbix proxy :기본적으로 alpine-6.4.6 OS의 sqlite3 DB의 이미지로 배포되며 active 모드로 데이터를 수집합니다. 자세한 설정의 경우 zabbix docker 자료를 참고해 주시기 바랍니다.
4. Zabbix agent : 기본적으로 alpine-6.4.6 OS의 agent2 이미지로 배포되며 passive 모드로 데이터를 수집합니다.
Step 3 ‘monitoring’ 네임스페이스를 생성합니다.
kubectl create namespace monitoring
Step 4 설정한 zabbix_value.yaml 파일을 기반으로 헬름 차트를 배포합니다.
[root@Jackson-Kubernetes-Master zabbix-helm]# helm install zabbix zabbix-chart-6.4/zabbix-helm-chrt --dependency-update -f zabbix_values.yaml -n monitoring
NAME: zabbix
LAST DEPLOYED: Fri Dec 1 00:26:37 2023
NAMESPACE: monitoring
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Thank you for installing zabbix-helm-chrt.
Your release is named zabbix.
Zabbix agent installed: "zabbix/zabbix-agent2:alpine-6.4.6"
Zabbix proxy installed: "zabbix/zabbix-proxy-sqlite3:alpine-6.4.6"
Annotations:
app.kubernetes.io/name: zabbix-zabbix-helm-chrt
helm.sh/chart: zabbix-helm-chrt-1.3.4
app.kubernetes.io/version: "6.4.6"
app.kubernetes.io/managed-by: Helm
Service account created:
zabbix-service-account
To learn more about the release, try:
$ helm status zabbix -n monitoring
$ helm get all zabbix -n monitoring
⭕ 헬름 차트를 무사히 배포했다면 헬름 차트를 통해 에이전트, 프록시, 서비스, 데몬 셋 등이 생성된 것을 확인할 수 있습니다.
root@Jackson-Kubernetes-Master ~]# kubectl get all -n monitoring -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod/zabbix-agent-l8l5t 1/1 Running 0 38h 10.220.0.102 jackson-kubernetes-master <none> <none>
pod/zabbix-agent-rcztb 1/1 Running 0 38h 10.220.0.120 worker-node1 <none> <none>
pod/zabbix-kube-state-metrics-64ddc65c45-k97hw 1/1 Running 0 38h 192.168.180.206 worker-node1 <none> <none>
pod/zabbix-proxy-8759df8f5-9nfk6 0/1 CrashLoopBackOff 643 (3m12s ago) 38h 192.168.180.207 worker-node1 <none> <none>
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
service/zabbix-kube-state-metrics ClusterIP 10.105.44.144 <none> 8080/TCP 38h app.kubernetes.io/instance=zabbix,app.kubernetes.io/name=kube-state-metrics
service/zabbix-zabbix-helm-chrt-agent ClusterIP 10.96.229.93 <none> 10050/TCP 38h name=zabbix-agent
service/zabbix-zabbix-helm-chrt-proxy ClusterIP 10.111.250.102 <none> 10051/TCP 38h name=zabbix-proxy
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE CONTAINERS IMAGES SELECTOR
daemonset.apps/zabbix-agent 2 2 2 2 2 kubernetes.io/os=linux 38h zabbix-agent zabbix/zabbix-agent2:alpine-6.4.6 name=zabbix-agent
NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR
deployment.apps/zabbix-kube-state-metrics 1/1 1 1 38h kube-state-metrics registry.k8s.io/kube-state-metrics/kube-state-metrics:v2.9.2 app.kubernetes.io/instance=zabbix,app.kubernetes.io/name=kube-state-metrics
deployment.apps/zabbix-proxy 0/1 1 0 38h zabbix-proxy zabbix/zabbix-proxy-sqlite3:alpine-6.4.6 name=zabbix-proxy
NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR
replicaset.apps/zabbix-kube-state-metrics-64ddc65c45 1 1 1 38h kube-state-metrics registry.k8s.io/kube-state-metrics/kube-state-metrics:v2.9.2 app.kubernetes.io/instance=zabbix,app.kubernetes.io/name=kube-state-metrics,pod-template-hash=64ddc65c45
replicaset.apps/zabbix-proxy-8759df8f5 1 1 0 38h zabbix-proxy zabbix/zabbix-proxy-sqlite3:alpine-6.4.6 name=zabbix-proxy,pod-template-hash=8759df8f5
배포된 Zabbix 헬름 차트를 분석해 보면 아래와 같이 해석할 수 있습니다.
- 각 Node 별 Zabbix Agent2 배포
- 에이전트의 경우 쉽게 변경되면 안 되기 때문에 데몬 셋 형태로 배포
- 워커 Node에 Zabbix Proxy, Zabbix-kube-state-mertircs Pod 배포
- Zabbix Proxy와 Zabbix-Kube-State-Metrics의 경우 1개의 ReplicaSet 형태로 Deployment 배포
여기까지 Zabbix 헬름 차트 구성 방법에 대해 알아보았습니다.
이제 Zabbix에서 템플릿을 활용하여 쿠버네티스의 메트릭을 수집하는 방법에 대하여 구체적으로 알아보겠습니다. 앞서 쿠버네티스를 모니터링할 때에는 ‘Kubernetes nodes by HTTP’와 ‘Kubernetes cluster state by HTTP’ 템플릿으로 구분하여 모니터링할 수 있다고 설명드렸는데요. 각 템플릿을 연결한 뒤 각각 어떤 메트릭을 수집하는지 설명드리겠습니다.
Kubernetes nodes by HTTP 템플릿을 활용한 모니터링
‘Kubernetes nodes by HTTP’ 템플릿을 연결한 뒤 구조를 살펴보고 어떤 사항을 모니터링하는지 알아보겠습니다.
✔ 템플릿 연결하기
호스트를 만든 뒤 ‘Kubernetes nodes by HTTP’ 템플릿을 연결합니다.
✔ 템플릿 구조 알아보기
템플릿에 매핑되어 있는 아이템과 디스커버리 정보들을 확인해 보면 ‘Get Nodes’라는 스크립트를 통해 데이터를 가져오는 아이템 값과 ‘Dependent Item’ 형태로 된 아이템 그리고 디스커버리로 구성되어 있는 것을 알 수 있습니다.
🔎 해당 디스커버리를 자세히 확인해 볼까요?
- Master 아이템인 ‘Get Nodes’로부터 데이터를 가져오면 ‘Dependent Item’인 Pod 디스커버리와 Node 디스커버리가 생성됩니다.
- 이때에 Pod와 Node 정보는 JSON 형태로 불러옵니다.
템플릿의 구조는 아래와 같이 정리할 수 있습니다.
- Master 아이템인 ‘Get Node’ 아이템을 통해 JSON 형태로 전달되는 Node와 Pod 정보를 수집합니다.
- ‘Dependent Item’인 Pod 디스커버리와 Node 디스커버리는 Master 아이템 데이터를 기반으로 구성됩니다.
- Discovery Rule을 통해 자동으로 호스트 구성과 아이템 구성이 진행됩니다.
✔ 모니터링 항목
디스커버리를 통해 수집할 수 있는 아이템 리스트는 아래와 같습니다.
Node 디스커버리
⊙ Node의 CPU, Memory, Network와 같은 하드웨어 정보
⊙ 각 지표들에 대한 사용량
Pod 디스커버리
⊙ Pod들의 스텝별 상태
최종적으로 ‘Get nodes’ 아이템을 통해 성공적으로 데이터를 가져오게 되면 하위 의존성 디스커버리를 통해 Node와 Pod 정보 등에 대한 아이템을 생성합니다.
Node의 정보를 가져올 때, Node 이름을 기반으로 한 호스트 프로토 타입을 통해 각 Node에 에이전트에 대한 호스트를 자동으로 생성하고 'Linux by Zabbix Agent' 템플릿과 연결하여 각 Node 별 모니터링을 자동화할 수 있습니다.
호스트 디스커버리를 통해 배포되는 메트릭을 별도로 수집해야 한다면, ‘Kubernetes nodes by HTTP’ 템플릿의 호스트 프로토타입 설정에서 연결된 템플릿을 수정하여 배포할 수 있습니다.
Kubernetes cluster state by HTTP 템플릿을 활용한 모니터링
‘Kubernetes cluster state by HTTP’ 템플릿은 클러스터 상태에 대한 Health Check나 컨트롤러 상태, API 정보 등을 모니터링할 수 있습니다.
✔ 템플릿 구조 알아보기
해당 템플릿 역시 API, Kubelet, cluster-state 서비스에 HTTP 요청을 보내 호출을 받고, 디스커버리를 통해 아이템을 배포하는 구조로 이루어져 있습니다.
HTTP 요청을 통해 정상적으로 데이터를 가져오게 되면 호스트 디스커버리를 통해 API Server와 Controller manager, Kubelet 모니터링을 위한 호스트가 자동으로 생성됩니다.
✔ 모니터링 항목
각 서비스 별 수집하는 지표는 대략적으로 아래와 같습니다.
- API Server
- API Server Request
- 인증 정보 및 인증 요청 정보
- Kubelet
- 컨테이너 상태
- Pod 상태 및 메트릭
- REST 혹은 HTTP 리퀘스트 요청 및 Status 상태
- Cluster Manager
- Rest Request 정보
- Controller Manager 상태
- WorkQueue 정보
지금 까지 Zabbix를 이용하여 쿠버네티스를 모니터링하는 방법과 항목들에 대해 자세히 살펴보았습니다.
오늘 설명 드린 내용을 요약하면 Zabbix에서는 템플릿을 활용하여 쿠버네티스의 Node와 Pod 정보의 상태와 리퀘스트 요청 그리고 요청에 따른 상태 값 등을 모니터링 할 수 있다는 것을 알 수 있습니다.
Zabbix를 통해 쿠버네티스를 모니터링하여 안전한 서비스 환경을 구축할 수 있는 방법에 대하여 더 궁금하신 점이 있으시다면 자빅스 공식 파트너 디무브를 찾아주세요 😉
'자빅스 > Case Study' 카테고리의 다른 글
| Case Study- Zabbix를 통한 TCP/UDP 포트 상태 확인 (0) | 2024.02.28 |
|---|---|
| Case Study- Zabbix와 Atlassian Statuspage를 활용한 웹 서버 상태 모니터링 (0) | 2024.01.09 |
| Case Study- Zabbix에서 수집한 데이터를 Grafana를 통해 시각적으로 구성하기 (1) | 2023.10.26 |
| Case Study- Zabbix에서 수집한 데이터를 커스텀 대시보드로 만드는 법 (0) | 2023.09.25 |
| Case Study- Harp사 Zabbix 구축 사례 (0) | 2023.07.19 |
