Kubernetes Monitoring – 3. kube-prometheus 설치 후 해야 할일

kube-prometheus 를 설치 후 해야할 일들에 대해서 알아 보겠습니다.

편안하고 안전한 모니터링을 위해서 다음과 같은 작업을 하면 좋습니다.

  • prometheus-k8s, alertmanager-main 에서 PV(Persistence Volume) 을 사용하도록 변경합니다.
  • prometheus-k8s, alertmanager-main, grafana를 위한 Ingress 를 생성합니다.
  • alertmanager-main 에서 노티피케이션을 보낼 수 있도록 설정을 추가해 줍니다.

PV(Persistence Volume) 사용하기

프로메테우스 서버 같은 애플리케이션들은 데이터를 스토리지에 저장합니다. 그래서, 포드(POD)를 이용하여 애플리케이션을 실행할 때, 사용할 수 있는 스토리지를 지정해 줘야 데이터를 저장할 수 있습니다. kube-prometheus 의 기본값을 사용하여 설치하였을 경우에, 설정된 스토리지는 호스트 노드의 임시 디렉토리입니다. 그래서 포드가 다른 곳에 재배치되는 등의 상황에서는 기존 데이터를 사용할 수 없는 문제가 생깁니다. 이러한 문제를 해결하기 위해서 쿠버네티스에 지원하는 볼륨들 중에서 영속성을 가지고, 노드에 상관없이 이용할 수는 볼륨을 사용해야 합니다. 이 문서에서는 쿠버네티스트의 PV(Persistence Volume)를 사용하겠습니다. PV는 단어 그대로, 영속성을 가지는 볼륨으로서, 데이터를 지속적으로 저장할 수 있습니다. 한 가지 주의할 점은, PV를 사용하기 위해서는 쿠버네티스 클러스터에 PV를 위한 프로비저닝 설정이 되어 있어야합니다. PV를 위한 동적 프로비저닝이 된다는 가정하에 설명을 진행하도록 하겠습니다.

먼저 쿠버네티스 클러스터에서 지원하는 스토리지 클래스를 조회해 봅니다. 다음 명령어를 실행하면 스토리지 클래스를 조회할 수 있습니다.

kubectl get storageclass

지원하는 스토리지 클래스가 있을 경우 다음과 같은 형식으로 출력됩니다.

NAME                   PROVISIONER                AGE
ssd (default)          cinder.csi.openstack.org   51d

prometheus-k8s 에서 PV 사용하기

동적 프로비저닝을 이용하여 PV를 생성해 보겠습니다. 동적 프로비저닝을 이용하면, PVC(PersistentVolumeClaim)을 생성하면, 프로비저너가 자동으로 PV를 생성해 줍니다.

다음 명령어를 실행하여 k8s 라는 이름의 Prometheus 리소스를 편집하겠습니다.

kubectl -n monitoring edit prometheus k8s

Prometheus 리소스 매니페스트를 다음과 같이 수정합니다. Prometheus 리소스 매니페스트의 storage 필드에 volumeClaimTemplate 을 추가해 줍니다. 사용할 storageClassName 이름과 용량을 지정해 줍니다.

apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  labels:
    prometheus: k8s
  name: k8s
  namespace: monitoring
spec:
  externalUrl: <http://prometheus.my-domain.com/>
  storage:
    volumeClaimTemplate:
      spec:
        resources:
          requests:
            storage: 80Gi
        storageClassName: ssd

alertmanager-main 에서 PV 사용하기

다음 명령어를 실행하여 main이라는 이름의 AlertManager 리소스를 편집하겠습니다.

kubectl -n monitoring edit alertmanager main

AlertManager 리소스 매니페스트를 다음과 같이 수정합니다. AlertManager 리소스 매니페스트의 storage 필드에 volumeClaimTemplate 을 추가해 줍니다. 사용할 storageClassName 이름과 용량을 지정해 줍니다.

apiVersion: monitoring.coreos.com/v1
kind: Alertmanager
metadata:
  labels:
    alertmanager: main
  name: main
  namespace: monitoring
spec:
  externalUrl: <http://alertmanager.my-domain.com/>
  storage:
    volumeClaimTemplate:
      spec:
        resources:
          requests:
            storage: 10Gi
        storageClassName: ssd

Grafana 에서 PV 사용하기

그라파나의 대시보드 같은 정보를 저장하기 위하여서 PV를 사용하는게 좋습니다. 기본 설정은 임시디렉토로 되어 있습니다. 그래서, 그라파에서 새로운 대시보드를 생성할 경우 문제가 생길 수 있습니다. 포드가 재시작되는 경우 새로 생성한 대시보드 정보가 사라져 버릴 수 있기 때문입니다. 그래서 그라파나에서 PV를 사용하도록 설정해 주는 좋습니다.

그라파나는 prometheus-operator 에서 관리하는 대상이 아닙니다. 쿠버네티스의 기본 리소스인 Deployment 를 사용하고 있습니다. 그래서 먼저 PVC 를 생성하여, Deployment 에 추가 해줘햐합니다.

PVC 생성하기

먼저 그라파나 PVC 매니페스트를 작성합니다.

grafana-pvc.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  labels:
    app: grafana
  name: grafana
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: ssd

그리고, 다음 명령어를 실행하여 grafan이라는 이름의 PVC 를 생성하겠습니다.

kubectl -n monitoring apply -f grafana-pvc.yaml

그라파나 Deployment 수정하기

다음 명령어를 실행하여 grafan이라는 이름의 Deployment 리소스를 편집하겠습니다.

kubectl -n monitoring edit deploy grafana

Deployment 리소스 매니페스트를 다음과 같이 수정합니다.

