쿠버네티스(Kubernetes) 쉽게 이해하기 — SW 레이어 어디에서 어떻게 작동하나

쿠버네티스(Kubernetes) 쉽게 이해하기 — SW 레이어 어디에서 어떻게 작동하나

OS 위·애플리케이션 아래에 사는 오케스트레이션 미들웨어, 30분 만에 큰 그림 잡기

"쿠버네티스(Kubernetes)" 단어만 들어도 머리가 복잡해지는 분들이 많습니다. 클라우드, 컨테이너, 오케스트레이션… 용어는 많은데 정작 "내 컴퓨터의 어느 층에서, 무엇을 대신 해주는 도구인가"는 잘 안 와닿죠. 이 글은 쿠버네티스를 SW 스택(소프트웨어 계층) 관점에서 한 번에 정리합니다. 비유 → 위치 → 동작 흐름 순서로 읽으면 30분 안에 큰 그림이 잡힙니다.

쿠버네티스, 한 문장으로 말하면

쿠버네티스는 "수십~수천 개의 컨테이너를 사람 대신 자동으로 굴려주는 운영체제 같은 소프트웨어"입니다. Google이 자사의 대규모 서비스를 운영하면서 만들었던 내부 도구(Borg)를 오픈소스화한 것이고, 줄여서 K8s라고 씁니다. (K와 s 사이에 글자가 8개라서 K8s)

핵심 역할은 단순합니다. "이 앱을 3개 띄워줘"라고 말하면, 어느 서버에 띄울지 골라주고, 죽으면 다시 살리고, 트래픽이 몰리면 자동으로 늘려주는 것. 사람이 하던 일을 선언적(declarative)으로 자동화한 게 전부입니다.

아주 짧은 비유 — Docker가 "음식을 도시락에 담는 도구"라면, 쿠버네티스는 "수백 개 도시락을 매장 수십 곳에 배달하고, 떨어지면 다시 채워주고, 손님 몰리면 매장 늘리는 본사 시스템"입니다. 도시락(컨테이너)을 만드는 도구와 도시락을 운영·배포하는 도구는 역할이 다릅니다.

SW 레이어 어디에 위치하나 — 이게 핵심

많은 분들이 헷갈리는 지점이 바로 이겁니다. 쿠버네티스는 OS도 아니고, 애플리케이션도 아닌, 그 사이에 끼어 있는 "오케스트레이션 레이어"입니다. 아래 스택을 보면 한 번에 정리됩니다.

L5 · Application

웹앱 / API / DB / AI 모델 등 실제 서비스

▲ 쿠버네티스가 "관리"하는 대상

L4 · Orchestration

⭐ Kubernetes (스케줄링·자가치유·확장·네트워크 추상화)

▲ 쿠버네티스가 "명령"을 내리는 대상

L3 · Container Runtime

containerd / CRI-O / Docker Engine

▲ 컨테이너 런타임이 "사용"하는 기능

L2 · Operating System

Linux 커널 (namespace, cgroups, network stack)

▲

L1 · Hardware

물리/가상 서버 — CPU, 메모리, 디스크, NIC

이 그림에서 한 가지만 기억하시면 됩니다. 쿠버네티스는 "OS 위, 애플리케이션 아래"에 사는 미들웨어입니다. 컨테이너를 직접 만들지도, 직접 실행하지도 않습니다. "실행해줘"라고 명령만 내리고, 실제 실행은 아래 계층(컨테이너 런타임 → OS 커널)이 맡습니다.

각 레이어가 실제로 뭘 하는가

L1 · 하드웨어 — 물리적 자원

그냥 서버입니다. CPU, RAM, 디스크, 네트워크 카드. 클라우드라면 AWS EC2, GCP Compute Engine 같은 가상머신이 여기 해당합니다. 쿠버네티스 입장에서는 이걸 "노드(Node)"라는 단위로 추상화해서 인식합니다.

L2 · OS / Linux 커널 — 진짜 격리는 여기서 일어난다

의외로 많은 분들이 모르고 넘어가는 사실인데, 컨테이너 격리 기술 자체는 쿠버네티스나 Docker의 발명품이 아닙니다. 리눅스 커널이 가진 두 가지 기능을 활용한 것뿐이에요.

• Namespace — 프로세스, 네트워크, 파일시스템, 사용자 등을 격리. "다른 프로세스가 안 보이게" 만들어줌
• cgroups (control groups) — CPU·메모리·I/O 사용량 제한. "이 프로세스는 CPU 0.5코어, RAM 512MB만 써" 같은 제약

이 두 가지가 컨테이너의 본질입니다. 위 계층들은 전부 이걸 편하게 쓰기 위한 포장지에 가깝습니다.

L3 · 컨테이너 런타임 — 실제로 컨테이너를 띄우는 일꾼

커널의 namespace·cgroups를 매번 직접 호출하기는 너무 번거롭습니다. 그래서 containerd, CRI-O, Docker Engine 같은 런타임이 이걸 추상화해서 "이미지 받아와서 컨테이너 실행해줘" 한 줄로 처리할 수 있게 해줍니다.

