Prometheus Operator #1 - 소개

Operator Framework 란?

Prometheus Operator를 소개하기 전에 먼저 Operator Framework를 알아보자.

Container의 Lifecycle을 관리하기 위해 Kubernetes(k8s)가 나왔으며, 많은 각광을 받고 있다. 그러나 사람이 직접 유지보수해야 하는 부분은 존재한다.

예를 들어 Configuration 변경이나 stateful application의 scale-out 등이 필요할때, 단순히 Configmap을 수정하고 Pod을 재시작하는 방식으로는 매끄러운 관리가 되지 않는다.

사람이 Manual로 작업해야 하는 부분이 있을 수 있는데, 문제는 이러한 Manual 작업이 반복될 수 밖에 없다는 것이다. 

이러한 문제를 해결하기 위해 만들어진 것이 바로 Operator Framework이다.

한 문장으로 컨셉을 설명하자면, "k8s application을 대상으로, 사람이 직접 하던 작업을 자동화 할 수 있게 해주는 프레임워크" 이다.

- https://www.redhat.com/ko/blog/introducing-operator-framework-building-apps-kubernetes

이 프레임워크는 Coreos에서 시작되었고 현재는 Coreos를 인수한 Redhat에서 리딩하고 있다.

Operator Framework은 Kubernetes Application을 패키징, 배포, 운영 자동화를 제공하며, 다음과 같은 Tool을 제공한다.

Operator SDK

개발자는 이 SDK를 이용해 Operator를 개발하면 된다. SDK를 이용하면 기존의 k8s client-go 를 이용하지 않고도 추상화된 k8s API사용이 가능하다.

Operator Lifecycle Manager(OLM)

OLM은 말그대로 Operator를 관리하는 매니저이다. Operator를 설치하고, 업데이트, 백업, 스케일링 등을 한다. 그 외에도 Application의 Operator 생성을 SDK를 사용하지 않고도 OLM을 활용해 가능하다고 한다.(OLM이란 용어가 명확하지 않아서 추구 바뀔 가능성도 있다)

Operator Metering

이러한 Operator Framework에 의해 만들어진 Application, Operator조합을 대상으로 한Metering 툴이다. 기본적으로 Application의 CPU/Memory등의 시계열 데이터를 활용(Prometheus와 연동된다)하여 Metering report data를 생성하고 제공하는 역할을 한다

이 Operator Framework은 Cloud에서 하나의 Architecture pattern이다. k8s에 Application의 모든 관리를 맡기는 것은 불가능하며, 그렇다고 단순한 작업에 많은 시간을 할애할 수가 없기 때문에 등장한 하나의 패턴인 것이다. 

Prometheus Operator

https://github.com/coreos/prometheus-operator

이 Operator Framework을 이용해 Prometheus를 효율적으로 관리하겠다는 의도로 나온게 이 Prometheus Operator 다. Pure Prometheus만을 사용하다보면 다음과 같은 운영관리 문제점들이 존재한다. 

점점 많아지는 Scrape, Rule configuration

수집해야하는 metric 정보와 rule이 많아질수록 prometheus configuration이 상당히 복잡해져서 효율적으로 관리하기가 어렵다. 특히나 CI/CD까지 적용하려다 보면 configuration의 부분적 재사용이 필요하게 되는데, 이 경우에도 Prometheus operator를 이용하면 쉽게 해결 된다. 

앞서 Operator framework의 주요 기능중에 핵심컨셉이 하나 존재한다. 

CRD(CustomResourceDefinition)가 바로 그것이다. k8s에서 제공하는, 사용자가 직접 Resource 를 define할 수가 있는데, Operator framework에서는 이 CRD를 활용하고 있다. 

Prometheus operator는 Prometheus의 Configuration을 이 CRD로 해결함으로써 결합도를 낮추고(decoupled) Prometheus 운영 효율성을 높인다.

상황에 따른 Logical data sharding이 필요

Prometheus operator는 N개의 Prometheus를 설치/관리할 수 있다. 이 말은 위에서 말한 configuration decoupling과 연계되어 각각의 Prometheus가 서로 다른 metric정보를 수집할 수 있으며, federation까지 활용하게 되면 복잡한 구조의 metric 수집 구조도 쉽게 해결 할 수 있음을 의미힌다(Prometheus조차 CRD로 관리되고 있다).

기본 작동 원리

위는 Prometheus Operator의 작동 방식에 대한 간단한 그림이다. 

여기서 ServiceMonitor는 특별히 어떠한 process가 아니고 configuration인 CRD에 해당한다.

ServiceMonitor의 예(k8s yaml): k8s apiserver를 scrape하는 configuration

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: creationTimestamp: "2018-12-26T02:18:11Z" generation: 1 labels: app: test-apiserver chart: prometheus-operator-0.1.31 heritage: Tiller release: test name: test-apiserver namespace: monitoring resourceVersion: "4450746" selfLink: /apis/monitoring.coreos.com/v1/namespaces/monitoring/servicemonitors/test-apiserver uid: 7ded03fb-08b4-11e9-940a-fa163e6e7c03 spec: endpoints: - bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token interval: 30s port: https scheme: https tlsConfig: caFile: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt insecureSkipVerify: false serverName: kubernetes jobLabel: component namespaceSelector: matchNames: - default selector: matchLabels: component: apiserver provider: kubernetes

예를 들어, 운영자가 ServiceMonitor 2번을 생성하면, 이를 Watch 하고 있는 Operator가 이 새로 생성된 ServiceMonitor로 현재 실행되고 있는 prometheus의 configuration file을 업데이트 하고, prometheus를 재실행 시킨다.

Operator와 Helm의 차이

Operator는 Helm의 기능을 포괄하고 있다. Helm은 k8s application의 배포 및 업그레이드를 다룬다면, Operator는 배포,업그레이드를 포함해 Application을 운영관리하는 역할까지 한다.

Operator Framework을 도입하면 기존의 Helm chart가 대체가 될 것이나, Operator자체를 Helm chart로도 만들수도 있고(OLM 사용을 배제), Operator 내부에서 Application 배포를 helm 으로도 할 수도 있다. 그러니까 정확히 Helm 기능을 대체하는게 아니고, 목적이 다르다고 이해하면 될 것 같다.

다음 글에서는 Helm chart를 이용해 Prometheus operator를 설치하고, Operator가 Prometheus를 구체적으로 어떠한 방식으로 다루는지 다뤄볼 예정이다.