Memecahkan masalah penyimpanan di GKE

Masalah terkait penyimpanan di cluster Google Kubernetes Engine (GKE) dapat muncul dalam berbagai cara, mulai dari hambatan performa dan kegagalan pemasangan volume hingga error saat menggunakan jenis disk tertentu dengan jenis mesin tertentu. Masalah ini dapat memengaruhi status aplikasi, persistensi data, dan kesehatan workload secara keseluruhan.

Gunakan dokumen ini untuk mengatasi masalah umum yang memengaruhi fungsi penyimpanan di cluster Anda. Temukan panduan tentang cara memecahkan masalah terkait penyediaan dan lampiran volume, akses dan performa data, serta pengelolaan kapasitas penyimpanan.

Informasi ini penting bagi Admin platform dan operator yang mengelola infrastruktur dan penyimpanan cluster serta Developer aplikasi yang workload-nya bergantung pada penyimpanan persisten. Untuk mengetahui informasi selengkapnya tentang peran umum dan contoh tugas yang kami referensikan dalam Google Cloud konten, lihat Peran dan tugas pengguna GKE umum.

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 container 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 type 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 berikut untuk menyelesaikan masalah ini:

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

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

Perbaiki

Masalah ini telah diperbaiki dalam container 1.6.0+. Versi GKE yang diperbaiki 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 container

Saat melakukan ekspansi volume, selalu pastikan untuk memperbarui 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 diperbarui ke nilai baru, tetapi ukuran sistem file tidak ditampilkan dalam container 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:

  1. Pertahankan objek PersistentVolume yang dimodifikasi seperti semula.
  2. Edit objek PersistentVolumeClaim dan tetapkan spec.resources.requests.storage ke nilai yang lebih tinggi daripada yang digunakan dalam PersistentVolume.
  3. 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.

Hyperdisk Storage Pool: 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 boot atau disk terlampir node Anda di Hyperdisk Storage Pool.

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

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

Untuk mengatasi masalah ini:

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

Tekanan penyimpanan node tinggi terdeteksi

Jika Anda mengamati peristiwa atau kondisi node yang terkait dengan StoragePressureRootFileSystem dengan alasan StoragePressureDetected, hal ini menunjukkan bahwa sistem file root node atau titik pemasangan penyimpanan penting mengalami penggunaan disk yang tinggi, mendekati kapasitasnya.

Saat mendeskripsikan node menggunakan perintah kubectl describe node NODE_NAME, Anda mungkin melihat peristiwa yang serupa dengan ini:

Events:
  Type     Reason                      Age   From                     Message
  ----     ------                      ----  ----                     -------
  ...
  Warning  StoragePressureDetected     46m   device-capacity-monitor  Node condition StoragePressureRootFileSystem is now: True, reason: StoragePressureDetected, message: "Disk /dev/nvme0n1 usage 89% exceeds threshold 85%"

Penyebab:

Alasan StoragePressureDetected menunjukkan bahwa penggunaan disk pada sistem file root node (sering kali mnt/stateful_partition atau pemasangan terkait) telah melebihi nilai minimum yang telah ditentukan (misalnya, 85%). Hal ini dapat disebabkan oleh hal berikut:

  • Workload yang menulis data berlebihan ke volume emptyDir yang tidak didukung oleh SSD Lokal.
  • Image container besar yang ditarik ke node.
  • File log yang terakumulasi di node.
  • Proses lain yang menggunakan ruang disk.

Penggunaan disk yang tinggi secara terus-menerus dapat menyebabkan ketidakstabilan node, penghentian Pod, dan kegagalan aplikasi.

Proses debug dan resolusi:

Mengidentifikasi penggunaan disk: gunakan SSH untuk terhubung ke node yang terpengaruh dan gunakan perintah seperti df -h untuk memeriksa penggunaan disk pada berbagai titik pemasangan, dengan memperhatikan /mnt/stateful_partition dan pemasangan penyimpanan efemeral.

Menganalisis pola penyimpanan workload: tinjau permintaan penyimpanan dan pola penggunaan Pod yang berjalan di node. Identifikasi apakah ada workload tertentu yang menggunakan penyimpanan efemeral dalam jumlah yang tidak proporsional.

Meningkatkan kapasitas penyimpanan node: ketahui bahwa resolusi utama sering kali adalah memastikan node Anda memiliki kapasitas penyimpanan yang memadai untuk workload Anda. Pertimbangkan hal berikut:

  • Menggunakan boot disk yang lebih besar: saat membuat node pool, pilih ukuran boot disk yang lebih besar jika workload Anda memerlukan lebih banyak penyimpanan efemeral pada sistem file root.
  • Menggunakan SSD lokal yang lebih besar untuk penyimpanan efemeral: untuk workload yang memerlukan penyimpanan efemeral berperforma tinggi dan latensi rendah, konfigurasi node pool Anda untuk menggunakan SSD Lokal. Hal ini memberikan kapasitas yang terpisah dan lebih besar untuk volume emptyDir.
  • Menyesuaikan permintaan atau batas workload: pastikan spesifikasi Pod Anda menyertakan permintaan dan batas penyimpanan efemeral yang sesuai untuk membantu penjadwal menempatkan Pod di node dengan ruang yang cukup dan mencegah penggunaan disk yang tidak terkendali.
  • Membersihkan resource yang tidak digunakan: hapus file yang tidak diperlukan, image container lama, atau log dari node jika file tersebut berkontribusi pada penggunaan disk yang tinggi.

Dengan mengatasi kapasitas dan penggunaan penyimpanan di node, Anda dapat mengurangi masalah terkait StoragePressureDetected dan membantu operasi node.

Langkah berikutnya