නිෂ්පාදනයේ Istio සහ Kubernetes. 2 කොටස. ලුහුබැඳීම

අන්තිමට ලිපියයි අපි Service Mesh Istio හි මූලික සංරචක දෙස බැලුවෙමු, පද්ධතිය සමඟ දැන හඳුනා ගත් අතර Istio සමඟ වැඩ කිරීමට පටන් ගන්නා විට සාමාන්යයෙන් පැන නගින ප්රධාන ප්රශ්නවලට පිළිතුරු සැපයුවා. මෙම කොටසේදී අපි ජාලයක් හරහා සොයාගැනීමේ තොරතුරු එකතු කිරීම සංවිධානය කරන්නේ කෙසේදැයි බලමු.

බොහෝ සංවර්ධකයින් සහ පද්ධති පරිපාලකයින් හට Service Mesh is tracing යන වචන ඇසෙන විට මතකයට එන පළමු දෙය. ඇත්ත වශයෙන්ම, අපි සියලු TCP ගමනාගමනය ගමන් කරන සෑම ජාල නෝඩයකටම විශේෂ ප්‍රොක්සි සේවාදායකයක් එක් කරන්නෙමු. ජාලයේ සියලුම ජාල අන්තර්ක්‍රියා පිළිබඳ තොරතුරු පහසුවෙන් යැවීමට දැන් හැකි බව පෙනේ. අවාසනාවකට මෙන්, යථාර්ථයේ දී සැලකිල්ලට ගත යුතු බොහෝ සූක්ෂ්මතා තිබේ. අපි ඒවා බලමු.

වැරදි වැටහීම අංක එක: අපට මාර්ගගත කඳු නැගීමේ දත්ත නොමිලේ ලබා ගත හැක.

ඇත්ත වශයෙන්ම, සාපේක්ෂව නොමිලේ, අපට ලබා ගත හැක්කේ ඊතල මගින් සම්බන්ධ කර ඇති අපගේ පද්ධතියේ නෝඩ් සහ සේවා අතර ගමන් කරන දත්ත අනුපාතය පමණි (ඇත්ත වශයෙන්ම, කාල ඒකකයකට බයිට් ගණන පමණි). කෙසේ වෙතත්, බොහෝ අවස්ථාවලදී, අපගේ සේවාවන් HTTP, gRPC, Redis, සහ යනාදී යෙදුම් ස්ථර ප්‍රොටෝකෝලයක් හරහා සන්නිවේදනය කරයි. තවද, ඇත්ත වශයෙන්ම, අපට මෙම ප්‍රොටෝකෝල සඳහා විෙශේෂෙයන් ෙතොරතුරු ලුහුබැඳීම දැකීමට අවශ්‍යයි; අපට අවශ්‍ය වන්නේ ඉල්ලීම් අනුපාතය මිස දත්ත අනුපාතය නොවේ. අපගේ ප්‍රොටෝකෝලය භාවිතයෙන් ඉල්ලීම්වල ප්‍රමාදය තේරුම් ගැනීමට අපට අවශ්‍යය. අවසාන වශයෙන්, අපගේ පද්ධතියට ඇතුළු වීමේ සිට පරිශීලකයාගෙන් ප්‍රතිචාරයක් ලැබීම දක්වා ඉල්ලීමක් ගන්නා සම්පූර්ණ මාර්ගය බැලීමට අපට අවශ්‍යය. මෙම ගැටළුව තවදුරටත් විසඳීම එතරම් පහසු නැත.

