[프로젝트 3]🌐 사내망 DHCP가 클러스터를 죽였다 – K3s 전면 재구축과 GitOps 완성기

2편에서 K3s 클러스터를 겨우 올렸다고 했죠. 이번 편은 그걸 전부 다 날리고 처음부터 다시 만든 이야기입니다. MetalLB 설치 하나가 클러스터 전체를 무너뜨렸고, 원인을 파고들다가 사내망 DHCP와 노드 IP가 충돌하고 있었다는 걸 발견했습니다. 그 삽질을 통해 결국 훨씬 견고한 아키텍처가 완성됐고, 그 위에 GitOps 파이프라인까지 올라갔습니다.

🔗 DevOps 위키 상세 문서: GitHub Wiki — DevOps | GitOps 실증

---

💥 Episode 5. MetalLB 설치가 클러스터를 통째로 무너뜨렸다

LoadBalancer 타입 서비스에 외부 IP를 할당하기 위해 MetalLB v0.14.3을 설치했습니다. 그런데 파드들이 7분 넘게 ContainerCreating에서 꼼짝을 안 합니다. 하나씩 증상이 터지기 시작했습니다.

연쇄 증상들:

• speaker 파드에서 secret "memberlist" not found 반복
• 특정 Worker 노드에서만 ErrImagePull (다른 노드는 Running)
• controller 파드 CrashLoopBackOff → 로그: dial tcp 10.43.0.1:443: connect: no route to host
• kubectl delete namespace metallb-system 후 20분 넘게 Terminating 고착
• Master → Worker 간 ping이 137ms → 959ms → 128ms → 959ms 패턴으로 주기적으로 1초 이상 튐

처음엔 MetalLB 설정 문제라고 생각했습니다. 그런데 아무리 들여다봐도 이상이 없어요. IP 충돌을 우회하려고 스마트폰 핫스팟으로 네트워크를 전환했더니 이번엔 클러스터 내부 통신이 완전히 단절됩니다.

원인은 단일 원인이 아닌 3개 레이어의 복합 장애였습니다.

레이어	문제	영향
네트워크	사내망 DHCP와 노드 고정 IP 충돌	ping 지연, 이미지 pull 실패
K3s 설치	--disable servicelb 누락	Klipper LB ↔ MetalLB 충돌
임시 조치	핫스팟 전환	클러스터 내부 라우팅 소실

핵심 원인: 노드에 고정 IP(192.168.0.10~12)를 설정했지만, 사내망 공유기 DHCP 범위가 192.168.0.2~254 전체를 포함하고 있었습니다. 공유기가 다른 기기(스마트폰, 노트북)에 같은 IP를 배포하면서 ARP Storm이 발생했던 것입니다. 공유기 관리자 권한이 없어서 DHCP 범위를 직접 수정할 수도 없었어요.

---

🔨 해결: 독립 대역으로 클러스터 전면 재구축

사내망 DHCP가 절대 침범할 수 없는 10.10.10.x/24 대역을 클러스터 전용 네트워크로 지정하고, K3s를 처음부터 다시 설치했습니다.

Step 1. 기존 K3s 완전 철거

# Master 노드
/usr/local/bin/k3s-uninstall.sh

# Worker 노드 1, 2
/usr/local/bin/k3s-agent-uninstall.sh

Step 2. nmtui로 이더넷 IP를 독립 대역으로 변경

역할	인터페이스	신규 IP
Master	eth0	10.10.10.10/24
Worker 1	eth0	10.10.10.11/24
Worker 2	eth0	10.10.10.12/24
MetalLB Pool	—	10.10.10.200~220

⚠️ Gateway 칸은 반드시 공란으로 유지해야 합니다. 값을 입력하면 Wi-Fi 인터넷 라우팅과 충돌해 이미지 pull이 불가능해집니다.

Step 3. K3s 재설치 — 망 분리 옵션 + Klipper 비활성화

# Master 노드
curl -sfL https://get.k3s.io | sh -s - \
  --node-ip 10.10.10.10 \
  --flannel-iface eth0 \
  --disable servicelb      # ← Klipper LB 비활성화 (MetalLB와 충돌 방지)

# Worker 1
curl -sfL https://get.k3s.io | \
  K3S_URL=https://10.10.10.10:6443 \
  K3S_TOKEN=<TOKEN> \
  sh -s - \
  --node-ip 10.10.10.11 \
  --flannel-iface eth0

[최종 네트워크 아키텍처]

이더넷 eth0 → 10.10.10.x (클러스터 내부 통신 전용)
               ├── Master:  10.10.10.10
               ├── Worker1: 10.10.10.11
               └── Worker2: 10.10.10.12

Wi-Fi wlan0  → 사내망 192.168.0.x (인터넷 / 이미지 pull 전용)

💡 교훈: 베어메탈 클러스터는 설치 전에 네트워크 구조를 먼저 설계해야 합니다. 노드 IP 대역, DHCP 충돌 여부, CNI 인터페이스, LB IP 풀 범위를 확정하지 않으면 설치 중 네트워크 트러블슈팅으로 시간을 대부분 소모하게 됩니다.

---

💥 Episode 6. Ingress 설정 — StripPrefix를 빼먹으면 흰 화면만 나온다

클러스터를 재구축하고 MetalLB로 단일 대표 IP(10.10.10.200)를 받았습니다. 이제 /longhorn, /dashboard 경로로 여러 서비스를 묶어서 접근하려 했는데, http://10.10.10.200/longhorn 접속 시 HTML은 수신되는데 CSS, JS가 로드되지 않아 흰 화면만 뜹니다.

