Memecahkan masalah penyimpanan di GKE

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

Gunakan dokumen ini untuk menyelesaikan masalah umum yang memengaruhi fungsi penyimpanan di cluster Anda. Temukan panduan tentang pemecahan masalah terkait penyediaan dan pemasangan 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 mengandalkan penyimpanan persisten. Untuk mengetahui informasi selengkapnya tentang peran umum dan contoh tugas yang kami referensikan dalam konten Cloud de Confiance by S3NS , 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 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:

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 di 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 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 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 yang terpasang pada node 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 mungkin tidak memiliki kapasitas yang cukup untuk membuat node jenis mesin yang Anda tentukan, seperti c3-standard-4.

Untuk menyelesaikan masalah ini:

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

Tekanan penyimpanan node yang 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 direktori 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 mirip 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 menandakan bahwa penggunaan disk pada sistem file root node (sering kali mnt/stateful_partition atau pemasangan terkait) telah melampaui batas 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 ditarik ke node.
  • File log yang menumpuk di node.
  • Proses lain yang menggunakan kapasitas disk.

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

Proses debug dan penyelesaian:

Identifikasi penggunaan disk: gunakan SSH untuk terhubung ke node yang terpengaruh dan gunakan perintah seperti df -h untuk memeriksa penggunaan disk di berbagai direktori 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.

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

  • Gunakan boot disk yang lebih besar: saat membuat node pool, pilih ukuran boot disk yang lebih besar jika workload Anda memerlukan lebih banyak penyimpanan efemeral di sistem file root.
  • Gunakan SSD lokal yang lebih besar untuk penyimpanan efemeral: untuk workload yang memerlukan penyimpanan efemeral berperforma tinggi dan berlatensi rendah, konfigurasikan node pool Anda untuk menggunakan SSD Lokal. Hal ini memberikan kapasitas yang terpisah dan lebih besar untuk volume emptyDir.
  • Sesuaikan 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 untuk mencegah penggunaan disk yang tidak terkontrol.
  • Bersihkan resource yang tidak digunakan: hapus file yang tidak diperlukan, image container lama, atau log dari node jika berkontribusi pada penggunaan disk yang tinggi.

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

Memecahkan masalah peristiwa kehabisan memori (OOM) Cloud Storage FUSE

Jika Pod Anda mengalami penggunaan memori yang tinggi atau peristiwa Kehabisan Memori (OOM) yang terkait dengan driver CSI Cloud Storage FUSE, Anda dapat mengumpulkan dan menganalisis snapshot CPU dan memori menggunakan Cloud Profiler. Siapkan opsi ini di bagian Mengonfigurasi container sidecar driver CSI Cloud Storage FUSE.

Saat Pod mengalami penghentian OOM, Anda dapat menghubungkan peristiwa tersebut ke snapshot Cloud Profiler yang benar menggunakan alur kerja berikut:

  1. Periksa Cloud Logging: Buka Cloud Logging untuk menemukan Peristiwa OOM Kubernetes.

  2. Filter menurut nama Pod: Jalankan kueri berikut untuk menemukan log peristiwa untuk Pod tertentu, dengan mengganti POD_NAME dengan nama Pod workload:

    jsonPayload.involvedObject.name="POD_NAME"
jsonPayload.involvedObject.kind="Pod"
OOMKilled

  3. Ekstrak UID Pod: Luaskan log peristiwa OOM yang relevan dan catat stempel waktu serta UID Pod yang tepat yang terletak di jsonPayload.involvedObject.uid.

  4. Analisis di Cloud Profiler: Buka Cloud Profiler, filter Service Version menggunakan format POD_NAME_POD_UID, dan sesuaikan rentang waktu agar sesuai dengan stempel waktu OOM. Hal ini membantu memastikan Anda melihat profil memori yang tepat dari instance container tertentu tepat sebelum dihentikan.

Workload stateful terjebak dalam status Pending karena kapasitas komputasi tidak memadai

Jika Anda memiliki workload stateful yang terjebak dalam status Pending dengan pesan error seperti ZONE_RESOURCE_POOL_EXHAUSTED atau GCE_STOCKOUT, zona tertentu mungkin memiliki kapasitas komputasi yang terbatas.

Jika node komputasi offline di zona yang tidak memiliki kapasitas memadai, penggantian node tersebut mungkin akan gagal. Pod Stateful yang mengandalkan PersistentVolume zona yang sudah ada (seperti disk pd-ssd atau pd-balanced standar) dibatasi pada zona tempat volume tersebut dibuat. Karena Pod harus dijadwalkan di zona tertentu tersebut untuk memasang volume, Pod akan tetap Pending hingga kapasitas komputasi di zona tersebut tersedia.

Untuk mengurangi masalah ini pada workload stateful mendatang, pertimbangkan hal berikut:

  • Hindari penggantian zona yang sama antara pd-ssd dan pd-balanced: karena volume pd-ssd dan pd-balanced memiliki batas kapasitas dan kumpulan ketersediaan yang sama di suatu zona, mengubah StorageClass dari pd-ssd menjadi pd-balanced di zona yang sama tidak akan menyelesaikan masalah kekurangan kapasitas. Jangan coba ini sebagai penggantian.
  • Gunakan bentuk yang kompatibel dengan Hyperdisk: beberapa seri mesin mendukung Hyperdisk. Pertimbangkan untuk menggunakan bentuk yang kompatibel dengan Hyperdisk karena bentuk ini mungkin memiliki batasan ketersediaan yang berbeda yang membantu saat zona tidak memiliki kapasitas yang memadai. Sebelum memigrasikan workload, pastikan Anda memiliki Kuota disk yang cukup.
  • Mengaktifkan binding topologi dinamis (WaitForFirstConsumer): saat Anda membuat workload stateful baru, konfigurasikan definisi StorageClass Anda dengan pasangan nilai kolom volumeBindingMode: WaitForFirstConsumer. Setelan ini menunda pembuatan volume hingga Pod dijadwalkan ke node yang responsif di zona dengan kapasitas komputasi yang memadai, yang membantu mencegah pembuatan volume prematur mengunci Pod Anda ke zona offline atau habis.
  • Mengonfigurasi pemilihan jenis disk otomatis untuk penggantian VM: di GKE versi 1.35.3-gke.1290000 dan yang lebih baru, Anda dapat mengonfigurasi ComputeClass kustom untuk workload yang beralih ke generasi VM yang lebih lama (misalnya, N4 ke N2, atau C4 ke C2). Dengan menggunakan pemilihan jenis disk otomatis, Anda dapat mengonfigurasi definisi StorageClass dengan pasangan nilai kolom parameters.type: dynamic dan use-allowed-disk-topology: "true". Konfigurasi ini memungkinkan GKE menyediakan disk hyperdisk-balanced secara otomatis pada generasi mesin yang lebih baru dan beralih ke disk pd-balanced pada generasi yang lebih lama.

Langkah berikutnya