쿠버네티스란 무엇인가 — 개념·도커 차이·설치·자격증 정리

목차 (Agenda)

TL;DR — 쿠버네티스는 여러 서버에 흩어진 컨테이너의 배포·확장·복구를 자동으로 관리하는 오픈소스 컨테이너 오케스트레이션 플랫폼입니다.

2014년 공개된 쿠버네티스는 이제 프로덕션 표준으로 자리 잡았지만, 도입을 검토하는 담당자에게는 용어부터 벽입니다. 이 글은 정의와 도커와의 차이, 도커 지원 중단 논란, 설치 방법과 자격증 취득 단계를 판단에 필요한 만큼만 정리하기 위해 썼습니다. 더 깊은 주제는 각 절 끝의 링크로 이어집니다.

Kubernetes 도입·운영, 전문가와 상담하세요

프로덕션 Kubernetes 도입부터 안정화까지 — Cloud Native Forum 전문가가 무료 상담으로 함께합니다.

Kubernetes 도입 문의하기 →

쿠버네티스란 무엇인가?

쿠버네티스는 여러 대의 서버를 하나의 자원 풀로 묶고, 그 위에서 컨테이너를 배포하고 확장하고 복구하는 일을 자동으로 처리하는 오픈소스 플랫폼입니다. 운영자가 서버 한 대씩 골라 프로세스를 띄우는 대신, “이 애플리케이션을 3벌 유지하라”처럼 원하는 상태를 선언하면 이 플랫폼이 그 상태를 계속 맞춰 줍니다.

이름은 그리스어 κυβερνήτης에서 왔고 배의 키를 잡는 조타수를 뜻합니다. 컨테이너라는 화물을 실은 배들을 항구로 이끈다는 뜻이 담겨 있습니다. 클라우드 네이티브 생태계에서 헬름(Helm, 키의 손잡이) 같은 항해 용어가 자주 보이는 것도 같은 맥락입니다. 줄여서 K8s 라고 쓰는데, K와 s 사이에 글자가 여덟 개라서 붙은 표기입니다.

기술적 뿌리는 구글에 있습니다. 구글은 검색·지메일 같은 대규모 서비스를 운영하려고 보그(Borg) 라는 내부 클러스터 관리 시스템을 오래 써 왔고, 파드(Pod)·서비스(Service)·레이블(Label) 같은 핵심 개념 상당수가 그 운영 경험에서 나왔습니다(Aqua Security, “The History of Kubernetes”). 구글은 이 노하우를 오픈소스로 다시 구현해 2014년 6월 6일 쿠버네티스를 공개했고, 2015년 1.0 릴리스와 함께 리눅스 재단 산하 CNCF(Cloud Native Computing Foundation) 에 기증했습니다. CNCF의 첫 프로젝트였고 2018년 3월 처음으로 ‘졸업(Graduated)’ 등급에 올랐습니다.

정리하면 이 플랫폼은 특정 회사의 제품이 아니라 중립 재단이 관리하는 공동 자산이고, 그래서 특정 벤더에 묶이지 않고 온프레미스와 퍼블릭 클라우드 어디에서나 같은 방식으로 운영할 수 있습니다.

글보다 영상이 편하다면 아래 재생목록에서 클라우드네이티브TV 의 쿠버네티스 영상(입문·운영·보안)을 이어서 보실 수 있습니다.

탄생 과정을 더 따라가고 싶다면 쿠버네티스의 시작과 클라우드 네이티브와의 관계에서 구글 보그부터 재단 이관까지의 흐름을 정리해 두었습니다. 왜 이 방식이 필요해졌는지는 컨테이너 혁명의 배경에서 데이터센터 운영 관점으로 다룹니다.

경량 쿠버네티스 배포판

k3s로 시작하는 가벼운 쿠버네티스

엣지·개발·소규모 환경이라면 풀 쿠버네티스가 부담스러울 수 있습니다.

메모리 512MB로도 도는 경량 배포판 k3s의 개요와 특징, 언제 쓰면 좋은지 한 번에 정리했습니다.

k3s 개요와 특징 보러 가기

