Многи људи верују да је довољно да мигрирају апликацију на Кубернетес (било користећи Хелм или ручно) и биће срећни. Али то није тако једноставно.
Тим превео је чланак ДевОпс инжењера Џулијана Гиндија. Он дели на које замке је његова компанија наишла током процеса миграције како не бисте нагазили на исте грабље.
Први корак: Подешавање захтева и ограничења за под
Почнимо са постављањем чистог окружења у којем ће наше махуне радити. Кубернетес ради одличан посао у заказивању подова и руковању условима квара. Али испоставило се да планер понекад не може да постави под ако је тешко проценити колико ресурса му је потребно за успешан рад. Овде се појављују захтеви за ресурсима и ограничењима. Много је дебата о најбољем приступу постављању захтева и ограничења. Понекад се заиста чини да је то више уметност него наука. Ево нашег приступа.
Под захтеви - Ово је главна вредност коју користи планер за оптимално постављање капсуле.
Од : Корак филтрирања одређује скуп чворова где се под може заказати. На пример, филтер ПодФитсРесоурцес проверава да ли чвор има довољно ресурса да задовољи специфичне захтеве модула за ресурсе.
Користимо захтеве за апликације тако да се могу користити за процену колико ресурса у ствари Апликација треба да ради исправно. На овај начин планер може реално поставити чворове. Првобитно смо желели да поставимо захтеве са маргином како бисмо осигурали да сваки модул има довољно велики број ресурса, али смо приметили да се време заказивања значајно повећало и да неки модули никада нису били у потпуности заказани, као да за њих нису примљени захтеви за ресурсе.
У овом случају, планер би често избацивао подове и не би могао да их поново распореди јер контролна раван није имала појма колико ресурса захтева апликација, што је кључна компонента алгоритма за планирање.
Под лимити - ово је јаснија граница за махуну. Представља максималну количину ресурса коју ће кластер доделити контејнеру.
Опет, од : Ако контејнер има постављено ограничење меморије од 4 ГиБ, онда ће га кубелет (и време извођења контејнера) применити. Време извођења не дозвољава контејнеру да користи више од наведеног ограничења ресурса. На пример, када процес у контејнеру покуша да искористи више од дозвољене количине меморије, системско језгро завршава процес са грешком „недостаје меморије“ (ООМ).
Контејнер увек може да користи више ресурса него што је наведено у захтеву за ресурсе, али никада не може да користи више од наведеног у ограничењу. Ову вредност је тешко правилно поставити, али је веома важна.
У идеалном случају, желимо да се захтеви за ресурсе за модул мењају током животног циклуса процеса без мешања у друге процесе у систему — то је циљ постављања ограничења.
Нажалост, не могу дати конкретна упутства о томе које вредности поставити, али се ми сами придржавамо следећих правила:
- Користећи алат за тестирање оптерећења, симулирамо основни ниво саобраћаја и пратимо коришћење ресурса под (меморије и процесора).
- Подешавамо захтеве под на произвољно ниску вредност (са ограничењем ресурса од око 5 пута већом од вредности захтева) и посматрамо. Када су захтеви прениски, процес не може да почне, што често узрокује мистериозне грешке Го рунтиме-а.
Имајте на уму да већа ограничења ресурса отежавају заказивање јер је модулу потребан циљни чвор са довољно доступних ресурса.
Замислите ситуацију у којој имате лагани веб сервер са веома високим ограничењем ресурса, рецимо 4 ГБ меморије. Овај процес ће вероватно морати да се скалира хоризонтално, а сваки нови модул ће морати да буде заказан на чвору са најмање 4 ГБ доступне меморије. Ако такав чвор не постоји, кластер мора да уведе нови чвор да обради тај под, што може потрајати. Важно је да разлику између захтева за ресурсе и ограничења сведете на минимум да бисте обезбедили брзо и глатко скалирање.
Други корак: постављање тестова за живост и спремност
Ово је још једна суптилна тема о којој се често расправља у Кубернетес заједници. Важно је добро разумети тестове за живост и спремност јер они обезбеђују механизам за неометано покретање софтвера и минимизирање застоја. Међутим, они могу изазвати озбиљан пад перформанси ваше апликације ако нису правилно конфигурисани. Испод је резиме о томе каква су оба узорка.
Живост показује да ли је контејнер покренут. Ако не успе, кубелет убија контејнер и за њега је омогућена политика поновног покретања. Ако контејнер није опремљен Ливенесс сондом, тада ће подразумевано стање бити успешно - овако пише у .
Ливенесс сонде би требало да буду јефтине, што значи да не би требало да троше много ресурса, јер се често покрећу и треба да обавесте Кубернетес да је апликација покренута.
Ако подесите опцију да се покреће сваке секунде, ово ће додати 1 захтев у секунди, па имајте на уму да ће бити потребни додатни ресурси за руковање овим саобраћајем.
У нашој компанији, Ливенесс тестови проверавају основне компоненте апликације, чак и ако подаци (на пример, из удаљене базе података или кеша) нису у потпуности доступни.
Конфигурисали смо апликације са „здравственом“ крајњом тачком која једноставно враћа код одговора од 200. Ово је индикација да је процес покренут и да је способан да обрађује захтеве (али још не и саобраћај).
Узорак Спремност означава да ли је контејнер спреман за послуживање захтева. Ако сонда спремности не успе, контролер крајње тачке уклања ИП адресу модула са крајњих тачака свих услуга које одговарају модулу. Ово је такође наведено у Кубернетес документацији.
Пробе спремности троше више ресурса јер морају бити послате на позадину на начин који показује да је апликација спремна да прихвати захтеве.
У заједници се води много дебата о томе да ли приступити бази података директно. С обзиром на оптерећење (провере се обављају често, али се могу прилагодити), одлучили смо да се за неке апликације спремност за опслуживање саобраћаја рачуна тек након провере да се записи враћају из базе података. Добро осмишљене пробе спремности обезбедиле су већи ниво доступности и елиминисале застоје током примене.
Ако одлучите да поставите упит бази података да бисте тестирали спремност ваше апликације, уверите се да је што је могуће јефтинија. Узмимо овај захтев:
SELECT small_item FROM table LIMIT 1Ево примера како конфигуришемо ове две вредности у Кубернетесу:
livenessProbe:
httpGet:
path: /api/liveness
port: http
readinessProbe:
httpGet:
path: /api/readiness
port: http periodSeconds: 2
Можете додати неке додатне опције конфигурације:
initialDelaySeconds— колико секунди ће проћи између лансирања контејнера и почетка узорака.periodSeconds— интервал чекања између покретања узорка.timeoutSeconds— број секунди након којих се јединица сматра хитном. Редовно временско ограничење.failureThreshold— број неуспешних тестова пре него што се сигнал за поновно покретање пошаље у модул.successThreshold— број успешних сонди пре него што модул пређе у стање спремности (након квара, када се модул покрене или опорави).
Трећи корак: подешавање подразумеваних мрежних смерница за под
Кубернетес има „равну“ топографију мреже; подразумевано, сви подови комуницирају директно једни са другима. У неким случајевима то није пожељно.
Потенцијални безбедносни проблем је тај што би нападач могао да користи једну рањиву апликацију за слање саобраћаја на све подове на мрежи. Као иу многим областима безбедности, и овде се примењује принцип најмање привилегија. У идеалном случају, мрежне политике треба да експлицитно прецизирају које су везе између подова дозвољене, а које не.
На пример, испод је једноставна политика која одбија сав долазни саобраћај за одређени простор имена:
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
spec:
podSelector: {}
policyTypes:
- Ingress
Визуелизација ове конфигурације:
(https://miro.medium.com/max/875/1*-eiVw43azgzYzyN1th7cZg.gif)
Више детаља .
Четврти корак: прилагођено понашање помоћу кукица и инит контејнера
Један од наших главних циљева је био да обезбедимо примену Кубернетеса без прекида за програмере. Ово је тешко јер постоји много опција за гашење апликација и ослобађање ресурса које су користили.
Посебне потешкоће су настале са . Приметили смо да када су ови модули распоређени узастопно, активне везе су прекинуте пре успешног завршетка.
Након опсежног истраживања на мрежи, испоставило се да Кубернетес не чека да се Нгинк везе исцрпе пре него што прекине под. Користећи пре-стоп куку, имплементирали смо следећу функционалност и потпуно се решили застоја:
lifecycle:
preStop:
exec:
command: ["/usr/local/bin/nginx-killer.sh"]
Али nginx-killer.sh:
#!/bin/bash
sleep 3
PID=$(cat /run/nginx.pid)
nginx -s quit
while [ -d /proc/$PID ]; do
echo "Waiting while shutting down nginx..."
sleep 10
done
Још једна изузетно корисна парадигма је употреба инит контејнера за руковање покретањем одређених апликација. Ово је посебно корисно ако имате процес миграције базе података који захтева много ресурса и који треба да се покрене пре него што се апликација покрене. Такође можете одредити веће ограничење ресурса за овај процес без постављања таквог ограничења за главну апликацију.
Друга уобичајена шема је приступ тајнама у инит контејнеру који обезбеђује те акредитиве главном модулу, што спречава неовлашћени приступ тајнама из самог модула главне апликације.
Као и обично, цитат из документације: Инит контејнери безбедно покрећу прилагођени код или услужне програме који би иначе смањили безбедност слике контејнера апликације. Одвајањем непотребних алата, ограничавате површину напада слике контејнера апликације.
Пети корак: Конфигурисање кернела
На крају, хајде да причамо о напреднијој техници.
Кубернетес је изузетно флексибилна платформа која вам омогућава да покрећете радна оптерећења онако како вам одговара. Имамо велики број апликација високих перформанси које су изузетно захтевне за ресурсе. Након спровођења опсежног тестирања оптерећења, открили смо да се једна апликација бори са очекиваним оптерећењем саобраћаја када су Кубернетес-ова подразумевана подешавања била на снази.
Међутим, Кубернетес вам омогућава да покренете привилеговани контејнер који мења параметре кернела само за одређени под. Ево шта смо користили да променимо максималан број отворених веза:
initContainers:
- name: sysctl
image: alpine:3.10
securityContext:
privileged: true
command: ['sh', '-c', "sysctl -w net.core.somaxconn=32768"]
Ово је напреднија техника која често није потребна. Али ако се ваша апликација бори да се носи са великим оптерећењем, можете покушати да подесите нека од ових подешавања. Више детаља о овом процесу и постављању различитих вредности - као и увек .
У закључку
Иако Кубернетес може изгледати као готово решење из кутије, постоји неколико кључних корака које морате да предузмете да би ваше апликације функционисале несметано.
Током ваше Кубернетес миграције, важно је да пратите „циклус тестирања оптерећења“: покрените апликацију, тестирајте је учитавањем, посматрајте метрику и понашање скалирања, прилагодите конфигурацију на основу тих података, а затим поновите циклус поново.
Будите реални у погледу очекиваног саобраћаја и покушајте да га превазиђете да бисте видели које компоненте се прве покваре. Уз овај итеративни приступ, само неколико од наведених препорука може бити довољно за постизање успеха. Или ће можда бити потребно дубље прилагођавање.
Увек постављајте себи ова питања:
- Колико ресурса троше апликације и како ће се променити овај обим?
- Који су стварни захтеви за скалирање? Колико саобраћаја ће апликација у просеку поднети? Шта је са вршним саобраћајем?
- Колико често ће услуга бити потребно хоризонтално скалирати? Колико брзо нове махуне треба да се доведу на мрежу да би примиле саобраћај?
- Колико се правилно искључују махуне? Да ли је ово уопште неопходно? Да ли је могуће постићи имплементацију без застоја?
- Како можете минимизирати безбедносне ризике и ограничити штету од било које компромитоване махуне? Да ли неке услуге имају дозволе или приступ који им нису потребни?
Кубернетес пружа невероватну платформу која вам омогућава да искористите најбоље праксе за примену хиљада услуга у кластеру. Међутим, свака апликација је другачија. Понекад имплементација захтева мало више рада.
На срећу, Кубернетес пружа неопходну конфигурацију за постизање свих техничких циљева. Користећи комбинацију захтева и ограничења за ресурсе, пробе за живост и спремност, инит контејнере, мрежне политике и прилагођено подешавање кернела, можете постићи високе перформансе заједно са толеранцијом грешака и брзом скалабилности.
Шта још читати:
- .
- .
- .
Извор: ввв.хабр.цом