GKE로 마이그레이션할 때 IP 주소 계획

표준

이 문서에서는 Google Kubernetes Engine(GKE)에서 IP 주소 사용을 관리하고 필요할 때 GKE에서 대체 네트워크 모델을 사용하는 방법을 설명합니다. 이 문서에서는 다음 개념을 다룹니다.

대부분 조직의 IP 주소 요구에 맞게 GKE에서 포드 IP 주소 사용을 줄이는 방법
클러스터 아키텍처가 조직 요구사항을 충족하지 못할 때 GKE에서 대체 네트워킹 모델을 구현하는 방법

다른 환경에서 GKE로 Kubernetes 클러스터를 마이그레이션하려는 클라우드 설계자, 운영 엔지니어, 네트워크 엔지니어를 위한 문서입니다. GKE의 예상 사용량에 맞게 내부 IP 주소를 충분히 할당하는 것이 어려운 조직의 경우 이 문서의 안내를 따르세요.

이 문서에서는 사용자가 Kubernetes 및 네트워킹 모델에 익숙하다고 가정합니다. 또한 IP 주소 지정, 네트워크 주소 변환(NAT), 방화벽, 프록시와 같은 네트워킹 개념에 익숙해야 합니다.

서비스 IP 주소에 사용되는 주소 범위에 대한 관리 전략은 이 문서에서 다루지 않습니다. 서비스에 필요한 주소 수는 포드에 필요한 것보다 훨씬 적으며, 이 숫자를 줄이기 위한 옵션이 제한적입니다. GKE에서 서비스 IP 주소 범위는 클러스터의 전체 기간으로 고정되어 있습니다. 따라서 예상되는 가장 큰 서비스 개수에 맞게 서비스 IP 주소 범위의 크기를 조정해야 합니다. 클러스터 외부에서 서비스 IP 주소에 연결할 수 없으므로 다른 네트워크에서 해당 주소를 재사용할 수 있습니다.

이 문서에서는 또한 완전 통합형, 섬(island) 모드, 격리형의 여러 다른 Kubernetes 네트워크 모델에 대해 설명합니다. 이러한 모델은 네트워크에서 포드 IP 주소에 연결하는 방법이 다릅니다. 이러한 차이로 인해 사용 가능한 IP 주소 관리 전략이 달라집니다. 이러한 모델 및 GKE 네트워크 모델에 대한 자세한 내용은 함께 포함된 GKE에 사용되는 네트워크 모델 및 기타 Kubernetes 구현에 사용되는 네트워크 비교를 참조하세요.

GKE에서 내부 IP 주소 사용 감소

GKE는 클러스터가 다른 애플리케이션도 포함할 수 있는 VPC 네트워크에 배포된 완전 통합 네트워크 모델을 사용합니다. GKE 모델에는 여러 이점이 있습니다. 하지만 이 유형의 모델에서는 포드 IP 주소를 재사용할 수 없습니다. 재사용이 불가능하기 때문에 전체 VPC 네트워크 내에서 포드 IP 주소가 고유해야 합니다. 따라서 필요한 고유한 IP 주소 수를 신중하게 고려해야 합니다.

필요한 고유한 주소 수에 따라 다음과 같이 IP 주소 사용 감소가 필요한지 여부에 영향을 줍니다.

IP 주소 요구에 따라 주소 공간이 충분하면 IP 주소 사용 감소 조치를 반드시 수행할 필요가 없습니다. 하지만 IP 주소 감소 방법을 알고 있으면 사용할 최소 IP 주소를 확인하는 데 도움이 됩니다.
주소 공간이 충분하지 않으면 주소 공간의 제약조건에 맞는 GKE 클러스터를 만들기 위해 IP 주소 사용을 줄여야 합니다.

GKE에서 IP 주소 사용 감소를 위해서는 다음 옵션을 사용하는 것이 좋습니다.

노드당 포드 설정을 변경합니다. 기본적으로 GKE 표준 클러스터는 모든 노드에 /24 서브넷 범위를 예약하고 포드를 노드당 최대 110개까지 허용합니다. 노드당 사용할 수 있는 포드 수가 64개 미만이면 노드당 최대 포드 수를 조정하여 포드 IP 주소 사용을 절반 이상 줄일 수 있습니다. Autopilot 클러스터는 포드를 노드당 32개 허용하며 이 설정은 변경될 수 없습니다.
여러 포드 IP 주소 범위를 사용합니다. 연속적이지 않은 멀티 포드 클래스 없는 도메인 간 라우팅(CIDR)을 사용하여 기존 클러스터에 보조 포드 IP 주소 범위를 추가할 수 있습니다. 각 노드 풀에서 사용하는 포드 IP 주소 범위를 선택할 수 있습니다. 각 풀에 사용되는 IP 주소 범위를 선택하면 처음에 포드 IP 주소 공간을 보수적으로 할당하면서도 클러스터 확장성을 유지할 수 있습니다.
비RFC 1918 IP 주소를 사용합니다. 기업 네트워크에 포드 IP 주소에 사용할 할당되지 않은 RFC 1918 IP 주소가 충분하지 않을 수 있습니다. 할당되지 않은 RFC 1918 IP 주소가 부족하면 RFC 6598 주소 공간(100.64.0.0/10)의 주소와 같은 비RFC 1918 주소를 사용할 수 있습니다.