컨테이너와 쿠버네티스는 무엇이 다른가?

컨테이너는 애플리케이션을 실행 환경째 담는 패키징·실행 단위이고, 쿠버네티스는 그 컨테이너를 여러 서버에 걸쳐 운영하는 체계입니다. 층이 다르기 때문에 둘을 비교해 하나를 고르는 관계가 아닙니다.

컨테이너는 애플리케이션 코드와 라이브러리, 런타임을 한 덩어리로 묶습니다. 그래서 개발자 노트북에서 동작한 것이 테스트 서버와 운영 서버에서도 같게 동작합니다. 가상 머신과 달리 운영체제 커널을 호스트와 공유하므로 기동이 초 단위로 빠르고 같은 하드웨어에 더 많이 올릴 수 있습니다.

문제는 그다음입니다. 컨테이너 한두 개는 손으로 띄울 수 있지만, 수십 대 서버에 수백 개가 흩어지면 어느 서버에 배치할지, 죽으면 누가 살릴지, 트래픽이 몰리면 몇 개로 늘릴지를 사람이 판단할 수 없습니다. 이 운영 문제를 정하는 규칙과 자동화가 쿠버네티스입니다.

컨테이너: 무엇을 어떻게 패키징하고 실행할 것인가
컨테이너 런타임(containerd·CRI-O): 컨테이너를 실제로 띄우는 실행기
쿠버네티스: 여러 서버 위에서 그 컨테이너들을 배치·유지·확장하는 운영 체계

더 자세한 구분은 컨테이너와 쿠버네티스 — 각각의 역할과 함께 쓰는 이유와 컨테이너 런타임이란? containerd·CRI-O·Docker 비교에서 이어 볼 수 있습니다.

런타임 표준이 어떻게 나뉘는지는 컨테이너 기술 표준 정리에서 CRI-O 와 runC 의 역할 차이로 설명합니다. 이 구분을 알아 두면 다음 절의 도커 지원 중단 이야기가 훨씬 단순해집니다.

도커와 쿠버네티스는 어떻게 다른가?

도커는 컨테이너를 만들고 한 대에서 실행하는 도구이고, 쿠버네티스는 그렇게 만든 컨테이너를 여러 대에서 대규모로 운영하는 도구입니다. 경쟁 관계가 아니라 역할이 다른 층이고, 실무에서는 대개 함께 씁니다.

구분	도커 (Docker)	쿠버네티스 (Kubernetes)
핵심 역할	컨테이너 이미지 생성과 단일 호스트 실행	다수 컨테이너의 자동 배치와 운영
관리 단위	컨테이너 1개	파드·디플로이먼트·서비스
확장 방식	사람이 직접 추가 실행	선언한 개수·부하 기준으로 자동 확장
장애 대응	사람이 재실행	상태를 감지해 자동 재생성
적합한 자리	개발·빌드·소규모 실행	프로덕션 다중 서버 운영

개발자는 여전히 로컬에서 도커로 이미지를 만들고, 그 이미지를 레지스트리에 올리고, K8s가 그것을 클러스터에 배포합니다. 이미지를 만드는 도구와 이미지를 운영하는 플랫폼이 나뉘어 있을 뿐입니다.

항목별 비교는 쿠버네티스 vs 도커 차이 완벽 정리에서 더 깊게 다룹니다.

쿠버네티스가 도커 지원을 중단했다는 말의 진실은?

쿠버네티스가 제거한 것은 도커 엔진을 컨테이너 런타임으로 연결하던 어댑터(dockershim)이지, 도커로 만든 이미지가 아닙니다. 검색에서 자주 보이는 “쿠버네티스 도커 지원 중단”은 이 한 문장으로 정리됩니다.

배경은 이렇습니다. 초기 쿠버네티스는 도커만 지원했지만, 이후 여러 런타임을 붙일 수 있도록 CRI(Container Runtime Interface) 표준이 생겼습니다. 도커 엔진은 이 CRI를 구현하지 않았기 때문에 이 어댑터, 곧 dockershim 을 프로젝트가 직접 유지해야 했습니다. 이 유지 부담을 정리하려고 v1.20에서 폐기를 예고하고 v1.24에서 실제로 제거했습니다(Kubernetes, “Dockershim Removal FAQ”, 2022-02-17).

