IL-0161 Linode · 2024-04-22kubernetes
2024년 4월 22일 14:05 UTC 쯤 Linode 팀은 토론토 데이터센터에서 새 LKE 클러스터가 프로비저닝되지 않는 것을 발견했다. 새로 만든 클러스터에 노드 풀이 없거나 노드 수가 틀렸고, 고객은 Cloud Manager 에서 클러스터를 만든 뒤 타임아웃 오류를 받았다. 같은 날 17:32 UTC 에 팀은 문제를 토론토 데이터센터의 특정 인프라 구역으로 좁혔다.
4월 23일 15:03 UTC 에 문제가 된 인프라를 새 LKE 클러스터 프로비저닝에서 빼고 원인 조사를 이어 갔다. 조사해 보니 앞서 배포한 API 업데이트가 의도대로 동작하지 않아 새 클러스터를 프로비저닝할 때 타임아웃이 나고 있었다. 4월 25일 16:45 UTC 쯤 수정을 적용했고, 18:05 UTC 에 새 클러스터 생성이 완전히 돌아온 것을 확인했다. 수정 뒤 빼 두었던 인프라를 다시 넣었고, 4월 26일 17:09 UTC 에 장애를 해결로 닫았다.
2024년 4월 22일 14:05 UTC 쯤 토론토 데이터센터에서 새 LKE 클러스터가 프로비저닝되지 않았다.
고객이 Cloud Manager 에서 새 LKE 클러스터를 만들면 타임아웃이 났다. Cloud Manager 를 새로 고치면 클러스터는 만들어져 있었지만 노드 풀이 없었다. 노드 풀에 노드 수가 잘못 들어가거나 노드가 아예 없는 클러스터도 있었다.
오류는 토론토 데이터센터의 특정 백엔드 자원에서 훨씬 자주 났다. 다른 데이터센터에서도 나타났지만 빈도는 매우 낮았다.
2024년 4월 22일 14:05 UTC 쯤 Linode 팀이 토론토 데이터센터에서 새 LKE 클러스터가 프로비저닝되지 않는 것을 알아채고 조사를 시작했다.
–
원인은 오류가 드러난 인프라가 아니라 앞서 배포한 API 업데이트에 있었다. 그런데도 실패는 대부분 한 데이터센터의 백엔드 자원 하나에 몰렸다. 그 자원을 새 클러스터 프로비저닝에서 빼서, 근본 원인을 찾는 데 걸린 사흘 동안 고객 영향을 줄였다.
IL-0147 AKS 202508 노드 이미지가 캐시되지 않은 쿠버네티스 바이너리를 받을 때 HTTP 프록시 설정을 쓰지 않아, 프록시 뒤에 있는 노드의 프로비저닝이 CSE 종료 코드 31 로 실패했다.Microsoft · 2025같은 원인 · 공통 노드 풀
IL-0078 EKS 업그레이드 중 Terraform 으로 KMS 시크릿 암호화를 켜자 워커 노드의 IAM 권한이 빠져 운영 ZenML Pro 워크스페이스에 모두 접속할 수 없게 됐다ZenML · 2025같은 원인 · 공통 노드 풀
IL-0190 쿠버네티스 업그레이드로 etcd 리더가 있던 노드가 갑자기 종료된 뒤, Cortex distributor 두 개가 옛 리더와 맺은 TCP 연결이 멈춘 채 그 연결을 계속 써서 런던 리전 Hosted Prometheus 쓰기가 12분 동안 일부 실패했다.Grafana Labs · 2020같은 원인 · 공통 노드 풀
https://incidentlib-mcp.benchlet.com/mcpAPI 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.