기업 네트워크의 다른 곳에서 이미 RFC 6598 공간을 사용하고 있으면 포드 IP 주소에 Class E/RFC 5735(240.0.0.0/4) 주소 공간을 사용할 수 있습니다. 하지만 이러한 IP 주소의 트래픽은 Windows 호스트 및 일부 온프레미스 하드웨어에서 차단됩니다. RFC 5735 주소 차단을 방지하기 위해서는 온프레미스 네트워크에서만 포드 IP 주소 숨기기 섹션에 설명된 대로 외부 대상에 대한 트래픽 매스커레이드를 고려해야 합니다. 하지만 외부 대상에 대해 트래픽을 매스커레이드할 때 온프레미스 애플리케이션으로 전달되는 일부 원격 분석 데이터가 손실됩니다.

또한 조직의 공개 IP 주소 공간이 큰 경우 비공개로 사용되는 공개(PUPI) 주소를 사용할 수 있습니다. PUPI 주소를 사용할 때 NAT를 사용하지 않고 클러스터 외부에서 연결을 설정하려면 nonMasqueradeCIDRs 목록에 PUPI 주소를 포함해야 합니다.

GKE에서 네트워크 모델 선택

GKE 네트워킹 모델 문서에서는 관련된 포드 IP 주소를 포함하여 GKE에서 표준 클러스터가 작동하는 방식을 설명합니다. 이 문서에서 GKE에서 내부 IP 주소 사용 감소 섹션에서는 클러스터에 필요한 내부 IP 주소 수를 줄이는 방법을 설명합니다. GKE 네트워킹 모델 작동 방법과 내부 IP 주소를 줄이는 방법을 아는 것은 GKE에서 사용되는 모든 네트워크 모델의 기본 지식입니다.

하지만 이러한 개념을 알고 적용하는 것만으로는 자신의 요구에 부합되는 네트워크 구현을 얻기 어려울 수 있습니다. 다음 결정 트리에 따라 자신에게 가장 적합한 GKE 네트워크 모델을 구현하는 방법을 결정해볼 수 있습니다.

GKE에서 IP 주소 마이그레이션 전략을 위한 결정 트리입니다.

이 결정 트리는 항상 완전 통합형 네트워크 모델을 기반으로 GKE 표준 클러스터를 만드는 것으로 시작합니다. 이 트리에서 다음 단계는 이 문서에 설명된 모든 옵션을 적용하여 IP 주소 사용을 줄이는 단계입니다.

IP 주소 사용을 최대한 줄였어도 GKE 클러스터에 필요한 주소 공간이 충분하지 않으면 다른 네트워크 모델이 필요합니다. 결정 트리에 따라 다음으로 사용할 네트워크 모델 대안을 결정할 수 있습니다.

온프레미스 네트워크에서만 포드 IP 주소 숨기기. 다음 조건에 해당하는 경우 이 모델을 사용합니다.
- RFC 6598 공간을 사용해서 내부 IP 주소 사용을 줄일 수 없습니다.
- 클래스 E/RFC 5735 주소 공간을 사용할 수 있고 온프레미스 네트워크에서 이 공간을 숨길 수 있습니다.
Private Service Connect를 사용하여 포드 IP 주소 숨기기. 다음 조건에 해당하는 경우 이 모델을 사용합니다.
- 클래스 E/RFC 5735 주소 공간을 사용할 수 없습니다.
- 클러스터에 더 큰 네트워크의 서비스에 대한 비공개 통신이 필요하지 않습니다.
- 클러스터 리전 외부에 있는 모든 리전에서 클러스터에 연결할 필요가 없습니다.
공개 IP 주소 및 VPC 네트워크 피어링을 내부적으로 사용해서 포드 IP 주소 숨기기. 필수는 아니지만 다음 조건에 해당하는 경우 이 모델을 사용합니다.
- 클래스 E/RFC 5735 주소 공간을 사용할 수 없습니다.
- 클러스터에 더 큰 네트워크의 서비스에 대한 비공개 통신이 필요합니다.
- 조직에 사용되지 않은 공개 IP 주소 공간이 할당되었고 가장 큰 클러스터에 대해서도 충분히 큽니다.
Cloud VPN을 사용하여 포드 IP 주소 숨기기. 클러스터가 결정 트리에 설명된 기타 조건을 충족하지 않을 경우 이 모델을 사용합니다.

