Бүгін мен қосымшаларды қалай жазу керек және Kubernetes-те жақсы жұмыс істеу үшін сіздің қосымшаңызға қойылатын талаптар туралы сөйлесуді жоспарлап отырмын. Қолданбаның бас ауруы болмауы үшін, оның айналасында ешқандай «сызаттар» ойлап табудың және салудың қажеті жоқ - және бәрі Кубернетестің өзі ойлағандай жұмыс істейді.
Бұл дәріс «" Кешкі мектептің ашық теориялық дәрістерін көруге болады . Бейнеден гөрі мәтінді ұнататындар үшін біз бұл мақаланы дайындадық.
Менің атым Павел Селиванов, қазір мен Mail.ru Cloud Solutions компаниясының жетекші DevOps инженерімін, біз бұлт жасаймыз, басқару кубернеттерін жасаймыз және т.б. Енді менің міндеттеріме әзірлеуге көмектесу, осы бұлттарды шығару, біз жазатын қолданбаларды шығару және пайдаланушыларымызға ұсынатын құралдарды тікелей әзірлеу кіреді.
Мен DevOps жасап жатырмын, менің ойымша, соңғы, мүмкін, үш жыл. Бірақ, негізінен, мен DevOps жасайтын нәрсені шамамен бес жыл бойы істеп келемін. Бұған дейін мен көбіне админ істерімен айналысатынмын. Мен Кубернетеспен ұзақ уақыт бұрын жұмыс істей бастадым - онымен жұмыс істей бастағаныма төрт жылдай уақыт өткен шығар.
Жалпы, мен Кубернетес 1.3 нұсқасы болған кезде бастадым, бәлкім, және мүмкін 1.2 - ол әлі нәресте кезінде. Қазір ол бастапқы кезеңде емес - және Кубернетеспен айналысқысы келетін инженерлерге нарықта үлкен сұраныс бар екені анық. Ал компанияларда мұндай адамдарға сұраныс өте жоғары. Сондықтан, шын мәнінде, бұл дәріс пайда болды.
Мен айтатын жоспар туралы айтатын болсақ, ол былай көрінеді, жақшада (TL;DR) - «тым ұзын; оқыма». Менің бүгінгі презентациям шексіз тізімдерден тұрады.
Шындығында, мен мұндай презентацияларды жасаған кезде ұнатпаймын, бірақ бұл тақырып соншалық, мен бұл презентацияны дайындаған кезде мен бұл ақпаратты қалай басқаша ұйымдастыру керектігін түсінбедім.
Өйткені, жалпы алғанда, бұл ақпарат «ctrl+c, ctrl+v», басқалармен қатар, DevOps бөліміндегі Wiki-ден алынған, мұнда біз әзірлеушілерге қойылатын талаптарды жазғанбыз: «жігіттер, сіздің қосымшаңызды іске қосамыз. Кубернетес, бұл осылай болуы керек ».
Сондықтан презентация үлкен тізімге айналды. Кешіріңіз. Мүмкіндігінше жалықтырмас үшін айтып беруге тырысамын.
Біз қазір нені қарастырамыз:
- бұл, біріншіден, журналдар (қолданба журналдары?), олармен Kubernetes-те не істеу керек, олармен не істеу керек, олар қандай болуы керек;
- Kubernetes конфигурацияларымен не істеу керек, Kubernetes қолданбасын конфигурациялаудың ең жақсы және ең нашар тәсілдері қандай;
- Жалпы қол жетімділікті тексеру дегеніміз не, олар қандай болуы керек туралы сөйлесейік;
- сымбатты өшіру дегеніміз не туралы сөйлесейік;
- ресурстар туралы тағы да сөйлесейік;
- Деректерді сақтау тақырыбына тағы да тоқталайық;
- және соңында мен бұл жұмбақ бұлт қолданбасының термині қандай екенін айтып беремін. Бұлттылық, осы терминнің сын есімі ретінде.
Журналдар
Мен журналдардан бастауды ұсынамын - бұл журналдарды Kubernetes-те қай жерде жылжыту керек. Енді сіз Kubernetes қолданбасын іске қостыңыз. Классиктердің айтуынша, бұрын қолданбалар әрқашан файлдың бір жерінде журналдарды жазатын. Нашар қолданбалар қолданбаны іске қосқан әзірлеушінің үй каталогындағы файлға журналдар жазды. Жақсы қолданбалар файлға журналдарды жазды /var/log.
Тиісінше, одан әрі жақсы әкімшілер өздерінің инфрақұрылымдарында бұл журналдар айналуы мүмкін кейбір нәрселерді конфигурациялаған - дәл сол rsyslog, бұл журналдарды қарайды және олармен бірдеңе болған кезде, олардың саны көп, ол резервтік көшірмелерді жасайды , журналдарды сол жерге қояды. , ескі файлдарды жояды, бір аптадан астам, алты айдан астам және кейбіреулері. Теориялық тұрғыдан бізде жай ғана қолданба журналдарды жазғандықтан, өндірістік серверлердегі бос орын (жауынгерлік серверлер?) таусылмайтындай ережелер болуы керек. Және, тиісінше, бөренелер кесірінен бүкіл өндіріс тоқтап қалмады.
Біз Кубернетес әлеміне көшкен кезде және сол жерде бірдей нәрсені іске қосқан кезде, сіз бірінші назар аударатын нәрсе - адамдар файлға журналдар жазған кезде, оларды жазуды жалғастырады.
Егер Кубернетес туралы айтатын болсақ, журналдарды докерлік контейнерден бір жерде жазудың дұрыс орны оларды қосымшадан Stdout/Stderr деп аталатынға, яғни операциялық жүйенің стандартты шығыс ағындарына жазу болып табылады. стандартты қате шығысы. Бұл Docker жүйесінде, атап айтқанда Kubernetis жүйесінде журналдарды қоюдың ең дұрыс, қарапайым және логикалық әдісі. Өйткені сіздің қолданба журналдарды Stdout/Stderr жүйесіне жазса, бұл журналдармен не істеу керектігін Docker және Kubernetes қондырмасы шешеді. Docker әдепкі бойынша JSON пішімінде өзінің арнайы файлдарын құрастырады.
Осы жерде сұрақ туындайды, сіз бұл журналдармен ары қарай не істейсіз? Ең оңай жолы түсінікті, мүмкіндігіміз бар kubectl logs және осы «бұршақтардың» журналдарына қараңыз. Бірақ, мүмкін, бұл өте жақсы нұсқа емес - журналдармен тағы бір нәрсе жасау керек.
Әзірге, біз журналдар тақырыбын қозғағандықтан, журналдар сияқты нәрсе туралы сөйлесейік. Яғни, бұл тікелей Кубернетеске қатысты емес, бірақ біз журналдармен не істеу керектігі туралы ойлана бастағанда, бұл туралы да ойластырған дұрыс.
Бізге доккер өз файлдарына енгізетін журналдарды алып, оларды бір жерге жіберетін достық жолмен қандай да бір құрал қажет. Жалпы алғанда, біз әдетте Kubernetes ішінде DaemonSet - журнал жинағыш түрінде қандай да бір агентті іске қосамыз, ол жай ғана Docker жинайтын журналдар қайда орналасқаны туралы айтылады. Және бұл жинақтаушы агент оларды жай ғана қабылдайды, мүмкін, тіпті оларды жол бойына талдайды, мүмкін оларды кейбір қосымша мета-ақпараттармен байытады және, сайып келгенде, оларды бір жерге сақтауға жібереді. Ол жерде вариациялар қазірдің өзінде мүмкін. Ең көп таралғаны Elasticsearch болуы мүмкін, онда журналдарды сақтауға болады және оларды сол жерден ыңғайлы түрде алуға болады. Содан кейін, сұрауды пайдаланып, Kibana көмегімен, мысалы, олардың негізінде графиктер құрастырыңыз, олардың негізінде ескертулер жасаңыз және т.б.
Ең маңызды идея, мен оны қайтадан қайталағым келеді, Docker ішінде, атап айтқанда Кубернетес ішінде журналдарыңызды файлда сақтау өте жаман идея.
Өйткені, біріншіден, файлдағы контейнер ішіндегі журналдарды алу қиын. Алдымен контейнерге кіріп, сонда exec, содан кейін журналдарды қарау керек. Келесі мәселе, егер сізде файлда журналдар болса, онда контейнерлерде әдетте минималистік орта болады және әдетте журналдармен қалыпты жұмыс істеу үшін қажет утилиталар жоқ. Оларды көміңіз, қараңыз, мәтіндік редакторда ашыңыз. Келесі сәт - бізде контейнер ішіндегі файлда журналдар бар, егер бұл контейнер жойылса, онымен бірге журналдар да өледі. Тиісінше, контейнерді кез келген қайта іске қосу журналдар жоқ дегенді білдіреді. Тағы да, жаман нұсқа.
Және соңғы нүкте, әдетте контейнерлердің ішінде сіздің қолданбаңыз болады және бұл - әдетте орындалатын жалғыз процесс. Журналдарыңызбен файлдарды айналдыратын кез келген процесс туралы мүлде әңгіме жоқ. Журналдар файлға жазыла бастағанда, бұл кешіріңіз, біз өндірістік серверді жоғалта бастаймыз дегенді білдіреді. Өйткені, біріншіден, оларды табу қиын, оларды ешкім қадағаламайды, сонымен қатар оларды ешкім басқармайды - сәйкесінше, сервердегі бос орын таусылғанша файл шексіз өседі. Сондықтан мен Docker жүйесінде, атап айтқанда Кубернетесте файлға кіру жаман идея екенін тағы айтамын.
Келесі мәселе, мен бұл туралы тағы да айтқым келеді - біз журналдар тақырыбын қозғап жатқандықтан, олармен жұмыс істеу ыңғайлы болу үшін журналдар қалай көрінетіні туралы сөйлескен дұрыс. Мен айтқанымдай, бұл тақырып Kubernetes-ке тікелей қатысты емес, бірақ ол DevOps тақырыбына өте жақсы қатысты. Әркімге ыңғайлы болу үшін осы екі түрлі бөлімнің - Dev және Ops арасындағы мәдениет пен достықты дамыту тақырыбында.
Бұл бүгінгі күні журналдар JSON пішімінде жазылуы керек дегенді білдіреді. Егер сізде қандай да бір баспа түрін немесе сол сияқты нәрсені енгізгендіктен журналдарды түсініксіз пішімдерде жазатын өзіңіздің түсініксіз қолданбаңыз болса, онда қалыпты тіркеуді жүзеге асыруға мүмкіндік беретін қандай да бір құрылымды, қандай да бір қаптаманы Google-да іздеудің уақыты келді; JSON жүйесінде тіркеу параметрлерін қосыңыз, себебі JSON қарапайым пішім, оны талдау оңай.
Егер сіздің JSON кейбір критерийлерге сәйкес жұмыс істемесе, ешкім нені білмейді, онда кем дегенде талдауға болатын пішімдегі журналдарды жазыңыз. Бұл жерде, мысалы, егер сіз бірнеше контейнерлерді іске қосып жатсаңыз немесе жай ғана nginx-пен өңдеп жатсаңыз және олардың әрқайсысында жеке тіркеу параметрлері болса, онда бұл сізге өте ыңғайсыз болып көрінуі мүмкін. оларды талдау. Өйткені әрбір жаңа nginx данасы үшін өзіңіздің талдаушыңызды жазуыңыз керек, себебі олар журналдарды басқаша жазады. Тағы да, бұл барлық nginx даналарының бірдей тіркеу конфигурациясына ие болуын және олардың барлық журналдарын мүлдем біркелкі жазғанын қамтамасыз ету туралы ойлану керек еді. Бұл барлық қолданбаларға қатысты.
Ақыр соңында, мен де отқа жанармай қосқым келеді, ең дұрысы, көп жолды пішім журналдарынан аулақ болу керек. Мәселе мынада, егер сіз бөрене жинаушылармен жұмыс істеген болсаңыз, онда сіз олардың сізге не уәде ететінін, көп жолды журналдармен жұмыс істей алатынын, оларды қалай жинау керектігін және т.б. Шындығында, менің ойымша, бүгінгі күні бірде-бір коллектор көп жолды журналдарды қалыпты, толық және қатесіз жинай алмайды. Ыңғайлы және қатесіз болу үшін адами жолмен.
Бірақ стек ізі әрқашан көп жолды журналдар және оларды қалай болдырмау керек. Бұл жерде сұрақ мынада: журнал оқиғаның жазбасы, ал stactrace іс жүзінде журнал емес. Егер журналдарды жинап, оларды Elasticsearch қолданбасының бір жеріне қойсақ, содан кейін олардан графиктер салсақ, сайтыңызда пайдаланушы әрекеті туралы есептерді құрастырсақ, онда стек ізін алған кезде, бұл күтпеген нәрсе болып жатқанын білдіреді. қолданбаңызда өңделмеген жағдай. Және оларды бақылай алатын жүйеге стек ізін автоматты түрде жүктеп салу мағынасы бар.
Бұл стек ізімен жұмыс істеу үшін арнайы жасалған бағдарламалық құрал (сол Sentry). Ол дереу автоматтандырылған тапсырмаларды жасай алады, оларды біреуге тағайындай алады, стакттректер пайда болған кезде ескертеді, осы стакттректерді бір түр бойынша топтай алады және т.б. Негізінде, бөренелер туралы айтатын болсақ, стактрастар туралы айтудың мағынасы жоқ, өйткені бұл әр түрлі мақсаттары бар әртүрлі нәрселер.
Конфигурация
Содан кейін біз Kubernetes-тегі конфигурация туралы сөйлесеміз: онымен не істеу керек және Kubernetes ішіндегі қолданбаларды қалай конфигурациялау керек. Жалпы, мен әдетте Docker контейнерлер туралы емес деп айтамын. Docker контейнерлер туралы екенін бәрі біледі, тіпті Docker-пен көп жұмыс істемегендер де. Қайталап айтамын, Docker контейнерлер туралы емес.
Docker, менің ойымша, стандарттар туралы. Және іс жүзінде барлығы үшін стандарттар бар: қолданбаңызды құру стандарттары, қолданбаңызды орнату стандарттары.
Және бұл нәрсе - біз оны бұрын қолдандық, ол контейнерлердің пайда болуымен ғана танымал болды - бұл ENV (қоршаған орта) айнымалылары деп аталады, яғни сіздің операциялық жүйеңіздегі орта айнымалылары. Бұл әдетте қолданбаңызды конфигурациялаудың тамаша тәсілі, өйткені сізде JAVA, Python, Go, Perl, Құдай сақтасын қолданбаларыңыз болса және олардың барлығы дерекқор хостын, дерекқор пайдаланушысын, дерекқор құпия сөзінің айнымалы мәндерін оқи алса, бұл өте қолайлы. Сізде төрт түрлі тілдегі қолданбалар дерекқор жоспарында бірдей конфигурацияланған. Басқа конфигурациялар жоқ.
Барлығын ENV айнымалылары арқылы конфигурациялауға болады. Біз Kubernetes туралы айтқан кезде, ENV айнымалы мәндерін тікелей Deployment ішінде жариялаудың тамаша тәсілі бар. Тиісінше, егер біз құпия деректер туралы айтатын болсақ, онда біз ENV айнымалыларынан құпия деректерді (деректер базасына құпия сөздер және т. осы айнымалының мәні және осы дерекқордың құпия сөз айнымалысының мәні құпиядан оқылады. Бұл Kubernetes стандартты әрекеті. Бұл қолданбаларды конфигурациялаудың ең тамаша нұсқасы. Тек код деңгейінде, бұл қайтадан әзірлеушілерге қатысты. Егер сіз DevOps болсаңыз, сіз мынаны сұрай аласыз: «Балалар, қолданбаңызды қоршаған ортаның айнымалы мәндерін оқуға үйретіңіз. Және бәріміз бақытты боламыз ».
Егер компаниядағы барлығы бірдей аталған орта айнымалы мәндерін оқыса, бұл өте жақсы. Кейбіреулер postgres дерекқорын күтуде, басқалары дерекқордың атын күтуде, басқалары басқа нәрсені күтуде, басқалары қандай да бір dbn күтеді, осылайша, сәйкесінше, біркелкі болады.
Мәселе сізде жай ғана Орналастыруды ашатын көптеген орта айнымалылары болғанда туындайды - және орта айнымалыларының бес жүз жолы бар. Бұл жағдайда сізде жай ғана өскен ортаның айнымалылары бар - енді өзіңізді азаптаудың қажеті жоқ. Бұл жағдайда конфигурацияларды пайдалануды бастау мағынасы бар. Яғни, қолданбаңызды конфигурацияларды пайдалануға үйретіңіз.
Жалғыз сұрақ - конфигурациялар сіз ойлағандай емес. Config.pi пайдалану ыңғайлы конфигурация емес. Немесе өзіңіздің жеке пішіміңіздегі кейбір конфигурация, балама түрде дарынды - бұл да мен айтқым келген конфигурация емес.
Менің айтып отырғаным қолайлы форматтардағы конфигурация, яғни ең танымал стандарт .yaml стандарты болып табылады. Оны қалай оқитыны түсінікті, адам оқитыны, қалай оқуы қосымшадан түсінікті.
Тиісінше, YAML-ден басқа, сіз, мысалы, JSON-ды пайдалана аласыз, талдау сол жерден қолданба конфигурациясын оқу тұрғысынан YAML сияқты ыңғайлы. Адамдардың оқуы айтарлықтай ыңғайсыз. Сіз пішімді көріңіз, a la ini. Бұл адам тұрғысынан оқуға өте ыңғайлы, бірақ оны автоматты түрде өңдеу ыңғайсыз болуы мүмкін, яғни егер сіз өз конфигурацияларыңызды жасағыңыз келсе, ini пішімі қазірдің өзінде жасау ыңғайсыз болуы мүмкін.
Бірақ кез келген жағдайда, сіз қандай форматты таңдасаңыз да, Кубернетес тұрғысынан бұл өте ыңғайлы. Толық конфигурацияны ConfigMap ішіндегі Kubernetes ішіне қоюға болады. Содан кейін осы конфигматикалық картаны алыңыз және оны конфигурацияңыздың ішіне қандай да бір нақты каталогта орнатуды сұраңыз, мұнда сіздің қолданба осы конфигурациядан конфигурацияны жай файл сияқты оқиды. Бұл, шын мәнінде, қолданбаңызда көптеген конфигурация опциялары болған кезде істеу жақсы. Немесе бұл күрделі құрылымның бір түрі, ұя салу бар.
Егер сізде конфигурация картасы болса, онда сіз қолданбаңызды өте жақсы үйрете аласыз, мысалы, конфигурация орнатылған файлдағы өзгерістерді автоматты түрде қадағалауға, сондай-ақ конфигурациялар өзгерген кезде қолданбаны автоматты түрде қайта жүктеуге болады. Бұл, әдетте, тамаша нұсқа болар еді.
Мен бұл туралы тағы да айттым - құпия ақпарат конфигмапта емес, құпия ақпарат айнымалыларда емес, құпия ақпарат құпияда емес. Сол жерден бұл құпия ақпаратты дипломатияға қосыңыз. Әдетте біз Kubernetes нысандарының, орналастырулардың, конфигматикалардың, қызметтерінің барлық сипаттамаларын git ішінде сақтаймыз. Тиісінше, git-дегі дерекқорға құпия сөзді қою, тіпті ол сіздің компанияңызда бар GIT болса да, жаман идея. Өйткені, кем дегенде, git бәрін есте сақтайды және ол жерден парольдерді алып тастау оңай емес.
Денсаулықты тексеру
Келесі нүкте - бұл денсаулықты тексеру деп аталатын нәрсе. Жалпы, денсаулықты тексеру сіздің қолданбаңыздың жұмыс істеп тұрғанын тексеру болып табылады. Сонымен қатар, біз көбінесе белгілі бір веб-қосымшалар туралы айтып отырмыз, олар үшін, тиісінше, денсаулықты тексеру тұрғысынан (мұнда және одан әрі аудармаған дұрыс) бұл олар өңдейтін кейбір арнайы URL мекенжайы болады. стандарт, олар әдетте жасайды /health.
Осы URL мекенжайына қол жеткізген кезде, сәйкесінше, біздің қолданба «иә, жақсы, менде бәрі жақсы, 200» немесе «жоқ, менде бәрі жақсы емес, шамамен 500» дейді. Тиісінше, егер біздің қолданба http емес, веб-қосымша емес болса, біз қазір демонның қандай да бір түрі туралы айтып отырмыз, біз денсаулықты тексеруді қалай жасау керектігін анықтай аламыз. Яғни, бұл қажет емес, егер қолданба http болмаса, онда бәрі денсаулықты тексерусіз жұмыс істейді және мұны ешқандай жолмен жасау мүмкін емес. Сіз файлдағы кейбір ақпаратты мезгіл-мезгіл жаңарта аласыз, демоныңыз үшін арнайы пәрмен жасай аласыз, мысалы: daemon status, ол «иә, бәрі жақсы, демон жұмыс істейді, ол тірі» дейді.
Ол не үшін? Бірінші және ең айқын нәрсе - бұл қосымшаның жұмыс істеп тұрғанын түсіну үшін денсаулықты тексеру не үшін қажет. Менің айтайын дегенім, бұл жай ғана ақымақтық, ол қазір жұмыс істеп тұрғанда, ол жұмыс істеп тұрған сияқты көрінеді, сондықтан оның жұмыс істейтініне сенімді бола аласыз. Қолданба жұмыс істеп тұр, контейнер жұмыс істейді, данасы жұмыс істейді, бәрі жақсы - содан кейін пайдаланушылар техникалық қолдаудан барлық телефон нөмірлерін өшіріп тастап, «сен кімсің..., сен ұйықтап қалды, ештеңе істемейді ».
Денсаулықты тексеру - бұл пайдаланушының көзқарасы бойынша оның жұмыс істейтінін көрудің тәсілі. Әдістердің бірі. Оны былай қояйық. Кубернетес көзқарасы бойынша, бұл қолданбаның қашан басталатынын түсінудің де жолы, өйткені біз контейнер іске қосылған, жасалған және іске қосылған кезде және қолданба тікелей осы контейнерде іске қосылған кезде айырмашылық бар екенін түсінеміз. Өйткені, егер біз орташа Java қолданбасын алып, оны докта іске қосуға тырыссақ, онда қырық секундқа, тіпті бір минутқа, тіпті онға дейін, ол жақсы басталуы мүмкін. Бұл жағдайда сіз кем дегенде оның порттарын қағуға болады, ол жерде жауап бермейді, яғни трафикті қабылдауға әлі дайын емес.
Қайтадан, денсаулықты тексерудің көмегімен және біз осында бұрылып жатқанымыздың көмегімен біз Кубернетесте қолданбада тек контейнер көтеріліп қана қоймай, қолданбаның өзі іске қосылып, ол қазірдің өзінде жауап беретінін түсінеміз. денсаулықты тексеру, яғни біз сол жерге трафик жібере аламыз.
Мен қазір айтып отырған нәрсе Кубернетес ішіндегі Дайындық/Тірілік сынақтары деп аталады; сәйкесінше, біздің дайындық сынақтары теңгерімдеудегі қолданбаның қолжетімділігіне жауап береді. Яғни, егер қосымшада дайындық сынақтары орындалса, онда бәрі жақсы, клиент трафигі қолданбаға түседі. Егер дайындық сынақтары орындалмаса, онда қолданба жай қатыспайды, бұл нақты данасы теңгерімдеуге қатыспайды, ол теңгерімдеуден жойылады, клиент трафигі ағып кетпейді. Тиісінше, Kubernetes ішіндегі Liveness сынақтары қажет, сондықтан қолданба тұрып қалса, оны қайта іске қосуға болады. Егер Kubernetes-те жарияланған қолданба үшін тірілік сынағы жұмыс істемесе, онда қолданба тек теңгерімдеуден жойылмайды, қайта іске қосылады.
Міне, мен айта кеткім келетін маңызды мәселе: практикалық тұрғыдан алғанда, дайындық тесті әдетте өмірлік сынаққа қарағанда жиі қолданылады және жиі қажет. Яғни, дайындық пен өмірлік сынақтарды ойланбастан жариялау, өйткені Кубернетес мұны істей алады және ол жасай алатын барлық нәрсені қолданайық, бұл өте жақсы идея емес. Неге екенін түсіндіремін. Өйткені тестілеудегі екінші тармақ денсаулықты тексеру кезінде негізгі қызметті тексеру жақсы идея болар еді. Бұл дегеніміз, егер сізде кейбір ақпаратты беретін веб-бағдарлама болса, ол өз кезегінде оны бір жерден алуы керек. Мысалы, дерекқорда. Бұл REST API-ге келетін ақпаратты сол дерекқорға сақтайды. Содан кейін, сәйкесінше, егер сіздің денсаулық тексеруіңіз байланысқан slashhealth сияқты жауап берсе, қолданба «200, жарайды, бәрі жақсы» дейді және сонымен бірге қолданбаңыздың дерекқорына қол жеткізу мүмкін емес, ал Healthcheck қолданбасы «200, жарайды, бәрі жақсы» дейді. ” - Бұл денсаулықты тексеру. Бұл қалай жұмыс істеуі керек емес.
Яғни, сіздің өтінішіңіз, оған сұраныс келгенде /health, ол «200, жарайды» деп жауап беріп қана қоймайды, ол алдымен, мысалы, дерекқорға кіреді, оған қосылуға тырысады, ол жерде өте қарапайым нәрсені жасайды, мысалы біреуін таңдаңыз, тек қосылым бар-жоғын тексереді. дерекқорды сұрай аласыз. Мұның бәрі сәтті болса, жауап «200, жарайды». Сәтті болмаса, қате бар, дерекқор қолжетімсіз деп айтады.
Сондықтан, осыған байланысты мен Дайындық/Тірілік сынақтарына қайта ораламын - неліктен сізге дайындық сынағы қажет болуы мүмкін, бірақ жандылық тесті сұрақ туындайды. Өйткені, егер сіз денсаулықты тексеруді дәл мен айтқандай сипаттасаңыз, онда ол даналық бөлімде қол жетімді емес болып шығады.в или со всех instanceмысалы, дерекқорда. Дайындық сынағы туралы мәлімдеген кезде, біздің медициналық тексерулеріміз сәтсіз аяқталды, сәйкесінше дерекқорға қол жетімді емес барлық қосымшалар теңгерімдеуден ажыратылды және іс жүзінде жай ғана ескерілмеген күйде «ілулі болады» және олардың дерекқорлары жұмыс істеуін күтеді. жұмыс.
Егер біз тірілік сынағы жариялаған болсақ, елестетіп көріңізші, біздің дерекқорымыз бұзылды және сіздің Kubernetes-те барлығының жартысы қайта іске қосыла бастайды, себебі тірілік сынағы сәтсіз аяқталды. Бұл қайта іске қосу керек дегенді білдіреді. Бұл сіз қалаған нәрсе емес, тіпті тәжірибеде жеке тәжірибем де болды. Бізде JS тілінде жазылған және Mongo дерекқорына енгізілген чат қолданбасы болды. Мәселе мынада, бұл менің Кубернетеспен жұмысымның басында болды, біз Кубернетес жасай алады, сондықтан біз оны қолданамыз деген принцип бойынша сынақтардың дайындығын, жандылығын сипаттадық. Тиісінше, бір сәтте Монго сәл «түтіккен» болды және үлгі сәтсіздікке ұшырай бастады. Тиісінше, жаңбырлылық сынағы бойынша, бұршақтар «өлтіре» бастады.
Түсінгеніңіздей, олар «өлген» кезде бұл чат, яғни клиенттердің көптеген байланыстары бар. Олар сондай-ақ «өлтіріледі» - жоқ, клиенттер емес, тек байланыстар - барлығы бір уақытта емес, және олар бір уақытта өлтірілмейтіндіктен, кейбіреулері ертерек, кейбіреулері кейінірек, олар бір уақытта басталмайды. уақыт. Стандартты кездейсоқ, біз әр уақытта қолданбаның басталу уақытын миллисекундтық дәлдікпен болжай алмаймыз, сондықтан олар оны бір уақытта бір данасын жасайды. Бір инфоспот көтеріледі, теңгерімге қосылады, сонда барлық клиенттер келеді, ол мұндай жүктемеге төтеп бере алмайды, өйткені ол жалғыз, және шамамен айтқанда, онда оншақты адам жұмыс істейді, ол төмендейді. Келесісі көтеріледі, бүкіл жүк оның мойнында, ол да түседі. Бұл сарқырамалар тек қана сарқырама жалғастырады. Ақырында, бұл қалай шешілді - бізге осы қолданбаға пайдаланушы трафигін қатаң түрде тоқтату керек болды, барлық даналарды жоғарылатуға мүмкіндік беріп, содан кейін ол барлық он данаға бөлінген болатындай барлық пайдаланушы трафигін бірден бастау керек болды.
Егер барлығын қайта іске қосуға мәжбүр ететін осы тірілік сынағы жарияланбаған болса, қолданба оны жақсы өңдейтін еді. Бірақ теңгерімдеуден бастап бәрі біз үшін өшірілген, өйткені дерекқорларға қол жетімсіз және барлық пайдаланушылар «құлап кетті». Содан кейін, бұл дерекқор қол жетімді болған кезде, бәрі теңдестіруге қосылады, бірақ қолданбаларды қайта бастаудың қажеті жоқ және бұл үшін уақыт пен ресурстарды ысырап етудің қажеті жоқ. Олардың барлығы қазірдің өзінде осында, олар қозғалысқа дайын, сондықтан трафик ашылады, бәрі жақсы - қолданба орнында, бәрі жұмысын жалғастыруда.
Сондықтан, дайындық пен жандылық сынақтары әртүрлі, сонымен қатар сіз теориялық түрде әртүрлі денсаулық тексерулерін жасай аласыз, мысалы, бір типті радиусты, бір типті liv, және әртүрлі нәрселерді тексере аласыз. Дайындық тестілері кезінде серверлерді тексеріңіз. Сондай-ақ, мысалы, өмірлік тестілеуде, егер ол мүлдем жауап бере алатын болса, тірілік тесті әдетте жауап беретін қолданба екенін тексермейсіз.
Өйткені жандылық сынағы, жалпы алғанда, біз «жабысып қалған» кезде. Шексіз цикл басталды немесе басқа нәрсе - және басқа сұраулар өңделмейді. Сондықтан, тіпті оларды бөліп алу - және оларда әртүрлі логиканы жүзеге асыру мағынасы бар.
Тест тапсырғанда, денсаулықты тексергенде не жауап беру керектігі туралы. Бұл жай ғана азап. Мұны білетіндер күлетін шығар, бірақ шындап айтсам, мен өмірімде 200% жағдайда «XNUMX» деп жауап беретін қызметтерді көрдім. Яғни, кім табысты. Бірақ сонымен бірге жауап мәтінінде олар «мұндай қате» деп жазады.
Яғни, жауап мәртебесі сізге келеді - бәрі сәтті. Бірақ сонымен бірге сіз денені талдауыңыз керек, өйткені дене «кешіріңіз, сұрау қатемен аяқталды» дейді және бұл жай шындық. Мен мұны өмірде көрдім.
Кейбіреулер оны күлкілі деп таппауы үшін, ал басқалары өте ауыр деп санауы үшін қарапайым ережені ұстанған жөн. Денсаулықты тексеруде және веб-қосымшалармен жұмыс істеу кезінде.
Егер бәрі жақсы болса, екі жүзінші жауаппен жауап беріңіз. Негізінде кез келген екі жүздік жауап сізге сәйкес келеді. Егер сіз ragsy-ді жақсы оқысаңыз және кейбір жауап күйлерінің басқаларынан ерекшеленетінін білсеңіз, сәйкесінше жауап беріңіз: 204, 5, 10, 15, кез келген жағдайда. Егер бұл өте жақсы болмаса, онда «екі нөл нөл». Егер бәрі нашар болса және денсаулық тексеруі жауап бермесе, кез келген бес жүздікпен жауап беріңіз. Қайтадан, егер сіз қалай жауап беру керектігін түсінсеңіз, әртүрлі жауап күйлері бір-бірінен қалай ерекшеленеді. Түсінбесеңіз, бірдеңе дұрыс болмаса, денсаулықты тексеруге жауап беру мүмкіндігі 502 болып табылады.
Бұл тағы бір мәселе, мен негізгі қызметтерді тексеру туралы аздап қайтарғым келеді. Егер сіз, мысалы, қолданбаңыздың артында тұрған барлық негізгі қызметтерді тексеруді бастасаңыз - жалпы барлығы. Микросервис архитектурасы тұрғысынан бізде «төмен байланыс» ұғымы бар, яғни сіздің қызметтеріңіз бір-біріне ең аз тәуелді болғанда. Егер олардың біреуі сәтсіз болса, бұл функционалдығы жоқ қалғандары жай ғана жұмысын жалғастырады. Кейбір функциялар жұмыс істемейді. Тиісінше, егер сіз барлық медициналық тексерулерді бір-бірімен байланыстырсаңыз, онда сіз инфрақұрылымда бір нәрсе құлап қаласыз және ол құлағандықтан, барлық қызметтердің барлық медициналық тексерулері де сәтсіздікке ұшырай бастайды - және жалпы алғанда, денсаулық сақтау саласы үшін инфрақұрылым көп. бүкіл микросервис архитектурасы №. Онда бәрі қараңғы болды.
Сондықтан, мен тағы да қайталап айтқым келеді, сізге негізгі қызметтерді тексеру керек, онсыз сіздің өтінішіңіз жүз пайыз жағдайда өз жұмысын орындай алмайды. Яғни, егер сізде пайдаланушы дерекқорға сақтайтын немесе дерекқордан шығарып алатын REST API болса, онда дерекқор болмаған жағдайда пайдаланушылармен жұмыс істеуге кепілдік бере алмайтыныңыз қисынды.
Бірақ егер сіз оларды дерекқордан шығарған кезде сіздің пайдаланушыларыңыз фронтендке жауап жібермес бұрын енгізген басқа серверден кейбір басқа метадеректермен қосымша байытылса және бұл сервер қол жетімді болмаса, бұл сіздің метадеректердің ешбір бөлігінсіз жауап беріңіз.
Әрі қарай, бізде қосымшаларды іске қосу кезінде ауыр мәселелердің бірі бар.
Шындығында, бұл тек Кубернетеске ғана қатысты емес; жаппай даму мәдениеті және әсіресе DevOps Кубернетеспен бір уақытта тарала бастады. Сондықтан, жалпы алғанда, сізге Кубернетессіз қосымшаңызды әдемі түрде өшіру керек екені белгілі болды. Кубернетеске дейін де адамдар мұны істеді, бірақ Кубернетестің пайда болуымен біз бұл туралы жаппай айта бастадық.
Керемет өшіру
Жалпы, Graceful Shutdown дегеніміз не және ол не үшін қажет? Бұл сіздің қолданбаңыз қандай да бір себептермен істен шыққан кезде, сізге істеу керек app stop - немесе сіз, мысалы, операциялық жүйеден сигнал алсаңыз, қолданбаңыз оны түсінуі және бұл туралы бірдеңе істеуі керек. Ең нашар сценарий, әрине, сіздің өтініміңіз SIGTERM алған кезде және «SIGTERM, тоқталайық, жұмыс істейік, ештеңе жасамаңыз» деген сияқты. Бұл мүлдем жаман нұсқа.
Сіздің қолданбаңыз SIGTERM алған кезде дерлік бірдей нашар опция болып табылады және «олар segterm айтты, бұл біз аяқталып жатырмыз дегенді білдіреді, мен көрген жоқпын, мен ешқандай пайдаланушы сұрауларын білмеймін, қандай түрін білмеймін. Мен қазір жұмыс істеп жатқан сұраулар, олар SIGTERM деді, бұл біз аяқталып жатырмыз » Бұл да жаман нұсқа.
Қай нұсқа жақсы? Бірінші тармақ - операциялардың аяқталуын ескеру. Жақсы нұсқа - сіздің серверіңіз SIGTERM алған жағдайда не істейтінін әлі де ескеруі.
SIGTERM - бұл жұмсақ өшіру, ол арнайы жасалған, оны код деңгейінде ұстауға болады, оны өңдеуге болады, қазір айтыңыз, күтіңіз, біз алдымен қолымызда бар жұмысты аяқтаймыз, содан кейін шығамыз.
Кубернетестің көзқарасы бойынша, бұл осылай көрінеді. Kubernetes кластерінде жұмыс істеп тұрған подводқа «тоқтаңыз, кетіңіз» деп айтқан кезде немесе біз қайта іске қосыламыз немесе Kubernetes подкасттарды қайта жасағанда жаңарту орын алса, Кубернетес қосқышқа дәл сол SIGTERM хабарламасын жібереді, күтеді. біраз уақыт, және , бұл оның күтетін уақыты, ол да конфигурацияланған, дипломдарда осындай арнайы параметр бар және ол Graceful ShutdownTimeout деп аталады. Түсінгеніңіздей, бұл бекер аталмаған және біз қазір бұл туралы бекер айтып отырған жоқпыз.
Онда біз SIGTERM қолданбасын қолданбаға жіберген уақыт пен қолданбаның бірдеңе үшін есінен танып қалған сияқты немесе «жабысып қалған» және аяқталмайтынын түсінген кезде қанша уақыт күту керектігін нақты айта аламыз - және бізге қажет оны SIGKILL жіберіңіз, яғни оның жұмысын аяқтаңыз. Яғни, сәйкесінше, бізде демонның қандай да бір түрі жұмыс істейді, ол операцияларды өңдейді. Демон жұмыс істейтін біздің операциялар орташа есеппен бір уақытта 30 секундтан аспайтынын түсінеміз. Тиісінше, SIGTERM келгенде, біздің демон SIGTERM-ден кейін 30 секундтан кейін аяқтай алатынын түсінеміз. Біз оны жазамыз, мысалы, 45 секунд жағдайға байланысты және SIGTERM деп айтамыз. Осыдан кейін біз 45 секунд күтеміз. Теориялық тұрғыдан алғанда, осы уақыт ішінде жын өз жұмысын аяқтап, өзін аяқтауы керек еді. Бірақ кенеттен ол мүмкін болмаса, бұл оның кептеліп қалғанын білдіреді — ол енді біздің сұрауларымызды қалыпты түрде өңдемейді. Ал 45 секундта сіз оны қауіпсіз түрде шегелей аласыз.
Бұл жерде, шын мәнінде, тіпті 2 аспектіні де ескеруге болады. Біріншіден, егер сіз сұрау алсаңыз, сіз онымен қандай да бір түрде жұмыс істей бастағаныңызды және пайдаланушыға жауап бермегеніңізді түсініңіз, бірақ сіз, мысалы, SIGTERM алдыңыз. Оны нақтылау және пайдаланушыға жауап беру мағынасы бар. Бұл осыған байланысты бірінші тармақ. Мұндағы екінші тармақ мынада: егер сіз өзіңіздің қосымшаңызды жазсаңыз, әдетте архитектураны қолданбаңызға сұраныс алатындай етіп жасаңыз, содан кейін сіз біраз жұмысты бастайсыз, файлдарды бір жерден жүктей бастайсыз, дерекқорды жүктей аласыз және т.б. Бұл. Тұтастай алғанда, сіздің пайдаланушы, сіздің сұрауыңыз жарты сағат бойы ілініп тұрады және оған жауап беруіңізді күтеді - содан кейін, ең алдымен, архитектурада жұмыс істеу керек. Яғни, егер сіздің операцияларыңыз қысқа болса, SIGTERM-ді елемеу және оны өзгерту мағынасы бар деген қарапайым ойды ескеріңіз. Егер сіздің операцияларыңыз ұзақ болса, онда бұл жағдайда SIGTERM-ді елемеу мағынасы жоқ. Мұндай ұзақ операцияларды болдырмас үшін архитектураны қайта құру мағынасы бар. Пайдаланушылар жай ғана қыдырып, күтіп қалмауы үшін. Мен білмеймін, сонда қандай да бір веб-розетканы жасаңыз, серверіңіз клиентке жіберетін кері ілмектерді жасаңыз, басқа кез келген нәрсе, бірақ пайдаланушыны жарты сағат бойы іліп қоюға мәжбүрлемеңіз және сіз сеансты күткенше күтіңіз. оған жауап бер. Өйткені оның қай жерде сынуы мүмкін екенін болжау мүмкін емес.
Қолданбаңыз аяқталған кезде, кейбір сәйкес шығу кодын беруіңіз керек. Яғни, егер сіздің қолданбаңызды жабуды, тоқтатуды сұраса және ол өзін қалыпты түрде тоқтата алса, 1,5,255 және т.б. шығу кодының қандай да бір түрін қайтарудың қажеті жоқ. Нөлдік код емес кез келген нәрсе, кем дегенде Linux жүйелерінде, мен бұған сенімдімін, сәтсіз деп саналады. Яғни, бұл жағдайда сіздің өтінішіңіз қатемен аяқталды деп есептеледі. Сәйкесінше, келісімді түрде, егер сіздің өтінішіңіз қатесіз аяқталса, шығыста 0 деп айтасыз. Қолданбаңыз қандай да бір себептермен сәтсіз болса, шығыста 0 емес деп айтасыз. Және сіз бұл ақпаратпен жұмыс істей аласыз.
Және соңғы нұсқа. Пайдаланушы сұрау жіберіп, оны өңдеу кезінде жарты сағат бойы ілулі тұрғаны жаман. Бірақ, тұтастай алғанда, мен клиент тарапынан жалпы нені қажет ететіні туралы айтқым келеді. Сізде мобильді қосымшаның, алдыңғы интерфейстің және т.б. бар-жоғы маңызды емес. Жалпы алғанда, пайдаланушының сеансын тоқтатуға болатынын, кез келген нәрсе болуы мүмкін екенін ескеру қажет. Сұрау жіберілуі мүмкін, мысалы, өңделмеген және жауап қайтарылмаған. Сіздің фронтендіңіз немесе мобильді қосымшаңыз – жалпы кез келген frontend, былайша айтайық – мұны ескеруі керек. Егер сіз веб-розеткалармен жұмыс жасасаңыз, бұл мен үшін ең ауыр ауру.
Кейбір кәдімгі чаттарды әзірлеушілер мұны білмеген кезде, веб-розеткалар бұзылуы мүмкін. Олар үшін проксиде бірдеңе болғанда, біз жай ғана конфигурацияны өзгертеміз және ол қайта жүктейді. Әрине, бұл жағдайда барлық ұзақ мерзімді сессиялар жыртылады. Әзірлеушілер бізге жүгіріп келіп: «Жігіттер, не істеп жатырсыңдар, біздің барлық клиенттеріміз үшін чат бұзылды!» - дейді. Біз оларға: «Не істеп жатырсыңдар? Клиенттеріңіз қайта қосыла алмай жатыр ма? Олар: «Жоқ, сеанстар үзілмеуі керек» дейді. Қысқасы, бұл шын мәнінде нонсенс. Клиент жағын ескеру қажет. Әсіресе, мен айтқандай, веб-розеткалар сияқты ұзақ өмір сүретін сеанстарда ол бұзылуы мүмкін және пайдаланушы байқамай, мұндай сеанстарды қайта орнату мүмкіндігі болуы керек. Содан кейін бәрі тамаша.
Ресурстар
Шындығында, мен сізге нақты оқиғаны айтайын. Қайтадан шынайы өмірден. Мен ресурстар туралы естіген ең ауыр нәрсе.
Бұл жағдайда ресурстар, мен Kubernetes кластерлеріндегі подкасттарға қоюға болатын қандай да бір сұраулар, шектеулерді айтқым келеді. Әзірлеушіден естіген ең күлкілі нәрсе... Бұрынғы жұмыс орнындағы әзірлеушілерімнің бірі: «Менің қолданбам кластерде іске қосылмайды» деді. Мен оның басталмағанын көрдім, бірақ ол ресурстарға сәйкес келмеді немесе олар өте аз шектеулер қойды. Қысқаша айтқанда, қолданба ресурстарға байланысты іске қосылмайды. Мен айтамын: «Бұл ресурстарға байланысты басталмайды, сіз қаншалықты қажет екенін шешесіз және барабар мәнді орнатасыз». Ол: «Қандай ресурстар?» дейді. Мен оған Кубернетес, сұрауларға шектеулер және бла, бла, бла орнату керек екенін түсіндіре бастадым. Ер адам бес минут тыңдап, басын изеп: «Мен мұнда әзірлеуші болып жұмыс істеу үшін келдім, мен ешқандай ресурстар туралы ештеңе білгім келмейді. Мен мұнда код жазу үшін келдім және солай болды ». Бұл қайғылы. Бұл әзірлеуші тұрғысынан өте өкінішті тұжырымдама. Әсіресе заманауи әлемде, былайша айтқанда, прогрессивті девоптар.
Неліктен ресурстар қажет? Kubernetes-те ресурстардың 2 түрі бар. Кейбіреулері сұраулар, басқалары шектеулер деп аталады. Ресурстар арқылы біз әрқашан тек екі негізгі шектеулер бар екенін түсінеміз. Яғни, Kubernetes жүйесінде жұмыс істейтін контейнер үшін процессордың уақыт шектеулері және жедел жады шектеулері.
Шектеу ресурсты қолданбаңызда қалай пайдалануға болатынына жоғарғы шек қояды. Яғни, сәйкесінше, шектеулерде 1 ГБ ЖЖҚ десеңіз, қолданбаңыз 1 ГБ жедел жадтан артық пайдалана алмайды. Ал егер ол кенеттен қалап, мұны істегісі келсе, онда oom killer деп аталатын процесс жадтан шығып кетеді, яғни сіздің қолданбаңызды өлтіреді - яғни ол жай ғана қайта іске қосылады. Бағдарламалар CPU негізінде қайта іске қосылмайды. CPU тұрғысынан, егер қолданба шектеулерде көрсетілгеннен көп нәрсені қолдануға тырысса, процессор жай ғана қатаң таңдалады. Бұл қайта іске қосуға әкелмейді. Бұл шек – бұл жоғарғы шегі.
Және өтініш бар. Сұрау - Kubernetes кластеріңіздегі түйіндердің қолданбалармен қалай толтырылғанын қалай түсінетіні. Яғни, сұрау - бұл сіздің өтінішіңізді орындаудың бір түрі. Онда менің қолданғым келетіні жазылған: «Мен үшін осынша процессор мен жадты сақтауыңызды қалаймын». Осындай қарапайым ұқсастық. Егер бізде барлығы 8 процессоры бар түйін болса ше? Сұраныстарында 1 процессор бар, яғни түйінде 7 процессор қалған дегенді білдіретін подвод келеді. Яғни, сәйкесінше, әрқайсысының сұрауларында 8 процессоры бар 1 түйін осы түйінге келген кезде, Kubernetes көзқарасы бойынша түйінде CPU таусылған сияқты және сұраулары бар көбірек подкольдер мүмкін емес. осы түйінде іске қосылды. Егер барлық түйіндерде процессор таусылған болса, онда Кубернетес блоктарды іске қосу үшін кластерде қолайлы түйіндер жоқ деп айта бастайды, себебі процессор таусылды.
Сұраныстар не үшін қажет және неге сұраусыз, менің ойымша, Kubernetes-те ештеңені іске қосудың қажеті жоқ деп ойлаймын? Гипотетикалық жағдайды елестетейік. Сіз қолданбаңызды сұраусыз іске қосасыз, Кубернетес сізде қанша нәрсе бар екенін, оны қандай түйіндерге итеруге болатынын білмейді. Ал, ол түйіндерге итереді, итереді, итереді. Бір сәтте сіз қолданбаңызға трафикті ала бастайсыз. Ал қосымшалардың бірі кенеттен ресурстарды шектеулерге сәйкес шектеулерге дейін пайдалана бастайды. Жақын жерде тағы бір қосымша бар екен және оған да ресурстар қажет. Түйін шын мәнінде ресурстарды физикалық түрде таусыла бастайды, мысалы, ОС. Түйін шын мәнінде ресурстарды физикалық түрде таусыла бастайды, мысалы, жедел жады (RAM). Түйіннің қуаты таусылғанда, ең алдымен докер жауап беруді тоқтатады, содан кейін текше, содан кейін ОЖ. Олар жай ғана есінен танып қалады және БАРЛЫҒЫ сөзсіз сіз үшін жұмысын тоқтатады. Яғни, бұл түйіннің тұрып қалуына әкеледі және оны қайта іске қосу қажет болады. Бір сөзбен айтқанда, жағдай онша жақсы емес.
Егер сізде сұраулар болса, шектеулер өте ерекшеленбейді, кем дегенде шектеулерден немесе сұраулардан бірнеше есе көп емес, Kubernetes кластерлерінің түйіндері бойынша қосымшаларды қалыпты, ұтымды толтыруға болады. Сонымен бірге, Кубернетес нені қайда қоятынын, қаншасы қайда қолданылатынын шамамен біледі. Яғни, бұл дәл осындай сәт. Оны түсіну маңызды. Және бұл көрсетілгенін бақылау маңызды.
деректерді сақтау
Біздің келесі ойымыз деректерді сақтау туралы. Олармен не істеу керек және тұтастай алғанда, Кубернетестегі табандылықпен не істеу керек?
Менің ойымша, тағы да біздің ішімізде , Kubernetes-те дерекқор туралы тақырып болды. Менің ойымша, мен сіздің әріптестеріңіздің сізге: «Кубернетесте дерекқорды іске қосу мүмкін бе?» Деген кезде не айтқанын шамамен білетін сияқтымын. Қандай да бір себептермен, менің ойымша, сіздің әріптестеріңіз сізге Kubernetes-те дерекқорды іске қосу мүмкін бе деген сұрақты қойсаңыз, бұл мүмкін емес деп айтуы керек сияқты.
Мұнда логика қарапайым. Қалай болғанда да, мен тағы бір рет түсіндіремін, егер сіз бөлінген желілік сақтаудың қатеге төзімді жүйесін құра алатын шынымен керемет жігіт болсаңыз, дерекқорды бұл жағдайда қалай орналастыру керектігін түсініңіз, контейнерлердегі бұлттылық қалай жұмыс істейтінін түсініңіз. жалпы мәліметтер базасында. Сірә, сізде оны қалай іске қосу туралы сұрақ жоқ. Егер сізде осындай сұрақ туындаса және сіз оның барлығы өндірісте өліп қалмайтынына және ешқашан құламайтынына көз жеткізгіңіз келсе, онда бұл болмайды. Бұл тәсілмен өзіңізді аяққа атуға кепілдік беріледі. Сондықтан болмаған дұрыс.
Қолданбамыз сақтағысы келетін деректермен, пайдаланушылар жүктеп салатын кейбір суреттермен, мысалы, іске қосу кезінде біздің қолданба жұмыс істеген кезде жасайтын кейбір нәрселермен не істеуіміз керек? Кубернетесте олармен не істеу керек?
Жалпы алғанда, иә, әрине, Кубернетес өте жақсы жобаланған және әдетте азаматтығы жоқ қосымшалар үшін ойластырылған. Яғни, ақпаратты мүлде сақтамайтын қолданбалар үшін. Бұл идеал.
Бірақ, әрине, идеалды нұсқа әрқашан бола бермейді. Енді не? Бірінші және ең қарапайым нүкте - S3 түрін алу, үйде жасалғаны емес, ол қалай жұмыс істейтіні де түсініксіз, бірақ кейбір провайдерден. Жақсы, қалыпты провайдер - және қолданбаңызды S3 пайдалануды үйретіңіз. Яғни, пайдаланушы файлды жүктеп салғысы келгенде, «осында, оны S3-ге жүктеп салыңыз» деп айтыңыз. Ол оны алғысы келгенде: «Міне, S3-ке кері сілтеме және оны осы жерден алыңыз» деп айтыңыз. Бұл идеал.
Егер кенеттен қандай да бір себептермен бұл тамаша опция жарамсыз болса, сізде сіз жазбаған қосымшаңыз бар, сіз әзірлемеген немесе бұл қандай да бір қорқынышты мұра болса, ол S3 протоколын пайдалана алмайды, бірақ жергілікті каталогтармен жұмыс істеуі керек. жергілікті қалталар. Азды-көпті қарапайым нәрсені алыңыз, Кубернеттерді орналастырыңыз. Яғни, кейбір минималды тапсырмалар үшін дереу Цефті қоршау, менің ойымша, бұл жаман идея. Өйткені Ceph, әрине, жақсы және сәнді. Бірақ егер сіз шынымен не істеп жатқаныңызды түсінбесеңіз, Цефке бірдеңе қойғаннан кейін, оны оңай әрі оңай алып кете алмайсыз. Өйткені, өзіңіз білетіндей, Ceph өзінің кластеріндегі деректерді қарапайым файлдар түрінде емес, екілік түрде сақтайды. Сондықтан, егер кенеттен Ceph кластері бұзылса, онда сіздің деректеріңізді ол жерден ешқашан алмауыңыздың толық және жоғары ықтималдығы бар.
Бізде Ceph бойынша курс болады, сіз аласыз .
Сондықтан NFS сервері сияқты қарапайым нәрсені жасаған дұрыс. Kubernetes олармен жұмыс істей алады, каталогты NFS серверінің астына орнатуға болады - қолданбаңыз жергілікті каталог сияқты. Сонымен қатар, әрине, сіз NFS-мен бірдеңе істеу керек екенін түсінуіңіз керек, кейде оның қол жетімсіз болып қалуы мүмкін екенін түсінуіңіз керек және бұл жағдайда сіз не істейсіз деген сұрақты қарастыруыңыз керек. Мүмкін оның сақтық көшірмесін бөлек құрылғыда жасау керек шығар.
Мен айтқан келесі мәселе, егер сіздің қолданбаңыз жұмыс кезінде кейбір файлдарды жасаса не істеу керек. Мысалы, ол іске қосылғанда, ол қолданба тек іске қосу кезінде алатын кейбір ақпаратқа негізделген кейбір статикалық файлды жасайды. Қандай сәт. Егер мұндай деректер көп болмаса, сізге мүлдем алаңдамау керек, бұл қолданбаны өзіңіз үшін орнатып, жұмыс істеңіз. Бұл жерде жалғыз сұрақ - не, қараңыз. Көбінесе WordPress және т.б. сияқты бұрынғы жүйелердің барлық түрлері, әсіресе өзгертілген ақылды плагиндермен, ақылды PHP әзірлеушілерімен, олар көбінесе өздері үшін қандай да бір файл түрін жасау үшін оны қалай жасау керектігін біледі. Сәйкесінше, біреуі бір файлды, екіншісі екінші файлды жасайды. Олар әртүрлі. Баланстау клиенттердің Kubernetes кластерінде кездейсоқ орын алады. Тиісінше, олар, мысалы, бірге жұмыс істеуді білмейді. Біреуі бір ақпаратты береді, екіншісі пайдаланушыға басқа ақпаратты береді. Бұл аулақ болу керек. Яғни, Kubernetes-те сіз іске қосқан барлық нәрсе бірнеше жағдайда жұмыс істей алатынына кепілдік беріледі. Өйткені Кубернетес қозғалатын нәрсе. Тиісінше, ол ешкімнен мүлде сұрамай-ақ, кез келген нәрсені қалаған кезде жылжыта алады. Сондықтан осыған сену керек. Бір данада іске қосылғанның бәрі ерте ме, кеш пе сәтсіздікке ұшырайды. Неғұрлым көп брондау болса, соғұрлым жақсы. Бірақ тағы айтамын, егер сізде осындай бірнеше файлдар болса, оларды дәл астыңызға қоюға болады, олардың салмағы аз. Егер олар аздап көп болса, оларды контейнерге итермеу керек.
Мен Кубернетесте осындай керемет нәрсе бар екеніне кеңес берер едім, сіз көлемді пайдалана аласыз. Атап айтқанда, бос dir түрінің көлемі бар. Яғни, Kubernetes сіз бастаған сервердегі қызмет каталогтарында автоматты түрде каталог жасайды. Ал ол сізге оны пайдалануыңыз үшін береді. Бір ғана маңызды мәселе бар. Яғни, сіздің деректеріңіз контейнер ішінде емес, сіз іске қосылған хостта сақталады. Сонымен қатар, Кубернетес қалыпты конфигурацияда мұндай бос директорларды басқара алады және олардың максималды өлшемін басқара алады және одан асып кетуге жол бермейді. Жалғыз мәселе - бос каталогта жазғандарыңыз подкастты қайта іске қосу кезінде жоғалмайды. Яғни, егер сіздің поддон қателесіп құлап, қайтадан көтерілсе, бос дирдегі ақпарат ешқайда кетпейді. Ол оны жаңадан қолдана алады - бұл жақсы. Егер сіздің подъездіңіз бір жерден кетсе, онда ол, әрине, деректерсіз кетеді. Яғни, бос дирмен іске қосылған түйіннен подкаст жоғалған кезде бос дир жойылады.
Бос режиссурадан басқа не жақсы? Мысалы, оны кэш ретінде пайдалануға болады. Біздің қолданба бірден бір нәрсені жасайды, оны пайдаланушыларға береді және оны ұзақ уақыт жасайды деп елестетіп көрейік. Сондықтан, мысалы, қолданба оны жасайды және пайдаланушыларға береді, сонымен бірге оны бір жерде сақтайды, осылайша пайдаланушы келесі жолы сол нәрсе үшін келгенде, оны дереу генерациялау үшін беру жылдамырақ болады. Бос директорды жадта жасау үшін Кубернетеске сұрауға болады. Осылайша, сіздің кэштеріңіз әдетте найзағай жылдамдығымен жұмыс істей алады - дискіге кіру жылдамдығы бойынша. Яғни, жадта бос dir бар, ОЖ-да ол жадта сақталады, бірақ сіз үшін, подкаст ішіндегі пайдаланушы үшін ол жай ғана жергілікті каталог сияқты көрінеді. Кез келген сиқырды арнайы үйрету үшін қолданба қажет емес. Сіз өзіңіздің файлыңызды тікелей алып, каталогқа қоясыз, бірақ шын мәнінде ОЖ жадында. Бұл сонымен қатар Kubernetes тұрғысынан өте ыңғайлы мүмкіндік.
Minio-ның қандай проблемалары бар? Minio-ның басты мәселесі мынада, бұл нәрсе жұмыс істеуі үшін ол бір жерде жұмыс істеп тұруы керек және файлдық жүйенің қандай да бір түрі, яғни сақтау орны болуы керек. Міне, біз Сеф сияқты проблемаларға тап боламыз. Яғни Minio файлдарын бір жерде сақтауы керек. Бұл жай ғана файлдарыңызға арналған HTTP интерфейсі. Сонымен қатар, функционалдық Amazon S3-ке қарағанда нашар. Бұрын ол пайдаланушыны дұрыс авторизациялай алмаған. Енді, менің білуімше, ол әртүрлі рұқсаттары бар шелектерді жасай алады, бірақ менің ойымша, негізгі мәселе, былайша айтқанда, ең аз дегенде негізгі сақтау жүйесі болып табылады.
Жадтағы бос каталог шектеулерге қалай әсер етеді? Бұл шектеулерге ешқандай әсер етпейді. Ол сіздің контейнеріңіздің жадында емес, хосттың жадында жатыр. Яғни, сіздің контейнер жадтағы бос каталогты оның бос тұрған жадының бөлігі ретінде көрмейді. Үй иесі мұны көреді. Тиісінше, иә, кубернеттердің көзқарасы бойынша, сіз мұны қолдана бастағанда, жадыңыздың бір бөлігін бос дирге арнағаныңызды түсінгеніңіз жөн. Тиісінше, жад тек қолданбалардан ғана емес, сонымен қатар біреу осы бос дирлерге жазғандықтан таусылуы мүмкін екенін түсініңіз.
Бұлттылық
Ал соңғы тақырып - бұл Cloudnative. Ол не үшін қажет? Бұлттылық және т.б.
Яғни, заманауи бұлттық инфрақұрылымда жұмыс істеуге қабілетті және жазылған қолданбалар. Бірақ, шын мәнінде, Cloudnative-тің басқа аспектісі бар. Бұл заманауи бұлттық инфрақұрылымның барлық талаптарын ескеретін қолданба ғана емес, сонымен қатар осы заманауи бұлттық инфрақұрылыммен қалай жұмыс істеу керектігін, оның осы бұлттарда жұмыс істеуінің артықшылықтары мен кемшіліктерін пайдалануды біледі. Тек шектен шығып, бұлттарда жұмыс істемеңіз, бұлтта жұмыс істеудің артықшылықтарын пайдаланыңыз.
Мысал ретінде Кубернетесті алайық. Қолданбаңыз Kubernetes жүйесінде жұмыс істейді. Қолданбаңыз әрқашан, дәлірек айтқанда, қолданбаңыздың әкімшілері әрқашан қызмет тіркелгісін жасай алады. Яғни, Kubernetes серверіндегі авторизацияға арналған тіркелгі. Онда бізге қажет құқықтарды қосыңыз. Сондай-ақ сіз Kubernetes қолданбаңыздан қол жеткізе аласыз. Сіз бұл жолмен не істей аласыз? Мысалы, қолданбадан басқа қолданбаларыңыздың, басқа ұқсас даналарыңыздың қай жерде орналасқаны туралы деректерді алыңыз және қажет болса, қандай да бір түрде Kubernetes үстіне кластер жасаңыз.
Тағы да, жақында бізде бір оқиға болды. Бізде кезекті бақылайтын бір контроллер бар. Осы кезекте кейбір жаңа тапсырмалар пайда болған кезде, ол Кубернетеске өтеді және Кубернетес ішінде ол жаңа подкаст жасайды. Осы подкастқа кейбір жаңа тапсырма береді және осы подкасттың шеңберінде подвод тапсырманы орындайды, контроллердің өзіне жауап жібереді, содан кейін контроллер осы ақпаратпен бірдеңе жасайды. Мысалы, ол дерекқорды қосады. Яғни, бұл біздің қосымшамыздың Kubernetes-те жұмыс істейтіндігінің артықшылығы. Қолданбамыздың функционалдығын қандай да бір жолмен кеңейту және ыңғайлы ету үшін біз кірістірілген Kubernetes функционалдығын пайдалана аламыз. Яғни, қолданбаны іске қосу, жұмысшыны қалай іске қосу туралы қандай да бір сиқырды жасырмаңыз. Kubernetes-те, егер бағдарлама Python тілінде жазылған болса, қолданбаға жай ғана сұрау жібересіз.
Егер біз Кубернетес шегінен шығатын болсақ, дәл солай болады. Бізде Кубернетес бір жерде жұмыс істейді - бұл бұлтта болса жақсы. Тағы да, біз жұмыс істеп жатқан жерде бұлттың мүмкіндіктерін пайдалана аламыз және тіпті пайдалануымыз керек деп ойлаймын. Бұлт бізге беретін қарапайым нәрселерден. Баланстау, яғни біз бұлтты теңгергіштерді жасап, оларды пайдалана аламыз. Бұл біз пайдалана алатын нәрсенің тікелей артықшылығы. Өйткені бұлтты теңгерімдеу, біріншіден, оның қалай жұмыс істейтіні, конфигурацияланғаны үшін жауапкершілікті бізден ақымақтықпен алып тастайды. Сонымен қатар, бұл өте ыңғайлы, өйткені кәдімгі Кубернеттер бұлттармен біріктіре алады.
Масштабтау үшін де солай. Тұрақты Kubernetes бұлт провайдерлерімен біріктіре алады. Кластерде түйіндер бітсе, яғни түйін кеңістігі таусылып қалса, онда қосу керек екенін қалай түсінуге болатынын біледі - Kubernetes өзі кластерге жаңа түйіндерді қосады және оларда түйіндерді іске қоса бастайды. Яғни, жүгің келгенде ошақтың саны көбейе бастайды. Кластердегі түйіндер осы қосқыштар үшін таусылғанда, Kubernetes жаңа түйіндерді іске қосады және сәйкесінше, түйіндер саны әлі де көбеюі мүмкін. Және бұл өте ыңғайлы. Бұл кластерді жылдам масштабтаудың тікелей мүмкіндігі. Өте жылдам емес, бұл секунд емес, жаңа түйіндерді қосу үшін бір минут сияқты.
Бірақ менің тәжірибемнен қайталаймын, бұл мен көрген ең керемет нәрсе. Cloudnative кластері тәулік уақытына қарай масштабталған кезде. Бұл бэк-офистегі адамдар пайдаланатын бэкенд қызметі болды. Яғни, олар жұмысқа таңғы сағат 9-да келіп, жүйеге кіре бастайды, сәйкесінше, барлығы жұмыс істейтін Cloudnative кластері ісініп, жұмысқа келгендердің барлығы қосымшамен жұмыс істей алатындай жаңа блоктарды іске қосады. Олар жұмыстан кешкі сағат 8 немесе 6-де шыққан кезде, Кубернетес кластерлері қолданбаны енді ешкім пайдаланбайтынын байқап, кішірейе бастайды. 30 пайызға дейін үнемдеуге кепілдік беріледі. Ол кезде Amazon-да жұмыс істеді, ол кезде Ресейде мұны жақсы жасай алатын ешкім жоқ еді.
Мен сізге нақты айтамын, үнемдеу 30 пайызды құрайды, өйткені біз Kubernetes-ті қолданамыз және бұлт мүмкіндіктерін пайдаланамыз. Енді мұны Ресейде де жасауға болады. Мен, әрине, ешкімге жарнама бермеймін, бірақ мұны істей алатын провайдерлер бар деп айтайық, оны қораптан шығып, түймемен қамтамасыз етіңіз.
Соңғы бір жайт бар, оған да назар аударғым келеді. Қолданбаңыз, инфрақұрылымыңыз Cloudnative болуы үшін, ақырында, Инфрақұрылым деп аталатын тәсілді код ретінде бейімдеуді бастау мағынасы бар. Яғни, сіздің қолданбаңыз, дәлірек айтсақ, сіздің инфрақұрылымыңыз дәл осындай қажет екенін білдіреді. код Қолданбаңызды, бизнес логикаңызды код түрінде сипаттаңыз. Онымен код ретінде жұмыс жасаңыз, яғни оны сынап көріңіз, шығарыңыз, git-де сақтаңыз, оған CICD қолданыңыз.
Бұл, біріншіден, әрқашан өз инфрақұрылымыңызды бақылауға, оның қандай күйде екенін түсінуге мүмкіндік беретін нәрсе. Екіншіден, қателерді тудыратын қолмен жұмыс істеуден аулақ болыңыз. Үшіншіден, қолмен бірдей тапсырмаларды үнемі орындау қажет болғанда, жай айналым деп аталатын нәрседен аулақ болыңыз. Төртіншіден, ол істен шыққан жағдайда әлдеқайда жылдам қалпына келтіруге мүмкіндік береді. Ресейде мен бұл туралы айтқан сайын: «Иә, түсінікті, бірақ сізде тәсілдер бар, қысқасы, ештеңені түзетудің қажеті жоқ» деп айтатын адамдар көп. Бірақ бұл шындық. Егер сіздің инфрақұрылымыңызда бірдеңе бұзылса, оны түзетіп, серверге кіріп, ненің бұзылғанын анықтап, оны жөндегеннен гөрі Cloudnative көзқарасы тұрғысынан және код ретіндегі инфрақұрылым тұрғысынан қарағанда, оңайырақ. серверді жойып, оны қайта жасау үшін. Мен мұның бәрін қалпына келтіремін.
Барлық осы мәселелер толығырақ мына жерде талқыланады . Сілтемеге өту арқылы сіз бағдарламамен және шарттармен таныса аласыз. Ыңғайлысы, сіз үйде немесе күніне 1-2 сағат жұмыс істеу арқылы Кубернетесті меңгере аласыз.
Ақпарат көзі: www.habr.com