[k8s] K3s/MicroK8s로 구축하는 경량 엣지 쿠버네티스: 실제 운영 사례 분석

안녕하세요, 13년차 서버실 지킴이입니다. 오늘도 제 홈랩 서버에서 굴러가는 작은 친구들 이야기를 좀 해볼까 합니다. 요즘 엣지 컴퓨팅(Edge Computing)에 대한 관심이 정말 뜨거우니까요? 클라우드의 강점을 작은 엣지 디바이스까지 끌어내려는 움직임이 활발합니다. 그런데 막상 작은 디바이스에 쿠버네티스(Kubernetes)를 올리려고 하면, 덩치 큰 녀석이라 부담스러울 때가 많았거든요.

저도 처음엔 라즈베리 파이(Raspberry Pi) 같은 작은 보드 컴퓨터에 풀 스택 쿠버네티스를 올려보려다가 리소스 부족으로 꽤나 삽질을 했어요. 😅 그러다 발견한 보석 같은 친구들이 바로 K3s와 MicroK8s거든요. 이 경량 쿠버네티스 배포판들이 엣지 환경에서 얼마나 쓸모 있게 쓰일 수 있는지, 그리고 제가 직접 운영하면서 겪었던 경험담들을 공유해볼까 합니다. 저처럼 작은 디바이스에서 쿠버네티스를 돌려보고 싶으셨던 분들이라면 오늘 글이 좋은 가이드가 될 거예요!

이미지: 엣지 환경에서 경량 쿠버네티스 클러스터가 어떻게 구성되는지 보여주는 아키텍처 다이어그램입니다.

K3s와 MicroK8s, 뭐가 다를까? (개념 설명 및 비교)

경량 쿠버네티스라는 카테고리 안에 K3s와 MicroK8s가 대표주자인데, 이 둘은 각각 다른 접근 방식으로 '가벼움'을 추구해요. 핵심부터 쉽게 설명해 드릴게요.

K3s: Rancher Labs의 선택

K3s는 Rancher Labs에서 만든 경량 쿠버네티스 배포판이에요. 'K8s'에서 숫자 8을 3으로 바꾼 건, 일반적인 쿠버네티스보다 절반도 안 되는 리소스로 동작한다는 의미를 담고 있더라고요. 💡 K3s의 가장 큰 특징은 단일 바이너리(Single Binary) 형태로 배포된다는 점이에요. 모든 핵심 컴포넌트(kube-apiserver, kube-controller-manager 등)가 하나의 파일에 쏙 들어있어서 설치가 정말 간편합니다. 게다가 SQLite를 기본 데이터베이스로 써서 외부 DB(데이터베이스) 없이도 잘 동작하거든요. 엣지 환경처럼 리소스가 제한적이거나 네트워크 연결이 불안정한 곳에 정말 안성맞춤이죠.

MicroK8s: Canonical의 유연성

MicroK8s는 Canonical(우분투를 만드는 회사)에서 만든 경량 쿠버네티스예요. K3s만큼 설치가 간단한 건 맞는데, 애드온(Add-ons) 시스템이 정말 강점이거든요. Ingress(인그레스, 외부 트래픽 진입점), DNS, Storage(스토리지) 같은 필수 기능들을 필요할 때마다 쉽게 켜고 끄는 식으로 활성화할 수 있어요. 스냅(Snap) 패키지로 배포되기 때문에 우분투(Ubuntu) 환경에서 특히 설치와 관리가 편리합니다. 저는 홈랩에서 우분투를 주로 쓰는데, MicroK8s는 정말 친숙하게 느껴지더라고요.

간단한 비교 표

두 솔루션의 특징을 한눈에 보기 위해 표로 정리해봤어요.

특징	K3s	MicroK8s
개발사	Rancher Labs	Canonical
설치 방식	단일 바이너리, 스크립트	Snap 패키지
데이터베이스	SQLite (기본), PostgreSQL, MySQL 등	etcd
장점	극강의 경량성, 빠른 설치, 단일 파일	모듈식 애드온, 스냅 자동 업데이트, 고가용성 용이
적합 환경	초소형 엣지, IoT, CI/CD	개발/테스트, 데스크톱, 엣지

경량 쿠버네티스 설치, 어디서부터 시작할까? (실전 구현)

