Halaman ini diterjemahkan oleh Cloud Translation API.

Memecahkan masalah penyimpanan di GKE

Autopilot Standard

Halaman ini menunjukkan cara menyelesaikan masalah terkait penyimpanan di cluster Google Kubernetes Engine (GKE).

Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care.

Error 400: Tidak dapat memasang RePD ke VM yang dioptimalkan

Persistent disk regional dibatasi agar tidak digunakan dengan mesin yang dioptimalkan untuk memori atau mesin yang dioptimalkan untuk komputasi.

Pertimbangkan untuk menggunakan kelas penyimpanan persistent disk non-regional jika penggunaan persistent disk regional bukan persyaratan wajib. Jika penggunaan persistent disk regional sangat wajib dilakukan, pertimbangkan untuk menjadwalkan strategi seperti taint dan toleransi untuk memastikan Pod yang memerlukan persistent disk regional dijadwalkan pada node pool yang bukan merupakan mesin yang dioptimalkan.

Memecahkan masalah terkait performa disk

Performa boot disk bersifat penting karena boot disk untuk node GKE tidak hanya digunakan untuk sistem operasi, tetapi juga untuk hal berikut:

Image Docker.
Sistem file penampung untuk sistem file yang tidak dipasang sebagai volume (yaitu, sistem file overlay), dan ini sering kali menyertakan direktori seperti /tmp.
Volume emptyDir yang didukung disk, kecuali jika node menggunakan SSD lokal.

Performa disk dibagikan untuk semua disk dengan jenis disk yang sama di sebuah node. Misalnya, jika Anda memiliki boot disk pd-standard 100 GB dan PersistentVolume pd-standard 100 GB dengan banyak aktivitas, performa boot disk akan menghasilkan performa disk sebesar 200 GB. Selain itu, jika ada banyak aktivitas di PersistentVolume, hal ini juga akan memengaruhi performa boot disk.

Jika menerima pesan yang serupa dengan yang berikut ini di node Anda, hal ini bisa menjadi gejala performa disk yang rendah:

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

Untuk membantu mengatasi masalah tersebut, tinjau hal-hal berikut:

Pastikan Anda telah membaca Perbandingan jenis disk penyimpanan dan memilih jenis persistent disk yang sesuai dengan kebutuhan Anda.
Masalah ini sering terjadi pada node yang menggunakan persistent disk standar dengan ukuran kurang dari 200 GB. Pertimbangkan untuk menambah ukuran disk Anda atau beralih ke SSD, terutama untuk cluster yang digunakan dalam produksi.
Sebaiknya aktifkan SSD lokal untuk penyimpanan efemeral di node pool Anda. Hal ini sangat efektif jika Anda memiliki container yang sering menggunakan volume emptyDir.

Memasang volume akan berhenti merespons karena setelan `fsGroup`

Satu masalah yang dapat menyebabkan pemasangan PersistentVolume gagal adalah Pod yang dikonfigurasi dengan setelan fsGroup. Biasanya, pemasangan otomatis akan melakukan percobaan ulang dan kegagalan pemasangan akan teratasi dengan sendirinya. Namun, jika PersistentVolume memiliki file dalam jumlah besar, kubelet akan mencoba mengubah kepemilikan pada setiap file di sistem file, yang dapat meningkatkan latensi pemasangan volume.

Unable to attach or mount volumes for pod; skipping pod ... timed out waiting for the condition

Untuk mengonfirmasi apakah error pemasangan gagal disebabkan oleh setelan fsGroup, Anda dapat memeriksa log untuk Pod. Jika masalahnya terkait dengan setelan fsGroup, Anda akan melihat entri log berikut:

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

Jika PersistentVolume tidak terpasang dalam beberapa menit, coba langkah-langkah berikut untuk menyelesaikan masalah ini:

Kurangi jumlah file dalam Volume.
Berhenti menggunakan setelan [fsGroup].
Ubah aplikasi fsGroupChangePolicy menjadi OnRootMismatch.

Operasi disk yang lambat menyebabkan kegagalan pembuatan Pod

Untuk informasi selengkapnya, lihat masalah dalam container #4604.

Versi node GKE yang terpengaruh: 1.18, 1.19, 1.20.0 hingga 1.20.15-gke.2100, 1.21.0 hingga 1.21.9-gke.2000, 1.21.10 hingga 1.21.10-gke.100, 1.22.0 hingga 1.22.6-gke.2000, 1.22.7 hingga 1.22.7-gke.100, 1.23.0 hingga 1.23.3-gke.700, 1.23.4 hingga 1.23.4-gke.100