Deployment 리소스 매니페스트의 spec.template.spec.volumes 필드에 있는 name: grafana-storage 부분을 persistentVolumeClaim 을 사용하도록 수정해 줍니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: grafana
  name: grafana
...
spec:
...
  template:
    spec:
...
      volumes:
      - name: grafana-storage
        persistentVolumeClaim:
          claimName: grafana

그리고 디렉토리의 권한을 맞추기 위해서 securityContext을 수정해 줍니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: grafana
  name: grafana
...
spec:
...
  template:
    spec:
      securityContext:
        runAsUser: 472
        fsGroup: 472

이 부분은 그라파나 컨테이너 이미지 버전에 따라서 다르기 때문에 필요 없을 수도 있습니다. 만약 추가하지 않으면 다음과 같은 에러가 발생할 수 있습니다.

$ kubectl logs grafana-84b4f94f5-7hnl9

GF_PATHS_DATA='/var/lib/grafana' is not writable.
You may have issues with file permissions, more information here: <http://docs.grafana.org/installation/docker/#migration-from-a-previous-version-of-the-docker-container-to-5-1-or-later>
mkdir: can't create directory '/var/lib/grafana/plugins': Permission denied

다음은 수정한 매니페스트의 일부분입니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: grafana
  name: grafana
...
spec:
  replicas: 1
  selector:
    matchLabels:
      app: grafana
  template:
    metadata:
      labels:
        app: grafana
    spec:
      containers:
      - image: grafana/grafana:7.0.3
        name: grafana
        ports:
        - containerPort: 3000
          name: http
...
      nodeSelector:
        beta.kubernetes.io/os: linux
      securityContext:
        runAsUser: 472
        fsGroup: 472
      serviceAccountName: grafana
      volumes:
      - name: grafana-storage
        persistentVolumeClaim:
          claimName: grafana

Kubernetes Monitoring – 2. 모니터링 이해하기

프로메테우스를 이용한 쿠버네티스 모니터링 이해하기

kube-prometheus에 의해서 설치된 컴포넌트들을 살펴보도록 하겠습니다.

설치된 컴포넌트

kube-prometheus를 설치하면, 다음과 같은 컴포넌트들이 생성됩니다.

  • prometheus -operator : prometheus 와 alertmanager를 생성/삭제하고 관리하는 prometheus -operator가 설치됩니다.
  • prometheus : prometheus-k8s 라는 이름의 기본 프로메테우스 서버가 생성됩니다.
  • alertmanager : alertmanager-main 라는 이름의 기본 알럿 매니저가 생성됩니다.
  • node-exporter : 노드의 메트릭을 수집하기 위한 node-exporter가 생성됩니다.
  • prometheus -adapter : HPA를 위한 proemtheus-adapter가 생성됩니다.
  • kube-state-metrics : 쿠버네티스 클러스터의 메트릭을 수집하기 위한 kube-state-metrics가 생성됩니다.
  • grafana : 메트릭 시각화를 위한 grafana가 생성됩니다.

메트릭 수집

기본적으로 생성되는 prometheus-k8s 라는 이름의 프로메테우스 서버에서 수집하는 대상들에 대해서 알아보겠습니다. 설치한 버전에 따라서 약간의 차이는 존재할 수 있습니다.

프로메테우스 서버에서 수집하는 대상은 프로메테우스 서버 웹 화면의 메뉴에서 Status → Targets을 클릭하면 확인해 볼 수 있습니다. kube-prometheus 를 이용하여 설치했기 때문에, 기본적인 수집 대상이 등록되어 있습니다.

kubelet

쿠버네티스의 각 노드들에는 kubelet 이 기본적으로 설치되어 있습니다. kubelet 에는 cAdvisor가 통합되어 있는데, 이 cAdvisor 를 통해서 개별 컨테이너의 메트릭 정보들을 가져올 수 있습니다.

프로메테우스 서버는 kubelet을 이용하여 컨테이너의 메트릭 정보들을 수집합니다.

node-exporter

node-exporter는 쿠버네티스의 DaemonSet 리소스로 정의되어 있습니다. 그래서 쿠버네티스의 각 노드들에 node-exporter가 설치됩니다. node-exporter는 설치된 노드의 CPU, 메모리, 네트워크 같은 메트릭을 수집하도록 도와줍니다. node-exporter에 대한 자세한 사항은 해당 페이지를 참고하시기 바랍니다.

프로메테우스 서버는 node-exporter을 이용하여 노드의 메트릭 정보들을 수집합니다.

kube-state-metrics

kube-state-metrics 는 쿠버네티스 클러스터 레벨의 메트릭을 수집할 수 있도록 도와줍니다. 디플로이먼트(deployment)나 포드(pod) 등의 메트릭과 자원 예약 같은 정보를 제공합니다. kube-state-metrics에서 제공하는 메트릭에 대한 자세한 내용은 해당 페이지를 참고 바랍니다.

프로메테우스 서버는 kube-state-metrics을 이용하여 쿠버네티스 클러스터의 메트릭 정보들을 수집합니다.

기타 내부 컴포넌트

kube-system 네임스페이스 있는 내부 컴포넌트들의 메트릭도 수집을 합니다. etcd, coredns, kube-apiserver, kube-controller-manager, kube-scheduler 등이 있습니다.

알럿 관리

프로메테우스 서버에서 알럿 룰(AerltRule)을 정의하여, 알럿을 발생 시킬 수 있습니다. 발생한 알럿은 서버에 설정된 알럿 매니저(AlertManager)로 전송됩니다. prometheus-k8s 프로메테우스 서버의 경우에는 alertmanager-main 이라는 이름의 알럿 매니저로 알럿이 발송됩니다.

알럿 룰 (Alert Rules)

