GKE 네트워킹 권장사항

이 문서에서는 Google Kubernetes Engine(GKE) 클러스터에 네트워킹 옵션 구성에 대한 권장사항을 간략하게 설명합니다. 이는 대부분의 GKE 클러스터에 적용할 수 있는 클러스터 구성 권장사항이 포함된 클라우드 설계자 및 네트워크 엔지니어를 위한 아키텍처 계획 가이드입니다. GKE 클러스터를 만들기 전에 이 페이지의 모든 섹션을 검토하여 GKE에서 지원하는 네트워킹 옵션과 그 영향을 이해하는 것이 좋습니다.

선택한 네트워킹 옵션은 GKE 클러스터의 아키텍처에 영향을 미칩니다. 이러한 옵션 중 일부는 클러스터를 다시 만들지 않고 구성한 후에는 변경할 수 없습니다.

이 페이지를 읽기 전에 Kubernetes 네트워킹 개념과 용어, 일정 수준의 일반적인 네트워킹 개념, Kubernetes 네트워킹을 숙지해야 합니다. 자세한 내용은 GKE 네트워크 개요를 참조하세요.

다음 권장사항을 검토할 때 다음 사항을 고려하세요.

• Virtual Private Cloud(VPC) 네트워크, 클러스터의 다른 워크로드, 다른 GKE 클러스터에 내부적으로 워크로드를 노출하거나 인터넷에 외부적으로 워크로드를 노출하는 방법
• 워크로드 확장 방법
• 소비할 Google 서비스의 유형

모든 권장사항을 요약한 체크리스트는 체크리스트 요약을 참조하세요.

VPC 설계

VPC 네트워크를 설계할 때는 VPC 설계 권장사항을 따르세요.

다음 섹션에서는 VPC 네트워크 설계에 대한 GKE별 권장사항을 제공합니다.

VPC 기반 클러스터 사용

VPC 기반 클러스터를 사용하는 것이 좋습니다. VPC 기반 클러스터는 GKE 노드에서 별칭 IP 주소 범위를 사용하며 이는 비공개 GKE 클러스터에 필요하고 공유 VPC에서 클러스터를 만드는 데 필요하며 여러 가지 다른 이점이 있습니다. Autopilot 모드에서 생성된 클러스터의 경우 VPC 기반 모드가 항상 켜져 있으며 사용 중지할 수 없습니다.

VPC 기반 클러스터는 Google Cloud 경로를 사용하지 않고도 경로 기반 클러스터보다 더 쉽게 확장되므로 라우팅 제한을 초과할 가능성이 적습니다.

VPC 기반 클러스터를 사용할 때의 장점은 별칭 IP 지원과 관련이 있습니다. 예를 들어 네트워크 엔드포인트 그룹(NEG)은 보조 IP 주소만 사용할 수 있으므로 VPC 기반 클러스터에서만 지원됩니다.

공유 VPC 네트워크 사용

GKE 클러스터에는 신중한 IP 주소 계획이 필요합니다. 대부분의 조직은 클러스터의 IP 주소 공간을 할당할 수 있는 네트워크 관리팀과 클러스터 운영을 담당하는 플랫폼 관리자가 있는 중앙 집중식 관리 구조를 가지는 경향이 있습니다. 이러한 유형의 조직 구조는 Google Cloud의 공유 VPC 네트워크 아키텍처에서 원활하게 작동합니다. 공유 VPC 네트워크 아키텍처에서 네트워크 관리자는 서브넷을 만들어 VPC와 공유할 수 있습니다. 서비스 프로젝트에서 GKE 클러스터를 만들고 호스트 프로젝트의 공유 VPC에서 공유된 서브넷을 사용할 수 있습니다. IP 주소 구성요소는 호스트 프로젝트에 유지되고 다른 클러스터 구성요소는 서비스 프로젝트에 유지됩니다.

일반적으로 공유 VPC 네트워크는 중앙 집중식 관리팀이 있는 대부분의 조직에 적합한 자주 사용되는 아키텍처입니다. 공유 VPC 네트워크를 사용하여 GKE 클러스터의 서브넷을 만들고 조직 전체에서 IP 주소 충돌을 방지하는 것이 좋습니다. 운영 함수의 거버넌스에 공유 VPC를 사용할 수도 있습니다. 예를 들어 네트워크 구성요소 및 안정성에 대해서만 작업하는 네트워크팀과 GKE에 대해 작업하는 다른 팀이 있을 수 있습니다.

IP 주소 관리 전략

GKE 클러스터를 포함한 모든 Kubernetes 클러스터에는 모든 포드마다 고유한 IP 주소가 필요합니다.

GKE에서 이러한 모든 IP 주소는 VPC 네트워크 전체에서 라우팅할 수 있습니다. 따라서 주소는 온프레미스 또는 기타 연결된 환경에서 사용되는 내부 IP 주소 공간과 겹칠 수 없으므로 IP 주소 계획이 필요합니다. 다음 섹션에서는 GKE를 사용하여 IP 주소 관리를 위한 전략을 제시합니다.

