Untuk setiap sumber daya Kubernetes, Anda dapat mengonfigurasi dua jenis persyaratan - Permintaan dan Batasan. Yang pertama menjelaskan persyaratan minimum untuk ketersediaan sumber daya node gratis yang diperlukan untuk menjalankan sebuah container atau pod, yang kedua secara ketat membatasi sumber daya yang tersedia untuk container tersebut.
Saat Kubernetes menjadwalkan pod, sangat penting bagi container untuk memiliki sumber daya yang cukup agar dapat berfungsi dengan baik. Jika Anda berencana untuk menyebarkan aplikasi besar pada node dengan sumber daya terbatas, ada kemungkinan aplikasi tersebut tidak akan berjalan karena memori node hampir habis atau kehabisan daya CPU. Dalam artikel ini, kita akan melihat bagaimana Anda dapat mengatasi kekurangan daya komputasi menggunakan permintaan dan batasan sumber daya.
Permintaan dan Batasan adalah mekanisme yang digunakan Kubernetes untuk mengelola sumber daya seperti CPU dan memori. Permintaan adalah hal yang memastikan kontainer menerima sumber daya yang diminta. Jika sebuah container meminta sumber daya, Kubernetes hanya akan menjadwalkannya pada node yang dapat menyediakannya. Batas mengontrol bahwa sumber daya yang diminta oleh penampung tidak akan pernah melebihi nilai tertentu.
Sebuah container hanya dapat meningkatkan daya komputasinya hingga batas tertentu, setelah itu akan dibatasi. Mari kita lihat cara kerjanya. Jadi, ada dua jenis sumber daya - prosesor dan memori. Penjadwal Kubernetes menggunakan data tentang sumber daya ini untuk mengetahui tempat menjalankan pod Anda. Spesifikasi sumber daya tipikal untuk sebuah pod terlihat seperti ini.
Setiap container di dalam pod dapat menetapkan kueri dan batasannya sendiri, semuanya bersifat tambahan. Sumber daya prosesor ditentukan dalam milicore. Jika kontainer Anda memerlukan dua inti penuh untuk dijalankan, tetapkan nilainya menjadi 2000m. Jika wadah hanya membutuhkan daya 1/4 inti maka nilainya menjadi 250m. Perlu diingat bahwa jika Anda menetapkan nilai sumber daya CPU lebih besar dari jumlah inti node terbesar, pod Anda tidak akan dijadwalkan untuk dijalankan sama sekali. Situasi serupa akan terjadi jika Anda memiliki Pod yang memerlukan empat inti, dan cluster Kubernetes hanya terdiri dari dua mesin virtual utama.
Kecuali jika aplikasi Anda dirancang khusus untuk memanfaatkan banyak inti (yang terlintas dalam pikiran adalah program seperti komputasi ilmiah kompleks dan operasi basis data), maka praktik terbaiknya adalah menyetel Permintaan CPU ke 1 atau lebih rendah, lalu menjalankan lebih banyak replika untuk skalabilitas. Solusi ini akan memberikan fleksibilitas dan keandalan sistem yang lebih besar.
Terkait keterbatasan CPU, segalanya menjadi lebih menarik karena dianggap sebagai sumber daya yang dapat dikompresi. Jika aplikasi Anda mulai mendekati batas daya prosesor, Kubernetes akan mulai memperlambat container Anda menggunakan CPU Throttling - mengurangi frekuensi prosesor. Ini berarti bahwa CPU akan dibatasi secara artifisial, sehingga berpotensi memberikan kinerja aplikasi yang lebih buruk, namun prosesnya tidak akan dihentikan atau dihentikan.
Sumber daya memori ditentukan dalam byte. Biasanya nilai dalam pengaturan diukur dalam mebibyte Mib, tetapi Anda dapat menetapkan nilai apa pun, dari byte hingga petabyte. Situasi yang sama berlaku di sini seperti pada CPU - jika Anda mengajukan permintaan jumlah memori yang lebih besar daripada jumlah memori pada node Anda, pod tersebut tidak akan dijadwalkan untuk dieksekusi. Namun tidak seperti sumber daya CPU, memori tidak dikompresi karena tidak ada cara untuk membatasi penggunaannya. Oleh karena itu, eksekusi kontainer akan dihentikan segera setelah melebihi memori yang dialokasikan padanya.
Penting untuk diingat bahwa Anda tidak dapat mengonfigurasi permintaan yang melebihi sumber daya yang dapat disediakan oleh node Anda. Spesifikasi resource bersama untuk mesin virtual GKE dapat ditemukan pada link di bawah video ini.
Idealnya, pengaturan default container akan cukup untuk menjaga alur kerja berjalan lancar. Namun dunia nyata tidak seperti itu, orang dapat dengan mudah lupa mengkonfigurasi penggunaan sumber daya, atau peretas akan menetapkan permintaan dan batasan yang melebihi kemampuan infrastruktur sebenarnya. Untuk mencegah terjadinya skenario seperti itu, Anda dapat mengonfigurasi kuota sumber daya ResourceQuota dan LimitRange.
Setelah namespace dibuat, namespace tersebut dapat diblokir menggunakan kuota. Misalnya, jika Anda memiliki namespace prod dan dev, polanya adalah tidak ada kuota produksi sama sekali dan kuota pengembangan sangat ketat. Hal ini memungkinkan prod, jika terjadi lonjakan lalu lintas yang tajam, untuk mengambil alih seluruh sumber daya yang tersedia, memblokir dev sepenuhnya.
Kuota sumber daya mungkin terlihat seperti ini. Dalam contoh ini ada 4 bagian - ini adalah 4 baris kode terbawah.
Mari kita lihat masing-masingnya. Requests.cpu adalah jumlah maksimum permintaan CPU gabungan yang dapat berasal dari semua kontainer di namespace. Dalam contoh ini, Anda dapat memiliki 50 kontainer dengan permintaan 10 juta, lima kontainer dengan permintaan 100 juta, atau hanya satu kontainer dengan permintaan 500 juta. Selama jumlah total request.cpu dari namespace tertentu kurang dari 500m, semuanya akan baik-baik saja.
Permintaan memori yang diminta.memori adalah jumlah maksimum permintaan memori gabungan yang dapat dimiliki oleh semua kontainer di namespace. Seperti dalam kasus sebelumnya, Anda dapat memiliki 50 kontainer 2 mib, lima kontainer 20 mib, atau satu kontainer 100 mib selama jumlah total memori yang diminta dalam namespace kurang dari 100 mebibyte.
Limits.cpu adalah jumlah gabungan maksimum daya CPU yang dapat digunakan oleh semua container di namespace. Kita dapat menganggap ini sebagai batas permintaan daya prosesor.
Terakhir, limit.memory adalah jumlah maksimum memori bersama yang dapat digunakan oleh semua container di namespace. Ini adalah batas total permintaan memori.
Jadi, secara default, container di cluster Kubernetes dijalankan dengan sumber daya komputasi yang tidak terbatas. Dengan kuota sumber daya, administrator klaster dapat membatasi konsumsi sumber daya dan pembuatan sumber daya berdasarkan namespace. Dalam sebuah namespace, sebuah pod atau container dapat menggunakan daya CPU dan memori sebanyak yang ditentukan oleh kuota sumber daya namespace. Namun, terdapat kekhawatiran bahwa satu pod atau container dapat memonopoli seluruh sumber daya yang tersedia. Untuk mencegah situasi ini, rentang batas digunakan - kebijakan untuk membatasi alokasi sumber daya (untuk pod atau container) di namespace.
Rentang batas memberikan batasan yang dapat:
- Memastikan penggunaan sumber daya komputasi minimum dan maksimum untuk setiap modul atau kontainer di namespace;
- menerapkan permintaan penyimpanan Starage Request minimum dan maksimum untuk setiap PersistentVolumeClaim di namespace;
- menegakkan hubungan antara Permintaan dan Batas untuk sumber daya di namespace;
- atur Permintaan/Batas default untuk sumber daya komputasi di namespace dan secara otomatis memasukkannya ke dalam kontainer pada waktu proses.
Dengan cara ini Anda dapat membuat rentang batas di namespace Anda. Berbeda dengan kuota, yang berlaku untuk seluruh namespace, Rentang Batas digunakan untuk kontainer individual. Hal ini dapat mencegah pengguna membuat container yang sangat kecil atau, sebaliknya, raksasa di dalam namespace. Rentang Batas mungkin terlihat seperti ini.
Seperti pada kasus sebelumnya, ada 4 bagian yang dapat dibedakan di sini. Mari kita lihat masing-masing.
Bagian default menetapkan batas default untuk container di dalam pod. Jika Anda menetapkan nilai-nilai ini ke kisaran ekstrem, maka wadah apa pun yang nilai-nilai ini belum ditetapkan secara eksplisit akan mengikuti nilai default.
Bagian permintaan default defaultRequest mengonfigurasi permintaan default untuk container di pod. Sekali lagi, jika Anda menyetel nilai ini ke rentang ekstrem, maka penampung apa pun yang tidak secara eksplisit menyetel opsi ini akan menggunakan nilai ini secara default.
Bagian max menentukan batas maksimum yang dapat ditetapkan untuk sebuah container di dalam pod. Nilai pada bagian default dan batas penampung tidak dapat disetel di atas batas ini. Penting untuk diperhatikan bahwa jika nilai disetel ke max dan tidak ada bagian default, maka nilai maksimum menjadi nilai default.
Bagian min menentukan permintaan minimum yang dapat diatur untuk sebuah container di dalam pod. Namun, nilai di bagian default dan kueri untuk penampung tidak dapat disetel di bawah batas ini.
Sekali lagi, penting untuk dicatat bahwa jika nilai ini disetel, defaultnya tidak, maka nilai minimum menjadi prompt default.
Permintaan sumber daya ini pada akhirnya digunakan oleh penjadwal Kubernetes untuk menjalankan beban kerja Anda. Agar Anda dapat mengonfigurasi container dengan benar, sangat penting untuk memahami cara kerjanya. Katakanlah Anda ingin menjalankan beberapa pod di cluster Anda. Dengan asumsi spesifikasi pod valid, jadwal Kubernetes akan menggunakan penyeimbangan round robin untuk memilih node guna menjalankan beban kerja.
Kubernetes akan memeriksa apakah Node 1 memiliki sumber daya yang cukup untuk memenuhi permintaan dari kontainer pod, dan jika tidak, maka akan berpindah ke node berikutnya. Jika tidak ada satu pun node di sistem yang dapat memenuhi permintaan tersebut, pod akan masuk ke status Pending. Dengan menggunakan fitur mesin Google Kubernetes seperti penskalaan otomatis node, GKE dapat mendeteksi status tunggu secara otomatis dan membuat beberapa node tambahan lagi.
Jika Anda kemudian kehabisan kapasitas node, penskalaan otomatis akan mengurangi jumlah node untuk menghemat uang Anda. Inilah sebabnya Kubernetes menjadwalkan pod berdasarkan permintaan. Namun, batasnya mungkin lebih tinggi dari permintaan, dan dalam beberapa kasus, node mungkin kehabisan sumber daya. Kami menyebut kondisi ini sebagai kondisi komitmen berlebihan.
Seperti yang saya katakan, jika menyangkut CPU, Kubernetes akan mulai membatasi pod. Setiap pod akan menerima sebanyak yang diminta, namun jika tidak mencapai batas, pembatasan akan mulai berlaku.
Dalam hal sumber daya memori, Kubernetes terpaksa membuat keputusan tentang pod mana yang akan dihapus dan mana yang akan disimpan sampai Anda mengosongkan sumber daya sistem atau seluruh sistem akan crash.
Bayangkan sebuah skenario ketika mesin Anda kehabisan memori - bagaimana Kubernetes mengatasinya?
Kubernetes akan mencari pod yang menggunakan lebih banyak sumber daya daripada yang diminta. Jadi, jika container Anda tidak memiliki Permintaan sama sekali, itu berarti container tersebut secara default menggunakan lebih dari yang diminta, hanya karena container tersebut tidak meminta apa pun sama sekali! Kontainer seperti ini menjadi kandidat utama untuk ditutup. Kandidat selanjutnya adalah container yang telah memenuhi semua permintaannya namun masih di bawah batas maksimal.
Jadi jika Kubernetes menemukan beberapa pod yang melebihi parameter permintaannya, Kubernetes akan mengurutkannya berdasarkan prioritas dan kemudian menghapus pod dengan prioritas terendah. Jika semua pod memiliki prioritas yang sama, maka Kubernetes akan menghentikan pod yang melebihi permintaannya dibandingkan pod lainnya.
Dalam kasus yang sangat jarang terjadi, Kubernetes dapat membatalkan pod yang masih berada dalam cakupan permintaannya. Hal ini dapat terjadi ketika komponen sistem penting seperti agen Kubelet atau Docker mulai menggunakan lebih banyak sumber daya daripada yang disediakan untuk mereka.
Jadi, pada tahap awal perusahaan kecil, klaster Kubernetes dapat berfungsi dengan baik tanpa menetapkan permintaan dan batasan sumber daya, namun seiring dengan bertambahnya ukuran tim dan proyek Anda, Anda berisiko mengalami masalah di area ini. Menambahkan kueri dan batasan ke modul dan namespace Anda hanya memerlukan sedikit usaha ekstra dan dapat menghemat banyak kerumitan.
Beberapa iklan π
Terima kasih untuk tetap bersama kami. Apakah Anda menyukai artikel kami? Ingin melihat konten yang lebih menarik? Dukung kami dengan melakukan pemesanan atau merekomendasikan kepada teman, , analog unik dari server level awal, yang kami temukan untuk Anda: (tersedia dengan RAID1 dan RAID10, hingga 24 core dan hingga 40GB DDR4).
Dell R730xd 2x lebih murah di pusat data Equinix Tier IV di Amsterdam? Hanya disini di Belanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - mulai $99! Membaca tentang
Sumber: www.habr.com