Истио жана Кубернетес өндүрүштө. 2-бөлүк. Издөө

Акырында макала Биз Service Mesh Istio'нун негизги компоненттерин карап чыктык, система менен тааныштык жана адатта Istio менен иштей баштаганда пайда болгон негизги суроолорго жооп бердик. Бул бөлүктө биз тармак боюнча маалымат чогултууну кантип уюштурууну карап чыгабыз.

Көптөгөн иштеп чыгуучулар жана системалык администраторлор Service Mesh деген сөздү укканда биринчи ойго келе турган нерсе бул трасса. Чынында эле, биз ар бир тармак түйүнүнө атайын прокси серверди кошобуз, ал аркылуу бардык TCP трафиги өтөт. Бул тармактагы бардык тармактык өз ара аракеттенүү жөнүндө маалыматты оңой эле жөнөтүү мүмкүн болуп калды окшойт. Тилекке каршы, иш жүзүндө эске алынышы керек болгон көптөгөн нюанстар бар. Келгиле, аларды карап көрөлү.

Биринчи жаңылыш түшүнүк: биз онлайн жөө жүрүү маалыматтарын акысыз ала алабыз.

Чынында, салыштырмалуу акысыз, биз жебелер менен байланышкан системабыздын түйүндөрүн жана кызматтардын ортосунда өтүүчү маалымат ылдамдыгын гана ала алабыз (чындыгында, убакыт бирдигине байттардын саны гана). Бирок, көпчүлүк учурларда, биздин кызматтар HTTP, gRPC, Redis ж.б. Жана, албетте, биз бул протоколдор үчүн атайын маалыматты издөөнү каалайбыз; биз маалымат ылдамдыгын эмес, суроо-талаптын ылдамдыгын көргүбүз келет. Биз биздин протоколду колдонуу менен суроо-талаптардын кечиктирилишин түшүнгүбүз келет. Акыр-аягы, биз сурам биздин системага кирүүдөн колдонуучудан жооп алууга чейинки толук жолду көргүбүз келет. Бул маселени чечүү мындан ары оңой эмес.

Биринчиден, келгиле, Istioдогу архитектуралык көз караштан алганда, трассаны жөнөтүү кандай болорун карап көрөлү. Биринчи бөлүктөн эстегендей, Istio телеметрияны чогултуу үчүн Миксер деп аталган өзүнчө компонентке ээ. Бирок, учурдагы 1.0.* версиясында жөнөтүү түздөн-түз прокси серверлерден, тактап айтканда, элчи проксиден жүзөгө ашырылат. Элчи прокси кутудан zipkin протоколун колдонуу менен издөө аралыгын жөнөтүүнү колдойт. Башка протоколдорду туташтырууга болот, бирок плагин аркылуу гана. Istio менен биз дароо чогултулган жана конфигурацияланган өкүл проксисин алабыз, ал zipkin протоколун гана колдойт. Эгер биз, мисалы, Jaeger протоколун колдонуп, UDP аркылуу трассаны жөнөтүүнү кааласак, анда өзүбүздүн истио-прокси имиджин түзүшүбүз керек болот. İstio-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 акыркы чекит катары тааныйт). Формат: proto-extra.

Протоколду аныктоо үчүн көп сандагы конфигурацияларды жаңыртпаш үчүн, сиз ыплас чечүүнү колдонсоңуз болот: Пилот компонентин жаңы эле иштеп жаткан учурда жамоо. протоколду аныктоо логикасын аткарат. Акырында, албетте, бул логиканы стандартка өзгөртүү жана бардык порттор үчүн ат коюу конвенциясына өтүү керек болот.

Протокол чындап эле туура аныкталганбы же жокпу, түшүнүү үчүн, сиз элчи проксиси бар каптал контейнерлердин бирине кирип, /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-parentspanid,
• x-b3 үлгүсү,
• x-b3-желектери,
• x-ot-span-контекст.

Эгер сизде бир эле пункт болсо, мисалы, негизги кардар, ага сиз ушундай логиканы кошо аласыз, анда баары жакшы, сиз жөн гана бул китепкана бардык кардарлар үчүн жаңыртылышын күтүшүңүз керек. Бирок, эгерде сизде өтө гетерогендүү система болсо жана тармак аркылуу кызматтан сервиске өтүүдө биригүү жок болсо, анда бул чоң көйгөй болот. Мындай логиканы кошпостон, бардык чалгындоо маалыматы "бир деңгээлдеги" гана болот. Башкача айтканда, биз бардык кызматтар аралык өз ара аракеттенүүлөрдү алабыз, бирок алар тармак аркылуу өтүүнүн бирдиктүү чынжырларына жабышпайт.

жыйынтыктоо

Istio тармак аркылуу маалымат чогултуу үчүн ыңгайлуу куралды сунуштайт, бирок ишке ашыруу үчүн системаңызды ыңгайлаштырып, Istio ишке ашыруунун өзгөчөлүктөрүн эске алуу керек экенин түшүнүшүңүз керек. Натыйжада, эки негизги пунктту чечүү керек: колдонмо деңгээлиндеги протоколду аныктоо (прокси өкүл тарабынан колдоого алынышы керек) жана кызматтан келген суроо-талаптардан кызматка суроо-талаптарды туташтыруу жөнүндө маалыматты жөнөтүүнү орнотуу (баш тамгаларды колдонуу менен). , HTTP протоколунда). Бул маселелер чечилгенден кийин, биз ар кандай тилдерде жана алкактарда жазылган өтө гетерогендүү системаларда да, тармактан маалыматты ачык-айкын чогултууга мүмкүндүк берген күчтүү куралыбыз бар.

Service Mesh жөнүндө кийинки макалада биз Istio менен болгон эң чоң көйгөйлөрдүн бирин карап чыгабыз - ар бир капталдагы прокси-контейнердин оперативдүү эстутумун көп керектөө жана аны кантип чечүүгө болорун талкуулайбыз.

Source: www.habr.com