به گزارش از وبسایت cncf، در دو سال گذشته موضوع حاکمیت دیجیتال از بحث‌های سیاست‌گذاری به یکی از دغدغه‌های عملی مهندسی پلتفرم تبدیل شده است 😊. قانون داده اتحادیه اروپا از 11 ژانویه 2025 قابل اجرا شده و مقرراتی مانند NIS-2 و DORA هم‌اکنون بر تصمیم‌های روزمره پلتفرم در بخش‌های تحت نظارت تاثیر می‌گذارند. قانون Data Use and Access بریتانیا (2025) و مقررات قابل انتقال آن تا 2026 نیز در راه اجرا هستند. در نتیجه تیم‌های پلتفرم این روزها باید فراتر از نشان‌دادن محل اجرای بارهای کاری، نحوه عملکرد، ایمن‌سازی و اداره زیرساخت را نیز اثبات کنند؛ سؤالاتی درباره سطوح کنترل، کلیدهای رمزنگاری، دسترسی‌های مدیریتی، قابلیت حسابرسی و قابلیت حمل بار الآن کنار الزامات سنتی محل نگهداری داده‌ها قرار گرفته‌اند و برای سازمان‌هایی که پلتفرم‌های ابری بومی می‌سازند، چالشی معماری‌محور پدید آورده‌اند.

در حالی که انتخاب زیرساخت منطقه‌ای هم‌چنان اهمیت دارد، بسیاری از الزامات حاکمیت در عمل به نحوه توزیع کنترل، دسترسی و مسئولیت‌های عملیاتی در سراسر پشته پلتفرم وابسته است. این مطلب بررسی می‌کند چگونه پلتفرم‌های مبتنی بر Kubernetes می‌توانند به این نیازها پاسخ دهند و چرا طراحی «هواییپمان کنترلی» (control plane) به نقطه‌ای کلیدی در گفت‌وگوی حاکمیت تبدیل شده است 🔍.

وقتی درخواست‌های مکرر تنظیم‌کننده‌ها، حسابرسان و تیم‌های تدارکات را تحلیل می‌کنید، چهار ویژگی بارها مطرح می‌شوند: محدودیت قضایی (هر مؤلفه‌ای که قادر به خواندن داده مستاجر است، از جمله control plane، باید تحت یک حوزه قضایی مشخص اجرا شود)، استقلال عملیاتی (تیم مالک بار کاری باید بتواند بدون وابستگی به سرویس میزبانی‌دهنده فروشنده، آن را بازسازی، مهاجرت و ممیزی کند)، رمزنگاری و کنترل دسترسی (کلیدها، محتوای etcd و credentialهای admin نباید برای نهادی خارج از حوزه قضایی قابل دسترسی باشند)، و قابلیت حمل (بارها باید بتوانند بدون بازنویسی هنگام تغییر سخت‌افزار، ارائه‌دهنده یا کشور میزبان منتقل شوند). برای طراحان ابر مستقل، مواردی مانند مکان control plane، ذخیره‌سازی ابرداده، دسترسی‌های مدیریتی، رمزنگاری و مالکیت مدیریت کلید باید به صورت صریح تعریف شوند و استراتژی‌های پشتیبان‌گیری و مدل‌های دسترسی طوری طراحی شوند که مرزهای قضایی را محترم شمارند — صرف انتخاب یک منطقه («ما فرانکفورت را انتخاب کردیم») کفایت نمی‌کند؛ انتخاب‌های زیرساختی باید تا سطح control plane پیش بروند 🔐.

چرا یک خوشه Kubernetes به تنهایی کافی نیست؟ هنگام ساختن یک پلتفرم مستقل، Kubernetes نقش مرکزی دارد و APIهای اعلامی و اکوسیستم باز آن (از جمله Kyverno برای سیاست‌ها، Argo CD و Flux برای GitOps، KubeVirt برای VMs، Cilium برای شبکه، و SPIFFE/SPIRE برای هویت بار کاری) بلوک‌های بنیادی‌ای هستند که شرکت‌های تنظیم‌شده به آن‌ها تکیه می‌کنند. معماری مرجع Kubernetes مستقل Swisscom در architecture.cncf.io نیز نشان‌دهنده مسیر حرکت صنعت است.

