[클라우드 프로그래밍] 13주차

쿠버네티스 로그 관리 개요

파드 수가 급격히 증가하면 kubectl logs 명령만으로는 로그를 제대로 관리하기 어렵다. 기업에서는 **수집 후 전달 모델(collect-then-forward)**을 따르는 로그 프레임워크를 사용한다.

EFK 스택 구성:

• Fluentd / Fluent Bit: 컨테이너 로그 수집 (수집기)
• Elasticsearch: 로그 저장 및 색인
• Kibana: 로그 시각화 및 검색 프런트엔드

쿠버네티스는 각 컨테이너의 로그를 노드의 /var/log/containers/ 디렉터리에 파일로 저장한다. 로그 파일 이름 형식: 파드명_네임스페이스명_컨테이너명_컨테이너ID.log

💡 시험 포인트: 로그 파일 이름에는 파드명, 네임스페이스, 컨테이너명이 포함되지만 노드의 IP 주소는 포함되지 않는다.

---

Fluent Bit

Fluent Bit은 플루언트디의 경량 버전으로 IoT/임베디드 환경을 위해 개발됐지만 쿠버네티스 로그 통합에 필요한 기능을 충분히 갖추고 있다. 데몬셋(DaemonSet) 형태로 모든 노드에 배포하여 호스트경로 마운트로 로그 파일에 접근한다.

로그 처리 파이프라인 단계: INPUT → FILTER → OUTPUT

# INPUT: 로그 파일 읽기
[INPUT]
    Name tail                        # 파일 끝부터 읽기
    Tag kube.*                       # 수집 로그에 태그 접두어 부여
    Path /var/log/containers/timecheck*.log
    Parser docker                    # JSON 형식 컨테이너 로그 파서
    Refresh_Interval 10

# FILTER: 메타데이터 추가 또는 필터링
# → 파드명, 네임스페이스, 컨테이너명 등의 메타데이터 추가
# → 불필요한 데이터 제외

# OUTPUT: 결과 전달
[OUTPUT]
    Name stdout                      # 표준 출력으로 내보내기
    Format json_lines
    Match kube.*                     # kube.* 태그 로그만 대상

💡 시험 포인트: FILTER 단계 = 수집된 로그에 메타데이터를 추가하거나 불필요한 데이터를 제외하는 단계.

kubectl apply -f fluentbit/
kubectl rollout restart ds/fluent-bit -n kiamol-ch13-logging
kubectl logs -l app=fluent-bit -n kiamol-ch13-logging --tail 2

---

일래스틱서치 (Elasticsearch)

일래스틱서치는 도큐먼트(document) 단위로 데이터를 저장하며, 도큐먼트의 집합을 **인덱스(Index)**라고 한다. 관계형 데이터베이스와 달리 고정된 스키마를 갖지 않아 서로 다른 형식의 로그를 한곳에 수집하기에 매우 적합하다.

데이터를 저장하고 조회할 때 REST API를 사용한다. 키바나(Kibana)가 프런트엔드로 동작한다.

⚠️ 자주 나오는 함정: "일래스틱서치는 고정된 스키마를 따른다" → 틀림. 스키마가 없어서 다양한 로그를 수집할 수 있는 것이 장점.

# Fluent Bit → Elasticsearch 출력 설정
[OUTPUT]
    Name  es
    Match kube.kiamol-ch13-test.*
    Host  elasticsearch
    Index test              # 저장할 인덱스 이름

---

2차시: 프로메테우스를 이용한 쿠버네티스 모니터링

프로메테우스 동작 방식

프로메테우스(Prometheus)는 CNCF에서 관리하는 클러스터 측정값 수집/저장 서버다.

풀링(Pulling) 모델: 프로메테우스가 직접 파드의 HTTP 엔드포인트에 주기적으로 접근하여 측정값을 가져온다. (서비스를 경유하지 않고 파드 IP로 직접 접근)

• 쿠버네티스 API를 통해 모니터링 대상 파드를 자동으로 발견하므로 새 애플리케이션 배포 시 설정 변경 불필요.
• 기본 포트: 9090

⚠️ 자주 나오는 함정: "파드가 프로메테우스로 측정값을 밀어 넣는다(Push 모델)" → 틀림. 프로메테우스가 Pull하는 방식.

# prometheus-config.yaml (컨피그맵)
scrape_configs:
- job_name: 'test-pods'
  kubernetes_sd_configs:
  - role: pod               # 파드를 대상으로 자동 발견
  relabel_configs:
  - source_labels:
    - __meta_kubernetes_namespace
    action: keep
    regex: kiamol-ch14-test  # 특정 네임스페이스만 대상

---

프로메테우스 스크래핑 제어 (애너테이션)

파드 정의에 애너테이션을 추가하여 스크래핑 동작을 제어할 수 있다.

template:
  metadata:
    annotations:
      prometheus.io/path: "/actuator/prometheus"   # 스크래핑 경로 커스텀
      prometheus.io/scrape: "false"                # 스크래핑 대상 제외
      prometheus.io/port: "9113"                   # 스크래핑 포트 지정

