쿠버네티스(K8s) 클러스터 아키텍처 - 마스터와 워커 노드의 완벽한 분업
핵심 인사이트 (3줄 요약)
- 본질: 쿠버네티스(K8s) 클러스터 아키텍처는 절대 권력을 쥔 브레인 사령탑인 **'컨트롤 플레인(Control Plane, 마스터 노드)'**과 그 사령탑의 지시를 받아 묵묵히 도커 컨테이너(Pod)를 짊어지고 나르는 수십 대의 노예 노동자 **'데이터 플레인(Data Plane, 워커 노드)'**으로 완벽하게 역할이 쪼개진(Decoupled) 분산 병렬 시스템이다.
- 가치: "웹 서버 5개를 돌려줘"라는 사용자의 yaml 명령서는 오직 마스터 노드(API Server)만 접수하며, 마스터는 어떤 워커 노드(CPU 여유분)에 짐을 던질지 계산(Scheduler)하고 감시(Controller)한다. 워커 노드가 번개를 맞아 불타 없어져도 마스터 노드는 즉시 다른 워커 노드에 5개의 웹 서버를 똑같이 부활시키는 기적의 **자가 치유(Self-Healing) 및 영원한 상태 유지(Desired State)**를 달성한다.
- 융합: 이 방대한 클러스터가 단일 생명체처럼 움직이기 위해, 마스터의 기억 저장소인 **etcd(분산 DB)**와 워커 노드의 현장 반장인 Kubelet, 그리고 트래픽 교통정리원인 Kube-proxy 등 여러 마이크로 컴포넌트들이 톱니바퀴처럼 융합되어 거대한 인프라 운영체제(Cloud OS)를 형성한다.
Ⅰ. 개요 및 필요성 (Context & Necessity)
-
개념: 쿠버네티스는 컴퓨터 1대에 까는 프로그램이 아니다. 수십 대의 서버 컴퓨터(EC2 등)를 한데 묶은 덩어리(Cluster)다. 이 서버 덩어리를 통제하기 위해, 1~3대의 서버를 '두뇌 전용(마스터 노드)'으로 떼어놓고, 나머지 97대의 서버를 '손발 전용(워커 노드)'으로 지정하여 극단적인 역할 분담을 세팅하는 것이 K8s 아키텍처의 핵심 뼈대다.
-
필요성: 만약 100대의 서버가 지휘관 없이 평등하게 묶여 있다면? 내가 "결제 컨테이너 1개 띄워"라고 명령할 때, 100대 서버가 서로 눈치를 보다가 동시에 띄우거나 아무도 안 띄우는 대혼돈(Split Brain)이 발생한다. 누군가는 100대의 CPU와 RAM 상태를 엑셀 장부(etcd)에 실시간으로 기록하고 꿰뚫고 있어야 하며(통제탑), 누군가는 불평 없이 배당된 컨테이너만 멍청하게 실행(노동자)해야 한다. 즉, 인프라의 무한 확장(Scale-out)과 고가용성을 보장하기 위해 '생각하는 자'와 '행동하는 자'를 물리적으로 분리하는 독재적 오케스트레이션 아키텍처가 절대적으로 필요했다.
-
💡 비유: 수백 명의 요리사가 일하는 최고급 대형 호텔 주방과 같습니다.
- 마스터 노드 (총괄 셰프 룸): 주방장(마스터)은 프라이팬(컨테이너)을 절대 직접 잡지 않습니다. 유리창 너머로 주문서(yaml)를 받고, "A 요리사는 한가하니까 스테이크 구워, B 요리사는 수프 끓여!"라고 지시만 내리고 장부(etcd)에 감시 기록만 철저히 적습니다.
- 워커 노드 (실제 주방 불판): 수십 명의 막내 요리사(워커)들입니다. 이들은 스스로 무슨 요리를 할지 결정할 권한이 없습니다. 주방장(마스터)이 무전기로 던져준 오더(Pod)만 받아서 묵묵히 불판에서 지지고 볶아 만들어내는(Run) 육체노동자들입니다.
-
등장 배경 및 발전 과정:
- 초기 모놀리식 통제 (2000년대): 한 대의 거대한 서버가 모든 걸 다 하려다 트래픽 폭발로 마더보드가 타버리는 스케일업(Scale-up)의 한계 봉착.
- Borg(구글)의 마스터-슬레이브 사상: 구글이 수십만 대의 서버를 통제하기 위해, 오직 상태만 관리하는 중앙 뇌(BorgMaster)와 명령만 실행하는 노드(Borglet) 아키텍처를 내부적으로 증명함.
- 쿠버네티스(K8s) 오픈소스화 (현재): 구글의 그 뼈대를 그대로 Go 언어로 재현하여 마스터 노드(Control Plane)와 워커 노드(Data Plane)라는 표준 아키텍처 용어로 정립, 전 세계 클라우드를 평정.
-
📢 섹션 요약 비유: 수만 명의 건설 노동자(워커 노드)들이 벽돌(컨테이너)을 나르는 공사장에서, 노동자들이 제멋대로 집을 짓지 못하게 언덕 꼭대기 텐트에 앉아 현장 도면(etcd)을 보며 "철수는 왼쪽, 영희는 오른쪽!"이라고 확성기로 쉴 새 없이 지휘하는 깐깐한 건설 현장 소장님(마스터 노드)의 완벽한 분업 체계입니다.
Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)
1. 마스터 노드 (Control Plane) - 두뇌 컴포넌트 4인방
마스터 노드는 사용자의 명령을 받고 워커들을 감시하는 4개의 뇌세포로 이루어져 있다.
┌───────────────────────────────────────────────────────────────┐
│ 🧠 컨트롤 플레인 (Master Node)의 4대 핵심 컴포넌트 아키텍처 │
├───────────────────────────────────────────────────────────────┤
│ │
│ ① [ Kube-API Server ] - K8s의 우체국이자 유일한 출입문 │
│ - 엔지니어가 `kubectl apply -f app.yaml`을 치면 제일 먼저 받는 놈. │
│ - 마스터 내부의 모든 컴포넌트도 무조건 얘를 거쳐서만 대화해야 함! 통제소!│
│ │
│ ② [ Etcd ] - 마스터의 영구 기억 저장소 (절대 잃어버리면 안 되는 장부)│
│ - "클러스터에 노드가 10대고, Nginx 팟 3개를 유지하기로 약속했다"는 │
│ 모든 '상태 정보(State)'와 '설정'이 JSON(Key-Value)으로 백업된 금고.│
│ - 🚨 Etcd 디스크가 타버리면? K8s는 즉시 기억상실증 좀비가 되어 멸망함. │
│ │
│ ③ [ Kube-Scheduler ] - 테트리스 달인 (배치 담당) │
│ - API 서버가 "야! 팟 1개 새로 띄워!"라고 하면, 스케줄러가 워커 노드 10대│
│ 중에서 CPU 넉넉하고 메모리 텅 빈 최적의 명당자리(노드)를 귀신같이 찍어줌.│
│ │
│ ④ [ Kube-Controller-Manager ] - 24시간 CCTV 감시자 (의사) │
│ - 끊임없이 Etcd 장부를 보고 "약속은 3개인데, 지금 워커 노드에 2개밖에 없네?"│
│ 라는 불일치를 발견하면, 즉시 API 서버에 "1개 더 만들어!"라고 호통치는 놈.│
└───────────────────────────────────────────────────────────────┘
2. 워커 노드 (Data Plane) - 노동자 컴포넌트 3인방
워커 노드는 마스터의 지시를 받아 실제로 도커 컨테이너를 띄우고 밥을 먹여주는 땀 흘리는 현장이다.
┌───────────────────────────────────────────────────────────────┐
│ 💪 데이터 플레인 (Worker Node)의 3대 핵심 컴포넌트 │
├───────────────────────────────────────────────────────────────┤
│ [ 워커 노드 서버 (예: EC2 인스턴스 1번) ] │
│ │
│ ① [ Kubelet ] - 현장 십장 (작업 반장) │
│ - 마스터(API 서버)가 "너희 노드에 Nginx 팟 1개 띄워라"고 명령하면 접수함.│
│ - 아래의 런타임에게 망치질을 지시하고, "팟 잘 살아있습니다!" 하고 마스터에│
│ 보고(Heartbeat)를 올리는 K8s의 가장 핵심적인 현장 프락치 대리인. │
│ │
│ ② [ Container Runtime ] - 철창 용접공 (예: containerd, runc) │
│ - Kubelet이 지시하면, 진짜 리눅스 커널에 도커/컨테이너 감옥(Namespace)을 │
│ 뚝딱뚝딱 용접해서 띄우고 프로세스를 격리시켜 버리는 찐 행동대장 엔진. │
│ │
│ ③ [ Kube-Proxy ] - 교통 경찰 (네트워크 통신망) │
│ - 워커 노드 안에 띄워진 팟(Pod)들이 서로 통신하거나, 외부 손님이 접속할 때 │
│ IP 패킷의 길을 안내하고 방화벽 룰(iptables)을 조작해 주는 트래픽 조절자.│
└───────────────────────────────────────────────────────────────┘
Ⅲ. 실무 적용 및 기술사적 판단
실무 시나리오
-
시나리오 — 워커 노드 대형 화재 시 컨트롤 플레인의 '자가 치유(Self-Healing)' 콤보 작렬: 새벽 3시, 100대의 워커 노드 중 웹 서버 컨테이너 5개가 이쁘게 떠 있던 **'워커 노드 7번'**의 파워 서플라이가 터져 서버가 통째로 즉사했다. 엔지니어는 쿨쿨 자고 있다. 무슨 일이 일어날까?
- 동작 1 (감지): 마스터 노드의
Controller-Manager가 7번 노드의Kubelet으로부터 5분 넘게 생존 보고(Heartbeat)가 안 올라오는 것을 눈치챈다. "7번 노드 죽었군. 거기 있던 팟 5개도 다 죽었네." - 동작 2 (명령): 컨트롤러는
Etcd장부를 본다. "원래 목표는 5개 유진데 지금 0개네!" 컨트롤러는 즉시API Server에 "팟 5개 당장 새로 만들어!"라고 요청한다. - 동작 3 (배치): 마스터의
Scheduler가 작동한다. "살아남은 99대 노드 중에 어디가 널널하지? 오케이, 12번 노드랑 45번 노드에 쪼개서 넣자!" - 동작 4 (실행): 12번, 45번 노드의 현장 반장
Kubelet이 마스터의 명령을 받고 하청업체(Containerd)를 조인트 까서 0.1초 만에 죽었던 웹 서버 5개를 완벽하게 부활시킨다. 아침 9시에 출근한 엔지니어는 밤새 서버가 죽었다 살아난 사실조차 모른 채 평화로운 대시보드를 보며 커피를 마신다. 이것이 선언적(Declarative) K8s 아키텍처의 위대한 치유 마술이다.
- 동작 1 (감지): 마스터 노드의
-
시나리오 — 마스터 노드 단일 장애점(SPOF)의 붕괴 (K8s The Hard Way의 참사): 스타트업 개발자가 클라우드 요금 아끼겠다고 서버 3대를 빌려서 K8s를 깔았다. 1대는 마스터 노드, 2대는 워커 노드로 구성했다(Single Master). 한 달 뒤 마스터 노드 서버의 RAM이 터지며 커널 패닉이 났다. 워커 노드 2대에 있던 컨테이너들은 잘 돌고 있었지만, 새로운 컨테이너를 배포하려
kubectl apply를 쳤더니 "API Server 뻗음" 에러가 났다. 마스터가 죽으니 클러스터 전체가 수술 불가능한 마비 상태가 되었다.- 판단: 컨트롤 플레인(Control Plane)은 K8s의 신이다. 신이 1명(Single)뿐인데 죽어버리면 클러스터는 끝이다. 마스터 노드 다중화(HA) 아키텍처를 세우지 않은 인프라 오판이다.
- 해결책: 마스터 노드는 절대로 1대로 구성하면 안 된다. 반드시 3대 이상의 홀수 개수(Quorum 룰)로 마스터 노드 다중화(High Availability) 셋팅을 묶어둬야 1대가 뻗어도
Etcd리더 선출이 살아남아 뇌사 상태를 막을 수 있다. 그러나 이 다중화 세팅이 지옥같이 어렵기 때문에, 대다수의 현명한 아키텍트들은 직접 마스터 노드를 설치하지 않고 AWS에게 돈을 갖다 바치며 **EKS, GKE (완전 관리형 컨트롤 플레인)**를 사서 쓴다. (AWS가 마스터 노드 3대를 뒤에서 절대 안 죽게 관리해 주므로, 우리는 워커 노드만 붙여서 신경 끄고 편하게 쓴다).
도입 체크리스트
- Kube-proxy의 iptables 병목 (Scale 이슈): 워커 노드가 1,000대, 파드가 1만 개로 미친 듯이 늘어나는 거대 은행/게임사인가? Kube-proxy는 태생적으로 트래픽 길을 터줄 때 리눅스의 구형 방화벽 규칙인
iptables를 수만 줄씩 떡칠해서 트래픽을 통제한다. 파드가 1만 개가 넘어가면 iptables 룰을 읽느라 CPU가 박살 나며 네트워크 레이턴시가 폭발한다. 초대형 클러스터 설계 시에는 Kube-proxy의 iptables 모드를 과감히 버리고, 차세대 커널 네트워크 기술인 IPVS나 Cilium/eBPF 기반의 네트워크 플러그인(CNI)으로 심장을 갈아 끼우는 고급 아키텍처 튜닝이 필수 도래한다.
Ⅳ. 기대효과 및 결론
정량/정성 기대효과
| 구분 | 레거시 도커 단일 노드 운영 | K8s 마스터-워커 분업 클러스터 아키텍처 | 인프라 운영 혁신 효과 |
|---|---|---|---|
| 정량 (확장성/스케일 아웃) | 서버 터지면 인간이 다른 서버에 수동 복사 세팅 | 마스터가 워커 1,000대에 알아서 컨테이너 분배 | 트래픽 폭증 시 Auto Scaling 대응력 무한대 펌핑 |
| 정량 (장애 복구 시간) | 노드 사망 시 복구 및 IP 재할당에 2~3시간 소요 | 마스터의 컨트롤 루프 감지로 0.1초 내 부활 셋팅 | 하드웨어 장애 대비 서비스 다운타임 제로(0)화 |
| 정성 (운영 철학의 진화) | 100대 서버 접속해 명령(명령적, Imperative) | 야믈(yaml) 던지고 K8s 뇌에 위임 (선언적, Declarative) | 엔지니어가 잡무에서 해방되는 완벽한 IaC 자동화 유토피아 |
"황제(Master)는 현장에 나가지 않고 전장을 내려다보며 펜만 굴리고, 병사(Worker)는 머리를 비우고 오직 칼집에서 칼만 뺀다." 쿠버네티스의 마스터-워커 노드 아키텍처는 IT 역사상 가장 완벽하고 잔혹하게 구현된 마키아벨리적 분업 시스템이다. 마스터의 절대적인 기억(etcd)과 무자비한 감시 컨트롤 루프(Controller)가 있는 한, 워커 노드 수십 대가 물리적으로 불타 없어져도 클라우드의 논리적 상태(Desired State)는 단 한 줌도 훼손되지 않는다. 기술사는 K8s라는 이름의 화려함에 취하기보다, 그 이면에 돌아가는 **API 서버(입) - Etcd(뇌) - 스케줄러(눈) - 큐블릿(손발)**의 무시무시한 생체공학적 톱니바퀴를 꿰뚫어 보며 절대 죽지 않는 불멸의 백엔드 인프라를 지휘하는 군단장이 되어야 한다.
📌 관련 개념 맵 (Knowledge Graph)
| 개념 명칭 | 관계 및 시너지 설명 |
|---|---|
| Kube-API Server | K8s 마스터 노드의 입구이자 경비실. 관리자가 날린 kubectl 명령어든, Kubelet의 보고서든 무조건 이 녀석을 거치지 않으면 마스터 노드 내부에 절대 출입할 수 없는 1급 통제소. |
| Etcd (엣씨디) | 마스터 노드의 가장 깊은 곳에 숨어있는 황금 금고(분산 Key-Value DB). K8s 클러스터의 모든 비밀, 상태, 설정 파일이 저장되며 이것만 날아가면 K8s는 즉시 치매에 걸려 붕괴된다. |
| Kubelet (큐블릿) | 워커 노드마다 1개씩 파견 나가 있는 마스터 노드의 현장 대리인(십장). 마스터가 "컨테이너 띄워라!" 명령하면 리눅스 런타임에게 망치질을 지시하고 감시하는 핵심 스파이. |
| Kube-proxy (큐브프록시) | 워커 노드에 띄워진 수십 개의 파드(웹, DB)들이 외부 인터넷이나 서로 통신할 수 있게, 리눅스 커널 방화벽(iptables)을 실시간으로 조작해 길을 열어주는 신호등 교통경찰. |
| EKS / GKE / AKS | 더럽게 셋팅하기 힘들고 터지기 쉬운 마스터 노드(Control Plane) 관리를 AWS, 구글이 알아서 다 해주고 돈을 뜯어가는 클라우드 관리형 K8s 상품들. 실무 아키텍트들의 구원자. |
👶 어린이를 위한 3줄 비유 설명
- 1,000명의 일꾼 로봇(워커 노드)이 짐(컨테이너)을 나르는 엄청나게 큰 공사장이 있어요. 로봇들이 자기 마음대로 움직이면 집이 엉망진창으로 지어지겠죠?
- 그래서 언덕 위에 텐트를 치고 똑똑한 **'공사 소장님 세트(마스터 노드)'**를 모셔왔어요! [설계도 보관함(etcd)], [명령 내리는 마이크(API)], [로봇 감시 CCTV(Controller)]가 다 모여있는 두뇌 지휘통제실이죠.
- 소장님이 언덕에서 쳐다보다가 로봇 하나가 고장 나서 쓰러지면? 마이크로 "야! 저기 고장 났으니 새 로봇 출동해서 짐 다시 날라라!"라고 1초 만에 척척 지휘해서 공사장을 완벽하게 굴려주는 위대한 분업 마술이랍니다!