이제 직접 설치해보는 과정을 보여드릴게요. 저는 주로 라즈베리 파이나 집에 굴러다니는 미니 PC에 설치해서 쓰고 있거든요. 여기서는 범용적으로 사용할 수 있는 K3s 설치 예시를 들어볼 텐데, MicroK8s도 과정이 비슷하게 간단합니다.

K3s 설치 예시

제가 실제로 경험해본 K3s는 정말 😎 쉽습니다. 단 한 줄의 명령어로 서버(Master)와 에이전트(Agent)를 세팅할 수 있거든요.

1. 서버 노드(Master) 설치

먼저 클러스터의 컨트롤 플레인(Control Plane) 역할을 할 서버 노드를 깔아봅시다. 보통 가장 먼저 설치하고, 이 노드가 나머지 에이전트 노드들을 관리하게 되거든요. 다음 명령어를 실행하면 K3s가 알아서 설치되고 시작돼요.

curl -sfL https://get.k3s.io | sh -

설치가 끝나면 kubectl 명령어를 바로 사용할 수 있게 돼요. 잘 설치됐는지 확인해볼까요?

sudo k3s kubectl get nodes

자신의 서버 노드가 Ready 상태로 보일 텐데, 이때 느끼는 쾌감은 정말 🎉 입니다.

2. 에이전트 노드(Agent) 추가

이제 클러스터에 워커 노드를 추가할 차례예요. 다른 라즈베리 파이나 미니 PC에 접속해서 다음 명령어를 실행하면 되는데, 여기서 중요한 게 K3S_URL과 K3S_TOKEN입니다.

• K3S_URL: 서버 노드의 IP 주소를 지정합니다.
• K3S_TOKEN: 서버 노드에서 생성된 토큰이에요. 이 토큰은 /var/lib/rancher/k3s/server/node-token 파일에서 확인할 수 있습니다.

# 서버 노드에서 토큰 확인
sudo cat /var/lib/rancher/k3s/server/node-token

# 에이전트 노드에서 설치 (TOKEN과 SERVER_IP는 자신의 환경에 맞게 변경)
curl -sfL https://get.k3s.io | K3S_URL="https://YOUR_SERVER_IP:6443" K3S_TOKEN="K10xxxxxxxxxxxxxxxxxxxx" sh -

모든 에이전트 노드에 이 과정을 반복하면 되는데, 몇 분이 지난 후 서버 노드에서 다시 sudo k3s kubectl get nodes를 실행해보면 새로 추가된 노드들이 보일 거예요. 정말 신기하지 않나요? 😁

이미지: K3s 클러스터에 연결된 노드들의 상태를 보여주는 터미널 화면입니다.

홈랩에서 겪은 삽질 경험과 해결책 (주의사항/트러블슈팅)

13년차 엔지니어라고 해서 삽질을 안 하는 건 아닙니다. 오히려 더 많이 해요. 😅 특히 엣지 환경에서는 예상치 못한 변수들이 많아서 몇 번은 머리를 쥐어뜯었거든요. 제가 직접 겪었던 몇 가지 문제와 그 해결책을 공유해볼게요.

⚠️ 1. 네트워크 문제: 노드 간 통신 장애

정말 흔한 문제예요. 처음엔 분명 잘 연결된 것 같았는데, 어느 순간 노드(Node)들이 NotReady 상태로 바뀌는 경우가 있더라고요. 대부분 방화벽(Firewall)이나 네트워크 설정 때문이었습니다. 특히 라즈베리 파이 같은 작은 디바이스들은 무선 LAN(랜)을 많이 쓰는데, 공유기 설정 때문에 서로 통신이 안 되는 경우도 있었어요.

• 해결책:
• 방화벽 확인: ufw나 firewalld 같은 방화벽이 6443 포트(Port)나 다른 쿠버네티스 관련 포트를 막고 있지 않은지 확인하고 열어줍니다.
• IP 주소 고정: DHCP(동적 호스트 구성 프로토콜)로 IP가 자꾸 바뀌면 노드 통신이 끊기기도 해요. 각 노드의 IP 주소를 고정(Static IP)으로 설정하는 게 좋습니다.
• Cilium/Flannel 로그 확인: CNI(Container Network Interface) 플러그인(Plug-in)인 Cilium이나 Flannel 로그를 확인하면 네트워크 문제를 진단하는 데 정말 큰 도움이 돼요.

