[6주차] PKOS 쿠버네티스 실무 실습 스터디 (23.02.19)

PKOS(Production Kubernetes Online Study) #6

 

스터디에서 진행하는 이론 및 실습은 PKOS 스터디 자료 및 이정훈 님의 "24단계 실습으로 정복하는 쿠버네티스" 서적의 내용을 기반으로 합니다.

24단계 실습으로 정복하는 쿠버네티스 | 위키북스 | 이정훈 | 링크

24단계 실습으로 정복하는 쿠버네티스 | 이정훈 - 교보문고

 

들어가며

이번 주 스터디에서는 kOps Cluster (Kubernetes Cluster)의 node들의 매트릭을 통해 Slack으로 알림을 전송하고, Pod들의 Log를 수집한 후 Grafana에서 모니터링 하는 방법에 대해 배웠다.

 

 회사에서는 클러스터를 운영할 때 Prometheus와 Grafana를 조합하여 매트릭 모니터링하는 방법을 사용하다가, 작년 연말부터 Datadog를 이용한 로그 모니터링할 수 있도록 적용하고 테스트하는 중이다.

 

 대규모의 프로젝트는 APM이나 기타 편의기능을 위해 Datadog를 사용할 것이지만, 스터디를 통해 알게된 스택들의 구축 난이도가 높지 않아서 프로토타입 프로젝트들에 적용하면 비용적인 측면에서 좋을 것 같다고 생각했다.

 

---

 

실습 환경 구성

이번 실습 환경은 t3.small 1식 & c5.xlarge 서버 4식으로 클러스터를 구성했다. (Bastion, Leader Node, Follow Node) 이번 환경의 차이는 Follow Node하나가 더 추가된 것으로, Node의 장애 상황을 발생시키는 실험을 위함이었다.

 

 kOps 클러스터를 구성한 후 certManager. awsLoadBalancerController, externalDns, metricsServer 를 설치한다. 또한 매트릭 수집이 가능하도록 spec.kubeProxy.metricsBindAddress를 0.0.0.0으로 설정했다.

 

---

 

Alert Manager

Prometheus는 알림 시스템이 분리되어 있어서 서버 매트릭에 어떤 문제가 있거나 했을 때 기준을 정해두고 이를 Alertmanager에서 곤리해서 개발자가 알림을 받을 수 있도록 한다.

 

Alert Manager를 설치하고 접속하면 다음과 같은 화면을 볼 수 있다. 화면은 Alertmanager의 진입 페이지인데, watchdog으로 부터 알림 하나가 와있음을 확인할 수 있다. 이 watchdog는 Alert 을 전달하는 Prometheus가 정상적으로 동작하고 있는지 확인하기 위한 용도이다. 

 

Alert Manager

 

Alert manager의 주요 기능 세 가지는 다음과 같다.

1. Alerts 경고
   시스템 문제시 프로메테우스가 rule에 따라 판단한 경고메시지 목록을 확인한다.
2. Silences 일시 중지
   계획된 장애 작업시 일정 기간 동안 경고메시지를 받지 않을 때, 메시지 별로 메시지 전송을 일시적으로 중지할 수 있다. 만약 이 기능이 없다면 어떤 장애 상황 발생 시 처리하는 도중 지속적인 알람을 받아야 하는 고통이 따를 수 있다. 또한 시스템 계선을 위해 임의로 발생시킨 문제 상황이 지속적인 긴급 알림으로 인식될 수 있다.
3. Status 상태
   얼럿매니저의 상세 설정을 확인할 수 있다.

AlertManager의 UI는 아름답지 않은 편이라 karma와 같은 툴을 이용하여 더욱 화려하게 변경할 수 있다.

 

 

Karma 링크

GitHub - prymitive/karma: Alert dashboard for Prometheus Alertmanager

 

아래의 그림과 같이 Prometheus가 수집하는 매트릭의 임계치를 설정하고, 이를 Alertting Rule로 설정해 두면 슬랙으로 알림이 전송된다.

그림 출저 - 링크

Prometheus: Up & Running

 

Slack의 웹훅 주소를 alertmanager-kube-prometheus-stack-alertmanager 파드에 환경설정으로 추가하면 다음과 같이 Alert이 Slack의 특정 채널에 연동된다.

 

 

Silence 기능은 말 그대로 알림을 일시적으로 끄는 기능이다.

Alertmanager > Silences에서 사용 가능하다.

 

---

 

PLG(Promtail, Loki, Grafana) Stack

PLG Stack은 Promtail, Loki, Grafana로 구성된 스택으로써, 여러 파드의 로그들을 중앙 서버에 저장하고 조회할 수 있는 환경을 구성할 때 쓰인다. Promtail은 로컬 시스템에서 Loki 클러스터로 로그를 전달하는 에이전트 이고, Loki에 저장되는 로그는 LogQL을 통해 조회할 수 있고, Grafana에서 시각화할 수 있다.

