온프렘 경량 쿠버네티스 선택 기준 — k3s, k0s, RKE2를 데이터스토어와 규제로 가른다

• 들어가며 — "가볍다"는 선택 기준이 아닙니다
• 축 1: 데이터스토어 — 여기서 절반이 갈린다
• 축 2: 무엇을 번들하는가 — 걷어낼 때의 비용
• 축 3: 프로세스 배치 — 단일 바이너리와 스태틱 파드
• 축 4: 규제 대응 — RKE2의 CIS와 FIPS는 누구를 위한 것인가
  • FIPS는 생각보다 좁습니다
• 축 5: 업그레이드, 지원 수명, 소형 노드 발자국
  • 축 정리표
• 시나리오 셋과 권고
  • 시나리오 1: 공장 현장의 엣지 노드
  • 시나리오 2: 금융 또는 공공 폐쇄망의 내부 서비스 클러스터
  • 시나리오 3: 개발자 노트북과 CI
• 마치며 — 되돌리기 가장 어려운 축부터 고르십시오
• 참고 자료

들어가며 — "가볍다"는 선택 기준이 아닙니다

온프렘 클러스터를 새로 세울 때 가장 자주 나오는 질문이 "k3s랑 RKE2 중 뭐가 나은가요"입니다. 그런데 이 질문에 기능 비교표로 답하면 대개 틀립니다. 세 배포판 모두 인증된 쿠버네티스이고, 셋 다 단일 바이너리에 가깝게 배포되며, 셋 다 폐쇄망 설치 경로를 공식적으로 지원합니다. 기능 목록만 보면 구분이 안 됩니다.

실제로 선택을 결정하는 것은 다섯 개 정도의 축입니다. 그리고 그중 첫 번째 축인 데이터스토어는 나중에 바꾸기가 가장 어렵습니다. 설치 후 6개월이 지나서야 "서버 노드를 한 대 더 넣어야 한다"는 요구가 오는데, 그때 SQLite로 시작했다는 사실을 알게 되는 식입니다.

이 글은 그 축들을 하나씩 놓고, 마지막에 세 개의 구체적인 시나리오에 답을 답니다. 검증 기준은 아래와 같습니다.

축 1: 데이터스토어 — 여기서 절반이 갈린다

k3s의 기본 데이터스토어는 SQLite입니다. 공식 CLI 문서는 --datastore-endpoint 옵션을 "etcd, NATS, MySQL, Postgres 또는 SQLite(기본값) 데이터 소스 이름을 지정한다"고 설명합니다. 그리고 SQLite 구성에서는 서버 노드를 늘릴 수 없습니다. 고가용성이 필요하면 임베디드 etcd로 가거나 외부 데이터스토어를 붙여야 합니다.

# k3s — 임베디드 etcd 로 시작 (첫 서버)
k3s server --cluster-init

# k3s — 외부 데이터스토어 (PostgreSQL 예시)
k3s server --datastore-endpoint="postgres://k3s:PASSWORD@10.10.30.5:5432/k3s?sslmode=require"

이미 SQLite로 띄운 클러스터도 전환 경로가 있긴 합니다. 공식 문서는 기존 서버를 --cluster-init 플래그와 함께 재기동하면 etcd로 전환된다고 안내합니다. 다만 백업 없이 프로덕션에서 시도할 작업은 아닙니다.

k0s는 spec.storage.type으로 지정하며 유효 값은 etcd와 kine 둘입니다. 공식 설정 문서의 예시는 type: etcd를 보여 주고, kine을 쓰면 spec.storage.kine.dataSource의 접속 문자열로 SQLite·MySQL·PostgreSQL 계열 백엔드를 연결합니다. 외부에서 관리하는 etcd를 붙일 때는 spec.storage.etcd.externalCluster 아래에 엔드포인트와 TLS 파일 경로를 지정합니다.

# k0s — 내장 etcd (문서 예시의 기본형)
apiVersion: k0s.k0sproject.io/v1beta1
kind: ClusterConfig
spec:
  storage:
    type: etcd

# k0s — 외부에서 관리하는 etcd 클러스터를 붙이는 형태
apiVersion: k0s.k0sproject.io/v1beta1
kind: ClusterConfig
spec:
  storage:
    type: etcd
    etcd:
      externalCluster:
        endpoints:
          - https://10.10.30.11:2379
          - https://10.10.30.12:2379
        etcdPrefix: onprem-cluster
        caFile: /etc/pki/etcd/ca.crt
        clientCertFile: /etc/pki/etcd/client.crt
        clientKeyFile: /etc/pki/etcd/client.key

