Init Persian localization - Part 19

Author: xirehat

content/fa/docs/concepts/overview/working-with-objects/_index.md

@@ -0,0 +1,160 @@
+---
+title: اشیاء در کوبرنتیز
+content_type: concept
+weight: 30
+description: >
+  اشیای کوبرنتیز موجودیت‌های پایداری در سیستم کوبرنتیز هستند.  
+  کوبرنتیز از این موجودیت‌ها برای نمایش وضعیت خوشه شما استفاده می‌کند.  
+  دربارهٔ مدل اشیای کوبرنتیز و چگونگی کار با این اشیا بیشتر بیاموزید.
+simple_list: true
+card:
+  name: concepts
+  weight: 40
+---
+
+<!-- overview -->
+
+این صفحه توضیح می‌دهد که اشیای کوبرنتیز چگونه در API کوبرنتیز نمایش داده می‌شوند و چگونه می‌توانید آن‌ها را در قالب `.yaml` بیان کنید.
+
+<!-- body -->
+
+## درک اشیای کوبرنتیز {#kubernetes-objects}
+
+*اشیای کوبرنتیز* موجودیت‌های پایداری در سیستم کوبرنتیز هستند. کوبرنتیز از این موجودیت‌ها برای نمایش وضعیت خوشهٔ شما استفاده می‌کند. این اشیا به‌طور مشخص می‌توانند موارد زیر را توصیف کنند:
+
+* چه برنامه‌های کانتینری در حال اجرا هستند (و روی کدام نودها)
+* منابع در دسترس برای آن برنامه‌ها
+* سیاست‌های مرتبط با رفتار آن برنامه‌ها، مانند سیاست‌های راه‌اندازی مجدد، به‌روزرسانی‌ها و تحمل خطا
+
+یک شیٔ کوبرنتیز در واقع «ثبتِ نیت» است—پس از ایجاد یک شیٔ، سیستم کوبرنتیز به‌طور مداوم تلاش می‌کند تا از وجود آن شیٔ اطمینان حاصل کند. با ایجاد یک شیٔ، در واقع به سیستم کوبرنتیز می‌گویید که می‌خواهید بار کاری خوشهٔ شما چه شکلی باشد؛ این همان *وضعیت مطلوب* خوشه است.
+
+برای کار با اشیای کوبرنتیز—چه برای ایجاد، چه اصلاح یا حذف آن‌ها—باید از
+[API کوبرنتیز](/docs/concepts/overview/kubernetes-api/) استفاده کنید. به‌عنوان مثال، وقتی از
+رابط خط فرمان `kubectl` استفاده می‌کنید، این CLI فراخوان‌های لازم به API کوبرنتیز را برای شما انجام می‌دهد. همچنین می‌توانید به‌طور مستقیم در برنامه‌های خود و با استفاده از یکی از
+[کتابخانه‌های کاربری](/docs/reference/using-api/client-libraries/)
+به API کوبرنتیز متصل شوید.
+
+### مشخصات و وضعیت شیء
+
+تقریباً هر شیء کوبرنتیز دو فیلد تودرتو دارد که پیکربندی شیء را کنترل می‌کنند:  
+*`spec`* (مشخصات) و *`status`* (وضعیت).  
+برای اشیایی که دارای `spec` هستند، هنگام ایجاد شیء باید این فیلد را تنظیم کنید و
+توصیفی از ویژگی‌هایی که می‌خواهید منبع داشته باشد ارائه دهید؛ یعنی _وضعیت مطلوب_ آن.
+
+فیلد `status` _وضعیت فعلی_ شیء را توصیف می‌کند و توسط سیستم کوبرنتیز و اجزای آن
+تأمین و به‌روزرسانی می‌شود.  
+{{< glossary_tooltip text="control plane" term_id="control-plane" >}}
+کوبرنتیز به‌طور مداوم و فعال تلاش می‌کند وضعیت واقعی هر شیء را با وضعیت مطلوب
+ارائه‌شده توسط شما منطبق نگه دارد.
+
+برای مثال: در کوبرنتیز، **Deployment** شیئی است که می‌تواند یک برنامهٔ در حال اجرا روی خوشهٔ شما را نشان دهد.  
+هنگامی‌ که Deployment را ایجاد می‌کنید، ممکن است در `spec` آن مشخص کنید که سه
+نمونه (Replica) از برنامه باید اجرا شوند. سیستم کوبرنتیز این مشخصات را خوانده و سه
+نمونه از برنامهٔ موردنظر شما را اجرا می‌کند—و `status` را طوری به‌روزرسانی می‌کند که
+با `spec` منطبق باشد. اگر یکی از این نمونه‌ها از کار بیفتد (تغییری در وضعیت)، سیستم
+کوبرنتیز به اختلاف بین `spec` و `status` واکنش نشان می‌دهد و آن را اصلاح می‌کند—در این
+جا با راه‌اندازی یک نمونهٔ جایگزین.
+
+برای اطلاعات بیشتر دربارهٔ فیلدهای `spec`، `status` و متاداده‌ها، به
+[قراردادهای API کوبرنتیز](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)
+مراجعه کنید.
+
+### توصیف یک شیء در کوبرنتیز
+
+هنگام ایجاد یک شیء در کوبرنتیز، باید `spec` آن را که وضعیت مطلوب را توصیف می‌کند به‌ همراه
+برخی اطلاعات پایه (مانند نام) ارائه دهید.  
+وقتی از API کوبرنتیز برای ایجاد شیء استفاده می‌کنید (مستقیم یا از طریق `kubectl`)،
+درخواست API باید این اطلاعات را به‌صورت JSON در بدنهٔ درخواست داشته باشد.  
+اغلب، این اطلاعات را در فایلی به نام _مانیفست_ به `kubectl` می‌دهید.  
+به‌طور قراردادی، مانیفست‌ها با فرمت YAML نوشته می‌شوند (هرچند می‌توانید از JSON نیز
+استفاده کنید).  
+ابزاری مانند `kubectl` هنگام ارسال درخواست HTTP به API، اطلاعات موجود در مانیفست را
+به JSON یا یک قالب‌سازی پشتیبانی‌شدهٔ دیگر تبدیل می‌کند.
+
+در این‌جا یک نمونه مانیفست آورده شده که فیلدهای الزامی و `spec` یک Deployment
+کوبرنتیز را نشان می‌دهد:
+
+{{% code_sample file="application/deployment.yaml" %}}
+
+یکی از روش‌های ایجاد یک Deployment با استفاده از فایلی شبیه مثال بالا، استفاده از
+دستور [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) در
+رابط خط فرمان `kubectl` و ارسال فایل `.yaml` به‌عنوان آرگومان است. برای مثال:
+
+```shell
+kubectl apply -f https://k8s.io/examples/application/deployment.yaml
+```
+
+خروجی مشابه این است:
+
+```
+deployment.apps/nginx-deployment created
+```
+
+### فیلدهای ضروری
+
+در مانیفست (فایل YAML یا JSON) مربوط به شیٔ کوبرنتیزی که می‌خواهید ایجاد کنید، لازم است مقادیر فیلدهای زیر را تعیین کنید:
+
+* `apiVersion` – نسخهٔ API کوبرنتیز که برای ایجاد این شیٔ استفاده می‌کنید  
+* `kind` – نوع شیئی که می‌خواهید ایجاد کنید  
+* `metadata` – داده‌هایی که به شناسایی منحصربه‌فرد شیء کمک می‌کنند، شامل رشتهٔ `name`، شناسهٔ یکتا (`UID`) و `namespace` اختیاری  
+* `spec` – وضعیتی که برای شیء انتظار دارید
+
+قالب دقیق فیلد `spec` برای هر شیء کوبرنتیز متفاوت است و شامل فیلدهای تو‌درتوی مخصوص آن شیء می‌شود.  
+[مرجع API کوبرنتیز](/docs/reference/kubernetes-api/) می‌تواند به شما کمک کند قالب `spec` برای تمام اشیایی را که می‌توانید با کوبرنتیز ایجاد کنید پیدا کنید.
+
+برای نمونه، به فیلد [`spec`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec) در مرجع API مربوط به Pod نگاه کنید.  
+برای هر Pod، فیلد `.spec` خود پاد و وضعیت مطلوب آن (مثل نام ایمیج کانتینر برای هر کانتینر در آن پاد) را مشخص می‌کند. نمونهٔ دیگری از مشخصات شیء، فیلد [`spec`](/docs/reference/kubernetes-api/workload-resources/stateful-set-v1/#StatefulSetSpec) برای API مربوط به StatefulSet است؛ در StatefulSet، فیلد `.spec` خود StatefulSet و وضعیت مطلوب آن را تعیین می‌کند.  
+درون `.spec` یک StatefulSet، یک [قالب](/docs/concepts/workloads/pods/#pod-templates) برای اشیای Pod قرار دارد. این قالب پادهایی را توصیف می‌کند که کنترلر StatefulSet برای برآورده کردن مشخصات StatefulSet ایجاد خواهد کرد.  
+انواع مختلف شیء همچنین می‌توانند فیلدهای `.status` متفاوتی داشته باشند؛ صفحات مرجع API ساختار این فیلد `.status` و محتوای آن را برای هر نوع شیء توضیح می‌دهند.
+
+{{< note >}}
+برای اطلاعات بیشتر دربارهٔ نگارش فایل‌های پیکربندی YAML به  
+[بهترین شیوه‌های پیکربندی](/docs/concepts/configuration/overview/) مراجعه کنید.
+{{< /note >}}
+
+## اعتبارسنجی فیلد در سمت سرور
+
+از نسخهٔ Kubernetes v1.25، سرور API قابلیت
+[اعتبارسنجی فیلد](/docs/reference/using-api/api-concepts/#field-validation)
+در سمت سرور را ارائه می‌دهد که فیلدهای ناشناخته یا تکراری در یک شیء را شناسایی می‌کند.
+این قابلیت تمام کارکردهای `kubectl --validate` را در سمت سرور فراهم می‌کند.
+
+ابزار `kubectl` برای تعیین سطح اعتبارسنجی فیلد از فلگ `--validate` استفاده می‌کند.
+این فلگ مقادیر `ignore`، `warn` و `strict` را می‌پذیرد؛ همچنین مقادیر `true`
+(معادل `strict`) و `false` (معادل `ignore`) را قبول می‌کند.
+تنظیم پیش‌فرض در `kubectl`، گزینهٔ `--validate=true` است.
+
+`Strict`
+: اعتبارسنجی سخت‌گیرانهٔ فیلد؛ در صورت خطا درخواست با شکست مواجه می‌شود
+
+`Warn`
+: اعتبارسنجی فیلد انجام می‌شود، اما خطاها به‌صورت هشدار گزارش می‌شوند و باعث خطا در درخواست نمی‌شوند
+
+`Ignore`
+: هیچ اعتبارسنجی فیلدی در سمت سرور انجام نمی‌شود
+
+اگر `kubectl` نتواند به سروری متصل شود که از اعتبارسنجی فیلد پشتیبانی می‌کند،
+به اعتبارسنجی سمت کاربر (client-side) برمی‌گردد. Kubernetes 1.27 و نسخه‌های پس از آن
+همواره اعتبارسنجی فیلد را ارائه می‌دهند؛ نسخه‌های قدیمی‌تر ممکن است این قابلیت را
+نداشته باشند. اگر خوشهٔ شما قدیمی‌تر از v1.27 است، مستندات نسخهٔ خود را بررسی کنید.
+
+## {{% heading "whatsnext" %}}
+
+اگر در Kubernetes تازه‌کار هستید، دربارهٔ موضوعات زیر بیشتر بخوانید:
+
+* [Pods](/docs/concepts/workloads/pods/) که پایه‌ای‌ترین اشیای کوبرنتیز هستند.
+* اشیای [Deployment](/docs/concepts/workloads/controllers/deployment/).
+* [کنترلرها](/docs/concepts/architecture/controller/) در کوبرنتیز.
+* [kubectl](/docs/reference/kubectl/) و [دستورات kubectl](/docs/reference/generated/kubectl/kubectl-commands).
+
+[مدیریت اشیای کوبرنتیز](/docs/concepts/overview/working-with-objects/object-management/)
+نشان می‌دهد چگونه با `kubectl` اشیا را مدیریت کنید.
+اگر `kubectl` را در اختیار ندارید، ممکن است لازم باشد آن را
+[نصب کنید](/docs/tasks/tools/#kubectl).
+
+برای آشنایی کلی با API کوبرنتیز، به این صفحه مراجعه کنید:
+
+* [مروری بر API کوبرنتیز](/docs/reference/using-api/)
+
+برای آشنایی عمیق‌تر با اشیا در کوبرنتیز، سایر صفحات همین بخش را مطالعه کنید:
+<!-- Docsy automatically includes a list of pages in the section -->

content/fa/docs/concepts/overview/working-with-objects/annotations.md

@@ -0,0 +1,82 @@
+---
+title: حاشیه‌نویسی‌ها
+content_type: concept
+weight: 60
+---
+
+<!-- overview -->
+می‌توانید از حاشیه‌نویس‌های کوبرنتیز برای پیوست کردن فرا‌دادهٔ دلخواه و غیرشناسه‌ای به {{< glossary_tooltip text="اشیاء" term_id="object" >}} استفاده کنید. ابزارها و کتابخانه‌ها می‌توانند به‌عنوان کلاینت این فرا‌داده را بازیابی کنند.
+
+<!-- body -->
+## پیوست کردن فرا‌داده به اشیاء
+
+برای پیوست کردن فرا‌داده به اشیای کوبرنتیز می‌توانید از برچسب‌ها (labels) یا حاشیه‌نویس‌ها (annotations) استفاده کنید.  
+برچسب‌ها برای انتخاب اشیا و یافتن مجموعه‌هایی از اشیا که شرایط خاصی را دارند به‌کار می‌روند.  
+در مقابل، حاشیه‌نویس‌ها برای شناسایی و انتخاب اشیا استفاده نمی‌شوند.  
+فرا‌داده در یک حاشیه‌نویس می‌تواند کوچک یا بزرگ، ساخت‌یافته یا غیرساخت‌یافته باشد و حتی شامل نویسه‌هایی باشد که در برچسب‌ها مجاز نیستند.  
+همچنین می‌توانید در فرا‌دادهٔ یک شیء به‌طور هم‌زمان از برچسب‌ها و حاشیه‌نویس‌ها استفاده کنید.
+
+حاشیه‌نویس‌ها نیز مانند برچسب‌ها، نگاشت‌های کلید/مقدار هستند:
+
+```json
+"metadata": {
+  "annotations": {
+    "key1" : "value1",
+    "key2" : "value2"
+  }
+}
+```
+
+{{<note>}}
+کلیدها و مقدارهای این نگاشت باید رشته (string) باشند؛ به بیان دیگر، نمی‌توانید از انواع عددی، بولی، فهرست یا هر نوع دیگری برای کلید یا مقدار استفاده کنید.
+{{</note>}}
+
+در ادامه چند نمونه از اطلاعاتی که می‌توان در حاشیه‌نویس‌ها ذخیره کرد آورده شده است:
+
+* فیلدهایی که توسط لایهٔ پیکربندی اعلانی مدیریت می‌شوند. افزودن این فیلدها به‌صورت حاشیه‌نویس، آن‌ها را از مقادیر پیش‌فرض تنظیم‌شده توسط کلاینت یا سرور و همچنین از فیلدهای تولیدشدهٔ خودکار یا فیلدهای تنظیم‌شده توسط سامانه‌های خوداندازه یا خودمقیاس جدا می‌کند.
+
+* اطلاعات ساخت (build)، انتشار (release) یا ایمیج مانند برچسب‌های زمانی (timestamp)، شناسهٔ انتشار (release ID)، شاخهٔ Git، شمارهٔ Pull Request، هش‌های ایمیج و نشانی رجیستری.
+
+* اشاره‌گرهایی به مخزن‌های لاگ، پایش (monitoring)، تحلیل (analytics) یا ممیزی (audit).
+
+* اطلاعات کتابخانهٔ کلاینت یا ابزار که می‌تواند برای اشکال‌زدایی مفید باشد؛ برای مثال نام، نسخه و اطلاعات build.
+
+* اطلاعات منشأ کاربر یا ابزار/سیستم، مانند URLهای اشیای مرتبط در دیگر اجزای اکوسیستم.
+
+* فرا‌دادهٔ سبک ابزارهای rollout؛ برای مثال پیکربندی یا نقاط بازیابی (checkpoint).
+
+* شماره تلفن یا پیجر افراد مسئول، یا مراجع دایرکتوری که نشان می‌دهند این اطلاعات در کجا یافت می‌شود، مثل وب‌سایت تیم.
+
+* دستورالعمل‌های کاربر نهایی برای پیاده‌سازی‌ها به‌منظور تغییر رفتار یا فعال‌سازی قابلیت‌های غیراستاندارد.
+
+به‌جای استفاده از حاشیه‌نویس‌ها، می‌توانید این نوع اطلاعات را در یک پایگاه داده یا دایرکتوری بیرونی ذخیره کنید، اما این کار تولید کتابخانه‌ها و ابزارهای مشترک برای استقرار، مدیریت، وارسی (introspection) و کارهای مشابه را بسیار دشوارتر می‌کند.
+
+## نحو و مجموعه نویسه
+
+_حاشیه‌نویس‌ها_ نگاشت‌های کلید/مقدار هستند. کلید معتبر یک حاشیه‌نویس دو بخش دارد: یک پیشوند اختیاری و یک نام که با اسلش (`/`) از هم جدا می‌شوند. بخش نام الزامی است و باید حداکثر ۶۳ نویسه باشد؛ این بخش باید با یک نویسهٔ الفانامریک (`[a-z0-9A-Z]`) آغاز و پایان یابد و می‌تواند در میان خود خط تیره (`-`)، زیرخط (`_`)، نقطه (`.`) و نویسه‌های الفانامریک داشته باشد. پیشوند اختیاری است؛ در صورت وجود، باید یک زیر‌دامنهٔ DNS باشد: رشته‌ای از برچسب‌های DNS که با نقطه (`.`) از هم جدا شده‌اند، در مجموع بیش از ۲۵۳ نویسه نباشد و در پایان با یک اسلش (`/`) بیاید.
+
+اگر پیشوند ذکر نشود، فرض بر این است که کلید حاشیه‌نویس خصوصیِ کاربر است. اجزای خودکار سامانه (برای مثال `kube-scheduler`، `kube-controller-manager`، `kube-apiserver`، `kubectl` یا اتوماسیون‌های شخص ثالث) که به اشیای کاربر نهایی حاشیه‌نویس اضافه می‌کنند، باید حتماً پیشوند مشخص کنند.
+
+پیشوندهای `kubernetes.io/` و `k8s.io/` برای اجزای اصلی کوبرنتیز رزرو شده‌اند.
+
+به‌عنوان مثال، در ادامه مانیفستی برای یک Pod آمده است که حاشیه‌نویس `imageregistry: https://hub.docker.com/` را دارد:
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: annotations-demo
+  annotations:
+    imageregistry: "https://hub.docker.com/"
+spec:
+  containers:
+  - name: nginx
+    image: nginx:1.14.2
+    ports:
+    - containerPort: 80
+```
+
+## {{% heading "whatsnext" %}}
+
+- درباره [برچسب‌ها و انتخابگرها](/docs/concepts/overview/working-with-objects/labels/) بیشتر بیاموزید.  
+- فهرست [برچسب‌ها، حاشیه‌نویس‌ها و تِینت‌های شناخته‌شده](/docs/reference/labels-annotations-taints/) را بیابید.