사례2건

2건 중 1~2번째

1. IL-0299 Wikimedia CirrusSearch 의 OpenSearch 클러스터에서 인덱스 약 60개가 red 상태가 되어 쓸 수 없었다

   Wikimedia Foundation2025

   증상

   2025-05-28 21:27 부터 CirrusStreamingUpdaterFlinkJobUnstable 알림이 울렸다. 검색 업데이트 파이프라인이 red 상태가 된 인덱스 약 60개에 쓰지 못하고 있었다.

   쓰기 거부

   촉발

   2025-05-28 21:08 에 폐기할 호스트 elastic/cirrussearch10[53-67] 의 클러스터 접근을 없애는 Puppet 패치가 머지됐다. 이 중 일부 호스트가 아직 primary 샤드를 가지고 있었다.

   원인

   설정 변경

   구성 요소

   Elasticsearch 와 OpenSearch

   기여 요인

   미검증 가정런북 부재미검증 백업

   감지

   사람이 발견했다. 2025-05-28 21:27 부터 CirrusStreamingUpdaterFlinkJobUnstable 알림이 울렸지만, 클러스터 유지보수 작업 때문에 다른 알림 다수가 억제돼 울리지 않았다. 엔지니어가 다음 날 07:24 에 조사를 시작했다.

   조치

   • 09:29 에 red 인덱스를 지워 클러스터를 green, 즉 쓸 수 있는 상태로 되돌렸다. 업데이트 파이프라인이 회복하기 시작했다.
   • 09:47 에 망가진 인덱스 복구를 시작했고 14:50 에 모든 인덱스가 돌아왔다.

   후속 조치

   • 운영 CirrusSearch 의 스냅샷 저장소를 다시 켠다.
   • 운영 대응에 맞춘 OpenSearch 대시보드를 만든다.
   • Search Platform 이 맡은 OpenSearch 클러스터의 Logstash 파이프라인을 확인하고 고친다.

   교훈

   노드 ban 은 성공을 보장하지 않는 동작이라 기대대로 되지 않았다. 같은 종류의 서버를 한꺼번에 여러 대 폐기하는 큰 작업에 유지보수 계획이나 런북이 없었다. 스냅샷과 대시보드, 로깅 같은 중요한 도구를 쓸 수 없거나 문서가 모자랐다. 데이터센터가 depool 돼 있던 덕분에 사용자 영향이 없었다.

   사례 보기
2. IL-0458 Toolforge 쿠버네티스 API 서버가 재시작 뒤 올라오지 못해 몇 시간 동안 클러스터 전체가 멈췄다

   Wikimedia Foundation2019

   증상

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

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

   촉발

   18:30 에 maintain-kubeusers 프로세스가 쿠버네티스 API 서버를 재시작했다. 재시작한 API 서버는 etcd 에 다시 연결해야 했는데, 전날 밤 퍼핏 변경으로 CA 인증서가 etcd 서버의 것과 어긋나 있어 연결하지 못했다.

   원인

   설정 변경

   구성 요소

   쿠버네티스 API 서버etcd구성 관리 도구

   기여 요인

   늦게 드러난 변경수동 조치 악화런북 부재

   감지

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

   조치

   • 19:10 과 20:30 에 쿠버네티스 마스터를, 20:18 에 etcd 클러스터를 재부팅했지만 도움이 되지 않았다.
   • 21:06 에 백업을 떠 둔 뒤 잦은 raft 선출을 원인에서 빼려고 etcd 클러스터를 노드 하나로 줄였다.
   • 노드를 다시 넣다 클러스터가 무너진 뒤 여러 시도 끝에 백업에서 etcd 전체 재해 복구를 해 00:25 쯤 etcd 를 원래 용량으로 되돌렸다.
   • 01:28 에 API 서버가 쓰는 CA 를 etcd 서버의 CA 로 바꿨고, 통신과 서비스가 돌아왔다. 퍼핏이 곧 이 변경을 되돌렸다.
   • 01:43 에 etcd 퍼핏 CA 인증서를 /var/lib/puppet/client/ssl/certs/ca.pem 에 두었고, 퍼핏이 이 인증서를 가져가 장애가 안정적으로 끝났다.

   후속 조치

   • etcd 클러스터 운영 절차를 문서로 남긴다. 작업 번호는 T232769 다.
   • Toolforge 쿠버네티스 업그레이드로 etcd 와 쿠버네티스의 오류 보고를 개선하고, 도구를 추가할 때 API 서버를 재시작하지 않아도 되게 한다. 작업 번호는 T214513 이다.
   • kube2proxy 가 API 서버 장애를 더 잘 견디게 만들어 본다. 작업 번호는 T232770 이다.
   • 퍼핏 CA 인증서를 점검한다. tools 프로젝트 안에 CA 인증서가 둘 이상 있어서는 안 된다. 작업 번호는 T232772 다.
   • 쿠버네티스 컨트롤 플레인을 고가용성으로 만든다. 작업 번호는 T142862 다.

   교훈

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

   사례 보기

원인별1