Skip to content

Commit 0c7e9ff

Browse files
committed
Init Persian localization - Part 21
1 parent 20b38a5 commit 0c7e9ff

File tree

3 files changed

+660
-0
lines changed

3 files changed

+660
-0
lines changed
Lines changed: 92 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,92 @@
1+
---
2+
title: "بارکاری"
3+
weight: 55
4+
description: >
5+
پادها، کوچکترین شیء محاسباتی قابل استقرار در کوبرنتیز، و انتزاع‌های سطح بالاتری که به شما در اجرای آنها کمک می‌کنند را درک کنید.
6+
no_list: true
7+
card:
8+
title: حجم کار و پادها
9+
name: concepts
10+
weight: 60
11+
---
12+
13+
{{< glossary_definition term_id="workload" length="short" >}}
14+
چه وظیفهٔ شما یک مؤلفهٔ واحد باشد یا چندین مؤلفه که با هم کار می‌کنند، در کوبرنتیز آن را
15+
درون مجموعه‌ای از [_Pods_](/docs/concepts/workloads/pods) اجرا می‌کنید.
16+
در کوبرنتیز، یک Pod نمایانگر مجموعه‌ای از
17+
{{< glossary_tooltip text="Containers" term_id="container" >}}
18+
در حال اجرا روی کلاستر شماست.
19+
20+
Pods در کوبرنتیز یک [چرخهٔ عمر تعریف‌شده](/docs/concepts/workloads/pods/pod-lifecycle/) دارند.
21+
برای مثال، وقتی یک Pod در کلاستر شما در حال اجراست، یک خطای بحرانی در
22+
{{< glossary_tooltip text="Node" term_id="node" >}}
23+
که آن Pod روی آن اجرا می‌شود، به معنای از کار افتادن همهٔ Podهای آن Node است.
24+
کوبرنتیز این سطح از خطا را نهایی در نظر می‌گیرد: برای بازیابی باید یک Pod جدید ایجاد کنید،
25+
حتی اگر آن Node بعداً سالم شود.
26+
27+
با این حال، برای ساده‌تر شدن کار، نیازی نیست هر Pod را مستقیماً مدیریت کنید.
28+
در عوض می‌توانید از _Workload resources_ استفاده کنید که مجموعه‌ای از Pods را به نمایندگی از شما مدیریت می‌کنند.
29+
این منابع {{< glossary_tooltip term_id="controller" text="Controllers" >}}
30+
را پیکربندی می‌کنند تا مطمئن شوند تعداد مناسب و نوع صحیح Pod در حال اجرا باشد،
31+
مطابق با حالتی که شما مشخص کرده‌اید.
32+
33+
کوبرنتیز چند منبع پیش‌فرض برای Workload فراهم می‌کند:
34+
35+
* [Deployment](/docs/concepts/workloads/controllers/deployment/) و [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/)
36+
(جایگزین منبع قدیمی
37+
{{< glossary_tooltip text="ReplicationController" term_id="replication-controller" >}}).
38+
Deployment برای مدیریت یک بار کاری بدون وضعیت (stateless) در کلاستر شما مناسب است،
39+
جایی که هر Pod در این Deployment قابل تعویض بوده و در صورت لزوم می‌توان آن را جایگزین کرد.
40+
41+
* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/)
42+
به شما اجازه می‌دهد یک یا چند Pod مرتبط که به نوعی وضعیت (state) را دنبال می‌کنند، اجرا کنید.
43+
برای مثال، اگر بار کاری شما داده‌ها را به‌صورت مداوم ثبت می‌کند، می‌توانید یک StatefulSet
44+
اجرا کنید که هر Pod را به یک
45+
[PersistentVolume](/docs/concepts/storage/persistent-volumes/)
46+
اختصاص دهد. کد شما، که در Pods متعلق به آن StatefulSet اجرا می‌شود، می‌تواند داده‌ها را
47+
بین سایر Pods در همان StatefulSet تکرار کند تا مقاومت کلی افزایش یابد.
48+
49+
* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
50+
Pods‌ای را تعریف می‌کند که خدمات محلی (local) به هر Node ارائه می‌دهند.
51+
هر بار که یک Node جدید به کلاستر شما اضافه شود و با مشخصات یک DaemonSet مطابقت داشته باشد،
52+
کنترل‌پلن یک Pod از آن DaemonSet را روی Node جدید زمان‌بندی می‌کند.
53+
هر Pod در یک DaemonSet کاری شبیه یک سرویس سیستم (system daemon) در سرورهای کلاسیک Unix/POSIX انجام می‌دهد.
54+
یک DaemonSet ممکن است برای عملکرد کلاستر شما اساسی باشد، مانند افزونه‌ای برای اجرای
55+
[شبکه‌بندی کلاستر](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-network-model)،
56+
یا ممکن است به مدیریت Node کمک کند، یا رفتاری اختیاری فراهم کند که پلتفرم کانتینری شما را بهبود دهد.
57+
58+
* [Job](/docs/concepts/workloads/controllers/job/) و
59+
[CronJob](/docs/concepts/workloads/controllers/cron-jobs/)
60+
روش‌های متفاوتی برای تعریف وظایفی فراهم می‌کنند که تا پایان اجرا شده و سپس متوقف می‌شوند.
61+
می‌توانید از [Job](/docs/concepts/workloads/controllers/job/)
62+
برای تعریف یک وظیفه که یک بار و تا پایان اجرا شود استفاده کنید.
63+
می‌توانید از [CronJob](/docs/concepts/workloads/controllers/cron-jobs/)
64+
برای اجرای مکرر همان Job طبق یک زمان‌بندی مشخص استفاده کنید.
65+
66+
در اکوسیستم گسترده‌تر کوبرنتیز، می‌توانید منابع workload شخص ثالث را بیابید که رفتارهای اضافی ارائه می‌دهند.
67+
با استفاده از یک
68+
[Custom Resource Definition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)،
69+
می‌توانید منبع workload شخص ثالثی اضافه کنید اگر به رفتار خاصی نیاز دارید که در هسته کوبرنتیز موجود نیست.
70+
برای مثال، اگر می‌خواستید گروهی از Pods را برای برنامه‌تان اجرا کنید اما کار را تا زمانی که _همه_ Pods در دسترس نباشند متوقف کنید
71+
(شاید برای بعضی کارهای توزیع‌شده با توان بالا)،
72+
می‌توانید افزونه‌ای پیاده‌سازی یا نصب کنید که آن ویژگی را فراهم آورد.
73+
74+
## {{% heading "whatsnext" %}}
75+
76+
هم‌چنین علاوه بر مطالعه هر نوع API برای مدیریت Workload، می‌توانید یاد بگیرید چگونه کارهای خاص را انجام دهید:
77+
78+
* [اجرای یک برنامه بدون وضعیت با استفاده از Deployment](/docs/tasks/run-application/run-stateless-application-deployment/)
79+
* اجرای یک برنامه با وضعیت به‌صورت [یک نمونهٔ واحد](/docs/tasks/run-application/run-single-instance-stateful-application/)
80+
یا به‌صورت [مجموعهٔ تکرارشده](/docs/tasks/run-application/run-replicated-stateful-application/)
81+
* [اجرای وظایف خودکار با CronJob](/docs/tasks/job/automated-tasks-with-cron-jobs/)
82+
83+
برای آشنایی با مکانیزم‌های کوبرنتیز برای جدا کردن کد از پیکربندی، به [Configuration](/docs/concepts/configuration/) مراجعه کنید.
84+
85+
دو مفهوم پشتیبان وجود دارند که زمینهٔ نحوهٔ مدیریت Pods برای برنامه‌ها توسط کوبرنتیز را توضیح می‌دهند:
86+
* [Garbage collection](/docs/concepts/architecture/garbage-collection/) اشیاء را پس از حذف _منبع مالک_ آن‌ها از بین می‌برد.
87+
* [_time-to-live after finished_ controller](/docs/concepts/workloads/controllers/ttlafterfinished/)
88+
پس از گذشت زمان مشخصی از تکمیل Jobs، آن‌ها را حذف می‌کند.
89+
90+
پس از اجرای برنامهٔ شما، ممکن است بخواهید آن را به‌صورت یک [Service](/docs/concepts/services-networking/service/)
91+
در اینترنت در دسترس قرار دهید یا برای برنامه‌های وب فقط با استفاده از یک [Ingress](/docs/concepts/services-networking/ingress/) منتشر کنید.
92+
Lines changed: 129 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,129 @@
1+
---
2+
title: مقیاس‌بندی خودکار بارهای کاری
3+
description: >-
4+
با مقیاس‌بندی خودکار، می‌توانید بارهای کاری خود را به طور خودکار به یک روش یا روش دیگر به‌روزرسانی کنید. این به کلاستر شما اجازه می‌دهد تا به تغییرات در تقاضای منابع، انعطاف‌پذیرتر و کارآمدتر واکنش نشان دهد.
5+
content_type: concept
6+
weight: 40
7+
---
8+
9+
<!-- overview -->
10+
11+
در Kubernetes، می‌توانید بسته به تقاضای فعلی منابع، حجم کار را _مقیاس_ کنید.
12+
13+
این به کلاستر شما اجازه می‌دهد تا به تغییرات در تقاضای منابع، انعطاف‌پذیرتر و کارآمدتر واکنش نشان دهد.
14+
15+
هنگامی که یک حجم کار را مقیاس‌بندی می‌کنید، می‌توانید تعداد کپی‌های مدیریت‌شده توسط حجم کار را افزایش یا کاهش دهید، یا منابع موجود برای کپی‌های موجود را تنظیم کنید.
16+
17+
رویکرد اول به عنوان _مقیاس‌بندی افقی_ و رویکرد دوم به عنوان _مقیاس‌بندی عمودی_ شناخته می‌شود.
18+
19+
بسته به مورد استفاده شما، روش‌های دستی و خودکار برای مقیاس‌بندی حجم کار شما وجود دارد.
20+
21+
<!-- body -->
22+
23+
## مقیاس‌بندی دستی بارهای کاری
24+
25+
کوبرنتیز از _مقیاس‌بندی دستی_ بارهای کاری پشتیبانی می‌کند. مقیاس‌بندی افقی را می‌توانید
26+
با استفاده از ابزار `kubectl` انجام دهید.
27+
برای مقیاس‌بندی عمودی، باید تعریف منبع بار کاری خود را _patch_ کنید.
28+
29+
مثال هر دو استراتژی را در ادامه ببینید:
30+
31+
- **مقیاس‌بندی افقی**: [اجرای چند نمونه از برنامهٔ شما](/docs/tutorials/kubernetes-basics/scale/scale-intro/)
32+
- **مقیاس‌بندی عمودی**: [تغییر اندازهٔ منابع CPU و حافظهٔ اختصاص‌یافته به کانتینرها](/docs/tasks/configure-pod-container/resize-container-resources)
33+
34+
## مقیاس‌بندی خودکار بارهای کاری
35+
36+
کوبرنتیز همچنین از _مقیاس‌بندی خودکار_ بارهای کاری پشتیبانی می‌کند که موضوع این صفحه است.
37+
38+
مفهوم _Autoscaling_ در کوبرنتیز به توانایی به‌روزرسانی خودکار یک
39+
شیٔی که مجموعه‌ای از Pods را مدیریت می‌کند (برای مثال
40+
{{< glossary_tooltip text="Deployment" term_id="deployment" >}}) اشاره دارد.
41+
42+
### مقیاس‌بندی بارهای کاری به‌صورت افقی
43+
44+
در کوبرنتیز، می‌توانید به‌صورت خودکار بار کاری را به‌صورت افقی با استفاده از _HorizontalPodAutoscaler_ مقیاس‌بندی کنید.
45+
46+
این قابلیت به‌عنوان یک منبع API کوبرنتیز و یک {{< glossary_tooltip text="controller" term_id="controller" >}} پیاده‌سازی شده و به‌طور دوره‌ای تعداد {{< glossary_tooltip text="replicas" term_id="replica" >}} را در یک بار کاری تنظیم می‌کند تا با مصرف منابع مشاهده‌شده مانند استفاده از CPU یا حافظه هم‌خوانی داشته باشد.
47+
48+
یک [آموزش گام‌به‌گام](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough) برای پیکربندی _HorizontalPodAutoscaler_ برای یک Deployment وجود دارد.
49+
50+
### مقیاس‌بندی بارهای کاری به‌صورت عمودی
51+
52+
{{< feature-state for_k8s_version="v1.25" state="stable" >}}
53+
54+
می‌توانید به‌صورت خودکار بار کاری را به‌صورت عمودی با استفاده از _VerticalPodAutoscaler_ مقیاس‌بندی کنید. بر خلاف HPA، VPA به‌طور پیش‌فرض همراه کوبرنتیز عرضه نمی‌شود، بلکه یک پروژهٔ مستقل است که در [GitHub](https://github.com/kubernetes/autoscaler/tree/9f87b78df0f1d6e142234bb32e8acbd71295585a/vertical-pod-autoscaler) در دسترس قرار دارد.
55+
56+
پس از نصب، می‌توانید برای بارهای کاری خود {{< glossary_tooltip text="CustomResourceDefinitions" term_id="customresourcedefinition" >}} (CRD) ایجاد کنید که تعریف می‌کنند _چگونه_ و _چه زمانی_ منابع نسخه‌های مدیریت‌شده را مقیاس‌بندی کنند.
57+
58+
{{< note >}}
59+
برای کارکرد VPA نیاز است که [Metrics Server](https://github.com/kubernetes-sigs/metrics-server) در کلاستر شما نصب شده باشد.
60+
{{< /note >}}
61+
62+
در حال حاضر، VPA می‌تواند در چهار حالت مختلف کار کند:
63+
64+
{{< table caption="حالت‌های مختلف VPA" >}}
65+
حالت | توضیحات
66+
:----|:-----------
67+
`Auto` | در حال حاضر `Recreate`. ممکن است در آینده به به‌روزرسانی درجا (in-place) تغییر یابد.
68+
`Recreate` | VPA درخواست‌های منابع را هنگام ایجاد پاد تنظیم می‌کند و همچنین با بیرون‌کردن پادهای موجود، آن‌ها را به‌روزرسانی می‌کند وقتی درخواست منابع به‌طور قابل توجهی با پیشنهاد جدید متفاوت باشد.
69+
`Initial` | VPA تنها هنگام ایجاد پاد درخواست‌های منابع را تنظیم می‌کند و پس از آن هرگز آن‌ها را تغییر نمی‌دهد.
70+
`Off` | VPA به‌صورت خودکار نیازمندی‌های منابع پادها را تغییر نمی‌دهد. پیشنهادها محاسبه می‌شوند و می‌توان آن‌ها را در شی VPA بررسی کرد.
71+
{{< /table >}}
72+
73+
#### مقیاس‌بندی عمودی پاد درجا
74+
75+
{{< feature-state feature_gate_name="InPlacePodVerticalScaling" >}}
76+
77+
از زمان Kubernetes {{< skew currentVersion >}}، VPA از تغییر اندازهٔ پادها درجا پشتیبانی نمی‌کند، اما این ادغام در دست کار است.
78+
برای تغییر اندازهٔ دستی پادها درجا، به [Resize Container Resources In-Place](/docs/tasks/configure-pod-container/resize-container-resources/) مراجعه کنید.
79+
80+
### مقیاس‌بندی خودکار بر اساس اندازهٔ کلاستر
81+
82+
برای بارهای کاری که نیاز به مقیاس‌بندی بر اساس اندازهٔ کلاستر دارند (برای مثال `cluster-dns` یا سایر اجزای سیستمی)، می‌توانید از
83+
[_Cluster Proportional Autoscaler_](https://github.com/kubernetes-sigs/cluster-proportional-autoscaler) استفاده کنید.
84+
مانند VPA، این ابزار بخشی از هستهٔ کوبرنتیز نیست و به‌صورت یک پروژهٔ مستقل در GitHub میزبانی می‌شود.
85+
86+
Cluster Proportional Autoscaler تعداد {{< glossary_tooltip text="Nodes" term_id="node" >}} قابل زمان‌بندی و هسته‌ها را پایش کرده و
87+
تعداد Replicaهای بار کاری هدف را بر همان اساس تنظیم می‌کند.
88+
89+
اگر قرار است تعداد Replicaها ثابت بماند، می‌توانید بارهای کاری خود را به‌صورت عمودی بر اساس اندازهٔ کلاستر مقیاس دهید
90+
با استفاده از [_Cluster Proportional Vertical Autoscaler_](https://github.com/kubernetes-sigs/cluster-proportional-vertical-autoscaler).
91+
این پروژه **در حال حاضر در مرحلهٔ بتا** قرار دارد و در GitHub در دسترس است.
92+
93+
در حالی که Cluster Proportional Autoscaler تعداد Replicaهای یک بار کاری را مقیاس می‌دهد،
94+
Cluster Proportional Vertical Autoscaler درخواست‌های منابع (برای مثال در یک Deployment یا DaemonSet) را
95+
بر اساس تعداد Nodes و/یا هسته‌ها در کلاستر تنظیم می‌کند.
96+
97+
### مقیاس‌بندی خودکار مبتنی بر رویداد
98+
99+
همچنین امکان مقیاس‌بندی بارهای کاری بر اساس رویدادها وجود دارد، برای مثال با استفاده از
100+
[_Kubernetes Event Driven Autoscaler_ (**KEDA**)](https://keda.sh/).
101+
102+
KEDA یک پروژهٔ فارغ‌التحصیل‌شده از CNCF است که به شما امکان می‌دهد بارهای کاری خود را
103+
بر اساس تعداد رویدادهای قابل پردازش—مثلاً تعداد پیام‌ها در یک صف—مقیاس دهید.
104+
برای منابع رویداد مختلف، آداپتورهای متنوعی در دسترس هستند.
105+
106+
### مقیاس‌بندی خودکار بر اساس زمان‌بندی‌ها
107+
108+
استراتژی دیگری برای مقیاس‌بندی بارهای کاری شما این است که عملیات مقیاس‌بندی را **زمان‌بندی** کنید، برای مثال جهت کاهش مصرف منابع در ساعات کم‌بار.
109+
110+
مشابه مقیاس‌بندی خودکار مبتنی بر رویداد، این رفتار را می‌توان با استفاده از KEDA همراه با
111+
[`Cron` scaler](https://keda.sh/docs/latest/scalers/cron/)
112+
دستیابی کرد.
113+
`Cron` scaler به شما امکان می‌دهد زمان‌بندی‌ها (و مناطق زمانی) را برای مقیاس دادن بارهای کاری خود به داخل یا خارج تعریف کنید.
114+
115+
## مقیاس‌بندی زیرساخت کلاستر
116+
117+
اگر مقیاس‌بندی بارهای کاری برای رفع نیازهای شما کافی نیست، می‌توانید زیرساخت کلاستر خود را نیز مقیاس دهید.
118+
119+
مقیاس‌بندی زیرساخت کلاستر به‌طور معمول افزودن یا حذف {{< glossary_tooltip text="nodes" term_id="node" >}} را شامل می‌شود.
120+
برای اطلاعات بیشتر، [Node autoscaling](/docs/concepts/cluster-administration/node-autoscaling/) را ببینید.
121+
122+
## {{% heading "whatsnext" %}}
123+
124+
- یادگیری بیشتر درباره مقیاس‌بندی افقی
125+
- [مقیاس یک StatefulSet](/docs/tasks/run-application/scale-stateful-set/)
126+
- [آموزش گام‌به‌گام HorizontalPodAutoscaler](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)
127+
- [تغییر اندازهٔ منابع کانتینر به‌صورت درجا](/docs/tasks/configure-pod-container/resize-container-resources/)
128+
- [مقیاس‌بندی خودکار سرویس DNS در کلاستر](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/)
129+
- آشنایی با [Node autoscaling](/docs/concepts/cluster-administration/node-autoscaling/)

0 commit comments

Comments
 (0)