알럿 룰은 프로메테우스 서버에서 정의할 수 있습니다. 알럿 룰은 일반적으로 yaml 파일으로 이루어져 있으며 프로메테우스 서버가 해당 파일을 읽어서 알럿 룰을 읽어오게 됩니다.

알럿 룰은 프로메테우스 서버 웹 화면의 메뉴에서 Status → Rules 을 클릭하면 확인해 볼 수 있습니다. kube-prometheus 를 이용하여 설치했기 때문에, 기본적인 알럿 룰들이 등록되어 있습니다.

그리고 룰에 의해서 생성된 알럿들은 웹 화면의 메뉴의 Alerts 에서 확인할 수 있습니다.

알럿 룰은 알럿 룰을 정의한 yaml 파일은 만든 다음에, 프로메테우스 서버 설정에 추가 하면 됩니다. 이 글에서는 prometheus-operator를 사용하기 때문에, PrometheusRule 라는 사용자 리소스를 이용하여 알럿 룰을 정의할 수 있습니다.

다음은 PrometheusRule 매니페스트의 일부분 입니다.

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  labels:
    prometheus: k8s
    role: alert-rules
  name: prometheus-k8s-rules
  namespace: monitoring
spec:
  groups:
  - name: node-exporter
    rules:
    - alert: NodeFilesystemSpaceFillingUp
      annotations:
        description: Filesystem on {{ $labels.device }} at {{ $labels.instance }}
          has only {{ printf "%.2f" $value }}% available space left and is filling
          up.
        runbook_url: https://github.com/kubernetes-monitoring/kubernetes-mixin/tree/master/runbook.md#alert-name-nodefilesystemspacefillingup
        summary: Filesystem is predicted to run out of space within the next 24 hours.
      expr: |
        (
          node_filesystem_avail_bytes{job="node-exporter",fstype!=""} / node_filesystem_size_bytes{job="node-exporter",fstype!=""} * 100 < 40
        and
          predict_linear(node_filesystem_avail_bytes{job="node-exporter",fstype!=""}[6h], 24*60*60) < 0
        and
          node_filesystem_readonly{job="node-exporter",fstype!=""} == 0
        )
      for: 1h
      labels:
        severity: warning

프로메테우서 서버에서 발생한 알럿은 알럿 매니저로 발송됩니다. 알럿 매니저는 해당 알럿을 받아서, 설정에 따라 노티피케이션을 발송하게 됩니다. 노티피케이션은 슬랙, 메일 등 다양한 곳으로 보낼 수 있습니다. 자세한 사항은 해당 페이지를 참고하시기 바랍니다.

기본적으로 생성된alertmanager-main 알럿 매니저에서 별다른 설정이 없기 때문에, 노티피케이션이 발송되지 않습니다.

다음은 알럿 매니저의 화면입니다.

메트릭 시각화

프로메테우스 서버의 웹 화면에서 간단한 그래프를 그릴 수 있지만, 전문 시각화 도구인 그라파나(Grafana)를 이용하면, 보다 편리하고 멋지게 시각화를 할 수 있습니다.

그라파나는 데이터를 가져올 수 있는 데이터 소스를 등록할 수 있습니다. kube-prometheus 를 이용하여 설치했기 때문에 기본적으로 proemtheus-k8s 가 데이터 소스로 등록되어 있습니다. 그리고, 기본적인 대시보드들도 등록되어 있기 때문에, 바로 쿠버네티스 클러스터의 상태를 대시보드로 확인할 수 있습니다.

다음은 기본적으로 등록되어 있는 대시보드 목록의 일부분입니다. 대시보드 이름을 클릭하면 대시보드 화면으로 이동합니다.

다음은 쿠버네티스 클러스터의 대시보드 화면입니다.

Kubernetes Monitoring – 1. kube-prometheus 설치하기

쿠버네티스 클러스터와 애플리케이션을 모니터링 하기 위한 방법은 다양하게 존재합니다. 퍼블릭 클라우드를 사용하는 경우에는, 클라우드 프로바이더에서 제공하는 모니터링 도구들을 사용할 수 있습니다. 그리고, 직접 쿠버네티스 클러스터를 설치하여 사용하는 경우에는, 오픈소스들을 사용하여 모니터링할 수 있습니다. 이 글에서는 모니터링 오픈소스 중의 하나인 프로메테우스를 이용하여, 모니터링을 하는 방법에 대해서 알아보겠습니다.

쿠버네티스 기본 메트릭 서버

쿠버네티스에서는 리소스의 메트릭을 조회할 수 있는 메트릭 API를 제공하고 있습니다. 메트릭 API를 사용하면, 컨테이너 CPU 및 메모리 사용량과 같은 리소스 사용량을 조회할 수 있습니다. 이 메트릭 API는 kubectl top 같은 명령어를 실행될때 사용되며, HPA(Horizontal Pod Autoscaler) 같은 클러스터 컨트롤러에서도 사용을 하고 있습니다.

메트릭 API

메트릭 API를 통해 지정한 노드나 파드에서 사용하고 있는 현재 리소스의 양을 알 수 있습니다. 하지만, 메트릭 API는 메트릭 값을 저장하고 있지 않으므로, 10분 전에 사용한 리소스의 양을 조회할 수 는 없습니다. 한 가지 주의할 점은 메트릭 API를 사용하려면, 메트릭 서버가 클러스터에 배포되어 있어야합니다.

메트릭 API에 대한 상세한 정보는 k8s.io/metrics 리포지터리에서 확인할 수 있습니다.

메트릭 서버

메트릭 서버는 클러스터 전역에서 리소스 사용량 데이터를 집계합니다. 메트릭 서버는 오토스케일링 의 목적으로만 사용해야 합니다. 그래서 모니터링 솔루션에 메트릭스를 전달하거나, 모니터링 솔루션 메트릭의 소스로 사용해서는 안됩니다.

