[Kubernetes] 쿠버네티스에서 POD(파드)? 그리고 POD 생성하기

 

l  Kubernetes

 

파드(Pod) 쿠버네티스에서 생성하고 관리할 있는 배포 가능한 가장 작은 컴퓨팅 단위이다. 도커가 가장 일반적으로 알려진 컨테이너 런타임이지만, 쿠버네티스는 도커 외에도 다양한 컨테이너 런타임을 지원한다.

 

파드는 하나 이상의 컨테이너의 그룹이며 스토리지 네트워크를 공유하고, 해당 컨테이너를 구동하는 방식에 대한 명세를 갖는다. 파드의 컨텐츠는 항상 함께 배치되고, 스케줄되며, 공유 컨텍스트에서 실행된다. , 파드는 공유 네임스페이스와 공유 파일시스템 볼륨이 있는 컨테이너들의 집합과 비슷하다.

 

파드는 애플리케이션의 "논리 호스트" 모델링한다. 여기에는 상대적으로 밀접하게 결합된 하나 이상의 애플리케이션 컨테이너가 포함된다. 클라우드가 아닌 컨텍스트에서, 동일한 물리 또는 가상 머신에서 실행되는 애플리케이션은 동일한 논리 호스트에서 실행되는 클라우드 애플리케이션과 비슷하다.

 

애플리케이션 컨테이너와 마찬가지로, 파드에는 파드 시작 중에 실행되는 초기화 컨테이너가 포함될 있다. 클러스터가 제공하는 경우, 디버깅을 위해 임시 컨테이너를 삽입할 수도 있다. 쿠버네티스에서는 이러한 파드를 생성하기 위한 방법으로 kubectl run, kubectl create, kubectl apply 3가지가 있다. 각의 특징에 대해서 알아본다.

 

[kubectl run]

kubectl run kubernetes 클러스터에서 파드나 작업을 생성하는 명령어이다. 가장 간단하게 pod 만드는 방식이며, 실행 명령어 뒤에 각종 옵션 정보를 입력해서 생성한다. 가장 간편한 실행 방법인 반면 입력 정보가 남지 않기 때문에 재실행 문제가 발생했을 원인을 찾거나 해결 방법을 공유하는 등의 어려움이 있다. 일반적인 개발 단계에서 간편하게 pod 생성할 유용하지만 많은 옵션을 함께 사용해야 경우 모든 명령어를 입력해야하기 때문에, yaml 작성하여 사용하는 것이 일반적이다. 기본 구조는 아래와 같다.

Kubectl run [파드이름] –image=[이미지 이름]

 

아래 예시는 파드 생성시 실행할 이미지를 지정한다.

kubectl run nginx --image=nginx

 

아래 예시는 실행할 파드의 개수를 지정한다. Nginx 이미지를 사용하여 3개의 파드를 생성한다. 파드가 중간에 삭제되면 지정한 개수만큼 파드가 유지되도록 파드가 자동 생성된다.

kubectl run nginx --image=nginx --replicas=3

 

아래 예시는 파드를 생성할 포트 번호를 노출시킨다.

kubectl run nginx --image=nginx --port=80

 

아래 예시는 파드를 생성할 다양한 환경변수를 대입하여 파드를 실행한다.

kubectl run my-proxysql --image=my-proxysql --port=6033 --image-pull-policy=Never --restart=Never --env PROXY_ADMIN_PWD=pwd --env PROXY_ADMIN_ID=id

 

 

[kubectl create]

Kubectl create 명령은 kubernetes에서 새로운 리소스를 생성할 사용한다. 명령을 사용하면 yaml파일을 생성하지 않고도 명령어 자체에서 리소스를 생성할 있다. 기본구조는 아래와 같다.

kubectl create [리소스 종류] [리소스 이름]

 

아래 예시는 Nginx 이미지를 사용하는 my-nginx라는 pod 리소스를 생성한다.

kubectl create pod my-nginx --image=nginx

 

아래 예시는 Nginx 이미지를 사용하는 my-deployment 이름을 가진 Deployment 리소스를 생성한다.

Kubectl create deployment my-deployment --image=nginx

 

아래 예시는 80포트를 8080으로 매핑하는 my-service라는 이름의 ClusterIP 서비스 리소스를 생성한다.

Kubectl create service clusterip my-service --tcp=80:8080

 

아래 예시는 key1=value1, key2=value2 데이터를 가진 my-config 이름을 가진 ConfigMap 리소스를 생성한다.

kubectl create configmap my-config --from-literal=key1=value1 --from-literal=key2=value2

 