Contoh error berikut mungkin ditampilkan dalam log 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"

Mitigasi

Jika Pod gagal, pertimbangkan untuk menggunakan restartPolicy:Always atau restartPolicy:OnFailure di PodSpec Anda.
Tingkatkan IOPS boot disk (misalnya, mengupgrade jenis disk atau menambah ukuran disk).

Perbaiki

Masalah ini telah diperbaiki di containerd 1.6.0+. Versi GKE dengan perbaikan ini adalah 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+, dan 1.23.4-gke.100+

Perubahan ekspansi volume tidak tercermin dalam sistem file penampung

Saat melakukan ekspansi volume, selalu pastikan untuk memperbarui PersistentVolumeClaim. Mengubah PersistentVolume secara langsung dapat menyebabkan perluasan volume tidak terjadi. Hal ini dapat menyebabkan salah satu skenario berikut:

Jika objek PersistentVolume diubah secara langsung, nilai PersistentVolume dan PersistentVolumeClaim akan diperbarui ke nilai baru, tetapi ukuran sistem file tidak ditampilkan dalam penampung dan masih menggunakan ukuran volume lama.
Jika objek PersistentVolume diubah secara langsung, diikuti dengan pembaruan pada PersistentVolumeClaim tempat kolom status.capacity diperbarui ke ukuran baru, hal ini dapat mengakibatkan perubahan pada PersistentVolume, tetapi tidak pada PersistentVolumeClaim atau sistem file container.

Untuk mengatasi masalah ini, selesaikan beberapa langkah berikut:

Pertahankan objek PersistentVolume yang dimodifikasi seperti semula.
Edit objek PersistentVolumeClaim dan tetapkan spec.resources.requests.storage ke nilai yang lebih tinggi daripada yang digunakan dalam PersistentVolume.
Pastikan apakah PersistentVolume diubah ukurannya ke nilai baru.

Setelah perubahan ini, PersistentVolume, PersistentVolumeClaim, dan sistem file container akan diubah ukurannya secara otomatis oleh kubelet.

Verifikasi apakah perubahan tersebut tercermin dalam Pod.

kubectl exec POD_NAME  -- /bin/bash -c "df -h"

Ganti POD_NAME dengan Pod yang dipasang ke PersistentVolumeClaim.

Jenis mesin yang dipilih harus memiliki SSD lokal

Anda mungkin mengalami error berikut saat membuat cluster atau node pool yang menggunakan SSD Lokal:

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.

Dalam pesan error, Anda mungkin melihat LocalNvmeSsdBlockConfig, bukan EphemeralStorageLocalSsdConfig, bergantung pada apa yang Anda tentukan.

Error ini terjadi ketika jumlah disk SSD Lokal yang ditentukan tidak sama dengan jumlah disk SSD Lokal yang disertakan dengan jenis mesin.

Untuk mengatasi masalah ini, tentukan jumlah disk SSD Lokal yang cocok dengan jenis mesin yang Anda inginkan. Untuk seri mesin generasi ketiga, Anda harus menghilangkan flag count SSD Lokal dan nilai yang benar akan dikonfigurasi secara otomatis.

Penyimpanan Gabungan Hyperdisk: Pembuatan cluster atau node pool gagal

Anda mungkin mengalami error ZONE_RESOURCE_POOL_EXHAUSTED atau error resource Compute Engine serupa saat mencoba menyediakan disk Hyperdisk Balanced sebagai disk booting atau terpasang node di Hyperdisk Storage Pool.

Hal ini terjadi saat Anda mencoba membuat cluster atau node pool GKE di zona yang kehabisan resource, misalnya:

Zona mungkin tidak memiliki cukup disk Hyperdisk Balanced yang tersedia.
Zona mungkin tidak memiliki kapasitas yang memadai untuk membuat node jenis mesin yang Anda tentukan, seperti c3-standard-4.

Untuk menyelesaikan masalah ini:

Pilih zona baru dalam region yang sama dengan kapasitas yang cukup untuk jenis mesin yang Anda pilih dan tempat Hyperdisk Balanced Storage Pool tersedia.
Hapus kumpulan penyimpanan yang ada dan buat ulang di zona baru. Hal ini karena storage pool adalah resource zona.
Buat cluster atau node pool di zona baru.

Langkah selanjutnya