GKE의 네트워크 모델 비교

이 문서에서는 Google Kubernetes Engine(GKE)에 사용되는 네트워크 모델에 대해 설명하고 이 모델이 다른 Kubernetes 환경의 모델과 어떻게 다른지 살펴봅니다. 이 문서에서는 다음 개념을 다룹니다.

  • 여러 Kubernetes 구현에 사용되는 가장 일반적인 네트워크 모델
  • 가장 일반적인 네트워크 모델의 IP 주소 지정 메커니즘
  • 각 네트워크 모델의 장점과 단점
  • GKE에 사용되는 기본 네트워크 모델에 대한 자세한 설명

이 문서는 다른 Kubernetes 구현에 익숙하고 GKE를 사용하려는 클라우드 설계자, 운영 엔지니어, 네트워크 엔지니어를 대상으로 합니다. 이 문서에서는 사용자가 Kubernetes 및 기본 네트워킹 모델에 익숙하다고 가정합니다. 또한 IP 주소 지정, 네트워크 주소 변환(NAT), 방화벽, 프록시와 같은 네트워킹 개념에 익숙해야 합니다.

다양한 IP 주소 제약조건을 충족시키기 위해 기본 GKE 네트워킹 모델을 수정하는 방법은 이 문서에서 다뤄지지 않습니다. GKE로 마이그레이션할 때 IP 주소가 부족한 경우에는 GKE로 마이그레이션할 때 IP 주소 관리 전략을 참조하세요.

일반적인 네트워크 모델 구현

Kubernetes 네트워킹 모델은 여러 방법으로 구현할 수 있습니다. 하지만 모든 구현에서는 항상 다음 요구사항을 충족해야 합니다.

  • 모든 포드에 고유한 IP 주소가 필요합니다.
  • 포드가 NAT를 사용하지 않고도 모든 노드의 다른 포드와 통신할 수 있습니다.
  • kubelet와 같은 한 노드의 에이전트가 해당 노드에 있는 모든 포드와 통신할 수 있습니다.
  • 한 노드의 호스트 네트워크에 있는 포드가 NAT를 사용하지 않고도 모든 노드의 모든 포드와 통신할 수 있습니다.

이러한 요구사항을 충족하도록 개발된 Kubernetes 네트워크 모델에 대한 구현이 20개 이상 있습니다.

이러한 구현은 세 가지 유형의 네트워크 모델로 묶을 수 있습니다. 이러한 세 가지 모델의 차이점은 다음과 같습니다.

  • 포드가 회사 네트워크에서 비Kubernetes 서비스와 통신하는 방법
  • 포드가 동일 조직의 다른 Kubernetes 클러스터와 통신하는 방법
  • 클러스터 외부 통신을 위해 NAT가 필요한지 여부
  • 다른 클러스터 또는 기업 네트워크의 다른 위치에서 포드 IP 주소를 다시 사용할 수 있는지 여부

각 클라우드 제공업체에서 이러한 모델 유형 중 하나 이상이 구현되었습니다.

다음 표에서는 일반적으로 사용되고 세 가지 모델 유형과 해당 모델이 사용되는 Kubernetes 구현을 보여줍니다.

네트워크 모델 이름 모델이 사용되는 구현
완전 통합형 또는 플랫
섬(Island) 모드 또는 브리지
격리 또는 에어 갭 적용
  • Kubernetes 구현에 일반적으로 사용되지 않지만 개별 네트워크 또는 Virtual Private Cloud(VPC)에 클러스터가 배포되는 모든 구현에 사용 가능합니다.

이 문서에서 이러한 네트워크 모델에 대해 설명할 때는 연결된 온프레미스 네트워크에 대한 효과를 참조합니다. 하지만 다른 클라우드 공급업체 연결을 포함하여 연결된 온프레미스 네트워크에 대해 기술된 개념을 Virtual Private Network(VPN) 또는 비공개 Interconnect를 통해 연결된 네트워크에 적용할 수 있습니다. GKE의 경우 이러한 연결에는 Cloud VPN 또는 Cloud Interconnect를 통한 모든 연결이 포함됩니다.

