IL-0153 DigitalOcean · 2023-10-08kubernetesnetworking
DOKS 워커 노드가 쓰는 DigitalOcean Debian 이미지에는 모든 패키지를 올리는 systemd 타이머가 켜져 있었다. 이 타이머는 매일 06:00 UTC에 최대 60분의 무작위 지연을 두고 apt 업그레이드를 시작했다. DOKS 1.27.6-do.0 과 1.28.2-do.0 에서는 이 업그레이드가 systemd 와 커널을 비롯해 예상하지 못한, 지원하지 않는 버전의 구성 요소를 들여왔다. 특히 커널 업그레이드는 15분을 넘길 수 있었고, 그러면 systemd 가 업그레이드 프로세스를 강제로 끝냈다. 업그레이드가 중간에 끊기면 대부분 워커 노드의 공용 네트워크와 사설 네트워크가 모두 망가졌다.
10월 8일, 9일, 10일 아침마다 같은 장애가 났다. 망가진 노드에는 들어갈 수 없었고 워커 노드 접근은 보안상 제한되어 있어서 깊은 조사가 늦어졌다. 10월 10일 06:18에야 영향받은 노드에 붙어 실시간으로 디버깅할 수 있었고, 13:08에 자동 업그레이드 타이머를 찾았다. 테스트 클러스터에서 타이머를 손으로 돌려 보니 systemd 와 커널을 포함한 시스템 패키지를 올리는 긴 업그레이드가 시작됐다. 15분 타임아웃으로 업그레이드가 강제 종료되는 효과까지 완전히 검증하지는 못했지만, 팀은 이 타이머를 원인으로 판단했다.
팀은 각 워커 노드에서 이 타이머를 끄는 DaemonSet 을 만들어 10월 11일 03:08에 영향받은 모든 클러스터에 배포했다. 자동 업그레이드를 없앤 새 이미지도 내놓았다. 10월 11일 06:00 에서 07:00 사이에는 장애가 다시 일어나지 않았다.
2023년 10월 8일 06:00 UTC 무렵부터 일부 Managed Kubernetes 클러스터의 워커 노드가 NotReady 가 됐고, 그 노드에서 돌던 서비스와 애플리케이션이 멈췄다. 07:43부터 노드를 교체하면 해결되는 워커 노드 장애를 알리는 고객 보고가 드문드문 들어왔다.
같은 일이 10월 9일과 10일에도 06:00 에서 07:00 UTC 사이에 다시 일어났다. 10월 9일 06:31에는 여러 리전의 워커 노드로 넓게 번졌다. 노드는 교체하거나 재부팅할 때까지 쓸 수 없었고, 한 번으로는 회복되지 않아 여러 번 교체하거나 재부팅해야 한 경우도 있었다. 영향은 클러스터 버전 1.27.6-do.0 과 1.28.2-do.0 에 몰려 있었다.
망가진 노드는 공용 네트워크와 VPC 연결이 모두 끊겨 엔지니어가 로그인할 수도 없었다. 워커 노드 접근은 보안상 제한되어 있어서, 장애가 없는 시간에 SSH 와 콘솔 접근을 따로 마련해야 했다. 접속해 보니 노드의 프로세스는 VPC 와 공용 네트워크 어느 쪽으로도 연결하지 못했다. 응답 패킷은 머신까지 도착했지만 kubelet 과 워크로드 파드 같은 원래 프로세스로 전달되지 않았다.
처음에는 데이터 경로의 어느 구간이 끊겼는지 찾으려고 워커 노드와 하이퍼바이저에서 트레이스를 여러 번 떴다. 결과는 게스트 OS 수준에서 연결이 끊겼다는 것을 가리켰고, 데이터 경로는 원인 후보에서 빠졌다. 장애가 매일 같은 시각에 시작하고 두 버전에서만 난다는 점에서 노드에서 주기적으로 도는 프로세스를 의심했다. 크론잡은 원인이 아니었다.
증상 ? 노드 NotReady서비스 중단
10월 8일 07:43 UTC부터 노드 교체로 해결되는 워커 노드 장애를 알리는 고객 보고가 드문드문 들어왔다. 장애가 시작되고 약 1시간 43분 뒤였다. 내부 장애 대응은 영향이 여러 리전으로 번진 뒤인 10월 9일 07:10에 시작됐다.
베이스 이미지에 기본으로 켜진 자동 업그레이드 타이머가 운영 중인 노드에 지원하지 않는 패키지 버전을 들일 수 있다. 업그레이드 중 커널 같은 시스템 패키지가 타임아웃으로 강제 종료되면 노드 네트워킹이 망가질 수 있다. 네트워크가 끊긴 노드에 들어갈 방법이 없으면 깊은 조사는 장애가 없는 시간까지 밀린다. 매일 같은 시각에 반복되고 특정 버전에만 나는 장애는 노드에서 주기적으로 도는 작업을 가리켰다.
같은 원인 · 공통 kubelet
같은 원인 · 공통 kubelet