GKE 네트워킹 관련 알려진 문제

이 페이지에는 GKE 네트워킹에 대한 알려진 문제가 나와 있습니다. 이 페이지는 기본 기술 인프라의 수명 주기를 관리하고 서비스 수준 목표(SLO)가 충족되지 않거나 애플리케이션이 실패할 때 알림 및 페이지에 응답하는 관리자 및 설계자를 위해 작성되었습니다.

제품 버전별로 알려진 문제를 필터링하려면 다음 드롭다운 메뉴에서 필터를 선택하세요.

GKE 버전을 선택합니다.

또는 문제를 검색합니다.

식별된 버전 수정된 버전 문제 및 해결 방법
1.31, 1.32, 1.33
  • 1.33.1-gke.1107000 이상

기존 네트워크가 있는 클러스터의 인그레스 및 서비스 부하 분산기 중단

기존 네트워크와의 비호환성으로 인해 인그레스 또는 서비스를 사용하여 배포된 GKE 관리형 부하 분산기의 백엔드가 분리됩니다. 이로 인해 부하 분산기에 활성 백엔드가 없게 되고, 결과적으로 해당 부하 분산기로 들어오는 모든 요청이 삭제됩니다.

이 문제는 기존 네트워크를 사용하고 버전 1.31 이상을 실행하는 GKE 클러스터에 영향을 미칩니다.

기존 네트워크가 있는 GKE 클러스터를 식별하려면 다음 명령어를 실행합니다. 

    gcloud container clusters describe CLUSTER_NAME --location=LOCATION --format="value(subnetwork)"

기존 네트워크가 있는 클러스터는 이 명령어에 대해 빈 출력을 받습니다.

해결 방법:

레거시 네트워크는 한동안 지원 중단되었으므로 레거시 네트워크를 VPC 네트워크로 마이그레이션하는 것이 좋습니다. GKE 클러스터가 포함된 기존 네트워크를 변환하여 이 작업을 수행할 수 있습니다. 지금 이 이전을 수행할 수 없는 경우 Cloud Customer Care에 문의하세요.

1.30, 1.31, 1.32
  • 1.30.10-gke.1070000 이상
  • 1.31.5-gke.1068000 이상
  • 1.32.1-gke.1002000 이상

새로 만든 노드가 레이어 4 내부 부하 분산기에 추가되지 않음

내부 LoadBalancer 서비스에 대해 생성된 Google Cloud 부하 분산기에서 백엔드 인스턴스 그룹에 새로 생성된 노드가 누락될 수 있습니다.

이 문제는 노드 0개로 확장된 후 하나 이상의 노드로 다시 확장된 클러스터에서 가장 잘 보입니다.

해결 방법:

  • GKE 하위 설정을 사용 설정하고 서비스를 다시 만듭니다.

    참고: GKE 하위 설정은 사용 설정한 후에는 사용 중지할 수 없습니다.

  • 다른 내부 LoadBalancing 서비스를 만듭니다. 동기화되면 영향을 받는 서비스의 인스턴스 그룹도 수정됩니다. 새 서비스는 동기화 후 삭제할 수 있습니다.
  • 노드 중 하나에서 node.kubernetes.io/exclude-from-external-load-balancers 라벨을 추가한 후 삭제합니다.
  • 클러스터에 노드를 추가합니다. 서비스가 작동하기 시작한 후 노드를 삭제할 수 있습니다.
1.27,1.28,1.29,1.30,1.31

서비스에서 포트가 삭제되면 NEG 컨트롤러가 엔드포인트 관리를 중지함

서비스의 독립형 NEG를 만들도록 NEG 컨트롤러가 구성되어 있고 구성된 포트 중 하나가 나중에 서비스에서 삭제되면 NEG 컨트롤러가 결국 NEG의 엔드포인트 관리를 중지합니다. 사용자가 독립형 NEG 주석을 만드는 서비스 외에도 GKE 게이트웨이, MCI, GKE 멀티 클러스터 게이트웨이에서 참조하는 서비스에도 영향을 미칩니다.

해결 방법:

독립형 NEG 주석이 있는 서비스에서 포트를 삭제할 때는 해당 포트를 삭제하도록 주석도 업데이트해야 합니다.