이 결정 트리는 안내 목적으로만 사용해야 합니다. 특정 사용 사례에 따라 각 모델의 장단점을 기준으로 다른 모델을 사용해야 할 수도 있습니다. 여러 모델을 사용할 수 있는 경우가 많으며, 조직에 보다 적합한 방법을 선택할 수 있습니다.

드물지만 결정 트리에 표시된 대체 모델이 사용자의 특정 요구에 부합하지 않을 수도 있습니다. 드물지만 이러한 경우에는 멀티 NIC 인스턴스를 사용하여 클러스터 주소 숨기기에 설명된 모델을 사용할 수 있습니다.

대체 네트워크 모델 에뮬레이션

완전 통합형 네트워크 모델의 이점을 활용하기 위해서는 GKE 클러스터를 다른 클라우드 리소스와 동일한 논리적 네트워크에 두는 것이 좋습니다. 하지만 이 권장사항을 따르기 어려운 경우도 있습니다. IP 주소 공간이 부족하거나 조직의 대규모 네트워크에서 오는 포드 IP 주소를 숨겨야 할 수도 있습니다.

이 섹션에서는 GKE에서 여러 대체 네트워크 모델을 모방하는 여러 아키텍처 패턴을 기술하여 완전 통합형 네트워크 모델을 사용하는 옵션을 제공합니다. 이러한 대체 아키텍처 패턴은 섬(island) 모드 네트워크 모델 또는 격리형 모드 네트워크 모델과 비슷한 GKE용 작업 모드를 만듭니다.

각 대체 아키텍처 패턴에는 다음 정보가 포함됩니다.

아키텍처 패턴에 대한 설명
패턴 구현 방법을 보여주는 다이어그램입니다.

각 구현 다이어그램은 내부 부하 분산기 사용을 보여줍니다. 특정 부하 분산기가 다이어그램에 표시되지 않은 경우 내부 패스 스루 네트워크 부하 분산기를 사용합니다. 여러 백엔드 서비스를 사용하려면 대신 내부 애플리케이션 부하 분산기를 사용하면 됩니다.
패턴의 장점과 단점에 대한 설명입니다.

온프레미스 네트워크에서만 포드 IP 주소 숨기기

온프레미스 네트워크의 IP 주소를 숨기는 아키텍처 패턴에는 다음과 같은 라우팅 목표 조합이 사용됩니다.

Google Cloud에서 GKE 클러스터가 Google Cloud 배포를 통해 라우팅되는 포드 IP 주소를 할당하도록 설정합니다.
이러한 IP 주소가 Cloud VPN 또는 Cloud Interconnect를 통해 NAT 없이 온프레미스 리소스나 다른 클라우드 환경으로 라우팅되지 않도록 방지합니다.

이 아키텍처 패턴은 이 공간에 여러 IP 주소가 포함되기 때문에 일반적으로 클래스 E/RFC 5735 IP 주소와 함께 사용됩니다. 많은 IP 주소를 사용할 수 있도록 설정하면 각 포드에 고유한 IP 주소를 제공하는 데 도움이 됩니다. 하지만 많은 네트워크 하드웨어 공급업체에서 이 트래픽이 차단되기 때문에 클래스 E/RFC 5735 IP 주소를 온프레미스 리소스에 쉽게 라우팅할 수 없습니다.

클래스 E/RFC 5735 IP 주소 공간을 사용하는 대신 RFC 1918 IP 주소 또는 비RFC 1918 IP 주소의 내부 집합을 사용할 수 있습니다. 이러한 IP 주소의 다른 집합 중 하나를 사용할 경우 포드에 사용되는 주소와 온프레미스 네트워크에 사용되는 주소 사이에 IP 주소 겹침이 있는지 확인합니다. 겹침이 있으면 이러한 주소를 사용하는 클러스터와 동일 주소를 사용하는 온프레미스 애플리케이션 사이에 통신이 없어야 합니다.

다음 단계에서는 이러한 아키텍처 패턴을 설정하는 방법을 간략하게 설명합니다.

포드 서브넷에 대해 보조 IP 주소 범위를 만듭니다. 이 섹션의 앞에서 설명한 것처럼 클래스 E/RFC 5735 공간, RFC 1918 공간, 비RFC 1918 IP 주소의 내부 집합으로부터 이 주소 범위를 만들 수 있습니다. 일반적으로 클래스 E/RFC 5735 공간이 사용됩니다.
커스텀 공지 경로를 사용하고 Cloud Router의 공지에서 포드 IP 주소 범위를 삭제합니다. 이러한 주소를 삭제하면 포드 IP 범위가 경계 게이트웨이 프로토콜(BGP)을 통해 온프레미스 라우터로 공지되지 않도록 할 수 있습니다.
보조 IP 주소 범위를 포드의 클래스 없는 도메인 간 라우팅(CIDR)으로 사용하여 GKE 클러스터를 만듭니다. GKE에서 내부 IP 주소 사용 감소에 설명된 전략을 사용하여 IP 주소 사용을 줄일 수 있습니다.
다음 IP 주소를 매스커레이드 에이전트의 nonMasqueradeCIDRs 목록에 추가합니다.
- 포드에 사용된 IP 주소 범위
- 노드에 사용된 IP 주소 범위입니다.
- Google Cloud에 사용되는 기본 IP 주소 범위와 같이 Google Cloud에만 사용되는 기타 IP 주소
온프레미스 환경 또는 기타 클라우드 환경에 사용되는 내부 IP 주소 범위는 포함하지 않습니다. Google Cloud에 Windows 워크로드가 있으면 이를 개별 서브넷에 두고 해당 범위를 포함하지 않습니다.

