[k8s] EgressGateway과 NAT

공인 IP가 여러개인 환경에서 컨테이너의 아웃바운드 트래픽을 특정 IP로 고정하고 싶을 수 있다. 쉽게 말해서 NAT 패턴 말이다.
서드파티와의 신뢰관계를 위해서일 수도 있고, 크롤링 같은 어둠의 기술을 위해서일 수도 있지만 아무튼 중요한건 이런 필요성이 존재한다는 것이다.

쿠버에서 pod들이 바깥 인터넷과 통신할 때는, 따로 설정하지 않았다면 그냥 해당 노드의 기본 라우팅을 따라서 암묵적으로 처리가 된다. 하지만 서드파티 패키지들을 사용하면 이 Egress 통신 경로를 의도대로 조정할 수 있다.

사실 쿠버네티스 코어 자체는 이 Egress에 대한 표준 인터페이스란 것을 제공하지 않는다. 여기서 다루는 Egress는 서드파티들에서 암묵적으로 합의된 리소스 패턴을 말한다.

선택지

Egress Gateway 패턴을 지원하는 구현체로는 cillium, istio, antrea, calico(enterprise) 등이 있다.
calico는 지원을 하긴 하는데, 오픈소스 버전에서는 지원하지 않아서 한계가 있다.

istio는 L3/L4 NAT이 아니라 envoy로 통과시키는 L4/L7 메시 경로에 가까워서 NAT 사용패턴과 아주 잘 맞지는 않는다. 성능 손실도 있고, 애초에 이런 용도가 아니다.

그래서 이 중에서는 cillium을 가장 권장한다. 환경도 무르익었고, 성능이나 안정성도 가장 괜찮은 편에 속한다.
여기서도 cillium을 기준으로 설명한다.

동작 원리와 tradeoff 지점

Egress IP 치환은 보통 SNAT을 통해 동작한다.

Egress가 지정된 Pod에서 요청을 하나 날리면, cillium이 그 요청을 Egress Gateway로 넘긴다.
그러면 원하는 WAN IP의 Egress용 LAN IP로 SNAT 치환을 하고, 그 상태로 라우터로 나가는 것이다. 그러면 라우터가 거기에 매칭되는 WAN -> 공인IP로 바꿔서 내보내준다.

여기서 Egress Gateway는 특정 노드 하나를 고정해서 쓸 수도 있고, 2대 이상. 혹은 모든 워커노드를 게이트웨이로 사용하는 것도 가능하다. 근데 게이트웨이를 과도하게 구성하는 것도 운영부담이 크다. 노드마다 고유한 Egress LAN<>WAN 매핑을 구성하고, 각각의 LAN을 전부 스케줄링해가며 써야하기 때문이다.

그래서 일반적인 규모에서는 Egress Gateway를 2개 정도만 구성하는 것이 성능-가용성-운영 편의성 측면에서 괜찮은 편이다.

참조
https://kubernetes.io/ko/docs/concepts/services-networking/network-policies/
https://m.blog.naver.com/sssang97/224176429255
https://cilium.io/use-cases/egress-gateway/
https://istio.io/latest/docs/tasks/traffic-management/egress/egress-gateway/
https://tech.kakaopay.com/post/cilium-egress-gateway/