[홈랩] 라즈베리 파이 Kubernetes 클러스터 1년 운영 회고

라즈베리 파이 Kubernetes 클러스터를 집에서 1년 정도 굴려보면, 처음 기대했던 그림과 실제 운영 현실이 꽤 다르다는 걸 알게 됩니다. 저도 처음엔 “작고 조용한 장비 몇 대로 Kubernetes(쿠버네티스, 컨테이너 오케스트레이션 플랫폼)까지 돌리면 완벽한 홈랩 아니겠나” 싶었거든요. 실제로 해보니까 분명 배운 건 많았고, 홈랩 Kubernetes 환경으로는 정말 훌륭했습니다. 다만 운영 관점에서는 생각보다 손이 많이 가고, ARM Kubernetes 환경 특유의 제약도 분명하더라고요.

특히 k3s 라즈베리 파이 조합은 입문 장벽이 낮아서 많이들 시작하시는데, 막상 6개월, 1년 넘어가면 “왜 자꾸 스토리지가 문제지?”, “왜 어떤 이미지는 ARM에서 안 돌지?”, “왜 업그레이드가 무섭지?” 같은 현실적인 질문이 생깁니다. 오늘 글은 그런 부분을 미화하지 않고, 제가 직접 운영하면서 느낀 점을 정리한 회고입니다. 혹시 집에서 ARM Kubernetes 클러스터를 꾸려보려는 분이라면, 시행착오를 조금 덜 하실 수 있을 겁니다.

라즈베리 파이 여러 대와 스위치, 스토리지, 라우터가 연결된 홈랩 Kubernetes 아키텍처 예시입니다.

1. 왜 라즈베리 파이 Kubernetes 클러스터를 만들었나

시작 이유는 단순했습니다. 클라우드에서만 Kubernetes를 보면 너무 추상적으로 느껴지거든요. 노드가 실제로 꺼지면 어떻게 되는지, 네트워크가 꼬이면 어디서부터 봐야 하는지, 스토리지가 왜 중요한지 같은 건 직접 만져봐야 감이 옵니다. 라즈베리 파이는 소비전력이 낮고, 크기도 작고, 무엇보다 “망가져도 다시 해보자” 할 수 있는 범위라서 홈랩에 잘 맞습니다.

쉽게 말해, 홈랩 Kubernetes는 서비스 운영을 위한 정답이라기보다 분산 시스템의 감각을 몸으로 익히는 연습장에 가깝습니다. 이 포인트를 초반에 이해하면 만족도가 높아집니다. 반대로 “싼 비용으로 프로덕션 비슷하게 다 된다”에 초점을 맞추면 금방 피곤해질 수 있습니다.

• 좋았던 점: 노드 추가/제거, 장애 테스트, 배포 자동화, Ingress(인그레스, 외부 트래픽 진입점), Persistent Volume(퍼시스턴트 볼륨, 영속 스토리지) 개념을 직접 익히기 좋았습니다.
• 힘들었던 점: SD 카드 내구성, 전원 안정성, ARM 이미지 호환성, 발열, 스토리지 성능, 업그레이드 순서 같은 운영 이슈가 계속 따라왔습니다.

2. 라즈베리 파이와 k3s, 무엇이 잘 맞았나

제가 여러 선택지 중에서 k3s를 선호했던 이유는 명확합니다. k3s는 Kubernetes 경량 배포판으로 알려져 있고, 홈랩이나 에지 환경에서 많이 쓰입니다. 풀 사이즈 Kubernetes를 직접 구성하는 것보다 훨씬 빠르게 시작할 수 있었고, 필요한 핵심 개념은 대부분 그대로 가져갈 수 있었습니다. 처음엔 이게 뭔가 싶었는데, 막상 써보니 “학습용으로는 정말 적절하다”는 생각이 들더라고요.

여기서 중요한 포인트는 k3s가 Kubernetes를 쉽게 만들어주지만, 운영 복잡도 자체를 없애주진 않는다는 점입니다. 설치는 쉬워도 운영은 결국 운영이죠.

3. 홈랩 Kubernetes 구성은 어떻게 잡았나

