Dokumen ini membantu Anda menavigasi dokumentasi Google Kubernetes Engine (GKE) untuk menemukan panduan dan rekomendasi pengoptimalan biaya. GKE menawarkan kemampuan penskalaan otomatis dan penjadwalan yang luas yang dapat Anda gunakan untuk meminimalkan biaya cluster sekaligus mempertahankan stabilitas aplikasi.
Untuk ringkasan gabungan semua praktik terbaik GKE, lihat Praktik terbaik untuk GKE.Anda harus sudah memahami hal berikut:
Ringkasan
Saat menerapkan GKE, Anda harus mempertimbangkan berbagai aspek teknis agar selaras dengan persyaratan aplikasi dan bisnis. Selain menentukan jaringan, keamanan, penyimpanan, dan aspek teknis lainnya, Anda harus mengevaluasi biaya dan performa untuk memenuhi kebutuhan bisnis. Daripada memperlakukan biaya dan performa sebagai entitas yang berbeda, Anda harus mengintegrasikannya sejak tahap awal perencanaan infrastruktur untuk menentukan hubungan terpadu yang menentukan keandalan dan pengeluaran cloud. Biaya rendah dan keandalan tinggi diharapkan, tetapi saat Anda melakukan penskalaan, kompleksitas pengelolaan kompromi ini akan meningkat.
Untuk mencapai biaya rendah dan stabilitas aplikasi, Anda dapat menetapkan atau menyesuaikan fitur GKE berikut:
- Konfigurasi GKE
- Konfigurasi workload
- Dasar pengukuran dan visibilitas biaya
Menggunakan Autopilot GKE
Untuk lingkungan sandbox atau pengembangan kecil, pilih cluster Autopilot. Dalam mode Autopilot, GKE mengelola node secara dinamis dan Anda hanya ditagih untuk kapasitas Pod yang diminta, yang membantu Anda menghindari biaya VM, sistem operasi node, dan overhead sistem.
Untuk mengetahui informasi selengkapnya, lihat Ringkasan Autopilot GKE.
Memahami cara kerja penskalaan otomatis
Pengontrol penskalaan otomatis GKE menyesuaikan resource secara dinamis saat permintaan traffic berubah.
Menambahkan dan menghapus Pod berdasarkan metrik penggunaan
HorizontalPodAutoscaler (HPA) menambahkan dan menghapus Pod berdasarkan CPU atau metrik kustom.
Untuk memahami dan mengonfigurasi penskalaan otomatis Pod horizontal, lihat dokumentasi GKE berikut:
- Konsep penskalaan otomatis Pod horizontal
- Mengonfigurasi penskalaan otomatis Pod horizontal
- Melihat peristiwa Horizontal Pod Autoscaler
- Mengekspos metrik aplikasi kustom untuk penskalaan otomatis
Konfigurasikan nilai minimum penggunaan target (misalnya, 70% atau 80%) untuk mempertahankan buffer yang menangani lonjakan traffic saat Pod replika tambahan dimulai.
Menskalakan Pod berdasarkan metrik penggunaan
Gunakan VerticalPodAutoscaler (VPA) untuk mengubah ukuran permintaan CPU dan memori container secara dinamis untuk workload yang tidak menggunakan penskalaan otomatis Pod horizontal, atau saat workload puncak tidak diketahui.
Untuk memahami dan mengonfigurasi penskalaan otomatis Pod vertikal, lihat dokumentasi GKE berikut:
Pertahankan VPA dalam mode Off (hanya rekomendasi) selama minimal 24 jam (sebaiknya satu minggu) di lingkungan seperti produksi untuk menangkap pola traffic representatif. Untuk mencegah penyesuaian ukuran yang tidak menentu, tentukan batas minimum dan maksimum eksplisit dalam objek VerticalPodAutoscaler sebelum mengaktifkan mode Initial atau Auto.
Mengotomatiskan penskalaan infrastruktur menggunakan Cluster Autoscaler
Untuk menskalakan node komputasi yang mendasarinya berdasarkan simulasi penjadwalan aktif, bukan beban metrik, aktifkan Cluster Autoscaler di node pool GKE Standard. Tentukan parameter node minimum untuk mendukung kapasitas malam dasar pengukuran.
Selalu konfigurasi objek PodDisruptionBudget (PDB) untuk Pod sistem dan aplikasi. Konfigurasi ini membantu memastikan bahwa Cluster Autoscaler tidak menyebabkan gangguan layanan secara tidak sengaja saat menggabungkan atau menskalakan node pool yang kurang dimanfaatkan.
Untuk memahami dan mengonfigurasi Cluster Autoscaler, lihat dokumentasi GKE berikut:
- Tentang penskalaan otomatis cluster GKE
- Menskalakan cluster secara otomatis
- Melihat peristiwa autoscaler cluster
Men-deploy node pool dinamis menggunakan pembuatan otomatis node pool
Aktifkan pembuatan otomatis node pool untuk otomatis membuat node pool GKE kustom yang bentuk, jumlah CPU, atau batas memorinya sesuai dengan parameter penjadwalan Pod yang tertunda. Fitur ini meminimalkan resource yang tersisa di node yang terlalu besar.
Untuk memahami dan mengonfigurasi pembuatan otomatis node pool, lihat dokumentasi GKE berikut:
Checklist penskalaan otomatis
Karakteristik infrastruktur
Selaraskan hardware cluster, lokasi, dan aturan jaringan node dengan prioritas pengoptimalan biaya.
Memilih jenis mesin yang sesuai
Pilih jenis mesin yang sesuai untuk cluster Anda berdasarkan lokasi pengguna dan lokasi data yang perlu diakses cluster Anda.
Untuk mengetahui informasi selengkapnya, lihat Panduan perbandingan dan resource kelompok mesin guide.
Men-deploy workload fault-tolerant di Spot VM
Gunakan Spot VM untuk menjalankan workload stateless, fault-tolerant, atau batch dengan diskon hingga 91% dibandingkan dengan instance VM sesuai permintaan.
Untuk mengetahui informasi selengkapnya, lihat dokumentasi GKE berikut:
- Konsep Spot VM
- Menjalankan workload fault-tolerant dengan biaya lebih rendah menggunakan Spot VM
- Menjalankan workload fault-tolerant dengan biaya lebih rendah di Pod Spot
Memetakan kelompok mesin dan setelan sistem OS yang efisien
Sesuaikan setelan mesin node pool dengan profil instance yang hemat biaya (misalnya, arsitektur VM E2).
Untuk mengetahui informasi selengkapnya tentang ukuran node, mengonfigurasi waktu penghentian Spot VM, dan mengonfigurasi konfigurasi kernel, lihat Tentang node pool.
Memilih region yang sesuai
Jika latensi tidak memengaruhi pengguna, jalankan workload cluster di region Compute Engine dengan biaya operasional yang lebih rendah.
Untuk mengetahui informasi selengkapnya, lihat Praktik terbaik untuk pemilihan region Compute Engine.
Mendaftar untuk CUD
Beli diskon abonemen (CUD) untuk mengamankan harga yang sangat didiskon (hingga 70%) untuk resource komputasi dasar selama jangka waktu satu tahun atau tiga tahun.
Untuk mengetahui informasi selengkapnya, lihat Diskon abonemen berbasis resource.
Mempertimbangkan biaya jaringan
Cluster GKE regional dan multi-zona meningkatkan keandalan aplikasi, tetapi dapat menghasilkan biaya traffic keluar jaringan lintas zona internal.
Untuk meminimalkan dan mengontrol biaya jaringan, pertimbangkan hal berikut:
- Transfer data lintas zona: meskipun cluster regional meningkatkan ketersediaan dengan menyebarkan workload di seluruh zona, ada biaya terkait untuk data yang ditransfer antar-zona ini.
Untuk mengetahui informasi selengkapnya, lihat Semua harga jaringan.
Men-deploy cluster zona tunggal untuk lingkungan non-produksi
Di lingkungan non-produksi, untuk menghindari biaya jaringan lintas zona dan mengurangi overhead VM, deploy cluster zona tunggal, bukan cluster regional atau multi-zona.
Untuk mengetahui informasi selengkapnya, lihat Tentang pilihan konfigurasi cluster.
Mengoptimalkan jalur resolusi DNS cluster dan traffic masuk
Untuk mengoptimalkan resolusi DNS cluster dan traffic masuk, Anda dapat men-deploy NodeLocal DNSCache dan grup endpoint jaringan (NEG).
Saat Anda menjalankan workload yang menggunakan banyak DNS, NodeLocal DNSCache akan menjalankan daemon DNS lokal di setiap node. Konfigurasi ini mencegah beban kueri tinggi menghabiskan CoreDNS, sehingga tidak perlu menskalakan CoreDNS dan mengurangi biaya GKE secara keseluruhan.
Untuk traffic masuk, load balancing berbasis container melalui NEG merutekan traffic langsung ke alamat IP Pod, bukan grup instance. Perutean langsung ini memfasilitasi pengalihan traffic yang lancar selama tindakan penskalaan Pod.
Untuk mengetahui informasi selengkapnya, lihat:
- Menyiapkan NodeLocal DNSCache
- Ringkasan load balancing berbasis container
- Mengonfigurasi Ingress untuk Load Balancer Aplikasi eksternal
Menerapkan kuota resource per namespace
Deploy objek ResourceQuota Kubernetes standar per namespace di cluster multi-tenant untuk mengunci nilai minimum bentuk CPU dan memori serta mencegah setiap tim menjadwalkan workload yang tidak sesuai dan memicu biaya komputasi yang tidak terduga.
Untuk mengetahui informasi selengkapnya, lihat Namespace dalam dokumentasi Kubernetes.
Menerapkan audit Pengontrol Kebijakan
Deploy Pengontrol Kebijakan untuk mengaudit dan menerapkan kepatuhan cluster secara dinamis terhadap standar perusahaan. Pengontrol Kebijakan menggunakan kontrol penerimaan untuk menolak resource yang salah konfigurasi.
Untuk mengetahui informasi selengkapnya, lihat:
Menutup manifes yang tidak sesuai di pipeline CI/CD
Validasi kepatuhan kebijakan biaya lebih awal dalam siklus proses pengembangan Anda.
Integrasikan skrip validasi (seperti penguraian kpt) ke dalam pemeriksaan pra-commit atau permintaan pull untuk mengaudit dan memblokir manifes yang tidak sesuai sebelum mencapai cluster.
Untuk mengetahui informasi selengkapnya, lihat Memvalidasi aplikasi berdasarkan kebijakan perusahaan di pipeline CI.
Checklist infrastruktur
Pengoptimalan aplikasi dan workload
Konfigurasikan workload Anda untuk menggunakan resource secara efisien dan mengurangi overhead operasional.
Menentukan permintaan dan batas memori yang cocok
Tentukan permintaan CPU dan memori container yang tepat sebelum deployment. Untuk CPU, konfigurasikan permintaan untuk memenuhi tujuan tingkat layanan (SLO), tetapi biarkan batas tidak dibatasi. Untuk memori, pastikan alokasi yang diminta cocok dengan batas memori.
Untuk mengetahui informasi selengkapnya, lihat Mengubah Ukuran Resource CPU dan Memori yang ditetapkan ke Container dalam dokumentasi Kubernetes.
Mempercepat waktu mulai container
Buat image container sekecil mungkin untuk meminimalkan waktu download image.
Mengonfigurasi PDB
Tentukan objek PodDisruptionBudget (PDB) untuk replika aplikasi guna membatasi gangguan sukarela dan memastikan stabilitas saat GKE menskalakan atau saat upgrade node terjadi.
Untuk mengetahui informasi selengkapnya, lihat Menentukan Anggaran Gangguan untuk Aplikasi Anda.
Menetapkan pemeriksaan kesiapan dan keaktifan yang bermakna
Konfigurasikan pemeriksaan kesiapan dan keaktifan untuk semua container guna membantu memastikan bahwa GKE merutekan traffic hanya ke Pod yang siap dan memulai ulang instance yang gagal, sehingga mencegah kehilangan traffic selama penskalaan otomatis.
Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi Pemeriksaan Keaktifan, Kesiapan, dan Proses Mulai Sistem Probes.
Mengonfigurasi penonaktifan aplikasi yang lancar
Siapkan container untuk penghentian yang lancar dengan memproses sinyal SIGTERM, menyelesaikan permintaan yang sedang berlangsung sebelum keluar, atau dengan mengonfigurasi hook preStop.
Untuk mengetahui informasi selengkapnya, lihat Penghentian dan penghentian normal untuk VM preemptible.
Menerapkan percobaan ulang dengan backoff eksponensial
Terapkan percobaan ulang backoff eksponensial di tingkat aplikasi atau service mesh untuk menangani kegagalan sementara atau kemungkinan penghentian Spot VM.
Untuk mengetahui informasi selengkapnya, lihat Percobaan ulang dalam dokumentasi Istio.
Checklist pengoptimalan aplikasi dan workload
Dasar pengukuran dan visibilitas biaya
Untuk mengoptimalkan biaya, Anda harus terlebih dahulu memiliki visibilitas ke pengeluaran GKE dan cara alokasinya. Visibilitas ini membantu Anda mengaitkan biaya dengan tim dan unit bisnis yang menanggungnya.
Dokumentasi GKE berikut menjelaskan cara menetapkan visibilitas mendalam ke penagihan GKE, konsumsi resource, dan metrik dasar pengukuran.
Mengaktifkan alokasi biaya GKE
Aktifkan alokasi biaya GKE untuk mendapatkan visibilitas ke permintaan resource workload dan biaya terkait. Atribut alokasi biaya mengaitkan biaya cluster dengan namespace dan label Kubernetes dari workload Anda.
Ekspor detail ini ke BigQuery untuk menganalisis data di Penagihan Cloud. Gunakan analisis ini untuk mengidentifikasi workload mana yang menyebabkan puncak penagihan, melakukan penagihan balik, dan mengoptimalkan permintaan resource.
Untuk mengetahui informasi selengkapnya, lihat Mendapatkan analisis pengeluaran utama untuk alokasi resource dan biaya cluster GKE.
Meninjau volume penyerapan log dan metrik
Mengaktifkan Cloud Logging dan Cloud Monitoring untuk cluster Anda akan dikenai biaya. Volume penyerapan log dan metrik kustom yang tinggi dapat mengakibatkan biaya yang tidak terduga. Audit secara terpusat tingkat log dan metrik kustom yang diserap.
Untuk mengetahui informasi selengkapnya tentang cara memecahkan masalah penggunaan API logging yang tinggi atau waktu tunggu batas penulisan log, lihat:
Memantau kondisi Server Metrik
Pantau kondisi Deployment Server Metrik, karena pengontrol penskalaan otomatis bawaan GKE mengandalkannya untuk mengambil metrik CPU dan memori.
Untuk mengetahui informasi selengkapnya, lihat Memecahkan masalah penskalaan otomatis Pod horizontal.
Mendorong budaya hemat biaya
Berikan akses kepada developer ke dasbor pengeluaran cloud dan buat pelatihan FinOps untuk menyelaraskan keputusan arsitektur dengan anggaran biaya bisnis.
Untuk mengetahui informasi selengkapnya tentang budaya efisiensi biaya organisasi, lihat Sebarkan budaya hemat biaya.
Checklist dasar pengukuran dan visibilitas biaya
Langkah berikutnya
Untuk mengetahui informasi selengkapnya tentang prinsip arsitektur dan budaya organisasi yang diperlukan untuk efisiensi biaya, lihat Praktik terbaik untuk menjalankan aplikasi Kubernetes yang hemat biaya di GKE.