로컬 개발에는 어떤 배포판이 좋나요?

학습·일반 개발은 minikube, CI 반복 생성·삭제는 kind, 운영 환경과 동일한 구성이 필요하면 k3s 또는 k3d를 권합니다.

목차 (Agenda)

Cloud Native

k3s란? 경량 쿠버네티스의 구조와 배포판 선택 가이드

핵심 요약 — k3s는 단일 바이너리로 패키징된 CNCF 인증 경량 쿠버네티스 배포판입니다. 엣지·IoT·개발 환경처럼 자원이 제한된 곳에서 표준 쿠버네티스 API를 그대로 쓸 수 있게 해 줍니다.

2026년 07월 31일

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

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

Kubernetes 도입 문의하기 →

k3s란 무엇인가 — 이름부터 인증까지

k3s는 자원 제약 환경을 겨냥해 설계된, CNCF 적합성 인증을 통과한 완전한 쿠버네티스 배포판입니다.

k3s는 Rancher(현 SUSE)가 2019년 공개한 경량 쿠버네티스 배포판으로, 2020년 CNCF에 기부되어 현재 CNCF 샌드박스(Sandbox) 프로젝트로 관리되고 있습니다(출처: k3s 공식 사이트). 공식 소개는 “IoT·엣지 컴퓨팅을 위해 만들어진 인증(certified) 쿠버네티스 배포판”입니다. 여기서 두 단어가 모두 중요합니다.

인증 — k3s는 CNCF의 쿠버네티스 적합성 테스트(conformance test)를 통과한 배포판입니다. 축소판이지만 표준 쿠버네티스 API와 동작을 그대로 보장하므로, kubectl·Helm·오퍼레이터 같은 생태계 도구가 수정 없이 동작합니다(출처: k3s 공식 사이트).
경량 — 서버·에이전트 기능 전체가 단일 바이너리 하나에 담겨 있고, 설치는 스크립트 한 줄로 끝납니다. 공식 최소 요구 사양은 메모리 512MB 수준으로, 라즈베리 파이급 장비에서도 동작합니다(출처: k3s 공식 문서 — Requirements).

이름의 유래도 설계 철학을 보여 줍니다. Kubernetes를 K8s(10글자)로 줄여 부르는 관행에서, “메모리 사용량 기준 절반 크기의 쿠버네티스”라는 목표를 담아 그 절반인 5글자 단어, 즉 K3s로 이름 지었습니다(출처: k3s 공식 문서). 국내에서도 k3s는 엣지와 개발 환경을 중심으로 꾸준히 채택이 늘고 있으며, 기존에 소개했던 개요 글(k3s-overview)을 본 글이 대체·확장합니다(출처: cncf.co.kr — k3s 소개).

왜 만들어졌나 — 엣지의 부상과 표준 쿠버네티스의 한계

k3s 개발이 시작된 2018~2019년은 클라우드 네이티브 기술이 성숙기에 들어서는 동시에, 엣지 컴퓨팅과 사물인터넷이 새로운 축으로 떠오르던 시기였습니다. 공장 바닥의 센서, 매장의 POS, 통신 기지국처럼 컴퓨팅이 필요한 지점이 데이터센터 바깥으로 퍼져 나갔고, 그곳의 조건은 데이터센터와 전혀 달랐습니다. 하드웨어 자원이 빠듯하고, 네트워크가 끊기며, 손이 닿지 않는 곳에 놓인 장비를 원격으로 관리해야 했습니다. Rancher Labs는 표준 쿠버네티스가 이 조건을 감당하기 어렵다고 보고 네 가지를 목표로 삼았습니다 — 설치·운영 복잡도 낮추기, 자원 요구량 줄이기, 엣지 특유의 제약(작은 설치 공간·빠른 기동·오프라인 동작) 대응하기, 그러면서도 CNCF 인증을 받을 만큼의 표준 API 호환성 지키기입니다(출처: cncf.co.kr 쿠버네티스 eBook — 5.3.1 K3s 소개 및 특징).

