🥇Кубернетестегі ұзақ мерзімді қосылымдарды теңестіру және масштабтау

Бұл мақала Kubernetes жүйесінде жүктемені теңестіру қалай жұмыс істейтінін, ұзақ мерзімді қосылымдарды масштабтау кезінде не болатынын және HTTP/2, gRPC, RSockets, AMQP немесе басқа ұзақ мерзімді протоколдарды пайдалансаңыз, неге клиенттік теңгерімдеуді қарастыру керектігін түсінуге көмектеседі. .

Кубернетесте трафик қалай қайта бөлінетіні туралы аздап

Kubernetes қолданбаларды орналастыру үшін екі ыңғайлы абстракцияны ұсынады: Қызметтер және Орналастырулар.

Орналастырулар кез келген уақытта қолданбаның қалай және қанша көшірмелері іске қосылуы керектігін сипаттайды. Әрбір қолданба Pod ретінде орналастырылады және IP мекенжайы тағайындалады.

Қызметтер функциясы бойынша жүктеме теңестірушіге ұқсас. Олар трафикті бірнеше блоктар бойынша таратуға арналған.

Оның қалай көрінетінін көрейік.

Төмендегі диаграммада бір қолданбаның үш данасын және жүктеме балансын көре аласыз:
Жүктеме теңестіруші қызмет деп аталады және оған IP мекенжайы тағайындалады. Кез келген кіріс сұрау бөлімдердің біріне қайта бағытталады:
Орналастыру сценарийі қолданба даналарының санын анықтайды. Тікелей кеңейту қажет болмайды:
Әрбір подводқа өзінің IP мекенжайы тағайындалады:

Қызметтерді IP мекенжайларының жиынтығы ретінде қарастыру пайдалы. Қызметке кірген сайын тізімнен IP мекенжайларының бірі таңдалады және тағайындалған мекенжай ретінде пайдаланылады.

Мынадай көрінеді.

Қызметке curl 10.96.45.152 сұрауы алынды:
Қызмет тағайындалған орын ретінде үш подкаст мекенжайының бірін таңдайды:
Трафик арнайы подкастқа қайта бағытталады:

Қолданбаңыз фронт пен серверден тұрса, сізде әрқайсысы үшін қызмет те, орналастыру да болады.

Фронт сервер серверге сұрау жасағанда, сервердің нақты қанша подкастқа қызмет ететінін білу қажет емес: бір, он немесе жүз болуы мүмкін.

Сондай-ақ, frontend серверге қызмет көрсететін подкасттардың мекенжайлары туралы ештеңе білмейді.

Фронт сервер серверге сұраныс жасағанда, ол өзгермейтін сервер қызметінің IP мекенжайын пайдаланады.

Мұнда қалай көрінеді:.

1 астында ішкі сервер компонентін сұрайды. Арнайы сервер үшін таңдаудың орнына, ол қызметке сұраныс жасайды:
Қызмет тағайындау мекенжайы ретінде сервер бөлімдерінің бірін таңдайды:
Трафик қызмет таңдаған 1-қосқыштан 5-ші тармаққа ауысады:
1-ге дейінгілер қызметтің артында қанша 5-тен төмен сияқты бөтелкелердің жасырылғанын білмейді:

Бірақ қызмет сұрауларды нақты қалай таратады? Айналмалы теңгерімдеу қолданылған сияқты ма? Оны анықтап көрейік.

Kubernetes қызметтеріндегі теңгерім

Kubernetes қызметтері жоқ. IP мекенжайы мен порты тағайындалған қызмет үшін ешқандай процесс жоқ.

Мұны кластердегі кез келген түйінге кіру және netstat -ntlp пәрменін іске қосу арқылы тексеруге болады.

Сіз тіпті қызметке бөлінген IP мекенжайын таба алмайсыз.