완전 통합형 네트워크 모델

완전 통합형 네트워크(또는 플랫) 모델은 Kubernetes 외부 및 기타 Kubernetes 클러스터의 애플리케이션에 대해 간편한 통신을 제공합니다. 주요 클라우드 서비스 제공업체는 해당 Kubernetes 구현을 해당 소프트웨어 정의 네트워크(SDN)와 밀접하게 통합할 수 있기 때문에 이 모델을 일반적으로 구현합니다.

완전 통합형 모델을 사용할 때 포드에 사용되는 IP 주소는 Kubernetes 클러스터가 있는 네트워크 내에서 라우팅됩니다. 또한 기본 네트워크는 포드 IP 주소가 있는 노드를 인지합니다. 많은 구현에서 동일 노드의 포드 IP 주소는 사전 할당된 특정 포드 IP 주소 범위로부터 비롯됩니다. 하지만 이 사전 할당된 IP 주소 범위는 요구사항이 아닙니다.

다음 다이어그램은 완전 통합형 네트워킹 모델의 포드 통신 옵션을 보여줍니다.

완전 통합형 네트워크 모델에서 통신 패턴을 보여주는 네트워크 다이어그램입니다.

완전 통합형 네트워크 모델에 대한 위 다이어그램은 다음과 같은 통신 패턴을 보여줍니다.

  • Kubernetes 클러스터 내 포드가 서로 직접 통신할 수 있습니다.
  • 클러스터가 동일한 네트워크에 있는 한 포드가 다른 클러스터의 포드와 통신할 수 있습니다.
  • 해당 애플리케이션이 동일한 네트워크 또는 상호 연결된 네트워크에 있는지 여부에 관계없이 포드가 클러스터 외부의 다른 애플리케이션과 통신하기 위해 NAT가 필요하지 않습니다.

이 다이어그램은 또한 여러 클러스터 간에 포드 IP 주소 범위가 고유함을 보여줍니다.

완전 통합형 네트워크 모델은 다음 구현에서 사용 가능합니다.

  • 기본적으로 GKE는 이 모델을 구현합니다. 이 구현에 대한 자세한 내용은 이 문서 뒷 부분에 있는 GKE 네트워킹 모델을 참조하세요.
  • 기본적으로 Amazon EKS가 이 모델을 구현합니다. 이 구현에서 Amazon EKS는 Kubernetes용 Amazon VPC 컨테이너 네트워킹 인터페이스(CNI) 플러그인을 사용해서 VPC 주소 공간에서 직접 포드 IP 주소를 할당합니다. CNI 플러그인은 노드가 있는 기본 서브넷 또는 커스텀 서브넷에서 IP 주소를 할당합니다. 포드 IP 주소는 노드당 전용 포드 IP 주소 범위에서 오지 않습니다.
  • Azure에서 AKS는 Azure CNI(고급 네트워킹)를 사용할 때 이 모델을 구현합니다. 이 구현은 기본 구성이 아닙니다. 이 구현에서 각 포드는 서브넷에서 IP 주소를 가져옵니다. 또한 노드당 최대 포드 수를 구성할 수 있습니다. 따라서 해당 노드에서 포드에 대해 미리 예약된 IP 주소 수는 노드당 최대 포드 수와 동일합니다.

