راهنمای کامل POD در کوبرنتیز : از راه‌اندازی تا دیباگ!

در این مقاله به مفهوم POD در Kubernetes خواهیم پرداخت. همان کوبرنتیزی که توسعه‌دهنده‌ها را از اختلاف ورژن برنامه‌ها در محیط‌های ابری و فیزیکی و مجازی نجات داد و به‌عنوان بستری یکپارچه، زمان و منابع مورد نیاز برای توسعه و پیاده‌سازی برنامه‌های کانتینری را به‌ حداقل رسانده است. اگر کنجکاو هستید که درباره‌ی ساختار و نحوه‌ی مدیریت و شبکه‌بندی POD بدانید هو Load Balancing و امنیت و دیباگ  آن را بیاموزید؛ صفحه‌ی درستی را برای خواندن انتخاب کرده‌اید. 

تعریف Pod در کوبرنتیز چیست؟

POD در کوبرنتیز به‌عنوان کوچک‌ترین واحد اجرایی شناخته می‌شود و خانه یا میزبانی برای یک یا چند کانتینر مرتبط است. ممکن است با شنیدن کلمهٔ POD به درستی به یاد معادل انگلیسی «غلاف نخود فرنگی» افتاده باشید. پادها دقیقاً به همان شکل، ساختار یکپارچه‌ای از کانتینرهای مختلف (دانه‌های نخود فرنگی) را شکل می‌دهند. 

پادها منابع سیستمی مانند CPU و RAM و شبکه را به اشتراک می‌گذارند و در یک Node واحد اجرا می‌شوند. نود‌ها به‌عنوان واحدهای محاسباتی کوچک‌تر در کلاستر کوبرنتیز عمل می‌کنند. پادها قابلیت خودترمیمی ندارند؛ در صورت از بین رفتن یک پاد، کوبرنتیز به‌طور خودکار پاد جدیدی را با IP جدید ایجاد می‌کند.

اهمیت POD در کوبرنتیز چیست؟

پاد (Pod) در کوبرنتیز کوچک‌ترین و اساسی‌ترین واحد اجرای برنامه‌هاست که حاوی یک یا چند کانتینر است. اهمیت پاد به دلیل نقش مرکزی آن در معماری کوبرنتیز است. هر پاد یک نمونه اجرایی از برنامه‌های کاربردی را دربر می‌گیرد و به عنوان یک واحد مستقل از منابع محاسباتی و شبکه استفاده می‌کند. این ساختار باعث می‌شود که برنامه‌ها به‌صورت انعطاف‌پذیر و مقیاس‌پذیر اجرا شوند. پادها به‌طور معمول برای اجرای برنامه‌های کاربردی، مدیریت سرویس‌ها و اطمینان از استقرار مستمر مورد استفاده قرار می‌گیرند. همچنین، پادها امکان مهاجرت بین سرورها و توزیع بار بهینه را فراهم می‌کنند، که این امر به افزایش دسترس‌پذیری و پایداری برنامه‌ها کمک می‌کند. به‌طور کلی، پادها در کوبرنتیز یک ساختار مهم و ضروری برای مدیریت و اجرای کانتینرها هستند و نقش حیاتی در تضمین کارایی و قابلیت اطمینان سیستم‌های توزیع‌شده ایفا می‌کنند.

ساختار POD در کوبرنتیز به چه صورت است؟

به محض اینکه استقرار کوبرنتیز را انجام بدهید، یک کلاستر برایتان ایجاد می‌شود. هر POD در کوبرنتیز نشان‌دهنده‌ی یک فرآیند در حال اجرا در کلاستر شما است و می‌تواند شامل یک یا چند کانتینر باشد. هر پاد در یک کلاستر کوبرنتیز بر روی یک نود (Node) قرار می‌گیرد و کانتینرهای داخل پاد شبکه، آدرس IP و فضای پورت مشترک دارند و می‌توانند منابع ذخیره‌سازی را به اشتراک بگذارند. برای اینکه بتوانیم این فرآیند را بهتر درک کنیم، بهتر است ابتدا با اجزای پاد آشنا شویم. 

