이 페이지에는 GKE 네트워킹의 알려진 문제가 나와 있습니다. 이 페이지는 기본 기술 인프라의 수명 주기를 관리하고, 서비스 수준 목표(SLO)가 충족되지 않았거나 애플리케이션 오류가 발생했을 때 알림과 호출에 대응하는 관리자와 설계자를 위해 작성되었습니다.
제품 버전별로 알려진 문제를 필터링하려면 다음 드롭다운 메뉴에서 필터를 선택하세요.
GKE 버전을 선택합니다.
또는 문제를 검색합니다.
| 식별된 버전 | 수정된 버전 | 문제 및 해결 방법 |
|---|---|---|
| 1.28, 1.29, 1.30, 1.31, 1.32, 1.33 |
GKE Dataplane V2가 있는 노드에서 포드 IP 주소 누출GKE Dataplane V2가 사용 설정된 클러스터에서 노드의 포드 IP 주소가 소진될 수 있습니다. 이 문제는 포드가 생성 중에 일시적인 CNI 오류가 발생할 때 할당된 IP 주소가 누출될 수 있는 컨테이너 런타임 버그로 인해 발생합니다. 이 문제는 GKE 클러스터 노드가 다음 GKE 버전 중 하나로 업그레이드되거나 생성될 때 트리거됩니다.
이 문제가 발생하면 영향을 받는 노드에서 예약된 새 포드가 시작되지 않고 해결 방법: 이 문제를 완화하려면 완화 DaemonSet를 클러스터에 적용하여 유출된 IP 리소스를 정리하면 됩니다. apiVersion: apps/v1 kind: DaemonSet metadata: name: cleanup-ipam-dir namespace: kube-system spec: selector: matchLabels: name: cleanup-ipam template: metadata: labels: name: cleanup-ipam spec: hostNetwork: true securityContext: runAsUser: 0 runAsGroup: 0 seccompProfile: type: RuntimeDefault automountServiceAccountToken: false containers: - name: cleanup-ipam image: gcr.io/gke-networking-test-images/ubuntu-test:2022@sha256:6cfbdf42ccaa85ec93146263b6e4c60ebae78951bd732469bca303e7ebddd85e command: - /bin/bash - -c - | while true; do for hash in $(find /hostipam -iregex '/hostipam/[0-9].*' -mmin +10 -exec head -n1 {} \; ); do hash="${hash%%[[:space:]]}" if [ -z $(ctr -n k8s.io c ls | grep $hash | awk '{print $1}') ]; then grep -ilr $hash /hostipam fi done | xargs -r rm echo "Done cleaning up /var/lib/cni/networks/gke-pod-network at $(date)" sleep 120s done volumeMounts: - name: host-ipam mountPath: /hostipam - name: host-ctr mountPath: /run/containerd securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL volumes: - name: host-ipam hostPath: path: /var/lib/cni/networks/gke-pod-network - name: host-ctr hostPath: path: /run/containerd |
|
| 1.31, 1.32, 1.33 |
|
기존 네트워크가 있는 클러스터의 인그레스 및 서비스 부하 분산기 중단기존 네트워크와의 비호환성으로 인해 인그레스 또는 서비스를 사용하여 배포된 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 |
|
새로 만든 노드가 레이어 4 내부 부하 분산기에 추가되지 않음내부 LoadBalancer 서비스용으로 생성된 Google Cloud 부하 분산기에서 백엔드 인스턴스 그룹에 새로 생성된 노드가 누락될 수 있습니다. 이 문제는 노드 0개로 축소된 후 하나 이상의 노드로 다시 확장된 클러스터에서 가장 두드러지게 나타납니다. 해결 방법:
|
| 1.31,1.32 |
|
CRD 상태에서 삭제된 storedVersions로 인한 게이트웨이 API 문제
GKE의 Kube-Addon-Manager가 다음 조건을 모두 충족하는 경우 클러스터가 위험에 처할 수 있습니다.
해결 방법: 권장되는 해결 방법은 문제가 해결될 때까지 클러스터 업그레이드를 지연하는 것입니다.
또는 클러스터 버전을 업그레이드해야 하는 경우 영향을 받는 모든 Gateway API CRD의 스토리지 버전을
|
| 1.32 |
|
새 포드가 ContainerCreating에서 멈춰 초기화되지 않음
새 포드가 생성되지 않고 Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "[sandbox-ID]": plugin type="cilium-cni" failed (add): unable to create endpoint: Cilium API client timeout exceeded 이 문제는 GKE 버전 1.31 또는 1.32에서 생성되었으며 1.32~1.32.3-gke.1170000 이전 버전의 GKE 클러스터에 영향을 미칩니다. 근본 원인은 할당된 Cilium ID 컬렉션을 유지하는 메모리 내 데이터 구조가 Kubernetes API 서버 상태와 올바르게 동기화되지 않았기 때문입니다.
클러스터를 만드는 데 사용된 GKE 버전을 확인하려면 다음 명령어를 사용하여 gcloud container clusters describe [cluster_name] --location [location] --format='value(initialClusterVersion)'
GKE 클러스터에 로깅이 사용 설정된 경우 resource.type="k8s_container" resource.labels.container_name="cilium-agent" 해결 방법: 임시 해결 방법은 컨트롤 플레인을 다시 시작하는 것입니다. 이는 컨트롤 플레인을 이미 실행 중인 버전과 동일한 버전으로 업그레이드하여 달성할 수 있습니다. gcloud container clusters upgrade [cluster_name] --location [location] --cluster-version=[version] --master |
| 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.6-gke.1900 이상의 클러스터에서 간헐적인 연결 설정 실패가 발생할 수 있습니다. 실패 가능성이 낮고 모든 클러스터에 영향을 미치지는 않습니다. 이러한 장애는 증상이 시작된 후 며칠이 지나면 완전히 중지됩니다. |
| 1.27,1.28,1.29 |
|
Container-Optimized OS의 DNS 변환 문제Container-Optimized OS 기반 노드가 있는 GKE 클러스터에서 실행되는 워크로드에 DNS 변환 문제가 발생할 수 있습니다. |
| 1.28 | 1.28.3-gke.1090000 이상 |
잘못된 연결 추적 조회로 인해 네트워크 정책이 연결을 중단GKE Dataplane V2가 사용 설정된 클러스터의 경우 클라이언트 포드가 서비스 또는 내부 패스 스루 네트워크 부하 분산기의 가상 IP 주소를 사용하여 자체에 연결되면 Dataplane의 잘못된 conntrack 조회로 인해 응답 패킷이 기존 연결의 일부로 식별되지 않습니다. 즉, 포드의 인그레스 트래픽을 제한하는 네트워크 정책이 패킷에 잘못 적용됩니다. 이 문제의 영향은 서비스에 구성된 포드 수에 따라 다릅니다. 예를 들어 서비스에 백엔드 포드가 1개 있으면 연결이 항상 실패합니다. 서비스에 백엔드 포드가 2개 있는 경우 연결의 50%가 실패합니다. 해결 방법:
서비스 매니페스트에서 |
| 1.27,1.28 |
|
헤어핀 연결 흐름을 위한 패킷 삭제GKE Dataplane V2가 사용 설정된 클러스터의 경우 포드가 서비스를 사용하여 자체 TCP 연결을 만들면(예: 포드가 연결의 소스이자 목적지인 경우) GKE Dataplane V2 eBPF 연결 추적은 연결 상태를 잘못 추적하여 conntrack 항목이 유출될 수 있습니다. 연결 튜플(프로토콜, 소스/대상 IP, 소스/목적지 포트)이 유출되면 동일한 연결 튜플을 사용하는 새 연결로 인해 반환 패킷이 삭제될 수 있습니다. 해결 방법: 이때 다음 해결방법 중 하나를 사용해 보세요.
|
| 1.31.0-gke.1506000 이전 | 1.31.0-gke.1506000 이상 |
GKE 다중 네트워크에서 네트워크 이름이 긴 경우 기기 유형 네트워크가 실패함다음 오류와 함께 클러스터 생성이 실패합니다.
해결 방법: 기기 유형 네트워크 객체 이름의 길이를 41자(영문 기준) 이하로 제한합니다. 각 UNIX 도메인 소켓의 전체 경로가 상응하는 네트워크 이름을 포함하여 구성됩니다. Linux에는 소켓 경로 길이(107바이트 미만)에 대한 제한사항이 있습니다. 디렉터리, 파일 이름 프리픽스, |
| 1.27, 1.28, 1.29, 1.30 |
|
컨트롤 플레인 업그레이드 후
|
| 1.31, 1.32 |
|
동일한 노드에서 실행되는 포드 간의 손상된 UDP 트래픽노드 내 가시성이 사용 설정된 클러스터에서는 동일한 노드에서 실행되는 포드 간의 UDP 트래픽이 손상될 수 있습니다. 이 문제는 GKE 클러스터 노드가 다음 GKE 버전 중 하나로 업그레이드되거나 생성될 때 트리거됩니다.
영향을 받는 경로는 Hostport 또는 서비스를 통한 동일한 노드의 포드 간 UDP 트래픽입니다. 해결 방법 클러스터를 다음 고정 버전 중 하나로 업그레이드합니다.
|
| 1.28, 1.29, 1.30, 1.31 |
총 노드 수가 3개 미만이고 vCPU가 충분하지 않은 클러스터에서 Calico 포드가 정상이 아님다음 조건을 모두 충족하는 클러스터에서는 Calico-typha 및 calico-node 포드를 예약할 수 없습니다. 총 노드 수가 3개 미만이고, 각 노드에 할당 가능한 vCPU가 1개 이하이며, 네트워크 정책이 사용 설정되어 있습니다. 이는 CPU 리소스가 부족하기 때문입니다. 해결 방법:
|
|
제어 영역 업그레이드 중 영역 클러스터의 멀티 클러스터 게이트웨이 (MCG) 서비스 중단GKE 영역 클러스터에서 멀티 클러스터 게이트웨이 (MCG)를 사용하는 배포는 클러스터 업그레이드와 같이 컨트롤 플레인 재시작을 유발하는 이벤트 중에 `503` 오류와 함께 서비스 중단이 발생할 수 있습니다. 이는 MCG가 네트워크 엔드포인트 그룹 (NEG) 검색을 위해 기존 메커니즘을 사용하기 때문입니다. 이 메커니즘은 컨트롤 플레인 다시 시작 중에 영역 클러스터의 노드를 일시적으로 사용할 수 없게 되면 백엔드를 0으로 잘못 보고합니다. 이로 인해 부하 분산기가 모든 백엔드를 삭제하여 트래픽 손실이 발생합니다. 해결 방법:
|