이전 단계를 사용해서 이 패턴을 설정할 때는 다음 동작을 수행하도록 클러스터를 구성합니다.

Google Cloud 내에서 완전 통합형 네트워크 모델처럼 작동합니다.
온프레미스 네트워크와 상호작용할 때 섬(island) 모드 네트워크 모델처럼 작동합니다.

이 대체 패턴에서 섬 모드 네트워크 모델을 완전히 에뮬레이션하게 하려면 매스커레이드 에이전트의 nonMasqueradeCIDRs 목록을 클러스터 노드와 포드 IP 주소 범위만 포함된 목록으로 변경해야 합니다. 이러한 목록을 만들면 Google Cloud 내에서도 항상 클러스터 외부에 있는 트래픽을 노드 IP 주소로 매스커레이드합니다. 하지만 이렇게 변경한 후에는 VPC 네트워크 내에서 포드 수준의 원격 분석 데이터를 수집할 수 없습니다.

다음 다이어그램은 이 아키텍처 패턴의 구현을 보여줍니다.

온프레미스 네트워크에서만 IP 주소를 숨기는 구현을 보여주는 네트워크 다이어그램입니다.

앞의 다이어그램은 외부 네트워크의 포드 IP 주소를 숨기는 방법을 보여줍니다. 이 다이어그램에 표시된 것처럼 Google Cloud 내의 포드가 클러스터 사이에서도 서로 직접 통신할 수 있습니다. 이 포드 통신은 GKE 모델과 비슷합니다. 또한 이 다이어그램은 클래스 E/RFC 5735 공간의 주소를 사용하는 포드를 보여줍니다.

클러스터 외부로 전송되는 트래픽의 경우 다이어그램은 소스 NAT(SNAT)가 노드를 나갈 때 해당 트래픽에 적용되는 방식을 보여줍니다. SNAT는 트래픽이 Cloud VPN을 통해 온프레미스 애플리케이션으로 또는 Cloud NAT를 통해 외부 애플리케이션으로 라우팅되는지 여부와 관계없이 사용됩니다.

이 아키텍처 패턴에서는 Google Cloud 내의 통신을 위해 포드 IP 주소가 사용됩니다. 트래픽은 온프레미스 애플리케이션 또는 기타 클라우드 환경으로 전달될 때만 매스커레이드됩니다. 온프레미스 애플리케이션에서 포드에 직접 연결할 수는 없지만 내부 부하 분산을 통해 노출되는 서비스에 연결할 수 있습니다.

온프레미스 네트워크에서 포드 IP 주소를 숨길 때의 이점은 다음과 같습니다.

방화벽을 사용하고 포드 IP 주소를 기준으로 원격 분석 데이터를 수집하는 것과 같이 여전히 Google Cloud 내에서 완전 통합형 네트워크 모델의 이점을 이용할 수 있습니다. 또한 Google Cloud 내에서 디버깅 목적으로 포드에 직접 연결할 수 있습니다.
여전히 Google Cloud 내의 포드 IP 주소로 멀티 클러스터 서비스 메시를 사용할 수 있습니다.

하지만 외부 네트워크의 포드 IP 주소를 숨길 때 단점은 다음과 같습니다.

Google Cloud 내의 다른 클라우드에 대해 포드 또는 서비스 IP 주소 범위를 재사용할 수 없습니다.
온프레미스 네트워크 사이의 트래픽을 위한 것과 완전 Google Cloud 내부 트래픽을 위한 것의 두 가지 서로 다른 방화벽 규칙 집합을 관리해야 할 수 있습니다.
Google Cloud와 온프레미스 또는 기타 클라우드 서비스 제공업체 환경을 포함하는 멀티 클러스터 서비스 메시에서는 포드 간 직접 통신을 설정할 수 없습니다. 예를 들어 Istio를 사용할 때는 모든 통신이 Istio 게이트웨이 사이에 수행되어야 합니다.

Private Service Connect를 사용하여 포드 IP 주소 숨기기

이 아키텍처 패턴에서는 Private Service Connect를 사용하여 포드 IP 주소를 숨깁니다. 이 아키텍처 패턴은 요구사항이 다음과 같을 때 사용합니다.

GKE 클러스터에서 노출하는 서비스 수가 제한적으로만 필요합니다.
GKE 클러스터가 독립적으로 작동할 수 있고 회사 네트워크의 여러 애플리케이션에 대해 이그레스 통신이 필요하지 않습니다.

