لینک کوتاه مطلب : https://hsgar.com/?p=6823

از HN بپرسید: آیا شما Kubernetes را ترک کرده اید؟

ما چند تیم تلاش کرده‌ایم، اما به محض اینکه از «من می‌خواهم مقداری کد را اجرا کنم» فراتر رفتید، هیچ‌کس واقعاً چیزی برای شما ندارد. به جای تلاش برای اختراع مجدد چرخ (کشف خدمات، TLS متقابل، قابلیت‌های ارائه‌دهنده متقابل) با موفقیت، بسیار سریع سرازیر شد و آنها به عقب رفتند. (این بیشتر به دلیل هزینه بود زیرا سایر خدمات می توانند خیلی سریع گران شوند و به دلیل عدم دانش گسترده در دسترس برای چیزهای سفارشی که آنها باید می ساختند)

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

ما انجام دادیم. مورد استفاده ما این است که کانتینرها را بر اساس درخواست به کنش‌های کاربر می‌چرخانیم، به آنها نام‌های میزبان زودگذر و قابل مسیریابی از طریق اینترنت می‌دهیم، و وقتی همه اتصالات ورودی قطع می‌شوند، آنها را خاموش می‌کنیم. از آنجا که کاربران منتظر تعامل با این کانتینرها هستند، زمان شروع Kubernetes بسیار کند بود و معماری آن مناسب نیست.

ما در نهایت هواپیمای کنترلی خود را نوشتیم که از NATS به عنوان گذرگاه پیام استفاده می کند. ما در حال تهیه منبع باز آن در اینجا هستیم: https://github.com/drifting-in-space/spawner

> ما زمان شروع با Kubernetes را بسیار کند یافتیم

فقط کنجکاو هستم اگر می توانید در اینجا توضیح دهید؟ من با k8s روی داکر کار می‌کنم، و همچنین قرار است کانتینرهای زودگذر (و بیشتر چیزهای دیگری که شما می‌گویید) را با نوت‌بوک‌های jupyter بچرخانیم. ما همه با k8s آشنا هستیم، اما از آنجایی که ممکن است شما از من جلوتر باشید، فقط به این فکر می کنم که با چه موانعی روبرو شده اید؟

مشکل بزرگ ما این بود که واکشی ظروف بیش از حد طول کشید زیرا ما ظروف سینک آشپزخانه داریم که هر کدام 10 گیگابایت (!) هستند. به نظر می رسد که اگر تصویر از قبل کشیده شده باشد، خیلی سریع می چرخند. من روی سرویسی کار کرده ام که در خوشه k8s زندگی می کند تا تصاویر را بکشد تا مطمئن شوم تازه هستند (https://github.com/lsst-sqre/cachemachine) اما کنجکاو هستید که در مورد آن صحبت می کنید یا شبکه؟

از آنجایی که در مخزن شما به نظر می رسد، ممکن است لازم باشد زمان پاسخگویی جلسه (مانند ms) را از مرورگر انجام دهید؟

وای، این عالی است! در کار قبلی، ما از k8s + knative برای چرخاندن ظروف بر حسب تقاضا استفاده می‌کردیم و به همین ترتیب از تاخیرها ناراضی بودیم. Spawner عالی به نظر می رسد.

یک سوال: آیا مجبور به ساخت کانتینر سفارشی بر اساس تقاضا شده اید، و اگر چنین است، آیا مجبور شده اید با ظروف بزرگ “سینک آشپزخانه” (مثلاً یک تصویر پایه پایتون با چند بسته بزرگتر نصب شده از PyPI، به علاوه برخی بسته های سیستمی) سروکار داشته باشید. مانند مشتری Postgres)؟ ما با استفاده از ابزارهایی مانند kaniko با زمان‌های ساخت تصویر بسیار طولانی مواجه می‌شویم و کش معمولاً فقط یک مزیت محدود دارد.

