Praktik terbaik untuk menjalankan aplikasi Kubernetes hemat biaya di GKE

Dokumen ini membahas Google Kubernetes Engine (GKE) fitur dan opsi, serta praktik terbaik untuk menjalankan aplikasi dengan hemat biaya di GKE guna memanfaatkan elastisitas yang disediakan oleh Google Cloud. Dokumen ini mengasumsikan bahwa Anda mengenal Kubernetes, Google Cloud, GKE, dan penskalaan otomatis.

Pengantar

Seiring dengan semakin banyaknya adopsi Kubernetes, semakin banyak perusahaan dan penyedia platform-as-a-service (PaaS) dan software-as-a-service (SaaS) yang menggunakan cluster Kubernetes multi-tenant untuk workload mereka. Artinya, satu cluster mungkin menjalankan aplikasi milik departemen, tim, pelanggan, atau lingkungan yang berbeda. Multi-tenancy yang disediakan oleh Kubernetes memungkinkan perusahaan mengelola beberapa cluster besar, dan bukan beberapa cluster yang lebih kecil, dengan manfaat seperti penggunaan resource yang sesuai, kontrol pengelolaan yang disederhanakan, dan fragmentasi yang lebih kecil.

Seiring waktu, beberapa perusahaan dengan cluster Kubernetes yang berkembang pesat ini mulai mengalami peningkatan biaya yang tidak proporsional. Hal ini terjadi karena perusahaan tradisional yang menerapkan solusi berbasis cloud seperti Kubernetes tidak memiliki developer dan operator yang memiliki keahlian cloud. Kurangnya kesiapan cloud ini dapat menyebabkan aplikasi menjadi tidak stabil selama penskalaan otomatis (misalnya, volatilitas traffic selama periode yang teratur dalam sehari), burst yang tiba-tiba, atau lonjakan (seperti iklan TV atau peristiwa skala puncak) seperti Black Friday dan Cyber Monday). Dalam upaya untuk "memperbaiki" masalah, perusahaan ini cenderung menyediakan cluster secara berlebihan seperti yang biasa digunakan di lingkungan yang tidak elastis. Penyediaan yang berlebihan mengakibatkan alokasi CPU dan memori yang jauh lebih tinggi dibandingkan yang digunakan aplikasi hampir sepanjang hari.

Dokumen ini memberikan praktik terbaik untuk menjalankan workload Kubernetes dengan hemat biaya di GKE. Diagram berikut menguraikan pendekatan ini.

Pendekatan untuk mengoptimalkan biaya aplikasi Kubernetes.

Fondasi dari pembuatan aplikasi yang hemat biaya adalah menyebarkan budaya penghematan biaya ke berbagai tim. Selain memindahkan diskusi biaya ke awal proses pengembangan, pendekatan ini mengharuskan Anda untuk lebih memahami lingkungan tempat aplikasi Anda berjalan, dalam konteks ini, lingkungan GKE.

Untuk mencapai biaya rendah dan stabilitas aplikasi, Anda harus mengatur atau menyesuaikan beberapa fitur dan konfigurasi dengan benar (seperti penskalaan otomatis, jenis mesin, dan pemilihan region). Pertimbangan penting lainnya adalah jenis workload Anda karena, bergantung pada jenis workload dan persyaratan aplikasi, Anda harus menerapkan konfigurasi yang berbeda untuk lebih menurunkan biaya. Terakhir, Anda harus memantau pengeluaran dan membuat pengamanan sehingga Anda dapat menerapkan praktik terbaik di awal siklus pengembangan.

Tabel berikut merangkum tantangan yang dibantu oleh GKE untuk mengatasinya. Meskipun kami mendorong Anda untuk membaca seluruh dokumen, tabel ini menyajikan peta tentang hal-hal yang dicakup.

Tantangan Tindakan
Saya ingin melihat penghematan biaya yang mudah di GKE. Pilih region yang sesuai, daftar untuk mendapatkan diskon abonemen, dan gunakan jenis mesin E2.
Saya perlu memahami biaya GKE saya. Amati cluster GKE Anda dan perhatikan rekomendasi, serta aktifkan pengukuran penggunaan GKE
Saya ingin mengoptimalkan elastisitas GKE untuk workload saya saat ini. Baca Autoscaler Pod Horizontal, Autoscaler Cluster, dan pahami praktik terbaik untuk Autoscaler dan penyediaan yang berlebihan.
Saya ingin menggunakan jenis mesin yang paling efisien. Pilih jenis mesin yang tepat untuk workload Anda.
Banyak node di cluster saya sedang tidak ada aktivitas. Baca praktik terbaik untuk Autoscaler Cluster.
Saya perlu meningkatkan penghematan biaya dalam tugas batch saya. Baca praktik terbaik untuk workload batch.
Saya perlu meningkatkan penghematan biaya dalam workload aktif saya. Baca praktik terbaik untuk aktif workload.
Saya tidak tahu cara menentukan ukuran permintaan resource Pod saya. Gunakan Autoscaler Pod Vertikal (VPA), tetapi perhatikan saat menggabungkan praktik terbaik Autoscaler Pod Horizontal (HPA) dan VPA.
Aplikasi saya tidak stabil selama aktivitas penskalaan otomatis dan pemeliharaan. Siapkan aplikasi berbasis cloud untuk Kubernetes, dan pahami cara kerja Server Metrik dan cara memantaunya.
Bagaimana cara agar developer saya memperhatikan penggunaan resource aplikasi mereka? Sebarkan budaya hemat biaya, pertimbangkan untuk menggunakan GKE Enterprise Policy Controller, desain pipeline CI/CD untuk menerapkan praktik penghematan biaya, dan gunakan kuota resource Kubernetes.
Apa lagi yang harus saya pertimbangkan untuk lebih mengurangi biaya ekosistem? Tinjau cluster pengembangan kecil, tinjau strategi logging dan pemantauan Anda, serta tinjau traffic keluar antar-region di regional dan multi-zona cluster.

Fitur dan opsi pengoptimalan biaya GKE

Aplikasi Kubernetes yang hemat biaya sangat bergantung pada penskalaan otomatis GKE. Untuk menyeimbangkan biaya, keandalan, dan performa penskalaan di GKE, Anda harus memahami cara kerja penskalaan otomatis dan opsi yang Anda miliki. Bagian ini membahas penskalaan otomatis GKE dan konfigurasi hemat biaya berguna lainnya untuk penayangan dan batch workload.

Tingkatkan kualitas penskalaan otomatis GKE

Penskalaan otomatis adalah strategi yang digunakan GKE agar pelanggan Google Cloud cukup membayar sesuatu yang mereka butuhkan dengan meminimalkan waktu beroperasi infrastruktur. Dengan kata lain, penskalaan otomatis menghemat biaya dengan 1) membuat workload dan infrastruktur dasar mereka dimulai sebelum permintaan meningkat, dan 2) menonaktifkannya saat permintaan menurun.

Diagram berikut menggambarkan konsep tersebut. Di Kubernetes, workload Anda adalah aplikasi dalam container yang berjalan di dalam Pod, dan infrastruktur dasar, yang terdiri dari serangkaian Node, harus menyediakan cukup kapasitas komputasi untuk menjalankan workload.

Penskalaan otomatis menghemat biaya dengan 1) membuat workload dan infrastruktur dasarnya dimulai sebelum permintaan meningkat, dan 2) menonaktifkannya saat permintaan menurun.

Seperti yang ditampilkan diagram berikut, lingkungan ini memiliki empat dimensi skalabilitas. Workload dan infrastruktur dapat menskalakan secara horizontal dengan menambah dan menghapus Pod atau Node, serta dapat menskalakan secara vertikal dengan meningkatkan dan menurunkan ukuran Pod atau Node.

Empat dimensi skalabilitas dari lingkungan hemat biaya.

GKE menangani skenario penskalaan otomatis ini dengan menggunakan fitur seperti berikut:

Diagram berikut menggambarkan skenario tersebut.

Menggunakan skenario HPA, VPA, CA, dan penyediaan otomatis node.