اجزای کلیدی POD در کوبرنتیز

1. کانتینرها: یک پاد می‌تواند شامل یک یا چند کانتینر باشد، که معمولاً کانتینرهای Docker هستند. همه کانتینرهای درون یک پاد به شدت به هم متصل‌اند و لازم است که منابعی مانند سیستم فایل و شبکه را با یکدیگر به اشتراک بگذارند.
2. شبکه: همه کانتینرهای درون یک پاد از یک فضای شبکه مشترک استفاده می‌کنند،یعنی  آدرس IP و فضای پورت مشترک دارند. این کانتینرها می‌توانند با استفاده از localhost و مکانیزم‌های ارتباط بین فرآیندی استاندارد (IPC) با یکدیگر ارتباط برقرار کنند.
3. حجم‌های ذخیره‌سازی: کانتینرهای درون یک POD در کوبرنتیز می‌توانند حجم‌های ذخیره‌سازی را به اشتراک بگذارند. این Volumeها روی سیستم فایل هر کانتینر Mount می‌شوند و می‌توانند برای نگهداری و اشتراک داده بین کانتینرهای درون پاد استفاده شوند.
4. مشخصات پاد: پادها با استفاده از یک فایل مشخصات در فرمت YAML یا JSON تعریف می‌شوند، که جزئیات مربوط به کانتینرها، حجم‌های ذخیره‌سازی، تنظیمات شبکه و سایر تنظیمات در آن قرار می‌گیرد. 

مثال زیر یک نمونه POD در کوبرنتیز را در فرمت YAML نشان می‌دهد:

apiVersion: v1

kind: Pod

metadata:

  name: my-pod

spec:

  containers:

  - name: my-container

    image: my-image

    ports:

    - containerPort: 80

آشنایی با معماری POD در کوبرنتیز 

معماری کلاستر Kubernetes از یک صفحه یا Plane  اصلی (کنترلی) و یک یا چند Node (ماشین های ورکر) تشکیل شده است.حال  اگر از سرویس های خود مدیریت Kubernetes مثل kubeadmn و یا  kops استفاده کنید، تعداد Plane و نود بسیار بیشتر هم خواهد شد. در هر دو حالت، این کلاستر می‌تواند در فضای ابری به شکل ماشین مجازی یا حتی دستگاه فیزیکی ایجاد شود. تفاوت در این است که اگر محیط کوبرنتیز در فضای مدیریت‌شده‌ای مثل Azure AKS، GCP GKE و AWS EKS استقرار پیدا کند، مدیریت صفحه کنترل توسط ارائه‌دهنده ابری انجام می‌شود.

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

مزایای استفاده از دیاگرام معماری POD در کوبرنتیز 

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

مقیاس‌پذیری در Pod ها

مقیاس‌پذیری افقی: کوبرنتیز به شما اجازه می‌دهد تعداد پادهای خود را بر اساس نیاز افزایش یا کاهش دهید. این ویژگی به شما کمک می‌کند تا منابع خود را بهینه‌تر مدیریت کرده و در مواقع افزایش بار کاری به سرعت تعداد پادها را افزایش دهید.

مقیاس‌پذیری خودکار: با استفاده از امکاناتی مثل Horizontal Pod Autoscaler، می‌توانید مقیاس‌پذیری خودکار پادها را تنظیم کنید تا بر اساس معیارهایی مانند استفاده از CPU یا حافظه، تعداد پادها به صورت خودکار افزایش یا کاهش یابد.

دسترسی بالا (High Availability)

استقرار چندگانه: کوبرنتیز به شما این امکان را می‌دهد که اپلیکیشن‌های خود را در چندین نود (گره) مستقر کنید تا از دسترس‌پذیری بالای سرویس‌های خود اطمینان حاصل کنید.

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

قابلیت حمل (Portability)

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

