[K8S] 클러스터 붕괴 원인 분석 및 복구 과정

1. 장애 발생 및 확산 과정

운영 중인 Kubernetes 클러스터에서 Harbor 스케일링 작업 중 발생한 초기 오류가, 연쇄 반응을 일으키며 클러스터 전체 붕괴로 이어진 과정을 순서대로 기술함.

• 1. Harbor 설치 후 노드 증설

  • 초기 Harbor 설치 후, 클러스터에 워커 노드를 추가했음.

• 2. Harbor 컴포넌트 확장 시도 및 실패

  • 증설된 노드에 Pod를 분산시키기 위해 helm upgrade 명령으로 Harbor의 주요 컴포넌트(core, jobservice, registry) 복제본(replica)을 확장하려고 시도함.

    helm upgrade harbor harbor/harbor -n harbor \
      -f values.yaml \
      --set core.replicas=2 \
      --set jobservice.replicas=2 \
      --set registry.replicas=2

  • 에러 발생: harbor-trivy StatefulSet의 불변성(immutability) 제약 조건으로 인해 업그레이드가 실패함.

    Error: UPGRADE FAILED: cannot patch "harbor-trivy" with kind StatefulSet: ... updates to statefulset spec for fields other than 'replicas', ... are forbidden

• 3. Harbor 전체 재설치 및 Ingress 문제 발생

  • 업그레이드 실패 문제를 해결하기 위해 Harbor를 완전히 삭제 후 재설치함.

    helm uninstall harbor -n harbor
    kubectl delete pvc --all -n harbor
    helm install harbor harbor/harbor -n harbor -f values.yaml

  • 재설치 이후, Ingress 리소스가 외부 IP를 할당받지 못하는 문제가 발생함. helm upgrade 명령을 재실행하여 문제를 해결했음.

• 4. 노드 리소스 증설 및 Kubelet 장애 발생

  • Pod 스케줄링 과정에서 발생한 리소스 부족 문제를 해결하기 위해 각 워커 노드의 메모리를 6GB로 증설하고 재시작함.
  • 재시작 후, kubelet 서비스가 정상적으로 실행되지 않으며 노드가 NotReady 상태에 빠지는 심각한 문제가 발생함.

• 5. 설정 초기화 및 재조인 시도

  • containerd 설정 초기화, swapoff, kubeadm join 등의 명령어로 노드 복구를 시도했고, 재조인은 성공했으나 Harbor는 여전히 비정상 상태로 남음.

• 6. 모든 설정 초기화 및 클러스터 붕괴

  • 상황을 타개하기 위해 kubeadm reset -f 및 관련 디렉터리 수동 삭제로 모든 노드의 설정을 초기화함.
  • 이 과정에서 kube-system의 핵심 파드를 포함한 모든 파드를 동시에 중단시키는 조치를 실행했고, 이는 클러스터 전체의 제어 불능 상태를 초래함.

---

2. 장애 상태 및 원인 분석

핵심 시스템 파드가 붕괴된 후의 클러스터 상태와, 이러한 총체적 장애를 유발한 원인을 분석함.

• 망가진 상태 요약

  • 핵심 파드 붕괴: kubelet, kube-proxy, flannel, coredns 등 클러스터의 핵심 기능을 담당하는 모든 파드가 CrashLoopBackOff 상태에 진입.
  • 노드 상태 이상: k8s-worker-01은 NotReady, k8s-worker-02는 Ready 상태지만 내부적으로는 Crash 상태.
  • 네트워크 단절: CNI 플러그인(flannel)이 붕괴하여 Pod 간의 모든 통신이 두절됨.

• 종합적인 원인 정리

  범주	원인
  🚨 Pod 상태	DB나 Redis Init 중 멈춤
  🚨 PVC 재사용	기존 볼륨 오염 가능성
  🚨 CrashLoop	Trivy, Registry config 충돌 또는 의존성 실패
  🚨 Ingress 503	ingress-nginx 비정상 또는 core 서비스 미준비