1.28

게이트웨이 TLS 구성 오류

GKE 버전 1.28.4-gke.1083000을 실행하는 클러스터에서 게이트웨이의 TLS를 구성하는 데 문제가 있는 것으로 확인되었습니다. 이는 SSLCertificate 또는 CertificateMap을 사용하는 TLS 구성에 영향을 미칩니다. 기존 게이트웨이가 있는 클러스터를 업그레이드하는 경우 게이트웨이에 적용된 업데이트가 실패합니다. 새 게이트웨이의 경우 부하 분산기가 프로비저닝되지 않습니다. 이 문제는 향후 GKE 1.28 패치 버전에서 해결될 예정입니다.

1.27,1.28,1.29
  • 1.26.13-gke.1052000 이상
  • 1.27.10-gke.1055000 이상
  • 1.28.6-gke.1095000 이상
  • 1.29.1-gke.1016000 이상

간헐적인 연결 설정 실패

컨트롤 플레인 버전 1.26.6-gke.1900 이상의 클러스터에서 간헐적인 연결 설정 실패가 발생할 수 있습니다.

실패 가능성이 낮으며 모든 클러스터에 영향을 미치지는 않습니다. 이러한 오류는 증상이 시작된 후 며칠이 지나면 완전히 중지됩니다.

1.27,1.28,1.29
  • 1.27.11-gke.1118000 이상
  • 1.28.7-gke.1100000 이상
  • 1.29.2-gke.1217000 이상

Container-Optimized OS의 DNS 변환 문제

Container-Optimized OS 기반 노드가 있는 GKE 클러스터에서 실행되는 워크로드에 DNS 변환 문제가 발생할 수 있습니다.

1.28 1.28.3-gke.1090000 이상

잘못된 연결 추적 조회로 인해 네트워크 정책이 연결을 중단

GKE Dataplane V2가 사용 설정된 클러스터의 경우 클라이언트 포드가 내부 패스 스루 네트워크 부하 분산기의 서비스 또는 가상 IP 주소를 사용하여 자체에 연결되면 데이터 영역의 잘못된 conntrack 조회로 인해 응답 패킷이 기존 연결의 일부로 식별되지 않습니다. 즉, 포드의 인그레스 트래픽을 제한하는 네트워크 정책이 패킷에 잘못 적용됩니다.

이 문제의 영향은 서비스에 구성된 포드 수에 따라 다릅니다. 예를 들어 서비스에 백엔드 포드가 1개 있으면 연결이 항상 실패합니다. 서비스에 백엔드 포드가 2개 있는 경우 연결의 50% 가 실패합니다.

해결 방법:

서비스 매니페스트에서 port 및 containerPort를 동일한 값으로 구성하여 이 문제를 완화할 수 있습니다.

1.27,1.28
  • 1.28.3-gke.1090000 이상
  • 1.27.11-gke.1097000 이상

헤어핀 연결 흐름을 위한 패킷 삭제

GKE Dataplane V2가 사용 설정된 클러스터의 경우 포드가 서비스를 사용하여 자체 TCP 연결을 만들면(예: 포드가 연결의 소스이자 대상인 경우), GKE Dataplane V2 eBPF 연결 추적은 연결 상태를 잘못 추적하여 conntrack 항목의 유출로 이어지게 됩니다.

연결 튜플 (프로토콜, 소스/대상 IP, 소스/대상 포트)이 유출되면 동일한 연결 튜플을 사용하는 새 연결로 인해 반환 패킷이 삭제될 수 있습니다.

해결 방법:

이때 다음 해결방법 중 하나를 사용해 보세요.

  • 서비스를 사용하여 자체적으로 통신할 수 있는 포드에서 실행되는 애플리케이션에 TCP 재사용 (연결 유지)을 사용 설정합니다. 이렇게 하면 TCP FIN 플래그가 발행되지 않고 conntrack 항목이 누출되지 않습니다.
  • 단기 연결을 사용할 때는 게이트웨이와 같은 프록시 부하 분산기를 사용하여 포드를 노출하여 서비스를 노출하세요. 이로 인해 연결 요청의 대상이 부하 분산기 IP 주소로 설정되어 GKE Dataplane V2가 루프백 IP 주소로 SNAT를 실행할 수 없습니다.