Қызметтің IP мекенжайы басқару деңгейінде, контроллерде орналасқан және деректер базасында жазылған - т.б. Дәл сол мекенжайды басқа құрамдас – kube-proxy пайдаланады.
Kube-proxy барлық қызметтер үшін IP мекенжайларының тізімін алады және кластердегі әрбір түйінде iptables ережелер жинағын жасайды.

Бұл ережелерде: «Егер біз қызметтің IP мекенжайын көретін болсақ, сұраудың тағайындалған мекенжайын өзгертіп, оны бөлімдердің біріне жіберуіміз керек».

Қызметтік IP мекенжайы тек кіру нүктесі ретінде пайдаланылады және сол IP мекенжайы мен портты тыңдайтын ешбір процесс қызмет көрсетпейді.

Осыны қарастырайық.

Үш түйіннен тұратын кластерді қарастырайық. Әрбір түйіннің түйіндері бар:
Бежевый боялған байланған бұршақ - қызметтің бір бөлігі. Қызмет процесс ретінде болмағандықтан, ол сұр түспен көрсетіледі:
Бірінші подключ қызметті сұрайды және байланыстырылған бөлімдердің біріне өтуі керек:
Бірақ қызмет жоқ, процесс жоқ. Бұл қалай жұмыс істейді?
Сұрау түйіннен шықпас бұрын, ол iptables ережелерінен өтеді:
iptables ережелері бұл қызметтің жоқ екенін біледі және оның IP мекенжайын сол қызметпен байланысты бөлімдердің IP мекенжайларының бірімен ауыстырады:
Сұрау тағайындалған мекенжай ретінде жарамды IP мекенжайын алады және қалыпты түрде өңделеді:
Желі топологиясына байланысты сұрау ақырында подкастқа жетеді:

iptables балансты жүктей алады ма?

Жоқ, iptables сүзу үшін пайдаланылады және теңгерімдеуге арналмаған.

Дегенмен, сияқты жұмыс істейтін ережелер жинағын жазуға болады псевдобалансер.

Бұл Кубернетесте жүзеге асырылатын нәрсе.

Егер сізде үш қосқыш болса, kube-proxy келесі ережелерді жазады:

33% ықтималдығы бар бірінші қосалқы элементті таңдаңыз, әйтпесе келесі ережеге өтіңіз.
50% ықтималдығы бар екіншісін таңдаңыз, әйтпесе келесі ережеге өтіңіз.
астындағы үшіншісін таңдаңыз.

Бұл жүйе әрбір подводтың 33% ықтималдықпен таңдалуына әкеледі.

Ал Pod 2 келесі Pod 1-ден кейін таңдалатынына кепілдік жоқ.

ескерту: iptables кездейсоқ таралымы бар статистикалық модульді пайдаланады. Осылайша, теңдестіру алгоритмі кездейсоқ таңдауға негізделген.

Енді қызметтердің қалай жұмыс істейтінін түсінгеннен кейін, қызықтырақ қызмет сценарийлерін қарастырайық.

Kubernetes қызметіндегі ұзақ мерзімді қосылымдар әдепкі бойынша масштабталмайды

Фронттен серверге дейінгі әрбір HTTP сұрауы ашылатын және жабылатын бөлек TCP қосылымы арқылы қызмет етеді.

Егер фронтон серверге секундына 100 сұрау жіберсе, онда 100 түрлі TCP қосылымдары ашылады және жабылады.

Бір TCP қосылымын ашып, оны барлық келесі HTTP сұраулары үшін пайдалану арқылы сұрауды өңдеу уақытын және жүктемені қысқартуға болады.

HTTP протоколында HTTP тірі қалу немесе қосылымды қайта пайдалану деп аталатын мүмкіндік бар. Бұл жағдайда жалғыз TCP қосылымы бірнеше HTTP сұраулары мен жауаптарын жіберу және алу үшін пайдаланылады:

Бұл мүмкіндік әдепкі бойынша қосылмаған: сервер де, клиент те сәйкесінше конфигурациялануы керек.

