Incident Library

IL-0458 Wikimedia Foundation · 2019-09-10kubernetes

Toolforge 쿠버네티스 API 서버가 재시작 뒤 올라오지 못해 몇 시간 동안 클러스터 전체가 멈췄다

2019-09-10 18:30 에 maintain-kubeusers 프로세스가 Toolforge 쿠버네티스 API 서버를 재시작했고, API 서버는 다시 올라오지 못했다. 전날 밤 퍼핏 변경으로 API 서버가 쓰는 CA 인증서가 etcd 서버의 것과 어긋났는데, 재시작으로 etcd 에 다시 연결하기 전까지는 드러나지 않았다. API 서버가 멈춘 동안 webservice 와 kubectl 로 도구를 띄우거나 관리할 수 없었고, kube2proxy 가 죽어 쿠버네티스 webservice 전부가 프록시 단계에서 내려갔다.

로그에 etcd 오류가 찍히고 옛 etcdctl 이 1초 만에 타임아웃을 내자 팀은 etcd 를 원인으로 보았다. 쿠버네티스 마스터와 etcd 클러스터를 재부팅하고, 백업을 뜬 뒤 잦은 raft 선출을 원인에서 빼려고 etcd 를 노드 하나로 줄였다. 21:24 에 etcd 가 느렸을 뿐 떨어진 것이 아님을 알고 클러스터를 원래 크기로 되돌리기 시작했다. 그런데 첫 노드를 다시 넣을 때 실수가 있어 노드 두 개짜리 etcd 클러스터가 무너졌다. 노드 두 개짜리 etcd 클러스터는 두 노드가 모두 살아 있어야 동작한다. 결국 백업에서 전체 재해 복구를 해 00:25 쯤 etcd 를 원래 용량으로 되돌렸다.

01:02 에 CA 인증서가 전날 밤 바뀌었다는 것을 찾았고, 01:05 에 curl 로 kube API 서버에서 나가는 SSL 호출에서만 CA 신뢰 오류가 나고 etcd 서버끼리는 나지 않는 것을 재현했다. 01:28 에 CA 를 etcd 서버의 것으로 바꾸자 통신과 서비스가 돌아왔지만, 01:33 에 퍼핏이 그 변경을 되돌려 다시 깨졌다. 01:43 에 etcd 퍼핏 CA 인증서를 /var/lib/puppet/client/ssl/certs/ca.pem 에 두자 퍼핏이 그 인증서를 가져가 안정적으로 복구됐다. 복구에는 SRE 4명, 팀 관리자 1명, 기술 자원봉사자 1명이 참여했다.

심각도
–
영향 범위
Toolforge Kubernetes API server down for several hours: tools could not be launched or managed with webservice or kubectl, and Kubernetes webservices were offline at the proxy level after kube2proxy crashed
영향 사용자
Toolforge users and the tools running on the Kubernetes backend
지역
–
감지까지
15m
복구까지
7h 13m

증상

18:45 에 toolschecker 의 icinga 검사 "All k8s nodes healthy" 가 알림을 울렸다. 쿠버네티스 API 서버가 응답하지 않아 모니터링에서도 사용자 쪽에서도 클러스터가 완전히 내려간 것처럼 보였다. 사용자는 webservice 명령으로 도구를 띄울 수 없었고 kubectl 로 상태를 보거나 도구를 다룰 수도 없었다.

kube-apiserver 로그의 마지막 실패 메시지는 "Failed to list *storage.StorageClass: client: etcd cluster is unavailable or misconfigured" 였다. kube-apiserver 프로세스를 다시 시작해도 실패했고, 쿠버네티스 마스터를 재부팅해도 같았다.

API 서버가 멈춘 직후 kube2proxy 도 쿠버네티스 변경을 watch 하지 못했다. kube2proxy 는 처음부터 다시 시작했다가 죽었다. prometheus 로 보면 컨테이너와 도구 자체는 영향이 없었지만, 쿠버네티스 webservice 전부가 프록시 단계에서 내려간 것으로 보였다. 19:48 에는 Toolforge 홈페이지 다운 알림도 울렸다.

18:55 에 퍼핏 인증서를 의심했다. 그러나 이 클러스터는 프로젝트 내부 인증서를 쓰고 퍼핏 인증서는 전날 밤에 바뀌었으므로, 장애 시점과 맞지 않는다고 보고 제쳤다. 방화벽 변경도 확인했지만 새 퍼핏 마스터를 위한 변경이어서 시점이 맞지 않았다.

etcd 헬스체크는 정상으로 나왔다. 그런데 etcd 에서도 같은 오류 메시지가 재현됐고 etcd 로그에 타임아웃과 잦은 raft 선출이 보였다. 그래서 팀은 etcd 를 원인으로 잘못 짚었다. tools-k8s-etcd 서버의 옛 etcdctl 은 1초 만에 타임아웃이 났다. 이 때문에 etcd 가 죽었다 살아나기를 되풀이하거나 점점 무너지는 중인 것처럼 보였다. 21:24 에야 etcd 가 떨어진 것이 아니라 etcdctl 기본 타임아웃보다 느렸을 뿐이라는 것을 알았다.

증상 컨트롤 플레인 무응답서비스 중단TLS 인증서 오류

원인

원인 설정 변경

구성 요소 쿠버네티스 API 서버etcd구성 관리 도구
기여 요인 늦게 드러난 변경수동 조치 악화런북 부재
촉발
18:30 에 maintain-kubeusers 프로세스가 쿠버네티스 API 서버를 재시작했다. 재시작한 API 서버는 etcd 에 다시 연결해야 했는데, 전날 밤 퍼핏 변경으로 CA 인증서가 etcd 서버의 것과 어긋나 있어 연결하지 못했다.

감지

처음 울린 것은 http://checker.tools.wmflabs.org/k8s/nodes/ready 를 검사하는 icinga 알림이었다. 18:45 에 toolschecker 의 "All k8s nodes healthy" 검사가 울렸다.

조치

후속 조치

교훈

etcd 처럼 원래 말썽이 잦은 구성 요소가 해법 찾기를 헷갈리게 했다. 퍼핏 인증서는 위험하다. 아주 오래된 쿠버네티스 버전은 로그에 남기는 오류 메시지가 형편없다. 팀은 CA 인증서가 아니라 etcd 를 고치려다 상황을 더 나쁘게 만들었다. 문제는 API 서버를 재시작할 때에야 드러났다. etcd 클러스터에는 문서화되지 않은 오래된 특이점이 있었고, etcd 재해 복구와 노드 교체 절차는 문서로 남아 있지 않았다. 이 셋이 겹쳐 해법을 찾는 데 오래 걸렸다. 교차 교육이 있었다면 도움이 됐을 수 있지만, 이번 일은 어차피 여럿이 함께 풀어야 했다.

출처

참고 문서

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 쿠버네티스 API 서버, etcd, 구성 관리 도구. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.