클라우드/Kubernetes

[트러블슈팅] nodelocaldns 에러

세브웁스 2025. 5. 19. 11:00
반응형

🚨 긴급 보고: 네이버 클라우드 NKS 환경 nodelocaldns 장애 및 복구 과정 (feat. 2년 묵은 이슈?) 🚨

최근 저희 팀에서 관리하던 네이버 클라우드 NKS(Naver Kubernetes Service) 고객사의 환경에서 심각한 장애가 발생했습니다. pod 내부에서 갑자기 CDB(Cloud DataBase) 도메인 주소를 호출하지 못하는 상황이 벌어진 것이죠. 긴급했던 당시 상황과 문제 해결을 위해 동분서주했던 과정을 상세히 기록하고, 재발 방지를 위한 권고사항까지 정리하여 공유드립니다.

💥 예상치 못한 오류의 습격

문제의 발단은 일부 pod에서 시작되었습니다. 처음에는 특정 App Service pod에서 이미지 배포 후 오류 로그가 확인되었고, 곧이어 다른 pod에서도 이상 증상이 감지되기 시작했습니다.

문제 발생 시점 로그:

kube-system   nks-nas-csi-node  : Connection lost to unix:///csi/csi.sock.

[App Service]   commerce-pc-*** : DeprecationWarning: fs.Stats constructor is deprecated.

[App Service]   commerce-mobile-*** : [unhandledRejection] Error: instance unavailable

[App Service]   backend-service-*** : Caused by: java.net.UnknownHostException:
db-***.vpc-cdb.cloud-provider.com

로그 분석 결과, commerce-pc와 commerce-mobile pod의 오류는 이미지 배포 과정에서 node.js 버전이 업그레이드되며 발생한 것으로 추정되었습니다. 문제의 원인이 된 코드는 fs.stats로, 상위 버전의 node.js에서는 더 이상 지원하지 않는 함수였죠.

하지만 가장 심각했던 문제는 backend-service pod였습니다. 명확한 에러 메시지 없이, pod 내부에서 CDB 도메인 주소를 전혀 호출하지 못하는 java.net.UnknownHostException 오류가 지속적으로 발생하고 있었습니다.

🛠️ 문제 해결을 위한 사투

  1. 원인 파악 및 초기 대응: 우선 문제 발생 pod들의 로그를 면밀히 분석하여 각 오류의 원인을 파악하는 데 집중했습니다.
  2. App Service pod 재배포 시도: commerce-pc와 commerce-mobile pod는 deployment로 관리되고 있었기에, 간단히 해당 pod들을 삭제하여 재생성을 시도했습니다. 하지만 신규 생성되는 pod들에서도 동일한 오류가 발생하는 것을 확인했습니다.
  3. node.js 버전 문제 확인 및 개발팀 협조: App Service pod들의 문제는 node.js 버전 업그레이드와 관련된 것으로 결론짓고, 해당 내용을 개발팀에 전달하여 코드 수정을 요청했습니다.
  4. nodelocaldns 문제 의심 및 노드 재기동 검토: backend-service pod의 도메인 호출 실패는 DNS 설정에 문제가 있을 가능성을 시사했습니다. 가장 먼저 떠올린 해결책은 worker node를 재기동하는 것이었죠.
  5. 노드 재기동 불가 및 네이버 클라우드 지원 요청: 하지만 해당 worker node에는 다른 중요한 서비스들이 많이 운영 중이었고, 더욱이 해당 노드풀에는 단 1개의 노드만 등록된 상황이었습니다. 섣부른 노드 재기동은 전체 서비스 중단으로 이어질 수 있었기에, 불가피하게 네이버 클라우드 엔지니어의 지원을 요청하게 되었습니다. 비용 문제로 노드 추가가 불가능한 점도 발목을 잡았죠. 😥
  6. nodelocaldns pod 재기동 지원: 네이버 클라우드 엔지니어의 도움으로 문제의 원인이 worker node의 nodelocaldns pod에 있음을 확인했고, 긴급하게 해당 pod의 재기동 지원을 받아 문제를 해결할 수 있었습니다.
  7. 서비스 정상화 확인: nodelocaldns pod 재기동 후, backend-service pod에서 CDB 도메인 주소를 정상적으로 호출하는 것을 확인하며 긴급 상황은 일단락되었습니다.

