VMware → Multipass 마이그레이션 (2/2) — 트러블슈팅과 최종 검증

1/2부(사전 조사~ArgoCD 재설치)에 이어지는 후반부 — 실제로 격은 트러블슈팅들과 최종 검증, 후속 과제.

5. 트러블슈팅

5.1 SSH 인증 실패 (Too many authentication failures)

sshpass 경유 SSH가 간헐적으로 Permission denied → Too many authentication failures로 끓김. ssh 클라이언트가 비밀번호 시도 전에 등록된 여러 identity(키) 인증을 먼저 시도하다 시도 횟수 제한에 걸리는 문제. -o PreferredAuthentications=password -o PubkeyAuthentication=no 옵션으로 해결.

5.2 워커 디스크 부족 → ArgoCD 이미지 pull 실패

ArgoCD 코어 설치 직후 파드들이 전부 ImagePullBackOff/ErrImagePull.

ctr images pull quay.io/argoproj/argocd:latest
# ctr: failed to extract layer ... write .../usr/local/bin/helm: no space left on device

k3s-worker1  DiskPressure   True   KubeletHasDiskPressure
k3s-worker2  DiskPressure   True   KubeletHasDiskPressure

원인: 워커 VM 디스크를 6GB로 잡았는데, OS(4.4GB) + ArgoCD 이미지 여러 개(서버/repo-server/dex/redis/notifications/applicationset)를 감당하기에 턴없이 부족.

multipass stop k3s-worker1 k3s-worker2
multipass set local.k3s-worker1.disk=14G
multipass set local.k3s-worker2.disk=14G
multipass start k3s-worker1 k3s-worker2

Multipass는 정지 상태에서만 디스크 증설 가능(온라인 리사이즈 미지원, 축소는 애초에 불가). 디스크 리사이즈로 워커가 재기동되면서 예전 파드들이 ContainerStatusUnknown으로 유령처럼 남았음 → 강제 정리 필요.

5.3 마스터 taint 적용으로 인한 메모리 재분배

마스터에 NoSchedule taint를 걸었기 때문에, ArgoCD 전체 컴포넌트 + 앱 워크로드가 워커 2대(합계 3GB)에만 스케쥴링된다. 기존 클러스터(taint 없음, 3노드 5.6GB 전체에 분산 가능)보다 실질적으로 가용 메모리 풀이 좋아진 셈. 실제로는 별문제 없이 안정화되었지만(최종 워커 available 535~674Mi 확보), 향후 defense-api-gateway처럼 워크로드가 추가되면 이 지점이 다시 병목이 될 수 있음(후속 과제로 남김).

5.4 CRD 적용 시 "일시적" 시크릿 not found

argocd-application-controller-0 파드가 잠깐 CreateContainerConfigError: secret "argocd-redis" not found를 발러 냈는데, 이는 argocd-redis 파드/시크릿이 아직 초기화되는 중이라 생긴 스타트업 순서 레이스 컨디션이었고 몇 초 뒤 자동 재시도로 해소됨(별도 조치 불필요).

5.5 진짜 문제: target-tracking-secrets 시크릿 백업 누락

target-tracking-service Application을 동기화하자 kafka, postgres, target-tracking-service 파드가 전부 Error: secret "target-tracking-secrets" not found.

원인: c4i 네임스페이스의 target-tracking-secrets(DB 계정/비밀번호, Gemini API 키)는 ArgoCD가 관리하는 매니페스트에 없는 수동으로 생성된 시크릿이다. 3.1절 백업 때 argocd 네임스페이스만 확인하고 c4i 애플리케이션 시크릿은 확인하지 않아 통째로 누락된 것.

복구: 이미 종료해둔 VMware server1을 일시적으로 재기동해서 값을 추출한 뒤 즉시 재종료.

# server1 재기동 (호스트 메모리 여유 61MB 수준에서 진행, 면밀히 모니터링)
vmrun start server1.vmx nogui
# k3s 서비스 기동 대기 후
kubectl get secret target-tracking-secrets -n c4i -o yaml > target-tracking-secrets.yaml
# 즉시 종료
vmrun stop server1.vmx soft
# 신규 클러스터에 복원
kubectl apply -f target-tracking-secrets.yaml