완전 통합형 네트워크 모델을 사용할 때 이점은 다음과 같습니다.

  • 향상된 원격 분석 데이터. 네트워크 전체에 포드 IP 주소가 표시됩니다. 이러한 가시성 덕분에 클러스터 외부에서 수집된 원격 분석 데이터에서도 포드를 식별할 수 있기 때문에 다른 모델보다 원격 분석 데이터가 더 유용합니다.
  • 더 쉬운 방화벽 구성. 완전 통합형 네트워크 모델에서 방화벽 규칙을 설정할 때는 노드 및 포드 트래픽을 다른 모델보다 더 쉽게 구분할 수 있습니다.
  • 향상된 호환성. 포드가 NAT를 지원하지 않는 프로토콜을 사용하여 통신할 수 있습니다.
  • 향상된 디버깅. 방화벽에서 허용되는 경우 클러스터 외부 리소스가 디버깅 프로세스 중 직접 포드에 연결할 수 있습니다.
  • 서비스 메시를 사용한 호환성. 포드가 서로 직접 통신할 수 있기 때문에 Istio 또는 Anthos Service Mesh와 같은 서비스 메시가 클러스터 간에 쉽게 통신할 수 있습니다. 일부 서비스 메시 구현은 멀티 클러스터 서비스 메시에 대해서만 포드 간 연결을 지원합니다.

완전 통합형 네트워크 모델을 사용할 때의 단점은 다음과 같습니다.

  • IP 주소 사용. 네트워크 내에서 포드 IP 주소를 재사용할 수 없고 각 IP 주소가 고유해야 합니다. 이러한 요구사항으로 인해 포드에 대해 예약해야 하는 IP 주소 수가 커질 수 있습니다.
  • SDN 요구사항. Kubernetes 구현으로 SDN을 직접 프로그래밍해야 하기 때문에 완전 통합형 네트워크 모델은 기본 네트워크와의 깊은 통합이 요구됩니다. SDN 프로그래밍은 사용자에게 투명하게 수행되며 사용자에게 직접 영향을 주는 단점을 일으키지 않습니다. 하지만 이러한 깊은 통합형 네트워크 모델은 자체적으로 관리되는 온프레미스 환경에서 쉽게 구현할 수 없습니다.

섬(Island) 모드 네트워크 모델

섬(Island) 모드 네트워크 모델(또는 브리지)은 기본 네트워크와의 깊은 통합이 가능하지 않은 온프레미스 Kubernetes 구현에 일반적으로 사용됩니다. 섬(Island) 모드 네트워크 모델을 사용할 때Kubernetes 클러스터 포드는 일종의 게이트웨이 또는 프록시를 통해 클러스터 외부 리소스와 통신할 수 있습니다.

다음 다이어그램은 섬(Island) 모드 네트워킹 모델의 포드 통신 옵션을 보여줍니다.

섬(Island) 모드 네트워크 모델의 통신 패턴을 보여주는 네트워크 다이어그램입니다.

섬(Island) 모드 네트워크 모델에 대한 위 다이어그램은 Kubernetes 클러스터 내 포드가 서로 직접 통신할 수 있는 방법을 보여줍니다. 이 다이어그램은 또한 클러스터 외부 애플리케이션 또는 다른 클러스터의 포드와 통신할 때 클러스터의 포드가 게이트웨이 또는 프록시를 사용해야 함을 보여줍니다. 클러스터와 외부 애플리케이션 간의 통신에는 단일 게이트웨이가 필요하지만 클러스터 간 통신에는 2개의 게이트웨이가 필요합니다. 두 클러스터 간 트래픽은 첫 번째 클러스터를 나갈 때 하나의 게이트웨이를 통과하고, 다른 클러스터에 들어갈 때 또 다른 게이트웨이를 통과합니다.

