[k8s] MicroK8s 벤치마크: K3s와 엣지 환경 성능 비교 [실전 가이드]

목차

• 1. 왜 엣지 환경에서는 MicroK8s 벤치마크가 중요할까
• 2. MicroK8s와 K3s, 쉽게 말해 뭐가 다를까
• 3. MicroK8s 벤치마크는 무엇을 비교해야 의미가 있을까
• 4. 제가 홈랩에서 잡은 테스트 조건
• 5. 실전 구현: MicroK8s와 K3s 벤치마크 준비
• 5-1. MicroK8s 설치와 기본 확인
• 5-2. K3s 설치와 기본 확인
• 5-3. 공통 워크로드 배포
• 5-4. 유휴 리소스와 파드 상태 측정
• 6. ⚠️ 실제로 겪었던 문제와 트러블슈팅
• 6-1. 애드온 차이 때문에 공정 비교가 안 되는 문제
• 6-2. ARM 서버에서 스토리지 지연 때문에 체감이 달라지는 문제
• 6-3. 첫 부팅과 재부팅 후 상태가 다른 문제
• 7. 검증과 결과 해석: 숫자보다 패턴을 보셔야 합니다
• 8. 어떤 환경에 무엇을 고르면 좋을까
• 9. 정리와 다음 단계
• 자주 묻는 질문
• Q1. MicroK8s와 K3s 중 뭐가 무조건 더 빠른가요?
• Q2. 엣지 컴퓨팅에서는 무엇을 먼저 봐야 하나요?
• Q3. 홈랩 입문자는 무엇으로 시작하면 좋을까요?

[인프라] MicroK8s 벤치마크: K3s와 엣지 환경 리소스 사용량 비교

홈랩을 굴리다 보면 결국 한 번은 부딪히는 주제가 있습니다. 바로 MicroK8s 벤치마크를 어떻게 봐야 하느냐는 점이거든요. 저도 ARM 서버를 만지면서 처음엔 "둘 다 경량 쿠버네티스인데 뭐가 그렇게 다르지?" 싶었는데, 실제로 써보니까 꽤 차이가 있더라고요. 특히 엣지 컴퓨팅이나 소형 ARM 보드, 미니 PC처럼 자원이 넉넉하지 않은 환경에서는 이런 차이가 더 크게 체감됩니다.

이번 글에서는 MicroK8s와 K3s 성능 비교를 단순한 스펙 나열이 아니라, 실제로 어떤 항목을 벤치마크해야 의미가 있는지 중심으로 정리해보겠습니다. 제가 직접 홈랩에서 테스트할 때 썼던 방식, 삽질했던 포인트, 그리고 해석할 때 조심해야 할 점까지 같이 적어볼게요.

엣지 환경에서 경량 쿠버네티스를 비교하는 전체 구성을 한눈에 보여주는 이미지입니다.

1. 왜 엣지 환경에서는 MicroK8s 벤치마크가 중요할까

데이터센터에서는 CPU랑 메모리를 조금 더 쓰더라도 관리 편의성이 좋으면 넘어가는 경우가 많습니다. 근데 엣지에서는 얘기가 달라집니다. 1~2GB 메모리 차이, 디스크 I/O 초기화 시간, 컨트롤 플레인(control plane, 클러스터 제어 영역) 기동 속도 같은 게 꽤 민감하게 다가오거든요.

쉽게 말해, 같은 Kubernetes(쿠버네티스, 컨테이너 오케스트레이션 플랫폼) 계열이라도 무엇을 기본으로 포함하느냐, 어떤 런타임을 묶어 배포하느냐, 초기 설치와 운영 자동화가 어디까지 되어 있느냐에 따라 체감 리소스 사용량이 달라집니다. 그래서 MicroK8s 벤치마크를 볼 때는 숫자 하나보다도 "어떤 조건에서 잰 숫자인가?"를 먼저 보셔야 합니다.

2. MicroK8s와 K3s, 쉽게 말해 뭐가 다를까