Private Service Connect는 다른 네트워크에서 소비되는 서비스 게시 방법을 제공합니다. 내부 패스 스루 네트워크 부하 분산기와 서비스 연결을 사용하여 GKE 서비스를 노출하고 다른 VPC 네트워크의 엔드포인트를 사용하여 이러한 서비스를 소비할 수 있습니다.

다음 단계에서는 이러한 아키텍처 패턴을 설정하는 방법을 간략하게 설명합니다.

개별 VPC 네트워크에 GKE 클러스터를 만듭니다. VPC 네트워크에는 해당 클러스터만 포함되어야 합니다.
다른 VPC 네트워크에 있는 다른 클러스터 또는 애플리케이션에서 액세스해야 하는 사용자 클러스터에 있는 각 GKE 서비스에 대해 Private Service Connect를 사용하여 내부 패스 스루 네트워크 부하 분산기를 만듭니다.
(선택사항) GKE 클러스터에 회사 네트워크의 일부 애플리케이션에 대한 이그레스 통신이 필요하면 Private Service Connect를 통해 서비스를 게시하여 이러한 애플리케이션을 노출합니다.

다음 다이어그램은 이 아키텍처 패턴의 구현을 보여줍니다.

Private Service Connect를 사용하여 IP 주소 숨기기 구현을 보여주는 네트워크 다이어그램입니다.

이전 다이어그램은 Private Service Connect 모델에서 클러스터 내부 통신 및 클러스터 사이의 통신이 격리형 네트워크 모델과 얼마나 비슷한지를 보여줍니다. 하지만 허용된 통신은 공개 IP 주소 대신 Private Service Connect 엔드포인트를 통해 수행됩니다. 이 다이어그램에 표시된 것처럼 모든 클러스터는 고유한 개별 VPC 네트워크를 갖습니다. 또한 각 VPC 네트워크는 동일한 IP 주소를 공유할 수 있고, 각 클러스터는 동일한 IP 주소 공간을 공유할 수 있습니다. 클러스터 내의 포드만 서로 직접 통신할 수 있습니다.

클러스터 외부 통신의 경우 이 다이어그램은 Private Service Connect 엔드포인트를 통해 외부 애플리케이션이 클러스터에 연결하는 방법을 보여줍니다. 이 엔드포인트는 클러스터 VPC 네트워크에서 서비스 프로듀서가 제공하는 서비스 연결에 연결됩니다. 클러스터 간 통신은 또한 Private Service Connect 엔드포인트와 서비스 프로듀서의 서비스 연결을 통과합니다.

Private Service Connect를 사용해서 포드 IP 주소를 숨길 때 이점은 다음과 같습니다.

GKE 클러스터의 IP 주소 공간이 나머지 네트워크에서 숨겨지므로 IP 주소를 계획할 필요가 없습니다. 이 방법은 서비스당 단일 IP 주소만 소비 VPC 네트워크에 노출합니다.
이 모델은 노출되는 서비스를 명확하게 정의하고 나머지 VPC 네트워크에서 이렇게 노출된 서비스에 연결할 수 있기 때문에 클러스터 보안이 더 쉽습니다.

하지만 Private Service Connect를 사용하여 포드 IP 주소를 숨길 때의 단점은 다음과 같습니다.

클러스터 내부의 포드가 클러스터 외부의 비공개 통신을 설정할 수 없습니다. 포드가 공개 서비스(포드에 인터넷 연결이 있는 경우) 또는 Google API(Private Google Access 사용)와만 통신할 수 있습니다. 클러스터 외부 서비스가 Private Service Connect를 통해 노출된 경우 포드가 해당 서비스에도 연결할 수 있습니다. 하지만 내부 서비스 제공업체가 모두 서비스 연결을 만들지는 않습니다. 따라서 이러한 서비스 수가 연결을 제공하는 제공업체로 제한될 때만 Private Service Connect를 사용할 수 있습니다.
엔드포인트는 서비스가 있는 동일 리전에서만 연결될 수 있습니다. 또한 이러한 엔드포인트는 피어링된 VPC 네트워크 또는 Cloud VPN 또는 Cloud Interconnect를 통해 연결된 네트워크가 아닌 연결된 VPC 네트워크 자체에서만 연결될 수 있습니다.

Cloud VPN을 사용하여 포드 IP 주소 숨기기

이 아키텍처 패턴은 Cloud VPN을 사용해서 GKE 클러스터와 기본 VPC 네트워크를 서로 분리합니다. 이러한 분리를 수행할 때 결과 네트워크는 섬(island) 모드 네트워크 모델과 비슷하게 작동합니다. 섬(island) 모드 모델과 마찬가지로 이 패턴은 클러스터 간에 포드 및 서비스 IP 주소 범위를 재사용하는 이점이 있습니다. 재사용이 가능한 이유는 클러스터 외부 애플리케이션과의 통신에 SNAT가 사용되기 때문입니다. 노드는 트래픽이 노드를 나가기 전 SNAT를 사용해서 포드 IP 주소를 고유 노드 IP 주소에 매핑합니다.

