Istio و Kubernetes در حال تولید هستند. قسمت 2. ردیابی

در آخر مقاله ما به اجزای اصلی سرویس مش ایستیو نگاه کردیم، با سیستم آشنا شدیم و به سوالات اصلی که معمولاً هنگام شروع کار با ایستیو پیش می آید پاسخ دادیم. در این قسمت به نحوه سازماندهی مجموعه اطلاعات ردیابی در شبکه خواهیم پرداخت.

اولین چیزی که با شنیدن عبارت Service Mesh is tracing به ذهن بسیاری از توسعه دهندگان و مدیران سیستم می رسد. در واقع، ما یک سرور پراکسی ویژه به هر گره شبکه اضافه می کنیم که تمام ترافیک TCP از آن عبور می کند. به نظر می رسد که اکنون می توان به راحتی اطلاعات مربوط به تمام تعاملات شبکه در شبکه را ارسال کرد. متأسفانه، در واقعیت، تفاوت های ظریف زیادی وجود دارد که باید در نظر گرفته شود. بیایید به آنها نگاه کنیم.

تصور اشتباه شماره یک: ما می توانیم داده های پیاده روی آنلاین را به صورت رایگان دریافت کنیم.

در واقع، به صورت نسبتاً رایگان، ما فقط می‌توانیم گره‌های سیستم خود را با فلش‌ها و نرخ داده‌ای که بین سرویس‌ها منتقل می‌شود (در واقع فقط تعداد بایت‌ها در واحد زمان) به هم متصل کنیم. با این حال، در بیشتر موارد، سرویس‌های ما از طریق نوعی پروتکل لایه کاربردی مانند HTTP، gRPC، Redis و غیره ارتباط برقرار می‌کنند. و البته، ما می خواهیم اطلاعات ردیابی را به طور خاص برای این پروتکل ها ببینیم؛ ما می خواهیم نرخ درخواست را ببینیم، نه نرخ داده را. ما می خواهیم با استفاده از پروتکل خود تاخیر درخواست ها را درک کنیم. در نهایت، می‌خواهیم مسیر کاملی را که یک درخواست از ورود به سیستم ما تا دریافت پاسخ از کاربر طی می‌کند، ببینیم. این مشکل دیگر به این راحتی قابل حل نیست.

ابتدا، بیایید ببینیم که دهانه های ردیابی ارسال از نقطه نظر معماری در ایستیو چگونه به نظر می رسد. همانطور که از قسمت اول به یاد داریم، ایستیو یک جزء مجزا به نام Mixer برای جمع آوری تله متری دارد. با این حال، در نسخه فعلی 1.0.*، ارسال مستقیماً از سرورهای پروکسی، یعنی از پروکسی envoy انجام می شود. پروکسی Envoy از ارسال بازه های ردیابی با استفاده از پروتکل zipkin خارج از جعبه پشتیبانی می کند. اتصال پروتکل های دیگر امکان پذیر است، اما فقط از طریق یک افزونه. با 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 تشخیص می دهد). قالب این است: proto-extra.

برای اینکه تعداد زیادی پیکربندی برای تعیین پروتکل وصله نکنید، می توانید از یک راه حل کثیف استفاده کنید: مؤلفه Pilot را در لحظه ای که درست است وصله کنید. منطق تعریف پروتکل را انجام می دهد. در پایان، البته، تغییر این منطق به استاندارد و تغییر به یک قرارداد نامگذاری برای همه پورت ها ضروری خواهد بود.

برای درک اینکه آیا پروتکل واقعاً به درستی تعریف شده است، باید به هر یک از کانتینرهای sidecar با پروکسی envoy بروید و یک درخواست به پورت مدیریت رابط envoy با موقعیت /config_dump ارسال کنید. در پیکربندی به دست آمده، باید به قسمت عملیات سرویس مورد نظر نگاه کنید. در ایستیو به عنوان شناسه محل درخواست استفاده می شود. برای سفارشی سازی مقدار این پارامتر در ایستیو (سپس آن را در سیستم ردیابی خود خواهیم دید)، باید پرچم serviceCluster را در مرحله راه اندازی کانتینر sidecar مشخص کنید. به عنوان مثال، می توان آن را از روی متغیرهای به دست آمده از API رو به پایین kubernetes به صورت زیر محاسبه کرد:

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