• 붕괴의 연쇄 반응 분석

  1. 시발점: 제어 불능 상태 진입
     etcd(기억), kube-apiserver(신경망), coredns(주소록), kube-flannel(혈관) 등 클러스터의 두뇌와 신경계에 해당하는 핵심 파드들이 동시에 종료되면서, 클러스터는 스스로를 제어하고 복구할 능력을 완전히 상실했음.
  2. 도미노 효과: 네트워크 및 상태 붕괴
     핵심 기능이 마비되자, 파드들은 재시작에 필요한 네트워크(CNI)나 설정 정보(DNS)에 접근할 수 없었다. 이로 인해 파드들은 서로를 찾지 못하고 CrashLoopBackOff나 ContainerCreating 상태에 빠졌으며, 클러스터 전체의 상태 일관성(정합성)이 완전히 파괴되었음.
  3. 기저 문제: 취약했던 노드 환경
     이러한 붕괴가 더 심각하게 진행된 배경에는, 이전에 확인되었던 근본적인 노드 환경 문제가 있었다. containerd 설정 오류나 불완전한 kubeadm reset 시도는 노드 간의 신뢰 관계를 이미 손상시킨 상태였음.

• 최종 진단
  이번 사태는 기초가 부실했던 클러스터 환경 위에서, 운영자의 실수로 핵심 시스템 파드가 일괄 삭제되자 시스템 전체가 회복 불능 상태에 빠진 총체적 장애이다. 연쇄 반응으로 인해 클러스터의 신뢰 체계와 상태 정보가 돌이킬 수 없을 정도로 손상되었기 때문에, OS 재설치를 통한 완전한 재구축만이 유일한 해결책이었다.

---

3. 복구 절차

장애가 발생한 클러스터를 초기화하고 재구성하기 위해 진행한 절차는 다음과 같다.

• 1. 모든 워커 노드에서 초기화 실행
  kubeadm reset과 CNI, kubelet 관련 디렉터리를 수동으로 삭제하여 노드를 깨끗한 상태로 되돌린다.

  sudo kubeadm reset -f
  sudo systemctl stop kubelet
  sudo rm -rf /etc/cni/net.d
  sudo rm -rf /var/lib/cni/
  sudo rm -rf /var/lib/kubelet/*
  sudo rm -rf /etc/kubernetes
  sudo systemctl restart containerd

• 2. 마스터에서 재조인 명령 생성
  워커 노드가 클러스터에 다시 참여할 수 있도록 새로운 토큰과 join 명령어를 생성한다.

  kubeadm token create --print-join-command

• 3. 워커에서 조인 재시도
  생성된 join 명령어를 모든 워커 노드에서 실행한다.

  sudo kubeadm join ...

  • 참고: 만약 마스터 노드에 기존 노드 정보가 남아있어 충돌이 발생하면, 아래 명령으로 해당 노드를 먼저 삭제해야 한다.

    kubectl delete node <노드이름>

• 4. Harbor 및 Ingress 재설치
  클러스터가 정상화된 후, 오염되었을 가능성이 있는 PVC와 Namespace를 완전히 삭제하고 Helm을 통해 Harbor와 ingress-nginx를 재설치한다.

  # Harbor 완전 삭제
  helm uninstall harbor -n harbor
  kubectl delete pvc --all -n harbor
  kubectl delete pv --all
  kubectl delete ns harbor
  # 노드에서 실제 볼륨 삭제
  sudo rm -rf /opt/local-path-provisioner/*
  # Ingress-nginx 완전 삭제
  helm uninstall ingress-nginx -n ingress-nginx
  kubectl delete ns ingress-nginx
  
  # 재설치 진행...

• 결과

  • 노드 2개 Ready 상태 회복.
  • 모든 kube-system, ingress, Harbor 파드 정상화.
  • 클러스터 네트워크 복구 완료.