다음 단계에서는 이 모델을 설정하는 방법을 간략히 설명합니다.

개별 VPC 네트워크에 GKE 클러스터를 만듭니다. VPC 네트워크에는 해당 클러스터만 포함되어야 합니다.

클러스터의 경우 공개 IP 주소 할당 중 사용되지 않은 부분을 사용해서 포드 및 서비스에 대해 하나씩 2개의 IP 주소 범위를 정의합니다. 사용하려는 가장 큰 GKE 클러스터의 요구사항에 따라 IP 주소 범위의 크기를 조정합니다. GKE 내에서 단독으로 사용하도록 이러한 각 범위를 예약합니다. 또한 이러한 범위를 조직 내 모든 GKE 클러스터에 재사용합니다.

일부 경우에는 이러한 큰 IP 주소 범위를 예약하는 것이 불가능합니다. 조직에서 이미 다른 애플리케이션에 대해 포드 및 서비스 IP 주소 범위 중 하나 또는 모두가 사용될 수 있습니다. IP 주소 범위가 사용되고 이를 예약할 수 없으면, 이 IP 주소를 사용하는 애플리케이션이 GKE 클러스터와 통신할 필요가 없어야 합니다.
방금 만든 클러스터의 경우 매스커레이드 에이전트의 nonMasqueradeCIDRs 목록을 클러스터 노드와 포드 IP 주소 범위가 포함된 목록으로 구성합니다. 이 목록을 사용하면 GKE가 Google Cloud 내에서도 항상 클러스터에서 노드 IP 주소로 이동하는 트래픽을 매스커레이드합니다.
Cloud VPN을 사용해서 GKE 클러스터를 포함하는 VPC 네트워크를 기존(기본) VPC 네트워크에 연결합니다.
커스텀 공지 경로를 사용하여 클러스터의 VPC 네트워크에서 기본 VPC 네트워크로 연결되는 포드와 서비스 IP 주소 범위를 공지하지 못하도록 중지합니다.
필요한 다른 GKE 클러스터에 대해 1~4단계를 반복합니다. 모든 클러스터에 대해 포드 및 서비스에 동일한 IP 주소 범위를 사용합니다. 하지만 각 노드에 대해 고유 IP 주소를 사용합니다.
Cloud VPN 또는 Cloud Interconnect를 통해 온프레미스 네트워크에 연결되어 있으면 커스텀 공지 경로를 사용하여 노드 IP 범위를 수동으로 공지합니다.
VPC 네트워크 피어링을 통해 기본 VPC 네트워크에 다른 네트워크가 연결되어 있으면 GKE 클러스터 노드가 피어링된 네트워크에 연결할 수 있도록 피어링에서 커스텀 경로를 내보냅니다.

다음 다이어그램은 포드 IP 주소 숨기기를 위해 Cloud VPN을 사용하는 구현을 보여줍니다.

Cloud VPN을 사용해서 IP 주소를 숨기는 구현을 보여주는 네트워크 다이어그램입니다.

앞의 다이어그램은 Cloud VPN을 사용해서 포드 IP 주소를 숨기는 방법을 보여줍니다. 이 접근 방법은 섬(island) 모드 네트워크 모델과 비슷합니다. 다이어그램에 표시된 것처럼 모든 GKE 클러스터는 고유한 개별 VPC 네트워크를 갖습니다. 각 네트워크는 고유한 노드 IP 주소 공간을 갖지만, 동일한 포드 IP 주소 공간을 사용합니다. Cloud VPN 터널은 이러한 VPC 네트워크를 서로 그리고 회사 네트워크에 연결합니다. 포드 IP 주소 공간은 클러스터를 포함하는 VPC 네트워크에서 공지되지 않습니다.

다이어그램에서 클러스터 내부의 포드만 서로 직접 통신할 수 있습니다. 노드는 클러스터 외부의 다른 클러스터, 회사 네트워크, 연결된 온프레미스 네트워크와 통신할 때 SNAT를 사용해서 포드 IP 주소 공간을 매스커레이드합니다. 포드는 다른 클러스터 또는 회사 네트워크에서 직접 연결될 수 없습니다. 내부 부하 분산기로 노출된 클러스터 서비스만 Cloud VPN 연결을 통해 연결될 수 있습니다.

Cloud VPN을 사용해서 포드 IP 주소를 숨길 때 이점은 다음과 같습니다.

섬(island) 모드 네트워크 모델에 설명된 대로 클러스터 간에 포드 및 서비스 IP 주소 범위를 재사용할 수 있습니다.
기본 VPC 네트워크 및 연결된 네트워크에서 직접 포드 IP 주소에 연결할 수 없기 때문에 방화벽에 필요한 구성이 적을 수 있습니다. 따라서 포드와 통신을 차단하기 위한 명시적인 방화벽 규칙을 구성할 필요가 없습니다.