یک مثال خوب برای درک اینکه چگونه ردیابی در فرستاده کار می کند اینجا.

خود نقطه پایانی برای ارسال بازه های ردیابی نیز باید در پرچم های راه اندازی پروکسی فرستاده مشخص شود، به عنوان مثال: --zipkinAddress tracing-collector.tracing:9411

تصور نادرست شماره دو: ما می‌توانیم با ارزان‌قیمت از طریق سیستم، ردپای کامل درخواست‌ها را خارج از جعبه به دست آوریم

متاسفانه اینطور نیست. پیچیدگی پیاده سازی بستگی به نحوه اجرای تعامل سرویس ها دارد. چرا اینطور است؟

واقعیت این است که برای اینکه istio-proxy بتواند مطابقت درخواست‌های دریافتی به یک سرویس را با کسانی که همان سرویس را ترک می‌کنند درک کند، کافی نیست که به سادگی تمام ترافیک را رهگیری کنیم. شما باید نوعی شناسه ارتباطی داشته باشید. پروکسی فرستاده HTTP از هدرهای ویژه ای استفاده می کند، که توسط آن ها envoy درک می کند که کدام درخواست خاص برای سرویس درخواست های خاصی را برای سرویس های دیگر ایجاد می کند. لیست این سربرگ ها:

• x-request-id,
• x-b3-traceid،
• x-b3-spanid،
• x-b3-parentspanid،
• x-b3-sampled،
• پرچم های x-b3
• x-ot-span-context.

اگر یک نقطه واحد دارید، به عنوان مثال، یک کلاینت اصلی، که می توانید چنین منطقی را در آن اضافه کنید، پس همه چیز خوب است، فقط باید منتظر بمانید تا این کتابخانه برای همه مشتریان به روز شود. اما اگر سیستم بسیار ناهمگنی دارید و در انتقال از سرویسی به سرویس دیگر از طریق شبکه یکپارچگی وجود ندارد، به احتمال زیاد این یک مشکل بزرگ خواهد بود. بدون افزودن چنین منطقی، تمام اطلاعات ردیابی تنها "تک سطح" خواهند بود. یعنی ما همه تعاملات بین سرویسی را دریافت خواهیم کرد، اما آنها به زنجیره های عبور منفرد از طریق شبکه چسبانده نمی شوند.

نتیجه

ایستیو ابزار مناسبی برای جمع آوری اطلاعات ردیابی از طریق شبکه فراهم می کند، اما باید بدانید که برای پیاده سازی باید سیستم خود را تطبیق دهید و ویژگی های پیاده سازی ایستیو را در نظر بگیرید. در نتیجه، دو نکته اصلی باید حل شود: تعریف پروتکل سطح برنامه (که باید توسط پروکسی فرستاده پشتیبانی شود) و تنظیم ارسال اطلاعات در مورد اتصال درخواست ها به سرویس از درخواست های سرویس (با استفاده از هدرها). ، در مورد پروتکل HTTP). وقتی این مسائل حل شد، ما ابزار قدرتمندی داریم که به ما امکان می‌دهد به طور شفاف اطلاعات را از شبکه جمع‌آوری کنیم، حتی در سیستم‌های بسیار ناهمگن که به زبان‌ها و چارچوب‌های مختلف نوشته شده‌اند.

در مقاله بعدی در مورد Service Mesh، یکی از بزرگترین مشکلات ایستیو را بررسی خواهیم کرد – مصرف زیاد RAM توسط هر کانتینر پراکسی sidecar و نحوه مقابله با آن را مورد بحث قرار خواهیم داد.

منبع: www.habr.com