그림 1. k3s의 세 가지 설계 축 — 엣지 우선 · 단순화와 보안 · ARM 최적화

이 목표는 세 가지 설계 축으로 정리됩니다. 첫째 엣지 우선 — 데이터센터 밖의 프로덕션 워크로드를 처음부터 대상으로 삼았습니다. 둘째 단순화와 보안 — 설치·실행·자동 업데이트에 필요한 종속성과 단계를 줄인 단일 바이너리로 배포합니다. 바이너리는 보통 100MB를 넘지 않는 수십 MB 수준입니다. 셋째 ARM 최적화 — ARM64와 ARMv7을 모두 공식 지원하므로 라즈베리 파이나 산업용 ARM 보드에서도 그대로 돌아갑니다.

k3s는 무엇을 덜어냈나 — 아키텍처와 축소 포인트

k3s는 컨트롤 플레인 전체를 한 프로세스로 합치고, etcd를 SQLite로 대체하며, 레거시 기능을 제거해 몸집을 줄였습니다.

표준 쿠버네티스의 컨트롤 플레인은 API 서버·스케줄러·컨트롤러 매니저·etcd가 각각 별도 프로세스로 뜹니다(전체 구조는 쿠버네티스 아키텍처 완전 정복 참고). k3s의 축소 전략은 이 구조를 세 방향에서 단순화합니다(출처: k3s 공식 문서 — Architecture).

그림 2. k3s 아키텍처 — 컨트롤 플레인은 server, 노드 측은 agent 한 프로세스로

프로세스 통합 — 컨트롤 플레인 컴포넌트 전체를 “server”라는 단일 프로세스로, 노드 측 컴포넌트(kubelet·kube-proxy)를 “agent”라는 단일 프로세스로 합쳤습니다. 운영자가 관리할 프로세스가 두 종류뿐입니다.
데이터 저장소 교체 — 기본 저장소로 etcd 대신 SQLite를 내장했습니다. 단일 노드라면 별도 데이터베이스 구축이 필요 없습니다. 필요 시 kine 계층을 거쳐 MySQL·PostgreSQL 같은 외부 데이터베이스나 내장(embedded) etcd로 바꿀 수 있어, 소규모에서 시작해 HA 구성으로 성장하는 경로가 열려 있습니다.
불필요 요소 제거와 내장 도구 동봉 — 클라우드 사업자 연동 코드(in-tree cloud provider)와 레거시·알파 기능을 걷어내는 대신, 운영에 바로 필요한 containerd(런타임), Flannel(CNI), CoreDNS, Traefik(인그레스), 로컬 스토리지 프로비저너를 기본 동봉했습니다. 설치 직후 바로 서비스 배포가 가능한 “배터리 포함” 구성입니다.

위 그림에서 눈여겨볼 부분이 하나 더 있습니다. 서버와 에이전트 양쪽에 놓인 터널 프록시입니다. 에이전트가 서버 쪽으로 먼저 접속해 터널을 열고 그 위에서 통신하므로, 에이전트가 공인 IP를 갖지 않아도 되고 인바운드 방화벽 구멍을 뚫을 필요도 없습니다. 매장이나 공장처럼 NAT 뒤에 놓인 엣지 노드를 중앙 서버에 붙일 때 이 방향성이 실질적인 차이를 만듭니다.

뺀 것과 더한 것

k3s의 경량화를 “무엇을 뺐나”만으로 보면 절반만 본 셈입니다. 아래 정리처럼 k3s는 덜어낸 자리에 운영 편의를 더해 넣었습니다.

그림 3. k3s가 뺀 것과 더한 것 — 축소는 제거만이 아니다