필요한 IP 주소 할당량 계획

비공개 클러스터는 권장되며 네트워크 보안 섹션에서 더 자세히 설명합니다. 비공개 클러스터 맥락에서 VPC 기반 클러스터만 지원되며 다음 IP 주소 범위가 필요합니다.

• 컨트롤 플레인 IP 주소 범위: RFC 1918에 포함된 IP 주소 비공개 범위 내에서 /28 서브넷을 사용합니다. 이 서브넷이 VPC 네트워크의 그 외 모든 클래스 없는 도메인 간 라우팅(CIDR)과 겹치지 않는지 확인해야 합니다.
• 노드 서브넷: 클러스터의 모든 노드에 할당할 기본 IP 주소 범위가 있는 서브넷입니다. cloud.google.com/load-balancer-type: "Internal" 주석을 사용하는 LoadBalancer 유형의 서비스는 기본적으로 이 서브넷을 사용합니다. 내부 부하 분산기의 전용 서브넷을 사용할 수도 있습니다.
• 포드 IP 주소 범위: 클러스터의 모든 포드에 할당하는 IP 범위입니다. GKE는 이 범위를 서브넷의 별칭으로 프로비저닝합니다. 자세한 내용은 VPC 기반 클러스터의 IP 주소 범위를 참조하세요.
• 서비스 IP 주소 범위: 클러스터의 모든 서비스에 할당하는 IP 주소 범위입니다. GKE는 이 범위를 서브넷의 별칭으로 프로비저닝합니다.

비공개 클러스터의 경우 노드 서브넷, 포드 IP 주소 범위, 서비스 IP 주소 범위를 정의해야 합니다.

컨트롤 플레인 IP 주소 범위는 VPC와 피어링된 Google 관리형 테넌트 프로젝트에 있는 GKE 관리형 컨트롤 플레인 전용입니다. GKE가 이 경로를 프로젝트로 가져오기 때문에 이 IP 주소 범위는 VPC 피어링 그룹의 IP 주소와 겹치지 않아야 합니다. 즉, 프로젝트에 동일한 CIDR로 가는 경로가 있으면 라우팅 문제가 발생할 수 있습니다.

클러스터를 만들 때 서브넷에는 클러스터의 노드에 대한 기본 범위가 있으며, 클러스터 생성 전에 서브넷이 존재해야 합니다. 서브넷은 클러스터에서 예상하는 최대 노드 수와 서브넷을 사용하는 클러스터의 내부 부하 분산기 IP 주소를 수용할 수 있어야 합니다.

포드와 서비스 IP 주소 범위는 서브넷의 구별된 보조 범위로 표현되며, VPC 기반 클러스터에서 별칭 IP 주소로 구현됩니다.

클러스터의 모든 노드, 포드, 서비스를 수용할 수 있을 만한 IP 주소 범위를 선택하세요.

다음 제한사항을 고려하세요.

• 기본 IP 주소 범위를 확장할 수는 있지만 줄일 수는 없습니다. 이러한 IP 주소 범위는 연속되어야 합니다.
• 클러스터에 포드 범위를 추가하거나 다른 보조 포드 범위로 새 노드 풀을 만들어 포드 범위를 확장할 수 있습니다.
• 서비스의 보조 IP 주소 범위는 클러스터 수명 동안 확장하거나 변경할 수 없습니다.
• 포드 및 서비스의 보조 IP 주소 범위 제한사항을 검토하세요.

비공개 RFC 1918 IP 주소를 2개 이상 사용

일부 환경에서는 대규모 연속 CIDR 블록의 RFC 1918 공간이 이미 조직에 할당되었을 수 있습니다. Google 소유의 공개 IP 주소와 겹치지 않는 경우 GKE 클러스터의 추가 CIDR에 대해 RFC 1918이 아닌 공간을 사용할 수 있습니다. 클래스 E 주소 공간은 온프레미스 하드웨어와의 상호 운용성 문제가 발생할 수 있으므로 RFC 주소 공간의 100.64.0.0/10 부분을 사용하는 것이 좋습니다. 비공개로 재사용되는 공개 IP(PUPI)를 사용할 수 있습니다.

비공개로 사용되는 공개 IP 주소를 사용할 때는 주의해야 하고 이 옵션을 선택할 때 온프레미스 네트워크에서 인터넷으로 경로 공지를 제어해 보세요.

포드 간 및 포드-서비스 트래픽이 있는 클러스터에서 소스 네트워크 주소 변환(SNAT)을 사용해서는 안 됩니다. 그러면 Kubernetes 네트워킹 모델이 중단됩니다.