프로메테우스 서버

프로메테우스 소개

프로메테우스는 현재 쿠버네티스 상에서 가장 많이 사용되고 있는 오픈 소스 기반 모니터링 시스템입니다. CNCF에 소속되어 있으며, 쿠버네티스 클러스터 및 컨테이너들를 손쉽게 모니터링 가능합니다.

프로메테우스의 주요 특징은 다음과 같습니다.

  • 메트릭 이름과 key-value 형태로 식별되는 시계열 데이터를 제공합니다.
  • PromQL 이라는 쿼리 언어를 사용할 수 있습니다.
  • 경고(Alert)와 룰셋(Ruleset)을 만들 수 도 있습니다.
  • Grafana 같은 시스템을 이용하여 간단하게 대시보드를 만들 수 있습니다.

프로메테우스 구조

모니터링을 위해 메트릭을 수집하는 방식은 크게 두 가지가 있습니다. Push 방식과 Pull 방식입니다.

Push 방식은 각 서버나 애플리케이션에 클라이언트를 설치하고, 이 클라이언트가 메트릭 데이터를 수집해서 메트릭 서버로 보내는 방식입니다.

Pull 방식은 각 서버나 애플리케이션이 메트릭을 수집할 수 있는 엔드포인트를 제공합니다. 그래서 메트릭 서버가 해당 엔드포인트를 호출하여 메트릭을 가지고 가는 방식입니다.

프로메테우스는 Pull 방식을 사용합니다. 즉, 애플리케이션이 작동하고 있으면, 메트릭 서버가 주기적으로 애플리케이션의 메트릭 엔드포인트에 접속해서 데이터를 가져오는 방식을 취하는 것입니다.

다음 다이어그램은 프로메테우스의 구조와 일부 생태계 구성요소를 보여줍니다.

출처 : https://prometheus.io/docs/introduction/overview/

프로메테우스 생태계는 여러 컴포넌트로 구성되어 있으며, 대부분은 선택 사항입니다.

  • Prometeus Server : 시계열 데이터를 스크랩하고 저장합니다.
  • Service discovery : 프로메테우스는 메트릭을 Pull 하기 때문에, 메트릭 수집 대상에 대한 정보가 필요합니다. 메트릭 수집 대상은 파일 같은 것을 이용하여 직접 관리할 수 있고, 쿠버네티스와 연동하여 자동으로 수집 대상을 동기화할 수 있습니다.
  • Pushgateway : ‘Short-lived jobs’ 을 지원하기 위해서 메트릭을 Push 하기 위한 게이트입니다. 애플리케이션이 Pushgateway에 메트릭을 Push 한 후, Prometheus Server가 Pushgateway에 접근해 메트릭을 Pull 해서 가져옵니다.
  • Jobs/Expoerters : Exporter 는 프로메테우스가 메트릭을 수집할 수 있도록, 특정 서버나 애플리케이션의 메트릭을 노출할 수 있게 도와주는 에이전트라고 볼 수 있습니다. Exporter는 서버 상태를 나타내는 Node exporter 같은 것이 존재하며, 다양한 커스텀 Exporter 이 개발되어 사용되고 있습니다.이러한 Exporter를 사용하여, 메트릭을 프로메테우스어 수집해 갈 수 있습니다.
  • Alertmanager : 경고(Alert)를 관리합니다. 메트릭에 대한 어떠한 지표를 지정해놓고, 그 규칙을 위반하는 사항에 대해 경고을 전송하는 역할을 합니다. 발생한 경고를 Slack이나 Email등으로 발송할 수 있습니다.
  • Service discovery : 프로메테우스는 메트릭을 Pull 하기 때문에, 메트릭 수집 대상에 대한 정보가 필요합니다. 메트릭 수집 대상은 파일 같은 것을 이용하여 직접 관리할 수 있고, 쿠버네티스와 연동하여 자동으로 수집 대상을 동기화할 수 있습니다.
  • Data visualiztion : Data visualiztion은 다양한 모니터링 대시보드를 위한 시각화를 제공합니다. 프로메테우스 web UI에서도 수집한 데이터를 이용하여 간단한 그래프를 그릴 수 있습니다. 일반적으로 Grafana 같은 전문 시각환 도구를 이용하여, 수집한 데이터를 시각화 합니다.

쿠버네티스에서 프로메테우스 사용하기

쿠버네티스에서 프로메테우스를 사용하는 방법은 크게 두 가지가 있습니다.

  • Prometheus : 프로메테우스 서버를 직접 생성하여 사용하는 방법입니다.
  • Prometheus Operator : 프로메테우스 오퍼레이터를 먼저 설치 한 다음, 오퍼레이터를 이용하여 프로메테우스 서버를 생성하는 방법입니다.

이 글에서는 프로메테우스 오퍼레이터를 이용합니다. 프로메테우스 오퍼레이터를 사용하는 이유는, 보다 간단하게 프로메테우스 서버를 생성할 수 있기 때문입니다. 사용자의 다양한 요구를 만족시키거나, 자동화를 하기에서는 프로메테우스 오퍼레이터가 조금 더 편합니다. 하지만 프로메테우스 오퍼레이터에 대한 학습 비용이 더 발생하기 때문에 간단히 사용할 경우에는 직접 프로메테우스 서버를 생성하여 사용하는게 좋을 수도 있습니다.

Prometheus Operator

프로메테우스 오퍼레이터는 쿠버네티스의 서비스들을 쉽게 모니터링할 수 있도록 해줍니다. 그리고, 프로메테우스 인스턴스의 배포와 관리하는 기능을 제공하고 있습니다. 사용자는 쿠버네티스의 사용자 리소스를 이용하여, 프로메테우스 모니터링 인스턴스를 생성, 구성 및 관리할 수 있습니다.

