상태: 초안 (2026-10-13), 공식 문서·릴리스 정보 기준 + 일부 실측. 크기는 GitHub 릴리스의 파일 정보(2026-10-13 조회), 요구 사항은 공식 문서(2026-10-13 열람), 준비 시간은 TT Lab 실습 VM 의 실측입니다. 세 배포판의 메모리 사용량을 같은 조건에서 잰 값은 없습니다(미실측). 결정 흐름은 위의 사실을 바탕으로 한 필자의 판단입니다. 작성 규칙: 실측 데이터가 기본이고, 못 잰 것은 「미실측」, 문서에서 찾지 못한 것은 「미확인」으로 표시합니다.
목차
1. 자원: 무엇을 재고 무엇을 못 쟀나
「k3s 는 가볍다」는 말은 많이 듣지만, 어느 숫자를 두고 하는 말인지 구분해야 합니다. 바이너리 크기, 옮겨야 할 이미지 양, 문서가 요구하는 최소 메모리, 실제로 쓰는 메모리는 모두 다른 숫자입니다.
내려받을 크기(GitHub 릴리스 파일 정보, amd64)
| k3s v1.37.1+k3s1 | RKE2 v1.37.1+rke2r1 | k0s v1.36.4+k0s.1 | |
|---|---|---|---|
| 바이너리 | 77.8 MiB | 137.1 MiB(tar.gz 로 41.1 MiB) | 251.1 MiB |
| 바이너리에 든 것 | 전부(containerd 포함) | 감독 프로세스만, 나머지는 이미지 | 전부(etcd 포함) |
| 에어갭 이미지 묶음 | 185.4 MiB(zst) | 코어 558.8 MiB + canal 227.7 MiB(zst), 전체 묶음은 787.1 MiB | 402.4 MiB |
파일을 내려받지 않고 GitHub API 의 릴리스 파일 정보(크기)만 읽은 값입니다(2026-10-13). 바이너리만 비교하면 k3s 가 가장 작고 k0s 가 가장 큽니다. 하지만 RKE2 의 바이너리는 감독만 하고 나머지를 이미지로 받기 때문에, 에어갭으로 옮길 양으로 보면 RKE2 가 가장 무겁습니다.
문서의 표기는 서로 다릅니다. docs.k3s.io 와 README 는 k3s 바이너리를 100MB 미만, k3s.io 홈페이지는 70MB 미만이라고 적습니다. 실제 v1.37.1 파일은 77.8 MiB(81.5MB)라 앞의 표기와 맞습니다. RKE2 와 k0s 는 문서에 크기 수치가 없었습니다(미확인).
TT Lab 실습 VM 에서 직접 본 크기도 있습니다. k0s 바이너리는 251MB 였고(실측, 2026-08, 위 릴리스 정보와 같은 크기), RKE2 v1.36.4 설치 스크립트가 푼 설치물은 128M 였습니다(실측). k3s 는 실습에서 크기를 따로 기록하지 않았습니다(미실측).
문서가 요구하는 최소 사양(공식 문서 기준, 미실측)
| k3s | RKE2 | k0s | |
|---|---|---|---|
| 서버(컨트롤러) | 2코어 · 2GB | 2코어 · 4GB(권장 4코어 · 8GB) | 1 vCPU · 1GB |
| 에이전트(워커) | 1코어 · 512MB | 서버와 따로 적지 않음 | 1 vCPU · 0.5GB |
| 한 노드에 둘 다 | — | — | 1 vCPU · 1GB |
| 디스크 | SSD 권장, 수치 없음 | SSD 권장, 수치 없음 | 컨트롤러 약 0.5GB, 워커 약 1.3GB, 둘 다 약 1.7GB 사용 |
워크로드에 드는 자원은 모두 빠진 값입니다. k0s 가 가장 작아 보이는 것은 컨트롤러에 kubelet 과 런타임이 없기 때문이기도 합니다. 같은 역할끼리 비교해야 공정합니다.
공식 측정값을 내놓은 것은 k3s 뿐입니다. k3s 문서의 자원 프로파일링(v1.26.5, 패키지 구성요소 전부 + Prometheus·Grafana + 예제 앱, 정상 상태의 95분위)에 따르면, x86 4코어 서버에서 에이전트 한 대가 붙은 클러스터의 서버가 1,428M(SQLite)·1,450M(etcd), 에이전트가 275M 였습니다. 감시 도구까지 올린 조건이라 「k3s 만의 메모리」로 읽으면 안 됩니다. RKE2 는 노드 크기 안내(2코어·4GB 서버가 에이전트 225대까지, v1.27.4 기준)는 있지만 유휴 사용량은 없고, k0s 도 측정값은 없었습니다.
실측: 준비 시간
| k3s | k0s | RKE2 | |
|---|---|---|---|
| VM 을 만들고 노드가 Ready 될 때까지 | 82초(Traefik 끔) | 약 150초 | 기록 없음(미실측) |
| 설치 스크립트 → 노드 Ready | 설치 8초 · Ready 11초(v1.35.8) | 기록 없음 | 기록 없음 |
TT Lab 의 VM 실습 준비 시간입니다. 앞 행은 VM 부팅과 인터넷에서 내려받는 시간을 포함하므로, 배포판 자체의 속도라기보다 「실습 하나를 열 때까지」의 체감 시간입니다. k0s 는 etcd 를 쓰는 --enable-worker 구성이라 SQLite 로 뜨는 k3s 와 조건이 같지 않습니다.
세 배포판을 같은 조건에서 재려면
메모리와 디스크를 같은 조건에서 비교한 실측은 아직 없습니다. 재려면 같은 크기의 VM 세 대에 세 배포판을 각각 기본값으로 세우고, 유휴 상태에서 서비스 cgroup 의 메모리와 디스크 사용량을 몇 차례 재어 중앙값을 써야 합니다. 이때 바이너리와 이미지(위 표의 크기만큼)를 새로 내려받아야 해서, 다음 판에서 실측으로 바꿀 예정입니다.
2. 상황별로 보면
| 상황 | 먼저 볼 것 | 이유 |
|---|---|---|
| 엣지·IoT·ARM 보드, 노드 한 대 | k3s | 바이너리가 가장 작고, 에이전트 최소 512MB, SQLite 로 etcd 없이 시작 |
| 개발 PC, CI 의 일회용 클러스터 | k3s | 설치 직후 인그레스·LB·스토리지가 다 있어 바로 쓴다 |
| 규제 산업(공공·금융), 감사 대응 | RKE2 | profile: cis, FIPS 140-2 빌드, SELinux 정책 |
| 처음부터 etcd 로, kubeadm 과 비슷한 모양 | RKE2 | 정적 파드라 kubeadm 경험이 그대로 통한다 |
| 바이너리 하나로 운영, 구성은 직접 고름 | k0s | 기본이 비어 있고 컨트롤러가 워크로드와 분리됨 |
| 여러 호스트를 설정 파일 하나로 | k0s | k0sctl 이 SSH 로 설치·가입, autopilot 이 업그레이드 |
| Rancher 로 여러 클러스터를 한 화면에서 | k3s 또는 RKE2 | Rancher 가 둘 다 프로비저닝·관리한다 |
| CKA 공부, 표준 그대로 배우기 | kubeadm | 시험이 묻는 정적 파드·etcd 백업이 그대로 |
마지막 행은 이 글의 셋이 아니지만 자주 받는 질문이라 넣었습니다. k3s 는 기본 저장소가 SQLite 이고 컨트롤 플레인이 한 프로세스라, 시험에서 묻는 「etcd 백업」, 「정적 파드 고치기」가 그대로 통하지 않습니다.
3. 결정 흐름
질문의 순서가 중요합니다. 바꾸기 어려운 조건부터 묻습니다. 규정 준수는 협상할 수 없고, 하드웨어는 새로 사야 바뀝니다. 반면 「구성을 직접 고르고 싶다」는 선호라서, k3s 에서도 --disable 로 기본 구성요소를 끄고 원하는 것을 올리면 상당 부분 맞출 수 있습니다.
이 흐름은 필자의 정리입니다. 팀이 이미 한 배포판에 익숙하다면 그 경험이 위의 차이보다 클 수 있습니다.
4. 옮길 때 걸리는 것
예를 들어 개발은 k3s 로, 서비스는 RKE2 로 나눠 쓴다면 같은 매니페스트가 두 배포판을 오가야 합니다. 이때 자주 걸리는 것이 넷입니다. 1번과 4번은 실습에서 직접 겪었고, 2번과 3번은 기본값 표(1편 5절)에서 나오는 차이입니다.
- 대역. k3s·RKE2 는 10.42/10.43, k0s 는 10.244/10.96 입니다. 중첩 환경이나 사내망과 겹치는지 먼저 셉니다(1편 6절).
- 인그레스 클래스. k3s 는 Traefik, RKE2 는 만든 판에 따라 Traefik 또는 ingress-nginx, k0s 는 없음입니다. 어노테이션이 컨트롤러마다 달라서, 매니페스트를 Gateway API 나 클래스 이름을 값으로 받게 해 두면 옮기는 비용이 줄어듭니다.
- 스토리지 클래스. k3s 의
local-path는 RKE2·k0s 에 없습니다. 매니페스트에 이름을 박으면 PVC 가 Pending 에 멈춥니다. - 파드 보안. k3s·k0s 기본에서 뜨던 특권 파드가 cis 프로필의 RKE2 에서는 거절됩니다. 다만 이미 떠 있던 파드는 계속 돌기 때문에 다음 배포 때에야 드러납니다(2편 3절).
5. TT Lab 에서는
TT Lab 의 실습 서비스 자체는 kubeadm 으로 세운 쿠버네티스(v1.34 계열) 위에서 돕니다. 그리고 코스의 VM 실습 안에서 k3s, k0s, RKE2 를 직접 세웁니다. 이 시리즈의 「실측」은 모두 그 실습 VM 에서 나왔습니다.
같은 내용을 손으로 해 보고 싶다면 TT Lab 의 「쿠버네티스 배포판 — 직접 세운다」 코스를 찾아보세요(사이트의 코스 목록에서 「배포판」으로 검색). 이 글과 맞닿은 모듈은 이렇습니다.
- 「k0s 로 세우고 복구하기」: etcd 백업 → 변경 → 복구를 한 바퀴 돌리고, 복원이 무엇을 되돌리는지 확인합니다.
- 「k3s 저장소와 스냅숏」: SQLite 에서 내장 etcd 로 옮기고 스냅숏으로 복원합니다.
- 「k3s 기본 구성요소」: 지운 Traefik 이 왜 돌아오는지,
--disable·.skip·HelmChartConfig 의 차이를 봅니다. - 「업그레이드와 판 차이」: 설치 스크립트로 한 칸 올리고 system-upgrade-controller Plan 을 씁니다.
- 「k0s 구성과 동적 구성」: 설정 파일과 ClusterConfig 오브젝트 중 어디가 진실인지 확인합니다.
- 「RKE2 와 CIS 프로필」: 2편의 실측 장면을 그대로 겪어 봅니다.
티티 한마디. 가벼운 게 좋다고 늘 k3s, 안전한 게 좋다고 늘 RKE2 는 아니에요. 「나중에 바꾸기 제일 어려운 게 뭐지?」부터 물어보면 답이 빨리 나와요. 그리고 숫자를 볼 땐 그게 바이너리 크기인지, 최소 사양인지, 진짜 잰 메모리인지 꼭 확인하세요.
참고
모든 자료는 2026-10-13 에 열람·조회했습니다.
- 릴리스 파일 정보(GitHub API): https://api.github.com/repos/k3s-io/k3s/releases/latest, https://api.github.com/repos/rancher/rke2/releases/latest, https://api.github.com/repos/k0sproject/k0s/releases/latest
- k3s: 요구 사항 https://docs.k3s.io/installation/requirements, 자원 프로파일링 https://docs.k3s.io/reference/resource-profiling, 문서 첫 페이지 https://docs.k3s.io/, 홈페이지 https://k3s.io/
- RKE2: 요구 사항 https://docs.rke2.io/install/requirements
- k0s: 시스템 요구 사항 https://docs.k0sproject.io/stable/system-requirements/, k0sctl https://docs.k0sproject.io/stable/k0sctl-install/
- Rancher 로 클러스터 만들기: https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/launch-kubernetes-with-rancher
- 실측: TT Lab 「쿠버네티스 배포판 — 직접 세운다」 코스의 실습 VM 기록(준비 시간, k0s 바이너리, RKE2 설치물, 2026-08~09)