Kubernetes는 모든 RFC 1918 이외의 IP 주소가 비공개로 재사용되는 공개 IP 주소라고 가정하고 이러한 주소에서 시작되는 모든 트래픽에 SNAT를 사용합니다.

GKE 클러스터, Standard 클러스터에 RFC 1918 이외의 IP 주소를 사용하는 경우 SNAT를 명시적으로 사용 중지하거나 IP 매스커레이드 에이전트를 구성하여 클러스터의 포드 IP 주소와 서비스의 보조 IP 주소 범위를 SNAT에서 제외해야 합니다. Autopilot 클러스터의 경우 추가 단계가 필요하지 않습니다.

커스텀 서브넷 모드 사용

네트워크를 설정할 때 서브넷 모드 auto(기본) 또는 custom(권장)도 선택합니다. auto 모드는 서브넷 할당을 Google에 맡기고 IP 주소 계획 없이 시작할 수 있는 좋은 옵션입니다. 하지만 이 모드에서는 환경의 다른 범위와 겹치지 않는 IP 주소 범위를 선택할 수 있으므로 custom 모드를 선택하는 것이 좋습니다. 공유 VPC를 사용하는 경우 조직 관리자 또는 네트워크 관리자가 이 모드를 선택할 수 있습니다.

다음 예시에서는 커스텀 서브넷 모드로 my-net-1이라는 네트워크를 만듭니다.

gcloud compute networks create my-net-1 --subnet-mode custom

노드당 포드 밀도 계획

기본적으로 Standard 클러스터는 서브넷의 포드 주소 공간 외의 모든 노드에 /24 범위를 예약하고 노드당 최대 110개의 포드를 허용합니다. 하지만 Standard 클러스터에서 모든 노드에 /23 범위를 예약하고 노드당 포드를 최대 256개까지 지원하도록 구성할 수 있습니다. 노드 크기와 포드의 애플리케이션 프로필에 따라 각 노드에서 상당히 적은 수의 포드를 실행할 수 있습니다.

노드당 64개 이상의 포드가 실행되는 것으로 예상되지 않는 경우 포드 서브넷의 IP 주소 공간을 보존하도록 노드당 최대 포드를 조정하는 것이 좋습니다.

노드당 포드 수가 기본 110개를 초과하여 실행될 것으로 예상되면 모든 노드에 예약된 /23을 사용하여 노드당 최대 포드 수를 256개까지 증가시킬 수 있습니다. 이러한 유형의 고밀도 포드 구성을 사용하는 경우 CPU 코어가 16개 이상 있는 인스턴스를 사용하여 클러스터의 확장성과 성능을 보장하는 것이 좋습니다.

Autopilot 클러스터의 경우 노드당 최대 포드 수는 32개로 설정되고 모든 노드에 /26 범위를 예약합니다. 이 설정은 Autopilot 클러스터에서 구성할 수 없습니다.

다른 환경에서 사용되는 IP 주소와 겹침 피하기

Cloud VPN 또는 Cloud Interconnect를 통해 VPC 네트워크를 온프레미스 환경 또는 다른 클라우드 서비스 제공업체에 연결할 수 있습니다. 이러한 환경은 경로를 공유할 수 있으므로 온프레미스 IP 주소 관리 체계가 GKE의 IP 주소 계획에 중요합니다. IP 주소가 다른 환경에서 사용되는 IP 주소와 겹치지 않는지 확인하는 것이 좋습니다.

부하 분산기 서브넷 만들기

내부 TCP/UDP 부하 분산으로 서비스를 노출하기 위해 별도의 부하 분산기 서브넷을 만드세요. 별도의 부하 분산기 서브넷을 사용하지 않는 경우, 이러한 서비스는 노드 서브넷의 IP 주소를 사용하여 노출되므로 해당 서브넷에서 이전의 할당된 모든 공간을 예상보다 빨리 사용하게 되어 GKE 클러스터를 예상 노드 수로 확장하지 못하게 될 수 있습니다.

또한 별도의 부하 분산기 서브넷을 사용하면 GKE 노드와의 트래픽을 각각 내부 TCP/UDP 부하 분산에 의해 노출되는 서비스에 별도로 필터링할 수 있으므로 보다 엄격한 보안 경계를 설정할 수 있습니다.

클러스터 자동 확장 처리에 필요한 IP 주소 공간 충분히 예약

클러스터 자동 확장 처리를 사용하여 클러스터의 노드를 동적으로 추가하거나 제거할 수 있으므로 비용을 관리하고 사용률을 개선할 수 있습니다. 하지만 클러스터 자동 확장 처리를 사용할 때는 IP 주소 계획에서 모든 노드 풀의 최대 크기를 고려해야 합니다. 각 새 노드에는 자체 노드 IP 주소와 구성된 노드당 포드를 기반으로 할당 가능한 자체 포드 IP 주소 세트가 필요합니다. 노드당 포드 수를 클러스터 수준에서 구성한 것과 다르게 구성할 수 있습니다. 클러스터 또는 노드 풀을 만든 후에는 노드당 포드 수를 변경할 수 없습니다. 최적의 IP 주소 할당을 위해 워크로드 유형을 고려하여 개별 노드 풀에 할당해야 합니다.

