Kubernetes 는 특정 하이퍼바이저에 묶이지 않는다. XCP-ng(Xen) 나 Proxmox(KVM) 위에서도 잘 돈다. 차이는 Kubernetes 쪽이 아니라 그 플랫폼이 제공하는 통합 기능에 있다.
vSphere 처럼 클라우드 프로바이더 연동이 준비된 환경에서는 로드밸런서와 동적 볼륨이 자동으로 따라온다. 그 연동이 없는 플랫폼에서는 같은 기능을 직접 얹어야 한다.
| 필요한 것 | 직접 얹는 방법 |
|---|---|
| LoadBalancer 주소 | MetalLB, kube-vip |
| 동적 볼륨 | Rook-Ceph, Longhorn, OpenEBS, NFS 프로비저너 |
| 노드 생성 | 템플릿 + cloud-init, Terraform · Ansible |
MTU. VM 브리지 위에 오버레이 네트워크(VXLAN·Geneve)를 얹으면 캡슐화가 두 겹이 된다. MTU 를 줄이지 않으면 큰 패킷만 사라지는, 진단하기 까다로운 증상이 난다. CNI 쪽 MTU 를 1450 언저리로 맞춘다.
디스크. 반가상화 드라이버를 쓴다. Proxmox 는 virtio-scsi 나 virtio-blk, Xen 은 PVHVM 이다. etcd 는 디스크 지연에 민감하므로 컨트롤 플레인 디스크는 NVMe 나 SSD 로 둔다. 느린 디스크에서는 리더 선출이 자주 일어나 클러스터가 불안정해진다.
시간. 하이퍼바이저의 시간 동기화와 게스트의 chrony 가 겹치면 시각이 튄다. 한쪽만 쓴다.
CPU 와 메모리. 컨트롤 플레인에는 핫플러그를 쓰지 않는다. 스왑은 끈다.
HA. 컨트롤 플레인은 3대로 두고 etcd 스냅샷을 주기적으로 받는다. 하이퍼바이저 스냅샷은 etcd 백업을 대신하지 못한다. 시점이 어긋난 스냅샷으로 되돌리면 클러스터 상태가 깨진다.
| 제품 | 성격 | 맞는 곳 |
|---|---|---|
| Rook + Ceph | 블록 · 파일 · 오브젝트를 모두 제공하는 분산 스토리지 | 규모가 크고 운영 인력이 있는 환경 |
| Longhorn | 가벼운 분산 블록 스토리지. UI 와 스냅샷·백업 내장 | 중소 규모, 빠른 도입 |
| OpenEBS | 파드에 붙는 구조. Mayastor 엔진은 NVMe 를 활용 | 성능이 중요한 블록 볼륨 |
| NFS 프로비저너 | 기존 NAS 를 그대로 활용 | 공유 파일(RWX)이 필요하고 성능 요구가 낮을 때 |
| 상용 제품 | 지원과 재해 복구 기능 | 지원 계약이 필요한 환경 |
고르는 기준은 셋이다. 접근 모드 — 여러 파드가 같은 볼륨을 읽어야 하면 블록 전용 제품으로는 안 된다. 운영 부담 — Ceph 는 기능이 넓은 대신 OSD 관리와 용량 계획이 따라온다. 가진 하드웨어 — 노드마다 로컬 디스크가 있는지, 별도 스토리지 장비가 있는지에 따라 답이 갈린다.
작게 시작한다면 Longhorn 이나 NFS 프로비저너로 먼저 돌려 보고, 용량과 성능 요구가 커진 뒤에 분산 스토리지로 옮기는 편이 현실적이다. 옮길 때는 PVC 를 새로 만들고 데이터를 복사한다.