Орнатудың өзі қарапайым және көптеген бағдарламалау тілдері мен орталары үшін қол жетімді.

Мұнда әртүрлі тілдердегі мысалдарға бірнеше сілтемелер берілген:

Kubernetes қызметінде сақтауды пайдалансақ не болады?
Фронт пен сервердің екеуі де тірі қалуды қолдайды деп есептейік.

Бізде алдыңғы беттің бір данасы және сервердің үш данасы бар. Frontend бірінші сұрауды жасайды және серверге TCP қосылымын ашады. Сұрау қызметке жетеді, мақсатты мекенжай ретінде серверлік бөлімдердің бірі таңдалады. Backend жауап жібереді, ал фронтенд оны қабылдайды.

Жауап алғаннан кейін TCP қосылымы жабылатын әдеттегі жағдайдан айырмашылығы, ол енді HTTP сұраулары үшін ашық сақталады.

Фронт сервер серверге көбірек сұрау жіберсе не болады?

Бұл сұрауларды қайта жіберу үшін ашық TCP қосылымы пайдаланылады, барлық сұраулар бірінші сұрау жіберілген серверге өтеді.

iptables трафикті қайта бөлуі керек емес пе?

Бұл жағдайда емес.

TCP қосылымы жасалғанда, ол трафик өтетін арнайы серверді таңдайтын iptables ережелерінен өтеді.

Барлық кейінгі сұраулар әлдеқашан ашық TCP қосылымында болғандықтан, iptables ережелері енді шақырылмайды.

Оның қалай көрінетінін көрейік.

Бірінші бөлім қызметке сұрау жібереді:
Ары қарай не болатынын өзіңіз білесіз. Бұл қызмет жоқ, бірақ сұрауды өңдейтін iptables ережелері бар:
Тағайындалған мекенжай ретінде серверлік бөлімдердің бірі таңдалады:
Сұрау подкастқа жетеді. Осы кезде екі подвод арасында тұрақты TCP байланысы орнатылады:
Бірінші подкасттың кез келген келесі сұрауы бұрыннан орнатылған қосылым арқылы өтеді:

Нәтиже жылдамырақ жауап беру уақыты және жоғары өткізу қабілеті, бірақ сіз серверді масштабтау мүмкіндігін жоғалтасыз.

Тұрақты қосылымы бар серверде екі тармақ болса да, трафик әрқашан олардың біреуіне өтеді.

Мұны түзетуге бола ма?

Кубернетес тұрақты қосылымдарды теңестіруді білмейтіндіктен, бұл тапсырма сізге жүктеледі.

Қызметтер - соңғы нүктелер деп аталатын IP мекенжайлары мен порттарының жиынтығы.

Қолданбаңыз қызметтен соңғы нүктелердің тізімін ала алады және олардың арасында сұрауларды қалай бөлу керектігін шеше алады. Әрбір подводқа тұрақты қосылымды ашуға және осы қосылымдар арасындағы сұрауларды round-robin көмегімен теңестіруге болады.

Немесе көбірек қолданыңыз күрделі теңдестіру алгоритмдері.

Баланстандыруға жауапты клиенттік код мына логикаға сәйкес болуы керек:

Қызметтен соңғы нүктелердің тізімін алыңыз.
Әрбір соңғы нүкте үшін тұрақты қосылымды ашыңыз.
Сұраныс жасау қажет болғанда, ашық қосылымдардың бірін пайдаланыңыз.
Соңғы нүктелер тізімін үнемі жаңартып отырыңыз, жаңаларын жасаңыз немесе тізім өзгерсе, ескі тұрақты қосылымдарды жабыңыз.

Ол осылай болады.

Сұранысты қызметке жіберетін бірінші подкольдің орнына клиент тарапынан сұрауларды теңестіруге болады:
Сізге қай подкасттардың қызмет бөлігі екенін сұрайтын кодты жазу керек:
Тізім болғаннан кейін оны клиент жағында сақтаңыз және оны қосқыштарға қосылу үшін пайдаланыңыз:
Сіз жүктемені теңестіру алгоритміне жауаптысыз:

Енді сұрақ туындайды: бұл мәселе тек HTTP тірі қалдыруға қатысты ма?

Клиенттік жүктемені теңестіру

HTTP тұрақты TCP қосылымдарын пайдалана алатын жалғыз протокол емес.

Қолданбаңыз дерекқорды пайдаланса, сұрау жасау немесе дерекқордан құжатты алу қажет болған сайын TCP қосылымы ашылмайды.

Оның орнына дерекқорға тұрақты TCP қосылымы ашылады және пайдаланылады.

Егер сіздің дерекқорыңыз Kubernetes жүйесінде орналастырылса және кіру қызмет ретінде қамтамасыз етілсе, сіз алдыңғы бөлімде сипатталған мәселелерге тап боласыз.

Бір дерекқор репликасы басқаларына қарағанда көбірек жүктеледі. Kube-proxy және Kubernetes қосылымдарды теңестіруге көмектеспейді. Сұрауларды дерекқорға теңестіруге қамқорлық жасау керек.

Дерекқорға қосылу үшін қай кітапхананы пайдаланатыныңызға байланысты бұл мәселені шешудің әртүрлі нұсқалары болуы мүмкін.

Төменде Node.js жүйесінен MySQL дерекқор кластеріне қатынасу мысалы берілген:

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

Тұрақты TCP қосылымдарын пайдаланатын көптеген басқа протоколдар бар:

WebSockets және қорғалған WebSockets
HTTP / 2
gRPC
RSockets
AMQP

Сіз бұл хаттамалардың көпшілігімен бұрыннан таныс болуыңыз керек.

Бірақ егер бұл хаттамалар соншалықты танымал болса, неге теңдестірудің стандартталған шешімі жоқ? Неліктен клиент логикасын өзгерту керек? Түпнұсқа Kubernetes шешімі бар ма?

Kube-proxy және iptables Kubernetes жүйесіне орналастыру кезінде жиі қолданылатын пайдалану жағдайларын қамтуға арналған. Бұл ыңғайлы болу үшін.

REST API ашатын веб-қызметті пайдалансаңыз, сәттілікке ие боласыз - бұл жағдайда тұрақты TCP қосылымдары пайдаланылмайды, кез келген Kubernetes қызметін пайдалана аласыз.

Бірақ тұрақты TCP қосылымдарын пайдалана бастағаннан кейін, жүктемені серверлер бойынша біркелкі бөлу жолын анықтау керек болады. Kubernetes бұл жағдайға дайын шешімдерді қамтымайды.

Дегенмен, көмектесетін нұсқалар бар.

Кубернетестегі ұзақ мерзімді қосылымдарды теңестіру

Kubernetes-те қызметтердің төрт түрі бар:

ClusterIP
NodePort
LoadBalancer
Бассыз

Алғашқы үш қызмет iptables ережелерін құру үшін kube-proxy арқылы пайдаланылатын виртуалды IP мекенжайы негізінде жұмыс істейді. Бірақ барлық қызметтердің іргелі негізі – бассыз қызмет.

Басы жоқ қызметте онымен байланысты ешқандай IP мекенжайы жоқ және тек IP мекенжайларының тізімін және онымен байланысты түйіндердің (соңғы нүктелердің) порттарын шығарып алу механизмін қамтамасыз етеді.

Барлық қызметтер бассыз қызметке негізделген.

ClusterIP қызметі кейбір толықтырулары бар бассыз қызмет болып табылады:

Басқару деңгейі оған IP мекенжайын тағайындайды.
Kube-прокси қажетті iptables ережелерін жасайды.

Осылайша сіз kube-proxy-ді елемеуіңізге және қолданбаңызды жүктеп салуды теңестіру үшін бассыз қызметтен алынған соңғы нүктелер тізімін тікелей пайдалануға болады.

