4주차 - EKS Observability - Prometheus, Grafana, Loki

0. 도입

AWS 내에서 K8S을 통해 Prometheus와 Grafana를 사용해서 실습을 진행했습니다.
EKS 콘솔에서 CloudWatch Insights 를 사용한 로그 확인 방법들, 컴포넌트 별 로그 스트림 확인 방법을 실습했습니다.
모니터링을 진행할 때, AWS 진영의 Cloudwatch Container Observability를 통해 agent를 설치해서 로그와 메트릭을 확인 하는 방법도 실습했습니다.
Node와 pod 각각 로그의 확인은 어떻게 하는지, 어떤 원리로 진행되는지 알아보았습니다.
Prometheus를 사용한 Grafana와 Grafana Alert을 실습했습니다.
자세한 PromQL과 Grafana에서 대시보드 추가하는 방법을 실습했습니다.
다시 한번 가르침을 주시는 @CloudNet 팀에 감사함을 표합니다!

1. 선수지식

CloudWatch
K8S
- node
- pod
Grafana
Prometheus

2. 실습 환경 배포

이번 환경은 ebs addon, ec2 iam role, irsa lb, preCmd가 추가되었고 노드도 t3.large로 설정되었다.
이외에도
- DNS 설정
- LB 설정
- CSI 드라이버 설정
- GP3 스토리지 클래스 생성
- eksctl 설치 및 addon들의 정책을 설정
현재 배포된 pod들의 이미지들 확인 -> 정상적으로 다 올라온것을 확인
- kubectl get pods --all-namespaces -o jsonpath="{.items[].spec.containers[].image}" | tr -s '[[:space:]]' '\n' | sort | uniq -c

3. EKS Console

A. [이론] AWS 내에서 EKS 자원 확인 방법

해당 화면에서 리소스 유형의 항목들을 확인 할 수 있습니다.
- 워크로드
  - Pods, ReplicaSets, Deployments, DaemonSets
- 클러스터
  - Nodes, Namespaces, Service, k8s의 api 서비스들
- 서비스와 네트워킹
  - Service, Ingress
- 구성 및 보안 암호
  - ConfigMap, Secrets
- 스토리지
  - PV, PVC, Storage class, CSI Drivers, CSI Nodes, Volume Attachement
- 인증
  - Service Account (IAM 역할(ARN))
- 권한 부여
  - Cluster Roles & Roles, ClusterRoleBindings, RoleBindings
- 정책
  - Limit Ranges, Resource Quotas, Network Policies, Pod Disruption Budgets, Pod Security Policies
- 확장프로그램
  - Custom Resource Definitions, Webhook Configuration

4. Logging in EKS

A. [실습] ControlPlane Logging

목적: 감사를 위한 ControlPlane의 로깅 활성화 확인
실험 설정:

로깅 활성화
로그 TAIL 확인 aws logs tail /aws/eks/$CLUSTER_NAME/cluster | more

실험 결과:
Deployment 관련 요청 이후 정상적으로 표기됨을 확인
로그 스트림에 따라 표기하는것도 확인

B. [실습] CloudWatch Log/Metrics Insights 쿼리

목적: 로깅/모니터링으로 수집한 정보들을 쿼리로서 확인

실험 설정:

A 스텝에서의 AUDIT 설정
fields userAgent, requestURI, @timestamp, @message | filter @logStream ~= "kube-apiserver-audit" | stats count(userAgent) as count by userAgent | sort count desc 해당 쿼리를 EKS 대상으로실행

실험 결과:

다음과 같은 로깅 생성 확인

C. [실습] 파드 로깅

목적: 파드 대상으로 로깅 조회하는 방법 확인

실험 설정:

NGINX 웹서버 배포
kubectl logs 로 로그 조회

실험 결과:

kubectl logs deploy/nginx -f 로 로그 확인
로그로 생성되는 파일 확인

기본 설정으로 etc/kubernetes/kubelet-config.yaml 에 containerLogMaxSize 는 10Mi이다. ClusterConfig에서 수정 가능하다.

5. Container Insights metrics in Amazon CloudWatch & Fluent Bit

A. [이론] Container Insights metrics 이란?/ 노드 로그 확인