RKE2는 개요 문서에서 데이터스토어를 명시하지 않습니다. 이번 확인 범위에서 RKE2가 SQLite 데이터스토어를 제공하는지를 공식 문서 본문으로 확인하지 못했으므로, 단일 노드 초경량 구성이 목적이라면 이 항목을 도입 전에 직접 확인하십시오. 다만 RKE2의 성격상 이 배포판을 SQLite 단일 노드로 쓰려는 상황 자체가 드뭅니다. RKE2는 컨트롤 플레인을 스태틱 파드로 띄우는 구조이고, 문서가 스스로 밝히는 목표가 규제 대응입니다.

폐쇄망 관점에서 이 축의 결론은 이렇습니다. 처음부터 서버 노드를 3대로 잡을 수 있으면 임베디드 etcd로 시작하십시오. 폐쇄망에서는 나중에 노드를 추가하려면 반입 심의부터 다시 시작해야 하므로, 전환 비용이 일반 환경보다 훨씬 큽니다. 그리고 임베디드 etcd는 홀수 노드를 요구합니다. 2대 구성은 1대와 장애 허용 능력이 같으면서 운영 대상만 늘어납니다.

축 2: 무엇을 번들하는가 — 걷어낼 때의 비용

경량 배포판은 "바로 쓸 수 있게" 만들려고 컴포넌트를 미리 넣어 둡니다. 이건 첫날에는 장점이고, 6개월 뒤 Ingress 컨트롤러를 바꾸려는 날에는 단점이 됩니다.

k3s는 이 지점이 가장 명시적입니다. 공식 CLI 문서에 따르면 --disable 플래그로 끌 수 있는 패키지 컴포넌트는 coredns, servicelb, traefik, local-storage, metrics-server, runtimes입니다. 목록이 문서에 그대로 적혀 있다는 것 자체가 실무에서 의미가 큽니다.

# /etc/rancher/k3s/config.yaml — Traefik 대신 다른 인그레스를 쓸 때
disable:
  - traefik
  - servicelb

# 이미 설치된 클러스터에서 끄면 매니페스트가 남아 되살아날 수 있습니다.
# k3s 는 /var/lib/rancher/k3s/server/manifests 를 감시하므로 함께 정리합니다.
sudo ls /var/lib/rancher/k3s/server/manifests/
sudo systemctl restart k3s
sudo k3s kubectl -n kube-system get pods

k0s는 네트워크 공급자를 spec.network.provider로 지정하며, 공식 문서 기준 유효 값은 calico, kuberouter, custom이고 기본값은 kuberouter입니다. custom을 고르면 "모든 CNI 설정과 호스트 수준 설정에 대한 책임을 사용자가 진다"고 문서가 명시합니다. 다른 CNI를 쓰겠다는 결정이 곧 "직접 다 하겠다"는 선언이 되는 구조라, 선택이 명확한 대신 중간 지대가 없습니다.

RKE2는 CNI를 아예 이미지 아카이브 단위로 나눠 배포합니다. 폐쇄망 반입 목록이 여기서 달라집니다.

이 분리가 폐쇄망에서 실제로 도움이 됩니다. 안 쓸 CNI 이미지를 매체에 담아 심의에 올릴 이유가 없기 때문입니다. 반대로 반입 목록을 잘못 짜면 코어만 들여오고 CNI를 빠뜨려서 노드가 NotReady로 멈춥니다.

축 3: 프로세스 배치 — 단일 바이너리와 스태틱 파드

k3s와 k0s는 컨트롤 플레인 컴포넌트를 자기 프로세스 안에서 돌립니다. 노드에서 ps를 쳐도 kube-apiserver라는 별도 프로세스가 안 보입니다. RKE2는 다릅니다. 공식 개요 문서가 "RKE2는 컨트롤 플레인 컴포넌트를 kubelet이 관리하는 스태틱 파드로 실행한다"고 명시합니다.

이 차이가 만드는 실무적 결과는 세 가지입니다.

1. 디버깅 경로가 다릅니다. RKE2에서는 API 서버 로그를 파드 로그로 읽을 수 있고 매니페스트를 직접 고칠 수 있습니다. k3s와 k0s에서는 서비스 로그(journalctl) 하나를 뒤져야 합니다. 폐쇄망에서 외부 지원을 못 받는 상황이면 이 차이가 체감이 큽니다.
2. 업스트림 문서가 그대로 먹히는 정도가 다릅니다. RKE2는 문서가 스스로 "RKE1에서 업스트림 쿠버네티스와의 긴밀한 정렬을 물려받았다"고 말합니다. 인터넷 검색이 막힌 환경에서 손에 든 쿠버네티스 교재가 그대로 적용되는지는 생각보다 중요한 조건입니다.
3. 리소스 발자국이 다릅니다. 프로세스가 나뉘면 메모리도 나뉩니다. 2 GB 램짜리 산업용 PC에서는 이 차이가 결정적입니다.

