Ninano Tech Blog

prometheus agent를 사용하려면, 수집하려는 클러스터에 각각 prometheus를 agent 모드로 설치하고

별도의 클러스터에 prometheus 를 server 모드로 설치한다.

이때 grafana 도 함께 설치하여 수집한 지표를 대시보드로 구성하여 모니터링 한다.

이 예제는 AWS EKS 기반으로 작성하였다.

먼저 promethues server와 grafana를 설치한다.

1. promethues server 설치

프로메테우스는 아래의 헬름차트 중 선택하여 구성할 수 있다.

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

• operator 가 설정되어 있는 헬름차트
• Kubernetes 사용자 지정 리소스 를 사용하여 Prometheus, Alertmanager 및 관련 모니터링 구성 요소의 배포 및 구성을 단순화

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

• Prometheus 및 Prometheus Operator를 기반으로 하는 전체 클러스터 모니터링 스택에 대한 예제 구성을 제공
•  여러 Prometheus 및 Alertmanager 인스턴스의 배포, 노드 메트릭 수집을 위한 node_exporter와 같은 메트릭 내보내기, Prometheus를 다양한 메트릭 엔드포인트에 연결하는 스크랩 대상 구성, 클러스터의 잠재적인 문제 알림을 위한 예제 경고 규칙이 포함

- community helm chart : https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack

• kube-prometheus와 유사한 기능 세트를 제공
• Prometheus 커뮤니티에서 관리

community helm chart를 사용하여 prometheus 서버와 grafana를 구성한다.

#get helm ropository info
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

환경에 맞도록 value.yaml 파일을 작성한다.

https://github.com/prometheus-community/helm-charts/blob/main/charts/prometheus/values.yaml

파일을 참고하여 설정에 맞도록 value.yaml 을 작성한다.

SSL이 미적용된 AWS ALB를 사용하도록 설정하였다.

remote-write-receiver 를 활성화 하여 agent에서 접속할 수 있도록 한다.

server:
    ingress:
        enabled: true
        annotations:
            kubernetes.io/ingress.class: "alb"
            alb.ingress.kubernetes.io/load-balancer-name: #ALB name           
            alb.ingress.kubernetes.io/scheme: "internal"
            alb.ingress.kubernetes.io/target-type: "ip"
            alb.ingress.kubernetes.io/security-groups: #SecurityGroupId                        
            alb.ingress.kubernetes.io/success-codes: "200"
            alb.ingress.kubernetes.io/healthcheck-path: "/-/healthy"
        hosts:
            - #host name
    persistentVolume:
        enabled: true
        storageClass: "gp2"
    extraArgs:
        enable-feature: remote-write-receiver

alertmanager:
    enabled: false

value.yaml  작성 완료 후 헬름 차트를 설치한다.

helm install [RELEASE_NAME] prometheus-community/prometheus -f values.yaml

이때  [RELEASE_NAME]  은 적당한 이름으로 변경한다.

2. grafana 설치

그라파나 커뮤니티에서 관리하는 헬름차트로 그라파나를 설치한다.

helm repo add grafana https://grafana.github.io/helm-charts
helm repo update

마찬가지로 환경에 맞게 value.yaml 을 작성한다.

참고 : https://github.com/grafana/helm-charts/blob/main/charts/grafana/values.yaml

ingress로 SSL이 미적용된 ALB를 구성한다.

ingress:
    enabled: true
    annotations:
        kubernetes.io/ingress.class: "alb"
        alb.ingress.kubernetes.io/load-balancer-name: #ALB NAME 작성
        alb.ingress.kubernetes.io/scheme: "internet-facing"
        alb.ingress.kubernetes.io/target-type: "ip"
        alb.ingress.kubernetes.io/security-groups: #SercurityGroupId 작성         
        # alb.ingress.kubernetes.io/backend-protocol: HTTP
        alb.ingress.kubernetes.io/success-codes: "200"
        alb.ingress.kubernetes.io/healthcheck-path: "/api/health"
    hosts:
        - #Hostname 작성

persistence:
    enabled: true
    storageClassName: gp2

adminUser: #ADMIN USER NAME
adminPassword: #ADMIN PASSWORD

헬름차트를 설치한다.

helm install my-release grafana/grafana -f value.yaml

3. prometheus agent 설치(수집하기 위한 클러스터에 설치)

프로메테우스 서버와 마찬가지로 헬름차트를 먼저 구성한다.

#get helm ropository info
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

agent 설정에 맞게 value.yaml을 수정한다.

참고 : https://github.com/prometheus-community/helm-charts/blob/main/charts/prometheus/values.yaml

agent 모드 설정을 위해 --enable-feature=agent 설정과 prometheus.yml 파일의 rule_files 내용을 삭제한다.

remoteWrite의 url에 프로메테우스 서버 url을 작성하여 지표가 수집될 수 있도록 한다.