پشتیبانی از سیستم‌عامل‌های مختلف: شما می‌توانید کلاسترهای کوبرنتیز را بر روی توزیع‌های مختلف لینوکس مانند CentOS، Debian، Fedora، CoreOS، Ubuntu و Red Hat Linux پیکربندی کنید.

امنیت و دسترسی در PODها

پیکربندی امن: معماری کوبرنتیز به گونه‌ای طراحی شده است که امنیت را در سطوح مختلف بهینه می‌کند. (مواردی مثل امنیت در سطح شبکه، امنیت کانتینرها و  مدیریت دسترسی‌ها) 

پشتیبانی از افزونه‌های امنیتی: کوبرنتیز از افزونه‌های امنیتی مختلفی مانند Network Policies و Secrets برای مدیریت اطلاعات حساس پشتیبانی می‌کند.

تکرارپذیری Podها

تکرارپذیری به معنای قابلیت اجرای چندین نسخه یا کپی از یک پاد به‌صورت همزمان است. این ویژگی به شما اجازه می‌دهد تا با ایجاد نسخه‌های متعدد از یک پاد، به قابلیت‌هایی نظیر افزایش دسترس‌پذیری و بهبود عملکرد دست یابید. در کوبرنتیز، تکرارپذیری از طریق اجزایی مانند کنترلرهای تکرار (Replication Controllers) و مجموعه‌های تکثیر (Replica Sets) مدیریت می‌شود.

روش ایجاد و مدیریت Pod در کوبرنتیز

ایجاد Pod در کوبرنتیز معمولاً با استفاده از فایل‌های YAML انجام می‌شود. در این فایل‌ها، مشخصات مربوط به کانتینرها، منابع مورد نیاز و تنظیمات شبکه‌ای تعریف می‌شود. برای ایجاد یک Pod، از دستورات kubectl شبیه به نمونه‌ی زیر استفاده می‌شود:

apiVersion: v1

kind: Pod

metadata:

  name: my-pod

spec:

  containers:

    - name: my-container

      image: my-image

      ports:

        - containerPort: 80

پس از ایجاد فایل YAML، با استفاده از دستور زیر می‌توانید Pod را ایجاد کنید:

kubectl apply -f my-pod.yaml

مدیریت Podها نیز از طریق دستورات kubectl انجام می‌شود. با استفاده از این دستورات می‌توانید Podها را مانیتور، بروزرسانی یا حذف کنید.

توزیع بار و تعادل بار (Load Balancing) در Pod ها

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

۱. مفهوم Load Balancing

منظور از Load Balancing یا تعادل بار، فرآیند توزیع بار میان منابع مختلف (مانند سرورها، پادها و …) است. هدف اصلی از این کار، جلوگیری از بارگذاری بیش از حد روی یک منبع و اطمینان از استفاده بهینه از تمام منابع موجود است.

۲. انواع Load Balancing در کوبرنتیز

در کوبرنتیز، دو نوع Load Balancing اصلی وجود دارد:

• Internal Load Balancing (تعادل بار داخلی)

این نوع از Load Balancing برای توزیع ترافیک درون کلاستر کوبرنتیز به کار می‌رود. زمانی که درخواست‌های داخلی (مانند سرویس‌های میکروسرویس‌ها) به توزیع بار نیاز دارند، از این روش با مفاهیمی مانند Service و Endpoints استفاده می‌شود. 

• External Load Balancing (تعادل بار خارجی)

این نوع از Load Balancing برای توزیع ترافیک ورودی از خارج کلاستر به پادها استفاده می‌شود. این کار معمولاً با استفاده از Load Balancerهای خارجی (مانند Load Balancerهای ابری در AWS، GCP، Azure) انجام می‌شود.

۳. Service و Endpoints در کوبرنتیز

کوبرنتیز از سرویس‌ها (Services) برای پیاده‌سازی Load Balancing داخلی استفاده می‌کند. یک سرویس در کوبرنتیز مجموعه‌ای از پادها را به‌عنوان یک واحد انتزاعی در نظر می‌گیرد و یک IP پایدار و یک DNS نام برای دسترسی به این پادها فراهم می‌کند.

