Cases2 cases

1 to 2 of 2

1. IL-0448 Requests from Uzabase's Kubernetes Job pods to an LLM agent randomly never got responses when they ran past 15 minutes

   Uzabase2026

   Symptoms

   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.

   Intermittent timeouts

   Trigger

   LLM agent requests that took more than 15 minutes without packets on the TCP connection.

   Root cause

   DNS or network fault

   Component

   kube-proxy

   Contributing factor

   Unreviewed defaultsUnknown limit

   Detection

   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.

   Remediation

   • Turned on TCP keepalive in the Python client so packets keep the connection alive

   Lessons

   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.

   View case
2. IL-0445 Chatwork's service on EKS became unstable as conntrack tables on some nodes overflowed and connections were dropped

   Chatwork2021

   Symptoms

   In 2020 Chatwork moved its legacy system from EC2 to EKS, running both sides in parallel with Route53 weighted records. Once more than a certain share of requests was sent to the EKS side, the service suddenly became unstable. On some nodes the conntrack table had gone past its limit and connections to the application were being dropped.

   Intermittent connection failuresDNS resolution failuresIntermittent timeoutsLoad imbalance

   Trigger

   During the migration from EC2 to EKS, Chatwork sent more than a certain share of requests to the EKS side. Later, applying node-local-dns with force_tcp in its configuration made DNS unstable again.

   Root cause

   Capacity exhaustion

   Component

   conntrack tableCoreDNSkube-proxyClient-side DNS resolver and cacheVPC DNS resolver

   Contributing factor

   Unreviewed defaultsUnrepresentative stagingUnknown limit

   Remediation

   • Raised the conntrack maxPerCore value in the kube-proxy configuration
   • Installed dns-autoscaler so CoreDNS ran with more pods
   • Installed node-local-dns as a DaemonSet on every node
   • Replaced force_tcp with prefer_udp in the node-local-dns configuration

   Lessons

   On EKS, dns-autoscaler and node-local-dns made DNS stable, but node-local-dns must not use force_tcp there. Stable DNS also matters for sizing the number of pods correctly, since blocked DNS queries had made the pod count grow.

   View case

By root cause2