Бөлінген жүйелерді басқару қиын болуы мүмкін, себебі оларда жүйенің жұмыс істеуі үшін дұрыс жұмыс істеуі қажет көптеген қозғалатын, өзгеретін элементтер бар. Элементтердің бірі істен шыққан жағдайда жүйе оны анықтап, айналып өтіп, түзетуі керек және мұның барлығы автоматты түрде орындалуы керек. Бұл Kubernetes үздік тәжірибелері сериясында біз Kubernetes кластерінің денсаулығын тексеру үшін Дайындық пен жандылық сынақтарын орнату жолын үйренеміз.
Денсаулықты тексеру жүйеге қолданба данасы іске қосылғанын немесе жұмыс істемейтінін білуге мүмкіндік беретін қарапайым әдіс. Қолданба данасы өшірілген болса, басқа қызметтер оған қол жеткізбеуі немесе оған сұрау жібермеуі керек. Оның орнына сұрау бұрыннан іске қосылған немесе кейінірек іске қосылатын қолданбаның басқа данасына жіберілуі керек. Бұған қоса, жүйе қолданбаңыздың жоғалған функционалдығын қалпына келтіруі керек.
Әдепкі бойынша, Kubernetes подкасттағы барлық контейнерлер жұмыс істеп тұрған кезде трафикті подкастқа жібере бастайды және олар бұзылған кезде контейнерлерді қайта жүктейді. Бұл әдепкі жүйе әрекеті бастау үшін жеткілікті жақсы болуы мүмкін, бірақ реттелетін ақыл-ой тексерулерін пайдалану арқылы өнімді орналастырудың сенімділігін жақсартуға болады.
Бақытымызға орай, Кубернетес мұны өте оңай етеді, сондықтан бұл тексерулерді елемеу үшін ешқандай ақтау жоқ. Kubernetes денсаулық тексерулерінің екі түрін ұсынады және олардың әрқайсысын пайдаланудағы айырмашылықтарды түсіну маңызды.
Дайындық сынағы Kubernetes қолданбаңыздың трафикті өңдеуге дайын екенін айту үшін жасалған. Қызметке трафикті подкастқа жіберуге рұқсат бермес бұрын, Кубернетес дайындықты тексеру сәтті өткенін тексеруі керек. Дайындық сынағы сәтсіз аяқталса, Кубернетес сынақтан өткенше трафикті подкастқа жіберуді тоқтатады.
Тірілік сынағы Kubernetes-ке қолданбаңыздың тірі немесе өлі екенін айтады. Бірінші жағдайда Кубернетес оны жалғыз қалдырады, екіншісінде ол өлі қабықты жояды және оны жаңасымен ауыстырады.
Қолданбаны қыздырып, іске қосу үшін 1 минут қажет болатын сценарийді елестетіп көрейік. Жұмыс процесі әлдеқашан басталғанымен, қолданба толығымен жүктелмейінше және іске қосылмайынша қызметіңіз жұмыс істемейді. Бұл орналастыруды бірнеше көшірмеге дейін кеңейткіңіз келсе, сізде де проблемалар болады, себебі бұл көшірмелер толығымен дайын болғанша трафикті қабылдамауы керек. Дегенмен, әдепкі бойынша, Кубернетес контейнер ішіндегі процестер басталған кезде трафикті жібере бастайды.
Дайындық сынағын пайдаланған кезде, Kubernetes қызметке трафикті жаңа көшірмеге жіберуге рұқсат бермес бұрын қолданба толығымен іске қосылғанша күтеді.
Қолданба ұзақ уақыт бойы сұрауларға қызмет көрсетуді тоқтататын басқа сценарийді елестетіп көрейік. Процесс жалғасуда, әдепкі бойынша Kubernetes барлығы жақсы деп есептейді және жұмыс істемейтін подводқа сұрауларды жіберуді жалғастырады. Бірақ Liveness пайдаланған кезде, Kubernetes қолданбаның бұдан былай сұрауларға қызмет көрсетпейтінін анықтайды және әдепкі бойынша өлі қосқышты қайта іске қосады.
Дайындық пен өміршеңдік қалай тексерілетінін қарастырайық. Тестілеудің үш әдісі бар - HTTP, Пәрмен және TCP. Тексеру үшін олардың кез келгенін пайдалануға болады. Пайдаланушыны тексерудің ең көп тараған жолы HTTP тексеруі болып табылады.
Қолданбаңыз HTTP сервері болмаса да, Liveness сынағымен әрекеттесу үшін қолданбаның ішінде жеңіл HTTP серверін жасай аласыз. Осыдан кейін Кубернетес подкастқа пинг жасай бастайды және HTTP жауабы 200 немесе 300 мс диапазонында болса, бұл подкасттың сау екенін көрсетеді. Әйтпесе, модуль «сау емес» деп белгіленеді.
Пәрмен сынақтары үшін Kubernetes пәрменді контейнеріңіздің ішінде іске қосады. Егер пәрмен нөлдік шығу кодымен оралса, онда контейнер сау деп белгіленеді, әйтпесе 1-ден 255-ке дейінгі шығу күйінің нөмірін алған кезде контейнер «ауру» деп белгіленеді. Бұл сынақ әдісі HTTP серверін іске қоса алмасаңыз немесе қосқыңыз келмесе, бірақ қолданбаңыздың жұмысын тексеретін пәрменді іске қоса алатын болсаңыз пайдалы.
Соңғы тексеру механизмі TCP тесті болып табылады. Кубернетес көрсетілген портта TCP қосылымын орнатуға тырысады. Егер мұны істеу мүмкін болса, контейнер сау болып саналады, егер олай болмаса, ол өмір сүруге жарамсыз болып саналады. Бұл әдіс HTTP сұрауымен немесе пәрменді орындаумен тестілеу өте жақсы жұмыс істемейтін сценарийді пайдалансаңыз пайдалы болуы мүмкін. Мысалы, TCP көмегімен тексеруге арналған негізгі қызметтер gRPC немесе FTP болады.
Сынақтарды әртүрлі параметрлермен бірнеше жолмен конфигурациялауға болады. Оларды қаншалықты жиі орындау керектігін, сәттілік пен сәтсіздік шектері қандай екенін және жауаптарды қанша уақыт күту керектігін көрсетуге болады. Қосымша ақпарат алу үшін Дайындық және өмір сүру сынақтарының құжаттамасын қараңыз. Дегенмен, Liveness тестін орнатудың бір маңызды сәті бар - тестілеу кешігуінің initialDelaySeconds бастапқы параметрі. Жоғарыда айтқанымдай, бұл сынақтың сәтсіздігі модульдің қайта іске қосылуына әкеледі. Сондықтан қолданба жұмысқа дайын болғанша тестілеу басталмайтынына көз жеткізуіңіз керек, әйтпесе ол қайта іске қосу арқылы циклді бастайды. Мен P99 іске қосу уақытын немесе буфердегі қолданбаның орташа іске қосылу уақытын пайдалануды ұсынамын. Қолданбаның іске қосылу уақыты жылдамырақ немесе баяулаған сайын бұл мәнді реттеуді ұмытпаңыз.
Көптеген сарапшылар Health Checks кез келген таратылған жүйе үшін міндетті тексеру екенін растайды және Kubernetes ерекшелік емес. Қызметтің денсаулығын тексеруді пайдалану Kubernetes сенімді, ақаусыз жұмысын қамтамасыз етеді және пайдаланушылар үшін оңай.
Жақында жалғасын табады...
Кейбір жарнамалар 🙂
Бізбен бірге болғандарыңызға рахмет. Сізге біздің мақалалар ұнайды ма? Қызықты мазмұнды көргіңіз келе ме? Тапсырыс беру немесе достарыңызға ұсыну арқылы бізге қолдау көрсетіңіз, , Сіз үшін біз ойлап тапқан бастапқы деңгейдегі серверлердің бірегей аналогы: (RAID1 және RAID10, 24 ядроға дейін және 40 ГБ DDR4 дейін қол жетімді).
Dell R730xd Амстердамдағы Equinix Tier IV деректер орталығында 2 есе арзан ба? Тек осында Нидерландыда! Dell R420 - 2x E5-2430 2.2 ГГц 6C 128 ГБ DDR3 2x960 ГБ SSD 1 Гбит/с 100 ТБ - 99 доллардан бастап! туралы оқыңыз
Ақпарат көзі: www.habr.com