استقرارهای خود را با محدودیت های گسترش توپولوژی Pod افزایش دهید: K8s 1.30

محدودیت های گسترش توپولوژی Pod در Kubernetes به ما کمک می کند Pod ها را به طور یکنواخت در قسمت های مختلف یک خوشه مانند گره ها یا مناطق پخش کنیم. این برای انعطاف پذیر و در دسترس نگه داشتن برنامه های ما عالی است. این ویژگی باعث می‌شود از جمع‌بندی بیش از حد Pods در یک نقطه جلوگیری شود که می‌تواند منجر به یک نقطه شکست شود.

پارامترهای کلیدی: –

1. کلید توپولوژی: – این یک کلید برچسب است که مشخص می کند Pods شما می تواند در کجا در خوشه قرار گیرد. کلیدهای توپولوژی موجود
   ⇒ kubernetes.io/hostname → این کلید Pods را در گره های مختلف درون خوشه پخش می کند.
   ⇒ topology.kubernetes.io/zone ← این کلید Pods را در مناطق مختلف در دسترس پخش می کند.
   ⇒ topology.kubernetes.io/region → این کلید Pods را در مناطق مختلف پخش می کند.

2. MaxSkew: – حداکثر تفاوت مجاز در تعداد Podها بین گروه های پرجمعیت و کم جمعیت تعریف شده توسط کلید توپولوژی شما.

3. WhenUnstisfiable: – این کاری است که Kubernetes وقتی نمی تواند معیارهای پخش پاد مشخص شده شما را برآورده کند، این کار را انجام می دهد.
   ⇒ DoNotSchedule ← در صورت نقض محدودیت از زمان بندی جلوگیری می کند.
   ⇒ ScheduleAnyway ← زمان‌بندی را می‌دهد اما یک هشدار را ثبت می‌کند.

4. LabelSelector: – انتخابگر برچسب استاندارد Kubernetes برای فیلتر کردن پادهایی که برای محدودیت در نظر گرفته می شوند.

5. minDomain: – اطمینان حاصل می کند که غلاف ها در حداقل ‘n’ مناطق مختلف پخش شده اند. این یک فیلد اختیاری است که فقط هنگام استفاده از آن می توان از آن استفاده کرد

پیکربندی اولیه YAML

apiVersion: apps/v1 
kind: Deployment 
metadata:
 name: new-app 
spec:
 replicas: 5 
 selector:
  matchLabels: 
   app: new-app
template: 
 metadata:
  labels:
    app: new-app
 spec: 
   topologySpreadConstraints:
     - maxSkew: 1
       topologyKey: "topology.kubernetes.io/zone" 
       whenUnsatisfiable: "DoNotSchedule" 
       labelSelector:
         matchLabels: 
          app: new-app
        minDomains: 3 
   containers:
    - name: new-app-container 
      image: new-app-image

توجه داشته باشید –

فرض کنید ما سه ناحیه داریم و Pods را با maxSkew 1 مستقر می کنیم. توزیع ممکن است به شکل زیر باشد:
• Zone A: 2 Pods
• Zone B: 2 Pods
• Zone C: 1 Pod
در اینجا، می بینیم که حداکثر اختلاف در تعداد Pod بین مناطق بیشتر از 1 نیست. بنابراین، هر Pod جدید تا زمانی برنامه ریزی می شود که این اختلاف از 1 تجاوز نکند. اگر اختلاف بیشتر از 1 بود، سیستم برنامه ریزی می کند. هیچ Pod اضافی را در مناطقی که از این حد فراتر رفته است برنامه ریزی نکنید.

Pod Topology Spread Constraints را می توان با اشیاء مختلف k8s استفاده کرد:

1. استقرارها
2. StatefulSets
3. DaemonSets
4. ReplicaSets
5. جابز و کرون جابز

برخی از موارد استفاده رایج: –

1. استقرار یک برنامه وب با کپی های آن به طور یکنواخت در چندین منطقه در دسترس برای اطمینان از در دسترس بودن و تحمل خطا بالا است.
2. استقرار یک برنامه حالت دار، مانند پایگاه داده، با Pods که در گره های مختلف پخش شده است تا از از دست رفتن داده ها در صورت خرابی گره جلوگیری شود.
3. استقرار یک برنامه پردازش دسته ای با بارهای کاری توزیع شده در چندین منطقه برای بهینه سازی استفاده از منابع و اطمینان از تداوم پردازش.

مکانیسم های دیگر برای دستیابی به توزیع متعادل Pod و انعطاف پذیری:

1. Pod AntiAffinity
2. گره افینیتی
3. Cluster Autoscaler با گروه‌های Balance-Similar-Node
4. توزیع دستی
5. زمانبندی های سفارشی

مزایای قابل توجه محدودیت های گسترش توپولوژی Pod نسبت به مکانیسم های دیگر

1. دانه بندی و کنترل پیشرفته: محدودیت های گسترش توپولوژی Pod اجازه می دهد تا کنترل دقیقی بر توزیع Pod در دامنه های مختلف (به عنوان مثال، زون ها، گره ها) داشته باشد و از استقرار متعادل با حداقل انحراف بین دامنه ها اطمینان حاصل کند.
2. اتوماسیون و سادگی: برخلاف Pod AntiAffinity و Node Affinity که می توانند پیچیده باشند و نیاز به مدیریت دستی دارند، Pod Topology Spread Constraints به طور خودکار پادها را بر اساس قوانین از پیش تعریف شده متعادل می کند و تلاش دستی و خطاها را کاهش می دهد.
3. تعادل پیشگیرانه: این ویژگی تضمین می‌کند که Pods در زمان برنامه‌ریزی به طور یکنواخت توزیع می‌شوند، برخلاف Cluster Autoscaler که پس از وقوع به عدم تعادل واکنش نشان می‌دهد و تعادل فوری‌تر و ثابت‌تری را فراهم می‌کند.
4. تطبیق پذیری در سراسر دامنه ها: در حالی که Node Affinity بر گره ها تمرکز دارد، محدودیت های گسترش توپولوژی Pod در چندین دامنه توپولوژی کار می کند و آنها را برای سناریوهای مختلف استقرار متنوع تر می کند.
5. استاندارد شده و داخلی: به عنوان یک ویژگی بومی Kubernetes، Pod Topology Spread Constraints یک رویکرد استاندارد را ارائه می‌کند که نیاز به زمان‌بندی‌های سفارشی را حذف می‌کند و از سازگاری با به‌روزرسانی‌های Kubernetes و پشتیبانی انجمن اطمینان می‌دهد.