격리형 네트워크 모델로 게이트웨이 또는 프록시를 구현하는 방법은 여러 가지가 있습니다. 다음 구현은 가장 일반적으로 사용되는 두 가지 게이트웨이 또는 프록시입니다.

  • 노드를 게이트웨이로 사용. 이 구현은 클러스터 노드가 기존 네트워크의 일부이고 해당 IP 주소가 이 네트워크 내에서 기본적으로 라우팅 가능할 때 일반적으로 사용됩니다. 이 경우 노드 자체는 클러스터 내부에서 더 큰 네트워크로의 연결을 제공하는 게이트웨이입니다. 포드에서 클러스터 외부로의 이그레스 트래픽은 회사 네트워크의 온프레미스 API 호출과 같이 다른 클러스터 또는 비Kubernetes 애플리케이션으로 연결될 수 있습니다. 이 이그레스 트래픽의 경우 포드를 포함하는 노드가 소스 NAT(SNAT)를 사용해서 포드의 IP 주소를 노드 IP 주소에 매핑합니다. 클러스터 외부에 있는 애플리케이션이 클러스터 내 서비스와 통신할 수 있도록 하려면 대부분의 구현에 NodePort 서비스 유형을 사용할 수 있습니다. 일부 구현에서는 LoadBalancer 서비스 유형을 사용하여 서비스를 노출할 수 있습니다. LoadBalancer 서비스 유형을 사용할 때는 노드 간에 부하 분산되고 서비스에 포함된 포드로 라우팅되는 가상 IP 주소를 서비스에 부여합니다.

    다음 다이어그램은 노드를 게이트웨이로 사용하는 구현 패턴을 보여줍니다.

    노드를 게이트웨이로 사용하는 섬(Island) 모드 네트워크 모델의 통신 패턴을 보여주는 네트워크 다이어그램입니다.

    위 다이어그램은 노드를 게이트웨이로 사용해도 클러스터 내의 포드 간 통신에 영향을 주지 않음을 보여줍니다. 클러스터의 포드가 여전히 서로 직접적으로 통신합니다. 하지만 이 다이어그램은 또한 클러스터 외부의 다음 통신 패턴을 보여줍니다.

    • 포드가 노드를 나갈 때 SNAT를 사용해서 다른 클러스터 또는 비Kubernetes 애플리케이션과 통신하는 방법
    • 다른 클러스터의 외부 서비스 또는 비Kubernetes 애플리케이션의 트래픽이 클러스터의 올바른 포드로 전달되기 전 NodePort 서비스를 통해 클러스터에 들어가는 방법

  • 다중 네트워크 인터페이스로 프록시 가상 머신(VM) 사용. 이 구현 패턴은 프록시를 사용하여 Kubernetes 클러스터가 포함된 네트워크에 액세스합니다. 프록시에는 포드 및 노드 IP 주소 공간에 대한 액세스 권한이 있어야 합니다. 이 패턴에서 각 프록시 VM에는 2개의 네트워크 인터페이스가 포함됩니다. 인터페이스 하나는 대규모 기업 네트워크에 사용되고, 다른 인터페이스는 Kubernetes 클러스터를 포함하는 네트워크에 사용됩니다.

    다음 다이어그램은 프록시 VM을 사용할 때의 구현 패턴을 보여줍니다.

    프록시 VM을 사용하는 섬(Island) 모드 네트워크 모델의 통신 패턴을 보여주는 네트워크 다이어그램입니다.

    위 다이어그램은 섬(Island) 모드로 프록시를 사용해도 클러스터 내 통신에 영향을 주지 않음을 보여줍니다. 클러스터의 포드가 여전히 서로 직접적으로 통신할 수 있습니다. 하지만 이 다이어그램은 또한 포드에서 다른 클러스터 또는 비Kubernetes 애플리케이션으로의 통신이 클러스터의 네트워크 및 목적지 네트워크 모두에 액세스할 수 있는 프록시를 통해 전달되는지를 보여줍니다. 또한 외부에서 클러스터로 들어가는 통신은 동일한 종류의 프록시를 통과합니다.

섬(Island) 모드 네트워크 모델은 다음 구현에서 사용 가능합니다.

  • 기본적으로 Azure Kubernetes Service(AKS)는 Kubenet(기본) 네트워킹을 사용할 때 섬(Island) 모드 네트워킹을 사용합니다. AKS에 섬(Island) 모드 네트워킹이 사용될 때 클러스터를 포함하는 가상 네트워크에는 노드 IP 주소만 포함됩니다. 포드 IP 주소는 가상 네트워크에 포함되지 않습니다. 대신 포드가 다른 논리적 공간에서 IP 주소를 수신합니다. AKS에 사용되는 섬(Island) 모드 모델은 또한 노드 인터페이스에서 활성화된 IP 전달과 함께 사용자 정의 경로를 사용해서 노드 사이에 포드 간 트래픽을 라우팅합니다. 클러스터 외부 리소스에 대한 포드 통신을 위해 이 노드는 SNAT를 사용해서 이그레스 트래픽이 노드를 나가기 전 포드 IP 주소를 노드 IP 주소에 매핑합니다.
  • Oracle Container Engine for Kubernetes(OKE)에서 포드 간 통신에는 VXLAN 오버레이 네트워크가 사용됩니다. 또한 포드에서 클러스터 외부 애플리케이션으로의 트래픽은 SNAT를 사용해서 포드 IP 주소를 노드 IP 주소에 매핑합니다.