하지만 Cloud VPN을 사용해서 포드 IP 주소를 숨길 때의 단점은 다음과 같습니다.

섬 모드 네트워크 모델에서 언급된 단점이 동일하게 적용됩니다. 예를 들어 포드 수준에서 방화벽 규칙을 설정할 수 없습니다. 또한 기본 VPC 네트워크 또는 연결된 네트워크에서 포드 수준으로 원격 분석 데이터를 수집할 수 없습니다.
기본 GKE 네트워킹 모델과 비교할 때 이 패턴에는 Cloud VPN 터널과 관련된 비용 및 데이터 전송 요금에서 발생하는 추가 비용이 청구됩니다.
Cloud VPN에는 VPN 터널당 대역폭 한도가 있습니다. 이 대역폭 한도에 도달하면 동일 비용 다중 경로(ECMP)를 사용해서 다중 Cloud VPN 터널을 구성하고 트래픽을 분산할 수 있습니다. 하지만 이러한 작업을 수행함으로써 GKE 구현을 설정하고 유지 보수해야 하는 복잡성이 추가됩니다.
경로 공지를 동기화 상태로 유지함으로써 클러스터 만들기에 복잡성이 추가됩니다. 새 GKE 클러스터를 만들 때마다 Cloud VPN 터널을 설정하고 해당 터널에서 그리고 온프레미스 애플리케이션에 커스텀 공지 경로를 만들어야 합니다.

내부적으로 사용되는 공개 IP 주소 및 VPC 네트워크 피어링을 사용하여 포드 IP 주소 숨기기

조직에서 사용하지 않은 공개 IP 주소를 소유하고 있으면 섬 모드 네트워크 모델과 비슷한 이 아키텍처 패턴을 사용할 수 있지만 이 공개 IP 주소 공간의 비공개 사용이 필요합니다. 이 아키텍처는 Cloud VPN을 사용하는 모델과 비슷하지만 대신 VPC 네트워크 피어링을 사용하여 GKE 클러스터와 기본 네트워크를 구분합니다.

다음 단계에서는 이러한 아키텍처 패턴을 설정하는 방법을 간략하게 설명합니다.

개별 VPC 네트워크에 GKE 클러스터를 만듭니다. VPC 네트워크에는 해당 클러스터만 포함되어야 합니다.

클러스터의 경우 공개 IP 주소 할당 중 사용되지 않은 부분을 사용해서 포드 및 서비스에 대해 하나씩 2개의 IP 주소 범위를 정의합니다. 사용하려는 가장 큰 GKE 클러스터의 요구사항에 따라 IP 주소 범위의 크기를 조정합니다. GKE 내에서 단독으로 사용하도록 이러한 각 범위를 예약합니다. 또한 이러한 범위를 조직 내 모든 GKE 클러스터에 재사용합니다.

공개 IP 주소 할당을 사용하는 대신 타사에서 소유하는 사용되지 않은 대규모 공개 IP 주소 블록을 사용하는 것도 이론적으로 가능합니다. 하지만 이러한 IP 주소는 언제든지 판매되거나 공개적으로 사용될 수 있기 때문에 설정하지 않는 것이 좋습니다. 주소가 판매 또는 사용될 경우 인터넷에서 공개 서비스를 사용할 때 보안 및 연결 문제로 이어집니다.
방금 만든 클러스터의 경우 매스커레이드 에이전트의 nonMasqueradeCIDRs 목록을 클러스터 노드와 포드 IP 주소 범위가 포함된 목록으로 구성합니다. 이 목록을 사용하면 GKE가 Google Cloud 내에서도 항상 클러스터에서 노드 IP 주소로 이동하는 트래픽을 매스커레이드합니다.
VPC 네트워크 피어링을 사용해서 GKE 클러스터가 포함된 VPC 네트워크를 기존(기본) VPC 네트워크에 연결합니다. 이 모델에서 PUPI 주소를 교환하지 않으려고 하기 때문에 피어링을 구성할 때 --no-export-subnet-routes-with-public-ip 플래그를 설정합니다.
필요한 다른 GKE 클러스터에 대해 1~3단계를 반복합니다. 모든 클러스터에 대해 포드 및 서비스에 동일한 IP 주소 범위를 사용합니다. 하지만 각 노드에 대해 고유 IP 주소를 사용합니다.
Cloud VPN 또는 Cloud Interconnect를 통해 온프레미스 네트워크에 연결되어 있으면 커스텀 경로 공지를 사용해서 노드 IP 주소 범위를 수동으로 공지합니다.

다음 다이어그램은 이 아키텍처 패턴의 구현을 보여줍니다.

PUPI 및 VPC 네트워크 피어링을 사용해서 IP 주소를 숨기는 구현을 보여주는 네트워크 다이어그램입니다.

