Quiz: Troubleshooting and etcd

파드가 Pending 이고 Events 에 '0/3 nodes are available: 3 Insufficient cpu' 가 보인다. 가장 먼저 의심할 것은?

• 요청한 CPU 가 모든 노드의 할당 가능량보다 커서 filter 단계에서 전부 탈락한 것 (단위 표기 실수 여부부터 확인)
• 이미지 레지스트리 인증에 실패해 못 받는 것
• CNI 플러그인이 설치되지 않아 노드가 아직 준비되지 않은 것
• PVC 가 아직 바인딩되지 않은 것

RuntimeClass nvidia 는 등록돼 있는데 파드가 'no runtime for nvidia is configured' 로 시작조차 못 하는 이유는?

• RuntimeClass 는 handler 이름표일 뿐이고, 그 이름에 해당하는 런타임 설정이 노드의 컨테이너 런타임에 없기 때문
• RuntimeClass 이름을 오타로 적었기 때문
• 노드에 GPU 드라이버가 설치되지 않았기 때문
• 파드가 nvidia.com/gpu 자원을 요청하지 않았기 때문

노드에서 which nvidia-ctk 가 경로를 출력하는 것을 보고 toolkit 설치를 껐다가 사고가 난 사례의 교훈은?

• 바이너리가 있으면 설정도 되어 있다고 봐도 된다
• helm 은 언제나 노드의 시스템 설정을 직접 바꾼다
• RuntimeClass 는 노드마다 따로 만들어야 한다
• 바이너리가 존재한다는 것과 런타임이 그것을 쓰도록 설정돼 있다는 것은 별개의 명제다

drain 이 'Cannot evict pod as it would violate the pod disruption budget' 로 멈췄을 때 올바른 대응은?

• PDB 의 minAvailable / maxUnavailable 을 실제 레플리카 수에 맞게 조정하거나 레플리카를 늘려 여유를 만든다
• --force 옵션을 붙여 경고를 무시하고 파드를 그대로 밀어내 버린다
• PDB 를 삭제하고 다시 만들지 않는다
• 노드를 강제로 재부팅한다

etcd 스냅샷으로 복구할 때 반드시 지켜야 할 절차는?

• 컨트롤 플레인을 잠시 내리고 새 --data-dir 로 복구한 뒤 --initial-cluster 와 peer URL 을 맞춰 다시 띄운다
• 기존 data-dir 에 그대로 덮어써서 경로 변경을 피한다
• apiserver 를 계속 띄워 둔 채로 복구를 진행해 다운타임을 아예 없앤다
• 스냅샷 파일을 data-dir 에 복사하기만 하면 된다

'etcd 멤버가 3개라 쿼럼이 있으니 백업은 필요 없다' 는 주장에 대한 가장 정확한 반박은?

• 쿼럼은 멤버가 5개 이상일 때만 의미가 있다
• etcd 에는 자동 백업 기능이 내장돼 있어 별도 설정이 필요 없다
• 백업은 kube-apiserver 가 주기적으로 대신 수행한다
• 쿼럼은 노드 장애 대비이고, 잘못된 삭제나 논리적 손상은 즉시 모든 멤버에 복제되므로 시점 복구는 스냅샷으로만 가능하다