단일 스택 IPv6 클러스터 만들기 및 관리

이 문서에서는 Google Kubernetes Engine(GKE)에서 단일 스택 IPv6 클러스터를 만들고 구성하고 관리하는 방법을 설명합니다.

IPv6 전용 네트워킹 환경에서 컨테이너화된 워크로드를 실행하여 비공개 IPv4 주소 공간(RFC 1918)이 소진되지 않도록 할 수 있습니다. 단일 스택 IPv6 클러스터를 배포할 때는 내부 및 외부 리소스에 대한 인그레스 및 이그레스 연결을 유지하면서 포드, 노드, 서비스에 IPv6 주소만 할당합니다.

개요

워크로드가 확장되고 클러스터 밀도가 증가함에 따라 비공개 IPv4 주소 공간이 빠르게 소진될 수 있습니다. IPv4 전용 및 이중 스택 클러스터에서 모든 포드에는 IPv4 주소가 필요하므로 VPC 네트워크 전반에 CIDR 블록을 할당하는 것이 주요 확장 병목 현상이 될 수 있습니다.

GKE 단일 스택 IPv6 클러스터에서는 클러스터 데이터 영역 전체에 IPv6 주소를 독점적으로 할당하여 IPv4 주소 제약 조건을 완전히 제거합니다. 워커 노드는 단일 스택 IPv6 Compute Engine VM 인스턴스에서 실행되며 포드와 서비스는 IPv6 연결을 통해 통신합니다.

IP 주소 할당(IPAM)

단일 스택 IPv6 클러스터는 다음 프리픽스 크기를 사용하여 서브네트워크, 노드, 포드, 서비스에 IPv6 주소를 할당합니다.

리소스 CIDR 블록 프리픽스 설명
서브네트워크 /64 IPv6 전용 서브네트워크 CIDR 블록으로 지정됩니다.
노드 /96 GKE가 서브네트워크 CIDR 블록에서 자동으로 할당하며, 노드당 약 42억 9천만 개의 고유 IPv6 주소를 제공합니다.
포드 /112 노드의 /96 하위 범위의 하위 집합에서 할당됩니다.
서비스 /64 2600:2D00:0:4::0:0/64 IPv6 주소 범위에서 ClusterIP 서비스에 대해 GKE에 의해 자동으로 할당됩니다.

외부 및 내부 IPv6 액세스 유형

클러스터 서브네트워크를 설정할 때 두 가지 IPv6 액세스 유형 중에서 선택하여 인터넷 라우팅 가능성을 제어할 수 있습니다.

  • 내부(ULA): INTERNAL 액세스 유형이 있는 서브네트워크는 fd20::/20 범위 내에서 고유한 로컬 유니캐스트 주소(ULA)를 사용합니다. 통신 범위는 VPC 네트워크, 피어링 네트워크, 하이브리드 연결로 지정됩니다. 노드와 포드는 공개 IPv6 인터넷 리소스에 직접 연결하거나 직접 인터넷 인그레스를 수신할 수 없습니다.
  • 외부(GUA): EXTERNAL 액세스 유형이 있는 서브네트워크는 전역 유니캐스트 주소(GUA)를 사용합니다. 노드와 포드에는 전역적으로 고유한 IPv6 주소가 할당되며 VPC 방화벽 규칙 및 라우팅 테이블에 따라 인그레스와 이그레스 모두에서 공개 IPv6 인터넷 리소스와 통신할 수 있습니다.

시작하기 전에

시작하기 전에 다음 태스크를 수행했는지 확인합니다.

  • Google Kubernetes Engine API를 사용 설정합니다.
  • Google Kubernetes Engine API 사용 설정
  • 이 태스크에 Google Cloud CLI를 사용하려면 gcloud CLI를 설치한 후 초기화합니다. 이전에 gcloud CLI를 설치했으면 gcloud components update 명령어를 실행하여 최신 버전을 가져옵니다. 이전 gcloud CLI 버전에서는 이 문서의 명령어를 실행하지 못할 수 있습니다.

요구사항 및 제한사항