⚠️ 2. 리소스 제한: 메모리/CPU 부족

라즈베리 파이 3B+나 4B 모델에 1GB, 2GB 램(RAM)을 가진 노드들을 운영하다 보면 파드(Pod) 몇 개만 돌려도 메모리가 부족하다고 아우성칠 때가 많아요. 특히 메트릭 서버(Metrics Server)나 모니터링 툴(Monitoring Tool)까지 올리면 순식간에 리소스가 바닥나더라고요.

• 해결책:
• 오버프로비저닝 금지: 😭 욕심부리지 마세요! 필요한 파드만 최소한으로 배포합니다.
• 리소스 요청/제한 설정: 디플로이먼트(Deployment) YAML 파일에 resources.requests와 resources.limits를 명확하게 설정해서 파드가 필요한 만큼만 쓰도록 제한하는 거예요.
• 스왑(Swap) 공간 활용: 성능 저하를 감수하고라도 메모리가 정말 부족하다면 스왑 공간을 활성화하는 것도 한 방법입니다. 하지만 이건 최후의 수단으로 생각하세요.

⚠️ 3. SD 카드 수명 문제

라즈베리 파이에서 SD 카드를 부팅 디스크로 쓸 때, 쿠버네티스는 로그(Log)나 데이터베이스 쓰기 작업이 정말 많아서 SD 카드 수명이 급격히 줄어들 수 있어요. 실제로 저도 몇 번 SD 카드가 사망하는 경험을 했습니다. 💀

• 해결책:
• USB SSD 사용: 가능하면 USB 외장 SSD(솔리드 스테이트 드라이브)를 부팅 디스크로 쓰는 게 정말 좋아요. 훨씬 빠르고 안정적이며 수명도 길거든요.
• 로그 회전(Log Rotation) 설정: 로그 파일이 너무 커지지 않도록 logrotate를 설정해서 관리하는 게 중요합니다.

성능 모니터링 및 리소스 관리 팁 (추가적인 팁)

경량 쿠버네티스라고 해서 모니터링을 소홀히 하면 안 돼요. 오히려 작은 시스템일수록 더욱 꼼꼼하게 지켜봐야 합니다. 제가 실제로 쓰는 몇 가지 팁을 알려드릴게요.

1. Prometheus/Grafana로 시각화

작은 규모의 클러스터라도 프로메테우스(Prometheus)와 그라파나(Grafana)는 거의 필수라고 생각해요. 노드의 CPU(중앙 처리 장치), 메모리(Memory) 사용량, 네트워크 트래픽(Traffic) 등을 실시간으로 시각화해서 볼 수 있거든요. K3s나 MicroK8s 모두 Prometheus를 쉽게 설치할 수 있는 방법을 제공합니다.

# MicroK8s의 경우
microk8s enable prometheus

# K3s의 경우, Helm 차트(Chart)로 설치
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm install prometheus prometheus-community/kube-prometheus-stack

저는 Grafana 대시보드를 띄워놓고 커피 마시면서 클러스터 상태를 확인하는 게 소소한 낙이에요. 😄

2. 리소스 쿼터(Resource Quotas) 설정

여러 애플리케이션(Application)을 배포할 때, 특정 네임스페이스(Namespace)나 파드가 너무 많은 리소스를 독점하지 않도록 리소스 쿼터를 설정하는 게 중요해요. 특히 홈랩처럼 리소스가 제한적인 환경에서는 더욱 그렇거든요.

# resource-quota.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: pod-quota
spec:
  hard:
    pods: "10"
    requests.cpu: "1"
    requests.memory: "1Gi"
    limits.cpu: "2"
    limits.memory: "2Gi"

kubectl apply -f resource-quota.yaml -n my-namespace

이렇게 하면 my-namespace 안에서는 최대 10개의 파드만 생성할 수 있고, CPU와 메모리도 지정된 범위 내에서만 쓸 수 있게 된답니다. 💸

이미지: Grafana 대시보드에서 경량 쿠버네티스 클러스터의 실시간 리소스 사용량을 모니터링하는 모습입니다.