Бірақ кластерде орналастырылған барлық қолданбаларға ұқсас логиканы қалай қосуға болады?

Қолданбаңыз әлдеқашан орналастырылған болса, бұл тапсырма мүмкін емес болып көрінуі мүмкін. Дегенмен, балама нұсқа бар.

Service Mesh сізге көмектеседі

Сіз клиенттік жүктемені теңестіру стратегиясының стандартты екенін байқаған боларсыз.

Қолданба іске қосылғанда, ол:

Қызметтен IP мекенжайларының тізімін алады.
Қосылым пулын ашады және қолдайды.
Соңғы нүктелерді қосу немесе жою арқылы пулды мерзімді түрде жаңартып отырады.

Қолданба сұрау жасағысы келгенде, ол:

Кейбір логиканы пайдаланып қолжетімді қосылымды таңдайды (мысалы, round-robin).
Сұранысты орындайды.

Бұл қадамдар WebSockets, gRPC және AMQP қосылымдары үшін жұмыс істейді.

Сіз бұл логиканы бөлек кітапханаға бөліп, қолданбаларыңызда пайдалана аласыз.

Дегенмен, оның орнына Istio немесе Linkerd сияқты қызмет торларын пайдалануға болады.

Service Mesh қолданбаңызды келесі процеспен толықтырады:

Қызметтік IP мекенжайларын автоматты түрде іздейді.
WebSockets және gRPC сияқты қосылымдарды тексереді.
Сұраныстарды дұрыс протоколды пайдалана отырып теңестіреді.

Service Mesh кластердегі трафикті басқаруға көмектеседі, бірақ ол ресурстарды көп қажет етеді. Басқа опциялар Netflix Ribbon сияқты үшінші тарап кітапханаларын немесе Envoy сияқты бағдарламаланатын проксилерді пайдаланады.

Теңгерім мәселелерін елемейтін болсаңыз не болады?

Жүктемені теңестіруді пайдаланбауды таңдай аласыз және әлі де ешқандай өзгерістерді байқамайсыз. Бірнеше жұмыс сценарийін қарастырайық.

Егер сізде серверлерден көбірек клиенттер болса, бұл үлкен мәселе емес.

Екі серверге қосылатын бес клиент бар делік. Баланстау болмаса да, екі сервер де пайдаланылады:

Қосылымдар біркелкі бөлінбеуі мүмкін: бір серверге төрт клиент қосылған болуы мүмкін, бірақ екі серверді де пайдалану мүмкіндігі жоғары.

Неғұрлым проблемалысы - қарама-қарсы сценарий.

Клиенттеріңіз аз болса және серверлеріңіз көп болса, ресурстарыңыз жеткіліксіз пайдаланылуы мүмкін және ықтимал кедергі пайда болады.

Екі клиент және бес сервер бар делік. Ең жақсы жағдайда бес серверден екі серверге екі тұрақты қосылым болады.

Қалған серверлер бос болады:

Бұл екі сервер клиент сұрауларын өңдей алмаса, көлденең масштабтау көмектеспейді.

қорытынды

Kubernetes қызметтері көптеген стандартты веб-бағдарлама сценарийлерінде жұмыс істеуге арналған.

Дегенмен, дерекқорлар, gRPC немесе WebSockets сияқты тұрақты TCP қосылымдарын пайдаланатын қолданба протоколдарымен жұмыс істей бастағанда, қызметтер енді жарамсыз болады. Kubernetes тұрақты TCP қосылымдарын теңестірудің ішкі механизмдерін қамтамасыз етпейді.

Бұл клиенттік балансты ескере отырып қолданбаларды жазу керек дегенді білдіреді.

Аударма командасымен дайындалған Mail.ru сайтынан Kubernetes aaS.

Тақырып бойынша тағы не оқу керек:

Ақпарат көзі: www.habr.com

Kubernetes жүйесіндегі ұзақ мерзімді қосылымдарды теңестіру және масштабтау