섬(Island) 모드 네트워크 모델을 사용할 때의 이점은 다음과 같습니다.

  • IP 주소 사용. 클러스터의 포드 IP 주소를 다른 클러스터에서 재사용할 수 있습니다. 하지만 이미 회사 네트워크에서 외부 서비스에 사용되는 IP 주소는 통신이 포드와 해당 서비스 사이에 이뤄져야 할 경우 포드에 사용할 수 없습니다. 따라서 섬(Island) 모드 네트워킹의 권장사항은 네트워크 내에서 고유한 포드 IP 주소 공간을 예약하고 이 IP 주소 공간을 모든 클러스터에 사용하는 것입니다.
  • 간편한 보안 설정. 포드가 나머지 회사 네트워크에 직접 노출되지 않기 때문에 나머지 회사 네트워크에서 인그레스 트래픽에 대해 포드를 보호할 필요가 없습니다.

섬(Island) 모드 네트워크 모델을 사용할 때의 단점은 다음과 같습니다.

  • 부정확한 원격 분석. 클러스터 외부에서 수집되는 원격 분석 데이터에 포드 IP 주소가 아닌 노드 IP 주소만 포함됩니다. 포드 IP 주소가 없으면 트래픽의 소스 및 대상을 식별하기 어렵습니다.
  • 까다로운 디버깅. 디버깅할 때 클러스터 외부에서 포드에 직접 연결할 수 없습니다.
  • 까다로운 방화벽 구성. 방화벽을 구성할 때 노드 IP 주소만 사용할 수 있습니다. 따라서 결과 방화벽 설정은 한 노드의 모든 포드 및 노드 자체가 외부 서비스에 연결하거나 아무 것도 외부 서비스에 연결하지 못하도록 설정합니다.

  • 서비스 메시를 사용한 호환성. 섬(Island) 모드에서는 Istio 또는 Anthos Service Mesh와 같은 서비스 메시의 클러스터 간 직접 포드 간 통신이 불가능합니다.

    일부 서비스 메시 구현에는 추가 제한사항이 있습니다. Google Cloud에서 GKE 클러스터에 대한 Anthos Service Mesh 멀티 클러스터 지원은 동일 네트워크의 클러스터만 지원합니다. 다중 네트워크 모델을 지원하는 Istio 구현의 경우 Istio 게이트웨이를 통해 통신이 수행되어야 하기 때문에 멀티 클러스터 서비스 메시 배포가 더 복잡해집니다.

격리형 네트워크 모델

격리형(또는 에어 갭 적용) 네트워크 모델은 공개 대면 API를 제외하고 대규모 회사 네트워크에 액세스할 필요가 없는 클러스터에 가장 일반적으로 사용됩니다. 격리형 네트워크 모델을 사용할 때는 각 Kubernetes 클러스터가 격리되고 내부 IP 주소를 사용해서 나머지 네트워크와 통신할 수 없습니다. 클러스터는 자체 비공개 네트워크에 있습니다. 클러스터의 포드가 클러스터 외부 서비스와 통신해야 할 경우 이 통신은 인그레스 및 이그레스 모두 공개 IP 주소를 사용해야 합니다.

다음 다이어그램은 격리형 네트워크 모델의 포드 통신 옵션을 보여줍니다.

격리형 네트워크 모델의 통신 패턴을 보여주는 네트워크 다이어그램입니다.