Bagian selanjutnya dari bagian ini membahas kemampuan penskalaan otomatis GKE ini secara lebih mendetail dan mencakup konfigurasi hemat biaya lain yang berguna untuk penayangan dan batch workload.

Autoscaler Otomatis Pod Horizontal

Autoscaler Pod Horizontal (HPA) dimaksudkan untuk menskalakan aplikasi yang berjalan di Pod berdasarkan metrik yang menyatakan load. Anda dapat mengonfigurasi penggunaan CPU atau metrik khusus lainnya (misalnya, permintaan per detik). Singkatnya, HPA menambahkan dan menghapus replika Pod, dan hal tersebut paling cocok untuk pekerja stateless yang dapat berjalan dengan cepat untuk bereaksi terhadap lonjakan penggunaan, dan dinonaktifkan dengan baik untuk menghindari ketidakstabilan workload..

Batas penggunaan target HPA memungkinkan Anda menyesuaikan saat memicu penskalaan secara otomatis.

Seperti yang ditampilkan gambar sebelumnya, HPA memerlukan batas penggunaan target, yang dinyatakan dalam persentase, yang memungkinkan Anda menyesuaikan kapan saat memicu penskalaan secara otomatis. Dalam contoh ini, target penggunaan CPU adalah 70%. Artinya, workload Anda memiliki buffer CPU sebesar 30% untuk menangani permintaan saat replika baru sedang berjalan. Buffer kecil mencegah peningkatan skala diawal, tetapi hal tersebut dapat membebani aplikasi Anda selama lonjakan. Namun, buffer yang besar menyebabkan pemborosan resource, sehingga meningkatkan biaya Anda. Target yang tepat adalah aplikasi yang spesifik, dan Anda harus mempertimbangkan ukuran buffer yang cukup untuk menangani permintaan selama dua atau tiga menit selama lonjakan. Meskipun Anda menjamin bahwa aplikasi dapat dimulai dalam hitungan detik, waktu tambahan ini diperlukan saat Autoscaler Cluster menambahkan node baru ke cluster Anda, atau saat Pod terhambat karena kurangnya sumber daya.

Berikut adalah praktik terbaik untuk mengaktifkan HPA di aplikasi Anda:

Untuk informasi selengkapnya, lihat Mengonfigurasi Autoscaler Pod Horizontal.

Vertical Pod Autoscaler

Tidak seperti HPA, yang menambah dan menghapus replika Pod yang bereaksi dengan cepat terhadap lonjakan penggunaan, Autoscaler Pod Vertikal (VPA) mengamati Pod dari waktu ke waktu dan secara bertahap menemukan CPU dan memori yang optimal resource yang diperlukan oleh Pod. Menetapkan resource yang tepat sangat penting untuk stabilitas dan efisiensi biaya. Jika resource Pod Anda terlalu kecil, aplikasi dapat dihambat atau gagal karena error kehabisan memori. Jika resource Anda terlalu besar, maka Anda akan mengalami pemborosan, dan oleh karena itu, tagihannya akan lebih besar. VPA dimaksudkan untuk workload stateless dan stateful yang tidak ditangani oleh HPA atau jika Anda tidak mengetahui permintaan resource Pod yang tepat.

VPA mendeteksi bahwa Pod secara konsisten berjalan pada batasnya dan membuat ulang Pod dengan resource yang lebih besar.

Seperti yang ditampilkan gambar sebelumnya, VPA mendeteksi bahwa Pod secara konsisten berjalan pada batasnya dan membuat ulang Pod dengan resource yang lebih besar. Hal sebaliknya juga terjadi saat Pod secara konsisten kurang dimanfaatkan—memicu penurunan skala.

VPA dapat bekerja pada tiga mode berbeda:

  • Off. Mode ini, juga dikenal sebagai mode rekomendasi, VPA tidak menerapkan perubahan apa pun pada Pod Anda. Rekomendasi tersebut dihitung dan dapat diperiksa di objek VPA.
  • Initial: VPA menetapkan permintaan resource hanya saat pembuatan Pod dan tidak pernah mengubahnya nanti.
  • Auto: VPA memperbarui CPU dan permintaan memori selama kehidupan dari Pod. Artinya, Pod dihapus, CPU dan memori disesuaikan, lalu Pod baru dimulai.

Jika Anda berencana menggunakan VPA, praktik terbaiknya adalah memulai dengan mode Off untuk menarik rekomendasi VPA. Pastikan fitur tersebut berjalan selama 24 jam, idealnya selama satu minggu atau lebih, sebelum menarik rekomendasi. Kemudian, hanya jika Anda merasa percaya diri, pertimbangkan untuk beralih ke mode Initial atau Auto.

Ikuti praktik terbaik berikut untuk mengaktifkan VPA, baik dalam mode Initial maupun Auto, di aplikasi Anda:

Baik Anda mempertimbangkan menggunakan mode Otomatis, pastikan Anda juga mengikuti praktik berikut:

  • Pastikan aplikasi Anda dapat dimulai ulang saat sedang menerima traffic.
  • Tambahkan Anggaran Gangguan Pod (PDB) untuk mengontrol jumlah Pod yang dapat dihapus secara bersamaan.

Untuk informasi selengkapnya, lihat Mengonfigurasi Penskalaan Otomatis Pod Vertikal.

Mencampur HPA dan VPA

Rekomendasi resminya adalah Anda tidak boleh mencampur VPA dan HPA pada CPU atau memori. Namun, Anda dapat mencampurnya dengan aman saat menggunakan mode rekomendasi di VPA atau metrik khusus di HPA—misalnya, permintaan per detik. Saat menggabungkan VPA dengan HPA, pastikan deployment Anda menerima cukup traffic. Artinya, deployment secara konsisten berjalan di atas min-replika HPA. Hal ini memungkinkan VPA memahami kebutuhan resource Pod Anda.

Untuk informasi selengkapnya tentang batasan VPA, lihat Batasan untuk Penskalaan Otomatis Pod Vertikal.

Autoscaler Cluster

Cluster Autoscaler (CA) akan secara otomatis mengubah ulang ukuran infrastruktur komputer yang mendasarinya. CA menyediakan node untuk Pod yang tidak memiliki tempat untuk dijalankan dalam cluster serta menghapus node yang kurang digunakan. CA dioptimalkan untuk biaya infrastruktur. Dengan kata lain, jika ada dua atau lebih jenis node pada cluster, CA memilih yang paling murah dan sesuai dengan permintaan tertentu.

Tidak seperti HPA dan VPA, CA tidak bergantung pada beban metrik. Sebaliknya, CA didasarkan pada simulasi penjadwalan dan permintaan Pod yang dideklarasikan. Praktik terbaiknya adalah mengaktifkan CA setiap kali Anda menggunakan HPA atau VPA. Praktik ini memastikan bahwa jika autoscaler Pod Anda menentukan bahwa memerlukan kapasitas lebih, infrastruktur dasar Anda akan bertambah sesuai kebutuhan.

CA secara otomatis menambahkan dan menghapus kapasitas komputasi untuk menangani lonjakan traffic.

Seperti yang ditampilkan pada diagram berikut, CA secara otomatis menambahkan dan menghapus kapasitas komputasi untuk menangani lonjakan traffic dan menghemat uang Anda saat pelanggan sedang tidur. Salah satu praktik terbaik adalah menentukan anggaran gangguan podAnggaran Gangguan Pod (PDB) untuk semua aplikasi Anda. Hal ini sangat penting pada tahap penurunan skala CA saat PDB mengontrol jumlah replika yang dapat dihapus dalam satu waktu.

Pod tertentu tidak dapat dimulai ulang oleh autoscaler mana pun jika menyebabkan gangguan sementara, sehingga tempat node pod berjalan tidak dapat dihapus. Misalnya, sistem Pod (seperti metrics-server dan kube-dns), serta Pod yang menggunakan penyimpanan lokal tidak akan dimulai ulang. Namun, Anda dapat mengubah perilaku ini dengan menentukan PDB untuk sistem Pod ini dan dengan menyetel "cluster-autoscaler.kubernetes.io/safe-to-evict": "true" anotasi untuk Pod yang menggunakan penyimpanan lokal yang aman untuk autoscaler agar dapat dimulai ulang. Selain itu, pertimbangkan untuk menjalankan Pod jangka panjang yang tidak dapat dimulai ulang pada node pool terpisah, sehingga tidak memblokir penurunan skala node lain. Terakhir pelajari cara menganalisis peristiwa CA di log untuk memahami mengapa aktivitas penskalaan tertentu tidak terjadi seperti yang diharapkan

