이그레스 NAT 게이트웨이 구성

이 문서에서는 Google Distributed Cloud용 이그레스 NAT 게이트웨이를 설정하는 방법을 설명합니다. 이 게이트웨이는 클러스터에서 이그레스 트래픽에 영구적이고 확정적인 SNAT IP 주소를 제공합니다. 클러스터 외부에 이그레스 사용자 트래픽이 있는 워크로드를 실행할 때 고객은 몇 가지 확정적인 IP 주소를 사용하여 이 트래픽을 식별하려고 합니다. 이를 통해 고객이 허용 목록 정책과 같은 IP 기반 보안 측정을 설정할 수 있습니다.

이 페이지는 조직의 네트워크를 계획 및 설계하고 네트워크 장비를 설치, 구성, 지원하는 네트워킹 전문가를 대상으로 합니다. Google Cloud 콘텐츠에서 참조하는 일반적인 역할과 예시 태스크에 대한 자세한 내용은 일반 GKE Enterprise 사용자 역할 및 태스크를 참조하세요.

이그레스 NAT 게이트웨이는 2개의 커스텀 리소스를 사용하여 사용 설정됩니다. 제공된 네임스페이스에 대해 NetworkGatewayGroup 커스텀 리소스는 게이트웨이로 작동하도록 선택된 노드의 네트워크 인터페이스에 구성할 수 있는 유동 IP 주소를 지정합니다. EgressNatPolicy 커스텀 리소스를 사용하면 이그레스 게이트웨이에서 트래픽을 제어하는 이그레스 라우팅 정책을 지정할 수 있습니다.

이그레스 NAT 게이트웨이를 설정하지 않거나 이그레스 트래픽이 트래픽 선택 규칙을 충족하지 않으면 지정된 Pod에서 클러스터 외부의 대상으로의 이그레스 트래픽이 Pod가 실행되는 노드의 IP 주소로 매스커레이드됩니다. 이 시나리오에서는 특정 Pod의 모든 이그레스 트래픽이 동일한 소스 IP 주소를 갖거나 동일한 노드 IP 주소로 매스커레이드된다고 보장하지 않습니다.

이그레스 NAT 게이트웨이는 Dataplane V2 위에 빌드된 고급 네트워킹 제품입니다.

참고: 노드가 Ubuntu 18.04를 실행하는 경우 Linux 커널은 버전 5.4 이상이어야 합니다. 자세한 내용은 Ubuntu 구성을 참조하세요.

이그레스 NAT 게이트웨이 작동 방법

이그레스 트래픽 선택 논리는 CIDR 블록 표기법의 대상 IP 주소 범위 집합, Pod 선택기, 네임스페이스 선택기를 기반으로 합니다. 이그레스 NAT 게이트웨이 작동 방법을 보려면 Pod에서 외부 소비자로의 패킷 흐름 및 해당 응답을 고려하세요. 노드 서브넷에 192.168.1.0/24 CIDR 블록의 IP 주소가 있다고 가정하세요.

다음 다이어그램은 게이트웨이 노드를 통해 이그레스 트래픽의 네트워크 아키텍처를 보여줍니다.

이그레스 NAT 게이트웨이를 통한 패킷 흐름은 다음과 같습니다.

1. 이그레스 트래픽은 IP 주소가 192.168.1.1인 노드에서 IP 주소가 10.10.10.1인 Pod로부터 생성됩니다.

   트래픽의 대상 주소는 클러스터 외부의 엔드포인트입니다.

2. 트래픽이 이그레스 규칙과 일치하면 eBPF 프로그램이 노드 IP 주소로 직접 매스커레이드하는 대신 게이트웨이 노드로 이그레스 트래픽을 라우팅합니다.

3. 게이트웨이 노드가 이그레스 트래픽을 수신합니다.

