blog,미분류

핵심 한 줄 — 카카오는 온프레미스에 7,000개 이상의 클러스터, 12만 대 이상의 노드를 운영합니다.

카카오는 KakaoTalk 메신저를 중심으로 지도·웹툰·쇼핑·뱅킹·모빌리티(택시)까지 아우르는 서비스를 제공합니다. CNCF 케이스 스터디에 따르면 국내 월간 활성 사용자(MAU)는 약 1억 250만 명, 사용자 규모는 5,000만 명 이상입니다(출처: CNCF Kakao Case Study).

인프라 규모는 다음과 같습니다(출처: CNCF Kakao Case Study).

• Kubernetes 클러스터 7,000개 이상 — 퍼블릭 클라우드가 아니라 사내 온프레미스로 구축
• 노드 12만 대 이상 — 다중 존(multi-zone)에 분산 배치

이 수치가 특별한 이유는 두 가지입니다. 첫째, 대부분의 초대규모 Kubernetes 사례가 하이퍼스케일러의 관리형 서비스(EKS·GKE·AKS)를 전제하는 반면, 카카오는 클러스터 수명주기와 네트워크 데이터플레인을 직접 소유합니다. 둘째, 클러스터를 크게 몇 개로 묶는 대신 7,000개로 잘게 나눠 운영합니다. 클러스터를 작게 유지하면 장애 폭발 반경(blast radius)이 줄고 업그레이드가 국소화되지만, 그만큼 네트워킹·관측성의 표준화 부담이 커집니다. 이 선택이 뒤에서 다룰 CNI 결정의 배경이 됩니다.

Kubernetes 커뮤니티는 단일 클러스터를 노드 5,000대, 파드 15만 개, 컨테이너 30만 개 수준까지 권고 상한으로 제시합니다(출처: Kubernetes Docs — Considerations for large clusters). 카카오처럼 클러스터를 다수로 쪼개는 전략은 이 상한을 안전하게 회피하는 정공법이기도 합니다.

핵심 한 줄 — kube-proxy·Cilium·Nginx Ingress가 겹쳐 장애 추적이 어려웠습니다.

카카오의 초기 구성은 흔히 볼 수 있는 조합이었습니다. Cilium을 CNI로 쓰되, 서비스 로드밸런싱은 kube-proxy에 맡기고, L7 정책과 인그레스는 Nginx Ingress로 처리하는 방식입니다. 문제는 이 세 컴포넌트가 네트워크 경로 위에 층층이 쌓이면서 발생했습니다.

카카오의 클라우드 엔지니어 최광훈(Kwang Hun Choi)은 CNCF 케이스 스터디에서 이렇게 설명합니다.

“우리는 (Cilium을) kube-proxy와 함께 썼는데, 이것이 많은 네트워크 문제를 일으켰습니다. kube-proxy와 Cilium을, 그리고 L7 정책을 위한 Nginx Ingress까지 함께 분석해야 했기 때문에 이 문제들을 해결하기가 어려웠습니다.”
— Kwang Hun Choi, Cloud Engineer, Kakao Corp (출처: CNCF Kakao Case Study)

이 증언의 핵심은 성능이 아니라 디버깅 가능성(debuggability)입니다. 패킷 하나가 파드에 도달하기까지 CNI 데이터플레인, kube-proxy의 서비스 변환, Nginx의 L7 라우팅을 차례로 통과합니다. 지연이나 드롭이 발생했을 때 원인이 어느 계층인지 특정하려면 세 개의 서로 다른 모델을 동시에 이해해야 합니다.

기술적으로 kube-proxy의 부담은 규모에 비례합니다. kube-proxy는 iptables(또는 IPVS) 모드에서 Service 하나, Endpoint 하나마다 규칙을 추가하고, 변경이 있을 때마다 규칙 체인을 갱신·순회합니다. 파드와 서비스가 수만 개인 클러스터에서는 이 규칙 세트를 업데이트하고 탐색하는 것만으로도 상당한 시간이 소요됩니다(출처: Cilium — Kube-proxy Replacement). 카카오처럼 클러스터가 7,000개라면 이 부담이 클러스터마다 반복됩니다.

