VPC 클러스터의 IP 주소 관리 문제 해결


이 섹션에서는 VPC 기반 클러스터와 관련된 문제를 해결하는 방법을 설명합니다. GKE IP 주소 사용률 통계도 볼 수 있습니다.

기본 네트워크 리소스가 준비되지 않음

증상

다음과 비슷한 오류 메시지가 표시됩니다.

projects/[PROJECT_NAME]/regions/XXX/subnetworks/default
가능한 원인

동일한 서브넷에 동시 작업이 있습니다. 예를 들어 서브넷에 다른 VPC 기반 클러스터를 만들거나, 보조 범위를 추가하거나 삭제하는 경우가 있습니다.

해결 방법

명령어를 재실행합니다.

잘못된 IPCidrRange 값입니다.

증상

다음과 비슷한 오류 메시지가 표시됩니다.

resource.secondaryIpRanges[1].ipCidrRange': 'XXX'. Invalid IPCidrRange: XXX conflicts with existing subnetwork 'default' in region 'XXX'
가능한 원인

다른 VPC 기반 클러스터가 동시에 생성되고 동일한 VPC 네트워크에 동일한 범위를 할당하려고 합니다.

동일한 VPC 네트워크의 서브네트워크에 동일한 보조 범위가 추가됩니다.

해결 방법

보조 범위를 지정하지 않은 경우 클러스터를 만들 때 이 오류가 반환되면 클러스터 생성 명령어를 재실행합니다.

포드의 IP 주소 여유 공간 부족

증상

클러스터가 장기간 프로비저닝 상태에서 멈춰 있습니다.

클러스터 생성이 관리형 인스턴스 그룹(MIG) 오류를 반환합니다.

클러스터에 노드를 하나 이상 추가하면 다음 오류가 표시됩니다.

[IP_SPACE_EXHAUSTED] Instance 'INSTANCE_NAME' creation failed: IP space of 'projects/PROJECT_ID/regions/REGION/subnetworks/SUBNET_NAME-SECONDARY_RANGE_NAME' is exhausted.
가능한 원인

노드 IP 주소 소진: 클러스터에 할당된 서브넷의 기본 IP 주소 범위에서 사용 가능한 IP 주소가 소진됩니다. 이는 일반적으로 노드 풀을 확장하거나 대규모 클러스터를 만들 때 발생합니다.

포드 IP 주소 소진: 클러스터에 할당된 포드 CIDR 범위가 꽉 찼습니다. 이 문제는 특히 노드당 포드 밀도가 높거나 대규모 배포의 경우 포드 수가 포드 CIDR 용량을 초과할 때 발생합니다.

특정 서브넷 이름 지정 규칙: 오류 메시지에서 서브넷 이름이 지정되는 방식은 노드 IP 주소 범위(노드 자체가 IP 주소를 가져오는 위치) 또는 포드 IP 주소 범위(포드 내부의 컨테이너가 IP 주소를 가져오는 위치)에 문제가 있는지 확인하는 데 도움이 될 수 있습니다.

보조 범위 소진(Autopilot): Autopilot 클러스터에서 확장 또는 높은 포드 밀도로 인해 포드 IP 주소에 할당된 보조 범위가 소진됩니다.

솔루션

이름, 컨트롤 플레인 버전, 작업 모드, 연결된 VPC 이름, 서브넷 이름 및 CIDR과 같은 클러스터에 대한 정보를 수집합니다. 또한 기본 및 추가 클러스터 포드 IPv4 범위(이름 및 CIDR 포함), VPC 기반 트래픽 라우팅 사용 설정 여부, 클러스터 및 노드 풀 수준의 노드당 최대 포드 수 설정(해당하는 경우)을 확인합니다. 영향을 받는 노드 풀과 해당 노드 풀의 특정 IPv4 포드 IP 주소 범위, 노드당 최대 포드 구성이 클러스터 전체 설정과 다른 경우 이를 기록합니다. 또한 노드 풀 구성에서 노드당 최대 포드 수의 기본 및 커스텀 구성(있는 경우)을 기록합니다.