4. 게이트웨이 노드는 EgressNATPolicy 커스텀 리소스에 지정된 소스 이그레스 IP 주소 192.168.1.100을 사용하여 원래 트래픽의 소스 IP 주소 10.10.10.1을 매스커레이드합니다.

5. 반환 트래픽은 192.168.1.100을 대상으로 사용하여 게이트웨이 노드로 돌아옵니다.

6. 게이트웨이 노드는 반환 트래픽의 conntrack을 원본 이그레스 트래픽의 conntrack과 일치하는지 확인하고 대상 IP 주소를 10.10.10.1로 다시 작성합니다.

7. 10.10.10.1은 원본 노드로 라우팅되는 클러스터 내 트래픽으로 취급되고 원본 포드로 다시 전달됩니다.

노드 트래픽의 유동 IP 주소 구성

네트워크 게이트웨이 그룹 커스텀 리소스는 Google Distributed Cloud의 번들 구성요소입니다. 리소스는 클러스터의 노드에서 이그레스 트래픽에 사용할 유동 IP 주소 목록 하나 이상의 목록을 관리합니다. 노드 참가는 지정된 네임스페이스로 결정됩니다. 네트워크 게이트웨이 그룹은 가장 효과적인 방식으로 유동 IP 주소를 항상 제공합니다. 유동 IP 주소를 사용하는 노드가 중지되면 고급 네트워크 운영자가 할당된 IP 주소를 사용 가능한 다음 노드로 이동합니다. 이 IP 주소를 사용하는 모든 워크로드 이그레스 트래픽도 함께 이동합니다.

새 1.30.100-gke.96 클러스터를 만들 때 클러스터 구성 파일에 네트워크 게이트웨이 그룹 세부정보(주석 및 사양)를 포함합니다.

NetworkGatewayGroup 커스텀 리소스 만들기

다음 예시와 같이 클러스터를 만들 때 클러스터 구성 파일에서 spec.clusterNetwork.advancedNetworking 필드를 true로 설정하여 네트워크 게이트웨이 그룹을 사용 설정합니다.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  clusterNetwork:
    ...
    advancedNetworking: true
    ...

NetworkGatewayGroup 커스텀 리소스를 만들 때 해당 네임스페이스를 클러스터 네임스페이스로 설정하고 다음 예시에 표시된 것처럼 유동 IP 주소 목록을 지정합니다.

참고: 클러스터 운영자는 kube-system 네임스페이스에 NetworkGatewayGroup 커스텀 리소스의 복사본을 만듭니다. 이 kube-system 네임스페이스의 NetworkGatewayGroup 커스텀 리소스 복사본에서 고급 네트워킹 운영자가 사용하는 유동 IP 주소를 정의해야 합니다.

kind: NetworkGatewayGroup
apiVersion: networking.gke.io/v1
metadata:
  namespace: cluster-cluster1
  name: default
spec:
  floatingIPs:
  - 192.168.1.100
  - 192.168.1.101
  - 192.168.1.102

참고: 이그레스 NAT 게이트웨이에서는 고가용성(HA) 구성을 지원하지 않습니다. 유동 IP 주소를 처리하는 네트워크 게이트웨이 노드가 중지되거나 연결 문제가 있으면 이그레스 트래픽이 단시간 동안 중단될 수 있습니다. 고급 네트워킹 운영자는 이그레스 트래픽이 복원되도록 유동 IP 주소를 새 노드에 자동으로 다시 할당합니다.

고급 네트워킹 운영자는 다음 기준에 따라 유동 IP를 노드에 할당합니다.

• 노드 서브넷: 유동 IP 주소가 노드의 서브넷과 일치해야 합니다.
• 노드 역할(제어 영역, 작업자): 워커 노드는 유동 IP 주소를 할당할 때 제어 영역 노드보다 우선 적용됩니다.
• 노드에 유동 IP 주소가 있는지 여부: 운영자는 유동 IP가 아직 할당되지 않은 노드에 할당을 우선 적용합니다.

