Белешка. трансл.: Аутори овог чланка су инжењери из мале чешке компаније пипетаил. Успели су да саставе дивну листу [понекад баналних, али ипак] веома хитних проблема и заблуда у вези са радом Кубернетес кластера.
Током година коришћења Кубернетес-а, радили смо са великим бројем кластера (управљаних и неуправљаних – на ГЦП, АВС и Азуре). Временом смо почели да примећујемо да се неке грешке стално понављају. Међутим, у томе нема срамоте: већину смо урадили сами!
Чланак садржи најчешће грешке и такође помиње како их исправити.
1. Ресурси: захтеви и ограничења
Ова ставка дефинитивно заслужује највећу пажњу и прво место на листи.
ЦПУ захтева обично или уопште није наведено или има веома ниску вредност (да поставите што више махуна на сваки чвор). Дакле, чворови постају преоптерећени. Током времена великог оптерећења, процесорска снага чвора је у потпуности искоришћена и одређено радно оптерећење прима само оно што је „захтевало“ ЦПУ тхроттлинг. То доводи до повећаног кашњења апликације, временског ограничења и других непријатних последица. (Прочитајте више о овоме у нашем другом недавном преводу: „“ – прибл. превод)
БестЕффорт (изузетно не препоручује се):
resources: {}Екстремно низак ЦПУ захтев (изузетно не препоручује се):
resources:
Requests:
cpu: "1m"С друге стране, присуство ЦПУ ограничења може довести до неразумног прескакања циклуса такта од стране подова, чак и ако процесор чвора није у потпуности учитан. Опет, ово може довести до повећаног кашњења. Контроверзе се настављају око параметра ЦПУ ЦФС квота у Линук кернелу и ЦПУ тхроттлинг у зависности од постављених ограничења, као и онемогућавање ЦФС квоте... Авај, ЦПУ ограничења могу да изазову више проблема него што могу да реше. Више информација о овоме можете пронаћи на линку испод.
Претерана селекција (претеривање) проблеми са меморијом могу довести до већих проблема. Достизање ограничења ЦПУ-а подразумева прескакање циклуса такта, док достизање ограничења меморије подразумева убијање модула. Да ли сте икада приметили ООМкилл? Да, управо о томе говоримо.
Да ли желите да смањите вероватноћу да се ово деси? Немојте претерано додељивати меморију и користите загарантовани КоС (квалитет услуге) постављањем захтева за меморију на ограничење (као у примеру испод). Прочитајте више о овоме у (Главни инжењер у Заланду).
Бурстабле (већа шанса за убијање ООМ-а):
resources:
requests:
memory: "128Mi"
cpu: "500m"
limits:
memory: "256Mi"
cpu: 2Гарантовано:
resources:
requests:
memory: "128Mi"
cpu: 2
limits:
memory: "128Mi"
cpu: 2Шта ће потенцијално помоћи при постављању ресурса?
Са метрика-сервер можете видети тренутну потрошњу ЦПУ ресурса и употребу меморије по подовима (и контејнерима унутар њих). Највероватније, већ га користите. Само покрените следеће команде:
kubectl top pods
kubectl top pods --containers
kubectl top nodesМеђутим, они приказују само тренутну употребу. Може вам дати грубу представу о реду величине, али на крају ће вам требати историја промена метрике током времена (да одговорите на питања попут: „Колико је било максимално оптерећење ЦПУ-а?“, „Колико је било оптерећење јуче ујутро?“, итд.). За ово можете користити Прометеј, ДатаДог и други алати. Они једноставно добијају метрике са сервера за метрике и чувају их, а корисник их може питати и у складу са тим исцртати.
Он омогућава аутоматизовати овај процес. Прати историју коришћења ЦПУ-а и меморије и поставља нове захтеве и ограничења на основу ових информација.
Ефикасно коришћење рачунарске снаге није лак задатак. То је као да стално играте Тетрис. Ако плаћате превише за рачунарску снагу са ниском просечном потрошњом (рецимо ~10%), препоручујемо вам да погледате производе засноване на АВС Фаргате или Виртуал Кубелет-у. Они су изграђени на моделу наплате без сервера/плати по коришћењу, што може бити јефтиније у таквим условима.
2. Сонде за живост и спремност
Подразумевано, провере животности и спремности нису омогућене у Кубернетесу. А понекад забораве да их укључе...
Али како другачије можете покренути поновно покретање услуге у случају фаталне грешке? И како балансатор оптерећења зна да је под спреман да прихвати саобраћај? Или да може да поднесе већи промет?
Ови тестови се често мешају једни са другима:
- Живост — провера „преживљавања“, која поново покреће модул ако не успе;
- Спремност — провера спремности, ако не успе, искључује под са Кубернетес сервиса (ово се може проверити помоћу
kubectl get endpoints) и саобраћај до њега не стиже док се следећа провера не заврши успешно.
Обе ове провере ИЗВОЂЕНО ТОКОМ ЦЕЛОГ ЖИВОТНОГ ЦИКЛУСА ПОД. Врло је важно.
Уобичајена заблуда је да се сонде спремности покрећу само при покретању како би балансер могао да зна да је модул спреман (Ready) и може да почне да обрађује саобраћај. Међутим, ово је само једна од опција за њихову употребу.
Друга је могућност да се сазна да је саобраћај на махунарки претеран и преоптерећује га (или под врши прорачуне који захтевају велике ресурсе). У овом случају, провера спремности помаже смањити оптерећење на махуну и "охладити" је. Успешан завршетак провере спремности у будућности омогућава поново повећајте оптерећење на махуну. У овом случају (ако је тест спремности неуспешан), неуспех теста животности би био веома контрапродуктиван. Зашто поново покренути капсулу која је здрава и напорно ради?
Стога је у неким случајевима боље да нема провера него да их омогућите са погрешно конфигурисаним параметрима. Као што је горе наведено, ако провера животности копије провера спремности, онда сте у великој невољи. Могућа опција је конфигурисање И оставити по страни.
Обе врсте провера не би требало да пропадну када уобичајене зависности не успеју, иначе ће то довести до каскадног (лавиновитог) отказа свих подова. Другим речима, .
3. ЛоадБаланцер за сваку ХТТП услугу
Највероватније у свом кластеру имате ХТТП услуге које бисте желели да проследите спољном свету.
Ако сервис отворите као type: LoadBalancer, његов контролер (у зависности од провајдера услуге) ће обезбедити и преговарати о екстерном ЛоадБаланцер-у (не мора да ради на Л7, већ чак и на Л4), а то може утицати на цену (екстерна статичка ИПв4 адреса, рачунарска снага, наплата по секунди ) због потребе стварања великог броја оваквих ресурса.
У овом случају, много је логичније користити један екстерни балансер оптерећења, отварајући услуге као type: NodePort. Или још боље, проширите нешто слично нгинк-ингресс-цонтроллер (Или траефик), који ће бити једини НодеПорт крајња тачка повезана са спољним балансатором оптерећења и усмераваће саобраћај у кластеру користећи улазак-Кубернетес ресурси.
Друге (микро) услуге унутар кластера које међусобно комуницирају могу „комуницирати“ користећи услуге као што су ЦлустерИП и уграђени механизам за откривање услуга преко ДНС-а. Само немојте да користите њихов јавни ДНС/ИП, јер то може утицати на кашњење и повећати цену услуга у облаку.
4. Аутоматско скалирање кластера без узимања у обзир његових карактеристика
Када додајете чворове и уклањате их из кластера, не би требало да се ослањате на неке основне метрике као што је употреба ЦПУ-а на тим чворовима. Планирање махуна мора узети у обзир многе Ограничења, као што су афинитет под/чворова, мрље и толеранције, захтеви за ресурсима, КоС итд. Коришћење екстерног аутоматског скалера који не узима у обзир ове нијансе може довести до проблема.
Замислите да одређени под треба да буде заказан, али сва расположива ЦПУ снага је затражена/растављена и под заглави у стању Pending. Спољни аутоматски скалер види просечно тренутно оптерећење ЦПУ-а (не тражено) и не покреће проширење (размера) - не додаје још један чвор. Као резултат тога, ова група неће бити заказана.
У овом случају, обрнуто скалирање (увећавање) — уклањање чвора из кластера је увек теже имплементирати. Замислите да имате модул са стањем (са повезаним сталним складиштем). Персистент волумес обично припадају специфична зона доступности и не реплицирају се у региону. Према томе, ако екстерни аутоматски скалер избрише чвор са овим подом, планер неће моћи да закаже овај под на другом чвору, пошто се то може урадити само у зони доступности у којој се налази трајно складиште. Под ће бити заглављен у стању Pending.
Веома популаран у Кубернетес заједници . Покреће се на кластеру, подржава АПИ-је главних добављача облака, узима у обзир сва ограничења и може се скалирати у горе наведеним случајевима. Такође је у могућности да се повећа уз одржавање свих постављених ограничења, чиме се штеди новац (који би иначе био потрошен на неискоришћени капацитет).
5. Занемаривање ИАМ/РБАЦ могућности
Чувајте се коришћења ИАМ корисника са упорним тајнама за машине и апликације. Организујте привремени приступ користећи улоге и сервисне налоге (услужни налози).
Често се сусрећемо са чињеницом да су приступни кључеви (и тајне) тврдо кодирани у конфигурацији апликације, као и да занемарујемо ротацију тајни упркос томе што имамо приступ Цлоуд ИАМ-у. Користите ИАМ улоге и сервисне налоге уместо корисника где је то прикладно.
Заборавите на кубе2иам и идите директно на ИАМ улоге за сервисне налоге (као што је описано у Штепан Враны):
apiVersion: v1
kind: ServiceAccount
metadata:
annotations:
eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/my-app-role
name: my-serviceaccount
namespace: defaultЈедна напомена. Није тако тешко, зар не?
Такође, немојте давати привилегије за налоге услуге и профиле инстанце admin и cluster-adminако им не треба. Ово је мало теже имплементирати, посебно у РБАЦ К8с, али дефинитивно вреди труда.
6. Не ослањајте се на аутоматски анти-афинитет за махуне
Замислите да имате три реплике неке имплементације на чвору. Чвор пада, а заједно са њим и све реплике. Непријатна ситуација, зар не? Али зашто су све реплике биле на истом чвору? Зар Кубернетес не би требало да обезбеди високу доступност (ХА)?!
Нажалост, Кубернетес планер, на сопствену иницијативу, није у складу са правилима одвојеног постојања (анти-афинитет) за махуне. Они морају бити експлицитно наведени:
// опущено для краткости
labels:
app: zk
// опущено для краткости
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: "app"
operator: In
values:
- zk
topologyKey: "kubernetes.io/hostname"
То је све. Сада ће подови бити заказани на различитим чворовима (овај услов се проверава само током заказивања, али не и током њиховог рада - стога requiredDuringSchedulingIgnoredDuringExecution).
Овде говоримо о podAntiAffinity на различитим чворовима: topologyKey: "kubernetes.io/hostname", - а не о различитим зонама доступности. Да бисте имплементирали пуноправни ХА, мораћете дубље да копате у ову тему.
7. Игнорисање ПодДисруптионБудгетс
Замислите да имате производно оптерећење на Кубернетес кластеру. Повремено, чворови и сам кластер морају бити ажурирани (или поништени). ПодДисруптионБудгет (ПДБ) је нешто попут уговора о гаранцији услуге између администратора кластера и корисника.
ПДБ вам омогућава да избегнете прекиде услуге узроковане недостатком чворова:
apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
name: zk-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: zookeeperУ овом примеру, ви, као корисник кластера, кажете администраторима: „Хеј, имам услугу чувара зоолошког врта, и шта год да радите, желео бих да имам најмање 2 реплике ове услуге увек доступне.“
Можете прочитати више о овоме .
8. Више корисника или окружења у заједничком кластеру
Кубернетес именски простори (именски простори) не пружају јаку изолацију.
Уобичајена заблуда је да ако примените не-прод лоад у један именски простор и прод лоад у други, онда неће утицати једни на друге ни на који начин... Међутим, одређени ниво изолације се може постићи коришћењем захтева/ограничења ресурса, постављањем квота и постављањем приоритетних класа. Нека „физичка“ изолација у равни података обезбеђена је афинитетима, толеранцијама, мрљама (или селекторима чворова), али такво раздвајање је прилично тешко имплементирати.
Они који треба да комбинују обе врсте оптерећења у истом кластеру мораће да се позабаве сложеношћу. Ако нема такве потребе, а можете себи приуштити да је имате још један грозд (рецимо, у јавном облаку), онда је боље то учинити. Ово ће постићи много виши ниво изолације.
9. ектерналТраффицПолици: Кластер
Врло често видимо да сав саобраћај унутар кластера долази преко услуге као што је НодеПорт, за коју је подешена подразумевана политика externalTrafficPolicy: Cluster... То значи да НодеПорт је отворен на сваком чвору у кластеру и можете користити било који од њих за интеракцију са жељеном услугом (скупом подова).
У исто време, прави подови повезани са горе поменутом услугом НодеПорт обично су доступни само на одређеном подскуп ових чворова. Другим речима, ако се повежем са чвором који нема потребну под, он ће проследити саобраћај на други чвор, додајући поскок и повећање латенције (ако се чворови налазе у различитим зонама доступности/центрима података, кашњење може бити прилично велико; поред тога, трошкови излазног саобраћаја ће се повећати).
С друге стране, ако одређени Кубернетес сервис има постављену политику externalTrafficPolicy: Local, онда се НодеПорт отвара само на оним чворовима на којима су потребни подови заправо покренути. Када користите екстерни балансер оптерећења који проверава стање (здравствена провера) крајње тачке (како то ради АВС ЕЛБ), Он ће слати саобраћај само до потребних чворова, што ће благотворно утицати на кашњења, потребе за рачунаром, излазне рачуне (а здрав разум налаже исто).
Постоји велика шанса да већ користите нешто попут траефик или нгинк-ингресс-цонтроллер као НодеПорт крајња тачка (или ЛоадБаланцер, који такође користи НодеПорт) за рутирање улазног ХТТП саобраћаја, а постављање ове опције може значајно смањити кашњење за такве захтеве.
В Можете сазнати више о ектерналТраффицПолици, њеним предностима и недостацима.
10. Немојте се везивати за кластере и не злоупотребљавајте контролну раван
Раније је било уобичајено да се сервери називају правим именима: , ХАЛ9000 и Цолоссус... Данас су их заменили насумично генерисани идентификатори. Ипак, навика је остала, а сада властита имена иду у кластере.
Типична прича (заснована на стварним догађајима): све је почело са доказом концепта, тако да је кластер имао поносно име тестирање… Прошле су године и још увек се користи у производњи, а сви се плаше да га додирну.
Нема ништа забавно у томе да се гроздови претварају у кућне љубимце, па препоручујемо да их повремено уклањате док вежбате опоравак од катастрофе (ово ће помоћи — прибл. превод). Поред тога, не би шкодило радити на контролном слоју (контролни авион). Плашити се да га додирнете није добар знак. Итд мртав? Момци, стварно сте у невољи!
С друге стране, не треба се заносити манипулисањем. Са временом контролни слој може постати спор. Највероватније је то због великог броја објеката који се креирају без њихове ротације (честа ситуација када се користи Хелм са подразумеваним поставкама, због чега се његово стање у цонфигмапс/тајнама не ажурира - као резултат тога, хиљаде објеката се акумулирају у контролни слој) или са сталним уређивањем кубе-апи објеката (за аутоматско скалирање, за ЦИ/ЦД, за праћење, евиденције догађаја, контролере итд.).
Поред тога, препоручујемо да проверите СЛА/СЛО уговоре са управљаним Кубернетес провајдером и обратите пажњу на гаранције. Продавац може гарантовати доступност контролног слоја (или његове подкомпоненте), али не и п99 кашњење захтева које му шаљете. Другим речима, можете ући kubectl get nodes, а одговор добијете тек након 10 минута и то неће бити кршење услова уговора о услузи.
11. Бонус: коришћење најновије ознаке
Али ово је већ класика. У последње време се ређе срећемо са овом техником, јер су многи, поучени из горког искуства, престали да користе ознаку :latest и почео да качи верзије. Ура!
стр ; Препоручујемо вам да се упознате са овом изузетном функцијом.
Резиме
Не очекујте да ће све радити преко ноћи: Кубернетес није панацеја. Лоша апликација (и вероватно ће бити горе). Непажња ће довести до прекомерне сложености, спорог и стресног рада контролног слоја. Поред тога, ризикујете да останете без стратегије опоравка од катастрофе. Не очекујте да ће Кубернетес обезбедити изолацију и високу доступност из кутије. Проведите неко време да своју апликацију учините заиста изворном у облаку.
Можете се упознати са неуспешним искуствима разних тимова у од Хеннинга Јацобса.
Они који желе да додају листу грешака датих у овом чланку могу нас контактирати на Твиттер-у (, ).
ПС од преводиоца
Прочитајте и на нашем блогу:
- «";
- «";
- «„(преглед и видео извештај);
- «'.
Извор: ввв.хабр.цом