구성 자체는 복잡하게 시작하지 않는 게 좋습니다. 저도 초반에는 컨트롤 플레인(Control Plane, 클러스터 제어 영역)과 워커 노드(Worker Node, 실제 워크로드 실행 노드)를 나누는 개념부터 익혔고, 네트워크와 스토리지는 최대한 단순하게 가져갔습니다.

3-1. 기본 구성 원칙

1. 운영체제는 최소 구성으로 설치합니다.
2. 노드 이름과 IP 대역을 미리 정리합니다.
3. 시간 동기화와 고정 IP를 먼저 잡습니다.
4. 클러스터 설치 전 컨테이너 이미지가 ARM을 지원하는지 확인합니다.
5. 스토리지는 처음부터 분리할지, 로컬 디스크로 시작할지 결정합니다.

제가 직접 해보니 가장 많이 꼬이는 건 Kubernetes 자체보다 주변부였습니다. DNS(도메인 네임 시스템), DHCP 예약, 공유기 설정, 스위치 품질, 전원 어댑터 같은 것들이요. 진짜 삽질은 여기서 많이 합니다.

3-2. 예시 설치 흐름

아래는 홈랩에서 많이 쓰는 형태의 아주 기본적인 흐름입니다.

# 컨트롤 플레인 노드에서 k3s 설치
curl -sfL https://get.k3s.io | sh -

# 토큰 확인
sudo cat /var/lib/rancher/k3s/server/node-token

# 워커 노드에서 조인
curl -sfL https://get.k3s.io | K3S_URL=https://CONTROL_PLANE_IP:6443 K3S_TOKEN=YOUR_TOKEN sh -

설치는 생각보다 금방 끝납니다. 문제는 그 다음이죠. 노드가 붙었다고 끝이 아니라, 이제부터가 진짜 시작입니다.

# 상태 확인
sudo kubectl get nodes -o wide
sudo kubectl get pods -A

# 간단한 테스트 배포
sudo kubectl create deployment hello --image=nginx
sudo kubectl expose deployment hello --port=80 --type=ClusterIP

3-3. 예시 매니페스트

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: demo-web
  template:
    metadata:
      labels:
        app: demo-web
    spec:
      containers:
        - name: web
          image: nginx:stable
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: demo-web
spec:
  selector:
    app: demo-web
  ports:
    - port: 80
      targetPort: 80

k3s 라즈베리 파이 환경에서 컨트롤 플레인과 워커 노드가 연결되는 기본 구조를 보여주는 다이어그램입니다.

4. 1년 운영하면서 체감한 현실적인 문제들

이 섹션이 아마 제일 중요할 겁니다. 블로그나 영상에서는 “설치 성공”까지가 잘 보이는데, 실제 운영은 그 뒤의 평범한 장애와 유지보수에서 갈립니다.

4-1. 스토리지가 생각보다 훨씬 중요했습니다

처음엔 SD 카드로도 되겠지 싶었는데, 오래 굴릴수록 로그, 컨테이너 레이어, 작은 쓰기 작업이 누적되면서 성능과 안정성 이슈가 슬슬 보였습니다. 특히 재부팅 후 상태가 애매해지거나, 특정 파드(Pod, Kubernetes의 최소 배포 단위)가 느리게 올라오는 상황을 몇 번 겪으니 금방 교훈이 생기더라고요.

교훈: 홈랩이라도 스토리지는 가볍게 보면 안 됩니다. 가능하면 더 안정적인 저장장치 구성을 고민하는 게 좋습니다.

4-2. ARM Kubernetes는 이미지 호환성을 항상 봐야 합니다

이건 진짜 자주 나옵니다. 문서대로 배포했는데 안 뜹니다. 로그를 보면 이미지가 ARM 아키텍처를 제대로 지원하지 않거나, 특정 툴체인이 x86 중심으로 만들어진 경우가 있거든요. 저도 처음엔 네트워크 문제인가 싶어서 한참 봤는데, 결국 이미지 아키텍처 문제였던 적이 있었습니다.

그래서 지금은 새 앱을 올리기 전에 아래처럼 확인하는 습관을 들였습니다.

