이 페이지에는 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에 대해 해결 방법: GKE 클러스터를 버전 1.33.4-gke.1036000 이상으로 업그레이드합니다. 안정화 채널을 사용하는 경우 아직 최신 버전을 사용하지 못할 수 있습니다. 이 경우 수정사항이 포함된 Regular 또는 Rapid 채널에서 버전을 수동으로 선택할 수 있습니다. |
작업 |
|
1.33.3-gke.1266000 이상 |
Cloud Storage FUSE CSI 드라이버를 사용하여 파일 이름을 바꾸거나 파일을 이동할 때 발생하는 입력/출력 오류영향을 받는 버전의 Cloud Storage FUSE CSI 드라이버를 사용하는 경우 Cloud Storage 버킷에서 파일의 이름을 바꾸거나 파일을 이동하면 I/O 오류가 발생할 수 있습니다. 해결 방법: 포드 매니페스트에 특정 사이드카 이미지 정의를 일시적으로 추가합니다. 포드 매니페스트의 # 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 버전 이상으로 업그레이드한 후에는 매니페스트에서 전체 |
로깅 및 모니터링 | 모든 버전 | 미정 |
|
업그레이드 | 1.33 | 1.33.2-gke.1043000 |
containerd 2.0으로 열린 파일 제한이 낮아짐containerd 2.0을 사용하는 GKE 버전 1.33을 실행하는 노드 풀의 경우 컨테이너의 열린 파일의 기본 소프트 제한 ( 이는 containerd 자체의 변경사항 (containerd PR #8924 참고)으로, 여기서 기본 소프트 한도가 더 높을 것으로 예상되는 워크로드 (예: 이전의 더 높은 기본값을 암시적으로 사용하는 워크로드)에서 해결책: 이전 1.33 패치 버전에서 1.33.2-gke.1043000 이상으로 업그레이드합니다. 해결 방법: 다음 방법 중 하나를 사용하여 워크로드의 열린 파일 제한을 늘립니다.
|
업그레이드 | 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에 잘못된 이 문제는 다음 두 가지를 모두 충족하는 클러스터에 영향을 미칩니다.
해결 방법: 권장되는 해결 방법은 문제가 해결될 때까지 클러스터 업그레이드를 지연하는 것입니다. 또는 클러스터에 지원되지 않는 버전의 CRD 객체가 포함되어 있음을 알고 있는 경우 |
작업, 로깅, 모니터링 | 1.32.2-gke.1652000, 1.31.6-gke.1221000, 1.30.10-gke.1227000 |
|
측정항목이 누락되었거나 워크로드 자동 확장 처리가 확장되지 않음클러스터 크기가 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 노드 (예: 해결 방법: TPU 또는 GPU 노드에서 |
|
작업 |
|
|
PVC에서 NodePendingResize 상태가 비정상적으로 남아 있어 볼륨 크기 조절이 중단될 수 있습니다.버전 1.31 이하의 노드가 있는 버전 1.32의 클러스터는 크기 조절 중에 PersistentVolumeClaim 상태를 업데이트하지 못합니다. 이 잘못된 상태로 인해 후속 크기 조절 작업이 시작되지 않아 추가 크기 조절이 효과적으로 방지됩니다. 이 상태의 PVC에는 클러스터가 영향을 받는 버전에 있는 동안 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}}' |
작업 |
|
|
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") |
작업 |
|
|
이전에 읽기 전용 (RO) 마운트가 있었던 COS 노드에 NFS 영구 볼륨을 마운트하려고 하는 포드는 RO 모드로만 마운트됩니다.GKE 버전 1.27 이상의 경우 Kubernetes 인트리 CSI 드라이버를 사용하는 NFS 볼륨은 동일한 노드에서 이전 RO 마운트 후 RO 모드로만 영구 볼륨을 마운트할 수 있습니다. 해결 방법: 영향을 받는 버전보다 이전 버전으로 노드 풀을 다운그레이드합니다. |
작업 |
|
|
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.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 |
|
io_uring 관련 syscall을 사용하는 포드가 종료 상태로 멈출 수 있음
io_uring 관련 syscall을 사용하는 포드는 Linux 커널의 버그로 인해 D(디스크 절전 모드) 상태(TASK_UNINTERRUPTIBLE이라고도 함)로 전환될 수 있습니다. D 상태의 프로세스는
이 알려진 문제로 인해 포드가 영향을 받는 경우 컨테이너가 정상적으로 종료되지 않을 수 있습니다. containerd 로그에서 시스템이 컨테이너를 반복적으로 중지하려고 시도함을 나타내는
또는
이러한 증상은 컨테이너 내 프로세스가 무중단 절전 모드 (D 상태)에서 멈춰 포드가 적절하게 종료되지 않음을 나타냅니다.
io_uring을 직접 사용하거나 NodeJS와 같은 언어 런타임을 통해 io_uring을 간접적으로 사용하는 워크로드는 이 알려진 문제의 영향을 받을 수 있습니다. 영향을 받는 워크로드에는 해결 방법: 클러스터 노드를 고정 버전 이상으로 업그레이드합니다. |
작업 | 1.28, 1.29, 1.30, 1.31 |
|
이미지 스트리밍을 사용하는 워크로드가 인증 오류로 실패함이미지 스트리밍 기능의 버그로 인해 컨테이너가 파일을 읽는 동안 특정 조건이 충족되면 워크로드가 실패할 수 있습니다. 인증 실패와 관련된 오류 메시지가 gcfsd 로그에 표시될 수 있습니다.
영향을 받았는지 확인하려면 다음 검색어로 로그를 검색하세요.
이러한 오류가 있으면 노드에 영향을 미친다는 의미입니다. 이 문제의 영향을 받는 경우 패치된 GKE 버전으로 노드 풀을 업그레이드하면 됩니다. |
작업 |
|
|
GKE 버전 1.30 및 1.31에서 포드 제거 비율 증가
COS 113 및 COS 117을 각각 사용하는 GKE 1.30 및 GKE 1.31의 일부 버전에는
cos-113-18244-151-96 및 cos-117-18613-0-76에서 구성 옵션 이 문제는 워크로드의 메모리 사용량 패턴에 따라 달라지므로 비정상적인 포드 퇴출 비율이 항상 표시되지는 않을 수 있습니다. 리소스 필드에 메모리 한도를 설정하지 않은 워크로드의 경우 kubelet이 포드를 제거할 위험이 더 높습니다. 이는 워크로드에서 kubelet이 사용 가능하다고 보고한 것보다 더 많은 메모리를 요청할 수 있기 때문입니다. 다른 변경사항 없이 언급된 GKE 버전으로 업그레이드한 후 애플리케이션의 메모리 사용량이 증가하는 경우 커널 옵션의 영향을 받을 수 있습니다.
비정상적인 포드 퇴출 비율이 있는지 확인하려면 측정항목 탐색기로 다음 측정항목을 분석하세요.
다음 PromQL 쿼리를 사용할 수 있습니다.
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 옵션을 사용 중지할 수 있습니다.
선택한 모든 노드 풀에서 DaemonSet가 실행되면 변경사항이 즉시 적용되고 kubelet 메모리 사용량 계산이 정상으로 돌아갑니다. |
작업 | 1.28, 1.29, 1.30, 1.31 |
|
포드가 종료 중 상태로 멈춰 있음컨테이너 런타임 (containerd)의 버그로 인해 포드와 컨테이너가 종료 상태로 멈추고 다음과 유사한 오류가 발생할 수 있습니다. OCI runtime exec failed: exec failed: cannot exec in a stopped container: unknown
이 문제의 영향을 받는 경우 containerd 버전이 수정된 GKE 버전으로 노드를 업그레이드하면 됩니다. |
작업 | 1.28,1.29 |
|
심볼릭 링크로 인해 이미지 스트리밍이 실패함이미지 스트리밍 기능의 버그로 인해 컨테이너가 시작되지 않을 수 있습니다. 특정 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 |
게이트웨이 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 기기 플러그인 (
|
작업 | 1.27,1.28 |
|
모든 워크로드의 자동 확장 중지
잘못 구성된 해결 방법:
|
작업 | 1.28,1.29 |
|
Container Threat Detection을 배포할 수 없음다음 GKE 버전을 실행하는 Autopilot 클러스터에서는 Container Threat Detection이 배포되지 않을 수 있습니다.
|
네트워킹, 업그레이드 | 1.27, 1.28, 1.29, 1.30 |
|
컨트롤 플레인 업그레이드 후
|
네트워킹 | 1.31, 1.32 |
|
동일한 노드에서 실행되는 포드 간의 손상된 UDP 트래픽노드 내 가시성이 사용 설정된 클러스터에서는 동일한 노드에서 실행되는 포드 간의 UDP 트래픽이 손상될 수 있습니다. 이 문제는 GKE 클러스터 노드가 다음 GKE 버전 중 하나로 업그레이드되거나 생성될 때 트리거됩니다.
영향을 받는 경로는 Hostport 또는 서비스를 통한 동일한 노드의 포드 간 UDP 트래픽입니다. 해결 방법 클러스터를 다음 고정 버전 중 하나로 업그레이드합니다.
|
작업 | 1.29,1.30,1.31 |
|
호환되지 않는 Ray 연산자 및 Cloud KMS 데이터베이스 암호화일부 Ray Operator 버전은 Cloud KMS 데이터베이스 암호화와 호환되지 않습니다. 해결 방법: 클러스터 컨트롤 플레인을 고정 버전 이상으로 업그레이드합니다. |
업그레이드 및 업데이트 | 1.30, 1.31 |
|
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 이상 |
이미지 스트리밍이 사용 설정된 노드에서 포드가 시작되지 않음
이미지 스트리밍이 사용 설정된 노드에서 워크로드가 다음 오류 서명과 함께 시작되지 않을 수 있습니다.
영향을 받는 노드의 직렬 포트 로그에도 다음 오류 서명이 포함됩니다.
이 두 오류 서명이 있으면 이미지 스트리밍 구성요소 중 하나에 교착 상태가 있음을 나타냅니다. 이 교착 상태로 인해 포드가 성공적으로 시작되지 않습니다. 해결 방법: 빠른 완화를 위해 노드를 다시 시작합니다. 다시 시작된 노드에서 교착 상태가 다시 발생할 수 있습니다. 더 강력한 완화를 위해 다음을 실행하여 노드 풀에서 이미지 스트리밍을 사용 중지합니다. gcloud container node-pools update NODE_POOL_NAME --cluster CLUSTER_NAME --no-enable-image-streaming |
다음 단계
문서에서 문제 해결 방법을 찾을 수 없으면 지원 받기를 참조하여 다음 주제에 대한 조언을 포함한 추가 도움을 요청하세요.
- Cloud Customer Care에 문의하여 지원 케이스를 엽니다.
- StackOverflow에서 질문하고
google-kubernetes-engine
태그를 사용하여 유사한 문제를 검색해 커뮤니티의 지원을 받습니다.#kubernetes-engine
Slack 채널에 가입하여 더 많은 커뮤니티 지원을 받을 수도 있습니다. - 공개 Issue Tracker를 사용하여 버그나 기능 요청을 엽니다.