4 분 소요

📚 Airflow on K8s (Helm) 시리즈 (전체 4편)

  1. (1/4) Airflow on K8s 시리즈 개요 — Helm 으로 올리고 워커는 컨테이너로 띄운다 ← 지금 글
  2. (2/4) Helm 으로 Airflow 를 K8s 에 설치하기 — KubernetesExecutor 셋업
  3. (3/4) Airflow 워커 이미지 만들고 pod_template_file 로 묶기
  4. (4/4) Airflow on K8s 운영 — git-sync · 로그 영속화 · 모니터링 · 스케일

Summary

이 시리즈는 K8s YAML 읽는 법 — 자주 보는 오브젝트 7가지 의 응용편 이에요. 그 글에서 가상의 web 앱으로 풀었던 7개 오브젝트(Namespace / Pod / Deployment / Service / Ingress / ConfigMap / Secret) 가 Airflow 라는 진짜 도메인 위에서 어떻게 묶이는지 4편으로 풀어요. 1편인 이 글은 큰 그림과 왜 이렇게 가는지부터 잡아둘게요.

📚 전제 지식 위 입문 글의 7개 오브젝트 어휘를 본문에서 자유롭게 씁니다. 처음이라면 한 번 훑고 오시고, 이미 익숙하면 바로 다음 섹션으로 가셔도 돼요.

💡 이 글에서 다루는 것

  • Airflow 가 뭐 하는 친구인지 짧게
  • 왜 K8s 위에 올리나
  • KubernetesExecutor 가 워커 Pod 를 어떻게 다루는가
  • Helm 차트가 깔아주는 K8s 오브젝트 묶음 한눈에
  • 시리즈 4편 로드맵



1. Airflow 컴포넌트 4가지

Airflow 는 한 줄로 줄이면 “Python 으로 짠 DAG 를 정해진 시간에 의존 관계대로 돌려주는 스케줄러” 예요. 안에는 4개의 핵심 컴포넌트가 있어요.

컴포넌트 역할 K8s 위에선 어떻게
API Server (3.x) / Webserver (2.x) UI + REST API. DAG/태스크 상태 확인, 로그 보기 Deployment 1개
Scheduler 시간/의존성 보고 “이 태스크 지금” 결정 Deployment 1개 (혹은 N개)
Triggerer deferrable 태스크의 대기 처리 Deployment 1개
Dag Processor (3.x 부터 standalone 필수) DAG 파일을 파싱해서 DB 에 적재 Deployment 1개
Worker 실제 태스크 코드 실행 태스크마다 새 Pod (이게 KubernetesExecutor)
Metadata DB DAG/태스크 실행 이력 보관 외부 RDS 또는 내장 StatefulSet(Postgres)

오른쪽 칸이 이 시리즈의 결론이에요. API Server / Scheduler / Triggerer / Dag Processor 는 상시 떠 있는 Deployment 로, Worker 는 KubernetesExecutor 가 매번 새 Pod 로 띄우고 정리 하는 구조.

💡 Airflow 3.0 부터 Dag Processor 가 별도 standalone 컴포넌트로 빠졌어요. 2.x 에선 스케줄러 안에서 같이 돌았는데, 3.x 에선 무조건 따로 띄워야 합니다. 그리고 Webserver 는 API Server 라는 이름으로 바뀌었어요(레거시 이름도 호환은 됨).



2. 왜 K8s 위에 올리나

Airflow 만 따로 보면 한 대 서버에 깔아도 굴러가요. 그런데 데이터 파이프라인은 부하가 들쭉날쭉해요. 새벽 배치 시간엔 수십 ~ 수백 개 태스크가 동시에 떠야 하고, 낮엔 거의 놀아요. 고정된 워커 풀로 굴리면 새벽엔 모자라고 낮엔 자원이 놀아요.

K8s + KubernetesExecutor 조합은 이걸 정공법으로 풀어요. 태스크 단위로 Pod 하나를 띄우고, 끝나면 즉시 정리. 부하 따라 자연스럽게 늘었다 줄었다 합니다.

이 구조가 주는 이득을 정리해보면.

  • 태스크 격리 — 각 태스크가 자기만의 Pod 라서 라이브러리 충돌 없음
  • 자가복구 — Pod 가 죽거나 노드가 죽으면 K8s 가 다른 노드에 다시 띄움
  • 설정/비밀 표준화 — ConfigMap / Secret 로 환경별 값 주입
  • 외부 노출 분리 — 웹 UI 는 Service + Ingress 로 깔끔히

💡 Docker 와 Kubernetes 의 관계 의 “Docker 는 워커, K8s 는 오케스트레이터” 그림을 그대로 가져왔다고 보면 돼요. Airflow 의 워커가 컨테이너로 추상화되고, 그걸 K8s 가 부려요.



3. KubernetesExecutor 의 그림

