Ар бир Kubernetes ресурсу үчүн талаптардын эки түрүн конфигурациялай аласыз - Сурамдар жана Лимиттер. Биринчиси контейнерди же поддонду иштетүү үчүн зарыл болгон эркин түйүн ресурстарынын болушуна минималдуу талаптарды сүрөттөйт, экинчиси контейнерге жеткиликтүү ресурстарды катуу чектейт.
Kubernetes поддондорду пландаштырганда, контейнерлердин туура иштеши үчүн жетиштүү ресурстар болушу абдан маанилүү. Эгер сиз чоң тиркемени ресурстары чектелген түйүндө жайгаштырууну пландап жатсаңыз, ал иштебей калышы мүмкүн, анткени түйүн эстутуму азайып же CPU кубаттуулугу түгөнүп баратат. Бул макалада биз ресурстук суроо-талаптарды жана чектөөлөрдү колдонуу менен эсептөө кубаттуулугунун жетишсиздигин кантип чечсе болорун карап чыгабыз.
Сурамдар жана Лимиттер - бул Kubernetes CPU жана эстутум сыяктуу ресурстарды башкаруу үчүн колдонгон механизмдер. Сурамдар - бул контейнердин суралган ресурсту алуусун камсыз кылган нерсе. Эгер контейнер ресурсту сураса, Kubernetes аны камсыздай турган түйүндө гана пландаштырат. Контейнер сураган ресурстар эч качан белгилүү бир мааниден ашпасын көзөмөлдөөнү чектейт.
Контейнер өзүнүн эсептөө күчүн белгилүү бир чекке чейин гана жогорулата алат, андан кийин ал чектелет. Келгиле, анын кантип иштээрин карап көрөлү. Ошентип, ресурстардын эки түрү бар - процессор жана эс. Kubernetes пландоочусу подколоруңузду кайда иштетүү керектигин аныктоо үчүн бул ресурстар жөнүндө маалыматтарды колдонот. Кап үчүн типтүү ресурстун спецификациясы ушундай көрүнөт.
Подгондогу ар бир контейнер өзүнүн суроо-талаптарын жана чектөөлөрүн орното алат, мунун баары кошумча. Процессордун ресурстары милликор менен аныкталат. Эгерде сиздин контейнериңизди иштетүү үчүн эки толук өзөк керек болсо, анда сиз маанини 2000м деп коюңуз. Эгерде контейнерге өзөктүн 1/4 бөлүгү гана керек болсо, анда анын мааниси 250 м болот. Эң чоң түйүндүн өзөктөрүнүн санынан чоңураак CPU ресурстук маанисин дайындасаңыз, подъездиңиз дегеле башталууга пландаштырылбай турганын унутпаңыз. Эгер сизде төрт ядрону талап кылган Pod болсо жана Kubernetes кластери эки гана негизги виртуалдык машинадан турса, ушундай эле жагдай пайда болот.
Сиздин тиркемеңиз атайын бир нече өзөктөрдүн артыкчылыктарын пайдалануу үчүн иштелип чыкпаса (татаал илимий эсептөө жана маалымат базасы операциялары сыяктуу программалар эске түшөт), анда эң жакшы тажрыйба CPU суроо-талаптарын 1 же андан төмөн кылып коюу жана андан кийин масштабдуулукка көбүрөөк репликаларды иштетүү. Бул чечим системага көбүрөөк ийкемдүүлүк жана ишенимдүүлүк берет.
Процессордун чектөөлөрү жөнүндө сөз болгондо, ал кысылган ресурс болуп эсептелгендиктен, нерселер кызыктуураак болот. Эгер колдонмоңуз процессордун кубаттуулугунун чегине жакындай баштаса, Kubernetes процессордун жыштыгын азайтып, CPU Throttling аркылуу контейнериңизди жайлай баштайт. Бул CPU жасалма түрдө дросселделип, колдонмонун иштөөсүн начарлатат, бирок процесс токтотулбайт же чыгарылбайт дегенди билдирет.
Эстутум ресурстары байт менен аныкталат. Адатта орнотуулардагы маани мебибайт Миб менен өлчөнөт, бирок сиз байттан петабайтка чейин каалаган маанини орното аласыз. Бул жерде процессордогудай эле жагдай колдонулат - эгер сиз түйүндөрүңүздөгү эстутумдун көлөмүнөн чоңураак эстутумга суроо-талапты койсоңуз, анда ал подкасттын аткарылышы пландаштырылбайт. Бирок CPU ресурстарынан айырмаланып, эс кысылган эмес, анткени анын колдонулушун чектөөгө эч кандай жол жок. Демек, контейнердин аткарылышы ал өзүнө бөлүнгөн эстутумдан ашып кеткенден кийин токтойт.
Түйүндөрүңүз камсыздай турган ресурстардан ашкан суроо-талаптарды конфигурациялай албасыңызды эстен чыгарбоо маанилүү. GKE виртуалдык машиналары үчүн жалпы ресурстун спецификацияларын бул видеонун астындагы шилтемелерден тапса болот.
Идеалдуу дүйнөдө контейнердин демейки жөндөөлөрү иш процесстеринин үзгүлтүксүз иштеши үчүн жетиштүү болмок. Бирок чыныгы дүйнө андай эмес, адамдар ресурстарды колдонууну конфигурациялоону оңой эле унутуп коюшу мүмкүн, же хакерлер инфраструктуранын реалдуу мүмкүнчүлүктөрүнөн ашкан суроо-талаптарды жана чектөөлөрдү коюшат. Мындай сценарийлердин алдын алуу үчүн, сиз ResourceQuota жана LimitRange ресурстук квоталарды конфигурациялай аласыз.
Ат мейкиндиги түзүлгөндөн кийин, аны квоталар аркылуу бөгөттөсө болот. Мисалы, эгерде сизде прод жана иштеп чыгуучу аттар мейкиндиктери болсо, анда өндүрүштүк квоталар такыр жок жана өнүктүрүү үчүн абдан катуу квоталар бар. Бул продюсерге трафиктин кескин көбөйүшүнө, иштеп чыгууну толугу менен бөгөттөп, бүт ресурсту ээлеп алууга мүмкүндүк берет.
Ресурстук квота ушундай болушу мүмкүн. Бул мисалда 4 бөлүм бар - бул коддун 4 төмөнкү саптары.
Келгиле, алардын ар бирин карап көрөлү. Requests.cpu - аттар мейкиндигиндеги бардык контейнерлерден келе турган бириктирилген CPU сурамдарынын максималдуу саны. Бул мисалда сизде 50м өтүнүч менен 10 контейнер, 100м өтүнүч менен беш контейнер же 500м өтүнүч менен бир эле контейнер болушу мүмкүн. Берилген аттар мейкиндигиндеги requests.cpu жалпы саны 500мден аз болсо, баары жакшы болот.
Эстутум суралган суроо-талаптар.эс - бул аттар мейкиндигиндеги бардык контейнерлерде болушу мүмкүн болгон бириккен эстутум сурамдарынын максималдуу көлөмү. Мурунку окуядагыдай эле, аттар мейкиндигинде суралган эс тутумдун жалпы көлөмү 50 мебибайттан аз болсо, сизде 2 20 миб контейнер, беш 100 миб контейнер же бир 100 миб контейнер болушу мүмкүн.
Limits.cpu - бул аттар мейкиндигиндеги бардык контейнерлер колдоно ала турган CPU кубаттуулугунун максималдуу жалпы суммасы. Биз муну процессордун кубаттуулугунун суроо-талаптарынын чеги деп эсептесек болот.
Акырында, limits.memory аттар мейкиндигиндеги бардык контейнерлер колдоно ала турган жалпы эстутумдун максималдуу көлөмү. Бул жалпы эстутум суроо-талабы боюнча чектөө болуп саналат.
Ошентип, демейки боюнча, Kubernetes кластериндеги контейнерлер чексиз эсептөө ресурстары менен иштейт. Ресурстук квоталар менен кластердин администраторлору аттар мейкиндигине негизделген ресурстарды керектөөнү жана ресурстарды түзүүнү чектей алышат. Аттар мейкиндигинде поддон же контейнер аттар мейкиндигинин ресурстук квотасы менен аныкталгандай көп CPU күчүн жана эстутумун сарпташы мүмкүн. Бирок, бир поддон же контейнер бардык колдо болгон ресурстарды монополиялап алышы мүмкүн деген кооптонуу бар. Мындай абалдын алдын алуу үчүн чек аралыгы колдонулат - аттар мейкиндигинде ресурстарды (поддор же контейнерлер үчүн) бөлүштүрүүнү чектөө саясаты.
Чек аралыгы төмөнкү чектөөлөрдү берет:
- Ат мейкиндигинде ар бир модул же контейнер үчүн эсептөө ресурстарын минималдуу жана максималдуу пайдаланууну камсыз кылуу;
- ат мейкиндигиндеги ар бир PersistentVolumeClaim үчүн минималдуу жана максималдуу Starage Request сактоо өтүнүчтөрүн ишке ашыруу;
- аттар мейкиндигиндеги ресурс үчүн Суроо менен Лимиттин ортосундагы мамилени бекемдөө;
- аттар мейкиндигинде эсептөө ресурстары үчүн демейки Сурамдарды/Чектерди коюп, аларды автоматтык түрдө иштөө учурунда контейнерлерге сайыңыз.
Ушундай жол менен сиз аттар мейкиндигинде чек аралыгын түзө аласыз. Бүткүл аттар мейкиндигине тиешелүү квотадан айырмаланып, Limit Range жеке контейнерлер үчүн колдонулат. Бул колдонуучулардын аттар мейкиндигинде өтө кичинекей же, тескерисинче, гиганттык контейнерлерди түзүшүнө жол бербейт. Чек аралыгы ушундай көрүнүшү мүмкүн.
Мурунку окуядагыдай эле, бул жерде 4 бөлүмдү айырмалоого болот. Келгиле, ар бирин карап көрөлү.
Демейки бөлүм поддондогу контейнер үчүн демейки чектерди орнотот. Эгер сиз бул маанилерди эң жогорку диапазонго койсоңуз, анда бул баалуулуктар ачык коюлбаган контейнерлер демейки маанилерге ылайык келет.
Демейки суроо-талап бөлүмү defaultRequest поддондогу контейнер үчүн демейки суроо-талаптарды конфигурациялайт. Дагы бир жолу, эгерде сиз бул маанилерди эң жогорку диапазонго койсоңуз, анда бул параметрлерди ачык орнотпогон бардык контейнерлер бул маанилерге демейки болуп калат.
Макс бөлүмү подставадагы контейнер үчүн коюла турган максималдуу чектерди аныктайт. Демейки бөлүмдөгү маанилер жана контейнер чеги бул чектен жогору коюлушу мүмкүн эмес. Белгилей кетчү нерсе, эгер маани макс деп коюлса жана демейки бөлүм жок болсо, анда максималдуу маани демейки мааниге айланат.
Минималдуу бөлүм поддондогу контейнер үчүн коюла турган минималдуу суроо-талаптарды көрсөтөт. Бирок демейки бөлүмдөгү маанилерди жана контейнерге суроо-талаптарды бул чектен төмөн коюуга болбойт.
Дагы бир жолу белгилей кетүү керек, эгерде бул маани коюлса, демейки эмес, анда минималдуу маани демейки чакырык болуп калат.
Бул ресурс суроо-талаптары акыры Kubernetes пландоочусу тарабынан жумуш жүктөмүңүздү аткаруу үчүн колдонулат. Контейнериңизди туура конфигурациялоо үчүн, анын кантип иштээрин түшүнүү абдан маанилүү. Келгиле, сиз кластериңизде бир нече поддонду иштеткиңиз келет дейли. Pod спецификациялары жарактуу деп эсептесек, Kubernetes графиги жумуш жүгүн иштетүү үчүн түйүндү тандоо үчүн тегерек балансты колдонот.
Kubernetes 1 түйүнүндө под контейнерлердин суроо-талаптарын аткаруу үчүн жетиштүү ресурстары бар-жогун текшерет, ал эми ал жок болсо, кийинки түйүнгө өтөт. Эгерде тутумдагы түйүндөрдүн бири да суроо-талаптарды канааттандыра албаса, анда подъезддер Күтүүдөгү абалга өтөт. Google Kubernetes кыймылдаткычынын түйүндөрдүн авто масштабы сыяктуу функцияларын колдонуу менен, GKE күтүү абалын автоматтык түрдө аныктап, дагы бир нече кошумча түйүндөрдү түзө алат.
Эгер сиз кийинчерээк түйүн сыйымдуулугуңуз түгөнүп калса, автоматтык масштабдоо акчаңызды үнөмдөө үчүн түйүндөрдүн санын азайтат. Ошондуктан Kubernetes суроо-талаптардын негизинде подкасттарды пландаштырат. Бирок, чектөө суроо-талаптарга караганда жогору болушу мүмкүн, ал эми кээ бир учурларда түйүн чынында ресурстары түгөнүп калышы мүмкүн. Биз бул мамлекеттик милдеттенмени мамлекет деп атайбыз.
Мен айткандай, CPU жөнүндө сөз болгондо, Kubernetes поддондорду чектей баштайт. Ар бир поддон талап кылынган көлөмдө алат, бирок ал чекке жетпесе, дроссель колдонула баштайт.
Эстутум ресурстарына келгенде, Кубернетес тутум ресурстарын бошотмоюнча кайсы подкасттарды жок кылуу жана кайсынысын сактоо жөнүндө чечим кабыл алууга аргасыз болот, болбосо тутумдун баары бузулат.
Келиңиз, сизде машинанын эс тутуму түгөнүп калган сценарийди элестетип көрөлү - Кубернетес муну кантип чечет?
Kubernetes алар сурагандан көбүрөөк ресурстарды колдонуп жаткан поддондорду издейт. Демек, эгерде сиздин контейнерлериңизде эч кандай Сурамдар жок болсо, бул алар сурагандан көптү демейки түрдө колдонбойт дегенди билдирет, анткени алар эч нерсе сурабагандыктан! Мындай контейнерлер жабылууга негизги талапкер болуп калышат. Кийинки талапкерлер бардык суроо-талаптарын канааттандырган, бирок дагы эле максималдуу чектен төмөн контейнерлер.
Ошентип, эгерде Kubernetes алардын сурамынын параметрлеринен ашкан бир нече поддондорду тапса, аларды артыкчылыктары боюнча иреттеп, андан соң эң төмөнкү артыкчылыктуу подкасттарды алып салат. Эгерде баардык поддондор бирдей артыкчылыкка ээ болсо, анда Kubernetes башка поддондорго караганда алардын суроо-талаптарынан ашкан подряддарды токтотот.
Өтө сейрек учурларда, Kubernetes дагы эле алардын суроо-талаптарынын чегинде болгон поддондорду токтотушу мүмкүн. Бул Kubelet агенти же Docker сыяктуу системанын маанилүү компоненттери алар үчүн сакталган ресурстардан көбүрөөк ресурстарды керектей баштаганда болушу мүмкүн.
Ошентип, чакан компаниялардын алгачкы этаптарында Kubernetes кластери ресурстук суроо-талаптарды жана чектөөлөрдү койбостон жакшы иштей алат, бирок сиздин командаларыңыз жана долбоорлоруңуз чоңоюп баштаганда, бул чөйрөдө көйгөйлөргө туш болуу коркунучу бар. Модулдарыңызга жана аттар мейкиндиктериңизге суроо-талаптарды жана чектөөлөрдү кошуу өтө аз кошумча күч-аракетти талап кылат жана көп түйшүктөн куткара алат.
Кээ бир жарнамалар 🙂
Биз менен болгонуңуз үчүн рахмат. Биздин макалалар сизге жагабы? Көбүрөөк кызыктуу мазмунду көргүңүз келеби? Буйрутма берүү же досторуңузга сунуштоо менен бизди колдоңуз, , биз сиз үчүн ойлоп тапкан баштапкы деңгээлдеги серверлердин уникалдуу аналогу: (RAID1 жана RAID10 менен жеткиликтүү, 24 өзөккө чейин жана 40 ГБ DDR4 чейин).
Dell R730xd Амстердамдагы Equinix Tier IV маалымат борборунда 2 эсе арзанбы? Бул жерде гана Нидерландыда! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 доллардан! Жөнүндө окуу
Source: www.habr.com