모험가

AEWS 4주차 - Observability(Monitoring, EKS 컨트롤 플레인, 파드 로깅) 본문

쿠버네티스/AEWS

AEWS 4주차 - Observability(Monitoring, EKS 컨트롤 플레인, 파드 로깅)

라리음 2025. 2. 27. 15:55
본 글은 가시다님이 진행하시는 AEWS(AWS EKS Workshop Study)를 참여하여 정리한 글입니다. 
모르는 부분이 많아서 틀린 내용이 있다면 말씀 부탁드리겠습니다!

 

 

 

 


Observability와 Monitoring

 

 

 

구분 옵저빌리티 모니터링
정의 시스템의 내부 상태와 동작을 관찰하고 이해하는 것 시스템의 성능, 가용성, 상태 등을 지속적으로 관찰하고 데이터를 수집하는 것
목적 시스템 문제 해결, 성능 향상, 복잡성 관리 시스템 상태 파악, 이상 징후 감지
방법 로그 분석, 트레이싱, 디버깅 등 지표 수집, 알람 설정, 대시보드 구축 등
활용 개발자, 운영팀 운영팀, 관리자

 

 

옵저빌리티와 모니터링은 차이가 있지만 정말 연관이 있는 관계입니다.

 

관련해서 가시다님의 글이 너무 정리가 잘 되어있어서 그대로 첨부하겠습니다.

  • 모니터링의 정의와 특징 : 사전에 정의된 기준을 기반으로 시스템의 상태를 감시에 중점
    • 모니터링은 IT 시스템의 운영 상태를 추적하고, 성능 지표를 수집하며, 예상치 못한 문제를 조기에 감지하는 과정입니다. What is IT monitoring? | Definition from TechTarget에 따르면, 모니터링은 하드웨어와 소프트웨어의 메트릭을 수집하여 모든 것이 정상적으로 작동하는지 확인하고, 문제를 탐지하며 해결하는 데 사용됩니다.
      • 주요 활동: CPU 사용량, 메모리 사용량, 응답 시간, 오류율 등 특정 지표를 지속적으로 측정.
      • 목적: 시스템 다운타임을 방지하고, 경고를 통해 팀이 빠르게 대응할 수 있도록 함.
      • 빈도: 연속적이거나 일정 간격(일간, 주간, 월간)으로 수행됨.
      • 예시: Google의 SRE 책(What’s IT Monitoring? IT Systems Monitoring Explained | Splunk)에서는 모니터링을 "시스템에 대한 실시간 정량 데이터 수집, 처리, 집계, 표시"로 정의하며, 쿼리 수, 오류 수, 처리 시간 등을 포함한다고 설명합니다.
    • 모니터링은 주로 단순하고 잘 알려진 시스템에 적합하며, 미리 설정된 임계값을 초과하면 알림을 발송하는 방식으로 작동합니다. 예를 들어, 서버의 CPU 사용량이 90%를 초과하면 경고가 발생할 수 있습니다.

 

  • 관측 가능성의 정의와 특징 : 수집된 다양한 데이터를 활용하여 예측되지 않은 문제까지 분석
    • 관측 가능성은 시스템의 내부 상태를 외부 출력 데이터(로그, 메트릭, 트레이스)를 통해 이해할 수 있는 능력을 의미합니다. Observability (software) - Wikipedia에 따르면, 관측 가능성은 소프트웨어 엔지니어링에서 프로그램 실행, 모듈 내부 상태, 컴포넌트 간 통신 데이터를 수집하고 분석하는 능력을 말합니다.
      • 핵심 데이터: 로그(이벤트 기록), 메트릭(수치 데이터), 트레이스(요청 흐름 추적), 그리고 일부 경우 이벤트가 포함됩니다.
      • 목적: 복잡한 분산 시스템에서 문제를 진단하고, 새로운 문제를 탐지하며, 시스템 동작을 최적화.
      • 예시: 애플리케이션이 느려진 이유가 특정 마이크로서비스의 데이터베이스 연결 문제 때문이라는 것을 로그와 트레이스를 통해 파악.
    • 관측 가능성은 특히 현대의 분산 아키텍처(예: 마이크로서비스, 컨테이너)에서 필수적이며, 미리 정의되지 않은 질문에 답할 수 있는 유연성을 제공합니다. 예를 들어, "왜 이 특정 요청이 실패했는가?"라는 질문을 로그와 트레이스를 통해 분석할 수 있습니다. → 콘텍스트 context(문맥) 정보를 제공
    • APM 대신 추적 tracing 이라고 부르며, 계측 instrumentation텔레메트리 telemetry 라는 용어를 범용적으로 사용함.

 

  • 차이점
    1. 목적:
      • 모니터링: 시스템의 건강 상태를 확인하고, 문제가 발생했는지 감지. 예: 서버 다운 감지.
      • 관측 가능성: 문제의 원인을 진단하고, 시스템 동작을 이해. 예: 왜 서버가 다운되었는지 분석.
    2. 데이터 수집:
      • 모니터링: 미리 정의된 메트릭(CPU 사용량, 메모리 사용량 등)에 초점.
      • 관측 가능성: 로그, 메트릭, 트레이스 등 다양한 데이터 소스를 통합적으로 사용.
    3. 시스템 복잡성:
      • 모니터링: 단순한 시스템에 적합, 예: 단일 서버 환경.
      • 관측 가능성: 복잡한 분산 시스템에 필수, 예: 마이크로서비스 아키텍처.
    4. 사용자 상호작용:
      • 모니터링: 경고 기반, 예: 임계값 초과 시 알림.
      • 관측 가능성: 동적 쿼리 및 분석 가능, 예: 특정 로그를 검색해 문제 원인 찾기.

 

 

 


