{"id":"IL-0168","org":"Scaleway","date":"2024-02-13","docs":[],"title":{"en":"Simultaneous cluster auto-upgrades overloaded Scaleway's Kubernetes API, and a node authentication retry loop kept Kapsule and Kosmos nodes NotReady in FR-PAR","ko":"새 쿠버네티스 릴리스 뒤 많은 Kapsule 클러스터가 동시에 자동 업그레이드되면서 Kubernetes API 가 과부하로 OOM 이 났고, 새 노드 인증 방식의 재시도가 혼잡을 키워 노드가 Not Ready 가 됐다."},"domain":["kubernetes"],"impact":{"scope":"Kapsule and Kosmos clusters in mutualized and dedicated environments: slow and timing-out Kubernetes API, nodes NotReady","users":"Customers of Kapsule and Kosmos in FR-PAR","region":"FR-PAR (Paris)"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Letting many clusters auto-upgrade at the same moment after a release turns routine upgrades into one coordinated load spike on the shared Kubernetes API. A node authentication mechanism that retries without letting up turns a slow API into an unavailable one, and auto-healing that replaces NotReady nodes amplifies the problem.\n\nThe congestion pattern had already appeared three weeks earlier, and short-term mitigations did not stop it from recurring, so Scaleway rolled back the new authentication mechanism. Scaleway notes that as the number of customer clusters and nodes grows sharply, traffic control mechanisms have to improve to prevent congestion.","ko":"고객의 클러스터와 노드가 빠르게 늘면서 기존 트래픽 제어로는 혼잡을 막기 어려워졌다. 많은 클러스터의 자동 업그레이드가 한 번에 시작되면 Kubernetes API 에 부하가 몰리고, 계속 실패하고 재시도하는 노드 인증 방식이 혼잡을 더 키운다. 1월 24일 장애 뒤 넣은 단기 완화 조치로는 재발을 막지 못했다."},"related":[],"sources":[{"url":"https://www.scaleway.com/en/blog/update-kapsule-kosmos-fr-par/","kind":"blog","license":"unknown","archived":"https://web.archive.org/web/2024/https://www.scaleway.com/en/blog/update-kapsule-kosmos-fr-par/"}],"summary":{"en":"Scaleway's managed Kubernetes services Kapsule and Kosmos failed in the Paris region (FR-PAR) on 13 February 2024 from 01:04 until 16:40 CET. A new Kubernetes release had become available to all users on 12 February, and overnight many clusters triggered their auto-upgrade simultaneously. The resulting load made the Kubernetes API slow and congested, and after RAM and CPU spikes it ran out of memory. Scaleway later named the root cause as insufficient resources allocated to the Kubernetes API server.\n\nWith the API unavailable, nodes failed to authenticate to their control plane and became NotReady. A new node authentication mechanism, deployed on 24 January 2024, failed and retried continuously, which deepened the congestion, and auto-healing replaced some nodes automatically, which amplified the problem. The same fail-and-retry congestion had caused an incident on 24 January 2024, and the short-term mitigations put in place since then had not prevented it from happening again.\n\nScaleway raised the API's resources twice, applied API traffic restrictions at 02:30 to smooth incoming traffic, and from 03:20 removed them progressively in 50-100 batches, after which nodes authenticated and became Ready. A script launched at 03:40 replaced the failing nodes created during the congestion, and service was stable by 05:30. At 15:45 Scaleway began rolling back to the former authentication mechanism on a subset of clusters; congestion returned at 16:00 and was handled the same way, and all nodes were Ready by 16:40. Cluster upgrade and configuration update features were disabled to avoid simultaneous node authentication. The rollback reached all clusters at 19:41 on 19 February, the features were re-enabled at 10:30 on 20 February, and the incident was closed at 17:56 that day.","ko":"2024년 2월 12일 Scaleway 는 새 쿠버네티스 릴리스를 모든 사용자에게 내놓았다. 12일에서 13일로 넘어가는 밤 많은 클러스터가 한꺼번에 자동 업그레이드를 시작했고, Kapsule API 가 느려지고 혼잡해졌다. 1월 24일에 배포한 새 노드 인증 방식에서는 이 혼잡 속에서 노드가 인증에 계속 실패하고 다시 시도했다. 이 재시도가 혼잡을 더 키웠다. 그 결과 FR-PAR 리전의 Kapsule 과 Kosmos 노드가 \"Not Ready\" 가 됐다.\n\n팀은 Kubernetes API 자원을 두 번 늘렸고, API 트래픽을 제한했다가 나눠서 풀어 03:20 에 노드를 \"Ready\" 로 되돌렸다. 03:40 에는 혼잡 중에 만들어진 고장 노드를 스크립트로 교체했고, 05:30 에 서비스가 안정됐다. 15:40 에 근본 원인을 Kubernetes API 서버의 자원 부족으로 확정했다. 팀은 인증 방식의 실패와 재시도가 1월 24일 장애 때와 같은 혼잡을 만들었다고 봤다.\n\n1월 24일 이후 넣은 단기 위험 완화 조치로는 재발을 막지 못했기 때문에 Scaleway 는 예전 인증 방식으로 롤백하기로 했다. 15:45 에 일부 클러스터부터 롤백을 시작했지만 16:00 에 혼잡이 한 번 더 일어났고, 트래픽 제한으로 16:40 에 모든 노드를 \"Ready\" 로 되돌렸다. 노드 인증이 한꺼번에 몰리지 않게 클러스터 업그레이드와 설정 갱신 기능을 껐고, 2월 16일부터 모든 클러스터로 롤백을 넓혀 2월 19일 19:41 에 마쳤다. 업그레이드와 갱신 기능은 2월 20일 10:30 에 다시 켰고, 장애는 그날 17:56 에 닫혔다."},"trigger":{"en":"A new Kubernetes release was made available to all users on 12 February 2024, and during the night of 12 to 13 February many clusters triggered their auto-upgrade at the same time.","ko":"2월 12일 새 쿠버네티스 릴리스가 모든 사용자에게 나온 뒤, 12일에서 13일로 넘어가는 밤에 많은 클러스터가 동시에 자동 업그레이드를 시작했다."},"severity":"unknown","symptoms":["node-not-ready","control-plane-slow","oom-killed"],"timeline":{"detected_after":null,"resolved_after":"15h 36m"},"date_kind":"incident","detection":{"en":"The timeline's first entry, at 01:04 CET, records the Kubernetes API's RAM and CPU spikes and out-of-memory state, with nodes unable to authenticate to their control plane and some becoming \"Not Ready\". The first recorded action, 42 minutes later at 01:46, was to increase the resources allocated to the API.","ko":"타임라인의 첫 기록은 01:04 CET 다. 이때 Kubernetes API 의 RAM 과 CPU 사용량이 치솟아 OOM 이 났고, 노드들이 컨트롤 플레인에 인증하지 못해 일부가 \"Not Ready\" 가 됐다. 기록된 첫 조치는 42분 뒤인 01:46 에 API 자원을 늘린 일이었다."},"components":["kube-apiserver"],"root_cause":"capacity","remediation":[{"text":{"en":"increased the resources allocated to the Kubernetes API at 01:46 and again at 02:20","ko":"Kubernetes API 에 배정한 자원을 01:46 과 02:20 두 차례 늘렸다."}},{"text":{"en":"applied API traffic restrictions at 02:30 to smooth the incoming traffic","ko":"02:30 에 API 트래픽을 제한해 들어오는 트래픽을 고르게 만들고 혼잡을 줄였다."}},{"text":{"en":"removed the traffic restrictions progressively in 50-100 batches from 03:20","ko":"03:20 부터 트래픽 제한을 50-100 개 배치로 나눠 차례로 풀어 노드들이 다시 인증하고 \"Ready\" 가 되게 했다."}},{"text":{"en":"ran a script at 03:40 to replace the failing nodes created during the congestion","ko":"03:40 에 API 혼잡 중에 만들어진 고장 노드를 교체하는 스크립트를 돌렸다."}},{"text":{"en":"rolled back to the former node authentication mechanism, first on a subset of clusters from 15:45 and on all clusters by 19:41 on 19 February","ko":"15:45 부터 노드 인증이 한꺼번에 몰리지 않게 일부 클러스터부터 예전 인증 방식으로 차례로 롤백했고, 2월 19일 모든 클러스터에서 롤백을 마쳤다."}},{"text":{"en":"disabled cluster upgrade and configuration update features until 10:30 on 20 February","ko":"노드 인증이 동시에 몰릴 수 있는 클러스터 업그레이드와 설정 갱신 기능을 2월 20일 10:30 까지 껐다."}}],"action_items":[{"text":{"en":"Increase the resources allocated to the Kubernetes API","ko":"Kubernetes API 자원 배정을 늘렸다."}},{"text":{"en":"Roll back to the former node authentication mechanism","ko":"예전 인증 방식으로 롤백했다."}},{"text":{"en":"Implement a local authentication cache on nodes","ko":"노드에 로컬 인증 캐시를 둔다."}},{"text":{"en":"Rework the resource allocation strategy to behave better under load spikes","ko":"부하가 치솟을 때 더 잘 버티도록 자원 배정 전략을 다시 짠다."}},{"text":{"en":"Add new request queuing mechanisms for Kubernetes","ko":"쿠버네티스에 새 요청 큐잉 방식을 넣는다."}},{"text":{"en":"Separate the different components to reduce side effects under high load or failure","ko":"높은 부하나 장애가 다른 구성 요소로 번지지 않게 구성 요소를 서로 분리한다."}},{"text":{"en":"Monitor selected metrics closely to identify anomalous patterns earlier","ko":"몇몇 지표를 꼼꼼히 지켜봐 이상 패턴을 더 일찍 찾는다."}},{"text":{"en":"Refund customers who deployed nodes during the incident but could not use them normally","ko":"이 기간에 노드를 배포했지만 제대로 쓰지 못한 고객에게 환불한다."}}],"contributing":["retry-storm","automation-amplified","no-staged-rollout"],"recurrence_of":null,"symptoms_text":{"en":"At 01:04 CET on 13 February 2024, the Kubernetes API behind Scaleway's managed Kubernetes services Kapsule and Kosmos in the Paris region (FR-PAR) spiked in RAM and CPU use and ran out of memory. Nodes in FR-PAR could no longer authenticate to their control plane, and some of them went \"Not Ready\". Customers on both shared (mutualized) and dedicated environments were affected.\n\nKubernetes API response times rose until some requests timed out. The auto-healing feature automatically replaced some of the failing nodes, which made the problem bigger.\n\nThe first increase of the API's resources, at 01:46, seemed to help but the API ran out of memory again; a second increase at 02:20 brought improvement. Later in the day, when the rollback of the node authentication mechanism started at 15:45, API congestion returned at 16:00 and nodes again went Not Ready.","ko":"2024년 2월 13일 01:04 CET 에 FR-PAR 리전의 Kubernetes API 에서 RAM 과 CPU 사용량이 치솟아 OOM 이 났다. 노드들이 컨트롤 플레인에 인증하지 못해 일부가 \"Not Ready\" 상태가 됐다.\n\nKubernetes API 응답 시간이 늘어나 일부 요청은 타임아웃이 났다. 노드는 인증하지 못한 채 잠시 \"Not Ready\" 에 머물렀고, 그 위의 서비스가 중단될 수 있었다. 자동 복구 기능이 일부 노드를 교체하면서 문제가 더 커졌다.\n\n01:46 에 Kubernetes API 자원을 늘리자 잠시 나아지는 듯했지만 다시 OOM 이 났다. 02:20 에 한 번 더 늘리자 개선이 보였다. 02:30 에 API 트래픽을 제한했다가 03:20 부터 50-100 개 배치로 나눠 풀자 노드들이 인증에 성공해 \"Ready\" 가 됐다.\n\n15:45 에 예전 인증 방식으로 일부 클러스터부터 롤백을 시작했는데, 16:00 에 API 혼잡이 다시 일어나 노드들이 또 인증하지 못하고 \"Not Ready\" 가 됐다. 같은 방식으로 트래픽을 제한했다가 나눠 풀었고, 16:40 에 모든 노드가 \"Ready\" 로 돌아왔다."},"updated_at":"2026-11-10T00:00:37.035810Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0168","org_slug":"scaleway"}