IL-0013 loveholidays · 2020-02-15 (게시일)kubernetesgcpnetworking

노드 RAM 을 절반으로 줄이자 conntrack 테이블이 가득 차 집계 서비스에 연결 리셋과 오류가 늘었다

conntrack 은 리눅스 커널이 네트워크 연결을 추적하는 기능이다. NAT 와 iptables 가 이 정보를 쓰고, 쿠버네티스 노드는 수많은 파드와 서비스 사이의 연결을 여기에 기록한다. 테이블 크기인 conntrack_max 는 노드 RAM 에 비례한다. loveholidays 가 GKE 노드에서 관찰해 보니 conntrack_max 는 메모리 1MB 당 대략 5였다.

loveholidays 의 집계 서비스는 각각 인스턴스가 100개 넘는 두 서비스 사이에서 프록시 역할을 한다. 평소 초당 10,000건 넘는 요청을 처리하고, 기본 부하의 네 배까지 치솟기도 한다. 노드 RAM 을 절반으로 줄이고 추적할 연결을 두 배로 늘리자 일부 노드의 conntrack 테이블이 바닥났고, 연결 문제와 연결 리셋 오류가 생겼다.

팀은 RAM 이 더 큰 노드에 애플리케이션을 배치하고 노드당 집계 서비스 파드 수를 제한해 당장의 문제를 풀었다. 쿠버네티스 1.15 이상에는 관련 수정이 들어 있을 것으로 보인다. init 컨테이너나 데몬셋에서 sysctl 로 conntrack_max 를 올리는 방법도 있다. 다만 이렇게 하면 애플리케이션이 인프라를 건드리게 되고, 여러 애플리케이션이 같은 값을 서로 덮어쓸 수 있으며, 노드 메모리 사용량과 지연도 늘 수 있다.

심각도: –
영향 범위: one aggregation service
영향 사용자: –
지역: –
감지까지: –
복구까지: –

증상

서비스 구조를 바꾸고 노드 풀 크기를 조정하고 하위 서비스를 샤딩한 직후, 집계 서비스에 여러 연결 문제가 생기고 오류율이 올라갔다.

애플리케이션에는 Caused by: org.apache.http.NoHttpResponseException: xxxxx failed to respond 오류가 찍혔다. HAProxy 가 보고하는 연결 리셋 오류는 계속 늘었다.

팀은 네트워크 지표를 살피다가 Prometheus 지표 node_nf_conntrack_entries 와 node_nf_conntrack_entries_limit 을 겹쳐 보았고, 일부 노드의 conntrack 테이블 공간이 바닥나고 있다는 것을 알았다. 사용률은 다음 쿼리로 봤다. (node_nf_conntrack_entries / on (pod) node_nf_conntrack_entries_limit / on (pod) group_right kube_pod_info) * 100

증상 연결 리셋 오류율 상승 간헐적 연결 실패

원인

원인 용량 한계

구성 요소 conntrack 테이블 kube-proxy 노드 풀 HAProxy

감지

팀은 먼저 서비스의 연결 문제와 오류율 상승을 알아챘다. HAProxy 가 보고하는 연결 리셋 오류가 계속 늘었고, 팀은 node_nf_conntrack_entries 를 node_nf_conntrack_entries_limit 과 겹쳐 보고 일부 노드의 conntrack 테이블이 바닥난 것을 확인했다.

조치

집계 서비스를 RAM 이 더 큰 노드에 배치했다.
노드 하나에 뜨는 집계 서비스 파드 수를 제한했다.

후속 조치

conntrack 사용률이 75% 를 넘으면 경보가 가도록 Prometheus 쿼리 (node_nf_conntrack_entries / on (pod) node_nf_conntrack_entries_limit / on (pod) group_right kube_pod_info) > 0.75 로 경보 규칙을 만들었다.

교훈

쿠버네티스 노드의 conntrack_max 는 노드 RAM 에 비례해 정해진다. 부하가 큰 애플리케이션은 특히 작은 노드에서 conntrack_max 를 쉽게 넘겨 연결 리셋과 타임아웃을 일으킨다. 노드를 작게 바꾸면 추적할 수 있는 연결 수도 함께 줄어든다. conntrack 사용률은 지표로 보고 경보를 걸어 둬야 한다.

출처

https://deploy.live/blog/kubernetes-networking-problems-due-to-the-conntrack/ · blog · 보관본

참고 문서

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: conntrack 테이블, kube-proxy, 노드 풀. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

이 사례의 JSON: https://incidentlib-api.benchlet.com/cases/IL-0013
가장 비슷한 사례들: https://incidentlib-api.benchlet.com/cases/IL-0013/similar
MCP 서버(Streamable HTTP, 키 없음): https://incidentlib-mcp.benchlet.com/mcp

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.

증상

원인

감지

조치

후속 조치

교훈

출처

참고 문서

관련 사례

내 클러스터에도 있는지 확인하기

AI 도구와 스크립트용