{"id":"IL-0517","org":"Gitpod","date":"2022-01-25","docs":[],"title":{"en":"Gitpod workspaces failed to start worldwide and lost data when CoreDNS lookups to 8.8.8.8 timed out in its clusters","ko":"Gitpod 워크스페이스 클러스터의 CoreDNS 가 상위 DNS 서버에 닿지 못해 워크스페이스가 시작되지 않고 일부 데이터가 사라졌다"},"domain":["kubernetes","gcp","networking"],"impact":{"scope":"Workspaces could not be started, and running workspaces lost data","users":"unknown","region":"global"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://web.archive.org/web/20221206084830/https://www.gitpod.io/blog/no-way-it-is-dns","kind":"blog","archived":null}],"summary":{"en":"On 25 January 2022 Gitpod had a global outage of a little over an hour. The workspace clusters used Google's primary DNS server 8.8.8.8 to resolve public addresses, and the clusters could no longer reach it: UDP traffic on port 53 timed out. Image pulls from GCR failed, so workspaces could not start, and the workspace backup service could not resolve the address of the private GCS bucket that holds workspace content backups, so backups failed and workspaces that were already running lost data. User data in /workspace was kept on the individual nodes of the workspace clusters, so a node or cluster failure before a backup finished meant data loss.\n\nAs a precaution, and because cluster creation had recently been automated, the team started creating new workspace clusters in the EU and the US in the background through a werft job, which takes about 20 minutes. The new clusters were not affected, so traffic was redirected to them and workspaces started again. The old cluster recovered shortly after traffic left it, which the team took as a sign of some kind of load issue, but later tests on the old cluster could not reproduce the network failure.","ko":"2022년 1월 25일 Gitpod 에 전 세계 장애가 났다. 5.44pm UTC 쯤 Google Container Registry 에서 이미지를 받을 때 cannot get manifest 오류가 많이 났고, 약 10분 뒤 사용자들이 워크스페이스를 시작할 수 없다고 보고해 당번 팀이 장애 대응을 시작했다. 원인은 워크스페이스 클러스터 안의 DNS 장애였다. 클러스터는 공개 주소를 Google 의 기본 DNS 서버 8.8.8.8 로 풀었는데, 이 서버와 통신하지 못했고 UDP 53 트래픽이 통과하지 못해 타임아웃이 났다. CoreDNS 파드 로그에는 8.8.8.8:53 으로 가는 요청의 i/o timeout 이 쌓였다.\n\n워크스페이스 내용의 백업은 비공개 Google Cloud Storage 버킷에 올라간다. 백업 서비스가 DNS 장애로 GCS 주소를 풀지 못해 백업이 실패했고, 이미 돌던 워크스페이스의 데이터가 사라졌다. 사용자 데이터인 /workspace 는 워크스페이스 클러스터의 각 노드에 저장되므로, 백업이 끝나기 전에 노드나 클러스터가 실패하면 데이터를 잃는다.\n\n조사하는 동안 팀은 예방 조치로 werft 작업을 돌려 EU 와 US 에 새 워크스페이스 클러스터를 만들었다. 약 20분 걸려 준비된 새 클러스터에는 문제가 없었고, 트래픽을 새 클러스터로 돌리자 곧 워크스페이스가 시작됐다. 장애는 한 시간 남짓 이어졌다. 트래픽이 빠진 옛 클러스터는 곧 회복해 어떤 부하 문제로 보였지만, ARP 테이블과 conntrack 테이블은 정상이었다. 팀은 나중에 시간 압박 없이 재현해 보려 했으나 재현하지 못했다. Gitpod 는 유료 사용자에게 지난 석 달 치 환불을, 무료 사용자에게 unleashed 요금제 3개월 쿠폰을 제공했다."},"trigger":null,"severity":"unknown","symptoms":["image-pull-failures","dns-resolution-failures","service-unavailable","data-loss"],"timeline":{"detected_after":null,"resolved_after":"1h"},"date_kind":"incident","detection":{"en":"The team noticed a high error rate on image pulls from GCR at around 5.44pm UTC; about 10 minutes later users reported that workspaces would not start, and the on-call team started incident response.","ko":"5.44pm UTC 쯤 팀이 GCR 에서 이미지를 받을 때 cannot get manifest 오류율이 높아진 것을 알아챘다. 약 10분 뒤 사용자들이 워크스페이스를 시작할 수 없다고 보고했고, 당번 팀이 장애 대응을 시작했다."},"components":["coredns","registry","object-storage"],"root_cause":"dns-network","remediation":[{"text":{"en":"Created new workspace clusters in the EU and the US with a werft job","ko":"GCR 연결 문제를 조사하는 동안 예방 조치로 werft 작업을 돌려 EU 와 US 에 새 워크스페이스 클러스터를 만들기 시작했다. 만드는 데 약 20분 걸렸다."}},{"text":{"en":"Redirected traffic to the new clusters","ko":"새 클러스터에 문제가 없음을 확인하고 트래픽을 새 클러스터로 돌렸다. 곧 워크스페이스가 시작됐고 사용자들이 Discord 에서 시작된다고 알려 왔다."}}],"action_items":[{"text":{"en":"Keep workspace data on cloud provider persistent volumes that survive node and cluster failures","ko":"노드와 클러스터가 실패해도 남는 클라우드 사업자의 영구 볼륨에 사용자 데이터를 저장한다."}},{"text":{"en":"Let users download their files from a workspace that cannot be started","ko":"워크스페이스가 시작할 수 없는 상태가 되어도 사용자가 파일을 내려받을 수 있게 한다. 지금은 워크스페이스가 멈춰 있을 때만 내려받을 수 있다."}},{"text":{"en":"Improve the workspace backup process","ko":"백업 절차 개선을 우선으로 진행한다."}},{"text":{"en":"Use three DNS servers instead of one: a GCP-internal one, 8.8.8.8 and Cloudflare's 1.1.1.1","ko":"DNS 서버 하나에 기대지 않고 GCP 내부 DNS, Google 의 공개 DNS 8.8.8.8, Cloudflare 의 1.1.1.1 세 곳을 쓰도록 바꿨다. 하나에 문제가 나도 나머지에 연결할 수 있다."}},{"text":{"en":"Do more DNS resiliency work, tracked in an epic","ko":"DNS 복원력을 높이는 작업을 더 진행한다."}},{"text":{"en":"Improve support for multi-region clusters and later go multi-cloud","ko":"여러 리전의 클러스터 지원을 늘린다. 지금은 US 와 EU 두 곳뿐이고, 나중에는 여러 클라우드를 쓰는 것도 계획한다."}}],"contributing":["single-point-of-failure"],"recurrence_of":null,"symptoms_text":{"en":"At around 5.44pm UTC on 25 January 2022, Gitpod saw a high error rate when pulling images from Google Container Registry (gcr.io), with the error \"cannot get manifest\". About 10 minutes later users reported that they could not start workspaces.\n\nThe logs also showed \"dial tcp: i/o timeout failed to do request\" on image pulls, and the CoreDNS pods logged many DNS errors such as \"[ERROR] plugin/errors: 2 storage.googleapis.com. A: read udp 192.168.60.206:55169->8.8.8.8:53: i/o timeout\". Traffic on UDP port 53 to Google's public DNS server 8.8.8.8 seemed not to get through. Running workspaces lost data, because the backup service could not resolve the Google Cloud Storage address and their backups failed.\n\nGoogle's status page showed only a Service Usage API issue that did not look related, and checks of DNS and the status page showed no errors, so the team assumed the problem was on Gitpod's side; no recent changes had been made to the clusters. The ARP table was within normal limits and conntrack utilization was at about 10%.","ko":"5.44pm UTC 쯤 Google Container Registry 에서 이미지를 받을 때 cannot get manifest 오류가 많이 났다. 약 10분 뒤 사용자들이 워크스페이스를 시작할 수 없다고 보고했고, 이미 돌던 워크스페이스는 데이터를 잃었다.\n\n로그에는 이미지를 받으려다 난 dial tcp: i/o timeout failed to do request 오류도 있어서 GCR 과의 연결 문제로 보였다. 그 뒤 CoreDNS 파드에서 [ERROR] plugin/errors: 2 storage.googleapis.com. A: read udp 192.168.60.206:55169->8.8.8.8:53: i/o timeout 같은 DNS 오류가 많이 나온 것을 찾았다. UDP 53 포트로 가는 트래픽이 아예 통과하지 못하는 것처럼 보였다.\n\n팀은 먼저 Google 서비스 장애를 의심해 Google 상태 페이지를 봤다. 올라와 있던 것은 Service Usage API 가 \"available services\" 나 \"disabled services\" 목록 조회에서 오류율이 높다는 알림 하나뿐이었고, GCR 과 관계없어 보여 문제가 Gitpod 쪽에 있다고 판단했다. 다시 DNS 와 상태 페이지를 확인했지만 오류는 없었고, 클러스터에 최근 바꾼 것도 없었다.\n\nARP 테이블이 넘쳤는지 확인했지만 장애 전, 중, 후 모두 정상 범위였다. conntrack 테이블도 확인했지만 사용률은 약 10% 였다."},"updated_at":"2026-11-14T12:34:16.084937Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0517","org_slug":"gitpod"}