축 4: 규제 대응 — RKE2의 CIS와 FIPS는 누구를 위한 것인가

RKE2가 존재하는 이유가 이 축입니다. 개요 문서는 목표 영역을 "미국 연방정부 부문의 보안과 컴플라이언스"로 명시하고, FIPS 140-2 준수를 가능하게 하며 클러스터가 "CIS 쿠버네티스 벤치마크 v1.7 또는 v1.8"을 통과할 수 있게 한다고 적습니다.

CIS 프로파일은 설정 한 줄로 켭니다.

# /etc/rancher/rke2/config.yaml
profile: 'cis'

# RKE2 v1.29 이상에서 함께 필요할 수 있는 API 서버 인자
kube-apiserver-arg:
  - 'service-account-extend-token-expiration=false'

공식 하드닝 가이드는 이 제네릭 프로파일이 RKE2 버전에 맞는 벤치마크 통제를 자동으로 적용하므로 업그레이드 때 설정 값을 바꿀 필요가 없다고 설명합니다. 다만 호스트 준비가 선행되어야 하고, 준비가 안 되면 RKE2가 치명적 오류로 기동을 중단합니다.

# 1) etcd 사용자와 그룹 생성
sudo useradd -r -c "etcd user" -s /sbin/nologin -M etcd -U

# 2) 커널 파라미터 적용 — RPM 계열
sudo cp -f /usr/share/rke2/rke2-cis-sysctl.conf /etc/sysctl.d/60-rke2-cis.conf
sudo systemctl restart systemd-sysctl

# 2') 비 RPM 계열 (Ubuntu 등)
sudo cp -f /usr/local/share/rke2/rke2-cis-sysctl.conf /etc/sysctl.d/60-rke2-cis.conf
sudo systemctl restart systemd-sysctl

공식 문서는 이 sysctl 변경을 쿠버네티스 배포 전 신규 설치에서만 적용하라고 경고합니다. 이미 돌고 있는 클러스터에서 sysctl을 재시작하면 예기치 못한 부작용이 생깁니다.

CIS 프로파일을 켜면 무엇이 바뀌는지도 문서에 정리되어 있습니다. 파드 보안 승인이 클러스터 전역 restricted로 강제되고(kube-system, compliance-operator-system, tigera-operator 제외), 같은 네임스페이스 안으로 트래픽을 제한하는 네트워크 정책이 배포되며, 에이전트 매니페스트와 설정 파일 권한이 644에서 600으로 조여지고, etcd 스태틱 파드가 etcd 사용자로 실행됩니다.

여기서 대부분의 팀이 놓치는 항목이 감사 로그입니다.

# RKE2 의 기본 감사 정책은 아무것도 기록하지 않습니다.
# level 을 None 에서 Metadata 이상으로 바꿔야 로그가 남습니다.
sudo vi /etc/rancher/rke2/audit-policy.yaml
sudo systemctl restart rke2-server.service
sudo tail -f /var/lib/rancher/rke2/server/logs/audit.log

폐쇄망 감사에서 "감사 로그를 켰습니까"라는 질문에 "프로파일을 켰습니다"로 답하면 통과되지 않습니다. 정책 파일을 직접 고쳐야 합니다.

FIPS는 생각보다 좁습니다

FIPS 문서를 읽을 때 반드시 확인해야 할 문장이 하나 있습니다. CNI에 관한 것입니다. 공식 문서는 지원 CNI 중 기본값인 Canal만 FIPS 준수를 위해 재빌드된다고 명시합니다. Cilium, Calico, Multus는 해당되지 않습니다.

그래서 "FIPS가 필요하다"와 "eBPF 기반 CNI를 쓰고 싶다"가 동시에 요구되면 둘 중 하나를 포기해야 합니다. 이 결정을 설계 단계에서 못 하면 감사 직전에 CNI를 갈아엎게 됩니다.

그리고 솔직하게 말할 부분이 있습니다. FIPS와 CIS가 계약서나 감사 항목으로 요구되지 않는다면, RKE2를 그 이유로 고를 필요는 없습니다. 국내 금융·공공 폐쇄망에서 실제 요구되는 것은 대개 CIS 계열 하드닝과 감사 로그이지 FIPS 140 검증 모듈 자체가 아닌 경우가 많습니다. 요구 사항 문서에 명시된 항목이 무엇인지부터 확인하고, 그 항목이 RKE2가 자동으로 해 주는 것인지 아니면 어느 배포판에서든 직접 해야 하는 것인지 구분하십시오.

