Kubernetes 이그레스
Kubernetes 이그레스 (egress)
Kubernetes 이그레스는 파드가 클러스터 바깥으로 내보내는 연결을 다루는 주제예요. 이 문서는 이그레스 트래픽을 제한하는 방법, NAT outgoing의 동작 원리, 그리고 이그레스 게이트웨이의 역할까지 차근차근 설명해요. Calico 고유 기능보다는 Kubernetes 전반에 적용되는 배경 지식이니, 네트워크 구성을 설계하기 전에 개념을 잡는 데 활용하세요.
출처: 문서
본문
SECONDARY: 이 가이드는 Calico에 국한되지 않는 교육용 자료를 제공해요.
이 가이드에서 배울 내용:
- Kubernetes 이그레스란 무엇인가?
- 이그레스 트래픽을 제한해야 하는 이유와 방법은?
- "NAT outgoing"이란 무엇이고 언제 사용되나?
- 이그레스 게이트웨이란 무엇이고, 왜 사용하고 싶어질 수 있나?
Kubernetes 이그레스란 무엇인가?
이 가이드에서는 Kubernetes 이그레스라는 용어를, 파드가 클러스터 바깥의 무언가로 만드는 연결을 설명하는 데 사용해요.
Kubernetes에는 트래픽 관리를 돕는 Ingress 리소스 타입이 있는 인그레스 트래픽과 달리, Kubernetes Egress 리소스는 존재하지 않아요. 대신 이그레스 트래픽이 네트워킹 수준에서 어떻게 처리되는지는 클러스터가 사용하는 Kubernetes 네트워크 구현 / CNI 플러그인이 결정해요. 게다가 서비스 메시를 사용 중이라면, 네트워크 구현이 제공하는 동작 위에 이그레스 동작을 추가할 수도 있어요.
이그레스 트래픽에 대해 이해해 둘 만한 동작 영역은 세 가지예요. 이걸 알아야 자신의 필요에 가장 잘 맞는 네트워킹 및/또는 서비스 메시 구성을 고를 수 있어요:
- 이그레스 트래픽 제한
- 아웃고잉 NAT 동작
- 이그레스 게이트웨이
이그레스 트래픽 제한
클러스터에서 나가는 연결을 제한하는 것은 흔한 보안 요구 사항이자 모범 사례예요. 보통은 네트워크 정책으로 각 마이크로서비스의 이그레스 규칙을 정의하는 방식으로 이루어지고, default deny 정책을 함께 써서 특정 트래픽을 명시적으로 허용하는 정책을 정의하기 전까지는 아웃고잉 연결이 기본 거부되도록 하는 경우가 많아요.
Kubernetes Network Policy로 특정 외부 리소스 접근을 제한할 때 한 가지 한계는, 정책 규칙 안에 외부 리소스를 IP 주소(또는 IP 주소 범위)로 지정해야 한다는 점이에요. 외부 리소스와 연결된 IP 주소가 바뀌면, 그 IP를 참조하던 모든 정책을 새 IP로 업데이트해야 해요. 이 한계는 Calico의 정책에서 외부 IP 또는 네트워크 규칙 사용 기능이나, Calico Enterprise의 정책 규칙에서 도메인 이름 지원으로 우회할 수 있어요.
지금까지 말한 내용에 더해, 경계 방화벽(perimeter firewall)으로도 아웃고잉 연결을 제한할 수 있다는 점에 유의하세요. 예를 들어 특정 외부 IP 범위나 외부 서비스로만 연결을 허용하는 식이에요. 하지만 경계 방화벽은 보통 개별 파드를 구분할 수 없기 때문에, 규칙이 클러스터의 모든 파드에 똑같이 적용돼요. 이는 어느 정도의 다계층 방어(defense in depth)를 제공하지만, 네트워크 정책의 필요성을 대체할 수는 없어요.
NAT outgoing
네트워크 주소 변환(NAT)은 패킷이 NAT를 수행하는 장치를 통과할 때 패킷의 IP 주소를 다른 IP 주소로 매핑하는 과정이에요. 사용 사례에 따라 NAT는 소스 IP 주소, 목적지 IP 주소, 또는 둘 다에 적용될 수 있어요.
Kubernetes 이그레스 맥락에서 NAT는, 파드의 IP 주소가 클러스터 밖에서 라우팅 불가능할 때(예: 파드 네트워크가 오버레이인 경우) 파드가 클러스터 밖의 서비스에 연결할 수 있도록 하는 데 사용돼요.
예를 들어 오버레이 네트워크의 파드가 클러스터 밖의 IP 주소에 연결하려 하면, 파드를 호스팅하는 노드가 SNAT(Source Network Address Translation)를 사용해 패킷의 라우팅 불가능한 소스 IP를 노드의 IP 주소로 매핑한 뒤 패킷을 전달해요. 노드는 반대 방향으로 들어오는 응답 패킷을 다시 원래 파드 IP 주소로 매핑해서, 양방향으로 패킷이 엔드투엔드로 흐르고 파드나 외부 서비스 어느 쪽도 매핑이 일어나고 있다는 사실을 알지 못해요.
대부분의 클러스터에서는 이 NAT 동작이 클러스터 전체에 걸쳐 정적으로 설정돼요. Calico를 사용하면 IP 풀을 사용해 특정 주소 범위에 대해 더 세밀한 수준으로 NAT 동작을 설정할 수 있어요. 이렇게 하면 "클러스터 안 vs 클러스터 밖"보다 촘촘하게 "라우팅 불가능"의 범위를 정의할 수 있고, 일부 엔터프라이즈 배포 시나리오에서 유용해요.
이그레스 게이트웨이
Kubernetes 이그레스에 대한 또 다른 접근은 모든 아웃바운드 연결을 하나 이상의 이그레스 게이트웨이로 라우팅하는 거예요. 게이트웨이는 연결에 SNAT(Source Network Address Translation)를 적용해서, 연결되는 외부 서비스가 그 연결을 이그레스 게이트웨이에서 온 것으로 보게 해요. 주요 용도는 보안 강화로, 이그레스 게이트웨이가 허용할 연결을 직접 판단하는 보안 역할을 하거나, 경계 방화벽(또는 다른 외부 개체)과 함께 쓰일 수 있어요. 예를 들어 경계 방화벽이 파악할 수 없는 동적 파드 IP가 아니라 잘 알려진 IP 주소(이그레스 게이트웨이)에서 오는 연결로 보이도록 하는 식이에요.
이그레스 게이트웨이는 Kubernetes 자체의 네이티브 개념은 아니지만, 일부 Kubernetes 네트워크 구현과 일부 서비스 메시가 구현하고 있어요. 예를 들어 Calico는 이그레스 게이트웨이 기능을 제공하고, 네임스페이스(또는 개별 파드)를 특정 이그레스 게이트웨이에 매핑하는 기능도 제공해요. 그러면 경계 방화벽(또는 다른 외부 보안 개체)이 동적 파드 IP를 볼 수 없더라도 사실상 네임스페이스별 보안 제어를 제공할 수 있어요.
이그레스 게이트웨이의 대안으로, Calico를 사용하면 파드 IP 주소 범위를 네임스페이스별, 노드별, 심지어 개별 파드 수준에서 제어할 수 있어요. 아웃고잉 NAT가 필요 없다고 가정하면, 이 방식은 경계 방화벽(또는 다른 외부 보안 개체)이 인그레스와 이그레스 트래픽 모두에 대해 Kubernetes와 통합하는 아주 간단한 방법을 제공해요. (다만 이 접근은 IP 주소 범위를 합리적으로 할당할 수 있을 만큼 주소 공간이 충분해야 해요. 예를 들어 네임스페이스마다 하나씩 할당하는 식이에요. 그래서 대규모 배포에서는 IP 주소 범위 고갈 문제가 생길 수 있어요. 이런 시나리오에서는 이그레스 게이트웨이를 사용하는 쪽이 더 나은 선택일 가능성이 커요.)
추가 리소스
더 알아보기 (Learn more)
이그레스 설계를 마쳤다면, 네트워크 정책 문서로 default deny 구성을 이어서 살펴보는 걸 추천해요. IP 풀 문서를 보면 NAT outgoing을 주소 범위별로 세밀하게 제어하는 방법도 확인할 수 있어요.