앞의 다이어그램은 VPC 네트워크 피어링을 사용해서 IP 주소를 숨기는 방법을 보여줍니다. 다이어그램에 표시된 것처럼 모든 GKE 클러스터는 고유한 개별 VPC 네트워크를 갖습니다. 각 노드에는 고유 노드 IP 주소 공간이 있지만 조직의 PUPI 주소 공간에서 정의된 것과 동일한 포드 IP 주소 공간이 사용됩니다. VPC 네트워크는 VPC 네트워크 피어링을 통해 서로 그리고 Google Cloud의 비Kubernetes 애플리케이션에 연결됩니다. PUPI 주소 공간은 피어링 사이에 공지되지 않습니다. VPC 네트워크는 Cloud VPN 터널을 통해 회사 네트워크에 연결됩니다.

클러스터 내의 포드만 서로 직접 통신할 수 있습니다. 노드는 클러스터 외부의 다른 클러스터, 회사 네트워크, 연결된 온프레미스 네트워크와 통신할 때 SNAT를 사용해서 포드 IP 공간을 매스커레이드합니다. 포드는 다른 클러스터 또는 회사 네트워크에서 직접 연결될 수 없습니다. 내부 부하 분산기로 노출된 서비스만 VPC 네트워크 피어링 연결을 통해 연결될 수 있습니다.

이 아키텍처 패턴은 앞에서 설명한 Cloud VPN 방식과 비슷하지만 해당 패턴에 비해 다음과 같은 이점이 있습니다.

Cloud VPN 아키텍처 패턴과 달리 VPC 네트워크 피어링은 환경 간 Cloud VPN 터널 또는 대역폭에 대해 추가 비용을 일으키지 않습니다.
VPC 네트워크 피어링은 대역폭 제한이 없고 Google의 소프트웨어 정의 네트워크에 완전히 통합됩니다. 따라서 VPC 네트워크 피어링은 Cloud VPN에 필요한 게이트웨이 및 처리가 피어링에 필요하지 않기 때문에 Cloud VPN보다 약간 낮은 지연 시간을 제공할 수 있습니다.

하지만 VPC 네트워크 피어링 모델은 또한 Cloud VPN 모델에 비해 다음과 같은 단점이 있습니다.

조직에서 예상되는 가장 큰 GKE 클러스터에 필요한 포드 IP 주소 공간을 위해 충분히 크고 사용되지 않은 공개 IP 주소 공간이 필요합니다.
VPC 네트워크 피어링은 비전이성입니다. 따라서 VPC 네트워크 피어링을 통해 기본 VPC 네트워크에 연결된 GKE 클러스터는 서로 또는 기본 VPC와 피어링된 VPC 네트워크의 애플리케이션에 직접 연결할 수 없습니다. 이러한 통신을 사용 설정하거나 기본 VPC 네트워크에서 프록시 VM을 사용하기 위해서는 VPC 네트워크 피어링을 통해 이러한 네트워크에 직접 연결해야 합니다.

멀티 NIC 인스턴스를 사용하여 클러스터 주소 숨기기

이 아키텍처 패턴은 다음 구성요소 및 기술들로 구성되며, 섬(island) 모드 네트워크 모델과 비슷한 모델을 만듭니다.

멀티 네트워크 인터페이스 카드(멀티 NIC)가 포함된 Compute Engine 인스턴스를 사용해서 GKE 클러스터와 기본 VPC 네트워크 사이의 구분 레이어를 만듭니다.
여기에서는 해당 환경 사이에 전송되는 IP 주소에 대해 NAT가 사용됩니다.

GKE 클러스터에 들어오거나 나가는 특정 트래픽을 조사, 변환, 필터링해야 할 때 이 패턴을 사용할 수 있습니다. 이러한 유형의 조사, 변환, 필터링을 수행해야 할 경우 배포된 Compute Engine 인스턴스를 사용해서 해당 태스크를 수행합니다.

멀티 NIC 인스턴스를 사용하여 클러스터 주소를 숨길 때 이점은 다음과 같습니다.

GKE 클러스터의 IP 주소 공간이 나머지 네트워크에서 숨겨집니다. 서비스당 단일 IP 주소만 소비 VPC 네트워크에 노출됩니다.
연결된 온프레미스 네트워크 및 피어링된 네트워크에서 전역적으로 서비스에 연결할 수 있습니다.

하지만 멀티 NIC 인스턴스를 사용하여 클러스터 주소를 숨길 때는 다음과 같은 단점이 있습니다.

이 모델은 모델 구현뿐만 아니라 멀티 NIC 인스턴스에 대한 모니터링 및 로깅도 설정해야 하므로 다른 접근 방법보다 구현이 복잡합니다.
멀티 NIC 인스턴스에 대역폭 제한사항이 있으며 VM 인스턴스 가격 책정이 적용됩니다.
멀티 NIC 인스턴스를 관리 및 업그레이드해야 합니다.