격리형 네트워크 모델에 대한 위 다이어그램은 Kubernetes 클러스터 내 포드가 서로 직접 통신할 수 있음을 보여줍니다. 또한 이 다이어그램은 포드가 내부 IP 주소를 사용해서 다른 클러스터의 포드와 통신할 수 없음을 보여줍니다. 또한 포드는 다음 조건이 충족될 때만 클러스터 외부 애플리케이션과 통신할 수 있습니다.

  • 클러스터를 외부에 연결하는 인터넷 게이트웨이가 있습니다.
  • 외부 애플리케이션이 통신을 위해 외부 IP 주소를 사용합니다.

마지막으로 이 다이어그램은 포드 및 노드에 대해 동일한 IP 주소 공간을 서로 다른 환경 간에 재사용하는 방법을 보여줍니다.

격리형 네트워크 모델은 Kubernetes 구현에 일반적으로 사용되지 않습니다. 하지만 모든 구현에서 격리형 네트워크 모델을 달성할 수 있습니다. 다른 서비스 또는 회사 네트워크에 대한 연결 없이 개별 네트워크 또는 VPC에 Kubernetes 클러스터를 배포해야 합니다. 결과 구현은 격리형 네트워크 모델과 동일한 장점 및 단점을 갖습니다.

격리형 네트워크 모드를 사용할 때 장점은 다음과 같습니다.

  • IP 주소 사용. 노드 IP 주소, 서비스 IP 주소, 포드 IP 주소와 같은 클러스터의 모든 내부 IP 주소를 재사용할 수 있습니다. 내부 IP 주소를 재사용할 수 있는 이유는 각 클러스터에 자체 비공개 네트워크가 있고 클러스터 외부 리소스에 대한 통신이 공개 IP 주소를 통해서만 수행되기 때문입니다.
  • 제어. 클러스터 관리자는 클러스터의 IP 주소 지정을 모드 제어할 수 있으며, IP 주소 관리 태스크를 수행할 필요가 없습니다. 예를 들어 관리자는 해당 주소가 조직에 이미 사용되었더라도 클러스터의 포드 및 서비스에 전체 10.0.0.0/8 주소 공간을 할당할 수 있습니다.
  • 보안. 클러스터 외부 통신은 긴밀하게 제어되며, 허용될 경우 잘 정의된 외부 인터페이스 및 NAT를 사용합니다.

격리형 네트워크 모델을 사용할 때 단점은 다음과 같습니다.

  • 비공개 통신 없음. 내부 IP 주소를 사용한 통신은 네트워크의 다른 클러스터 또는 다른 서비스에 허용되지 않습니다.

GKE 네트워킹 모델

GKE에는 다른 애플리케이션을 포함할 수 있는 Virtual Private Cloud(VPC) 네트워크에 클러스터가 배포된 완전 통합형 네트워크 모델이 사용됩니다.

GKE 환경에 대해 VPC 기반 클러스터를 사용하는 것이 좋습니다. Standard 또는 Autopilot에서 VPC 기반 클러스터를 만들 수 있습니다. Autopilot 모드를 선택하면 VPC 기반 모드가 항상 설정되어 있고 이를 해제할 수 없습니다. 다음 단락에서는 Autopilot과의 차이점과 함께 Standard의 GKE 네트워킹 모델에 대해 설명합니다.

VPC 기반 클러스터의 IP 주소 관리

VPC 기반 클러스터를 사용할 때는 포드 IP 주소가 각 노드에서 보조 IP 주소입니다. 각 노드에는 클러스터를 만들 때 내부 IP 주소 공간에서 선택하는 포드 IP 주소 범위의 특정 서브넷이 할당됩니다. 기본적으로 VPC 기반 클러스터는 각 노드에 포드 IP 주소로 사용하도록 /24 서브넷을 할당합니다. /24 서브넷은 256 IP 주소에 해당합니다. Autopilot에서 클러스터는 64 주소에 해당하는 /26 서브넷을 사용하며, 이 서브넷 설정을 변경할 수 없습니다.

