EP04 [Part 2: Prometheus Operator 설치와 구성 #1] Kubernetes에 Prometheus Operator 설치 준비

Observability/Prometheus

EP04 [Part 2: Prometheus Operator 설치와 구성 #1] Kubernetes에 Prometheus Operator 설치 준비

ygtoken 2025. 3. 19. 14:38

728x90

이 글에서는 Kubernetes 환경에서 Prometheus Operator를 설치하기 위한 준비 과정에 대해 알아봅니다. Prometheus Operator의 개념과 장점, 아키텍처를 이해하고, 설치 전 사전 요구사항과 환경 준비 과정을 상세히 다룹니다. 이를 통해 안정적이고 확장 가능한 모니터링 시스템 구축의 기반을 마련할 수 있습니다.

📌 Prometheus Operator 이해하기

Kubernetes에서 Prometheus를 운영하려면 여러 컴포넌트를 개별적으로 관리해야 하는 복잡성이 있습니다. Prometheus Operator는 이러한 복잡성을 추상화하여 쿠버네티스 네이티브 방식으로 모니터링 시스템을 선언적으로 관리할 수 있게 해줍니다.

✅ Operator 패턴이란?

Operator는 쿠버네티스의 확장 메커니즘을 활용하여 복잡한 애플리케이션을 관리하는 패턴입니다.

# Operator가 없을 때 - 수동으로 모든 리소스 관리
# Prometheus 배포를 위한 일반적인 매니페스트 예시
apiVersion: apps/v1
kind: Deployment
metadata:
  name: prometheus-server
  namespace: monitoring
spec:
  replicas: 1
  selector:
    matchLabels:
      app: prometheus
  template:
    metadata:
      labels:
        app: prometheus
    spec:
      containers:
      - name: prometheus
        image: prom/prometheus:v2.41.0
        # 수십 줄의 설정이 필요...
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-config
  namespace: monitoring
data:
  prometheus.yml: |
    # 수백 줄의 복잡한 설정...
---
# 서비스, PVC, 인그레스 등 추가 리소스들...

Operator는 이러한 복잡성을 크게 단순화합니다:

# Operator 사용 시 - 단순한 CR(Custom Resource) 정의
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: prometheus
  namespace: monitoring
spec:
  replicas: 2  # 고가용성을 위한 2개 복제본
  version: v2.41.0
  serviceAccountName: prometheus
  securityContext:
    fsGroup: 2000
    runAsNonRoot: true
    runAsUser: 1000
  serviceMonitorSelector:
    matchLabels:
      team: frontend  # frontend 팀 애플리케이션만 모니터링
  resources:
    requests:
      memory: 400Mi
      cpu: 500m
    limits:
      memory: 2Gi
      cpu: 1000m
  retention: 15d  # 15일간 데이터 보존
  storage:
    volumeClaimTemplate:
      spec:
        storageClassName: standard
        resources:
          requests:
            storage: 50Gi  # 50GB 스토리지 요청

✅ Prometheus Operator의 주요 기능

선언적 관리
- 모니터링 스택을 코드로 정의(GitOps 친화적)
- 버전 관리 용이
자동화된 운영
- 프로비저닝 자동화
- 설정 업데이트 자동화
- 버전 업그레이드 간소화
쿠버네티스 통합
- 네이티브 쿠버네티스 리소스로 관리
- 라벨/어노테이션 기반 서비스 디스커버리
확장성
- 다중 Prometheus 인스턴스 관리
- 샤딩(Sharding) 지원

▶️ 실무 사례: 한 대규모 전자상거래 회사에서는 모니터링을 위해 10개 이상의 Prometheus 인스턴스를 관리해야 했습니다. 수동 관리 시 각 인스턴스별 설정과 업그레이드에 엔지니어 시간이 과도하게 소요되었으나, Operator 도입 후 모든 인스턴스를 중앙에서 단일 YAML 파일 세트로 관리하게 되어 운영 효율성이 크게 향상되었습니다.

📌 Prometheus Operator 아키텍처

Prometheus Operator는 여러 커스텀 리소스 정의(CRD)를 통해 모니터링 스택을 관리합니다.

✅ 주요 커스텀 리소스

Prometheus
- 실제 Prometheus 서버 인스턴스 정의
- 복제본 수, 버전, 보존 정책, 리소스 요구사항 등 지정

# Prometheus CR 예시
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: prometheus-main
  namespace: monitoring
spec:
  # Prometheus 서버 포드 복제본 수 (HA 구성)
  replicas: 2
  
  # 사용할 Prometheus 버전
  version: v2.41.0
  
  # 데이터 보존 기간
  retention: 10d
  
  # 스크레이핑할 ServiceMonitor 선택
  serviceMonitorSelector:
    matchLabels:
      monitor: "true"
  
  # 외부 레이블 설정 (다중 클러스터 구성 시 유용)
  externalLabels:
    cluster: "production-east"
    environment: "prod"
  
  # 노드 셀렉터를 통한 배치 제어
  nodeSelector:
    monitoring: "true"
  
  # 리소스 요청 및 제한
  resources:
    requests:
      memory: "1Gi"
      cpu: "500m"
    limits:
      memory: "2Gi"
      cpu: "1000m"
  
  # 영구 스토리지 설정
  storage:
    volumeClaimTemplate:
      spec:
        storageClassName: fast
        resources:
          requests:
            storage: 100Gi

ServiceMonitor
- 모니터링할 서비스를 정의
- 라벨 셀렉터를 통해 타겟 서비스 선택

# ServiceMonitor CR 예시
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: api-service-monitor
  namespace: monitoring
  labels:
    monitor: "true"  # Prometheus에서 이 레이블로 선택
spec:
  # 모니터링할 서비스가 있는 네임스페이스 선택
  namespaceSelector:
    matchNames:
      - default
      - app
  
  # 실제 모니터링할 서비스 선택 (라벨 기반)
  selector:
    matchLabels:
      app: api-service
  
  # 엔드포인트 설정
  endpoints:
  - port: web  # 서비스의 포트 이름 (숫자 대신 이름 사용)
    interval: 15s  # 스크래핑 주기
    path: /metrics  # 메트릭 경로
    
    # 기본 인증 설정 (필요한 경우)
    basicAuth:
      username:
        name: basic-auth
        key: username
      password:
        name: basic-auth
        key: password
    
    # mTLS 설정 (필요한 경우)
    tlsConfig:
      insecureSkipVerify: false
      caFile: /etc/prometheus/certs/ca.crt
      certFile: /etc/prometheus/certs/client.crt
      keyFile: /etc/prometheus/certs/client.key
    
    # 시간 초과 설정
    scrapeTimeout: 10s
    
    # 메트릭 릴레이블링 (수집 전)
    relabelings:
    - sourceLabels: [__meta_kubernetes_pod_name]
      targetLabel: pod
    
    # 메트릭 수집 후 메트릭 릴레이블링
    metricRelabelings:
    - sourceLabels: [__name__]
      regex: 'go_.*'
      action: drop  # go_ 접두사가 있는 메트릭 제외

PodMonitor
- 서비스 없이 직접 파드 모니터링
- 마이크로서비스가 서비스로 노출되지 않을 때 유용

# PodMonitor CR 예시
apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: backend-metrics
  namespace: monitoring
spec:
  # 모니터링할 파드가 있는 네임스페이스 선택
  namespaceSelector:
    matchNames:
      - backend
  
  # 실제 모니터링할 파드 선택 (라벨 기반)
  selector:
    matchLabels:
      app: backend-api
  
  # 파드의 메트릭 엔드포인트 정의
  podMetricsEndpoints:
  - port: metrics  # 컨테이너 포트 이름
    interval: 30s  # 스크래핑 주기
    path: /stats/prometheus  # 메트릭 경로 (기본값 /metrics와 다른 경우)

AlertManager
- Alertmanager 인스턴스 정의 및 설정

# AlertManager CR 예시
apiVersion: monitoring.coreos.com/v1
kind: Alertmanager
metadata:
  name: main
  namespace: monitoring
spec:
  # AlertManager 인스턴스 수 (HA 구성)
  replicas: 3
  
  # 설정은 보통 Secret으로 관리
  # 이 예시에서는 인라인으로 설정
  config:
    global:
      resolve_timeout: 5m
      smtp_smarthost: 'smtp.example.org:587'
      smtp_from: 'alerts@example.org'
      smtp_auth_username: 'alertmanager'
      smtp_auth_password: 'password'
    
    route:
      group_by: ['job', 'alertname', 'severity']
      group_wait: 30s
      group_interval: 5m
      repeat_interval: 4h
      receiver: 'team-emails'
      routes:
      - match:
          severity: critical
        receiver: 'team-pager'
    
    receivers:
    - name: 'team-emails'
      email_configs:
      - to: 'team@example.org'
    - name: 'team-pager'
      pagerduty_configs:
      - service_key: '<key>'
  
  # 리소스 요청 및 제한
  resources:
    requests:
      memory: "100Mi"
      cpu: "100m"
    limits:
      memory: "200Mi"
      cpu: "200m"

PrometheusRule
- 알림 및 기록 규칙 정의

# PrometheusRule CR 예시
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: kubernetes-important-rules
  namespace: monitoring
  labels:
    prometheus: main  # 특정 Prometheus 인스턴스에 규칙 적용
spec:
  groups:
  # 노드 관련 알림 규칙 그룹
  - name: node-alerts
    rules:
    # 디스크 공간 부족 알림
    - alert: NodeDiskRunningFull
      expr: predict_linear(node_filesystem_free_bytes[6h], 3600 * 24) < 0
      for: 30m
      labels:
        severity: warning
      annotations:
        summary: "디스크 공간 부족"
        description: "{{ $labels.instance }} 노드의 {{ $labels.mountpoint }} 파티션이 24시간 내에 가득 찰 예정입니다."
    
    # 노드 메모리 부족 알림
    - alert: NodeMemoryHigh
      expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes > 0.9
      for: 15m
      labels:
        severity: warning
      annotations:
        summary: "노드 메모리 사용량 높음"
        description: "{{ $labels.instance }} 노드의 메모리 사용량이 90%를 초과했습니다."
  
  # API 서비스 알림 규칙 그룹
  - name: api-service-alerts
    rules:
    # 높은 에러율 알림
    - alert: HighErrorRate
      expr: sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.1
      for: 10m
      labels:
        severity: critical
        team: api
      annotations:
        summary: "API 에러율 높음"
        description: "API 요청의 에러율이 10%를 초과했습니다 (현재 값: {{ $value | humanizePercentage }})"
    
    # 느린 응답 시간 알림
    - alert: SlowAPIResponse
      expr: histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service)) > 2
      for: 10m
      labels:
        severity: warning
        team: api
      annotations:
        summary: "API 응답 시간 지연"
        description: "{{ $labels.service }} 서비스의 95번째 백분위 응답 시간이 2초를 초과했습니다."
  
  # 자주 사용하는 집계 메트릭을 기록 규칙으로 사전 계산하여 쿼리 성능 향상
  - name: recording-rules
    rules:
    # 노드별 CPU 사용 기록 규칙
    - record: node:cpu_utilization:avg5m
      expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
    
    # API 엔드포인트별 요청 비율 기록 규칙
    - record: api:request_rate:5m
      expr: sum by (service, endpoint) (rate(http_requests_total[5m]))

