Disk Thin Provisioning 방식과 Node Deadlock 상관관계

2026. 1. 1. 18:53·Kubernetes
728x90

VMware나 Citrix와 같은 가상화 환경(Hypervisor) 위에서 쿠버네티스를 운영할 때, 디스크 할당 방식(Provisioning Type) 하나가 전체 노드를 마비시키는 치명적인 장애를 유발했다.

 

이번 포스팅은 디스크 I/O 지연이 어떻게 CPU 멈춤으로 이어지고, 결국 쿠버네티스 노드 장애를 일으키는지 정리한다.

( 공식 사이트에서 발췌한 내용을 기반으로 작성하였으나, 명확하지 않은 부분은 경험을 토대로 작성하였습니다. 이는 정확한 정보가 아닐 수 있음을 알려드립니다. )

공식 사이트

광고 클릭은 큰 힘이 됩니다!

728x90
 

Nodes

Kubernetes runs your workload by placing containers into Pods to run on Nodes. A node may be a virtual or physical machine, depending on the cluster. Each node is managed by the control plane and contains the services necessary to run Pods. Typically you h

kubernetes.io


1. Thin Provisioning

상황

Hypervisor는 VM(Kubernetes Node)에게 "500GB 디스크를 할당했다"고 보고했지만, 실제 물리 스토리지에서는 필요한 만큼만 그때그때 할당하는 방식(Thin Provisioning)으로 설정되어 있었다. (다른 노드는 정적 할당 방식이였다.)

 

평소 읽기(Read) 위주의 워크로드에서는 문제없었지만, 특정 시각에 백업이나 로그 로테이션(Log Rotation)이 실행되면서 대량의 "새로운 데이터 쓰기(New Write)"가 발생하며 문제가 시작되었다.


2. 병목

VM 내부에서 아직 할당되지 않은 '영역'인 블록에 데이터를 쓰려고 할 때, 지연(Latency)이 발생한다.

작동 메커니즘

1. Write 요청: VM OS(RedHat)가 "100번지 블록에 데이터를 써달라"고 요청한다.

2. Hypervisor의 당황: 해당 블록은 물리적으로 할당된 적이 없다.

3. 공간 확보 작업 (Overhead):

  • Hypervisor는 데이터 무결성을 위해 VM의 동작을 일시 정지(Pause/Stun)시킨다.
  • 물리 스토리지에서 공간을 할당받고, 기존 데이터를 지우는 Zeroing 작업을 수행한다.

이 과정을 'Metadata Update' 또는 'First Write Penalty'라고 부른다고 하는데 처음 들어봤다.
I/O가 폭주하는 상황에서 이 작업은 0.001초가 아닌, 수 초에서 수십 초까지 지연될 수 있다.


3. XFS Lock

물리 스토리지 할당이 지연되는 동안, VM 내부의 OS는 디스크가 응답하지 않는다고 판단한다.

내부 상황

Kubelet/Fluentd: 디스크에 데이터를 써야 하는데 컨트롤러가 응답을 주지 않는다.

파일 시스템(XFS): 데이터 정합성을 위해 "쓰기 작업이 끝날 때까지 락(Lock)을 건다.

 

로그 발생: xfs_buf_lock 경고가 발생하며 I/O 대기열(Wait Queue)이 급증한다.

task:fluentd state:D stack:0 pid:1234
Call Trace:
...
xfs_buf_lock+0x...

4. 시스템 마비

Hypervisor가 공간 할당을 위해 VM을 멈춘(Stun) 시간이 길어지면서 CPU 스케줄링이 깨져버린다.

과정

1. 정지(Freeze): 공간 할당이 늦어지자 Hypervisor는 VM의 vCPU 스케줄링을 아예 중단시킨다. VM 입장에서는 시간이 멈춘 것이다.

