Halaman ini menjelaskan praktik terbaik secara umum untuk merancang cluster GKE yang skalabel. Anda dapat menerapkan rekomendasi ini pada semua cluster dan beban kerja untuk mencapai performa yang optimal. Rekomendasi ini sangat penting untuk cluster yang akan Anda skalakan secara signifikan. Praktik terbaik ditujukan bagi administrator yang bertanggung jawab untuk menyediakan infrastruktur dan bagi developer yang menyiapkan komponen dan beban kerja kubernetes.
Apa itu skalabilitas?
Dalam cluster Kubernetes, skalabilitas mengacu pada kemampuan cluster untuk berkembang sambil tetap berada dalam tujuan tingkat layanan (SLO)-nya. Kubernetes juga memiliki kumpulan SLO sendiri
Kubernetes adalah sistem yang kompleks, dan kemampuannya untuk melakukan penskalaan ditentukan oleh beberapa faktor. Beberapa faktor ini mencakup jenis dan jumlah node dalam kumpulan node, jenis dan jumlah kumpulan node, jumlah Pod yang tersedia, cara resource dialokasikan ke Pod, dan jumlah Layanan atau backend di balik Layanan.
Praktik terbaik untuk ketersediaan
Memilih bidang kontrol regional atau zona
Karena perbedaan arsitektur, cluster regional lebih cocok untuk ketersediaan tinggi. Cluster regional memiliki beberapa bidang kontrol di beberapa zona komputasi dalam satu region, sedangkan cluster zona memiliki satu bidang kontrol dalam satu zona komputasi.
Jika cluster zona diupgrade, VM bidang kontrol akan mengalami periode nonaktif selama Kubernetes API tidak tersedia hingga upgrade selesai.
Pada cluster regional, bidang kontrol tetap tersedia selama pemeliharaan cluster seperti rotasi IP, mengupgrade VM bidang kontrol, atau mengubah ukuran cluster atau kumpulan node. Saat mengupgrade cluster regional, dua dari tiga VM bidang kontrol selalu berjalan selama upgrade berkelanjutan, sehingga Kubernetes API masih tersedia. Demikian pula, pemadaman layanan zona tunggal tidak akan menyebabkan periode nonaktif di bidang kontrol regional.
Namun, semakin banyak cluster regional yang tersedia memiliki konsekuensi tertentu:
Perubahan pada konfigurasi cluster memerlukan waktu lebih lama karena harus diterapkan di semua bidang kontrol dalam cluster regional, bukan bidang kontrol tunggal di cluster zona.
Anda mungkin tidak dapat membuat atau mengupgrade cluster regional sesering cluster zona. Jika VM tidak dapat dibuat di salah satu zona, baik karena kurangnya kapasitas atau masalah sementara lainnya, cluster tidak dapat dibuat atau diupgrade.
Karena kompromi ini, cluster zona dan regional memiliki kasus penggunaan yang berbeda:
- Gunakan cluster zona untuk membuat atau mengupgrade cluster dengan cepat jika ketersediaan tidak menjadi kekhawatiran.
- Gunakan cluster regional jika ketersediaan lebih penting daripada fleksibilitas.
Pilih jenis cluster dengan cermat saat membuat cluster karena Anda tidak dapat mengubahnya setelah cluster dibuat. Sebagai gantinya, Anda harus membuat cluster baru, lalu memigrasikan traffic ke cluster tersebut. Migrasi traffic produksi antar-cluster dapat dilakukan, tetapi sulit dalam skala besar.
Memilih kumpulan node multi-zona atau satu zona
Untuk mencapai ketersediaan tinggi, harus dilakukan penyebaran bidang kontrol Kubernetes dan node-nya di berbagai zona. GKE menawarkan dua jenis kumpulan node: satu zona dan multi-zona.
Untuk men-deploy aplikasi yang sangat tersedia, distribusikan beban kerja Anda di beberapa zona komputasi dalam satu region menggunakan kumpulan node multi-zona yang mendistribusikan node secara seragam di seluruh zona.
Jika semua node berada di zona yang sama, Anda tidak akan dapat menjadwalkan Pod jika zona tersebut tidak dapat dijangkau. Penggunaan kumpulan node multi-zona memiliki konsekuensi tertentu:
GPU hanya tersedia di zona tertentu. Anda mungkin tidak dapat menjangkaunya di semua zona dalam region.
Latensi bolak-balik antarzona dalam satu region mungkin lebih tinggi daripada latensi antar-resource dalam satu zona. Perbedaannya seharusnya tidak penting untuk sebagian besar beban kerja.
Harga traffic egress antar-zona di region yang sama tersedia di halaman harga Compute Engine.
Praktik terbaik untuk penskalaan
Infrastruktur dasar
Beban kerja Kubernetes memerlukan jaringan, komputasi, dan penyimpanan. Anda perlu menyediakan CPU dan memori yang cukup untuk menjalankan Pod. Namun, ada lebih banyak parameter infrastruktur dasar yang dapat memengaruhi performa dan skalabilitas cluster GKE.
Jaringan cluster
Menggunakan cluster berbasis VPC adalah setelan default jaringan dan pilihan yang direkomendasikan untuk menyiapkan cluster GKE baru. Cluster berbasis VPC memungkinkan beban kerja yang lebih besar, jumlah node yang lebih tinggi, dan beberapa keuntungan lainnya.
Dalam mode ini, jaringan VPC memiliki rentang sekunder untuk semua alamat IP Pod. Setiap node kemudian diberi bagian rentang sekunder untuk alamat IP Pod-nya sendiri. Hal ini memungkinkan jaringan VPC secara native memahami cara merutekan traffic ke Pod tanpa mengandalkan rute kustom. Satu jaringan VPC dapat memiliki hingga 15000 VM.
Pendekatan lain, yang tidak digunakan lagi dan mendukung tidak lebih dari 1500 node, adalah menggunakan cluster berbasis rute. Cluster berbasis rute tidak cocok untuk beban kerja yang besar. Menggunakan kuota rute VPC dan tidak memiliki manfaat lain dari jaringan native VPC. Cara kerjanya adalah dengan menambahkan rute kustom baru ke tabel perutean di jaringan VPC untuk setiap node baru.
Ukuran cluster
Cluster yang lebih besar dari 5.000 node harus menggunakan Private Service Connect. Private Service Connect menghubungkan node dan bidang kontrol secara pribadi, serta menawarkan keamanan dan performa jaringan yang lebih baik.
Load balancing cluster
GKE Ingress dan Cloud Load Balancing mengonfigurasi dan men-deploy load balancing untuk mengekspos beban kerja Kubernetes di luar cluster dan juga ke internet publik. GKE Ingress dan Pengontrol Layanan men-deploy objek seperti aturan penerusan, peta URL, layanan backend, grup endpoint jaringan, dan lainnya atas nama workload GKE. Masing-masing resource ini memiliki kuota dan batas inheren dan batas ini juga berlaku di GKE. Jika resource Cloud Load Balancing tertentu telah mencapai kuotanya, hal ini akan mencegah Ingress atau Layanan tertentu di-deploy dengan benar dan error akan muncul dalam peristiwa resource.
Tabel berikut menjelaskan batas penskalaan saat menggunakan GKE Ingress and Services:
| Load balancer | Batas node per cluster |
|---|---|
| Load Balancer Network passthrough internal |
|
| Load Balancer Jaringan passthrough eksternal | 1000 node per zona |
| Load Balancer Aplikasi Eksternal |
|
| Load Balancer Aplikasi Internal | Tidak ada batas node |
Jika Anda perlu melakukan penskalaan lebih lanjut, hubungi tim penjualan Google Cloud Anda untuk meningkatkan batas ini.
DNS
Penemuan layanan di GKE disediakan melalui kube-dns, yang merupakan resource terpusat untuk memberikan resolusi DNS ke Pod yang beroperasi di dalam cluster. Hal ini dapat menyebabkan bottleneck pada cluster yang sangat besar atau untuk beban kerja yang memiliki beban permintaan tinggi. GKE secara otomatis menskalakan kube-dns secara otomatis berdasarkan ukuran cluster untuk meningkatkan kapasitasnya. Jika kapasitas ini masih belum cukup, GKE menawarkan resolusi lokal yang terdistribusi untuk kueri DNS pada setiap node dengan NodeLocal DNSCache. Tindakan ini menyediakan cache DNS lokal di setiap node GKE yang menjawab kueri secara lokal, mendistribusikan beban, dan memberikan waktu respons yang lebih cepat.
Mengelola alamat IP di cluster native VPC
Cluster native VPC menggunakan tiga rentang alamat IP:
- Rentang utama untuk subnet node: Secara default ditetapkan ke /20 (4092 alamat IP).
- Rentang sekunder untuk subnet Pod: Secara default ditetapkan ke /14 (262.144 alamat IP). Namun, Anda dapat mengonfigurasi subnet Pod.
- Rentang sekunder untuk subnet Layanan: Secara default ditetapkan ke /20 (4096 alamat). Namun, Anda tidak dapat mengubah rentang ini setelah membuat subnet Layanan ini.
Untuk mengetahui informasi selengkapnya, lihat Rentang alamat IP untuk cluster native VPC.
Batasan dan rekomendasi alamat IP:
- Batas node: Batas node ditentukan oleh alamat IP utama dan Pod per node. Harus ada cukup alamat di rentang alamat IP node dan Pod untuk menyediakan node baru. Secara default, Anda hanya dapat membuat 1.024 node karena batasan alamat IP Pod.
- Batas Pod per node: Secara default, batas Pod per node adalah 110 Pod. Namun, Anda dapat mengonfigurasi CIDR Pod yang lebih kecil untuk penggunaan yang efisien dengan lebih sedikit Pod per node.
- Menskalakan di luar RFC 1918: Jika Anda memerlukan lebih banyak alamat IP daripada yang tersedia dalam ruang pribadi yang ditentukan oleh RFC 1918, sebaiknya gunakan alamat pribadi non-RFC 1918 atau PUPI untuk fleksibilitas tambahan.
- Rentang alamat IP sekunder untuk Layanan dan Pod: Secara default, Anda dapat mengonfigurasi 4096 Layanan. Namun, Anda dapat mengonfigurasi lebih banyak Layanan dengan memilih rentang subnet Layanan. Anda tidak dapat mengubah rentang sekunder setelah dibuat. Saat membuat cluster, pastikan Anda memilih rentang yang cukup besar untuk mengakomodasi pertumbuhan yang diharapkan. Namun, Anda dapat menambahkan lebih banyak alamat IP untuk Pod nanti menggunakan CIDR multi-Pod yang terpisah-pisah. Untuk mengetahui informasi selengkapnya, lihat Ruang alamat IP yang kosong tidak cukup untuk Pod.
Untuk informasi selengkapnya, lihat rentang yang membatasi node dan Merencanakan alamat IP saat bermigrasi ke GKE.
Mengonfigurasi node untuk performa yang lebih baik
Node GKE adalah mesin virtual Google Cloud reguler. Beberapa parameternya, misalnya jumlah core atau ukuran disk, dapat memengaruhi performa cluster GKE.
Mengurangi waktu inisialisasi Pod
Anda dapat menggunakan Streaming gambar untuk melakukan streaming data dari image container yang memenuhi syarat saat beban kerja Anda memintanya, yang menghasilkan waktu inisialisasi yang lebih cepat.
Traffic keluar
Di Google Cloud, jenis mesin dan jumlah inti yang dialokasikan ke instance menentukan kapasitas jaringannya. Bandwidth egress maksimum bervariasi dari 1 hingga 32 Gbps, sedangkan bandwidth egress maksimum untuk mesin e2-medium-2 default adalah 2 Gbps. Untuk mengetahui detail tentang batas bandwidth, lihat Jenis mesin dengan inti bersama.
IOPS dan throughput disk
Di Google Cloud, ukuran persistent disk menentukan IOPS dan throughput disk. GKE biasanya menggunakan Persistent Disk sebagai boot disk dan untuk mendukung Volume Persistent Kubernetes. Peningkatan ukuran disk akan meningkatkan IOPS dan throughput, hingga batas tertentu.
Setiap operasi penulisan persistent disk berkontribusi terhadap batas traffic keluar jaringan kumulatif instance mesin virtual Anda. Dengan demikian, performa IOPS disk, terutama SSD, juga bergantung pada jumlah vCPU dalam instance selain ukuran disk. VM inti yang lebih rendah memiliki batas IOPS operasi tulis yang lebih rendah karena adanya batasan traffic egress jaringan pada throughput operasi tulis.
Jika instance mesin virtual Anda tidak memiliki CPU yang cukup, aplikasi tidak akan bisa mendekati batas IOPS. Sebagai aturan umum, Anda harus memiliki satu CPU yang tersedia untuk setiap 2000-2500 IOPS dari traffic yang diharapkan.
Beban kerja yang memerlukan kapasitas tinggi atau disk dalam jumlah besar perlu mempertimbangkan batas jumlah PD yang dapat dipasang ke satu VM. Untuk VM reguler, batas tersebut adalah 128 disk dengan ukuran total 64 TB, sedangkan VM dengan inti bersama memiliki batas 16 PD dengan total ukuran 3 TB. Google Cloud yang menerapkan batasan ini, bukan Kubernetes.
Memantau metrik bidang kontrol
Gunakan metrik bidang kontrol yang tersedia untuk mengonfigurasi dasbor pemantauan Anda. Anda dapat menggunakan metrik bidang kontrol untuk mengamati kondisi cluster, mengamati hasil perubahan konfigurasi cluster (misalnya, men-deploy beban kerja tambahan atau komponen pihak ketiga) atau saat memecahkan masalah.
Salah satu metrik terpenting untuk dipantau adalah latensi Kubernetes API. Jika latensi meningkat, ini menunjukkan kelebihan beban pada sistem. Perlu diingat bahwa panggilan LIST yang mentransfer data dalam jumlah besar diharapkan memiliki latensi yang jauh lebih tinggi daripada permintaan yang lebih kecil.
Peningkatan latensi Kubernetes API juga dapat disebabkan oleh respons yang lambat dari webhook penerimaan pihak ketiga. Anda dapat menggunakan metrik untuk mengukur latensi webhook guna mendeteksi masalah umum tersebut.
Praktik terbaik untuk developer Kubernetes
Gunakan pola daftar dan tontonan, bukan listingan berkala
Sebagai developer Kubernetes, Anda mungkin perlu membuat komponen yang memiliki persyaratan berikut:
- Komponen Anda perlu mengambil daftar beberapa objek Kubernetes secara berkala.
- Komponen Anda harus dijalankan di beberapa instance (dalam kasus DaemonSet, bahkan di setiap node).
Komponen tersebut dapat menghasilkan lonjakan beban pada kube-apiserver, meskipun status objek yang diambil secara berkala tidak berubah.
Pendekatan paling sederhana adalah menggunakan panggilan LIST berkala. Namun, ini adalah pendekatan yang tidak efisien dan mahal untuk pemanggil dan server karena semua objek harus dimuat ke memori, diserialisasi, dan ditransfer setiap saat. Penggunaan permintaan LIST yang berlebihan dapat membebani bidang kontrol atau menghasilkan throttling berat pada permintaan tersebut.
Anda dapat meningkatkan kualitas komponen dengan menetapkan parameter resourceVersion=0 pada panggilan LIST. Hal ini memungkinkan kube-apiserver menggunakan cache objek dalam memori dan mengurangi jumlah interaksi internal antara kube-apiserver dan database etcd serta pemrosesan terkait.
Sebaiknya hindari panggilan LIST yang berulang dan ganti dengan pola daftar dan smartwatch. Buat daftar objek sekali, lalu gunakan Watch API untuk mendapatkan perubahan status secara inkremental. Pendekatan ini mengurangi waktu pemrosesan dan meminimalkan traffic dibandingkan dengan panggilan LIST berkala. Jika objek tidak berubah, tidak ada beban tambahan yang dihasilkan.
Jika Anda menggunakan bahasa Go, periksa SharedInformer dan SharedInformerFactory untuk mengetahui paket Go yang menerapkan pola ini.
Batasi traffic tidak perlu yang dihasilkan oleh smartwatch dan daftar
Kubernetes secara internal menggunakan smartwatch untuk mengirim notifikasi tentang update objek. Meskipun smartwatch memerlukan lebih sedikit resource daripada panggilan LIST berkala, pemrosesan smartwatch dalam cluster besar dapat menyita sebagian besar resource cluster dan akan memengaruhi performa cluster. Dampak negatif terbesar dihasilkan dengan membuat smartwatch yang mengamati objek yang sering berubah dari beberapa tempat. Misalnya, dengan mengamati data tentang semua Pod dari komponen yang berjalan di semua node. Jika Anda menginstal kode atau ekstensi pihak ketiga di cluster, mereka dapat membuat smartwatch tersebut di balik layar.
Kami merekomendasikan praktik terbaik berikut:
- Kurangi pemrosesan dan traffic yang tidak perlu yang dihasilkan oleh smartwatch dan panggilan LIST.
- Hindari membuat smartwatch yang mengamati objek yang sering berubah dari beberapa tempat (misalnya DaemonSets).
- (Sangat direkomendasikan) Buat pengontrol pusat yang mengawasi dan memproses data yang diperlukan pada satu node.
- Perhatikan hanya subset objek, misalnya, kubelet pada setiap node mengamati hanya pod yang dijadwalkan pada node yang sama.
- Hindari men-deploy komponen atau ekstensi pihak ketiga yang dapat memengaruhi performa cluster dengan membuat smartwatch atau panggilan LIST bervolume tinggi.
Menggunakan update rolling dengan DaemonSet untuk mencegah peningkatan traffic secara tiba-tiba
Saat dibuat di cluster, DaemonSet akan segera menjadwalkan Pod baru di setiap Node. Jika semua Pod baru tersebut terhubung ke endpoint jaringan yang sama,
permintaan tersebut akan terjadi secara bersamaan, sehingga menimbulkan beban yang tinggi pada host target.
Untuk mencegah hal ini, konfigurasi DaemonSet Anda dengan update rolling dengan Pod maxSurge terbatas.
Membatasi ukuran manifes objek Kubernetes
Jika Anda membutuhkan operasi cepat yang memerlukan throughput Pod yang tinggi, seperti mengubah ukuran atau memperbarui beban kerja yang besar, pastikan untuk meminimalkan ukuran manifes Pod, idealnya di bawah 10 KiB.
Kubernetes menyimpan manifes resource dalam dll. Seluruh manifes dikirim setiap kali resource diambil, termasuk saat Anda menggunakan pola daftar dan jam tangan.
Ukuran manifes memiliki batasan berikut:
- Ukuran maksimum untuk setiap objek dalam etcd: Sekitar 1,5 MiB.
- Kuota total untuk semua objek etcd dalam cluster: Ukuran kuota yang telah dikonfigurasi sebelumnya adalah 6 GiB. Ini mencakup log perubahan dengan semua pembaruan untuk semua objek dalam 150 detik terakhir histori cluster.
- Performa bidang kontrol selama periode traffic tinggi: Ukuran manifes yang lebih besar akan meningkatkan beban di server API.
Untuk objek tunggal yang jarang diproses, ukuran manifes biasanya tidak menjadi masalah selama di bawah 1,5 MiB. Namun, ukuran manifes di atas 10 KiB untuk banyak objek yang sering diproses - seperti pod dalam beban kerja yang sangat besar - dapat menyebabkan peningkatan latensi panggilan API dan penurunan performa secara keseluruhan. Daftar dan tontonan secara khusus dapat terpengaruh secara signifikan oleh ukuran manifes yang besar. Anda mungkin juga mengalami masalah dengan kuota etcd, karena jumlah revisi dalam 150 detik terakhir dapat terakumulasi dengan cepat selama periode traffic server API yang tinggi.
Untuk mengurangi ukuran manifes pod, ConfigMaps Kubernetes dapat dimanfaatkan untuk menyimpan bagian konfigurasi, terutama bagian yang digunakan bersama oleh beberapa pod di cluster. Misalnya, variabel lingkungan sering digunakan bersama oleh semua pod dalam beban kerja.
Perlu diperhatikan bahwa Anda juga dapat mengalami masalah serupa dengan objek ConfigMap jika jumlahnya sebanyak, sebesar, dan diproses sesering pod. Mengekstrak bagian konfigurasi akan sangat berguna saat mengurangi keseluruhan traffic.
Nonaktifkan pemasangan otomatis akun layanan default
Jika logika yang berjalan di Pod tidak perlu mengakses Kubernetes API, Anda harus menonaktifkan pemasangan otomatis akun layanan default untuk menghindari pembuatan Secret dan smartwatch terkait.
Saat Anda membuat Pod tanpa menentukan akun layanan, Kubernetes akan otomatis melakukan tindakan berikut:
- Menetapkan akun layanan default ke Pod.
- Memasang kredensial akun layanan sebagai Secret untuk Pod.
- Untuk setiap Secret yang terpasang, kubelet akan membuat smartwatch untuk mengamati perubahan pada Secret tersebut di setiap node.
Dalam cluster besar, tindakan ini mewakili ribuan smartwatch yang tidak diperlukan dan dapat memberikan beban signifikan pada kube-apiserver.
Menggunakan buffering Protokol sebagai ganti JSON untuk permintaan API
Gunakan buffering protokol saat menerapkan komponen yang sangat skalabel seperti yang dijelaskan dalam Konsep Kubernetes API.
REST API Kubernetes mendukung JSON dan buffering protokol sebagai format serialisasi untuk objek. JSON digunakan secara default, tetapi buffering protokol lebih efisien untuk performa dalam skala besar karena memerlukan pemrosesan yang lebih efisien dengan CPU dan mengirimkan lebih sedikit data melalui jaringan. Overhead yang terkait dengan pemrosesan JSON dapat menyebabkan waktu tunggu habis saat mencantumkan data berukuran besar.