카테고리 없음

14. kubernetes모니터링방법

잘나가는전산쟁이 2026. 8. 5. 02:28
728x90
반응형

Kubernetes 모니터링

  • 본 문서는 Zabbix에서 Kubernetes 클러스터를 모니터링하는 절차를 설명한다.
  • Zabbix 공식 방식은 Kubernetes용 Helm Chart를 배포하고, Web UI에서 공식 HTTP 템플릿을 연결해 클러스터 구성 요소를 모니터링하는 구조이다.
  • 일반적으로 Kubernetes nodes by HTTP와 Kubernetes cluster state by HTTP 두 개의 핵심 템플릿부터 시작한다.

구성 개요

  • Zabbix Server: 템플릿, 이벤트, 알림, 시각화를 담당한다.
  • Zabbix Proxy: Kubernetes 클러스터 내부 또는 인접 위치에서 API 수집을 담당할 수 있다.
  • Kubernetes API server: 클러스터 메타데이터와 상태 조회 대상.
  • kube-state-metrics: 워크로드 상태 메트릭 제공.
  • kubelet: 노드별 런타임 및 리소스 상태 수집 대상.
  • controller-manager / scheduler: 컨트롤 플레인 상태 수집 대상.
  • 주요 포트 예시는 다음과 같다.
    • Zabbix Proxy -> Zabbix Server: 10051/tcp.
    • Zabbix components -> Kubernetes API: 443/tcp 또는 6443/tcp.
    • Zabbix components -> kubelet: 10250/tcp.
  • 실제 포트는 클러스터 구성과 인증 정책에 따라 다를 수 있다.

권장 방식

  • 공식 문서는 Kubernetes용 Helm Chart 설치 후, Zabbix Web UI에서 템플릿을 연결하는 흐름을 안내한다.
  • 대규모 환경에서는 Zabbix Proxy를 클러스터 내부에 두고 외부 Zabbix Server와 연동하는 구성이 일반적이다.
  • Zabbix는 Kubernetes를 Agent 설치 중심이 아니라, API/HTTP 기반 수집으로 모니터링하는 접근을 사용한다.

사전 준비

  • Kubernetes 클러스터가 정상 동작 중이어야 한다.
  • Zabbix Server가 준비되어 있어야 한다.
  • Helm과 kubectl 사용이 가능해야 한다.
  • Zabbix Kubernetes용 Helm Chart를 배포할 namespace를 준비한다. 일반적으로 monitoring을 사용한다.

Helm Chart 배포

  • 공식 문서는 Kubernetes용 Helm Chart 설치를 선행 단계로 안내한다.
  • 배포 예시는 환경에 따라 조금씩 다르지만, 기본 흐름은 repo 추가, values 확인, namespace 생성, chart 설치 순서이다. 
helm repo add zabbix-chart-6.4 https://cdn.zabbix.com/zabbix/integrations/kubernetes-helm/6.4
helm repo update
kubectl create namespace monitoring
helm show values zabbix-chart-6.4/zabbix-helm-chart > $HOME/zabbix_values.yaml
  • values 파일을 환경에 맞게 수정한 뒤 Helm Chart를 배포한다. 
helm install zabbix zabbix-chart-6.4/zabbix-helm-chart -n monitoring -f $HOME/zabbix_values.yaml

Token 확인

  • 공식 문서는 Helm Chart 설치 후 생성된 ServiceAccount token을 사용해 Kubernetes API 접근에 활용한다.
  • 예시는 다음과 같다. 
kubectl get secret zabbix-zabbix-helm-chart -n monitoring -o jsonpath={.data.token} | base64 -d
  • 일부 배포 예시에서는 Secret 이름이 환경에 따라 다를 수 있으므로 실제 생성된 Secret 이름을 확인해야 한다.

Web UI 사전 설정

  • Zabbix Frontend에서 Kubernetes 관련 Host group을 먼저 만든다.
  • Proxy를 사용하는 경우 Administration -> Proxies에서 active proxy를 생성하고, Helm values에 지정한 이름과 일치해야 한다.
  • 템플릿이 기본 설치에 없으면 공식 통합 페이지에서 가져와 import 해야 한다.

주요 템플릿

  • 공식 통합 문서에는 다음 템플릿이 포함되어 있다.

    • Kubernetes nodes by HTTP
    • Kubernetes cluster state by HTTP
    • Kubernetes API server by HTTP
    • Kubernetes Controller manager by HTTP
    • Kubernetes Scheduler by HTTP
    • Kubernetes kubelet by HTTP

  • 일반적으로는 먼저 Kubernetes nodes by HTTP와 Kubernetes cluster state by HTTP를 연결한 뒤, 필요 시 control plane 템플릿을 추가한다.