Jika workload Anda tahan oleh node yang dimulai ulang secara tidak sengaja dan kerugian kapasitas, Anda dapat menghemat lebih banyak biaya dengan membuat cluster atau node pool dengan preemptible VM. Agar CA dapat bekerja seperti yang diharapkan, Permintaan resource pod harus cukup besar agar Pod berfungsi secara normal. Jika permintaan resource terlalu kecil, node mungkin tidak memiliki cukup resource dan Pod Anda mungkin akan error atau mengalami masalah selama runtime.

Berikut adalah ringkasan praktik terbaik untuk mengaktifkan Cluster Autoscaler pada cluster Anda:

  • Gunakan HPA atau VPA untuk menskalakan workload Anda secara otomatis.
  • Pastikan Anda mengikuti praktik terbaik yang dijelaskan dalam autoscaler Pod terpilih.
  • Sesuaikan ukuran aplikasi Anda dengan benar dengan menetapkan permintaan dan batas resource yang sesuai atau menggunakan VPA.
  • Tentukan PDB untuk aplikasi Anda.
  • Tentukan PDB untuk sistem Pod yang mungkin memblokir penurunan skala Anda. Contoh, kube-dns Untuk menghindari gangguan sementara dalam cluster Anda, jangan menetapkan PDB untuk sistem Pod yang hanya memiliki 1 replika (seperti metrics-server).
  • Jalankan Pod jangka pendek dan Pod yang dapat dimulai ulang dalam node pool terpisah, sehingga Pod yang berjangka panjang tidak memblokir penurunan skalanya.
  • Hindari penyediaan yang berlebihan dengan mengonfigurasi node yang nonaktif di cluster Anda. Untuk itu, Anda harus mengetahui kapasitas minimum—bagi banyak perusahaan penggunaannya di malam hari—dan menetapkan jumlah minimum node dalam node pool Anda untuk mendukung kapasitas tersebut.
  • Jika Anda memerlukan kapasitas tambahan untuk menangani permintaan selama lonjakan, gunakan jeda Pod, yang dibahas di Autoscaler dan penyediaan berlebihan.

Untuk informasi selengkapnya, lihat Penskalaan otomatis cluster.

Penyediaan otomatis node

Penyediaan otomatis node (NAP) adalah mekanisme dari Autoscaler Cluster yang secara otomatis menambahkan node pool baru selain mengelola ukurannya di atas nama pengguna. Tanpa penyediaan otomatis node, GKE mempertimbangkan memulai node baru hanya dari sekumpulan node pool yang dibuat pengguna. Dengan penyediaan otomatis node, GKE dapat membuat dan menghapus node pool baru secara otomatis.

Penyediaan otomatis node cenderung mengurangi pemborosan resource dengan secara dinamis membuat node pool yang paling sesuai dengan workload terjadwal. Namun, latensi penskalaan otomatis bisa sedikit lebih tinggi saat node pool baru perlu dibuat. Jika workload tahan terhadap node yang memulai ulang secara tidak sengaja dan kehilangan kapasitas, Anda dapat menurunkan biaya lebih lanjut dengan mengonfigurasi toleransi preemptible VM pada Pod Anda.

Berikut adalah praktik terbaik untuk mengaktifkan penyediaan otomatis node:

  • Ikuti semua praktik terbaik dari Autoscaler Cluster.
  • Setel ukuran minimum dan maksimum resource dan agar terhindar dari NAP yang tidak membuat perubahan signifikan pada cluster Anda saat aplikasi tidak menerima traffic.
  • Saat menggunakan Horizontal Pod Autoscaler untuk menyalurkan workload, pertimbangkan untuk mereservasi sedikit lebih besar target buffer pemanfaatan karena NAP dapat meningkatkan latensi penskalaan otomatis dalam beberapa kasus.

Untuk informasi selengkapnya, lihat Menggunakan penyediaan otomatis node dan Fitur yang tidak didukung.

Autoscaler dan penyediaan yang berlebihan

Untuk mengontrol biaya Anda, kami merekomendasikan Anda mengaktifkan autoscaler sesuai dengan bagian sebelumnya. Tidak ada konfigurasi yang cocok untuk semua kemungkinan skenario, sehingga Anda harus meningkatkan setelan untuk workload Anda guna memastikan bahwa autoscaler merespon dengan benar untuk meningkatkan traffic.

Namun, seperti yang disebutkan di bagian Horizontal Pod Autoscaler , peningkatan skala mungkin memerlukan waktu karena penyediaan infrastruktur. Untuk memvisualisasi perbedaan waktu dan kemungkinan skenario peningkatan skala, pertimbangkan gambar berikut.

Visualisasikan perbedaan waktu dan kemungkinan skenario peningkatan skala.

Jika cluster Anda memiliki cukup ruang untuk men-deploy Pod baru, salah satu skenario peningkatan skala workload akan dipicu. Artinya, jika node yang ada tidak pernah men-deploy aplikasi Anda,maka node tersebut harus mendownload image container-nya sebelum memulai Pod (skenario 1). Namun, jika node yang sama harus memulai replika Pod baru dari aplikasi Anda, total waktu peningkatan skala akan berkurang karena mendownload gambar tidak diperlukan (skenario 2).

Ketika cluster tidak memiliki cukup ruang untuk men-deploy Pod baru, salah satu Skenario peningkatan skala workload dan infrastruktur akan dipicu. Artinya, Autoscaler Cluster harus menyediakan node baru dan memulai software yang diperlukan sebelum mendekati aplikasi Anda (skenario 1). Jika Anda menggunakan penyediaan otomatis node, bergantung pada workload yang dijadwal, node pool baru mungkin diperlukan. Dalam situasi ini, total waktu peningkatan skala akan meningkat karena Cluster Autoscaler harus menyediakan node dan node pool (skenario 2).

Untuk skenario yang memerlukan infrastruktur baru, jangan terlalu menekan cluster Anda—Artinya, Anda harus memberi penyediaan yang banyak, tetapi hanya untuk mereservasi buffer yang diperlukan guna menangani permintaan puncak yang diharapkan selama peningkatan skala.

Ada dua strategi utama jenis penyediaan yang berlebihan ini:

  • Tingkatkan kualitas target penggunaan HPA. Persamaan berikut adalah cara sederhana dan aman untuk menemukan target CPU yang bagus:

    (1 - buff)/(1 + perc)

    • buff adalah buffer keamanan yang dapat Anda setel agar tidak mencapai CPU 100%. Variabel ini berguna karena mencapai CPU 100% berarti latensi pemrosesan permintaan jauh lebih tinggi dari biasanya.
    • perc adalah persentase dari pertumbuhan traffic yang Anda harapkan dalam dua atau tiga menit.

    Misalnya, jika Anda mengharapkan pertumbuhan pada permintaan Anda sebesar 30% dan ingin menghindari jangkauan CPU 100% dengan menentukan buffer keamanan 10%, formula Anda akan terlihat seperti ini:

    (1 - 0.1)/(1 + 0.3) = 0.69

  • Konfigurasi jeda Pod. Tidak ada cara untuk mengonfigurasi Autoscaler Cluster untuk menjalankan node di awal. Sebagai gantinya, Anda dapat menetapkan target penggunaan HPA untuk menyediakan buffer guna membantu menangani lonjakan beban. Namun, jika Anda memperkirakan burst yang besar, menetapkan target penggunaan HPA yang kecil mungkin tidak cukup atau mungkin akan menjadi terlalu mahal.

    Solusi alternatif untuk masalah ini adalah dengan menggunakan jeda Pod. Jeda Pod adalah deployment berprioritas rendah yang tidak melakukan apa pun selain mencadangkan ruang di cluster Anda. Setiap kali Pod berprioritas tinggi dijadwalkan, jeda Pod akan dikeluarkan dan Pod prioritas tinggi segera menggantikan tempatnya. Jeda Pod yang dikeluarkan akan dijadwalkan ulang, dan jika tidak ada ruang di cluster, Autoscaler Cluster akan menjalankan node baru untuk menyesuaikannya. Praktik terbaiknya adalah hanya jika memiliki satu jeda Pod per node. Misalnya, jika Anda menggunakan 4 node CPU, konfigurasi permintaan jeda Pod CPU sekitar 3.200m.

