هنگام راه‌اندازی یک خوشه Kubernetes برای یک برنامه خاص، باید درک کنید که خود برنامه، کسب‌وکار و توسعه‌دهندگان به این منبع چه می‌گویند. با این اطلاعات، می‌توانید تصمیم‌گیری در زمینه معماری و به‌ویژه انتخاب یک کنترلر Ingress خاص را شروع کنید، که امروزه تعداد زیادی از آنها وجود دارد. به منظور دریافت ایده اولیه از گزینه های موجود بدون نیاز به مرور مقالات / اسناد و مدارک زیاد و غیره، ما این نمای کلی از جمله کنترل کننده های ورودی اصلی (آماده تولید) را آماده کرده ایم.
ما امیدواریم که در انتخاب یک راه حل معماری به همکاران کمک کند - حداقل به نقطه شروعی برای به دست آوردن اطلاعات دقیق تر و آزمایش های عملی تبدیل شود. پیش از این، ما سایر مواد مشابه را در شبکه مطالعه کردیم و، به اندازه کافی عجیب، یک بررسی کم و بیش کامل و مهمتر از همه - ساختار یافته - پیدا نکردیم. پس بیایید این شکاف را پر کنیم!
ضوابط
در اصل، برای انجام مقایسه و به دست آوردن هر نتیجه مفیدی، نه تنها باید حوزه موضوعی را درک کنید، بلکه باید فهرست خاصی از معیارها را نیز داشته باشید که بردار تحقیق را تعیین می کند. بدون تظاهر به تجزیه و تحلیل همه موارد احتمالی استفاده از Ingress / Kubernetes، ما سعی کردیم کلی ترین الزامات را برای کنترلرها برجسته کنیم - آماده باشید که در هر صورت باید تمام مشخصات و جزئیات خود را جداگانه مطالعه کنید.
اما من با ویژگی هایی شروع می کنم که آنقدر آشنا شده اند که در همه راه حل ها اجرا می شوند و مورد توجه قرار نمی گیرند:
- کشف پویا خدمات (کشف خدمات)؛
- خاتمه SSL؛
- کار با سوکت های وب
حالا برای مقایسه:
پروتکل های پشتیبانی شده
یکی از معیارهای اساسی انتخاب. ممکن است نرم افزار شما روی HTTP استاندارد کار نکند، یا ممکن است به کار بر روی چندین پروتکل به طور همزمان نیاز داشته باشد. اگر کیس شما غیراستاندارد است، حتما این فاکتور را در نظر بگیرید تا بعداً مجبور به پیکربندی مجدد خوشه نباشید. برای همه کنترلرها، لیست پروتکل های پشتیبانی شده متفاوت است.
نرم افزار در هسته
انواع مختلفی از برنامه ها وجود دارد که کنترل کننده بر اساس آنها ساخته شده است. محبوب ترین آنها nginx، traefik، haproxy، envoy هستند. در حالت کلی، ممکن است تأثیر چندانی بر نحوه دریافت و انتقال ترافیک نداشته باشد، اما دانستن تفاوت‌های ظریف و ویژگی‌های بالقوه «زیر کاپوت» همیشه مفید است.
مسیریابی ترافیک
بر اساس چه چیزی می توان در مورد جهت تردد به یک سرویس خاص تصمیم گرفت؟ معمولاً اینها میزبان و مسیر هستند، اما امکانات اضافی نیز وجود دارد.
فضای نام در یک خوشه
فضای نام (فضای نام) - توانایی تقسیم منطقی منابع در Kubernetes (به عنوان مثال، روی صحنه، تولید و غیره). کنترلرهای Ingress وجود دارند که باید به طور جداگانه در هر فضای نام نصب شوند (و سپس می توانند ترافیک را هدایت کنند تنها به غلاف های این فضا). و کسانی هستند (و اکثریت واضح آنها) که به صورت جهانی برای کل خوشه کار می کنند - در آنها ترافیک به هر غلاف خوشه، صرف نظر از فضای نام، هدایت می شود.
نمونه برای بالادست
ترافیک چگونه به نمونه های سالم برنامه، خدمات هدایت می شود؟ گزینه هایی با بررسی فعال و غیرفعال، تلاش مجدد، قطع کننده مدار وجود دارد (برای جزئیات بیشتر، به عنوان مثال، )، بررسی های بهداشتی سفارشی و غیره یک پارامتر بسیار مهم در صورتی که نیازهای بالایی برای در دسترس بودن و حذف به موقع سرویس های ناموفق از تعادل دارید.
الگوریتم های متعادل کننده
گزینه های زیادی وجود دارد: از سنتی به عجیب و غریب ، و همچنین ویژگی های فردی مانند .
احراز هویت
کنترل کننده از چه طرح های مجوز پشتیبانی می کند؟ پایه، خلاصه، oauth، خارجی-ath - فکر می کنم این گزینه ها باید آشنا باشند. اگر حلقه‌های توسعه‌دهنده (و/یا فقط خصوصی) زیادی وجود داشته باشد که از طریق Ingress به آنها دسترسی پیدا می‌کند، این یک معیار مهم است.
توزیع ترافیک
آیا کنترلر از مکانیسم های رایج توزیع ترافیک مانند قناری ها (قناری)، تست A/B، آینه سازی ترافیک (آینه کاری / سایه زدن) پشتیبانی می کند؟ این موضوع واقعاً دردناکی برای برنامه‌هایی است که نیاز به مدیریت دقیق و دقیق ترافیک برای آزمایش مولد، اشکال‌زدایی باگ‌های محصول به‌صورت آفلاین (یا با حداقل ضرر)، تجزیه و تحلیل ترافیک و غیره دارند.
اشتراک پولی
آیا گزینه پولی برای کنترلر با عملکرد پیشرفته و/یا پشتیبانی فنی وجود دارد؟
رابط کاربری گرافیکی (Web UI)
آیا رابط کاربری گرافیکی برای مدیریت پیکربندی کنترلر وجود دارد؟ عمدتا برای "دستی" و / یا برای کسانی که نیاز به ایجاد برخی تغییرات در پیکربندی Ingress'a دارند، اما کار با الگوهای "خام" ناخوشایند است. اگر توسعه دهندگان بخواهند آزمایش هایی را با ترافیک در حال پرواز انجام دهند، می تواند مفید باشد.
اعتبار سنجی JWT
وجود اعتبار سنجی داخلی توکن های وب JSON برای مجوز و اعتبارسنجی کاربر تا برنامه نهایی.
امکان سفارشی سازی پیکربندی
توسعه پذیری قالب به معنای داشتن مکانیسم هایی که به شما امکان می دهد دستورالعمل ها، پرچم ها و غیره خود را به قالب های پیکربندی استاندارد اضافه کنید.
مکانیسم های اساسی حفاظت از DDOS
الگوریتم‌های محدود نرخ ساده یا گزینه‌های پیچیده‌تر فیلتر ترافیک براساس آدرس‌ها، لیست‌های سفید، کشورها و غیره.
درخواست ردیابی
امکان نظارت، ردیابی و اشکال زدایی درخواست ها از Ingresses به سرویس ها / پادهای خاص، و در حالت ایده آل بین سرویس ها / پادها نیز وجود دارد.
WAF
پشتیبانی .
کنترل کننده ها
لیست کنترل کننده ها بر اساس تشکیل شد и . ما برخی از آنها را به دلیل ویژگی یا شیوع کم (مرحله اولیه توسعه) از بررسی حذف کردیم. بقیه موارد در زیر مورد بحث قرار گرفته است. بیایید با توضیح کلی راه حل ها شروع کنیم و با یک جدول خلاصه ادامه دهیم.
ورود از Kubernetes
وب سایت:
مجوز: آپاچی 2.0
این کنترلر رسمی برای Kubernetes است و توسط انجمن در حال توسعه است. بدیهی است که از نام، بر اساس nginx است و با مجموعه متفاوتی از پلاگین های Lua که برای پیاده سازی ویژگی های اضافی استفاده می شود، تکمیل می شود. با توجه به محبوبیت خود nginx و حداقل تغییرات در آن هنگام استفاده به عنوان کنترلر، این گزینه ممکن است ساده ترین و آسان ترین پیکربندی برای مهندسان معمولی (با تجربه وب) باشد.
Ingress توسط NGINX Inc.
وب سایت:
مجوز: آپاچی 2.0
محصول رسمی توسعه دهندگان nginx. دارای نسخه پولی بر اساس . ایده اصلی سطح بالایی از ثبات، سازگاری ثابت با عقب، عدم وجود ماژول های اضافی و افزایش سرعت اعلام شده (در مقایسه با کنترل کننده رسمی) است که به دلیل رد Lua به دست آمده است.
نسخه رایگان به طور قابل توجهی کاهش می یابد، از جمله حتی در مقایسه با کنترل کننده رسمی (به دلیل عدم وجود همان ماژول های Lua). در عین حال، پولی دارای یک عملکرد اضافی نسبتاً گسترده است: معیارهای زمان واقعی، اعتبارسنجی JWT، بررسی های سلامت فعال و موارد دیگر. یک مزیت مهم نسبت به NGINX Ingress پشتیبانی کامل از ترافیک TCP / UDP (و در نسخه انجمن نیز!) است. منهای - ویژگی توزیع ترافیک، که با این حال، "بالاترین اولویت را برای توسعه دهندگان دارد"، اما پیاده سازی آن زمان می برد.
کنگ ورود
وب سایت:
مجوز: آپاچی 2.0
محصول توسعه یافته توسط Kong Inc. در دو نسخه تجاری و رایگان. بر اساس nginx که با تعداد زیادی ماژول Lua توسعه یافته است.
در ابتدا، روی پردازش و مسیریابی درخواست های API متمرکز بود، یعنی. به عنوان یک API Gateway، اما در حال حاضر به یک کنترلر Ingress تمام عیار تبدیل شده است. مزایای اصلی: بسیاری از ماژول های اضافی (از جمله ماژول های توسعه دهندگان شخص ثالث) که به راحتی نصب و پیکربندی می شوند و با کمک آنها طیف گسترده ای از ویژگی های اضافی پیاده سازی می شوند. با این حال، توابع داخلی در حال حاضر امکانات زیادی را ارائه می دهند. پیکربندی کار با استفاده از منابع CRD انجام می شود.
یکی از ویژگی های مهم محصول - کار کردن در یک کانتور (به جای نام متقاطع) یک موضوع بحث برانگیز است: برای برخی به عنوان یک نقطه ضعف به نظر می رسد (شما باید برای هر کانتور موجودیت هایی تولید کنید)، و برای کسی این یک ویژگی است ( بоسطح بیشتری از انزوا، به عنوان اگر یکی از کنترلرها خراب باشد، مشکل فقط به مدار محدود می شود).
ترافیک
وب سایت:
مجوز: MIT
پروکسی که در ابتدا برای کار با مسیریابی درخواست برای میکروسرویس ها و محیط پویا آنها ایجاد شد. از این رو، بسیاری از ویژگی‌های مفید: به‌روزرسانی پیکربندی بدون راه‌اندازی مجدد، پشتیبانی از تعداد زیادی روش متعادل‌سازی، رابط وب، ارسال معیارها، پشتیبانی از پروتکل‌های مختلف، REST API، نسخه‌های قناری و موارد دیگر. یکی دیگر از ویژگی‌های خوب، پشتیبانی از گواهی‌های Let's Encrypt خارج از جعبه است. نقطه ضعف این است که به منظور سازماندهی دسترسی بالا (HA)، کنترل کننده نیاز به نصب و اتصال ذخیره سازی KV خود دارد.
HAProxy
وب سایت:
مجوز: آپاچی 2.0
HAProxy از دیرباز به عنوان یک پروکسی و متعادل کننده ترافیک شناخته شده است. به عنوان بخشی از یک خوشه Kubernetes، به‌روزرسانی پیکربندی «نرم» (بدون از دست دادن ترافیک)، کشف سرویس مبتنی بر DNS، پیکربندی پویا با استفاده از API را ارائه می‌دهد. سفارشی کردن کامل قالب پیکربندی با جایگزینی CM و همچنین امکان استفاده از توابع کتابخانه Sprig در آن می تواند جذاب باشد. به طور کلی تاکید اصلی راه حل بر سرعت بالا، بهینه سازی و کارایی آن در منابع مصرفی است. مزیت کنترلر پشتیبانی از تعداد بی سابقه ای از روش های مختلف تعادل است.
مسافر کشتی یا وسیله مسافری دیگری
وب سایت:
مجوز: آپاچی 2.0
بر اساس کنترلر HAproxy، که به عنوان یک راه حل جهانی است که از طیف گسترده ای از ویژگی ها در تعداد زیادی از ارائه دهندگان پشتیبانی می کند. فرصتی برای متعادل کردن ترافیک در L7 و L4 ارائه شده است و متعادل کردن ترافیک TCP L4 به عنوان یک کل را می توان یکی از ویژگی های کلیدی راه حل نامید.
حد فاصل
وب سایت:
مجوز: آپاچی 2.0
این راه حل نه تنها بر اساس Envoy است: آن را توسعه داده است مشترکاً با نویسندگان این پروکسی محبوب. یک ویژگی مهم، امکان تفکیک کنترل منابع ورودی با استفاده از منابع IngressRoute CRD است. برای سازمان‌هایی که تیم‌های توسعه زیادی دارند که از یک خوشه استفاده می‌کنند، این کمک می‌کند تا امنیت کار با ترافیک در حلقه‌های همسایه را به حداکثر برساند و هنگام تغییر منابع ورودی از آنها در برابر خطا محافظت کند.
همچنین مجموعه گسترده‌ای از روش‌های متعادل‌سازی را ارائه می‌دهد (معناسازی درخواست، تکرار خودکار، محدود کردن نرخ درخواست و موارد دیگر)، نظارت دقیق بر جریان ترافیک و خرابی‌ها. شاید برای کسی، عدم پشتیبانی از جلسات چسبنده (اگرچه کار می کند) یک اشکال مهم باشد ).
ایستیو اینگرس
وب سایت:
مجوز: آپاچی 2.0
یک راه حل مشبک سرویس جامع که نه تنها یک کنترل کننده Ingress است که ترافیک ورودی را از خارج مدیریت می کند، بلکه تمام ترافیک درون خوشه را نیز کنترل می کند. در زیر کاپوت، Envoy به عنوان یک پروکسی کناری برای هر سرویس استفاده می شود. در اصل، این یک ترکیب بزرگ است که "می تواند هر کاری را انجام دهد" و ایده اصلی آن حداکثر مدیریت پذیری، توسعه پذیری، امنیت و شفافیت است. با استفاده از آن، می‌توانید مسیریابی ترافیک، دسترسی به مجوز بین سرویس‌ها، تعادل، نظارت، انتشار قناری و موارد دیگر را تنظیم کنید. اطلاعات بیشتر در مورد ایستیو را در سری مقالات بخوانید'.
سفیر
وب سایت:
مجوز: آپاچی 2.0
راه حل دیگری بر اساس Envoy. دارای نسخه های رایگان و تجاری است. این به عنوان "کاملا بومی Kubernetes" قرار می گیرد، که مزایای مربوطه را به ارمغان می آورد (ادغام فشرده با روش ها و موجودیت های خوشه K8s).
جدول مقایسه
بنابراین، نقطه اوج مقاله این جدول بزرگ است:
برای مشاهده نزدیکتر قابل کلیک است و همچنین در قالب موجود است .
به طور خلاصه
هدف مقاله ارائه درک کامل تری (اما، به هیچ وجه جامع!) از اینکه در مورد خاص خود چه انتخابی انجام دهید، است. طبق معمول، هر کنترل کننده مزایا و معایب خاص خود را دارد…
Ingress کلاسیک از Kubernetes به دلیل در دسترس بودن و اثبات بودن، ویژگی های به اندازه کافی غنی خوب است - در حالت کلی، باید "برای چشم ها کافی باشد". با این حال، اگر نیازهای بیشتری برای ثبات، سطح ویژگی ها و توسعه وجود دارد، باید به Ingress با NGINX Plus و اشتراک پولی توجه کنید. کنگ دارای غنی ترین مجموعه افزونه ها (و بر این اساس، فرصت هایی است که آنها ارائه می دهند) و در نسخه پولی حتی تعداد بیشتری از آنها وجود دارد. فرصت های زیادی برای کار به عنوان یک دروازه API، پیکربندی پویا بر اساس منابع CRD و همچنین خدمات اولیه Kubernetes دارد.
با افزایش الزامات برای متوازن سازی و روش های مجوز، نگاهی به Traefik و HAProxy بیندازید. اینها پروژه های منبع باز هستند که در طول سال ها ثابت شده اند، بسیار پایدار و فعالانه در حال توسعه هستند. Contour چند سالی است که منتشر شده است، اما هنوز خیلی جوان به نظر می رسد و فقط ویژگی های اساسی به Envoy اضافه شده است. اگر الزاماتی برای حضور / تعبیه WAF در جلوی برنامه وجود دارد، باید به همان Ingress از Kubernetes یا HAProxy توجه کنید.
و غنی ترین از نظر ویژگی ها محصولاتی هستند که بر روی Envoy ساخته شده اند، به ویژه ایستیو. به نظر می رسد این یک راه حل جامع است که "می تواند هر کاری را انجام دهد"، که با این حال، به معنای آستانه ورود به طور قابل توجهی بالاتر برای پیکربندی / راه اندازی / مدیریت نسبت به راه حل های دیگر است.
ما Ingress را از Kubernetes به عنوان یک کنترل کننده استاندارد انتخاب کرده ایم و هنوز از آن استفاده می کنیم که 80-90٪ نیازها را پوشش می دهد. کاملا قابل اعتماد است، پیکربندی و گسترش آن آسان است. به طور کلی، در غیاب الزامات خاص، باید برای اکثر خوشه ها / برنامه ها مناسب باشد. از همان محصولات جهانی و نسبتا ساده، Traefik و HAProxy را می توان توصیه کرد.
PS
در وبلاگ ما نیز بخوانید:
- "بازگشت به میکروسرویس با ایستیو": , , ;
- «"؛
- «'.
منبع: www.habr.com