저도 처음엔 둘 다 그냥 작은 경량 쿠버네티스 배포판 정도로 이해했었는데요, 실제로는 운영 철학이 꽤 다릅니다.

항목	MicroK8s	K3s
배포 성격	Canonical에서 제공하는 경량 쿠버네티스 배포판	Rancher 진영에서 시작된 경량 쿠버네티스 배포판
설치 방식	snap 기반 설치가 대표적	단일 바이너리 중심 설치 경험이 간단한 편
체감 특징	애드온(add-on, 부가 기능) 관리가 편함	가볍고 빠르게 올리기 좋음
엣지 적합성	기능 일체감이 좋음	최소 자원 환경에서 선호되는 경우가 많음

여기서 중요한 포인트! 경량 쿠버네티스라고 해서 무조건 가장 적은 메모리만 쓰는 제품을 고르면 끝은 아닙니다. 예를 들어 Ingress(인그레스, 외부 트래픽 진입점), DNS, StorageClass(스토리지 클래스, 동적 볼륨 정책) 같은 기본 기능을 나중에 붙이기 시작하면, 처음의 "가벼움"이 생각보다 금방 상쇄되거든요.

3. MicroK8s 벤치마크는 무엇을 비교해야 의미가 있을까

MicroK8s 벤치마크라고 검색하면 CPU, 메모리 그래프 하나 딱 보여주는 자료가 많은데요, 실무에서는 그걸로 판단하기 어렵습니다. 제가 실제로 비교할 때는 아래 항목을 기준으로 잡았습니다.

• Idle resource usage(유휴 리소스 사용량): 아무 워크로드 없을 때 CPU와 메모리 사용량
• Cold start time(콜드 스타트 시간): 설치 후 API 응답 가능 상태까지 걸리는 시간
• Pod scheduling latency(파드 스케줄링 지연): 테스트 파드가 실제 Running 상태가 되기까지의 시간
• Add-on overhead(부가 기능 오버헤드): DNS, Ingress, Metrics 추가 후 증가 폭
• Disk footprint(디스크 점유): 설치 후 데이터 디렉터리 증가량

사실 이 다섯 개만 잡아도 꽤 감이 옵니다. 특히 ARM 서버에서는 디스크 성능이 병목이 되는 경우가 많아서, 메모리만 보면 놓치는 게 많더라고요.

4. 제가 홈랩에서 잡은 테스트 조건

벤치마크는 조건 통제가 핵심입니다. 같은 하드웨어, 같은 OS 계열, 같은 컨테이너 이미지, 같은 측정 횟수로 맞춰야 비교가 그나마 공정해집니다. 저는 아래처럼 맞춰서 보는 편입니다.

1. 테스트 대상 노드는 동일한 ARM 기반 장비 또는 동일 사양 미니 PC로 구성합니다.
2. 운영체제는 같은 Ubuntu 계열로 맞춥니다.
3. 백그라운드 서비스와 자동 업데이트는 측정 전 최대한 정리합니다.
4. MicroK8s와 K3s는 각각 단일 노드로 먼저 비교합니다.
5. 기본 상태와 add-on 활성화 상태를 따로 측정합니다.
6. 각 측정은 3회 이상 반복해서 편차를 확인합니다.

이 부분을 안 맞추면 진짜 헷갈립니다. 저도 처음엔 결과가 들쭉날쭉해서 한참 헤맸는데, 알고 보니 한쪽은 메트릭 수집기가 떠 있었고 다른 쪽은 아니더라고요. 삽질 좀 했습니다 ㅎㅎ

5. 실전 구현: MicroK8s와 K3s 벤치마크 준비

5-1. MicroK8s 설치와 기본 확인

sudo snap install microk8s --classic
sudo usermod -a -G microk8s $USER
newgrp microk8s
microk8s status --wait-ready
microk8s kubectl get nodes -o wide

MicroK8s는 snap 기반이라 설치 경험이 꽤 일관적입니다. 대신 snapd 상태나 채널(channel, 배포 트랙)에 따라 초기 준비 시간이 다르게 느껴질 수 있습니다.

5-2. K3s 설치와 기본 확인