프로메테우스 오퍼레이터는 설치 후 다음과 같은 기능을 제공한다.

  • 생성 / 삭제 : 프로메테우스 오퍼레이터를 사용하여, 특정 애플리케이션 또는 팀을 위한 프로메테우스 인스턴스를 쉽게 실행할 수 있습니다.
  • 단순 구성: 쿠버네티스의 리소스를 이용하여 프로메테우스의 설정을 구성할 수 있습니다.
  • 레이블을 통한 대상 서비스 : 쿠버네티스 레이블 쿼리를 기반으로 모니터링 대상 구성을 자동으로 생성할 수 있습니다.

Prometheus Operator vs. kube-prometheus vs. community helm chart

프로메테우스 오퍼레이터를 설치하는 방법도 크게 세 가지가 있습니다. 이 글에서 kube-prometheus 를 사용하겠습니다.

Prometheus Operator

프로메테우스 오퍼레이터는 프로메테우스와 Alertmanager를 관리하고 운영합니다.

kube-prometheus

kube-prometheus 프로메테우스 오퍼레이터와 일련의 매니페스트들을 결합하여 쿠버네티스 클러스트와 그 위에서 실행 중인 애플리케이션을 모니터링하는 것을 도와줍니다.

kube-prometheus 패키지에는 다음과 같은 패키지가 포함되어 있습니다.

helm chart

stable/prometheus-operator 헬름 차트는 kube-prometheus 와 비슷한 기능을 제공합니다. 이 차트는 커뮤니티에 의해 유지되고 있습니다. 자세한 내용은 차트의 readme 를 참고하십시오.

kube-prometheus

쿠버네티스 호환성

다음은 쿠버네티스 버전과 kube-prometheus 버전의 호환성을 나타낸 것입니다.

kube-prometheus stackKubernetes 1.14Kubernetes 1.15Kubernetes 1.16Kubernetes 1.17Kubernetes 1.18
release-0.3
release-0.4✔ (v1.16.5+)
release-0.5
HEAD

kube-prometheus 설치

이미 만들어진 매니페스트를 이용하여 kube-prometheus를 설치하겠습니다.

  • 저장소에서 kube-prometheus 를 가지고 옵니다.
git clone <https://github.com/coreos/kube-prometheus.git>
cd kube-prometheus
  • 디렉토리에 있는 매니페스트를 사용하여 모니터링 스택을 생성합니다.
kubectl create -f manifests/setup
until kubectl get servicemonitors --all-namespaces ; do date; sleep 1; echo ""; done
kubectl create -f manifests/

모니터링 컴포넌트를 배포할 때 레이스 조건을 피하기 위해 먼저 네임스페이스와 CustomResourceDefinitions를 생성합니다. 두 폴더의 리소스를 단일 명령 kubectl create -f manifests/setup -f manifests로 적용할 수 있지만, 모든 컴포넌트가 성공적으로 생성되기 위해서는 명령을 여러 번 실행해야 할 수도 있기 때문에 나누어서 실행하였습니다.

  • 만약 설치한 모니터링 스택을 제거하려면 다음 명령어를 사용할 수 있습니다.
kubectl delete --ignore-not-found=true -f manifests/ -f manifests/setup

대시보드 접근하기

Prometheus

$ kubectl --namespace monitoring port-forward svc/prometheus-k8s 9090

http://localhost:9090 로 접속할 수 있습니다.

Grafana

$ kubectl --namespace monitoring port-forward svc/grafana 3000

http://localhost:3000 로 접속할 수 있습니다. Grafana의 기본 사용자:비밀번호는 admin:admin 입니다.

Alert Manager

$ kubectl --namespace monitoring port-forward svc/alertmanager-main 9093

Then access via http://localhost:9093 로 접속할 수 있습니다.

참고자료

Prometheus Operator로 kube-proxy 모니터링 하기

kube-proxy 모니터링 하기

kube-proxy도 /metrics라는 매트릭 엔드 포인트를 제공한다. 하지만 기본 설정값이 127.0.0.1:10249이기 때문에, 외부에서 접근이 안된다.

그래서 prometheus에서 수집하려고 하면, 접근이 안되서 문제가 발생한다.

설정 변경하기

$ kubectl -n kube-system edit cm/kube-proxy 
## Change from
    metricsBindAddress: 127.0.0.1:10249
## Change to
    metricsBindAddress: 0.0.0.0:10249

물론 0.0.0.0:10249로 변경하고, 모든 곳에서 다 접근이 가능하기 때문에, 보안이 취약한 곳이라면 사용하지 않는것이 좋다.

설정을 변경하고, kube-proxy를 재시작하면 적용이 된다.

kubectl -n kube-system delete pod -l k8s-app=kube-proxy 

Prometheus Operator로 etcd 모니터링 하기

etcd 모니터링 하기

etcd는 /metrics 라는, 프로메테우스가 수집할 수 있는 매트릭 엔드 포인트를 제공한다. 하지만, Secure Etcd 클러스터인 경우에는 해당 엔드 포인트에 접근하기 위해서는 인증서가 필요하다.

(다른 방법으로는 /metrics 엔드 포인트를 다른 포트로 분리하여, 인증서 없이 접근할 수도 있다. --listen-metrics-urls 옵션을 참고 바란다.)

환경

helm을 사용해서 prometheus-operator를 설치할 것이다. 그래서 prometheus-operator를 설치할때, etcd를 모니터링하도록 설정 파일을 변경해서 사용한다.

values.yaml 수정하기

kubeEtcd

kubeEtcd.serviceMonitor의 값들을 변경한다. scheme를 https로 변경하고, 인증서 정보를 등록한다.