2. 재개(Resume) 직후의 패닉: 겨우 공간을 할당받고 VM이 다시 깨어난다. 리눅스 커널이 시계를 확인하니, 짧은 사이에 200초가 지나가 버렸다.

3. Soft Lockup 감지: 할 일 없이 쉬고 있던 프로세스(swapper)조차 스케줄링을 받지 못했다.

4. 로그 발생: 커널은 "CPU가 멈췄었다"고 판단하고 워치독(Watchdog) 경고를 뿜어낸다.

watchdog: BUG: soft lockup - CPU# stuck for 223s! [swapper/0:0]

 


5. 결말: 쿠버네티스의 사망 선고

VM 레벨의 멈춤은 상위 애플리케이션인 쿠버네티스 클러스터의 장애로 이어진다.

연쇄 장애

1. 네트워크 단절: VM이 멈춰있던 동안 외부 스토리지(NFS)와의 세션도 타임아웃으로 끊어졌다. (nfs: Server not responding)

2. 노드 축출: 쿠버네티스 마스터(Control Plane)는 "이 노드가 3분 넘게 심장박동(Heartbeat)이 없다"고 판단한다.

3. 결과: 해당 노드는 NotReady 상태로 변경되고, 파드(Pod)들은 강제로 축출(Eviction)된다.


정리

운영 환경의 쿠버네티스 및 데이터베이스, 로그 서비스 등 읽기 쓰기가 빈번하게 일어나는 서버(노드)는 정적 할당이 이롭다.


중요

잘못된 정보나, 문의등은 댓글로 메일과 함께 적어주시면 감사하겠습니다.

728x90
저작자표시 비영리 (새창열림)

'Kubernetes' 카테고리의 다른 글

Kubestronaut 여정과 그 마지막  (0) 2026.01.13
GET 그리고 WATCH는 뭐가 다를까? - OpenTelemetry 장애 케이스  (0) 2026.01.08
I/O 병목과 ETCD 그리고 API 서버  (0) 2025.12.09
Ingress NGINX의 공식 은퇴  (0) 2025.11.27
Kubernetes Node Life Cycle - 노드의 생명주기  (0) 2025.11.26
'Kubernetes' 카테고리의 다른 글
  • Kubestronaut 여정과 그 마지막
  • GET 그리고 WATCH는 뭐가 다를까? - OpenTelemetry 장애 케이스
  • I/O 병목과 ETCD 그리고 API 서버
  • Ingress NGINX의 공식 은퇴
MAGUJOB
MAGUJOB
Officially Kubestronaut 사파스러운 블로그 느립니다.
  • MAGUJOB
    마구잡
    MAGUJOB
  • 전체
    오늘
    어제
    • 분류 전체보기 (65) N
      • Kubernetes (54) N
        • Kubernetes 버전별 변경 이력 (8)
        • 작은팁-짧은글 (11) N
      • 운영체제 (1)
      • 오픈스택 (1)
      • 책 후기 (2)
      • 운동 (1)
        • 헬스 (0)
        • 클라이밍 (1)
      • 기타팁 (1)
  • 블로그 메뉴

    • 홈
    • 태그
    • 방명록
  • 링크

    • 링크드인
  • 공지사항

  • 인기 글

  • 태그

    ingressnginx
    피카푸글램핑
    티스토리챌린지
    AI
    kubernetes
    쿠버네티스
    virt-manager
    CKS
    GPU
    1.35
    클라우드
    캠핑
    피카푸캠핑도봉산
    gatewayAPI
    오블완
    업데이트
    Calico
    쿠버네티스기초
    글램핑
    파드
    쿠버네티스 생명주기
    POD
    IT
    CKA
    v1.35
    버전
    KVM
    kube-ai
    피카푸클램핑도봉산
    k8s
  • 최근 댓글

  • 최근 글

  • hELLO· Designed By정상우.v4.10.4
MAGUJOB
Disk Thin Provisioning 방식과 Node Deadlock 상관관계
상단으로

티스토리툴바