• 공식 이미지인지 확인
• 멀티 아키텍처(multi-arch) 지원 여부 확인
• ARM64 태그 또는 매니페스트 지원 여부 확인
• 헬름 차트(Helm Chart, Kubernetes 패키지 템플릿)가 ARM에서 문제 사례가 없는지 확인

4-3. 전원과 발열은 사소해 보여도 누적되면 문제입니다

홈랩은 책상 위에서 끝나는 실험 같지만, 결국 24시간 켜두는 장비입니다. 전원이 순간적으로 불안정하면 노드가 이유 없이 사라진 것처럼 보일 수 있고, 발열이 누적되면 성능 저하나 불안정성으로 이어질 수 있습니다. 저는 한동안 Kubernetes 문제인 줄 알고 로그만 팠는데, 알고 보니 전원 쪽이 애매했던 적도 있었습니다. 이건 진짜 허탈하더라고요.

5. ⚠️ 실제로 겪었던 트러블슈팅

여기서는 조금 더 실전적으로 적어보겠습니다. 저도 처음엔 헷갈렸는데, 막상 패턴이 보이기 시작하면 접근 순서가 정리됩니다.

5-1. 노드가 갑자기 NotReady가 될 때

1. kubectl get nodes로 상태를 먼저 봅니다.
2. kubectl describe node로 이벤트를 확인합니다.
3. 해당 장비의 전원, 네트워크 링크, 디스크 상태를 OS 레벨에서 봅니다.
4. 문제가 반복되면 Kubernetes 내부보다 하드웨어/OS 쪽을 먼저 의심합니다.

sudo kubectl get nodes
sudo kubectl describe node worker-01
journalctl -u k3s -n 100
journalctl -u k3s-agent -n 100

5-2. 파드가 계속 재시작될 때

처음엔 애플리케이션 버그라고만 생각했었는데, 실제로는 이미지 아키텍처 미지원, 환경 변수 누락, 볼륨 마운트 실패, 리소스 부족 등 원인이 다양했습니다. 여기서 중요한 건 로그와 이벤트를 같이 보는 것입니다.

sudo kubectl get pods -A
sudo kubectl describe pod POD_NAME -n NAMESPACE
sudo kubectl logs POD_NAME -n NAMESPACE --previous

5-3. Ingress가 안 열릴 때

Ingress(인그레스, 외부 트래픽 진입점)는 홈랩에서 체감 난이도가 꽤 있습니다. 공유기 포트포워딩, 내부 DNS, 서비스 타입, Ingress Controller(인그레스 컨트롤러) 설정이 다 맞아야 하거든요. 한 군데만 틀려도 접속이 안 됩니다.

• 서비스가 ClusterIP인지 NodePort인지 확인
• Ingress 리소스의 호스트 이름이 DNS와 맞는지 확인
• 공유기 포트포워딩 규칙 확인
• 내부망 테스트와 외부망 테스트를 분리해서 확인

이거 진짜 편하더라고요 싶은 구조는, 처음부터 도메인과 내부 DNS 전략을 정해두는 겁니다. 대충 시작하면 나중에 더 큰 삽질로 돌아옵니다.

노드 상태, 파드 상태, 리소스 사용량을 함께 점검하는 홈랩 Kubernetes 운영 화면을 표현한 이미지입니다.

6. 검증은 어떻게 했나

클러스터가 “떠 있다”와 “운영 가능하다”는 다릅니다. 저는 최소한 아래 기준으로 확인했습니다.

1. 노드가 모두 Ready 상태인지
2. 기본 시스템 파드가 안정적으로 유지되는지
3. 테스트 애플리케이션이 재배포 후에도 정상 기동하는지
4. 노드 한 대를 내렸을 때 서비스 복구 흐름이 보이는지
5. Ingress를 통한 내부 접근이 되는지

sudo kubectl get nodes
sudo kubectl get pods -A
sudo kubectl rollout restart deployment/demo-web
sudo kubectl rollout status deployment/demo-web
sudo kubectl get svc,ingress -A

