클러스터 구축
미니 PC에 k3s를 설치해서 클러스터 환경을 구성해보았다.
미니 PC 한 대만으로도 컨트롤 플레인 + 워커 역할을 모두 수행하게 하면서, 실제 서비스 환경에서의 클러스터 운영 개념을 어느정도 체험할 수 있었다.
설치 전략
k3s를 설치할 때는 여러 전략을 선택할 수 있었다.
- Embedded DB를 이용한 Single K3s server 구성
- Embedded DB를 이용한 Multiple K3s server 구성
- External DB를 이용한 Multiple K3s server 구성
나는 미니 PC를 항상 켜둘 수 있는 컨트롤 플레인으로 지정하고, 동시에 워커 노드 역할까지 맡기는 단일 클러스터 형태를 선택했다.
curl -sfL https://get.k3s.io | sh -이렇게 설치하면 한 대의 서버에서 바로 pod를 배포할 수 있는 환경이 갖춰진다.
추후 필요하다면 k3s agent 명령어를 이용해 메인 PC나 EC2 인스턴스를 워커 노드로 붙여 클러스터를 확장할 수 있도록 계획했다.
즉, 지금은 단일 노드 클러스터지만, 구조적으로는 멀티 노드로 확장이 가능하게 설계한 것이다.
물론 단일 클러스터 구성은 가용성에 문제가 있다는 점은 충분히 알고 있다. 컨트롤 플레인과 워커가 동시에 한 노드에 있기 때문에, 해당 노드에 장애가 발생하면 클러스터 전체가 중단될 수 있다. 하지만 학습과 데모 용도에서는 이 정도의 리스크를 감수하고도 충분히 의미 있는 선택이었다.
특징
k3s는 기본적으로 경량화된 쿠버네티스 배포판이다. 직접 사용해보니 다음과 같은 특징이 눈에 띄었다.
1. 설치 및 구성의 간소화
- k3s : 단일 바이너리로 제공되며, 외부 etcd 대신 sqlite를 기본 사용한다.
→ 로컬 환경이나 소규모 테스트에서는 k3s가 훨씬 진입 장벽이 낮았다.
2. 리소스 사용량
- k3s : CPU·메모리 사용량이 적어서 미니 PC(16GB RAM)에서도 여유가 있었다.
→ 저사양 장비에서는 k3s가 사실상 유일한 선택지였다.
3. 네트워크와 CNI
- k3s : flannel이 내장되어 있어 설치 직후 바로 pod 간 통신이 가능했다.
→ 현업 환경에서는 보안 정책 때문에 네트워크 구성이 복잡하지만, 개인 서버에서는 flannel만으로 충분했다.
4. 스토리지
- k3s : local-path-provisioner가 내장되어 PVC를 바로 쓸 수 있었다.
→ 개인 클러스터에서는 로컬 스토리지만으로도 충분했지만, 데이터 내구성은 보장되지 않는다.
5. 운영/관리성
- k3s : 단일 노드에서 설치 후 바로 사용이 가능했다. 확장성도 필요한 만큼 붙여가는 형태였다.
→ k3s는 단순함 덕분에 빠르게 실험하고 배우기 좋았다.
직접 써본 소감
k3s는 쿠버네티스를 학습하거나 작은 규모의 배포를 테스트하기에 최적이었다. 특히 미니 PC 한 대만으로도 컨트롤 플레인 + 워커 역할을 모두 수행하게 하면서, 실제 서비스 환경에서의 클러스터 운영 개념을 그대로 체험할 수 있었다.
또한 확장이 필요할 때는 워커 노드만 추가하면 되기 때문에, 메인 PC나 EC2를 연결해 멀티 노드 환경으로 발전시킬 수도 있다는 점이 큰 장점이었다.
다만, 현업에서 쓰는 k8s는 훨씬 복잡하다. 고가용성 구성, 네트워크 정책, 외부 스토리지 연동, CI/CD와의 통합까지 고려해야 하기 때문에, k3s에서 경험한 단순한 환경과는 차이가 크다.
정리
미니 PC에 k3s로 클러스터를 올려본 것은 값진 경험이었다. 특히 단일 노드로 시작했지만, 필요하다면 언제든 멀티 노드로 확장할 수 있다는 점에서, “작은 쿠버네티스"라는 이름에 걸맞은 유연함을 느낄 수 있었다.
물론 현업처럼 고가용성과 안정성을 요구하는 환경에서는 단일 클러스터는 절대 적합하지 않다. 그러나 학습과 실험 목적이라면 이 방식이 가장 빠르고 합리적인 선택이었다.
앞으로는 실제 프로젝트들을 이 클러스터 위에 배포해볼 예정이다.