특히 VPC 기반 클러스터를 사용하는 경우 클러스터 자동 확장 처리와 함께 노드 자동 프로비저닝을 사용하는 것이 좋습니다. 자세한 내용은 노드 제한 범위를 참고하세요.

클러스터 간 IP 주소 공유

클러스터의 인프라를 관리하는 중앙 팀이 있는 경우 클러스터 간에 IP 주소를 공유해야 할 수 있습니다. GKE 클러스터 간에 IP 주소를 공유하려면 GKE 클러스터 간 IP 주소 범위 공유를 참조하세요. 포드, 서비스, 노드에 대한 세 개의 범위를 만들고 재사용하거나 공유하는 식으로, 특히 공유 VPC 모델에서 IP 소모를 줄일 수 있습니다. 또한 이 설정을 사용하면 네트워크 관리자가 각 클러스터에서 특정 서브넷을 만들지 않아도 되므로 IP 주소를 관리하기가 쉬워집니다.

다음 사항을 고려하세요.

• 모든 클러스터에 별도의 서브넷 및 IP 주소 범위를 사용하는 것이 가장 좋습니다.
• 보조 포드 IP 주소 범위를 공유할 수 있지만 한 클러스터가 모든 IP 주소를 사용할 수 있으므로 권장되지 않습니다.
• 보조 서비스 IP 주소 범위를 공유할 수 있지만 이 기능은 GKE용 VPC 범위 Cloud DNS와 함께 작동하지 않습니다.

포드 IP 주소가 부족할 경우 연속되지 않은 멀티 포드 CIDR을 사용하여 추가 포드 IP 주소 범위를 만들 수 있습니다.

내부 LoadBalancer 서비스의 IP 주소 공유

여러 포트를 사용하여 단일 IP 주소를 최대 50개의 백엔드와 공유할 수 있습니다. 이렇게 하면 내부 LoadBalancer 서비스에 필요한 IP 주소 수가 줄어듭니다.

자세한 내용은 공유 IP를 참조하세요.

네트워크 보안 옵션

이 섹션에서는 클러스터 격리를 위한 몇 가지 주요 권장사항을 설명합니다. GKE 클러스터의 네트워크 보안은 Google과 클러스터 관리자 간의 공동 책임입니다.

GKE Dataplane V2 사용

GKE Dataplane V2는 eBPF를 기반으로 하며 통합 네트워크 보안 및 가시성 환경을 제공합니다. GKE Dataplane V2에서 서비스 라우팅, 네트워크 정책 적용, 로깅을 관리하므로 GKE Dataplane V2를 사용하여 클러스터를 만들 때 네트워크 정책을 명시적으로 사용 설정할 필요가 없습니다. 클러스터를 만들 때 Google Cloud CLI --enable-dataplane-v2 옵션을 사용하여 새 데이터 플레인을 사용 설정합니다. 네트워크 정책을 구성한 후에는 기본 NetworkLogging CRD 객체를 구성하여 허용 및 거부된 네트워크 연결을 로깅할 수 있습니다. 네트워크 정책 로깅과 같은 기본 제공 기능을 최대한 활용하려면 GKE Dataplane V2로 클러스터를 만드는 것이 좋습니다.

비공개 클러스터 유형 선택

공개 클러스터에는 노드의 비공개 IP 주소와 공개 IP 주소가 모두 있고 컨트롤 플레인 노드의 공개 엔드포인트만 있습니다. 비공개 클러스터는 노드에 내부 IP 주소만 가지고 있고 컨트롤 플레인 노드에 비공개 또는 공개 엔드포인트를 가지므로 더 많은 격리를 제공합니다(더 격리 가능하며 클러스터 컨트롤 플레인 노출 최소화 섹션에 설명됨). 비공개 클러스터에서 비공개 Google 액세스를 사용하여 Google API에 계속 액세스할 수 있습니다. 비공개 클러스터를 선택하는 것이 좋습니다.

비공개 클러스터에서 포드는 인바운드 및 아웃바운드 통신(클러스터 경계)에서 격리됩니다. 이 문서의 클러스터 연결 섹션에서 설명된 대로 부하 분산 및 Cloud NAT를 사용하여 서비스를 노출시켜 이러한 방향 흐름을 제어할 수 있습니다. 다음 다이어그램에서는 이러한 유형의 설정을 보여줍니다.

이 다이어그램은 비공개 클러스터가 통신하는 방법을 보여줍니다. 온프레미스 클라이언트는 kubectl 클라이언트로 클러스터에 연결할 수 있습니다. Google 서비스에 대한 액세스는 비공개 Google 액세스를 통해 제공되며 인터넷 통신은 Cloud NAT를 사용하는 경우에만 가능합니다.