뺀 것 — 레거시·알파 기능, 인-트리 클라우드 프로바이더, 인-트리 스토리지 드라이버. 도커는 선택 사항으로 내려가고 기본 런타임 자리를 containerd가 대신합니다. 필요하면 CSI나 외부 클라우드 컨트롤러 매니저 같은 표준 인터페이스로 다시 붙일 수 있습니다.
더한 것 — 단순화된 설치, etcd에 더해 쓸 수 있는 SQLite3, TLS 인증서 자동 관리, 매니페스트와 Helm 차트 자동 관리, 그리고 containerd·CoreDNS·Flannel 동봉. 표준 쿠버네티스를 직접 구축할 때 가장 손이 많이 가는 인증서 발급·갱신과 애드온 배포를 배포판이 떠안은 셈입니다.

기본 동봉 컴포넌트 — 설치 직후 바로 쓰는 것들

k3s가 설치와 동시에 붙여 주는 확장 기능은 네 가지로 요약됩니다.

Helm Controller — HelmChart 커스텀 리소스를 클러스터에 적용하면 컨트롤러가 대신 차트를 설치·업데이트합니다. 별도로 Helm CLI를 깔지 않아도 되고, 애플리케이션의 생애주기를 매니페스트 하나로 다룰 수 있습니다.
ServiceLB — 클라우드 사업자의 로드밸런서가 없는 환경에서도 LoadBalancer 타입 서비스를 만들 수 있게 해 줍니다. 엣지나 온프레미스 단독 노드에서 특히 유용합니다.
Traefik — 가벼운 인그레스 컨트롤러가 기본 동봉되어, 설치 직후 외부 노출 경로를 잡을 수 있습니다(인그레스 컨트롤러의 역할은 8.3.2 인그레스 컨트롤러 참고).
local-path 프로비저너 — 노드의 로컬 디스크를 쓰는 기본 StorageClass를 제공해, 스토리지 시스템 없이도 PVC를 붙여 볼 수 있습니다.

그림 4. k3s 기본 동봉 컴포넌트 — 설치 직후 이미 떠 있는 것

정리하면 k3s의 경량화는 기능을 깎아 만든 반쪽 쿠버네티스가 아니라, “표준 API는 유지하고 운영 복잡도와 기본 자원 요구량을 줄이는” 방향의 재포장입니다. 무엇이 빠지고 무엇이 대체됐는지를 알고 있으면, 이후 프로덕션 전환 시 검토 지점도 명확해집니다.

경량 배포판 비교 — k3s·k0s·microk8s·kind·minikube

다섯 배포판은 모두 쿠버네티스를 가볍게 띄우지만, 설계 목적이 프로덕션 엣지·로컬 개발·CI 테스트로 서로 다릅니다.

“가벼운 쿠버네티스”라는 같은 표현 아래 목적이 다른 도구들이 섞여 있어 혼동이 잦습니다. 대표 다섯을 비교하면 다음과 같습니다(출처: 각 프로젝트 공식 문서).

구분	k3s	k0s	microk8s	kind	minikube
주관	SUSE(CNCF Sandbox)	Mirantis	Canonical	Kubernetes SIG	Kubernetes SIG
형태	단일 바이너리	단일 바이너리	snap 패키지	컨테이너(도커 안 K8s)	VM/컨테이너 드라이버
기본 저장소	SQLite(→etcd 선택)	etcd(kine 선택)	dqlite	etcd	etcd
주 용도	엣지·IoT·소형 프로덕션	프로덕션·자체 플랫폼 구축	우분투 환경·워크스테이션	CI·쿠버네티스 자체 테스트	학습·로컬 개발
프로덕션 지향	예	예	부분적(HA 지원)	아니요	아니요
특징	배터리 포함, 설치 한 줄	의존성 제로 지향, 컨트롤러·워커 분리	애드온 방식 기능 확장	클러스터 생성·파괴가 초 단위	드라이버·애드온 다양, 입문 문서 풍부

갈림길은 두 가지 질문입니다. 첫째, 프로덕션에서 계속 운영할 클러스터인가? 그렇다면 k3s·k0s처럼 프로덕션을 명시적으로 지향하는 배포판이 후보이고, kind·minikube는 처음부터 제외합니다. 둘째, 호스트 환경의 제약은 무엇인가? 우분투·snap 기반 조직이면 microk8s가 자연스럽고, CI 파이프라인에서 클러스터를 매번 만들었다 부수는 용도라면 kind가 사실상 표준입니다.