아래 예시는 password=1234데이터를 가진 my-secret 이름의 secret 리소스를 생성한다.

Kubectl create secret generic my-secret --from-literal=password=1234

 

아래 예시는 리소스를 생성하지 않고 생성 결과만 미리 확인한다.

kubectl create deployment my-deployment --image=nginx --dry-run

 

아래 예시는 파일(yaml 또는 json) 사용하여 리소스를 생성한다.

kubectl create -f test.yaml

 

아래 예시는 리소스가 생성될 네임스페이스를 지정한다.

Kubectl create deployment my-deployment --image=nginx -n my-namespace

 

아래 예시는 컨테이너의 재시작 정책을 지정한다. 상태는 Always, OnFailure, Never 하나를 사용한다.

Kubectl create pod my-pod --image=nginx --restart-policy=OnFailure

 

 

[kubectl apply]

kubectl apply kubectl create 동일하지만 가장 차이점은 기존에 동일한 pod 없다면 새로운 pod 생성하고, 이미 동일한 pod 존재하는 경우 기존 config 비교하여 수정된 부분만 업데이트 한다.

 

 

[kubectl delete]

파드나 리소스를 삭제하기 위해서는 kubectl delete 명령을 사용한다. 기본 구조는 아래와 같다.

Kubectl delete [리소스 유형] [리소스 이름]

 

아래 예시는 nginx라는 파드를 삭제한다.

kubectl delete pod nginx

 

삭제할 다양한 옵션을 함께 사용할 있다.

l  --all : 모든 리소스를 삭제

l  --force : 강제로 삭제

l  ---grace-period=<second> : 대기시간() 이후 삭제 설정

l  --timeout=<second> : 명령이 실행될 대기할 최대 시간() 설정

 

 

 

2023-09-08 / Sungwook Kang / https://sungwookkang.com

 

 

Kubernetes, 쿠버네티스, pod, 파드, kubectl, create, delete, apply, 파드생성, 리소스 생성

[Kubernetes] 쿠버네티스에서 파드 생성시 프라이빗 레지스트리 이미지 사용하기

 

l  Kubernetes

 

Kubernetes 환경에서 pod 생성할 Private Registry에서 이미지를 다운받아 실행하는 방법에 대해서 알아본다.

 

현재 구성되어 있는 실습 환경은 MAC OS + PODMAN + MINIKUBE이다. 일반적으로 많이 사용하는 docker 환경은 아니지만 사용법이 거의 유사하기 때문에 따라하는데 크게 문제가 없으리라 생각한다. Minikube 설치 Podman 설치는 공식 문서에 쉽게 설명되어 있기 때문에 여기에서는 다루지 않는다.

 

l  Podman Installation Instructions : https://podman.io/docs/installation

l  minikube start : https://minikube.sigs.k8s.io/docs/start/

 

실습 시나리오는 아래와 같다.

1.       Dockerfile 작성

2.       컨테이너 이미지 빌드

3.       Docker Hub 개인 저장소에 이미지 푸시

4.       쿠버네티스에서 프라이빗 시크릿키 생성

5.       YAML 파일 작성

6.       Pod 생성

 

사용자 커스텀 이미지를 만들기 위해 Dockerfile 작성한다. Dockerfile 작성에 관한 방법은 다른 문서를 참고한다. 도커 허브의 공식 이미지 저장소에서는 Dockerfile 대한 샘플코드를 제공한다. 아래는 proxysql 공식 저장소이다.

l   https://hub.docker.com/r/proxysql/proxysql

 

 

 

 Dockerfile 작성이 완료되었으면, 이미지를 빌드 한다. Podman 명령어는 도커 명령어와 거의 유사하기 때문에 어려움 없이 사용할 있다. 아래 스크립트는 Dockerfile 빌드하여 컨테이너 이미지를 생성하고, 현재 생성되어 있는 이미지를 확인한다.

podman build -t proxysql-sw:1.0.0 .
 
podman images

 

 

 

podman에서는 도커 레지스트리에 push하기 위해 로그인 과정이 필요하다. 도커 허브의 로그인은 아래와 같은 명령어를 사용한다. 로그인은 ID, 패스워드로 인증한다.

podman login docker.io

 

 

 

이미지를 푸시 하기 위해서는 이미지 ID 필요하다. Podman images명령을 사용하여 확인한 이미지ID 사용하여 도커 허브의 프라이빗 레지스트리로 푸시 한다.

podman push 561f3e4999fddocker.io/<개인저장소 경로>

 

 

