Kubernetesディストリビューション — 自分で立てる
既定値が、できることを分ける
한국어 원문으로 표시합니다.
한 줄 요약
경량 배포판의 차이는 기능이 아니라 기본값에 있고, 그 기본값이 운영에서 할 수 있는 일을 가릅니다.
왜 기본값을 알고 골라야 하나
k3s 와 k0s 는 둘 다 단일 바이너리로 배포되는 경량 쿠버네티스입니다. 겉보기에는 비슷하지만 기본값이 다르고, 그 기본값이 운영에서 할 수 있는 일을 가릅니다.
저장소
k3s 의 기본 저장소는 sqlite 입니다. kine 이라는 층이 etcd 의 API 를 흉내 내면서 뒤에 sqlite 를 둡니다. 가볍고 한 대짜리에는 충분하지만 etcdctl 도 멤버 관리도 쓸 수 없습니다.
k0s 를 --enable-worker 로 세우면 진짜 etcd 입니다. 스냅숏·멤버 관리·복구를 실제로 다룰 수 있습니다. CKA 의 etcd 문제와 실무의 컨트롤 플레인 운영이 여기에 해당합니다.
주의할 것은 k0s 의 --single 모드입니다. 간편해 보이지만 그쪽은 kine(sqlite) 이라 k0s etcd member-list 가 이렇게 거절합니다.
Error: wrong storage type: kine
기본 구성요소
k3s 는 traefik 인그레스와 local-path 프로비저너가 기본으로 들어옵니다. 개발 환경에서는 편합니다. k0s 는 아무것도 넣지 않고 필요한 것을 직접 고르게 합니다. 운영에서는 이쪽이 낫습니다 — 기본으로 들어온 것을 나중에 걷어내는 일이 더 번거롭기 때문입니다.
대역
k0s 의 기본 대역(파드 10.244.0.0/16 · 서비스 10.96.0.0/12)은 표준 쿠버네티스와 같습니다. 그래서 다른 클러스터 안에 중첩해 세우면 겹칩니다. k3s 의 10.42/10.43 은 비표준이라 우연히 충돌을 피합니다.
어느 쪽이 옳다기보다 자기 환경의 대역을 알고 고르는 것이 맞습니다. 그리고 우연히 비켜 가는 상태에 기대면, 배포판을 바꾸는 순간 함정이 되살아납니다.
무엇을 기준으로 고르나
배포판 선택은 취향이 아니라 어디에 무엇을 얹을 것인가 로 정해집니다.
| 상황 | 맞는 것 | 이유 |
|---|---|---|
| 엣지·IoT·단일 노드 | k3s | 바이너리 하나, 메모리 512MB 대 |
| 개발용 로컬 | kind, minikube | 만들고 버리기가 빠르다 |
| 표준을 그대로 배우고 싶다 | kubeadm | 인증 시험과 문서가 이것을 전제한다 |
| 여러 클러스터를 자동으로 | k0s, Cluster API | 선언적으로 찍어 낸다 |
| 관리 부담을 줄이고 싶다 | 관리형(EKS·GKE) | 컨트롤 플레인을 안 본다 |
시험 준비라면 kubeadm 입니다. k3s 는 etcd 대신 SQLite 를 쓰고 컨트롤 플레인이 한 프로세스라, 시험에서 묻는 "etcd 백업", "정적 파드 수정", "인증서 갱신" 이 그대로 안 통합니다. 편한 것과 배우는 것이 다릅니다.
기본값이 만드는 차이
같은 쿠버네티스라도 기본으로 들어 있는 것이 다르고, 그것이 실습과 운영을 가릅니다.
| kubeadm | k3s | k0s | |
|---|---|---|---|
| 데이터 저장 | etcd | SQLite(기본), etcd 가능 | etcd(기본), kine 가능 |
| CNI | 없음 — 직접 설치 | Flannel | Kube-router |
| Ingress | 없음 | Traefik | 없음 |
| LoadBalancer | 없음 | ServiceLB(klipper) | 없음 |
| 스토리지 클래스 | 없음 | local-path | 없음 |
kubeadm 으로 처음 세우면 노드가 NotReady 로 멈춰 있습니다. 고장이 아니라 CNI 가 없어서입니다. 이것을 모르면 첫 설치에서 한 시간을 씁니다.
반대로 k3s 는 다 들어 있어 편하지만, 그 기본값을 빼는 방법을 알아야 합니다.
# Traefik 과 ServiceLB 를 빼고 직접 고른 것을 쓴다
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--disable=traefik --disable=servicelb" sh -
옮길 때 무엇이 걸리나
배포판을 바꾸는 일은 생각보다 자주 생깁니다. 걸리는 것은 대개 셋입니다.
- 스토리지 클래스 이름 —
local-path와standard처럼 이름이 다르면 PVC 가 Pending 에 멈춥니다. 매니페스트에 이름을 박지 말고 기본 클래스를 쓰거나 값으로 주입합니다. - LoadBalancer 구현 — k3s 의 ServiceLB 는 노드 IP 를 그대로 씁니다. MetalLB 가 있는 곳으로 옮기면 IP 대역 설정이 필요합니다.
- 인그레스 컨트롤러 차이 — Traefik 과 NGINX 는 어노테이션이 다릅니다. Gateway API 로 쓰면 이 이전 비용이 크게 줄어듭니다.
실무에서 진짜 중요한 것
etcd 를 다뤄야 하면 저장소부터 확인합니다. kine(sqlite) 위에서는 etcdctl 도 멤버 관리도 스냅숏 복구도 쓸 수 없습니다. k0s 라도 --single 모드는 kine 이라서, 명령이 wrong storage type: kine 으로 거절합니다.
중첩해 세울 때는 대역이 겹치는지 먼저 셉니다. k0s 의 기본 대역은 표준 쿠버네티스와 같아서, 다른 클러스터 안에 세우면 충돌합니다. k3s 가 잘 되던 이유는 설계가 아니라 비표준 대역이 우연히 비켜 간 것이라, 배포판을 바꾸는 순간 함정이 되살아납니다.
기본으로 들어온 구성요소는 나중에 걷어내기가 더 번거롭습니다. 개발 환경에서는 traefik 과 local-path 가 들어 있는 편이 편하지만, 운영에서는 필요한 것만 직접 고르는 쪽이 낫습니다.
다음 실습에서 k0s 를 세우고 백업·복구를 한 바퀴 돌립니다.