GKE 네트워킹 모델에서는 네트워크에서 IP 주소를 재사용할 수 없습니다. GKE로 마이그레이션할 때는 GKE에서 내부 IP 주소 사용 감소하도록 IP 주소 할당을 계획해야 합니다.

포드 IP 주소는 VPC 네트워크 내에서 라우팅 가능하기 때문에 포드가 기본적으로 다음 리소스에서 트래픽을 수신할 수 있습니다.

IP 매스커레이드 에이전트로 외부 트래픽 통신 관리

포드에서 클러스터 외부 서비스로 통신할 때 IP 매스커레이드 에이전트는 트래픽이 해당 서비스에 표시되는 방식을 제어합니다. IP 매스커레이드 에이전트는 다음 글머리표 목록에 표시된 대로 비공개 및 외부 IP 주소를 서로 다르게 처리합니다.

  • 기본적으로 IP 매스커레이드 에이전트는 내부적으로 흔히 사용되는 RFC 1918 IP 주소, 비RFC 1918 IP 주소를 포함하여 트래픽을 내부 IP 주소로 매스커레이드하지 않습니다. 자세한 내용은 기본 비매스커레이드 대상 목록을 참조하세요. 내부 IP 주소는 매스커레이드되지 않기 때문에 노드가 해당 주소에 NAT를 사용하지 않습니다.
  • 외부 IP 주소의 경우 IP 매스커레이드 에이전트가 이러한 주소를 노드 IP 주소로 매스커레이드합니다. 따라서 이러한 매스커레이드된 주소가 Cloud NAT에 의해 외부 IP 주소로 변환됩니다. 또는 가상 머신(VM) 인스턴스의 외부 IP 주소로 변환됩니다.

또한 VPC 네트워크 또는 연결된 네트워크 내부의 비공개로 사용되는 공개 IP(PUPI) 주소를 사용할 수 있습니다. PUPI 주소를 사용하는 경우 완전 통합형 네트워크 모델의 이점을 활용하고 포드 IP 주소를 직접 소스로 확인할 수 있습니다. 이러한 목표를 모두 달성하기 위해서는 nonMasqueradeCIDRs 목록에 PUPI 주소를 포함해야 합니다.

GKE 네트워크의 포드 트래픽 흐름 이해

다음 다이어그램은 GKE 네트워킹 모델에서 포드가 통신할 수 있는 방법을 보여줍니다.

GKE 네트워크 모델의 통신 패턴을 보여주는 네트워크 다이어그램입니다.

위 다이어그램은 GKE 환경의 포드가 내부 IP 주소를 사용하여 다음 리소스와 직접 통신하는 방법을 보여줍니다.

  • 동일 클러스터의 다른 포드
  • 동일 VPC 네트워크의 다른 GKE 클러스터에 있는 포드
  • 동일 VPC 네트워크의 다른 Google Cloud 애플리케이션
  • Cloud VPN을 통해 연결된 온프레미스 애플리케이션

이 다이어그램은 또한 포드에서 외부 IP 주소를 사용해서 애플리케이션과 통신해야 하는 경우에 발생하는 결과를 보여줍니다. 트래픽이 노드를 떠날 때 포드가 있는 노드는 SNAT를 사용해서 포드의 IP 주소를 노드의 IP 주소에 매핑합니다. 트래픽이 노드를 떠난 후 Cloud NAT는 노드의 IP 주소를 외부 IP 주소로 변환합니다.

이 문서의 앞에서 설명한 이점 중 특히 모든 원격 분석 데이터에서 포드 IP 주소를 표시할 수 있는 이점을 위해 Google은 완전 통합형 네트워크 모델을 선택했습니다. GKE에서 포드 IP 주소는 VPC 흐름 로그(메타데이터의 포드 이름 포함), 패킷 미러링, 방화벽 규칙 로깅, 비매스커레이드 대상에 대한 고유 애플리케이션 로그에 노출됩니다.

다음 단계