CloudWatch Container Insight 는 AWS 에서 지원하는 CloudWatch와 연동되는 에이전트와 Fluent 파드를 데몬 셋으로 생성해서 Metrics 와 Log를 수집합니다.
동작원리:
- CloudWatch Agent를 데몬셋으로 생성
  - 메트릭 정보들을 수집 및 CloudWatchLogs로 전송
- Fluent Bit를 데몬셋으로 생성
  - /aws/containerinsights/Cluster_Name/application -> 컨테이너 로그(var/log/containers)
  - /aws/containerinsights/Cluster_Name/host -> 노드 로그(var/log/messages)
  - /aws/containerinsights/Cluster_Name/dataplane -> k8s 데이터 플레인 로그(var/log/journal)
  - 해당 로그들을 CloudWatchLogs에 전송
- Log Insights를 사용해서 대상 로그 분석 및 시각화

B. [실습] CloudWatch Container observability 설치 / Nginx 로그 확인

목적: CloudWatch의 노드 메트릭, 로그 확인 및 FluentBit 파드가 로그를 수집하는 방법 확인

실험 설정:

CloudWatch Observability Add-on 설치
daemon set 들 확인
FluentBit 파드가 로그를 수집하는 방법 확인 (Volume 의 HostPath)

설치 완료 이후에 CloudWatch 관련 daemon set 떠있는것을 확인

kubectl describe -n amazon-cloudwatch ds cloudwatch-agent
HostPath는 노드의 탑 디렉토리로 확인 (보안상 이슈가 있다. 설정 변경 가능할듯)

kubectl describe -n amazon-cloudwatch ds fluent-bit
Fluent Bit 파드가 가지는 HostPath를 확인
kubectl describe cm fluent-bit-config -n amazon-cloudwatch
INPUT: Path /var/log/containers/*.log
OUTPUT: log_group_name /aws/containerinsights/${CLUSTER_NAME}/application
해당 인풋 아웃풋으로 매칭 되서 로그를 쌓게 된다.

실험 결과:

CloudWatch > Container Insights 에서 메트릭 확인

다음과 같은 CloudWatch dataplane의 로그 이벤트도 명시가 됩니다.

6. Metrics-server & kwatch & botkube

A. [이론] metrics-server 이란?

kubelet으로 수집한 리소스 메트릭을 수집 및 집계하는 클러스터 애드온 구성요소
- cAdvisor: 에서 컨테이너 메트릭을 수집함

B. [실습] Metrics-server 확인

목적: 메트릭 서버로 k8s 노드와 파드의트릭을 확인

실험 설정:

메트릭 서버 배포
노드 메트릭 확인
파드 메트릭 확인

실험 결과:

C. [실습] Kwatch 소개

목적: Kwatch를 사용해 discord에 웹훅을 날리는 것을 확인

실험 설정:

kubectl apply -f https://raw.githubusercontent.com/abahmed/kwatch/v0.8.5/deploy/deploy.yaml

실험 결과:

해당 웹훅이 나가질 않는다;;
설정은 잘 해준것을 확인했는데 웹훅의 재설정이 필요해 보인다.

7. 프로메테우스-스택

A. [이론] 프로메테우스 소개

프로메테우스는 Time Series Database로 metric의 이름과 key value 값으로 pair들로 매칭이 된다.
PromQL 은 flexible Query Language로 해당 메트릭을 가져올 수 있다. (Pull 방식 )

B. [실습] 프로메테우스 설치

목적: CSI 드라이버를 설치하고 실제 스토리지 클래스를 생성하는것을 확인

실험 설정:

모니터링 네임 스페이스 생성
helm repo 추가
배포 진행
1. helm install kube-prometheus-stack prometheus-community/kube-prometheus-stack --version 57.1.0 --set prometheus.prometheusSpec.scrapeInterval='15s' --set prometheus.prometheusSpec.evaluationInterval='15s' -f monitor-values.yaml --namespace monitoring

실험 결과:

배포된 것을 확인 가능합니다.
yaml 파일에서 ingress 에대해서 80 포트를 443 포트로 redirect 시켜놨습니다.
ELB의 갯수는 한개로 프로메테우스와 그라파나 두개가 동일한 ALB를 LoadBalancerName을 통해서 공유하게끔 설정 가능합니다. URL 기반 라우팅을 하게됨
Scheduler와 컨트롤러 매니저는 데이터가 수집이 되지 않는데 그 이유는 컨트롤러 노드들은 EKS에 의해서 관리되고 있기 떄문입니다.