1.31.0-gke.1506000 이전 1.31.0-gke.1506000 이상

GKE 다중 네트워크에서 네트워크 이름이 긴 경우 기기 유형 네트워크가 실패함

다음 오류와 함께 클러스터 생성이 실패합니다.

error starting very-long-string-that-exceeds-character-limit-gpu-nic0 device plugin endpoint: listen unix /var/lib/kubelet/plugins_registry/networking.gke.io.networks_very-long-string-that-exceeds-character-limit-gpu-nic0.sock: bind: invalid argument

해결 방법:

기기 유형 네트워크 객체 이름의 길이를 41자(영문 기준) 이하로 제한합니다. 각 UNIX 도메인 소켓의 전체 경로가 상응하는 네트워크 이름을 포함하여 구성됩니다. Linux에는 소켓 경로 길이(107바이트 미만)에 대한 제한사항이 있습니다. 디렉터리, 파일 이름 접두사, .sock 확장자를 고려하면 네트워크 이름은 최대 41자로 제한됩니다.
1.27, 1.28, 1.29, 1.30
  • 1.30.4-gke.1282000 이상
  • 1.29.8-gke.1157000 이상
  • 1.28.13-gke.1078000 이상
  • 1.27.16-gke.1342000 이상

컨트롤 플레인 업그레이드 후 hostPort 포드의 연결 문제

네트워크 정책이 사용 설정된 클러스터에서는 hostPort 포드와의 연결 문제가 발생할 수 있습니다. 또한 새로 생성된 포드가 준비되는 데 30~60초가 추가로 걸릴 수 있습니다.

이 문제는 클러스터의 GKE 컨트롤 플레인이 다음 GKE 버전 중 하나로 업그레이드될 때 트리거됩니다.

  • 1.30~1.30.4-gke.1281999
  • 1.29.1-gke.1545000~1.29.8-gke.1156999
  • 1.28.7-gke.1042000~1.28.13-gke.1077999
  • 1.27.12-gke.1107000~1.27.16-gke.1341999

해결 방법:

GKE 컨트롤 플레인 업그레이드 직후 노드를 업그레이드하거나 다시 만듭니다.
1.31, 1.32
  • 1.32.1-gke.1729000 이상
  • 1.31.6-gke.1020000 이상

동일한 노드에서 실행되는 포드 간의 손상된 UDP 트래픽

노드 내 가시성이 사용 설정된 클러스터에서는 동일한 노드에서 실행되는 포드 간의 UDP 트래픽이 손상될 수 있습니다.

이 문제는 GKE 클러스터 노드가 다음 GKE 버전 중 하나로 업그레이드되거나 이러한 버전으로 생성될 때 트리거됩니다.

  • 1.32.1-gke.1729000 이상
  • 1.31.6-gke.1020000 이상

영향을 받는 경로는 Hostport 또는 서비스를 통한 동일한 노드의 포드 간 UDP 트래픽입니다.

해결 방법

클러스터를 다음 고정 버전 중 하나로 업그레이드합니다.

  • 1.32.3-gke.1927000 이상
  • 1.31.7-gke.1390000 이상
1.28, 1.29, 1.30, 1.31

총 노드 수가 3개 미만이고 vCPU가 충분하지 않은 클러스터에서 Calico 포드가 정상이 아님

다음 조건을 모두 충족하는 클러스터에서는 Calico-typha 및 calico-node 포드를 예약할 수 없습니다. 총 노드 수가 3개 미만이고, 각 노드에 할당 가능한 vCPU가 1개 이하이며, 네트워크 정책이 사용 설정되어 있습니다. 이는 CPU 리소스가 부족하기 때문입니다.

해결 방법:

  • 할당 가능한 vCPU 1개를 사용하는 노드 1개가 있는 노드 풀을 최소 3개로 확장합니다.
  • 할당 가능한 vCPU가 1개인 노드를 최소 3개로 단일 노드 풀의 크기를 조정합니다.
  • 단일 노드가 있는 노드 풀에서 할당 가능한 vCPU가 2개 이상인 머신 유형을 사용합니다.