사례2건

2건 중 1~2번째

1. IL-0469 Azure 관리형 쿠버네티스의 API 서버가 응답하지 않아 data100 허브 파드가 다시 만들어지지 않았다

   UC Berkeley2019

   증상

   data100 클러스터의 쿠버네티스 API 서버에 닿지 않아 새 자원을 만드는 요청이 실패했다. 허브 파드가 멈춘 뒤 새 파드가 만들어지지 않아 사용자들은 프록시 오류 메시지를 보았다.

   컨트롤 플레인 무응답서비스 중단

   원인

   클라우드 제공자 장애

   구성 요소

   AKS 컨트롤 플레인쿠버네티스 API 서버kubelet

   기여 요인

   디버그 접근 제한

   감지

   11:34 에 인프라 담당자가 Slack 으로 알림을 받았다. API 서버가 멈춘 시각인 11:21 은 장애가 끝난 뒤 클라우드 사업자의 모니터링 지표로 확인했다.

   조치

   • 13:00 에 새 클러스터를 만들고, 그 클러스터의 리소스 그룹에 새 nfs 서버를 요청했다.
   • 데이터 볼륨을 옛 nfs 서버에서 떼어 옛 클러스터의 리소스 그룹에서 새 클러스터의 리소스 그룹으로 옮겼다.
   • ZFS 풀을 새 nfs 서버로 가져왔다.
   • helm 으로 staging 허브를 띄우고 DNS 를 바꿨다.
   • helm 으로 prod 허브를 띄우고 DNS 를 바꿨다.

   후속 조치

   • API 서버 엔드포인트를 외부에서 감시하고, 응답하지 않으면 알림을 보낸다.

   사례 보기
2. IL-0505 GKE 에서 kubectl logs 가 모든 파드에서 실패해 mybinder.org 사용자에게 빌드 로그가 가지 않았다

   Binder Project2019

   증상

   kubectl logs -f <pod> 가 모든 파드에서 실패했다. mybinder.org 는 파드 로그로 빌드 로그를 전달하므로 사용자가 새 빌드의 로그를 보지 못했다. 빌드 자체는 정상으로 돌았다.

   모니터링 중단배포 실패

   원인

   클라우드 제공자 장애

   구성 요소

   GKE 컨트롤 플레인쿠버네티스 API 서버

   기여 요인

   디버그 접근 제한

   조치

   • API 서버 로그가 가리킨 노드 gke-prod-a-users-b921bb88-rd5d 를 cordon 하고, 비면 풀에서 빼기로 했다.
   • rd5d 노드를 drain 해 풀에서 빼자 kubectl logs 가 돌아오고 모두 정상으로 동작했다.

   후속 조치

   • kubectl logs 가 동작하는지 시험하고 동작하지 않으면 알림을 보낸다.
   • API 서버 로그를 받는 명령을 SRE 가이드에 넣는다.
   • 의심스러운 네트워크 상태를 알아보는 방법을 SRE 가이드에 적는다.

   교훈

   kubectl logs 가 안 되고 클러스터 전체를 업그레이드하는 동안에도 실행 성공률은 97.5% 아래로 떨어지지 않았다. 문제 노드를 빼자 모두 돌아왔다. 원인이 쿠버네티스 마스터나 GKE 서비스 자체의 버그로 보여서 찾기가 아주 어려웠다. 노드를 의심했을 때 kubectl describe node gke-prod-a-users-b921bb88-rd5d 를 받아 두었으면 정상 노드와 비교할 수 있었다. 노드 주소 목록에서 ExternalIP 와 InternalIP 가 빠진 것은 이 문제의 직접 증상으로 보이고 앞으로 진단에 쓸 수 있다.

   사례 보기

원인별1