{"id":"IL-0153","org":"DigitalOcean","date":"2023-10-08","docs":[],"title":{"en":"DOKS worker nodes went NotReady at 06:00 UTC on three days because a systemd timer in the Debian image ran apt upgrade and killed it mid kernel upgrade, breaking node networking","ko":"DOKS 1.27.6-do.0 과 1.28.2-do.0 워커 노드에서 매일 아침 도는 apt 자동 업그레이드가 15분 타임아웃에 걸려 강제 종료되면서 노드 네트워킹이 망가지고, 노드가 사흘 연속 NotReady 가 됐다."},"domain":["kubernetes","networking"],"impact":{"scope":"Worker nodes NotReady with no network connectivity, disrupting services on them, until replaced or rebooted; recurred on three consecutive days","users":"DOKS customers on cluster versions 1.27.6-do.0 and 1.28.2-do.0","region":"AMS3, BLR1, FRA1, LON1, NYC1, NYC3, SFO2, SFO3, SGP1, SYD1, TOR1"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"An operating system auto-update timer left enabled in a node image can change the kernel and systemd underneath Kubernetes, and a timeout that kills the upgrade half-way can leave a node without networking. Failures that start at the same time every day point to a scheduled job on the nodes, and systemd timers belong on that list next to cron jobs.\n\nWhen the failure takes out a node's network, an investigation that depends on logging into the node stalls; access paths that work while the node is broken shorten diagnosis.","ko":"베이스 이미지에 기본으로 켜진 자동 업그레이드 타이머가 운영 중인 노드에 지원하지 않는 패키지 버전을 들일 수 있다. 업그레이드 중 커널 같은 시스템 패키지가 타임아웃으로 강제 종료되면 노드 네트워킹이 망가질 수 있다. 네트워크가 끊긴 노드에 들어갈 방법이 없으면 깊은 조사는 장애가 없는 시간까지 밀린다. 매일 같은 시각에 반복되고 특정 버전에만 나는 장애는 노드에서 주기적으로 도는 작업을 가리켰다."},"related":[],"sources":[{"url":"https://status.digitalocean.com/incidents/fsfsv9fj43w7","kind":"official-status","license":"unknown","archived":null}],"summary":{"en":"The Debian image used for DOKS worker nodes on cluster versions 1.27.6-do.0 and 1.28.2-do.0 had a systemd timer enabled that ran an apt upgrade of all packages every day at 06:00 UTC plus up to 60 minutes. The upgrade pulled in unsupported versions of system-critical packages, including systemd and the kernel. The kernel upgrade could take longer than 15 minutes, and systemd then aborted the upgrade ungracefully, which in most cases left the node's public and private networking broken. The node went NotReady and stayed that way until it was replaced or rebooted.\n\nThe incident repeated on October 8, 9 and 10, 2023, across the AMS3, BLR1, FRA1, LON1, NYC1, NYC3, SFO2, SFO3, SGP1, SYD1 and TOR1 regions. Investigation was slow because the affected nodes had no working network and engineers' access to worker nodes is restricted. After cron jobs were ruled out, the team found the timer on October 10 at 13:08 UTC, ran it by hand on a test cluster, and saw a long upgrade of systemd and the kernel begin; the effect of the 15-minute timeout could not be fully validated, but the evidence was judged sufficient. A DaemonSet that disables the timer on every worker node was released to all affected clusters on October 11 at 03:08 UTC, and no failures occurred at 06:00 UTC that day.","ko":"DOKS 워커 노드가 쓰는 DigitalOcean Debian 이미지에는 모든 패키지를 올리는 systemd 타이머가 켜져 있었다. 이 타이머는 매일 06:00 UTC에 최대 60분의 무작위 지연을 두고 apt 업그레이드를 시작했다. DOKS 1.27.6-do.0 과 1.28.2-do.0 에서는 이 업그레이드가 systemd 와 커널을 비롯해 예상하지 못한, 지원하지 않는 버전의 구성 요소를 들여왔다. 특히 커널 업그레이드는 15분을 넘길 수 있었고, 그러면 systemd 가 업그레이드 프로세스를 강제로 끝냈다. 업그레이드가 중간에 끊기면 대부분 워커 노드의 공용 네트워크와 사설 네트워크가 모두 망가졌다.\n\n10월 8일, 9일, 10일 아침마다 같은 장애가 났다. 망가진 노드에는 들어갈 수 없었고 워커 노드 접근은 보안상 제한되어 있어서 깊은 조사가 늦어졌다. 10월 10일 06:18에야 영향받은 노드에 붙어 실시간으로 디버깅할 수 있었고, 13:08에 자동 업그레이드 타이머를 찾았다. 테스트 클러스터에서 타이머를 손으로 돌려 보니 systemd 와 커널을 포함한 시스템 패키지를 올리는 긴 업그레이드가 시작됐다. 15분 타임아웃으로 업그레이드가 강제 종료되는 효과까지 완전히 검증하지는 못했지만, 팀은 이 타이머를 원인으로 판단했다.\n\n팀은 각 워커 노드에서 이 타이머를 끄는 DaemonSet 을 만들어 10월 11일 03:08에 영향받은 모든 클러스터에 배포했다. 자동 업그레이드를 없앤 새 이미지도 내놓았다. 10월 11일 06:00 에서 07:00 사이에는 장애가 다시 일어나지 않았다."},"trigger":{"en":"A systemd timer in the DigitalOcean Debian image started apt upgrade daily at 06:00 UTC, with a random delay of up to 60 minutes.","ko":"DigitalOcean Debian 이미지의 systemd 타이머가 매일 06:00 UTC에 최대 60분의 무작위 지연을 두고 apt 업그레이드를 시작했다."},"severity":"unknown","symptoms":["node-not-ready","service-unavailable"],"timeline":{"detected_after":"1h 43m","resolved_after":"2d 21h"},"date_kind":"incident","detection":{"en":"Sporadic customer reports of failed worker nodes arrived at 07:43 UTC on October 8; internal incident response started at 07:10 UTC on October 9 after broader impact across regions.","ko":"10월 8일 07:43 UTC부터 노드 교체로 해결되는 워커 노드 장애를 알리는 고객 보고가 드문드문 들어왔다. 장애가 시작되고 약 1시간 43분 뒤였다. 내부 장애 대응은 영향이 여러 리전으로 번진 뒤인 10월 9일 07:10에 시작됐다."},"components":["node-image","linux-kernel","kubelet"],"root_cause":"config-change","remediation":[{"text":{"en":"Advised customers to replace or reboot affected worker nodes","ko":"고객에게 영향받은 머신을 교체하거나 재부팅해 장애를 줄이라고 안내했다."}},{"text":{"en":"Arranged SSH and console access to worker nodes while they were healthy, and live-debugged an affected node on October 10","ko":"장애가 없는 동안 워커 노드에 SSH 와 콘솔 접근을 마련했고, 10월 10일 영향받은 노드에 붙어 실시간으로 디버깅했다."}},{"text":{"en":"Released a DaemonSet to all affected clusters that disables the apt upgrade systemd timer on every worker node","ko":"각 워커 노드에서 apt 업그레이드 systemd 타이머를 끄는 DaemonSet 을 만들어 10월 11일 03:08 UTC에 영향받은 모든 클러스터에 배포했다."}},{"text":{"en":"Released new node images without the auto-update process","ko":"자동 업그레이드 과정을 없앤 새 노드 이미지를 배포했다."}}],"action_items":[{"text":{"en":"Disable the timer during node provisioning, then remove the DaemonSet from all clusters","ko":"노드 프로비저닝 과정에서 같은 수정을 적용해 워커 노드에 타이머가 처음부터 켜지지 않게 한다. 그 뒤 모든 클러스터에서 DaemonSet 을 지운다."}},{"text":{"en":"Add a check to the internal conformance test suite for new cluster versions that the auto-upgrade process and other unwanted timers stay disabled","ko":"새 클러스터 버전마다 도는 내부 적합성 테스트에 자동 업그레이드와 원하지 않는 다른 타이머가 꺼져 있는지 확인하는 검사를 넣었다."}},{"text":{"en":"Support logging into worker nodes even when normal access paths are broken","ko":"평소 쓰는 접근 경로가 막혀도 워커 노드 머신에 로그인할 수 있게 한다."}}],"contributing":["default-config-unchanged","limited-debug-access","delayed-effect-change"],"recurrence_of":null,"symptoms_text":{"en":"Customers of DigitalOcean Managed Kubernetes (DOKS) saw worker nodes go NotReady between 06:00 and 07:00 UTC and stay unavailable, taking down the services on them, until the nodes were replaced or rebooted; some nodes needed several replacements or reboots. The first sporadic reports on October 8 said replacing the node fixed it. The same thing happened again around 06:00 UTC on October 9, more widely and across many regions, and again on October 10. Only clusters on versions 1.27.6-do.0 and 1.28.2-do.0 were affected.\n\nOn an affected node, processes could not reach anything over either the VPC or the public network. Traces across the worker nodes and their hypervisors showed reply packets arriving at the machine but never reaching the processes that had sent the requests, including kubelet and workload pods, so the network data path was ruled out and the fault was placed in the guest operating system.\n\nThe broken networking also kept engineers out. DOKS worker nodes allow DigitalOcean engineers only limited access for security reasons, so SSH and console access had to be arranged while the nodes were healthy, and live debugging on an affected node was possible only on the third occurrence. Many clusters appeared to heal on their own or were fixed by customers rebooting nodes, and attempts to reproduce the failure failed until the daily 06:00 UTC pattern pointed at a scheduled job on the nodes.","ko":"2023년 10월 8일 06:00 UTC 무렵부터 일부 Managed Kubernetes 클러스터의 워커 노드가 NotReady 가 됐고, 그 노드에서 돌던 서비스와 애플리케이션이 멈췄다. 07:43부터 노드를 교체하면 해결되는 워커 노드 장애를 알리는 고객 보고가 드문드문 들어왔다.\n\n같은 일이 10월 9일과 10일에도 06:00 에서 07:00 UTC 사이에 다시 일어났다. 10월 9일 06:31에는 여러 리전의 워커 노드로 넓게 번졌다. 노드는 교체하거나 재부팅할 때까지 쓸 수 없었고, 한 번으로는 회복되지 않아 여러 번 교체하거나 재부팅해야 한 경우도 있었다. 영향은 클러스터 버전 1.27.6-do.0 과 1.28.2-do.0 에 몰려 있었다.\n\n망가진 노드는 공용 네트워크와 VPC 연결이 모두 끊겨 엔지니어가 로그인할 수도 없었다. 워커 노드 접근은 보안상 제한되어 있어서, 장애가 없는 시간에 SSH 와 콘솔 접근을 따로 마련해야 했다. 접속해 보니 노드의 프로세스는 VPC 와 공용 네트워크 어느 쪽으로도 연결하지 못했다. 응답 패킷은 머신까지 도착했지만 kubelet 과 워크로드 파드 같은 원래 프로세스로 전달되지 않았다.\n\n처음에는 데이터 경로의 어느 구간이 끊겼는지 찾으려고 워커 노드와 하이퍼바이저에서 트레이스를 여러 번 떴다. 결과는 게스트 OS 수준에서 연결이 끊겼다는 것을 가리켰고, 데이터 경로는 원인 후보에서 빠졌다. 장애가 매일 같은 시각에 시작하고 두 버전에서만 난다는 점에서 노드에서 주기적으로 도는 프로세스를 의심했다. 크론잡은 원인이 아니었다."},"updated_at":"2026-11-10T00:00:36.375058Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0153","org_slug":"digitalocean"}