بیایید با آن روبرو شویم: اجرای چندین برنامه در خوشه های جداگانه یک کابوس منابع است. اگر تیم های مختلفی یا مشتریانی را که به محیط های جدا شده نیاز دارند ، دارید ، احتمالاً بیشتر از آنچه لازم است برای زیرساخت ها هزینه می کنید.
چند اجاره در Kubernetes یک راه حل ارائه می دهد ، اما با مجموعه چالش های خاص خود همراه است. چگونه انزوای مناسب را تضمین می کنید؟ در مورد تخصیص منابع چطور؟ و بزرگ – امنیت؟
این راهنما مراحل عملی را برای اجرای Kubernetes چند مستاجر که در واقع در محیط های تولید کار می کنند ، ارائه می دهد. در پایان ، شما می توانید در ضمن حفظ انزوا در جایی که اهمیت دارد ، یک نقشه راه برای ادغام زیرساخت های خود داشته باشید.
چند اجاره در واقع در سال 2025 چه معنی دارد
چند اجاره به یک کلمه کلیدی تبدیل شده است ، اما در اصل آن ، هنوز هم به معنای یکسان است: چندین کاربر که زیرساخت های مشابهی را به اشتراک می گذارند. در Kubernetes ، ما به طور معمول دو طعم را می بینیم:
-
چندین تیم در یک سازمان: بخش ها یا پروژه های مختلفی که یک خوشه را به اشتراک می گذارند ، که در آن اعضای تیم از طریق کنترل کننده های Kubectl یا GITOPS دسترسی دارند
-
چندین نمونه مشتری: برنامه های SaaS که بار کار مشتری را در زیرساخت های مشترک اجرا می کنند
تجارت کلیدی در طول سالها تغییر نکرده است. شما همیشه متعادل هستید:
- انزوا: از دسترسی یا آشفتگی مستاجران با منابع یکدیگر جلوگیری می کند
- کارایی منابع: به حداکثر رساندن استفاده از سخت افزار و کاهش هزینه ها
- پیچیدگی عملیاتی: اطمینان حاصل کنید که تیم شما در واقع می تواند این تنظیمات را مدیریت کند
آنچه تغییر کرده است ابزارها و الگوهای است. انزوا مبتنی بر فضای ناب هنوز هم رایج است ، اما ما شاهد تغییر رویکردهای پیشرفته تر با استفاده از مکانهای نام سلسله مراتبی ، خوشه های مجازی و مشهای خدمات هستیم. بیایید با بلوک های ساختمانی مورد نیاز برای اجرای عملی شروع کنیم.
برای اطلاعات بیشتر در مورد چگونگی نزدیک شدن به این پلتفرم به چند اجاره ، مستندات Kubernetes را بررسی کنید.
بلوک های ساختمان: راهنمای اجرای عملی
پیکربندی فضای نام که در واقع کار می کند
نام های نام اولین خط دفاع شما در چند اجاره است. در اینجا یک پیکربندی مدرن فضای نام با انزوا در ذهن آورده شده است:
apiVersion: v1
kind: Namespace
metadata:
name: tenant-a
labels:
tenant: tenant-a
pod-security.kubernetes.io/enforce: baseline
pod-security.kubernetes.io/audit: restricted
pod-security.kubernetes.io/warn: restricted
networking.k8s.io/isolation: enabled
این چند مورد کلیدی را انجام می دهد:
- یک فضای نام اختصاصی برای مستاجر ایجاد می کند
- آن را برای فیلتر آسان تر و هدف قرار دادن سیاست برچسب می زند
- استانداردهای امنیتی POD را اعمال می کند (جایگزینی مدرن برای سیاست های امنیتی POD)
- آن را برای جداسازی شبکه نشان می دهد
هنگام سازماندهی مکانهای نام ، بسیاری از تیم ها از الگویی مانند پیروی می کنند {tenant}-{environment} (به عنوان مثال ، marketing-devبا marketing-prod). برای برنامه های SaaS ، ممکن است از شناسه مشتری یا شناسه های مشابه استفاده کنید.
نکته کلیدی که باید به خاطر بسپارید: فضای نام به تنهایی برای انزوا واقعی کافی نیست. آنها فقط ظروف برای منابع هستند – برای اجرای مرزها به کنترل های اضافی نیاز دارید.
RBAC که در واقع مستاجران را منزوی می کند
کنترل دسترسی مبتنی بر نقش (RBAC) برای جلوگیری از دسترسی مستاجران به منابع یکدیگر ضروری است. در اینجا الگویی وجود دارد که در عمل به خوبی کار می کند:
# Tenant admin role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: tenant-a
name: tenant-admin
rules:
- apiGroups: ["", "apps", "batch"]
resources: ["pods", "services", "deployments", "jobs"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: ["networking.k8s.io"]
resources: ["ingresses"]
verbs: ["get", "list", "watch", "create", "update", "patch"]
- apiGroups: [""]
resources: ["configmaps", "secrets"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
# Binding for tenant admin
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: tenant-a-admin-binding
namespace: tenant-a
subjects:
- kind: User
name: tenant-a-admin
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: tenant-admin
apiGroup: rbac.authorization.k8s.io
به چند نکته مهم در اینجا توجه کنید:
- این نقش به یک فضای نام خاص تبدیل شده است (
tenant-a) - این مجوزها را برای منابع مشترک اعطا می کند اما هیچ چیز در سطح خوشه ای نیست
- اتصال دهنده یک کاربر را با این نقش مرتبط می کند
این الگوی ساده اما مؤثر است: مجموعه ای از نقش های استاندارد را برای هر مستاجر (مدیر ، توسعه دهنده ، بیننده) ایجاد کنید ، که هر یک به فضای نام مستاجر (های) می پردازند.
یک اشتباه که من می بینم تیم ها مرتکب شده اند بسیار سخاوتمندانه با مجوزها است. در صورت لزوم محدود کننده را شروع کرده و به تدریج شل کنید – این بسیار ساده تر از تلاش برای قفل کردن اوضاع پس از نقض است.
خط مشی های شبکه که در واقع ترافیک را منزوی می کنند
جداسازی شبکه برای چند اجاره بسیار مهم است. به طور پیش فرض ، تمام غلافهای موجود در یک خوشه Kubernetes می توانند با یکدیگر صحبت کنند-نه آنچه شما در یک محیط چند مستاجر می خواهید.
در اینجا یک سیاست شبکه عملی وجود دارد که ترافیک مستاجر را جدا می کند:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: tenant-isolation
namespace: tenant-a
spec:
podSelector: {} # Applies to all pods in namespace
policyTypes:
- Ingress
- Egress
ingress:
- from:
- namespaceSelector:
matchLabels:
tenant: tenant-a
egress:
- to:
- namespaceSelector:
matchLabels:
tenant: tenant-a
- to:
- namespaceSelector:
matchLabels:
common-services: "true"
این سیاست دو چیز مهم را انجام می دهد:
- ترافیک Ingress را فقط از فضای نام مستاجر اجازه می دهد
- ترافیک خروجی را فقط به همان فضای نام مستاجر یا به نام های نامگذاری شده به عنوان خدمات مشترک امکان پذیر می کند
بخش دوم از اهمیت ویژه ای برخوردار است – مستاجران شما احتمالاً نیاز به دسترسی به خدمات مشترک مانند نظارت ، ورود به سیستم یا بانک اطلاعاتی دارند. با برچسب زدن آن به نام های نام common-services: "true"، شما استثنائات کنترل شده را در قوانین انزوا خود ایجاد می کنید.
یک اشتباه رایج فراموش کردن DNS و سایر خدمات خوشه ای است. اطمینان حاصل کنید که خط مشی های شبکه شما امکان دسترسی به خدمات سیستم Kube را که مستاجران به آن نیاز دارند ، امکان پذیر است ، یا جلسات اشکال زدایی بسیار گیج کننده ای خواهید داشت.
سهمیه منابع برای جلوگیری از همسایگان پر سر و صدا
یک مستاجر بد می تواند با مصرف تمام منابع موجود ، حزب را برای همه خراب کند. سهمیه منابع از این مشکل “همسایه پر سر و صدا” جلوگیری می کند:
apiVersion: v1
kind: ResourceQuota
metadata:
name: tenant-a-quota
namespace: tenant-a
spec:
hard:
requests.cpu: "10"
requests.memory: 20Gi
limits.cpu: "20"
limits.memory: 40Gi
persistentvolumeclaims: "20"
services: "30"
count/deployments.apps: "25"
count/statefulsets.apps: "10"
این سهمیه محدودیت هایی را در این مورد تعیین می کند:
- CPU و مصرف حافظه (هم درخواست و هم محدودیت)
- تعداد ادعاهای حجم مداوم (ذخیره سازی)
- تعداد خدمات و بارهای کاری (استقرار ، مطبوعات)
تنظیم اندازه سهمیه مناسب برخی از آزمایشات را انجام می دهد. الگوهای استفاده واقعی را کنترل کرده و مطابق آن تنظیم کنید – بارهای کاری بیش از حد محدود کننده و مشروع ، بسیار سست است و به مشکل همسایه پر سر و صدا باز می گردید.
نکته حرفه ای: علاوه بر ResourceQuotas (که در سطح فضای نام کار می کنند) ، از محدوده ها برای تعیین محدودیت های پیش فرض و حداکثر برای ظروف جداگانه استفاده کنید. این امر مانع از ایجاد غلافهای گرسنه منابع می شود که هنوز در سهمیه کلی آنها قرار دارند.
مزایای اجرای دنیای واقعی
گزارش های تحقیق و صنعت فواید روشنی را نشان می دهد که سازمان ها چند اجاره مناسب در محیط های Kubernetes را اجرا می کنند:
مطابق پیاده سازی های مستند ، سازمان ها به طور معمول می بینند:
- 30-40 ٪ کاهش در هزینه های زیرساخت با ادغام چندین خوشه تک مستاجر
- کاهش قابل توجه در زمان صرف شده برای نگهداری و به روزرسانی خوشه
- استفاده از منابع بهبود یافته ، اغلب از حدود 30-35 ٪ به 70 ٪ یا بیشتر دو برابر می شود
- استاندارد سازی بهتر در تیم های توسعه
با این حال ، اجرای بدون چالش نیست. موضوعات مشترک شامل:
- مقاومت از تیم های نگران امنیت بار کاری و انزوا
- پیچیدگی مهاجرت برای برنامه های موجود
- منحنی یادگیری برای ابزار جدید و گردش کار چند مستاجر
- اسکان ویژه برای بارهای کار با منابع یا حساسیت به منابع مورد نیاز است
این نکته مهم را برجسته می کند: چند اجاره همه یا هیچ چیز نیست. بسیاری از پیاده سازی های موفق از یک رویکرد ترکیبی استفاده می کنند و برخی از بارهای کار با امنیت بالا یا با کارایی بالا را روی خوشه های اختصاصی در حالی که بارگذاری بار استاندارد در محیط های مشترک را تثبیت می کنند ، نگه می دارند.
حل سه چالش بزرگ
چالش 1: آسیب پذیری های امنیتی
حملات نشت داده های متقاطع و تشدید سناریوهای کابوس در محیط های چند مستاجر است. در اینجا یک چک لیست امنیتی عملی وجود دارد:
- استانداردهای امنیتی POD را اجرا کنید:
apiVersion: v1
kind: Namespace
metadata:
name: tenant-a
labels:
pod-security.kubernetes.io/enforce: restricted
pod-security.kubernetes.io/enforce-version: v1.29
مشخصات “محدود” مانع از اجرای غلاف ها به عنوان ممتاز ، دسترسی به نام های نام میزبان یا استفاده از قابلیت های خطرناک می شود.
-
ذخیره سازی مستاجر را جدا کنید:
از StorageClasses با کنترل های دسترسی خاص به مستاجر استفاده کنید ، یا بهتر است با استفاده از پشتیبان های ذخیره سازی جداگانه برای داده های حساس. -
اسکن امنیتی منظم را اجرا کنید:
ابزارهایی مانند Trivy ، Falco و Kube-Bench می توانند آسیب پذیری ها را در تنظیمات چند مستاجر شما شناسایی کنند. -
حسابرسی ، حسابرسی ، حسابرسی:
ورود به سیستم حسابرسی را فعال کنید و به طور مرتب الگوهای دسترسی را مرور کنید – بسیاری از نقض ها از طریق دسترسی غیرمعمول تشخیص داده می شوند.
چالش 2: مشاجره منابع
حتی با سهمیه منابع ، شما هنوز هم می توانید به مسائل مشاجره بپردازید. در اینجا برخی از راه حل های عملی وجود دارد:
- اولویت غلاف و پیشگیری:
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
name: tenant-high-priority
value: 1000000
کلاس های اولویت های مختلف را بر اساس اهمیت آنها به بارهای کاری مستاجر اختصاص دهید.
- ضد عاطفه:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: tenant
operator: In
values:
- tenant-a
topologyKey: "kubernetes.io/hostname"
این مانع از چندین غلاف از همان مستاجر در همان گره می شود و بار را توزیع می کند.
- کیفیت کلاسهای خدمات: کلاسهای QoS مناسب (تضمین شده ، پشت سر هم ، Bestiffort) را برای بارهای مختلف کار مستاجر تنظیم کنید تا بر نحوه برخورد تحت فشار منابع تأثیر بگذارد.
چالش 3: پیچیدگی عملیاتی
مدیریت ده ها یا صدها مستاجر به صورت دستی امکان پذیر نیست. در اینجا نحوه ساده سازی عملیات آورده شده است:
-
تهیه مستاجر خودکار:
یک فرآیند استاندارد برای چرخش در نام های جدید مستاجر ، استفاده از سیاست ها و تنظیم سهمیه ایجاد کنید. -
از یک اپراتور مستاجر استفاده کنید:
ابزارهایی مانند کپسول یا اپراتور چند مستاجر می توانند مدیریت چرخه عمر مستاجر را از آفرینش گرفته تا خاتمه کنترل کنند:
apiVersion: tenancy.stakater.com/v1alpha1
kind: Tenant
metadata:
name: tenant-a
spec:
owners:
- name: tenant-a-admin
kind: User
namespaces:
- tenant-a-dev
- tenant-a-prod
quota:
hard:
requests.cpu: '10'
requests.memory: 20Gi
resourcePooling: true
namespacePrefix: tenant-a-
-
نظارت بر آگاه مستاجر:
برای ساده کردن اشکال زدایی و فعال کردن داشبوردهای خاص مستاجر ، تمام معیارها و سیاهههای مربوط را با شناسه های مستاجر برچسب گذاری کنید. -
قابلیت های سلف سرویس را ایجاد کنید:
ابزارهای داخلی بسازید که به مستاجران اجازه می دهد منابع خود را در محدودیت هایی که شما تعریف می کنید مدیریت کنند.
بسته بندی: آیا چند اجاره برای شما مناسب است؟
Kubernetes چند مستاجر یک گلوله نقره ای نیست ، اما می تواند در هنگام اجرای صحیح هزینه ها و سربار عملیاتی را به میزان قابل توجهی کاهش دهد. در اینجا یک لیست چک سریع برای تصمیم گیری در مورد مناسب سازمان شما وجود دارد:
✅ شما چندین تیم یا مشتریانی دارید که از زیرساخت های مشابه استفاده می کنند
✅ شما با پیامدهای امنیتی زیرساخت های مشترک راحت هستید
✅ بلوغ عملیاتی برای اجرای و حفظ انزوا دارید
✅ صرفه جویی در هزینه از افزایش پیچیدگی بیشتر است
الگوهای اجرای ما پوشش داده شده است-جداسازی فضای نام ، RBAC ، خط مشی شبکه و سهمیه منابع-پایه ای محکم برای اکثر محیط های چند مستاجر فراهم می کند. کوچک ، شاید فقط با دو تیم یا مشتری را شروع کنید و با اطمینان به مکانیسم های انزوا خود ، گسترش دهید.
به یاد داشته باشید ، لازم نیست که در مورد چند اجاره بها بروید. بسیاری از سازمان ها از یک رویکرد ترکیبی استفاده می کنند ، با خوشه های مشترک برای بیشتر بارهای کاری و خوشه های اختصاصی برای برنامه های با امنیت بالا یا با کارایی بالا.
هر رویکردی را که انتخاب می کنید ، اطمینان حاصل کنید که تیم های شما مرزها و محدودیت های راه اندازی چند مستاجر خود را درک می کنند. کنترل های فنی مهم هستند ، اما آموزش کاربر نیز چنین است – یک مستاجر گیج شده می تواند ناخواسته برای همه مشکلاتی ایجاد کند.
تجربه شما با Kubernetes چند مستاجر چیست؟ آیا شما هیچ یک از این الگوهای را پیاده سازی کرده اید ، یا رویکردهای جایگزین دارید؟ نظرات خود را در نظرات زیر به اشتراک بگذارید.