자세한 내용은 비공개 클러스터의 요구사항, 제한사항 및 제한을 참조하세요.

클러스터 컨트롤 플레인 노출 최소화

비공개 클러스터에서 GKE API 서버는 공개 또는 비공개 엔드포인트로 노출될 수 있습니다. 클러스터를 만들 때 사용할 엔드포인트를 결정할 수 있습니다. 승인된 네트워크를 사용하여 액세스를 제어할 수 있으며, 여기에서는 공개 엔드포인트와 비공개 엔드포인트가 모두 기본적으로 클러스터의 포드와 노드 IP 주소 간의 모든 통신을 허용합니다. 클러스터를 만들 때 비공개 엔드포인트를 사용 설정하려면 --enable-private-endpoint 플래그를 사용합니다.

컨트롤 플레인에 대한 액세스 승인

승인된 네트워크는 GKE 컨트롤 플레인 노드에 액세스할 수 있는 IP 주소 서브넷을 결정하는 데 도움이 됩니다. 이러한 네트워크를 사용 설정한 후에는 특정 소스 IP 주소 범위에 대한 액세스를 제한할 수 있습니다. 공개 엔드포인트가 사용 중지된 경우 이러한 소스 IP 주소 범위는 비공개여야 합니다. 공개 엔드포인트가 사용 설정된 경우 공개 또는 내부 IP 주소 범위를 허용할 수 있습니다. 온프레미스 환경에서 클러스터 컨트롤 플레인의 비공개 엔드포인트에 연결할 수 있도록 커스텀 경로 공지를 구성합니다. 클러스터를 만들 때 --enable-master-global-access 옵션을 사용하여 비공개 GKE API 엔드포인트에 전역적으로 연결할 수 있도록 설정할 수 있습니다.

다음 다이어그램은 승인된 네트워크를 사용하는 일반적인 컨트롤 플레인 연결을 보여줍니다.

이 다이어그램은 신뢰할 수 있는 사용자가 승인된 네트워크의 일부이므로 공개 엔드포인트를 통해 GKE 컨트롤 플레인과 통신할 수 있는 것을 보여주며 반면에 신뢰할 수 없는 행위자의 액세스는 차단됩니다. GKE 클러스터와 주고받는 통신은 컨트롤 플레인의 비공개 엔드포인트를 통해 이루어집니다.

컨트롤 플레인 연결 허용

모든 워커 노드의 특정 시스템 포드가 Kubernetes API 서버(kube-apiserver), Google API, 또는 메타데이터 서버와 같은 서비스에 연결되어야 합니다. 또한 kube-apiserver는 특별히 event-exporter와 같은 일부 시스템 포드와 통신해야 합니다. 이 통신은 기본적으로 허용됩니다. 프로젝트 내에 VPC 방화벽 규칙을 배포하는 경우(클러스터 트래픽 제한 섹션에서 자세한 내용 확인) 이러한 포드가 Google API뿐 아니라 kube-apiserver에도 계속 통신할 수 있는지 확인합니다.

피어링된 네트워크에서 컨트롤 플레인 액세스를 위한 프록시 배포

비공개 GKE 클러스터의 컨트롤 플레인에 대한 액세스는 VPC 네트워크 피어링을 통해 이루어집니다. VPC 네트워크 피어링은 전환할 수 없으므로 다른 피어링된 네트워크에서 클러스터의 컨트롤 플레인에 액세스할 수 없습니다.

허브 및 스포크 아키텍처를 사용할 때 다른 피어링된 네트워크 또는 온프레미스에서 직접 액세스하려는 경우 컨트롤 플레인 트래픽용 프록시를 배포합니다.

네트워크 정책을 사용하여 클러스터 트래픽 제한

VPC 방화벽 규칙, 계층적 방화벽 정책, Kubernetes 네트워크 정책 등 결합할 수 있는 클러스터 워크로드에 여러 수준의 네트워크 보안을 사용할 수 있습니다. VPC 방화벽 규칙 및 계층적 방화벽 정책은 GKE 클러스터의 포드가 있는 워커 노드인 가상 머신(VM) 수준에서 적용됩니다. Kubernetes 네트워크 정책은 포드 수준에서 적용되어 포드 간 트래픽 경로를 적용합니다.

VPC 방화벽을 구현하면 기본 필수 컨트롤 플레인 통신(예: 컨트롤 플레인과의 kubelet 통신)을 끊을 수 있습니다. GKE는 기본적으로 필수 방화벽 규칙을 만들지만 덮어쓸 수 있습니다. 일부 배포의 경우 서비스의 클러스터에 도달하기 위해 컨트롤 플레인이 필요할 수도 있습니다. VPC 방화벽을 사용하여 서비스에 액세스할 수 있는 인그레스 정책을 구성할 수 있습니다.

