Sonda Biz Service Mesh Istio-nun əsas komponentlərinə baxdıq, sistemlə tanış olduq və adətən Istio ilə işə başladıqda yaranan əsas suallara cavab verdik. Bu hissədə biz şəbəkə üzərindən izləmə məlumatlarının toplanmasının necə təşkil olunacağına baxacağıq.
Bir çox tərtibatçı və sistem administratoru Service Mesh sözünü eşidəndə ağlına gələn ilk şey izləmədir. Həqiqətən, bütün TCP trafikinin keçdiyi hər bir şəbəkə node üçün xüsusi bir proxy server əlavə edirik. Görünür, indi şəbəkədə bütün şəbəkə qarşılıqlı əlaqələri haqqında məlumatı asanlıqla göndərmək mümkündür. Təəssüf ki, əslində nəzərə alınmalı olan bir çox nüanslar var. Gəlin onlara baxaq.
Bir nömrəli yanlış fikir: onlayn gəzinti məlumatlarını pulsuz əldə edə bilərik.
Əslində, nisbətən pulsuz olaraq, sistemimizin yalnız oxlarla birləşdirilmiş qovşaqlarını və xidmətlər arasında keçən məlumat sürətini əldə edə bilərik (əslində, yalnız vaxt vahidi üçün baytların sayı). Bununla belə, əksər hallarda xidmətlərimiz HTTP, gRPC, Redis və s. kimi bir növ tətbiq səviyyəsi protokolu üzərindən əlaqə saxlayır. Və əlbəttə ki, biz bu protokollar üçün xüsusi olaraq izləmə məlumatlarını görmək istəyirik; biz məlumat sürətini deyil, sorğu dərəcəsini görmək istəyirik. Protokolumuzdan istifadə edərək sorğuların gecikməsini anlamaq istəyirik. Nəhayət, sorğunun sistemimizə daxil olmasından istifadəçidən cavab almasına qədər keçdiyi tam yolu görmək istəyirik. Bu problemi həll etmək artıq o qədər də asan deyil.
Əvvəlcə, Istio-da memarlıq nöqteyi-nəzərindən izləmə məsafələrinin göndərilməsinin necə göründüyünə baxaq. Birinci hissədən xatırladığımız kimi, Istio-da telemetriya toplamaq üçün Mixer adlı ayrıca komponent var. Bununla belə, cari versiya 1.0.*-da göndərmə birbaşa proksi serverlərdən, yəni elçi proxy-dən həyata keçirilir. Elçi proksi qutudan kənarda zipkin protokolundan istifadə edərək izləmə aralıqlarının göndərilməsini dəstəkləyir. Digər protokolları birləşdirmək mümkündür, ancaq plagin vasitəsilə. Istio ilə biz dərhal yalnız zipkin protokolunu dəstəkləyən yığılmış və konfiqurasiya edilmiş envoy proxy alırıq. Məsələn, Jaeger protokolundan istifadə etmək və UDP vasitəsilə izləmə spanlarını göndərmək istəyiriksə, o zaman öz istio-proxy imicimizi yaratmalıyıq. İstio-proxy üçün xüsusi plaginlər üçün dəstək var, lakin o, hələ də alfa versiyasındadır. Buna görə də, çox sayda fərdi parametrlər olmadan etmək istəsək, izləmə aralıqlarını saxlamaq və qəbul etmək üçün istifadə olunan texnologiyaların çeşidi azalır. Əsas sistemlərdən, əslində, indi Zipkin-in özündən və ya Jaeger-dən istifadə edə bilərsiniz, lakin zipkin uyğun protokoldan istifadə edərək hər şeyi oraya göndərin (bu, daha az səmərəlidir). Zipkin protokolunun özü bütün izləmə məlumatlarının HTTP protokolu vasitəsilə kollektorlara göndərilməsini nəzərdə tutur ki, bu da olduqca bahalıdır.
Artıq dediyim kimi, biz proqram səviyyəsindəki protokolları izləmək istəyirik. Bu o deməkdir ki, hər bir xidmətin yanında dayanan proksi serverlər hazırda hansı qarşılıqlı əlaqənin baş verdiyini başa düşməlidirlər. Varsayılan olaraq, Istio bütün portları düz TCP olaraq konfiqurasiya edir, yəni heç bir iz göndərilməyəcək. İzlərin göndərilməsi üçün, ilk növbədə, əsas mesh konfiqurasiyasında bu seçimi aktivləşdirməlisiniz və çox vacib olanı, xidmətdə istifadə olunan protokola uyğun olaraq kubernetes xidmət obyektlərinin bütün portlarını adlandırmalısınız. Yəni, məsələn, belədir:
apiVersion: v1
kind: Service
metadata:
name: nginx
spec:
ports:
- port: 80
targetPort: 80
name: http
selector:
app: nginxSiz http-magic kimi mürəkkəb adlardan da istifadə edə bilərsiniz (Istio http görəcək və həmin portu http son nöqtəsi kimi tanıyacaq). Format belədir: proto-extra.
Protokolu müəyyən etmək üçün çox sayda konfiqurasiyaya düzəliş etməmək üçün çirkli bir həll yolu istifadə edə bilərsiniz: Pilot komponentini yeni olduğu anda yamaq. . Sonda, əlbəttə ki, bu məntiqi standarta dəyişmək və bütün portlar üçün adlandırma konvensiyasına keçmək lazım gələcək.
Protokolun həqiqətən düzgün müəyyən edilib-edilmədiyini başa düşmək üçün siz envoy proxy-si olan yan vaqon konteynerlərindən hər hansı birinə daxil olmalı və /config_dump yeri ilə elçi interfeysinin admin portuna sorğu göndərməlisiniz. Yaranan konfiqurasiyada istədiyiniz xidmətin əməliyyat sahəsinə baxmaq lazımdır. Istio-da sorğunun edildiyi yer üçün identifikator kimi istifadə olunur. Istio-da bu parametrin dəyərini fərdiləşdirmək üçün (sonra onu izləmə sistemimizdə görəcəyik), yan vaqon konteynerinin işə salınması mərhələsində serviceCluster bayrağını təyin etmək lazımdır. Məsələn, aşağı kubernetes API-dən əldə edilən dəyişənlərdən belə hesablana bilər:
--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')
Elçidə izləmənin necə işlədiyini başa düşmək üçün yaxşı bir nümunə .
İzləmə aralığını göndərmək üçün son nöqtənin özü də elçi proksi işə salma bayraqlarında göstərilməlidir, məsələn: --zipkinAddress tracing-collector.tracing:9411
İki nömrəli yanlış fikir: sistem vasitəsilə sorğuların tam izlərini qutudan kənarda ucuz əldə edə bilərik
Təəssüf ki, belə deyil. Tətbiqin mürəkkəbliyi xidmətlərin qarşılıqlı əlaqəsini necə həyata keçirdiyinizdən asılıdır. Niyə belədir?
Fakt budur ki, istio-proxy-nin bir xidmətə daxil olan sorğuların eyni xidmətdən çıxanlarla uyğunluğunu başa düşə bilməsi üçün bütün trafikin qarşısını almaq kifayət deyil. Bir növ ünsiyyət identifikatorunuz olmalıdır. HTTP envoy proksi xüsusi başlıqlardan istifadə edir, bu başlıqlar vasitəsilə elçi xidmətə hansı xüsusi sorğunun digər xidmətlərə xüsusi sorğular yaratdığını başa düşür. Belə başlıqların siyahısı:
- x-sorğu-id,
- x-b3-iz,
- x-b3-spanid,
- x-b3-parentspanid,
- x-b3-nümunə,
- x-b3-bayraqları,
- x-ot-span-kontekst.
Bir nöqtəniz varsa, məsələn, belə bir məntiqi əlavə edə biləcəyiniz əsas müştəri varsa, onda hər şey yaxşıdır, sadəcə bu kitabxananın bütün müştərilər üçün yenilənməsini gözləmək lazımdır. Ancaq çox heterojen bir sisteminiz varsa və şəbəkə üzərindən xidmətdən xidmətə keçiddə birləşmə yoxdursa, bu, çox güman ki, böyük bir problem olacaq. Belə bir məntiq əlavə etmədən bütün izləmə məlumatları yalnız “bir səviyyəli” olacaqdır. Yəni, biz bütün xidmətlərarası qarşılıqlı əlaqələri alacağıq, lakin onlar şəbəkə vasitəsilə tək keçid zəncirlərinə yapışmayacaqlar.
Nəticə
Istio şəbəkə üzərindən izləmə məlumatlarının toplanması üçün əlverişli alət təqdim edir, lakin siz başa düşməlisiniz ki, həyata keçirmək üçün sisteminizi uyğunlaşdırmalısınız və Istio tətbiqinin xüsusiyyətlərini nəzərə almalısınız. Nəticə etibarilə, iki əsas məqamı həll etmək lazımdır: tətbiq səviyyəsi protokolunun müəyyən edilməsi (elçi vəkil tərəfindən dəstəklənməlidir) və xidmətdən gələn sorğulardan (başlıqlardan istifadə etməklə) sorğuların xidmətə qoşulması haqqında məlumatın yönləndirilməsinin qurulması. , HTTP protokolu vəziyyətində). Bu problemlər həll edildikdə, bir çox müxtəlif dillərdə və çərçivələrdə yazılmış çox heterojen sistemlərdə belə şəbəkədən şəffaf şəkildə məlumat toplamağa imkan verən güclü alətimiz var.
Service Mesh haqqında növbəti məqalədə Istio ilə bağlı ən böyük problemlərdən birinə - hər bir yan vaqon proksi konteynerinin böyük RAM istehlakına baxacağıq və bununla necə məşğul ola biləcəyinizi müzakirə edəcəyik.
Mənbə: www.habr.com