이 페이지에서는 Google Kubernetes Engine(GKE) 클러스터에서 스토리지 관련 문제를 해결하는 방법을 보여줍니다.
추가 지원이 필요하면 Cloud Customer Care에 문의합니다.오류 400: 최적화된 VM에 RePD를 연결할 수 없음
리전 영구 디스크는 메모리 최적화 머신 또는 컴퓨팅 최적화 머신과 함께 사용할 수 없도록 제한됩니다.
리전 영구 디스크를 사용하는 것이 필수 요구사항이 아닌 경우 리전이 아닌 영구 디스크 스토리지 클래스를 사용하는 것이 좋습니다. 리전 영구 디스크를 사용하는 것이 필수 요구사항인 경우 리전 영구 디스크가 필요한 포드가 최적화된 머신이 아닌 노드 풀에 예약되도록 taint 및 톨러레이션(toleration)과 같은 예약 전략을 수립하는 것이 좋습니다.
디스크 성능 문제 해결
GKE 노드의 부팅 디스크는 운영체제뿐만 아니라 다음에도 사용되므로 부팅 디스크의 성능이 중요합니다.
- Docker 이미지
- 볼륨으로 마운트되지 않는(즉, 오버레이 파일 시스템) 컨테이너 파일 시스템. 여기에는 일반적으로
/tmp같은 디렉터리가 포함됩니다. - 디스크 지원
emptyDir볼륨(노드가 로컬 SSD를 사용하는 경우는 제외)
디스크 성능은 노드에서 동일한 디스크 유형의 모든 디스크에 공유됩니다. 예를 들어 100GB pd-standard 부팅 디스크와 활동이 많은 100GB pd-standard PersistentVolume이 있는 경우 부팅 디스크의 성능은 200GB 디스크와 동일합니다. 또한 PersistentVolume에서 활동이 많으면 부팅 디스크의 성능에도 영향을 미칩니다.
노드에 다음과 유사한 메시지가 표시되면 디스크 성능이 저하되었음을 나타내는 증상일 수 있습니다.
INFO: task dockerd:2314 blocked for more than 300 seconds.
fs: disk usage and inodes count on following dirs took 13.572074343s
PLEG is not healthy: pleg was last seen active 6m46.842473987s ago; threshold is 3m0s
이러한 문제를 해결하려면 다음을 검토합니다.
- 스토리지 디스크 유형 비교를 참조하고 요구사항에 맞는 영구 디스크 유형을 선택하세요.
- 이 문제는 크기가 200GB 미만인 표준 영구 디스크를 사용하는 노드에서 자주 발생합니다. 특히 프로덕션에 사용되는 클러스터의 경우 디스크 크기를 늘리거나 SSD로 전환하는 것이 좋습니다.
- 노드 풀의 임시 스토리지에 로컬 SSD를 사용 설정하는 것이 좋습니다.
이 방법은
emptyDir볼륨을 자주 사용하는 컨테이너가 있는 경우에 특히 효과적입니다.
fsGroup 설정으로 인해 볼륨 마운트가 응답하지 않음
PersistentVolume 마운트가 실패하는 원인이 되는 한 가지 문제는 fsGroup 설정으로 구성된 포드입니다. 일반적으로 마운트가 자동으로 재시도 되므로 마운트 실패는 자동으로 해결됩니다. 그러나 PersistentVolume에 파일이 많으면 kubelet이 파일 시스템의 각 파일의 소유권을 변경하려고 시도하여 볼륨 마운트 지연 시간이 늘어날 수 있습니다.
Unable to attach or mount volumes for pod; skipping pod ... timed out waiting for the condition
fsGroup 설정으로 인해 실패한 마운트 오류가 발생했는지 확인하려면 포드의 로그를 확인하면 됩니다.
fsGroup 설정과 관련된 문제인 경우 다음 로그 항목이 표시됩니다.
Setting volume ownership for /var/lib/kubelet/pods/POD_UUID and fsGroup set. If the volume has a lot of files then setting volume ownership could be slow, see https://github.com/kubernetes/kubernetes/issues/69699
몇 분 내에 PersistentVolume이 마운트되지 않으면 다음 단계를 시도하여 이 문제를 해결하세요.
- 볼륨의 파일 수를 줄입니다.
[fsGroup]설정 사용을 중지합니다.- 애플리케이션
fsGroupChangePolicy를OnRootMismatch로 변경합니다.
느린 디스크 작업으로 인해 포드 생성 실패
자세한 내용은 containerd 문제 #4604를 참조하세요.
영향을 받는 GKE 노드 버전: 1.18, 1.19, 1.20.0~1.20.15-gke.2100, 1.21.0~1.21.9-gke.2000, 1.21.10~1.21.10-gke.100, 1.22.0~1.22.6-gke.2000, 1.22.7~1.22.7-gke.100, 1.23.0~1.23.3-gke.700, 1.23.4~1.23.4-gke.100
k8s_node container-runtime 로그에 다음 오류 예시가 표시될 수 있습니다.
Error: failed to reserve container name "container-name-abcd-ef12345678-91011_default_12131415-1234-5678-1234-12345789012_0": name "container-name-abcd-ef12345678-91011_default_12131415-1234-5678-1234-12345789012_0" is reserved for "1234567812345678123456781234567812345678123456781234567812345678"
위험 완화
- 포드가 실패하면 PodSpec에서
restartPolicy:Always또는restartPolicy:OnFailure을 사용하는 것이 좋습니다. - 부팅 디스크 IOPS를 늘립니다(예: 디스크 유형 업그레이드 또는 디스크 크기 증가).
수정
이 문제는 containerd 1.6.0 이상에서 수정되었습니다. 이 수정사항이 포함된 GKE 버전은 1.20.15-gke.2100+, 1.21.9-gke.2000+, 1.21.10-gke.100+, 1.22.6-gke.2000+, 1.22.7-gke.100+, 1.23.3-gke.1700+, 1.23.4-gke.100+입니다.
볼륨 확장 변경사항이 컨테이너 파일 시스템에 반영되지 않음
볼륨 확장을 수행할 때는 항상 PersistentVolumeClaim을 업데이트해야 합니다. PersistentVolume을 직접 변경하면 볼륨 확장이 진행되지 않을 수 있습니다. 이로 인해 다음 시나리오 중 하나가 발생할 수 있습니다.
PersistentVolume 객체가 직접 수정되면 PersistentVolume 및 PersistentVolumeClaim 값이 모두 새 값으로 업데이트되지만 파일 시스템 크기는 컨테이너에 반영되지 않고 여전히 이전 볼륨 크기를 사용합니다.
PersistentVolume 객체를 직접 수정한 후
status.capacity필드를 새 크기로 업데이트하는 PersistentVolumeClaim으로 업데이트하면 PersistentVolumeClaim 또는 컨테이너 파일 시스템이 아닌 PersistentVolume이 변경될 수 있습니다.
이 문제를 해결하려면 다음 단계를 완료하시기 바랍니다.
- 수정된 PersistentVolume 객체는 그대로 유지합니다.
- PersistentVolumeClaim 객체를 수정하고
spec.resources.requests.storage를 PersistentVolume에서 사용한 값보다 높은 값으로 설정합니다. - PersistentVolume의 크기가 새 값으로 조절되었는지 확인합니다.
이러한 변경 후에는 kubelet에서 PersistentVolume, PersistentVolumeClaim, 컨테이너 파일 시스템 크기를 자동으로 조절되어야 합니다.
변경사항이 포드에 반영되는지 확인합니다.
kubectl exec POD_NAME -- /bin/bash -c "df -h"
POD_NAME을 PersistentVolumeClaim에 연결된 포드로 바꿉니다.
선택한 머신 유형에 로컬 SSD가 있어야 함
로컬 SSD를 사용하는 클러스터나 노드 풀을 만들 때 다음 오류가 발생할 수 있습니다.
The selected machine type (c3-standard-22-lssd) has a fixed number of local SSD(s): 4. The EphemeralStorageLocalSsdConfig's count field should be left unset or set to 4, but was set to 1.
지정된 오류에 따라 오류 메시지에 EphemeralStorageLocalSsdConfig 대신 LocalNvmeSsdBlockConfig가 표시될 수 있습니다.
이 오류는 지정된 로컬 SSD 디스크 수가 머신 유형에 포함된 로컬 SSD 디스크 수와 일치하지 않을 때 발생합니다.
이 문제를 해결하려면 원하는 머신 유형과 일치하는 로컬 SSD 디스크 수를 지정합니다.
3세대 머신 시리즈의 경우 로컬 SSD count 플래그를 생략해야 합니다. 그러면 자동으로 올바른 값이 구성됩니다.
하이퍼디스크 스토리지 풀: 클러스터 또는 노드 풀 생성 실패
하이퍼디스크 스토리지 풀에서 하이퍼디스크 균형 디스크를 노드의 부팅 디스크 또는 연결된 디스크로 프로비저닝하려고 하면 ZONE_RESOURCE_POOL_EXHAUSTED 오류 또는 유사한 Compute Engine 리소스 오류가 발생할 수 있습니다.
이는 리소스가 부족한 영역에서 GKE 클러스터나 노드 풀을 만들려고 할 때 발생합니다. 예를 들면 다음과 같습니다.
- 해당 영역에서 사용할 수 있는 하이퍼디스크 균형 디스크가 충분하지 않을 수 있습니다.
- 지정한 머신 유형(예:
c3-standard-4)의 노드를 만들 만큼 영역의 용량이 충분하지 않을 수 있습니다.
이 문제를 해결하려면 다음 안내를 따르세요.
- 선택한 머신 유형에 충분한 용량이 있고 하이퍼디스크 균형 스토리지 풀을 사용할 수 있는 동일한 리전 내의 새 영역을 선택합니다.
- 기존 스토리지 풀을 삭제하고 새 영역에서 다시 만듭니다. 스토리지 풀은 영역별 리소스이기 때문입니다.
- 새 영역에서 클러스터 또는 노드 풀을 만듭니다.