curl -sfL https://get.k3s.io | sh -
sudo kubectl get nodes -o wide
sudo systemctl status k3s --no-pager

K3s는 설치가 정말 간단합니다. 처음 써보면 "이렇게 빨리 올라온다고?" 싶은 느낌이 있어요. 엣지 환경에서 자주 언급되는 이유가 괜히 있는 게 아니더라고요.

단일 노드 환경에서 두 배포판의 설치 직후 상태를 비교하는 장면을 보여주는 이미지입니다.

5-3. 공통 워크로드 배포

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-bench
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-bench
  template:
    metadata:
      labels:
        app: nginx-bench
    spec:
      containers:
      - name: nginx
        image: nginx:stable
        ports:
        - containerPort: 80
---

kubectl apply -f nginx-bench.yaml
kubectl get pods -w

여기서는 복잡한 앱보다 단순한 워크로드가 낫습니다. 이유는 비교 대상을 경량 쿠버네티스 배포판 자체로 최대한 좁혀야 하기 때문입니다.

5-4. 유휴 리소스와 파드 상태 측정

free -h
vmstat 1 5
ps aux --sort=-%mem | head
kubectl get pods -A
kubectl top nodes
kubectl top pods -A

Metrics Server(메트릭 서버, 리소스 수집 컴포넌트)가 없는 상태라면 kubectl top이 바로 안 될 수 있습니다. 이때는 OS 레벨 지표와 함께 보셔야 합니다.

6. ⚠️ 실제로 겪었던 문제와 트러블슈팅

6-1. 애드온 차이 때문에 공정 비교가 안 되는 문제

이게 제일 흔합니다. MicroK8s는 add-on 활성화가 쉽고, K3s는 기본 구성이 상대적으로 간결한 편이라 시작점이 다를 수 있거든요. 그래서 기본 설치 상태와 필수 기능 포함 상태를 따로 비교해야 합니다.

microk8s enable dns ingress metrics-server
kubectl get pods -A

혹시 이런 경험 있으신가요? "왜 MicroK8s가 더 무겁지?" 하고 봤더니 사실 기능이 더 많이 켜져 있었던 겁니다.

6-2. ARM 서버에서 스토리지 지연 때문에 체감이 달라지는 문제

특히 SD 카드나 느린 eMMC 기반 장비에서는 API 응답보다 이미지 풀(image pull, 컨테이너 이미지 다운로드)과 파일 시스템 동기화가 더 큰 변수였습니다. 그래서 이미지를 미리 받아둔 상태와 처음 내려받는 상태를 분리해서 봐야 해요.

6-3. 첫 부팅과 재부팅 후 상태가 다른 문제

처음엔 이게 뭔가 싶었는데, 재부팅 후 서비스 재기동 순서와 캐시 영향으로 결과가 다르게 나오더라고요. 그래서 가능하면 아래처럼 측정 구간을 분리하는 게 좋습니다.

• 설치 직후 측정
• 재부팅 후 안정화 뒤 측정
• 워크로드 배포 후 측정

7. 검증과 결과 해석: 숫자보다 패턴을 보셔야 합니다

제가 여러 번 비교해보면서 느낀 패턴은 이렇습니다. K3s는 초기 설치와 기동이 간결하게 느껴지고, MicroK8s는 기능 통합과 관리 편의성이 좋다는 점입니다. 그리고 K3s 성능 비교 자료를 볼 때 자주 나오는 "더 가볍다"는 평은, 대체로 최소 구성 기준에서 이해하면 맞습니다.

반대로 실서비스에 가까운 구성으로 DNS, Ingress, 모니터링 관련 요소를 하나씩 붙이기 시작하면, 단순 메모리 숫자만으로는 승부가 잘 안 나기도 합니다. 여기서 중요한 건 운영 편의성 대비 리소스 비용입니다. CPU 몇 퍼센트, 메모리 몇백 MB보다도 내가 관리하면서 덜 고생하는 쪽이 전체 비용은 더 낮을 수 있거든요.