GKE 네트워크 정책은 Kubernetes 네트워크 정책 API를 통해 구성되며, 클러스터의 포드 통신을 시행합니다. 클러스터를 만들 때 gcloud container clusters create 옵션 --enable-network-policy을(를) 사용하여 네트워크 정책을 사용 설정할 수 있습니다. 네트워크 정책을 사용하여 트래픽을 제한하려면 Anthos 트래픽 제한 세부 계획 구현 가이드를 따르세요.

인그레스에 Google Cloud Armor 보안 정책 사용 설정

Google Cloud Armor 보안 정책을 사용하면 네트워크 경계에서 DDoS 공격 및 기타 웹 기반 공격 트래픽을 차단함으로써 외부 애플리케이션 부하 분산기를 사용하는 애플리케이션을 공격으로부터 보호할 수 있습니다. GKE에서 외부 애플리케이션 부하 분산기용 인그레스를 사용하고 인그레스 객체에 연결된 BackendConfig에 보안 정책을 추가하여 애플리케이션에 대한 Google Cloud Armor 보안 정책을 사용 설정하세요.

IAP(Identity-Aware Proxy)를 사용하여 IAM 사용자 애플리케이션에 인증 제공

기업 네트워크에 있을 필요 없이 조직 내부 사용자만 액세스할 수 있는 서비스를 배포하려면 IAP(Identity-Aware Proxy)를 사용하여 이런 어플리케이션에 대한 인증 레이어를 생성합니다. GKE용 IAP(Identity-Aware Proxy)를 사용 설정하려면 구성 단계를 따라 서비스 인그레스의 BackendConfig의 일부로 IAP(Identity-Aware Proxy)를 추가합니다. IAP(Identity-Aware Proxy)는 Google Cloud Armor와 결합될 수 있습니다.

조직 정책 제약조건을 사용하여 보안 강화

조직 정책 제약조건을 사용하면 보안 상태를 더욱 강화할 수 있는 정책을 설정할 수 있습니다. 예를 들어 제약조건을 사용하여 내부 부하 분산기만과 같은 특정 유형으로 부하 분산기 생성을 제한할 수 있습니다.

클러스터 연결 확장

이 섹션에서는 클러스터에서 인터넷 및 Google 서비스로의 DNS 및 아웃바운드 연결에 대해 확장 가능한 옵션을 설명합니다.

GKE용 Cloud DNS 사용

GKE용 Cloud DNS를 사용하여 클러스터 호스팅 DNS 제공업체 없이 관리형 DNS로 포드 및 서비스 DNS 변환을 제공할 수 있습니다. Cloud DNS는 클러스터 호스팅 DNS 서버 관리의 오버헤드를 제거하며, 호스팅되는 Google 서비스이므로 DNS 인스턴스를 확장, 모니터링 또는 관리할 필요가 없습니다.

NodeLocal DNSCache 사용 설정

GKE는 클러스터의 로컬 DNS 서비스를 기본 클러스터 부가기능으로 제공하기 위해 kube-dns를 사용합니다. kube-dns는 클러스터에 있는 총 코어 및 노드 수의 함수로 클러스터 전체에 복제됩니다.

NodeLocal DNSCache로 DNS 성능을 향상시킬 수 있습니다. NodeLocal DNSCache는 DaemonSet로 배포되는 부가기능으로, 어떤 포드 구성도 변경할 필요가 없습니다. 로컬 포드 서비스에 대한 DNS 조회는 노드에서 범위 확장을 감안한 추적해야 하는 개방형 연결을 만들지 않습니다. 외부 호스트 이름 조회가 Cloud DNS로 전달되는 반면 다른 모든 DNS 쿼리는 kube-dns로 이동합니다.

보다 일관적인 DNS 쿼리 조회 시간을 개선하고 클러스터 확장을 개선하기 위해 NodeLocal DNSCache를 사용 설정하세요. Autopilot 클러스터의 경우 NodeLocal DNSCache가 기본적으로 사용 설정되며 이 설정은 재정의할 수 없습니다.

--addons NodeLocalDNS. Google Cloud CLI 옵션은 클러스터를 만들 때 NodeLocal DNSCache를 사용 설정합니다.

애플리케이션에서 해결하려는 이름을 제어할 경우 DNS 확장을 개선할 수 있는 방법이 있습니다. 예를 들어 FQDN(호스트 이름을 마침표로 종료)을 사용하거나 Pod.dnsConfig 매니페스트 옵션을 통해 검색 경로 확장을 사용 중지합니다.

비공개 클러스터에서 인터넷 액세스에 Cloud NAT 사용

기본적으로 비공개 클러스터는 인터넷에 액세스할 수 없습니다. 포드가 인터넷에 연결될 수 있도록 각 리전에 Cloud NAT를 사용 설정합니다. 최소한 GKE 서브넷의 기본 및 보조 범위에 Cloud NAT를 사용 설정합니다. Cloud NAT용 IP 주소와 VM당 포트를 충분히 할당했는지 확인합니다.