Airflow Executor 중 우리가 쓸 건 KubernetesExecutor 예요. 동작을 한 그림으로 요약하면 이렇습니다.

[Scheduler Pod] ── "이 태스크 돌려" ──▶ [K8s API]
                                          │
                                          ▼
                                   [새 Worker Pod 생성]
                                          │
                                          ▼  태스크 코드 실행
                                          │
                                          ▼  실행 끝 → Pod 자동 정리

핵심 포인트.

  • 워커 Pod 는 태스크 1개 = Pod 1개. 끝나면 사라져요.
  • 워커 Pod 의 이미지는 보통 스케줄러/웹서버와 같은 Airflow 이미지. DAG 코드를 같이 가져가야 하니까.
  • 워커 Pod 의 스펙 (이미지/리소스/볼륨/시크릿/노드) 은 pod_template_file 이라는 YAML 로 미리 정의. 이 YAML 은 K8s 의 평범한 Pod 스펙과 같은 골격이에요 — (3/4) 편에서 한 번에 다뤄요.
  • 태스크 단위 부분 override 가능 (executor_config={"pod_override": ...}).



4. Helm 차트가 깔아주는 K8s 오브젝트 묶음

Airflow 를 K8s 에 올리려면 만들어야 하는 리소스가 한둘이 아니에요. 손으로 다 짜면 며칠 걸리고 변경 관리도 지옥. 그래서 공식 apache-airflow Helm 차트 를 쓰는 게 사실상 표준이에요.

이 차트가 한 번의 helm install 로 깔아주는 오브젝트를 정리해보면, K8s YAML 입문 글 에서 본 7가지가 거의 다 등장합니다.

Helm 이 만드는 오브젝트 K8s 관점 역할 Airflow 안에서 하는 일
Namespace (선택) 클러스터 안 칸막이 Airflow 관련 리소스를 한 곳에 모음
Deployment × 4 (3.x) 워크로드 컨트롤러 scheduler / api-server / triggerer / dag-processor 각각의 Pod 묶음
StatefulSet (postgres 내장 시) 상태형 워크로드 메타데이터 DB
Service 여러 안정적인 내부 주소 api-server / postgres 내부 통신 입구
Ingress (옵션) 외부 HTTP 입구 웹 UI 를 클러스터 밖에 노출
ConfigMap 설정 키-값 airflow.cfg, 환경변수 묶음
Secret 여러 비밀 키-값 Fernet 키 / webserver(=apiServer) 시크릿 / JWT 시크릿 / DB 비번 / git SSH 키
ServiceAccount + RBAC 권한 부여 스케줄러가 워커 Pod 를 만들 수 있게

우리가 손으로 짤 필요 없이 values.yaml 만 잘 채우면 위 묶음이 한 방에 깔립니다.



5. 시리즈 4편 로드맵

편 다룰 것
(1/4) 개요 (지금 글) 전체 그림, 왜 K8s + Helm + KubernetesExecutor
(2/4) 설치 helm repo add → values.yaml → helm install 한 호흡
(3/4) 워커 이미지 커스텀 Airflow 이미지 빌드 + pod_template_file 로 워커 Pod 스펙 결정
(4/4) 운영 DAG 동기화(git-sync), 로그 영속화(PVC/Remote logging), 모니터링, 스케일



6. 들어가기 전 사전 체크

본격 설치 전 환경 한 번 확인.

  • K8s 클러스터 — kind, minikube, Docker Desktop, EKS/GKE 무엇이든. kubectl get nodes 로 노드 1개 이상 Ready. 차트 1.22.0 기준 K8s 1.30.13+ 필요
  • kubectl — 클러스터에 붙어 있어야 함
  • Helm — helm version 으로 3.19.0+ 확인 (차트 1.22.0 의 최소 요구)
  • 컨테이너 레지스트리 — 워커 이미지를 푸시할 곳. Docker Hub, ECR, GHCR, GCR, 사내 Harbor
  • (선택) Ingress 컨트롤러 — 외부 노출 시. 로컬 실험은 kubectl port-forward 로도 충분

실험 목적이면 노드 1대에 4 vCPU / 8GiB RAM 정도가 첫 설치 + 가벼운 DAG 까지 무리 없어요.

💡 차트 버전과 Airflow 호환: apache-airflow/airflow 차트 1.22.0 의 기본 이미지가 Airflow 3.1.8 이에요. 그 이하 차트(1.16.0+) 도 Airflow 3.x 를 지원하긴 하지만, 가능하면 최신 차트로 갑니다.

일단 오늘은 여기까지…..
다음 글에서는 helm install 한 방으로 위 7~8 개 오브젝트 묶음을 K8s 에 올리는 과정을 처음부터 끝까지 짚어볼게요.

다음 글 →: (2/4) Helm 으로 Airflow 를 K8s 에 설치하기 — KubernetesExecutor 셋업

참고