단일 스택 IPv6 클러스터를 사용하려면 다음 요구사항 및 제한사항을 충족해야 합니다.

  • 클러스터는 GKE 버전 1.37.1-gke.3020000 이상을 실행해야 합니다.
  • 클러스터는 GKE Dataplane V2를 사용하는 VPC 기반 클러스터여야 합니다. 단일 스택 IPv6 클러스터는 경로 기반 클러스터를 지원하지 않습니다.
  • 단일 스택 IPv6 클러스터는 단일 스택 IPv6 VM 인스턴스만 워커 노드로 지원하며 혼합 또는 이중 스택 노드 풀을 지원하지 않습니다.
  • Cloud DNS를 클러스터 DNS 제공업체(--cluster-dns=clouddns)로 사용해야 합니다. 단일 스택 IPv6 클러스터는 kube-dns를 지원하지 않습니다.
  • 단일 스택 IPv6 클러스터의 컨트롤 플레인 액세스는 두 가지 경로를 사용합니다.
    • 외부 클라이언트: 클러스터 외부의 클라이언트(예: kubectl 사용)는 GKE 프런트엔드(GKFE)를 통해 도메인 기반 엔드포인트를 통해 컨트롤 플레인에 액세스합니다.
    • 내부 워크로드: 노드와 포드가 Private Service Connect를 통해 컨트롤 플레인에 안전하게 연결됩니다. 이 통신을 지원하려면 INTERNAL IPv6 액세스 유형(--private-endpoint-subnetwork)이 있는 서브네트워크를 제공하거나 만들어야 합니다.
  • 내부(INTERNAL) IPv6 서브네트워크에서 노드와 포드는 Cloud NAT 게이트웨이 없이 IPv6를 통해 Google API 및 Artifact Registry에 연결할 수 있습니다. 단, 다음 사항을 고려하세요.
    • 외부 IPv4 전용 엔드포인트(예: 외부 IPv4 전용 컨테이너 레지스트리)에 연결하려면 DNS64 및 Cloud NAT(NAT64)를 구성해야 합니다.
    • 고유 로컬 주소(ULA)는 공개 IPv6 인터넷에서 라우팅할 수 없고 Cloud NAT는 IPv6-IPv6(NAT66) 변환을 지원하지 않으므로 INTERNAL 서브네트워크의 노드와 포드는 Google 외부의 공개 IPv6 엔드포인트에 연결할 수 없습니다.
  • 단일 스택 IPv6 클러스터는 --private-ipv6-google-access-type 및 --enable-private-nodes 클러스터 플래그를 지원하지 않습니다. 대신 VPC 서브네트워크에서 직접 비공개 Google 액세스 및 IPv6 액세스 유형(INTERNAL 또는 EXTERNAL)을 구성합니다.
  • 단일 스택 IPv6 클러스터는 멀티 서브넷 구성을 지원하지 않습니다.
  • 단일 스택 IPv6 클러스터는 GKE 인그레스를 지원하지 않습니다. 레이어 7 애플리케이션 부하 분산기를 구성하려면 Gateway API를 사용합니다.
  • GKE 멀티 네트워킹 API는 IPv6 포드 네트워크를 지원하지 않습니다. 보조 포드 네트워크는 IPv4 전용이어야 합니다. 자세한 내용은 포드의 멀티 네트워크 지원을 참조하세요.
  • IPv6 전용 클러스터는 Cloud Service Mesh를 지원하지 않습니다.
  • 단일 스택 IPv6 클러스터에서 자체 IPv6 주소 사용(BYOIPv6)을 사용할 수 있습니다. BYOIPv6 프리픽스에 적용되는 요구사항을 알아보려면 IPv6 하위 프리픽스 만들기 및 사용을 참조하세요.

워크로드 메타데이터 서버 구성

IPv6 전용 포드에서 실행되는 워크로드는 표준 IPv4 메타데이터 서버 주소(169.254.169.254)에 연결할 수 없으므로 다음 조정을 적용합니다.

  • 도메인 이름 metadata.google.internal(권장) 또는 리터럴 ULA IPv6 주소 [fd20:ce::254]를 사용하여 메타데이터 서버에 액세스하도록 애플리케이션 및 클라이언트 라이브러리를 구성합니다.
  • 하드코딩된 IPv4 메타데이터 서버 엔드포인트가 있는 클라이언트 라이브러리 또는 애플리케이션(예: 이전 버전의 Google API 클라이언트 라이브러리)을 사용하는 경우 컨테이너 이미지 또는 포드 사양에서 GCE_METADATA_HOST 환경 변수를 설정합니다.

    env:
    - name: GCE_METADATA_HOST
      value: "metadata.google.internal"
    