✅ Operator 작동 원리

시작 시: Operator는 Kubernetes API 서버에 CRD들을 등록
CR 감시: Operator의 컨트롤러가 CR 변경사항 감시
리소스 관리:
- CR 생성 시: 필요한 Deployment, ConfigMap, Secret 등 생성
- CR 변경 시: 관련 리소스 자동 업데이트
- CR 삭제 시: 관련 리소스 정리

▶️ 아키텍처 특징: Prometheus Operator는 "조정자(reconciler)" 패턴을 따릅니다. 이는 현재 상태와 목표 상태 간의 차이를 지속적으로 확인하고 필요한 조치를 취하여 목표 상태에 도달하도록 합니다. 이 방식은 선언적 관리와 자가 치유 속성을 제공합니다.

📌 설치 전 사전 요구사항

Prometheus Operator를 설치하기 전에 다음 요구사항을 확인하고 준비하세요.

✅ 쿠버네티스 클러스터 요구사항

쿠버네티스 버전
- Kubernetes 1.19 이상
- RBAC(Role-Based Access Control) 활성화

# 쿠버네티스 버전 확인
kubectl version --short
# 출력 예시
# Client Version: v1.25.3
# Server Version: v1.24.8

클러스터 리소스
- 최소 권장 사양:
  - CPU: 2코어 (Prometheus + Operator)
  - 메모리: 4GB
  - 스토리지: 50GB (기본 보존 기간 15일 기준)