주소/노드 매핑은 NetworkGatewayGroup 객체를 가져올 때 status 섹션에서 찾을 수 있습니다. NetworkGatewayGroup 객체는 kube-system 네임스페이스에 있습니다. 게이트웨이 노드가 다운되면 고급 네트워크 운영자는 유동 IP 주소를 사용 가능한 다음 노드에 할당합니다.

게이트웨이 구성 확인

게이트웨이 구성 변경사항을 적용한 후 kubectl을 사용하여 게이트웨이 상태를 확인하고 게이트웨이에 대해 지정된 유동 IP 주소를 검색할 수 있습니다.

1. 다음 명령어를 사용하여 NetworkGatewayGroup의 상태를 확인하고 유동 IP 주소가 할당되는 방법을 확인하세요.

   kubectl -n kube-system get networkgatewaygroups.networking.gke.io default -o yaml

   worker1 및 worker2의 2개 노드가 있는 클러스터에 대한 응답은 다음과 같습니다.

   kind: NetworkGatewayGroup
   apiVersion: networking.gke.io/v1
   metadata:
     namespace: kube-system
     name: default
   spec:
     floatingIPs:
     - 192.168.1.100
     - 192.168.1.101
     - 192.168.1.102
   status:
     nodes:
       worker1: Up
       worker2: Up // Or Down
     floatingIPs:
       192.168.1.100: worker1
       192.168.1.101: worker2
       192.168.1.102: worker1
   

트래픽 선택 규칙 설정

EgressNATPolicy 커스텀 리소스는 트래픽 선택 규칙을 지정하고 클러스터를 나가는 이그레스 트래픽에 대해 확정적인 IP 주소를 할당합니다. 커스텀 리소스를 지정할 때 egress(최소 하나 이상의 규칙 포함), destinationCIDRs, egressSourceIP는 모두 필수입니다.

참고: 다른 EgressNATPolicy 객체에 이미 사용되는 egressSourceIP 주소를 지정하는 트래픽 선택 규칙을 설정할 수 있습니다. 이렇게 하면 이그레스 트래픽 라우팅이 충돌합니다. 개발팀과 협력하여 EgressNATPolicy 커스텀 리소스에 egressSourceIP 주소를 지정하기 전에 사용 가능한 유동 IP 주소를 결정합니다.

kubectl apply를 사용하여 EgressNATPolicy 커스텀 리소스를 만듭니다. 다음 섹션에서는 사양 정의에 대한 세부정보 및 예시를 보여줍니다.

이그레스 라우팅 규칙 지정

EgressNatPolicy 커스텀 리소스를 사용하면 이그레스 트래픽에 대해 다음 규칙을 지정할 수 있습니다.

• egress 섹션에서 이그레스 트래픽 선택 규칙을 하나 이상 지정해야 합니다.

  • 각 규칙은 podSelector 및 namespaceSelector로 구성됩니다.
  • 선택은 네임스페이스 라벨 namespaceSelector.matchLabels.user 및 Pod 라벨 podSelector.matchLabels.role을 기반으로 합니다.
  • Pod가 규칙 중 하나와 일치하면(일치에 OR 관계 사용) 이그레스 트래픽용으로 선택됩니다.

• destinationCIDRs 섹션에서 허용된 대상 주소를 지정합니다.

  • destinationCIDRs는 CIDR 블록 목록을 가져옵니다.
  • Pod에서 나가는 트래픽에 지정된 CIDR 블록 범위에 포함되는 대상 IP 주소가 있으면 이그레스 트래픽용으로 선택됩니다.

다음 예시에서 다음 기준이 충족되었을 때 Pod의 이그레스 트래픽이 허용됩니다.

• Pod 라벨이 role: frontend로 지정되었습니다.
• Pod가 user: alice 또는 user: paul로 라벨 지정된 네임스페이스에 있습니다.
• 포드가 8.8.8.0/24 CIDR 블록의 IP 주소와 통신합니다.