Pilih jenis mesin yang tepat

Selain penskalaan otomatis, konfigurasi lainnya dapat membantu Anda menjalankan aplikasi Kubernetes yang hemat biaya di GKE. Bagian ini membahas cara memilih jenis mesin yang tepat.

Preemptible VM

Preemptible VMs (PVMs) adalah Compute Engine VM contoh yang berlangsung maksimal 24 jam dan tidak memberikan jaminan ketersediaan. PVM lebih murah hingga 80% daripada VM Compute Engine standar, tetapi sebaiknya Anda menggunakannya dengan hati-hati pada cluster GKE. PVM di GKE paling cocok untuk menjalankan tugas batch atau fault-tolerant yang kurang sensitif terhadap sifat PVM sementara dan tanpa jaminan. Stateful dan penayangan workload tidak boleh menggunakan PVM kecuali jika Anda menyiapkan sistem dan arsitektur Anda untuk menangani batasan PVM.

Apa pun jenis workload, Anda harus memperhatikan batasan berikut:

  • Anggaran Gangguan Pod mungkin tidak diterapkan karena node kemungkinkan dihentikan dapat dinonaktifkan secara tidak sengaja.
  • Tidak ada jaminan bahwa Pod Anda akan nonaktifkan dengan tuntas setelah nood preemption mengabaikan masa tenggang Pod.
  • GKE perlu waktu beberapa menit untuk mendeteksi bahwa node tersebut di-preempt dan Pod tidak lagi berjalan, sehingga menunda penjadwalan ulang Pod ke node baru.

Untuk memitigasi batasan ini, Anda dapat men-deploy projek pada komunitas cluster Pengendali Peristiwa Penghentian Node Anda(penting: ini bukan projek Google resmi) yang menyediakan adaptor untuk menerjemahkan peristiwa penghentian node Compute Engine ke penghentian Pod dengan tuntas di Kubernetes. Projek komunitas ini tidak menyelesaikan dengan andal semua batasan PVM setelah Anggaran Gangguan Pod masih diabaikan. Oleh karena itu, pod dapat memerlukan waktu sedikit lebih lama untuk dijadwalkan kemabali.

Terakhir, PVM tidak memiliki jaminan ketersediaan, artinya PVM dapat kehabisan stok dengan mudah di beberapa region. Untuk mengatasi batasan ini, sebaiknya Anda menetapkan node pool cadangan tanpa PVM. Cluster Autoscaler memberikan preferensi pada PVM karena hal tersebut dioptimalkan untuk biaya infrastruktur.

Untuk informasi selengkapnya, lihat Menjalankan preemptible VM di GKE dan Jalankan aplikasi web di GKE menggunakan Spot VM hemat biaya.

Jenis mesin E2

Jenis mesin E2 (VM E2) adalah mesin hemat biaya yang menawarkan penghematan 31% dibandingkan dengan jenis mesin N1. VM E2 cocok untuk berbagai macam workload, termasuk server web, microservice, aplikasi yang penting untuk bisnis, database berukuran kecil hingga menengah, dan lingkungan pengembangan.

Untuk informasi selengkapnya tentang VM E2 dan perbandingannya dengan jenis mesin Google Cloud lainnya, lihat Pengelolaan resource dinamis berbasis performa di VM E2 dan Jenis mesin.

Pilih region yang sesuai

Ketika biaya menjadi batasan, tempat Anda menjalankan cluster GKE sangat penting. Karena banyak faktor, biaya bervariasi di setiap region komputasi. Jadi, pastikan Anda menjalankan workload dengan opsi yang paling murah, tetapi latensi tidak memengaruhi pelanggan Anda. Jika workload Anda memerlukan penyalinan data dari satu region ke region lain—misalnya, untuk menjalankan tugas batch—Anda juga harus mempertimbangkan biaya untuk memindahkan data ini.

Untuk mengetahui informasi selengkapnya tentang cara memilih region yang tepat, lihat Praktik terbaik untuk pemilihan region Compute Engine.

Daftar untuk diskon abonemen

Jika Anda ingin tetap menggunakan Google Cloud selama beberapa tahun, sebaiknya beli diskon abonemen sebagai gantinya atas harga diskon yang sangat besar untuk penggunaan VM. Saat menandatangani kontrak abonemen, Anda membeli resource komputasi dengan harga diskon (diskon hingga 70%) sebagai gantinya atas komitmen Anda untuk membayar resource tersebut selama satu tahun atau tiga tahun. Jika Anda tidak yakin dengan jumlah resource yang harus digunakan, lihat penggunaan komputasi minimum Anda—misalnya, pada malam hari—dan lakukan pembayaran untuk jumlah tersebut.

Untuk informasi selengkapnya tentang harga abonemen untuk jenis mesin yang berbeda, lihat Harga instance VM.

Tinjau cluster pengembangan kecil

Untuk cluster pengembangan kecil yang perlu meminimalkan biaya, pertimbangkan untuk menggunakan Autopilot cluster. Dengan cluster dalam mode operasi ini, Anda tidak akan dikenai biaya untuk Pod sistem, biaya sistem operasi, atau workload yang tidak terjadwal.

Tinjau strategi logging dan pemantauan Anda

Jika menggunakan Cloud Logging dan Cloud Monitoring untuk menyediakan kemampuan observasi ke aplikasi dan infrastruktur Anda, Anda hanya perlu membayar sesuai yang Anda gunakan. Namun, semakin banyak infrastruktur dan aplikasi Anda yang dicatat, dan semakin lama Anda menyimpan log tersebut, semakin banyak yang Anda bayar. Demikian pula, semakin banyak metrik eksternal dan khusus yang Anda miliki, semakin tinggi biaya Anda. Tinjau strategi logging dan pemantauan Anda sesuai dengan Pengoptimalan biaya untuk Cloud Logging, Cloud Monitoring, dan Pengelolaan Performa Aplikasi.

Tinjau lalu lintas keluar antar-region di cluster regional dan multi-zona

Jenis cluster GKE yang tersedia adalah zona tunggal, multi-zona, dan regional. Karena ketersediaan node yang tinggi di seluruh zona, regional dan multi-zona cluster sangat cocok untuk lingkungan produksi. Namun Anda akan dikenai biaya oleh traffic keluar antar-zona. Untuk lingkungan produksi, sebaiknya pantau beban traffic di seluruh zona dan tingkatkan API Anda untuk meminimalkannya. Pertimbangkan juga untuk menggunakan konfigurasi afinitas dan anti-afinitas antar-pod untuk mengalokasi Pod dependen dari berbagai layanan dalam node yang sama atau di zona ketersediaan yang sama untuk meminimalkan biaya dan jaringan latensi di antara mereka. Cara yang disarankan untuk memantau traffic ini adalah dengan mengaktifkan pengukuran penggunaan GKE dan agen jaringan keluar traffic, yang dinonaktifkan secara default.

Untuk lingkungan non-produksi, praktik terbaik untuk menghemat biaya adalah men-deploy cluster zona tunggal.

Siapkan lingkungan Anda agar sesuai dengan jenis workload Anda

Perusahaan memiliki persyaratan biaya dan ketersediaan yang berbeda. Workload mereka dapat dibagi menjadi workload penayangan, yang harus cepat merespon burst atau lonjakan, dan workload batch, yang berkaitan dengan pekerjaan tertunda yang harus diselesaikan. Penayangan workload memerlukan latensi peningkatan skala yang kecil; workload batch lebih toleran terhadap latensi. Perbedaan ekspektasi untuk jenis workload ini membuat pemilihan metode hemat biaya yang berbeda menjadi lebih fleksibel.

Batch workload