쿠버네티스에서 파드 생성시 사용할 프라이빗 레지스트리에 대한 시크릿 키를 생성한다. 시크릿 키에 대한 생성은 여러 방법이 있지만 여기에서는 커맨드 라인에서 자격증명을 통한 시크릿 키를 생성한다. 아래 예제에서는 시크릿 이름은 regcred 생성한다.

kubectl create secret docker-registry regcred --docker-server=<your-registry-server> --docker-username=<your-name> --docker-password=<your-pword> --docker-email=<your-email>

 

l   <your-registry-server> : 프라이빗 도커 저장소의 FQDN 주소로, 도커허브(DockerHub) https://index.docker.io/v1/ 사용

l   <your-name> : 도커 사용자의 계정

l   <your-pword> : 도커 사용자의 비밀번호

l   <your-email> : 도커 사용자의 이메일 주소

 

키가 정상적으로 생성되었는지는 아래 명령으로 확인 가능하다. 명령을 실행하면 키에 대한 자세한 정보를 확인할 있다.

kubectl get secret regcred --output=yaml

 

 

쿠버네티스에서 파드 생성시 사용할 YAML 파일을 작성한다. YAML에서 시크릿 키를 사용할 있도록 imagePullSecrets 항목에서 시크릿키 이름을 입력한다.

apiVersion: v1
kind: Pod
metadata:
  name: private-reg
spec:
  containers:
  - name: private-reg-container
    image: <your-private-image>
  imagePullSecrets:
  - name: regcred

 

 

YAML파일을 사용하여 쿠버네티스 파드를 생성한다.

kubectl apply -f my-private-reg-pod.yaml

 

 

도커허브의 개인 저장소 이미지를 사용하여 파드가 정상적으로 생성된 것을 확인할 있다.

kubectl get pod 

 

 

 

지금까지 도커 허브의 프라이빗 레지스트리에서 이미지를 받아 파드를 생성하는 방법에 대해서 알아보았다. 원래 나의 목적은 로컬( 컴퓨터)에서 이미지를 빌드한 다음 로컬 저장소의 이미지를 사용하여 쿠버네티스 파드를 생성하려고 하였는데, podman에서 생성한 이미지를 minikube에서 찾지 못하여 (정확히는 내가 모르는 ) 도커 허브를 사용하는 방향으로 실습하였다. 이후 작업으로 로컬 저장소에서 파드를 생성하는 방법을 추가적으로 알아볼 예정이다.

 

 

[참고자료]

l  Podman Installation Instructions : https://podman.io/docs/installation

l  minikube start : https://minikube.sigs.k8s.io/docs/start/

l  docker hub : https://hub.docker.com/

l  프라이빗 레지스트리에서 이미지 받아오기 : https://kubernetes.io/ko/docs/tasks/configure-pod-container/pull-image-private-registry/

 

 

 

 

2023-08-09 / Sungwook Kang / https://sungwookkang.com

 

 

쿠버네티스, Kubernetes, 미니쿠베, minikube, 도커, 도커허브, 컨테이너, 도커파일, dockerfile, yaml, 도커 레지스트리, 프라이빗 레지스트리, podman, 파드맨, 도커빌드. 이미지빌드

[Kubernetes] vagrant 환경에서 Kubernetes 클러스터 구성하기

 

l  Kubernetes on vagrnat

 

vagrant에서 Kubernetes 클러스터를 구성하는 방법에 대해서 알아본다. 클러스터 구성환경은 virtualbox centos8 운영체제의 가상머신을 3 생성하고, 머신은 master, woker1, woker2 구성한다.

 

l  vagrant 활용한 개발 환경 구축하기 : https://sungwookkang.com/1523

l  vagrant 가상머신 생성하기 : https://sungwookkang.com/1524

 

호스트이름 IP 역할
k8s-master 192.168.10 Master node
k8s-worker1 192..168.11 Worker node
k8s-worker2 192.168.12 Worker node

 

l   Kubernetes Version : v1.27.3

l   Docker Version : 24.0.2, build cb74dfc

 

vagrnatfile 구성 Kubernetes 구성에 사용할 스크립트 파일은 아래 깃헙을 참고 한다.

l   https://github.com/sqlmvp/k8s-cluster-vagrant

 

 

vagrant up 완료되면 아래와 같이 클러스터가 생성되어 ready 상태로 동작되는 것을 확인할 있다.

 

 

2023-07-03 / Sungwook Kang / https://sungwookkang.com

 

 

vagrant, 베이그랜트, 쿠버네티스, Kubernetes,

