IL-0076 Fullstaq · 2019-06-01 (게시일)kubernetes
Fullstaq의 Pieter Lange가 NMBRS에서 열린 k8s 밋업에서 발표한 사례다. 이 클러스터는 쿠버네티스 인증에 OIDC 프록시인 dex를 썼고, dex는 저장소로 클러스터 자체를 쓰도록 type: kubernetes, inCluster: true로 설정돼 있었다. 잘못된 기본값 탓에 AuthRequest가 쌓였고, 목록 조회조차 타임아웃이 나서 지울 수 없었다. 발표자가 든 선택지는 etcd와 API 서버의 타임아웃을 조정하는 것, 네임스페이스를 지워 쿠버네티스가 정리하게 두는 것, 쿠버네티스를 거치지 않고 etcd에서 직접 지우는 것이었다. 발표자는 두 번째를 골랐다.
네임스페이스 정리 루프는 지우기 위해 모든 요청을 나열하다 타임아웃이 나고 다시 시도하기를 반복했다. 마스터 부하가 60까지 오르며 마스터가 내려갔다. 네임스페이스는 finalizers에 kubernetes가 남은 채 Active 상태로 멈춰 있었고, 이 finalizer는 kubectl로 지울 수 없었다. 발표자는 kill-kube-ns 도구로 API를 직접 호출해 finalizer를 지웠다. 그러면서 이 방법은 절대 쓰지 말라고 두 번 강조했다. 이것으로 일단 풀렸지만 etcd에는 AuthRequest가 0.5G 남았다. 발표자는 kubectl create namespace dex를 실행하면 클러스터가 죽을 것이라고 봤다. dex를 적절한 기본값으로 설정해 새 네임스페이스에 다시 배포했다. 업무 애플리케이션은 이 장애로 피해를 입지 않았다.
dex의 AuthRequest 리소스가 엄청난 수로 쌓여 있었다. 발표자는 그 전부터 이미 징후가 있었다고 했다.
AuthRequest 전체 목록을 조회하면 타임아웃이 났다. 리소스를 지우려면 목록이 필요했기 때문에 쌓인 리소스를 정리할 수 없었다.
dex 네임스페이스를 지우자 쿠버네티스의 정리 루프가 모든 요청을 나열하려다 타임아웃이 나고 다시 시도하기를 반복했다. 마스터 부하가 60까지 치솟았고 마스터가 내려갔다. 인증이 되지 않고 port-forward도 할 수 없어 모니터링에 들어갈 수 없었다. Slack에는 경보가 많이 들어왔다.
증상 ? 컨트롤 플레인 무응답모니터링 중단
원인 ? 용량 한계
발표자는 그 전부터 이미 징후가 있었다고 했다. 마스터가 내려간 뒤에는 Slack에 경보가 많이 들어왔지만, 인증도 port-forward도 되지 않아 모니터링에는 들어갈 수 없었다.
–
외부 도구의 기본값을 그대로 믿지 않는다. 목록 조회도 안 될 만큼 쌓인 리소스를 네임스페이스 삭제로 치우면 정리 루프가 타임아웃과 재시도를 반복해 마스터를 내릴 수 있다. 클러스터 인증이 클러스터 안에 있으면 클러스터가 죽었을 때 모니터링에도 들어갈 수 없다. API로 finalizer를 직접 지우는 방법은 발표자도 절대 하지 말라고 한 마지막 수단이다.
같은 원인 · 공통 쿠버네티스 API 서버, etcd
같은 원인 · 공통 쿠버네티스 API 서버, etcd
같은 원인 · 공통 쿠버네티스 API 서버, etcd
같은 원인 · 공통 쿠버네티스 API 서버
같은 원인 · 공통 쿠버네티스 API 서버
같은 원인 · 공통 쿠버네티스 API 서버
같은 원인 · 공통 쿠버네티스 API 서버
같은 원인 · 공통 쿠버네티스 API 서버