Init Persian localization - Part 11

Author: xirehat

content/fa/docs/setup/best-practices/cluster-large.md

@@ -0,0 +1,97 @@
+---
+reviewers:
+- xirehat
+title: ملاحظات مربوط به خوشه‌های بزرگ
+weight: 10
+---
+
+یک خوشه مجموعه‌ای از {{< glossary_tooltip text="گره‌ها" term_id="node" >}} (ماشین‌های فیزیکی یا مجازی) است که عامل‌های کوبرنتیز را اجرا می‌کنند و توسط {{< glossary_tooltip text="control plane" term_id="control-plane" >}} مدیریت می‌شوند.
+
+کوبرنتیز {{< param "version" >}} از خوشه‌هایی با حداکثر ۵,۰۰۰ گره پشتیبانی می‌کند. به طور خاص‌تر،
+کوبرنتیز به گونه‌ای طراحی شده است که پیکربندی‌هایی را که *همه* معیارهای زیر را برآورده می‌کنند، در خود جای دهد:
+
+* حداکثر ۱۱۰ پاد در هر گره
+* حداکثر ۵,۰۰۰ گره
+* حداکثر ۱۵۰,۰۰۰ پاد در کل
+* حداکثر ۳۰۰,۰۰۰ کانتینر در کل
+
+شما می‌توانید با اضافه کردن یا حذف گره‌ها، خوشه خود را مقیاس‌بندی کنید. روش انجام این کار به نحوه‌ی استقرار خوشه شما بستگی دارد.
+
+## سهمیه منابع ارائه دهنده ابر {#quota-issues}
+
+برای جلوگیری از مواجهه با مشکلات سهمیه ارائه دهنده ابر، هنگام ایجاد یک خوشه با گره‌های زیاد، موارد زیر را در نظر بگیرید:
+* درخواست افزایش سهمیه برای منابع ابری مانند:
+    * نمونه‌های رایانه‌ای
+    * پردازنده‌ها
+    * حجم‌های ذخیره‌سازی
+    * آدرس‌های IP در حال استفاده
+    * مجموعه قوانین فیلتر بسته
+    * تعداد متعادل‌کننده‌های بار
+    * زیرشبکه‌های شبکه
+    * جریان‌های گزارش
+* محدود کردن اقدامات مقیاس‌بندی خوشه برای ایجاد گره‌های جدید در دسته‌ها، با یک مکث
+بین دسته‌ها، زیرا برخی از ارائه دهندگان ابر، ایجاد نمونه‌های جدید را محدود می‌کنند.
+
+## اجزای Control plane
+
+برای یک خوشه بزرگ، به یک control plane با منابع محاسباتی و سایر منابع کافی نیاز دارید.
+
+معمولاً شما یک یا دو نمونه control plane را در هر منطقه خرابی اجرا می‌کنید، ابتدا آن نمونه‌ها را به صورت عمودی مقیاس‌بندی می‌کنید و سپس پس از رسیدن به نقطه بازگشت نزولی به مقیاس (عمودی)، به صورت افقی مقیاس‌بندی می‌کنید.
+
+شما باید حداقل یک نمونه را در هر منطقه خرابی اجرا کنید تا تحمل خطا فراهم شود. گره‌های Kubernetes به طور خودکار ترافیک را به سمت نقاط انتهایی control plane که در همان منطقه خرابی هستند هدایت نمی‌کنند. با این حال، ارائه دهنده ابر شما ممکن است مکانیسم‌های خاص خود را برای انجام این کار داشته باشد.
+
+به عنوان مثال، با استفاده از یک متعادل کننده بار مدیریت شده، متعادل کننده بار را طوری پیکربندی می‌کنید که ترافیکی را که از kubelet و Pods در منطقه خرابی _A_ سرچشمه می‌گیرد، ارسال کند و آن ترافیک را فقط به میزبان‌های control plane که در منطقه _A_ نیز هستند، هدایت کند. اگر یک میزبان control plane یا منطقه خرابی نقطه انتهایی _A_ آفلاین شود، به این معنی است که تمام ترافیک control plane برای گره‌های موجود در منطقه _A_ اکنون بین مناطق ارسال می‌شود. اجرای چندین میزبان control plane در هر منطقه، احتمال وقوع چنین نتیجه‌ای را کاهش می‌دهد.
+
+### مخزن etcd
+
+برای بهبود عملکرد خوشه‌های بزرگ، می‌توانید اشیاء رویداد را در یک نمونه etcd اختصاصی جداگانه ذخیره کنید.
+
+هنگام ایجاد یک خوشه، می‌توانید (با استفاده از ابزارهای سفارشی):
+
+* شروع و پیکربندی نمونه etcd اضافی
+* پیکربندی {{< glossary_tooltip term_id="kube-apiserver" text="API server" >}} برای استفاده از آن برای ذخیره رویدادها
+
+برای جزئیات بیشتر در مورد پیکربندی و مدیریت etcd برای یک خوشه بزرگ، به [مدیریت خوشه‌های etcd برای کوبرنتیز](/docs/tasks/administer-cluster/configure-upgrade-etcd/) و [راه‌اندازی یک خوشه etcd با قابلیت دسترسی بالا با kubeadm](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) مراجعه کنید.
+
+## منابع افزونه
+
+کوبرنتیز [محدودیت منابع](/docs/concepts/configuration/manage-resources-containers/)
+به حداقل رساندن تأثیر نشت حافظه و سایر روش‌هایی که podها و containerها می‌توانند بر سایر اجزا تأثیر بگذارند، کمک می‌کند. این محدودیت‌های منابع، همانطور که برای بارهای کاری برنامه اعمال می‌شوند، برای منابع {{< glossary_tooltip text="افزونه" term_id="addons" >}} نیز اعمال می‌شوند.
+
+به عنوان مثال، می‌توانید محدودیت‌های CPU و حافظه را برای یک جزء ثبت وقایع تنظیم کنید:
+
+```yaml
+  ...
+  containers:
+  - name: fluentd-cloud-logging
+    image: fluent/fluentd-kubernetes-daemonset:v1
+    resources:
+      limits:
+        cpu: 100m
+        memory: 200Mi
+```
+
+محدودیت‌های پیش‌فرض افزونه‌ها معمولاً بر اساس داده‌های جمع‌آوری‌شده از تجربه اجرای هر افزونه روی خوشه‌های کوچک یا متوسط کوبرنتیز است. هنگام اجرا روی خوشه‌های بزرگ، افزونه‌ها اغلب منابع بیشتری نسبت به محدودیت‌های پیش‌فرض خود مصرف می‌کنند.
+اگر یک خوشه بزرگ بدون تنظیم این مقادیر مستقر شود، افزونه(ها) ممکن است به دلیل رسیدن به حد مجاز حافظه، به‌طور مداوم از کار بیفتند.
+از طرف دیگر، افزونه ممکن است اجرا شود اما به دلیل محدودیت‌های برش زمانی CPU، عملکرد ضعیفی داشته باشد.
+
+برای جلوگیری از بروز مشکلات مربوط به منابع افزونه خوشه، هنگام ایجاد خوشه با گره‌های زیاد، موارد زیر را در نظر بگیرید:
+
+* برخی افزونه‌ها به صورت عمودی مقیاس‌پذیر هستند - یک کپی از افزونه برای خوشه وجود دارد یا به کل یک منطقه خرابی سرویس می‌دهد. برای این افزونه‌ها، درخواست‌ها و محدودیت‌ها را همزمان با مقیاس‌پذیری خوشه خود افزایش دهید.
+
+* بسیاری از افزونه‌ها به صورت افقی مقیاس‌پذیر هستند - شما با اجرای پادهای بیشتر ظرفیت را افزایش می‌دهید - اما با یک خوشه بسیار بزرگ، ممکن است لازم باشد محدودیت‌های CPU یا حافظه را کمی افزایش دهید.
+
+[مقیاس پذیر خودکار عمودی](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#readme) می‌تواند در حالت _recommender_ اجرا شود تا ارقام پیشنهادی برای درخواست‌ها و محدودیت‌ها را ارائه دهد.
+
+* برخی افزونه‌ها به صورت یک رونوشت در هر گره اجرا می‌شوند که توسط {{< glossary_tooltip text="DaemonSet"
+  term_id="daemonset" >}} کنترل می‌شوند: به عنوان مثال، یک تجمیع‌کننده لاگ در سطح گره. مشابه مورد افزونه‌های مقیاس‌پذیر افقی، ممکن است لازم باشد محدودیت‌های CPU یا حافظه را کمی افزایش دهید.
+
+## {{% heading "whatsnext" %}}
+
+* `VerticalPodAutoscaler` یک منبع سفارشی است که می‌توانید در خوشه خود مستقر کنید تا به شما در مدیریت درخواست‌های منابع و محدودیت‌های podها کمک کند.
+درباره [مقیاس پذیر خودکار عمودی](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#readme) و نحوه استفاده از آن برای مقیاس‌بندی اجزای خوشه، از جمله افزونه‌های حیاتی خوشه، بیشتر بدانید.
+
+* درباره [مقیاس‌بندی خودکار گره](/docs/concepts/cluster-administration/node-autoscaling/) بخوانید
+
+* [تغییر اندازه افزونه](https://github.com/kubernetes/autoscaler/tree/master/addon-resizer#readme)
+به شما کمک می‌کند تا با تغییر مقیاس خوشه، اندازه افزونه‌ها را به طور خودکار تغییر دهید.

content/fa/docs/setup/best-practices/enforcing-pod-security-standards.md

@@ -0,0 +1,54 @@
+---
+reviewers:
+- xirehat
+title: اجرای استانداردهای امنیتی pod
+weight: 40
+---
+
+<!-- overview -->
+
+این صفحه مروری بر بهترین شیوه‌ها در مورد اجرای [استانداردهای امنیتی پاد](/docs/concepts/security/pod-security-standards) ارائه می‌دهد.
+
+<!-- body -->
+
+## استفاده از کنترل‌کننده پذیرش امنیتی داخلی pod
+
+{{< feature-state for_k8s_version="v1.25" state="stable" >}}
+
+کنترل‌کننده‌ی پذیرش امنیت پاد [Pod Security Admission Controller](/docs/reference/access-authn-authz/admission-controllers/#podsecurity) قصد دارد جایگزین سیاست‌های امنیتی منسوخ‌شده‌ی پاد (PodSecurityPolicies) شود.
+
+### پیکربندی تمام فضاهای نام خوشه
+
+فضاهای نامی که فاقد هرگونه پیکربندی هستند، باید به عنوان شکاف‌های قابل توجه در مدل امنیتی خوشه شما در نظر گرفته شوند. توصیه می‌کنیم برای تجزیه و تحلیل انواع بارهای کاری موجود در هر فضای نام، وقت بگذارید و با مراجعه به استانداردهای امنیتی پاد، سطح مناسبی را برای هر یک از آنها تعیین کنید. فضاهای نام بدون برچسب فقط باید نشان دهند که هنوز ارزیابی نشده‌اند.
+
+در سناریویی که همه بارهای کاری در همه فضاهای نام الزامات امنیتی یکسانی دارند، ما یک [مثال](/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/#applying-to-all-namespaces) ارائه می‌دهیم که نحوه اعمال برچسب‌های PodSecurity را به صورت انبوه نشان می‌دهد.
+
+### اصل حداقل امتیاز را بپذیرید
+
+در یک دنیای ایده‌آل، هر پاد در هر فضای نامی الزامات سیاست `محدود` را برآورده می‌کند. با این حال، این امر نه ممکن است و نه عملی، زیرا برخی از بارهای کاری به دلایل موجه به امتیازات بالاتری نیاز دارند.
+
+- فضاهای نامی که به بارهای کاری «ممتاز» اجازه می‌دهند، باید کنترل‌های دسترسی مناسبی را ایجاد و اجرا کنند.
+- برای بارهای کاری که در آن فضاهای نام مجاز اجرا می‌شوند، مستندات مربوط به الزامات امنیتی منحصر به فرد آنها را نگهداری کنید. در صورت امکان، در نظر بگیرید که چگونه می‌توان این الزامات را بیشتر محدود کرد.
+
+### اتخاذ یک استراتژی چند حالته
+
+حالت‌های `audit` و `warn` کنترل‌کننده پذیرش استانداردهای امنیتی پاد، جمع‌آوری بینش‌های امنیتی مهم در مورد پادهای شما را بدون ایجاد اختلال در حجم کار موجود، آسان می‌کند.
+
+فعال کردن این حالت‌ها برای همه فضاهای نام، و تنظیم آنها روی سطح و نسخه مورد نظر شما که در نهایت می‌خواهید `enforce` کنید، یک تمرین خوب است. هشدارها و حاشیه‌نویسی‌های حسابرسی ایجاد شده در این مرحله می‌توانند شما را به سمت آن وضعیت هدایت کنند. اگر انتظار دارید نویسندگان بار کاری تغییراتی را برای مطابقت با سطح مورد نظر ایجاد کنند، حالت `warn` را فعال کنید. اگر انتظار دارید از گزارش‌های حسابرسی برای نظارت/هدایت تغییرات برای مطابقت با سطح مورد نظر استفاده کنید، حالت `audit` را فعال کنید.
+
+وقتی حالت `enforce` را روی مقدار دلخواه خود تنظیم کرده‌اید، این حالت‌ها همچنان می‌توانند به چند روش مختلف مفید باشند:
+
+- با تنظیم `warn` در همان سطح `enforce`، کلاینت‌ها هنگام تلاش برای ایجاد Podها (یا منابعی که قالب‌های Pod دارند) که اعتبارسنجی را پشت سر نمی‌گذارند، هشدارهایی دریافت می‌کنند. این به آنها کمک می‌کند تا آن منابع را برای مطابقت به‌روزرسانی کنند.
+- در فضاهای نامی که `enforce` را به یک نسخه غیرجدید خاص پین می‌کنند، تنظیم حالت‌های `audit` و `warn` در همان سطح `enforce`، اما به نسخه `latest`، امکان مشاهده تنظیماتی را فراهم می‌کند که در نسخه‌های قبلی مجاز بودند اما طبق بهترین شیوه‌های فعلی مجاز نیستند.
+
+## جایگزین‌های شخص ثالث
+
+{{% thirdparty-content %}}
+
+گزینه‌های دیگری برای اجرای پروفایل‌های امنیتی در بوم‌سازگان کوبرنتیز در حال توسعه هستند:
+
+- [Kubewarden](https://github.com/kubewarden).
+- [Kyverno](https://kyverno.io/policies/).
+- [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper).
+
+تصمیم برای استفاده از یک راهکار داخلی (مثلاً کنترل‌کننده پذیرش PodSecurity) در مقابل یک ابزار شخص ثالث، کاملاً به شرایط شما بستگی دارد. هنگام ارزیابی هر راهکاری، اعتماد به زنجیره تأمین شما بسیار مهم است. در نهایت، استفاده از هر یک از رویکردهای فوق‌الذکر بهتر از انجام ندادن هیچ کاری خواهد بود.