원인: Longhorn을 비롯한 대부분의 오픈소스 웹 앱은 자신이 루트 경로(/)에서 동작한다고 가정합니다. 외부 경로를 /longhorn으로 지정하면 앱 내부의 정적 파일 경로(/static/logo.png)와 브라우저가 실제 요청하는 경로(10.10.10.200/static/logo.png) 사이에 불일치가 생깁니다.

해결: StripPrefix 미들웨어로 경로를 벗겨내야 합니다.

# longhorn-route.yaml
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: longhorn-stripprefix
  namespace: longhorn-system
spec:
  stripPrefix:
    prefixes:
      - /longhorn
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: longhorn-ingress
  namespace: longhorn-system
  annotations:
    traefik.ingress.kubernetes.io/router.middlewares: longhorn-system-longhorn-stripprefix@kubernetescrd
spec:
  rules:
  - http:
      paths:
      - path: /longhorn
        pathType: Prefix
        backend:
          service:
            name: longhorn-frontend
            port:
              number: 80

Traefik 내부 대시보드(api@internal)는 일반 Ingress가 아닌 IngressRoute를 써야 하고, /dashboard와 /api 두 경로를 모두 포함해야 404가 나지 않습니다.

💡 교훈: 하위 경로에 서비스를 배치할 때는 StripPrefix가 필수입니다. 그리고 URL 끝에 /를 반드시 붙여야 상대 경로 오류가 발생하지 않습니다.

---

💥 Episode 7~9. ArgoCD — GitLab 연동 트러블슈팅 3연속

클러스터 위에 ArgoCD를 올리고 GitLab과 연동하려 했습니다. 에러가 세 번 바뀌면서 연달아 터졌습니다.

1차 에러: argocd-repo-server가 Completed 상태

connection error: dial tcp 10.43.31.222:8081: connect: connection refused

파드가 Running이 아닌 Completed로 종료된 상태였습니다. 마치 GitLab 연결 에러처럼 보이지만 사실은 ArgoCD 내부 파드 상태 문제였습니다.

# 해결: repo-server 재시작
kubectl rollout restart deployment/argocd-repo-server -n argocd

2차 에러: applicationset-controller CrashLoopBackOff

no matches for kind "ApplicationSet" in version "argoproj.io/v1alpha1"

ArgoCD v3.3.2가 설치됐지만 applicationsets.argoproj.io CRD가 누락된 상태였습니다.

kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-cd/v2.13.2/manifests/crds/applicationset-crd.yaml

3차 에러: remote repository is empty

unable to ls-remote HEAD: failed to list refs: remote repository is empty

GitLab 저장소를 README 없이 완전히 빈 상태로 생성했기 때문입니다. ArgoCD는 빈 저장소를 연결 성공으로 인정하지 않습니다. 이후 deployment.yaml을 push하면서 자연스럽게 해결됐습니다.

💡 교훈: ArgoCD 연결 에러가 발생하면 네트워크보다 파드 상태부터 먼저 확인하는 습관이 중요합니다. kubectl get pods -n argocd 한 줄이 많은 것을 설명해 줍니다.

---

🚀 GitOps 파이프라인 완성 — git push 한 번으로 3-Node 배포

트러블슈팅을 모두 해결하고 나서, 드디어 원하던 GitOps 파이프라인이 완성됐습니다.

① 코드 수정 (로컬 WSL)
     │ git push
     ▼
② GitLab (10.10.10.100) — 폐쇄망 자체 호스팅
     │ 3분마다 폴링
     ▼
③ ArgoCD (10.10.10.201) — 변경 감지
     │ Helm 렌더링 후 Auto Sync
     ▼
④ K3s 3-Node 클러스터 자동 배포 완료 ✅

폐쇄망에서 GitLab을 직접 호스팅하는 이유: 인터넷이 차단된 산업 현장에서 GitHub을 사용하면 ArgoCD가 저장소에 접근할 수 없습니다. Host PC의 Docker에 GitLab 컨테이너를 올려서 인터넷 없이 GitOps 파이프라인을 완결했습니다.

Helm Chart로 설정을 코드로 관리

AI 파드들은 Helm Chart로 관리합니다. values.yaml 한 줄만 바꾸면 이미지 태그, replicas, Failover 감지 시간이 자동으로 반영됩니다.

# ai-apps/values.yaml
integratedAi:
  image: "minsoo0919/safe-edge-integrated-ai:v7"
  replicas: 1
  tolerationSeconds: 30   # ← 이 숫자 하나가 Failover 감지 시간을 결정합니다

audio:
  image: "minsoo0919/safe-edge-audio:v3"
  replicas: 1

시나리오	변경 항목	효과
이미지 업데이트	image: v7 → v8	AI 파드 자동 재배포
긴급 스케일 아웃	replicas: 1 → 2	파드 즉시 2개로 증가
Failover 시간 단축	tolerationSeconds: 30 → 15	더 빠른 장애 감지

---

✅ 2편~3편을 거친 최종 인프라 상태

구성 요소	상태
K3s 3-Node 클러스터 (10.10.10.x 독립망)	✅
MetalLB — VIP 10.10.10.200~220 할당	✅
Traefik Ingress + StripPrefix 미들웨어	✅
Longhorn 대시보드 /longhorn 접근	✅
GitLab 자체 호스팅 (Host PC Docker)	✅
ArgoCD Auto Sync + Helm Chart 연동	✅
git push → 3-Node 자동 배포	✅

이제 인프라가 안정됐습니다. 다음은 이 위에 Edge AI를 올리는 차례입니다. 카메라 인식이 v7까지 가는 여정을 기다려주세요.

🔗 GitOps 실증 상세: GitHub Wiki — Proof CI 🔗 다음 편: 4편 — Edge AI: YOLOv8 카메라 인식이 v7까지 걸린 이유