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