دختری سوار بر اسکوتر تصویر Freepik، لوگوی Nomad از HashiCorp

Kubernetes یک گوریل ارکستراسیون کانتینری 300 کیلوگرمی است. این در برخی از بزرگترین سیستم های کانتینری در جهان کار می کند، اما هزینه دارد.

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

چه چیزی می خواهید

تیم ما تعدادی از خدمات نظارت بر عملکرد و تجزیه و تحلیل معمولی را حفظ می کند: نقاط پایانی API برای معیارهای نوشته شده در Go، صادرات Prometheus، تجزیه کننده های گزارش مانند Logstash و گولومو همچنین پایگاه های داده ای مانند InfluxDB یا Elasticsearch. هر یک از این سرویس ها در ظرف مخصوص به خود اجرا می شوند. ما به یک سیستم ساده نیاز داریم تا همه چیز در حال اجرا باشد.

ما با لیستی از الزامات برای ارکستراسیون کانتینر شروع کردیم:

اجرای مجموعه ای از خدمات در بسیاری از ماشین ها.
مروری بر خدمات در حال اجرا
روابط بین خدمات
راه اندازی مجدد خودکار در صورت خرابی سرویس.
تعمیر و نگهداری زیرساخت توسط یک تیم کوچک.

علاوه بر این، موارد زیر خوب هستند، اما نیازی به افزودن ندارند:

علامت گذاری ماشین ها با قابلیت هایشان (به عنوان مثال، علامت گذاری ماشین ها با دیسک های سریع برای سرویس های I/O سنگین).
توانایی اجرای خدمات مستقل از ارکستراتور (به عنوان مثال، در طول توسعه).
مکانی مشترک برای به اشتراک گذاشتن تنظیمات و اسرار.
نقطه پایان برای معیارها و گزارش‌ها.

چرا Kubernetes برای ما نیست

در حین ساخت نمونه اولیه با Kubernetes، متوجه شدیم که شروع به اضافه کردن لایه‌های منطقی پیچیده‌تر و بیشتر کردیم، که به طور ضمنی به آن تکیه کردیم.

به عنوان مثال، Kubernetes از تنظیمات سرویس داخلی پشتیبانی می کند ConfigMaps. شما می توانید به سرعت گیج شوید، به خصوص هنگام ادغام چندین فایل پیکربندی یا اضافه کردن خدمات اضافی به یک pod. Kubernetes (یا سکان در این مورد) به شما امکان می دهد به صورت پویا پیکربندی های خارجی را برای جداسازی نگرانی ها تزریق کنید. اما این منجر به یک ارتباط سخت و تاریک بین پروژه شما و Kubernetes می شود. با این حال، Helm و ConfigMaps اختیاری هستند، بنابراین نیازی به استفاده از آنها ندارید. شما فقط می توانید پیکربندی را در تصویر Docker کپی کنید. با این حال، وسوسه انگیز است که آن مسیر را طی کنید و انتزاعات غیر ضروری بسازید که ممکن است بعداً پشیمان شوید.

علاوه بر این، اکوسیستم Kubernetes به سرعت در حال تکامل است. به روز ماندن با بهترین شیوه ها و جدیدترین ابزارها زمان و انرژی زیادی می طلبد. Kubectl، minikube، kubeadm، helm، tiller، kops، oc - این لیست همچنان ادامه دارد. برای شروع به همه این ابزارها نیاز نیست، اما شما نمی دانید به چه چیزی نیاز دارید، بنابراین باید از همه چیز آگاه باشید. به همین دلیل، منحنی یادگیری بسیار شیب دار است.

زمان استفاده از Kubernetes

بسیاری از افراد در شرکت ما از Kubernetes استفاده می کنند و کاملاً از آن راضی هستند. این نمونه ها توسط گوگل یا آمازون مدیریت می شوند که منابع پشتیبانی کافی دارند.

Kubernetes همراه است ویژگی های شگفت انگیز، که ارکستراسیون کانتینر در مقیاس بزرگ را قابل مدیریت تر می کند:

دقیق مدیریت حقوق.
کنترلرهای سفارشی منطق را به خوشه اضافه کنید. آنها فقط برنامه هایی هستند که با API Kubernetes صحبت می کنند.
مقیاس خودکار! Kubernetes قادر است خدمات را در صورت تقاضا با استفاده از معیارهای سرویس بدون نیاز به مداخله دستی مقیاس‌بندی کند.

سوال این است که آیا واقعاً به همه این ویژگی ها نیاز دارید؟ شما نمی توانید فقط بر انتزاعات تکیه کنید. باید بفهمی زیر کاپوت چه خبره.

تیم ما بیشتر خدمات را از راه دور (به دلیل ارتباط نزدیک با زیرساخت اصلی) ارائه می دهد، بنابراین ما نمی خواستیم خوشه Kubernetes خود را افزایش دهیم. ما فقط می خواستیم خدمات ارائه دهیم.