k3d와 Rancher Desktop — k3s를 감싼 도구들

한 가지 더 짚어 둘 것은, 표에 있는 다섯 말고도 k3s를 엔진으로 쓰는 도구가 따로 있다는 점입니다. 이름이 비슷해 배포판과 자주 헷갈립니다.

k3d — kind가 표준 쿠버네티스를 도커 컨테이너 안에 띄우듯, k3d는 k3s를 도커 컨테이너 안에 띄웁니다. k3s의 가벼움을 그대로 가져가면서 클러스터 생성·삭제와 멀티 노드 구성이 kind만큼 빠릅니다.
Rancher Desktop — 내부 엔진으로 k3s를 쓰는 데스크톱 애플리케이션입니다. 쿠버네티스 버전 선택, 컨테이너 런타임(containerd 또는 dockerd) 전환, 시작·중지를 GUI에서 처리할 수 있어, 명령줄 설정을 최소화하고 싶은 경우에 적합합니다.

즉 k3s는 “배포판”, k3d와 Rancher Desktop은 “그 배포판을 다루는 도구”입니다. 셋 중 무엇을 고르든 안에서 도는 쿠버네티스는 같은 k3s이므로, 학습한 내용과 매니페스트는 그대로 이어집니다(출처: cncf.co.kr 쿠버네티스 eBook — 5.1.3 Rancher Desktop과 K3s 선택 이유).

시나리오별 선택 기준 — 엣지·개발·홈랩·CI

운영 장소와 목적을 먼저 정하면 배포판 선택은 대부분 자동으로 결정됩니다.

그림 5. 경량 배포판 선택 결정 트리 — 프로덕션 여부와 호스트 제약

엣지·IoT·매장/공장 현장 — k3s가 첫 번째 후보입니다. 낮은 사양 요구, ARM 아키텍처 지원, 무인 환경을 고려한 설계가 강점입니다. 수백 개 지점에 같은 구성을 찍어내는 GitOps 방식과 결합하면 관리 부담이 크게 줄어듭니다(수백 개 클러스터를 GitOps로 다루는 실제 사례는 Adobe의 GitOps 플랫폼 확장 전략에서 확인할 수 있습니다). 중앙 집중 관리가 필요한 규모라면 k0s의 플랫폼 구축 지향성도 비교해 볼 만합니다.
개발자 로컬 환경 — 목적이 “애플리케이션 개발·검증”이면 minikube나 kind로 충분하고, “운영 환경과 최대한 같은 구성”이 필요하면 로컬에도 k3s를 씁니다. k3s를 컨테이너로 감싼 k3d를 쓰면 kind처럼 빠른 생성·삭제도 가능합니다.
홈랩·학습 — 라즈베리 파이 여러 대로 실제 멀티 노드 클러스터를 경험하기에는 k3s가 가장 문턱이 낮습니다. 설치부터 클러스터 확인까지의 절차는 openSUSE에 K3s 설치와 K3s 환경 확인 및 kubectl 설정에서 단계별로 다룹니다.
CI 파이프라인 — 테스트마다 깨끗한 클러스터를 몇 초 안에 만들어야 하므로 kind가 표준 선택입니다. 애플리케이션이 k3s 환경에 배포될 예정이라면 k3d로 CI 환경을 실제 런타임에 맞추는 방법도 있습니다.

한 가지 실무 조언을 덧붙이면, 시나리오가 겹칠 때는 “최종 운영 환경”을 기준으로 정하는 편이 후회가 적습니다. 예를 들어 개발은 노트북에서 하지만 최종 배포처가 매장의 k3s 클러스터라면, 개발 단계부터 k3d로 맞춰 두는 쪽이 환경 차이로 인한 막판 이슈를 줄여 줍니다. 반대로 배포처가 관리형 쿠버네티스 서비스라면 로컬 도구는 어떤 것을 써도 차이가 크지 않습니다.

