{"id":"IL-0084","org":"Namespace","date":"2024-10-22","docs":[],"title":{"en":"Packet drops on a bare metal provider's vSwitch forced Namespace to rebuild its fra3 region and left global capacity short, and the next day slow NVMe writes on a control plane node drove the Kubernetes API server to very high CPU","ko":"베어메탈 업체 vSwitch 의 패킷 드롭으로 Namespace 의 fra3 리전이 빠져 전 세계 용량이 모자랐고, 다음 날에는 컨트롤 플레인 노드의 느린 NVMe 쓰기로 쿠버네티스 API 서버 CPU 가 치솟아 zrh1 이 멈췄다."},"domain":["kubernetes","networking"],"impact":{"scope":"Customer jobs: job failures from packet drops, longer queue times across the fleet and some remote builds failing for lack of capacity on 22 October; workloads to zrh1 failing to start on 23 October","users":"All customers running jobs during the outages","region":"fra3 and zrh1 (Europe); queue times across the global fleet"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Running hot with a delayed hardware delivery left no room to take a region out, so fixing a provider network fault turned into a global capacity shortage.\n\nAfter one outage the team was anchored on its cause and first looked for network problems in the second outage, which had a different cause: a control plane node whose disk could not keep up with the Kubernetes change rate.","ko":"비결정적인 네트워크 드롭은 재시도에 가려져서 SLO 기반 모니터링으로 긴 시간을 봐야 영향이 드러난다. 핵심 인프라의 문제를 직접 고칠 수단을 갖고 있어야 한다. 큰 장애 직후에는 같은 종류의 원인에 매이기 쉽다. 이번 두 번째 장애는 전혀 다른 종류였다. 미리 해 둔 모의 위기 훈련 덕분에 대응을 바로 체계적으로 시작할 수 있었다."},"related":[],"sources":[{"url":"https://namespace.so/blog/slowdown-oct22","kind":"blog","license":"unknown","archived":null}],"summary":{"en":"Namespace runs customer jobs on bare metal machines, both its own hardware and machines rented from bare metal providers, managed through Kubernetes clusters tuned for fast pod creation. Growth outpaced planning towards the end of Q3 2024, and new hardware due in a European region by 15 October was delayed three to four weeks because the supplier had ordered the wrong DIMMs. Namespace ordered extra capacity from an existing provider whose machines are connected in one L2 segment by a feature the provider calls vSwitch.\n\nFrom 17 October packets through the vSwitch dropped sporadically, and by 21 October jobs were failing. Without a prompt fix from the provider, Namespace moved fra3 off the vSwitch: each provider machine was connected to the nearby Namespace-managed zrh1 cluster over Wireguard, and all customer traffic was diverted from fra3 to other regions. Because the infrastructure is immutable, every machine had to be repaved with a new identity, certificates and encryption-at-rest keys, and regional caches were dropped to recover faster. Image distribution to many machines at once was slow because a few distributor machines are not built for that, so the team cloned datasets in a more distributed way. The outage ran from 12:00 to 18:30 CET on 22 October, and the rebuild was mostly complete by 20:30.\n\nOn 23 October one zrh1 control plane node, an older machine type than in other regions, started failing partially because of slow NVMe writes. The rate of change in Kubernetes had grown past what its I/O could handle, and the API server's CPU went very high from retries, so other parts of the system suffered. Workloads were redirected away from zrh1, and the node's key state was cloned to a higher-capacity node that took over its role with the same IP address; after working through pending changes the cluster returned to normal and each kubelet reconnected. That second outage lasted roughly 50 minutes.","ko":"Namespace 는 자체 관리하는 베어메탈 머신에 고객 워크로드를 올린다. 자체 하드웨어로 옮기는 중에도 기존 베어메탈 업체의 용량을 함께 쓰고 있었다. 3분기 말부터 성장이 계획을 앞질렀고, 10월 15일까지 유럽 리전 하나에 들어올 증설 장비가 공급사의 DIMM 주문 실수로 3주에서 4주 늦어졌다. 그 틈을 메우려고 기존 베어메탈 업체에 추가 용량을 주문했다.\n\n이 업체에서는 머신들을 같은 L2 세그먼트로 묶으려고 vSwitch 기능을 썼다. 10월 17일부터 vSwitch 를 지나는 패킷이 무작위로 버려졌다. 업체는 문제를 확인했지만 빨리 해결하지 않았다. 10월 21일에는 패킷 드롭으로 고객 잡이 실패했다. Namespace 는 vSwitch 를 쓰지 않도록 네트워크 구성을 통째로 바꾸기로 했다. 업체의 물리 머신 하나하나를 Wireguard 로 가까운 자체 클러스터에 연결하는 방식이다. 이 머신들이 피크 용량을 맡고 있었으므로 고객 영향을 피할 수 없었다.\n\n10월 22일 09:30 CET 에 fra3 를 zrh1 에 연결하는 형태로 다시 구축하기 시작했다. 12:00 부터 영향받는 리전의 고객 트래픽을 다른 리전으로 돌리자 전 세계 용량이 모자라 그동안 잡을 돌린 모든 고객의 대기 시간이 늘었다. 불변 인프라 방식이라 머신마다 새 신원, 새 인증서, 새 저장 데이터 암호화 키를 받도록 다시 깔아야 했다. 캐시를 다른 리전으로 옮기면 복구가 늦어지므로 캐시를 버렸다. 고객 이미지를 많은 머신에 한꺼번에 나눠 주느라 속도가 더 떨어졌고, 팀 일부가 데이터셋을 더 분산된 방식으로 복제해 작업을 앞당겼다. 18:30 에 70% 가 끝나 대기 시간이 회복되기 시작했고, 20:30 에 대부분이 끝났다.\n\n10월 23일에는 컨트롤 플레인 노드 하나가 느린 NVMe 쓰기 때문에 부분적으로 실패했다. 사용량이 늘면서 쿠버네티스의 변경 속도가 그 노드의 I/O 한계를 넘었다. API 서버는 재시도가 늘며 CPU 사용량이 매우 높아졌다. 이 노드는 다른 리전과 달리 오래된 머신 유형이어서 문제가 더 커졌다. 팀은 이 노드의 핵심 상태를 더 큰 노드로 복제해 같은 IP 주소로 역할을 넘겼다. 쌓인 변경을 처리하고 나자 클러스터가 정상으로 돌아왔고, 각 kubelet 은 아무 일 없던 것처럼 다시 연결됐다. 두 번째 장애는 약 50분 이어졌다."},"trigger":{"en":"Random packet drops on the bare metal provider's vSwitch from 17 October 2024; for the second outage, a rate of Kubernetes changes that the slow NVMe on one control plane node could no longer keep up with.","ko":"fra3 에서 베어메탈 업체의 vSwitch 를 지나는 패킷이 무작위로 드문드문 버려지기 시작했다. 두 번째 장애는 컨트롤 플레인 노드 하나의 느린 NVMe 가 쿠버네티스의 변경 속도를 더는 따라가지 못하면서 일어났다."},"severity":"unknown","symptoms":["intermittent-connection-failures","high-latency","control-plane-slow","service-unavailable"],"timeline":{"detected_after":null,"resolved_after":"6h 30m"},"date_kind":"incident","detection":{"en":"SLO-based monitoring of latency targets showed the error budget burning while retries hid the individual packet drops.","ko":"패킷 드롭은 비결정적이라 바로 보이지 않았다. 주요 상호작용에 잡아 둔 백분위 지연 SLO 의 에러 버짓이 줄어드는 것을 보고 영향을 알아챘다."},"components":["kube-apiserver"],"root_cause":"cloud-provider","remediation":[{"text":{"en":"diverted all customer traffic from fra3 to other regions","ko":"fra3 의 고객 트래픽을 모두 다른 리전으로 돌렸다."}},{"text":{"en":"connected each provider machine to the zrh1 cluster over Wireguard instead of the vSwitch","ko":"vSwitch 대신 Wireguard 로 업체의 물리 머신 하나하나를 zrh1 클러스터에 연결했다."}},{"text":{"en":"repaved every fra3 machine with a new identity, certificates and encryption-at-rest keys, dropping regional caches to recover faster","ko":"각 머신을 새 신원, 새 인증서, 새 저장 데이터 암호화 키로 다시 깔았고, 복구를 앞당기려고 캐시를 버렸다."}},{"text":{"en":"cloned existing datasets in a more distributed way to speed up repaving the machines","ko":"팀 일부가 데이터셋을 더 분산된 방식으로 복제해 머신을 다시 까는 작업을 앞당겼다."}},{"text":{"en":"added machines back to the new region in batches and returned the region to the compute pool","ko":"준비된 머신을 묶음으로 새 리전에 넣고, 충분히 모이자 리전을 컴퓨트 풀에 다시 넣었다."}},{"text":{"en":"redirected workloads away from zrh1 during the second outage","ko":"두 번째 장애에서 워크로드를 zrh1 밖으로 돌렸다."}},{"text":{"en":"cloned the failing control plane node's key state to a higher-capacity node that took over its role and IP address","ko":"실패하던 컨트롤 플레인 노드의 핵심 상태를 더 큰 노드로 복제하고, 새 노드가 같은 IP 주소로 옛 노드의 역할을 넘겨받게 했다."}}],"action_items":[{"text":{"en":"Credit all instances that ran during the outages back to customers","ko":"장애 동안 실행된 모든 인스턴스의 요금을 고객에게 크레딧으로 환급했다."}},{"text":{"en":"Build up backup regions and solutions so a similar event has options that do not affect customers","ko":"비슷한 상황이 다시 와도 고객에게 영향을 주지 않도록 백업 리전과 대안을 만든다."}}],"contributing":["no-capacity-planning","no-spare-capacity","overlapping-failures"],"recurrence_of":null,"symptoms_text":{"en":"From 17 October 2024, packets through the vSwitch that joined Namespace's bare metal machines at one provider in the fra3 region were dropped at random. Retries in TCP, QUIC and the Namespace control plane hid most of it, but the SLO error budget for latency targets on key interactions began to burn.\n\nThe drops grew towards the weekend, and on Monday 21 October the SLO fell sharply and the packet drops were making customer jobs fail. The provider confirmed a problem but did not fix it promptly.\n\nWhen fra3 was taken out of service on 22 October to rebuild its network, global capacity ran short, linux/arm64 first. By 16:00 CET queue times were visible across the whole fleet and some remote builds failed for lack of capacity.\n\nOn 23 October at 20:10 CET the zrh1 region began to degrade, and at 20:14 its core failed and workloads sent to zrh1 failed to start. One control plane node had backed-up I/O from slow NVMe writes and the Kubernetes API server showed very high CPU from retries. Coming straight out of a network outage, the team first looked for network-related causes.","ko":"10월 17일부터 fra3 리전에서 패킷이 드문드문 버려지기 시작했다. 처음 이틀은 TCP 와 QUIC 의 재전송이나 컨트롤 플레인의 재시도로 대부분 넘어갔지만, 시스템이 조금씩 불안정했다. 이런 실패는 비결정적이라 겉으로 잘 드러나지 않았다.\n\n영향은 SLO 기반 모니터링에서 먼저 보였다. 주요 상호작용의 백분위 지연 목표를 잡아 두었는데, SLO 에러 버짓이 줄어들기 시작했다. 드롭은 주말로 갈수록 늘었지만 주말 트래픽이 적어 영향이 덜했다. 월요일인 10월 21일에 SLO 가 크게 떨어졌고, 패킷 드롭 때문에 고객 잡이 실패하기 시작했다.\n\n10월 22일 12:00 CET 에 fra3 를 다시 구축하느라 서비스에서 빼자 전 세계 용량이 모자랐다. linux/arm64 부터 부족해졌고, 16:00 에는 전체 플릿에서 대기 시간이 길어졌으며 일부 원격 빌드가 용량 부족으로 실패했다.\n\n10월 23일 20:10 CET 에 zrh1 의 성능이 떨어지기 시작했다. 20:14 에 zrh1 의 핵심 구성 요소가 실패해 zrh1 로 가는 워크로드가 시작되지 못했다. 컨트롤 플레인 노드 하나에서 느린 NVMe 쓰기로 I/O 가 밀렸고, 쿠버네티스 API 서버의 CPU 사용량이 재시도 증가로 매우 높아졌다. 직전 장애가 네트워크 문제였기 때문에 팀은 처음에 같은 종류의 문제부터 찾았지만, 이번 원인은 전혀 다른 종류였다."},"updated_at":"2026-11-10T00:00:31.961344Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0084","org_slug":"namespace"}