[Prometheus] Prometheus Thanos 아키텍처 살펴보기

 

l  Prometheous with Thanos

 

Thanos(타노스) CNCF(https://www.cncf.io/) 인큐베이팅 프로젝트로, 프로메테우스의 확장성과 내구성을 향상시키기 위한 오픈소스 프로젝트이다.

l  Prometheus 확장 내구성을 위한 다양한 구성 방법 : https://sqlmvp.tistory.com/1521

 

Thanos Prometheus 2.0 스토리지 형식을 활용하여 빠른 쿼리 대기 시간을 유지하면서 모든 개체 스토리지에 메트릭 데이터를 효율적으로 저장한다. 또한 운영중인 프로메테우스 서버의 데이터를 통합 저장 외부 저장소에 데이터를 저장할 있기 때문에 보관 기간에 제한이 없고, 단일 쿼리로 전체 프로메테우스 서버의 데이터를 쿼리 있다. 장점을 크게 정리하면 아래와 같이 정리할 있다.

l  Long-term Storage : 원격 스토리지에 데이터를 안정적으로 저장하여 장기적인 데이터 보존을 가능

l  Global Query : 여러 원격 스토리지에서 데이터를 통합하여 조회할 있는 Global Query 기능을 제공하여 분산된 데이터에 대해 단일 쿼리를 실행할 있어 데이터 분석과 모니터링에 유용

l  HA(고가용성) : 원격 스토리지에 데이터를 복제하여 프로메테우스 서버 하나가 장애가 발생하더라도 데이터의 고가용성을 보장

 

타노스는 Sidecar, Query Gateway, Store Gateway, Compactor, Ruler, Receiver라는 6개의 컴포넌트로 이루어져 있다.  

 

l   Thanos Sidecar

ü  Prometheus 함께 하나의 POD 배포되어 기존 프로메테우스 서버와 통합

ü  Prometheus 데이터를 Object Storage 버킷에 백업하고 다른 Thanos 구성 요소가 gRPC API 통해 Sidecar 연결된 Prometheus 인스턴스에 액세스

ü  2시간마다 프로메테우스 메트릭을 객체 스토리지로 보냄

ü  사이드카는 Prometheus 끝점을 사용. --web.enable-lifecycle 플래그로 활성화

l   Thanos Query Gateway

ü  PromQL 처리하는 부분으로 필요한 Prometheus sidecar 연결

ü  질의를 Store (Store API), Sidecar등으로 전달하고 수집

ü  타노스의 전역 쿼리 계층(Global query layer) 사용하여 모든 프로메테우스 인스턴스에 대해 PromQL 사용하여 한번에 조회가능

ü  쿼리 구성 요소는 상태 비저장이며 수평 확장이 가능하며 여러 복제본과 함께 배포 가능

ü  사이드카에 연결되면 주어진 PromQL 쿼리를 위해 어떤 프로메테우스 서버에 접속해야 하는지 자동으로 감지

ü  단일 Thanos 쿼리 엔드 포인트에서 여러 메트릭 백엔드를 집계하고 중복 제거하는 기능을 제공

l   Thanos Store Gateway

ü  Store 같은 개념이며, API Gateway 역할을 하며 오브젝트 스토리지에 접근하는 모든 작업은 Store API 사용

ü  Query, Receive, Ruler 등에 존재

ü  사이드카와 동일한 gRPC 데이터 API 구성되어 있지만 개체 저장소 버킷에서 찾을 있는 데이터로 백업

ü  스토어 게이트웨이는 오브젝트 스토리지 데이터에 대한 기본 정보를 캐싱 하기위해 소량의 디스크 공간을 차지 (타노스 쿼리 저장소 역할)

l   Thanos Compactor

ü  오브젝트 스토리지에 저장된 블록 데이터를 압축하여 저장공간 최적화 작업 진행

ü  개체 저장소를 간단히 스캔하고 필요한 경우 압축을 처리

ü  동시에 쿼리 속도를 높이기 위해 다운 샘플링된 데이터 복세본을 만드는 역할 수행

ü  주기적 배치 작업으로 실행하거나 데이터를 빨리 압축하기 위해 상시 실행 상태로 있음

ü  데이터 처리를 위해 100GB ~ 300GB 로컬 디스크 공간을 제공하는 것이 좋음  

ü  동시성이 보장되지 않으므로 전체 클러스터에서 싱글톤 형식으로 배포하고 버킷에서 데이터를 수동으로 수정할 실행하면 안됨

l   Thanos Ruler

ü  타노스 사이드카가 적용된 프로메테우스의 보존기간이 충분하지 않거나 전체 보기가 필요한 알림 또는 규칙 구성

ü  Thanos 쿼리 구성 요소에 연결하고 Prometheus Alert Record 규칙을 평가

ü  Prometheus Alert Manager 사용하여 Alert 트리거 있음

l   Thanos Receiver

ü  프로메테우스 서버에서 remote_write 통해 메트릭 데이터 수신할 사용

ü  기본 2시간 단위로 TSDB 블록을 만들어 오브젝트 스토리지에 저장

 

 

아키텍처를 살펴보고 요악하면 다음과 같은 활용을 구상해 있다.

l   다수의 프로메테우스 서버를 Global Query view기능을 통해 하나의 인터페이스로 조회 활용

l   Global Query view, 메트릭 duplication 기능으로 프로메테우스 서버가 장애나더라도 서비스 단절이나 데이터 손실 방지

l   외부 저장소를 활용할 있으므로 데이터 크기에 따른 스토리지 성능 하락에 대비할 있고, 메트릭 데이터를 영구 보관할 있으므로 다양하게 활용 가능



 

[참고자료]

l   Thanos공식 문서 : https://thanos.io/v0.6/thanos/getting-started.md/

l   Multi-Cluster Monitoring with Thanos : https://particule.io/en/blog/thanos-monitoring/

 

 

 

2023-06-29 / Sungwook Kang / https://sungwookkang.com

 

 

프로메테우스, Prometheus, 모니터링 시스템, Grafana, 그라파나, DevOps, 데브옵스, Kubernetes, 쿠버네티스, 타노스, Thanos, CNCF

[Prometheus] Prometheus 확장 내구성을 위한 다양한 구성 방법들

 

l  Prometheous with Thanos

 

Prometheus(프로메테우스) 모니터링 시스템은 오픈 소스 기반의 모니터링 시스템으로 Kubernetes(쿠버네티스) 활성화 함께 많이 사용되고 있다.  프로메테우스는 구조가 간단하며, 운영이 쉽고 강력한 쿼리 기능을 가지고 있다. 간단한 텍스트 형식으로 메트릭 데이터를 쉽게 익스포트 있으며, key-value 형식의 데이터 모델을 사용한다. 수집된 데이터는 Grafana(그라파나) 통해 시각화를 제공한다.

 

l  Prometheus 구조 개념 : https://sqlmvp.tistory.com/1520

 

프로메테우스의 가장 약점은 확장성과 가용성이다. 프로메테우스는 클러스터가 지원되지 않는 독립형 서비스로, 프로메테우스 서버 장애시 메트릭을 수집할 없다는 것이다. 프로메테우스 서버의 장애시간 또는 재설정 등으로 서버 또는 서비스가 재시작 동안 타켓에 대한 모니터링을 없다면 이는 서비스를 운영하는데 매우 리스크이다.  이러한 문제를 해결하기 위해 여러가지 프로메테우스 서버 구성에 대한 아키텍처를 생각해 있다.

 

[프로메테우스N 구성으로 타켓 서버 중복 모니터링]

대이상의 프로메테우스 서버를 구성하여, 프로메테우스 서버에서 타겟 서버를 교차해서 메트릭을 수집하는 방식이다.

 

이러한 방식으로 구성할 경우 관리 해야하는 프로메테우스 서버도 증가하지만, 모니터링 대상이 되는 타겟 서버 입장에서도 여러 프로메테우스 서버로부터 요청되는 메트릭 데이터를 수집 전달하기 위해 오버헤드가 발생한다. 또한 프로메테우스로 수집된 데이터를 분석할 때에도, 특정 시점에 장애가 번갈아 발생시, 데이터가 한쪽에만 있게 되므로 중앙에서 한번에 분석하기 불편한 단점이 있다.

 

 

[프로메테우스 Federation 구성]

프로메테우스 서버를 여러 구성하고, 프로메테우스 서버가 다른 프로메테우스 서버로 요청하여 데이터를 수집할 있다.

l  Hierarchical Federation 구성은 프로메테우스 서버 사이에 계층을 두고 Tree 형태로 Federation 구성하는 방법이다. 부모 프로메테우스는 자식 프로메테우스들의 통합 메트릭 제공 통합 메트릭을 기반으로 알람을 제공하는 용도로 사용할 있다.

l  Cross-service Federation 구성은 동일 레벨의 프로메테우스 서버사이를 Federation으로 구성하는 방법이다.

 

 

 

Federation으로 구성할 경우, 프로메테우스 서버는 타겟 서버로부터 일정 주기로 데이터를 수집하고 저장하고, 부모(중앙) 프로메테우스 서버는 프로메테우스 서버로부터 저장된 데이터를 별도의 주기로 수집할 있어, 데이터양이 많을 , 평균값이나 해상도 등을 조정할 있다. 예를들면 프로메테우스 서버는 10 단위로 수집하고, 중앙 프로메테우스는 1 단위로 하위 프로메테우스 서버로 요청하여 평균값 등을 이용할 있다. 하지만 프로메테우스 서버 장애 데이터 유실, 데이터 증가로 인한 중앙 프로메테우스 서버의 오버헤드 증가 문제가 있으므로 일정 규모 이상에서는 적용하기 힘든 부분이 있다.

 

 

[프로메테우스 Thanos 구성]

Thanos 프로메테우스의 확장성과 내구성을 향상 시키기 위한 오픈소스 프로젝트로, 프로메테우스의 메트릭 데이터를 분산된 원격 스토리지에 저장하고 조회할 있는 기능을 제공한다. 아래 그림에서 서드파티 스토리지로 데이터를 저장하기 위한 Adapter 역할이 Thanos 기능이다.

l   Thanos 사용하여 구성 경우 아래와 같은 장점이 있다.

l   Long-term Storage: 원격 스토리지에 데이터를 안정적으로 저장하여 장기적인 데이터 보존을 가능

l   Global Query: 여러 원격 스토리지에서 데이터를 통합하여 조회할 있는 Global Query 기능을 제공하여 분산된 데이터에 대해 단일 쿼리를 실행할 있어 데이터 분석과 모니터링에 유용

l   HA(고가용성): 원격 스토리지에 데이터를 복제하여 프로메테우스 서버 하나가 장애가 발생하더라도 데이터의 고가용성을 보장

 

프로메테우스 Thanos 구성으로 데이터를 수집하여 S3 저장하는 구성하는 구조를 만든다면 아래와 같은 형식으로 아키텍처를 디자인 있다.

1.          Prometheus Thanos 사이드카를 활성화

2.          Sidecar 대화할 있는 기능이 있는 Thanos Querier 배포

3.          Thanos Sidecar S3 버킷에 Prometheus 메트릭을 업로드할 있는지 확인

4.          Thanos Store 배포하여 장기 스토리지( 경우 S3 버킷) 저장된 메트릭 데이터를 검색

5.          데이터 압축 다운 샘플링을 위해 Thanos Compactor 설정

 

 

다양한 구성으로 프로메테우스의 단점인 확장 내구성을 보완하는 방법에 대해서 살펴보았다. 여러 방식이 있겠지만 현재 대규모 서비스에서는 Thanos 구성이 가장 많이 사용되는 하다. Thanos 아키텍처 자세한 내용은 다른 포스트에서 다뤄볼 예정이다. 모니터링을 구성하는데 있어서 정답은 없다. 항상 우리가 가진 리소스 환경에서 가장 최선의 방법을 찾는 것이 중요할 하다.

 

참고자료 :

l   https://wikitech.wikimedia.org/wiki/File:Prometheus_federation.png

l   https://prometheus.io/docs/prometheus/latest/federation/

l   https://www.robustperception.io/federation-what-is-it-good-for/

l   https://aws.amazon.com/blogs/opensource/improving-ha-and-long-term-storage-for-prometheus-using-thanos-on-eks-with-s3/

l   https://thanos.io/v0.6/thanos/getting-started.md/

l   https://particule.io/en/blog/thanos-monitoring/

 

 

 

2023-06-28 / Sungwook Kang / https://sungwookkang.com

 

 

프로메테우스, Prometheus, 모니터링 시스템, Grafana, 그라파나, DevOps, 데브옵스, Kubernetes, 쿠버네티스

[Prometheus] Prometheus 구조 개념

 

l  Prometheous

 

Prometheus(프로메테우스) 모니터링 시스템은 오픈 소스 기반의 모니터링 시스템으로 Kubernetes(쿠버네티스) 활성화 함께 많이 사용되고 있다. 물론 쿠버네티스 환경 외에도 일반적인 온프레미스 환경에서도 사용이 가능하여 많은 인기를 끌고 있다.  현재 CNCF(Cloud Native Computing Foundation) 소속되어 있다.

 

프로메테우스는 구조가 간단하며, 운영이 쉽고 강력한 쿼리 기능을 가지고 있다. 간단한 텍스트 형식으로 메트릭 데이터를 쉽게 익스포트 있으며, key-value 형식의 데이터 모델을 사용한다. 수집된 데이터는 Grafana(그라파나) 통해 시각화를 제공한다.

 

프로메테우스는 순전히 숫자로 시계열을 기록하는 적합하다. 기계 중심 모니터링과 고도로 동적인 서비스 지향 아키텍처 모니터링 모두에 적합하다. 프로메테우스는 중단 중에 신속하게 문제를 진단할 있도록 하는 시스템으로서 안정성을 위해 설계되어있으며, 프로메테우스 서버는 독립형으로 동작하며, 네트워크 스토리지 또는 기타 원격 서비스에 의존하지 않는다.

 

대부분의 모니터링 시스템은 타켓 서버(모니터링 대상 서버) 에이전트를 설치하여 중앙의 모니터링 수집 서버로 push(푸시) 하는 방식인데, 프로메테우스는 pull() 방식을 사용하여 데이터를 수집한다. 모니터링 대상 서버에 exporter(익스포터)라는 에이전트가 실행되어 있으면, 주기적으로 에이전트에 접속하여 데이터를 가져오는 방식이다.

 

l  Jobs / Exporter : 프로메테우스가 모니터링 데이터를 가져갈 있도록 타겟 서버에 설치되는 에이전트 이다. 서버 상태를 나타내는 Node exporter, DB 상태를 나타내는 SQL Exporter 다양한 커스텀 익스포터들이 개발되어 사용되고 있다. 익스포터 자체는 특별한 기능을 수행하지 않는다. 프로메테우스의 요청이 있을 시점에 메트릭을 수집하여 http get 방식으로 리턴한다. 히스토리를 저장하지 않기 때문에 시점의 값만 있다.

l  Pushgateway : Pushgateway는보안상의 이유로 프로메테우스가 직접 익스포터에 연결 없을 , Proxy Forwarding 사용하여 메트릭 데이터를 수집할 있도록 해주는 서비스이다. Application pushgateway 메트릭 데이터를 푸쉬하면, 프로메테우스 서버가 pushgateway 접근해 메트릭 데이터를 하는 방식으로 동작한다.

l  Alertmanager: Alertmanagr 메트릭에 대한 특정 룰을 설정하고 규칙을 위반하는 사항에 대해 알람을 전송하는 역할을 한다. 예를들면 “CPU 사용률이 50% 이상일때 알람을 보낸다.” 라고 룰을 설정하면, 수집된 CPU 메트릭의 값이 50 이상일때 알람을 발송한다.

l  Service discovery : 프로메테우스는 기본적으로 방식을 사용하여 모니터링을 하기 때문에 모니터링 대상 서버의 목록을 유지하고 있어야 한다. 쿠버네티스 환경처럼 오토스케일이 발생할 경우, 타겟 서버의 IP 가변적이어서 수집할 서버의 목록을 확인할 없는 경우가 많다. 이런 경우 모니터링 대상 목록을 관리하기 위해 서비스 디스커버리를 사용하여 유지한다.

l  Retrieval : 익스포터로 부터 주기적으로 메트릭을 수집하는 모듈이며, 서비스 디스커버리 시스템으로 부터 모니터링 대상 목록을 받아오는 역할도 수행하는 컴포넌트이다.

l  HDD/SDD : 수집된 데이터는 프로메테우스 서버의 로컬 메모리와 디스크에 저장된다. 단순하고 사용이 쉬운 방면, 별도의 데이터베이스가 없으므로 확장이 불가능하다.

l  Data visualization : 저장된 메트릭은 PromQL 쿼리 언어를 사용하여 조회가 가능하다. 또한 외부 API 프로메테우스 웹콘솔을 사용하여 visualization 구성할 있다.

 

프로메테우스 서버는 독립적인 구조로 운영되기 때문에, 많은 수의 모니터링 서버에서 대량의 메트릭을 수집할 프로메테우스 서버의 시스템 리소스가 부족할 경우 확장이 불가능한 구조로 되어 있다. 또한 프로메테우스 서버가 다운되거나 설정 변경으로 인한 재시작시 메트릭이 저장되지 않고 유실되는 문제가 있다. 이러한 문제를 수정하기 위해 프로메테우스 서버를 다양한 형태로 구성 운영하기 위한 노하우가 필요 하다. 부분은 다른 포스트에서 다루어 본다.

 

 

 

참고자료 :

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

 

 

2023-06-28 / Sungwook Kang / https://sungwookkang.com

 

 

프로메테우스, Prometheus, 모니터링 시스템, Grafana, 그라파나, DevOps, 데브옵스, Kubernetes, 쿠버네티스

Kubernetes 장점

 

·       Version :

 

 쿠버네티스(Kubernetes) 환경에서는 컨테이너에 애플리케이션에 필요한 모든 항목이 포함되어 있기 때문에 시스템 관리자가 애플리케이션을 실행하기 위해 아무것도 설치할 필요가 없다.

·       애플리케이션 배포 단순화 : 쿠버네티스는 모든 워커 노드를 단일 플랫폼으로 제공하므로 애플리케이션 개발자는 자체적으로 배포할 있으며 클러스터를 구성하는 서버에 대해서 필요가 없다. 특히 특정 컨테이너가  SSD에서만 실행되거나 또는 HDD에서만 실행되어야 하는  경우처럼 특정 리소스가 필요한 경우 쿠버네티스 노드에서 필요한 리소스가 있는 노드를 선택해서 배포할 있다.

·       효율적인 하드웨어 활용 : 쿠버네티스환경에서 애플리케이션을 배포,실행하면 애플리케이션 리소스 요구사항에 따라 사용 가능한 가장 적합한 노드가 선택되어 할당된다. 또한 특정 노드에 애플리케이션을 종속시키지 않는다면 클러스터를 자유럽게 이동할 있어 리소스 가용 상태에 따라 자동으로 이동하거나 매치하여 사용할 있다.

·       자동 복구 모니터링 : 특정 클러스터에 종속되지 않으면 자유롭게 클러스터를 이동할 있기 때문에 이러한 장점으로 인해 모니터링 중에 특정 노드에 장애가 발생하면 자동으로 다른 노드에 애플리케이션이 재배치 되어 실행되기 때문에 야간이나 장애 발생시 즉시 대응할 필요가 없다.

·     오토스케일링 : 쿠버네티스는 애플리케이션에서 사용하는 리소스를 모니터링 하고 애플리케이션에서 실행되는 인스턴스 수를 조정하도록 지시할 있다.

·       개발 환경 단순화 : 애플리케이션이 개발 운영 환경이 동일하기 때문에 개발자는 본인 컴퓨터에서 개발하고 버그를 수정하고, 테스트한 완성된 애플리케이션 환경 그대로 운영 환경에서 실행할수 있다.

 

 

2021-07-30 / Sungwook Kang / https://sungwookkang.com

 

 

Kubernetes, 쿠버네티스

Kubernetes 마스터 노드, 워커 노드

 

·       Version :

 

 쿠버네티스(Kubernetes) 클러스터에서 마스터 노드는 전체 쿠버네티스 시스템을 관리하고 통제하는 쿠버네티스 컨트롤 플레인을 관장한다. 워커 노드는 실제 배포하고자 하는 애플리케이션 실행을 담당한다.

마스터 노드(컨트롤 플레인)에서는 클러스터를 관리하고 클러스터의 기능을 실행한다. 단일 마스터 노드에서 실행하거나 여러 노드로 분할 복제되어 고가용성을 보장할 있는 여러 구성요소로 구성 있다.

·       API Server : 사용자와 컨트롤 플레인과 통신하는 쿠버네티스 API

·       Scheduler : 애플리케이션을 예약하는 스케줄러로, 배포 가능한 구성 요서에 워커 노드 할당을 담당

·       Control Manager : 구성 요소 복제, 워커 노드 추적, 노드 장애 처리 클러스터 기능을 실행

·       etcd : 클러스터 구성을 저장하는 분산 데이터 스토리지  

 

워커 노드는 컨테이너화된 애플리케이션을 실행하는 시스템으로 서비스 실행, 모니터링을 제공한다.

·       Kubelet : API 서버와 통신하고 노드에서 컨테이너를 관리

·       Kube-proxy : 애플리케이션 구성 요소 간에 네트워크 트래픽을 분산하는 쿠버네티스 서비스 프록시

 

 

2021-07-28 / Sungwook Kang / https://sungwookkang.com

 

 

Kubernetes, 쿠버네티스, 마스터 노드, 워커 노드, 컨트롤 플레인, Control Plane

'SW Engineering > DevOps, SRE' 카테고리의 다른 글

[Prometheus] Prometheus 구조 및 개념  (0) 2023.06.28
Kubernetes 장점  (0) 2021.07.31
SRE (Site Reliability Engineering) 역할  (0) 2020.05.14
SRE (Site Reliability Engineering)  (0) 2020.05.11
Docker Network  (0) 2019.03.27

+ Recent posts