공통 원칙은 “작게 시작하되, 표준 API를 벗어나지 않는 것”입니다. 다섯 배포판 모두 표준 쿠버네티스 API를 유지하므로, 매니페스트와 Helm 차트는 배포판을 옮겨도 대부분 그대로 씁니다. 초기 선택이 틀려도 갈아타는 비용이 크지 않다는 뜻이며, 이것이 경량 배포판 생태계의 가장 큰 미덕입니다.

설치 한 줄로 시작하는 첫 클러스터

k3s는 설치 스크립트 한 줄이면 단일 노드 클러스터가 완성되고, kubectl까지 함께 준비됩니다.

k3s의 설치 경험은 경량 배포판의 지향점을 그대로 보여 줍니다. 서버(컨트롤 플레인) 노드는 다음 한 줄로 설치합니다(출처: k3s 공식 사이트).

# 서버 노드 설치 — 설치 후 kubectl 로 바로 사용 가능
curl -sfL https://get.k3s.io | sh -

# 상태 확인
sudo k3s kubectl get nodes

설치 스크립트가 바이너리 배치, systemd 서비스 등록, kubeconfig 생성까지 처리하므로 별도 준비 작업이 거의 없습니다. 워커 노드를 추가할 때는 서버가 발급한 토큰을 환경 변수로 넘겨 같은 스크립트를 실행하면 됩니다.

# 에이전트(워커) 노드 합류
curl -sfL https://get.k3s.io | K3S_URL=https://<서버IP>:6443 K3S_TOKEN=<토큰> sh -

표준 쿠버네티스를 kubeadm으로 구축할 때 거치는 런타임 설치, 네트워크 플러그인 배포, 인증서 구성 같은 단계가 스크립트 안으로 흡수된 셈입니다. 다만 이 간편함은 “기본 구성을 그대로 받아들일 때”의 이야기이고, 조직 표준 CNI나 인그레스로 바꾸려면 설치 옵션으로 기본 컴포넌트를 끄고 시작해야 한다는 점은 기억해 둘 필요가 있습니다.

프로덕션 전환 시 고려사항

k3s를 프로덕션으로 가져갈 때는 HA 데이터 저장소, 업그레이드 체계, 백업, 지원 체계 네 가지를 먼저 점검합니다.

개발·파일럿에서 검증한 k3s를 실제 서비스에 올릴 때 확인할 항목은 다음과 같습니다.

데이터 저장소와 HA — 기본 SQLite는 단일 서버 구성 전용입니다. 서버 노드를 3대 이상 홀수로 두고 내장 etcd(또는 외부 데이터베이스)로 전환해야 컨트롤 플레인 장애를 견딥니다(출처: k3s 공식 문서 — High Availability). 서버 앞에는 고정 진입점(로드밸런서 또는 VIP)을 둡니다.
업그레이드 체계 — 쿠버네티스는 마이너 버전 주기가 빠르므로, 수동 업그레이드 대신 계획된 절차(순차 업그레이드, 자동화 도구)를 마련합니다. 엣지처럼 노드가 많고 손이 닿기 어려운 환경일수록 자동화가 필수입니다.
백업 — 클러스터 상태 저장소(etcd 스냅숏 또는 데이터베이스)와 애플리케이션 데이터(PV)의 백업을 분리해 설계하고, 복구 리허설까지 포함해야 실전에서 의미가 있습니다.
동봉 컴포넌트의 교체 여부 — 기본 Traefik·Flannel·로컬 스토리지가 요구 사항에 맞는지 검토하고, 조직 표준(다른 인그레스·CNI·스토리지)이 있으면 설치 시점에 비활성화 후 교체합니다. Pod 네트워크와 CNI 선택 기준은 8.1.3 컨테이너 네트워크 인터페이스(CNI)에서 이어집니다.

그림 6. 단일 SQLite 서버에서 3서버 내장 etcd HA 로의 전환