IP 주소 소진 문제 확인

  • Network Intelligence Center: GKE 클러스터의 Network Intelligence Center에서 포드 IP 주소 범위의 IP 주소 할당 비율이 높은지 확인합니다.

    Network Intelligence Center 내의 포드 범위에서 IP 주소 할당 비율이 높으면 포드 IP 주소 범위가 소진된 것입니다.

    포드 IP 주소 범위에 정상적인 할당률이 표시되지만 여전히 IP 주소가 부족한 경우 노드 IP 주소 범위가 소진되었을 수 있습니다.

  • 감사 로그: IP_SPACE_EXHAUSTED 항목의 resourceName 필드를 확인하여 서브넷 이름 또는 보조 포드 IP 주소 범위 이름과 비교합니다.

  • 소진된 IP 주소 범위가 노드 IP 주소 범위인지 포드 IP 주소 범위인지 확인합니다.

    소진된 IP 주소 범위가 노드 IP 주소 범위인지 포드 IP 주소 범위인지 확인하려면 IP_SPACE_EXHAUSTED 로그 항목의 ipSpaceExhausted 부분에서 resourceName의 값이 영향을 받는 GKE 클러스터에서 사용되는 포드의 서브넷 이름 또는 보조 IPv4 주소 범위 이름과 상관관계가 있는지 확인합니다.

    resourceName 값이 '[Subnet_name]' 형식이면 노드 IP 주소 범위가 소진된 것입니다. resourceName의 값이 '[Subnet_name]-[Name_of_Secondary_IPv4_range_for_pods]-[HASH_8BYTES]' 형식이면 포드 IP 주소 범위가 소진된 것입니다.

포드 IP 주소 소진 해결:

  • 기존 포드 CIDR 크기 조정: 현재 포드 IP 주소 범위의 크기를 늘립니다. 연속되지 않은 멀티 포드 CIDR을 사용하여 포드 IP 범위를 클러스터에 추가할 수 있습니다.
  • 서브넷 추가: 클러스터에 전용 포드 CIDR이 있는 서브넷을 추가합니다.

노드당 포드를 줄여 IP 주소를 확보합니다.

노드 IP 주소 소진 해결:

  • IP 주소 계획 검토: 노드 IP 주소 범위가 확장 요구사항과 일치하는지 확인합니다.
  • 새 클러스터 만들기(필요한 경우): 노드 IP 주소 범위가 크게 제한된 경우 적절한 IP 주소 범위 크기로 대체 클러스터를 만듭니다. VPC 기반 클러스터의 IP 범위IP 범위 계획을 참조하세요.

gcpdiag로 IP 주소 소진 문제 디버그

gcpdiag는 오픈소스 도구입니다. 공식적으로 지원되는 Google Cloud 제품이 아닙니다. gcpdiag 도구를 사용하여 Google Cloud 프로젝트 문제를 식별하고 해결할 수 있습니다. 자세한 내용은 GitHub의 gcpdiag 프로젝트를 참조하세요.

Autopilot 및 Standard GKE 클러스터에서 IP 주소 소진의 원인을 조사하려면 다음 사항을 고려하세요.
  • 클러스터 상태: IP 주소 소진이 보고된 경우 클러스터 상태를 확인합니다.
  • 네트워크 분석기: 네트워크 분석기 로그에 대한 Stackdriver 로그를 쿼리하여 포드 또는 노드 IP 주소 소진이 있는지 확인합니다.
  • 클러스터 유형: 클러스터 유형을 확인하고 클러스터 유형에 따라 관련 추천을 제공합니다.

