사례12건

12건 중 5~9번째

1. IL-0156 인증서 교체 뒤 옛 인증서를 폐기하자 애틀랜타 LKE 의 클러스터 관리와 오토스케일링이 5xx 오류로 실패했다.

   Linode2025

   증상

   2025년 9월 24일 02:29 UTC 무렵부터 US-Southeast 애틀랜타의 LKE 오토스케일링이 영향을 받았고 고객은 클러스터를 관리할 수 없었다. 노드 풀 수정, 스케일링, 클러스터 생성과 삭제가 막혔다. 실행 중인 고객 워크로드는 영향을 받지 않았다.

   오류율 상승오토스케일러 오동작

   촉발

   9월 23일 클러스터 컨트롤러의 만료가 다가온 인증서를 교체한 뒤, 후속 작업으로 9월 24일 02:29 UTC 에 관련 컨트롤러의 옛 인증서를 폐기했다.

   원인

   인증서·자격 증명 만료

   구성 요소

   관리형 쿠버네티스 컨트롤 플레인과 제공자 API클러스터 오토스케일러

   기여 요인

   늦게 드러난 변경

   조치

   • 문제를 고치는 수정을 배포했다.
   • API 엔드포인트를 재시작했다.

   후속 조치

   • Akamai 전문가들이 근본 원인을 계속 조사하고 알맞은 예방 조치를 한다.

   사례 보기
2. IL-0162 데이터베이스 업데이트 뒤 LKE 내부 DNS 서비스가 멈춰 사용자가 LKE 클러스터 컨트롤 플레인과 LKE 대시보드에 접속하지 못했다

   Linode2025

   증상

   2025년 4월 1일 Linode Kubernetes Engine, 줄여서 LKE 의 사용자들이 자기 클러스터에 연결하지 못하기 시작했다. 외부에서 클러스터 컨트롤 플레인과 LKE 대시보드에 접근할 수 없었다.

   DNS 조회 실패컨트롤 플레인 무응답

   촉발

   앞서 진행한 데이터베이스 업데이트 때문에 LKE DNS 서비스가 멈췄다.

   원인

   의존성 장애

   구성 요소

   DNS 서버와 레코드애플리케이션 데이터베이스

   기여 요인

   –

   감지

   Linode 는 20시 28분 UTC 상태 페이지에 사용자가 클러스터 컨트롤 플레인에 연결하기 어려울 수 있다고 알리고 조사를 시작했다. 21시 33분 문제를 LKE 의 DNS 기능으로 좁혔고, 22시 29분 근본 원인을 찾았다.

   조치

   • 영향받은 LKE DNS 서비스를 재시작해 클러스터와 LKE 대시보드 접근을 되살렸다.

   후속 조치

   • DNS 서비스가 의존하는 시스템과 잠깐 연결이 끊겨도 스스로 회복하도록 개선한다.
   • 비슷한 문제를 더 빨리 찾도록 모니터링을 강화한다.
   • 서로 의존하는 시스템 사이의 변경을 더 잘 조율하도록 배포 절차를 고친다.

   교훈

   DNS 서비스가 의존하는 데이터베이스를 바꾸면 DNS 서비스가 멈출 수 있고, 그러면 클러스터 안은 멀쩡해도 사용자는 컨트롤 플레인에 닿지 못한다. Linode 는 DNS 서비스가 의존하는 시스템과 잠깐 연결이 끊겨도 회복할 수 있어야 하고, 서로 의존하는 시스템의 변경은 함께 조율해야 한다고 정리했다.

   사례 보기
3. IL-0157 IP ACL 을 켠 LKE 클러스터에 새 노드가 붙지 못해 오토스케일링이 실패했다

   Linode2025

   증상

   2025-03-05 01:00 UTC 무렵부터 일부 고객의 LKE 클러스터가 IP ACL 을 켠 상태에서 오토스케일링에 실패했고, 서비스 장애로 이어졌다.

   노드 증설 실패서비스 중단

   촉발

   가장 최근에 배포한 LKE 소프트웨어 릴리스에 결함이 있었다.

   원인

   소프트웨어 결함

   구성 요소

   클러스터 오토스케일러

   기여 요인

   –

   감지

   고객 쪽 문제는 01:00 UTC 무렵 시작됐고, 상태 페이지의 첫 조사 공지는 06:49 UTC 에 올라왔다.

   조치

   • 임시 조치로 게이트웨이 파드를 재시작했지만 잠깐만 효과가 있었다.
   • 문제가 된 소프트웨어 릴리스를 롤백했고, 15:00 UTC 무렵 영향받은 모든 클러스터에서 롤백을 마쳤다.

   후속 조치

   • 근본 원인을 계속 조사하고 알맞은 재발 방지 조치를 한다.

   교훈

   결함은 IP ACL 을 켠 클러스터에서만 문제를 일으켰고, autoscaler 가 노드를 추가하려 할 때 드러났다. 게이트웨이 파드 재시작은 효과가 오래가지 않았고, 릴리스를 롤백하자 장애가 끝났다.

   사례 보기
