Бул макала сизге Kubernetes'те жүктү тең салмактуулук кантип иштээрин, узакка созулган байланыштарды масштабдоодо эмне болорун жана HTTP/2, gRPC, RSockets, AMQP же башка узак мөөнөттүү протоколдорду колдонсоңуз, эмне үчүн кардар тарабынан тең салмактуулукту эске алуу керек экенин түшүнүүгө жардам берет. .
Кубернетесте трафик кантип бөлүштүрүлөт
Kubernetes тиркемелерди жайылтуу үчүн эки ыңгайлуу абстракцияны камсыз кылат: Кызматтар жана Жайылтуулар.
Жайгаштыруу колдонмоңуздун кандай жана канча көчүрмөсү каалаган убакта иштеши керектигин сүрөттөйт. Ар бир колдонмо Pod катары жайгаштырылат жана IP дареги ыйгарылган.
Кызматтар функциясы боюнча жүк баланстоочуга окшош. Алар трафикти бир нече поддондорго бөлүштүрүү үчүн иштелип чыккан.
Келгиле, анын кандай экенин карап көрөлү.
- Төмөнкү диаграммада сиз бир эле колдонмонун үч нускасын жана жүк балансын көрө аласыз:
- Жүктөлүштүн тең салмактуусу Кызмат деп аталат жана ага IP дареги ыйгарылган. Каалаган келген суроо-талап подкасттардын бирине багытталат:
- Жайгаштыруу сценарийи колдонмонун инстанцияларынын санын аныктайт. Сиз дээрлик эч качан түздөн-түз төмөндөгүлөрдү кеңейтүүгө туура келбейт:
- Ар бир подрядга өзүнүн IP дареги ыйгарылган:
Кызматтарды IP даректеринин жыйындысы катары кароо пайдалуу. Кызматка кирген сайын IP даректердин бири тизмеден тандалып алынат жана көздөгөн дарек катары колдонулат.
Бул окшойт.
- Кызматка curl 10.96.45.152 сурамы кабыл алынат:
- Кызмат көздөгөн жер катары үч под даректин бирин тандайт:
- Трафик белгилүү бир подкокко багытталат:
Эгерде сиздин тиркемеңиз frontend жана backendден турса, анда сизде ар бири үчүн кызмат да, жайылтуу да болот.
Фронт бэкендге суроо-талапты жасаганда, ал бэкенд канча подколь кызмат кылаарын так билүүнүн кереги жок: бир, он же жүз болушу мүмкүн.
Ошондой эле, frontend backend кызмат кылган подкасттардын даректери жөнүндө эч нерсе билбейт.
Фронт серверге суроо-талапты жасаганда, ал өзгөрүлбөй турган сервер кызматынын IP дарегин колдонот.
Бул ушундай көрүнөт.
- 1 асты ички арткы компонентти сурайт. Backend үчүн белгилүү бирөөнү тандоонун ордуна, ал кызматка суроо салат:
- Кызмат көздөгөн дарек катары арткы бөлүмдөрдүн бирин тандайт:
- Трафик кызмат тарабынан тандалган 1-поддон 5-подго өтөт:
- 1ге чейинкилер кызматтын артында 5ке чейинки сыяктуу канча подряд жашырылганын так билбейт:
Бирок кызмат суроо-талаптарды кантип так бөлүштүрөт? Бул тегерек-робин балансташтыруу колдонулат окшойт? Келгиле, аны аныктап көрөлү.
Kubernetes кызматтарында баланстоо
Kubernetes кызматтары жок. IP дареги жана порту дайындалган кызмат үчүн процесс жок.
Муну кластердин каалаган түйүнүнө кирип, netstat -ntlp буйругун иштетип текшерсеңиз болот.
Сиз кызматка бөлүнгөн IP даректи да таба албайсыз.
Кызматтын IP дареги башкаруу катмарында, контроллерде жайгашкан жана маалымат базасында жазылган - ж.б. Ошол эле даректи башка компонент колдонот - kube-proxy.
Kube-прокси бардык кызматтар үчүн IP даректердин тизмесин алат жана кластердеги ар бир түйүндө iptables эрежелеринин топтомун түзөт.
Бул эрежелер мындай дейт: "Эгер биз кызматтын IP дарегин көрсөк, биз суроо-талаптын көздөгөн дарегин өзгөртүп, аны подкасттардын бирине жөнөтүшүбүз керек."
Кызматтын IP дареги кирүү чекити катары гана колдонулат жана ал IP даректи жана портту угуучу процесс тарабынан тейленбейт.
Келгиле, муну карап көрөлү.
- Үч түйүндөрдүн кластерин карап көрөлү. Ар бир түйүндөн уячалары бар:
- Кызматтын бир бөлүгү бежге боёлгон байланган кабыктар. Кызмат процесс катары жок болгондуктан, ал боз түстө көрсөтүлөт:
- Биринчи поддон кызматты сурайт жана ага байланышкан подкасттардын бирине өтүшү керек:
- Бирок кызмат жок, процесс жок. Бул кантип иштейт?
- Сурам түйүндөн чыкканга чейин, ал iptables эрежелеринен өтөт:
- iptables эрежелери бул кызмат жок экенин билет жана анын IP дарегин ошол кызмат менен байланышкан подкасттардын IP даректеринин бирине алмаштырат:
- Сурам максаттуу дарек катары жарактуу IP даректи алат жана кадимкидей иштетилет:
- Тармактын топологиясына жараша сурам акыры подкетке жетет:
iptables балансты жүктөй алабы?
Жок, iptables чыпкалоо үчүн колдонулат жана балансташтыруу үчүн иштелип чыккан эмес.
Бирок, бул сыяктуу иштеген эрежелердин топтомун жазууга болот .
Бул так Kubernetes ишке ашырылат.
Эгерде сизде үч поддон болсо, 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 жооп жөнөтөт, жана frontend аны кабыл алат.
Жооп алгандан кийин TCP байланышы жабылган кадимки кырдаалдан айырмаланып, ал эми HTTP сурамдары үчүн ачык бойдон калууда.
Фронт артка көбүрөөк суроо-талаптарды жөнөтсө эмне болот?
Бул сурамдарды жөнөтүү үчүн ачык TCP байланышы колдонулат, бардык суроо-талаптар биринчи сурам барган ошол эле серверге кетет.
iptables трафикти кайра бөлүштүрүшү керек эмеспи?
Бул учурда эмес.
TCP байланышы түзүлгөндө, ал iptables эрежелери аркылуу өтөт, алар трафик бара турган белгилүү бир серверди тандайт.
Бардык кийинки суроо-талаптар мурунтан эле ачык TCP байланышында болгондуктан, iptables эрежелери мындан ары чакырылбайт.
Келгиле, анын кандай экенин карап көрөлү.
- Биринчи подряд кызматка суроо-талап жөнөтөт:
- Мындан ары эмне болорун билесиз. Кызмат жок, бирок сурамды иштете турган iptables эрежелери бар:
- Арткы подкасттардын бири көздөгөн дарек катары тандалат:
- Өтүнүч капчыкка жетет. Бул учурда, эки поддондун ортосунда туруктуу TCP байланышы түзүлөт:
- Биринчи поддондон келген кийинки суроо-талап мурунтан эле орнотулган байланыш аркылуу өтөт:
Натыйжа тезирээк жооп берүү убакыты жана жогорку өткөрүү жөндөмдүүлүгү болуп саналат, бирок сиз бэкэндди масштабдоо мүмкүнчүлүгүн жоготосуз.
Ар дайым туташуу менен эки капчыгайыңыз болсо да, трафик алардын бирине барат.
Муну оңдоого болобу?
Кубернетес туруктуу туташууларды кантип тең салмактоого болорун билбегендиктен, бул милдет сизге жүктөлөт.
Кызматтар - акыркы чекиттер деп аталган IP даректердин жана порттордун жыйындысы.
Сиздин колдонмоңуз кызматтан акыркы чекиттердин тизмесин алып, алардын ортосунда суроо-талаптарды кантип бөлүштүрүүнү чече алат. Сиз ар бир подъездге туруктуу туташууну ача аласыз жана бул туташуулардын ортосундагы суроо-талаптарды тегерек-робин аркылуу баланстасаңыз болот.
Же көбүрөөк кайрылыңыз .
Балансташтыруу үчүн жооптуу кардар тараптын коду бул логикага ылайык келиши керек:
- Кызматтан акыркы чекиттердин тизмесин алыңыз.
- Ар бир акыркы чекит үчүн туруктуу туташууну ачыңыз.
- Сурам жасоо керек болгондо, ачык байланыштардын бирин колдонуңуз.
- Тизме өзгөрсө, акыркы чекиттердин тизмесин такай жаңыртыңыз, жаңыларын түзүңүз же эски туруктуу байланыштарды жабыңыз.
Бул ушундай болот.
- Кызматка суроо-талапты жөнөтүүчү биринчи поддондун ордуна, сиз кардар тараптагы суроо-талаптарды тең салмактай аласыз:
- Кайсы подколор кызматтын бир бөлүгү экенин сураган кодду жазышыңыз керек:
- Тизмеңиз болгондон кийин, аны кардар тарапка сактап, аны подкалдарга туташуу үчүн колдонуңуз:
- Сиз жүктү балансташтыруу алгоритми үчүн жооптуусуз:
Эми суроо туулат: бул көйгөй 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-проксиге көңүл бурбай, колдонмоңузду тең салмактоо үчүн башсыз кызматтан алынган акыркы чекиттердин тизмесин түздөн-түз колдоно аласыз.
Бирок кластерде орнотулган бардык тиркемелерге окшош логиканы кантип кошо алабыз?
Эгер колдонмоңуз мурунтан эле орнотулган болсо, бул тапшырма мүмкүн эместей сезилиши мүмкүн. Бирок, альтернативалуу вариант бар.
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 байланыштарын балансташтыруу үчүн ички механизмдерди камсыз кылбайт.
Бул сиз кардарлардын балансын эске алуу менен арыз жазуу керек дегенди билдирет.
Котормо командасы тарабынан даярдалган .
Тема боюнча дагы эмнени окуу керек:
- .
- .
- .
Source: www.habr.com