Хамгийн сүүлд Бид Service Mesh Istio-ийн үндсэн бүрэлдэхүүн хэсгүүдийг судалж, системтэй танилцаж, Istio-тэй ажиллаж эхлэхэд ихэвчлэн гарч ирдэг гол асуултуудад хариулсан. Энэ хэсэгт бид сүлжээгээр мөрдөх мэдээллийг цуглуулах ажлыг хэрхэн зохион байгуулах талаар авч үзэх болно.
Олон хөгжүүлэгчид болон системийн администраторуудад Service Mesh гэдэг үгийг сонсоход хамгийн түрүүнд санаанд орж ирдэг зүйл бол мөрдөх явдал юм. Үнэн хэрэгтээ бид бүх TCP траффик дамждаг сүлжээний зангилаа бүрт тусгай прокси сервер нэмж өгдөг. Сүлжээ дээрх бүх сүлжээний харилцан үйлчлэлийн талаарх мэдээллийг хялбархан илгээх боломжтой болсон бололтой. Харамсалтай нь бодит байдал дээр анхааралдаа авах шаардлагатай олон нюансууд байдаг. Тэднийг харцгаая.
Нэгдүгээр ташаа ойлголт: бид онлайнаар явган аялалын мэдээллийг үнэ төлбөргүй авах боломжтой.
Үнэн хэрэгтээ харьцангуй үнэ төлбөргүй бол бид зөвхөн сумаар холбогдсон системийн зангилаа болон үйлчилгээнүүдийн хооронд дамжих өгөгдлийн хурдыг (үнэндээ зөвхөн цаг хугацааны нэгж дэх байт) авах боломжтой. Гэсэн хэдий ч ихэнх тохиолдолд манай үйлчилгээнүүд HTTP, gRPC, Redis гэх мэт зарим төрлийн хэрэглээний түвшний протоколоор холбогддог. Мэдээжийн хэрэг, бид эдгээр протоколуудад тусгайлан мөрдөх мэдээллийг харахыг хүсч байна; бид өгөгдлийн хурдыг бус хүсэлтийн хурдыг харахыг хүсч байна. Бид өөрсдийн протоколыг ашиглан хүсэлтийн хоцролтыг ойлгохыг хүсч байна. Эцэст нь, бид систем рүүгээ нэвтэрч хэрэглэгчийн хариултыг хүлээн авах хүртэлх хүсэлтийн бүрэн замыг харахыг хүсч байна. Энэ асуудлыг шийдэх нь тийм ч хялбар биш болсон.
Эхлээд Istio дахь архитектурын үүднээс илгээх мөшгих зай ямар байдгийг харцгаая. Эхний хэсгээс бидний санаж байгаагаар Istio нь телеметрийг цуглуулах зориулалттай Mixer нэртэй тусдаа бүрэлдэхүүн хэсэгтэй байдаг. Гэсэн хэдий ч одоогийн 1.0.* хувилбарт илгээлт нь прокси серверээс, тухайлбал элч проксигээс шууд хийгддэг. Envoy прокси нь хайрцагнаас гарсан zipkin протоколыг ашиглан мөрдөх зайг илгээхийг дэмждэг. Бусад протоколуудыг холбох боломжтой, гэхдээ зөвхөн залгаасаар дамжуулан. Istio-ийн тусламжтайгаар бид нэн даруй угсарч, тохируулсан элч прокси авах бөгөөд энэ нь зөвхөн зипкин протоколыг дэмждэг. Хэрэв бид жишээ нь Jaeger протоколыг ашиглаж, UDP-ээр дамжуулан мөрийн зайг илгээхийг хүсвэл өөрийн istio-proxy дүрсийг бүтээх хэрэгтэй болно. İstio-proxy-д зориулсан тусгай залгаасуудын дэмжлэг байдаг боловч альфа хувилбар дээр хэвээр байна. Тиймээс, хэрэв бид олон тооны захиалгат тохиргоогүйгээр хийхийг хүсч байвал мөрдөх зайг хадгалах, хүлээн авахад ашигладаг технологийн хүрээ багасна. Үндсэн системүүдээс та одоо Zipkin өөрөө эсвэл Jaeger-ийг ашиглаж болно, гэхдээ zipkin-тэй нийцтэй протоколыг ашиглан тэнд бүх зүйлийг илгээх боломжтой (энэ нь үр ашиг багатай). Зипкин протокол нь өөрөө HTTP протоколоор дамжуулан цуглуулагчдад мөрдөх бүх мэдээллийг илгээдэг бөгөөд энэ нь нэлээд үнэтэй юм.
Би аль хэдийн хэлсэнчлэн, бид програмын түвшний протоколуудыг мөрдөхийг хүсч байна. Энэ нь үйлчилгээ бүрийн хажууд байрлах прокси серверүүд одоо ямар төрлийн харилцан үйлчлэл болж байгааг ойлгох ёстой гэсэн үг юм. Анхдагч байдлаар, Istio нь бүх портуудыг энгийн TCP байхаар тохируулдаг бөгөөд энэ нь ямар ч ул мөр илгээгдэхгүй гэсэн үг юм. Мөрийг илгээхийн тулд та эхлээд үндсэн торон тохиргоонд энэ сонголтыг идэвхжүүлж, хамгийн чухал нь үйлчилгээнд ашигладаг протоколын дагуу kubernetes үйлчилгээний байгууллагуудын бүх портуудыг нэрлэх ёстой. Жишээлбэл, иймэрхүү:
apiVersion: v1
kind: Service
metadata:
name: nginx
spec:
ports:
- port: 80
targetPort: 80
name: http
selector:
app: nginxТа мөн http-magic гэх мэт нийлмэл нэрийг ашиглаж болно (Istio http-г харж, тэр портыг http төгсгөлийн цэг гэж таних болно). Формат нь: proto-extra.
Протоколыг тодорхойлохын тулд асар олон тооны тохиргоог нөхөхгүйн тулд та бохир шийдлийг ашиглаж болно: Pilot бүрэлдэхүүн хэсгийг яг одоо байгаа үед нөхөх. . Эцсийн эцэст мэдээжийн хэрэг, энэ логикийг стандарт болгон өөрчилж, бүх портуудыг нэрлэх конвенцид шилжих шаардлагатай болно.
Протокол үнэхээр зөв тодорхойлогдсон эсэхийг ойлгохын тулд элчний прокси бүхий хажуугийн аль нэг контейнерт орж, /config_dump байршил бүхий элч интерфейсийн админ порт руу хүсэлт гаргах шаардлагатай. Үүссэн тохиргоонд та хүссэн үйлчилгээнийхээ үйл ажиллагааны талбарыг харах хэрэгтэй. Үүнийг Istio-д хүсэлт гаргасан газрыг танигч болгон ашигладаг. Istio-д энэ параметрийн утгыг өөрчлөхийн тулд (бид үүнийг мөрдөх систем дээрээ харах болно) хажуугийн савыг эхлүүлэх үе шатанд serviceCluster тугийг зааж өгөх шаардлагатай. Жишээлбэл, доош чиглэсэн kubernetes API-аас олж авсан хувьсагчдаас үүнийг дараах байдлаар тооцоолж болно:
--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')
Элч дээр мөшгих нь хэрхэн ажилладагийг ойлгох сайн жишээ .
Мөшгих зайг илгээх төгсгөлийн цэгийг төлөөлөгчийн прокси эхлүүлэх тугуудад мөн зааж өгөх ёстой, жишээлбэл: --zipkinAddress tracing-collector.tracing:9411
Хоёрдугаар ташаа ойлголт: бид системээр дамжуулан хүсэлтийн бүрэн ул мөрийг хямд үнээр авах боломжтой.
Харамсалтай нь тийм биш. Хэрэгжүүлэх нарийн төвөгтэй байдал нь үйлчилгээний харилцан үйлчлэлийг хэрхэн хэрэгжүүлсэнээс хамаарна. Яагаад тэр вэ?
Баримт нь istio-proxy нь ижил үйлчилгээнээс гарсан хүмүүстэй ирж буй хүсэлтийн захидал харилцааг ойлгохын тулд бүх урсгалыг таслан зогсооход хангалттай биш юм. Та ямар нэгэн төрлийн харилцаа холбооны танигчтай байх хэрэгтэй. HTTP элч прокси нь тусгай толгойг ашигладаг бөгөөд үүгээрээ элч нь тухайн үйлчилгээнд ямар хүсэлт бусад үйлчилгээнд тодорхой хүсэлт үүсгэдэг болохыг ойлгодог. Ийм толгойн жагсаалт:
- x хүсэлтийн дугаар,
- x-b3-traceid,
- x-b3-spanid,
- x-b3-эцэг эх,
- x-b3-түүвэрлэсэн,
- x-b3-тугнууд,
- x-ot-span-context.
Хэрэв танд нэг цэг байгаа бол, жишээлбэл, ийм логикийг нэмж болох үндсэн клиенттэй бол бүх зүйл сайхан байна, та энэ номын сан бүх үйлчлүүлэгчдэд шинэчлэгдэхийг хүлээх хэрэгтэй. Гэхдээ хэрэв та маш олон төрлийн системтэй бөгөөд сүлжээгээр үйлчилгээнээс үйлчилгээ рүү шилжих нэгдмэл байдал байхгүй бол энэ нь том асуудал байх магадлалтай. Ийм логикийг нэмэхгүйгээр бүх мөрдөх мэдээлэл зөвхөн "нэг түвшний" байх болно. Өөрөөр хэлбэл, бид бүх үйлчилгээ хоорондын харилцан үйлчлэлийг хүлээн авах болно, гэхдээ тэдгээр нь сүлжээгээр дамжин өнгөрөх нэг хэлхээнд наалдахгүй.
дүгнэлт
Istio нь сүлжээгээр дамжуулан мөрдөх мэдээллийг цуглуулах тохиромжтой хэрэгслийг санал болгодог боловч хэрэгжүүлэхийн тулд та системээ тохируулж, Istio хэрэгжилтийн онцлогийг харгалзан үзэх шаардлагатай гэдгийг ойлгох ёстой. Үүний үр дүнд хоёр үндсэн асуудлыг шийдвэрлэх шаардлагатай байна: програмын түвшний протоколыг тодорхойлох (энэ нь элч төлөөлөгчөөр дэмжигдэх ёстой) болон үйлчилгээнээс ирсэн хүсэлтээс үйлчилгээнд хүсэлтийг холбох тухай мэдээллийг дамжуулах тохиргоог хийх (толгойг ашиглан). , HTTP протоколын хувьд). Эдгээр асуудлууд шийдэгдвэл бид олон хэл, хүрээ дээр бичигдсэн маш олон төрлийн системд ч гэсэн сүлжээнээс мэдээллийг ил тод цуглуулах боломжийг олгодог хүчирхэг хэрэгсэлтэй болно.
Үйлчилгээний торны тухай дараагийн нийтлэлд бид Istio-ийн хамгийн том бэрхшээлүүдийн нэг болох хажуугийн машины прокси контейнер бүрийн RAM-ийн их хэмжээний хэрэглээг авч үзэх бөгөөд үүнийг хэрхэн шийдвэрлэх талаар ярилцах болно.
Эх сурвалж: www.habr.com