GKE 알려진 문제

이 페이지에는 GKE의 알려진 문제가 나와 있습니다. 이 페이지는 기본 기술 인프라의 수명 주기를 관리하고, 서비스 수준 목표(SLO)가 충족되지 않았거나 애플리케이션 오류가 발생했을 때 알림과 호출에 대응하는 관리자와 설계자를 위해 작성되었습니다.

이 페이지에는 지원되는 모든 버전과 연장 지원의 가장 초기 버전 바로 앞에 있는 두 개의 마이너 버전의 알려진 문제가 나열되어 있습니다. 버전이 연장 지원 종료에 도달하면 모든 N-2 문제가 삭제됩니다. 예를 들어 버전 1.30의 연장 지원이 종료되면 버전 1.28 이하에만 해당하는 알려진 문제가 삭제됩니다.

Google Developer Program에 참여하는 경우 이 페이지를 저장하여 이 페이지와 관련된 출시 노트가 게시될 때 알림을 받으세요. 자세한 내용은 저장된 페이지를 참고하세요.

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

GKE 버전을 선택합니다.

문제 카테고리를 선택하세요.

또는 문제를 검색합니다.

카테고리 식별된 버전 수정된 버전 문제 및 해결 방법
작업 1.33.4-gke.1036000 이전의 1.33 버전 1.33.4-gke.1036000 이상

동적으로 프로비저닝된 Lustre 인스턴스의 성능 등급이 잘못됨

Lustre 인스턴스를 동적으로 프로비저닝할 때 API 요청에 지정된 perUnitStorageThroughput 값과 관계없이 PerUnitStorageThroughput에 대해 InvalidArgument 오류가 발생하여 인스턴스 생성이 실패합니다.

해결 방법:

GKE 클러스터를 버전 1.33.4-gke.1036000 이상으로 업그레이드합니다. 안정화 채널을 사용하는 경우 아직 최신 버전을 사용하지 못할 수 있습니다. 이 경우 수정사항이 포함된 Regular 또는 Rapid 채널에서 버전을 수동으로 선택할 수 있습니다.

작업
  • 1.32.3-gke.1099000 이상
  • 1.33
1.33.3-gke.1266000 이상

Cloud Storage FUSE CSI 드라이버를 사용하여 파일 이름을 바꾸거나 파일을 이동할 때 발생하는 입력/출력 오류

영향을 받는 버전의 Cloud Storage FUSE CSI 드라이버를 사용하는 경우 Cloud Storage 버킷에서 파일의 이름을 바꾸거나 파일을 이동하면 I/O 오류가 발생할 수 있습니다.

해결 방법:

포드 매니페스트에 특정 사이드카 이미지 정의를 일시적으로 추가합니다. 포드 매니페스트의 spec.containers 섹션에 이미지(gcr.io/gke-release/gcs-fuse-csi-driver-sidecar-mounter:v1.8.9-gke.2)가 포함된 다음 컨테이너 정의를 추가합니다.

    # Add the following block to use the fixed sidecar image
    - name: gke-gcsfuse-sidecar
      image: gcr.io/gke-release/gcs-fuse-csi-driver-sidecar-mounter:v1.8.9-gke.2
    

자세한 내용은 사이드카 컨테이너의 비공개 이미지 구성의 포드 매니페스트를 참고하세요.

클러스터를 고정된 GKE 버전 이상으로 업그레이드한 후에는 매니페스트에서 전체 gke-gcsfuse-sidecar 블록을 삭제해야 합니다. 이 블록을 삭제하면 GKE는 업그레이드된 클러스터 버전에 맞는 올바른 사이드카 이미지를 자동으로 삽입하고 관리합니다.

로깅 및 모니터링 모든 버전 미정

gke-metrics-agent DaemonSet의 경합 상태

gke-metrics-agent DaemonSet의 메모리 할당을 수동으로 늘리기 위해 노드 풀에 cloud.google.com/gke-metrics-agent-scaling-level 라벨을 추가하면 새 노드 생성 중에 DaemonSet에서 경합 상태가 발생합니다. 이 경합 상태로 인해 간헐적으로 다시 시작되고 측정항목이 손실될 수 있습니다.

