LLM WikiAccess-protected knowledge portal
🔒 내부용 · 비배포 (포트폴리오에는 일반화 버전만 공개) · 출처: 운영 기록/장애 회고 수집물

K8s · Airflow 데이터 수집 플랫폼 운영 & 장애 대응 (2024–2026)

데이터파트 수집 플랫폼 운영·장애 대응을 새 팀원이 이해할 수 있는 수준의 온보딩 상세

0한눈에

1아키텍처 흐름

Git-Sync(DAG-as-Code) → Airflow(KubernetesExecutor) on K8s수집 DAG(크롤러 Task별 Pod) → PostgreSQL(메타) · 모니터링.

2왜 K8s로 전환했나

Docker Compose 단일 호스트 운영은 Task 간 격리가 없고 DAG 배포가 수동이라 형상 관리가 어려웠다. K8s 전환으로:

  1. KubernetesExecutor로 Task마다 Pod를 분리해 자원·실패를 격리
  2. Git-Sync 사이드카로 DAG를 코드로 동기화(DAG-as-Code)해 배포·이력 관리
  3. 메타데이터를 PostgreSQL로 분리해 상태 일관성·복구성 확보

3주요 장애 & 근본 원인 대응

패턴: 단순 재기동에 그치지 않고 CrashLoopBackOff → 통신 경로, Eviction → Inode/Disk, Task 실패 → etcd 처럼 근본 원인까지 추적해 재발을 줄였다(HA 개선 포함).

4정기 운영

결과: 수집 파이프라인의 안정성·가용성 확보, 반복 장애의 근본 원인 해소.

5온보딩 포인트

6공개(포트폴리오)와의 차이

공개 버전(human/portfolio/items/infra-k8s-airflow-ops.html)은 내부 호스트명/IP(172.30.x, 211.115.x 등)·내부 식별자·동료 이름·고객사명을 제거하고 아키텍처·장애 대응·임팩트 중심으로 일반화했다. 이 내부 문서는 본인 참고/온보딩용으로, 장애 항목과 운영 세부를 더 구체적으로 남긴다.