Halaman ini menjelaskan cara merencanakan ukuran node di node pool Google Kubernetes Engine (GKE) Standard untuk mengurangi risiko gangguan workload dan penghentian resource. Perencanaan ini tidak diperlukan dalam GKE Autopilot karena Google mengelola node untuk Anda.
Manfaat node yang berukuran tepat
Memastikan node Anda berukuran tepat untuk mengakomodasi workload dan untuk menangani lonjakan aktivitas, akan memberikan manfaat seperti berikut:
- Keandalan workload yang lebih baik karena mengurangi risiko penghapusan di luar resource.
- Peningkatan skalabilitas untuk menskalakan workload selama periode traffic tinggi.
- Biaya lebih rendah karena node tidak terlalu besar untuk kebutuhan Anda, yang dapat mengakibatkan resource terbuang percuma.
Resource node yang dapat dialokasikan
Node GKE menjalankan komponen sistem yang memungkinkan node berfungsi sebagai bagian dari cluster Anda. Komponen ini menggunakan resource node, seperti CPU dan memori. Mungkin Anda melihat perbedaan antara total resource node, yang didasarkan pada ukuran mesin virtual (VM) Compute Engine yang mendasarinya, dan resource yang tersedia untuk diminta oleh workload GKE Anda. Perbedaan ini karena GKE mencadangkan jumlah resource yang telah ditetapkan untuk fungsionalitas sistem dan keandalan node. Kapasitas disk yang dicadangkan GKE untuk resource sistem berbeda-beda berdasarkan image node. Resource sisa yang tersedia untuk workload Anda disebut resource yang dapat dialokasikan.
Saat menentukan Pod dalam manifes, Anda dapat menentukan permintaan dan batas resource dalam spesifikasi Pod. Saat GKE menempatkan Pod di suatu node, Pod akan meminta resource yang ditentukan tersebut dari resource yang dapat dialokasikan pada node. Saat merencanakan ukuran node di node pool, Anda harus mempertimbangkan jumlah resource yang diperlukan workload agar dapat berfungsi dengan benar.
Memeriksa resource yang dapat dialokasikan pada node
Untuk memeriksa resource yang dapat dialokasikan pada node yang ada, jalankan perintah berikut:
kubectl get node NODE_NAME \
-o=yaml | grep -A 7 -B 7 capacity
Ganti NODE_NAME dengan nama node.
Outputnya mirip dengan hal berikut ini:
allocatable:
attachable-volumes-gce-pd: "127"
cpu: 3920m
ephemeral-storage: "47060071478"
hugepages-1Gi: "0"
hugepages-2Mi: "0"
memory: 13498416Ki
pods: "110"
capacity:
attachable-volumes-gce-pd: "127"
cpu: "4"
ephemeral-storage: 98831908Ki
hugepages-1Gi: "0"
hugepages-2Mi: "0"
memory: 16393264Ki
pods: "110"
Dalam output ini, nilai di bagian allocatable adalah resource
yang dapat dialokasikan pada node. Nilai di bagian capacity adalah total resource pada node. Unit penyimpanan {i>ephemeral<i} adalah byte.
Reservasi resource GKE
GKE mencadangkan jumlah resource CPU dan memori tertentu pada node berdasarkan total ukuran resource yang tersedia di node tersebut. Jenis mesin yang lebih besar menjalankan lebih banyak container dan Pod, sehingga jumlah resource yang dicadangkan GKE ditingkatkan untuk mesin yang lebih besar. Node Windows Server juga memerlukan lebih banyak sumber daya daripada node Linux yang setara, untuk memperhitungkan menjalankan OS Windows dan untuk komponen Windows Server yang tidak dapat berjalan dalam container.
Reservasi memori dan CPU
Bagian berikut menjelaskan reservasi memori dan CPU default berdasarkan jenis mesin.
Reservasi memori
Untuk resource memori, GKE mencadangkan hal berikut:
- Memori 255 MiB untuk mesin dengan memori kurang dari 1 GiB
- 25% dari 4 GiB pertama memori
- 20% dari 4 GiB memori berikutnya (hingga 8 GiB)
- 10% dari 8 GiB memori berikutnya (hingga 16 GiB)
- 6% dari 112 GiB memori berikutnya (hingga 128 GiB)
- 2% dari memori apa pun di atas 128 GiB
GKE juga menyimpan memori tambahan sebesar 100 MiB di setiap node untuk menangani penghapusan Pod.
Reservasi CPU
Untuk resource CPU, GKE mencadangkan hal berikut:
- 6% dari inti pertama
- 1% dari inti berikutnya (hingga 2 inti)
- 0,5% dari 2 inti berikutnya (hingga 4 inti)
- 0,25% dari setiap inti di atas 4 inti
Untuk jenis mesin E2 dengan inti bersama, GKE mencadangkan total 1.060 milidetik.
Reservasi penyimpanan efemeral lokal
GKE menyediakan penyimpanan efemeral lokal pada node, yang didukung oleh perangkat yang terpasang secara lokal, seperti boot disk node atau SSD lokal. Penyimpanan efemeral tidak menjamin ketersediaan, dan data dalam penyimpanan efemeral dapat hilang jika node gagal dan dihapus.
GKE mencadangkan sebagian dari total penyimpanan efemeral node sebagai sistem file tunggal untuk digunakan oleh kubelet selama penghapusan Pod, dan untuk komponen sistem lainnya yang berjalan pada node. Anda dapat mengalokasikan penyimpanan efemeral yang tersisa ke Pod untuk digunakan untuk berbagai tujuan seperti log. Untuk mempelajari cara menentukan permintaan dan batas penyimpanan efemeral di Pod, lihat Penyimpanan efemeral lokal.
GKE menghitung reservasi penyimpanan efemeral lokal sebagai berikut:
EVICTION_THRESHOLD + SYSTEM_RESERVATION
Nilai sebenarnya bervariasi berdasarkan ukuran dan jenis perangkat yang mendukung penyimpanan.
Penyimpanan efemeral yang didukung oleh boot disk node
Secara default, penyimpanan efemeral didukung oleh boot disk node. Dalam hal ini, GKE menentukan nilai batas penghapusan sebagai berikut:
EVICTION_THRESHOLD = 10% * BOOT_DISK_CAPACITY
Nilai minimum penghapusan selalu 10% dari total kapasitas boot disk.
GKE menentukan nilai reservasi sistem sebagai berikut:
SYSTEM_RESERVATION = Min(50% * BOOT_DISK_CAPACITY, 6GiB + 35% * BOOT_DISK_CAPACITY, 100 GiB)
Jumlah reservasi sistem adalah yang terendah dari jumlah berikut:
- 50% kapasitas boot disk
- 35% kapasitas boot disk + 6 GiB
- 100 GiB
Misalnya, jika boot disk Anda adalah 300 GiB, nilai berikut akan berlaku:
- 50% kapasitas: 150 GiB
- 35% kapasitas + 6 GiB: 111 GiB
- 100 GiB
GKE akan mencadangkan hal berikut:
- Reservasi sistem: 100 GiB (nilai terendah)
- Nilai minimum penghapusan: 30 GiB
Total penyimpanan efemeral yang dicadangkan adalah 130 GiB. Kapasitas yang tersisa, 170 GiB, adalah penyimpanan efemeral yang dapat dialokasikan.
Penyimpanan efemeral yang didukung oleh SSD lokal
Jika penyimpanan efemeral Anda didukung oleh SSD lokal, GKE akan menghitung nilai minimum penghapusan sebagai berikut:
EVICTION_THRESHOLD = 10% * SSD_NUMBER * 375 GB
Dalam penghitungan ini, SSD_NUMBER adalah jumlah SSD lokal yang terpasang. Semua SSD lokal berukuran 375 GB, sehingga nilai minimum penghapusannya adalah 10% dari total kapasitas penyimpanan efemeral.
GKE menghitung reservasi sistem bergantung pada jumlah SSD yang terpasang, sebagai berikut:
| Jumlah SSD lokal | Reservasi sistem (GiB) |
|---|---|
| 1 | 50 GiB |
| 2 | 75 GiB |
| 3 atau lebih | 100 GiB |
Menggunakan reservasi resource untuk merencanakan ukuran node
Pertimbangkan persyaratan resource workload Anda pada waktu deployment dan saat memuat. Ini termasuk permintaan dan batas yang direncanakan untuk workload, serta overhead untuk mengakomodasi peningkatan skala.
Pertimbangkan apakah Anda ingin sejumlah kecil node besar atau sejumlah besar node kecil untuk menjalankan workload Anda.
- Sejumlah kecil node besar berfungsi dengan baik untuk workload intensif resource yang tidak memerlukan ketersediaan tinggi. Penskalaan otomatis node kurang tangkas karena makin banyak Pod yang harus dikeluarkan agar penurunan skala terjadi.
- Sejumlah besar node kecil berfungsi dengan baik untuk workload yang sangat tersedia yang tidak intensif resource. Penskalaan otomatis node lebih tangkas karena lebih sedikit Pod harus dikeluarkan agar penurunan skala terjadi.
Gunakan panduan perbandingan kelompok mesin Compute Engine untuk menentukan rangkaian mesin dan rangkaian yang Anda inginkan untuk node Anda.
Pertimbangkan persyaratan penyimpanan efemeral workload Anda. Apakah boot disk node sudah cukup? Apakah Anda memerlukan SSD lokal?
Hitung resource yang dapat dialokasikan pada jenis mesin yang Anda pilih menggunakan informasi di bagian sebelumnya. Bandingkan ini dengan sumber daya dan overhead yang Anda butuhkan.
- Jika jenis mesin yang Anda pilih terlalu besar, pertimbangkan mesin yang lebih kecil agar tidak membayar resource tambahan.
- Jika jenis mesin yang Anda pilih terlalu kecil, pertimbangkan mesin yang lebih besar untuk mengurangi risiko gangguan workload.
Langkah selanjutnya
- Memilih jenis mesin untuk node pool
- Menjadwalkan workload pada node pool tertentu menggunakan taint node