[AEWS_1기] 4주차 - Observability (4/6) - 프로메테우스-스택

 

 

본 시리즈는 가시다님의 AEWS(AWS EKS Workshop) 1기 진행 내용입니다. (가시다님 노션)

스터디에 사용되는 링크 (AWS EKS Workshop) 

 

목차

1. Logging in EKS (링크)
2. Container Insights metrics in Amazon CloudWatch & Fluent Bit (Logs) (링크)
3. Metrics-server & kwatch & botkube (링크)
4. 프로메테우스-스택
5. 그라파나 Grafana
6. kubecost

 

 

 

EKS 클러스터 세팅 (Cloudformation)

https://s3.ap-northeast-2.amazonaws.com/cloudformation.cloudneta.net/K8S/eks-oneclick3.yaml

 

 

 

---

4. 프로메테우스-스택

PKOS 때 한번 했었지만 한번 더 해보자!

 

 

 

 

# 모니터링
kubectl create ns monitoring
watch kubectl get pod,pvc,svc,ingress -n monitoring

# 사용 리전의 인증서 ARN 확인
CERT_ARN=`aws acm list-certificates --query 'CertificateSummaryList[].CertificateArn[]' --output text`
echo $CERT_ARN

# repo 추가
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts

# 파라미터 파일 생성
cat <<EOT > monitor-values.yaml
prometheus:
  prometheusSpec:
    podMonitorSelectorNilUsesHelmValues: false
    serviceMonitorSelectorNilUsesHelmValues: false
    retention: 5d
    retentionSize: "10GiB"

  ingress:
    enabled: true
    ingressClassName: alb
    hosts: 
      - prometheus.$MyDomain
    paths: 
      - /*
    annotations:
      alb.ingress.kubernetes.io/scheme: internet-facing
      alb.ingress.kubernetes.io/target-type: ip
      alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
      alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
      alb.ingress.kubernetes.io/success-codes: 200-399
      alb.ingress.kubernetes.io/load-balancer-name: myeks-ingress-alb
      alb.ingress.kubernetes.io/group.name: study
      alb.ingress.kubernetes.io/ssl-redirect: '443'

grafana:
  defaultDashboardsTimezone: Asia/Seoul
  adminPassword: prom-operator

  ingress:
    enabled: true
    ingressClassName: alb
    hosts: 
      - grafana.$MyDomain
    paths: 
      - /*
    annotations:
      alb.ingress.kubernetes.io/scheme: internet-facing
      alb.ingress.kubernetes.io/target-type: ip
      alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
      alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
      alb.ingress.kubernetes.io/success-codes: 200-399
      alb.ingress.kubernetes.io/load-balancer-name: myeks-ingress-alb
      alb.ingress.kubernetes.io/group.name: study
      alb.ingress.kubernetes.io/ssl-redirect: '443'

defaultRules:
  create: false
kubeControllerManager:
  enabled: false
kubeEtcd:
  enabled: false
kubeScheduler:
  enabled: false
alertmanager:
  enabled: false

# alertmanager:
#   ingress:
#     enabled: true
#     ingressClassName: alb
#     hosts: 
#       - alertmanager.$MyDomain
#     paths: 
#       - /*
#     annotations:
#       alb.ingress.kubernetes.io/scheme: internet-facing
#       alb.ingress.kubernetes.io/target-type: ip
#       alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
#       alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
#       alb.ingress.kubernetes.io/success-codes: 200-399
#       alb.ingress.kubernetes.io/load-balancer-name: myeks-ingress-alb
#       alb.ingress.kubernetes.io/group.name: study
#       alb.ingress.kubernetes.io/ssl-redirect: '443'
EOT
cat monitor-values.yaml | yh

# 배포
helm install kube-prometheus-stack prometheus-community/kube-prometheus-stack --version 45.27.2 \
--set prometheus.prometheusSpec.scrapeInterval='15s' --set prometheus.prometheusSpec.evaluationInterval='15s' \
-f monitor-values.yaml --namespace monitoring

# 확인
## alertmanager-0 : 사전에 정의한 정책 기반(예: 노드 다운, 파드 Pending 등)으로 시스템 경고 메시지를 생성 후 경보 채널(슬랙 등)로 전송
## grafana : 프로메테우스는 메트릭 정보를 저장하는 용도로 사용하며, 그라파나로 시각화 처리
## prometheus-0 : 모니터링 대상이 되는 파드는 ‘exporter’라는 별도의 사이드카 형식의 파드에서 모니터링 메트릭을 노출, pull 방식으로 가져와 내부의 시계열 데이터베이스에 저장
## node-exporter : 노드익스포터는 물리 노드에 대한 자원 사용량(네트워크, 스토리지 등 전체) 정보를 메트릭 형태로 변경하여 노출
## operator : 시스템 경고 메시지 정책(prometheus rule), 애플리케이션 모니터링 대상 추가 등의 작업을 편리하게 할수 있게 CRD 지원
## kube-state-metrics : 쿠버네티스의 클러스터의 상태(kube-state)를 메트릭으로 변환하는 파드
helm list -n monitoring
kubectl get pod,svc,ingress -n monitoring
kubectl get-all -n monitoring
kubectl get prometheus,servicemonitors -n monitoring
kubectl get crd | grep monitoring

 

group.name - ALB 한 묶음으로 사용 = ALB tag로 추가됨

 

그렇다면 group.name만 주석처리하면 어떻게 될까?

어떻게 되긴...

 

ingress 확인

하나만 배포된다

내 grafana 어디갔지..

뭐야 내 그라파나 돌려줘요

결론 : 묶으려면 group.name

 

 

그럼 ALB를 두개로 나누고 싶다면

 

 

번외) group.name은 두고 load-balancer-name만 주석처리하면?

못난(?) 이름으로 만들어진다.

load-balancer-name을 안넣어줬으니 그렇게 됐으리라.

 

그래도 리스너도 잘 들어갔다.

group.name으로 진하게 묶여있는 사이인 것을 확인했다. 

 

 

그럼 좀 이상하게(?) 만들어보자 group.name은 study 통일, load-balancer-name만 다르게 설정

과연 어떻게 될까?

일단 ingress 확인

 

myeks-ingress-alb2 만 생성된다.

 

 

그렇다면 두 ALB를 나누고자 한다면?

 ingress에서도 address가 잘 분리되었다.

훌륭한 모습이다.

 

리스너를 확인해보자

프로메테우스 ALB

그라파나 ALB

 짝짝짝짝!

 

 

 

group.name 다르게해도 역시 잘 나뉘지 않을까?

(당연히 잘 되어야 겠지...?)

 

ingress 확인

 

 ALB 확인 (group.name)

• group.name이 서로 다르게 잘 나왔다 (study, study2)
  • 사실 중간에 한번 꼬여서 당황했는데, 역시 생각한대로 잘 된다

AWS가 익숙치 않은 내가 조물조물 가지고 놀기 좋았다

정리하자면,

• ALB를 따로 쓰고싶다면
  • load-balancer-name을 다르게 설정
• ALB를 하나로 쓰고싶다면

 

 

다시 돌아와서

ssl-redirect - HTTP로 접속 요청이 들어왔을 때 HTTPS로 라우팅

Redirect

하나의 ALB 안에 HTTPS:443 리스너에 grafana와 prometheus가 둘다 ingress로 들어가있다.

 

 

 

GPU 리소스를 사용하기에 GPU 클러스터 배포하고 프로메테우스로 GPU 자원 모니터링하는 멋진 꿈을 꾸었는데 잘 안되서...(삽질 & 삽질..)

 

Exporter 테스트

- 악분님 블로그 참조 (링크)

 

Helm Chart로 제공하는 프로젝트들 중 잘 관리된 것들은 metrics 와 같은 파라미터값으로 프로메테우스에게 전달하는 잘 구성된 exporter 설정을 제공한다.

 

https://artifacthub.io/packages/helm/ingress-nginx/ingress-nginx

기본적으로 프로메테우스 메트릭을 수집 가능한 상태로 제공하려면 controller.metrics.enabled를 true로 설정.

프로메테우스 오퍼레이터를 쓰는 경우 controller.metrics.serviceMonitor.enabled도 true 설정하여 사용 가능

해보자!

## vi nginx-ingress.yaml
controller:
  metrics:
    enabled: true
    serviceMonitor:
      enabled: true

# nginx ingress helm 차트 추가
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

# helm 차트 릴리즈
## -f nginx-ingress.yaml 을 통해 설정값을 오버라이딩
helm install -n infra --create-namespace nginx ingress-nginx/ingress-nginx -f nginx-ingress.yaml

## 프로메테우스 오퍼레이터 중 서비스모니터로 잘 등록되었는지 확인
kubectl get servicemonitor -n infra

 

프로메테우스 확인

어떤 메트릭을 사용할 수 있나 확인

tail -n 30으로 마지막 30개만 본거라 이거보다 훨씬 메트릭 데이터가 많음

 

한번 슥 쿼리해보자

이런식으로 자동완성?을 도와줘서 참 좋다

 

nginx-ingress 라고해도 Application이니 exporter면 pod에 sidecar로 붙는건가? 라는 생각을 했는데

확인해보니 아니였다.

별도의 pod 형태로 뜨는 것도 아닌 듯 하다.

 

nginx-ingress Deployment를 보면 그냥 단일 컨테이너에서 80,443 뿐만 아니라 메트릭을 위한 10254나 웹훅을 위한 8443포트까지 제공하고 있다.

 

 

 

결론

ALB 얘기가 8할인 것 같은 느낌이지만...

악분님 덕에 helm chart 쪽 까지 실습할 수 있어서 좋았습니다 ㅎㅎ