중요한 점 — 쿠버네티스는 컨테이너를 직접 실행하지 않습니다. CRI(Container Runtime Interface)라는 표준 인터페이스를 통해 런타임에게 "띄워달라"고 요청만 합니다. 그래서 런타임은 갈아 끼울 수 있어요. (실제로 K8s 1.24부터는 Docker Engine 직접 지원이 빠지고 containerd가 표준이 됨)

L4 · Kubernetes — 이 글의 주인공

여기가 쿠버네티스가 사는 층입니다. 하는 일을 한 줄씩 정리하면:

• 스케줄링 — "어느 노드에 띄울까?"를 자원 상태 보고 자동 결정
• 자가 치유(Self-healing) — 컨테이너가 죽으면 자동으로 다시 띄움
• 스케일링 — CPU 사용률 70% 넘으면 알아서 복제본 늘리기
• 롤아웃·롤백 — 새 버전 배포 중 문제 생기면 이전 버전으로 자동 복귀
• 서비스 디스커버리·로드밸런싱 — 컨테이너 IP 바뀌어도 이름으로 찾을 수 있게
• 비밀 관리·설정 주입 — 비밀번호, 환경변수를 안전하게 컨테이너에 전달

L5 · 애플리케이션 — 우리가 만드는 코드

웹서버, API, AI 추론 서버, DB, 메시지 큐. 쿠버네티스 입장에서는 그냥 "컨테이너 이미지"일 뿐입니다. 안에 뭐가 들었는지는 관심 없고, "몇 개 띄울지, 자원 얼마 줄지, 외부에 노출할지"만 봅니다.

쿠버네티스 내부 구조 — Control Plane vs Worker Node

쿠버네티스 클러스터는 두 종류의 노드로 구성됩니다. Control Plane(두뇌)과 Worker Node(일꾼)입니다.

구분	Control Plane	Worker Node
역할	의사결정·관리	실제 컨테이너 실행
핵심 컴포넌트	API Server, Scheduler, Controller Manager, etcd	kubelet, kube-proxy, Container Runtime
비유하자면	회사의 본사·임원진	현장 매장·직원
장애 시	새 명령은 못 받지만 기존 컨테이너는 계속 동작	해당 노드의 컨테이너만 다른 노드로 재배치

Control Plane의 4대 컴포넌트

• kube-apiserver — 모든 명령의 입구. 사용자도, 내부 컴포넌트도 전부 이 API를 거쳐 통신
• etcd — 클러스터의 모든 상태를 저장하는 분산 키-값 DB. "현재 진실의 원본"
• kube-scheduler — 새로 만들어진 Pod를 어느 노드에 배치할지 결정
• kube-controller-manager — "원하는 상태"와 "현재 상태"를 끊임없이 비교하며 차이를 메우는 일꾼

Worker Node의 핵심 컴포넌트

• kubelet — 노드에서 일하는 에이전트. API Server의 명령을 받아 컨테이너 런타임에게 "이거 띄워라" 전달
• kube-proxy — 노드 안 네트워크 규칙을 관리. 서비스 IP를 실제 Pod로 라우팅
• Container Runtime — 실제 컨테이너를 띄우는 containerd 등

실제 동작 흐름 — "Pod 하나 띄워줘"가 일어나는 순서

"이미지 nginx로 Pod 하나 띄워줘"라고 명령했을 때 내부에서 무슨 일이 벌어지는지 따라가 보겠습니다.

1

사용자가 kubectl apply 명령으로 YAML 매니페스트를 제출

2

kube-apiserver가 요청을 받아 검증하고 etcd에 "이런 Pod가 필요하다"고 기록

3

kube-scheduler가 etcd 변경을 감지 → 자원 여유 있는 노드를 골라 "Node A에 배치" 결정

4

Node A의 kubelet이 자기에게 할당된 Pod를 발견 → 컨테이너 런타임에게 명령 전달

5

containerd가 nginx 이미지를 받아와서 namespace + cgroups로 컨테이너 생성

6

kubelet이 "Pod 잘 떴다"고 API Server에 보고 → etcd 상태 업데이트

7

이후로도 controller들이 "원하는 3개" vs "실제 3개"를 계속 비교하며 차이가 생기면 즉시 보정

이 7단계 흐름에서 핵심은 "선언적(declarative) 모델"입니다. 사용자는 "최종 상태"만 말하고, 쿠버네티스가 "거기까지 가는 방법"을 알아서 처리합니다. 명령형(imperative)으로 "이거 해라, 저거 해라"를 일일이 쓰지 않아도 되는 거죠. 이게 쿠버네티스의 가장 강력한 설계 철학입니다.

핵심 오브젝트 5가지만 알면 90% 이해

Pod — 가장 작은 배포 단위

컨테이너 1개(혹은 강하게 묶인 여러 개)를 감싸는 껍데기입니다. 쿠버네티스는 컨테이너를 직접 다루지 않고, 항상 Pod 단위로 다룹니다. 같은 Pod 안 컨테이너들은 IP와 볼륨을 공유합니다.

