{"id":"IL-0448","org":"Uzabase","date":"2026-07-28","docs":[],"title":{"en":"Requests from Uzabase's Kubernetes Job pods to an LLM agent randomly never got responses when they ran past 15 minutes","ko":"Job 파드가 15분 넘게 걸리는 LLM 에이전트 요청의 응답을 일정 확률로 받지 못하고 계속 기다렸다"},"domain":["kubernetes","networking"],"impact":{"scope":"Requests from Job pods to the LLM agent that took longer than about 15 minutes never received their responses","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Application engineers also need to know the network and infrastructure. As AI applications with long response times become common, a silent cut of a long request can come from a network setting such as the IPVS TCP timeout.","ko":"소프트웨어 엔지니어는 애플리케이션에만 관심을 두기 쉽지만 네트워크와 인프라 지식도 갖춰야 한다. AI 애플리케이션이 흔해지면서 응답까지 오래 걸리는 경우가 늘어날 것이므로, 원인을 알 수 없는 네트워크 오류가 나면 이 설정을 떠올릴 만하다."},"related":[],"sources":[{"url":"https://tech.uzabase.com/entry/2026/07/28/113158","kind":"blog","archived":null}],"summary":{"en":"The cluster runs kube-proxy in IPVS mode, and in the kube-proxy ConfigMap the IPVS TCP timeout was left at `tcpTimeout: 0s`, which means the default is used, and the default was 15 minutes. A TCP connection that sends and receives no packets for 15 minutes is removed from the IPVS connection table, which records which pod each connection is forwarded to. Neither the client nor the agent is told: no RST or FIN is sent, so both sides believe the connection is still open, the agent's response never reaches the client, and the client keeps waiting.\n\nThe team found this while investigating with Claude Code. It fixed the failure in the Python client by turning on TCP keepalive on the httpx transport (SO_KEEPALIVE 1, TCP_KEEPIDLE 60, TCP_KEEPINTVL 30, TCP_KEEPCNT 3, with a client timeout of 3600), so packets regularly cross the TCP connection and keep it alive.","ko":"Uzabase 의 Speeda 사업 Product Team 은 LLM 에이전트로 여러 공개 자료에서 기업의 경영 과제를 뽑아 목록으로 만든다. 품질을 높이려고 에이전트가 리뷰를 여러 번 되풀이하므로 응답까지 15분 넘게 걸리는 일이 많았다. 클라이언트인 Job 파드가 에이전트에 요청하면 일정 확률로 응답이 오지 않았다. 에이전트 로그에는 응답을 정상으로 보낸 기록이 있었다. 두 쪽 로그를 맞춰 보니 응답까지 대략 13분 넘게 걸린 요청이 실패하고 있었다.\n\n팀은 Claude Code 와 함께 조사하다 원인을 찾았다. 클러스터는 kube-proxy 의 IPVS 모드로 통신을 라우팅했다. ConfigMap 의 KubeProxyConfiguration 에서 IPVS 의 tcpTimeout 이 0s 로 남아 있어 기본값 15분이 쓰였다. 15분 넘게 패킷이 오가지 않은 TCP 커넥션은 IPVS 의 커넥션 관리 테이블에서 지워진다. 이 테이블은 어느 커넥션을 어느 파드로 보내는지 세션 단위로 기록해 둔다. 커넥션이 지워질 때 클라이언트와 에이전트에는 아무 알림이 없고 RST 도 FIN 도 가지 않는다. 두 쪽은 커넥션이 살아 있다고 여겼다. 에이전트가 보낸 응답은 클라이언트에 닿지 않았고, 클라이언트는 응답을 계속 기다렸다. 팀은 Python 으로 쓴 클라이언트에서 TCP keepalive 를 켜 커넥션을 유지하는 방법으로 해결했다."},"trigger":{"en":"LLM agent requests that took more than 15 minutes without packets on the TCP connection.","ko":"LLM 에이전트가 리뷰를 여러 번 되풀이해 응답에 15분 넘게 걸렸고, 그동안 TCP 커넥션에 패킷이 오가지 않았다."},"severity":"unknown","symptoms":["intermittent-timeouts"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"published","detection":{"en":"Client Job pods were not getting responses for some requests to the agent; the client log showed tasks that started but never finished until the 60-minute forced retry.","ko":"팀은 클라이언트 로그에서 Job 파드의 요청 일부에 응답이 돌아오지 않는 것을 확인했다."},"components":["kube-proxy"],"root_cause":"dns-network","remediation":[{"text":{"en":"Turned on TCP keepalive in the Python client so packets keep the connection alive","ko":"Python 으로 쓴 클라이언트에서 httpx 의 소켓 옵션으로 SO_KEEPALIVE 를 켜고 TCP_KEEPIDLE 60, TCP_KEEPINTVL 30, TCP_KEEPCNT 3 을 설정해, 커넥션 유지용 패킷을 주기적으로 보내게 했다."}}],"action_items":[],"contributing":["default-config-unchanged","limit-unknown"],"recurrence_of":null,"symptoms_text":{"en":"At Uzabase, a product team in the Speeda business uses an LLM agent to extract companies' management issues from public documents, and a client pod run as a Kubernetes Job sends the requests to the agent. The agent reviews its output many times, so a response often takes more than 15 minutes. Some share of the requests never got a response, with no clear pattern in which ones.\n\nThe client log showed that responses had not come back for some of the requests, which stayed unfinished until the forced retry the client runs after 60 minutes. The team first suspected that the agent had a problem with some requests, but the agent's log showed that it had returned its responses normally.\n\nComparing the client and agent logs showed that the requests that failed were the ones taking about 13 minutes or more to answer, so the team suspected a timeout somewhere on the network path inside Kubernetes.","ko":"클라이언트인 Job 파드가 LLM 에이전트에 경영 과제 추출을 요청하면 일정 확률로 응답이 돌아오지 않았다. 응답이 오지 않는 요청에 뚜렷한 규칙이 보이지 않아 조사가 초반에 막혔다.\n\n클라이언트 로그를 보면 일부 작업은 끝났다는 기록이 없는 채로 남아 있었다. 그 작업에는 60분이 지나자 클라이언트에 설정해 둔 강제 재시도가 걸렸다.\n\n팀은 처음에 에이전트 쪽에 문제가 생겨 일부 요청에 응답하지 않는다고 의심했다. 그러나 에이전트 로그에는 응답을 정상으로 보낸 기록이 있었다. 그래서 팀은 쿠버네티스 네트워크의 문제를 의심하고 조사를 이어 갔다.\n\n클라이언트와 에이전트의 로그를 맞춰 보니 응답까지 대략 13분 넘게 걸리는 요청이 실패하고 있었다. 팀은 네트워크 어딘가에서 타임아웃이 걸린다고 보고 조사했다."},"updated_at":"2026-11-14T12:34:09.725465Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0448","org_slug":"uzabase"}