Nodes Host 등록

  • 첫 번째 Host는 노드 모니터링용 Host로 생성한다.
  • 예시 Host name은 Kubernetes Nodes로 설정할 수 있다.
  • Host group을 Kubernetes 전용 그룹으로 지정하고, Kubernetes nodes by HTTP 템플릿을 연결한다.
  • HTTP item 템플릿 특성상 dummy interface가 필요할 수 있으므로 Host interface를 하나 등록한다.

주요 매크로 예시

Cluster State Host 등록

  • 두 번째 Host는 클러스터 상태 모니터링용으로 생성한다.
  • 예시 Host name은 Kubernetes Cluster State로 설정할 수 있다.
  • Kubernetes cluster state by HTTP 템플릿을 연결한다.
  • 이 템플릿은 Kubernetes API를 이용해 클러스터 구성 요소와 control plane 노드를 발견하고, 필요한 Host와 Template을 자동 생성하는 역할을 한다.

추가 템플릿 적용

  • 필요 시 아래 템플릿을 추가로 연결한다.

    • Kubernetes API server by HTTP
    • Kubernetes Controller manager by HTTP
    • Kubernetes Scheduler by HTTP
    • Kubernetes kubelet by HTTP

  • kubelet 모니터링 시 매크로 예시는 다음과 같다.

    • {$KUBE.KUBELET.URL} = https://:10250

수집 항목 예시

  • Node 상태, CPU, Memory, Pod 수
  • Deployment, DaemonSet, ReplicaSet, Pod, Service, Endpoint 상태
  • kubelet runtime operation, running pod 수
  • scheduler 요청/지연 통계
  • API server 상태
  • cluster object discovery 및 상태 변화

방화벽 및 접근 제어

  • Zabbix Proxy 또는 Server는 Kubernetes API endpoint에 접근할 수 있어야 한다.
  • kubelet 모니터링 시 10250/tcp 접근이 필요할 수 있다.
  • Token 기반 인증 정보를 사용하므로 Secret 관리와 RBAC 범위를 최소화하는 것이 중요하다.
  • 가능하면 Zabbix Proxy를 클러스터 내부에 두고 외부 Zabbix Server에는 10051/tcp만 열어 두는 방식이 운영상 유리하다.

대용량 운영 추천값

  • 대규모 클러스터에서는 Zabbix Proxy를 클러스터 내부에 두는 방식을 우선 검토한다.
  • 모든 템플릿을 처음부터 다 붙이기보다, nodes/cluster state부터 시작해 필요한 control plane 템플릿을 추가하는 것이 좋다.
  • 추천 시작 기준은 아래와 같다.
항목 추천값
배포 방식 공식 Helm Chart
수집 위치 클러스터 내부 Proxy 우선
핵심 템플릿 Kubernetes nodes by HTTP, Kubernetes cluster state by HTTP
API endpoint 내부 DNS 또는 API VIP
인증 Helm Chart 생성 token 기반
Host 구성 Nodes / Cluster State 분리
확장 방식 kubelet, scheduler, controller-manager 순차 적용

점검 항목

  • Helm Chart가 정상 배포되었는지 확인한다.
  • Token을 정상 조회할 수 있는지 확인한다.
  • Proxy 이름이 Frontend 설정과 values 파일에서 일치하는지 확인한다.
  • {$KUBE.API.ENDPOINT.URL}와 token 매크로 값이 정확한지 확인한다.
  • 템플릿 import 여부, Host interface 등록, API 접근 차단은 가장 흔한 원인이므로 우선 점검한다.

운영 팁

  • 처음에는 Nodes와 Cluster State 템플릿만으로 시작하고, 이후 kubelet과 control plane 템플릿을 확장하는 것이 안정적이다.
  • RBAC 권한은 최소 범위로 시작하고, 필요한 메트릭이 부족할 때만 단계적으로 확장하는 것이 좋다.
  • Host group, template 연결 기준, macro 이름 규칙을 표준화하면 대규모 클러스터 운영이 쉬워진다.
  • kube-state-metrics와 API 기반 수집은 강력하지만, 너무 많은 항목을 한 번에 활성화하면 수집량이 급증할 수 있으므로 점진적으로 적용하는 것이 좋다.
728x90
반응형
저작자표시 (새창열림)