네트워크 요구사항
- Ingress Controller 또는 LoadBalancer (선택적)
- NodePort로도 접근 가능

✅ 권한 및 RBAC

Prometheus Operator가 클러스터 리소스를 관찰하고 관리하려면 적절한 권한이 필요합니다.

# 기본 권한 확인 예시 (필요한 ServiceAccount, ClusterRole, ClusterRoleBinding)
apiVersion: v1
kind: Namespace
metadata:
  name: monitoring
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: prometheus-operator
  namespace: monitoring
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus-operator
rules:
# 이 ClusterRole은 다음 API 그룹의 리소스를 관리할 권한을 부여
- apiGroups: [""]  # 코어 API 그룹
  resources:
  - services
  - endpoints
  - pods
  verbs: ["get", "list", "watch"]  # 읽기 전용 권한
- apiGroups: [""]
  resources:
  - nodes
  - nodes/metrics
  - namespaces
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources:
  - configmaps
  - secrets
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]  # 전체 권한
- apiGroups: ["apps"]
  resources:
  - statefulsets
  - deployments
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
# Custom Resource에 대한 권한
- apiGroups: ["monitoring.coreos.com"]
  resources:
  - prometheuses
  - alertmanagers
  - servicemonitors
  - podmonitors
  - prometheusrules
  verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: prometheus-operator
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: prometheus-operator
subjects:
- kind: ServiceAccount
  name: prometheus-operator
  namespace: monitoring