kind: EgressNATPolicy
apiVersion: networking.gke.io/v1
metadata:
  name: egress
spec:
  sources:
  - namespaceSelector:
      matchLabels:
        user: alice
    podSelector:
      matchLabels:
        role: frontend
  - namespaceSelector:
      matchLabels:
        user: paul
    podSelector:
      matchLabels:
        role: frontend
  action: SNAT
  destinations:
    - cidr: 8.8.8.0/24
  gatewayRef:
    name: default
    namespace: kube-system

라벨 사용에 대한 자세한 내용은 Kubernetes 문서의 라벨 및 선택기를 참조하세요.

이그레스 트래픽의 소스 IP 주소 가져오기

EgressNATPolicy 커스텀 리소스(정책)는 gatewayRef.name 값과 gatewayRef.namespace 값을 사용하여 NetworkGatewayGroup 객체(게이트웨이)를 찾습니다. 정책은 게이트웨이의 유동 IP 주소 중 하나를 이그레스 트래픽의 소스 IP 주소로 사용합니다. 일치하는 게이트웨이에 유동 IP 주소가 여러 개 있으면 정책은 floatingIPs 목록의 첫 번째 IP 주소를 사용하고 다른 IP 주소를 무시합니다. 예시 게이트웨이에서 floatingIPs 목록의 첫 번째 주소는 192.168.1.100입니다. gatewayRef 섹션에 잘못된 필드나 값이 있으면 정책 객체를 적용하지 못합니다.

여러 이그레스 정책 및 여러 게이트웨이 객체

이전 섹션의 설명대로 각 egressNATPolicy 객체(정책)는 gatewayRef.name 및 gatewayRef.namespace와 일치하는 게이트웨이 객체의 floatingIPs 목록에 있는 첫 번째 IP 주소를 사용합니다. 정책을 여러 개 만들 수 있으며 다른 IP 주소를 사용하려면 NetworkGatewayGroup 객체를 여러 개 만들고 각각 참조해야 합니다.

각 NetworkGatewayGroup 리소스에는 고유한 유동 IP 주소가 포함되어야 합니다. 여러 EgressNATPolicy 객체에서 같은 IP 주소를 사용하도록 구성하려면 두 객체 모두에 같은 gatewayRef.name 및 gatewayRef.namespace를 사용합니다.

참고: GDC용 Network Gateway에서는 기존 게이트웨이 객체에서 이미 사용된 spec.floatingIPs의 IP 주소가 포함된 새 게이트웨이 객체를 만들 수 없습니다. 이 규칙은 웹훅에서 적용됩니다.

이그레스 정책 여러 개와 게이트웨이 객체 여러 개를 설정하려면 다음 안내를 따르세요.

1. kube-system 네임스페이스에 게이트웨이 객체를 만들어 각 유동 IP 주소를 관리합니다. 일반적으로 올바른 이그레스 IP 주소가 할당되도록 하려면 각 이그레스 정책에 해당 게이트웨이 객체가 있어야 합니다.

   그런 다음 kubectl로 각 게이트웨이 객체를 확인하여 유동 IP 주소의 할당 상태를 가져옵니다.

   kind: NetworkGatewayGroup
   apiVersion: networking.gke.io/v1
   metadata:
     namespace: kube-system
     name: gateway1
   spec:
     floatingIPs:
     - 192.168.1.100
   status:
     ...
     floatingIPs:
       192.168.1.100: worker1
   ---
   kind: NetworkGatewayGroup
   apiVersion: networking.gke.io/v1
   metadata:
     namespace: kube-system
     name: gateway2
   spec:
     floatingIPs:
     - 192.168.1.101
   status:
     ...
     floatingIPs:
       192.168.1.101: worker2
   ---
   kind: NetworkGatewayGroup
   apiVersion: networking.gke.io/v1
   metadata:
     namespace: kube-system
     name: gateway3
   spec:
     floatingIPs:
     - 192.168.1.102
   status:
     ...
     floatingIPs:
       192.168.1.102: worker1
   

