쿠버네티스 오퍼레이터란? ( Kubernetes Operator )
먼저 오퍼레이터를 이해하기 위해서는 쿠버네티스의 동작흐름과 몇 가지 개념을 알 필요가 있다.
왜냐하면 오퍼레이터는 쿠버네티스가 동작 흐름을 기반으로 동작하기 때문이다.
쿠버네티스는 다음과 같은 두 가지 접근법이 존재한다.
명령형(Imperative)
- shell을 통해 kubectl과 같은 커맨드라인으로 오브젝트를 핸들링하는 방식이다.
선언형(Declarative)
- yaml과 같은 파일에 오브젝트를 정의하고 apply로 생성하는 방식이다.
사용자는 두 접근방식으로 명시적인 애플리케이션 상태를 설정하면 쿠버네티스의 컨트롤러들은 지속적으로(컨트롤 루프) 리소스들을 감시하고 current state(현재 상태) -> desired state(원하는 상태) 되도록 상태를 처리한다.
오퍼레이터는 이러한 멱등성의 쿠버네티스의 동작방식을 기반으로 추가적인 오브젝트들을 관리하기 위한 확장 기능의 조합이다.
CRD(CustomResourceDefinition)
: pod, service와 같은 쿠버네티스 기본 오브젝트 이외에 사용자가 추가적으로 사용하는 오브젝트를 정의한 것이다.
# CRD 예시: ServiceMonitor
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
annotations:
controller-gen.kubebuilder.io/version: v0.11.1
creationTimestamp: "2023-08-07T07:46:05Z"
generation: 1
name: servicemonitors.monitoring.coreos.com
resourceVersion: "15703927"
uid: dfd87263-e0b5-48c6-bb52-099bb7f1ea9c
spec:
conversion:
strategy: None
group: monitoring.coreos.com
names:
categories:
- prometheus-operator
kind: ServiceMonitor
listKind: ServiceMonitorList
plural: servicemonitors
shortNames:
- smon
singular: servicemonitor
scope: Namespaced
CR(CustomResource)
: CRD에서 정의한 오브젝트의 데이터라고도 할 수 있다. 아래와 같이 crd를 kind로 사용하는 yaml 파일이다.
# CR 예시: ServiceMonitor
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor # CRD
metadata:
annotations:
meta.helm.sh/release-name: prometheus-stack
meta.helm.sh/release-namespace: monitoring
creationTimestamp: "2023-09-07T04:27:05Z"
generation: 1
labels:
app: kube-prometheus-stack-alertmanager
app.kubernetes.io/instance: prometheus-stack
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/part-of: kube-prometheus-stack
app.kubernetes.io/version: 48.3.1
chart: kube-prometheus-stack-48.3.1
heritage: Helm
release: prometheus-stack
name: prometheus-stack-kube-prom-alertmanager
namespace: monitoring
resourceVersion: "26363529"
uid: 67b6cc21-3cfa-40b1-9085-5a9f3435eb1d
spec:
endpoints:
- enableHttp2: true
path: /metrics
port: http-web
- path: /metrics
port: reloader-web
CC(Custom Controller)
replicaset controller와 같은 쿠버네티스 컨트롤러 이외에 추가적으로 커스텀 리소스를 관리하는 사용자가 만든 컨트롤러이다.
정리하자면,
오퍼레이터는 쿠버네티스의 컨트롤러 개념을 통해 새로운 오브젝트를 정의(CRD)하고 오브젝트(CR)와 컨트롤러(CC)의 통합이다.
오퍼레이터를 사용한다면 쿠버네티스의 코드를 수정할 필요 없이 쿠버네티스의 운영에 필요한 다양한 것들을 포함시켜 자동화 할 수 있다.
프로메테우스 오퍼레이터 실습 ( Prometheus Operator )
이론적인 설명 만으로는 잘 이해가 되지 않으니 실제로 오퍼레이터를 어떻게 활용하는지 실습을 통해 알아보자.
이번 포스팅에서는 대표적인 오퍼레이터 사용 사례가 되는 프로메테우스 오퍼레이터를 예시로 설명하겠다.
프로메테우스 오퍼레이터
프로메테우스 오퍼레이터는 ServiceMonitor,PodMonitor,PrometheusRule 등의 커스텀리소스의 변경사항을 감지하며
프로메테우스운영의 필요한 다양한 것들을 자동화 해준다.
프로메테우스 prometheus-kube-stack 오퍼레이터 헬름 차트를 배포해 보자. 설치방법은 링크를 참고.
리소스 조회 시 , prometheus-stack-kube-prom-operator라는 오퍼레이터와 프로메테우스 관련 CRD를 볼 수 있다.
프로메테우스 PrometheusRule 추가
프로메테우스의 웹 화면에 접속 후, status > alert 페이지에서 pod:container_cpu_usage:sum라는 레코드 룰이 있는지 확인한다.
default로 생성되는 룰이 아니기 때문에 조회가 되지 않는다.
그럼, PrometheusRule 커스텀리소스(CR)를 이용해서 pod:container_cpu_usage:sum라는 record 룰을 추가해 볼 것이다.
# prometheusRule.yaml
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
labels:
release: prometheus-stack
name: cluster-monitoring-operator-prometheus-rules
namespace: monitoring
spec:
groups:
- name: openshift-kubernetes.rules
rules:
- expr: sum(rate(container_cpu_usage_seconds_total{container!="",pod!=""}[5m]))
BY (pod, namespace)
record: pod:container_cpu_usage:sum
# prometheusRule 배포
kubectl apply -f prometheusRule.yaml
# prometheusRule 확인
kubectl get prometheusrules.monitoring.coreos.com -n monitoring cluster-monitoring-operator-prometheus-rules
cluster-monitoring-operator-prometheus-rules
# 프로메테우스 업데이트된 이력 확인(sh.helm.release.v1.prometheus-stack.v2)
root@master1:~# kubectl get secret -n monitoring
NAME TYPE DATA
alertmanager-prometheus-stack-kube-prom-alertmanager Opaque 1
alertmanager-prometheus-stack-kube-prom-alertmanager-generated Opaque 1
alertmanager-prometheus-stack-kube-prom-alertmanager-tls-assets-0 Opaque 0
alertmanager-prometheus-stack-kube-prom-alertmanager-web-config Opaque 1
prometheus-kube-prometheus-admission Opaque 3
prometheus-prometheus-stack-kube-prom-prometheus Opaque 1
prometheus-prometheus-stack-kube-prom-prometheus-tls-assets-0 Opaque 1
prometheus-prometheus-stack-kube-prom-prometheus-web-config Opaque 1
prometheus-stack-grafana Opaque 3
prometheus-stack-kube-prom-admission Opaque 3
sh.helm.release.v1.prometheus-1691390239.v1 helm.sh/release.v1 1
sh.helm.release.v1.prometheus-stack.v2 helm.sh/release.v1 1
sh.helm.release.v1.prometheus-stack.v3 helm.sh/release.v1 1
sh.helm.release.v1.prometheus-stack.v3 helm.sh/release.v1 1
sh.helm.release.v1.prometheus-stack.v4 helm.sh/release.v1 1
sh.helm.release.v1.prometheus-stack.v5 helm.sh/release.v1 1
sh.helm.release.v1.prometheus-stack.v6 helm.sh/release.v1 1
# alertmanger 변경사항 로그
kubectl logs -f -n monitoring alertmanager-prometheus-stack-kube-prom-alertmanager-0 --tail=0
ts=2023-10-20T09:29:07.104Z caller=coordinator.go:113 level=info component=configuration msg="Loading configuration file" file=/etc/alertmanager/config_out/alertmanager.env.yaml
ts=2023-10-20T09:29:07.107Z caller=coordinator.go:126 level=info component=configuration msg="Completed loading of configuration file" file=/etc/alertmanager/config_out/alertmanager.env.yaml이제, 웹 화면의 Status > alert창에서 pod:container_cpu_usage:sum 프로메테우스 룰이 생성된 것을 볼 수 있다.
프로메테우스 오퍼레이터는 PrometheusRule과 같은 커스텀 리소스를 감지하고 애플리케이션을 재기동하지 않고도 프로메테우스의 룰이 자동으로 반영이 되는 것을 볼 수 있다.
새로운 메트릭이 추가될 때마다 configmap 설정에서 JOB을 추가하는 불필요한 반복발생이 발생하는 뿐만 아니라,
helm upgrade 시 cm이 초기화될 가능성이나 휴먼에러 등 다양한 문제점들을 방지할 수 있을 뿐만 아니라 쿠버네티스 리소스이기 때문에 rest api까지 활용할 수 있다.
기타
Operator HUB
OperatorHub.io | The registry for Kubernetes Operators
operatorhub.io
다양한 오퍼레이터를 모아둔 허브로 성숙도가 3 레벨 이상의 오퍼레이터를 실무에서 사용하도록 하자.
오퍼레이터 개발
KUDO, kubebuilder, Operator Framework 등 다양한 오퍼레이터를 개발하는 필요한 프레임워크들이 있으며
Custom Resource나 Controller를 개발하는 데 있어 도움을 준다. 기회가 된다면 Operator Framework를 이용해서 꼭 Operator 개발도 도전해 보자.
'Kubernetes > Database Operator' 카테고리의 다른 글
| Kafka Operator(Strimzi) - DOIK2_5주차 (0) | 2023.11.19 |
|---|---|
| MongoDB Operator - Percona Operator for MongoDB(PSMDB) - DOIK 4주차 (3) | 2023.11.12 |
| PostgreSQL Operator - CloudNative PostgreSQL - DOIK2_3주차 (0) | 2023.11.05 |
| 쿠버네티스 MySQL InnoDB Cluster - DOIK2_2주차 2 (2) | 2023.10.28 |
| 쿠버네티스 스테이트풀셋이란? (Kubernetes Statefulset) - DOIK2_1주차 (3) | 2023.10.21 |