실무에서 달라지는 것은 다음과 같습니다.

이미지는 그대로 동작합니다. 도커로 빌드한 이미지는 OCI(Open Container Initiative) 표준을 따르므로 containerd·CRI-O 같은 CRI 호환 런타임에서 그대로 실행됩니다.
바뀐 것은 클러스터 운영자 쪽입니다. 노드의 런타임을 containerd 또는 CRI-O 로 옮기면 됩니다. 오늘 새로 설치하는 배포판은 대부분 containerd를 기본으로 씁니다.
개발자 작업은 영향을 받지 않습니다. Docker Desktop과 docker 명령으로 이미지를 빌드하고 푸시하는 흐름은 그대로입니다.

즉 도커를 계속 써도 됩니다. 바꿔야 하는 것은 노드에서 컨테이너를 실제로 띄우는 실행기뿐입니다.

쿠버네티스는 어떻게 동작하는가?

운영자가 원하는 상태를 선언하면, 컨트롤 플레인이 현재 상태와의 차이를 계속 메워 목표 상태로 수렴시킵니다. 이 반복 과정을 리컨실 루프(reconciliation loop) 라고 부르고, 쿠버네티스의 거의 모든 동작이 여기서 나옵니다.

클러스터는 크게 두 부분입니다.

컨트롤 플레인: 요청을 받는 API 서버, 파드를 어느 노드에 놓을지 정하는 스케줄러, 목표 상태를 지키는 컨트롤러 매니저, 클러스터 상태를 저장하는 etcd
워커 노드: 노드에서 파드를 띄우고 상태를 보고하는 kubelet, 컨테이너를 실제 실행하는 런타임, 네트워크를 담당하는 프록시

배포 단위는 컨테이너가 아니라 파드(Pod) 입니다. 파드는 하나 이상의 컨테이너가 네트워크와 저장소를 공유하는 최소 실행 단위이며, 파드를 개별적으로 고치지 않고 버리고 새로 만드는 방식으로 관리합니다.

예를 들어 “이 애플리케이션을 3벌 유지하라”고 선언하면, 노드 한 대가 내려가 파드가 2벌로 줄었을 때 컨트롤러가 차이를 감지해 남은 노드에 한 벌을 다시 만듭니다. 사람이 새벽에 깨서 복구하지 않아도 되는 이유가 이 구조입니다.

구조를 더 파고들려면 쿠버네티스 아키텍처 완벽 정리와 쿠버네티스 Pod란? 개념·생명주기·멀티컨테이너 패턴를 함께 보시기 바랍니다.

구성 요소를 하나씩 짚어 보려면 클러스터 구성 요소와 기본 배포 단위인 파드를 차례로 읽는 편이 빠릅니다. 선언형 API 가 자동화로 이어지는 지점은 선언적 API와 자동화에서 따로 다룹니다.

무엇을 해결해 주는가?

쿠버네티스가 주는 것은 기능 하나가 아니라 운영 부담의 이동입니다. 사람이 지켜보며 처리하던 일을 규칙으로 옮깁니다.

자가 치유(Self-healing): 프로세스가 죽거나 노드가 빠지면 선언한 개수를 다시 채웁니다. 장애 대응의 1차 조치가 자동으로 일어납니다.
오토스케일링: 부하 지표를 기준으로 파드 수를 늘리고 줄입니다. 트래픽이 몰리는 시간대에만 자원을 더 쓰고 평소에는 줄일 수 있습니다.
무중단 배포: 새 버전을 조금씩 교체하는 롤링 업데이트, 일부 트래픽만 새 버전으로 보내는 카나리, 두 벌을 두고 전환하는 블루/그린 이 표준 동작으로 제공됩니다. 문제가 보이면 이전 버전으로 되돌립니다.
자원 효율: 여러 서버를 하나의 풀로 보고 빈 자리에 배치하므로 서버마다 남기던 여유 자원을 줄일 수 있습니다.

