روش‌های بک‌آپ‌گیری از کلاستر Kubernetes؛ از etcd تا داده‌های برنامه

بک‌آپ‌گیری از کلاستر Kubernetes تنها به ذخیره فایل‌های YAML یا گرفتن Snapshot از ماشین‌های مجازی محدود نمی‌شود. یک برنامه بازیابی کامل باید وضعیت کلاستر، تعریف منابع، داده‌های پایدار برنامه‌ها و وابستگی‌های زیرساخت را پوشش دهد.

ممکن است پس از بازیابی، همه Podها در وضعیت Running باشند، اما پایگاه داده ناقص باشد یا برنامه به کلید رمزگشایی موردنیاز دسترسی نداشته باشد. بنابراین معیار موفقیت بک‌آپ، بازگشت سرویس و صحت داده‌های آن است.

چه بخش‌هایی از Kubernetes باید بک‌آپ داشته باشند؟

پیش از انتخاب ابزار، دارایی‌های موردنیاز برای بازیابی را مشخص کنید:

• وضعیت کلاستر: اطلاعات ذخیره‌شده در etcd.
• منابع Kubernetes: مانند Deployment، Service، ConfigMap، Secret، CRD و منابع سفارشی.
• داده‌های پایدار: محتوای Volumeهایی که پایگاه داده و برنامه‌های Stateful استفاده می‌کنند.
• پیکربندی زیرساخت: تنظیمات شبکه، ذخیره‌سازی، گواهی‌ها، کلیدهای رمزگذاری و روش ساخت مجدد کلاستر.
• وابستگی‌های بیرونی: مانند رجیستری تصاویر، DNS، پایگاه داده خارجی و سامانه مدیریت اسرار.

هر روش بک‌آپ بخشی از این نیازها را پوشش می‌دهد؛ هیچ‌کدام را نباید بدون بررسی، جایگزین تمام روش‌های دیگر دانست.

۱. بک‌آپ etcd برای بازیابی وضعیت کلاستر

etcd مخزن دادهٔ کلیدی Kubernetes است و وضعیت منابع کلاستر در آن نگهداری می‌شود. تهیه Snapshot از etcd برای بازیابی Control Plane در کلاسترهایی که خودتان مدیریت می‌کنید اهمیت دارد.

بااین‌حال، بک‌آپ etcd شامل محتوای واقعی دیسک‌های برنامه‌ها نیست. برای مثال، تعریف PVC و اطلاعات مربوط به آن می‌تواند در وضعیت کلاستر وجود داشته باشد، اما فایل‌های پایگاه داده داخل Volume باید جداگانه محافظت شوند.

روش تهیه و بازیابی Snapshot باید با نسخه etcd و شیوه نصب Kubernetes سازگار باشد. گواهی‌ها و کلیدهای لازم برای راه‌اندازی مجدد، از جمله کلیدهای رمزگذاری داده‌های Kubernetes در صورت استفاده، نیز باید در برنامه بازیابی لحاظ شوند. در سرویس‌های مدیریت‌شده، مسئولیت و امکانات بازیابی Control Plane را باید از ارائه‌دهنده بررسی کرد. مستندات رسمی مدیریت etcd در Kubernetes.

۲. نگهداری تنظیمات با GitOps و Infrastructure as Code

نگهداری Manifestها، Chartهای Helm و تنظیمات زیرساخت در مخزن نسخه‌بندی‌شده، ساخت مجدد محیط را تکرارپذیرتر می‌کند.

این روش برای برنامه‌هایی که تعریف آن‌ها کامل و به‌روز در مخزن نگهداری می‌شود مفید است. اما Git به‌تنهایی بک‌آپ کامل کلاستر نیست:

• تغییراتی که فقط داخل کلاستر انجام شده‌اند، ممکن است در مخزن نباشند.
• منابع ساخته‌شده توسط Operatorها باید در طرح بازیابی بررسی شوند.
• داده‌های Volumeها با ذخیره Manifest محافظت نمی‌شوند.
• اسرار باید با روش امن و همراه با کلیدهای بازیابی لازم مدیریت شوند.

کاربرد اصلی این لایه، بازسازی وضعیت مطلوب محیط است. برای بازیابی داده و تغییرات زمان اجرا، به روش‌های تکمیلی نیاز دارید.

۳. بک‌آپ منابع و داده‌ها با Velero

Velero ابزاری برای تهیه و بازیابی نسخه پشتیبان منابع Kubernetes است. بسته به تنظیمات، افزونه‌ها و روش انتخاب‌شده، می‌تواند حفاظت از داده‌های Volume را نیز در فرایند بک‌آپ وارد کند.

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