با ترسیم نیازهای حاکمیتی در یک خوشه، شکاف‌ها روشن می‌شوند: یک control plane مشترک به همه مستاجران سرویس می‌دهد و یک رویداد قضایی یا فنی که صفحه داده یک مستاجر را هدف قرار دهد، ممکن است همه کسانی را که سرور API، etcd و کنترل‌کننده‌ها را به اشتراک می‌گذارند، تحت تاثیر قرار دهد. فضاهای نام به تنهایی مرز کافی نیستند — حتی با RBAC قوی، CRDها، admission webhooks و کنترل‌کننده‌ها می‌توانند میان فضاها به اشتراک گذاشته شوند یا به خاطر پیکربندی نادرست در سراسر خوشه نشت کنند. طراحی «یک خوشه کامل در هر حوزه قضایی/هر محیط/هر تیم» از نظر عملیاتی سنگین، هزینه‌زا و کند است؛ در عمل اپراتورها اغلب پلتفرم‌های مشترکی را اجرا می‌کنند که هم‌زمان چند محیط تنظیم‌شده را پشتیبانی می‌کنند و هر کدام نیازهای عملیاتی، انطباق و محل نگهداری مخصوص خود را دارند.

برای مثال، یک ارائه‌دهنده ممکن است محیط‌های جداگانه‌ای برای مستاجران اتحادیه اروپا و بریتانیا داشته باشد، هر کدام با زیرساخت منطقه‌ای، ذخیره‌سازی و مرزهای حسابرسی مشخص. اما قرار دادن تنها بار کاری در یک منطقه به معنای تحقق حاکمیت نیست: حتی اگر بارهای مستاجر در مناطق جدا اجرا شوند، یک control plane مشترک تکیه‌گاه متمرکزی برای اختیارات اداری، اجرای سیاست، APIها و تصمیمات عملیاتی کلیدی باقی می‌گذارد. محل استقرار و مدیر control plane در نهایت مرز واقعی حاکمیت سکو را تعیین می‌کند.

الگوی ارزشمند برای یادگیری: خوشه‌های مستاجر. در این الگو یک control plane Kubernetes برای هر مرز انزوا مجزا ایجاد می‌شود که بر بستر یک خوشه زیربنایی مشترک قرار دارد. هر خوشه مستاجر سرور API، controller manager، scheduler و ذخیره‌سازی وضعیت خاص خود را دارد؛ از منظر بار کاری این همان خوشه واقعی و سازگار Kubernetes است، اما از منظر پلتفرم control plane هر مستاجر به صورت مجموعه‌ای از پادها روی یک خوشه کنترل زیربنایی اجرا می‌شود. یکی از پیاده‌سازی‌های رایج این الگو vCluster است، یک پروژه متن‌باز که خوشه‌های مستاجر را به‌عنوان پادها در یک خوشه موجود فراهم می‌کند. ما در ادامه از vCluster به‌عنوان مثال استفاده خواهیم کرد، هرچند ایده‌ها برای هر راه‌حلی که مرز control plane ایزوله می‌دهد، کاربردی است.

چند ویژگی خوشه‌های مستاجر برای حاکمیت حیاتی است: control plane مستقل—هر خوشه مستاجر سرور API و یک فروشگاه پشتیبان مستقل (etcd تعبیه‌شده، etcd خارجی یا یک پایگاه داده SQL) دارد؛ CRDهای یک مستاجر، admission webhookها و گزارش‌های حسابرسی به مستاجر دیگر وارد نمی‌شوند. این جداسازی به معنای چرخه‌های ارتقا و نسخه‌های جداگانه Kubernetes نیز هست که با افزایش تعداد مستاجران اهمیت بیشتری می‌یابد. یک مرز قضایی در سطح خوشه معنا پیدا می‌کند؛ فروشگاه پشتیبان می‌تواند روی حجم‌های رمزگذاری‌شده‌ای قرار گیرد که روی سخت‌افزار تحت کنترل شما و در حوزه قضایی موردنظر زندگی می‌کنند. این‌گونه اقامت کنترل plane، فراتر از تنها محل اجرای بار کاری، قابل طراحی می‌شود.

به‌جای تکیه بر فضای نام چندمستاجر، جداسازی واقعی مستاجر باید در سطح خوشه باشد: بارهای درون یک خوشه مستاجر نباید به API خوشه زیربنایی دسترسی داشته باشند. برای جداسازی زمان‌اجر قوی‌تر در لایه کانتینر، معمولاً خوشه مستاجر با runtime مبتنی بر user namespace مانند vNode یا با gVisor یا کانتینرهای kata جفت می‌شود، یا در مواردی که مرز VM لازم است از VMها بهره گرفته می‌شود. این موضوع مخصوصاً برای اپراتورهای ابری در حوزه AI اهمیت دارد، جایی که تهدیدات فرار از کانتینر با نیاز به جلوگیری از مشاهده بارهای یکدیگر در سخت‌افزار مشترک ترکیب می‌شود.

