Halaman ini diterjemahkan oleh Cloud Translation API.

Memecahkan masalah penyimpanan di GKE

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 bersifat wajib, pertimbangkan strategi penjadwalan seperti taint dan toleransi untuk memastikan Pod yang memerlukan persistent disk regional dijadwalkan di kumpulan node yang bukan 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 container untuk item yang tidak dipasang sebagai volume (yaitu, sistem file overlay), dan ini sering kali mencakup 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 sebesar 200 GB disk. Selain itu, jika ada banyak aktivitas pada 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 masalah 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.
Tingkatkan IOPS boot disk (misalnya, mengupgrade jenis disk atau menambah ukuran disk).

Perbaikan

Masalah ini telah diperbaiki dalam 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-gke.2000+, 1.22.7-gke.7.

Perubahan perluasan volume tidak terlihat di sistem file container

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

Jika objek PersistentVolume diubah secara langsung, nilai PersistentVolume dan PersistentVolumeClaim akan diupdate ke nilai baru, tetapi ukuran sistem file tidak tercermin dalam container dan masih menggunakan ukuran volume lama.
Jika objek PersistentVolume diubah secara langsung, diikuti dengan update pada PersistentVolumeClaim dengan 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 dari 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 kumpulan node 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 jika jumlah disk SSD Lokal yang ditentukan tidak cocok dengan jumlah disk SSD Lokal yang disertakan dengan jenis mesin.

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

Langkah selanjutnya