경량 배포판이라는 말이 “프로덕션 부적합”을 뜻하지 않는다는 점은 분명히 해 둘 필요가 있습니다. k3s는 무인·원격·자원 제약 환경의 프로덕션 워크로드를 명시적 설계 목표로 삼고 있습니다(출처: k3s 공식 문서). 관건은 배포판 자체가 아니라, HA·업그레이드·백업이라는 운영 체계를 갖추었는가입니다. 클러스터 수가 늘어날수록 개별 클러스터의 사양보다 “여러 클러스터를 어떤 표준으로 찍어내고 관리하는가”가 승부처가 되는데, 그 감각은 카카오의 온프레미스 7,000개 클러스터 운영 사례나 LY(라인·야후)가 15명으로 1,300개 클러스터를 운영하는 사례에서 얻을 수 있습니다.

엣지 컴퓨팅과 소형 AI 추론 워크로드가 늘면서 “데이터센터 밖의 쿠버네티스”는 계속 커지는 흐름입니다. k3s 경량 쿠버네티스처럼 표준 API를 유지한 채 몸집만 줄인 배포판은 이 흐름의 기본 인프라로 자리를 넓혀 갈 가능성이 높습니다. 클러스터를 어디에나 둘 수 있게 되었을 때 무엇이 달라지는지 — 그 답은 결국 조직의 클라우드 네이티브 역량에 달려 있으며, 그 큰 그림은 클라우드 네이티브란 무엇인가에서 확인하실 수 있습니다.

자주 묻는 질문 (FAQ)

k3s는 정식 쿠버네티스인가요?

정식입니다. k3s는 CNCF의 쿠버네티스 적합성 인증을 통과한 배포판으로, 표준 쿠버네티스 API와 동작을 그대로 보장합니다. kubectl·Helm·오퍼레이터 같은 생태계 도구가 수정 없이 동작하며, “축소”는 패키징과 기본 구성의 문제이지 API 호환성의 문제가 아닙니다.

k3s와 k8s의 차이는 무엇인가요?

K8s는 쿠버네티스 자체를 가리키는 약칭이고, k3s는 그 쿠버네티스를 경량으로 재포장한 배포판입니다. k3s는 컨트롤 플레인을 단일 프로세스로 합치고 기본 저장소를 SQLite로 바꾸었으며 런타임·CNI·인그레스를 동봉해, 저사양 환경에서 적은 운영 부담으로 표준 쿠버네티스를 실행하게 해 줍니다.

k3s와 k3d, Rancher Desktop은 어떤 관계인가요?

k3s는 배포판이고, k3d와 Rancher Desktop은 그 배포판을 다루는 도구입니다. k3d는 k3s를 도커 컨테이너 안에 띄워 클러스터를 빠르게 만들고 지우며, Rancher Desktop은 k3s를 내부 엔진으로 쓰면서 버전 선택과 런타임 전환을 GUI로 제공합니다. 안에서 도는 쿠버네티스는 셋 다 같은 k3s이므로 매니페스트와 학습 내용이 그대로 이어집니다.

k3s를 프로덕션에 써도 되나요?

가능합니다. k3s는 무인·원격·자원 제약 환경의 프로덕션 워크로드를 설계 목표로 명시하고 있습니다. 다만 서버 노드 3대 이상과 내장 etcd(또는 외부 데이터베이스)로 HA를 구성하고, 업그레이드 자동화와 백업·복구 체계를 갖추는 것이 전제 조건입니다.

로컬 개발에는 k3s·kind·minikube 중 무엇이 좋나요?

목적에 따라 다릅니다. 쿠버네티스 학습과 일반 개발이면 minikube, CI에서 클러스터를 반복 생성·삭제하면 kind, 운영 환경(특히 k3s 기반 엣지)과 동일한 구성을 원하면 k3s 또는 k3d가 맞습니다. 셋 모두 표준 API를 쓰므로 매니페스트는 호환됩니다.