Денеска планирам да зборувам за тоа како да пишувате апликации и кои се барањата за вашата апликација да работи добро во Кубернетес. За да нема главоболки со апликацијата, за да не треба да измислувате и да градите какви било „гребнатини“ околу неа - и сè работи како што замислил самиот Кубернет.
Ова предавање е дел од „" Можете да ги погледнете отворените теоретски предавања на Вечерната школа . За оние кои претпочитаат текст наместо видео, го подготвивме овој напис.
Јас се викам Павел Селиванов, моментално сум водечки инженер за DevOps во Mail.ru Cloud Solutions, правиме облаци, правиме кубернети за управување и така натаму. Моите задачи сега вклучуваат помош во развојот, ширење на овие облаци, ширење на апликациите што ги пишуваме и директно развивање на алатките што ги обезбедуваме за нашите корисници.
Правам DevOps, мислам дека последните, веројатно, три години. Но, во принцип, јас го правам она што го прави DevOps веројатно околу пет години. Пред тоа, јас најмногу се занимавав со администраторски работи. Почнав да работам со Kubernetes одамна - веројатно поминаа околу четири години откако почнав да работам со него.
Во принцип, почнав кога Kubernetes беше верзија 1.3, веројатно, а можеби и 1.2 - кога сè уште беше во повој. Сега веќе не е во повој - и очигледно е дека на пазарот има огромна побарувачка за инженери кои би сакале да можат да работат Кубернетес. И компаниите имаат многу голема побарувачка за такви луѓе. Затоа, всушност, се појави ова предавање.
Ако зборуваме според планот за што ќе зборувам, изгледа вака, во загради пишува (TL;DR) - „премногу долго; не читај“. Мојата денешна презентација ќе се состои од бескрајни списоци.
Всушност, јас самиот не сакам такви презентации кога се прават, но ова е таква тема што кога ја подготвував оваа презентација, едноставно не сфатив како да ги организирам овие информации поинаку.
Бидејќи, во голема мера, овие информации се „ctrl+c, ctrl+v“, од, меѓу другото, од нашето Вики во делот DevOps, каде што имаме напишани барања за програмерите: „момци, за да ја стартуваме вашата апликација во Кубернетес, треба да биде вака“.
Затоа презентацијата се покажа како толку голема листа. Извинете. Ќе се обидам да кажам што повеќе за да не е досадно ако е можно.
Што ќе разгледаме сега:
- ова се, прво, дневници (дневници на апликации?), што да се прави со нив во Кубернет, што да се прави со нив, што треба да бидат;
- што да се прави со конфигурациите во Kubernetes, кои се најдобрите и најлошите начини за конфигурирање на апликација за Kubernetes;
- Ајде да разговараме за тоа какви се проверките за пристапност воопшто, како тие треба да изгледаат;
- ајде да разговараме за тоа што е благодатно исклучување;
- ајде повторно да зборуваме за ресурсите;
- Ајде уште еднаш да ја допреме темата за складирање податоци;
- и на крајот ќе ви кажам каков е терминот оваа мистериозна апликација од облак. Облачност, како придавка на овој поим.
Дневници
Предлагам да започнете со дневниците - со тоа каде овие логови треба да се туркаат во Кубернетес. Сега лансиравте апликација во Кубернетес. Според класиците, претходно апликациите секогаш пишувале дневници некаде во датотека. Лошите апликации напишаа дневници во датотека во домашниот директориум на развивачот кој ја стартуваше апликацијата. Добрите апликации напишаа дневници на датотека некаде внатре /var/log.
Според тоа, понатаму, добрите администратори имаа конфигурирани некои работи во нивните инфраструктури што овие дневници може да ги ротираат - истиот rsyslog, кој ги гледа овие дневници и кога ќе им се случи нешто, ги има многу, создава резервни копии, става логови таму , брише стари датотеки, повеќе од една недела, шест месеци и уште некои. Теоретски, треба да имаме одредби за едноставно затоа што апликацијата пишува логови, просторот на производствените сервери (борбени сервери?) да не истекува. И, соодветно, целото производство не запре поради трупците.
Кога ќе се преселиме во светот на Кубернетите и ќе го извршиме истото таму, првото нешто на што можете да обрнете внимание е фактот дека луѓето, како што напишале дневници во датотека, продолжуваат да ги пишуваат.
Излегува дека ако зборуваме за Kubernetes, вистинското место за пишување логови некаде од докер контејнер е едноставно да ги напишете од апликацијата до таканаречените Stdout/Stderr, односно стандардните излезни струи на оперативниот систем, стандардниот излез за грешка. Ова е најправилниот, наједноставниот и најлогичен начин да се стават логовите во принцип во Docker и конкретно во Kubernetis. Затоа што ако вашата апликација пишува дневници на Stdout/Stderr, тогаш останува на Docker и додатокот Kubernetes да одлучат што да прават со овие дневници. Докер стандардно ќе ги изгради своите специјални датотеки во JSON формат.
Тука се поставува прашањето, што ќе правите понатаму со овие трупци? Најлесниот начин е јасен, ние имаме способност да направиме kubectl logs и погледнете ги овие трупци на овие „мешули“. Но, веројатно, ова не е многу добра опција - треба да се направи нешто друго со дневниците.
Засега, ајде да разговараме во исто време, бидејќи ја допревме темата за дневници, за такво нешто како што треба да изгледаат дневниците. Односно, ова не се однесува директно на Kubernetes, но кога ќе почнеме да размислуваме што да правиме со логовите, би било добро да размислиме и за ова.
Потребен ни е некој вид алатка, на пријателски начин, што ќе ги земе овие логови што нашиот докер ги става во своите датотеки и ќе ги испрати некаде. Во голема мера, ние обично лансираме некој вид агент во Кубернетс во форма на DaemonSet - собирач на дневници, на кој едноставно се кажува каде се наоѓаат дневниците што ги собира Docker. И овој собирен агент едноставно ги зема, можеби дури и некако ги анализира по пат, можеби ги збогатува со некои дополнителни мета-информации и, на крајот, ги испраќа некаде на складирање. Таму веќе се можни варијации. Најчестиот е веројатно Elasticsearch, каде што можете да складирате логови и можете лесно да ги извадите од таму. Потоа, користејќи барање, користејќи Kibana, на пример, изградете графикони врз основа на нив, изградете предупредувања врз основа на нив и така натаму.
Најважната идеја, сакам да ја повторам повторно, е дека внатре во Docker, особено во Кубернетес, складирањето на вашите дневници во датотека е многу лоша идеја.
Затоа што прво, тешко е да се внесат дневниците во контејнерот во датотека. Прво мора да отидете во контејнерот, да извршите таму, а потоа да ги погледнете дневниците. Следниот момент е дека ако имате логови во датотека, тогаш контејнерите обично имаат минималистичка средина и нема комунални услуги што обично се потребни за нормална работа со логови. Закопајте ги, погледнете ги, отворете ги во текстуален уредувач. Следниот момент е кога имаме логови во датотека во контејнер, ако овој контејнер е избришан, разбирате, дневниците ќе умрат заедно со него. Според тоа, секое рестартирање на контејнерот значи дека нема повеќе трупци. Повторно, лоша опција.
И последната точка е дека во контејнерите обично ја имате вашата апликација и тоа е тоа - тоа е обично единствениот процес што работи. Воопшто не се зборува за кој било процес кој би ги ротирал датотеките со вашите дневници. Штом дневниците почнат да се запишуваат во датотека, тоа значи дека, извинете, ќе почнеме да го губиме серверот за производство. Затоа што, прво, тешко се наоѓаат, никој не ги следи, плус никој не ги контролира - соодветно, датотеката расте бескрајно додека просторот на серверот едноставно не истече. Затоа, повторно велам дека најавувањето на Docker, особено во Kubernetes, во датотека е лоша идеја.
Следната точка, овде сакам повторно да зборувам за ова - бидејќи ја допираме темата за дневници, би било добро да разговараме за тоа како треба да изгледаат дневниците за да биде погодно да се работи со нив. Како што реков, темата не е директно поврзана со Kubernetes, но многу добро се однесува на темата на DevOps. На тема развојна култура и пријателство помеѓу овие два различни одделенија - Dev и Ops, така што на сите им е удобно.
Ова значи дека идеално, денес, дневниците треба да се пишуваат во JSON формат. Ако имате некоја ваша неразбирлива апликација, која запишува дневници во неразбирливи формати затоа што вметнувате некаков вид печатење или слично, тогаш време е да гуглате некаква рамка, некаков вид обвивка што ви овозможува да спроведете нормално логирање; овозможете ги параметрите за логирање во JSON таму, бидејќи JSON е едноставен формат, неговото парсирање е едноставно.
Ако вашиот JSON не работи според некои критериуми, никој не знае што, тогаш барем напишете дневници во формат што може да се анализира. Тука, попрво, вреди да се размислува за фактот дека, на пример, ако управувате со куп контејнери или само обработувате со nginx, и секој има свои поставки за логирање, тогаш веројатно се чини дека ќе ви биде многу незгодно да анализирајте ги. Затоа што за секој нов примерок на nginx треба да напишете свој парсер, бидејќи тие пишуваат логови поинаку. Повторно, веројатно вредеше да се размислува за тоа дали сите овие примероци на nginx ја имаат истата конфигурација за логирање и ги напишаа сите нивни дневници апсолутно подеднакво. Истото важи и за апсолутно сите апликации.
На крајот, исто така сакам да додадам масло на огнот дека, идеално, треба да се избегнуваат дневници со повеќелиниски формати. Еве ја работата, ако некогаш сте работеле со собирачи на трупци, тогаш најверојатно сте виделе што ви ветуваат, дека можат да работат со трупци со повеќе линии, да знаат како да ги соберат итн. Всушност, според мене, ниту еден собирач денес не може нормално, целосно и без грешки да собере повеќелиниски дневници. На човечки начин, за да биде погодно и без грешки.
Но, оџакот е секогаш логови со повеќе линии и како да ги избегнете. Прашањето овде е дека дневникот е запис на настан, а stactrace всушност не е дневник. Ако собереме логови и ги ставиме некаде во Elasticsearch и потоа цртаме графикони од нив, изградиме некои извештаи за активноста на корисниците на вашата страница, тогаш кога ќе добиете трага на стек, тоа значи дека се случува нешто неочекувано во вашата апликација. И има смисла автоматски да се вчита трага на стек некаде во систем што може да ги следи.
Ова е софтвер (ист Sentry) кој е направен специјално за работа со stack trace. Може веднаш да креира автоматизирани задачи, да ги додели некому, да предупредува кога ќе се појават stacttraces, да ги групира овие stacttraces по еден тип итн. Во принцип, нема многу смисла да се зборува за стактраци кога зборуваме за трупци, бидејќи тоа се, на крајот на краиштата, различни работи со различни цели.
Конфигурација
Следно, зборуваме за конфигурација во Kubernetes: што да правиме со неа и како треба да се конфигурираат апликациите во Kubernetes. Во принцип, обично велам дека Докер не е за контејнери. Секој знае дека Docker е за контејнери, дури и оние кои не работеле многу со Docker. Повторувам, Докер не е за контејнери.
Докер, според мене, е за стандарди. И постојат стандарди за практично сè: стандарди за градење на вашата апликација, стандарди за инсталирање на вашата апликација.
И ова нешто - го користевме претходно, стана особено популарно со појавата на контејнерите - ова нешто се нарекува ENV (еколошки) променливи, односно променливи на животната средина што се во вашиот оперативен систем. Ова е генерално идеален начин да ја конфигурирате вашата апликација, бидејќи ако имате апликации во JAVA, Python, Go, Perl, не дај Боже, и сите тие можат да го читаат домаќинот на базата на податоци, корисникот на базата на податоци, променливите за лозинка на базата на податоци, тогаш тоа е идеално. Имате апликации на четири различни јазици конфигурирани во планот на базата на податоци на ист начин. Нема повеќе различни конфигурации.
Сè може да се конфигурира со користење на ENV променливи. Кога зборуваме за Kubernetes, постои одличен начин да се декларираат променливите ENV директно во Deployment. Според тоа, ако зборуваме за тајни податоци, тогаш можеме веднаш да ги туркаме тајните податоци од променливите ENV (лозинки за бази на податоци итн.) во тајна, да создадеме таен кластер и да означиме во описот ENV во Deployment дека не објавуваме директно вредноста на оваа променлива и вредноста на оваа променлива лозинка за базата на податоци ќе се читаат од тајната. Ова е стандардно однесување на Кубернет. И ова е најидеалната опција за конфигурирање на вашите апликации. Само на ниво на код, повторно ова се однесува на програмерите. Ако сте DevOps, можете да прашате: „Момци, ве молиме научете ја вашата апликација да чита променливи на околината. И сите ќе бидеме среќни“.
Ако сите во компанијата ги читаат истите именувани променливи на животната средина, тогаш тоа е одлично. За да не се случи некои да ја чекаат базата на податоци на постгрес, други да го чекаат името на базата на податоци, други да чекаат нешто друго, други да чекаат некој вид dbn, така што, соодветно, има униформност.
Проблемот доаѓа кога имате толку многу променливи на околината што само го отворате Deployment - и има петстотини линии променливи на околината. Во овој случај, едноставно ги надминавте променливите на околината - и повеќе не треба да се измачувате себеси. Во овој случај, би имало смисла да започнете со користење на конфигурации. Односно, обучете ја вашата апликација да користи конфигурации.
Единственото прашање е дека конфигурациите не се она што мислите. Config.pi не е конфигурација што е погодна за користење. Или некоја конфигурација во ваш сопствен формат, алтернативно надарена - ова исто така не е конфигурацијата што мислам.
Она за што зборувам е конфигурација во прифатливи формати, односно убедливо најпопуларен стандард е стандардот .yaml. Јасно е како се чита, читливо е од човек, јасно е како се чита од апликацијата.
Соодветно на тоа, покрај YAML, можете, на пример, да користите JSON, парсирањето е приближно погодно како YAML во смисла на читање на конфигурацијата на апликацијата од таму. Забележливо е понезгодно за луѓето да читаат. Можете да го пробате форматот, a la ini. Сосема е погодно за читање, од човечка гледна точка, но можеби е незгодно да се обработува автоматски, во смисла дека ако некогаш сакате да генерирате свои конфигурации, форматот ini веќе може да биде незгоден за генерирање.
Но, во секој случај, каков формат и да одберете, поентата е дека од гледна точка на Кубернет е многу погодно. Можете да ја ставите целата ваша конфигурација во Kubernetes, во ConfigMap. И потоа земете ја оваа конфигурациона карта и побарајте да биде монтирана во вашиот подлога во некој специфичен директориум, каде што вашата апликација ќе ја чита конфигурацијата од оваа конфигурациона мапа како да е само датотека. Ова, всушност, е она што е добро да се направи кога имате многу опции за конфигурација во вашата апликација. Или тоа е само некаква сложена структура, има гнездење.
Ако имате конфигурациона мапа, тогаш многу добро можете да ја научите вашата апликација, на пример, автоматски да ги следи промените во датотеката каде што е монтирана конфигурационата мапа, а исто така автоматски да ја вчитате вашата апликација кога ќе се променат конфигурациите. Ова генерално би била идеална опција.
Повторно, веќе зборував за ова - тајните информации не се во конфигмапата, тајните информации не се во променливи, тајните информации не се во тајни. Оттаму, поврзете ја оваа тајна информација со дипломатијата. Обично ги складираме сите описи на Кубернетес објекти, распоредувања, конфигмапи, услуги во git. Според тоа, ставањето на лозинката во базата на податоци во git, дури и ако тоа е вашиот git, кој го имате внатрешно во компанијата, е лоша идеја. Затоа што, во најмала рака, git памти сè и едноставно отстранувањето на лозинките од таму не е толку лесно.
Здравствен преглед
Следната точка е оваа работа наречена здравствена проверка. Општо земено, здравствената проверка е едноставно проверка дали вашата апликација работи. Во исто време, најчесто станува збор за одредени веб-апликации, за кои, соодветно, од гледна точка на здравствена проверка (подобро е да не се преведува овде и понатаму) ова ќе биде некој посебен URL, кој тие го обработуваат како стандард, тие обично го прават /health.
Кога пристапуваме до овој URL, соодветно, нашата апликација вели или „да, во ред, се е во ред со мене, 200“ или „не, сè не е во ред со мене, некои 500“. Соодветно на тоа, ако нашата апликација не е http, а не веб-апликација, сега зборуваме за некој вид демон, можеме да сфатиме како да правиме здравствени проверки. Тоа е, не е потребно, ако апликацијата не е http, тогаш сè работи без здравствена проверка и тоа не може да се направи на кој било начин. Можете периодично да ажурирате некои информации во датотеката, можете да излезете со некоја посебна команда за вашиот демон, како, daemon status, кој ќе каже „да, сè е во ред, демонот работи, тој е жив“.
За што е? Првата и најочигледна работа е веројатно зошто е потребна здравствена проверка - да се разбере дека апликацијата работи. Мислам, едноставно е глупаво, кога е сега, изгледа како да работи, па можете да бидете сигурни дека работи. И излегува дека апликацијата работи, контејнерот работи, примерокот работи, сè е во ред - а потоа корисниците веќе ги отсекоа сите телефонски броеви од техничката поддршка и велат „што си ти..., ти заспа, ништо не работи“.
Здравствената проверка е токму таков начин да се види од гледна точка на корисникот дека функционира. Еден од методите. Ајде да го ставиме вака. Од гледна точка на Kubernetes, ова е исто така начин да се разбере кога започнува апликацијата, бидејќи разбираме дека постои разлика помеѓу кога контејнерот бил лансиран, креиран и стартуван и кога апликацијата била лансирана директно во овој контејнер. Затоа што ако земеме некоја просечна java апликација и се обидеме да ја лансираме во пристаништето, тогаш за четириесет секунди, па дури и една минута, па дури и десет, може да започне добро. Во овој случај, можете барем да тропнете на неговите пристаништа, тој нема да одговори таму, односно сè уште не е подготвен да прима сообраќај.
Повторно, со помош на здравствена проверка и со помош на фактот што се вртиме овде, можеме да разбереме во Кубернетес дека не само што контејнерот се кренал во апликацијата, туку и самата апликација започнала, таа веќе одговара на здравствена проверка, што значи дека можеме да испратиме сообраќај таму.
Она за што зборувам сега се нарекуваат тестови за подготвеност/живост во рамките на Kubernetes, соодветно, нашите тестови за подготвеност се одговорни за достапноста на апликацијата при балансирање; Односно, ако се направат тестови за подготвеност во апликацијата, тогаш сè е во ред, сообраќајот на клиентите оди кон апликацијата. Ако не се извршат тестови за подготвеност, тогаш апликацијата едноставно не учествува, овој конкретен пример не учествува во балансирањето, се отстранува од балансирањето и сообраќајот на клиентите не тече. Соодветно на тоа, потребни се тестови за Liveness во Kubernetes, така што ако апликацијата се заглави, може да се рестартира. Ако тестот за живост не работи за апликација што е декларирана во Kubernetes, тогаш апликацијата не само што се отстранува од балансирањето, туку се рестартира.
И еве една важна точка што би сакал да ја спомнам: од практична гледна точка, тестот за подготвеност обично се користи почесто и е почесто потребен од тестот за живост. Односно, едноставно непромислено објавување и тестови за подготвеност и живост, затоа што Кубернетис може да го направи тоа, а ајде да искористиме сè што може да направи, не е многу добра идеја. Ќе објаснам зошто. Бидејќи точката број два во тестирањето е дека би било добра идеја да ја проверите основната услуга во вашите здравствени проверки. Ова значи дека ако имате веб-апликација која дава некои информации, кои за возврат, нормално, мора да ги преземе од некаде. Во базата на податоци, на пример. Па, ги зачувува информациите што доаѓаат во овој REST API во истата база на податоци. Потоа, соодветно, ако вашата здравствена проверка одговори едноставно како контактирана slashhealth, апликацијата вели „200, во ред, сè е во ред“, а во исто време базата на податоци на вашата апликација е недостапна, а апликацијата за здравствена проверка вели „200, во ред, сè е во ред “ - Ова е лоша здравствена проверка. Ова не треба да функционира.
Тоа е, вашата апликација, кога ќе дојде барање до неа /health, не одговара само „200, ок“, прво оди, на пример, во базата на податоци, се обидува да се поврзе со неа, прави нешто многу основно таму, како изберете еден, само проверува дали има врска во база на податоци и можете да ја побарате базата на податоци. Ако сето ова беше успешно, тогаш одговорот е „200, во ред“. Ако не е успешен, пишува дека има грешка, базата е недостапна.
Затоа, во овој поглед, повторно се враќам на тестовите за подготвеност/живост - зошто најверојатно ви треба тест за подготвеност, но тест за живост е во прашање. Затоа што ако ги опишете здравствените проверки точно како што кажав, тогаш ќе испадне дека не е достапен во делот за инстанцав или со всех instanceво базата на податоци, на пример. Кога прогласивте тест за подготвеност, нашите здравствени проверки почнаа да не успеваат, и соодветно на сите апликации од кои не е достапна базата, тие едноставно се исклучени од балансирање и всушност „висат“ само во занемарена состојба и чекаат нивните бази на податоци да се работа.
Ако сме прогласиле тест за живост, тогаш замислете, нашата база на податоци е скршена и во вашиот Кубернетс половина од сè почнува да се рестартира бидејќи тестот за живост не успева. Ова значи дека треба да се рестартира. Воопшто не е тоа што го сакате, дури имав лично искуство во пракса. Имавме апликација за разговор што беше напишана во JS и внесена во базата на податоци на Mongo. И проблемот беше што беше на почетокот на мојата работа со Кубернетис, ја опишавме подготвеноста, живоста на тестовите на принципот дека Кубернетис може да го направи тоа, па ќе го искористиме. Според тоа, во одреден момент Монго стана малку „тапа“ и примерокот почна да пропаѓа. Според тоа, според тестот за дожд, мешунките почнаа да „убиваат“.
Како што разбирате, кога тие се „убиваат“, ова е разговор, односно на него висат многу врски од клиенти. И тие се „убиваат“ - не, не клиенти, само врски - не сите во исто време, и поради фактот што не се убиени во исто време, некои порано, некои подоцна, не започнуваат истовремено. време. Плус стандардно случаен избор, не можеме со точност од милисекунди да го предвидиме времето на започнување на апликацијата секој пат, па тие го прават тоа еден по еден пример. Се крева една инфо-точка, се додава на балансирањето, таму доаѓаат сите клиенти, не може да издржи толкав товар, затоа што е сам, а грубо кажано, таму работат десетина, па паѓа. Следниот се крева, целиот товар е на него, и тој паѓа. Па, овие водопади само продолжуваат да каскадираат. На крајот, како се реши ова - само требаше строго да го запреме корисничкиот сообраќај кон оваа апликација, да ги оставиме сите инстанци да се зголемат и потоа да го започнеме целиот кориснички сообраќај одеднаш, така што тој веќе беше дистрибуиран меѓу сите десет примероци.
Да не беше најавен овој тест за живост, кој ќе го принуди сето тоа да се рестартира, апликацијата добро ќе се справи со тоа. Но, сè од балансирање ни е оневозможено, бидејќи базите на податоци се недостапни и сите корисници „паднаа“. Потоа, кога оваа база на податоци ќе стане достапна, сè е вклучено во балансирањето, но апликациите не треба да се стартуваат повторно и нема потреба да трошите време и ресурси за ова. Сите тие се веќе тука, подготвени се за сообраќај, па сообраќајот само се отвора, се е во ред - апликацијата е поставена, сè продолжува да работи.
Затоа, тестовите за подготвеност и живост се различни, уште повеќе, теоретски можете да правите различни здравствени проверки, еден тип радиуси, еден тип liv, на пример, и да проверувате различни работи. За време на тестовите за подготвеност, проверете ги вашите задни делови. И на тест за живост, на пример, не проверувате од гледна точка дека тестот за живост е генерално само апликација која реагира, ако воопшто може да одговори.
Бидејќи тестот за живост, во голема мера, е кога сме „заглавени“. Започна бескрајна јамка или нешто друго - и не се обработуваат повеќе барања. Затоа, има смисла дури и да се разделат - и да се имплементира различна логика во нив.
Во однос на тоа што треба да одговорите кога правите тест, кога правите здравствени контроли. Тоа е само навистина болка. Оние кои се запознаени со ова веројатно ќе се насмеат - но сериозно, сум видел услуги во мојот живот кои одговараат „200“ во XNUMX% од случаите. Односно кој е успешен. Но, во исто време во телото на одговорот пишуваат „таква и таква грешка“.
Тоа е, статусот на одговор доаѓа кај вас - сè е успешно. Но, во исто време, мора да го анализирате телото, бидејќи телото вели „извинете, барањето заврши со грешка“ и ова е само реалност. Го видов ова во реалниот живот.
И така што на некои луѓе не им е смешно, а на други им е многу болно, сепак вреди да се придржувате до едноставно правило. Во здравствени проверки, и во принцип при работа со веб-апликации.
Ако сè е добро, тогаш одговорете со двестетиот одговор. Во принцип, секој одговор од две стотини ќе ви одговара. Ако многу добро читате рагзи и знаете дека некои статуси на одговор се различни од другите, одговорете со соодветните: 204, 5, 10, 15, што и да е. Ако не е многу добро, тогаш само „две нула нула“. Ако сè оди лошо и здравствената проверка не реагира, тогаш одговорете со која било петстотинка. Повторно, ако разбирате како да одговорите, како различните статуси на одговор се разликуваат едни од други. Ако не разбирате, тогаш 502 е вашата опција да одговорите на здравствени проверки ако нешто тргне наопаку.
Ова е уште една точка, сакам да се вратам малку за проверка на основните услуги. Ако започнете, на пример, да ги проверувате сите основни услуги што стојат зад вашата апликација - сè воопшто. Она што го добиваме од гледна точка на микросервисната архитектура, имаме таков концепт како „ниска спојка“ - односно кога вашите услуги се минимално зависни едни од други. Ако еден од нив не успее, сите други без оваа функционалност едноставно ќе продолжат да работат. Некои од функционалноста едноставно не функционираат. Соодветно, ако ги врзете сите здравствени проверки еден за друг, тогаш ќе завршите со една работа која ќе пропадне во инфраструктурата, а бидејќи паднала, почнуваат да пропаѓаат и сите здравствени проверки на сите услуги - и воопшто има повеќе инфраструктура за целата микросервисна архитектура бр. Таму сè се стемни.
Затоа, сакам да го повторам ова уште еднаш дека треба да ги проверите основните услуги, оние без кои вашата апликација во сто проценти од случаите не може да ја заврши својата работа. Односно, логично е дека ако имате REST API преку кој корисникот зачувува во базата на податоци или презема од базата на податоци, тогаш во отсуство на база на податоци, не можете да гарантирате работа со вашите корисници.
Но, ако вашите корисници, кога ќе ги извадите од базата на податоци, дополнително се збогатени со некои други метаподатоци, од друг бекенд, кои ги внесувате пред да испратите одговор до предниот дел - а овој заден дел не е достапен, тоа значи дека го давате вашиот одговори без кој било дел од метаподатоците.
Следно, имаме и еден од болните проблеми при стартување апликации.
Всушност, ова не се однесува само на Kubernetes во голема мера, туку така се случи културата на некој вид масовен развој и DevOps особено да се шири во исто време како и Kubernetes. Затоа, во голема мера, излегува дека треба благодатно да ја исклучите вашата апликација без Kubernetes. Дури и пред Кубернетес, луѓето го правеа ова, но со доаѓањето на Кубернетес, почнавме масовно да зборуваме за тоа.
Благодатно исклучување
Во принцип, што е Graceful Shutdown и зошто е потребно? Ова е за кога вашата апликација паѓа поради некоја причина, треба да го направите app stop - или добивате, на пример, сигнал од оперативниот систем, вашата апликација мора да го разбере и да направи нешто во врска со тоа. Најлошото сценарио, се разбира, е кога вашата апликација ќе добие SIGTERM и е како „SIGTERM, ајде да продолжиме, работиме, не правиме ништо“. Ова е сосема лоша опција.
Речиси подеднакво лоша опција е кога вашата апликација добива SIGTERM и е како „рекоа segterm, тоа значи дека завршуваме, не сум видел, не знам никакви барања од корисникот, не знам каков барања на кои работам во моментов, тие рекоа SIGTERM, тоа значи дека завршуваме " Ова е исто така лоша опција.
Која опција е добра? Првата точка е да се земе предвид завршувањето на операциите. Добра опција е вашиот сервер сепак да земе предвид што прави ако добие SIGTERM.
SIGTERM е меко исклучување, специјално е дизајниран, може да се пресретнува на ниво на код, може да се обработи, кажи сега, чекај, прво ќе ја завршиме работата што ја имаме, па ќе излеземе.
Од перспектива на Кубернет, вака изгледа. Кога ќе му кажеме на подлогата што работи во кластерот Kubernetes, „те молам застани, оди си“, или ние сме рестартирани, или се случува ажурирање кога Kubernetes ги рекреира парчињата, Kubernetes ја испраќа истата порака SIGTERM до подлогата, чека некое време, и , ова е времето што го чека, исто така е конфигурирано, има таков посебен параметар во дипломите и се вика Graceful ShutdownTimeout. Како што разбирате, тоа не се нарекува така за џабе, и не е за џабе што зборуваме за тоа сега.
Таму конкретно можеме да кажеме колку време треба да чекаме помеѓу времето кога ќе го испратиме SIGTERM до апликацијата и кога ќе разбереме дека апликацијата се чини дека полудела по нешто или е „заглавена“ и нема да заврши - и треба да испратете го SIGKILL, односно напорно завршете ја неговата работа. Тоа е, соодветно, имаме некој вид демон кој работи, тој обработува операции. Разбираме дека во просек нашите операции на кои работи демонот не траат повеќе од 30 секунди одеднаш. Според тоа, кога ќе пристигне SIGTERM, разбираме дека нашиот демон може, најмногу, да заврши 30 секунди по SIGTERM. Го пишуваме, на пример, 45 секунди за секој случај и велиме дека SIGTERM. После тоа чекаме 45 секунди. Теоретски, за тоа време демонот требало да ја заврши својата работа и да заврши сам. Но, ако одеднаш не може, тоа значи дека најверојатно е заглавено - повеќе не ги обработува нашите барања нормално. И за 45 секунди можете безбедно, всушност, да го заковате.
И тука, всушност, може да се земат предвид дури и 2 аспекти. Прво, разберете дека ако сте примиле барање, сте почнале некако да работите со него и не сте дале одговор на корисникот, но сте добиле SIGTERM, на пример. Има смисла да се рафинира и да се даде одговор на корисникот. Ова е точка број еден во овој поглед. Поентата број два овде е дека ако напишете сопствена апликација, генерално ја изградите архитектурата на таков начин што ќе добиете барање за вашата апликација, тогаш започнувате некоја работа, почнувате да преземате датотеки од некаде, да преземате база на податоци и што уште не. Тоа. Во принцип, вашиот корисник, вашето барање виси половина час и чека да му одговорите - тогаш, најверојатно, треба да работите на архитектурата. Односно, земете го предвид дури и здравиот разум дека ако вашите операции се кратки, тогаш има смисла да го игнорирате SIGTERM и да го измените. Ако вашите операции се долги, тогаш нема смисла да го игнорирате SIGTERM во овој случај. Има смисла да се редизајнира архитектурата за да се избегнат толку долги операции. За корисниците да не се дружат и чекаат. Не знам, направете некој вид веб-сокет таму, направете обратни куки што вашиот сервер веќе ќе ги испрати до клиентот, што било друго, но не го терајте корисникот да виси половина час и само чекајте сесија додека не одговори му. Затоа што е непредвидливо каде може да се скрши.
Кога вашата апликација ќе заврши, треба да наведете соодветна шифра за излез. Односно, ако вашата апликација беше побарано да се затвори, запре и таа можеше да се запре нормално, тогаш не треба да враќате некој вид излезна шифра 1,5,255 и така натаму. Сè што не е нула код, барем во системите на Линукс, сигурен сум во ова, се смета за неуспешно. Односно, се смета дека вашата апликација во овој случај завршила со грешка. Според тоа, на пријателски начин, ако вашата апликација е завршена без грешка, велите 0 на излезот. Ако вашата апликација не успее поради некоја причина, велите не-0 на излезот. И можете да работите со овие информации.
И последната опција. Лошо е кога вашиот корисник испраќа барање и виси половина час додека го обработувате. Но, генерално, би сакал да кажам и за она што генерално вреди од страната на клиентот. Не е важно дали имате мобилна апликација, преден дел, итн. Неопходно е да се земе предвид дека генерално сесијата на корисникот може да се прекине, сè може да се случи. Барањето може да биде испратено, на пример, недоволно обработено и никаков одговор не е вратен. Вашиот преден дел или вашата мобилна апликација - кој било преден дел воопшто, ајде да го ставиме така - треба да го земе предвид ова. Ако работите со веб-сокети, ова е генерално најлошата болка што некогаш сум ја имал.
Кога развивачите на некои редовни разговори не знаат дека, се испоставува, веб-сокетот може да се скрши. За нив, кога нешто ќе се случи кај проксито, ние само ја менуваме конфигурацијата и таа повторно вчитува. Нормално, сите долгогодишни сесии се искинати во овој случај. Програмерите трчаат кај нас и велат: „Момци, што правите, разговорот се расипа за сите наши клиенти! Им велиме: „Што правиш? Дали вашите клиенти не можат повторно да се поврзат? Тие велат: „Не, ни треба седниците да не се кинат“. Накратко, ова е всушност глупост. Треба да се земе предвид клиентската страна. Особено, како што велам, со долготрајни сесии како што се веб-сокетите, може да се скрши и, незабележано од корисникот, треба да можете повторно да инсталирате такви сесии. И тогаш сè е совршено.
Ресурси
Всушност, тука ќе ви кажам само една директна приказна. Повторно од реалниот живот. Најболното нешто што сум го слушнал за ресурсите.
Ресурси во овој случај, мислам на некакви барања, ограничувања што можете да ги ставите на подлоги во вашите кластери на Кубернет. Најсмешното нешто што го слушнав од програмер... Еден од моите колеги програмери на претходното работно место еднаш рече: „Мојата апликација нема да започне во кластерот“. Гледав да видам дека не започнува, но или не се вклопува во ресурсите, или поставија многу мали граници. Накратко, апликацијата не може да започне поради ресурси. Јас велам: „Нема да започне поради ресурсите, вие одлучувате колку ви треба и поставете соодветна вредност“. Тој вели: „Какви ресурси? Почнав да му објаснувам дека треба да се постават кубернети, ограничувања на барањата и бла, бла, бла. Човекот слушаше пет минути, кимна со главата и рече: „Дојдов овде да работам како програмер, не сакам да знам ништо за никакви ресурси. Дојдов овде да напишам код и тоа е тоа“. Тажно е. Ова е многу тажен концепт од гледна точка на програмери. Особено во современиот свет, така да се каже, на прогресивните девопови.
Зошто воопшто се потребни ресурси? Во Kubernetes има 2 типа ресурси. Некои се нарекуваат барања, други се нарекуваат ограничувања. По ресурси ќе разбереме дека во основа секогаш постојат само две основни ограничувања. Односно, временските ограничувања на процесорот и ограничувањата на RAM меморијата за контејнер што работи во Kubernetes.
Ограничувањето поставува горна граница за тоа како може да се користи ресурс во вашата апликација. Тоа е, соодветно, ако кажете 1GB RAM во границите, тогаш вашата апликација нема да може да користи повеќе од 1GB RAM. И ако тој одеднаш сака и се обиде да го направи ова, тогаш процесот наречен oom killer, без меморија, односно, ќе дојде и ќе ја убие вашата апликација - односно, таа едноставно ќе се рестартира. Апликациите нема да се рестартираат врз основа на процесорот. Во однос на процесорот, ако апликацијата се обиде да користи многу, повеќе од наведеното во границите, процесорот едноставно ќе биде строго избран. Ова не води до рестартирање. Ова е граница - ова е горната граница.
И има барање. Барањето е како Kubernetes разбира како јазлите во вашиот Kubernetes кластер се пополнети со апликации. Односно, барањето е еден вид обврзување на вашата апликација. Го кажува она што сакам да го користам: „Би сакал да резервирате толку процесор и толку меморија за мене“. Таква едноставна аналогија. Што ако имаме јазол кој има, не знам, вкупно 8 процесори. И таму пристигнува pod, чии барања велат 1 процесор, што значи дека на јазолот му преостануваат 7 процесори. Тоа е, соодветно, штом 8 подови пристигнат на овој јазол, од кои секоја има по 1 процесор во нивните барања, јазолот, како од гледна точка на Кубернетес, да снема процесор и повеќе подови со барања не можат да бидат лансиран на овој јазол. Ако сите јазли снема процесор, тогаш Kubernetes ќе почне да кажува дека нема соодветни јазли во кластерот за да ги стартуваат вашите подлоги бидејќи процесорот е снема.
Зошто се потребни барања и зошто без барања, мислам дека нема потреба да се лансира ништо во Кубернетес? Ајде да замислиме хипотетичка ситуација. Ја стартувате вашата апликација без барања, Kubernetes не знае колку од она што го имате, до кои јазли можете да ја турнете. Па, тој турка, турка, турка на јазлите. Во одреден момент, ќе почнете да добивате сообраќај кон вашата апликација. И една од апликациите одеднаш почнува да користи ресурси до границите што ги има според лимитите. Излегува дека има друга апликација во близина и и требаат ресурси. Јазолот всушност почнува физички да истекува без ресурси, на пример, ОП. Јазолот всушност почнува физички да истекува без ресурси, на пример, меморија за случаен пристап (RAM). Кога некој јазол ќе се потроши, прво ќе престане да реагира, потоа кубелетот, а потоа ОС. Едноставно ќе онесвестат и дефинитивно СЕ ќе престане да работи кај вас. Тоа е, ова ќе доведе до заглавување на вашиот јазол и ќе треба да го рестартирате. Накратко, ситуацијата не е многу добра.
И кога имате барања, границите не се многу различни, барем не многу пати повеќе од лимитите или барањата, тогаш можете да имате толку нормално, рационално пополнување на апликациите низ јазлите на кластерите на Kubernetes. Во исто време, Kubernetes е приближно свесен за тоа колку од она што го става каде, колку од она што се користи. Тоа е, тоа е само таков момент. Важно е да се разбере. И важно е да се контролира дека тоа е индицирано.
Складирање на податоци
Нашата следна точка е за складирање податоци. Што да се прави со нив и воопшто, што да се прави со упорноста во Кубернетес?
Мислам, повторно, во нашите , имаше тема за базата на податоци во Кубернетес. И ми се чини дека дури и приближно знам што ви кажаа вашите колеги на прашањето: „Дали е можно да се води база на податоци во Kubernetes? Поради некоја причина, ми се чини дека вашите колеги требаше да ви кажат дека ако го поставувате прашањето дали е можно да се води база на податоци во Кубернетес, тогаш тоа е невозможно.
Логиката овде е едноставна. За секој случај, ќе ви објаснам уште еднаш, ако сте навистина кул човек кој може да изгради прилично толерантен систем на дистрибуирано мрежно складирање, разберете како да вклопите база на податоци во овој случај, како треба да функционира облакот во контејнери. во базата на податоци воопшто. Најверојатно, немате прашање за тоа како да го извршите. Ако имате такво прашање и сакате да се уверите дека сето тоа се расплетува и стои до смрт во производството и никогаш не паѓа, тогаш тоа нема да се случи. Со овој пристап гарантирано ќе си пукате во нога. Затоа, подобро е да не.
Што треба да правиме со податоците што нашата апликација би сакала да ги складира, некои слики што корисниците ги поставуваат, некои работи што нашата апликација ги генерира за време на нејзината работа, на пример при стартување? Што да правам со нив во Кубернетес?
Во принцип, идеално, да, се разбира, Kubernetes е многу добро дизајниран и генерално првично беше замислен за апликации без државјанство. Односно за оние апликации кои воопшто не чуваат информации. Ова е идеално.
Но, се разбира, идеалната опција не секогаш постои. Па што? Првата и наједноставна поента е да земеш некој вид S3, само не домашен, што исто така не е јасно како функционира, туку од некој провајдер. Добар, нормален провајдер - и научете ја вашата апликација да користи S3. Односно, кога вашиот корисник сака да постави датотека, кажете „тука, ве молам, поставете ја на S3“. Кога сака да го добие, кажете: „Еве линк до S3 назад и земете го од тука“. Ова е идеално.
Ако одеднаш поради некоја причина оваа идеална опција не е погодна, имате апликација што не сте ја напишале, не ја развивате или е некој вид страшно наследство, не може да го користи протоколот S3, но мора да работи со локални директориуми во локални папки. Земете нешто повеќе или помалку едноставно, распоредете го Kubernetes. Односно, веднаш оградување на Цеф за некои минимални задачи, ми се чини дека е лоша идеја. Затоа што Цеф, се разбира, е добар и модерен. Но, ако навистина не разбирате што правите, тогаш штом ќе ставите нешто на Ceph, можете многу лесно и едноставно никогаш повеќе да не го извадите од таму. Бидејќи, како што знаете, Ceph ги складира податоците во својот кластер во бинарна форма, а не во форма на едноставни датотеки. Затоа, ако одеднаш кластерот Ceph се распадне, тогаш постои целосна и голема веројатност дека никогаш повеќе нема да ги добиете вашите податоци од таму.
Ќе имаме курс за Цеф, можеш .
Затоа, подобро е да направите нешто едноставно како NFS сервер. Kubernetes може да работи со нив, можете да монтирате директориум под NFS сервер - вашата апликација е исто како локален директориум. Во исто време, природно, треба да разберете дека, повторно, треба да направите нешто со вашиот NFS, треба да разберете дека понекогаш може да стане недостапно и да размислите за прашањето што ќе направите во овој случај. Можеби треба да се направи резервна копија некаде на посебна машина.
Следната точка за која зборував е што да направите ако вашата апликација генерира некои датотеки за време на работата. На пример, кога ќе започне, генерира некоја статична датотека, која се заснова на некои информации што апликацијата ги добива само во моментот на стартување. Каков момент. Ако нема многу такви податоци, тогаш воопшто не треба да се мачите, само инсталирајте ја оваа апликација за себе и работете. Единственото прашање е што, погледнете. Многу често, секакви наследни системи, како што се WordPress и така натаму, особено со изменети некакви паметни додатоци, паметни PHP програмери, често знаат како да го направат тоа за да генерираат некаков вид датотека за себе. Според тоа, еден генерира една датотека, вториот генерира втора датотека. Тие се различни. Балансирањето се случува во кластерот Kubernetes на клиентите едноставно случајно. Според тоа, излегува дека тие не знаат како да работат заедно на пример. Едниот дава една информација, другиот му дава на корисникот друга информација. Ова е нешто што треба да го избегнувате. Тоа е, во Kubernetes, сè што ќе започнете е загарантирано дека може да работи во повеќе случаи. Затоа што Кубернетес е подвижна работа. Според тоа, тој може да премести што било, кога сака, без воопшто да праша никого. Затоа, треба да сметате на ова. Сè што е лансирано во еден пример, порано или подоцна ќе пропадне. Колку повеќе резервации имате, толку подобро. Но, пак, велам, ако имаш неколку такви датотеки, тогаш можеш да ги ставиш веднаш под тебе, тие тежат мала количина. Ако има малку повеќе од нив, веројатно не треба да ги туркате во контејнерот.
Би советувал дека има толку прекрасно нешто во Кубернетес, можете да користите јачина на звук. Конкретно, постои волумен од типот празен реж. Тоа е, само Kubernetes автоматски ќе создаде директориум во своите директориуми за услуги на серверот каде што сте започнале. И тој ќе ти го даде за да можеш да го искористиш. Има само една важна точка. Односно, вашите податоци нема да се чуваат во контејнерот, туку на домаќинот на кој работите. Згора на тоа, Kubernetes може да ги контролира таквите празни дириви под нормална конфигурација и може да ја контролира нивната максимална големина и да не дозволи да се надмине. Единствената поента е тоа што сте го напишале во празен дир не се губи при рестартирање на pod. Односно, ако вашата мешунка падне по грешка и повторно се издигне, информациите во празното дир нема да одат никаде. Тој може да го користи повторно на нов почеток - и тоа е добро. Ако вашиот мешун замине некаде, тогаш природно тој ќе замине без податоци. Односно, штом подот од јазолот каде што е лансиран со празен дир исчезне, празната дир се брише.
Што друго е добро за празна реж? На пример, може да се користи како кеш. Да замислиме дека нашата апликација генерира нешто во лет, им го дава на корисниците и го прави тоа долго време. Затоа, апликацијата, на пример, ја генерира и ја дава на корисниците, а во исто време ја складира некаде, така што следниот пат кога корисникот ќе дојде за истото, ќе биде побрзо да ја даде веднаш генерирана. Празен дир може да се побара од Кубернетс да креира во меморија. И така, вашите кешови генерално можат да работат со молскавична брзина - во однос на брзината на пристап на дискот. Односно, имате празен дир во меморијата, во ОС е зачуван во меморија, но за вас, за корисникот внатре во подот, изгледа само како локален директориум. Не ви е потребна апликацијата за конкретно да научи магија. Вие само директно ја земате и ставате вашата датотека во директориум, но, всушност, во меморијата на ОС. Ова е исто така многу погодна карактеристика во однос на Kubernetes.
Какви проблеми има Minio? Главниот проблем со Minio е што за да работи оваа работа треба некаде да работи и мора да има некаков датотечен систем, односно складирање. И тука се среќаваме со истите проблеми што ги има и Цеф. Тоа е, Minio мора да ги складира своите датотеки некаде. Тоа е едноставно HTTP интерфејс за вашите датотеки. Покрај тоа, функционалноста е очигледно послаба од онаа на S3 на Amazon. Претходно, не можеше правилно да го овласти корисникот. Сега, колку што знам, веќе може да создаде кофи со различни овластувања, но повторно, ми се чини дека главниот проблем е, така да се каже, основниот систем за складирање на минимум.
Како Празен дир во меморијата влијае на границите? Не влијае на ограничувањата на кој било начин. Тоа лежи во меморијата на домаќинот, а не во меморијата на вашиот контејнер. Односно, вашиот контејнер не го гледа празното дир во меморијата како дел од неговата окупирана меморија. Домаќинот го гледа ова. Според тоа, да, од гледна точка на кубернетите, кога ќе почнете да го користите ова, би било добро да разберете дека дел од вашата меморија посветувате на празен дир. И соодветно на тоа, разберете дека меморијата може да истече не само поради апликациите, туку и затоа што некој пишува на овие празни дирови.
Облачност
И последната поттема е што е Cloudnative. Зошто е потребно? Облачност и така натаму.
Односно оние апликации кои се способни и напишани за да работат во модерна облак инфраструктура. Но, всушност, Cloudnative има уште еден таков аспект. Дека ова не е само апликација која ги зема предвид сите барања на модерна облак инфраструктура, туку знае и како да работи со оваа модерна облак инфраструктура, искористете ги предностите и недостатоците на фактот што работи во овие облаци. Немојте само да претерувате и да работите во облаците, туку искористете ги придобивките од работата во облакот.
Да го земеме само Кубернетис како пример. Вашата апликација работи во Kubernetes. Вашата апликација секогаш, или подобро кажано, администраторите за вашата апликација, секогаш може да креираат сметка за услуга. Тоа е, сметка за овластување во самиот Kubernetes во неговиот сервер. Додадете некои права што ни се потребни таму. И можете да пристапите до Kubernetes од вашата апликација. Што можете да направите на овој начин? На пример, од апликацијата, добивајте податоци за тоа каде се лоцирани другите ваши апликации, други слични примероци и заедно некако се групираат на врвот на Kubernetes, доколку има таква потреба.
Повторно, неодамна буквално имавме случај. Имаме еден контролер кој ја следи редицата. И кога ќе се појават некои нови задачи во оваа редица, таа оди во Kubernetes - и внатре во Kubernetes создава нов pod. На овој подлог му дава нова задача и во рамките на овој подлога, подлогата ја извршува задачата, испраќа одговор до самиот контролер, а контролорот потоа прави нешто со оваа информација. На пример, додава база на податоци. Тоа е, повторно, ова е плус од фактот дека нашата апликација работи во Kubernetes. Можеме да ја користиме самата вградена функционалност на Kubernetes со цел некако да ја прошириме и да ја направиме функционалноста на нашата апликација поудобна. Односно, не кријте некаква магија за тоа како да стартувате апликација, како да стартувате работник. Во Kubernetes, едноставно испраќате барање во апликацијата ако апликацијата е напишана во Python.
Истото важи и ако одиме подалеку од Кубернетес. Ги имаме нашите Кубернети кои работат некаде - добро е ако е во некој вид облак. Повторно, можеме да ги користиме, па дури и треба, верувам, да ги користиме можностите на самиот облак каде што работиме. Од елементарните работи што ни ги обезбедува облакот. Балансирање, односно, можеме да создадеме балансери на облак и да ги користиме. Ова е директна предност на она што можеме да го искористиме. Бидејќи балансирањето на облакот, прво, едноставно глупаво ја отстранува одговорноста од нас за тоа како функционира, како е конфигурирано. Плус тоа е многу погодно, бидејќи обичните Kubernetes можат да се интегрираат со облаците.
Истото важи и за скалирање. Редовните Kubernetes може да се интегрираат со давателите на облак. Знае како да разбере дека ако кластерот снема јазли, односно просторот на јазлите е снема, тогаш треба да додадете - самиот Kubernetes ќе додаде нови јазли во вашиот кластер и ќе започне да лансира подлоги на нив. Тоа е, кога ќе дојде вашиот товар, бројот на огништа почнува да се зголемува. Кога ќе истечат јазлите во кластерот за овие мешунки, Kubernetes лансира нови јазли и, соодветно, бројот на мешунките сè уште може да се зголеми. И тоа е многу погодно. Ова е директна можност да се зголеми кластерот во лет. Не многу брзо, во смисла дека не е секунда, тоа е повеќе како минута за да се додадат нови јазли.
Но, од моето искуство, повторно, тоа е најкул нешто што некогаш сум го видел. Кога кластерот Cloudnative се скалира врз основа на времето од денот. Тоа беше заднинска услуга што ја користеа луѓето во задната канцеларија. Односно, тие доаѓаат на работа во 9 часот наутро, почнуваат да се најавуваат во системот и соодветно на тоа, кластерот Cloudnative, каде што се работи, почнува да отекува, лансирајќи нови подлоги за секој што доаѓа на работа да може да работи со апликацијата. Кога ќе ја напуштат работата во 8 или 6 часот, кластерите на Kubernetes забележуваат дека никој повеќе не ја користи апликацијата и почнуваат да се намалуваат. Заштедата до 30 проценти е загарантирана. Работеше во Амазон во тоа време, немаше никој во Русија кој можеше да го направи тоа толку добро.
Директно ќе ви кажам, заштедите се 30 проценти само затоа што користиме Kubernetes и ги користиме можностите на облакот. Сега ова може да се направи во Русија. Се разбира, нема да му се рекламирам на никого, но само да кажеме дека има провајдери кои можат да го направат тоа, да го обезбедат директно од кутијата со копче.
Има уште една последна точка на која би сакал да го свртам вашето внимание. За да може вашата апликација, вашата инфраструктура да биде Cloudnative, има смисла конечно да започнете да го прилагодувате пристапот наречен Infrastructure as a Code, односно, тоа значи дека вашата апликација, поточно вашата инфраструктура, е потребна на ист начин како и на код Опишете ја вашата апликација, вашата деловна логика во форма на код. И работете со него како код, односно тестирајте го, развлечете го, складирајте го во git, применете го CICD на него.
И токму тоа ви овозможува, прво, секогаш да имате контрола над вашата инфраструктура, секогаш да разберете во каква состојба е. Второ, избегнувајте рачни операции што предизвикуваат грешки. Трето, избегнувајте едноставно она што се нарекува промет, кога постојано треба да ги извршувате истите рачни задачи. Четврто, ви овозможува да се опоравите многу побрзо во случај на неуспех. Во Русија, секогаш кога зборувам за ова, секогаш има огромен број луѓе кои велат: „Да, јасно е, но имате пристапи, накратко, нема потреба да се поправи ништо“. Но, тоа е вистина. Ако нешто е скршено во вашата инфраструктура, тогаш од гледна точка на пристапот Cloudnative и од гледна точка на Инфраструктурата како код, наместо да го поправите, да отидете на серверот, да откриете што е скршено и да го поправите, полесно е да го избришете серверот и повторно да го креирате. И сето ова ќе го обнови.
Сите овие прашања се дискутирани подетално на . Следејќи ја врската можете да се запознаете со програмата и условите. Погодно е што можете да го совладате Кубернетот со учење од дома или работа 1-2 часа на ден.
Извор: www.habr.com