4. IL-0159 Docker Hub 의 남용 방지 장치가 Linode 의 IPv6 주소 대역에 레이트 리밋을 걸어 LKE 와 LKE-E 의 이미지 풀이 429 Too Many Requests 로 실패했다.

   Linode2025

   증상

   2025년 2월 5일 21:38 UTC 무렵부터 여러 리전에서 LKE, LKE-E, 그 밖에 Docker Hub 이미지 풀에 기대는 서비스들이 이미지를 받지 못했다.

   이미지 풀 실패

   촉발

   Docker Hub 가 남용 방지 조치로 Linode 의 IPv6 주소 대역에서 오는 이미지 풀에 레이트 리밋을 걸었다.

   원인

   의존성 장애

   구성 요소

   컨테이너 레지스트리와 자격 증명VPC DNS 리졸버

   기여 요인

   한계 미인지

   감지

   레이트 리밋은 21:38 UTC 무렵 시작됐고, 22:48 UTC 에 상태 페이지가 Docker Hub IPv6 문제를 조사 중이라고 처음 알렸다. 2월 6일 01:06 UTC 에는 Docker Hub 로 가는 IPv6 이미지 풀 요청에 레이트 리밋이 걸린 것을 원인으로 확인했다고 올렸다.

   조치

   • DNS 리졸버가 'AAAA' 레코드 대신 'A' 레코드로 응답하게 바꿔 Docker Hub 이미지 풀이 IPv4 로 나가게 했다.

   후속 조치

   • Docker Hub 의 남용 방지 조치에 서비스가 영향받지 않도록 장기 해법을 찾는다.

   교훈

   공용 레지스트리 하나에 기대는 이미지 풀은 그 레지스트리의 레이트 리밋 정책 하나로 한꺼번에 막힐 수 있다. 이번에는 Docker Hub 가 IPv6 주소를 앞 64비트로 판정하는 방식 때문에 Linode IPv6 대역의 이미지 풀이 막혔고, DNS 로 IPv4 를 쓰게 해 피해 갔다.

   사례 보기
5. IL-0161 앞선 API 업데이트가 의도대로 동작하지 않아 토론토 데이터센터에서 새 LKE 클러스터 프로비저닝이 타임아웃으로 사흘 넘게 실패했다.

   Linode2024

   증상

   2024년 4월 22일 14:05 UTC 쯤 토론토 데이터센터에서 새 LKE 클러스터가 프로비저닝되지 않았다.

   클러스터·노드 생성 정체간헐적 타임아웃

   촉발

   앞서 배포한 API 업데이트가 의도대로 동작하지 않았고, 새 LKE 클러스터를 프로비저닝할 때 타임아웃을 일으켰다.

   원인

   소프트웨어 결함

   구성 요소

   노드 풀

   기여 요인

   –

   감지

   2024년 4월 22일 14:05 UTC 쯤 Linode 팀이 토론토 데이터센터에서 새 LKE 클러스터가 프로비저닝되지 않는 것을 알아채고 조사를 시작했다.

   조치

   • 4월 23일 15:03 UTC 에 문제가 된 토론토 데이터센터의 인프라를 새 LKE 클러스터 프로비저닝에 쓰지 않도록 껐다.
   • 4월 25일 16:45 UTC 쯤 의도대로 동작하지 않던 API 업데이트를 바로잡는 수정을 적용했고, 18:05 UTC 에 새 클러스터 생성이 완전히 돌아온 것을 확인했다.
   • 수정을 적용한 뒤 잠시 빼 두었던 인프라를 다시 프로비저닝에 넣었다.

   교훈

   원인은 오류가 드러난 인프라가 아니라 앞서 배포한 API 업데이트에 있었다. 그런데도 실패는 대부분 한 데이터센터의 백엔드 자원 하나에 몰렸다. 그 자원을 새 클러스터 프로비저닝에서 빼서, 근본 원인을 찾는 데 걸린 사흘 동안 고객 영향을 줄였다.

   사례 보기

원인별5