Quiz: Node Failure and Eviction Timing

이미 노드에서 돌고 있는 파드에 영향을 주는 테인트 효과는?

• NoSchedule 만 — 이미 떠 있는 파드도 다시 배치 심사를 받는다
• NoExecute 만 — 나머지 둘은 새 배치만 막는다
• PreferNoSchedule 만 — 약한 효과라 실행 중에도 적용된다
• 세 효과 모두 실행 중인 파드를 같은 규칙으로 내보낸다

톨러레이션을 한 줄도 적지 않은 보통의 파드는 노드가 Unknown 이 된 뒤 언제 축출되나?

• 즉시 — 견디는 톨러레이션이 없으므로 바로 나간다
• 노드 컨트롤러가 노드를 지울 때까지 영원히 남는다
• 어드미션이 넣어 준 톨러레이션 때문에 300초 뒤에 나간다
• kubelet 이 다시 붙을 때까지 기다렸다가 판단한다

NoExecute 톨러레이션에 tolerationSeconds 를 아예 적지 않으면?

• 그 파드는 테인트가 붙어도 축출되지 않고 계속 남는다
• 기본값 300초가 적용되어 5분 뒤에 축출된다
• 값이 없으므로 0 으로 읽혀 즉시 축출된다
• 톨러레이션 자체가 무효가 되어 배치에서도 제외된다

DaemonSet 이 만드는 파드가 not-ready 와 unreachable 테인트에서 받는 대우는?

• 다른 파드보다 짧은 60초 톨러레이션을 받아 먼저 정리된다
• 톨러레이션이 없어 노드가 흔들리면 가장 먼저 축출된다
• 노드 컨트롤러가 DaemonSet 파드만 따로 세어 마지막에 내보낸다
• tolerationSeconds 없는 NoExecute 톨러레이션을 받아 축출되지 않는다

스케줄러가 노드 컨디션을 직접 보지 않고 테인트를 보게 설계한 이유는?

• 컨디션은 kubelet 이 쓰는 값이라 컨트롤 플레인이 읽을 수 없기 때문이다
• 배치와 축출을 테인트라는 규칙 하나로 함께 처리할 수 있기 때문이다
• 컨디션에는 시간 정보가 없어 축출 시각을 계산할 수 없기 때문이다
• 컨디션은 노드마다 이름이 달라 표준화되어 있지 않기 때문이다

로컬 상태가 큰 데이터 워크로드에 unreachable 톨러레이션을 3600초로 늘렸다. 무엇을 얻고 무엇을 잃나?

• 짧은 단절에 헛되이 재배치되지 않는 대신, 진짜 죽은 노드에서도 오래 비어 있다
• 축출이 아예 없어지는 대신, 노드를 지울 때 수동 삭제가 필요해진다
• 재배치가 빨라지는 대신, 같은 노드로 다시 돌아올 수 있다
• 스케줄러가 그 노드를 후보에서 빼는 대신, 기존 파드는 유지된다