## Component scraping etcd
##
kubeEtcd:
...
  serviceMonitor:
    scheme: https
    insecureSkipVerify: false
    serverName: localhost
    caFile: /etc/prometheus/secrets/etcd-client-cert/etcd-ca
    certFile: /etc/prometheus/secrets/etcd-client-cert/etcd-client
    keyFile: /etc/prometheus/secrets/etcd-client-cert/etcd-client-key
...

prometheus

프로메테우스를 기동할때 etcd-client-cert란 이름의 secret를 pod에 마운트하기 위해서, prometheus.secrets에 etcd-client-cert를 추가해 준다. 그리고, etcd 스크랩 설정 추가를 위해서, prometheus.additionalScrapeConfigs의 kube-etcd 부분을 활성화 해준다

## Deploy a Prometheus instance
##
prometheus:
...
    secrets:
      - "etcd-client-cert"

...

    additionalScrapeConfigs:
      - job_name: kube-etcd
        kubernetes_sd_configs:
          - role: node
        scheme: https
        tls_config:
          ca_file:   /etc/prometheus/secrets/etcd-client-cert/etcd-ca
          cert_file: /etc/prometheus/secrets/etcd-client-cert/etcd-client
          key_file:  /etc/prometheus/secrets/etcd-client-cert/etcd-client-key
        relabel_configs:
        - action: labelmap
          regex: __meta_kubernetes_node_label_(.+)
        - source_labels: [__address__]
          action: replace
          target_label: __address__
          regex: ([^:;]+):(\d+)
          replacement: ${1}:2379
        - source_labels: [__meta_kubernetes_node_name]
          action: keep
          regex: .*mst.*
        - source_labels: [__meta_kubernetes_node_name]
          action: replace
          target_label: node
          regex: (.*)
          replacement: ${1}
        metric_relabel_configs:
        - regex: (kubernetes_io_hostname|failure_domain_beta_kubernetes_io_region|beta_kubernetes_io_os|beta_kubernetes_io_arch|beta_kubernetes_io_instance_type|failure_domain_beta_kubernetes_io_zone)
          action: labeldrop
          
...

인증서 복사하기

etcd 인증서를, 프로메테스를 설치할 monitoring 네임스페이스에, etcd-client-cert란 이름의 secret로 복사한다.

POD_NAME=$(kubectl get pods -o=jsonpath='{.items[0].metadata.name}' -l component=kube-apiserver -n kube-system)

kubectl create secret generic etcd-client-cert -n monitoring \
  --from-literal=etcd-ca="$(kubectl exec $POD_NAME -n kube-system -- cat /etc/kubernetes/pki/etcd/ca.crt)" \
  --from-literal=etcd-client="$(kubectl exec $POD_NAME -n kube-system -- cat /etc/kubernetes/pki/etcd/healthcheck-client.crt)" \
  --from-literal=etcd-client-key="$(kubectl exec $POD_NAME -n kube-system -- cat /etc/kubernetes/pki/etcd/healthcheck-client.key)"

helm으로 prometheus-operator 설치하기

helm 설치 명령어로, proemtheus-operator를 설치한다. 수정한 설정값을 적용하기 위해서 --values values.yaml 옵션을 사용한다.

helm install stable/prometheus-operator --name mon --namespace monitoring --values values.yaml --tls

참고 사항

helm으로 prometheus-operator를 삭제할때, crd는 자동으록 삭제되지 않는다. 아래 명령어로 직접 삭제해야한다.

kubectl delete --ignore-not-found customresourcedefinitions \
  prometheuses.monitoring.coreos.com \
  servicemonitors.monitoring.coreos.com \
  podmonitors.monitoring.coreos.com \
  alertmanagers.monitoring.coreos.com \
  prometheusrules.monitoring.coreos.com

Prometheus Operator로 etcd 모니터링 하기

 1 분 소요

etcd 모니터링 하기

etcd는 /metrics 라는, 프로메테우스가 수집할 수 있는 매트릭 엔드 포인트를 제공한다. 하지만, Secure Etcd 클러스터인 경우에는 해당 엔드 포인트에 접근하기 위해서는 인증서가 필요하다.

(다른 방법으로는 /metrics 엔드 포인트를 다른 포트로 분리하여, 인증서 없이 접근할 수도 있다. --listen-metrics-urls 옵션을 참고 바란다.)

환경

helm을 사용해서 prometheus-operator를 설치할 것이다. 그래서 prometheus-operator를 설치할때, etcd를 모니터링하도록 설정 파일을 변경해서 사용한다.

values.yaml 수정하기

kubeEtcd

kubeEtcd.serviceMonitor의 값들을 변경한다. scheme를 https로 변경하고, 인증서 정보를 등록한다.

## Component scraping etcd
##
kubeEtcd:
...
  serviceMonitor:
    scheme: https
    insecureSkipVerify: false
    serverName: localhost
    caFile: /etc/prometheus/secrets/etcd-client-cert/etcd-ca
    certFile: /etc/prometheus/secrets/etcd-client-cert/etcd-client
    keyFile: /etc/prometheus/secrets/etcd-client-cert/etcd-client-key
...

prometheus

프로메테우스를 기동할때 etcd-client-cert란 이름의 secret를 pod에 마운트하기 위해서, prometheus.secrets에 etcd-client-cert를 추가해 준다. 그리고, etcd 스크랩 설정 추가를 위해서, prometheus.additionalScrapeConfigs의 kube-etcd 부분을 활성화 해준다.

## Deploy a Prometheus instance
##
prometheus:
...
    secrets:
      - "etcd-client-cert"