---

그라파나 (Grafana)

프로메테우스가 수집한 측정값을 시각적인 대시보드로 표현하는 도구. 모니터링 시스템에서 시각화를 전담한다.

💡 시험 포인트:

• 수집: 프로메테우스 (9090포트)
• 시각화: 그라파나 (3000포트)
• 로그 시각화: 키바나 (5601포트)

---

측정값 추출기 (Exporter)

프로메테우스 형식의 측정값을 직접 제공하지 못하는 레거시 애플리케이션에는 사이드카 형태의 추출기를 붙여 변환한다. Nginx 추출기, PostgreSQL 추출기 등이 있다.

containers:
- name: nginx
  # ... Nginx 메인 컨테이너
- name: exporter                          # 추출기 사이드카
  image: nginx/nginx-prometheus-exporter:0.8.0
  ports:
  - name: metrics
    containerPort: 9113
  args:
  - -nginx.scrape-uri=http://localhost/stub_status   # localhost로 Nginx 접근

💡 시험 포인트: 같은 파드 안의 컨테이너들은 동일한 네트워크 네임스페이스를 공유하므로 추출기가 localhost로 메인 컨테이너에 접근 가능.

---

3차시: 인그레스를 이용한 인입 트래픽 관리

인그레스란?

인그레스(Ingress)는 도메인 네임과 애플리케이션의 요청 경로를 매핑하여 외부 트래픽을 클러스터 내 올바른 서비스로 라우팅하는 쿠버네티스 리소스다.

• 하나의 공인 IP만으로 전체 클러스터의 모든 애플리케이션에 트래픽 라우팅 가능.
• HTTP와 HTTPS 트래픽만 다룬다.

⚠️ 자주 나오는 함정: "인그레스는 TCP/UDP 트래픽도 처리한다" → 틀림. 웹 트래픽(HTTP/HTTPS)만 처리.

---

인그레스 YAML 정의

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: vweb
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: vweb.kiamol.local       # 이 도메인에만 규칙 적용
    http:
      paths:
      - path: /                    # 경로 매핑
        backend:
          serviceName: vweb-v2
          portNumber: 80
      - path: /v1
        backend:
          serviceName: vweb-v1
          portNumber: 80

💡 시험 포인트: 인그레스 규칙에서 도메인을 지정하는 필드는 host다. (domain이 아님에 주의!)

---

경로 매칭 방식

paths:
- pathType: Exact          # 완전 일치 (/new → /new만 허용)
  path: /new
  backend:
    serviceName: todo-web
    portNumber: 80
- pathType: Prefix         # 전방 일치 (/static/app.css 등도 허용)
  path: /static
  backend:
    serviceName: todo-web
    portNumber: 80

---

인그레스 컨트롤러

인그레스 객체는 인그레스 컨트롤러가 없으면 동작하지 않는다. 컨트롤러가 인그레스 규칙을 읽어 실제 트래픽 라우팅을 수행하는 리버스 프록시 역할을 한다.

유형 예시 특징

리버스 프록시형	Nginx, HAProxy	오래된 방식, 네트워크 수준 동작
현대적 프록시형	Traefik	플랫폼 통합 쉬움, 클라우드 친화적

💡 시험 포인트: Nginx 인그레스 컨트롤러는 설정을 애너테이션으로 제어한다. (nginx.ingress.kubernetes.io/...)

---

📝 학습정리

• EFK 스택: Fluent Bit(수집) → Elasticsearch(저장) → Kibana(시각화)
• 로그 파일 이름 형식에 노드 IP는 포함 안 됨
• FILTER 단계: 메타데이터 추가 또는 불필요 데이터 제거
• Elasticsearch: 도큐먼트 단위 저장, 인덱스 집합, 고정 스키마 없음, REST API
• 프로메테우스: Pull 모델, 자동 대상 발견, 9090포트
• 그라파나: 프로메테우스 시각화, 3000포트
• 추출기(Exporter): 레거시 앱에 사이드카로 붙여 변환
• 인그레스: HTTP/HTTPS만, host 필드로 도메인 지정
• pathType: Exact = 완전 일치, pathType: Prefix = 전방 일치

---

🔑 핵심 키워드 정리

키워드 설명

EFK 스택	Elasticsearch + Fluentd + Kibana
Fluent Bit	경량 로그 수집기, 데몬셋으로 배포
FILTER 단계	메타데이터 추가 및 불필요 데이터 제외
Elasticsearch	도큐먼트 단위 저장, 스키마 없음
인덱스(Index)	Elasticsearch에서 도큐먼트의 집합
프로메테우스	Pull 모델, CNCF, 9090포트
그라파나	프로메테우스 측정값 시각화, 3000포트
키바나	Elasticsearch 시각화, 5601포트
추출기(Exporter)	레거시 앱 측정값 변환 사이드카
인그레스(Ingress)	HTTP/HTTPS 트래픽 도메인+경로 기반 라우팅
host	인그레스 도메인 지정 필드
인그레스 컨트롤러	인그레스 규칙을 실제 라우팅으로 구현하는 리버스 프록시