{"id":"IL-0233","org":"Nebius","date":"2025-03-13","docs":[],"title":{"en":"A VPC control plane release broke IP alias routes in Nebius eu-west1, and Managed Kubernetes pods lost connectivity","ko":"eu-west1 에서 Managed Kubernetes 의 거의 모든 파드가 네트워크 연결을 잃었고 롤백으로도 돌아오지 않았다"},"domain":["kubernetes","networking"],"impact":{"scope":"Practically every pod of Managed Services for Kubernetes in eu-west1 lost connectivity for at least some time between 13:36 and 18:11 UTC","users":"Clients running Managed Services for Kubernetes in eu-west1","region":"eu-west1"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"The failure needed both an existing IP alias at release time and a particular order of node updates, and neither the testing installation nor the canaries met both, so neither caught it. Missing alerts on technical metrics that deviate from normal, here the number of routes and the number of drops, made the response much slower.","ko":"문제를 재현하려면 두 조건이 함께 맞아야 해서 테스트 환경과 카나리의 e2e 테스트로는 잡지 못했다. 기술 지표가 평소 값에서 벗어날 때 울리는 알림이 모자라 대응이 늦어졌다. 이번 경우에는 경로 수와 패킷 drop 수가 민감하게 반응한 지표였다."},"related":[],"sources":[{"url":"https://nebius.com/blog/posts/incident-post-mortem-analysis-networking-issues-for-managed-services-for-kubernetes-march-13","kind":"blog","archived":"https://web.archive.org/web/20260822200021/https://nebius.com/blog/posts/incident-post-mortem-analysis-networking-issues-for-managed-services-for-kubernetes-march-13"}],"summary":{"en":"Pods of Nebius Managed Services for Kubernetes depend on the IP alias (prefix delegation) mechanism of virtual machine network interfaces. A host component of the VPC control plane sends, receives and processes BGP messages and announces and withdraws routes. A bug in that component, in production since a much earlier release and unknown to the developers, made it partly ignore route distinguishers, so some IP alias announcements that should have been kept apart were merged into one, and one withdrawal could cancel two different announcements. The release on 13 March changed route distinguisher values for a new feature, and only the update messages of Managed Kubernetes pods changed. A sequence of two announcements and one withdrawal then left the data plane with no active route, and packets for those IP aliases were dropped.\n\nThe team noticed the problem at 15:13 UTC and started a rollback at 15:30 UTC, but rolling back produced the same sequence of update messages with the route distinguishers reversed, so it did not help. At 16:41 UTC the team found that restarting the host VPC component on one node fixed that node and began restarting it on every affected node one at a time. The root cause was found at 17:36 UTC; once the team was sure the restart alone fixed the problem, it restarted the component on the remaining nodes in parallel from 17:57 UTC, and the impact was fully mitigated at 18:11 UTC. The bug needed two conditions to show: an IP alias had to exist when the release changed route distinguishers, and the node with the virtual machine sending to that IP alias had to be updated before the node with the receiving virtual machine. The permanent e2e test virtual machines on the testing installation met only the first condition, and none of them ran on canary nodes.","ko":"2025-03-13 eu-west1 리전에서 VPC 서비스 컨트롤 플레인 구성 요소 하나를 릴리스하자 Managed Services for Kubernetes 고객 파드에 대규모 네트워크 장애가 났다. 13:36 UTC 에 카나리 배포를, 14:35 UTC 에 리전 전체 배포를 시작했고, Nebius 팀은 15:13 UTC 에 문제를 알았다. eu-west1 의 거의 모든 Managed Kubernetes 파드가 13:36 에서 18:11 UTC 사이에 한동안 연결을 잃었다.\n\nVPC 컨트롤 플레인의 호스트 구성 요소는 BGP 메시지를 주고받아 처리하고, 경로를 광고하고 철회한다. 이 구성 요소에는 경로 광고의 route distinguisher 를 일부 무시하는 버그가 오래전부터 있었다. 이번 릴리스가 새 기능을 위해 route distinguisher 값을 바꾸자, 따로 다뤄야 할 IP alias 광고 두 개가 하나로 합쳐졌다. 그래서 철회 한 번이 서로 다른 광고 두 개를 함께 지웠다. 광고 두 번과 철회 한 번이 이어지자 데이터 플레인에 활성 경로가 하나도 남지 않았고, 그 경로로 가는 패킷은 처리되지 않았다. 가상 머신 네트워크 인터페이스의 IP alias, 곧 prefix delegation 이 망가졌다. Managed Kubernetes 의 파드 네트워크는 이 방식에 기대고 있었다. 이번 릴리스가 바꾼 것은 Managed Kubernetes 파드의 업데이트 메시지뿐이어서 다른 서비스는 영향을 받지 않았다.\n\n15:30 UTC 의 롤백은 효과가 없었다. 롤백해도 같은 순서의 업데이트 메시지가 route distinguisher 만 뒤바뀐 채 나왔기 때문이다. 16:41 UTC 에 팀은 문제가 난 노드에서 구성 요소를 재시작하면 그 노드가 풀린다는 것을 찾아 노드를 하나씩 재시작했다. 17:36 UTC 에 실제 원인을 찾았고, 17:57 UTC 에 재시작만으로 고쳐진다고 확신해 병렬 재시작을 시작했다. 18:11 UTC 에 영향이 완전히 해소되었다.\n\n테스트 환경과 카나리에서는 이 문제를 잡지 못했다. 문제가 재현되려면 두 조건이 맞아야 했다. 첫째, route distinguisher 를 바꾸는 릴리스 시점에 IP alias 가 이미 있어야 했다. 둘째, IP alias 로 패킷을 보내는 가상 머신의 노드가 받는 가상 머신의 노드보다 먼저 업데이트되어야 했다. 테스트 환경의 상시 e2e 가상 머신은 첫 조건만 맞았다. eu-west1 카나리도 사정이 비슷했고, 상시 e2e 가상 머신은 카나리 노드에 있지 않았다. 기술 지표가 평소 값에서 벗어날 때 울리는 알림이 모자라 대응 시간도 크게 늘었다."},"trigger":{"en":"A release of a VPC control plane component in eu-west1, deployed to canaries from 13:36 UTC and to all other nodes from 14:35 UTC, changed route distinguisher values for a new feature. The change made a long-standing bug in the handling of route announcements take effect for the update messages of Managed Kubernetes pods.","ko":"eu-west1 에 배포한 VPC 컨트롤 플레인 구성 요소의 릴리스가 새 기능에 필요한 route distinguisher 값을 바꿨다. 이 변경으로 오래전부터 코드에 있던 버그가 실제로 드러났다."},"severity":"unknown","symptoms":["network-unreachable"],"timeline":{"detected_after":"1h 37m","resolved_after":"4h 35m"},"date_kind":"incident","detection":null,"components":["network-control-plane","bgp"],"root_cause":"software-bug","remediation":[{"text":{"en":"Restarted the host VPC component on the affected nodes one node at a time","ko":"문제가 난 노드에서 구성 요소를 재시작하면 그 노드가 풀린다는 것을 찾고, 영향을 받은 모든 노드에서 구성 요소를 한 번에 한 노드씩 재시작하기 시작했다."}},{"text":{"en":"Restarted the host VPC component on the remaining nodes in parallel once the restart was known to fix the problem","ko":"17:57 UTC 에 구성 요소 재시작만으로 고쳐진다고 확신하고 병렬 재시작을 시작했다. 18:11 UTC 에 영향이 완전히 해소되었다."}}],"action_items":[{"text":{"en":"Fix the bug in the VPC host component itself","ko":"버그 자체를 바로잡는다."}},{"text":{"en":"Add an alert on a diverging number of routes","ko":"경로 수가 어긋나면 울리는 알림을 더한다."}},{"text":{"en":"Add an alert on the number of drops in the data plane","ko":"데이터 플레인의 패킷 drop 수를 보는 알림을 더한다."}},{"text":{"en":"Develop a way to reset endpoints without restarting the host VPC component","ko":"호스트 VPC 구성 요소를 재시작하지 않고도 엔드포인트를 초기화하는 방법을 만든다."}},{"text":{"en":"Move the VPC's persistent e2e test virtual machines to canary hosts","ko":"VPC 의 상시 e2e 테스트 가상 머신을 카나리 호스트로 옮긴다."}},{"text":{"en":"Add persistent e2e tests for Managed Services for Kubernetes","ko":"Managed Services for Kubernetes 용 상시 e2e 테스트를 더한다."}},{"text":{"en":"Run e2e tests more often","ko":"e2e 테스트를 더 자주 돌린다."}},{"text":{"en":"Add a deployment stage in which non-critical internal services receive updates first","ko":"중요하지 않은 내부 서비스가 가장 먼저 업데이트를 받는 배포 단계를 새로 둔다."}}],"contributing":["revert-did-not-restore","test-coverage-gap","monitoring-blind-spot"],"recurrence_of":null,"symptoms_text":{"en":"On 13 March 2025 practically every pod of Nebius Managed Services for Kubernetes in the eu-west1 region lost network connectivity for at least some time between 13:36 and 18:11 UTC. Packets for the affected IP alias routes were not processed by the data plane. The eu-north1 region was not affected.\n\nThe Nebius team became aware of the problem at 15:13 UTC, about an hour and a half after the canary deployment of a VPC release started. Rolling the release back at 15:30 UTC did not help, which was clear by 16:00 UTC. At 16:20 UTC the team tied the problem to IP aliases without yet understanding it, and at 16:41 UTC found that restarting the VPC host component on a problematic node fixed that node. Two technical metrics, the number of routes and the number of drops, reacted to the problem, but alerting on technical metrics deviating from their normal values was insufficient.","ko":"2025-03-13 eu-west1 리전에서 Managed Services for Kubernetes 고객의 파드가 거의 모두 13:36 에서 18:11 UTC 사이에 적어도 한동안 네트워크 연결을 잃었다. Nebius 팀은 15:13 UTC 에 문제를 알아챘다. eu-north1 리전은 영향을 받지 않았다.\n\n문제는 VPC 컨트롤 플레인 구성 요소의 릴리스와 함께 시작되었다. 13:36 UTC 에 eu-west1 카나리 배포를 시작했고, 14:35 UTC 에 리전의 나머지 노드 전체로 배포를 넓혔다. 영향을 받은 것은 Managed Kubernetes 파드의 연결뿐이었다.\n\n당직 엔지니어는 15:30 UTC 에 릴리스를 롤백했지만, 16:00 UTC 에 롤백이 듣지 않았다는 것이 분명해졌다. 16:20 UTC 에 팀은 문제가 IP alias 와 관련 있다는 것까지 밝혔지만 전체 그림은 아직 몰랐다. 16:41 UTC 에 팀은 문제가 난 노드에서 구성 요소를 손으로 재시작하면 그 노드의 문제가 풀린다는 것을 찾았다."},"updated_at":"2026-11-14T05:53:45.178353Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0233","org_slug":"nebius"}