제가 실제로 만족했던 순간은, 뭔가 화려한 대시보드가 아니라 문제가 생겼을 때 원인을 좁혀갈 수 있게 된 시점이었습니다. “아, 이건 Kubernetes보다는 스토리지 쪽이네”, “이건 애플리케이션 이미지 문제네” 같은 판단이 빨라지더라고요. 그게 1년 운영의 가장 큰 수확이었습니다.

7. 1년 운영 후 느낀 장점과 한계

냉정하게 말하면, 장기 운영의 편안함만 놓고 보면 x86 미니 PC나 소형 서버가 더 나은 선택일 수 있습니다. 하지만 배움의 밀도는 라즈베리 파이 Kubernetes 클러스터가 정말 높았습니다. 장애 하나하나가 다 수업료였고, 그 덕분에 실무에서 로그를 보는 눈도 꽤 달라졌습니다.

8. 이런 분께는 추천하고, 이런 경우는 말리고 싶습니다

추천하는 경우

• Kubernetes를 손으로 익히고 싶은 분
• 홈랩 Kubernetes 환경에서 배포 자동화와 운영 흐름을 경험해보고 싶은 분
• ARM Kubernetes 제약까지 포함해서 배우고 싶은 분

말리고 싶은 경우

• 처음부터 안정적인 장기 서비스 운영이 목표인 분
• 트러블슈팅 자체를 즐기기 어려운 분
• 하드웨어/네트워크까지 만지는 게 부담스러운 분

사실 이 부분이 제일 현실적인 결론입니다. 라즈베리 파이 클러스터는 멋있습니다. 그런데 편한 건 아닙니다. 이 차이를 알고 시작하면 만족도가 높고, 모르고 시작하면 생각보다 금방 지칩니다.

학습 효과, 전력, 안정성, 스토리지, 운영 난이도를 한눈에 비교하는 요약 인포그래픽입니다.

9. 마무리: 홈랩의 현실과 교훈

1년 운영 후 제 결론은 이렇습니다. 라즈베리 파이 Kubernetes는 최고의 학습 장비 중 하나지만, 최고의 운영 장비는 아닐 수 있습니다. 이 문장을 받아들이고 시작하면 훨씬 좋습니다. 저도 처음엔 “이걸로 다 되겠는데?” 싶었는데, 실제로 써보니까 홈랩의 현실은 꽤 다층적이더라고요.

그래도 후회는 없습니다. 네트워크, 스토리지, 스케줄링, Ingress, 장애 대응, 로그 분석까지 한 번에 묶어서 배울 수 있었거든요. 특히 k3s 라즈베리 파이 조합은 작은 비용으로 큰 학습을 주는 도구였습니다. 다만 다음에 다시 구성한다면, 저는 초반부터 스토리지 전략과 전원 안정성, 그리고 ARM 이미지 호환성 점검 루틴을 더 엄격하게 가져갈 겁니다.

혹시 지금 홈랩 Kubernetes를 고민 중이시라면, 제 추천은 이거예요. 처음엔 작게 시작하세요. 노드 수보다 운영 경험이 먼저입니다. 그리고 성공 기준을 “오래 켜두기”보다 “문제가 생겼을 때 이해할 수 있는가”에 두시면 훨씬 많이 남습니다.

다음 글에서는 홈랩에서 자주 쓰는 Ingress(인그레스, 외부 트래픽 진입점) 구성이나, 모니터링 스택을 어떻게 가볍게 올릴지 다뤄볼 예정입니다. 이전 글이 있다면 함께 보셔도 흐름 잡는 데 도움이 되실 겁니다.

정리 FAQ

라즈베리 파이 Kubernetes 클러스터는 실사용에 적합한가요?

가벼운 내부 서비스나 학습 목적에는 괜찮지만, 안정성이 아주 중요한 운영 환경이라면 더 여유 있는 하드웨어가 낫습니다.

홈랩 Kubernetes에 k3s를 많이 쓰는 이유는 뭔가요?

설치와 초기 구성이 비교적 단순하고, Kubernetes 핵심 개념을 익히기에 충분하기 때문입니다.

ARM Kubernetes에서 가장 먼저 확인할 건 뭔가요?

컨테이너 이미지의 ARM 지원 여부, 스토리지 구성, 전원 안정성 이 세 가지를 먼저 보시면 됩니다.