iptables와 ipvs의 차이
iptables #
iptables는 리눅스 커널의 netfilter 프레임워크 위해서 동작하는 패킷 필터링, 방화벽 시스템이다.
말 그대로 패킷을 받아보고 규칙에 맞게 허용/차단/변경 하는 필터 기반 방화벽이다.
- L3/L4 중심 ip port protocol 기반
- Connecting tracking 기반 상태 추적 가능
- NAT, MASQUERADE 가능
- 단일 머신 방화벽/라우팅 조작 목적
ipvs #
ipvs는 리눅스 커널 LVS(Load Balancing) 기술의 일부로 L4 레벨에서 고성능 로드밸런싱을 제공하는 커널 모듈이다.
k8s에서도 kube-proxy가 iptables대신 ipvsㅁ 모드를 사용할때 등장한다.
- 고성능 L4 기반 로드밸런서
- 해시 기반 스케줄링(LC, WRR, SH, MH등 여러 알고리즘 제공)]
- connection table 최소화로 빠른 처리
- 대규모 트래픽 환경에서 iptables보다 훨신 효율적임
k8s iptables vs ipvs #
k8s kube-proxy 모드는 iptables ipvs 두 가지 모드를 지정할수 있다.
iptables #
- Service -> Pod 라우팅을 iptables 규칙 수천개로 구성한다.
- 규칙이 많아질수록 패킷 매칭 비용이 커진다
- 간단하지만 대규모 트래픽 성능 한계가 존재한다.
ipvs #
- iptables보다 빠르다 커널 해시 기반의 lookup이기 때문
- health check, connection handling 등 기능적 장점이 있다
- sService 수 / Pod 수가 많을때 성능이 압도적으로 우수하다.
그래서 공식문서에서도 ipvs를 대규모 클러스터 추천 모드로 권장중이다.
iptables와 connection tracking 구조적 문제 #
iptables는 netfilter의 conntrack을 사용한다.
신규 패킷이 생기면 conntrack 테이블을 조회하고 iptables rule을 체인해 순차 검색한다. 그러기에 규칙이 많으면 성능저하다.
규칙수에 비례해 선형적으로 나빠지는 문제가 있다.
ipvs에서 connection 구조는 ipvs는 iptables처럼 모든 connection conntracck에 심하게 의존하지 않고 아래 두 가지 테이블을 쓴다.
- Service Table
- Connection Table
그리고 이들은 모두 해시테이블 기반 구조다
여기서 contrack table은 패킷이 실제로 단일 조각이 아니라 ㅇ녀결 단위로 움직이기 때문에 필요한 테이블인데.
예를 들어 tcp는 syn syn ack ack data fin
udp는 client-request-response 관계
NAT는 클라이언트 - 서버 매핑등이걸 운영체제가 기억해둬야 나트도 되는거고 방화벽도 되는거다 그래서 커널은 다음을 저장해둔다. 이게 conntrack
(client_ip, client_port, protocol) <-> (server_ip, server_port) 리눅스에서 직접 확인도 가능하다 /proc/net/nf_conntrack 또는 /proc/net/ip_conntrack
IPVS connection 비용 최소화 방식 #
Hash Table 기반으로 Service(IP:port)를 key로 해 해시 테이블에 저장한다.
- key: VIP(ClusterIP), port, protocol
- value: backend list
패킷이 들어오면: O(1)시간에 Service -> Backend 매칭으로 iptables처럼 룰 체인을 다 순서대로 읽지 않는다.
Connection Entry 생성 방식도 다른데 ipvs는 특정 connection이 처음 들어왓을때만 connection entry를 생성한다 그리고 이후 패킷들은 conntrack을 통하지 않고 ipvs connection table에서 즉시 o(1) look up된다. 즉 필요한 연결만 저장하고 iptables처럼 전체를 건드리지 않는다.
udp등 비연결형 패킷은 엔트리를 거의 만들지 않으며 동작 방식 자첵가 nat가 아니라 DR, TUN등 여러 모드를 지원한다.
DR은 Direct Routing으로 요청은 LB -> Backend로 보내지만 응답은 LB를 안거치고 클라이언트로 직접 가는 방식
TUN은 터널링으로 요청을 LB -> Backend로 IPIP 터널링으로 보낸다. 이렇게되면 똑같이 응답은 바로 클라로 감 DR과 구조는 똑같지만 멀리 떨어진 서버에서도 사용할수있는 특징이 있음
| 구조 차이 | iptables | IPVS |
|---|---|---|
| 패킷 라우팅 방식 | 규칙 체인 순차 검사 | 해시 테이블 O(1) lookup |
| conntrack 의존성 | 높음 | 매우 낮음 |
| UDP connection 처리 | 긴 timeout, 테이블 증가 | 짧은 timeout 또는 무상태 처리 |
| NAT 방식 | 필연적 NAT | DR/TUN 등 NAT 회피 가능 |
| connection entry 개수 | 많은 편 | 필요한 경우만 생성 |
즉 iptables는 conntrack 에 의존성이 강하며 모든 패킷이 강제로 거치지만 ipvs는 그렇지 모든게 지나쳐야하지 않고 특히 dr tun은 지나치며 nat도 안한다. 그리고 해시 기반이라 lookup하는 속도도 개선되었고 여러모로 더 좋아졌다고 보면 된다.