Karena workload batch berkaitan dengan pekerjaan yang tertunda, workload tersebut memungkinkan penghematan biaya di GKE karena workload biasanya toleran terhadap beberapa latensi pada waktu startup tugas. Toleransi ini memberi ruang Autoscaler Cluster untuk menjalankan node baru hanya jika tugas telah dijadwalkan dan menghapusnya saat tugas selesai.

Praktik pertama yang direkomendasikan adalah memisahkan workload batch dalam berbagai node pool dengan menggunakan label dan pemilih, dan dengan menggunakan taint dan toleransi. Alasannya adalah sebagai berikut:

  • Autoscaler Cluster dapat menghapus node kosong lebih cepat jika tidak perlu memulai ulang pod. Saat tugas batch selesai, cluster akan mempercepat proses penurunan skala jika workload berjalan di node khusus yang saat ini kosong. Untuk lebih meningkatkan kecepatan dari penurunan skala, pertimbangkan untuk mengonfigurasi profil pengoptimalan penggunaan CA.
  • Beberapa Pod tidak dapat dimulai ulang, sehingga mereka memblokir penurunan skala node-nya secara permanen. Pod ini, yang mencakup sistem Pod, harus berjalan di node pool yang berbeda agar tidak memengaruhi penurunan skala.

Praktik kedua yang direkomendasikan adalah menggunakan penyediaan otomatis node untuk membuat node pool khusus secara otomatis untuk tugas dengan taint atau toleransi yang cocok. Dengan cara ini, Anda dapat memisahkan banyak workload yang berbeda tanpa harus menyiapkan semua node pool yang berbeda tersebut.

Sebaiknya gunakan preemptible VM hanya jika Anda menjalankan tugas fault-tolerant yang tidak terlalu sensitif terhadap preemptible VM yang bersifat sementara dan tanpa jaminan.

Untuk informasi selengkapnya tentang cara menyiapkan lingkungan yang mengikuti praktik ini, lihat tutorial Mengoptimalkan penggunaan resource di cluster GKE multi-tenant menggunakan penyediaan otomatis node

Tayangkan workload

Tidak seperti workload batch, penayangan workload harus merespon burst atau lonjakan secepat mungkin. Peningkatan traffic yang tiba-tiba ini dapat disebabkan oleh banyak faktor, misalnya, komersial TV, acara berskala puncak seperti Black Friday, atau berita terbaru. Aplikasi Anda harus siap untuk menanganinya.

Masalah dalam menangani lonjakan tersebut biasanya terkait dengan satu atau beberapa alasan berikut:

  • Aplikasi yang belum siap berjalan di Kubernetes—misalnya, aplikasi dengan ukuran gambar yang besar, waktu startup yang lambat, atau konfigurasi Kubernetes yang tidak optimal.
  • Aplikasi bergantung pada infrastruktur yang membutuhkan waktu untuk disediakan, seperti GPU.
  • Autoscaler dan penyediaan yang berlebih tidak ditetapkan dengan tepat.

Persiapkan aplikasi Kubernetes berbasis cloud

Beberapa dari praktik terbaik di bagian ini dapat menghemat uang dengan sendirinya. Namun, karena sebagian besar praktik ini dimaksudkan untuk membuat aplikasi Anda bekerja secara andal dengan autoscaler, sebaiknya Anda menerapkannya.

Pahami kapasitas aplikasi

Saat Anda merencanakan kapasitas aplikasi, ketahui jumlah permintaan serentak yang dapat ditangani aplikasi Anda, jumlah CPU dan memori yang diperlukan, serta responnya menangani beban berat. Sebagian besar tim tidak mengetahui kapasitas ini, jadi sebaiknya uji perilaku aplikasi Anda saat di bawah tekanan. Coba isolasi aplikasi tunggal replika Pod dengan penskalaan otomatis nonaktif, lalu jalankan simulasi pengujian beban penggunaan nyata. Hal ini membantu Anda memahami kapasitas per Pod Anda. Selanjutnya, sebaiknya konfigurasi Autoscaler Cluster Anda, permintaan dan batas resource, serta HPA atau VPA. Kemudian, tekan kembali aplikasi Anda, tetapi dengan kekuatan lebih untuk menyimulasikan burst atau lonjakan yang tiba-tiba.

Idealnya, untuk menghilangkan masalah latensi, pengujian ini harus berjalan dari region atau zona yang sama dengan aplikasi yang dijalan di Google Cloud. Anda dapat menggunakan alat pilihan Anda untuk pengujian ini, baik berupa skrip buatan sendiri maupun alat performa tingkat lanjut, seperti Apache Benchmark, JMeter, atau Locust.

Untuk contoh cara melakukan pengujian Anda, lihat Pengujian beban terdistribusi menggunakan Google Kubernetes Engine.

Pastikan aplikasi Anda dapat tumbuh secara vertikal dan horizontal

Pastikan aplikasi Anda dapat bertumbuh dan menyusut. Artinya, Anda dapat memilih untuk menangani peningkatan traffic, baik dengan menambahkan lebih banyak CPU dan memori atau menambahkan lebih banyak replika Pod. Hal ini memberi Anda fleksibilitas untuk bereksperimen apa yang lebih cocok dengan aplikasi Anda, baik penyiapan autoscaler yang berbeda maupun ukuran node yang berbeda. Sayangnya, beberapa aplikasi memiliki thread tunggal atau dibatasi oleh sejumlah pekerja atau subproses tetap, sehingga eksperimen ini tidak mungkin dilakukan tanpa pemfaktoran ulang arsitektur yang lengkap.

Set batas dan permintaan resource yang tepat.

Dengan memahami kapasitas aplikasi Anda , Anda dapat menentukan apa yang harus dikonfigurasi pada resource container. Resource di Kubernetes mayoritas ditentukan sebagai CPU dan memori (RAM). Anda mengonfigurasi CPU atau memori sesuai dengan jumlah yang diperlukan untuk menjalankan aplikasi menggunakan permintaan spec.containers[].resources.requests.<cpu|memory>, dan Anda mengonfigurasi batas menggunakan permintaan spec.containers[].resources.limits.<cpu|memory>.

Setelah Anda telah menetapkan permintaan resource dengan benar, penjadwal Kubernetes dapat menggunakannya untuk menentukan node mana yang akan digunakan untuk menempatkan Pod. Hal ini menjamin Pod ditempatkan di node yang dapat membuatnya berfungsi secara normal, sehingga Anda akan mendapatkan stabilitas yang lebih baik dan mengurangi pemborosan resource. Selain itu, menentukan batas resource juga membantu memastikan bahwa aplikasi ini tidak pernah menggunakan semua infrastruktur dasar yang disediakan oleh node komputasi.

Praktik yang baik untuk menetapkan resource container Anda adalah menggunakan jumlah memori yang sama untuk permintaan dan batas, serta batas CPU yang lebih besar atau tidak terbatas. Ambil deployment berikut sebagai contoh:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: wordpress
spec:
  replicas: 1
  selector:
    matchLabels:
      app: wp
  template:
    metadata:
      labels:
        app: wp
    spec:
      containers:
  - name: wp
    image: wordpress
    resources:
      requests:
        memory: "128Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"

Alasan pola sebelumnya didasarkan pada cara kerja penanganan out-of-resource Kubernetes. Singkatnya, saat resource komputer habis, node menjadi tidak stabil. Untuk menghindari situasi ini, kubelet pantau dan cegah kekurangan total resource ini dengan memberi peringkat Pod yang membutuhkan resource Saat CPU memproses banyak pekerjaan berat, Pod ini dapat di-throttle agar sesuai dengan permintaannya. Namun, karena memori merupakan resource yang tidak dapat dikompresi, saat memori habis, maka Pod harus dihapus. Agar Pod tidak dihapus—lalu akibatnya, destabilisasi lingkungan—Anda harus menetapkan memori yang diminta ke batas memori.