유휴 상태와 워크로드 배포 후 상태를 비교하는 벤치마크 대시보드 이미지입니다.

비교 관점	MicroK8s에서 보기 좋은 점	K3s에서 보기 좋은 점
초기 셋업	애드온 중심 운영이 편함	빠르고 단순하게 시작 가능
리소스 민감 환경	기능 포함 시 구성 일관성 확보	최소 구성에서 부담이 적은 편
실험/홈랩	여러 기능을 켜보며 배우기 좋음	가볍게 여러 노드 실험하기 좋음
운영 판단 기준	기능 통합성	경량성과 단순성

즉, MicroK8s 벤치마크 결과를 해석할 때는 "기본 상태 비교인지", "실제 운영 기능 포함 비교인지"를 꼭 구분하셔야 합니다.

8. 어떤 환경에 무엇을 고르면 좋을까

• 초소형 엣지 노드나 아주 타이트한 리소스 환경이면 K3s 쪽이 출발이 편할 가능성이 큽니다.
• 학습, 홈랩, 기능 실험을 자주 하신다면 MicroK8s의 add-on 경험이 꽤 편합니다.
• ARM 서버를 여러 대 운영하면서 자동화까지 보실 거라면 설치 이후 운영 스크립트와 모니터링 방식까지 같이 검토하셔야 합니다.

저는 개인적으로 "최소 자원 + 빠른 프로비저닝"이 우선이면 K3s를 먼저 보고, "기능 포함 상태에서 일관된 운영 경험"이 중요하면 MicroK8s를 먼저 봅니다. 둘 중 하나가 절대적으로 우월하다기보다, 우선순위가 다르다고 보는 게 맞더라고요.

9. 정리와 다음 단계

정리해보면, MicroK8s 벤치마크는 단순히 누가 더 메모리를 덜 먹느냐로 끝나지 않습니다. 엣지 환경에서는 설치 방식, 애드온 구조, 스토리지 특성, 재부팅 후 복구 속도, 그리고 운영 중 손이 얼마나 가는지가 다 같이 중요합니다. 제가 직접 해보니 숫자 하나보다 패턴이 더 중요했고, 특히 비교 조건을 통일하는 게 절반이더라고요.

다음 글에서는 실제 홈랩 기준으로 Prometheus(프로메테우스, 메트릭 수집 시스템)와 Grafana(그라파나, 시각화 도구)를 붙여서 MicroK8s와 K3s의 장기 모니터링 방법도 다뤄볼 예정입니다. 이전 글에서 다뤘던 홈랩 네트워크 설계 내용과도 연결해서 보시면 더 이해가 쉬우실 겁니다.

어떤 조건에서 어떤 배포판이 더 잘 맞는지 한 장으로 정리한 요약 이미지입니다.

자주 묻는 질문

Q1. MicroK8s와 K3s 중 뭐가 무조건 더 빠른가요?

무조건이라고 말하긴 어렵습니다. 최소 구성에서는 K3s가 가볍게 느껴지는 경우가 많지만, 운영 기능을 붙인 뒤에는 비교 조건에 따라 달라집니다.

Q2. 엣지 컴퓨팅에서는 무엇을 먼저 봐야 하나요?

CPU보다도 메모리, 디스크 I/O, 재기동 안정성을 먼저 보시는 걸 권장합니다. 특히 느린 저장장치에서는 체감 차이가 크게 납니다.

Q3. 홈랩 입문자는 무엇으로 시작하면 좋을까요?

기능을 빨리 배우고 싶으면 MicroK8s, 아주 가볍게 여러 노드를 올려보고 싶으면 K3s가 편할 수 있습니다.

📚 함께 읽으면 좋은 글

• Istio 프로덕션 도입 1년: 서비스 메시 운영에서 얻은 교훈과 팁
• Longhorn 1년 운영기: 안정성과 성능 정리
• Ingress Controller 비용 분석: 효율적인 선택 가이드
• Linux 커널 튜닝으로 보는 네트워크 I/O 벤치마크 분석
• CIS 벤치마크 기반 서버 보안 강화: 실제 적용 사례와 효과