2. 이전 단계에서 만든 gateway1과 같이 게이트웨이 객체를 참조하는 정책을 여러 개 만듭니다.

   kind: EgressNATPolicy
   apiVersion: networking.gke.io/v1
   metadata:
     name: egress1
   spec:
     ...
     gatewayRef:
       name: gateway1
       namespace: kube-system
   ---
   kind: EgressNATPolicy
   apiVersion: networking.gke.io/v1
   metadata:
     name: egress2
   spec:
     ...
     gatewayRef:
       name: gateway2
       namespace: kube-system
   ---
   kind: EgressNATPolicy
   apiVersion: networking.gke.io/v1
   metadata:
     name: egress3
   spec:
     ...
     gatewayRef:
       name: gateway3
       namespace: kube-system
   

(선택사항) 유동 IP 주소를 배치할 노드 지정

NetworkGatewayGroup 리소스는 노드 선택기를 지원합니다. 유동 IP 주소 호스팅을 위해 고려되는 노드 하위 집합을 지정하려면 다음 샘플에 표시된 것처럼 NetworkGatewayGroup 객체에 노드 선택기를 추가하면 됩니다.

kind: NetworkGatewayGroup
apiVersion: networking.gke.io/v1
metadata:
  namespace: cluster-cluster1
  name: default
spec:
  floatingIPs:
  - 192.168.1.100
  - 192.168.1.101
  - 192.168.1.102
  nodeSelector:
    node-type: "egressNat"

노드 선택기는 지정된 라벨이 있는 노드만 비교하고 이러한 노드만 유동 IP 주소 호스팅에 고려합니다. 선택기를 여러 개 지정하면 해당 논리가 점증적으로 부가되므로, 유동 IP 주소를 호스팅하는 데 고려되기 위해서는 노드가 모든 라벨과 일치해야 합니다. 라벨이 일치하는 노드가 여러 개 있지 않으면 노드 선택기가 유동 IP 주소 배치의 고가용성(HA) 품질을 줄일 수 있습니다.

이그레스 트래픽 선택 규칙 및 네트워크 정책

이그레스 NAT 게이트웨이는 네트워크 정책 API와 호환됩니다. 네트워크 정책이 먼저 평가되고 이그레스 NAT 게이트웨이의 트래픽 선택 규칙보다 우선 적용됩니다. 예를 들어 이그레스 트래픽이 트래픽 삭제를 일으키는 네트워크 정책을 트리거하는 경우, 이그레스 게이트웨이 규칙이 패킷을 확인하지 않습니다. 네트워크 정책으로 이그레스로 패킷 전송이 허용되는 경우에만 이그레스 NAT 게이트웨이를 사용하거나 Pod가 실행되는 노드의 IP 주소를 사용하여 직접 매스커레이드하는 방식으로 트래픽이 처리되는 방법을 결정하기 위해 이그레스 트래픽 선택 규칙이 평가됩니다.

제한사항

현재 이그레스 NAT 게이트웨이의 제한사항은 다음과 같습니다.

• 이그레스 NAT 게이트웨이는 IPv4 모드로만 사용 설정됩니다.

• 이그레스 IP 주소는 노드 IP 주소와 동일한 Layer 2 도메인에 있어야 합니다.

• 이그레스 NAT 게이트웨이의 미리보기를 사용하도록 구성된 클러스터는 업그레이드가 지원되지 않습니다. Google Distributed Cloud 출시 버전 1.30.0 이상의 경우 이그레스 NAT 게이트웨이는 Ubuntu 18.04에서만 미리보기 단계에 있습니다. 이 기능이 미리보기 단계인 동안에는 요금이 부과되지 않습니다.