...

    additionalScrapeConfigs:
      - job_name: kube-etcd
        kubernetes_sd_configs:
          - role: node
        scheme: https
        tls_config:
          ca_file:   /etc/prometheus/secrets/etcd-client-cert/etcd-ca
          cert_file: /etc/prometheus/secrets/etcd-client-cert/etcd-client
          key_file:  /etc/prometheus/secrets/etcd-client-cert/etcd-client-key
        relabel_configs:
        - action: labelmap
          regex: __meta_kubernetes_node_label_(.+)
        - source_labels: [__address__]
          action: replace
          target_label: __address__
          regex: ([^:;]+):(\d+)
          replacement: ${1}:2379
        - source_labels: [__meta_kubernetes_node_name]
          action: keep
          regex: .*mst.*
        - source_labels: [__meta_kubernetes_node_name]
          action: replace
          target_label: node
          regex: (.*)
          replacement: ${1}
        metric_relabel_configs:
        - regex: (kubernetes_io_hostname|failure_domain_beta_kubernetes_io_region|beta_kubernetes_io_os|beta_kubernetes_io_arch|beta_kubernetes_io_instance_type|failure_domain_beta_kubernetes_io_zone)
          action: labeldrop
          
...

인증서 복사하기

etcd 인증서를, 프로메테스를 설치할 monitoring 네임스페이스에, etcd-client-cert란 이름의 secret로 복사한다.

POD_NAME=$(kubectl get pods -o=jsonpath='{.items[0].metadata.name}' -l component=kube-apiserver -n kube-system)

kubectl create secret generic etcd-client-cert -n monitoring \
  --from-literal=etcd-ca="$(kubectl exec $POD_NAME -n kube-system -- cat /etc/kubernetes/pki/etcd/ca.crt)" \
  --from-literal=etcd-client="$(kubectl exec $POD_NAME -n kube-system -- cat /etc/kubernetes/pki/etcd/healthcheck-client.crt)" \
  --from-literal=etcd-client-key="$(kubectl exec $POD_NAME -n kube-system -- cat /etc/kubernetes/pki/etcd/healthcheck-client.key)"

helm으로 prometheus-operator 설치하기

helm 설치 명령어로, proemtheus-operator를 설치한다. 수정한 설정값을 적용하기 위해서 --values values.yaml 옵션을 사용한다.

helm install stable/prometheus-operator --name mon --namespace monitoring --values values.yaml --tls

참고 사항

helm으로 prometheus-operator를 삭제할때, crd는 자동으록 삭제되지 않는다. 아래 명령어로 직접 삭제해야한다.

kubectl delete --ignore-not-found customresourcedefinitions \
  prometheuses.monitoring.coreos.com \
  servicemonitors.monitoring.coreos.com \
  podmonitors.monitoring.coreos.com \
  alertmanagers.monitoring.coreos.com \
  prometheusrules.monitoring.coreos.com

참고 링크

  • https://github.com/helm/charts/tree/master/stable/prometheus-operator
  • https://github.com/kubernetes-monitoring/kubernetes-mixin
  • https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/monitoring.md

Prometheus를 사용해서 NVIDIA GPU 모니터링 하기

Node의 GPU 모니터링 하기

prometheus를 사용해서 노드들의 매트틱을 수집하고 있다면, 아마 node-exporter를 사용하고 있을 것이다. NVIDIA에서는 dcgm-exporter라는 GPU 매트릭 출력용 이미지를 제공하고 있다. 이 dcgm-exporter과 node-exporter를 결합하여 사용하면, GPU 매트릭을 수집할 수 있다.

dcgm-exporter

dcgm(Data Center GPU Manager) exporter는 nv-hostenging을 시작해서, 매초마다 GPU 매트릭을 읽어서 prometheus 형식으로 출력해주는 간단한 쉘 스크립트이다.

Node 설정하기

우선 일반 노드와 GPU 노드를 분리하기 위해서 taint와 label을 설정해주었다. 대부분 node-exporter를 실행하기 위해서 DaemonSet을 사용했을 것이다.

일반 노드에서는 node-exporter만을 실행하기 위해서 taint nvidia.com/gpu=:NoSchedule를 사용하였고, GPU 노드에서는 node-exporter + dcgm-exporter를 실행하기 위해서 label hardware-type=NVIDIAGPU를 사용하였다.

nvidia.com/brand는 현재로는 별의미가 없지만 붙여주었다.

kubectl taint nodes ${node} nvidia.com/gpu=:NoSchedule

kubectl label nodes ${node} "nvidia.com/brand=${label}"
kubectl label nodes ${node} hardware-type=NVIDIAGPU

기존 node-exporter에 dcgm-exporter 추가하기

dcgm-exporter가 GPU 매트릭을 파일로 남기고, prometheus는 그 파일을 읽어서 GPU 매트릭을 같이 출력한다.

GPU 노드용

apiVersion: apps/v1
kind: DaemonSet
metadata:
  labels:
    app.kubernetes.io/name: node-exporter
    app.kubernetes.io/instance: gpu-node-exporter
    app.kubernetes.io/part-of: prometheus
    app.kubernetes.io/managed-by: argo-system
  name: prometheus-gpu-node-exporter
  namespace: argo-system