EKS 컨트롤 플레인 로깅 활성화

 

 

 

 

 

EKS를 아무 설정없이 설치할 경우 Control Plane의 로깅은 비활성화입니다.

 

 

 

 

컨트롤 플레인 로그를 모두 활성화합니다.

# 모든 로깅 활성화
aws eks update-cluster-config --region ap-northeast-2 --name $CLUSTER_NAME \
    --logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}'

 

결과 화면

 

 

# 신규 로그를 바로 출력
aws logs tail /aws/eks/$CLUSTER_NAME/cluster --follow

결과 화면

 

# 로그 스트림이름
aws logs tail /aws/eks/$CLUSTER_NAME/cluster --log-stream-name-prefix kube-apiserver --follow
aws logs tail /aws/eks/$CLUSTER_NAME/cluster --log-stream-name-prefix kube-apiserver-audit --follow
aws logs tail /aws/eks/$CLUSTER_NAME/cluster --log-stream-name-prefix kube-scheduler --follow
aws logs tail /aws/eks/$CLUSTER_NAME/cluster --log-stream-name-prefix authenticator --follow
aws logs tail /aws/eks/$CLUSTER_NAME/cluster --log-stream-name-prefix kube-controller-manager --follow
aws logs tail /aws/eks/$CLUSTER_NAME/cluster --log-stream-name-prefix cloud-controller-manager --follow

 

 

 

 

해당 로그들은 CLI에서도 아래와 같은 명령어로 검색이 가능하지만 콘솔에서도 가시성있게 확인이 가능합니다.

 

 

추가로 Log Insight를 통해 쿼리를 날려서 얻고자 하는 로그를 찾아서 문제를 해결해 나갈 수 있습니다.

* 즉 적절히 섞어서 이용하면 운영자 입장에서는 매우 큰 이점이 됩니다.

 

 

실제 쿼리 예시

 fields @timestamp, @message
| filter @logStream = "<로그 스트림 이름>"
| sort @timestamp desc

 

스케쥴러의 로그 화면

 

 

 

이렇게 Cloudwatch Log Group에 Control Plane의 해당 로그들을 쌓고 있었습니다.

하지만 현재 이렇게 활성화된 로그 그룹은 데이터 만기 일정도 없고 계속해서 쌓입니다.

이러면 비용이 증가하기 때문에 삭제까지 진행하겠습니다.

 

 

로깅 끄기

# EKS Control Plane 로깅(CloudWatch Logs) 비활성화
eksctl utils update-cluster-logging --cluster $CLUSTER_NAME --region ap-northeast-2 --disable-types all --approve

# 로그 그룹 삭제
aws logs delete-log-group --log-group-name /aws/eks/$CLUSTER_NAME/cluster

 


컨테이너 로깅

 

 

사전 구성

1. Load Balance Controller 설치

2. Routing 53 도메인 등록, ACM 등록

3. externalDNS 설치

4. gp3 Storageclass 등록

 

 

# NGINX 웹서버 배포
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

 

# 변수 등록
CERT_ARN=<aws CERT ARN>
MyDomain=<도메인명>

# 파라미터 파일 생성
cat <<EOT > nginx-values.yaml
service:
  type: NodePort
  
networkPolicy:
  enabled: false
  
resourcesPreset: "nano"

ingress:
  enabled: true
  ingressClassName: alb
  hostname: nginx.$MyDomain
  pathType: Prefix
  path: /
  annotations: 
    alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
    alb.ingress.kubernetes.io/group.name: study
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
    alb.ingress.kubernetes.io/load-balancer-name: $CLUSTER_NAME-ingress-alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/ssl-redirect: "443"
    alb.ingress.kubernetes.io/success-codes: 200-399
    alb.ingress.kubernetes.io/target-type: ip
EOT
cat nginx-values.yaml

 

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

# 확인
kubectl get ingress,deploy,svc,ep nginx

결과 화면

 

 

 

 

# 접속 로그 확인
kubectl stern deploy/nginx
혹은
kubectl logs deploy/nginx -f

 

 

결과 화면

 

 

참고 사항

 

컨테이너 로그 환경의 로그는 표준 출력 stdout과 표준 에러 stderr로 보내는 것을 권고 - 링크

 

Logs and metrics

Learn how to write to, view, and configure a container's logs

docs.docker.com

 

실제 로그 파일이 컨테이너 안의 어느 경로에 쌓이는지 확인합니다.

# 컨테이너 로그 파일 위치 확인
kubectl exec -it deploy/nginx -- ls -l /opt/bitnami/nginx/logs/
total 0
lrwxrwxrwx 1 root root 11 Feb 18 13:35 access.log -> /dev/stdout
lrwxrwxrwx 1 root root 11 Feb 18 13:35 error.log -> /dev/stderr

결과 화면

 

 

 

* 종료된 파드는 kubectl logs로 확인이 불가합니다. 

-> 로그 전용 컨테이너를 생성하여 pv를 붙인다거나 다른 방법을 찾아볼 수 있을것 같습니다.

 

 

kubelet 기본 설정은 로그 파일의 최대 크기가 10Mi로 10Mi를 초과하는 로그는 전체 로그 조회가 불가능함 (파일 갯수 5개)

--> 오래된것부터 삭제됩니다

--> 설정 파일을 변경함으로써 용량을 변경할 수 있습니다.

 

 

# AL2 경우
cat /etc/kubernetes/kubelet-config.yaml
...
containerLogMaxSize: 10Mi

 

Amazon Linux 2023의 경우는 AL2의 위치와 다릅니다.

 

/etc/kubernetes/kubelet/config.json.d/00-nodeadm.conf

 

으로 파악되는데 설정을 나중에 한번 변경해보겠습니다.

AL2023에서는 설정 방법 변경 - Docs