قابلیت حمل یک خوشه مستاجر به این معناست که این خوشه یک API سازگار Kubernetes ارائه می‌دهد؛ بارهای درون آن برای هر اجرایی از Kubernetes که با آن منطبق باشد، قابل جابجایی است. مهاجرت از یک خوشه زیربنایی مبتنی بر hyperscaler به یک ارائه‌دهنده مستقل یا به سرور فلز لخت نیازی به بازنویسی بار کاری ندارد. الگوی عملی این است که تیم‌های پلتفرم چند خوشه زیربنایی را نگهداری می‌کنند و برای هر مستاجر، حوزه قضایی یا دسته بار کاری یک خوشه مستاجر جدا فراهم می‌کنند؛ مرزهای حاکمیت به اشیاء درجه‌یک تبدیل می‌شوند که با vCluster اعلام، حسابرسی و منتقل می‌گردند.

معمولاً از منظر معماری، این یعنی یک خوشه control plane زیربنایی در هر حوزه قضایی یا دیتاسنتر و درون آن خوشه‌های مستاجر برای مشتریان همان مرز تهیه می‌شوند. برای نمونه، یک control plane در اتحادیه اروپا ممکن است فقط به مستاجران مقیم اتحادیه اروپا خدمت کند، در حالی که یک control plane جداگانه در بریتانیا به مشتریان بریتانیایی خدمت می‌دهد؛ این مدل به هر مستاجر امکان اجرای control plane خود را بدون نیاز به یک خوشه فیزیکی کامل اختصاصی می‌دهد 🏷️.

الگوی عملی‌تر: حوزه قضایی به‌عنوان یک خوشه — فرض کنید یک شرکت SaaS مشتریان EU و UK دارد. طبق قانون داده اتحادیه اروپا، داده مشتری، گزارش‌های حسابرسی و ابرداده برای مستاجران مقیم EU باید تحت صلاحیت EU باقی بماند و قابل حمل باشد. مشتریان UK تحت Data Use and Access Act 2025 قرار دارند که نظامی موازی اما متفاوت است. همان محصول، دو مرز حاکمیتی. راه‌حل شفاف این است که برای هر حوزه قضایی یک خوشه مستاجر تعریف شود که به‌عنوان منابع Kubernetes اعلام شده و توسط GitOps مدیریت گردد؛ یک CRD مکان، ذخیره پشتیبان و وضعیت سیاست خوشه مستاجر را توصیف می‌کند و یک کنترل‌کننده آن را تطبیق می‌دهد. محدودیت‌هایی که باید در آن منبع ثبت شوند شامل selector گره یا محدودیت توپولوژی (برای پین‌کردن پادها به گره‌هایی با صلاحیت مناسب)، یک فروشگاه پشتیبان برای وضعیت خوشه مستاجر که در حوزه قضایی انتخاب شده زندگی کند (etcd یا معادل SQL)، جلوگیری از عبور داده‌های control plane، اشیاء API و اسرار از سرویس‌های مدیریت‌شده خارج از حوزه، و جریان حسابرسی محلی است — یعنی لاگ‌های حسابرسی نباید از مرز قضایی که تنظیم‌کننده اهمیت می‌دهد عبور کنند. بسته‌ای از سیاست‌ها (Kyverno یا OPA Gatekeeper) باید در خوشه مستاجر نصب و الزامات محل سکونت، منشأ تصویر و SBOM را درون خوشه اعمال کند. از منظر ساختار، خوشه مستاجر UK شبیه خوشه EU خواهد بود اما با برچسب‌ها، فروشگاه پشتیبان و هدف حسابرسی متفاوت. افزودن حوزه قضایی جدید باید یک pull request در Git باشد، نه ساخت یک خوشه از ابتدا؛ تمام تعریف‌ها در Git زندگی می‌کنند و دنباله حسابرسی برای «چرا داده‌های مستاجر X در حوزه قضایی Y هستند» به صورت تاریخچه تعهدات ثبت می‌شود، نه تصویری از یک کنسول.

کاهش شعاع انفجار در مواجهه با حوادث حاکمیتی حیاتی است. بحث حاکمیتی معمولاً روی محل نگهداری تمرکز دارد، اما چالش سخت‌تر وقوع رخدادهاست — احضاریه، یک controller با پیکربندی نادرست یا یک credential فاش‌شده. خوشه‌های مستاجر شعاع انفجار را به‌صورت ملموس محدود می‌کنند: یک درخواست به سبک CLOUD Act علیه اپراتور کنترل پِین (زیربنایی) که فروشگاه پشتیبان یک خوشه مستاجر در حوزه قضایی دیگری را نگهداری می‌کند، به‌صورت خودکار محتوای etcd آن خوشه مستاجر را در اختیار قرار نمی‌دهد. به بیان دیگر، هدف قانونی و هدف فنی از طریق طراحی از هم جدا می‌شوند و این جداشدگی همان چیزی است که حاکمیت عملی را ممکن می‌سازد 🚀.