😡 1 node(s) had untolerated taint(node.kubernetes.io/disk-pressure:)의 원인 파악과 해결

🚨 Error :

 

🚨
Pod를 여러 개 띄우고 테스트하는 도중에 새 Pod를 생성하자 Pending 상태가 지속되다가 한참 지나서 Running으로 변경되는 상황이 발생했다.
Pod에 문제가 발생하여 Running 상태가 되지 못하면 아래 명령어로 Pod의 Event를 확인할 수 있다.

 

$ kubectl describe po <pod명>

# 출력
...
Warning  FailedScheduling  6m21s  default-scheduler  0/2 nodes are available: 
1 node(s) had untolerated taint {node-role.kubernetes.io/control-plane: }, 
1 node(s) had untolerated taint {node.kubernetes.io/disk-pressure: }. 
preemption: 0/2 nodes are available: 2 Preemption is not helpful for scheduling.

• Pod를 노드에 띄울 때 해당 Pod가 어느 노드에 띄워질지를 결정하는 여러 요인 중 하나가 taint와 toleration이다.
• 아주 간단하게 설명하면 taint는 얼룩이라는 의미로 node에 얼룩을 묻히는 것이라고 볼 수 있다.
  • 이 얼룩이란 예를 들어 모기 기피제이다.
• 반대로 toleraiton은 taint에 저항할 수 있음을 의미한다.
  • 예를 들어 모기 기피제에 내성이 있는 모기이다.
• 모기 기피제가 발린 노드에는 일반 모기가 접근하지 못한다.
• 이를 Pod로 바꿔 얘기하면, 모기 기피제에 내성을 가지고 있지 않은 Pod(모기)는 해당 노드에 스케줄링(실행)될 수 없다.

🤓 원인 :

 

•  따라서 위 에러는 node-role.kubernetes.io/control-plane, node.kubernetes.io/disk-pressure라는 두 taint에 내성을 가지지 못한 Pod가 해당 노드에 스케줄링되지 못한 것이다.
• 기본적으로 control-plane(마스터 노드)에는 파드가 스케줄링되지 않는다.
  • 그 이유 역시 node-role.kubernetes.io/control-plane이 taint 때문이다.
  • 이는 마스터 노드에 설정되어 있는 기본 taint이다.
    • describe 명령어로 마스터노드의 taint 부분을 살펴보면
    • Taints:             node-role.kubernetes.io/control-plane:NoSchedule라고 되어있다.
• 이제 에러가 발생한 이유를 추측해보자.
  • 앞서 node.kubernetes.io/disk-pressure이라는 taint로 인해 Pod가 워커 노드로의 스케줄링에 실패했을 것이다.
  • 이후 control-plane(마스터노드)에 스케줄링을 하려다가 node-role.kubernetes.io/control-plane라는 taint로 인해 또 실패하여 위와 같은 에러가 발생한 것으로 보인다.

🚒 해결 :

 

node.kubernetes.io/disk-pressure

• node.kubernetes.io/disk-pressure는 노드의 디스크 사용량이 높아서 추가적인 리소스를 할당할 수 없다는 것을 나타낸다.
• 디스크 압박 상태에서는 해당 노드에 Pod를 스케줄링할 수 없다.

 

💡
워커 노드의 디스크 용량에 비해 Pod가 너무 많이 띄워져 있어 문제가 발생한 것이기 때문에 사용하지 않는 Pod는 모두 제거해 주었다.

이 문제는 워커노드에 얼마만큼의 가용량이 있는지 알지 못해 발생한 문제이므로, 이번 기회에 워커노드 디스크의 가용량을 확인해 보자.

 

$ k describe nodes <워커 노드명>

# 출력