핵심 한 줄 — 세 CNI를 다시 비교한 끝에 eBPF 기반 Cilium을 택했습니다.

카카오는 문제를 우회하지 않고 CNI 선택 자체를 원점에서 재평가했습니다. 후보는 클라우드 네이티브 진영에서 가장 널리 쓰이는 세 가지였습니다.

카카오는 Cilium을 최종 선택했습니다. 결정 근거는 다시 최광훈의 말에 담겨 있습니다.

“Cilium이 최선이었습니다. eBPF를 사용해 네트워크 비용을 줄일 수 있었고, kube-proxy 대체(replacement) 옵션이 네트워크 문제를 디버깅하는 복잡도를 낮춰 주었기 때문입니다.”
— Kwang Hun Choi (출처: CNCF Kakao Case Study)

주목할 점은 선택의 기준이 벤치마크 수치가 아니라 운영성이라는 것입니다. eBPF의 성능 이점(네트워크 비용 절감)과 함께, “장애를 분석할 때 봐야 할 컴포넌트가 하나로 줄어든다”는 디버깅 단순화가 동등한 무게로 언급됩니다. 초대규모 운영에서는 최고 성능보다 예측 가능하고 추적 가능한 동작이 더 값집니다.

핵심 한 줄 — eBPF가 커널에서 서비스 부하분산을 직접 처리해 kube-proxy를 없앱니다.

Cilium은 리눅스 커널의 eBPF(extended Berkeley Packet Filter) 기술을 데이터플레인의 핵심으로 사용합니다. eBPF는 커널을 재컴파일하거나 모듈을 적재하지 않고도, 커널 안에서 안전하게 실행되는 프로그램을 삽입할 수 있게 해 줍니다(출처: eBPF.io). Cilium은 이 위에서 CNI가 하던 파드 간 연결·네트워크 정책·서비스 라우팅을 커널 데이터 경로에서 직접 수행합니다(출처: CNCF.co.kr — 컨테이너 네트워크 인터페이스(CNI)).

kube-proxy 대체(kube-proxy replacement)의 핵심은 데이터 구조의 차이입니다. kube-proxy가 iptables 규칙 체인을 선형으로 순회하는 대신, Cilium은 eBPF 해시맵으로 서비스를 조회합니다. 서비스와 엔드포인트가 아무리 많아도 조회 비용이 일정하게 유지되는 성질(상수 시간에 가까운 조회)이 대규모에서 결정적 이점이 됩니다(출처: Cilium — Kube-proxy Replacement; The New Stack — Breaking the Chains of Kube-Proxy).

카카오는 클러스터를 완전 대체(full kube-proxy replacement) 모드로 업그레이드해 kube-proxy를 아예 제거했습니다(출처: CNCF Kakao Case Study). 설정은 개념적으로 다음과 같은 형태입니다.

# Cilium을 kube-proxy 완전 대체 모드로 설치 (개념 예시)
helm install cilium cilium/cilium \
  --namespace kube-system \
  --set kubeProxyReplacement=true \
  --set k8sServiceHost=<API_SERVER_IP> \
  --set k8sServicePort=6443

대체가 적용되었는지는 Cilium 상태로 확인합니다.

$ cilium status --verbose
...
KubeProxyReplacement:   True   [eth0 10.0.0.10 (Direct Routing)]
Host Routing:           BPF
Masquerading:           BPF

KubeProxyReplacement: True가 뜨면 ClusterIP·NodePort·LoadBalancer·ExternalIPs 같은 서비스 타입 처리를 kube-proxy 없이 eBPF가 담당한다는 뜻입니다. 운영 관점에서 이는 iptables 규칙 폭증이라는 스케일 한계를 구조적으로 제거하는 변화입니다. 참고로 eBPF 기능을 온전히 쓰려면 비교적 최신 리눅스 커널이 전제되며, 온프레미스에서 커널을 직접 관리하는 카카오는 이 조건을 통제할 수 있는 위치에 있습니다.

