iptables 1.8.4, K3s와 libvirtd를 함께 넘어뜨리다 — 워커 노드 부하 장애 원인 추적기

최근 돕고 있는 프로젝트에서 운영 중인 K3s 클러스터의 워커 노드에 CPU와 메모리 부하가 발생해 긴급 장애 대응을 진행한 적이 있다. 애당초 메모리가 16GB밖에 되지 않아 불안한 마음에 실서비스는 올리지 않도록 배치해둔 워커 노드였는데, 기어코 장애가 터졌다. 이런 상황을 사전에 예측해 실서비스를 올려두지 않은 게 그나마 다행이라면 다행이었달지. 어쨌거나 모니터링 경보가 계속 울려 긴급하게 장애 대응을 진행했다.

메모리 부하 증상 확인

           total   used   free   shared  buff/cache  available
Mem:       15Gi    14Gi   158Mi  3.0Mi   673Mi        499Mi

접속해서 free -h로 메모리 상태를 먼저 확인했다. 물리 메모리 부족으로 스와핑이 발생하는 상황이었고, 커널 자체도 눈에 띄게 느려져 있었다.

부하 원인 프로세스 특정

다음으로 ps aux --sort=-%mem으로 메모리 부하의 원인을 특정했다.

USER   PID      %CPU %MEM  VSZ      RSS     STAT START TIME  COMMAND
root   3352112  95.6 40.1  8097088  6497516 R    12:20 23:56  /usr/sbin/iptables -t filter -S FLANNEL-FWD 1 --wait
root   3352019  94.6 39.9  8440288  6472648 R    12:20 24:18  /usr/sbin/iptables -t filter -S KUBE-ROUTER-INPUT 1 --wait

3352112, 3352019 두 프로세스가 부하를 일으키는 주범이었다. flannel/kube-router가 관리하는 iptables 체인 규칙이 비대해지면서, 그냥 평범한 조회 명령어조차 부하를 일으키고 있었던 것이다. 커널 자체가 너무 느려진 상태라 우선 강제로라도 복구하는 게 급선무였고, 일단 프로세스 킬 명령어로 두 프로세스를 죽였다.

하지만 메모리는 일시적으로만 돌아왔을 뿐, 얼마 지나지 않아 부하가 다시 발생했다. 확인해보니 동일한 규칙이 재작성되며 다시 부하를 일으키고 있었다. 하는 수 없이 K3s 에이전트 프로세스 자체를 스탑시키는 방식으로 긴급 대응을 전환하고, 원인 분석에 들어갔다.

근본 원인: iptables 1.8.0-1.8.4 버그

분석 결과, K3s 공식 문서에서 원인의 실마리를 찾을 수 있었다.

iptables-k3s-libvirtd-2026-09-06_1

요약하자면 iptables 1.8.0~1.8.4 버전에 알려진 문제가 있어, 규칙 존재 여부를 확인하는 -c 옵션이 제대로 동작하지 않는다는 것이었다. 규칙을 추가하기 전에 -c 옵션으로 존재 여부를 확인하고, 없으면 추가하는 방식을 쓰는 모든 프로그램이 이 버그의 영향을 받는다.

그리고 이 버그가 K3s와 libvirtd 양쪽 모두에 영향을 준 것으로 추정된다. K3s의 경우 kube-proxy/network policy 컨트롤러가 flannel/kube-router 체인에 규칙을 추가·정리하는 과정에서, 같은 종류의 규칙이 중복 판정을 통과하지 못하고 계속 새로 추가되며 무한히 누적되는 구조였다.

K3s 조치: 내장 iptables로 전환

다행히 K3s도 이 문제를 도외시하지 않았는지, 아예 내장용 iptables를 하나 구비해두고 있었다. K3s가 iptables를 사용할 때 호스트의 iptables가 아니라 K3s 내장 iptables를 사용하도록 변경해 이 문제를 해결할 수 있었다.

sudo systemctl edit k3s-agent

[Service]
ExecStart=
ExecStart=/usr/local/bin/k3s agent --prefer-bundled-bin

sudo systemctl daemon-reload
sudo systemctl restart k3s-agent

libvirtd 조치: 누적된 INPUT 체인 정리

다만 이 조치만으로 현상이 완전히 해결되지는 않았다. 앞서 언급했듯 iptables 문제가 K3s뿐 아니라 libvirtd에도 영향을 주고 있었기 때문이다.

sudo iptables -t filter -S INPUT | sort | uniq -c | sort -rn | head -20

34286 -A INPUT -j LIBVIRT_INP
    1 -P INPUT ACCEPT

libvirtd의 INPUT 체인 규칙이 잔뜩 누적되어, 동일한 규칙이 무려 34286개나 들어가 있었다. 조금 이상했던 건, 서비스와 무관하며 평소 전혀 사용하지 않는 KVM/QEMU 가상화 데몬 libvirtd가 2주 전 사용된 기록이 남아 있었다는 점이다. 다만 이 히스토리를 더 추적하기는 어려웠다.

sudo iptables -F INPUT

이 문제는 위 명령어로 INPUT 체인의 중복 규칙을 정리해 해결했다. libvirtd는 애당초 필요 없는 서비스이고, 그 시점에도 Inactive 상태였기 때문에 그냥 disable시켜버렸다.

이러한 조치로 문제를 완전히 종결지었고, 일주일간 모니터링한 결과 재발하지 않는 것까지 확인을 마쳤다.