단일 스택 IPv6 클러스터 만들기

Google Cloud CLI를 사용하여 단일 스택 IPv6 클러스터를 만들 수 있습니다.

클러스터 및 서브네트워크 동시에 만들기

기존 커스텀 서브네트워크가 없는 경우 표준 단일 스택 IPv6 클러스터를 만들고 GKE가 단일 명령어로 필요한 노드 서브네트워크와 --private-endpoint-subnetwork을 자동으로 프로비저닝하도록 할 수 있습니다.

다음 명령어를 실행합니다.

gcloud beta container clusters create CLUSTER_NAME \
    --cluster-version=VERSION \
    --enable-dataplane-v2 \
    --cluster-dns=clouddns \
    --stack-type=ipv6 \
    --network=NETWORK_NAME \
    --create-subnetwork name=SUBNET_NAME \
    --ipv6-access-type=ACCESS_TYPE \
    --location=COMPUTE_LOCATION

다음을 바꿉니다.

  • CLUSTER_NAME: 새 클러스터의 이름입니다.
  • VERSION: GKE 버전 1.37.1-gke.3020000 이상
  • NETWORK_NAME: 기존 커스텀 모드 VPC 네트워크의 이름입니다.
  • SUBNET_NAME: 만들 새 노드 서브네트워크의 이름입니다.
  • ACCESS_TYPE: 서브네트워크의 인터넷 라우팅 가능 여부입니다. 비공개 ULA 주소 지정의 경우 INTERNAL를 지정하고 공개 GUA 주소 지정의 경우 EXTERNAL를 지정합니다. 생략하면 기본값은 EXTERNAL입니다.
  • COMPUTE_LOCATION: 클러스터의 컴퓨팅 리전 또는 영역입니다.

커스텀 서브네트워크에 Standard 클러스터 만들기

기존 또는 커스텀 서브네트워크를 사용하려면 클러스터를 만들기 전에 VPC 네트워크, PSC 컨트롤 플레인 서브네트워크, 노드 서브네트워크를 만듭니다.

  1. ULA 내부 IPv6 주소가 사용 설정된 커스텀 모드 VPC 네트워크를 만듭니다.

    gcloud compute networks create NETWORK_NAME \
        --subnet-mode=CUSTOM \
        --enable-ula-internal-ipv6
    
  2. 전용 내부 PSC 컨트롤 플레인 서브네트워크를 만듭니다.

    gcloud compute networks subnets create PSC_SUBNET_NAME \
        --stack-type=ipv6_only \
        --ipv6-access-type=INTERNAL \
        --network=NETWORK_NAME \
        --region=COMPUTE_REGION
    

    COMPUTE_REGION을 클러스터를 배포하는 리전으로 바꿉니다(예: us-central1). PSC 컨트롤 플레인 서브네트워크에 --stack-type=ipv4_ipv6을 지정할 수도 있습니다.

  3. 노드 서브네트워크를 만듭니다. 내부 액세스(INTERNAL) 또는 외부 액세스(EXTERNAL)를 선택합니다.

    gcloud compute networks subnets create NODE_SUBNET_NAME \
        --stack-type=ipv6_only \
        --ipv6-access-type=ACCESS_TYPE \
        --network=NETWORK_NAME \
        --region=COMPUTE_REGION
    
  4. 두 서브네트워크를 모두 참조하는 단일 스택 IPv6 표준 클러스터를 만듭니다.

    gcloud container clusters create CLUSTER_NAME \
        --cluster-version=VERSION \
        --enable-dataplane-v2 \
        --cluster-dns=clouddns \
        --stack-type=ipv6 \
        --network=NETWORK_NAME \
        --subnetwork=NODE_SUBNET_NAME \
        --private-endpoint-subnetwork=PSC_SUBNET_NAME \
        --location=COMPUTE_LOCATION
    