핵심 한 줄 — 비용·디버깅·안정성 세 축에서 개선을 보고했습니다(정성적).

CNCF 케이스 스터디는 도입 효과를 다음 세 가지로 정리합니다. 다만 구체적인 절감률이나 금액 같은 정량 지표는 명시되지 않았으므로, 아래는 정성적 성과로 읽어야 합니다(출처: CNCF Kakao Case Study).

• 네트워크·성능 비용 절감 — eBPF 최적화로 동일 규모를 더 적은 자원으로 처리. 플랫폼 규모가 큰 만큼 절대 효과가 큽니다.
• 디버깅 단순화 — kube-proxy를 제거하면서 네트워크 문제의 분석 대상이 사실상 Cilium 하나로 좁혀졌습니다. 앞서 본 “세 컴포넌트를 동시에 분석”하던 부담이 사라진 것이 가장 직접적인 이득입니다.
• 안정성 — 활발한 커뮤니티 패치가 이슈를 빠르게 흡수합니다. 최광훈은 “패치가 매우 자주 릴리스된다”고 언급했습니다.

여기서 의사결정자가 던질 질문은 “그래서 왜 우리에게 중요한가”입니다. 세 효과의 공통분모는 운영 인력의 인지 부하 감소입니다. 7,000개 클러스터를 소수의 플랫폼 팀이 관리하려면, 한 번의 장애를 분석하는 데 드는 시간을 줄이는 것이 곧 운영 가능한 규모의 상한을 끌어올리는 일입니다. 성능 지표보다 이 지점이 대규모 운영의 실질적 손익을 가릅니다.

핵심 한 줄 — 카카오의 컨테이너 플랫폼은 수백 클러스터에서 수천 클러스터로 성장했습니다.

카카오의 현재 규모는 하루아침에 만들어지지 않았습니다. 카카오는 사내 컨테이너 플랫폼 DKOS를 통해 컨테이너 오케스트레이션을 발전시켜 왔습니다. 초기에는 Mesos 기반이었고 이후 Kubernetes로 무게중심이 옮겨졌습니다(출처: SlideShare — DKOS, Mesos 기반 orchestration).

공개된 발표 자료의 규모 추이는 성장 궤적을 잘 보여줍니다(출처: SlideShare — KRnet 2018 Kakao Container Cloud DKOS. 아래 수치는 2017~2018년 발표 시점 기준이며, 앞서 인용한 현재 규모와는 시점이 다릅니다).

• 2017년 — 클러스터 약 400개, 노드 약 4,000대, 컨테이너 약 8,800개
• 2018년 — 클러스터 약 700개, 노드 약 8,000대, 컨테이너 약 16,000개, 최대 클러스터 1,600노드

2018년의 700개 클러스터가 오늘의 7,000개 이상으로 늘어나는 동안, 자연스럽게 네트워크 데이터플레인의 표준화가 핵심 과제가 되었습니다. 클러스터가 열 배로 늘면 kube-proxy 기반 구성의 운영 부담도 함께 열 배가 되기 때문입니다. Cilium/eBPF로의 전환은 이 성장 곡선 위에서 필연에 가까운 선택이었습니다. 계열사인 카카오페이 역시 멀티·하이브리드 클러스터 전략으로 고가용성을 추구해 온 것으로 공개되어 있어, 그룹 차원의 대규모 운영 노하우가 축적되어 있음을 짐작할 수 있습니다(출처: 카카오페이 기술 블로그).

이 사례가 주는 교훈은 분명합니다. 대규모에서 운영성을 좌우하는 것은 무엇을 더 붙이느냐가 아니라 무엇을 걷어내 단순화하느냐입니다. 카카오는 계층을 하나 제거함으로써 성능과 디버깅 가능성을 동시에 얻었습니다.

핵심 한 줄 — 카카오는 Cluster Mesh와 Hubble로 멀티클러스터·관측성을 확장 중입니다.