Anda juga dapat menggunakan VPA dalam mode rekomendasi untuk membantu menentukan penggunaan CPU dan penggunaan memori untuk aplikasi tertentu. Karena VPA memberikan rekomendasi tersebut berdasarkan penggunaan aplikasi Anda, sebaiknya aktifkan VPA dalam lingkungan seperti produksi untuk menghadapi traffic yang nyata. Status VPA kemudian menghasilkan laporan berisi permintaan dan batas resource yang disarankan, yang dapat Anda tentukan secara statis di manifes deployment. Jika aplikasi Anda sudah menentukan HPA, lihat Menggabungkan HPA dan VPA.

Pastikan container Anda seefisien mungkin

Saat Anda menjalankan aplikasi dalam container, penting untuk mengikuti beberapa praktik untuk membangun container tersebut. Saat menjalankan container tersebut di Kubernetes, beberapa praktik ini bahkan lebih penting karena aplikasi Anda dapat mulai dan berhenti kapan saja. Fokus utama bagian ini pada dua praktik berikut:

  • Siapkan gambar sekecil mungkin. Memiliki gambar kecil merupakan praktik terbaik karena setiap kali Autoscaler Cluster menyediakan node baru untuk cluster Anda, node harus mendownload gambar yang akan berjalan di node tersebut. Semakin kecil gambar, semakin cepat node dapat mendownloadnya.

  • Mulai aplikasi secepat mungkin. Beberapa aplikasi dapat memakan waktu beberapa menit untuk memulai karena pemuatan class, penyimpanan dalam cache, dan sebagainya. Saat Pod memerlukan waktu startup yang lama, permintaan pelanggan Anda mungkin akan gagal saat aplikasi sedang booting.

Pertimbangkan kedua praktik ini saat mendesain sistem Anda, terutama jika Anda mengharapkan burst atau lonjakan. Memiliki image kecil dan startup cepat yang membantu Anda mengurangi latensi peningkatan skala. Dengan demikian, Anda dapat menangani peningkatan traffic lebih baik tanpa terlalu mengkhawatirkan ketidakstabilan. Praktik ini bekerja lebih baik dengan praktik terbaik penskalaan otomatis yang dibahas dalam Penskalaan otomatis GKE.

Untuk mengetahui informasi selengkapnya tentang cara membangun container, lihat Praktik terbaik untuk membangun container.

Menambahkan Anggaran Gangguan Pod ke aplikasi Anda

Anggaran Gangguan Pod (PDB) membatasi jumlah Pod yang dapat dihapus secara bersamaan dari gangguan sukarela. Artinya, anggaran gangguan yang ditetapkan dipatuhi saat peluncuran, upgrade node, dan pada aktivitas penskalaan otomatis apa pun. Namun, anggaran ini tidak dapat dijamin jika terjadi hal yang tidak disengaja, seperti kegagalan hardware, kernel panik, atau seseorang yang tanpa sengaja menghapus VM.

Jika PDB dipatuhi selama fase pemadatan Autoscaler Cluster, praktik terbaiknya adalah menentukan Anggaran Gangguan Pod untuk setiap aplikasi. Dengan cara ini, Anda dapat mengontrol jumlah minimum replika yang diperlukan untuk mendukung beban Anda pada waktu tertentu, termasuk saat CA sedang memperkecil skala cluster Anda.

Untuk informasi selengkapnya, lihat Menentukan Anggaran Gangguan untuk Aplikasi Anda.

Menetapkan pemeriksaan kesiapan dan keaktifan yang bermakna untuk aplikasi Anda

Menyetel pemeriksaan yang bermakna memastikan aplikasi Anda menerima traffic hanya jika aplikasi sedang aktif dan berjalan, serta siap menerima traffic. GKE menggunakan pemeriksaan kesiapan untuk menentukan waktu harus menambahkan Pod atau menghapus Pod dari load balancer. GKE menggunakan pemeriksaan keaktifan untuk menentukan waktu untuk mulai ulang Pod Anda..

Pemeriksaan keaktifan berguna untuk memberi tahu Kubernetes bahwa Pod tertentu tidak dapat membuat progres, misalnya, saat status deadlock terdeteksi. Pemeriksaan kesiapan berguna untuk memberi tahu Kubernetes bahwa aplikasi Anda belum siap menerima traffic, misalnya, saat memuat data cache berukuran besar saat startup.

Untuk memastikan siklus proses aplikasi Anda yang benar selama aktivitas peningkatan skala, penting untuk melakukan hal berikut:

  • Tentukan pemeriksaan kesiapan untuk semua container Anda.
  • Jika aplikasi Anda bergantung pada cache untuk dimuat saat startup, pemeriksaan kesiapan harus menyatakan bahwa aplikasi hanya siap setelah cache dimuat sepenuhnya.
  • Jika aplikasi Anda dapat langsung mulai menayangkan iklan, implementasi pemeriksaan default yang baik dapat dilakukan sesederhana mungkin, misalnya, endpoint HTTP yang menampilkan kode status 200.
  • Jika Anda menerapkan pemeriksaan yang lebih lanjut, seperti memeriksa apakah kumpulan koneksi memiliki resource yang tersedia, pastikan tingkat error Anda tidak meningkat dibandingkan dengan implementasi yang lebih sederhana.
  • Jangan pernah membuat logika pemeriksaan mengakses layanan lainnya Layanan ini dapat membahayakan siklus proses Pod Anda jika layanan ini tidak merespon dengan segera.

Untuk informasi selengkapnya, lihat Konfigurasi Pemeriksaan Keaktifan, Kesiapan, dan Startup.

Pastikan aplikasi Anda dimatikan sesuai dengan ekspektasi Kubernetes

Autoscaler membantu Anda merespon lonjakan dengan menjalankan Pod dan node baru, dan dengan menghapusnya saat lonjakan telah selesai. Artinya, untuk menghindari error saat menayangkan Pod harus siap untuk startup cepat atau penghentian tuntas.

Karena Kubernetes secara asinkron memperbarui endpoint dan memuat balancer, penting untuk mengikuti praktik terbaik berikut untuk memastikan penghentian tanpa gangguan:

  • Jangan berhenti menerima permintaan baru setelah SIGTERM. Aplikasi Anda tidak boleh langsung berhenti, tetapi menyelesaikan semua permintaan yang sedang beroperasi dan tetap memproses koneksi yang masuk setelah penghentian Pod dimulai. Mungkin perlu waktu agak lama bagi Kubernetes untuk memperbarui semua kube-proxies dan load balancer. Jika aplikasi Anda berhenti sebelum diupdate, beberapa permintaan mungkin dapat menyebabkan error di sisi klien.
  • Jika aplikasi Anda tidak mengikuti praktik sebelumnya, gunakan preStop hook. Sebagian besar program tidak secara langsung berhenti menerima permintaan. Namun, jika Anda menggunakan kode pihak ketiga atau mengelola sistem yang tidak dapat Anda kontrol, seperti nginx, preStop hook adalah opsi bagus untuk memicu penghentian tuntas tanpa mengubah aplikasi. Salah satu strategi umum adalah mengeksekusi di hook preStop, mode tidur selama beberapa detik untuk menunda SIGTERM. Hal ini memberi Kubernetes tambahan waktu untuk menyelesaikan proses penghapusan Pod, dan mengurangi koneksi error di sisi klien.
  • Menangani SIGTERM untuk pembersihan. Jika aplikasi Anda harus membersihkan atau memiliki status dalam memori yang harus ditetapkan sebelum proses berhenti, sekarang adalah waktunya untuk melakukannya. Bahasa pemrograman yang berbeda memiliki cara yang berbeda untuk menangkap sinyal ini, jadi temukan cara tepat dalam bahasa Anda.
  • Konfigurasi terminationGracePeriodSeconds agar sesuai dengan kebutuhan aplikasi Anda. Beberapa aplikasi membutuhkan default lebih dari 30 detik untuk menyelesaikannya. Dalam hal ini, Anda harus tentukan terminationGracePeriodSeconds. Nilai yang tinggi memungkinkan mempercepat waktu untuk memperbarui atau peluncuran node, misalnya. Nilai yang rendah mungkin tidak memberikan cukup waktu bagi Kubernetes untuk menyelesaikan proses penghentian Pod. Apa pun pilihan Anda, sebaiknya setel periode penghentian aplikasi kurang dari 10 menit karena Autoscaler Cluster hanya memenuhinya selama 10 menit.
  • Jika aplikasi Anda menggunakan load balancing berbasis container, mulailah dengan menggagalkan pemeriksaan kesiapan saat Anda menerima SIGTERM. Tindakan ini langsung memberi sinyal kepada load balancer untuk berhenti meneruskan permintaan baru ke Pod backend. Bergantung pada race antara konfigurasi health check dan pemrograman endpoint, Pod backend mungkin akan dikeluarkan dari traffic sebelumnya.