그림 출저 - 링크

Logging in Kubernetes: EFK vs PLG Stack

 

PLG 스택을 사용해 보기 위해 간단한 Nginx 로그를 수집하는 실습을 진행했다.

#bitnami에서 제공하는 repository 추가
helm repo add bitnami https://charts.bitnami.com/bitnami

#Nginx의 metrics를 추가
cat <<EOT > ~/nginx-values.yaml
metrics:
  enabled: true

  service:
    port: 9113

  serviceMonitor:
    enabled: true
    namespace: monitoring
    interval: 10s
EOT

# 배포
helm install nginx bitnami/nginx --version 13.2.27 -f nginx-values.yaml

Helm을 통해 nginx 설치 시 서비스 모니터링이 가능하도록 metrics기능을 활성화시켰다.

 

nginx를 배포한 후 Pod의 컨테이너를 확인해 보면 다음과 같이 metrics 관련 컨테이너가 함께 생성되었음을 확인할 수 있다.

kubectl logs deploy/nginx -f

kubectl exec -it deploy/nginx -c nginx --ls -l /opt/bitnami/nginx/logs/

 

명령어를 통해 nginx의 액세스로그를 확인할 수 있고, 컨테이너 환경의 로그를 /dev/stdout, /dev/stderr 경로에서 확인할 수 있음을 알 수 있다.

 

 

 

 

 

PLG Stack을 통해 수집된 로그들은 다음과 같이 Grafana에서 확인할 수 있다.

 

---

 

6주 차 과제

과제 1 - 사용자 정의 prometheusrules 정책 설정

기존 파일 시스템은 여유공간이 5% 미만일 때 경고를 발생시키지만 설정을 통해 80% 이상이면 시스템 경고를 발생시키도록 alert rule을 생성한다.

 

rule 생성 yaml

rule 생성 결과 확인

 

알림 발생 확인

 

슬랙 알림 확인

 

---

 

과제 2 - LogQL 사용법 익히기

kubernetes namespace 로그에서 controller 키워드가 포함된 로그 출력하기

 

---

 

과제 3 - Awesome Prometheus alerts를 참고해서 스터디에서 배우지 않은 Alert Rule 생성 및 적용 후 관련 스샷을 올려주세요

KubernetesPodCrashLooping Alert 생성

 

컨테이너 배포 시 command에서 오류를 발생시켜 장애 상황 연출

apiVersion: v1
kind: Pod
metadata:
  name: busybox
spec:
  containers:
  - name: busybox
    image: busybox
    command:
      - slee1p
      - "3600"
  restartPolicy: Always

 

Prometheus alert

 

Slack alert

 

---

 

 

좋았던 점

스터디를 통해 컨테이너 로그 출력 시 stdout과 error로그의 표준 출력을 /dev/stdout. /dev/stderr로 보내는 것을 권고한다는 점을 새롭게 알았다.

링크 - https://docs.docker.com/config/containers/logging/

View container logs

Pod의 로그는 Pod가 죽을 경우 다시 확인할 수 없고, 정해진 용량이 차게 되면 더 이상 볼 수 없기 때문에, 로그 수집 시스템은 필수적으로 사용해야 한다는 점을 알게 되었다.

 

---

 

힘들었던 점

1번 과제를 진행하면서, 알림을 추가할 때 alert rule을 커스텀하게 만들어 배포했는데 rule 리스트에 관련 내용이 계속 확인되지 않았다. 그래서 이유를 확인해 봤더니 책에서 적혀있는 환경을 그대로 이용해 exporter를 생성한 것이 원인이었다. 현재 동작중인 환경에 무언가를 추가하려면 그냥 sample yaml 파일을 실행시키는 것이 아니라, 현재 동작중인 object를 -o yaml 형태로 출력하고 이를 수정해 환경을 업데이트해 주는 형식으로 진행해야 한다는 점을 다시 한번 상기하게 되었다.

 

---

 

마치며

사실 로그를 통합하여 본다는 것이 귀찮고 수고스러운 부분을 줄여주는 서포팅 역할 정도로 이해하고 있었는데, 이번 스터디를 참여하며 필수 요소라는 인식이 강해지게 되었다.

 

 아직 우리 서비스들이 엄청난 양의 로그를 생성할 만큼 트래픽을 많이 받는 편이 아니기 때문에 조금 이슈를 미뤄두고 있었던 것 같다. 프로토타입 프로젝트들에 스터디에서 배운 스택들을 접목해 보면서 기능들을 좀 더 비교해 보는 것이 좋을 것 같다.