카카오는 이 두 기능을 추가로 검토하고 있습니다(출처: CNCF Kakao Case Study).

• Cilium Cluster Mesh — 여러 클러스터의 서비스를 하나의 네트워크처럼 연결. 7,000개 클러스터 환경에서 클러스터 간 서비스 디스커버리와 부하분산을 표준화하는 자연스러운 다음 수순입니다.
• Hubble — Cilium 위에서 동작하는 네트워크 관측성 도구. 서비스 간 통신 흐름·정책 위반·드롭을 실시간으로 시각화합니다. 앞서 강조한 “디버깅 단순화”를 관측성 계층까지 확장하는 셈입니다.

관측성은 CNCF 생태계의 공통 화두이기도 합니다. eBPF 기반 네트워크 가시성은 OpenTelemetry 같은 애플리케이션 계층 관측성과 상호 보완적으로 작동합니다(출처: CNCF.co.kr — OpenTelemetry란 무엇인가). 네트워크 데이터플레인을 단순화한 다음, 그 위에 표준화된 관측성을 얹는 것이 대규모 클라우드 네이티브 플랫폼의 일반적인 성숙 경로입니다.

Q1. 카카오는 왜 관리형 Kubernetes(EKS/GKE) 대신 온프레미스를 택했나요?
A. CNCF 케이스 스터디는 선택 배경을 명시하지 않지만, 카카오는 사내 OpenStack 위에 7,000개 이상의 클러스터를 직접 운영합니다. 대규모·데이터 주권·비용·커널 수준 제어(eBPF 활용 전제)를 감안하면, 데이터플레인을 직접 소유하는 편이 유리한 조건이 갖춰져 있습니다.

Q2. kube-proxy를 제거하면 무엇이 좋아지나요?
A. iptables 규칙이 서비스·엔드포인트 수에 비례해 늘어나는 스케일 한계가 사라집니다. Cilium은 eBPF 해시맵으로 서비스를 조회하므로 규모가 커져도 조회 비용이 거의 일정하게 유지되고, 장애 분석 시 봐야 할 컴포넌트가 줄어 디버깅이 단순해집니다.

Q3. eBPF 기반 Cilium을 쓰려면 무엇이 필요한가요?
A. 비교적 최신 리눅스 커널이 전제됩니다. kube-proxy 완전 대체 모드에서는 kubeProxyReplacement=true로 설치하고 cilium status에서 KubeProxyReplacement: True를 확인하면 됩니다. 온프레미스처럼 커널을 직접 관리할 수 있는 환경일수록 도입이 수월합니다.

Q4. 이 사례를 우리 조직에 그대로 적용할 수 있나요?
A. 규모가 다르면 우선순위도 다릅니다. 다만 “네트워킹 계층을 단순화해 디버깅 가능성을 높인다”는 원칙은 규모와 무관하게 유효합니다. 그래서 새 CNI를 도입하기 전에 현재 CNI·kube-proxy·Ingress가 만드는 계층의 수부터 점검해야 합니다.

• 컨테이너 네트워크 인터페이스(CNI) — CNCF.co.kr
• 쿠버네티스 아키텍처 완벽 가이드 — CNCF.co.kr
• 쿠버네티스 아키텍처 이해(6장) — CNCF.co.kr
• OpenTelemetry란 무엇인가 — CNCF.co.kr
• Kubernetes 기본 개념 — MSAP.ai
• Kubernetes Pod 헬스체크(probe) — OPENMARU
• Kakao Case Study — CNCF
• Kube-proxy Replacement — Cilium 공식
• eBPF란 무엇인가 — eBPF.io
• Considerations for large clusters — Kubernetes Docs
• Breaking the Chains of Kube-Proxy With Cilium — The New Stack
• 99.999%를 향한 집착: 멀티 & 하이브리드 클러스터 — 카카오페이 기술 블로그
• KRnet 2018 — Kakao Container Cloud DKOS (SlideShare)