축 5: 업그레이드, 지원 수명, 소형 노드 발자국

폐쇄망에서 업그레이드는 "새 바이너리와 새 이미지 번들을 반입해서 교체"입니다. 세 배포판 모두 이 골격은 같지만 자동화 도구의 성격이 다릅니다.

k3s의 자동 업그레이드는 폐쇄망에서 추가 작업이 있습니다. 공식 문서는 자동 업그레이드를 쓰려면 rancher/k3s-upgrade, rancher/system-upgrade-controller, rancher/kubectl 이미지가 사설 레지스트리에 있어야 한다고 명시합니다. 이 세 이미지를 반입 목록에 넣지 않으면 자동 업그레이드 자체가 첫 시도에서 멈춥니다.

지원 수명은 세 배포판 모두 업스트림 쿠버네티스 마이너 버전 주기를 따라갑니다. 폐쇄망에서 중요한 것은 수명 자체보다 반입 주기와 지원 주기의 정합성입니다. 반입 심의가 분기에 한 번인데 패치가 월 단위로 나오면, 실질적으로는 분기마다 누적 패치를 한꺼번에 올리는 운영이 됩니다. 이 경우 마이너 버전을 하나 낮게 잡아 안정화된 패치 계열을 쓰는 편이 사고가 적습니다.

리소스 발자국은 축 3의 프로세스 배치에서 이미 갈립니다. 정확한 수치는 CNI 선택, 노드 수, 워크로드에 따라 크게 달라지므로 여기서 숫자를 인용하지 않겠습니다. 대신 판단 기준만 적습니다. 램이 4 GB 이하인 산업용 노드라면 스태틱 파드 방식은 후보에서 빼십시오. 컨트롤 플레인 컴포넌트가 각각 별도 컨테이너로 뜨는 구조는 그 하드웨어에서 여유가 없습니다.

축 정리표

이 표에서 "확인하지 못함"으로 남긴 칸은 추측으로 채우지 않았습니다. 폐쇄망 도입 결정에서는 확인되지 않은 항목을 확인된 것처럼 다루는 것이 가장 비싼 실수입니다. 해당 칸이 결정에 영향을 준다면 도입 전에 스테이징에서 직접 확인하십시오.

시나리오 셋과 권고

시나리오 1: 공장 현장의 엣지 노드

라인마다 산업용 PC 한 대, 램 4 GB, 원격 접속은 점검 시에만 열리고, 노드 수는 수십 대에서 수백 대. 한 대가 죽어도 라인 하나만 멈추고 다른 라인은 무관합니다.

권고: k3s. 노드 수가 많고 구축을 반복해야 하면 k0s 플러스 k0sctl.

근거는 세 가지입니다. 첫째, 고가용성이 필요 없는 구조이므로 SQLite 단일 노드가 오히려 적절합니다. etcd 정족수 관리는 이 시나리오에서 순수한 비용입니다. 둘째, 램 4 GB에서 스태틱 파드 배치는 여유가 없습니다. 셋째, k3s의 임베디드 레지스트리 미러를 쓰면 사내 레지스트리에 닿지 않는 노드끼리 이미지를 나눠 가질 수 있습니다.

# 엣지 노드 최소 구성 — /etc/rancher/k3s/config.yaml
disable:
  - traefik
  - servicelb
  - metrics-server
write-kubeconfig-mode: '0600'
kubelet-arg:
  - 'image-gc-high-threshold=70'
  - 'image-gc-low-threshold=50'

이미지 GC 임계값을 낮추는 이유는 엣지 노드의 디스크가 작기 때문입니다. 폐쇄망 엣지에서 디스크가 차면 이미지를 다시 받을 방법이 없어 노드가 통째로 못 쓰게 됩니다.

노드가 수백 대이고 같은 구축을 반복해야 한다면 k0sctl 쪽으로 기웁니다. YAML 한 장으로 노드 목록을 관리하고 같은 명령으로 업그레이드까지 가는 구조가, 수백 번 반복될 때 사람 실수를 가장 많이 줄입니다.

시나리오 2: 금융 또는 공공 폐쇄망의 내부 서비스 클러스터

내부 업무 시스템을 올리는 클러스터. 노드 10~30대, 감사 대상이며 보안 점검 항목표가 존재하고, 장애 시 업무가 멈춥니다.

권고: RKE2. 단, 요구 사항 문서에 CIS 계열 항목이 실제로 있는 경우에 한해서.

