k3s 마스터 노드 변경하기(0) - 배경 및 결론

배경 

서비스를 운영 중 크레딧 이슈로 인해, 기존 마스터 노드를 무조건 종료해야 하는 상황이 발생했다. 단순히 노드 한 대를 내리는 작업이 아니라 컨트롤플레인 자체를 다른 노드로 이관해야 하는 운영 이벤트였고, 그 여파로 클러스터 API 접근성, stg/prd 도메인 외부 라우팅(80/443 유입 경로), ingress-nginx 서비스 경로(NodePort 포함), cert-manager 기반 TLS 발급/갱신, ArgoCD 자동 동기화(GitOps) 정합성까지 한 번에 정리해야 했다.

 

이관 직전 기준으로 클러스터는 4개 노드가 모두 Ready였고, 노드 사용률은 CPU 29%, 메모리 63% 수준이었다. 영향 범위는 핵심 6개 네임스페이스(argocd, cert-manager, ingress-nginx, monitoring, starlight-production, starlight-staging)였으며, 이관 과정에서 일시 비정상 파드는 4개(mysql-0, loki-0, prometheus-0, starlight-production)가 관측됐다.

 

컨트롤플레인을 옮기는 방법에는 3가지 선택지가 있었다. (1) 기존 워커 승격, (2) 신규 x86 마스터 증설, (3) 신규 ARM 마스터 전환. 하지만 신규 증설은 조달·비용·시간이 병목이었고, ARM 전환은 멀티아키 이미지와 스케줄 제어, 핵심 애드온 호환성 검증이 선행되지 않으면 운영 리스크가 컸다. 그래서 최종적으로 최소 비용과 빠른 복구라는 운영 목표에 가장 부합하는 1번(기존 워커 승격)을 선택해 이관을 진행했다.

작업 절차 및 배운점

이관은 아래 절차를 통해 최소비용으로 진행했다.

1. 사전 점검: 노드/파드 상태, 리소스 사용률, PV('local-path') 종속성, DNS·Ingress·ArgoCD 동작 여부를 먼저 확인
2. 운영 대상 정리: 사용하지 않는 불필요한 리소스 제거
3. datastore 모드 확정: etcd datastore disabled 관측 후, 기존 마스터를 cluster-init 기반 embedded etcd 전환 및 스냅샷 생성
4. 컨트롤플레인 승격: 워커 1대를 server로 전환해 control-plane/etcd 역할 부여, API endpoint/노드 역할을 기준 조인 검증
5. 쿼럼 이슈 대응: 2멤버 etcd 구간에서 발생한 API 불안정(타임아웃)을 멤버 재정렬/정리로 복구
6. 외부 접근 복구: stg/prd 도메인의 80/443 유입 경로를 재구성 및 ingress-nginx 경로 정리
7. HTTPS 재적용: cert-manager + ingress-nginx 설정을 Git에 반영해 ArgoCD sync로 TLS 인증서를 재발급/적용
8. 운영 접점 복구: ArgoCD 접근(계정/포트포워딩/터널)과 kubeconfig 컨텍스트를 정리

이번 작업에서 가장 큰 교훈은 두 가지였다. 첫째, local-path PV는 노드 로컬 리스크에 가하게 종속되므로 노드 종료 전에 디렉터리/덤프 백업이 없으면 데이터 복구가 불간능하다는 점과, 둘째, 2멤버 etcd는 과반수(quorum)가 2라서 허용치가 0(한 대 이탈 시 즉시 발안정)이다. 따라서 고가용성이 필요한 운영 환경이라면 3멤버로(또는 그 이상의 홀수) 구성으로 가져가야한다는 점이다.

관련 포스팅

SSE로 알림 기능 구현하기(부록) - SSE Thread Safe Brothers

SSE로 알림 기능 구현하기(부록) - SSE Thread Safe Brothers

SSE로 알림 기능 구현하기(부록) - SSE Thread Safe Brothers

SSE로 알림 기능 구현하기(부록) - SSE Thread Safe Brothers