📗Kafka on Kubernetes

Kafka를 Kubernetes에서 운영하는 사례는 실제로 존재하며 점점 늘어나고 있다. Kafka는 기본적으로 "노드-디스크-브로커 ID"가 강하게 연결되는 구조다. Kubernetes의 Pod 유동성, Ephemeral 디스크, 네트워크 추상화 등은 이를 운영에 부담을 줄 수 있다. 다음과 같은 명확한 조건과 자동화/운영 도구를 갖춘 경우에 주로 적용된다.

• 핵심 전제 조건
• • StatefulSet + 고정된 브로커 ID 관리
• • 고성능 PVC (예: io2, PowerFlex, 로컬 SSD 등)
• • CNI 최적화로 네트워크 지연 최소화
• • Strimzi, Confluent Operator 등 도구 활용
• • 모니터링/백업 체계 확보 (Prometheus, Grafana, 로그 수집기)

🏳️‍🌈 [궁금한점]

• Kafka를 Kubernetes 에서 운영할 수 있을까
• Kafka를 Kubernetes 에서 운영시 Kubernetes 장애가 나면 Kafka가 어떤 영향을 받을까

---

🔗[목차]

• 📗Kafka on Kubernetes
• Kafka Kubernetes 운영 권장 조건
• Kafka Kubernetes 운영 베스트 프랙티스
• 쿠버네티스 장애 시 Kafka 영향
  • 운영 시 고려사항
• Kubernetes 외부 운영 시스템 고려 대상 시스템
  • 외부 운영의 장점
  • 내부 운영 조건

Kafka Kubernetes 운영 권장 조건

조건	설명
상태 저장 워크로드 경험	StatefulSet, PVC, Pod-Affinity 등 K8s Stateful 워크로드 이해 필요
고성능 스토리지 확보	로컬 SSD, 고성능 네트워크 스토리지 (ex. PowerFlex, EBS gp3/io2 등)
네트워크 성능 요구 충족	오버레이 아닌 네트워크 사용 또는 CNI 최적화 (Calico non-overlay 등)
자동화 툴 사용	Strimzi, Confluent Operator 등을 통한 배포/운영 자동화
모니터링/알림 체계 구축	Prometheus + Grafana, AlertManager, Log 수집 스택 구성

Kafka Kubernetes 운영 베스트 프랙티스

베스트 프랙티스	설명
StatefulSet 사용	브로커 ID, 볼륨 매핑 등 고정 필요
PodDisruptionBudget 설정	의도치 않은 롤링/재시작 방지
Anti-Affinity 설정	브로커가 다른 노드에 분산되도록 구성
Volume 고정	브로커와 PersistentVolume이 1:1 매칭되도록 유지
로그/모니터링 통합	Kafka Exporter, Zookeeper Exporter, 로그 수집기 구성
Operator 사용	Strimzi, Confluent Operator로 복잡한 구성 자동화

쿠버네티스 장애 시 Kafka 영향

Control Plane 노드의 장애가 생기더라도 Control Plane 노드가 복구될 때까지 Kafka Pod 자체는 영향 없이 메시지 처리 계속 가능하다.

상황	Kafka 영향	설명
Control Plane 장애 (예: kube-apiserver crash)	Kafka 정상 동작	Kafka는 Worker 노드에 있으므로, 이미 실행 중인 Pod는 계속 메시지 송수신 가능
Kafka Pod 재시작 필요	재스케줄 불가	Control Plane 없으면 새로운 Pod 생성, 재스케줄, Replica 유지 등 안 됨
PVC 동적 프로비저닝 중	중단됨	CSI 연동도 Control Plane 통해 이뤄지기 때문에, 스토리지 생성 불가
Kafka 스케일 업/다운 시도	불가	kubectl scale 등의 명령은 kube-apiserver 통해야 함
Kafka 서비스 DNS 새롭게 조회	문제 생길 수 있음	kube-dns가 apiserver와 연결 안 되면 새 DNS 등록/조회에 영향 가능

운영 시 고려사항

• Kafka는 StatefulSet 기반이라 더 민감함
• Pod 재시작이나 재배포가 제어 Plane 장애에 의존
• Control Plane는 HA 구성이 권장
• 장애를 줄이기 위해 3 노드 이상으로 이중화 (etcd, apiserver 포함)
• Kafka 자체의 Replication 기능은 별개
• Kafka는 자체적으로 broker 간 replication을 통해 데이터 보호 → Control Plane 장애와 무관
• Kafka-PVC가 연동된 경우
• CSI (예: Longhorn 등) 의 작동 일부도 Control Plane을 필요로 함

Kubernetes 외부 운영 시스템 고려 대상 시스템

시스템	이유
Kafka	- 고성능 로그 기반 스트리밍 시스템 - 디스크 I/O 민감, 클러스터 구성 복잡 - 브로커 간 복제/리밸런싱이 K8s 재시작/스케일과 충돌 가능
RDBMS (PostgreSQL, MySQL 등)	- 상태 저장 + 일관성 중요 - PVC 장애 시 데이터 손실 위험 - 백업/복구, 고가용성은 외부 운영 도구가 더 안정적
Harbor (Private Registry)	- 저장 공간(Iceberg, 이미지 등) 많이 차지 - 내부 배포 가능하나, 외부 서비스처럼 운영하는 게 편함
ElasticSearch	- 클러스터 구성 복잡 + 디스크 I/O 강함 - PVC 마운트, 리소스 요구 큼 - Elastic Operator는 있으나 운영 난이도 높음
Ceph / MinIO (Object Storage)	- 스토리지는 일반적으로 K8s 외부에서 운영 - Ceph는 전체 클러스터 자원을 쓰므로 외부화가 일반적
CI/CD 시스템 (Jenkins 등)	- Jenkins는 내부 가능하나, 빌드 캐시, Docker Daemon 등 고려 시 외부 운영이 안정적
로그/모니터링 스택	- Loki, Prometheus 등은 내부 가능 - 하지만 중앙 통합 수집/분석 목적이면 외부 플랫폼 사용 많음

외부 운영의 장점

이유	설명
고정된 디스크 환경 가능	VM에서는 디스크 재사용, 성능 최적화가 용이
네트워크 지연 최소화	VM 환경에서 오버레이 네트워크 없이 직접 통신
복잡한 상태 유지 피할 수 있음	Kubernetes의 스케줄링/재시작으로 인한 혼란 없음
장애 대응 유연성	디스크 교체, 재마운트 등 수작업 대응이 유리할 수 있음
클러스터 분리로 독립 운영 가능	Kafka 인프라 자체를 별도로 분리하여 운영할 수 있음

내부 운영 조건

조건	가능 여부
테스트/개발용 Kafka, DB	가능
단일 노드 환경 또는 작은 팀용 CI/CD	가능
내부에서만 사용하는 Harbor (작은 용량)	가능
K8s Operator로 안정화된 서비스 (ex. DB Operator)	가능 (단, 운영 경험 필요)