Untuk setiap sumber Kubernetes, anda boleh mengkonfigurasi dua jenis keperluan - Permintaan dan Had. Yang pertama menerangkan keperluan minimum untuk ketersediaan sumber nod percuma yang diperlukan untuk menjalankan bekas atau pod, yang kedua mengehadkan dengan ketat sumber yang tersedia untuk bekas.
Apabila Kubernetes menjadualkan pod, adalah sangat penting bahawa bekas mempunyai sumber yang mencukupi untuk berfungsi dengan betul. Jika anda merancang untuk menggunakan aplikasi besar pada nod yang dikekang sumber, ada kemungkinan ia tidak akan dijalankan kerana nod itu kehabisan memori atau kehabisan kuasa CPU. Dalam artikel ini, kami akan melihat cara anda boleh menyelesaikan kekurangan kuasa pengkomputeran menggunakan permintaan dan had sumber.
Permintaan dan Had ialah mekanisme yang Kubernetes gunakan untuk mengurus sumber seperti CPU dan memori. Permintaan ialah perkara yang memastikan bekas menerima sumber yang diminta. Jika kontena meminta sumber, Kubernetes hanya akan menjadualkannya pada nod yang boleh menyediakannya. Had kawalan bahawa sumber yang diminta oleh bekas tidak akan melebihi nilai tertentu.
Bekas hanya boleh meningkatkan kuasa pengkomputerannya sehingga had tertentu, selepas itu ia akan dihadkan. Mari lihat bagaimana ia berfungsi. Jadi, terdapat dua jenis sumber - pemproses dan memori. Penjadual Kubernetes menggunakan data tentang sumber ini untuk mengetahui tempat untuk menjalankan pod anda. Spesifikasi sumber biasa untuk pod kelihatan seperti ini.
Setiap bekas dalam pod boleh menetapkan pertanyaan dan hadnya sendiri, semuanya bersifat tambahan. Sumber pemproses ditakrifkan dalam milicore. Jika bekas anda memerlukan dua teras penuh untuk dijalankan, anda menetapkan nilai kepada 2000m. Jika bekas hanya memerlukan kuasa 1/4 daripada teras, nilainya ialah 250m. Perlu diingat bahawa jika anda menetapkan nilai sumber CPU lebih besar daripada bilangan teras nod terbesar, pod anda tidak akan dijadualkan untuk bermula sama sekali. Situasi yang sama akan berlaku jika anda mempunyai Pod yang memerlukan empat teras, dan kelompok Kubernetes hanya terdiri daripada dua mesin maya utama.
Melainkan aplikasi anda direka khusus untuk memanfaatkan berbilang teras (program seperti pengkomputeran saintifik yang kompleks dan operasi pangkalan data terlintas di fikiran), maka amalan terbaik ialah menetapkan Permintaan CPU kepada 1 atau lebih rendah dan kemudian menjalankan lebih banyak replika kepada skalabiliti. Penyelesaian ini akan memberikan sistem fleksibiliti dan kebolehpercayaan yang lebih besar.
Apabila bercakap tentang had CPU, perkara menjadi lebih menarik kerana ia dianggap sebagai sumber boleh mampat. Jika aplikasi anda mula menghampiri had kuasa pemproses, Kubernetes akan mula memperlahankan bekas anda menggunakan CPU Throttling - mengurangkan kekerapan pemproses. Ini bermakna CPU akan didikit secara buatan, memberikan aplikasi berpotensi prestasi yang lebih teruk, tetapi proses itu tidak akan ditamatkan atau ranap.
Sumber memori ditakrifkan dalam bait. Biasanya nilai dalam tetapan diukur dalam mebibait Mib, tetapi anda boleh menetapkan sebarang nilai, daripada bait kepada petabait. Keadaan yang sama berlaku di sini seperti dengan CPU - jika anda membuat permintaan untuk jumlah memori yang lebih besar daripada jumlah memori pada nod anda, pod itu tidak akan dijadualkan untuk dilaksanakan. Tetapi tidak seperti sumber CPU, memori tidak dimampatkan kerana tidak ada cara untuk mengehadkan penggunaannya. Oleh itu, pelaksanaan kontena akan dihentikan sebaik sahaja ia melampaui memori yang diperuntukkan kepadanya.
Adalah penting untuk diingat bahawa anda tidak boleh mengkonfigurasi permintaan yang melebihi sumber yang boleh disediakan oleh nod anda. Spesifikasi sumber yang dikongsi untuk mesin maya GKE boleh didapati dalam pautan di bawah video ini.
Dalam dunia yang ideal, tetapan lalai bekas akan mencukupi untuk memastikan aliran kerja berjalan lancar. Tetapi dunia sebenar tidak seperti itu, orang ramai boleh dengan mudah lupa untuk mengkonfigurasi penggunaan sumber, atau penggodam akan menetapkan permintaan dan sekatan yang melebihi keupayaan sebenar infrastruktur. Untuk mengelakkan senario sedemikian daripada berlaku, anda boleh mengkonfigurasi kuota sumber ResourceQuota dan LimitRange.
Setelah ruang nama telah dibuat, ia boleh disekat menggunakan kuota. Sebagai contoh, jika anda mempunyai ruang nama prod dan dev, coraknya ialah tiada kuota pengeluaran sama sekali dan kuota pembangunan yang sangat ketat. Ini membolehkan prod, sekiranya berlaku lonjakan mendadak dalam trafik, mengambil alih keseluruhan sumber yang ada, menyekat sepenuhnya pembangun.
Kuota sumber mungkin kelihatan seperti ini. Dalam contoh ini terdapat 4 bahagian - ini adalah 4 baris bawah kod.
Mari lihat setiap daripada mereka. Requests.cpu ialah bilangan maksimum permintaan CPU gabungan yang boleh datang daripada semua bekas dalam ruang nama. Dalam contoh ini, anda boleh mempunyai 50 bekas dengan permintaan 10m, lima kontena dengan permintaan 100m, atau hanya satu kontena dengan permintaan 500m. Selagi jumlah bilangan requests.cpu ruang nama yang diberikan adalah kurang daripada 500m, semuanya akan baik-baik saja.
Permintaan memori yang diminta.memori ialah jumlah maksimum permintaan memori gabungan yang boleh dimiliki oleh semua bekas dalam ruang nama. Seperti dalam kes sebelumnya, anda boleh mempunyai 50 bekas 2 mib, lima bekas 20 mib atau satu bekas 100 mib asalkan jumlah memori yang diminta dalam ruang nama kurang daripada 100 mebibait.
Limits.cpu ialah jumlah gabungan maksimum kuasa CPU yang boleh digunakan oleh semua bekas dalam ruang nama. Kami boleh menganggap ini sebagai had permintaan kuasa pemproses.
Akhir sekali, limits.memory ialah jumlah maksimum memori kongsi yang boleh digunakan oleh semua bekas dalam ruang nama. Ini adalah had pada jumlah permintaan memori.
Jadi, secara lalai, bekas dalam gugusan Kubernetes dijalankan dengan sumber pengiraan tanpa had. Dengan kuota sumber, pentadbir kluster boleh mengehadkan penggunaan sumber dan penciptaan sumber berdasarkan ruang nama. Dalam ruang nama, pod atau bekas boleh menggunakan kuasa CPU dan memori sebanyak yang ditentukan oleh kuota sumber ruang nama. Walau bagaimanapun, terdapat kebimbangan bahawa satu pod atau bekas boleh memonopoli semua sumber yang ada. Untuk mengelakkan keadaan ini, julat had digunakan - dasar untuk mengehadkan peruntukan sumber (untuk pod atau bekas) dalam ruang nama.
Julat had menyediakan sekatan yang boleh:
- Memastikan penggunaan minimum dan maksimum sumber pengkomputeran untuk setiap modul atau bekas dalam ruang nama;
- menguatkuasakan permintaan storan Permintaan Starage minimum dan maksimum untuk setiap PersistentVolumeClaim dalam ruang nama;
- menguatkuasakan hubungan antara Permintaan dan Had untuk sumber dalam ruang nama;
- tetapkan Permintaan/Had lalai untuk sumber pengiraan dalam ruang nama dan secara automatik menyuntiknya ke dalam bekas semasa masa jalan.
Dengan cara ini anda boleh membuat julat had dalam ruang nama anda. Tidak seperti kuota, yang digunakan untuk keseluruhan ruang nama, Julat Had digunakan untuk bekas individu. Ini boleh menghalang pengguna daripada mencipta bekas yang sangat kecil atau, sebaliknya, gergasi dalam ruang nama. Julat Had mungkin kelihatan seperti ini.
Seperti dalam kes sebelumnya, 4 bahagian boleh dibezakan di sini. Mari lihat setiap satu.
Bahagian lalai menetapkan had lalai untuk bekas dalam pod. Jika anda menetapkan nilai ini kepada julat melampau, maka mana-mana bekas yang nilai ini belum ditetapkan secara eksplisit akan mengikut nilai lalai.
Bahagian permintaan lalai defaultRequest mengkonfigurasi permintaan lalai untuk bekas dalam pod. Sekali lagi, jika anda menetapkan nilai ini kepada julat melampau, maka mana-mana bekas yang tidak menetapkan pilihan ini secara eksplisit akan lalai kepada nilai ini.
Bahagian maks menentukan had maksimum yang boleh ditetapkan untuk bekas dalam pod. Nilai dalam bahagian lalai dan had bekas tidak boleh ditetapkan melebihi had ini. Adalah penting untuk ambil perhatian bahawa jika nilai ditetapkan kepada maks dan tiada bahagian lalai, maka nilai maksimum menjadi nilai lalai.
Bahagian min menentukan permintaan minimum yang boleh ditetapkan untuk bekas dalam pod. Walau bagaimanapun, nilai dalam bahagian lalai dan pertanyaan untuk bekas tidak boleh ditetapkan di bawah had ini.
Sekali lagi, adalah penting untuk ambil perhatian bahawa jika nilai ini ditetapkan, lalai tidak, maka nilai minimum menjadi gesaan lalai.
Permintaan sumber ini akhirnya digunakan oleh penjadual Kubernetes untuk melaksanakan beban kerja anda. Untuk anda mengkonfigurasi bekas anda dengan betul, adalah sangat penting untuk memahami cara ia berfungsi. Katakan anda mahu menjalankan berbilang pod dalam kelompok anda. Dengan mengandaikan spesifikasi pod adalah sah, jadual Kubernetes akan menggunakan pengimbangan round robin untuk memilih nod untuk menjalankan beban kerja.
Kubernetes akan menyemak sama ada Node 1 mempunyai sumber yang mencukupi untuk memenuhi permintaan daripada bekas pod, dan jika tidak, ia akan beralih ke nod seterusnya. Jika tiada nod dalam sistem dapat memenuhi permintaan, pod akan masuk ke dalam keadaan Belum Selesai. Menggunakan ciri enjin Google Kubernetes seperti penskalaan automatik nod, GKE boleh mengesan keadaan menunggu secara automatik dan membuat beberapa lagi nod tambahan.
Jika anda kehabisan kapasiti nod kemudiannya, penskalaan automatik akan mengurangkan bilangan nod untuk menjimatkan wang anda. Inilah sebabnya mengapa Kubernetes menjadualkan pod berdasarkan permintaan. Walau bagaimanapun, had mungkin lebih tinggi daripada permintaan, dan dalam beberapa kes, nod mungkin benar-benar kehabisan sumber. Kami memanggil keadaan ini sebagai keadaan terlalu komited.
Seperti yang saya katakan, apabila ia datang kepada CPU, Kubernetes akan mula mengehadkan pod. Setiap pod akan menerima sebanyak yang diminta, tetapi jika ia tidak mencapai had, pendikitan akan mula digunakan.
Mengenai sumber memori, Kubernetes terpaksa membuat keputusan tentang pod mana yang hendak dipadamkan dan mana yang perlu disimpan sehingga anda mengosongkan sumber sistem atau keseluruhan sistem akan ranap.
Mari bayangkan senario di mana anda mempunyai mesin kehabisan memori - bagaimanakah Kubernetes akan mengendalikannya?
Kubernetes akan mencari pod yang menggunakan lebih banyak sumber daripada yang mereka minta. Jadi jika bekas anda tidak mempunyai Permintaan sama sekali, ini bermakna mereka lalai untuk menggunakan lebih daripada yang mereka minta, semata-mata kerana mereka tidak meminta apa-apa langsung! Bekas sedemikian menjadi calon utama untuk ditutup. Calon seterusnya adalah kontena yang telah memenuhi semua permintaan mereka tetapi masih di bawah had maksimum.
Jadi jika Kubernetes menemui beberapa pod yang telah melebihi parameter permintaan mereka, ia akan mengisihnya mengikut keutamaan dan kemudian mengalih keluar pod keutamaan terendah. Jika semua pod mempunyai keutamaan yang sama, maka Kubernetes akan menamatkan pod tersebut yang melebihi permintaan mereka lebih daripada pod lain.
Dalam kes yang sangat jarang berlaku, Kubernetes mungkin membatalkan pod yang masih dalam skop permintaan mereka. Ini boleh berlaku apabila komponen sistem kritikal seperti ejen Kubelet atau Docker mula menggunakan lebih banyak sumber daripada apa yang dikhaskan untuk mereka.
Jadi, pada peringkat awal syarikat kecil, kluster Kubernetes boleh berfungsi dengan baik tanpa menetapkan permintaan dan sekatan sumber, tetapi apabila pasukan dan projek anda mula berkembang dalam saiz, anda menghadapi risiko menghadapi masalah dalam bidang ini. Menambah pertanyaan dan kekangan pada modul dan ruang nama anda memerlukan sedikit usaha tambahan dan boleh menjimatkan banyak kerumitan.
Beberapa iklan π
Terima kasih kerana tinggal bersama kami. Adakah anda suka artikel kami? Ingin melihat kandungan yang lebih menarik? Sokong kami dengan membuat pesanan atau mengesyorkan kepada rakan, , analog unik pelayan peringkat permulaan, yang kami cipta untuk anda: (tersedia dengan RAID1 dan RAID10, sehingga 24 teras dan sehingga 40GB DDR4).
Dell R730xd 2 kali 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 - daripada $99! Baca tentang
Sumber: www.habr.com