실제 운영 사례와 얻은 교훈 (검증/결과)

저는 홈랩에서 K3s 클러스터를 여러 대 운영하고 있어요. 주로 하는 일들을 정리해보면 다음과 같습니다.

• 개인 웹사이트/블로그 호스팅: Nginx Ingress Controller(엔진엑스 인그레스 컨트롤러)와 Cert-Manager(서트 매니저)를 활용해서 Let's Encrypt(렛츠 인크립트) SSL(보안 소켓 계층) 인증서를 자동으로 발급받아 제 블로그를 안전하게 운영하고 있어요.
• IoT 데이터 수집 및 처리: 여러 센서(Sensor)에서 들어오는 데이터를 Kafka(카프카)로 수집하고, Go(고) 언어로 작성된 경량 워커(Worker) 파드에서 데이터를 처리한 후 InfluxDB(인플럭스디비)에 저장하는 파이프라인(Pipeline)을 구축했어요.
• CI/CD 테스트 환경: 작은 규모의 개발 프로젝트를 할 때, 젠킨스(Jenkins)나 아르고 CD(Argo CD)를 K3s 클러스터에 배포해서 CI/CD(지속적 통합/지속적 배포) 파이프라인 테스트 환경으로 활용하고 있습니다.

이런 실제 운영 사례들을 통해 얻은 가장 큰 교훈은, '작은 것이 아름답다'는 거예요. 😊 복잡하고 무거운 쿠버네티스 기능을 모두 필요로 하지 않는 엣지 환경에서는 K3s나 MicroK8s처럼 핵심 기능에만 집중하고 가볍게 동작하는 솔루션이 훨씬 더 효율적이더라고요.

물론, 완전한 프로덕션(Production) 환경에서 엔터프라이즈(Enterprise)급 요구사항을 만족시키기에는 제약이 있을 수 있어요. 하지만 소규모 팀, 홈랩, IoT 디바이스, 임베디드(Embedded) 시스템 같은 곳에서는 정말 '게임 체인저(Game Changer)'라고 할 수 있죠. 경량 쿠버네티스 덕분에 엣지 컴퓨팅의 문턱이 훨씬 낮아졌다고 저는 생각합니다.

이미지: 경량 쿠버네티스의 주요 장점과 고려해야 할 한계점을 시각적으로 요약한 인포그래픽입니다.

마무리: 엣지 쿠버네티스의 미래와 다음 단계

오늘은 K3s와 MicroK8s를 중심으로 경량 엣지 쿠버네티스를 구축하고 운영했던 제 경험을 공유해드렸어요. 처음엔 단순히 '작은 쿠버네티스' 정도로 생각했는데, 직접 써보니까 엣지 환경에 특화된 기능과 철학이 담겨 있더라고요. 설치는 쉽고 리소스 소모는 적어서, 저처럼 홈랩을 꾸리거나 소규모 엣지 프로젝트를 진행하는 분들께는 정말 강력 추천하고 싶은 솔루션입니다. 💪

물론, 모든 기술이 그렇듯 장점만 있는 건 아니에요. 풀 스택 쿠버네티스가 제공하는 모든 기능을 기대하기보다는, 자신의 환경과 필요한 기능에 맞춰 현명하게 선택하고 활용하는 지혜가 필요합니다. 하지만 '경량'이라는 이름표를 달고 엣지 컴퓨팅의 중요한 축으로 자리 잡은 K3s와 MicroK8s의 미래는 앞으로도 계속 밝을 거라고 확신해요.

다음번에는 이 경량 쿠버네티스 클러스터 위에 GitOps(깃옵스) 환경을 구축해서 애플리케이션 배포를 자동화하는 방법에 대해 다뤄볼까 합니다. 기대해주세요! 혹시 K3s나 MicroK8s를 사용하면서 겪었던 재미있는 경험이나 삽질 스토리가 있다면 댓글로 공유해주세요. 저도 배우는 게 많을 것 같습니다. 😊

📚 함께 읽으면 좋은 글

• Rancher vs OpenShift: 엔터프라이즈 쿠버네티스 플랫폼 비용 비교 분석
• GKE WireGuard 네트워크 장애: 디버깅 및 해결 사례 연구
• Cilium CNI 성능 벤치마크: Calico, Flannel과 직접 비교