커스텀 서브네트워크에 Autopilot 클러스터 만들기

Autopilot 클러스터는 지정한 노드 서브네트워크에서 스택 유형을 자동으로 상속합니다. IPv6 전용 서브네트워크를 선택하면 GKE가 단일 스택 IPv6 Autopilot 클러스터를 만듭니다.

  1. 이전 섹션에 설명된 대로 커스텀 VPC 네트워크, 내부 PSC 서브네트워크, IPv6 전용 노드 서브네트워크를 만들었는지 확인합니다.

  2. Autopilot 클러스터를 만듭니다.

    gcloud container clusters create-auto CLUSTER_NAME \
        --cluster-version=VERSION \
        --network=NETWORK_NAME \
        --subnetwork=NODE_SUBNET_NAME \
        --private-endpoint-subnetwork=PSC_SUBNET_NAME \
        --location=COMPUTE_LOCATION
    

관리형 노드가 있는 Standard 클러스터 만들기

워크로드 수준에서 구성된 관리형 노드를 사용하는 단일 스택 IPv6 Standard 클러스터를 만들 수도 있습니다. Standard 클러스터에서 관리형 ComputeClass를 구성하는 방법에 대한 자세한 내용은 Standard 클러스터의 Autopilot 클래스를 참조하세요.

노드 및 포드에 자체 IPv6 주소 사용

노드와 포드가 Google 제공 주소 대신 자체 IPv6 주소 사용(BYOIPv6)을 사용하는 단일 스택 IPv6 클러스터를 만들 수 있습니다. 이렇게 하려면 공개 위임 프리픽스(PDP)의 리전 IPv6 하위 프리픽스에서 가져온 외부 IPv6 주소 범위로 노드 서브네트워크를 만듭니다. 그러면 노드와 포드가 해당 프리픽스에서 IPv6 주소를 수신하고 이러한 주소를 사용하여 인터넷 및 서로 통신합니다.

  1. EXTERNAL_IPV6_SUBNETWORK_CREATION 모드에서 공개 위임 프리픽스의 리전 IPv6 하위 프리픽스를 만듭니다. 자세한 내용은 IPv6 하위 프리픽스 만들기를 참조하세요.

  2. EXTERNAL IPv6 액세스 유형으로 노드 서브네트워크를 만들고 --ip-collection 플래그를 사용하여 하위 프리픽스를 참조합니다. Compute Engine은 하위 프리픽스에서 서브네트워크의 /64 IPv6 주소 범위를 할당합니다.

    gcloud compute networks subnets create NODE_SUBNET_NAME \
        --stack-type=ipv6_only \
        --ipv6-access-type=EXTERNAL \
        --ip-collection=SUB_PREFIX_NAME \
        --network=NETWORK_NAME \
        --region=COMPUTE_REGION
    

    SUB_PREFIX_NAME을 이전 단계에서 만든 하위 프리픽스의 이름으로 바꿉니다. 하위 프리픽스는 서브네트워크와 동일한 리전에 있어야 합니다. Compute Engine에서 할당하도록 하는 대신 하위 프리픽스에서 특정 /64 범위를 선택하려면 --external-ipv6-prefix 플래그를 추가합니다.

  3. 커스텀 서브네트워크에 Standard 클러스터 만들기 또는 커스텀 서브네트워크에 Autopilot 클러스터 만들기의 단계에 따라 이 노드 서브네트워크에 클러스터를 만듭니다. PSC 컨트롤 플레인 서브넷에는 BYOIPv6 주소 범위가 필요하지 않습니다.

  4. GKE가 클러스터를 만든 후 노드와 포드에 프리픽스의 IPv6 주소가 있는지 확인합니다.

    kubectl get nodes -o wide
    kubectl get pods --all-namespaces -o wide
    