배포 전략은 롤링 업데이트 · 카나리 배포 · 블루/그린 배포 세 편에서 각각 다룹니다.

자동 확장은 마법이 아니라 지표를 읽고 개수를 고치는 절차입니다. 각 파드의 사용량을 모아 목표값과 견준 뒤 복제 수를 바꾸고, 값이 출렁이지 않도록 줄일 때는 일정 시간을 기다립니다.

그림. 자동 확장의 네 단계 — 상한과 하한을 정하지 않으면 클러스터 자원을 한 번에 소모할 수 있다.

설치와 시작하기, 세 갈래 경로

처음이라면 노트북에 경량 배포판 한 벌을 올리는 것이 가장 빠른 출발점입니다. 설치 방법은 목적에 따라 세 갈래로 갈립니다.

경로	무엇으로	준비 부담	적합한 상황
학습·개발	k3s, kind, minikube	낮음(노트북 1대)	개념 확인, 기능 실습
온프레미스 구축	kubeadm, RKE2, k3s	높음(설계·운영 필요)	사내 인프라, 규제·망 분리
매니지드 서비스	EKS, GKE, AKS	중간(운영 위탁)	빠른 시작, 소규모 운영 인력

학습 단계에서 중요한 것은 설치 자체가 아니라 선언한 상태가 유지되는 경험입니다. 파드를 하나 띄우고 강제로 지운 뒤 다시 생기는지 보는 것만으로도 리컨실 루프를 이해하게 됩니다. 온프레미스로 갈 때는 컨트롤 플레인 이중화와 백업, 업그레이드 주기를 처음부터 정해야 합니다. 대략 분기마다 새 마이너 버전이 나오고 지원 기간이 정해져 있어, 업그레이드를 미루면 나중에 한 번에 큰 비용으로 돌아옵니다.

첫 클러스터 구축 절차는 설치 가이드 — 첫 클러스터 구축에, 경량 배포판 선택은 k3s란? 경량 쿠버네티스의 구조와 배포판 선택 가이드와 쿠버네티스 배포판 비교 — RKE2·k3s·OpenShift에 정리돼 있습니다.

노트북에서 한 벌 올려 보는 단계는 로컬 클러스터 구축에서 화면 단위로 따라갈 수 있습니다. 학습용 클러스터는 지우고 다시 만드는 비용이 거의 없으니 부담 없이 몇 번이든 지워 보는 편이 낫습니다.

온프레미스와 매니지드 중 무엇을 고를지는 기능 비교보다 인력 문제로 갈립니다. 컨트롤 플레인을 24시간 지킬 사람이 없다면 매니지드가 기본값이고, 규제나 망 분리 요구가 있으면 온프레미스로 좁혀집니다.

그림. 온프레미스와 매니지드의 책임 범위 비교 — 규제 요구가 없다면 상시 인력 유무가 판단 기준이 된다.

학습 경로와 자격증 취득 순서

자격증은 네 개가 단계로 이어집니다. 입문은 KCNA, 실무 운영은 CKA가 기준선입니다. 아래 수치는 리눅스 재단 공식 안내 기준입니다(2026년 9월 확인).

자격	성격	응시료	시간	형식	유효기간
KCNA	입문(클라우드 네이티브 기초)	250 USD	90분	객관식	2년
CKAD	애플리케이션 개발자	445 USD	2시간	실기	2년
CKA	클러스터 운영자	445 USD	2시간	실기	2년
CKS	보안 전문가	445 USD	2시간	실기	2년

KCNA 는 선수 과목이 없어 비개발 직군도 시작할 수 있습니다(Linux Foundation, KCNA).
CKA·CKAD·CKS 는 객관식이 아니라 명령줄에서 실제 과제를 푸는 실기 시험이고, 현재 쿠버네티스 v1.35 기준으로 출제됩니다(Linux Foundation, CKA).
CKS는 유효한 CKA 취득이 선행 조건입니다. 보안만 따로 먼저 딸 수 없습니다.
등록에는 12개월의 응시 기간과 재응시 기회, Killer.sh 시뮬레이터 이용이 포함됩니다.

