Get best of the week

Praktik terbaik Kubernetes. Menyetel Kueri dan Batas Sumber Daya

Praktik terbaik Kubernetes. Membuat Kontainer Kecil
Kubernetes Praktik Terbaik. Organisasi Kubernetes dengan Kubernetes
Best Practices Namespace. Memeriksa kelayakan Kubernetes menggunakan uji Kesiapan dan Liveness

Untuk setiap sumber daya Kubernetes, Anda dapat mengonfigurasi dua jenis persyaratan - Permintaan dan Batas. Yang pertama menjelaskan persyaratan minimum untuk ketersediaan sumber daya simpul gratis yang diperlukan untuk menjalankan wadah atau perapian, yang kedua secara ketat membatasi sumber daya yang tersedia untuk wadah.

Ketika Kubernetes merencanakan pod, sangat penting bahwa wadah memiliki sumber daya yang cukup untuk operasi normal. Jika Anda berencana untuk menyebarkan aplikasi besar pada sebuah node dengan sumber daya terbatas, sangat mungkin itu tidak akan berfungsi karena node kehabisan memori atau kekurangan daya prosesor. Pada artikel ini, kita akan melihat bagaimana Anda dapat memecahkan masalah kurangnya kapasitas komputer menggunakan permintaan dan pembatasan sumber daya.

Permintaan dan Batas adalah mekanisme yang digunakan Kubernetes untuk mengelola sumber daya seperti prosesor dan memori. Permintaan adalah hasil dimana wadah dijamin untuk menerima sumber daya yang diminta. Jika sebuah wadah meminta sumber daya, Kubernetes hanya akan menjadwalkannya pada host yang dapat menyediakannya. Batas membatasi kontrol bahwa sumber daya yang diminta oleh wadah tidak akan pernah melebihi nilai tertentu.



Wadah hanya dapat meningkatkan daya komputasi hingga batas tertentu, setelah itu akan terbatas. Mari kita lihat cara kerjanya. Jadi, ada dua jenis sumber daya - prosesor dan memori. Penjadwal Kubernetes menggunakan data dari sumber daya ini untuk mencari tahu di mana harus menjalankan pod Anda. Spesifikasi sumber daya perapian yang khas terlihat seperti ini.



Setiap kontainer di pod dapat mengatur kueri dan batasannya sendiri, yang semuanya merupakan tambahan. Sumber daya prosesor didefinisikan dalam milimeter. Jika wadah peluncuran Anda membutuhkan dua inti penuh, Anda menetapkan nilainya menjadi 2000m. Jika wadah hanya membutuhkan daya 1/4 inti, nilainya 250m. Perlu diingat bahwa jika Anda menetapkan nilai sumber daya prosesor lebih besar dari jumlah inti dari simpul terbesar, maka peluncuran perapian Anda tidak akan direncanakan sama sekali. Situasi serupa akan terjadi jika Anda memiliki sub yang membutuhkan empat inti, dan kluster Kubernetes hanya terdiri dari dua mesin virtual utama.

Kecuali jika aplikasi Anda dirancang secara khusus untuk memanfaatkan banyak inti (dengan program seperti komputasi ilmiah yang kompleks dan operasi basis data), praktik terbaik untuk menetapkan Permintaan CPU menjadi 1 atau lebih rendah dan kemudian menjalankan lebih banyak replika untuk skalabilitas. Solusi semacam itu akan memberikan fleksibilitas dan keandalan sistem yang lebih besar.

Ketika datang ke keterbatasan prosesor, hal-hal menjadi lebih menarik karena dianggap sumber daya yang dapat dikompresi. Jika aplikasi Anda mulai mendekati batas kapasitas prosesor, Kubernetes akan mulai memperlambat wadah Anda menggunakan CPU Throttling - menurunkan frekuensi prosesor. Ini berarti bahwa prosesor akan dibatasi secara artifisial, memberikan aplikasi dengan kinerja yang berpotensi lebih buruk, tetapi prosesnya tidak akan dihentikan atau diturunkan.

Sumber daya memori didefinisikan dalam byte. Biasanya, nilai dalam pengaturan diukur dalam Mib mebytes, tetapi Anda dapat menentukan nilai apa pun, dari byte ke petabyte. Di sini situasinya sama dengan CPU - jika Anda menempatkan permintaan untuk jumlah memori yang melebihi jumlah memori pada node Anda, eksekusi pod ini tidak akan dijadwalkan. Tetapi tidak seperti sumber daya prosesor, memori tidak dikompresi, karena tidak ada cara untuk membatasi penggunaannya. Oleh karena itu, eksekusi wadah akan dihentikan segera setelah melampaui batas memori yang dialokasikan untuknya.



Penting untuk diingat bahwa Anda tidak dapat mengonfigurasi permintaan yang melebihi ukuran sumber daya yang dapat disediakan situs Anda. Karakteristik sumber daya bersama untuk mesin virtual GKE dapat ditemukan di tautan yang terletak di bawah video ini.