다음 사항에 유의하세요.

  • 이 절차에서는 EXTERNAL IPv6 액세스 유형의 노드 서브네트워크를 사용하므로 노드와 포드가 프리픽스에서 전역적으로 라우팅 가능한 주소를 가져옵니다. INTERNAL_IPV6_SUBNETWORK_CREATION 모드에서 하위 프리픽스를 참조하여 INTERNAL IPv6 액세스 유형의 노드 서브네트워크를 사용할 수도 있습니다. 이 경우 노드와 포드는 내부 BYOIPv6 주소를 가져오고 내부 IPv6 액세스 유형의 연결 제한사항이 적용됩니다. 자세한 내용은 외부 및 비공개 리소스에 연결을 참조하세요.
  • LoadBalancer 서비스를 사용하여 BYOIPv6 주소에 워크로드를 노출하려면 자체 IPv6 주소 사용(BYOIPv6)을 참조하세요. BYOIPv6 노드 서브네트워크가 필요하지 않습니다.
  • BYOIPv6 프리픽스에 적용되는 요구사항은 IPv6 하위 프리픽스 만들기 및 사용을 참조하세요.

클러스터 스택 유형 확인

클러스터 생성이 완료되면 클러스터를 나열하여 클러스터가 단일 스택 IPv6 모드로 실행되는지 확인합니다.

gcloud beta container clusters list

출력에서 STACK_TYPE 열이 IPV6로 설정되었음을 확인할 수 있습니다.

NAME               LOCATION       MASTER_VERSION      MASTER_IP                                 MACHINE_TYPE  NODE_VERSION        NUM_NODES  STACK_TYPE  STATUS
v6-only-cluster-1  us-central1-c  1.37.0-gke.1000000  gke-3a3234-123456.us-central1-c.gke.goog  e2-medium     1.37.0-gke.1000000  1          IPV6        RUNNING

단일 스택 IPv6 클러스터의 부하 분산

레이어 7 및 레이어 4 부하 분산기를 모두 사용하여 단일 스택 IPv6 클러스터 내에서 실행되는 애플리케이션을 노출할 수 있습니다.

  • 레이어 7 애플리케이션 부하 분산(Gateway API): Kubernetes Gateway API를 사용하여 레이어 7 애플리케이션 부하 분산기(gke-l7-rilb, gke-l7-regional-external-managed 또는 gke-l7-global-external-managed)를 배포합니다. 이러한 게이트웨이는 내부 및 외부 IPv4 및 IPv6 클라이언트를 모두 지원하면서 트래픽을 내부 IPv6 전용 포드 엔드포인트로 투명하게 라우팅할 수 있습니다. GKE 인그레스는 단일 스택 IPv6 클러스터에서 지원되지 않습니다. 단일 스택 IPv6 클러스터에 리전 게이트웨이(gke-l7-rilb 및 gke-l7-regional-external-managed)를 배포할 때는 다음 서브네트워크 요구사항에 유의하세요.

    • 프록시 전용 서브네트워크: 단일 스택 IPv6 클러스터에서 리전 프록시 전용 서브네트워크(--purpose=REGIONAL_MANAGED_PROXY)는 이중 스택(--stack-type=IPV4_IPV6)이어야 합니다. IPv4 전용 및 이중 스택 클러스터에서 서브네트워크는 IPv4 전용 또는 이중 스택일 수 있습니다.
    • 게이트웨이 VIP 서브네트워크: 서브네트워크에서 VIP를 할당하지 않는 IPv4 리전 외부 게이트웨이와 달리 IPv6 리전 외부 게이트웨이(gke-l7-regional-external-managed)에는 EXTERNAL IPv6 액세스 권한이 있는 서브네트워크가 필요하고 리전 내부 게이트웨이(gke-l7-rilb)에는 INTERNAL IPv6 액세스 권한이 있는 서브네트워크(또는 내부 IPv4 VIP의 IPv4 범위)가 필요합니다. 클러스터의 노드 서브네트워크 대신 커스텀 서브네트워크에서 임시 리전 게이트웨이 VIP를 할당하려면 게이트웨이에 연결된 GCPGatewayPolicy의 spec.default.subnetwork 필드에 서브네트워크 이름을 지정합니다.

    구성 안내는 게이트웨이 배포를 참조하세요.

  • 레이어 4 패스 스루 부하 분산(서비스 API): type: LoadBalancer로 구성된 Kubernetes 서비스를 사용하여 IPv6 클라이언트에 워크로드를 노출할 수 있습니다. 클러스터 노드가 INTERNAL(ULA) 또는 EXTERNAL(GUA) 서브네트워크에서 실행되는지 여부에 따라 전용 부하 분산기 서브네트워크를 프로비저닝하고 networking.gke.io/load-balancer-subnet 주석을 사용하여 참조해야 할 수 있습니다.