학습 순서는 개념 → 아키텍처 → 파드와 배포 → 설치 → 네트워킹 → 운영·보안 이 무난합니다. 자격증은 그 순서를 확인하는 이정표이지 출발선이 아닙니다.

언제 도입하고 언제 미루는가 — 판단 기준과 국내 사례

서비스가 여럿이고 배포가 잦고 장애 대응을 사람이 감당하고 있다면 도입할 때입니다. 반대로 서비스가 한둘이고 배포가 드물면 컨테이너와 관리형 런타임만으로 충분한 경우가 많습니다.

이 플랫폼은 이미 소수의 선택이 아닙니다. CNCF 연례 조사에서 컨테이너 사용 조직의 프로덕션 쿠버네티스 사용률은 2023년 66%에서 2024년 80% 로 올랐고, 검토·시범 단계를 합치면 93%에 이릅니다(CNCF Annual Survey 2024). CNCF는 2026년 1월 쿠버네티스를 AI 시대의 사실상 표준 운영 기반으로 규정하기도 했습니다(CNCF, 2026-01-20).

국내 사례도 규모를 보여 줍니다. 카카오는 온프레미스에 클러스터 7천 개, 노드 12만 대 규모를 운영하고, LY Corporation은 15명 규모 조직이 4만 노드·1,300여 클러스터를 다룹니다. 두 사례 모두 자동화의 범위를 먼저 정하고 조직을 거기에 맞춘 순서였습니다.

업종별로 어떤 판단을 거쳤는지는 프로덕션 도입 사례와 운영 교훈에 모여 있고, 서비스를 여러 개로 쪼개 운영하는 조직이라면 마이크로서비스 운영의 필수 플랫폼인 이유가 판단 근거를 더 좁혀 줍니다.

미루는 편이 나은 조건도 분명합니다.

운영 인력이 한 명뿐이고 학습에 쓸 시간이 없다 — 매니지드 서비스부터 검토합니다.
상태를 많이 가진 레거시 한 덩어리를 그대로 옮기려 한다 — 컨테이너화 설계가 먼저입니다.
배포가 분기에 한 번이다 — 자동화로 얻을 이득이 학습 비용보다 작습니다.

도입 로드맵과 비용 비교는 쿠버네티스 도입 전략 — 로드맵과 TCO 비교에서, 실제 운영 교훈은 카카오 사례와 LY Corporation 사례에서 확인할 수 있습니다. 도입을 막는 오해는 쿠버네티스 도입을 막는 오해와 장벽 12가지에 모아 두었습니다.

AI 워크로드가 쿠버네티스로 오는 이유

AI 학습과 추론은 GPU라는 비싼 자원을 여러 팀이 나눠 쓰는 문제이고, 쿠버네티스는 그 분배와 대기열을 다루는 기본 골격이 됐습니다. 웹 서비스 배포용으로 알려졌던 플랫폼이 최근 몇 년 사이 AI 인프라의 바닥으로 자리를 옮긴 이유가 여기 있습니다.

GPU는 CPU와 성격이 다릅니다. 수량이 적고 단가가 높으며, 한 번 점유하면 학습이 끝날 때까지 놓지 않습니다. 그래서 누가 언제 얼마를 쓰는지 정하는 규칙이 없으면 장비는 놀거나 특정 팀이 독점합니다. 쿠버네티스는 GPU를 노드의 자원으로 인식해 파드에 할당하고, 우선순위와 대기열을 정하고, 작업이 끝나면 회수합니다. 학습과 추론을 같은 클러스터에서 굴리면서 추론에는 항상 일정량을 보장하고 학습은 남는 자원을 쓰게 하는 식의 운영도 가능합니다.

모델을 서비스로 내보내는 단계에서는 앞서 다룬 기능이 그대로 쓰입니다. 추론 서버를 여러 벌 띄워 부하를 나누고, 트래픽에 따라 개수를 자동으로 늘리고, 새 모델 버전을 일부 트래픽에만 먼저 태우는 일이 모두 같은 방식으로 처리됩니다. AI를 위해 별도의 운영 체계를 새로 만들 필요가 없다는 점이 도입 근거가 됩니다.