Deployment — Pod를 몇 개로 유지할지 정의

"이 Pod를 항상 3개 띄워둬"를 선언하는 오브젝트. 하나가 죽으면 자동으로 새 Pod를 만들어 3개를 유지합니다. 새 버전 배포 시 무중단 롤링 업데이트도 여기가 담당합니다.

Service — Pod에 접근하는 안정적 주소

Pod는 죽고 살아나면서 IP가 계속 바뀝니다. Service는 그 앞에 안정적인 가상 IP/DNS 이름을 붙여주는 추상화입니다. 트래픽을 여러 Pod에 분산하는 로드밸런서 역할도 합니다.

ConfigMap / Secret — 설정과 비밀 분리

코드와 설정을 분리하는 정석적인 방법. ConfigMap은 일반 설정, Secret은 민감 정보(비밀번호, 토큰)를 담아 컨테이너에 환경변수나 파일로 주입합니다.

Ingress — 외부에서 들어오는 HTTP 트래픽 처리

도메인 기반으로 "api.example.com은 A 서비스로, web.example.com은 B 서비스로" 라우팅하는 7계층 게이트웨이. 사실상 클러스터의 정문입니다.

Docker만 쓰면 안 되나? — 쿠버네티스가 필요한 진짜 이유

"그냥 Docker로 띄우면 되는 거 아닌가?"라는 질문, 정말 자주 나옵니다. 답은 "규모가 작으면 Docker로 충분하고, 커지는 순간 쿠버네티스가 사실상 필수"입니다.

Docker만 썼을 때 부딪히는 벽
서버가 1대일 땐 docker run이면 끝납니다. 그런데 서버가 10대, 컨테이너가 100개로 늘어나면 — 어느 서버에 띄울지 누가 결정하나? 컨테이너 죽으면 누가 살리나? 트래픽 늘면 누가 복제하나? 새 버전 배포는? 비밀번호 관리는? 이걸 사람이 다 손으로 하면 회사 망합니다. 쿠버네티스는 정확히 이 문제들을 풀려고 만들어진 도구입니다.

언제 쓰고 언제 안 써도 되나

쿠버네티스가 어울리는 상황

• 마이크로서비스 아키텍처 — 서비스가 10개 이상으로 쪼개져 있는 경우
• 트래픽 변동이 크고 자동 확장이 필요한 경우
• 여러 환경(dev/stg/prod)에 동일한 인프라를 일관되게 유지해야 할 때
• 멀티 클라우드·하이브리드 클라우드 전략을 쓰는 조직

오히려 과한 경우

• 1인 개발 / 토이 프로젝트 — 학습 비용이 효용을 압도
• 모놀리식 앱 1~2개 — Docker Compose나 PaaS(Heroku, Cloud Run, Fly.io)가 훨씬 합리적
• 운영 인력이 부족한 소규모 팀 — 관리형 K8s(EKS, GKE, AKS)를 쓰더라도 학습곡선은 상당함

현실적인 조언 — 쿠버네티스는 "복잡함을 더하는 도구"가 아니라 "복잡함을 다루기 위한 도구"입니다. 복잡함이 없으면 굳이 도입할 이유가 없습니다. 반대로 이미 컨테이너가 수십 개, 서버가 여러 대인데 손으로 관리 중이라면 — 이미 도입이 늦은 겁니다.

정리 — 한 페이지로 끝내는 쿠버네티스

이 글에서 딱 5가지만 가져가시면 됩니다.

1. 위치 — 쿠버네티스는 OS 위, 애플리케이션 아래에 사는 오케스트레이션 레이어. 컨테이너를 직접 실행하지 않고 명령만 내림
2. 실제 격리 — 컨테이너의 본질은 리눅스 커널의 namespace + cgroups. 쿠버네티스는 이걸 대규모로 관리하는 상위 도구
3. 구성 — Control Plane(두뇌)과 Worker Node(일꾼). API Server·etcd·Scheduler·Controller가 핵심
4. 철학 — 선언적 모델. 사용자는 "원하는 상태"만 말하고 K8s가 "현재 상태"를 거기에 맞춤
5. 가치 — 자가치유, 자동확장, 무중단 배포, 서비스 디스커버리. 사람이 하던 운영 작업을 자동화한 게 본질

처음에는 용어가 많아 어렵게 느껴지지만, "OS 위·앱 아래에서 컨테이너 무리를 자동으로 굴려주는 미들웨어"라는 한 줄만 머릿속에 자리 잡으면 그다음부터는 빠르게 풀립니다. 다음 글에서는 실제로 minikube로 로컬에서 클러스터를 띄우고 첫 Pod를 배포하는 실습을 다뤄보겠습니다.

#쿠버네티스 #Kubernetes #K8s #컨테이너오케스트레이션 #도커 #클라우드네이티브 #DevOps #마이크로서비스 #쿠버네티스기초 #컨테이너런타임