✅ 스토리지 준비

Prometheus는 시계열 데이터를 저장하므로 적절한 스토리지 계획이 중요합니다.

스토리지 클래스 확인

# 사용 가능한 스토리지 클래스 확인
kubectl get storageclass

스토리지 요구사항 계산

데이터 크기는 다음과 같은 요소에 따라 결정됩니다:

메트릭 수 (시계열 개수)
샘플링 간격
라벨 카디널리티
보존 기간

일반적인 계산 공식:

필요 스토리지 = 메트릭 수 × 샘플 크기 × 초당 샘플 수 × 초 단위 보존 기간

예시: 10,000개 메트릭, 15초 샘플링, 15일 보존 시

10,000 × 2바이트 × (1/15) × (15 × 24 × 60 × 60) ≈ 8.64GB

실제로는 라벨과 메타데이터 오버헤드를 고려하여 2-3배 더 큰 값으로 계획하는 것이 좋습니다.

✅ 네트워크 접근성

인그레스 설정 계획

# Prometheus와 Grafana에 대한 인그레스 예시
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: monitoring
  namespace: monitoring
  annotations:
    # 여기에 인그레스 컨트롤러별 어노테이션 추가
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
  tls:
  - hosts:
    - prometheus.example.com
    - grafana.example.com
    secretName: monitoring-tls
  rules:
  - host: prometheus.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: prometheus-operated
            port:
              number: 9090
  - host: grafana.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: grafana
            port:
              number: 3000

보안 고려사항

운영 환경에서는 다음 보안 설정을 고려하세요:

Prometheus UI에 대한 인증 (OAuth, basic auth 등)
TLS 암호화
네트워크 정책을 통한 접근 제한

# 네트워크 정책 예시 - 모니터링 네임스페이스 보호
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: monitoring-network-policy
  namespace: monitoring
spec:
  podSelector: {}  # 네임스페이스의 모든 파드에 적용
  policyTypes:
  - Ingress
  ingress:
  - from:
    # 같은 네임스페이스의 파드에서 접근 허용
    - podSelector: {}
    # kube-system 네임스페이스에서 접근 허용
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
    # 특정 IP 대역에서 접근 허용
    - ipBlock:
        cidr: 10.0.0.0/8  # 내부 네트워크
    ports:
    - protocol: TCP
      port: 9090  # Prometheus
    - protocol: TCP
      port: 3000  # Grafana

▶️ 설치 전 체크리스트:

쿠버네티스 버전 확인 (1.19+)
클러스터 리소스 충분한지 확인
RBAC 활성화 확인
적절한 스토리지 클래스 및 용량 계획
네트워크 접근 전략 수립
보안 요구사항 검토

📌 모니터링 전략 설계

Prometheus Operator 설치 전에 모니터링 전략을 수립하는 것이 중요합니다.

✅ 대상 및 범위 정의

클러스터 인프라 모니터링
- 노드, kubelet, API 서버 등 쿠버네티스 구성 요소
- etcd, CoreDNS 등 핵심 서비스
애플리케이션 모니터링
- 마이크로서비스
- 데이터베이스
- 캐시 시스템
- 메시징 시스템
비즈니스 메트릭
- 사용자 활동
- 트랜잭션
- 에러율

✅ 네임스페이스 계획

모니터링 컴포넌트 배치를 위한 네임스페이스 전략:

# 모니터링 전용 네임스페이스 생성
kubectl create namespace monitoring

# 필요한 경우 네임스페이스에 라벨 추가
kubectl label namespace monitoring monitoring=true

✅ 리소스 할당 계획

Prometheus 및 관련 컴포넌트에 대한 리소스 계획:

프로덕션 환경 기본 권장 값

컴포넌트	CPU 요청	메모리 요청	CPU 제한	메모리 제한
Prometheus	1000m	2048Mi	2000m	4096Mi
Alertmanager	100m	200Mi	200m	400Mi
Grafana	100m	128Mi	200m	256Mi
node-exporter	100m	30Mi	200m	50Mi
kube-state-metrics	100m	128Mi	200m	256Mi

스케일링 고려사항

리소스 요구사항은 다음 요소에 따라 달라집니다:

모니터링 대상 수
메트릭 수와 카디널리티
수집 간격
쿼리 복잡도와 빈도

▶️ 모니터링 전략 수립 팁: "모든 것을 모니터링하지 말고, 중요한 것만 모니터링하세요." 모든 메트릭을 수집하면 리소스 사용량과 관리 복잡성이 급증합니다. 비즈니스 및 시스템에 정말 중요한 메트릭에 집중하세요.

📌 설치 방법 선택

Prometheus Operator를 설치하는 여러 방법이 있으며, 각 방법에는 장단점이 있습니다.

✅ 주요 설치 방법 비교

직접 YAML 적용
- 장점: 세밀한 제어, 모든 구성 요소 이해 가능
- 단점: 복잡하고 시간 소모적, 업그레이드 관리 어려움
Helm 차트 (kube-prometheus-stack)
- 장점: 간편한 설치 및 업그레이드, 다양한 옵션 제공
- 단점: 추상화로 인한 이해 어려움, 때로는 유연성 제한
Jsonnet (예: kube-prometheus)
- 장점: 고도의 커스터마이징, GitOps 워크플로우 적합
- 단점: 학습 곡선, 추가 도구 필요
Operator Lifecycle Manager (OLM)
- 장점: 오퍼레이터 수명주기 관리, 업그레이드 간소화
- 단점: 추가 오버헤드, 일부 환경에서 제한적

✅ 환경별 추천 방법

환경 추천	방법	이유
개발/테스트	Helm	빠른 시작, 간편한 설정
소규모 프로덕션	Helm	적절한 균형의 복잡성과 기능
대규모 프로덕션	Jsonnet	다중 클러스터 일관성, 세밀한 제어
규제 환경	직접 YAML	모든 구성 요소에 대한 감사 용이

✅ kube-prometheus-stack 살펴보기

kube-prometheus-stack은 Prometheus Operator를 포함하여 완전한 모니터링 스택을 제공하는 Helm 차트입니다.

포함된 구성 요소:

Prometheus Operator
Prometheus 인스턴스
Alertmanager
Grafana
kube-state-metrics
node-exporter
주요 서비스 모니터 및 대시보드

# helm values.yaml 구성 예시
prometheus:
  prometheusSpec:
    # Prometheus 서버 복제본 수
    replicas: 2
    
    # 보존 설정
    retention: 15d
    
    # 스토리지 설정
    storageSpec:
      volumeClaimTemplate:
        spec:
          storageClassName: standard
          resources:
            requests:
              storage: 50Gi
    
    # 리소스 요구사항
    resources:
      requests:
        memory: 2Gi
        cpu: 500m
      limits:
        memory: 4Gi
        cpu: 1000m

alertmanager:
  alertmanagerSpec:
    # Alertmanager 복제본 수
    replicas: 2
    
    # 스토리지 설정
    storage:
      volumeClaimTemplate:
        spec:
          storageClassName: standard
          resources:
            requests:
              storage: 10Gi
    
    # 리소스 요구사항
    resources:
      requests:
        memory: 200Mi
        cpu: 100m
      limits:
        memory: 400Mi
        cpu: 200m

grafana:
  # 관리자 비밀번호 (또는 기존 시크릿 사용)
  adminPassword: "prom-operator"
  
  # 영구 스토리지 활성화
  persistence:
    enabled: true
    size: 10Gi
    storageClassName: standard
  
  # 기본 대시보드 및 데이터 소스
  defaultDashboardsEnabled: true
  defaultDashboardsTimezone: Asia/Seoul
  
  # 추가 데이터 소스
  additionalDataSources:
  - name: Loki
    type: loki
    url: http://loki-gateway.monitoring.svc.cluster.local
    access: proxy

