وقتی در جایگاه تصمیم گیرنده هستیم ، اوضاع خیلی بهم ریخته است؛ به خصوص که بررسی و دیدن حقیقت ها در بین هیاهو های بیرون بسیار دشوارست. در صنعت تکنولوژی و نرم‌افزار مد های زیادی می‌آیند و می‌روند. کوبرنتیز نیز یکی از این هایپ های تکنولوژی است که در سال های اخیر خیلی پرطرفدار شد. الآن که کوبرنتیز کمی از مد و نقطه‌ی اوج افتاده ، جای آن است که کمی واقعیت های تلخ و پنهان کوبرنتیز را ببینیم و با در نظر گرفتن آن ها در موردش تصمیم بگیریم.
ما در این پست می‌خواهیم حقایقی تلخ از کوبرنتیز را برای سازمان و کسب و کار بیان کنیم. ممکنه اسم کوبرنتیز را شنیده باشید و تصور کنید که مثل یک چوب جادو بسیاری از مشکلات سیستم نرم‌افزاری شرکت را حل می‌کند. ولی حقیقت طور دیگری است. برای رسیدن به این چراغ جادو (کوبرنتیز) باید از دره ها و پل های معلق خطرناکی عبور کنید. بیاید با هم چند تا از این موانع رفتن سمت کوبرنتیز را ببینیم.
کوبرنتیز برای نگهداری و حفاظت از داده ها خوب نیست و به راحتی ریسک از دست رفتن و خرابی داده‌ها وجود دارد. چرا؟ ایشو ها (یک نمونه) و باگ هایی وجود دارد که کوبرنتیز بعد از آپدیت یا بازیابی ، در وضعیتی قرار می‌گیرد که نمی تواند داده ها و دیتابیس را صحیح و سالم تحویل دهد. به نظرتون راه حل در این موقع چیست؟ پاک کردن و حذف دیتابیس و بازگرداندن بکاپ و این یعنی یک داون تایم و ریسک درست و حسابی.
در تعدادی از شرکت های ایرانی که تصمیم مهاجرت سیستم به کوبرنتیز گرفته اند ، بعضا دیده‌ام که مهاجرت دیتابیس ها در آخرین مرحله بوده یا دیتابیس اصلی را به شکل قبلی حفظ کرده و مهاجرت نداده‌اند.
لذت و راحتی کار با داشبورد های کوبرنتیز و پلاگین هان آن در عین حال که جذاب است ، خطرناک هم هست. این داشبورد ها وقتی راه اندازی شوند و در دسترس قرار گیرند ، مثل یک مین عمل نشده رفتار می‌کنند ، کوچک ترین اشتباه در کانفیگ یا حفظ امنیت آن تبعات زیادی به دنبال دارد. سایت بیاد پایین یا اطلاعات سایت به جای دیگری ارسال و هک شود و هزاران ریسک و گلوگاه دیگر. در این بایستی حواسمان به API Server نیز باشد که کارش از مین عمل نشده هم گذشته و مثل یک TNT وسط سرور و کلاستر است! (جزئی مهم که در کوبرنتیز master وظیفه دریافت دستورات و اجرای غیر مستقیم آن را بر عهده دارد و در واقع داشبورد ها و همچنین ابزار kubectl به آن وصل می‌شوند و request می‌زنند) این سطح از حساسیت نیاز به مدیریت و روال های مشخص دارد.
اگر بخواهید کلاستر کوبرنتیز را آپدیت کنید همواره بایستی پلن A و پلن B مشخصی داشته باشید که در امن ترین حالت باید دو کلاستر پروداکشن جداگانه باشد و این یعنی هزینه‌ی دوچندان. وگرنه قطعا (با احتمال بالایی) در هر بار آپدیت مشکلاتی بزرگ یا کوچک به وجود خواهد آمد.
اگر نخواهید کلاستر کوبرنتیز را آپدیت کنید هم کلاستر شما در معرض حملات هکر ها و مشکلات امنیتی قرار خواهد گرفت و به ریسک آن نمی ارزد. پس چاره ای نیست :\
همگی ازعان داریم که یادگیری کوبرنتیز سخت و بسیار پیچیده است. این مسیر آرام یادگیری در کنار سایر مسائل و وظایف کارمندان همه چیز را بد و بدتر می‌کند. در نتیجه بایستی برای داون تایم های متعدد و مشکلات عجیب پروداکشن آماده باشید و امیدی هم به وقوع معجزه نداشته باشید.
ممکن است بگویید که «این حرف ها برای ما نیست چونکه روی کلود هستیم» و چالش های بالا را انکار کنید و به گردن cloud provider بیاندازید.
متاسفانه این بیشتر شبیه یک رویاست. علاوه بر اختلالات سرویس دهنده ، معماری سیستم نیز در زمانی که روی کوبرنتیز است بسیاری از چالش های بالا را تجربه می‌کند. اینکه یک کوبرنتیز مدیریت شده گرفته اید به این معنی نیست که یک سرویس با آپتایم و ریسپانس تایم بالا را دارید بلکه به این معنی است که صرفا کلاستر کوبرنتیز را روی زیرساخت دیگری آماده گرفته اید و با یک داشبورد یا هر بستر دلخواه مدیریت دیگری ، سرویس خود را مستقر کرده‌اید. همین! هنوز دانش مدیریت کوبرنتیز را نیاز دارید.
در همین راستا سایتی وجود دارد که داستان های داون تایم و اختلال کوبرنتیز را جمع آوری کرده است. مرور آن قبل از تصمیم مهاجرت به زیرساخت کوبرنتیز خالی از لطف نیست.
ممنونم تا اینجای مقاله اومدید امیدوارم به درد بخور بوده باشه. کوبر تون بالا :)
نکته: این مقاله ترجمه ایست آزاد از این مقاله:
https://blog.jessfraz.com/post/the-business-executives-guide-to-kubernetes
پس‌نوشت: فلسفه‌ی این مقاله اینست که با وجود اینکه خودم از مدافعان و مروجان کوبرنتیز بودم و هستم ، ولی برای متعادل کردن خودم این مقاله هارو خوندم و مروری رویشان نوشتم.
