{"id":"IL-0237","org":"Lucidworks","date":"2026-05-28","docs":[],"title":{"en":"A Kubernetes patch upgrade evicted every Ray Serve head and worker pod at once, and Lucidworks hosted LLMs went down","ko":"us-southcarolina 리전에서 Lucidworks AI 의 호스팅 LLM 이 약 1시간 반 동안 500 과 429 오류를 내며 멈췄다"},"domain":["kubernetes","ai-infra"],"impact":{"scope":"Hosted LLM inference for llama-3-8b-instruct, llama-3v2-3b-instruct and phi-4-multimodal-instruct returned 500 or 429 errors; search, embedding models, the Platform UI and passthrough LLM calls were not affected","users":"Customers using Lucidworks AI hosted LLM inference","region":"us-southcarolina"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://status.lucidworks.com/incidents/160cww6nznwy","kind":"official-status","archived":"https://web.archive.org/web/20260611070249/https://status.lucidworks.com/incidents/160cww6nznwy"}],"summary":{"en":"Lucidworks AI serves its hosted models with Ray Serve, which routes inference requests through head and worker nodes. A Ray cluster normally survives a head restart because the workers keep serving. The node pool upgrades used a surge strategy that waits only for a pod to leave the old node, not for it to run on the new one: a drain counted as successful once the pod was gone, even if the pod was still stuck in \"Initializing\" on its new node, and the upgrade moved straight on to the next pool. All node pools were therefore cycled in rapid succession, every head and worker pod was evicted before any replacement had finished initializing, and the whole Ray cluster went down at 16:18 UTC. Lucidworks Engineering declared a Sev1 incident at 16:54 UTC.\n\nRecovery took longer for three reasons. A replacement head node was degraded and could not pull images, and had to be deleted by hand. The 6-11 GB LLM images transferred abnormally slowly, in 30-52 minutes instead of 2-4. And a separate operation was bringing new models online at the same time, so the Ray operator's blue-green deployment strategy required both the existing and the replacement LLM deployments to be healthy before switching traffic, which meant waiting for the slow image pulls on both. The team deleted the degraded node, waited for the image pulls on the replacement nodes, redirected traffic to the new nodes and confirmed that every hosted model answered queries. All hosted models were working at 17:53 UTC, and the incident was verified as resolved at 18:07 UTC.","ko":"2026-05-28 16:18 UTC 에서 17:53 UTC 사이에 us-southcarolina 리전의 Lucidworks AI 호스팅 LLM 을 쓸 수 없었다. llama-3-8b-instruct, llama-3v2-3b-instruct, phi-4-multimodal-instruct 로 추론하던 고객은 500 이나 429 오류를 받았다. 검색, 임베딩 모델, Platform UI 는 영향을 받지 않았다. Lucidworks Engineering 은 16:54 UTC 에 Sev1 장애를 선언했다. 장애 중 상태 페이지는 노드 업그레이드 동안 클라우드 사업자의 용량 부족으로 인스턴스가 다시 뜨지 못했다고 알렸다.\n\nLucidworks 는 호스팅 모델을 Ray Serve 로 서빙하며, 추론 요청을 보내는 데 head 노드와 worker 노드를 쓴다. 평소에는 head 노드가 재시작되어도 worker 노드가 요청을 계속 처리한다. 그런데 정기 쿠버네티스 패치 업그레이드가 노드 풀을 교체하면서 모든 head 노드와 worker 노드가 한꺼번에 재시작되었다. 노드 풀 업그레이드의 surge 방식은 파드가 옛 노드에서 쫓겨나기만 기다리고 새 노드에서 실행되기까지는 기다리지 않았다. 새 노드에서 파드가 Initializing 에 머물러 있어도 drain 을 성공으로 보고 다음 노드로 넘어갔다. 그래서 노드 풀이 빠르게 연달아 교체되었다. head 파드와 worker 파드는 교체 노드에서 초기화를 마치기 전에 모두 쫓겨났고, 클러스터 전체가 멈췄다.\n\n복구는 여러 요인으로 늦어졌다. 교체된 head 노드 하나는 상태가 나빠 컨테이너 이미지를 받지 못했고, 팀은 이 노드를 손으로 지워야 했다. 6~11 GB 인 LLM 컨테이너 이미지를 받는 데 평소에는 2~4분이 걸렸지만 이때는 30~52분이 걸렸다. 팀은 별도 작업으로 새 모델을 올리던 중이었다. Ray operator 의 blue-green 배포 방식은 기존 배포와 새 배포가 모두 정상이 되어야 트래픽을 넘겼다. 그래서 blue 와 green 양쪽에서 느린 이미지 받기가 끝날 때까지 장애가 이어졌다. 팀은 상태가 나쁜 노드를 지우고, 교체 노드에서 이미지 받기가 끝나기를 기다린 뒤, 새 노드로 트래픽을 돌렸다. 17:53 UTC 에 모든 호스팅 모델이 복구되었고 18:07 UTC 에 해결을 확인했다."},"trigger":{"en":"A routine Kubernetes patch upgrade on a cluster in us-southcarolina cycled its node pools one after another in quick succession.","ko":"us-southcarolina 리전 클러스터의 정기 쿠버네티스 패치 업그레이드가 노드 풀을 차례로 교체했다. surge 방식의 노드 풀 업그레이드는 파드가 옛 노드에서 쫓겨나기만 하면 다음 노드로 넘어갔다. 그래서 Ray Serve 의 head 파드와 worker 파드가 새 노드에서 뜨기 전에 모두 쫓겨났다."},"severity":"sev1","symptoms":["service-unavailable","pods-evicted","image-pull-failures"],"timeline":{"detected_after":null,"resolved_after":"1h 35m"},"date_kind":"incident","detection":null,"components":["node-pool","inference-server"],"root_cause":"deploy-rollout","remediation":[{"text":{"en":"Deleted the degraded replacement head node that could not pull container images","ko":"상태가 나빠 컨테이너 이미지를 받지 못하던 교체 head 노드를 손으로 지웠다."}},{"text":{"en":"Waited for the LLM image pulls to finish on the replacement nodes","ko":"교체 노드에서 LLM 이미지 받기가 끝나기를 기다렸고, 모든 호스팅 모델이 질의에 응답하는 것을 확인했다."}},{"text":{"en":"Launched new nodes with the required LLM images and redirected Lucidworks AI traffic to them","ko":"필요한 LLM 이미지가 든 새 노드를 띄우고 Lucidworks AI 트래픽을 그 노드로 돌렸다. 예측 엔드포인트의 200 응답으로 안정을 확인했다."}}],"action_items":[{"text":{"en":"Upgrade clusters that host LLM workloads in sequence, with each node pool fully healthy before the next one is upgraded","ko":"LLM 워크로드를 돌리는 클러스터의 쿠버네티스 업그레이드를 순서대로 진행해, 한 노드 풀이 완전히 정상이 된 뒤에 다음 노드 풀을 올리게 한다."}},{"text":{"en":"Investigate image pre-loading, such as pre-baked disks or image streaming, for large ML model images","ko":"큰 ML 모델 이미지를 받는 데 오래 걸리지 않도록 이미지를 노드에 미리 올려 두는 방법을 조사한다. 후보는 디스크 이미지에 컨테이너 이미지를 미리 넣어 두는 방법과 이미지 스트리밍이다."}},{"text":{"en":"Open a support ticket with the cloud provider about the abnormal Docker pull times","ko":"비정상적으로 느린 Docker 이미지 받기를 조사하도록 클라우드 사업자에게 지원 티켓을 연다."}},{"text":{"en":"Coordinate Kubernetes maintenance windows with LLM service owners so they do not clash with ongoing deployments","ko":"진행 중인 배포와 겹치지 않도록 쿠버네티스 유지 보수 시간을 LLM 서비스 담당자와 맞추는 알림 절차를 만든다."}},{"text":{"en":"Build tooling to force a Ray cluster failover to the blue or green state instead of waiting for Ray to settle it","ko":"Ray 가 새 배포와 옛 배포를 스스로 정리하기를 기다리지 않고 Lucidworks Engineering 이 blue 나 green 으로 강제 전환할 수 있도록 Ray 클러스터 도구를 개선한다."}}],"contributing":["no-staged-rollout","overlapping-failures"],"recurrence_of":null,"symptoms_text":{"en":"From 16:18 UTC on 28 May 2026 the Lucidworks AI hosted LLMs in the us-southcarolina region were unavailable: queries to llama-3-8b-instruct, llama-3v2-3b-instruct and phi-4-multimodal-instruct returned 500 or 429 errors. Search, embedding models, the Lucidworks Platform UI and passthrough LLM calls kept working.\n\nThe outage began during a routine Kubernetes patch upgrade that cycled the node pools, and the head and worker pods of the Ray Serve deployment were evicted before any of them had finished initializing on the new nodes. One replacement head node was degraded and could not pull container images. The LLM container images, 6-11 GB each, took 30-52 minutes to transfer instead of the usual 2-4 minutes.\n\nWhile the incident was open the status page attributed it to a cloud provider capacity shortfall that kept the instances hosting the models from launching again, and said the needed capacity had been secured; the postmortem gives the upgrade's node pool cycling as the cause.","ko":"2026-05-28 16:18 UTC 부터 us-southcarolina 리전에서 Lucidworks AI 가 호스팅하는 LLM 인 llama-3-8b-instruct, llama-3v2-3b-instruct, phi-4-multimodal-instruct 에 보낸 질의가 500 이나 429 오류로 실패했다. 검색, 임베딩 모델, Lucidworks Platform UI, passthrough LLM 호출은 정상이었다.\n\n이 모델에 기대는 서비스를 쓰는 최종 사용자도 오류를 겪었다. Lucidworks Engineering 은 16:54 UTC 에 Sev1 장애를 선언했고, 17:14 UTC 에 상태 페이지에 첫 공지를 올렸다.\n\n이때 팀은 정기 쿠버네티스 유지 보수로 노드를 업그레이드하던 중이었다. 17:39 UTC 공지는 클라우드 사업자의 용량 부족으로 모델을 돌리는 인스턴스가 다시 뜨지 못했다고 설명했다. 팀은 필요한 용량을 확보했지만 모델이 다시 올라오는 것이 여전히 늦어 클라우드 사업자에게 도움을 요청했다.\n\n교체 노드에서 모델이 늦게 떴다. 교체된 head 노드 하나는 상태가 나빠 컨테이너 이미지를 받지 못했다. 6~11 GB 인 LLM 컨테이너 이미지를 받는 데 평소에는 2~4분이 걸렸지만 이때는 30~52분이 걸렸다."},"updated_at":"2026-11-14T05:53:45.632766Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0237","org_slug":"lucidworks"}