Untuk informasi selengkapnya, lihat Praktik terbaik Kubernetes: berhenti berlangganan dengan masa tenggang.

Siapkan NodeLocal DNSCache

DNS yang dikelola GKE diterapkan oleh kube-dns, add-on yang di-deploy di semua cluster GKE. Saat Anda menjalankan aplikasi yang membutuhkan DNS, konfigurasi kube-dns-autoscaler default, yang menyesuaikan jumlah replika kube-dns berdasarkan jumlah node dan core dalam cluster, mungkin tidak dalam jumlah yang cukup. Dalam skenario ini, kueri DNS dapat melambat atau waktu habis. Untuk memitigasi masalah ini, perusahaan terbiasa menyesuaikan kube-dns-autoscaler ConfigMap untuk meningkatkan jumlah replika kube-dns di cluster mereka. Meskipun strategi ini mungkin bekerja seperti yang diharapkan, strategi ini meningkatkan penggunaan resource dan total biaya GKE.

Alternatif lain yang hemat biaya dan lebih skalabel adalah untuk konfigurasi NodeLocal DNSCache di cluster Anda. NodeLocal DNSCache adalah add-on GKE opsional yang meningkatkan latensi DNS lookup, membuat waktu DNS lookup lebih konsisten, dan mengurangi jumlah DNS queries menjadi kube-dns dengan menjalankan cache DNS di setiap node cluster

Untuk informasi lebih lanjut, lihat Siapkan NodeLocal DNSCache.

Menggunakan load balancing berbasis container melalui Ingress

Load balancing berbasis container memungkinkan load balancer menarget Pod Kubernetes secara langsung dan mendistribusikan traffic ke Pod secara merata menggunakan model data yang disebut grup endpoint jaringan (NEG) Pendekatan ini meningkatkan performa jaringan, meningkatkan visibilitas, mengaktifkan fitur load balancing lanjutan, dan memungkinkan penggunaan Traffic Director, yakni yang mengelola bidang kontrol traffic sepenuhnya di Google Cloud untuk mesh layanan

Karena manfaat ini, load balancing berbasis container adalah solusi yang direkomendasikan untuk load balancing melalui Ingress. Saat NEG digunakan dengan GKE Ingress, pengontrol Ingress akan memfasilitasi pembuatan dari semua aspek load balancer L7. Hal ini termasuk membuat alamat IP virtual, aturan penerusan, health check, aturan firewall, dan banyak lagi.

Load balancing berbasis container menjadi lebih penting saat menggunakan Autoscaler Cluster. Untuk load balancer non-NEG, selama penurunan skala, pemrograman load balancing, dan pengosongan koneksi mungkin tidak sepenuhnya selesai sebelum Autoscaler Cluster menghentikan instance node. Hal ini dapat mengganggu koneksi yang sedang berlangsung dan mengalir melalui node meskipun Pod backend tidak ada pada node.

Load balancing berbasis container diaktifkan oleh default untuk Layanan saat semua kondisi berikut terpenuhi:

  • Layanan dibuat di cluster GKE 1.17.6-gke.7 dan lebih tinggi.
  • Jika Anda menggunakan cluster VPC native.
  • Jika Anda tidak menggunakan VPC Bersama.
  • Jika Anda tidak menggunakan Kebijakan Jaringan GKE.

Untuk informasi selengkapnya, lihat Dokumentasi GKE Ingress dan Gunakan load balancing berbasis container.

Pertimbangkan untuk menggunakan percobaan ulang dengan backoff eksponensial

Dalam arsitektur microservice yang berjalan di Kubernetes, kegagalan sementara mungkin muncul karena berbagai alasan, misalnya:

Masalah ini bersifat sementara, dan Anda dapat memitigasiinya dengan menghubungi layanan lagi setelah keterlambatan. Namun, untuk mencegah layanan tujuan yang berlebih dengan permintaan, penting bahwa Anda menjalankan panggilan ini menggunakan backoff eksponensial.

Untuk memfasilitasi pola percobaan ulang tersebut, banyak library yang ada menerapkan logika percobaan ulang eksponensial. Anda dapat menggunakan library pilihan Anda atau menulis kode Anda sendiri. Jika menggunakan Istio atau Anthos Service Mesh (ASM), Anda dapat memilih lmekanisme coba ulang level level yang secara transparan menjalankan percobaan ulang atas nama Anda.

Penting untuk merencanakan aplikasi Anda untuk mendukung percobaan ulang panggilan layanan, misalnya, untuk menghindari penyisipan informasi yang telah disisipkan. Pertimbangkan bahwa rantai percobaan ulang yang mungkin memengaruhi latensi pengguna akhir Anda, yang mungkin akan habis waktunya jika tidak direncanakan dengan benar.

Pantau lingkungan Anda dan terapkan konfigurasi serta praktik yang hemat biaya

Di banyak perusahaan menengah dan besar, tim platform dan infrastruktur terpusat sering kali bertanggung jawab untuk membuat, memelihara, dan memantau cluster Kubernetes untuk seluruh perusahaan. Hal ini mencerminkan kebutuhan yang kuat untuk memiliki akuntabilitas penggunaan resource dan untuk memastikan semua tim mengikuti kebijakan perusahaan. Bagian ini membahas opsi untuk memantau dan menerapkan praktik terkait biaya.

Amati cluster GKE Anda dan perhatikan rekomendasinya

Anda dapat memeriksa pemakaian resource di cluster Kubernetes dengan memeriksa container, Pod, dan layanan, serta karakteristik cluster secara menyeluruh Ada banyak cara untuk melakukan tugas ini, tetapi pendekatan awal yang kami rekomendasikan adalah mengamati cluster GKE Anda melalui Dasbor Pemantauan. Hal ini memberi Anda data deret waktu tentang cara cluster Anda digunakan, sehingga Anda dapat menggabung dan mencakup dari infrastruktur, workload dan layanan.

Meskipun ini adalah titik awal yang baik, Google Cloud menyediakan opsi lain—misalnya:

  • Di Konsol Google Cloud, di halaman Cluster GKE, lihat kolom Notifications. Jika Anda memiliki pemborosan resource yang tinggi dalam cluster, UI memberi Anda petunjuk tentang keseluruhan versus yang dialokasikan dan informasi yang diminta.

    Buka Daftar Cluster GKE

  • Di konsol Google Cloud pada halaman Rekomendasi, cari kartu rekomendasi Penghematan Biaya.

    Buka Hub Rekomendasi

Untuk detail selengkapnya, baca artikel Mengamati cluster GKE dan Memulai Hub Rekomendasi.

Aktifkan pengukuran penggunaan GKE

Untuk pendekatan yang lebih fleksibel agar Anda dapat melihat perincian dari perkiraan biaya, coba mengukur penggunaan GKE. Dengan mengukur penggunaan GKE, Anda dapat melihat profil penggunaan cluster GKE yang diperinci berdasarkan namespace dan label. Fitur ini melacak informasi tentang permintaan resource dan konsumsi resource dari workload cluster Anda, seperti CPU, GPU, TPU, memori, penyimpanan, dan jaringan keluar yang secara opsional.

Mengukur penggunaan GKE membantu Anda memahami keseluruhan struktur biaya dari cluster GKE Anda, tim atau aplikasi yang paling banyak mengeluarkan uang, lingkungan atau komponen yang menyebabkan lonjakan penggunaan atau biaya yang tiba-tiba, dan tim yang menjadi boros. Dengan membandingkan permintaan resource dengan pemanfaatan sebenarnya, Anda dapat memahami workload mana yang disediakan terlalu rendah atau berlebih.