비공개 클러스터에 Cloud NAT를 사용하는 동안 다음 Cloud NAT 게이트웨이 구성 권장사항을 따르세요.

• Cloud NAT 게이트웨이를 만들 때는 클러스터에서 사용하는 서브넷 범위로 한정하여 사용 설정합니다. 모든 클러스터의 모든 노드를 계수하여 프로젝트에 있는 NAT 소비자 VM의 수를 알 수 있습니다.

• 동적 포트 할당을 사용하여 VM 사용량에 따라 VM별로 다른 포트 수를 할당합니다. 최소 포트 64개, 최대 포트 2,048개로 시작합니다.

• 동일한 대상 3-튜플에 대한 여러 개의 동시 연결을 관리해야 하는 경우 TCP TIME_WAIT 제한 시간을 기본값인 120s에서 5s(으)로 줄입니다. 자세한 내용은 NAT 제한 시간 변경을 참조하세요.

• Cloud NAT 오류 로깅을 사용 설정하여 관련 로그를 확인합니다.

• 게이트웨이를 구성한 후 Cloud NAT 게이트웨이 로그를 확인합니다. 할당 상태가 삭제되는 문제를 줄이려면 VM당 최대 포트 수를 늘려야 할 수 있습니다.

포드 트래픽에 대해서는 두 개의 SNAT를 사용하지 않도록 해야 합니다(GKE 노드에서 먼저 SNAT를 사용한 다음 Cloud NAT 다시 사용). SNAT가 Cloud VPN 또는 Cloud Interconnect로 연결된 온프레미스 네트워크에 대해 포드 IP 주소를 숨겨야 하는 경우가 아니라면 확장성을 위해 disable-default-snat를 적용하고 SNAT 추적을 Cloud NAT로 오프로드합니다. 이 솔루션은 모든 기본 및 보조 서브넷 IP 범위에서 작동합니다. Cloud NAT를 사용 설정한 후 네트워크 정책을 사용하여 외부 트래픽을 제한합니다. Google 서비스에 액세스하는 데에는 Cloud NAT가 필요하지 않습니다.

비공개 Google 액세스를 사용하여 Google 서비스에 액세스

비공개 클러스터에서는 포드가 Google API 및 서비스를 포함한 공개 서비스에 연결할 수 있는 공개 IP 주소가 없습니다. 비공개 Google 액세스를 사용하면 비공개 Google Cloud 리소스가 Google 서비스에 도달할 수 있습니다.

비공개 Google 액세스는 공유 VPC 클러스터를 제외하고 비공개 클러스터에서 기본적으로 사용 설정됩니다.

애플리케이션 제공

조직 외부 또는 내부에 연결할 수 있는 애플리케이션을 만들 때는 올바른 부하 분산기 유형과 옵션을 사용해야 합니다. 이 섹션에서는 Cloud Load Balancing을 사용하여 애플리케이션을 노출하고 확장하는 방법에 대한 몇 가지 권장사항을 제공합니다.

컨테이너 기반 부하 분산 사용

HTTP(S)를 외부에서 사용하여 서비스를 노출할 때 컨테이너 기반 부하 분산을 사용합니다. 컨테이너 기반 부하 분산을 통해 네트워크 홉 수를 줄이고 지연 시간을 줄이며 더 정확한 트래픽 분산을 수행할 수 있습니다. 또한 왕복 시간에서 가시성을 높이고 Google Cloud Armor와 같은 부하 분산 기능을 사용하도록 합니다.

애플리케이션을 노출할 올바른 GKE 리소스 선택

클라이언트 범위(내부, 외부, 또는 심지어 cluster-internal까지), 애플리케이션 리전, 사용하는 프로토콜에 따라 애플리케이션 노출 사용에 선택할 수 있는 다양한 GKE 리소스가 존재합니다. 서비스 네트워킹 개요에서는 이러한 옵션을 설명하고 Google Cloud 부하 분산 옵션을 사용하여 애플리케이션의 각 부분을 노출할 최적의 리소스를 선택하는 데 도움을 얻을 수 있습니다.

BackendConfig를 기반으로 상태 점검 만들기

인그레스를 사용하여 서비스를 노출하는 경우 BackendConfig CRD의 상태 점검 구성을 사용하여 외부 애플리케이션 부하 분산기의 상태 점검 기능을 이용하세요. 사용자는 적절한 엔드포인트로 상태 점검을 보내고 직접 기준점을 설정할 수 있습니다. BackendConfig CRD가 없으면 준비 상태 프로브 매개변수에서 상태 점검을 추론하거나 기본 매개변수를 사용합니다.

로컬 트래픽 정책을 사용하여 기존 IP 주소 보존