පළමුව, ඉස්ටියෝ හි වාස්තු විද්‍යාත්මක දෘෂ්ටි කෝණයකින් යැවීමේ ලුහුබැඳීමේ පරාසය කෙබඳුදැයි බලමු. පළමු කොටසේ අපට මතක ඇති පරිදි, ඉස්ටියෝට ටෙලිමෙට්‍රි එකතු කිරීම සඳහා මික්සර් නමින් වෙනම අංගයක් ඇත. කෙසේ වෙතත්, වත්මන් අනුවාදය 1.0.* හි, යැවීම සෘජුවම ප්‍රොක්සි සර්වර් වලින්, එනම් එන්වෝයි ප්‍රොක්සි වලින් සිදු කෙරේ. එන්වෝයි ප්‍රොක්සි පෙට්ටියෙන් පිටත සිප්කින් ප්‍රොටෝකෝලය භාවිතයෙන් ලුහුබැඳීමේ පරාසය යැවීමට සහාය වේ. වෙනත් ප්‍රොටෝකෝල සම්බන්ධ කිරීමට හැකි නමුත් ප්ලගිනයක් හරහා පමණි. Istio සමඟින් අපි වහාම එකලස් කරන ලද සහ වින්‍යාස කළ නියෝජිත ප්‍රොක්සියක් ලබා ගනිමු, එය zipkin ප්‍රොටෝකෝලය සඳහා පමණක් සහය දක්වයි. අපට අවශ්‍ය නම්, උදාහරණයක් ලෙස, Jaeger ප්‍රොටෝකෝලය භාවිතා කිරීමට සහ UDP හරහා ලුහුබැඳීමේ පරාසය යැවීමට, එවිට අපට අපගේම istio-proxy රූපයක් ගොඩනගා ගැනීමට අවශ්‍ය වනු ඇත. istio-proxy සඳහා අභිරුචි ප්ලගීන සඳහා සහය ඇත, නමුත් එය තවමත් ඇල්ෆා අනුවාදයේ ඇත. එමනිසා, අපට අභිරුචි සැකසුම් විශාල ප්‍රමාණයක් නොමැතිව කිරීමට අවශ්‍ය නම්, ලුහුබැඳීමේ පරාසයන් ගබඩා කිරීම සහ ලබා ගැනීම සඳහා භාවිතා කරන තාක්‍ෂණ පරාසය අඩු වේ. ප්‍රධාන පද්ධති වලින්, ඇත්ත වශයෙන්ම, දැන් ඔබට Zipkin හෝ Jaeger භාවිතා කළ හැකිය, නමුත් Zipkin අනුකූල ප්‍රොටෝකෝලය (එය වඩා අඩු කාර්යක්ෂමතාවයක්) භාවිතයෙන් සියල්ල එහි යවන්න. 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 අන්ත ලක්ෂ්‍යයක් ලෙස හඳුනා ගනී). ආකෘතිය: ප්රෝටෝ-අතිරේක.

ප්‍රොටෝකෝලය තීරණය කිරීම සඳහා වින්‍යාසයන් විශාල ප්‍රමාණයක් නොගැලපීම සඳහා, ඔබට අපිරිසිදු පිළියමක් භාවිතා කළ හැකිය: නියමු සංරචකය නිකම් වූ මොහොතේම පැච් කරන්න. ප්රොටෝකෝල නිර්වචන තර්කනය සිදු කරයි. අවසානයේදී, ඇත්ත වශයෙන්ම, මෙම තර්කනය සම්මතයට වෙනස් කිරීම සහ සියලු වරායන් සඳහා නම් කිරීමේ සම්මුතියකට මාරු කිරීම අවශ්ය වනු ඇත.

ප්‍රොටෝකෝලය සැබවින්ම නිවැරදිව නිර්වචනය කර තිබේද යන්න තේරුම් ගැනීමට, ඔබ එන්වෝයි ප්‍රොක්සි සහිත ඕනෑම සයිඩ්කාර් බහාලුමක් වෙත ගොස් ස්ථානය / config_dump සමඟ නියෝජිත අතුරු මුහුණතේ පරිපාලක තොටට ඉල්ලීමක් කළ යුතුය. ලැබෙන වින්‍යාසය තුළ, ඔබ අපේක්ෂිත සේවාවේ මෙහෙයුම් ක්ෂේත්‍රය දෙස බැලිය යුතුය. එය ඉල්ලීම සිදු කරන ස්ථානය සඳහා හඳුනාගැනීමක් ලෙස Istio හි භාවිතා වේ. Istio හි මෙම පරාමිතියේ අගය අභිරුචිකරණය කිරීම සඳහා (අපි එය අපගේ ලුහුබැඳීමේ පද්ධතිය තුළ දකිනු ඇත), සයිඩ්කාර් බහාලුම් දියත් කිරීමේ අදියරේදී සේවා ක්ලස්ටර් ධජය නියම කිරීම අවශ්‍ය වේ. උදාහරණයක් ලෙස, පහතට 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-ඉල්ලීම-id,
• x-b3-traceid,
• x-b3-spanid,
• x-b3-parentspanid,
• x-b3-නියැදි,
• x-b3-කොඩි,
• x-ot-span-සන්දර්භය.