• ClusterIP Service: این نوع سرویس یک IP پایدار درون کلاستر اختصاص می‌دهد و برای ترافیک داخلی استفاده می‌شود.
• NodePort Service: این نوع سرویس پورت خاصی را روی هر Node باز می‌کند و امکان دسترسی به سرویس از خارج کلاستر را فراهم می‌کند.
• LoadBalancer Service: این نوع سرویس یک Load Balancer خارجی ایجاد می‌کند (در صورت استفاده از پلتفرم‌های ابری).

۴. Ingress و Ingress Controller

Ingress یک نوع منبع کوبرنتیز است که دسترسی به سرویس‌های داخلی را از طریق URLها و قوانین مسیریابی فراهم می‌کند. Ingress Controller مسئول مدیریت و پیاده‌سازی Ingress است. این ابزارها معمولاً به منظور مدیریت ترافیک HTTP و HTTPS استفاده می‌شوند.

۵. فرآیند Load Balancing

در فرآیند Load Balancing، ابتدا درخواست‌های ورودی توسط سرویس‌ها یا Ingress دریافت می‌شوند. سپس این درخواست‌ها به پادهای مناسب ارسال می‌شوند تا تعادل بار برقرار شود.

کوبرنتیز از الگوریتم‌های مختلفی برای توزیع بار استفاده می‌کند که شامل Round Robin، Least Connections، IP Hash و … است.

مدیریت حجم‌ ها (Volumes) در Pod

در کوبرنتیز، حجم‌ها یا Volumes ابزاری قدرتمند برای مدیریت داده‌ها درون پادها (Pods) اما مستقل از چرخه‌ی عمر پاد به شمار می‌روند. با استفاده از حجم‌ پاد می‌توانیم داده‌های مورد نیاز برنامه‌های خود را به‌طور ایمن و قابل اعتماد به اشتراک بگذاریم و داخل کانتینرها (و در نتیجه پادها) ذخیره کنیم. اجازه بدهید برخی از نکات مهم و قابل توجه مدیریت حجم‌ها در کوبرنتیز را بررسی کنیم:

۱. انواع حجم‌ ها در کوبرنتیز

کوبرنتیز انواع مختلفی از حجم‌ها را پشتیبانی می‌کند که با توجه به نیازهای مختلف برنامه‌ها قابل استفاده هستند:

• EmptyDir: حجم‌هایی که برای مدت زمان اجرای پاد وجود دارند و پس از حذف پاد نیز حذف می‌شوند. این نوع حجم می‌تواند برای موارد مانند مبادله داده بین کانتینرها درون یک پاد استفاده شود.
• HostPath: حجم‌هایی که به یک مسیر فیزیکی درون نود کوبرنتیز متصل می‌شوند. این انتخاب برای دسترسی به فایل‌ها یا دایرکتوری‌های موجود بر روی نودها مفید است.
• PersistentVolumeClaim یا PVC: این نوع از حجم‌ها از PV به‌عنوان یک منبع مجزا استفاده می‌کنند. PVها به عنوان یک نوع ذخیره‌سازی دائمی و مستقل از پادها در کوبرنتیز مدیریت می‌شوند و PVCها این PVها را به پادها اختصاص می‌دهند.
• CSI یا Container Storage Interface : این استاندارد به اپراتورهای ذخیره‌سازی امکان می‌دهد تا به‌صورت انعطاف‌پذیر حجم‌های خود را با استفاده از انواع مختلفی از ذخیره‌سازی مانند سرویس‌های ابری، ذخیره‌سازی محلی و غیره مدیریت کنند.

نظارت و دیباگ کردن Pod ها

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

نظارت و دیباگ کردن Podها در کوبرنتیز (Kubernetes) فرآیندی حیاتی برای حفظ سلامت و عملکرد صحیح برنامه‌های مستقر در این پلتفرم محسوب می‌شود. در اینجا به صورت کامل به این موضوع پرداخته می‌شود:

۱. نظارت (Monitoring)

منظور از نظارت بر Pod ها  در کوبرنتیز، پیگیری و بررسی وضعیت و عملکرد Podها برای اطمینان از عملکرد صحیح و شناسایی مشکلات احتمالی است. برای این کار ابزارهای مختلفی وجود دارد:

برخی از شناخته‌شده‌ترین ابزارهای نظارت بر POD در کوبرنتیز عبارتند از:

1. Prometheus: این ابزار نظارت و جمع‌آوری داده‌های متریک، به صورت گسترده در محیط‌های کوبرنتیز استفاده می‌شود.
2. Grafana: این ابزار تصویر‌سازی داده، معمولاً با Prometheus استفاده می‌شود تا داشبوردهای بصری برای مانیتورینگ ایجاد کند.
3. ELK Stack (Elasticsearch, Logstash, Kibana): این مجموعه ابزار برای جمع‌آوری، پردازش و تجزیه و تحلیل لاگ‌ها به کار می‌رود.

بررسی وضعیت Pod ها

برای بررسی وضعیت یک Pod، می‌توانید از دستور زیر در Shell Script استفاده کنید:

kubectl get pods

این دستور لیستی از Podها و وضعیت فعلی آنها را نمایش می‌دهد.

مشاهده لاگ‌های Podها

برای مشاهده لاگ‌های یک Pod، می‌توانید از دستور زیر استفاده کنید:

kubectl logs <pod-name>

این دستور، لاگ‌های مربوط به یک Pod خاص را نمایش می‌دهد.

۲. دیباگ (Debugging)

دیباگ کردن Podها به معنای شناسایی و رفع اشکالات و مشکلاتی است که در Podها بروز می‌کند. برای این منظور، چند روش و ابزار وجود دارد:

دستورات مهم برای دیباگ

• بررسی رویدادها (Events)

این دستور جزئیات کاملی از Pod مورد نظر و رویدادهای مربوط به آن را نمایش می‌دهد.

kubectl describe pod <pod-name>

• دسترسی به شل در داخل کانتینر

با این دستور می‌توانید یک شل اینتراکتیو را داخل کانتینر Pod باز کنید تا دستورات دیباگ خود را اجرا کنید.

kubectl exec -it <pod-name> -- /bin/bash

• بررسی منابع Pod

این دستور مصرف CPU و حافظه Pod را نمایش می‌دهد:

kubectl top pod <pod-name>

استفاده از ابزارهای دیباگ

علاوه بر دستوراتی که معرفی کردیم، می‌توانید از ابزارهای زیر نیز کمک بگیرید:

1. Lens: یک IDE برای کوبرنتیز که ابزارهای مناسبی برای نظارت و دیباگ کردن Podها ارائه می‌دهد.
2. K9s: یک ابزار ترمینال برای مدیریت و دیباگ کردن منابع کوبرنتیز که قابلیت‌های زیادی برای بررسی وضعیت Podها دارد.

ارتباطات و شبکه‌بندی در Podها

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

مدل شبکه

کوبرنتیز یک مدل شبکه ساده و مستقیم را فراهم می‌کند که شامل موارد زیر می‌شود:

• هر Pod دارای یک آدرس IP منحصر به فرد است. این آدرس IP درون شبکه Kubernetes قابل دسترسی است.
• Podها می‌توانند به‌طور مستقیم با یکدیگر ارتباط برقرار کنند. این ارتباط نیازی به NAT ندارد.
• سرویس‌ها (Services): سرویس‌ها در Kubernetes به عنوان یک انتزاع برای دسترسی به مجموعه‌ای از Podها استفاده می‌شوند. سرویس‌ها دارای یک آدرس IP پایدار هستند که می‌توانند ترافیک را به Podهای مختلف توزیع کنند.

انواع سرویس‌ها در Kubernetes

