쿠버네티스 환경이 복잡해지고 관리해야 할 클러스터가 늘어나면서, 안정적이고 예측 가능한 모니터링 시스템 구축은 모든 데브옵스 팀의 핵심 과제가 되었습니다.

이런 상황에서 그라파나 랩스(Grafana Labs)가 최근 공개한 쿠버네티스 모니터링 헬름 차트(Helm Chart) 버전 4는 단순한 업데이트를 넘어, 대규모 환경에서 사용자들이 겪어온 고질적인 문제들을 해결하는 데 초점을 맞춘 중요한 이정표로 평가받고 있습니다.

6개월의 개발, v4가 등장한 배경

그라파나 랩스는 이번 v4 업데이트가 약 6개월간의 기획과 개발을 거친 결과물이라고 밝혔습니다.

그동안 수많은 사용자들이 클러스터 규모를 확장하면서 누적된 설정의 복잡성과 예측 불가능성 때문에 어려움을 겪어왔습니다.

v3는 기능적으로는 강력했지만, 설정 구조의 한계로 인해 여러 클러스터를 관리하거나 GitOps 워크플로우를 적용할 때 예상치 못한 문제를 일으키곤 했습니다.

이번 업데이트의 핵심 목표는 명확합니다.

바로 차트를 더 예측 가능하고, 더 유연하며, 훨씬 쉽게 유지보수할 수 있도록 만드는 것입니다.

이는 단일 클러스터를 관리하는 팀부터 수백 개의 클러스터를 운영하는 대규모 조직까지 모두에게 실질적인 가치를 제공하기 위한 변화입니다.

‘리스트’에서 ‘맵’으로, GitOps 안정성을 잡다

v4에서 가장 주목할 만한 구조적 변화는 바로 설정 대상(destinations)을 기존의 ‘리스트(list)’ 형식에서 ‘맵(map)’ 형식으로 전환한 것입니다.

v3에서는 모니터링 데이터를 보낼 대상을 배열, 즉 리스트 형태로 정의했습니다.

이는 공유 설정 파일을 사용해 여러 클러스터를 관리하는 팀에게 큰 골칫거리였습니다.

예를 들어, 특정 대상의 비밀번호만 변경하려면 리스트 내에서의 ‘위치’를 기준으로 오버라이드해야 했습니다.

만약 설정 파일 어딘가에서 대상의 순서가 바뀌면, 변경 사항이 엉뚱한 대상에 적용되는 조용한 장애(silent failure)가 발생할 위험이 있었습니다.

이는 Argo CD나 Flux 같은 GitOps 도구를 사용하는 환경에서 특히 치명적이었습니다.

v4에서는 각 대상을 고유한 이름(key)을 가진 맵으로 정의합니다.

이제 destinations.prometheus.auth.password처럼 대상의 이름으로 직접 속성을 참조할 수 있어 순서가 바뀌어도 설정이 잘못 적용될 염려가 없습니다.

이 변화는 여러 파일에 걸쳐 설정을 병합하는 헬름의 기능을 온전히 활용하게 해, 멀티 클러스터 GitOps 워크플로우의 안정성을 극적으로 향상시킵니다.

더 이상 ‘깜짝 배포’는 없다, 명시적 서비스 관리

v3의 또 다른 문제점은 특정 기능을 활성화하면 관련된 백업 서비스들이 사용자 모르게 자동으로 배포된다는 점이었습니다.

예를 들어, clusterMetrics 기능을 켜면 Node Exporter나 kube-state-metrics 같은 서비스가 별다른 경고 없이 클러스터에 설치되었습니다.

만약 팀이 이미 자체적으로 해당 서비스를 운영하고 있었다면, 중복 배포로 인한 리소스 낭비와 혼란이 발생했습니다.

v4는 telemetryServices라는 새로운 키를 도입하여 이 문제를 해결했습니다.

이제 모든 백업 서비스의 배포는 사용자의 명시적인 선택 사항이 됩니다.

이미 클러스터에 Node Exporter가 실행 중이라면, 차트에게 배포를 건너뛰고 기존 인스턴스를 사용하도록 간단히 지시할 수 있습니다.

그라파나 측의 표현을 빌리자면, 이제 “깜짝 배포는 더 이상 없습니다.”

메모리 누수 해결, Pod 로그 레이블 처리 방식의 혁신

대규모 클러스터에서 로그를 수집하는 Alloy 인스턴스의 메모리 사용량이 급증하는 문제는 일부 사용자들에게 심각한 성능 저하를 유발했습니다.

문제의 원인은 v3의 Pod 로그 레이블 처리 방식에 있었습니다.

v3 차트는 기본적으로 Pod에 있는 모든 레이블과 어노테이션을 로그 레이블로 가져온 뒤, labelsToKeep 리스트를 사용해 필요한 것만 남기고 나머지를 버리는 방식을 사용했습니다.