من در حال آزمایش با استفاده از Nix بودم تا شاید برخی از این مشکلات را حل کنم، اما هرگز به اندازه کافی برای اجرای تست سرعت نرسیدم و سپس قبل از اتمام کار را ترک کردم. اما به نظر من از نوعی الگوریتم مانند Nixery استفاده می کند (https://nixery.dev) برای تولید لایه‌های کش با ساخت‌های کاملاً تکرارپذیر و هیچ چیز اضافی کمکی نمی‌کند.

شاید این مشکلی نباشد که شما مجبور به حل آن هستید، اما اگر حل شود، من از نظرات شما خوشحال خواهم شد.

این واقعا عالی است. با تشکر از شما برای به اشتراک گذاری این.

یکی از ایده‌های من اخیراً ارتقاء FaaS به سرور کامل پس از حجم معینی از ترافیک بوده است. یا به عبارت دیگر، یک سرور اختصاصی که همان برنامه را به عنوان توابع قابل فراخوانی، به عنوان RPC مقیاس پذیر، ارائه می دهد و به یک نمونه اختصاصی متشکل از توابع گفته شده ارتقا می دهد. بهترین از هر دو جهان.

مقیاس صفر سرور بدون سرور را با مقیاس پذیری و ظرفیت یک سرور اختصاصی ترکیب کنید.

به عشایر رفتم که برای حجم کاری من بهتر کار می کند.

هنوز موارد استفاده ای وجود دارد که k8s برنده می شود. اما دسته‌های عشایری کمی بهتر می‌شوند و از ابتدا راحت‌تر می‌توان درباره آن استدلال کرد.

یه جورایی…..

من از خوشه‌های K8s روی فلز، که یک PITA کامل بودند و نیاز به یک تیم کامل برای مدیریت داشتند، به استفاده از EKS رفتم که همه چیزهایی بود که K8s باید … آسان باشد.

نه، من k8s را دوست دارم. چیزی که من دوست ندارم این است که مردم سعی می کنند بیش از حد باهوش باشند و جهنم پیکربندی قالب ها، تنظیمات شبکه های عجیب و غریب و گواهی های شکسته را پشت سر خود بگذارند. برای من شخصی بارهای کاری همه کانتینرهای اولیه با یک پروکسی معکوس هستند.

ما حدود 4 سال است که از k8s استفاده کرده ایم و اکنون به آرامی از k8s به fargate برمی گردیم

ایجاد یک سیستم مقیاس پذیر در محدوده حساب aws پیچیده است

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

شرکت فعلی من از آن استفاده می کند و این انتخاب بدی نیست. من نومد را ترجیح می دهم که از سال 2016 استفاده کرده ام.

من چند هفته گذشته را صرف کار با kustomize کرده‌ام، زیرا از فرمان خوشم نمی‌آید و در حالی که کار را انجام می‌دهد، فکر می‌کنم تانکا بهتر است.

ما در GKE هستیم که کار را بسیار آسان‌تر می‌کند و من شخصاً انتخاب نمی‌کنم که کلاستر خودم را اجرا کنم.

(سلب مسئولیت: من در سال 2020 به مدت 4 ماه در هاشی کار کردم اما مربوط به عشایر نبود)

برای کسانی که از K8 به طور گسترده استفاده کرده اند …

1. واقعا اینقدر پیچیده است؟

2. آیا این پیچیدگی اتفاقی است یا ضروری؟

3. آیا می‌توانیم با مجموعه ساده‌تری از انتزاعات برای 90 درصد برنامه‌ها کنار بیاییم؟

> 3. آیا می‌توانیم با مجموعه ساده‌تری از انتزاعات برای 90 درصد برنامه‌ها کنار بیاییم؟

نیازی نیست از همه منابعی که توسط K8s API در معرض دید قرار گرفته اند استفاده کنید. بیشتر مردم می‌توانند با چیزهای اساسی، به‌ویژه در یک خوشه مدیریت‌شده، رفت و آمد کنند. در واقع اکثر مردم این کار را می کنند.

برای یک توسعه دهنده استقرار در Kubernetes از طریق چیزی مانند Argo بسیار آسان است.

> 1. آیا واقعاً اینقدر پیچیده است؟

بستگی دارد. آیا شما یک سازمان بیش از 500 توسعه دهنده با خدمات زیاد هستید؟ سپس در مقایسه با آنچه در خارج وجود دارد آسان است. هر چیزی کمتر از آن، می‌توانم بگویم که پیچیده است و بهتر است از PaaS استفاده کنید

> 2. آیا این پیچیدگی اتفاقی است یا ضروری؟

بستگی دارد. اگر قرار است کارهای ساده را برای همیشه انجام دهید، این کار بیش از حد است. اما اگر انتظار دارید در آینده به روش‌های ناشناخته رشد کنید و نمی‌خواهید زمان خود را با انجام چندین مهاجرت در آینده تلف کنید، ضروری است.

> 3. آیا می‌توانیم با مجموعه ساده‌تری از انتزاعات برای 90 درصد برنامه‌ها کنار بیاییم؟

شاید؟ Heroku، AppEngine، CloudFoundry تلاش کردند، اما زیاد جلو نرفتند. بیایید ببینیم محصول جدید ارائه‌های PaaS قادر به انجام چه کاری هستند

1. من از آن در یک شرکت قدیمی در روزهای اولیه K8s استفاده می کردم. ما راه اندازی خودمان را اجرا کردیم، زیرا EKS و AKS وجود نداشتند. GCP انجام داد، اما ما روی AWS بودیم. واقعاً بسیار پیچیده است، با این حال، با EKS، GCP، و AKS، آن را بسیار آسان‌تر می‌کند. توجه داشته باشید، برای کاربران بسیار ساده تر از گزینه های جایگزین است. مطمئناً هیروکو نیست، اما در مقایسه با اجرای بر روی AWS، GCP، Azure یا بدتر از آن بر روی فلز لخت، کار را بسیار آسان‌تر می‌کند.

2. ضروری. K8s مشکلی را حل می کند که بسیار پیچیده است. شما واقعا نمی توانید آن را به روشی ساده حل کنید.

3. احتمالاً، اما به هر حال آن 10 درصد به انتزاعات و پیچیدگی های اضافی نیاز دارد و مدیریت یک سیستم به جای 2 آسان تر خواهد بود.

k8s در واقع به عنوان یک کاربر بسیار ساده است. کار کردن با آن بدون EKS

ما نه تنها Kubernetes را ترک کردیم، بلکه Docker را نیز ترک کردیم.

با سرورهای لینوکس و SSH جایگزین شده است.

در گذشته کارهای زیادی با k8 انجام داده ام. ابزار مناسبی برای راه اندازی من نیست.

نوع؟

برای پروژه‌های جدیدم امروزه، رویکردهای بدون سرور را با استفاده از AWS Lambdas (در پشت دروازه‌های API برای مواردی که باید با HTTP قابل دسترسی باشند) به کار می‌برم.

فکر می‌کنم این پیچیدگی را از مدیریت Kubernetes و ده هزار فایل یامل همراه آن به زیرساخت به عنوان کد و پیچیدگی‌های برخورد با AWS تغییر می‌دهد. و من اتفاقاً دومی را ترجیح می‌دهم، هرچند که بی‌نهایت بهتر نیست.

برای موارد معدودی که باید همیشه آنلاین یا برنامه‌های خود میزبان شخص ثالث باشند، من هنوز در Kubernetes یا در صورت امکان Docker خالص هستم.

این یک رفتار چرخه ای معمولی است.

1. فناوری اثبات شده “فقط کار می کند”

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

3. در واقع، خیلی پیچیده است.

4. بازگشت به فناوری اثبات شده که “فقط کار می کند”

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

مدیریت k8s نیاز به یک تیم قوی DevOps دارد. یک مهندس DevOps قوی یک مهندس نرم افزار قوی به علاوه یک تخصص است. این افراد کمیاب و گران هستند و جذب استارتاپ ها بسیار سخت است.

بنابراین شما یا نمی توانید کسی را پیدا کنید یا به احتمال زیاد مهندسان کمتر خوب DevOps را استخدام می کنید.

راه حل این است که از k8s به عنوان راه اندازی استفاده نکنید. هرچه یک مهندس DevOps کمتر بتواند به پای خود شلیک کند، بهتر است.

واقعا ای کاش Rancher Rancher 1.6 را رها نمی کرد و به سمت k8s نمی رفت. این یک راه حل عالی برای یک تجارت کوچک و فلز لخت بود.

من سعی می کنم روی k3 ها حرکت کنم اما برای اجرای هر چیزی خیلی پیچیده است و هنوز مشکل ارائه خدمات به اینترنت حل نشده است.

چیزی که من می‌خواهم این است که اعلام کنم می‌خواهم این سرویس تحت این دامنه و این IP باشد – بنابراین برای این کار شما هنوز باید بار متعادل کننده (فلز لخت) خود را به صورت دستی پیکربندی کنید، گواهی‌های راه‌اندازی و غیره را تنظیم کنید. من در حال نوشتن ابزاری برای خودکار کردن این هستم، اما این یک درد بوده است

قطعی نبود، بیشتر یک “بعد می بینمت” بود. شرکت منابع کافی (افراد) برای حفظ خوشه نداشت و ما تصمیم گرفتیم از ECS در حالی که هنوز به عنوان یک تیم در حال بلوغ بودیم استفاده کنیم.

هنوز هم قوی در مشتریان کار می کند، شرکت های بزرگ.

برای پروژه های شخصی فقط با docker رول می کنم.

حداقل نیازهای k8s من را اذیت می کند، می خواهم روی ماشین های 5 دلاری مستقر شوم

K3s عالی است!

من از آن برای میزبانی چندین پروژه کوچک در ماشین های مجازی ارزان استفاده کردم. تنظیم بسیار ساده است. من حدس می‌زنم که ما فقط به پشتیبانی ویرایش بهتر YAML نیاز داریم.

با تشکر از توصیه!

آره! استارت آپ من 5 نفره انجام داد. ما کار خود را با یک خوشه Kubernetes مدیریت شده در DigitalOcean شروع کردیم، اما دلایل متعددی وجود داشت که باعث شد ما با این تنظیمات خیلی راحت نباشیم.

   - Taking random .yml configs from The InternetTM to install an Nginx Ingress with automatic LetsEncrypt certs felt not-exactly-great. It's no better than piping curl to bash, except the potential impact is not that your computer is dead, but the entirety of prod goes down.
   - Because of this, upgrades of Kubernetes are a pain. The DigitalOcean admin panel will complain about problems in 'our' configs, that aren't actually OUR configs. We don't know how to fix that, or if ignoring the warnings and upgrading will break our production apps.
   - Upgrades of Kubernetes itself aren't actually zero downtime, and we couldn't figure out how to do that (even after investing a significant amount of research time).  
   - We were using only a tiny subset of the functionality in Kubernetes. Specifically we wanted high-availability application servers (2+ pods in parallel) with zero-downtime deployments, connecting to a DO managed PostgreSQL instance, with a webserver that does SSL-termination in front of it.  
   - Setting up deployments from a GitLab CI/CD pipeline was pretty hard, and it turned out the functionality for managing a Kubernetes cluster from GitLab was not really done with our use case in mind (I think?).  
   - It would be bad enough if DigitalOcean shit the bed, but the biggest problem was that we couldn't reliably recognize if something was a problem caused by us, or by DO. Try explaining that one to your customers.

به طور خلاصه: خیلی پیچیده و شکننده بود، حتی زمانی که سر خود را دور آن چیزی بپیچید که یک Pod، یک Deployment، یک Ingress and Ingress Controller، و همه دیگر زبان های Kubernetes در واقع به معنای آن هستند. من گمان می‌کنم که برای انجام این کار به یک فرد زیرساخت اختصاصی نیاز دارید که چیزهای آنها را بشناسد، بنابراین برای شرکت‌های بزرگ‌تر می‌تواند منطقی باشد، اما برای وضعیت ما بیش از حد بود.

ما از نظر فکری کنترل این تنظیم را نداشتیم و من احساس راحتی نمی‌کنم که حجم کاری تولید (سیستم‌هایی که توسط ۲۰ هزار دانش‌آموز دبیرستانی استفاده می‌شوند، برنامه‌های کاربردی حیاتی که توسط شرکت‌های لجستیکی استفاده می‌شوند) را روی چیزی که نمی‌توانیم کاملاً درک کنیم، راحت می‌کنم.

ما به یک راه‌اندازی بسیار ساده‌تر در Fly.io رفتیم و از آن زمان خوشحالیم. مایه شرمساری است که به نظر می رسد آنها خیلی جوان هستند و نمی توانند واقعاً قابل اعتماد باشند، اما من گمان می کنم که این فقط یک موضوع زمان باشد. از نظر مجموعه ویژگی، آن چیزی است که ما نیاز داریم.

لینک منبع

ارسال یک پاسخ

آدرس ایمیل شما منتشر نخواهد شد.