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

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

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

GKE 버전을 선택합니다.

또는 문제를 검색합니다.

식별된 버전 수정된 버전 문제 및 해결 방법
1.30, 1.31, 1.32

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

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

이 문제는 노드 0개로 확장되었다가 다시 1개 이상의 노드로 확장된 클러스터에서 가장 두드러집니다.

해결 방법:

  • 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 to 1.27.16-gke.1341999

해결 방법:

GKE 제어 영역 업그레이드 직후 노드를 업그레이드하거나 다시 만듭니다.
1.28, 1.29, 1.30, 1.31

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

총 노드 수가 3개 미만이고, 각 노드에 할당 가능한 vCPU가 1개 이하이며, 네트워크 정책 사용 설정이 사용 설정된 클러스터에서는 Calico-typha 및 calico-node Pod를 예약할 수 없습니다. 이는 CPU 리소스가 충분하지 않기 때문입니다.

해결 방법:

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