근거는 두 가지입니다. 첫째, profile: 'cis' 한 줄로 파드 보안 승인, 네트워크 정책, 파일 권한, etcd 실행 사용자가 함께 조정됩니다. 이걸 손으로 하면 항목마다 검증이 필요하고, 감사 때 "왜 이렇게 설정했는가"를 매번 설명해야 합니다. 배포판이 공식 문서로 근거를 제공하는 편이 훨씬 유리합니다. 둘째, 스태틱 파드 구조라 업스트림 쿠버네티스 지식과 도구가 그대로 적용되어, 외부 지원 없이 자체 인력으로 오래 끌고 가기에 유리합니다.

# /etc/rancher/rke2/config.yaml — 폐쇄망 규제 클러스터 기본형
profile: 'cis'
system-default-registry: 'registry.internal.example:5000'
tls-san:
  - k8s-api.internal.example
  - 10.10.20.10
kube-apiserver-arg:
  - 'service-account-extend-token-expiration=false'

system-default-registry는 폐쇄망에서 특히 유용합니다. 공식 문서는 이 값이 RFC 3986 URI authority만 받는다고 명시합니다. 호스트와 선택적 포트만 쓸 수 있고 경로는 넣을 수 없다는 뜻입니다. 여기에 프로젝트 경로까지 붙이려다 실패하는 사례가 흔합니다.

반대로, 요구 사항 문서에 CIS도 FIPS도 없고 그냥 "보안 강화"라고만 적혀 있다면 RKE2를 고르는 근거가 약합니다. 그 경우 k3s에 파드 보안 표준과 네트워크 정책을 직접 적용하는 편이 운영 부담이 적습니다.

시나리오 3: 개발자 노트북과 CI

기능 개발과 통합 테스트용. 하루에도 몇 번씩 만들고 버리며, 수명이 몇 분에서 몇 시간입니다.

권고: k3s 또는 k0s 단일 노드. 기동 속도와 폐기 용이성만 봅니다.

이 시나리오에서 데이터스토어 논의는 무의미합니다. SQLite가 최선이고, 컴포넌트는 최대한 꺼서 기동 시간을 줄입니다.

# CI 러너에서 k3s 단일 노드 — 필요 없는 것을 전부 끕니다
sudo INSTALL_K3S_SKIP_DOWNLOAD=true \
  INSTALL_K3S_EXEC="server --disable traefik --disable servicelb --disable metrics-server --disable local-storage --write-kubeconfig-mode 0644" \
  ./install.sh

# k0s 단일 노드 — 설치 스크립트 없이 서브커맨드만으로
sudo k0s install controller --single
sudo k0s start
sudo k0s kubectl get nodes

# 폐기
sudo k0s stop && sudo k0s reset
# 또는 k3s
sudo /usr/local/bin/k3s-uninstall.sh

폐쇄망 CI에서 주의할 점 하나. CI 러너가 매번 클러스터를 새로 만든다면 이미지 임포트도 매번 일어납니다. 수백 MB 번들을 반복해서 푸는 비용이 빌드 시간을 지배하게 되므로, 러너 이미지에 containerd 저장소를 미리 채워 둔 스냅샷을 쓰거나 클러스터를 재사용하는 쪽으로 설계를 바꾸는 편이 낫습니다.

마치며 — 되돌리기 가장 어려운 축부터 고르십시오

세 배포판의 기능 차이는 시간이 지날수록 줄어듭니다. 줄지 않는 것은 초기 결정이 만든 제약입니다. SQLite로 시작한 클러스터에 서버 노드를 추가하는 일, FIPS가 요구되는 환경에서 이미 Cilium으로 구축해 버린 일, 램 4 GB 노드에 스태틱 파드 배포판을 올린 일. 셋 다 나중에 고치려면 클러스터를 다시 세워야 하고, 폐쇄망에서 클러스터를 다시 세운다는 것은 반입 심의부터 다시 시작한다는 뜻입니다.

그러니 순서는 이렇습니다. 데이터스토어를 먼저 정하고, 규제 요구 사항 문서를 읽고, 노드의 실제 램 용량을 확인한 다음, 그 세 개를 모두 만족하는 배포판을 고르십시오. 나머지 차이는 운영하면서 흡수할 수 있습니다.

참고 자료

• k3s Server CLI 레퍼런스
• k3s High Availability Embedded etcd
• k0s Configuration 레퍼런스
• k0s Air-Gapped Installation
• RKE2 Overview
• RKE2 CIS Hardening Guide
• RKE2 FIPS 140-2 Enablement
• RKE2 Air-Gap Install