{"id":"IL-0051","org":"thredUP","date":"2018-10-23","docs":[],"title":{"en":"A third-party log shipping client leaked file descriptors with every new container until nodes failed with too many open files","ko":"외부 업체의 로그 클라이언트가 새 컨테이너가 뜰 때마다 파일 디스크립터를 다시 열고 이전 것을 닫지 않아 쿠버네티스 노드가 too many open files 로 내려갔다"},"domain":["kubernetes","aws","observability"],"impact":{"scope":"Kubernetes nodes running the log client; services on those nodes went down","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Libraries and agents that worked with the EC2 deployment lifecycle may not cope with Kubernetes, where containers start, stop and move between nodes constantly. Each one needs to be checked against the new lifecycle instead of being trusted because it worked before.","ko":"EC2 에서 믿고 쓰던 서비스와 라이브러리가 쿠버네티스에서도 똑같이 잘 동작한다고 가정하면 안 된다. 그런 도구는 배포 방식과 수명 주기가 다른 환경을 전제로 만들어졌을 수 있다. 쿠버네티스에서는 배포할 때마다 컨테이너가 생기고 사라지고 노드 사이를 옮겨 다니므로, 쓰는 서비스마다 이런 수명 주기에 맞게 만들어졌는지 의심하고 확인해야 한다."},"related":[],"sources":[{"url":"https://www.youtube.com/watch?v=tA8Sr3Nsx1I","kind":"talk","license":"unknown","archived":null}],"summary":{"en":"thredUP is an online consignment store for women's and children's clothes. Over about a year it moved a stack of roughly 30 to 40 services from EC2 to Kubernetes on AWS, run with kops, Terraform, Ansible, Jenkins, Helm and HAProxy. In a 2018 conference talk the CTO describes the problems found along the way; this case is the open files problem.\n\nAn infrastructure engineer worked with the vendor of a third-party log aggregation service whose log client sent the logs to the provider. Every container's log file needed a file descriptor in the client. When a new container started, the client opened a descriptor for the new log file and also opened new descriptors for the log files of the containers already running, leaving the old ones open. With three containers on a node, a fourth container left the first three containers' descriptors open twice. Because Kubernetes adds, removes and moves containers all the time, descriptors piled up, and on nodes with many containers each new one made the count jump.\n\nRaising the settings the team found only delayed the failure. The vendor fixed the bug, and thredUP later moved away from that vendor. In the Q&A an infrastructure engineer confirmed the problem was in the application, not in Kubernetes tuning: the log client of the third-party provider was not ready for Kubernetes.","ko":"thredUP 의 공동 창업자이자 CTO 인 Chris Homer 가 1년 동안 전체 스택을 쿠버네티스로 옮기며 배운 것을 소개한 발표에 나온 장애다. thredUP 은 AWS 에서 kops 로 쿠버네티스를 운영했고, 서비스 수는 30개에서 40개 정도였다.\n\n마이그레이션 도중 노드의 열린 파일 수가 계속 늘었다. 팀은 관련 설정 값을 올렸지만 잠시 버틸 뿐이었고, 결국 노드가 터져 서비스가 내려갔다. 노드를 죽이고 새 노드를 띄워 다시 배포하면 복구는 됐다.\n\n엔지니어 Alex 가 외부 업체와 함께 원인을 파고들었다. 발표자는 업체가 이 문제를 이미 고쳤다는 이유로 업체 이름을 밝히지 않았다. 로그 파일을 쓰는 컨테이너가 세 개 떠 있으면 로그 파일마다 파일 디스크립터가 하나씩 있다. 새 컨테이너가 뜨면 이 클라이언트는 새 로그 파일의 디스크립터를 만들 뿐 아니라 기존 세 파일의 디스크립터도 다시 만들었고, 이전 세 개는 열어 둔 채로 두었다. 쿠버네티스에서는 배포할 때마다 컨테이너가 생기고 사라지며 노드 사이를 옮겨 다니므로, 컨테이너가 많은 노드일수록 열린 파일 수가 빠르게 쌓였다. 팀은 업체와 함께 문제를 다뤘고 결국 그 업체의 서비스를 쓰지 않게 됐다."},"trigger":{"en":"Containers starting on a node, which in Kubernetes happens constantly with every deploy and every pod that moves between nodes.","ko":"로그 파일을 쓰는 컨테이너가 여럿 떠 있는 노드에 새 컨테이너가 뜰 때마다, 외부 업체의 로그 클라이언트가 기존 로그 파일의 파일 디스크립터까지 새로 열고 이전 디스크립터를 닫지 않았다."},"severity":"unknown","symptoms":["service-unavailable","file-descriptor-exhaustion"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"published","detection":{"en":"Datadog showed the number of open files on the nodes rising.","ko":"Datadog 에서 노드의 열린 파일 수가 계속 오르는 것을 보고 알았다."},"components":["telemetry-agent"],"root_cause":"software-bug","remediation":[{"text":{"en":"killed the affected node, brought up a new one and redeployed","ko":"문제가 난 노드를 죽이고 새 노드를 띄운 뒤 서비스를 다시 배포해 복구했다."}}],"action_items":[{"text":{"en":"Move away from the log aggregation vendor","ko":"업체와 함께 문제를 다뤘고, 결국 그 로그 수집 업체의 서비스를 쓰지 않게 됐다."}}],"contributing":["assumption-unverified"],"recurrence_of":null,"symptoms_text":{"en":"While thredUP's move to Kubernetes seemed to be going well, Datadog showed the number of open files on the nodes climbing steadily, with no obvious reason.\n\nThe team searched for the cause, found some settings they could change, and raised them. That held for a while, and then the problem came back and caused downtime. Killing the node, bringing up a new one and redeploying restored service, but the underlying cause was still there.\n\nThe rise was steepest on busy nodes: once a node held many containers, starting one more container made the open file count jump sharply.","ko":"쿠버네티스 마이그레이션이 순조로워 보이던 중 Datadog 에서 노드의 열린 파일 수가 계속 늘어나는 것이 보였다.\n\n팀은 검색해서 찾은 관련 설정 값을 올렸다. 한동안은 괜찮아 보였지만 결국 노드가 터지면서 서비스가 내려갔다. 노드를 죽이고 새 노드를 띄운 뒤 다시 배포하면 복구됐지만, 근본 원인은 그대로 남아 있었다.\n\n노드에 컨테이너가 많이 올라간 상태에서 컨테이너가 하나 더 뜨면 열린 파일 수가 급격히 치솟았다. 시간이 오래 지날수록 문제가 커졌다."},"updated_at":"2026-11-10T00:00:38.790806Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0051","org_slug":"thredup"}