외부 및 비공개 리소스에 연결

단일 스택 IPv6 클러스터의 워크로드는 인터넷을 통해 외부 서비스와 통신하거나 Google Cloud의 비공개 서비스와 통신해야 하는 경우가 많습니다.

공개 IPv6 인터넷 리소스에 연결

클러스터 노드가 EXTERNAL IPv6 액세스 유형(--ipv6-access-type=EXTERNAL)으로 구성된 서브네트워크에서 실행되는 경우 공개 인터넷 IPv6 엔드포인트에 대한 아웃바운드 이그레스 및 인그레스 연결이 기본적으로 사용 설정됩니다. VPC 방화벽 규칙이 필요한 IPv6 트래픽을 허용하는지 확인합니다. 자세한 내용은 VPC 방화벽 규칙 사용을 참조하세요.

공개 IPv4 인터넷 리소스에 연결(DNS64 및 NAT64)

단일 스택 IPv6 클러스터의 포드에는 IPv6 주소만 있으므로 공개 IPv4 전용 인터넷 엔드포인트에 연결하려면 네트워크 변환이 필요합니다. VPC 네트워크에서 Cloud DNS 및 Cloud NAT를 구성하여 자동 DNS64 및 NAT64 변환을 제공할 수 있습니다.

  1. DNS64 서버 정책을 만듭니다.

    gcloud dns policies create POLICY_NAME \
        --description="DNS64 policy for single-stack IPv6 cluster" \
        --networks=NETWORK_NAME \
        --enable-dns64-all-queries
    
  2. 클러스터가 배포된 리전에 Cloud Router를 만듭니다.

    gcloud compute routers create ROUTER_NAME \
        --network=NETWORK_NAME \
        --region=COMPUTE_REGION
    
  3. NAT64 변환을 위해 구성된 Cloud NAT 게이트웨이를 만듭니다.

    gcloud compute routers nats create NAT_NAME \
        --router=ROUTER_NAME \
        --region=COMPUTE_REGION \
        --auto-allocate-nat-external-ips \
        --nat64-all-v6-subnet-ip-ranges
    

    특정 서브네트워크 또는 수동 외부 IP 주소로 NAT64를 구성하려면 --nat64-custom-v6-subnet-ip-ranges 및 --nat-external-ip-pool를 사용합니다.

주소 변환에 대한 자세한 내용은 DNS64 및 NAT64 구성 및 6to4 연결을 위한 DNS64 및 NAT64를 참조하세요.

Private Service Connect를 사용하여 비공개 서비스에 연결

Private Service Connect(PSC)는 엔드포인트와 전달 규칙 간의 IPv6-IPv4 주소 변환을 지원합니다. 단일 스택 IPv6 클러스터의 워크로드를 Google Cloud 관리형 서비스(예: Cloud SQL 인스턴스) 또는 서드 파티 제작자 서비스에 연결할 수 있습니다.

  1. 클러스터의 PSC 서브네트워크에서 고정 내부 IPv6 주소를 예약합니다.

    gcloud compute addresses create ADDRESS_NAME \
        --ip-version=IPV6 \
        --subnet=PSC_SUBNET_NAME \
        --region=COMPUTE_REGION
    
  2. 서비스 연결을 타겟팅하는 PSC 엔드포인트 전달 규칙을 만듭니다.

    gcloud compute forwarding-rules create FORWARDING_RULE_NAME \
        --address=ADDRESS_NAME \
        --region=COMPUTE_REGION \
        --network=NETWORK_NAME \
        --target-service-attachment=SERVICE_ATTACHMENT_URL \
        --allow-psc-global-access
    
  3. 할당된 IPv6 주소를 검색합니다.

    gcloud compute forwarding-rules describe FORWARDING_RULE_NAME \
        --region=COMPUTE_REGION \
        --format='value(IPAddress)'
    
  4. 애플리케이션 연결 문자열 내에서 검색된 IPv6 주소를 사용합니다. PSC는 IPv6 포드가 IPv4 또는 이중 스택 프로듀서 서비스에 안전하게 도달할 수 있도록 트래픽을 변환합니다.

