Istio va Kubernetes ishlab chiqarishda. 2-qism. Kuzatuv

Oxirida maqola Biz Service Mesh Istio ning asosiy komponentlarini ko'rib chiqdik, tizim bilan tanishdik va Istio bilan ishlashni boshlashda odatda paydo bo'ladigan asosiy savollarga javob berdik. Ushbu qismda biz tarmoq orqali kuzatuv ma'lumotlarini yig'ishni qanday tashkil qilishni ko'rib chiqamiz.

Ko'pgina ishlab chiquvchilar va tizim ma'murlari "Service Mesh" so'zini eshitganlarida birinchi bo'lib esga tushadigan narsa bu tracing. Haqiqatan ham, biz barcha TCP trafigini o'tadigan har bir tarmoq tuguniga maxsus proksi-server qo'shamiz. Ko'rinishidan, endi tarmoqdagi barcha tarmoq shovqinlari haqida ma'lumotni osongina yuborish mumkin. Afsuski, aslida e'tiborga olish kerak bo'lgan ko'plab nuanslar mavjud. Keling, ularga qaraylik.

Birinchi raqamli noto'g'ri tushuncha: biz onlayn sayohat ma'lumotlarini bepul olishimiz mumkin.

Aslida, nisbatan bepul, biz faqat o'qlar bilan bog'langan tizimimizning tugunlarini va xizmatlar o'rtasida o'tadigan ma'lumotlar tezligini olishimiz mumkin (aslida, vaqt birligi uchun faqat baytlar soni). Biroq, ko'p hollarda, bizning xizmatlarimiz HTTP, gRPC, Redis va boshqalar kabi ba'zi turdagi amaliy qatlam protokollari orqali muloqot qiladi. Va, albatta, biz ushbu protokollar uchun maxsus kuzatuv ma'lumotlarini ko'rishni xohlaymiz; biz ma'lumotlar tezligini emas, balki so'rov tezligini ko'rishni xohlaymiz. Protokolimiz yordamida so'rovlarning kechikishini tushunmoqchimiz. Nihoyat, so'rov tizimimizga kirishdan foydalanuvchidan javob olishgacha bo'lgan to'liq yo'lni ko'rishni istaymiz. Endi bu muammoni hal qilish unchalik oson emas.

Birinchidan, Istio-da arxitektura nuqtai nazaridan kuzatuv oraliqlarini yuborish qanday ko'rinishini ko'rib chiqaylik. Birinchi qismdan eslaganimizdek, Istio telemetriyani yig'ish uchun Mixer deb nomlangan alohida komponentga ega. Biroq, joriy 1.0.* versiyasida yuborish to'g'ridan-to'g'ri proksi-serverlardan, ya'ni elchi proksi-serverdan amalga oshiriladi. Elchi proksi-server zipkin protokoli yordamida kuzatuv oralig'ini qutidan tashqarida yuborishni qo'llab-quvvatlaydi. Boshqa protokollarni ulash mumkin, lekin faqat plagin orqali. Istio bilan biz darhol yig'ilgan va sozlangan elchi proksi-serverni olamiz, u faqat zipkin protokolini qo'llab-quvvatlaydi. Agar biz, masalan, Jaeger protokolidan foydalanmoqchi bo'lsak va UDP orqali kuzatuv oralig'ini yubormoqchi bo'lsak, biz o'z istio-proksi tasvirimizni yaratishimiz kerak bo'ladi. İstio-proksi uchun maxsus plaginlarni qo'llab-quvvatlash mavjud, ammo u hali ham alfa versiyasida. Shuning uchun, agar biz ko'p sonli maxsus sozlamalarsiz qilishni istasak, kuzatuv oralig'ini saqlash va qabul qilish uchun ishlatiladigan texnologiyalar doirasi kamayadi. Asosiy tizimlardan, aslida, endi siz Zipkin-ning o'zidan yoki Jaeger-dan foydalanishingiz mumkin, ammo u erga hamma narsani zipkin-ga mos keladigan protokol yordamida yuborishingiz mumkin (bu unchalik samarali emas). Zipkin protokolining o'zi barcha kuzatuv ma'lumotlarini HTTP protokoli orqali kollektorlarga yuborishni o'z ichiga oladi, bu juda qimmat.

Yuqorida aytganimdek, biz dastur darajasidagi protokollarni kuzatmoqchimiz. Bu shuni anglatadiki, har bir xizmat yonida joylashgan proksi-serverlar hozir qanday shovqin sodir bo'layotganini tushunishlari kerak. Odatiy bo'lib, Istio barcha portlarni oddiy TCP sifatida sozlaydi, ya'ni hech qanday izlar yuborilmaydi. Izlarni yuborish uchun, birinchi navbatda, asosiy tarmoq konfiguratsiyasida ushbu parametrni yoqishingiz kerak va eng muhimi, xizmatda ishlatiladigan protokolga muvofiq kubernetes xizmat ko'rsatish ob'ektlarining barcha portlarini nomlash kerak. Ya'ni, masalan, shunday:

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  ports:
  - port: 80
    targetPort: 80
    name: http
  selector:
    app: nginx