이 과정에서 Alloy는 잠재적으로 수백 개에 달하는 불필요한 레이블을 처리하기 위해 막대한 메모리를 할당했다가 버려야 했습니다.

v4는 이 비효율적인 구조를 완전히 개선했습니다.

labelsToKeep을 제거하고, 기본적으로는 아무 레이블도 가져오지 않는 ‘옵트인(opt-in)’ 방식으로 변경했습니다.

이제 사용자는 필요한 레이블만 명시적으로 선언하면 되며, 이는 단 한 줄의 설정 변경으로 가능합니다.

이 변화는 Alloy의 메모리 사용량을 눈에 띄게 줄여 모니터링 인프라의 안정성을 높이는 직접적인 효과를 가져옵니다.

kube-prometheus-stack과 차별점은?

쿠버네티스 모니터링 분야에서 그라파나 헬름 차트의 대표적인 대안은 kube-prometheus-stack입니다.

kube-prometheus-stack은 프로메테우스, 그라파나, Alertmanager 등을 하나의 패키지로 묶어 제공하며, 특히 프로메테우스 오퍼레이터(Prometheus Operator)의 CRD(Custom Resource Definitions)를 활용해 선언적으로 메트릭 수집을 관리하는 데 강점이 있습니다.

주로 자체 호스팅(self-hosted) 옵저버빌리티 스택을 구축하려는 팀에게 적합합니다.

반면 그라파나의 헬름 차트는 Grafana Cloud나 관리형 그라파나 스택으로 원격 측정 데이터를 보내는 팀을 주요 대상으로 합니다.

또한 프로파일링 데이터나 OpenCost를 통한 비용 메트릭 수집 같은 기능을 기본적으로 지원한다는 차별점이 있습니다.

따라서 어떤 차트를 선택할지는 팀의 기술 스택, 운영 모델(자체 호스팅 vs 클라우드), 그리고 필요한 모니터링 데이터의 종류에 따라 달라질 것입니다.

이번 v4 업데이트는 그라파나 헬름 차트가 대규모, 다중 클러스터 환경의 복잡성을 해결하기 위해 얼마나 진지하게 고민했는지를 보여줍니다.

불안정했던 패턴들을 제거하고 사용자에게 명시적인 제어권을 부여함으로써, 쿠버네티스 모니터링의 유지보수성과 신뢰성을 한 단계 끌어올렸습니다.

그라파나 랩스는 v3에서 v4로의 마이그레이션을 돕는 변환 도구도 함께 제공하고 있으니, 기존 사용자들은 이를 활용해 안정적인 모니터링 환경을 구축해 보시길 바랍니다.

자주 묻는 질문 (FAQ)

Q: 기존 그라파나 헬름 차트 v3 사용자는 어떻게 v4로 마이그레이션해야 하나요?

A: 그라파나 랩스에서 공식 마이그레이션 도구를 제공합니다.

이 도구에 기존 v3의 values.yaml 파일을 입력하면, v4와 호환되는 새로운 설정 파일을 자동으로 생성해 줍니다.

리스트를 맵으로 변환하는 등의 구조적 변경 사항을 대부분 처리해 주므로 마이그레이션 부담을 크게 줄일 수 있습니다.

Q: 그라파나 헬름 차트 v4 업데이트의 가장 큰 장점은 무엇인가요?

A: 가장 큰 장점은 GitOps 워크플로우의 안정성과 예측 가능성이 크게 향상되었다는 점입니다.

설정 대상을 리스트에서 맵으로 변경하여 설정 순서에 의존하지 않게 되었고, 백업 서비스 배포를 명시적으로 제어할 수 있게 되어 예기치 않은 리소스 생성을 방지합니다.

Q: ‘kube-prometheus-stack’ 대신 그라파나 헬름 차트를 사용해야 하는 경우는 언제인가요?

A: 모니터링 데이터를 Grafana Cloud나 다른 관리형 그라파나 서비스로 전송하는 경우에 가장 적합합니다.

또한, 프로파일링 데이터나 비용 메트릭(OpenCost) 수집 기능이 기본적으로 필요하다면 그라파나 헬름 차트가 더 편리한 선택이 될 수 있습니다.

Q: 이번 업데이트로 Alloy의 메모리 사용량이 얼마나 줄어드나요?

A: 정확한 감소량은 클러스터의 Pod 레이블 및 어노테이션 수에 따라 다릅니다.

하지만 모든 레이블을 일단 메모리에 올렸다가 필터링하던 기존 방식에서 필요한 레이블만 명시적으로 추가하는 방식으로 바뀌었기 때문에, 레이블이 많은 환경일수록 메모리 사용량 감소 효과가 매우 클 것으로 예상됩니다.

출처: https://www.infoq.com/news/2026/05/kubernetes-monitoring-helm/