در این قسمت از مقاله راجع به Kubernetes-native API در مقابل APIهای قدیمی REST یا SOAP صحبت می‌کنیم. احراز هویت و حق دسترسی یکپارچه می‌شوند و کاربر به یکپارچگی ساده‌تری از برنامه کاربردی و جریان کاری دست می‌یابد. توسعه‌دهندگان و اپراتورها از ابزارهایی می‌توانند استفاده کنند که به‌خوبی می‌شناسند؛ مانند Kubecti.
مجازی‌سازی بر انتزاعی‌سازی سخت‌افزار فیزیکی و استفاده از آن برای ایجاد چندین ماشین مجازی تمرکز دارد که می‌توانند این برنامه‌های مونولیتیک را در خود جای دهند. از سوی دیگر، بارهای کاری Cloud-native، به جای VM، کاملاً بر برنامه کاربردی متمرکز هستند. به این ترتیب، با تمرکز بر برنامه‌های کاربردی به‌عنوان واحد عملیاتی، انتزاعی‌سازی زیرساخت‌ها یا ذخیره‌های داده، عملیات مدیریت ساده می‌شود.
داشتن ابزار Backupای برای فراهم کردن امکان انعطاف‌پذیری و انتخاب رویکرد، ضروری است. هرسازمانی برای هدایت گردش کار Backup خود به API نیاز ندارد. برخی از سازمان‌ها برای این که تعیین مسیر خود به‌سمت Kubernetes به یک داشبورد نیاز دارند.
امنیت Kubernetes و یکپارچه‌سازی عمیق
یکپارچه‌سازی عمیق در جهت امنیت Kubernetes می‌تواند پیچیدگی پلتفرم اصلی را پنهان کند. می‌توان با دقت و تمرکز بر تجربه کاربری و بازبینی جریان‌های کاری Backupگیری برای برنامه‌های کاربردی Cloud-native، زمان و هزینه صرف‌شده برای کارهای دستی یا فعالیت‌های مرتبط با یکپارچه‌سازی را کاهش داد یا حذف کرد.
در گذشته، یک برنامه کاربردی بعضاً شامل چند ماشین مجازی بود، در حالی که برنامه‌های کاربردی Containerشده امروزی معمولاً از صدها منبع مجزای Kubernetes همچون پیکربندی، دیسک‌ها و اطلاعات محرمانه تشکیل شده‌اند.
همه این‌ها فقط مربوط به یک برنامه کاربردی است. حالا فرض کنیم که با وجود این همه برنامه کاربردی در کلاستر، اپراتور باید میلیون ها مؤلفه را بشناسد و از آن محافظت کند؛ مگر این که برنامه کاربردی، واحد عملیاتی Backupگیری باشد.
سیستم‌های Backupگیری قدیمی احتمالاً به زیرساخت‌هایی مانند دیسک‌ها و Volumeها می‌پردازند و منابع Kubernetes را نادیده می‌گیرند. این موضوع منجر به ایجاد خطاهای فراوان در راهنماهای بازیابی است که روابط لازم را ندارند و حاصل آن زمان بازیابی بسیار طولانی خواهد بود.
برای مشاوره رایگان جهت (باز)طراحی امنیت شبکه و یا انجام تست نفوذ مطابق با الزامات افتا با کارشناسان شرکت APK تماس بگیرید. |
در چنین وضعیت ناگواری به فرآیندی دستی نیاز خواهد بود تا دریابیم به چه Backupهایی برای بازیابی نیاز داریم، و سپس به فرآیند دستی پیچیده دیگری نیاز خواهیم داشت تا مجدداً Volumeهای بازیابی شده را به برنامه‌های کاربردی Kubernetes متصل کنیم. در این صورت، حتی اگر در Objectهای Kubernetes بین زمان Backupگیری تا بازیابی تغییری ایجاد نشده باشد، بار سنگینی بر دوش عملیات قرار خواهد گرفت.
در خصوص حفظ برنامه‌های کاربردی در حال اجرا حتی در صورت اختلالات جزئی در زیرساخت، به ندرت پلتفرمی را می‌توان یافت که به‌خوبی Kubernetes یا بهتر از آن عمل کند. تحمل خطا جذابیت سرویس را برای کاربران بالا می‌برد، اما مهم است که احساس امنیت کاذب نداشته باشیم و به این باور اشتباه برسیم که نیازی به Backupگیری، Disaster Recovery و تحرک‌پذیری برنامه کاربردی نیست.
باز هم، دسترس‌پذیری بالا و همسان‌سازی با Backupگیری یکسان نیستند. همچنان خطر خرابی یا حذف داده‌ها، چه به‌صورت تصادفی و چه از طریق عاملی مخرب، وجود خواهد داشت. اگر این اتفاق بیفتد، ممکن است به همه کپی‌ها سرایت کند و منجر به از دست رفتن فاجعه‌بار داده‌ها شود.
آیا این واقعیت که Kubernetes اغلب بر Public Cloud اجرا می‌شود، باعث نمی‌شود در برابر هرگونه خرابی مقاوم باشد؟ خیر؛ این خرافه‌ای بیش نیست. قابل‌اعتمادترین راهکارهای ذخیره‌سازی Cloud وعده Uptimeای بسیار قابل‌اتکا را می‌دهند، اما حفاظت از داده مسئولیت خود کاربر است.
بیشتر بخوانید: منظور از مشاهده‌پذیری و امنیت کوبرنتیز یا Kubernetes چیست – قسمت اول
Vendorهای Storage به‌صورت On-premise چطور؟ آن‌ها می‌توانند Volume Snapshot ارائه دهند، درست است؟ بله، اما این Snapshotها اغلب همچنان در برابر خرابی سخت‌افزار آسیب‌پذیر هستند و اگر Volumeای حذف شود، Snapshotهای مرتبط نیز معمولاً به‌صورت خودکار حذف خواهند شد.
اینجاست که قانون Backup 3-2-1 که قبلاً در بخش «برخورد با الگوهای مختلف پیاده‌سازی» توضیح داده شد، وارد عمل می‌شود. پیروی از این قانون کاربر را در برابر بیشتر سناریوهای خرابی، و نه همه آن‌ها، محافظت می‌کند؛ به‌خصوص زمانی که شروع به اعمال محافظت ثابت و غیرمتغیر از نسخه‌های خارج از سایت خود می‌کند.
معمولاً کاربر بدون دسترسی ویژه و بالاتر در امنیت Kubernetes، به اقداماتی مانند قطع فعالیت سیستم فایل دسترسی نخواهید داشت. اما اگر کاربر سیستم Backupگیری Kubernetes-native راا همراه با مجوزهای تعریف شده و کنترل دسترسی Role-based داشته باشد، می‌تواند پایگاه داده و ابزارهایی برای تعلیق جریان کاری Kubernetes را به دست‌آورد که باعث می‌شود بدون هرگونه نقض امنیتی به همان نتیجه دست یابد.
آنچه مهم است این است که توسعه‌دهندگان و عملیات نسبت به گذشته همراه با هم یا نزدیکتر به هم کار کنند. مخرج مشترکی که هدف آن‌ها را به هم مرتبط می‌کند، انجام کار درست برای داده‌هاست.
Disaster Recovery یکی دیگر از زمینه‌های کلیدی موردتوجه است. Backupگیری‌ها برای سناریوهای خرابی‌ای که می‌توانند از درون یک کلاستر بازیابی شوند، ضروری و اساسی هستند، اما Disaster Recovery به این معنی است که بارهای کاری کاربر در محیط کاملاً متفاوتی بارگذاری شوند.
Polyglot Persistence اصطلاحی است که به استفاده از فناوری‌های متعدد Data Storage برای نیازهای مختلف Data Storage در برنامه کاربردی یا در اجزای کوچکتر برنامه کاربردی اشاره دارد. اینجا فقط درباره دیتابیس‌های رابطه‌ای و غیر رابطه‌ای صحبت نمی‌کنیم، بلکه به مناطق Storage مانند داده‌های ورودی/داده‌های جریانی و صف‌های پیام نیز اشاره داریم.
این نیازهای مختلف Data Storage ممکن است در یک سازمان با چندین برنامه کاربردی یا در اجزای منحصر‌به‌فرد یک برنامه کاربردی که به شیوه‌های متفاوت ذخیره‌سازی داده احتیاج دارند، ایجاد شود. Polyglot Persistence با رواج بیشتر Kubernetes در حال افزایش است.
بیشتر بخوانید: کوبرنتیز یا Kubernetes چیست؟ چرا روش‌های امنیتی قدیمی در پیاده‌سازی آن کمک نمی کند – قسمت اول
خبر خوب این است که، با وجود این پیچیدگی، می‌توان با یکپارچه‌سازی در برابر Kubernetes برای کشف خودکار جریان‌های کاری، Backupگیری غنی‌تری برای این حجم‌های کاری دریافت کرد. این بدان معناست که راهکار Backup می‌تواند الزامات برنامه کاربردی را در نظر بگیرد و یکی از روش‌های Capturing اولیه (مانند Volume Snapshots، بک‌آپ‌گیری‌های سازگار با برنامه کاربردی و برداشت‌های منطقی) را برگزیند.
اکنون که سرویس داده واحد به تاریخ پیوسته است، Kubernetes Metadata می‌تواند به راهکار پشتیبان امکان دهد تا به‌طور خودکار رابطه بین چندین سرویس داده مستقل را تشخیص دهد.
درک بهتر و کنترل توپولوژی برنامه به راهکار Backupگیری Kubernetes-native امکان می‌دهد تا یک کپی ثابت از کل Stack برنامه کاربردی را، هم در داخل و هم در بین سرویس‌ها، Capture کند. به این ترتیب این راهکار این امکان را خواهد داشت که داده‌ها را از نسخه‌های کپی گردآوری کند و از تأثیر برنامه کاربردی بکاهد. عملکرد و کارایی بهبود می‌یابد و استفاده از موازی‌سازی Kubernetes باعث امنیت Kubernetes و بهینه‌سازی عملکرد بازیابی می‌شود.
بعد دیگری از پیچیدگی: سازمان‌های بیشتری در حال اجرای بسیاری از کلاسترهای Kubernetes در محیط‌های مختلف هستند. بنابراین، پلتفرم Backup باید با بخش‌های دیگر اکوسیستم زیرساخت Cloud-native تعامل داشته باشد.
کاربران در نهایت تجربه کاربری بهتری به دست خواهند آورد، به تیم‌های عملیاتی کمک خواهند کرد تا کارآمدتر باشند و هزینه‌ها را کاهش خواهند داد. یکی از مزایای این تجربه کاربری بهبودیافته این است که توسعه‌دهندگان و اپراتورها خواهند توانست به استفاده از ابزارهای Cloud-nativeای که با آن‌ها انس گرفته‌اند، ادامه دهند. برای مثال می‌توان برای Monitoring و هشدار با Prometheus، و با APIهای Kubernetes برای RBAC و با Auditing موردنیاز برای تجیزه و تحلیل ریشه‌ای یکپارچه‌سازی انجام داد.