⚠️ 잠재적인 위험 요소 및 임시 조치

이번 장애를 해결하는 과정에서 또 다른 문제점이 발견되었습니다. worker node에서 UNKNOWN 상태의 컨테이너가 다수 존재했던 것이죠. 이는 앞으로도 예기치 않은 장애가 발생할 수 있는 잠재적인 위험 요소입니다.

UNKNOWN 컨테이너 임시 조치:

Bash
 
# 1. 노드 SSH 접속
ssh <your_node_ip>

# 2. UNKNOWN 상태 컨테이너 확인
sudo ctr -n k8s.io task ls | grep UNKNOWN

# 3. UNKNOWN 컨테이너와 POD 비교
sudo crictl pods

# 4. 문제 POD 재시작 (안될 경우 containerd-shim 프로세스 kill)
kubectl delete pod <problem_pod_name>
# 또는
ps -ef | grep <unknown_container_id>
sudo kill -9 <containerd_shim_pid>

🛡️ 지속적인 안정 운영을 위한 권장 방안

근본적인 문제 해결과 안정적인 서비스 운영을 위해서는 다음과 같은 조치들을 적극적으로 검토해야 합니다.

  1. 쿠버네티스 버전 업그레이드: 현재 클러스터 버전은 1.23으로, 이미 지원이 종료되었거나 곧 종료될 예정입니다. 최신 버전(현재 1.25)으로의 주기적인 업그레이드를 통해 보안 및 안정성을 확보해야 합니다.
  2. 워커노드 커널 버전 업데이트: 네이버 클라우드 측에서도 언급했듯이, 현재 사용 중인 Ubuntu 20.04의 5.4.0-132-generic 커널에서 유사한 이슈가 반복될 가능성이 높습니다. 커널 업데이트를 통해 안정성을 향상시켜야 합니다.
  3. 신규 노드풀 추가 및 워커노드 교체: 노드풀에 단일 노드만 운영되는 환경은 장애 발생 시 매우 취약합니다. 신규 노드풀을 추가하여 worker node를 분산하고, 필요하다면 새로운 커널 버전이 적용된 노드로 점진적인 교체를 진행하는 것이 좋습니다.

🗣️ 네이버 클라우드로부터 받은 답변

이번 이슈와 관련하여 네이버 클라우드로부터 2차례에 걸쳐 답변을 받았습니다.

1차 답변 요약:

메인 이슈는 nodelocaldns의 비정상 동작이었으며, 재시작 후 정상화되었습니다. UNKNOWN 상태 컨테이너는 Kubernetes 자체의 알려진 이슈(https://github.com/kubernetes/kubernetes/issues/115192)와 관련 있을 수 있으며, 제시된 단계를 통해 확인 및 재시작할 수 있습니다.

2차 답변 요약:

다수의 컨테이너 문제 확인 후 노드 재기동을 계획하고 있습니다. 다만, 현재 Ubuntu 20.04 환경의 특정 커널 버전에서 유사한 이슈가 반복될 가능성이 높으므로, Kubernetes 버전 업그레이드 및 워커노드 교체를 통한 커널 변경을 강력히 권장합니다. 특히 현재 사용 중인 Kubernetes 1.23 버전과 워커노드 커널은 공식 지원되지 않는 버전이므로, 안정적인 운영을 위해 최신 환경으로 전환이 시급합니다.

🤦‍♂️ 결론: 2년 묵은 숙제, 이제는 해결해야 할 때

이번 nodelocaldns 장애를 겪으면서 쿠버네티스 클러스터의 버전 관리와 워커노드 관리가 얼마나 중요한지 다시 한번 절실히 깨달았습니다. 특히, 인수인계받은 지 이제 한 달 반밖에 되지 않았는데, 이번 문제가 무려 2년 전부터 꾸준히 이슈가 되어왔다는 사실을 알고는 깊은 탄식을 내뱉을 수밖에 없었습니다. 😩

이제 더 이상 묵과할 수 없습니다. 제시된 권장 사항들을 적극적으로 검토하고 실행하여, 안정적인 쿠버네티스 환경을 구축하는 데 최선을 다해야 할 것입니다.

긴급했던 상황 공유가 동료 개발자 및 시스템 관리자분들에게 조금이나마 도움이 되기를 바랍니다. 🙏

반응형
저작자표시 비영리 (새창열림)