사례2건

2건 중 1~2번째

1. IL-0076 dex의 AuthRequest 리소스가 끝없이 쌓였고, 이를 치우려고 네임스페이스를 지우자 목록 조회 타임아웃과 재시도가 반복되며 쿠버네티스 마스터가 내려갔다

   Fullstaq2019

   증상

   dex의 AuthRequest 리소스가 엄청난 수로 쌓여 있었다. 발표자는 그 전부터 이미 징후가 있었다고 했다.

   컨트롤 플레인 무응답모니터링 중단

   촉발

   dex의 잘못된 기본값 때문에 AuthRequest 리소스가 쌓였다. 발표는 원인으로 지나치게 긴 TTL, 계속 새로고침되는 대시보드, 실제 보안 버그를 꼽았다. 그리고 쌓인 리소스를 치우려고 dex 네임스페이스를 지우자 마스터가 내려갔다.

   원인

   용량 한계

   구성 요소

   쿠버네티스 API 서버etcd클러스터 인증 제공자

   기여 요인

   기본 설정 방치수동 조치 악화재시도 폭주디버그 접근 제한초기 신호 무시

   감지

   발표자는 그 전부터 이미 징후가 있었다고 했다. 마스터가 내려간 뒤에는 Slack에 경보가 많이 들어왔지만, 인증도 port-forward도 되지 않아 모니터링에는 들어갈 수 없었다.

   조치

   • kill-kube-ns 도구로 API를 직접 호출해 dex 네임스페이스에 남은 kubernetes finalizer를 지웠다.
   • dex를 적절한 기본값으로 설정해 새 네임스페이스에 다시 배포했다.

   교훈

   외부 도구의 기본값을 그대로 믿지 않는다. 목록 조회도 안 될 만큼 쌓인 리소스를 네임스페이스 삭제로 치우면 정리 루프가 타임아웃과 재시도를 반복해 마스터를 내릴 수 있다. 클러스터 인증이 클러스터 안에 있으면 클러스터가 죽었을 때 모니터링에도 들어갈 수 없다. API로 finalizer를 직접 지우는 방법은 발표자도 절대 하지 말라고 한 마지막 수단이다.

   사례 보기
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 가 빠진 것은 이 문제의 직접 증상으로 보이고 앞으로 진단에 쓸 수 있다.

   사례 보기

원인별2