Овај чланак ће вам помоћи да разумете како балансирање оптерећења функционише у Кубернетес-у, шта се дешава приликом скалирања дуготрајних веза и зашто бисте требали размотрити балансирање на страни клијента ако користите ХТТП/2, гРПЦ, РСоцкетс, АМКП или друге дуговечне протоколе .
Мало о томе како се саобраћај прераспоређује у Кубернетесу
Кубернетес пружа две згодне апстракције за примену апликација: услуге и примене.
Примене описују како и колико копија ваше апликације треба да буде покренуто у било ком тренутку. Свака апликација се примењује као Под и додељује јој се ИП адреса.
Услуге су сличне у функцији балансера оптерећења. Они су дизајнирани да дистрибуирају саобраћај на више подова.
Да видимо како то изгледа.
- На дијаграму испод можете видети три примера исте апликације и балансер оптерећења:
- Балансатор оптерећења се зове услуга и додељује му се ИП адреса. Сваки долазни захтев се преусмерава на један од подова:
- Сценарио примене одређује број инстанци апликације. Скоро никада нећете морати да се ширите директно испод:
- Свакој подлози је додељена сопствена ИП адреса:
Корисно је размишљати о услугама као о скупу ИП адреса. Сваки пут када приступите сервису, једна од ИП адреса се бира са листе и користи као одредишна адреса.
изгледа овако.
- Сервису је примљен захтев цурл 10.96.45.152:
- Услуга бира једну од три адресе под као одредиште:
- Саобраћај се преусмерава на одређени под:
Ако се ваша апликација састоји од фронтенд-а и бацкенд-а, тада ћете имати и услугу и примену за сваки.
Када фронтенд упути захтев бацкенду, не мора тачно да зна колико подова служи: може бити један, десет или сто.
Такође, фронтенд не зна ништа о адресама подова који опслужују бацкенд.
Када фронтенд упути захтев бацкенд-у, он користи ИП адресу позадинске услуге, која се не мења.
Овако изгледа.
- Под 1 захтева интерну позадинску компоненту. Уместо да изабере одређени за позадину, он шаље захтев сервису:
- Услуга бира једну од позадинских модула као одредишну адресу:
- Саобраћај иде од Под 1 до Под 5, по избору услуге:
- Под 1 не зна тачно колико подова као испод 5 је скривено иза услуге:
Али како тачно услуга дистрибуира захтеве? Чини се да се користи роунд-робин балансирање? Хајде да то схватимо.
Балансирање у Кубернетес сервисима
Кубернетес сервиси не постоје. Не постоји процес за услугу којој се додељују ИП адреса и порт.
Ово можете да проверите тако што ћете се пријавити на било који чвор у кластеру и покренути команду нетстат -нтлп.
Нећете моћи чак ни да пронађете ИП адресу додељену услузи.
ИП адреса услуге се налази у контролном слоју, у контролеру, и забележена је у бази података - итд. Исту адресу користи друга компонента - кубе-проки.
Кубе-проки прима листу ИП адреса за све услуге и генерише скуп иптаблес правила на сваком чвору у кластеру.
Ова правила кажу: „Ако видимо ИП адресу услуге, морамо да изменимо одредишну адресу захтева и пошаљемо је једном од подова.“
ИП адреса услуге се користи само као улазна тачка и не опслужује је ниједан процес који слуша ту ИП адресу и порт.
Хајде да погледамо ово.
- Размотрите кластер од три чвора. Сваки чвор има махуне:
- Везане махуне обојене у беж су део услуге. Пошто услуга не постоји као процес, она је приказана сивом бојом:
- Први модул захтева услугу и мора да оде до једног од повезаних модула:
- Али услуга не постоји, процес не постоји. Како то функционише?
- Пре него што захтев напусти чвор, пролази кроз иптаблес правила:
- Правила иптаблес-а знају да услуга не постоји и замењују њену ИП адресу једном од ИП адреса подова повезаних са том услугом:
- Захтев добија важећу ИП адресу као одредишну адресу и нормално се обрађује:
- У зависности од топологије мреже, захтев на крају стиже до под:
Може ли иптаблес балансирати оптерећење?
Не, иптаблес се користе за филтрирање и нису дизајнирани за балансирање.
Међутим, могуће је написати скуп правила која функционишу као .
А то је управо оно што је имплементирано у Кубернетес-у.
Ако имате три под-а, кубе-проки ће написати следећа правила:
- Изаберите прву подлогу са вероватноћом од 33%, у супротном пређите на следеће правило.
- Изаберите други са вероватноћом од 50%, иначе идите на следеће правило.
- Изаберите трећи испод.
Овај систем резултира избором сваке махуне са вероватноћом од 33%.
И нема гаранције да ће Под 2 бити изабран следећи после Под 1.
Приметити: иптаблес користи статистички модул са насумичном дистрибуцијом. Дакле, алгоритам балансирања се заснива на случајном избору.
Сада када разумете како услуге функционишу, погледајмо занимљивије сценарије услуга.
Дуготрајне везе у Кубернетесу се подразумевано не повећавају
Сваки ХТТП захтев од фронтенда до бацкенд-а опслужује посебна ТЦП веза, која се отвара и затвара.
Ако фронтенд пошаље 100 захтева у секунди бацкенду, тада се отвара и затвара 100 различитих ТЦП веза.
Можете смањити време обраде и учитавања захтева отварањем једне ТЦП везе и коришћењем за све наредне ХТТП захтеве.
ХТТП протокол има функцију која се зове ХТТП одржавање или поновна употреба везе. У овом случају, једна ТЦП веза се користи за слање и примање више ХТТП захтева и одговора:
Ова функција није подразумевано омогућена: и сервер и клијент морају бити конфигурисани у складу са тим.
Само подешавање је једноставно и доступно за већину програмских језика и окружења.
Ево неколико веза до примера на различитим језицима:
Шта се дешава ако користимо Кееп-аливе у Кубернетес услузи?
Претпоставимо да и фронтенд и бацкенд подржавају одржавање.
Имамо једну копију фронтенда и три копије позадине. Фронтенд прави први захтев и отвара ТЦП везу са позадином. Захтев стиже до сервиса, један од позадинских модула се бира као одредишна адреса. Бацкенд шаље одговор, а фронтенд га прима.
За разлику од уобичајене ситуације у којој је ТЦП веза затворена након пријема одговора, сада је отворена за даље ХТТП захтеве.
Шта се дешава ако фронтенд пошаље више захтева бацкенду?
За прослеђивање ових захтева користиће се отворена ТЦП веза, сви захтеви ће ићи на исту позадину где је отишао први захтев.
Зар иптаблес не би требало да прерасподели саобраћај?
Не у овом случају.
Када се ТЦП веза креира, она пролази кроз иптаблес правила, која бирају одређени позадински део где ће саобраћај ићи.
Пошто су сви наредни захтеви на већ отвореној ТЦП вези, иптаблес правила се више не позивају.
Да видимо како то изгледа.
- Прва капсула шаље захтев сервису:
- Већ знате шта ће бити следеће. Услуга не постоји, али постоје иптаблес правила која ће обрадити захтев:
- Један од позадинских модула биће изабран као одредишна адреса:
- Захтев стиже до под. У овом тренутку ће се успоставити стална ТЦП веза између два под-а:
- Сваки наредни захтев из прве групе ће проћи кроз већ успостављену везу:
Резултат је брже време одговора и већа пропусност, али губите могућност скалирања позадине.
Чак и ако имате два под-а у позадини, са сталном везом, саобраћај ће увек ићи на један од њих.
Може ли се ово поправити?
Пошто Кубернетес не зна како да уравнотежи сталне везе, овај задатак пада на вас.
Услуге су скуп ИП адреса и портова који се називају крајње тачке.
Ваша апликација може да добије листу крајњих тачака од услуге и одлучи како да дистрибуира захтеве између њих. Можете да отворите сталну везу са сваком под-ком и балансирате захтеве између ових веза користећи кружни рад.
Или примените више .
Код на страни клијента који је одговоран за балансирање треба да следи ову логику:
- Добијте листу крајњих тачака из услуге.
- Отворите трајну везу за сваку крајњу тачку.
- Када треба да се упути захтев, користите једну од отворених веза.
- Редовно ажурирајте листу крајњих тачака, креирајте нове или затворите старе трајне везе ако се листа промени.
Овако ће то изгледати.
- Уместо да први под шаље захтев услузи, можете да уравнотежите захтеве на страни клијента:
- Морате да напишете код који пита који су подови део услуге:
- Када имате листу, сачувајте је на страни клијента и користите је за повезивање са подовима:
- Ви сте одговорни за алгоритам балансирања оптерећења:
Сада се поставља питање: да ли се овај проблем односи само на ХТТП Кееп-аливе?
Балансирање оптерећења на страни клијента
ХТТП није једини протокол који може да користи трајне ТЦП везе.
Ако ваша апликација користи базу података, онда се ТЦП веза не отвара сваки пут када треба да упутите захтев или преузмете документ из базе података.
Уместо тога, отвара се и користи стална ТЦП веза са базом података.
Ако је ваша база података распоређена на Кубернетес-у и приступ је обезбеђен као услуга, онда ћете наићи на исте проблеме описане у претходном одељку.
Једна реплика базе података ће бити више учитана од осталих. Кубе-проки и Кубернетес неће помоћи у балансирању веза. Морате водити рачуна о балансирању упита у вашој бази података.
У зависности од тога коју библиотеку користите за повезивање са базом података, можда ћете имати различите опције за решавање овог проблема.
Испод је пример приступања МиСКЛ кластеру базе података из Ноде.јс:
var mysql = require('mysql');
var poolCluster = mysql.createPoolCluster();
var endpoints = /* retrieve endpoints from the Service */
for (var [index, endpoint] of endpoints) {
poolCluster.add(`mysql-replica-${index}`, endpoint);
}
// Make queries to the clustered MySQL databaseПостоји много других протокола који користе трајне ТЦП везе:
- ВебСоцкетс и заштићени ВебСоцкетс
- ХТТП / 2
- гРПЦ
- РСоцкетс
- АМКП
Већ би требало да сте упознати са већином ових протокола.
Али ако су ови протоколи толико популарни, зашто не постоји стандардизовано решење за балансирање? Зашто је потребно променити логику клијента? Да ли постоји изворно решење за Кубернетес?
Кубе-проки и иптаблес су дизајнирани да покрију најчешће случајеве употребе приликом постављања на Кубернетес. Ово је због погодности.
Ако користите веб услугу која излаже РЕСТ АПИ, имате среће - у овом случају се не користе трајне ТЦП везе, можете користити било коју Кубернетес услугу.
Али када почнете да користите трајне ТЦП везе, мораћете да схватите како да равномерно распоредите оптерећење на позадинске системе. Кубернетес не садржи готова решења за овај случај.
Међутим, сигурно постоје опције које могу помоћи.
Балансирање дуговечних веза у Кубернетесу
Постоје четири врсте услуга у Кубернетесу:
- ЦлустерИП
- НодеПорт
- Распоређивање оптерећења
- Без главе
Прве три услуге раде на основу виртуелне ИП адресе, коју кубе-проки користи за прављење иптаблес правила. Али основна основа свих услуга је служба без главе.
Услуга без главе нема ниједну ИП адресу која је повезана са њом и само обезбеђује механизам за преузимање листе ИП адреса и портова подова (крајњих тачака) повезаних са њом.
Све услуге су засноване на безглавој услузи.
Услуга ЦлустерИП је услуга без главе са неким додацима:
- Управљачки слој му додељује ИП адресу.
- Кубе-проки генерише неопходна правила за иптаблес.
На овај начин можете игнорисати кубе-проки и директно користити листу крајњих тачака добијених од безглавог сервиса за балансирање оптерећења ваше апликације.
Али како можемо додати сличну логику свим апликацијама распоређеним у кластеру?
Ако је ваша апликација већ распоређена, овај задатак може изгледати немогућ. Међутим, постоји алтернативна опција.
Сервице Месх ће вам помоћи
Вероватно сте већ приметили да је стратегија балансирања оптерећења на страни клијента прилично стандардна.
Када се апликација покрене, она:
- Добија листу ИП адреса од услуге.
- Отвара и одржава скуп веза.
- Повремено ажурира скуп додавањем или уклањањем крајњих тачака.
Када апликација жели да упути захтев, она:
- Бира доступну везу користећи неку логику (нпр. роунд-робин).
- Извршава захтев.
Ови кораци раде за ВебСоцкетс, гРПЦ и АМКП везе.
Ову логику можете одвојити у посебну библиотеку и користити је у својим апликацијама.
Међутим, уместо тога можете користити сервисне мреже као што су Истио или Линкерд.
Сервице Месх проширује вашу апликацију процесом који:
- Аутоматски тражи ИП адресе услуге.
- Тестира везе као што су ВебСоцкетс и гРПЦ.
- Балансира захтеве користећи исправан протокол.
Сервице Месх помаже у управљању саобраћајем унутар кластера, али је прилично интензиван ресурсима. Друге опције су коришћење библиотека трећих страна као што је Нетфлик Риббон или програмабилних проксија као што је Енвои.
Шта се дешава ако занемарите проблеме балансирања?
Можете изабрати да не користите балансирање оптерећења и да и даље нећете приметити никакве промене. Хајде да погледамо неколико сценарија рада.
Ако имате више клијената него сервера, то и није тако велики проблем.
Рецимо да постоји пет клијената који се повезују на два сервера. Чак и ако нема балансирања, оба сервера ће се користити:
Везе можда нису равномерно распоређене: можда су четири клијента повезана на исти сервер, али постоји велика шанса да ће се користити оба сервера.
Оно што је проблематичније је супротан сценарио.
Ако имате мање клијената и више сервера, ваши ресурси могу бити недовољно искоришћени и појавиће се потенцијално уско грло.
Рецимо да постоје два клијента и пет сервера. У најбољем случају биће две сталне везе са два сервера од пет.
Преостали сервери ће бити неактивни:
Ако ова два сервера не могу да обрађују захтеве клијената, хоризонтално скалирање неће помоћи.
Закључак
Кубернетес услуге су дизајниране да раде у већини стандардних сценарија веб апликација.
Међутим, када почнете да радите са протоколима апликација који користе трајне ТЦП везе, као што су базе података, гРПЦ или ВебСоцкетс, услуге више нису прикладне. Кубернетес не обезбеђује интерне механизме за балансирање упорних ТЦП веза.
То значи да морате писати апликације имајући на уму балансирање на страни клијента.
Превод припремио тим .
Шта још читати на тему:
- .
- .
- .
Извор: ввв.хабр.цом