게시된 서비스 사용에 대한 자세한 내용은 Private Service Connect 엔드포인트 만들기 및 Private Service Connect를 사용하여 Cloud SQL에 연결을 참조하세요. ServiceAttachment 리소스를 사용하여 다른 VPC 네트워크의 소비자에게 클러스터에서 실행되는 내부 LoadBalancer 서비스를 게시하려면 Private Service Connect를 사용하여 내부 부하 분산기 만들기를 참조하세요.

고급 네트워킹 및 가속기

가속기 노드 풀 및 다중 네트워크 포드에 보조 네트워크 인터페이스가 있는 단일 스택 IPv6 클러스터를 구성할 수 있습니다.

멀티 NIC 가속기 네트워킹

표준 단일 스택 IPv6 클러스터에서는 자동 네트워킹(--accelerator-network-profile=auto) 또는 수동 멀티 네트워크 구성(--additional-node-network)을 사용하여 보조 데이터 네트워크(RDMA 또는 DIORITE)를 가속기 노드 풀(GPU 및 TPU)에 연결할 수 있습니다. 보조 인터페이스는 IPv4 하위 네트워크, 이중 스택 하위 네트워크 또는 IPv6 전용 하위 네트워크에서 실행할 수 있습니다.

단계별 안내는 단일 스택 IPv6 클러스터에서 멀티 NIC 노드 네트워크 구성을 참조하세요.

포드에 대한 다중 네트워크 지원

단일 스택 IPv6 클러스터는 다음과 같은 특성을 가진 포드에 대한 멀티 네트워킹을 지원합니다.

  • 기본 포드 네트워크 인터페이스(eth0)는 단일 스택 IPv6 네트워킹을 사용합니다.
  • 추가 포드 네트워크 인터페이스는 IPv4 전용(레이어 3 VPC 네트워크)이어야 합니다. 단일 스택 IPv6 클러스터는 추가 네트워크 인터페이스에서 IPv6 포드 네트워크를 지원하지 않습니다.
  • networking.gke.io/default-interface 포드 주석은 IPv4 트래픽에 대해서만 기본 인터페이스를 구성합니다. IPv6 트래픽에 대해서는 기본 인터페이스가 구성되지 않습니다.

VPC 서브네트워크에서 지원하는 보조 IPv4 포드 네트워크를 구성하는 방법은 단일 스택 IPv6 클러스터에서 포드에 대한 다중 네트워크 지원 설정을 참조하세요.

단일 스택 IPv6 클러스터로 마이그레이션

기존 IPv4 클러스터 또는 이중 스택 클러스터를 단일 스택 IPv6 클러스터로 직접 전환하거나 인플레이스 업데이트할 수 없습니다. 워크로드를 전환하려면 블루-그린 마이그레이션을 사용합니다.

  1. 종속 항목 감사: 애플리케이션 구성, 클라이언트 라이브러리, 에이전트가 하드코딩된 IPv4 주소 대신 DNS 이름(예: metadata.google.internal)을 사용하는지 확인합니다. 필요한 경우 GCE_METADATA_HOST를 구성합니다.
  2. 그린 클러스터 프로비저닝: 동일하거나 피어링된 VPC 네트워크 내에서 기존 클러스터와 함께 새 단일 스택 IPv6 클러스터를 배포합니다. Cloud DNS, DNS64, Cloud NAT(NAT64), PSC 전달 규칙이 구성되어 있는지 확인합니다.
  3. 워크로드 배포: Kubernetes 매니페스트를 그린 클러스터에 적용하고 포드가 시작되고 성공적으로 통신하는지 확인합니다.
  4. 트래픽 전환: 부하 분산기(Gateway API 또는 Cloud DNS 라우팅 정책)를 사용하여 측정항목과 오류율을 모니터링하면서 기존 클러스터에서 새 IPv6 클러스터로 트래픽을 점진적으로 전환합니다.
  5. 기존 클러스터 사용 중단: 모든 트래픽이 전환되고 그린 클러스터가 안정적인 것으로 확인되면 이전 클러스터를 드레이닝하고 삭제합니다.

다음 단계