Google Cloud 콘솔

  1. 다음 명령어를 작성하고 복사합니다.
  2. gcpdiag runbook gke/ip-exhaustion --project=PROJECT_ID \
        --parameter name=CLUSTER_NAME \
        --parameter location=ZONE|REGION \
        --parameter start_time=yyyy-mm-ddThh:mm:ssZ \
        --parameter end_time=yyyy-mm-ddThh:mm:ssZ \
  3. Google Cloud 콘솔을 열고 Cloud Shell을 활성화합니다.
  4. Cloud 콘솔 열기
  5. 복사한 명령어를 붙여넣습니다.
  6. gcpdiag 명령어를 실행하면 gcpdiag Docker 이미지를 다운로드한 후 진단 검사를 수행합니다. 해당하는 경우 출력 안내에 따라 실패한 검사를 수정합니다.

Docker

Docker 컨테이너에서 gcpdiag를 시작하는 래퍼를 사용하여 gcpdiag를 실행할 수 있습니다. Docker 또는 Podman이 설치되어 있어야 합니다.

  1. 로컬 워크스테이션에서 다음 명령어를 복사하고 실행합니다.
    curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
  2. gcpdiag 명령어를 실행합니다.
    ./gcpdiag runbook gke/ip-exhaustion --project=PROJECT_ID \
        --parameter name=CLUSTER_NAME \
        --parameter location=ZONE|REGION \
        --parameter start_time=yyyy-mm-ddThh:mm:ssZ \
        --parameter end_time=yyyy-mm-ddThh:mm:ssZ \

이 런북에 사용 가능한 매개변수를 봅니다.

다음을 바꿉니다.

  • PROJECT_ID: 리소스가 포함된 프로젝트의 ID입니다.
  • CLUSTER_NAME: 프로젝트 내 대상 GKE 클러스터의 이름입니다.
  • LOCATION: 클러스터가 있는 영역 또는 리전입니다.
  • start_time: 문제가 시작된 시간입니다.
  • end_time: 문제가 종료된 시간입니다. 문제가 계속되는 경우 현재 시간을 설정합니다.

유용한 플래그:

모든 gcpdiag 도구 플래그의 목록과 설명은 gcpdiag 사용 안내를 참조하세요.

기본 SNAT가 사용 중지되었는지 여부 확인

다음 명령어를 사용하여 기본 SNAT 상태를 확인합니다.

gcloud container clusters describe CLUSTER_NAME

CLUSTER_NAME을 클러스터 이름으로 바꿉니다.

출력은 다음과 비슷합니다.

networkConfig:
  disableDefaultSnat: true
  network: ...

--enable-ip-alias 없이 --disable-default-snat을 사용할 수 없음

이 오류 메시지 및 must disable default sNAT (--disable-default-snat) before using public IP address privately in the cluster는 비공개 클러스터에서 공개 IP 주소를 사용하기 때문에 클러스터를 만들 때 --disable-default-snat 플래그를 명시적으로 설정해야 함을 나타냅니다.

cannot disable default sNAT ...와 같은 오류 메시지가 표시되면 클러스터에서 기본 SNAT를 사용 중지할 수 없음을 나타냅니다. 이 문제를 해결하려면 클러스터 구성을 검토합니다.

기본 SNAT가 사용 중지된 Cloud NAT 디버깅

--disable-default-snat 플래그로 비공개 클러스터가 생성되었고, 인터넷 액세스를 위해 Cloud NAT가 설정된 상태에서 포드의 인터넷 연결 트래픽이 보이지 않을 때는 포드 범위가 Cloud NAT 구성에 포함되어 있는지 확인하세요.

포드 간 통신에 문제가 있으면 노드에서 iptables 규칙을 조사하여 포드 범위가 iptables 규칙으로 매스커레이드되지 않았는지 확인하세요.

자세한 내용은 GKE IP 매스커레이드 문서를 참조하세요.

클러스터에 대해 IP 매스커레이드 에이전트를 구성하지 않은 경우 GKE는 자동으로 포드 간 통신이 매스커레이드되지 않도록 합니다. 그러나 IP 매스커레이드 에이전트가 구성되어 있으면 기본 IP 매스커레이드 규칙보다 우선 적용됩니다. IP 매스커레이드 에이전트에서 포드 범위 매스커레이드를 무시하도록 추가 규칙이 구성되었는지 확인하세요.