• ClusterIP: این نوع سرویس تنها از داخل کلاستر قابل دسترسی است و یک IP مجازی داخلی به Podها تخصیص می‌دهد.
• NodePort: این سرویس یک پورت روی هر Node از کلاستر باز می‌کند و امکان دسترسی به سرویس را از خارج کلاستر فراهم می‌کند.
• LoadBalancer: این سرویس یک IP خارجی اختصاص می‌دهد و ترافیک را بین Nodeهای مختلف توزیع می‌کند. این نوع سرویس بیشتر در محیط‌های کلاود استفاده می‌شود.
• ExternalName: این سرویس نام یک سرویس خارجی را به یک نام داخلی در کلاستر تبدیل می‌کند.

شبکه‌بندی Pod به Pod

• CNI (Container Network Interface): Kubernetes از پلاگین‌های CNI برای مدیریت شبکه استفاده می‌کند. برخی از معروف‌ترین پلاگین‌های CNI عبارت‌اند از Calico، Flannel، Weave و Cilium.
• Policy‌های شبکه: با استفاده از Network Policies می‌توان قوانین خاصی برای کنترل ترافیک شبکه بین Podها تعریف کرد. این سیاست‌ها مشخص می‌کنند که کدام Podها می‌توانند به یکدیگر دسترسی داشته باشند.

محدودیت‌ها و نیازمندی‌های منابع در Podها

درخواست‌ها و محدودیت‌های منابع

• Request (تقاضا): منظور از تقاضا مقدار حداقلی منابعی است که یک Pod نیاز دارد. کوبرنتیز تلاش می‌کند تا حداقل این مقدار منابع را برای Pod فراهم کند.
• Limit (سقف): منظور از سقف، مقدار حداکثری منابعی است که یک Pod می‌تواند استفاده کند. اگر یک Pod تلاش کند بیش از این مقدار منابع استفاده کند، Kubernetes منابع اضافی را محدود می‌کند.

برای تنظیم درخواست‌ها و محدودیت‌ها از مشخصات زیر در فایل‌های تنظیمات (YAML) استفاده می‌شود:

resources:

  requests:

    memory: "64Mi"

    cpu: "250m"

  limits:

    memory: "128Mi"

    cpu: "500m"

محدودیت‌های منابع:

• CPU و Memory: منابع اصلی که برای Podها تنظیم می‌شود. CPU به صورت واحدهای میلی (m) و حافظه به صورت مگابایت (Mi) یا گیگابایت (Gi) تعیین می‌شود.
• Ephemeral Storage: حافظه موقت که برای ذخیره داده‌های موقتی استفاده می‌شود.
• GPU: برای برنامه‌هایی که نیاز به پردازش موازی بالا دارند، می‌توان GPU اختصاص داد.

QoS (Quality of Service)

Kubernetes برای تضمین کیفیت سرویس‌دهی به Podها، آن‌ها را بر اساس درخواست‌ها و محدودیت‌های منابع به سه دسته تقسیم می‌کند:

• Guaranteed: اگر درخواست و محدودیت یکسان باشند. این نوع Podها بالاترین اولویت را دارند.
• Burstable: اگر درخواست کمتر از محدودیت باشد. این نوع Podها انعطاف‌پذیری بیشتری دارند.
• Best Effort: اگر هیچ درخواست و محدودیتی تعریف نشده باشد. این نوع Podها پایین‌ترین اولویت را دارند.

محدودیت‌های نود

هر نود در کلاستر Kubernetes نیز دارای منابع محدودی است و Podها باید در این محدودیت‌ها قرار بگیرند. تنظیم صحیح درخواست‌ها و محدودیت‌ها به جلوگیری از Overcommitment (تخصیص بیش از حد منابع) کمک می‌کند.

این تنظیمات و سیاست‌ها به کوبرنتیز کمک می‌کند تا در آن منابع به صورت کارآمد تخصیص داده شوند و از ثبات و عملکرد مطلوب کلاستر اطمینان حاصل شود.

جمع بندی: آشنایی با POD در کوبرنتیز

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