# 커스텀 ServiceMonitor 예시 (MySQL)
additionalServiceMonitors:
- name: mysql
  selector:
    matchLabels:
      app: mysql
  namespaceSelector:
    matchNames:
      - default
      - database
  endpoints:
  - port: metrics
    interval: 30s
    scrapeTimeout: 10s

▶️ 선택 기준: 소규모에서 중간 규모의 클러스터에는 Helm을 통한 kube-prometheus-stack 설치가 일반적으로 가장 적합합니다. 간편한 설치와 관리 용이성을 제공하면서도 대부분의 사용 사례를 충족합니다. 이후 글에서는 이 방법을 중심으로 설명하겠습니다.

📌 설치 환경 준비하기

실제 설치 전에 환경을 준비하고 필요한 도구를 설정해봅시다.

✅ 필요 도구 설치

kubectl - 쿠버네티스 클러스터 관리 CLI

# Linux에 kubectl 설치
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
chmod +x kubectl
sudo mv kubectl /usr/local/bin/

# 버전 확인
kubectl version --client

Helm - 쿠버네티스 패키지 관리자

# Linux에 Helm 설치
curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
chmod 700 get_helm.sh
./get_helm.sh

# 버전 확인
helm version

✅ Helm 레포지토리 추가

# Prometheus 커뮤니티 Helm 레포지토리 추가
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts

# 레포지토리 업데이트
helm repo update

# 사용 가능한 차트 확인
helm search repo prometheus-community

✅ 네임스페이스 및 리소스 준비

# 모니터링용 네임스페이스 생성
kubectl create namespace monitoring

# 필요한 경우 리소스 할당량 설정
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ResourceQuota
metadata:
  name: monitoring-quota
  namespace: monitoring
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi
    persistentvolumeclaims: "10"
EOF

✅ 보안 설정

RBAC 준비

# 기본 RBAC이 활성화되어 있는지 확인
kubectl cluster-info dump | grep authorization-mode
# 출력에 'RBAC'이 포함되어 있어야 함

PodSecurityPolicy (필요한 경우)

# 모니터링용 PodSecurityPolicy 예시
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: monitoring-psp
  annotations:
    seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'runtime/default'
    seccomp.security.alpha.kubernetes.io/defaultProfileName: 'runtime/default'
spec:
  privileged: false
  allowPrivilegeEscalation: false
  requiredDropCapabilities:
    - ALL
  volumes:
    - 'configMap'
    - 'emptyDir'
    - 'projected'
    - 'secret'
    - 'downwardAPI'
    - 'persistentVolumeClaim'
  hostNetwork: false
  hostIPC: false
  hostPID: false
  runAsUser:
    rule: 'MustRunAsNonRoot'
  seLinux:
    rule: 'RunAsAny'
  supplementalGroups:
    rule: 'MustRunAs'
    ranges:
      - min: 1
        max: 65535
  fsGroup:
    rule: 'MustRunAs'
    ranges:
      - min: 1
        max: 65535
  readOnlyRootFilesystem: false

✅ 스토리지 준비

# 사용 가능한 스토리지 클래스 확인
kubectl get storageclass

# 기본 스토리지 클래스가 없다면 생성 (예: minikube에서)
# 예: minikube에서 기본 스토리지 클래스 생성
cat <<EOF | kubectl apply -f -
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: standard
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: k8s.io/minikube-hostpath
EOF

✅ 설치 전 검증

쿠버네티스 버전 확인

kubectl version
# Server Version: v1.24.x 이상이면 OK

클러스터 상태 확인

kubectl get nodes
# 모든 노드가 Ready 상태여야 함

kubectl get pods --all-namespaces
# kube-system 포드들이 정상 실행 중이어야 함

네트워크 플러그인 동작 확인

# 파드 간 통신 테스트
kubectl run busybox --image=busybox -- sleep 3600
kubectl exec -it busybox -- ping -c 3 kubernetes.default
# 3개의 패킷이 모두 도달해야 함

Helm 기본 기능 테스트

# 테스트용 간단한 차트 배포
helm repo add bitnami https://charts.bitnami.com/bitnami
helm install test-redis bitnami/redis --set auth.enabled=false --set architecture=standalone

# 테스트 파드가 실행 중인지 확인
kubectl get pods | grep test-redis

# 테스트 완료 후 제거
helm uninstall test-redis

▶️ 환경 준비 체크리스트:

필요한 CLI 도구 설치 완료 (kubectl, helm)
Prometheus 커뮤니티 Helm 레포지토리 추가
모니터링 네임스페이스 생성
RBAC 및 보안 정책 확인
스토리지 클래스 및 용량 확인
클러스터 전반적인 상태 검증

📌 설치 전 설정 파일 준비

Helm을 사용하여 kube-prometheus-stack을 설치하기 전에 사용자 정의 values.yaml 파일을 준비하는 것이 좋습니다.

✅ 기본 values.yaml 확인

# 기본 values.yaml 파일 확인하기
helm show values prometheus-community/kube-prometheus-stack > original-values.yaml

✅ 사용자 정의 values.yaml 작성

다음은 일반적인 환경에 맞춘 사용자 정의 values.yaml 예시입니다:

# custom-values.yaml

# Prometheus Operator 설정
prometheusOperator:
  # Operator 리소스 요구사항
  resources:
    limits:
      cpu: 200m
      memory: 200Mi
    requests:
      cpu: 100m
      memory: 100Mi
  
  # Admission Webhook 설정 (선택적)
  admissionWebhooks:
    enabled: true
    # 인증서 관리 방법 (cert-manager 또는 자체 서명)
    certManager:
      enabled: false

# Prometheus 서버 설정
prometheus:
  prometheusSpec:
    # 복제본 수 (HA 구성)
    replicas: 1
    
    # 보존 정책
    retention: "10d"
    retentionSize: "30GB"
    
    # 리소스 요구사항
    resources:
      limits:
        cpu: 1000m
        memory: 2Gi
      requests:
        cpu: 500m
        memory: 1Gi
    
    # 영구 스토리지 설정
    storageSpec:
      volumeClaimTemplate:
        spec:
          storageClassName: standard
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 50Gi
    
    # 원격 쓰기/읽기 설정 (선택적)
    remoteWrite: []
    remoteRead: []
    
    # 외부 레이블 (여러 클러스터에서 메트릭 구분)
    externalLabels:
      cluster: "production"
      environment: "prod"
    
    # SecurityContext 설정
    securityContext:
      fsGroup: 2000
      runAsNonRoot: true
      runAsUser: 1000
    
    # 추가 Prometheus 규칙 (원하는 경우)
    additionalRuleLabels: {}
    
    # Thanos 사이드카 (장기 저장소 연동 시)
    thanos: {}

# Alertmanager 설정
alertmanager:
  alertmanagerSpec:
    # 복제본 수
    replicas: 1
    
    # 리소스 요구사항
    resources:
      limits:
        cpu: 200m
        memory: 200Mi
      requests:
        cpu: 100m
        memory: 100Mi
    
    # 영구 스토리지 설정
    storage:
      volumeClaimTemplate:
        spec:
          storageClassName: standard
          accessModes: ["ReadWriteOnce"]
          resources:
            requests:
              storage: 10Gi
    
    # 알림 설정
    config:
      global:
        resolve_timeout: 5m
      route:
        group_by: ['job', 'severity']
        group_wait: 30s
        group_interval: 5m
        repeat_interval: 12h
        receiver: 'null'
        routes:
        - match:
            alertname: Watchdog
          receiver: 'null'
      receivers:
      - name: 'null'
    
    # 내부 알림 템플릿 (선택적)
    templates: []

# Grafana 설정
grafana:
  # 관리자 계정 설정
  adminPassword: "admin-password"  # 또는 기존 시크릿 사용
  
  # 영구 스토리지 활성화
  persistence:
    enabled: true
    size: 10Gi
    storageClassName: standard
  
  # 리소스 요구사항
  resources:
    limits:
      cpu: 200m
      memory: 200Mi
    requests:
      cpu: 100m
      memory: 100Mi
  
  # 대시보드 프로비저닝
  dashboardProviders:
    dashboardproviders.yaml:
      apiVersion: 1
      providers:
      - name: 'default'
        orgId: 1
        folder: ''
        type: file
        disableDeletion: false
        editable: true
        options:
          path: /var/lib/grafana/dashboards/default
  
  # 추가 데이터 소스 (선택적)
  additionalDataSources: []
  
  # 기본 대시보드 활성화
  defaultDashboardsEnabled: true
  
  # SMTP 설정 (알림용)
  smtp:
    enabled: false
    host: "smtp.example.com:587"
    user: "grafana"
    password: "password"
    fromAddress: "grafana@example.com"