이중 스택 클러스터 네트워크 통신이 예상대로 작동하지 않음

가능한 원인
GKE 클러스터에서 만든 방화벽 규칙에 할당된 IPv6 주소가 포함되지 않습니다.
해결 방법
다음 단계에 따라 방화벽 규칙을 검증할 수 있습니다.
  1. 방화벽 규칙 콘텐츠를 확인합니다.

    gcloud compute firewall-rules describe FIREWALL_RULE_NAME
    

    FIREWALL_RULE_NAME을 방화벽 규칙의 이름으로 바꿉니다.

    각 이중 스택 클러스터는 노드와 포드가 서로 통신하도록 허용하는 방화벽 규칙을 만듭니다. 방화벽 규칙 콘텐츠는 다음과 비슷합니다.

    allowed:
    - IPProtocol: esp
    - IPProtocol: ah
    - IPProtocol: sctp
    - IPProtocol: tcp
    - IPProtocol: udp
    - IPProtocol: '58'
    creationTimestamp: '2021-08-16T22:20:14.747-07:00'
    description: ''
    direction: INGRESS
    disabled: false
    enableLogging: false
    id: '7326842601032055265'
    kind: compute#firewall
    logConfig:
      enable: false
    name: gke-ipv6-4-3d8e9c78-ipv6-all
    network: https://www.googleapis.com/compute/alpha/projects/my-project/global/networks/alphanet
    priority: 1000
    selfLink: https://www.googleapis.com/compute/alpha/projects/my-project/global/firewalls/gke-ipv6-4-3d8e9c78-ipv6-all
    selfLinkWithId: https://www.googleapis.com/compute/alpha/projects/my-project/global/firewalls/7326842601032055265
    sourceRanges:
    - 2600:1900:4120:fabf::/64
    targetTags:
    - gke-ipv6-4-3d8e9c78-node
    

    sourceRanges 값이 subnetIpv6CidrBlock과 동일해야 합니다. targetTags 값이 GKE 노드의 태그와 동일해야 합니다. 이 문제를 해결하려면 클러스터 ipAllocationPolicy 블록 정보를 사용하여 방화벽 규칙을 업데이트하세요.

클러스터 삭제 중에 Private Service Connect 엔드포인트가 유출될 수 있음

증상

Private Service Connect 기반 클러스터의 Private Service Connect에 연결된 엔드포인트가 표시되지 않습니다.

엔드포인트에 Private Service Connect가 할당된 서브넷 또는 VPC 네트워크는 삭제할 수 없습니다. 다음과 유사한 오류 메시지가 표시됩니다.

projects/<PROJECT_ID>/regions/<REGION>/subnetworks/<SUBNET_NAME> is already being used by projects/<PROJECT_ID>/regions/<REGION>/addresses/gk3-<ID>
가능한 원인

Private Service Connect를 사용하는 GKE 클러스터에서 GKE는 컨트롤 플레인의 네트워크에서 클러스터 컨트롤 플레인에 액세스할 수 있도록 내부 IP 주소를 할당하는 전달 규칙을 사용하여 Private Service Connect 엔드포인트를 배포합니다. Private Service Connect를 사용하여 컨트롤 플레인과 노드 간의 통신을 보호하기 위해 GKE는 엔드포인트를 표시하지 않으며 Google Cloud 콘솔 또는 gcloud CLI에서 볼 수 없습니다.

해결 방법

클러스터 삭제 전에 Private Service Connect 엔드포인트가 유출되지 않도록 하려면 다음 단계를 완료하세요.

  1. GKE 서비스 계정에 Kubernetes Engine Service Agent role을 할당합니다.
  2. compute.forwardingRules.*compute.addresses.* 권한이 GKE 서비스 계정에서 명시적으로 거부되지 않았는지 확인합니다.

Private Service Connect 엔드포인트가 유출된 것으로 확인되면 지원팀에 문의하세요.

다음 단계

  • Kubernetes DNS 문제 진단에 대한 일반적인 정보는 DNS 변환 디버깅을 참조하세요.