IL-0168 Scaleway · 2024-02-13kubernetes
2024년 2월 12일 Scaleway 는 새 쿠버네티스 릴리스를 모든 사용자에게 내놓았다. 12일에서 13일로 넘어가는 밤 많은 클러스터가 한꺼번에 자동 업그레이드를 시작했고, Kapsule API 가 느려지고 혼잡해졌다. 1월 24일에 배포한 새 노드 인증 방식에서는 이 혼잡 속에서 노드가 인증에 계속 실패하고 다시 시도했다. 이 재시도가 혼잡을 더 키웠다. 그 결과 FR-PAR 리전의 Kapsule 과 Kosmos 노드가 "Not Ready" 가 됐다.
팀은 Kubernetes API 자원을 두 번 늘렸고, API 트래픽을 제한했다가 나눠서 풀어 03:20 에 노드를 "Ready" 로 되돌렸다. 03:40 에는 혼잡 중에 만들어진 고장 노드를 스크립트로 교체했고, 05:30 에 서비스가 안정됐다. 15:40 에 근본 원인을 Kubernetes API 서버의 자원 부족으로 확정했다. 팀은 인증 방식의 실패와 재시도가 1월 24일 장애 때와 같은 혼잡을 만들었다고 봤다.
1월 24일 이후 넣은 단기 위험 완화 조치로는 재발을 막지 못했기 때문에 Scaleway 는 예전 인증 방식으로 롤백하기로 했다. 15:45 에 일부 클러스터부터 롤백을 시작했지만 16:00 에 혼잡이 한 번 더 일어났고, 트래픽 제한으로 16:40 에 모든 노드를 "Ready" 로 되돌렸다. 노드 인증이 한꺼번에 몰리지 않게 클러스터 업그레이드와 설정 갱신 기능을 껐고, 2월 16일부터 모든 클러스터로 롤백을 넓혀 2월 19일 19:41 에 마쳤다. 업그레이드와 갱신 기능은 2월 20일 10:30 에 다시 켰고, 장애는 그날 17:56 에 닫혔다.
2024년 2월 13일 01:04 CET 에 FR-PAR 리전의 Kubernetes API 에서 RAM 과 CPU 사용량이 치솟아 OOM 이 났다. 노드들이 컨트롤 플레인에 인증하지 못해 일부가 "Not Ready" 상태가 됐다.
Kubernetes API 응답 시간이 늘어나 일부 요청은 타임아웃이 났다. 노드는 인증하지 못한 채 잠시 "Not Ready" 에 머물렀고, 그 위의 서비스가 중단될 수 있었다. 자동 복구 기능이 일부 노드를 교체하면서 문제가 더 커졌다.
01:46 에 Kubernetes API 자원을 늘리자 잠시 나아지는 듯했지만 다시 OOM 이 났다. 02:20 에 한 번 더 늘리자 개선이 보였다. 02:30 에 API 트래픽을 제한했다가 03:20 부터 50-100 개 배치로 나눠 풀자 노드들이 인증에 성공해 "Ready" 가 됐다.
15:45 에 예전 인증 방식으로 일부 클러스터부터 롤백을 시작했는데, 16:00 에 API 혼잡이 다시 일어나 노드들이 또 인증하지 못하고 "Not Ready" 가 됐다. 같은 방식으로 트래픽을 제한했다가 나눠 풀었고, 16:40 에 모든 노드가 "Ready" 로 돌아왔다.
원인 ? 용량 한계
타임라인의 첫 기록은 01:04 CET 다. 이때 Kubernetes API 의 RAM 과 CPU 사용량이 치솟아 OOM 이 났고, 노드들이 컨트롤 플레인에 인증하지 못해 일부가 "Not Ready" 가 됐다. 기록된 첫 조치는 42분 뒤인 01:46 에 API 자원을 늘린 일이었다.
고객의 클러스터와 노드가 빠르게 늘면서 기존 트래픽 제어로는 혼잡을 막기 어려워졌다. 많은 클러스터의 자동 업그레이드가 한 번에 시작되면 Kubernetes API 에 부하가 몰리고, 계속 실패하고 재시도하는 노드 인증 방식이 혼잡을 더 키운다. 1월 24일 장애 뒤 넣은 단기 완화 조치로는 재발을 막지 못했다.
같은 원인 · 공통 쿠버네티스 API 서버
같은 원인 · 공통 쿠버네티스 API 서버
같은 원인 · 공통 쿠버네티스 API 서버
같은 원인 · 공통 쿠버네티스 API 서버
같은 원인 · 공통 쿠버네티스 API 서버
같은 원인 · 공통 쿠버네티스 API 서버
같은 원인 · 공통 쿠버네티스 API 서버
같은 원인 · 공통 쿠버네티스 API 서버