Siz http-magic kabi murakkab nomlardan ham foydalanishingiz mumkin (Istio http-ni ko'radi va bu portni http so'nggi nuqtasi sifatida tan oladi). Format: proto-extra.

Protokolni aniqlash uchun juda ko'p sonli konfiguratsiyalarni tuzatmaslik uchun siz iflos vaqtinchalik echimdan foydalanishingiz mumkin: Pilot komponentini hozirgi vaqtda yamoqlang. protokolni aniqlash mantiqini bajaradi. Oxir-oqibat, albatta, bu mantiqni standartga o'zgartirish va barcha portlar uchun nomlash konventsiyasiga o'tish kerak bo'ladi.

Protokol haqiqatan ham to'g'ri belgilangan yoki yo'qligini tushunish uchun siz elchi proksi-server bilan yonbosh konteynerlaridan biriga kirishingiz va/config_dump manzili bilan elchi interfeysining administrator portiga so'rov yuborishingiz kerak. Olingan konfiguratsiyada siz kerakli xizmatning ishlash maydoniga qarashingiz kerak. U Istio'da so'rov qilingan joyning identifikatori sifatida ishlatiladi. Istio-da ushbu parametrning qiymatini sozlash uchun (keyin biz uni kuzatish tizimimizda ko'ramiz), yonbosh konteynerini ishga tushirish bosqichida serviceCluster bayrog'ini ko'rsatish kerak. Misol uchun, uni pastga qarab kubernetes API-dan olingan o'zgaruvchilardan quyidagicha hisoblash mumkin:

--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')

Elchida kuzatuv qanday ishlashini tushunish uchun yaxshi misol shu yerda.

Kuzatuv oraliqlarini yuborish uchun so'nggi nuqta ham elchi proksi-serverni ishga tushirish bayroqlarida ko'rsatilishi kerak, masalan: --zipkinAddress tracing-collector.tracing:9411

Ikkinchi raqamli noto'g'ri tushuncha: biz tizim orqali so'rovlarning to'liq izlarini qutidan tashqarida arzon narxda olishimiz mumkin

Afsuski, unday emas. Amalga oshirishning murakkabligi xizmatlarning o'zaro ta'sirini qanday amalga oshirganingizga bog'liq. Nega bunday?

Gap shundaki, istio-proksi xizmatga kiruvchi so'rovlarning bir xil xizmatni tark etganlar bilan mosligini tushunishi uchun barcha trafikni to'xtatib qo'yishning o'zi etarli emas. Sizda qandaydir aloqa identifikatori bo'lishi kerak. HTTP elchisi proksi-serveri maxsus sarlavhalardan foydalanadi, ular orqali elchi xizmatga qaysi maxsus so'rov boshqa xizmatlarga maxsus so'rovlarni yaratishini tushunadi. Bunday sarlavhalar ro'yxati:

• x-so'rov identifikatori
• x-b3-traceid,
• x-b3-spanid,
• x-b3-parentspanid,
• x-b3-namuna,
• x-b3-bayroqlar,
• x-ot-span-kontekst.

Agar sizda bitta nuqta bo'lsa, masalan, asosiy mijoz, unda siz bunday mantiqni qo'shishingiz mumkin bo'lsa, unda hamma narsa yaxshi, faqat ushbu kutubxona barcha mijozlar uchun yangilanishini kutishingiz kerak. Ammo agar sizda juda xilma-xil tizim mavjud bo'lsa va tarmoq orqali xizmatdan xizmatga o'tishda unifikatsiya bo'lmasa, bu katta muammo bo'lishi mumkin. Bunday mantiqni qo'shmasdan, barcha kuzatuv ma'lumotlari faqat "bir darajali" bo'ladi. Ya'ni, biz barcha xizmatlararo o'zaro aloqalarni olamiz, lekin ular tarmoq orqali o'tishning yagona zanjirlariga yopishtirilmaydi.

xulosa

Istio tarmoq orqali kuzatuv ma'lumotlarini yig'ish uchun qulay vositani taqdim etadi, ammo amalga oshirish uchun siz tizimingizni moslashtirishingiz va Istio dasturining xususiyatlarini hisobga olishingiz kerakligini tushunishingiz kerak. Natijada, ikkita asosiy fikrni hal qilish kerak: dastur darajasidagi protokolni aniqlash (uni elchi proksi-server qo'llab-quvvatlashi kerak) va xizmatdan so'rovlardan (sarlavhalar yordamida) so'rovlarni xizmatga ulash haqidagi ma'lumotlarni yo'naltirishni sozlash. , HTTP protokoli holatida). Ushbu muammolar hal etilgach, bizda turli tillarda va ramkalarda yozilgan juda heterojen tizimlarda ham tarmoqdan ma'lumotlarni shaffof to'plash imkonini beruvchi kuchli vosita mavjud.

Service Mesh haqidagi keyingi maqolada biz Istio bilan bog'liq eng katta muammolardan birini ko'rib chiqamiz - har bir proksi-server konteynerida RAMning katta iste'moli va bu bilan qanday kurashishingiz mumkinligini muhokama qilamiz.

Manba: www.habr.com