Conditions:
  Type                 Status  LastHeartbeatTime                 LastTransitionTime                Reason                       Message
  ----                 ------  -----------------                 ------------------                ------                       -------
  NetworkUnavailable   False   Mon, 06 Jan 2025 11:16:31 +0000   Mon, 06 Jan 2025 11:16:31 +0000   FlannelIsUp                  Flannel is running on this node
  MemoryPressure       False   Wed, 15 Jan 2025 03:58:07 +0000   Mon, 06 Jan 2025 11:15:42 +0000   KubeletHasSufficientMemory   kubelet has sufficient memory available
  DiskPressure         False   Wed, 15 Jan 2025 03:58:07 +0000   Wed, 15 Jan 2025 03:49:07 +0000   KubeletHasNoDiskPressure     kubelet has no disk pressure
  PIDPressure          False   Wed, 15 Jan 2025 03:58:07 +0000   Mon, 06 Jan 2025 11:15:42 +0000   KubeletHasSufficientPID      kubelet has sufficient PID available
  Ready                True    Wed, 15 Jan 2025 03:58:07 +0000   Mon, 06 Jan 2025 11:16:29 +0000   KubeletReady                 kubelet is posting ready status
  
  ...
  
  Capacity:
  cpu:                8
  ephemeral-storage:  37206272Ki
  hugepages-1Gi:      0
  hugepages-2Mi:      0
  memory:             24306844Ki
  pods:               110
Allocatable:
  cpu:                8
  ephemeral-storage:  34289300219
  hugepages-1Gi:      0
  hugepages-2Mi:      0
  memory:             24204444Ki
  pods:               110
  
  ...
  Events:
  Type     Reason                 Age                 From     Message
  ----     ------                 ----                ----     -------
  Warning  EvictionThresholdMet   16m (x2 over 27m)   kubelet  Attempting to reclaim ephemeral-storage
  Normal   NodeHasDiskPressure    16m (x2 over 27m)   kubelet  Node k8s-worker1 status is now: NodeHasDiskPressure
  Normal   NodeHasNoDiskPressure  10m (x3 over 7d1h)  kubelet  Node k8s-worker1 status is now: NodeHasNoDiskPressure

 

Conditions

• Conditions를 확인해 보면 해당 노드의 네트워크. 메모리, 디스크 등의 한계가 타입 별로 나뉘어 있고, 현재 상태가 표시되어 있다.
• Ready의 경우는 노드가 정상적으로 활성화되어있다면 True로 되어있는 것이 맞다.
• 다른 타입은 명칭을 보면 False로 되어있어야 정상임을 짐작할 수 있고 현재 정상임을 확인할 수 있다.

 

Capacity & Allocatable

• 각 리소스 별 전체 용량과 할당 가능 용량을 표시한다.
• 여기서 ephemeral-storage에 대해 간단히 알아보자.
  • ephemeral-storage는 Kubernetes에서 컨테이너가 사용하는 임시 저장소를 의미한다.
  • 이 저장소는 컨테이너가 실행되는 동안만 데이터를 유지하며 컨테이너가 삭제되거나 재시작되면 데이터가 사라진다. 
  • 컨테이너와 생명주기를 함께하는 것이다.
• 즉, 한 노드에 여러 Pod를 띄울수록 실행 중인 컨테이너의 양이 많아져 할당 가능한 저장 용량이 점점 줄어들 것이다.
• 이 용량은 인스턴스의 디스크 용량과 관련이 있으므로 이 부분에서 문제가 발생한 것이다.

 

Events

• 기록 순서를 보면 ephemeral-storage에 용량 한계로 인한 경고가 발생했고, 이후 DiskPressure가 True로 되어 디스크 사용량이 임계치에 도달하여 Pod가 생성이 불가능해졌다가 풀렸음을 확인할 수 있다.
  • 아마 풀린 시점이 내가 사용하지 않은 Pod를 지운 시점일 것이다.

 

결론

• 현재는 테스트 중인 서비스이기 때문에 주기적으로 Pod를 삭제하면 어느 정도 해결될 문제이지만 추후에는 디스크 용량을 늘릴 필요가 있어 보인다.

 

https://suzuworld.tistory.com/453

kubernetes node : kubelet has disk pressure 해결 방법 총정리(pod status evicted, Attempting to reclaim ephemeral-storage)

• 좀 더 다양한 해결 방법을 찾고 있다면 다음 글을 참고하자.

 

 

🤔 의문점 :

없음!

 

 

 

참고

chatGPT