Di dunia yang ideal, pengaturan wadah default akan cukup untuk alur kerja untuk berjalan lancar. Tetapi dunia nyata tidak seperti itu, orang dapat dengan mudah lupa untuk mengkonfigurasi penggunaan sumber daya atau peretas akan mengatur permintaan dan pembatasan yang melebihi kemampuan nyata dari infrastruktur. Untuk mencegah berkembangnya skenario ini, Anda dapat mengonfigurasi kuota sumber daya ResourceQuota dan rentang batasan LimitRange.

Setelah Anda membuat namespace, Anda dapat memblokirnya dengan kuota. Misalnya, jika Anda memiliki ruang nama prod dan dev, templat digunakan di mana tidak ada kuota produksi sama sekali, dan kuota pengembangan sangat ketat. Hal ini memungkinkan prod dalam hal lompatan tajam dalam lalu lintas untuk mengambil semua sumber daya yang tersedia untuk dirinya sendiri, sepenuhnya memblokir dev.

Kuota sumber daya mungkin terlihat seperti ini. Dalam contoh ini, ada 4 bagian - ini adalah 4 baris kode.



Mari kita lihat masing-masing. Requests.cpu adalah jumlah maksimum permintaan daya prosesor gabungan yang dapat berasal dari semua wadah namespace. Dalam contoh ini, Anda dapat memiliki 50 kontainer dengan permintaan masing-masing 10m, lima kontainer dengan permintaan 100m atau hanya satu kontainer dengan permintaan 500m. Selama jumlah total request.cpu namespace ini kurang dari 500m, semuanya akan baik-baik saja.

Permintaan memori yang diminta. Memori adalah jumlah maksimum permintaan memori gabungan yang dapat dimiliki semua wadah di namespace. Seperti dalam kasus sebelumnya, Anda dapat memiliki 50 kontainer masing-masing 2 mib, lima kontainer masing-masing 20 Mib atau satu wadah dengan 100 Mib hingga jumlah total memori yang diminta dalam namespace kurang dari 100 mebibytes.

Limits.cpu adalah nilai daya prosesor gabungan maksimum yang dapat digunakan oleh semua wadah namespace. Kita dapat mengasumsikan bahwa ini adalah batas permintaan daya prosesor.

Akhirnya, limit.memory adalah jumlah maksimum memori bersama yang dapat digunakan oleh semua kontainer di namespace. Ini adalah batasan total permintaan memori.
Jadi, secara default, kontainer di cluster Kubernetes berfungsi dengan sumber daya komputasi tidak terbatas. Menggunakan kuota sumber daya, administrator gugus dapat membatasi konsumsi sumber daya dan pembuatannya berdasarkan ruang nama. Di namespace, modul pod atau wadah dapat mengkonsumsi CPU dan daya memori sebanyak yang ditentukan kuota sumber daya namespace. Namun, ada kekhawatiran bahwa seseorang di bawah atau sebuah wadah dapat memonopoli semua sumber daya yang tersedia. Untuk mencegah situasi ini, rentang rentang Range digunakan - kebijakan membatasi distribusi sumber daya (untuk pod atau wadah) di namespace.

Rentang batas menyediakan batasan yang dapat:

  • ;
  • Starage Request PersistentVolumeClaim ;
  • Request Limit ;
  • Requests/Limits .

Dengan cara ini Anda bisa membuat rentang batas di namespace Anda. Berbeda dengan kuota yang berlaku untuk seluruh namespace, Batas Rentang digunakan untuk kontainer individu. Ini dapat mencegah pengguna membuat wadah sangat kecil, atau sebaliknya, raksasa di dalam namespace. Rentang Batas mungkin terlihat seperti ini.



Seperti pada kasus sebelumnya, 4 bagian dapat dibedakan di sini. Mari kita lihat masing-masing.
Di bagian default, batasan default ditetapkan untuk wadah di perapian. Jika Anda menentukan nilai-nilai ini dalam rentang batas, maka setiap wadah yang nilai-nilai ini belum ditetapkan secara eksplisit akan dipandu oleh nilai-nilai default.

Di bagian kueri default, defaultRequest, kueri default untuk wadah di perapian dikonfigurasikan. Sekali lagi, jika Anda menetapkan nilai-nilai ini dalam rentang batas, maka setiap wadah yang parameternya tidak diatur secara eksplisit akan menggunakan nilai-nilai ini secara default.

Bagian maks menunjukkan batasan maksimum yang dapat diatur untuk wadah di perapian. Nilai-nilai di bagian default dan pembatasan untuk wadah tidak dapat ditetapkan di atas batas ini. Penting untuk dicatat bahwa jika maks diatur dan bagian default tidak ada, maka nilai maksimum menjadi nilai default.

Bagian min menunjukkan kueri minimum yang dapat ditetapkan untuk wadah di perapian. Pada saat yang sama, nilai-nilai di bagian default dan permintaan untuk wadah tidak dapat ditetapkan di bawah batas ini.

