Бөлінген жүйелердің жұмысындағы маңызды сәт сәтсіздіктерді өңдеу болып табылады. Кубернетес жүйенің күйін қадағалайтын контроллерлерді пайдалану және жұмысын тоқтатқан қызметтерді қайта іске қосу арқылы көмектеседі. Дегенмен, Kubernetes жүйенің жалпы денсаулығын қамтамасыз ету үшін қолданбаларды күшпен тоқтата алады. Бұл серияда біз Kubernetes-ке жұмысын тиімдірек орындауға және қолданбаның тоқтап қалу уақытын азайтуға қалай көмектесуге болатынын қарастырамыз.
Контейнерлерге дейін қолданбалардың көпшілігі виртуалды немесе физикалық машиналарда жұмыс істеді. Қолданба бұзылса немесе қатып қалса, орындалып жатқан тапсырмадан бас тартуға және бағдарламаны қайта жүктеуге көп уақыт қажет болды. Ең нашар жағдайда, біреу бұл мәселені түнде, ең қолайлы емес сағаттарда қолмен шешуге мәжбүр болды. Маңызды тапсырманы тек 1-2 жұмыс машинасы орындаса, мұндай бұзылу мүлдем мүмкін емес еді.
Сондықтан, қолмен қайта жүктеудің орнына, олар әдеттен тыс тоқтатылған жағдайда қолданбаны автоматты түрде қайта іске қосу үшін процесс деңгейіндегі бақылауды пайдалана бастады. Бағдарлама сәтсіз болса, бақылау процесі шығу кодын жазып алады және серверді қайта жүктейді. Kubernetes сияқты жүйелердің пайда болуымен жүйе ақауларына жауап берудің бұл түрі жай ғана инфрақұрылымға біріктірілді.
Кубернетес ресурстардың контейнерлерден түйіндерге өту кезінде олардың сау болып қалуын қамтамасыз ету үшін бақылау-айырмашылық-әрекет ету оқиғасының циклін пайдаланады.
Бұл процесс мониторингін қолмен іске қосудың қажеті жоқ дегенді білдіреді. Егер ресурс денсаулықты тексеруден өтпесе, Kubernetes оны автоматты түрде ауыстырумен қамтамасыз етеді. Дегенмен, Kubernetes қолданбаңызды сәтсіздікке бақылап қана қоймайды. Ол бірнеше машиналарда іске қосу үшін қолданбаның көбірек көшірмелерін жасай алады, қолданбаны жаңартады немесе қолданбаның бірнеше нұсқасын бір уақытта іске қоса алады.
Сондықтан, Кубернетес сау контейнерді тоқтата алатын көптеген себептер бар. Мысалы, орналастыруды жаңартсаңыз, Kubernetes жаңаларын іске қосу кезінде ескі қосқыштарды баяу тоқтатады. Егер сіз түйінді өшірсеңіз, Kubernetes сол түйіндегі барлық қосқыштарды іске қосуды тоқтатады. Ақырында, егер түйінде ресурстар таусылып қалса, Kubernetes сол ресурстарды босату үшін барлық подкасттарды өшіреді.
Сондықтан, қолданбаңыздың соңғы пайдаланушыға ең аз әсер етуі және қалпына келтіру уақыты аз болуы өте маңызды. Бұл өшіру алдында ол сақталуы қажет барлық деректерді сақтауы, барлық желілік қосылымдарды жабуы, қалған жұмыстарды аяқтауы және басқа шұғыл тапсырмаларды басқаруы керек дегенді білдіреді.
Іс жүзінде бұл сіздің қолданбаңыз Unix операциялық жүйелеріндегі өлтіру утилитасы үшін әдепкі сигнал болып табылатын процесті тоқтату сигналы болып табылатын SIGTERM хабарламасын өңдей алуы керек дегенді білдіреді. Бұл хабарды алғаннан кейін қолданба жабылуы керек.
Кубернетес подкастты тоқтатуды шешкеннен кейін, бірқатар оқиғалар орын алады. Кубернетес контейнерді немесе подводты өшірген кезде жасайтын әрбір қадамды қарастырайық.
Бөлшектердің бірін тоқтатқымыз келеді делік. Осы сәтте ол жаңа трафикті қабылдауды тоқтатады - подкастта жұмыс істейтін контейнерлерге әсер етпейді, бірақ барлық жаңа трафик бұғатталады.
PreStop ілмегін қарастырайық, ол арнайы пәрмен немесе подкасттағы контейнерлерге жіберілетін HTTP сұрауы. SIGTERM алған кезде қолданбаңыз дұрыс жабылмаса, дұрыс өшіру үшін preStop функциясын пайдалануға болады.
Бағдарламалардың көпшілігі SIGTERM сигналын алған кезде керемет түрде шығады, бірақ егер сіз үшінші тарап кодын немесе толық бақылай алмайтын жүйені пайдалансаңыз, preStop ілгегі қолданбаны өзгертпестен керемет өшіруді мәжбүрлеудің тамаша тәсілі болып табылады.
Осы ілгекті орындағаннан кейін Кубернетес контейнерлерге SIGTERM сигналын жіберіп, олардың жақын арада ажыратылатынын хабарлайды. Бұл сигналды алғаннан кейін сіздің кодыңыз өшіру процесіне көшеді. Бұл процесс дерекқор қосылымы немесе WebSocket ағыны сияқты кез келген ұзақ өмір сүретін қосылымдарды тоқтатуды, ағымдағы күйді сақтауды және т.б. қамтуы мүмкін.
PreStop ілмегін пайдалансаңыз да, SIGTERM сигналын жіберген кезде қолданбаңызбен нақты не болатынын және оның қалай әрекет ететінін тексеру өте маңызды, осылайша подключтің өшірілуінен туындаған оқиғалар немесе жүйе жұмысындағы өзгерістер келесідей келмеуі үшін. саған тосын сый.
Осы кезде Kubernetes әрі қарай әрекет етуден бұрын terminationGracePeriodSecond деп аталатын белгілі бір уақытты немесе SIGTERM сигналын алған кезде жақсы өшіру кезеңін күтеді.
Әдепкі бойынша бұл кезең 30 секунд. Оның preStop ілгегімен және SIGTERM сигналымен параллель жұмыс істейтінін ескеру маңызды. Kubernetes preStop ілгегі мен SIGTERM аяқталуын күтпейді — егер қолданбаңыз TerminationGracePeriod аяқталмай тұрып шықса, Kubernetes бірден келесі қадамға көшеді. Сондықтан осы кезеңнің секундтардағы мәні подкастты дұрыс өшіру үшін қажетті уақыттан кем емес екенін тексеріңіз, ал егер ол 30 секундтан асса, кезеңді YAML ішіндегі қажетті мәнге дейін арттырыңыз. Келтірілген мысалда ол 60-ты құрайды.
Соңында, соңғы қадам - егер контейнерлер terminationGracePeriod аяқталғаннан кейін жұмыс істеп тұрса, олар SIGKILL сигналын жібереді және мәжбүрлеп жойылады. Осы кезде Кубернетес барлық басқа подкаст нысандарын да тазартады.
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