자세한 운영 방법은 AI 워크로드 운영 가이드와 AI 시대, 가상서버 대신 쿠버네티스를 선택하는 이유에서 다룹니다. 장비를 직접 갖추는 경우라면 베어메탈 쿠버네티스 구축 전략도 함께 보시기 바랍니다.

클러스터와 함께 쓰는 도구 비교

쿠버네티스는 바닥을 깔아 줄 뿐이고, 실제 운영에는 배포·네트워크·관측을 맡는 도구가 함께 붙습니다. 처음부터 전부 도입할 필요는 없지만, 무엇이 어떤 빈자리를 메우는지는 알아 두는 편이 낫습니다.

헬름(Helm): 여러 개로 쪼개진 설정을 하나의 패키지로 묶어 설치하고 버전을 관리합니다.
아르고 CD(Argo CD): 깃 저장소의 내용을 클러스터의 정답으로 삼는 GitOps 방식을 구현합니다. 배포 이력이 곧 커밋 이력이 됩니다.
프로메테우스(Prometheus): 메트릭을 수집해 상태를 관측합니다. 자동 확장의 판단 근거도 결국 이 지표에서 나옵니다.
CNI(Calico·Cilium·Flannel): 파드 사이의 통신과 네트워크 정책을 담당합니다. 클러스터를 만들 때 반드시 하나를 고르게 됩니다.

이 도구들은 대부분 CNCF가 관리하는 오픈소스이고 서로 조합해 쓰도록 설계돼 있습니다. 선택 기준은 쿠버네티스 네트워킹과 CNI — Calico·Cilium·Flannel 비교와 Adobe GitOps 플랫폼 확장 전략에 정리돼 있고, 운영 자동화를 어디까지 맡길지는 쿠버네티스 운영 자동화 — 이해해야 신뢰할 수 있는 이유에서 다룹니다.

운영에서 부딪히는 문제와 대응 방법

도입 이후의 비용은 설치가 아니라 유지에서 발생합니다. 처음 클러스터를 올릴 때보다, 그것을 몇 년 동안 굴릴 때 부딪히는 문제가 더 많습니다. 미리 알고 시작하면 나중에 되돌리는 비용을 줄일 수 있습니다.

첫째는 업그레이드입니다. 새 마이너 버전이 꾸준히 나오고 각 버전의 지원 기간이 정해져 있습니다. 미루면 여러 버전을 한 번에 건너뛰어야 하고, 그 사이 바뀐 API와 애드온 호환성까지 한꺼번에 검증해야 합니다. 업그레이드는 이벤트가 아니라 정기 작업으로 잡는 편이 낫습니다.

둘째는 권한과 경계입니다. 여러 팀이 한 클러스터를 쓰면 네임스페이스로 자리를 나누고 역할별로 권한을 제한해야 합니다. 처음에 모두에게 관리자 권한을 주고 시작하면 나중에 회수하기가 어렵습니다.

셋째는 상태를 가진 워크로드입니다. 파드는 언제든 버려지고 다시 만들어지는 것을 전제로 설계돼 있어, 데이터베이스처럼 상태를 보관하는 구성 요소는 저장소 설계와 백업 전략을 먼저 정해야 합니다. 무상태 애플리케이션부터 옮기고 상태 저장 구성 요소는 나중에 판단하는 순서가 안전합니다.

백업도 파일 하나를 받아 두는 일이 아닙니다. 클러스터를 다시 세우려면 네 가지가 모두 있어야 하고, 무엇보다 실제로 복구해 본 적이 있어야 합니다.

그림. 클러스터 재구축에 필요한 네 가지 — 인증서가 빠지면 스냅샷을 복원해도 컴포넌트가 서로 붙지 않는다.

넷째는 이미지를 어디서 가져오는가입니다. 폐쇄망이거나 외부 레지스트리 의존을 줄여야 한다면 사내 레지스트리를 함께 준비해야 합니다.

각 주제는 업그레이드가 어려운 이유 · 쿠버네티스 Private 컨테이너 레지스트리 구축 방법 · 가상화 엔지니어를 위한 쿠버네티스에서 이어집니다.