이 문제는 라벨이 노드 풀의 새 노드에 추가되기 전에 지연이 발생하기 때문에 발생합니다. 이 지연 시간 동안 DaemonSet는 해당 노드에 원래 메모리 할당이 있는 포드를 만듭니다. 라벨이 적용되면 DaemonSet은 새 메모리 할당이 있는 Pod를 생성합니다. 업데이트된 포드가 시작될 때 기존 포드가 완전히 삭제되지 않습니다. 이 두 포드는 모두 동일한 포트 번호에 바인딩하려고 합니다.

해결 방법:

노드 풀에 cloud.google.com/gke-metrics-agent-scaling-level 라벨을 추가한 후 gke-metrics-agent DaemonSet를 다시 시작합니다.

kubectl -n kube-system rollout restart daemonset gke-metrics-agent
업그레이드 1.33 1.33.2-gke.1043000

containerd 2.0으로 열린 파일 제한이 낮아짐

containerd 2.0을 사용하는 GKE 버전 1.33을 실행하는 노드 풀의 경우 컨테이너의 열린 파일의 기본 소프트 제한 (ulimit -n)이 1024로 낮아집니다.

이는 containerd 자체의 변경사항 (containerd PR #8924 참고)으로, 여기서 LimitNOFILE가 권장사항으로 containerd.service에서 삭제되어 기본 시스템 소프트 제한이 적용됩니다.

기본 소프트 한도가 더 높을 것으로 예상되는 워크로드 (예: 이전의 더 높은 기본값을 암시적으로 사용하는 워크로드)에서 Too many open files 오류와 같은 장애가 발생할 수 있습니다.

해결책:

이전 1.33 패치 버전에서 1.33.2-gke.1043000 이상으로 업그레이드합니다.

해결 방법:

다음 방법 중 하나를 사용하여 워크로드의 열린 파일 제한을 늘립니다.

  • 애플리케이션 수준 조정: 애플리케이션 코드 또는 구성을 수정하여 ulimit -n 또는 prlimit --nofile=524288을 명시적으로 설정합니다.
  • Containerd NRI Ulimit Adjuster 플러그인 containerd/nri ulimit-adjuster 플러그인을 사용하여 ulimit을 조정합니다.
  • 노드 풀 다운그레이드 (Standard만 해당): Standard GKE 클러스터의 경우 영구적인 해결책이 제공될 때까지 이 문제를 방지하기 위해 노드 풀을 버전 1.32로 다운그레이드할 수 있습니다.
containerd 2로의 마이그레이션에 관한 자세한 내용은 노드를 containerd 2로 마이그레이션을 참고하세요.
업그레이드 1.31.5-gke.1169000, 1.32.1-gke.1376000 1.31.7-gke.1164000, 1.32.3-gke.1512000

관리 CRD의 CRD status.storedVersions가 잘못됨

일부 GKE 관리 CRD에 잘못된 status.storedVersions 필드가 있을 수 있으며, 이로 인해 업그레이드 후 CRD 객체에 대한 액세스가 중단될 위험이 있습니다.

이 문제는 다음 두 가지를 모두 충족하는 클러스터에 영향을 미칩니다.

  • 영향을 받는 GKE 버전을 한때 사용한 클러스터
  • 지원되지 않는 (served=false) 버전의 CRD 객체가 etcd에 저장된 클러스터

해결 방법:

권장되는 해결 방법은 문제가 해결될 때까지 클러스터 업그레이드를 지연하는 것입니다.

또는 클러스터에 지원되지 않는 버전의 CRD 객체가 포함되어 있음을 알고 있는 경우 kubectl patch 명령어를 사용하여 이러한 버전을 status.storedVersions 필드에 추가할 수 있습니다.

작업, 로깅, 모니터링 1.32.2-gke.1652000, 1.31.6-gke.1221000, 1.30.10-gke.1227000
  • 1.32.2-gke.1652003 이상
  • 1.31.6-gke.1221001 이상
  • 1.30.10-gke.1227001 이상

측정항목이 누락되었거나 워크로드 자동 확장 처리가 확장되지 않음

클러스터 크기가 5개 이상의 노드로 증가한 후 영향을 받는 버전의 측정항목 데이터에 격차가 발생할 수 있습니다. 이 문제는 자동 확장 작업에도 영향을 미칠 수 있습니다.

이 문제는 영향을 받는 버전으로 업그레이드된 클러스터에만 영향을 미칩니다. 새로 생성된 클러스터는 예상대로 작동해야 합니다.

해결 방법:

영향을 받는 경우 패치 버전을 하나 다운그레이드하거나 수정된 최신 버전으로 업그레이드하면 됩니다.

작업

Google Cloud Hyperdisk 크기 및 연결 한도

일반적으로 노드의 볼륨 연결 한도로 인해 예약할 수 없는 포드는 새 노드의 자동 프로비저닝을 트리거합니다. 하이퍼디스크 제품을 사용하는 워크로드가 C3 VM을 실행하는 노드에 예약되면 노드 자동 프로비저닝이 발생하지 않고 포드가 이미 가득 찬 노드에 예약됩니다.

사용 가능한 디스크 연결이 없는데도 워크로드가 노드에 예약됩니다. 다음과 같은 오류로 인해 워크로드도 시작되지 않습니다.

 AttachVolume.Attach failed for volume "[VOLUME NAME]" : rpc error: code = InvalidArgument desc = Failed to Attach: failed when waiting for zonal op: rpc error: code = InvalidArgument desc = operation operation-[OPERATION NUMBERS] failed (UNSUPPORTED_OPERATION): Maximum hyperdisk-balanced disks count should be less than or equal to [16], Requested : [17]

이 문제는 C3 머신의 모든 Hyperdisk 제품에 있습니다.

하이퍼디스크 연결 한도는 VM vCPU 수와 하이퍼디스크 제품에 따라 다릅니다. 자세한 내용은 하이퍼디스크 성능 한도를 참고하세요.

해결 방법:

하이퍼디스크 제품은 다른 VM 유형에서 자동 프로비저닝을 트리거합니다. Hyperdisk만 지원하는 모양을 사용하는 것이 좋습니다.

작업 1.32.3-gke.1927000, 1.32.3-gke.1785000, 1.32.3-gke.1717000, 1.32.3-gke.1440000, 1.32.3-gke.1170000, 1.32.3-gke.1250000, 1.32.3-gke.1671000, 1.32.3-gke.1596000, 1.32.3-gke.1298000

TPU/GPU 노드에서 gke-metadata-server가 OOMKilled됨

GKE TPU 노드 (예: ct4p-hightpu-4t) 및 GPU 노드 (예: a3-highgpu-8g)에서 서버의 메모리 사용량이 100MB를 초과하면 커널이 OOMKilledgke-metadata-server를 종료할 수 있습니다.

해결 방법:

TPU 또는 GPU 노드에서 gke-metadata-server에 대한 OOMKilled 이벤트가 관찰되면 GKE ID 당직팀 (구성요소 ID: 395450)에 문의하여 완화 옵션을 확인하세요.

작업
  • 1.32.0-gke.1358000~1.32.4-gke.1106006, 1.32.4-gke.1236007, 1.32.4-gke.1353001, 1.32.4-gke.1415001, 1.32.4-gke.1533000
  • 1.33.0-gke.0~1.33.0-gke.1552000
  • 1.32.4-gke.1353003 이상
  • 1.33.0-gke.1552000 이상

PVC에서 NodePendingResize 상태가 비정상적으로 남아 있어 볼륨 크기 조절이 중단될 수 있습니다.

버전 1.31 이하의 노드가 있는 버전 1.32의 클러스터는 크기 조절 중에 PersistentVolumeClaim 상태를 업데이트하지 못합니다. 이 잘못된 상태로 인해 후속 크기 조절 작업이 시작되지 않아 추가 크기 조절이 효과적으로 방지됩니다.

이 상태의 PVC에는 NodePendingResize 또는 status.allocatedResources 필드와 status.conditions.type: FileSystemResizePending가 모두 포함된 status.allocatedResourceStatuses 필드가 있습니다.

클러스터가 영향을 받는 버전에 있는 동안 PVC가 생성된 경우 클러스터를 알려진 고정 버전으로 업그레이드한 후에도 이 문제가 지속될 수 있습니다. 이 시나리오에서는 일회성 해결 방법으로 status.allocatedResources 필드를 삭제하도록 PVC를 패치해야 합니다.

해결 방법:

상태가 중단되어 멈춘 PVC는 해당 상태를 삭제하도록 패치를 적용할 수 있습니다. 다음과 같은 패치 명령어를 사용하여 연결되지 않은 상태를 삭제할 수 있습니다.

kubectl patch pvc $PVC_NAME --subresource='status' --type='merge' -p '{"status":{"allocatedResourceStatuses":null}}'
kubectl patch pvc $PVC_NAME --subresource='status' --type='merge' -p '{"status":{"allocatedResources":null}}'
작업
  • 1.32.4-gke.1236007, 1.32.4-gke.1353001
  • 1.32.4-gke.1353003 이상

PDCSI 드라이버가 과도하게 로깅할 수 있음

특정 버전의 1.32에서 실행되는 GKE 클러스터는 PDCSI 드라이버에서 과도한 로그 메시지를 내보낼 수 있습니다. 이러한 과도한 로깅은 Cloud Logging Write API 할당량을 소모합니다.

해결 방법:

제외 필터를 추가하여 과도한 로깅을 줄일 수 있습니다. 로그 메시지가 Cloud Logging에 수집되지 않도록 제외하려면 다음 쿼리를 사용하세요.

      resource.type="k8s_container"
      resource.labels.container_name="gce-pd-driver"
      (sourceLocation.file="cache.go" OR "Cannot process volume group")
    
작업
  • 1.27.16-gke.2440000 이상
  • 1.28.15-gke.1673000 이상
  • 1.29.13-gke.1038000 이상
  • 1.30.9 이상
  • 1.31.7 이상
  • 1.32.1-gke.1357001 이상
  • 1.27.16-gke.2691000 이상
  • 1.28.15-gke.2152000 이상
  • 1.29.15-gke.1218000 이상
  • 1.30.11-gke.1190000 이상
  • 1.31.7-gke.1363000 이상
  • 1.32.4-gke.1106000 이상
  • 1.33.0-gke.1552000 이상

이전에 읽기 전용 (RO) 마운트가 있었던 COS 노드에 NFS 영구 볼륨을 마운트하려고 하는 포드는 RO 모드로만 마운트됩니다.

GKE 버전 1.27 이상의 경우 Kubernetes 인트리 CSI 드라이버를 사용하는 NFS 볼륨은 동일한 노드에서 이전 RO 마운트 후 RO 모드로만 영구 볼륨을 마운트할 수 있습니다.

해결 방법:

영향을 받는 버전보다 이전 버전으로 노드 풀을 다운그레이드합니다.

작업
  • 1.32.1-gke.1357001 ~ 최대 1.32.4-gke.1106000(비포함) 사이의 1.32 버전
  • 1.33.0-gke.1552000 이전의 모든 1.33 버전
  • 1.32 출시: 1.32.4-gke.1106000 이상
  • 1.33 출시: 1.33.0-gke.1552000 이상

Ubuntu 노드에 NFS 영구 볼륨을 마운트하려고 하는 포드는 실행할 수 없습니다.

GKE 버전 1.32 이상에서 Kubernetes 인 트리 CSI 드라이버를 사용하는 NFS 볼륨은 Ubuntu 노드에 영구 볼륨을 마운트할 수 없습니다. 이 문제가 발생하면 다음과 같은 오류 메시지가 표시될 수 있습니다.

"MountVolume.SetUp failed for volume 'nfs-storage' : mount failed: exit status 1"
Output: Mount failed: mount failed: exit status 127
"Output: chroot: failed to run command 'mount': No such file or directory failed to run command mount on Ubuntu nodes"
이러한 오류 메시지가 표시될 뿐만 아니라 이러한 볼륨을 사용하는 포드가 실행되지 않습니다.

해결 방법:

노드 풀을 버전 1.31로 다운그레이드합니다.

작업 >= 1.28.15-gke.1436000, < 1.28.15-gke.1668000, >= 1.29.12-gke.1040000, < 1.29.13-gke.1028000, >= 1.30.8-gke.1053000, < 1.30.8-gke.1287000, >= 1.31.4-gke.1057000, < 1.31.6-gke.1020000, >= 1.32.0-gke.1281000, < 1.32.1-gke.1302000
  • 1.28.15-gke.1668000 이상
  • 1.29.13-gke.1028000 이상
  • 1.30.8-gke.1287000 이상
  • 1.31.6-gke.1020000 이상
  • 1.32.1-gke.1302000 이상

io_uring 관련 syscall을 사용하는 포드는 Linux 커널의 버그로 인해 D(디스크 절전 모드) 상태(TASK_UNINTERRUPTIBLE이라고도 함)로 전환될 수 있습니다. D 상태의 프로세스는 SIGKILL를 비롯한 신호로 깨울 수 없습니다.

이 알려진 문제로 인해 포드가 영향을 받는 경우 컨테이너가 정상적으로 종료되지 않을 수 있습니다. containerd 로그에서 시스템이 컨테이너를 반복적으로 중지하려고 시도함을 나타내는 Kill container [container-id]와 같은 메시지가 반복적으로 표시될 수 있습니다.
동시에 kubelet 로그에 다음과 같은 오류 메시지가 표시됩니다.

"Kill container failed" err="rpc error: code = DeadlineExceeded desc = context deadline exceeded"

또는

"Error syncing pod, skipping" err="[failed to \"KillContainer\" for \"container-name\" with KillContainerError: \"rpc error: code = DeadlineExceeded desc = an error occurs during waiting for container \\\"container-id\\\" to be killed: wait container \\\"container-id\\\": context deadline exceeded\", failed to \"KillPodSandbox\" for \"pod-uuid\" with KillPodSandboxError: \"rpc error: code = DeadlineExceeded desc = context deadline exceeded\"]" pod="pod-name" podUID="pod-uuid"

이러한 증상은 컨테이너 내 프로세스가 무중단 절전 모드 (D 상태)에서 멈춰 포드가 적절하게 종료되지 않음을 나타냅니다.

io_uring을 직접 사용하거나 NodeJS와 같은 언어 런타임을 통해 io_uring을 간접적으로 사용하는 워크로드는 이 알려진 문제의 영향을 받을 수 있습니다. 영향을 받는 워크로드에는 /proc/<pid>/state 파일에 D (디스크 절전 모드) 상태의 프로세스가 있으며 /proc/<pid>/stack 콘텐츠의 일부로 io_uring 문자열이 표시됩니다. NodeJS 워크로드는 UV_USE_IO_URING=0를 통해 io_uring 사용을 사용 중지할 수 있습니다.

해결 방법:

클러스터 노드를 고정 버전 이상으로 업그레이드합니다.

작업 1.28, 1.29, 1.30, 1.31
  • 1.30.8-gke.1261000 이상
  • 1.31.4-gke.1183000 이상
  • 1.32.0-gke.1448000 이상

이미지 스트리밍을 사용하는 워크로드가 인증 오류로 실패함

이미지 스트리밍 기능의 버그로 인해 컨테이너가 파일을 읽는 동안 특정 조건이 충족되면 워크로드가 실패할 수 있습니다. 인증 실패와 관련된 오류 메시지가 gcfsd 로그에 표시될 수 있습니다.

영향을 받았는지 확인하려면 다음 검색어로 로그를 검색하세요. resource.type="k8s_node" resource.labels.project_id="[project_id]" resource.labels.cluster_name="[cluster_name]" logName="projects/[project_id]/logs/gcfsd" "backend.FileContent failed" "Request is missing required authentication credential."

이러한 오류가 있으면 노드에 영향을 미친다는 의미입니다.

이 문제의 영향을 받는 경우 패치된 GKE 버전으로 노드 풀을 업그레이드하면 됩니다.

작업
  • 1.30.0~1.30.5-gke.1443001
  • 1.31.0~1.31.1-gke.1678000
  • 1.30.5-gke.1628000 이상
  • 1.31.1-gke.1846000 이상

GKE 버전 1.30 및 1.31에서 포드 제거 비율 증가

COS 113 및 COS 117을 각각 사용하는 GKE 1.30 및 GKE 1.31의 일부 버전에는 CONFIG_LRU_GEN_ENABLED=y 옵션으로 빌드된 커널이 있습니다. 이 옵션을 사용하면 커널 기능 Multi-Gen LRU가 사용 설정되어 kubelet이 메모리 사용량을 잘못 계산하고 kubelet이 포드를 제거할 수 있습니다.

cos-113-18244-151-96cos-117-18613-0-76에서 구성 옵션 CONFIG_LRU_GEN_ENABLED이 사용 중지되었습니다.

이 문제는 워크로드의 메모리 사용량 패턴에 따라 달라지므로 비정상적인 포드 퇴출 비율이 항상 표시되지는 않을 수 있습니다. 리소스 필드에 메모리 한도를 설정하지 않은 워크로드의 경우 kubelet이 포드를 제거할 위험이 더 높습니다. 이는 워크로드에서 kubelet이 사용 가능하다고 보고한 것보다 더 많은 메모리를 요청할 수 있기 때문입니다.

다른 변경사항 없이 언급된 GKE 버전으로 업그레이드한 후 애플리케이션의 메모리 사용량이 증가하는 경우 커널 옵션의 영향을 받을 수 있습니다.

비정상적인 포드 퇴출 비율이 있는지 확인하려면 측정항목 탐색기로 다음 측정항목을 분석하세요. kubernetes.io/container_memory_used_byteskubernetes.io/container_memory_request_bytes

다음 PromQL 쿼리를 사용할 수 있습니다. cluster_name, namespace_name, metadata_system_top_level_controller_type, metadata_system_top_level_controller_name 값을 분석하려는 워크로드 이름과 유형으로 바꿉니다.

max by (pod_name)(max_over_time(kubernetes_io:container_memory_used_bytes{monitored_resource="k8s_container",memory_type="non-evictable",cluster_name="REPLACE_cluster_name",namespace_name="REPLACE_namespace",metadata_system_top_level_controller_type="REPLACE_controller_type",metadata_system_top_level_controller_name="REPLACE_controller_name"}[${__interval}]))

sum by (pod_name)(avg_over_time(kubernetes_io:container_memory_request_bytes{monitored_resource="k8s_container",cluster_name="REPLACE_cluster_name",namespace_name="REPLACE_namespace",metadata_system_top_level_controller_type="REPLACE_controller_type",metadata_system_top_level_controller_name="REPLACE_controller_name"}[${__interval}]))

요청된 메모리보다 높은 메모리 사용량이 비정상적으로 급증하는 경우 워크로드가 더 자주 제거될 수 있습니다.

해결 방법

수정된 버전으로 업그레이드할 수 없고 권한이 있는 포드를 배포할 수 있는 GKE 환경에서 실행 중인 경우 DaemonSet을 사용하여 Multi-Gen LRU 옵션을 사용 중지할 수 있습니다.

  1. Multi-Gen LRU 옵션을 사용 중지하는 주석을 사용하여 DaemonSet를 실행할 GKE 노드 풀을 업데이트합니다. 예를 들면 disable-mglru: "true"입니다.
  2. 이전 단계에서 사용한 것과 동일한 주석으로 DaemonSet 매니페스트의 nodeSelector 매개변수를 업데이트합니다. 예를 들어 GoogleCloudPlatform/k8s-node-tools 저장소의 disable-mglru.yaml 파일을 참고하세요.
  3. 클러스터에 DaemonSet을 배포합니다.

선택한 모든 노드 풀에서 DaemonSet가 실행되면 변경사항이 즉시 적용되고 kubelet 메모리 사용량 계산이 정상으로 돌아갑니다.

작업 1.28, 1.29, 1.30, 1.31
  • 1.28.14-gke.1175000 이상
  • 1.29.9-gke.1341000 이상
  • 1.30.5-gke.1355000 이상
  • 1.31.1-gke.1621000 이상

포드가 종료 중 상태로 멈춰 있음

컨테이너 런타임 (containerd)의 버그로 인해 포드와 컨테이너가 종료 상태로 멈추고 다음과 유사한 오류가 발생할 수 있습니다.

OCI runtime exec failed: exec failed: cannot exec in a stopped container: unknown

이 문제의 영향을 받는 경우 containerd 버전이 수정된 GKE 버전으로 노드를 업그레이드하면 됩니다.

작업 1.28,1.29
  • 1.28.9-gke.1103000 이상
  • 1.29.4-gke.1202000 이상
  • 1.30: 모든 버전

이미지 스트리밍 기능의 버그로 인해 컨테이너가 시작되지 않을 수 있습니다.

특정 GKE 버전에서 이미지 스트리밍이 사용 설정된 노드에서 실행되는 컨테이너가 다음 오류와 함께 생성되지 않을 수 있습니다.

"CreateContainer in sandbox from runtime service failed" err="rpc error: code = Unknown desc = failed to create containerd container: failed to mount [PATH]: too many levels of symbolic links"

이 문제의 영향을 받는 경우 빈 레이어 또는 중복 레이어를 확인할 수 있습니다. 비어 있는 레이어나 중복된 레이어를 삭제할 수 없는 경우 이미지 스트리밍을 사용 중지하세요.

작업 1.27,1.28,1.29
  • 1.28.9-gke.1103000 이상
  • 1.29.4-gke.1202000 이상
  • 1.30: 모든 버전

파일 누락으로 인해 이미지 스트리밍이 실패함

이미지 스트리밍 기능의 버그로 인해 파일 누락으로 인해 컨테이너가 실패할 수 있습니다.

다음 버전에서 이미지 스트리밍이 사용 설정된 노드에서 실행되는 컨테이너는 특정 파일이 존재하지 않는다는 오류와 함께 시작되거나 실행되지 않을 수 있습니다. 다음은 이러한 오류의 예입니다.

  • No such file or directory
  • Executable file not found in $PATH

이 문제의 영향을 받는 경우 이미지 스트리밍을 사용 중지할 수 있습니다.

네트워킹,업그레이드 및 업데이트 1.28

게이트웨이 TLS 구성 오류

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

업그레이드 및 업데이트 1.27 1.27.8 이상

GPU 기기 플러그인 문제

GPU를 실행하고 1.26에서 1.27.8 이전의 1.27 패치 버전으로 업그레이드된 클러스터에서 노드의 GPU 기기 플러그인 (nvidia-gpu-device-plugin)에 문제가 발생할 수 있습니다. 클러스터 상태에 따라 다음 단계를 따르세요.

  • 클러스터가 버전 1.26을 실행하고 GPU가 있는 경우 클러스터의 출시 채널에서 버전 1.27.8을 사용할 수 있을 때까지 클러스터를 수동으로 업그레이드하지 마세요.
  • 클러스터에서 이전 1.27 패치 버전을 실행하고 노드가 영향을 받는 경우 노드를 다시 시작하거나 노드에서 nvidia-gpu-device-plugin 포드를 수동으로 삭제합니다(추가 기능 관리자가 새 작업 플러그인을 만듭니다).
  • 클러스터에서 자동 업그레이드를 사용하는 경우 자동 업그레이드는 수정사항이 포함된 패치 버전으로만 클러스터를 이동하므로 영향을 받지 않습니다.
작업 1.27,1.28
  • 1.27.5-gke.1300 이상
  • 1.28.1-gke.1400 이상

모든 워크로드의 자동 확장 중지

잘못 구성된 autoscaling/v2 HPA 객체가 포함된 경우 HorizontalPodAutoscaler (HPA) 및 VerticalPodAutoscaler (VPA)가 클러스터의 모든 워크로드 자동 확장을 중지할 수 있습니다. 이 문제는 GKE 버전 1.27 및 1.28의 이전 패치 버전을 실행하는 클러스터 (예: 1.27.3-gke.100)에 영향을 미칩니다.

해결 방법:

spec.metrics.resource.target의 필드가 일치하는지 확인하여 잘못 구성된 autoscaling/v2 HPA 객체를 수정합니다. 예를 들면 다음과 같습니다.

  • spec.metrics.resource.target.typeUtilization인 경우 타겟은 averageUtilization이어야 합니다.
  • spec.metrics.resource.target.typeAverageValue인 경우 타겟은 averageValue이어야 합니다.

autoscaling/v2 HPA 객체를 구성하는 방법에 관한 자세한 내용은 HorizontalPodAutoscaler Kubernetes 문서를 참고하세요.

작업 1.28,1.29
  • 1.28.7-gke.1026000
  • 1.29.2-gke.1060000

Container Threat Detection을 배포할 수 없음

다음 GKE 버전을 실행하는 Autopilot 클러스터에서는 Container Threat Detection이 배포되지 않을 수 있습니다.

  • 1.28.6-gke.1095000~1.28.7-gke.1025000
  • 1.29.1-gke.1016000~1.29.1-gke.1781000
네트워킹, 업그레이드 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.29,1.30,1.31
  • 1.29.10-gke.1071000 이상
  • 1.30.5-gke.1723000 이상
  • 1.31.2-gke.1115000 이상

호환되지 않는 Ray 연산자 및 Cloud KMS 데이터베이스 암호화

일부 Ray Operator 버전은 Cloud KMS 데이터베이스 암호화와 호환되지 않습니다.

해결 방법:

클러스터 컨트롤 플레인을 고정 버전 이상으로 업그레이드합니다.

업그레이드 및 업데이트 1.30, 1.31
  • 1.30.8-gke.1051000 이상
  • 1.31.1-gke.2008000 이상

GPU 유지보수 핸들러 포드가 CrashLoopBackOff 상태로 멈춤

이 문제로 인해 gpu-maintenance-handler 포드가 각 노드에서 `CrashLoopBackOff` 상태로 멈춥니다. 이 상태로 인해 GKE 노드에 `예정된 유지보수` 라벨이 적용되지 않으며, 이는 워크로드의 노드 드레인 및 포드 퇴출 프로세스에 영향을 미칠 수 있습니다.

"Node upcoming maintenance label not applied due to error: Node "gke-yyy-yyy" is invalid: metadata.labels: Invalid value: "-62135596800": a valid label must be an empty string or consist of alphanumeric characters, '-','' or '.', and must start and end with an alphanumeric character (e.g.'MyValue', or 'my_value', or '12345', regex used for validation is '(([A-Za-z0-9][-A-Za-z0-9.]*)?[A-Za-z0-9])?')"

이 문제의 영향을 받는 경우 수정사항이 포함된 GKE 버전으로 컨트롤 플레인을 업그레이드하여 문제를 해결할 수 있습니다.

작업 1.33.1-gke.1522000 이상 1.33.4-gke.1142000 이상

이미지 스트리밍이 사용 설정된 노드에서 포드가 시작되지 않음

이미지 스트리밍이 사용 설정된 노드에서 워크로드가 다음 오류 서명과 함께 시작되지 않을 수 있습니다. Failed to create pod sandbox ... context deadline exceeded

영향을 받는 노드의 직렬 포트 로그에도 다음 오류 서명이 포함됩니다. task gcfsd ... blocked for more than X seconds

이 두 오류 서명이 있으면 이미지 스트리밍 구성요소 중 하나에 교착 상태가 있음을 나타냅니다. 이 교착 상태로 인해 포드가 성공적으로 시작되지 않습니다.

해결 방법:

빠른 완화를 위해 노드를 다시 시작합니다. 다시 시작된 노드에서 교착 상태가 다시 발생할 수 있습니다. 더 강력한 완화를 위해 다음을 실행하여 노드 풀에서 이미지 스트리밍을 사용 중지합니다.

gcloud container node-pools update NODE_POOL_NAME --cluster CLUSTER_NAME --no-enable-image-streaming
참고: 이미지 스트리밍을 사용 중지하면 노드 풀 내의 모든 노드가 다시 생성됩니다.

다음 단계

  • 문서에서 문제 해결 방법을 찾을 수 없으면 지원 받기를 참조하여 다음 주제에 대한 조언을 포함한 추가 도움을 요청하세요.