Sekali lagi, penting untuk dicatat bahwa jika nilai ini diatur, nilai default tidak, maka nilai minimum menjadi permintaan default.

Akibatnya, permintaan sumber daya ini digunakan oleh penjadwal Kubernetes untuk mengeksekusi beban kerja Anda. Agar Anda dapat mengkonfigurasi wadah dengan benar, sangat penting untuk memahami cara kerjanya. Misalkan Anda ingin menjalankan beberapa modul di cluster Anda. Dengan asumsi bahwa spesifikasi perapian adalah valid, jadwal Kubernetes akan menggunakan balancing siklik untuk memilih node untuk beban kerja.



Kubernetes akan memeriksa untuk melihat apakah simpul Node 1 memiliki sumber daya yang cukup untuk memenuhi permintaan wadah pod, dan jika tidak, node akan beralih ke simpul berikutnya. Jika tidak ada node dalam sistem yang dapat memenuhi permintaan, pod akan masuk ke status Tertunda. Dengan fitur mesin Google Kubernetes seperti penskalaan otomatis node, GKE dapat secara otomatis menentukan status tunggu dan membuat beberapa node tambahan lainnya.

Jika kemudian ada kelebihan kapasitas node, fungsi penskalaan otomatis akan mengurangi jumlah mereka untuk menghemat uang Anda. Itu sebabnya Kubernetes merencanakan pod berbasis permintaan. Namun, batasnya mungkin lebih tinggi dari permintaan, dan dalam beberapa kasus node mungkin benar-benar kehabisan sumber daya. Kami menyebutnya kondisi overkomitmen negara ini.



Seperti yang saya katakan, jika kita berbicara tentang prosesor, Kubernetes akan mulai membatasi polong. Setiap pod akan menerima sebanyak yang ia minta, tetapi jika pada saat yang sama ia tidak mencapai batas, maka pembatasan akan mulai berlaku.

Mengenai sumber daya memori, di sini Kubernetes dipaksa untuk membuat keputusan tentang pod mana yang akan dihapus dan mana yang akan disimpan sampai Anda membebaskan sumber daya sistem, jika tidak seluruh sistem akan macet.

Mari kita bayangkan sebuah skenario di mana Anda memiliki mesin yang kehabisan memori - bagaimana Kubernetes akan melakukan ini?

Kubernetes akan mencari pod yang menggunakan lebih banyak sumber daya daripada yang diminta. Jadi, jika kontainer Anda tidak memiliki Permintaan sama sekali, itu berarti bahwa secara default mereka menggunakan lebih dari yang mereka minta, hanya karena mereka tidak meminta apa-apa sama sekali! Kontainer seperti itu menjadi kandidat utama penutupan. Kandidat berikutnya adalah kontainer yang telah memenuhi semua permintaan mereka, tetapi masih di bawah batas maksimum.

Jadi jika Kubernetes menemukan beberapa pod yang telah melampaui parameter kueri mereka, itu akan mengurutkannya berdasarkan prioritas, dan kemudian menghapus modul prioritas terendah. Jika semua modul memiliki prioritas yang sama, Kubernetes akan menghentikan pod-pod yang melebihi permintaan mereka lebih dari sisa pod.

Dalam kasus yang sangat jarang, Kubernetes dapat mengganggu perapian yang masih dalam cakupannya. Ini bisa terjadi ketika komponen sistem kritis seperti agen Kubelet atau Docker mulai mengonsumsi lebih banyak sumber daya daripada yang disediakan untuk mereka.
Jadi, pada tahap awal perusahaan kecil, kluster Kubernetes dapat berfungsi dengan baik tanpa menetapkan permintaan dan pembatasan sumber daya, tetapi ketika tim dan proyek Anda mulai bertambah besar, Anda berisiko menghadapi masalah di area ini. Menambahkan pertanyaan dan batasan pada modul dan ruang nama Anda membutuhkan sedikit usaha ekstra dan dapat menghemat banyak kesulitan.

Praktik terbaik Kubernetes. Nonaktifkan Akhiri Nonaktif


Sedikit iklan :)


Terima kasih untuk tetap bersama kami. Apakah Anda suka artikel kami? Ingin melihat materi yang lebih menarik? Dukung kami dengan melakukan pemesanan atau merekomendasikan kepada teman Anda, cloud VPS untuk pengembang dari $ 4,99 , analog unik dari server entry-level yang diciptakan oleh kami untuk Anda: Seluruh kebenaran tentang VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps mulai dari $ 19 atau cara membagi server? (opsi tersedia dengan RAID1 dan RAID10, hingga 24 core dan hingga 40GB DDR4).

Dell R730xd 2 kali lebih murah di pusat data Equinix Tier IV di Amsterdam? Hanya kami yang memiliki 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV dari $ 199 di Belanda!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - mulai dari $ 99! Baca tentang Cara Membangun Infrastruktur Bldg. kelas c menggunakan server Dell R730xd E5-2650 v4 seharga 9.000 euro untuk satu sen?

More articles:


All Articles