در طراحی باید مشخص کنید کدام منابع انتخاب می‌شوند، داده‌های Volume با چه روشی محافظت می‌شوند، نسخه‌ها کجا نگهداری می‌شوند و بازیابی به چه وابستگی‌هایی نیاز دارد. امکانات و محدودیت‌ها را بر اساس نسخه نصب‌شده بررسی کنید. مستندات رسمی Velero.

۴. Snapshot از Volumeها با CSI

Kubernetes با منابعی مانند VolumeSnapshot امکان درخواست Snapshot از ذخیره‌سازی را فراهم می‌کند. استفاده از این قابلیت به درایور CSI و پشتیبانی زیرساخت ذخیره‌سازی وابسته است.

Snapshot می‌تواند برای ثبت یک نقطه زمانی از Volume مفید باشد، اما دو موضوع باید جداگانه بررسی شوند:

استقلال نسخه: اگر Snapshot در همان سامانه ذخیره‌سازی باقی بماند، ممکن است خرابی کامل آن سامانه، نسخه اصلی و Snapshot را هم‌زمان تحت تأثیر قرار دهد.

سازگاری برنامه: ثبت وضعیت یک دیسک الزاماً به معنی سازگاری تراکنش‌های پایگاه داده یا چند Volume مرتبط نیست. هماهنگی نوشتن داده باید با توجه به برنامه طراحی شود.

پیش از انتخاب این روش، قابلیت‌های درایور، سیاست نگهداری Snapshot و امکان انتقال داده به مقصد مستقل را بررسی کنید. مستندات رسمی Volume Snapshot در Kubernetes.

۵. بک‌آپ فایل‌سیستم Volumeها

در این روش، فایل‌های داخل Volume خوانده و در مخزن بک‌آپ نگهداری می‌شوند. قابلیت File System Backup در Velero یکی از گزینه‌های قابل بررسی برای این سناریو است.

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

پشتیبانی نوع Volume، نیازهای Node Agent، مجوزها و محدودیت‌های روش را باید پیش از استفاده بررسی کرد. راهنمای رسمی File System Backup در Velero.

۶. بک‌آپ بومی پایگاه داده و برنامه

برای سرویس‌هایی مانند پایگاه داده، ابزار بومی همان سامانه یا قابلیت پشتیبان‌گیری Operator آن باید بخشی از ارزیابی باشد.

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

برای مثال، بازیابی تعریف StatefulSet بدون نسخه معتبر داده، سرویس را کامل برنمی‌گرداند. از سوی دیگر، داشتن بک‌آپ پایگاه داده بدون دسترسی به اسرار، تنظیمات و نسخه مناسب برنامه نیز کافی نیست.

چگونه روش مناسب را انتخاب کنیم؟

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

• برای خرابی Control Plane، روش بازیابی etcd یا امکانات ارائه‌دهنده را مشخص کنید.
• برای حذف اتفاقی برنامه، منابع و داده‌های همان برنامه باید قابل بازیابی باشند.
• برای خرابی ذخیره‌سازی یا سایت، نسخه‌ای خارج از دامنه خرابی اصلی لازم است.
• برای خطای منطقی داده، نقاط بازیابی و سیاست نگهداری اهمیت دارند.

سپس دو هدف را تعیین کنید: RPO یا میزان قابل قبول از دست رفتن داده، و RTO یا زمان هدف بازیابی سرویس. فاصله بک‌آپ‌ها، پهنای باند، حجم داده و روش بازگردانی باید با این اهداف هماهنگ شوند.

بک‌آپ را با آزمون بازیابی ارزیابی کنید

وضعیت Successful در ابزار بک‌آپ، پایان کار نیست. در محیط جداگانه بررسی کنید که منابع ساخته می‌شوند، Volumeها متصل می‌شوند، اسرار در دسترس‌اند و برنامه عملیات واقعی را انجام می‌دهد.

زمان بازیابی، صحت داده و وابستگی‌های جاافتاده را ثبت کنید. این آزمون باید پس از تغییرات مهم در نسخه Kubernetes، درایور ذخیره‌سازی یا معماری برنامه تکرار شود.

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

برای بک‌آپ و بهره‌برداری Kubernetes برنامه داشته باشیدبا خدمات دواپس ایران آشنا شوید و نیازهای خودکارسازی، پشتیبانی و بازیابی زیرساخت سازمانتان را مطرح کنید.مشاهده خدمات دواپس ←