spec:
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app.kubernetes.io/name: node-exporter
      app.kubernetes.io/instance: gpu-node-exporter
      app.kubernetes.io/part-of: prometheus
      app.kubernetes.io/managed-by: argo-system
  template:
    metadata:
      labels:
        app.kubernetes.io/name: node-exporter
        app.kubernetes.io/instance: gpu-node-exporter
        app.kubernetes.io/part-of: prometheus
        app.kubernetes.io/managed-by: argo-system
    spec:
      nodeSelector:
        hardware-type: NVIDIAGPU
      containers:
      - args:
        - --path.procfs=/host/proc
        - --path.sysfs=/host/sys
        - "--collector.textfile.directory=/run/prometheus"
        image: prom/node-exporter:v0.18.1
        imagePullPolicy: IfNotPresent
        name: prometheus-node-exporter
        ports:
        - containerPort: 9100
          hostPort: 9100
          name: metrics
          protocol: TCP
        resources:
          limits:
            cpu: 500m
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 100Mi
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        volumeMounts:
        - mountPath: /host/proc
          name: proc
          readOnly: true
        - mountPath: /host/sys
          name: sys
          readOnly: true
        - name: collector-textfiles
          readOnly: true
          mountPath: /run/prometheus
      - image: nvidia/dcgm-exporter:1.4.6
        name: nvidia-dcgm-exporter
        securityContext:
          runAsNonRoot: false
          runAsUser: 0
        volumeMounts:
          - name: collector-textfiles
            mountPath: /run/prometheus
      dnsPolicy: ClusterFirst
      hostNetwork: true
      hostPID: true
      restartPolicy: Always
      serviceAccount: prometheus-node-exporter
      serviceAccountName: prometheus-node-exporter
      terminationGracePeriodSeconds: 30
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/master
      - effect: NoSchedule
        key: node-role.kubernetes.io/ingress
        operator: Exists
      - effect: NoSchedule
        key: nvidia.com/gpu
        operator: Exists
      volumes:
      - hostPath:
          path: /proc
          type: ""
        name: proc
      - hostPath:
          path: /sys
          type: ""
        name: sys
      - name: collector-textfiles
        emptyDir:
          medium: Memory
      - name: pod-gpu-resources
        hostPath:
          path: /var/lib/kubelet/pod-resources
  updateStrategy:
    type: OnDelete

일반 노드용

apiVersion: apps/v1
kind: DaemonSet
metadata:
  labels:
    app.kubernetes.io/name: node-exporter
    app.kubernetes.io/instance: node-exporter
    app.kubernetes.io/part-of: prometheus
    app.kubernetes.io/managed-by: argo-system
  name: prometheus-node-exporter
  namespace: argo-system
spec:
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app.kubernetes.io/name: node-exporter
      app.kubernetes.io/instance: node-exporter
      app.kubernetes.io/part-of: prometheus
      app.kubernetes.io/managed-by: argo-system
  template:
    metadata:
      labels:
        app.kubernetes.io/name: node-exporter
        app.kubernetes.io/instance: node-exporter
        app.kubernetes.io/part-of: prometheus
        app.kubernetes.io/managed-by: argo-system
    spec:
      containers:
      - args:
        - --path.procfs=/host/proc
        - --path.sysfs=/host/sys
        image: prom/node-exporter:v0.18.1
        imagePullPolicy: IfNotPresent
        name: prometheus-node-exporter
        ports:
        - containerPort: 9100
          hostPort: 9100
          name: metrics
          protocol: TCP
        resources:
          limits:
            cpu: 500m
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 100Mi
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        volumeMounts:
        - mountPath: /host/proc
          name: proc
          readOnly: true
        - mountPath: /host/sys
          name: sys
          readOnly: true
      dnsPolicy: ClusterFirst
      hostNetwork: true
      hostPID: true
      restartPolicy: Always
      serviceAccount: prometheus-node-exporter
      serviceAccountName: prometheus-node-exporter
      terminationGracePeriodSeconds: 30
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/master
      - effect: NoSchedule
        key: node-role.kubernetes.io/ingress
        operator: Exists
      volumes:
      - hostPath:
          path: /proc
          type: ""
        name: proc
      - hostPath:
          path: /sys
          type: ""
        name: sys
  updateStrategy:
    type: OnDelete

프로메테우스 시계열 데이터 삭제하기

프로메테우스(Prometheus)에서 시계열(Time series) 데이터를 삭제하는 방법에 대해서 알아보겠습니다.

디스크 용량이 부족하거나 필요없는 시계열 데이터가 있을 경우, 데이터를 삭제할 필요가 있습니다. 프로메테우스의 시계열 데이터를 삭제하려면 관리 API를 사용해야합니다. 이 관리 API는 기본적으로 비활성화 되어 있습니다.

관리 API 활성화 하기

이 기능을 활성화 하기 위해서는, 프로메테우스를 기동할때 --web.enable-admin-api 파라메터를 추가해줘야합니다.

시계열 데이터 삭제하기

시계열 데이터를 삭제하는 API는 delete_series 입니다. 아래 명령어를 실행하면, 레이블과 일치하는 시계열 데이터를 모두 삭제할 수 있습니다.

curl -X POST \
	-g 'http://localhost:9090/api/v1/admin/tsdb/delete_series?match[]={foo="bar"}'

예를 들어 잡(job)이나 인스턴스(instance)에 해당하는 데이터를 삭제하려면, 다음과 같이 실행하면 됩니다.

curl -X POST \
	-g 'http://localhost:9090/api/v1/admin/tsdb/delete_series?match[]={job="node_exporter"}'

curl -X POST \
	-g 'http://localhost:9090/api/v1/admin/tsdb/delete_series?match[]={instance="172.22.0.1:9100"}'

전체 시계열 데이터를 모두 삭제하려면, 다음과 같이 실행하면 됩니다.

curl -X POST \
	-g 'http://localhost:9090/api/v1/admin/tsdb/delete_series?match[]={__name__=~".+"}'

참고로 delete_series API를 호출해도, 데이터가 즉시 삭제되지는 않는다. 실제 데이터는 디스크에 남아있고, 다음번 컴팩션(compaction)이 실행될때 정리된다. 바로 정리 하고 싶다면, 다음과 같이 clean_tombstones API를 호출하면 된다.

curl -X POST -g 'http://localhost:9090/api/v1/admin/tsdb/clean_tombstones'