باتری ها گنجانده نشده است

Nomad 20 درصد ارکستراسیون است که 80 درصد آنچه مورد نیاز است را می دهد. تنها کاری که انجام می دهد مدیریت استقرارها است. Nomad به استقرارها رسیدگی می کند، در صورت بروز خطا، کانتینرها را مجدداً راه اندازی می کند ... و تمام.

تمام هدف Nomad این است که چه می کند. کمترین: بدون مدیریت حقوق دقیق یا سیاست های شبکه پیشرفته، به طور خاص تصور شده است. این قطعات به صورت خارجی ارائه می شوند یا اصلا ارائه نمی شوند.

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

بهترین چیز در مورد Nomad این است که آسان است جایگزین کنید. عملاً هیچ قفل فروشنده ای وجود ندارد، زیرا عملکردهای آن به راحتی در هر سیستم دیگری که خدمات را مدیریت می کند ادغام می شود. درست مانند یک باینری معمولی در هر ماشینی در خوشه کار می کند، همین!

اکوسیستم عشایری با جفت آزاد

قدرت واقعی Nomad در اکوسیستم آن است. بسیار خوب با سایر محصولات - کاملا اختیاری - مانند کنسول (فروشگاه کلید-ارزش) یا طاق (دست زدن به اسرار). در داخل فایل Nomad بخش هایی برای استخراج داده از این سرویس ها وجود دارد:

template {
  data = <<EOH
LOG_LEVEL="{{key "service/geo-api/log-verbosity"}}"
API_KEY="{{with secret "secret/geo-api-key"}}{{.Data.value}}{{end}}"
EOH

  destination = "secrets/file.env"
  env         = true
}

در اینجا کلید را می خوانیم service/geo-api/log-verbosity از کنسول و در حین کار آن را با یک متغیر محیطی نشان می دهیم LOG_LEVEL. ما همچنین کلید را ارائه می دهیم secret/geo-api-key از خرک به عنوان API_KEY. ساده اما قدرتمند!

به دلیل سادگی، Nomad به راحتی با سایر خدمات از طریق یک API قابل توسعه است. به عنوان مثال، برچسب های شغلی پشتیبانی می شوند. ما همه خدمات را با معیارها با برچسب برچسب گذاری می کنیم trv-metrics. به این ترتیب Prometheus به راحتی این خدمات را از طریق کنسول پیدا می کند و به طور دوره ای نقطه پایانی را بررسی می کند /metrics برای داده های جدید همین کار را می توان انجام داد، به عنوان مثال، برای سیاهههای مربوط، با استفاده از لکی.

نمونه های زیادی از توسعه پذیری وجود دارد:

یک کار جنکینز را با یک قلاب اجرا کنید، و کنسول زمانی که پیکربندی سرویس تغییر می‌کند، شغل Nomad را پیگیری می‌کند.
Ceph یک سیستم فایل توزیع شده را به Nomad اضافه می کند.
فابیو برای متعادل کردن بار

همه اینها اجازه می دهد زیرساخت ها را به صورت ارگانیک توسعه دهند بدون اشاره خاص به فروشنده

هشدار منصفانه

هیچ سیستمی کامل نیست من به شما توصیه نمی کنم که بلافاصله جدیدترین ویژگی ها را به تولید معرفی کنید. مطمئناً، اشکالات و ویژگی‌های از دست رفته وجود دارد، اما همین امر در مورد Kubernetes نیز صدق می‌کند.

در مقایسه با Kubernetes، جامعه Nomad چندان بزرگ نیست. Kubernetes در حال حاضر حدود 75 commit و 000 مشارکت کننده دارد، در حالی که Nomad حدود 2000 commit و 14 مشارکت کننده دارد. برای Nomad سخت خواهد بود که در سرعت با Kubernetes همراه شود، اما ممکن است لازم نباشد! این یک سیستم تخصصی تر است، و جامعه کوچکتر همچنین به این معنی است که درخواست کشش شما نسبت به Kubernetes بیشتر مورد توجه و پذیرش قرار می گیرد.

خلاصه

غذای آماده: از Kubernetes فقط به این دلیل که دیگران آن را انجام می دهند استفاده نکنید. نیازهای خود را به دقت ارزیابی کنید و بررسی کنید که کدام ابزار سودآورتر است.

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

اگر فقط به دنبال یک ارکستراتور قوی هستید که نگهداری و گسترش آن آسان باشد، چرا Nomad را امتحان نکنید؟ ممکن است تعجب کنید که این کار تا کجا شما را می برد.

اگر Kubernetes مانند یک ماشین است، Nomad یک اسکوتر است. گاهی به یکی نیاز دارید و گاهی به دیگری. هر دو حق وجود دارند.

منبع: www.habr.com

ممکن است به Kubernetes نیاز نداشته باشید