server:
  enabled: true
  defaultFlagsOverride:
  - --enable-feature=agent
  - --config.file=/etc/config/prometheus.yml
  configPath: /etc/config/prometheus.yml   
  persistentVolume:
    enabled: true
    storageClass: "gp2" 
  remoteWrite:
  - url: https://#prometehus_server_host/api/v1/write    

serverFiles:
  prometheus.yml:
    rule_files:

prometheus-pushgateway:
  enabled: false

alertmanager:
  enabled: false

grafana:
  enabled: false

defaultRules:
  create: false

작성한 value 파일로 헬름차트를 설치한다.

helm install [RELEASE_NAME] prometheus-community/prometheus -f values.yaml

4. Grafana 확인

모든 클러스터에 prometeus agent 설정 후 그라파나에 접속한다.

Configuration - Data Source에서 프로메테우스를 데이터 소스로 추가한다.

그라파나 대시보드 구성 참고 : https://aws-diary.tistory.com/121

모든 클러스터의 파드를 namespace 별로 하나의 대시보드에서 확인 가능하다.

prometheus agent의 HA 구성

prometheus agent의 고가용성(HA)를 확보하기 위하여 value.yaml을 아래와 같이 수정한다.

1대 이상의 POD를 띄우기 위해서는 deploy 대신 statefulset 을 사용하도록 되어 있다.

server:
 ...(중략)
  replicaCount: 2
  statefulSet:    
    enabled: true
 ...(중략)

구성 완료 후 적용해 보면 prometheus agent가 이전과는 달리 sts로 뜨고, 두대가 뜨는걸 확인할 수 있다.

prometheus server 를 사용할때 처럼 shard를 설정하거나 하지않아도 쉽게 HA 구성이 가능하다.

좀더 다양한 옵션을 보고 싶다면, 아래 operator 헬름차트를 참고하는게 좋을 것 같다.

https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/designs/prometheus-agent.md

kubernetes 운영을 하다보면 클러스터가 여러개인 환경을 운영하게 된다.

이러한 multi-cluster 환경에서 하나의 대시보드를 통해 모든 지표를 확인할 수 있는 방법은 여러가지가 있다.

prometheus에서 멀티 클러스터 모니터링을 지원하는 방법은 다음과 같다.

1. Prometheus federation

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

- prometheus에서 도입한 첫번째 집계 기능이다.

- 각각의 서비스 클러스터에 prometheus(child)를 설치하고 /federate 엔드포인트에서 지표들을 수집/병합하기 위한 prometheus(parent)를 별도의 클러스터에 설치하여 지표를 수집한다.

- 수집해야 하는 자식 prometheus의 수가 증가하게 되면, 성능문제가 발생할 수 있으므로 주의하여 사용한다.

2. Thanos 

- https://thanos.io/

- 프로메테우스의 가용성, 확장성 등의 문제를 보완하기 위해 나온 오픈소스

- 특징

• Global Query View : Prometheus Server 및 Cluster에서 Prometheus Metric Query를 활성화하여 Prometheus 설정을 확장
• Unlimited Retention : 원하는 Scale이 가능한 Object Storage System을 통해 Metirc을 무제한으로 저장 가능
• Prometheus Compatible(프로메테우스 호환) :  Prometheus와 거의 완벽하게 호환되는 API 제공
• DownSampling & Compaction : Object Storage에 저장되어 있는 Data를 DownSampling하여 집계된 Data Query의 성능을 높이고, Data 압축/삭제를 통해 저장공간을 관리

- Thanos Sidecar : 서비스 클러스터에 thanos를 sidecar로 포함한 프로메테우스 서버 배포. query의 요청 처리

- Thanos Query : thanos sidecar와 연결하여 promQL을 처리. 메트릭을 쿼리하여 메트릭을 집계하고 중복을 제거함. 

- Thanos Ruler : Thanos에 의해 연동된 모든 프로메테우스의 룰을 정의하고 처리.

- Thanos Compactor : 수집된 데이터를 기준에 따라 장기 보관용 데이터로 변환

3. Prometheus Agent 모드(Prometheus Remote Write)

- Remote Write : Prometheus에서 수집한 모든 지표 또는 일부 지표를 원격 위치로 전달(스트리밍)

• Cortex, Thanos, OpenTelemetry 및 Amazon, Google, Grafana, Logz.io 등과 같은 클라우드 서비스는 모두 원격 쓰기를 통한 데이터 수집을 지원하게 됨
• 안정적이고 효율적인 Remote Write 구현 : 안정적이고 확장 가능한 WAL(write-ahead-log) 구현.  내부 대기열, 샤딩, 스마트 백오프 등을 추가

- Prometheus Agent 모드

