{"id":"IL-0087","org":"Fyra Labs","date":"2023-04-09","docs":[],"title":{"en":"After a cold reboot of RKE2 nodes, pods could not get IP addresses because Multus could not reach the Kubernetes API, and further reboots spread the failure to every node","ko":"RKE2 클러스터 노드를 재부팅한 뒤 Multus 가 쿠버네티스 API 에 닿지 못해 파드가 IP 를 받지 못했고, 같은 장애가 모든 노드로 번져 전체 서비스가 멈췄다."},"domain":["kubernetes","networking"],"impact":{"scope":"All services on the cluster, including the Terra repositories, Mastodon, Vault, Consul and the Grafana LGTM stack","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Rebooting nodes to clear one problem can expose another; here a CNI chain could not reach the API server after a cold start. Repeating the same reboot on more nodes while the first failure was not understood spread the outage from a few nodes to the whole cluster. The team also found that Cilium's real resource use in their cluster was acceptable, contrary to the benchmark they had relied on.","ko":"팀은 처음 장애를 저절로 풀릴 일시적인 문제로 보고 다른 노드까지 재부팅했는데, 이 판단은 완전히 틀렸고 장애가 모든 노드로 번졌다. 바꿔 넣은 Cilium 은 이 클러스터에서 Calico 보다도 잘 동작했다. 팀은 한 블로그 글의 자원 사용량 비교를 보고 Cilium 을 피했었지만, 실제로는 Calico, Canal, Flannel 과 마찬가지로 노드당 1코어라는 허용 범위 안에서 돌았다. 작은 클러스터에서는 Cilium 의 조금 더 큰 자원 사용량이 문제가 되지 않았다."},"related":[],"sources":[{"url":"https://blog.fyralabs.com/incident-report-full-networking-failure/","kind":"blog","license":"unknown","archived":null}],"summary":{"en":"Fyra Labs runs an RKE2 Kubernetes cluster with Multus, a meta-CNI (a CNI plugin that calls other network plugins), together with Calico, used to add extras such as bandwidth limits and network metering policies. Unusual CPU use on a node, presumed to be an upstream containerd and runc bug, led the team to cold-reboot the affected nodes. After the reboot Multus tried to set up IP addresses and virtual network interfaces again but could not reach the Kubernetes API, so the pods on those nodes got no IP address and failed.\n\nBelieving the failure was temporary, the team upgraded and cold-rebooted more nodes, and each one lost networking the same way until the whole cluster was isolated and all services were down. They uninstalled Multus and Calico completely and replaced them with the Cilium CNI, which RKE2 fully supports, then rolled back most other cluster settings. All services were back by 14:30 ICT. The write-up states that the cause is still unknown.\n\nThe team had earlier passed over Cilium because of its resource footprint in a published CNI comparison, but in their small cluster Cilium stayed within their threshold of one core per node, as Calico, Canal and Flannel had.","ko":"Fyra Labs 의 RKE2 클러스터에서 ICT 기준 2023-04-09 새벽 2시쯤 노드 하나가 평소와 다른 CPU 사용을 보였다. 팀은 containerd 와 runc 의 상위 프로젝트 CRI 버그로 추정했다. 이 노드가 다른 서비스를 스로틀링해 서비스가 실패하자, 팀은 시스템을 쓰는 사람이 없는 시간이라고 보고 클러스터를 정비 상태로 내린 뒤 영향받은 노드를 전부 재부팅했다.\n\n재부팅한 노드에서는 Multus 가 쿠버네티스 API 에 연결하지 못했다. 이 클러스터에서 Multus 는 모든 네트워킹의 주 CNI 인터페이스이고 그 위에 Calico 가 도는 구조였다. Multus 가 API 에 닿으려면 자기 프록시를 거쳐야 했는데 그 프록시도 뜨지 못했고, 파드는 IP 를 받지 못했다. 팀은 문제가 저절로 풀릴 것으로 여기고 다른 노드도 업그레이드하고 콜드 재부팅했는데, 같은 장애가 그 노드들로 번졌다. 모든 노드가 네트워크에서 고립됐고, 6시 31분에는 Terra 저장소까지 내려가 모든 서비스가 멈췄다.\n\n팀은 Multus 와 Calico 를 완전히 지우고 Cilium CNI 로 바꿨다. Cilium 은 RKE2 가 정식으로 지원하고, 오래된 네트워크 백엔드 대신 eBPF 를 쓴다. 14:30 ICT 까지 CNI 를 뺀 나머지 클러스터 설정 대부분을 되돌렸고 모든 서비스가 다시 올라왔다. Fyra Labs 는 근본 원인을 아직 모른다고 밝혔다."},"trigger":{"en":"A full cold reboot of the nodes that showed unusual CPU use, followed by upgrades and cold reboots of the other nodes.","ko":"평소와 다른 CPU 사용을 보인 노드를 바로잡으려고, 시스템을 쓰는 사람이 없는 시간이라고 보고 클러스터를 정비 상태로 내린 뒤 영향받은 노드를 전부 재부팅했다."},"severity":"unknown","symptoms":["node-high-cpu","service-unavailable"],"timeline":{"detected_after":null,"resolved_after":"12h 30m"},"date_kind":"incident","detection":{"en":"The team saw unusual CPU use on a node around 2 AM ICT and failing services on the rebooted nodes around 2:30 ICT; developers reported the Terra repositories down at 6:31 ICT.","ko":"새벽 2시쯤 노드 하나의 평소와 다른 CPU 사용을 발견했다. 재부팅 뒤 2시 30분쯤 일부 서비스에서 이상한 문제가 보여 네트워크 장애를 알아챘고, 6시 31분에는 개발자들이 Terra 저장소가 내려갔다고 알려 왔다."},"components":["multus","calico","container-runtime"],"root_cause":"unknown","remediation":[{"text":{"en":"uninstalled Multus and Calico and replaced them with the Cilium CNI","ko":"Multus 와 Calico 를 완전히 지우고 Cilium CNI 로 바꿨다."}},{"text":{"en":"rolled back most cluster settings except the CNI","ko":"14:30 ICT 까지 CNI 를 뺀 클러스터 설정 대부분을 되돌려 모든 서비스를 다시 올렸다."}}],"action_items":[],"contributing":["manual-action-worsened","assumption-unverified"],"recurrence_of":null,"symptoms_text":{"en":"At around 2 AM ICT on 2023-04-09 the team saw unusual CPU use on one cluster node, which throttled every other service on it and made them fail. They presumed an upstream container runtime bug in containerd and runc and decided to fully reboot the affected nodes, taking the cluster down for maintenance on the assumption that it was not in active use.\n\nAt around 2:30 ICT services on the rebooted nodes showed problems: the nodes could not connect to the service mesh, and no pod on them could get an IP address. Every service scheduled on those nodes failed to restart: HashiCorp Consul, HashiCorp Vault in high-availability mode on the Consul backend, the Grafana LGTM stack with Loki, Tempo and Mimir (which also use Consul), Mastodon, Traefik (partly), Terra (partly, with package uploads disabled), Subatomic, Madoguchi (a metadata service for Subatomic), KeyDB, PostgreSQL, the Hetzner Cloud CSI service and the JuiceFS CSI service.\n\nThe pods got no addresses because Multus, the meta-CNI the team ran together with Calico, could not contact the Kubernetes API through its own proxy, which had also failed to start. The log showed: \"Final result of CNI DEL was an error. error=error getting ClusterInformation: Get \"https://10.43.0.1:443/apis/crd.projectcalico.org/v1/clusterinformations/default\": dial tcp 10.43.0.1:443: i/o timeout\".\n\nThe team assumed the problem would clear by itself. Instead, system upgrades and cold reboots of other nodes, done in the hope of re-initialising the network, brought the same failure to those nodes until every node was cut off from the network. The Terra repositories still seemed up, so the team left them as they were; at 6:31 ICT developers reported that the Terra repositories had gone down, and the incident became a major one.","ko":"ICT 기준 2023-04-09 새벽 2시쯤 클러스터 노드 하나가 평소와 다른 CPU 사용을 보였다. 팀은 containerd 와 runc 의 상위 프로젝트에 있는 CRI 버그로 추정했다. 이 노드가 다른 서비스를 모두 스로틀링해 서비스가 실패하고 있었다.\n\n영향받은 노드를 재부팅한 뒤 2시 30분쯤, 그 노드가 서비스 메시와 연결을 맺지 못하는 것이 보였다. 그 때문에 노드의 모든 파드가 IP 주소를 받지 못하고 실패했다. 그 노드에 스케줄된 서비스는 하나도 다시 뜨지 못했다. 멈춘 서비스는 HashiCorp Consul, Consul 백엔드를 쓰는 고가용성 모드의 HashiCorp Vault, Consul 에 기대는 Grafana LGTM 스택의 Loki, Tempo, Mimir, Mastodon, Subatomic, Subatomic 의 메타데이터 마이크로서비스인 Madoguchi, KeyDB, PostgreSQL, Hetzner Cloud CSI, JuiceFS CSI 였다. Traefik 은 일부만 동작했고 Terra 는 패키지 업로드가 꺼진 채 일부만 동작했다.\n\n더 살펴보니 파드가 IP 를 받지 못한 원인은 Multus 였다. Multus 는 팀이 Calico 와 함께 쓰던 메타 CNI 로, 대역폭 제한과 추가 네트워크 계측 정책 같은 네트워크 플러그인을 더하려고 넣은 것이었다. Multus 는 쿠버네티스 API 에 연결하지 못했고, 로그에는 2023-04-08 21:56:16.577 [ERROR][206547] plugin.go 580: Final result of CNI DEL was an error. error=error getting ClusterInformation: Get \"https://10.43.0.1:443/apis/crd.projectcalico.org/v1/clusterinformations/default\": dial tcp 10.43.0.1:443: i/o timeout 오류가 남았다. Multus 는 콜드 재부팅 뒤 IP 와 가상 네트워크 인터페이스를 다시 할당하려 했지만, API 에 닿으려면 거쳐야 하는 자기 프록시도 뜨지 못했다.\n\n팀은 일시적인 문제라 저절로 풀릴 것이라고 생각했다. 다른 노드에서 시스템 업그레이드를 하고 콜드 재부팅을 하면 메시가 다시 초기화되기를 기대했지만, 그 노드들에도 같은 네트워크 장애가 나타났다. 결국 모든 노드가 자기 네트워크에서 고립돼 아무 연결도 맺지 못했다. Terra 저장소 같은 핵심 서비스는 아직 살아 있는 것처럼 보여서 문제를 더 살펴보려고 그대로 두었다. 6시 31분에 개발자들이 Terra 저장소가 내려갔다고 알려 왔고, 모든 서비스가 멈춘 큰 장애로 격상됐다."},"updated_at":"2026-11-09T11:55:42.396171Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0087","org_slug":"fyra-labs"}