Anda dapat mendapat manfaat dari template default Looker Studio, atau selangkah lebih maju lalu sesuaikan dengan dasbor menurut kebutuhan organisasi Anda. Untuk mengetahui informasi selengkapnya tentang mengukur penggunaan GKE dan prasyaratnya, lihat Memahami penggunaan resource cluster.

Pahami dan pantau cara kerja Server Metrik

Server Metrik adalah sumber metrik resource container untuk pipeline penskalaan otomatis bawaan GKE. Server Metrik mengambil metrik dari kubelets dan mengeksposnya melalui Metrics API Kubernetes. HPA dan VPA kemudian menggunakan metrik ini untuk menentukan waktu untuk memicu penskalaan otomatis.

Agar penskalaan otomatis GKE dapat terpenuhi, Anda harus memiliki Server Metrik yang sehat. Dengan deployment metrics-server GKE, nanny pengubah ukuran diinstal, yang membuat container Server Metrik bertumbuh secara vertikal dengan menambah atau menghapus CPU dan memori sesuai dengan jumlah node cluster. Update Pod masih belum didukung di Kubernetes, Itulah sebabnya nanny harus memulai ulang Pod metrics-server untuk menerapkan resource baru yang diperlukan.

Meskipun mulai ulang terjadi dengan cepat, latensi total bagi autoscaler untuk menyadari bahwa mereka harus bertindak sedikit ditingkatkan setelah perubahan metrics-server ukuran Agar Server Metrik tidak sering dimulai ulang pada cluster yang berubah dengan cepat, mulai dari GKE 1.15.11-gke.9, nanny mendukung penundaan perubahan ukuran.

Ikuti praktik terbaik ini saat menggunakan Server Metrik:

  • Pilih versi GKE yang mendukung metrics-server penundaan perubahan ukuran. Anda dapat mengonfirmasinya dengan memeriksa apakah metrics-serverfile YAML deployment memiliki scale-down-delay konfigurasi di metrics-server-nannycontainer
  • Pantau metrics-server deployment. Jika Server Metrik tidak telah dihapus, artinya tidak ada penskalaan otomatis yang bekerja sama sekali. Anda ingin layanan pemantauan prioritas utama Anda memantau deployment ini.
  • Ikuti praktik terbaik yang dibahas dalam Penskalaan otomatis GKE.

Gunakan Kuota Resource Kubernetes

Dalam cluster multi-tenant, tim yang berbeda biasanya bertanggung jawab atas aplikasi yang di-deploy pada namespace berbeda. Untuk grup infrastruktur dan platform terpusat, perlu diperhatikan bahwa satu tim mungkin menggunakan lebih banyak resource daripada yang diperlukan. Menghabiskan resource komputasi seluruh cluster atau bahkan memicu terlalu banyak peningkatan skala dapat meningkatkan biaya Anda.

Untuk mengatasi masalah ini, Anda harus menggunakan kuota resource. Kuota resource mengelola jumlah resource yang digunakan oleh objek dalam namespace. Anda dapat menetapkan kuota dalam hal komputasi (CPU dan memori) dan penyimpanan resource, atau dalam hal jumlah objek. Kuota resource memungkinkan Anda untuk memastikan bahwa tidak ada tenant yang menggunakan lebih dari bagian resource cluster yang ditetapkan.

Untuk informasi lebih lanjut, lihat Konfigurasi Kuota Memori dan CPU untuk Namespace.

Pertimbangkan untuk menggunakan Pengontrol Kebijakan GKE Enterprise

GKE Enterprise Policy Controller (APC) adalah pengontrol penerimaan dinamis Kubernetes yang memeriksa, mengaudit, dan menerapkan kepatuhan cluster Anda terhadap kebijakan terkait keamanan, peraturan, atau aturan bisnis arbitrer. Pengontrol Kebijakan menggunakan batasan untuk menerapkan kepatuhan cluster Anda. Misalnya, Anda dapat menginstal batasan cluster Anda dari banyaknya praktik terbaik yang dibahas di bagian Menyiapkan aplikasi Kubernetes berbasis cloud. Dengan cara ini, deployment akan ditolak jika benar-benar tidak mematuhi praktik Kubernetes Anda. Menerapkan aturan tersebut membantu menghindari lonjakan biaya yang tidak terduga dan mengurangi kemungkinan ketidakstabilan workload selama penskalaan otomatis.

Untuk informasi selengkapnya tentang cara menerapkan dan menulis aturan Anda sendiri, lihat Membuat batasan dan Menulis template batasan. Jika bukan pelanggan GKE Enterprise, Anda dapat mempertimbangkan untuk menggunakan Gatekeeper, software open source yang mendukung APC.

Desain pipeline CI/CD Anda untuk menerapkan praktik hemat biaya

Pengontrol Kebijakan GKE Enterprise membantu Anda menghindari deployment software yang tidak mematuhi kebijakan di cluster GKE. Namun, sebaiknya terapkan batasan kebijakan tersebut di awal siklus pengembangan Anda , baik dalam pemeriksaan pra-commit, permintaan pull pengiriman alur kerja, atau langkah apa pun yang masuk akal di lingkungan Anda. Praktik ini memungkinkan Anda menemukan dan memperbaiki kesalahan konfigurasi dengan cepat, serta membantu Anda memahami hal yang perlu diperhatikan dengan membuat keamanan.

Pertimbangkan juga untuk menggunakan fungsi kpt dalam pipeline CI/CD untuk memvalidasi apakah file konfigurasi Kubernetes mematuhi batasan yang diberlakukan oleh Pengontrol Kebijakan GKE Enterprise, dan untuk memperkirakan pemakaian resource atau biaya deployment. Dengan cara ini, Anda dapat menghentikan pipeline saat masalah terkait biaya terdeteksi. Atau, Anda dapat membuat proses persetujuan deployment yang berbeda untuk konfigurasi, misalnya, meningkatkan jumlah replika.

Untuk mengetahui informasi selengkapnya, lihat Menggunakan Pengontrol Kebijakan di pipeline CI, dan untuk contoh lengkap platform pengiriman, lihat CI/CD modern dengan GKE Enterprise.

Sebarkan budaya hemat biaya

Banyak organisasi membuat abstraksi dan platform untuk menyembunyikan kompleksitas infrastruktur dari Anda. Ini adalah praktik umum di perusahaan yang memigrasikan layanan mereka dari virtual machine ke Kubernetes. Terkadang perusahaan ini mengizinkan developer mengonfigurasi aplikasi mereka sendiri dalam produksi. Namun, tidak jarang ada developer yang belum pernah menyentuh cluster Kubernetes.

Praktik yang kami rekomendasikan di bagian ini, bukan berarti Anda harus berhenti melakukan abstraksi sama sekali. Sebaliknya, dasbor ini membantu Anda melihat pengeluaran di Google Cloud serta melatih developer Anda dan operator terkait infrastruktur Anda. Anda dapat melakukannya dengan membuat insentif dan program pembelajaran yang dapat Anda gunakan di kelas tradisional atau online, grup diskusi, ulasan sejawat, pemrograman pasangan, CI/CD dan gamifikasi yang hemat biaya, dan banyak lagi. Misalnya, dalam dunia Kubernetes, penting untuk memahami dampak aplikasi gambar 3 Gb, pemeriksaan kesiapan yang hilang, atau kesalahan konfigurasi HPA.

Terakhir, seperti yang ditampilkan dalam riset DORA Google, kemampuan budaya adalah beberapa faktor utama yang mendorong performa organisasi yang lebih baik, lebih sedikit pengerjaan ulang, lebih sedikit kejenuhan, dan sebagainya. Hemat biaya tidak lah berbeda. Memberi karyawan Anda akses ke pengeluaran mereka akan menyelaraskan mereka lebih dekat dengan tujuan dan batasan bisnis.

Ringkasan praktik terbaik

Tabel berikut meringkas praktik terbaik yang direkomendasikan dalam dokumen ini.

Topik Tugas
Fitur dan opsi pengoptimalan biaya GKE
Siapkan aplikasi Kubernetes berbasis cloud
Pantau lingkungan Anda dan terapkan konfigurasi serta praktik yang hemat biaya
Budaya

Langkah selanjutnya