• 프로메테우스 v2.32.0 버전 이상에서 사용 가능
• 프로메테우스 서버에 내장되어 --enable-feature=agent 플래그 설정 변경으로 사용가능
• 에이전트 모드는 원격 쓰기 사용 사례에 대해 Prometheus를 최적화
• 쿼리, 경고 및 로컬 스토리지를 비활성화하고 이를 사용자 정의된 TSDB WAL로 대체(스크래핑 로직, 서비스 검색 및 관련 구성과 같은 다른 모든 것은 동일하게 유지)
• 장점
  • 효율성 :  agetn TSDB WAL은 성공적인 쓰기 직후 데이터를 제거함. remote endpoint 에 도달할 수 없는 경우에는 remote endpoint이 다시 온라인 상태가 될 때까지 데이터를 디스크에 임시로 유지(서버 모드 설정과 동일). 즉agent 모드는 일반 Prometheus 서버가 유사한 상황에서 사용하는 리소스의 일부만 사용하게 됨.
  • 확장 가능성 : 메트릭 대상의 양과 대상이 노출하는 메트릭의 수를 기반으로 자동 확장이 가능해야 함.  서버 모드의 Prometheus에서는 수집된 모든 것이 한곳에 있는 그대로 유지되어야 하고(stateful) 모든 인스턴스(예: Thanos Query 또는 Promxy)에서 모든 샘플을 집계할 수 있는 전역 보기 쿼리가 필요하게 됨. agent 모드는 검색, 스크래핑 및 원격 쓰기를 별도의 마이크로 서비스로 이동하여 수집에만 집중된 운영 모델이 가능함.(stateless) Prometheus 기반 스크래핑의 손쉬운 수평적 자동 확장 기능을 활성화하여 지표 대상의 동적 변화에 반응 가능.

kubernetes v1.21 기준으로 시험봤던 후기입니다.

교육준비 과정은 아래와 같습니다.

Udemy CKA 강의

https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/

누구나 아는 그 강의를 신청하였습니다. 개인적으로 영어를 듣기에 힘이 들어 kodekloud 에서 제공해주는 실습 위주로 공부하였습니다. 직접 명령어를 치며 개념을 익히는 방안으로 수행하니 지루하지 않게 공부할 수 있었습니다. 이론을 제대로 듣지 않았던 만큼 실습을 3번정도 돌며 공부했습니다.

Kubernetes in Action

어려운 개념은 잘 정리된 블로그를 참고하셔도 되지만, 책을 보고 싶은 분은 이 책을 보시면 됩니다. 두께가 상당한 만큼 기본 개념들에 대한 설명이 자세하게 잘 나와 있습니다. 모르는 부분 위주로 찾아서 읽었습니다.

시험 대비

시험 보기 전 다른 분들의 후기를 많이 찾아봤습니다. 저는 k8s cluster 업데이트, kubelet 트러블 슈팅, etcd 백업 및 복구 문제가 어려운 난이도의 문제였는데 거의 비슷하게 나오는것 같으니 이정도는 꼭 미리 보고 가셨으면 좋겠습니다.

시험 볼때 사용중인 클러스터를 매 문제마다 변경해야 합니다. 이부분에 가장 실수가 많을것 같습니다. 문제 풀 때 클러스터를 꼼꼼히 확인 하셔야 합니다.

2시간이라서 시간이 부족할까 걱정했는데 의외로 시간은 많이 남았습니다. 어려운 문제만 잘 확인하고 가신다면 그렇게 어려운 시험은 아닌 것 같습니다.

참고가능한 명령어

공부하면서 사용했던 명령어들입니다. 주로 KodeKloud 의 실습 문제들에 활용이 가능합니다. 좋은 결과 있으시길 바랍니다.

alias 사용

https://kubernetes.io/ko/docs/reference/kubectl/cheatsheet/

alias k='kubectl' 

interactive 명령어 사용

#create taint
kubectl taint nodes node01 spray=mortein:NoSchedule

#untaint
kubectl taint nodes master node-role.kubernetes.io/master:NoSchedule-	

#node info
kubectl get pods -o wide

#노드한테 label 추가
kubectl label node node01 color=blue

#create deployment
kubectl create deployment blue --image=nginx
kubectl scale deployment blue --replicas=6

#create static pod
kubectl run --restart=Never --image=busybox static-busybox --dry-run=client -o yaml --command -- sleep 1000 > /etc/kubernetes/manifests/static-busybox.yaml

#multi scheduler
netstat -natulp | grep 10251 ~ 10253까지 찾아서 안쓰는걸로 port 지정

#log
kubectl logs -f pod이름 (container 이름)

# exec pod
kubectl -n elastic-stack exec -it app cat /log/app.log'

# config view
kubectl config view --kubeconfig my-kube-config

# 현재 컨텍스트(접속 매개 변수)를 선택
kubectl config use-context

# change current context
kubectl config --kubeconfig=/root/my-kube-config use-context research

# get role
kubectl get roles

# user check
kubectl get pods --as dev-user

# get count
kubectl get clusterroles --no-headers | wc -l

# confirm auth
k auth can-i list nodes --as michelle

# edit deployment
kubectl edit deployment

#api resource 확인
kubectl api-resources

network 영역

#network
cat /etc/network/interfaces #network interface 확인가능

# get mac address
arp node01

# route table 확인
ip route

#port 확인
netstat -nplt
netstat -anp | grep scheduler
netstat -anp | grep etcd

# CNI plugin 확인
ls /etc/cni/net.d/

# network ip range
ip addr