# Node Exporter 설정
nodeExporter:
  enabled: true
  resources:
    limits:
      cpu: 200m
      memory: 50Mi
    requests:
      cpu: 100m
      memory: 30Mi

# kube-state-metrics 설정
kubeStateMetrics:
  enabled: true
  resources:
    limits:
      cpu: 100m
      memory: 200Mi
    requests:
      cpu: 10m
      memory: 50Mi

# Prometheus 규칙 설정
defaultRules:
  # 기본 알림 규칙 활성화
  create: true
  # 특정 규칙 비활성화
  disabled: {}
  # 규칙 수정
  rules:
    etcd: false  # etcd 규칙 비활성화 (외부 etcd 사용 시)

# 네임스페이스 스크래핑 설정
kubeTargetVersionOverride: "1.24.0"  # 현재 쿠버네티스 버전에 맞게 설정

# kube-controller-manager와 kube-scheduler 모니터링 설정
kubeControllerManager:
  enabled: true
  endpoints: []  # 외부 컨트롤러 관리자 IP 지정 (필요한 경우)

kubeScheduler:
  enabled: true
  endpoints: []  # 외부 스케줄러 IP 지정 (필요한 경우)

kubelet:
  enabled: true
  serviceMonitor:
    https: true

✅ 설정 파일 검증

사용자 정의 values.yaml 파일을 작성한 후, 실제 적용 전에 템플릿 렌더링을 통해 검증할 수 있습니다:

# 템플릿 렌더링 검증 (실제 설치하지 않음)
helm template prometheus-stack prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  -f custom-values.yaml > rendered-templates.yaml

# 렌더링된 템플릿 검증
kubectl create --dry-run=client -f rendered-templates.yaml

▶️ 설정 파일 관리 팁: values.yaml 파일은 Git과 같은 버전 관리 시스템에 저장하고, 변경 사항을 추적하세요. 이렇게 하면 설정 변경 이력이 유지되며, GitOps 기반 접근 방식을 적용할 수 있습니다.

📌 Summary

Prometheus Operator는 쿠버네티스 환경에서 모니터링 스택을 선언적으로 관리하는 강력한 도구입니다.
커스텀 리소스를 통해 Prometheus, Alertmanager, ServiceMonitor 등을 관리하여 운영 복잡성을 크게 줄여줍니다.
설치 준비는 클러스터 요구사항 확인, 네임스페이스 생성, 권한 설정, 스토리지 구성 등을 포함합니다.
kube-prometheus-stack Helm 차트는 모니터링 스택의 모든 컴포넌트를 포함하는 포괄적인 솔루션입니다.
설치 환경은 kubectl, Helm과 같은 필수 도구 준비와 리포지토리 설정으로 시작합니다.
사용자 정의 values.yaml을 통해 환경에 맞는 리소스 할당, 보존 기간, 고가용성 구성 등을 설정할 수 있습니다.
다음 에피소드에서는 Helm을 사용한 kube-prometheus-stack 배포 과정을 자세히 다루겠습니다.

728x90

저작자표시 비영리 변경금지

'Observability > Prometheus' 카테고리의 다른 글

EP06 [Part 2: Prometheus Operator 설치와 구성 #3] 기본 설정 및 커스터마이징 (0)	2025.03.23
EP05 [Part 2: Prometheus Operator 설치와 구성 #2] Helm을 사용한 kube-prometheus-stack 배포 (0)	2025.03.19
EP03 [Part 1: Kubernetes 모니터링 기초 #3] 메트릭(Metrics)의 이해와 수집 방법 (0)	2025.03.19
EP02 [Part 1: Kubernetes 모니터링 기초 #2] Prometheus의 아키텍처와 작동 원리 (0)	2025.03.19
EP01 [Part 1: Kubernetes 모니터링 기초 #1] 모니터링의 본질과 Prometheus의 핵심 개념 (0)	2025.03.19

현재글EP04 [Part 2: Prometheus Operator 설치와 구성 #1] Kubernetes에 Prometheus Operator 설치 준비

YG Tech Blog

A blog about IT, covering topics from cloud computing and DevOps to Kubernetes and system architecture. Sharing insights, solutions, and best practices for modern IT professionals

쿠버네티스, Python, RAG, statefulset, 서비스_운영, 서비스메시, DevOps, langchain, Istio, k8s, Cilium, Minio, argocd, DaemonSet, CI/CD, 파이썬, gitops, Security, YAML, kubernetes,

Today :
Yesterday :

YG Tech Blog