GKE와 함께 내부 패스 스루 네트워크 부하 분산기를 사용하는 경우 externalTrafficPolicy 옵션을 Local로 설정하여 요청의 소스 IP 주소를 보존합니다. 애플리케이션에 원본 소스 IP 주소가 필요한 경우 이 옵션을 사용하세요. 하지만 externalTrafficPolicy local 옵션을 사용하면 부하 분산이 덜 최적화될 수 있으므로 필요한 경우에만 이 기능을 사용하세요. HTTP(S) 서비스의 경우 HTTP 요청에서 X-Forwarded-For 헤더를 읽어 인그레스 컨트롤러를 사용하고 원본 IP 주소를 가져올 수 있습니다.

Private Service Connect 사용

Private Service Connect를 사용하여 다른 VPC 네트워크 간에 내부 패스 스루 네트워크 부하 분산기 서비스를 공유할 수 있습니다. 이는 GKE 클러스터에서 호스팅되지만 다양한 프로젝트 및 다양한 VPC에서 실행되는 고객에게 제공되는 서비스로 유용합니다.

Private Service Connect를 사용하면 IP 주소가 겹치는 VPC 간에 연결을 제공하여 IP 주소 소비를 줄일 수 있습니다.

작업 및 관리

다음 섹션에는 워크로드에 대한 세부 승인 옵션을 보장하는 데 도움이 되는 운영 권장사항이 포함되어 있습니다. 수동 방화벽 규칙을 만들지 않으려면 이 섹션의 운영 권장사항을 따르세요. 여기에는 워크로드를 배포하고 GKE에서 모니터링 및 로깅을 위한 권장사항도 포함됩니다.

GKE용 IAM 권한을 사용하여 공유 VPC 네트워크의 정책 제어

공유 VPC 네트워크를 사용하면 부하 분산기의 방화벽 규칙이 호스트 프로젝트에 자동으로 생성됩니다.

방화벽 규칙을 수동으로 만들지 않으려면 service-HOST_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com이라는 호스트 프로젝트의 GKE 서비스 계정에 최소 권한 커스텀 역할을 할당합니다.

HOST_PROJECT_NUMBER를 공유 VPC 호스트 프로젝트의 프로젝트 번호로 바꿉니다.

생성하는 커스텀 역할은 다음 권한을 보유해야 합니다.

• compute.firewalls.create
• compute.firewalls.get
• compute.firewalls.list
• compute.firewalls.delete

또한 GKE에서 생성되는 방화벽 규칙은 항상 기본 우선순위가 1000이므로 우선순위가 더 높은 방화벽 규칙을 만들어 특정 트래픽이 통과되지 않도록 할 수 있습니다.

특정 부하 분산기 유형의 생성을 제한하려면 부하 분산기 생성 제한에 대한 조직 정책을 사용합니다.

고가용성을 위해 리전 클러스터를 사용하여 워크로드 배포

클러스터 컨트롤 플레인과 노드가 여러 영역에 분산되므로 리전 클러스터는 클러스터의 애플리케이션 가용성을 높일 수 있습니다.

또한 포드 안티어피니티를 사용하여 지정된 서비스의 포드가 여러 영역에 예약되도록 할 수 있습니다.

고가용성 및 비용 최적화를 위해 이러한 설정을 구성하는 방법에 대한 자세한 내용은 고가용성 GKE 클러스터 권장사항을 참조하세요.

Cloud Logging 및 Cloud Monitoring을 사용하고 네트워크 정책 로깅을 사용 설정

조직마다 가시성과 감사에 대한 요구사항이 다르므로 네트워크 정책 로깅을 사용 설정하는 것이 좋습니다. 이 기능은 GKE Dataplane V2에서만 사용할 수 있습니다. 네트워크 정책 로깅은 정책 시행 및 포드 트래픽 패턴을 보여줍니다. 네트워크 정책 로깅과 관련된 비용이 발생합니다.

버전 1.14 이상을 사용하는 GKE 클러스터의 경우, Logging 및 Monitoring이 모두 기본적으로 사용 설정됩니다. Monitoring은 GKE 클러스터에 대한 대시보드를 제공합니다. Logging은 또한 VPC 흐름 로그의 GKE 주석을 사용 설정합니다. 기본적으로 Logging은 클러스터에 배포된 모든 워크로드의 로그를 수집하지만 시스템 전용 로그 옵션도 있습니다. GKE 대시보드를 사용하여 관찰하고 알림을 설정합니다. Autopilot 모드에서 생성된 클러스터의 경우 Monitoring 및 Logging이 자동으로 사용 설정되며 구성할 수 없습니다.

Google Cloud Observability와 관련된 비용이 발생합니다.

체크리스트 요약

다음 단계

• GKE 권장사항 통계

• 기업 멀티테넌시 권장사항

• 인그레스 및 서비스를 통해 GKE 애플리케이션 노출

• VPC 설계에 관한 권장사항 및 참조 아키텍처