ඔබට තනි කරුණක් තිබේ නම්, උදාහරණයක් ලෙස, ඔබට එවැනි තර්කයක් එකතු කළ හැකි මූලික සේවාලාභියෙකු නම්, එවිට සියල්ල හොඳයි, සියලුම සේවාදායකයින් සඳහා මෙම පුස්තකාලය යාවත්කාලීන වන තෙක් ඔබ බලා සිටිය යුතුය. නමුත් ඔබට ඉතා විෂමජාතීය පද්ධතියක් තිබේ නම් සහ ජාලය හරහා සේවාවේ සිට සේවයට යාමේ ඒකාබද්ධතාවයක් නොමැති නම්, මෙය බොහෝ විට විශාල ගැටළුවක් වනු ඇත. එවැනි තර්කයක් එකතු නොකර, සියලු සොයාගැනීම් තොරතුරු "තනි මට්ටමේ" පමණක් වනු ඇත. එනම්, අපට සියලු අන්තර්-සේවා අන්තර්ක්‍රියා ලැබෙනු ඇත, නමුත් ඒවා ජාලය හරහා ගමන් කිරීමේ තනි දාමයකට ඇලවිය නොහැක.

නිගමනය

Istio ජාලයක් හරහා ලුහුබැඳීමේ තොරතුරු රැස් කිරීම සඳහා පහසු මෙවලමක් සපයයි, නමුත් ක්‍රියාත්මක කිරීම සඳහා ඔබට ඔබේ පද්ධතිය අනුවර්තනය කිරීමට සහ Istio ක්‍රියාත්මක කිරීමේ විශේෂාංග සැලකිල්ලට ගත යුතු බව ඔබ තේරුම් ගත යුතුය. ප්‍රතිඵලයක් වශයෙන්, ප්‍රධාන කරුණු දෙකක් විසඳිය යුතුය: යෙදුම් මට්ටමේ ප්‍රොටෝකෝලය නිර්වචනය කිරීම (එය නියෝජිත ප්‍රොක්සි මගින් සහාය විය යුතුය) සහ සේවාවෙන් ලැබෙන ඉල්ලීම් වලින් (ශීර්ෂ භාවිතා කරමින්) සේවාව වෙත ඉල්ලීම් සම්බන්ධ කිරීම පිළිබඳ තොරතුරු ඉදිරිපත් කිරීම සැකසීම , HTTP ප්‍රොටෝකෝලය සම්බන්ධයෙන්). මෙම ගැටළු විසඳන විට, විවිධ භාෂා සහ රාමු වලින් ලියා ඇති ඉතා විෂමජාතීය පද්ධතිවල පවා ජාලයෙන් විනිවිදභාවයෙන් තොරතුරු රැස් කිරීමට අපට ඉඩ සලසන බලවත් මෙවලමක් අප සතුව ඇත.

Service Mesh පිළිබඳ මීළඟ ලිපියෙන්, අපි Istio සමඟ ඇති විශාලතම ගැටළු වලින් එකක් දෙස බලමු - එක් එක් සයිඩ්කාර් ප්‍රොක්සි බහාලුම් මගින් RAM විශාල පරිභෝජනය සහ ඔබට එය සමඟ කටයුතු කළ හැකි ආකාරය සාකච්ඡා කරන්න.

මූලාශ්රය: www.habr.com