diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES index d97552508e6f1..3ee89b68875af 100644 --- a/OWNERS_ALIASES +++ b/OWNERS_ALIASES @@ -223,6 +223,16 @@ aliases: - Arhell - idvoretskyi - MaxymVlasov + sig-docs-fa-owners: # Admins for Persian content + - behiuu + - mamrezb + - moh0ps + - xirehat + sig-docs-fa-reviews: # PR reviews for Persian content + - behiuu + - mamrezb + - moh0ps + - xirehat # authoritative source: git.k8s.io/community/OWNERS_ALIASES committee-steering: # provide PR approvals for announcements - aojea diff --git a/README.md b/README.md index e1b5f3fa1f7f9..2960b53509345 100644 --- a/README.md +++ b/README.md @@ -221,14 +221,14 @@ If you need help at any point when contributing, the [New Contributor Ambassador | Language | Language | | -------------------------- | -------------------------- | -| [Bengali](./content/bn/README.md) | [Korean](./content/ko/README.md) | -| [Chinese](./content/zh-cn/README.md) | [Polish](./content/pl/README.md) | -| [French](./content/fr/README.md) | [Portuguese](./content/pt-br/README.md) | -| [German](./content/de/README.md) | [Russian](./content/ru/README.md) | -| [Hindi](./content/hi/README.md) | [Spanish](./content/es/README.md) | -| [Indonesian](./content/id/README.md) | [Ukrainian](./content/uk/README.md) | -| [Italian](./content/it/README.md) | [Vietnamese](./content/vi/README.md) | -| [Japanese](./content/ja/README.md) | | +| [Bengali](./content/bn/README.md) | [Korean](./content/ko/README.md) | +| [Chinese](./content/zh-cn/README.md) | [Persian](./content/fa/README.md) | +| [French](./content/fr/README.md) | [Polish](./content/pl/README.md) | +| [German](./content/de/README.md) | [Portuguese](./content/pt-br/README.md) | +| [Hindi](./content/hi/README.md) | [Russian](./content/ru/README.md) | +| [Indonesian](./content/id/README.md) | [Spanish](./content/es/README.md) | +| [Italian](./content/it/README.md) | [Ukrainian](./content/uk/README.md) | +| [Japanese](./content/ja/README.md) | [Vietnamese](./content/vi/README.md) | ## Code of conduct diff --git a/content/fa/OWNERS b/content/fa/OWNERS new file mode 100644 index 0000000000000..a1d81af5d0858 --- /dev/null +++ b/content/fa/OWNERS @@ -0,0 +1,14 @@ +# See the OWNERS docs at https://go.k8s.io/owners + +# This is the localization project for Persian. +# Teams and members are visible at https://github.com/orgs/kubernetes/teams. + +reviewers: +- sig-docs-fa-reviews + +approvers: +- sig-docs-fa-owners + +labels: +- area/localization +- language/fa diff --git a/content/fa/README.md b/content/fa/README.md new file mode 100644 index 0000000000000..4982fabede783 --- /dev/null +++ b/content/fa/README.md @@ -0,0 +1,133 @@ +‫ +# مستندات فارسی کوبرنتیز + +‫ +[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-main-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest) + + +‫ +خوش آمدید! این مخزن شامل محتویات لازم برای ساخت [تارنما کوبرنتیز فارسی و مستندات](https://kubernetes.io/fa/) آن است. خوشحال می‌شویم که در این مسیر با مشارکت کردن ما را همراهی کنید. + +‫ +## نحوه مشارکت کردن در مستندسازی + +‫ +شما می‌توانید روی دکمه‌ی **Fork** در گوشه‌ی سمت راست بالای صفحه کلیک کنید تا یک رونوشت از این مخزن در حساب گیت‌هاب خود ایجاد کنید. این رونوشت *fork* نامیده می‌شود. تغییرات دلخواه را در fork خود اعمال کنید. وقتی آماده‌ی ارسال آن تغییرات به ما شدید، به fork خود بروید و یک درخواست ادغام جدید ایجاد کنید و به ما اطلاع دهید. + +‫ +پس از ایجاد درخواست ادغام از سمت شما، فرد بررسی‌کننده تیم مستندات فارسی کوبرنتیز مسئولیت ارائه بازخورد و بررسی درخواست شما را بر عهده می‌گیرد. به عنوان صاحب درخواست ادغام، مسئولیت اصلاح درخواست ادغام بر اساس بازخوردی که از بررسی‌کننده تیم مستندات فارسی کوبرنتیز دریافت می‌کنید، بر عهده شماست. همچنین، توجه داشته باشید که ممکن است در نهایت بیش از یک بررسی‌کننده بازخورد ارائه دهند، یا ممکن است از فرد بررسی‌کننده جدید و متفاوت از کسی که در ابتدا برای ارائه بازخورد تعیین شده بود، بازخورد دریافت کنید. در برخی موارد، در صورت نیاز، یکی از بررسی‌کنندگان شما ممکن است از یک [بررسی‌کننده فنی کوبرنتیز](https://github.com/kubernetes/website/wiki/tech-reviewers) درخواست بررسی فنی کند. بررسی‌کنندگان تمام تلاش خود را می‌کنند تا بازخوردها را به موقع ارائه دهند، اما زمان پاسخگویی بسته به شرایط ممکن است متفاوت باشد. + +‫ +برای اطلاعات بیشتر در مورد مشارکت در مستندسازی کوبرنتیز به فارسی به لینک‌های زیر مراجعه کنید: + +‫ +* [شروع مشارکت](https://kubernetes.io/fa/docs/contribute/start/) +‫ +* [انواع محتوای صفحه](https://kubernetes.io/fa/docs/contribute/style/page-content-types/) +‫ +* [راهنمای سبک مستندسازی](https://kubernetes.io/fa/docs/contribute/style/style-guide/) +‫ +* [بومی‌سازی مستندات کوبرنتیز](https://kubernetes.io/fa/docs/contribute/localization/) + +‫ +## مستندات بومی‌سازی کوبرنتیز در `README.md` + +‫ +### فارسی +‫ +با تیم بومی سازی فارسی می‌توان از طریق آدرس‌های زیر در ارتباط باشید: +‫ +* محمدامین طاهری ([@xirehat](https://github.com/xirehat)) +‫ +* محمد زارعی ([@moh0ps](https://github.com/moh0ps)) +‫ +* به‌دین طالبی ([@behiuu](https://github.com/behiuu)) +‫ +* محمدرضا بهفر ([@mamrezb](https://github.com/mamrezb)) +‫ +* [کانال Slack](https://kubernetes.slack.com/messages/kubernetes-docs-fa) + +‫ +## اجرای تارنما با Docker + +‫ +برای اجرای تارنما کوبرنتیز، توصیه می‌شود آن را با [Docker](https://docker.com) اجرا کنید که شامل مولد تارنما استاتیک [Hugo](https://gohugo.io) باشد. + +‫ +> در ویندوز، به ابزارهای اضافی نیاز دارید که می‌توانید با [Chocolatey] (https://chocolatey.org) نصب کنید. +`choco install make` + +‫ +> اگر ترجیح می‌دهید تارنما را بدون داکر اجرا کنید، به [اجرای تارنما با هوگو](#اجرای-تارنما-با-هوگو) مراجعه کنید. + +‫ +قالب مورد نیاز [Docsy Hugo theme](https://github.com/google/docsy#readme) باید به عنوان یک زیرماژول git نصب شود: + +``` +git submodule update --init --recursive --depth 1 +``` + +‫ +اگر داکر را نصب کرده‌اید، image داکر `hugo` را ایجاد کنید: + +```bash +make container-image +``` + +‫ +پس از ایجاد image، می‌توانید تارنما را راه اندازی کنید: + +```bash +make container-serve +``` + +‫ +برای مشاهده تارنما، مرورگر خود را با نشانی http://localhost:1313 باز کنید. وقتی تغییراتی در پرونده‌های منبع ایجاد می‌کنید، Hugo تارنما را به‌روزرسانی کرده و مرورگر را مجبور به فراخوانی مجدد می‌کند. + +‫ +## اجرای تارنما با هوگو + +‫ +دستورالعمل‌های نصب Hugo را می‌توانید در [مستندات رسمی](https://gohugo.io/installation/) بیابید. مطمئن شوید که نسخه Hugo مشخص شده در متغیر محیطی `HUGO_VERSION` در فایل `netlify.toml` را نصب می‌کنید. + +‫ +قالب مورد نیاز [Docsy Hugo theme](https://github.com/google/docsy#readme) باید به عنوان یک زیرماژول git نصب شود: + +``` +git submodule update --init --recursive --depth 1 +``` + +‫ +برای اجرای تارنما در صورتی که Hugo را نصب کرده‌اید: + +```bash +npm ci +make serve +``` + +‫ +برای مشاهده تارنما، مرورگر خود را با نشانی http://localhost:1313 باز کنید. وقتی تغییراتی در پرونده‌های منبع ایجاد می‌کنید، Hugo تارنما را به‌روزرسانی کرده و مرورگر را مجبور به فراخوانی مجدد می‌کند. + +‫ +## جامعه، بحث، مشارکت و حمایت + +‫ +برای آشنایی با نحوه تعامل با انجمن کوبرنتیز به [صفحه انجمن](https://kubernetes.io/community/) مراجعه کنید. + +‫ +برای ارتباط با سرپرستان این پروژه می‌توانید از طریق نشانی زیر اقدام کنید: + +- [Slack](https://kubernetes.slack.com/messages/sig-docs) +- [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) + +‫ +### قوانین رفتاری + +‫ +مشارکت در جامعه کوبرنتیز تابع [قوانین رفتاری کوبرنتیز](https://github.com/kubernetes/website/blob/main/code-of-conduct.md) است. + +‫ +## سپاس گزاریم + +‫ +کوبرنتیز با مشارکت جامعه رونق می‌گیرد و ما از مشارکت‌های شما در تارنما و مستندات کوبرنتیز فارسی استقبال می‌کنیم. دمتون گرم! \ No newline at end of file diff --git a/content/fa/_common-resources/images/blocks.svg b/content/fa/_common-resources/images/blocks.svg new file mode 100644 index 0000000000000..a129531bec868 --- /dev/null +++ b/content/fa/_common-resources/images/blocks.svg @@ -0,0 +1 @@ +kubernetes_icons \ No newline at end of file diff --git a/content/fa/_common-resources/images/flower.svg b/content/fa/_common-resources/images/flower.svg new file mode 100644 index 0000000000000..fd287a8889c7e --- /dev/null +++ b/content/fa/_common-resources/images/flower.svg @@ -0,0 +1 @@ +kubernetes_icons \ No newline at end of file diff --git a/content/fa/_common-resources/images/kub_video_banner_homepage.jpg b/content/fa/_common-resources/images/kub_video_banner_homepage.jpg new file mode 100644 index 0000000000000..e40d92a50363b Binary files /dev/null and b/content/fa/_common-resources/images/kub_video_banner_homepage.jpg differ diff --git a/content/fa/_common-resources/images/scalable.svg b/content/fa/_common-resources/images/scalable.svg new file mode 100644 index 0000000000000..d8c475146e1cc --- /dev/null +++ b/content/fa/_common-resources/images/scalable.svg @@ -0,0 +1 @@ +kubernetes_icons \ No newline at end of file diff --git a/content/fa/_common-resources/images/suitcase.svg b/content/fa/_common-resources/images/suitcase.svg new file mode 100644 index 0000000000000..2393fa8bcb14e --- /dev/null +++ b/content/fa/_common-resources/images/suitcase.svg @@ -0,0 +1 @@ +kubernetes_icons \ No newline at end of file diff --git a/content/fa/_common-resources/index.md b/content/fa/_common-resources/index.md new file mode 100644 index 0000000000000..ca03031f1ee91 --- /dev/null +++ b/content/fa/_common-resources/index.md @@ -0,0 +1,3 @@ +--- +headless: true +--- diff --git a/content/fa/_index.html b/content/fa/_index.html new file mode 100644 index 0000000000000..fb2538a22dad0 --- /dev/null +++ b/content/fa/_index.html @@ -0,0 +1,62 @@ +--- +title: "مدیریت کانتینر در محیط عملیاتی" +abstract: "استقرار، مقیاس‌بندی و مدیریت خودکار کانتینر" +cid: home +sitemap: + priority: 1.0 +--- + +{{< blocks/section class="k8s-overview" >}} +{{% blocks/feature image="flower" id="feature-primary" %}} +[کوبرنتیز]({{< relref "/docs/concepts/overview/" >}}), که با نام K8s نیز شناخته می‌شود، یک سامانه متن‌باز برای خودکارسازی استقرار، مقیاس‌بندی و مدیریت برنامه‌های کانتینری است. + +این سامانه، کانتینرهایی را که یک برنامه را تشکیل می‌دهند، برای مدیریت و کشف آسان، در واحدهای منطقی گروه‌بندی می‌کند. کوبرنتیز بر اساس [۱۵ سال تجربه در اجرای برنامه‌های عملیاتی در گوگل](https://queue.acm.org/detail.cfm?id=2898444) و با ترکیب بهترین ایده‌ها و شیوه‌های جامعه ساخته شده است. +{{% /blocks/feature %}} + +{{% blocks/feature image="scalable" %}} +#### مقیاس سیاره + +کوبرنتیز که بر اساس همان اصولی طراحی شده است که به گوگل اجازه می‌دهد میلیاردها کانتینر را در هفته اجرا کند، می‌تواند بدون افزایش تیم عملیاتی شما، مقیاس‌پذیر شود. + +{{% /blocks/feature %}} + +{{% blocks/feature image="blocks" %}} +#### از بزرگ شدن نترس + +چه یک سازمان کوچک و چه یک سازمان با مقیاس جهانی را اداره کنید، انعطاف‌پذیری کوبرنتیز با شما رشد می‌کند تا برنامه‌های شما را به طور مداوم و آسان، صرف نظر از پیچیدگی نیازتان، ارائه دهد. + +{{% /blocks/feature %}} + +{{% blocks/feature image="suitcase" %}} +#### کوبرنتیز همه جا + +کوبرنتیز متن‌باز است و به شما آزادی عمل می‌دهد تا از زیرساخت‌های ابری داخلی، ترکیبی یا عمومی بهره ببرید و به شما امکان می‌دهد بدون دردسر برنامه‌ها را به جایی که برایتان مهم است منتقل کنید. + +برای دانلود کوبرنتیز، به بخش [دانلود](/releases/download/) مراجعه کنید. + +{{% /blocks/feature %}} + +{{< /blocks/section >}} + +{{< blocks/section id="video" background-image="kub_video_banner_homepage" >}} +
+

چالش‌های مهاجرت بیش از ۱۵۰ میکروسرویس به کوبرنتیز

+

نوشته Sarah Wells، راهبر فنی عملیات و پایایی در Financial Times

+ + +

در رویدادهای آینده KubeCon + CloudNativeCon شرکت کنید

+ هند (حیدرآباد، ۶ و ۷ اوت) + آمریکا شمالی (آتلانتا، ۱۰ تا ۱۳ نوامبر) + اروپا (آمستردام، ۲۳ تا ۲۶ مارس ۲۰۲۶) +
+
+ + +
+{{< /blocks/section >}} + +{{< blocks/kubernetes-features >}} + +{{< blocks/case-studies >}} + +{{< kubeweekly id="kubeweekly" >}} diff --git a/content/fa/case-studies/_index.html b/content/fa/case-studies/_index.html new file mode 100644 index 0000000000000..d34b330e87c69 --- /dev/null +++ b/content/fa/case-studies/_index.html @@ -0,0 +1,14 @@ +--- +title: مطالعات موردی +linkTitle: مطالعات موردی +bigheader: مطالعات موردی کاربران کوبرنتیز +abstract: مجموعه‌ای از کاربران که کوبرنتیز را در محیط عملیاتی اجرا می‌کنند. +layout: basic +class: gridPage +body_class: caseStudies +cid: caseStudies +menu: + main: + weight: 60 +--- + diff --git a/content/fa/community/_index.html b/content/fa/community/_index.html new file mode 100644 index 0000000000000..6cb601f969f61 --- /dev/null +++ b/content/fa/community/_index.html @@ -0,0 +1,191 @@ +--- +title: جامعه +layout: basic +body_class: community +cid: community +community_styles_migrated: true +menu: + main: + weight: 50 +--- + + +
+

جامعه کوبرنتیز - کاربران، مشارکت‌کنندگان و فرهنگی که + ما با هم ساخته‌ایم - یکی از بزرگترین دلایل رشد سریع این + پروژه متن‌باز است. فرهنگ و ارزش‌های ما همچنان با رشد و تغییر + خود پروژه، در حال رشد و تغییر هستند. همه ما با هم + برای بهبود مداوم پروژه و روش‌های کار بر روی آن تلاش می‌کنیم.

+

ما افرادی هستیم که مسائل را ثبت و درخواست‌ها را بررسی می‌کنیم، در جلسات SIG، + گردهمایی‌های کوبرنتیز و KubeCon شرکت می‌کنیم، از پذیرش و نوآوری آن حمایت می‌کنیم، + kubectl get pods را اجرا می‌کنیم و به هزاران روش حیاتی دیگر مشارکت می‌کنیم. + برای یادگیری نحوه مشارکت و عضویت در این جامعه شگفت‌انگیز، ادامه مطلب را بخوانید.

+
+ + + + + +
+

ارزش‌های جامعه

+

ارزش‌های جامعه کوبرنتیز سنگ بنای موفقیت مداوم این پروژه هستند.
+ این اصول، هر جنبه‌ای از پروژه کوبرنتیز را هدایت می‌کنند.

+ + ادامه مطلب + +
+ +
+

آیین‌نامه رفتاری

+

جامعه‌ی کوبرنتیز برای احترام و شمول ارزش قائل است و در تمام تعاملات، یک آیین‌نامه‌ی رفتاری را اجرا می‌کند.

+

اگر در یک رویداد یا جلسه، در Slack یا از طریق هر سازوکار ارتباطی دیگری متوجه نقض «آیین‌نامه رفتاری» شدید، با کمیته آیین‌نامه رفتاری کوبرنتیز از طریق conduct@kubernetes.io تماس بگیرید. تمام گزارش‌ها محرمانه می‌مانند. می‌توانید درباره کمیته در مخزن جامعه کوبرنتیز روی گیت‌هاب مطالعه کنید.

+ + بیشتر بخوانید + +
+ +
+

ویدیوها

+ +

کوبرنتیز در یوتیوب خیلی فعال هست، برای طیف وسیعی از موضوعات آن را دنبال کنید.

+ +
+
+ + + ◀ ساعات اداری ماهانه را تماشا کنید + +
+ +
+ + + ◀ جلسات هفتگی انجمن را تماشا کنید + +
+ + +
+
+ +
+

بحث‌ها

+ +

ما زیاد صحبت می‌کنیم. ما را پیدا کنید و در هر یک از این بُن‌سازه‌ها به گفتگو بپیوندید.

+ +
+
+ + Forum + + ◀ انجمن‌های اجتماعی +

بحث‌های فنی موضوعی که اسناد، عیب‌یابی و موارد دیگر را به هم پیوند می‌دهد.

+
+ +
+ + Bluesky + + ◀ Bluesky +

@kubernetes.io

+

اطلاعیه‌های بلادرنگ مطالب وبلاگ، رویدادها، اخبار، ایده‌ها.

+
+ +
+ + GitHub + + ◀ GitHub +

تمام ردیابی پروژه و مشکلات، به علاوه کدهای مربوط به دوره.

+
+ +
+ + Server Fault + + ◀ Server Fault +

بحث‌های مربوط به کوبرنتیز در Server Fault. سوالی بپرسید یا به سوالی پاسخ دهید.

+
+ +
+ + Slack + + ◀ Slack +

با بیش از ۱۷۰ کانال، کانالی را پیدا خواهید کرد که متناسب با نیازهای شما باشد.

+
دعوتنامه لازم داری؟ + برای دریافت دعوتنامه به این صفحه https://slack.k8s.io/ + مراجعه کنید.
+
+ +
+ + X + + ◀ 𝕏 +

@kubernetesio

+

اطلاعیه‌های بلادرنگ پست‌های وبلاگ، رویدادها، اخبار، ایده‌ها.

+
+
+
+ + +
+

جامعه جهانی

+

+ با بیش از ۱۵۰ گردهمایی در جهان که همچنان در حال افزایش است، به دنبال افراد محلی علاقه‌مند به کوبرنتیز بگردید. اگر کسی در نزدیکی شما نیست، مسئولیت را به عهده بگیرید و گردهمایی خودتان را ایجاد کنید. +

+ + یک جلسه ملاقات پیدا کنید + +
+ +
+

آخرین اخبار

+
+ +
+
diff --git a/content/fa/community/code-of-conduct.md b/content/fa/community/code-of-conduct.md new file mode 100644 index 0000000000000..d66e5174817f6 --- /dev/null +++ b/content/fa/community/code-of-conduct.md @@ -0,0 +1,23 @@ +--- +title: آیین‌نامه رفتاری انجمن کوبرنتیز +body_class: code-of-conduct +cid: code-of-conduct +--- + +_کوبرنتیز از +[آیین‌نامه رفتاری CNCF](https://github.com/cncf/foundation/blob/main/code-of-conduct.md) پیروی می‌کند. +متن آیین‌نامه رفتاری CNCF در زیر آمده است +[commit 71412bb02](https://github.com/cncf/foundation/blob/71412bb029090d42ecbeadb39374a337bfb48a9c/code-of-conduct.md)._ + +
+{{< include "static/cncf-code-of-conduct.md" >}} +
+ +--- + +اگر در یک رویداد یا جلسه، در Slack یا در هر سازوکار ارتباطی دیگری متوجه نقض آیین‌نامه رفتاری شدید، با [کمیته آیین نامه کوبرنتیز](https://git.k8s.io/community/committee-code-of-conduct) تماس بگیرید. + +می‌توانید از طریق این ایمیل [conduct@kubernetes.io](mailto:conduct@kubernetes.io) با آنها در ارتباط باشید. +تمام گزارش‌ها محرمانه می‌مانند. + +اگر متوجه شدید که این صفحه قدیمی است، لطفاً [درخواست رسیدگی به مشکل را ثبت کنید](https://github.com/kubernetes/website/issues/new/choose). diff --git a/content/fa/docs/OWNERS b/content/fa/docs/OWNERS new file mode 100644 index 0000000000000..457d6276563be --- /dev/null +++ b/content/fa/docs/OWNERS @@ -0,0 +1,9 @@ +# See the OWNERS docs at https://go.k8s.io/owners + +# Teams and members are visible at https://github.com/orgs/kubernetes/teams. + +reviewers: +- sig-docs-fa-reviews + +approvers: +- sig-docs-fa-owners diff --git a/content/fa/docs/_index.md b/content/fa/docs/_index.md new file mode 100644 index 0000000000000..832ab12d8b77d --- /dev/null +++ b/content/fa/docs/_index.md @@ -0,0 +1,6 @@ +--- +linktitle: مستندات کوبرنتیز +title: مستندات +sitemap: + priority: 1.0 +--- diff --git a/content/fa/docs/concepts/_index.md b/content/fa/docs/concepts/_index.md new file mode 100644 index 0000000000000..8002b9e83aa37 --- /dev/null +++ b/content/fa/docs/concepts/_index.md @@ -0,0 +1,12 @@ +--- +title: مفاهیم +main_menu: true +content_type: concept +weight: 40 +--- + + + +بخش مفاهیم به شما کمک می‌کند تا درباره بخش‌های سیستم کوبرنتیز و انتزاع‌هایی که کوبرنتیز برای نمایش {{< glossary_tooltip text="خوشه" term_id="cluster" length="all" >}} شما به کار می‌برد بیاموزید، و همچنین کمک می‌کند درک عمیق‌تری از نحوه کار کوبرنتیز به دست آورید. + + diff --git a/content/fa/docs/concepts/architecture/self-healing.md b/content/fa/docs/concepts/architecture/self-healing.md new file mode 100644 index 0000000000000..11b24b749eba2 --- /dev/null +++ b/content/fa/docs/concepts/architecture/self-healing.md @@ -0,0 +1,49 @@ +--- +title: خودترمیمی کوبرنتیز +content_type: concept +weight: 50 +feature: + title: خودترمیمی + anchor: بازیابی خودکار از آسیب + description: > + کوبرنتیز کانتینرهایی که از کار می‌افتند را مجدداً راه‌اندازی می‌کند، در صورت نیاز کل Podها را جایگزین می‌کند، در پاسخ به خرابی‌های گسترده‌تر، فضای ذخیره‌سازی را دوباره متصل می‌کند و می‌تواند با مقیاس‌پذیرهای خودکار گره ادغام شود تا حتی در سطح گره نیز خود را ترمیم کند. +--- + + +کوبرنتیز با قابلیت‌های خودترمیمی طراحی شده است که به حفظ سلامت و در دسترس بودن بارهای کاری کمک می‌کند. این سیستم به طور خودکار کانتینرهای خراب را جایگزین می‌کند، بارهای کاری را در صورت از دسترس خارج شدن گره‌ها مجدداً برنامه‌ریزی می‌کند و تضمین می‌کند که وضعیت مطلوب سیستم حفظ شود. + + + +## Self-Healing capabilities {#self-healing-capabilities} + +- **Container-level restarts:** If a container inside a Pod fails, Kubernetes restarts it based on the [`restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy). + +- **Replica replacement:** If a Pod in a [Deployment](/docs/concepts/workloads/controllers/deployment/) or [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) fails, Kubernetes creates a replacement Pod to maintain the specified number of replicas. + If a Pod fails that is part of a [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) fails, the control plane + creates a replacement Pod to run on the same node. + +- **Persistent storage recovery:** If a node is running a Pod with a PersistentVolume (PV) attached, and the node fails, Kubernetes can reattach the volume to a new Pod on a different node. + +- **Load balancing for Services:** If a Pod behind a [Service](/docs/concepts/services-networking/service/) fails, Kubernetes automatically removes it from the Service's endpoints to route traffic only to healthy Pods. + +Here are some of the key components that provide Kubernetes self-healing: + +- **[kubelet](/docs/concepts/architecture/#kubelet):** Ensures that containers are running, and restarts those that fail. + +- **ReplicaSet, StatefulSet and DaemonSet controller:** Maintains the desired number of Pod replicas. + +- **PersistentVolume controller:** Manages volume attachment and detachment for stateful workloads. + +## Considerations {#considerations} + +- **Storage Failures:** If a persistent volume becomes unavailable, recovery steps may be required. + +- **Application Errors:** Kubernetes can restart containers, but underlying application issues must be addressed separately. + +## {{% heading "whatsnext" %}} + +- Read more about [Pods](/docs/concepts/workloads/pods/) +- Learn about [Kubernetes Controllers](/docs/concepts/architecture/controller/) +- Explore [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) +- Read about [node autoscaling](/docs/concepts/cluster-administration/node-autoscaling/). Node autoscaling + also provides automatic healing if or when nodes fail in your cluster. \ No newline at end of file diff --git a/content/fa/docs/concepts/configuration/manage-resources-containers.md b/content/fa/docs/concepts/configuration/manage-resources-containers.md new file mode 100644 index 0000000000000..91bda75250669 --- /dev/null +++ b/content/fa/docs/concepts/configuration/manage-resources-containers.md @@ -0,0 +1,935 @@ +--- +title: مدیریت منابع برای پادها و کانتینرها +content_type: concept +weight: 40 +feature: + title: بسته بندی سطل زباله اتوماتیک + description: > + کانتینرها را به طور خودکار بر اساس الزامات منابع و سایر محدودیت‌ها قرار می‌دهد، در حالی که دسترسی‌پذیری را فدا نمی‌کند. بارهای کاری بحرانی و بهترین تلاش را با هم ترکیب می‌کند تا میزان استفاده را افزایش داده و منابع بیشتری را ذخیره کند. +--- + + + +When you specify a {{< glossary_tooltip term_id="pod" >}}, you can optionally specify how much of each resource a +{{< glossary_tooltip text="container" term_id="container" >}} needs. The most common resources to specify are CPU and memory +(RAM); there are others. + +When you specify the resource _request_ for containers in a Pod, the +{{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}} uses this information to decide which node to place the Pod on. +When you specify a resource _limit_ for a container, the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} enforces those +limits so that the running container is not allowed to use more of that resource +than the limit you set. The kubelet also reserves at least the _request_ amount of +that system resource specifically for that container to use. + + + +## Requests and limits + +If the node where a Pod is running has enough of a resource available, it's possible (and +allowed) for a container to use more resource than its `request` for that resource specifies. + +For example, if you set a `memory` request of 256 MiB for a container, and that container is in +a Pod scheduled to a Node with 8GiB of memory and no other Pods, then the container can try to use +more RAM. + +Limits are a different story. Both `cpu` and `memory` limits are applied by the kubelet (and +{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}), +and are ultimately enforced by the kernel. On Linux nodes, the Linux kernel +enforces limits with +{{< glossary_tooltip text="cgroups" term_id="cgroup" >}}. +The behavior of `cpu` and `memory` limit enforcement is slightly different. + +`cpu` limits are enforced by CPU throttling. When a container approaches +its `cpu` limit, the kernel will restrict access to the CPU corresponding to the +container's limit. Thus, a `cpu` limit is a hard limit the kernel enforces. +Containers may not use more CPU than is specified in their `cpu` limit. + +`memory` limits are enforced by the kernel with out of memory (OOM) kills. When +a container uses more than its `memory` limit, the kernel may terminate it. However, +terminations only happen when the kernel detects memory pressure. Thus, a +container that over allocates memory may not be immediately killed. This means +`memory` limits are enforced reactively. A container may use more memory than +its `memory` limit, but if it does, it may get killed. + +{{< note >}} +There is an alpha feature `MemoryQoS` which attempts to add more preemptive +limit enforcement for memory (as opposed to reactive enforcement by the OOM +killer). However, this effort is +[stalled](https://github.com/kubernetes/enhancements/tree/a47155b340/keps/sig-node/2570-memory-qos#latest-update-stalled) +due to a potential livelock situation a memory hungry can cause. +{{< /note >}} + +{{< note >}} +If you specify a limit for a resource, but do not specify any request, and no admission-time +mechanism has applied a default request for that resource, then Kubernetes copies the limit +you specified and uses it as the requested value for the resource. +{{< /note >}} + +## Resource types + +*CPU* and *memory* are each a *resource type*. A resource type has a base unit. +CPU represents compute processing and is specified in units of [Kubernetes CPUs](#meaning-of-cpu). +Memory is specified in units of bytes. +For Linux workloads, you can specify _huge page_ resources. +Huge pages are a Linux-specific feature where the node kernel allocates blocks of memory +that are much larger than the default page size. + +For example, on a system where the default page size is 4KiB, you could specify a limit, +`hugepages-2Mi: 80Mi`. If the container tries allocating over 40 2MiB huge pages (a +total of 80 MiB), that allocation fails. + +{{< note >}} +You cannot overcommit `hugepages-*` resources. +This is different from the `memory` and `cpu` resources. +{{< /note >}} + +CPU and memory are collectively referred to as *compute resources*, or *resources*. Compute +resources are measurable quantities that can be requested, allocated, and +consumed. They are distinct from +[API resources](/docs/concepts/overview/kubernetes-api/). API resources, such as Pods and +[Services](/docs/concepts/services-networking/service/) are objects that can be read and modified +through the Kubernetes API server. + +## Resource requests and limits of Pod and container + +For each container, you can specify resource limits and requests, +including the following: + +* `spec.containers[].resources.limits.cpu` +* `spec.containers[].resources.limits.memory` +* `spec.containers[].resources.limits.hugepages-` +* `spec.containers[].resources.requests.cpu` +* `spec.containers[].resources.requests.memory` +* `spec.containers[].resources.requests.hugepages-` + +Although you can only specify requests and limits for individual containers, +it is also useful to think about the overall resource requests and limits for +a Pod. +For a particular resource, a *Pod resource request/limit* is the sum of the +resource requests/limits of that type for each container in the Pod. + +## Pod-level resource specification + +{{< feature-state feature_gate_name="PodLevelResources" >}} + +Starting in Kubernetes 1.32, you can also specify resource requests and limits at +the Pod level. At the Pod level, Kubernetes {{< skew currentVersion >}} +only supports resource requests or limits for specific resource types: `cpu` and / +or `memory`. This feature is currently in alpha and with the feature enabled, +Kubernetes allows you to declare an overall resource budget for the Pod, which is +especially helpful when dealing with a large number of containers where it can be +difficult to accurately gauge individual resource needs. Additionally, it enables +containers within a Pod to share idle resources with each other, improving resource +utilization. + +For a Pod, you can specify resource limits and requests for CPU and memory by including the following: +* `spec.resources.limits.cpu` +* `spec.resources.limits.memory` +* `spec.resources.requests.cpu` +* `spec.resources.requests.memory` + +## Resource units in Kubernetes + +### CPU resource units {#meaning-of-cpu} + +Limits and requests for CPU resources are measured in *cpu* units. +In Kubernetes, 1 CPU unit is equivalent to **1 physical CPU core**, +or **1 virtual core**, depending on whether the node is a physical host +or a virtual machine running inside a physical machine. + +Fractional requests are allowed. When you define a container with +`spec.containers[].resources.requests.cpu` set to `0.5`, you are requesting half +as much CPU time compared to if you asked for `1.0` CPU. +For CPU resource units, the [quantity](/docs/reference/kubernetes-api/common-definitions/quantity/) expression `0.1` is equivalent to the +expression `100m`, which can be read as "one hundred millicpu". Some people say +"one hundred millicores", and this is understood to mean the same thing. + +CPU resource is always specified as an absolute amount of resource, never as a relative amount. For example, +`500m` CPU represents the roughly same amount of computing power whether that container +runs on a single-core, dual-core, or 48-core machine. + +{{< note >}} +Kubernetes doesn't allow you to specify CPU resources with a precision finer than +`1m` or `0.001` CPU. To avoid accidentally using an invalid CPU quantity, it's useful to specify CPU units using the milliCPU form +instead of the decimal form when using less than 1 CPU unit. + +For example, you have a Pod that uses `5m` or `0.005` CPU and would like to decrease +its CPU resources. By using the decimal form, it's harder to spot that `0.0005` CPU +is an invalid value, while by using the milliCPU form, it's easier to spot that +`0.5m` is an invalid value. +{{< /note >}} + +### Memory resource units {#meaning-of-memory} + +Limits and requests for `memory` are measured in bytes. You can express memory as +a plain integer or as a fixed-point number using one of these +[quantity](/docs/reference/kubernetes-api/common-definitions/quantity/) suffixes: +E, P, T, G, M, k. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi, +Mi, Ki. For example, the following represent roughly the same value: + +```shell +128974848, 129e6, 129M, 128974848000m, 123Mi +``` + +Pay attention to the case of the suffixes. If you request `400m` of memory, this is a request +for 0.4 bytes. Someone who types that probably meant to ask for 400 mebibytes (`400Mi`) +or 400 megabytes (`400M`). + +## Container resources example {#example-1} + +The following Pod has two containers. Both containers are defined with a request for +0.25 CPU +and 64MiB (226 bytes) of memory. Each container has a limit of 0.5 +CPU and 128MiB of memory. You can say the Pod has a request of 0.5 CPU and 128 +MiB of memory, and a limit of 1 CPU and 256MiB of memory. + +```yaml +--- +apiVersion: v1 +kind: Pod +metadata: + name: frontend +spec: + containers: + - name: app + image: images.my-company.example/app:v4 + resources: + requests: + memory: "64Mi" + cpu: "250m" + limits: + memory: "128Mi" + cpu: "500m" + - name: log-aggregator + image: images.my-company.example/log-aggregator:v6 + resources: + requests: + memory: "64Mi" + cpu: "250m" + limits: + memory: "128Mi" + cpu: "500m" +``` + +## Pod resources example {#example-2} + +{{< feature-state feature_gate_name="PodLevelResources" >}} + +This feature can be enabled by setting the `PodLevelResources` +[feature gate](/docs/reference/command-line-tools-reference/feature-gates). +The following Pod has an explicit request of 1 CPU and 100 MiB of memory, and an +explicit limit of 1 CPU and 200 MiB of memory. The `pod-resources-demo-ctr-1` +container has explicit requests and limits set. However, the +`pod-resources-demo-ctr-2` container will simply share the resources available +within the Pod resource boundaries, as it does not have explicit requests and limits +set. + +{{% code_sample file="pods/resource/pod-level-resources.yaml" %}} + +## How Pods with resource requests are scheduled + +When you create a Pod, the Kubernetes scheduler selects a node for the Pod to +run on. Each node has a maximum capacity for each of the resource types: the +amount of CPU and memory it can provide for Pods. The scheduler ensures that, +for each resource type, the sum of the resource requests of the scheduled +containers is less than the capacity of the node. +Note that although actual memory +or CPU resource usage on nodes is very low, the scheduler still refuses to place +a Pod on a node if the capacity check fails. This protects against a resource +shortage on a node when resource usage later increases, for example, during a +daily peak in request rate. + +## How Kubernetes applies resource requests and limits {#how-pods-with-resource-limits-are-run} + +When the kubelet starts a container as part of a Pod, the kubelet passes that container's +requests and limits for memory and CPU to the container runtime. + +On Linux, the container runtime typically configures +kernel {{< glossary_tooltip text="cgroups" term_id="cgroup" >}} that apply and enforce the +limits you defined. + +- The CPU limit defines a hard ceiling on how much CPU time the container can use. + During each scheduling interval (time slice), the Linux kernel checks to see if this + limit is exceeded; if so, the kernel waits before allowing that cgroup to resume execution. +- The CPU request typically defines a weighting. If several different containers (cgroups) + want to run on a contended system, workloads with larger CPU requests are allocated more + CPU time than workloads with small requests. +- The memory request is mainly used during (Kubernetes) Pod scheduling. On a node that uses + cgroups v2, the container runtime might use the memory request as a hint to set + `memory.min` and `memory.low`. +- The memory limit defines a memory limit for that cgroup. If the container tries to + allocate more memory than this limit, the Linux kernel out-of-memory subsystem activates + and, typically, intervenes by stopping one of the processes in the container that tried + to allocate memory. If that process is the container's PID 1, and the container is marked + as restartable, Kubernetes restarts the container. +- The memory limit for the Pod or container can also apply to pages in memory backed + volumes, such as an `emptyDir`. The kubelet tracks `tmpfs` emptyDir volumes as container + memory use, rather than as local ephemeral storage.　When using memory backed `emptyDir`, + be sure to check the notes [below](#memory-backed-emptydir). + +If a container exceeds its memory request and the node that it runs on becomes short of +memory overall, it is likely that the Pod the container belongs to will be +{{< glossary_tooltip text="evicted" term_id="eviction" >}}. + +A container might or might not be allowed to exceed its CPU limit for extended periods of time. +However, container runtimes don't terminate Pods or containers for excessive CPU usage. + +To determine whether a container cannot be scheduled or is being killed due to resource limits, +see the [Troubleshooting](#troubleshooting) section. + +### Monitoring compute & memory resource usage + +The kubelet reports the resource usage of a Pod as part of the Pod +[`status`](/docs/concepts/overview/working-with-objects/#object-spec-and-status). + +If optional [tools for monitoring](/docs/tasks/debug/debug-cluster/resource-usage-monitoring/) +are available in your cluster, then Pod resource usage can be retrieved either +from the [Metrics API](/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/#metrics-api) +directly or from your monitoring tools. + +### Considerations for memory backed `emptyDir` volumes {#memory-backed-emptydir} + +{{< caution >}} +If you do not specify a `sizeLimit` for an `emptyDir` volume, that volume may +consume up to that pod's memory limit (`Pod.spec.containers[].resources.limits.memory`). +If you do not set a memory limit, the pod has no upper bound on memory consumption, +and can consume all available memory on the node. Kubernetes schedules pods based +on resource requests (`Pod.spec.containers[].resources.requests`) and will not +consider memory usage above the request when deciding if another pod can fit on +a given node. This can result in a denial of service and cause the OS to do +out-of-memory (OOM) handling. It is possible to create any number of `emptyDir`s +that could potentially consume all available memory on the node, making OOM +more likely. +{{< /caution >}} + +From the perspective of memory management, there are some similarities between +when a process uses memory as a work area and when using memory-backed +`emptyDir`. But when using memory as a volume, like memory-backed `emptyDir`, +there are additional points below that you should be careful of: + +* Files stored on a memory-backed volume are almost entirely managed by the + user application. Unlike when used as a work area for a process, you can not + rely on things like language-level garbage collection. +* The purpose of writing files to a volume is to save data or pass it between + applications. Neither Kubernetes nor the OS may automatically delete files + from a volume, so memory used by those files can not be reclaimed when the + system or the pod are under memory pressure. +* A memory-backed `emptyDir` is useful because of its performance, but memory + is generally much smaller in size and much higher in cost than other storage + media, such as disks or SSDs. Using large amounts of memory for `emptyDir` + volumes may affect the normal operation of your pod or of the whole node, + so should be used carefully. + +If you are administering a cluster or namespace, you can also set +[ResourceQuota](/docs/concepts/policy/resource-quotas/) that limits memory use; +you may also want to define a [LimitRange](/docs/concepts/policy/limit-range/) +for additional enforcement. +If you specify a `spec.containers[].resources.limits.memory` for each Pod, +then the maximum size of an `emptyDir` volume will be the pod's memory limit. + +As an alternative, a cluster administrator can enforce size limits for +`emptyDir` volumes in new Pods using a policy mechanism such as +[ValidationAdmissionPolicy](/docs/reference/access-authn-authz/validating-admission-policy). + +## Local ephemeral storage + + +{{< feature-state for_k8s_version="v1.25" state="stable" >}} + +Nodes have local ephemeral storage, backed by +locally-attached writeable devices or, sometimes, by RAM. +"Ephemeral" means that there is no long-term guarantee about durability. + +Pods use ephemeral local storage for scratch space, caching, and for logs. +The kubelet can provide scratch space to Pods using local ephemeral storage to +mount [`emptyDir`](/docs/concepts/storage/volumes/#emptydir) + {{< glossary_tooltip term_id="volume" text="volumes" >}} into containers. + +The kubelet also uses this kind of storage to hold +[node-level container logs](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level), +container images, and the writable layers of running containers. + +{{< caution >}} +If a node fails, the data in its ephemeral storage can be lost. +Your applications cannot expect any performance SLAs (disk IOPS for example) +from local ephemeral storage. +{{< /caution >}} + + +{{< note >}} +To make the resource quota work on ephemeral-storage, two things need to be done: + +* An admin sets the resource quota for ephemeral-storage in a namespace. +* A user needs to specify limits for the ephemeral-storage resource in the Pod spec. + +If the user doesn't specify the ephemeral-storage resource limit in the Pod spec, +the resource quota is not enforced on ephemeral-storage. + +{{< /note >}} + +Kubernetes lets you track, reserve and limit the amount +of ephemeral local storage a Pod can consume. + +### Configurations for local ephemeral storage + +Kubernetes supports two ways to configure local ephemeral storage on a node: +{{< tabs name="local_storage_configurations" >}} +{{% tab name="Single filesystem" %}} +In this configuration, you place all different kinds of ephemeral local data +(`emptyDir` volumes, writeable layers, container images, logs) into one filesystem. +The most effective way to configure the kubelet means dedicating this filesystem +to Kubernetes (kubelet) data. + +The kubelet also writes +[node-level container logs](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level) +and treats these similarly to ephemeral local storage. + +The kubelet writes logs to files inside its configured log directory (`/var/log` +by default); and has a base directory for other locally stored data +(`/var/lib/kubelet` by default). + +Typically, both `/var/lib/kubelet` and `/var/log` are on the system root filesystem, +and the kubelet is designed with that layout in mind. + +Your node can have as many other filesystems, not used for Kubernetes, +as you like. +{{% /tab %}} +{{% tab name="Two filesystems" %}} +You have a filesystem on the node that you're using for ephemeral data that +comes from running Pods: logs, and `emptyDir` volumes. You can use this filesystem +for other data (for example: system logs not related to Kubernetes); it can even +be the root filesystem. + +The kubelet also writes +[node-level container logs](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level) +into the first filesystem, and treats these similarly to ephemeral local storage. + +You also use a separate filesystem, backed by a different logical storage device. +In this configuration, the directory where you tell the kubelet to place +container image layers and writeable layers is on this second filesystem. + +The first filesystem does not hold any image layers or writeable layers. + +Your node can have as many other filesystems, not used for Kubernetes, +as you like. +{{% /tab %}} +{{< /tabs >}} + +The kubelet can measure how much local storage it is using. It does this provided +that you have set up the node using one of the supported configurations for local +ephemeral storage. + +If you have a different configuration, then the kubelet does not apply resource +limits for ephemeral local storage. + +{{< note >}} +The kubelet tracks `tmpfs` emptyDir volumes as container memory use, rather +than as local ephemeral storage. +{{< /note >}} + +{{< note >}} +The kubelet will only track the root filesystem for ephemeral storage. OS layouts that mount a separate disk to `/var/lib/kubelet` or `/var/lib/containers` will not report ephemeral storage correctly. +{{< /note >}} + +### Setting requests and limits for local ephemeral storage + +You can specify `ephemeral-storage` for managing local ephemeral storage. Each +container of a Pod can specify either or both of the following: + +* `spec.containers[].resources.limits.ephemeral-storage` +* `spec.containers[].resources.requests.ephemeral-storage` + +Limits and requests for `ephemeral-storage` are measured in byte quantities. +You can express storage as a plain integer or as a fixed-point number using one of these suffixes: +E, P, T, G, M, k. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi, +Mi, Ki. For example, the following quantities all represent roughly the same value: + +- `128974848` +- `129e6` +- `129M` +- `123Mi` + +Pay attention to the case of the suffixes. If you request `400m` of ephemeral-storage, this is a request +for 0.4 bytes. Someone who types that probably meant to ask for 400 mebibytes (`400Mi`) +or 400 megabytes (`400M`). + +In the following example, the Pod has two containers. Each container has a request of +2GiB of local ephemeral storage. Each container has a limit of 4GiB of local ephemeral +storage. Therefore, the Pod has a request of 4GiB of local ephemeral storage, and +a limit of 8GiB of local ephemeral storage. 500Mi of that limit could be +consumed by the `emptyDir` volume. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: frontend +spec: + containers: + - name: app + image: images.my-company.example/app:v4 + resources: + requests: + ephemeral-storage: "2Gi" + limits: + ephemeral-storage: "4Gi" + volumeMounts: + - name: ephemeral + mountPath: "/tmp" + - name: log-aggregator + image: images.my-company.example/log-aggregator:v6 + resources: + requests: + ephemeral-storage: "2Gi" + limits: + ephemeral-storage: "4Gi" + volumeMounts: + - name: ephemeral + mountPath: "/tmp" + volumes: + - name: ephemeral + emptyDir: + sizeLimit: 500Mi +``` + +### How Pods with ephemeral-storage requests are scheduled + +When you create a Pod, the Kubernetes scheduler selects a node for the Pod to +run on. Each node has a maximum amount of local ephemeral storage it can provide for Pods. +For more information, see +[Node Allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable). + +The scheduler ensures that the sum of the resource requests of the scheduled containers is less than the capacity of the node. + +### Ephemeral storage consumption management {#resource-emphemeralstorage-consumption} + +If the kubelet is managing local ephemeral storage as a resource, then the +kubelet measures storage use in: + +- `emptyDir` volumes, except _tmpfs_ `emptyDir` volumes +- directories holding node-level logs +- writeable container layers + +If a Pod is using more ephemeral storage than you allow it to, the kubelet +sets an eviction signal that triggers Pod eviction. + +For container-level isolation, if a container's writable layer and log +usage exceeds its storage limit, the kubelet marks the Pod for eviction. + +For pod-level isolation the kubelet works out an overall Pod storage limit by +summing the limits for the containers in that Pod. In this case, if the sum of +the local ephemeral storage usage from all containers and also the Pod's `emptyDir` +volumes exceeds the overall Pod storage limit, then the kubelet also marks the Pod +for eviction. + +{{< caution >}} +If the kubelet is not measuring local ephemeral storage, then a Pod +that exceeds its local storage limit will not be evicted for breaching +local storage resource limits. + +However, if the filesystem space for writeable container layers, node-level logs, +or `emptyDir` volumes falls low, the node +{{< glossary_tooltip text="taints" term_id="taint" >}} itself as short on local storage +and this taint triggers eviction for any Pods that don't specifically tolerate the taint. + +See the supported [configurations](#configurations-for-local-ephemeral-storage) +for ephemeral local storage. +{{< /caution >}} + +The kubelet supports different ways to measure Pod storage use: + +{{< tabs name="resource-emphemeralstorage-measurement" >}} +{{% tab name="Periodic scanning" %}} +The kubelet performs regular, scheduled checks that scan each +`emptyDir` volume, container log directory, and writeable container layer. + +The scan measures how much space is used. + +{{< note >}} +In this mode, the kubelet does not track open file descriptors +for deleted files. + +If you (or a container) create a file inside an `emptyDir` volume, +something then opens that file, and you delete the file while it is +still open, then the inode for the deleted file stays until you close +that file but the kubelet does not categorize the space as in use. +{{< /note >}} +{{% /tab %}} +{{% tab name="Filesystem project quota" %}} + +{{< feature-state feature_gate_name="LocalStorageCapacityIsolationFSQuotaMonitoring" >}} + +Project quotas are an operating-system level feature for managing +storage use on filesystems. With Kubernetes, you can enable project +quotas for monitoring storage use. Make sure that the filesystem +backing the `emptyDir` volumes, on the node, provides project quota support. +For example, XFS and ext4fs offer project quotas. + +{{< note >}} +Project quotas let you monitor storage use; they do not enforce limits. +{{< /note >}} + +Kubernetes uses project IDs starting from `1048576`. The IDs in use are +registered in `/etc/projects` and `/etc/projid`. If project IDs in +this range are used for other purposes on the system, those project +IDs must be registered in `/etc/projects` and `/etc/projid` so that +Kubernetes does not use them. + +Quotas are faster and more accurate than directory scanning. When a +directory is assigned to a project, all files created under a +directory are created in that project, and the kernel merely has to +keep track of how many blocks are in use by files in that project. +If a file is created and deleted, but has an open file descriptor, +it continues to consume space. Quota tracking records that space accurately +whereas directory scans overlook the storage used by deleted files. + +To use quotas to track a pod's resource usage, the pod must be in +a user namespace. Within user namespaces, the kernel restricts changes +to projectIDs on the filesystem, ensuring the reliability of storage +metrics calculated by quotas. + +If you want to use project quotas, you should: + +* Enable the `LocalStorageCapacityIsolationFSQuotaMonitoring=true` + [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) + using the `featureGates` field in the + [kubelet configuration](/docs/reference/config-api/kubelet-config.v1beta1/). + +* Ensure the `UserNamespacesSupport` + [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) + is enabled, and that the kernel, CRI implementation and OCI runtime support user namespaces. + +* Ensure that the root filesystem (or optional runtime filesystem) + has project quotas enabled. All XFS filesystems support project quotas. + For ext4 filesystems, you need to enable the project quota tracking feature + while the filesystem is not mounted. + + ```bash + # For ext4, with /dev/block-device not mounted + sudo tune2fs -O project -Q prjquota /dev/block-device + ``` + +* Ensure that the root filesystem (or optional runtime filesystem) is + mounted with project quotas enabled. For both XFS and ext4fs, the + mount option is named `prjquota`. + + +If you don't want to use project quotas, you should: + +* Disable the `LocalStorageCapacityIsolationFSQuotaMonitoring` + [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) + using the `featureGates` field in the + [kubelet configuration](/docs/reference/config-api/kubelet-config.v1beta1/). +{{% /tab %}} +{{< /tabs >}} + +## Extended resources + +Extended resources are fully-qualified resource names outside the +`kubernetes.io` domain. They allow cluster operators to advertise and users to +consume the non-Kubernetes-built-in resources. + +There are two steps required to use Extended Resources. First, the cluster +operator must advertise an Extended Resource. Second, users must request the +Extended Resource in Pods. + +### Managing extended resources + +#### Node-level extended resources + +Node-level extended resources are tied to nodes. + +##### Device plugin managed resources +See [Device +Plugin](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) +for how to advertise device plugin managed resources on each node. + +##### Other resources + +To advertise a new node-level extended resource, the cluster operator can +submit a `PATCH` HTTP request to the API server to specify the available +quantity in the `status.capacity` for a node in the cluster. After this +operation, the node's `status.capacity` will include a new resource. The +`status.allocatable` field is updated automatically with the new resource +asynchronously by the kubelet. + +Because the scheduler uses the node's `status.allocatable` value when +evaluating Pod fitness, the scheduler only takes account of the new value after +that asynchronous update. There may be a short delay between patching the +node capacity with a new resource and the time when the first Pod that requests +the resource can be scheduled on that node. + +**Example:** + +Here is an example showing how to use `curl` to form an HTTP request that +advertises five "example.com/foo" resources on node `k8s-node-1` whose master +is `k8s-master`. + +```shell +curl --header "Content-Type: application/json-patch+json" \ +--request PATCH \ +--data '[{"op": "add", "path": "/status/capacity/example.com~1foo", "value": "5"}]' \ +http://k8s-master:8080/api/v1/nodes/k8s-node-1/status +``` + +{{< note >}} +In the preceding request, `~1` is the encoding for the character `/` +in the patch path. The operation path value in JSON-Patch is interpreted as a +JSON-Pointer. For more details, see +[IETF RFC 6901, section 3](https://tools.ietf.org/html/rfc6901#section-3). +{{< /note >}} + +#### Cluster-level extended resources + +Cluster-level extended resources are not tied to nodes. They are usually managed +by scheduler extenders, which handle the resource consumption and resource quota. + +You can specify the extended resources that are handled by scheduler extenders +in [scheduler configuration](/docs/reference/config-api/kube-scheduler-config.v1/) + +**Example:** + +The following configuration for a scheduler policy indicates that the +cluster-level extended resource "example.com/foo" is handled by the scheduler +extender. + +- The scheduler sends a Pod to the scheduler extender only if the Pod requests + "example.com/foo". +- The `ignoredByScheduler` field specifies that the scheduler does not check + the "example.com/foo" resource in its `PodFitsResources` predicate. + +```json +{ + "kind": "Policy", + "apiVersion": "v1", + "extenders": [ + { + "urlPrefix":"", + "bindVerb": "bind", + "managedResources": [ + { + "name": "example.com/foo", + "ignoredByScheduler": true + } + ] + } + ] +} +``` + +### Consuming extended resources + +Users can consume extended resources in Pod specs like CPU and memory. +The scheduler takes care of the resource accounting so that no more than the +available amount is simultaneously allocated to Pods. + +The API server restricts quantities of extended resources to whole numbers. +Examples of _valid_ quantities are `3`, `3000m` and `3Ki`. Examples of +_invalid_ quantities are `0.5` and `1500m` (because `1500m` would result in `1.5`). + +{{< note >}} +Extended resources replace Opaque Integer Resources. +Users can use any domain name prefix other than `kubernetes.io` which is reserved. +{{< /note >}} + +To consume an extended resource in a Pod, include the resource name as a key +in the `spec.containers[].resources.limits` map in the container spec. + +{{< note >}} +Extended resources cannot be overcommitted, so request and limit +must be equal if both are present in a container spec. +{{< /note >}} + +A Pod is scheduled only if all of the resource requests are satisfied, including +CPU, memory and any extended resources. The Pod remains in the `PENDING` state +as long as the resource request cannot be satisfied. + +**Example:** + +The Pod below requests 2 CPUs and 1 "example.com/foo" (an extended resource). + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: my-pod +spec: + containers: + - name: my-container + image: myimage + resources: + requests: + cpu: 2 + example.com/foo: 1 + limits: + example.com/foo: 1 +``` + +## PID limiting + +Process ID (PID) limits allow for the configuration of a kubelet +to limit the number of PIDs that a given Pod can consume. See +[PID Limiting](/docs/concepts/policy/pid-limiting/) for information. + +## Troubleshooting + +### My Pods are pending with event message `FailedScheduling` + +If the scheduler cannot find any node where a Pod can fit, the Pod remains +unscheduled until a place can be found. An +[Event](/docs/reference/kubernetes-api/cluster-resources/event-v1/) is produced +each time the scheduler fails to find a place for the Pod. You can use `kubectl` +to view the events for a Pod; for example: + +```shell +kubectl describe pod frontend | grep -A 9999999999 Events +``` +``` +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Warning FailedScheduling 23s default-scheduler 0/42 nodes available: insufficient cpu +``` + +In the preceding example, the Pod named "frontend" fails to be scheduled due to +insufficient CPU resource on any node. Similar error messages can also suggest +failure due to insufficient memory (PodExceedsFreeMemory). In general, if a Pod +is pending with a message of this type, there are several things to try: + +- Add more nodes to the cluster. +- Terminate unneeded Pods to make room for pending Pods. +- Check that the Pod is not larger than all the nodes. For example, if all the + nodes have a capacity of `cpu: 1`, then a Pod with a request of `cpu: 1.1` will + never be scheduled. +- Check for node taints. If most of your nodes are tainted, and the new Pod does + not tolerate that taint, the scheduler only considers placements onto the + remaining nodes that don't have that taint. + +You can check node capacities and amounts allocated with the +`kubectl describe nodes` command. For example: + +```shell +kubectl describe nodes e2e-test-node-pool-4lw4 +``` +``` +Name: e2e-test-node-pool-4lw4 +[ ... lines removed for clarity ...] +Capacity: + cpu: 2 + memory: 7679792Ki + pods: 110 +Allocatable: + cpu: 1800m + memory: 7474992Ki + pods: 110 +[ ... lines removed for clarity ...] +Non-terminated Pods: (5 in total) + Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits + --------- ---- ------------ ---------- --------------- ------------- + kube-system fluentd-gcp-v1.38-28bv1 100m (5%) 0 (0%) 200Mi (2%) 200Mi (2%) + kube-system kube-dns-3297075139-61lj3 260m (13%) 0 (0%) 100Mi (1%) 170Mi (2%) + kube-system kube-proxy-e2e-test-... 100m (5%) 0 (0%) 0 (0%) 0 (0%) + kube-system monitoring-influxdb-grafana-v4-z1m12 200m (10%) 200m (10%) 600Mi (8%) 600Mi (8%) + kube-system node-problem-detector-v0.1-fj7m3 20m (1%) 200m (10%) 20Mi (0%) 100Mi (1%) +Allocated resources: + (Total limits may be over 100 percent, i.e., overcommitted.) + CPU Requests CPU Limits Memory Requests Memory Limits + ------------ ---------- --------------- ------------- + 680m (34%) 400m (20%) 920Mi (11%) 1070Mi (13%) +``` + +In the preceding output, you can see that if a Pod requests more than 1.120 CPUs +or more than 6.23Gi of memory, that Pod will not fit on the node. + +By looking at the “Pods” section, you can see which Pods are taking up space on +the node. + +The amount of resources available to Pods is less than the node capacity because +system daemons use a portion of the available resources. Within the Kubernetes API, +each Node has a `.status.allocatable` field +(see [NodeStatus](/docs/reference/kubernetes-api/cluster-resources/node-v1/#NodeStatus) +for details). + +The `.status.allocatable` field describes the amount of resources that are available +to Pods on that node (for example: 15 virtual CPUs and 7538 MiB of memory). +For more information on node allocatable resources in Kubernetes, see +[Reserve Compute Resources for System Daemons](/docs/tasks/administer-cluster/reserve-compute-resources/). + +You can configure [resource quotas](/docs/concepts/policy/resource-quotas/) +to limit the total amount of resources that a namespace can consume. +Kubernetes enforces quotas for objects in particular namespace when there is a +ResourceQuota in that namespace. +For example, if you assign specific namespaces to different teams, you +can add ResourceQuotas into those namespaces. Setting resource quotas helps to +prevent one team from using so much of any resource that this over-use affects other teams. + +You should also consider what access you grant to that namespace: +**full** write access to a namespace allows someone with that access to remove any +resource, including a configured ResourceQuota. + +### My container is terminated + +Your container might get terminated because it is resource-starved. To check +whether a container is being killed because it is hitting a resource limit, call +`kubectl describe pod` on the Pod of interest: + +```shell +kubectl describe pod simmemleak-hra99 +``` + +The output is similar to: +``` +Name: simmemleak-hra99 +Namespace: default +Image(s): saadali/simmemleak +Node: kubernetes-node-tf0f/10.240.216.66 +Labels: name=simmemleak +Status: Running +Reason: +Message: +IP: 10.244.2.75 +Containers: + simmemleak: + Image: saadali/simmemleak:latest + Limits: + cpu: 100m + memory: 50Mi + State: Running + Started: Tue, 07 Jul 2019 12:54:41 -0700 + Last State: Terminated + Reason: OOMKilled + Exit Code: 137 + Started: Fri, 07 Jul 2019 12:54:30 -0700 + Finished: Fri, 07 Jul 2019 12:54:33 -0700 + Ready: False + Restart Count: 5 +Conditions: + Type Status + Ready False +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal Scheduled 42s default-scheduler Successfully assigned simmemleak-hra99 to kubernetes-node-tf0f + Normal Pulled 41s kubelet Container image "saadali/simmemleak:latest" already present on machine + Normal Created 41s kubelet Created container simmemleak + Normal Started 40s kubelet Started container simmemleak + Normal Killing 32s kubelet Killing container with id ead3fb35-5cf5-44ed-9ae1-488115be66c6: Need to kill Pod +``` + +In the preceding example, the `Restart Count: 5` indicates that the `simmemleak` +container in the Pod was terminated and restarted five times (so far). +The `OOMKilled` reason shows that the container tried to use more memory than its limit. + +Your next step might be to check the application code for a memory leak. If you +find that the application is behaving how you expect, consider setting a higher +memory limit (and possibly request) for that container. + +## {{% heading "whatsnext" %}} + +* Get hands-on experience [assigning Memory resources to containers and Pods](/docs/tasks/configure-pod-container/assign-memory-resource/). +* Get hands-on experience [assigning CPU resources to containers and Pods](/docs/tasks/configure-pod-container/assign-cpu-resource/). +* Read how the API reference defines a [container](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container) + and its [resource requirements](/docs/reference/kubernetes-api/workload-resources/pod-v1/#resources) +* Read about [project quotas](https://www.linux.org/docs/man8/xfs_quota.html) in XFS +* Read more about the [kube-scheduler configuration reference (v1)](/docs/reference/config-api/kube-scheduler-config.v1/) +* Read more about [Quality of Service classes for Pods](/docs/concepts/workloads/pods/pod-qos/) diff --git a/content/fa/docs/concepts/configuration/secret.md b/content/fa/docs/concepts/configuration/secret.md new file mode 100644 index 0000000000000..e6b761c2b728f --- /dev/null +++ b/content/fa/docs/concepts/configuration/secret.md @@ -0,0 +1,682 @@ +--- +reviewers: + - xirehat +title: Secrets +api_metadata: +- apiVersion: "v1" + kind: "Secret" +content_type: concept +feature: + title: مدیریت secrets و پیکربندی + description: > + بدون نیاز به بازسازی ایمیج و بدون افشای اسرار در پیکربندی پشته، اسرار و پیکربندی برنامه را مستقر و به‌روزرسانی کنید. +weight: 30 +--- + + + +A Secret is an object that contains a small amount of sensitive data such as +a password, a token, or a key. Such information might otherwise be put in a +{{< glossary_tooltip term_id="pod" >}} specification or in a +{{< glossary_tooltip text="container image" term_id="image" >}}. Using a +Secret means that you don't need to include confidential data in your +application code. + +Because Secrets can be created independently of the Pods that use them, there +is less risk of the Secret (and its data) being exposed during the workflow of +creating, viewing, and editing Pods. Kubernetes, and applications that run in +your cluster, can also take additional precautions with Secrets, such as avoiding +writing sensitive data to nonvolatile storage. + +Secrets are similar to {{< glossary_tooltip text="ConfigMaps" term_id="configmap" >}} +but are specifically intended to hold confidential data. + +{{< caution >}} +Kubernetes Secrets are, by default, stored unencrypted in the API server's underlying data store +(etcd). Anyone with API access can retrieve or modify a Secret, and so can anyone with access to etcd. +Additionally, anyone who is authorized to create a Pod in a namespace can use that access to read +any Secret in that namespace; this includes indirect access such as the ability to create a +Deployment. + +In order to safely use Secrets, take at least the following steps: + +1. [Enable Encryption at Rest](/docs/tasks/administer-cluster/encrypt-data/) for Secrets. +1. [Enable or configure RBAC rules](/docs/reference/access-authn-authz/authorization/) with + least-privilege access to Secrets. +1. Restrict Secret access to specific containers. +1. [Consider using external Secret store providers](https://secrets-store-csi-driver.sigs.k8s.io/concepts.html#provider-for-the-secrets-store-csi-driver). + +For more guidelines to manage and improve the security of your Secrets, refer to +[Good practices for Kubernetes Secrets](/docs/concepts/security/secrets-good-practices). + +{{< /caution >}} + +See [Information security for Secrets](#information-security-for-secrets) for more details. + + + +## Uses for Secrets + +You can use Secrets for purposes such as the following: + +- [Set environment variables for a container](/docs/tasks/inject-data-application/distribute-credentials-secure/#define-container-environment-variables-using-secret-data). +- [Provide credentials such as SSH keys or passwords to Pods](/docs/tasks/inject-data-application/distribute-credentials-secure/#provide-prod-test-creds). +- [Allow the kubelet to pull container images from private registries](/docs/tasks/configure-pod-container/pull-image-private-registry/). + +The Kubernetes control plane also uses Secrets; for example, +[bootstrap token Secrets](#bootstrap-token-secrets) are a mechanism to +help automate node registration. + +### Use case: dotfiles in a secret volume + +You can make your data "hidden" by defining a key that begins with a dot. +This key represents a dotfile or "hidden" file. For example, when the following Secret +is mounted into a volume, `secret-volume`, the volume will contain a single file, +called `.secret-file`, and the `dotfile-test-container` will have this file +present at the path `/etc/secret-volume/.secret-file`. + +{{< note >}} +Files beginning with dot characters are hidden from the output of `ls -l`; +you must use `ls -la` to see them when listing directory contents. +{{< /note >}} + +{{% code language="yaml" file="secret/dotfile-secret.yaml" %}} + +### Use case: Secret visible to one container in a Pod + +Consider a program that needs to handle HTTP requests, do some complex business +logic, and then sign some messages with an HMAC. Because it has complex +application logic, there might be an unnoticed remote file reading exploit in +the server, which could expose the private key to an attacker. + +This could be divided into two processes in two containers: a frontend container +which handles user interaction and business logic, but which cannot see the +private key; and a signer container that can see the private key, and responds +to simple signing requests from the frontend (for example, over localhost networking). + +With this partitioned approach, an attacker now has to trick the application +server into doing something rather arbitrary, which may be harder than getting +it to read a file. + +### Alternatives to Secrets + +Rather than using a Secret to protect confidential data, you can pick from alternatives. + +Here are some of your options: + +- If your cloud-native component needs to authenticate to another application that you + know is running within the same Kubernetes cluster, you can use a + [ServiceAccount](/docs/reference/access-authn-authz/authentication/#service-account-tokens) + and its tokens to identify your client. +- There are third-party tools that you can run, either within or outside your cluster, + that manage sensitive data. For example, a service that Pods access over HTTPS, + that reveals a Secret if the client correctly authenticates (for example, with a ServiceAccount + token). +- For authentication, you can implement a custom signer for X.509 certificates, and use + [CertificateSigningRequests](/docs/reference/access-authn-authz/certificate-signing-requests/) + to let that custom signer issue certificates to Pods that need them. +- You can use a [device plugin](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) + to expose node-local encryption hardware to a specific Pod. For example, you can schedule + trusted Pods onto nodes that provide a Trusted Platform Module, configured out-of-band. + +You can also combine two or more of those options, including the option to use Secret objects themselves. + +For example: implement (or deploy) an {{< glossary_tooltip text="operator" term_id="operator-pattern" >}} +that fetches short-lived session tokens from an external service, and then creates Secrets based +on those short-lived session tokens. Pods running in your cluster can make use of the session tokens, +and operator ensures they are valid. This separation means that you can run Pods that are unaware of +the exact mechanisms for issuing and refreshing those session tokens. + +## Types of Secret {#secret-types} + +When creating a Secret, you can specify its type using the `type` field of +the [Secret](/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/) +resource, or certain equivalent `kubectl` command line flags (if available). +The Secret type is used to facilitate programmatic handling of the Secret data. + +Kubernetes provides several built-in types for some common usage scenarios. +These types vary in terms of the validations performed and the constraints +Kubernetes imposes on them. + +| Built-in Type | Usage | +| ------------------------------------- |---------------------------------------- | +| `Opaque` | arbitrary user-defined data | +| `kubernetes.io/service-account-token` | ServiceAccount token | +| `kubernetes.io/dockercfg` | serialized `~/.dockercfg` file | +| `kubernetes.io/dockerconfigjson` | serialized `~/.docker/config.json` file | +| `kubernetes.io/basic-auth` | credentials for basic authentication | +| `kubernetes.io/ssh-auth` | credentials for SSH authentication | +| `kubernetes.io/tls` | data for a TLS client or server | +| `bootstrap.kubernetes.io/token` | bootstrap token data | + +You can define and use your own Secret type by assigning a non-empty string as the +`type` value for a Secret object (an empty string is treated as an `Opaque` type). + +Kubernetes doesn't impose any constraints on the type name. However, if you +are using one of the built-in types, you must meet all the requirements defined +for that type. + +If you are defining a type of Secret that's for public use, follow the convention +and structure the Secret type to have your domain name before the name, separated +by a `/`. For example: `cloud-hosting.example.net/cloud-api-credentials`. + +### Opaque Secrets + +`Opaque` is the default Secret type if you don't explicitly specify a type in +a Secret manifest. When you create a Secret using `kubectl`, you must use the +`generic` subcommand to indicate an `Opaque` Secret type. For example, the +following command creates an empty Secret of type `Opaque`: + +```shell +kubectl create secret generic empty-secret +kubectl get secret empty-secret +``` + +The output looks like: + +``` +NAME TYPE DATA AGE +empty-secret Opaque 0 2m6s +``` + +The `DATA` column shows the number of data items stored in the Secret. +In this case, `0` means you have created an empty Secret. + +### ServiceAccount token Secrets + +A `kubernetes.io/service-account-token` type of Secret is used to store a +token credential that identifies a +{{< glossary_tooltip text="ServiceAccount" term_id="service-account" >}}. This +is a legacy mechanism that provides long-lived ServiceAccount credentials to +Pods. + +In Kubernetes v1.22 and later, the recommended approach is to obtain a +short-lived, automatically rotating ServiceAccount token by using the +[`TokenRequest`](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/) +API instead. You can get these short-lived tokens using the following methods: + +* Call the `TokenRequest` API either directly or by using an API client like + `kubectl`. For example, you can use the + [`kubectl create token`](/docs/reference/generated/kubectl/kubectl-commands#-em-token-em-) + command. +* Request a mounted token in a + [projected volume](/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume) + in your Pod manifest. Kubernetes creates the token and mounts it in the Pod. + The token is automatically invalidated when the Pod that it's mounted in is + deleted. For details, see + [Launch a Pod using service account token projection](/docs/tasks/configure-pod-container/configure-service-account/#launch-a-pod-using-service-account-token-projection). + +{{< note >}} +You should only create a ServiceAccount token Secret +if you can't use the `TokenRequest` API to obtain a token, +and the security exposure of persisting a non-expiring token credential +in a readable API object is acceptable to you. For instructions, see +[Manually create a long-lived API token for a ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/#manually-create-an-api-token-for-a-serviceaccount). +{{< /note >}} + +When using this Secret type, you need to ensure that the +`kubernetes.io/service-account.name` annotation is set to an existing +ServiceAccount name. If you are creating both the ServiceAccount and +the Secret objects, you should create the ServiceAccount object first. + +After the Secret is created, a Kubernetes {{< glossary_tooltip text="controller" term_id="controller" >}} +fills in some other fields such as the `kubernetes.io/service-account.uid` annotation, and the +`token` key in the `data` field, which is populated with an authentication token. + +The following example configuration declares a ServiceAccount token Secret: + +{{% code language="yaml" file="secret/serviceaccount-token-secret.yaml" %}} + +After creating the Secret, wait for Kubernetes to populate the `token` key in the `data` field. + +See the [ServiceAccount](/docs/concepts/security/service-accounts/) +documentation for more information on how ServiceAccounts work. +You can also check the `automountServiceAccountToken` field and the +`serviceAccountName` field of the +[`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) +for information on referencing ServiceAccount credentials from within Pods. + +### Docker config Secrets + +If you are creating a Secret to store credentials for accessing a container image registry, +you must use one of the following `type` values for that Secret: + +- `kubernetes.io/dockercfg`: store a serialized `~/.dockercfg` which is the + legacy format for configuring Docker command line. The Secret + `data` field contains a `.dockercfg` key whose value is the content of a + base64 encoded `~/.dockercfg` file. +- `kubernetes.io/dockerconfigjson`: store a serialized JSON that follows the + same format rules as the `~/.docker/config.json` file, which is a new format + for `~/.dockercfg`. The Secret `data` field must contain a + `.dockerconfigjson` key for which the value is the content of a base64 + encoded `~/.docker/config.json` file. + +Below is an example for a `kubernetes.io/dockercfg` type of Secret: + +{{% code language="yaml" file="secret/dockercfg-secret.yaml" %}} + +{{< note >}} +If you do not want to perform the base64 encoding, you can choose to use the +`stringData` field instead. +{{< /note >}} + +When you create Docker config Secrets using a manifest, the API +server checks whether the expected key exists in the `data` field, and +it verifies if the value provided can be parsed as a valid JSON. The API +server doesn't validate if the JSON actually is a Docker config file. + +You can also use `kubectl` to create a Secret for accessing a container +registry, such as when you don't have a Docker configuration file: + +```shell +kubectl create secret docker-registry secret-tiger-docker \ + --docker-email=tiger@acme.example \ + --docker-username=tiger \ + --docker-password=pass1234 \ + --docker-server=my-registry.example:5000 +``` + +This command creates a Secret of type `kubernetes.io/dockerconfigjson`. + +Retrieve the `.data.dockerconfigjson` field from that new Secret and decode the +data: + +```shell +kubectl get secret secret-tiger-docker -o jsonpath='{.data.*}' | base64 -d +``` + +The output is equivalent to the following JSON document (which is also a valid +Docker configuration file): + +```json +{ + "auths": { + "my-registry.example:5000": { + "username": "tiger", + "password": "pass1234", + "email": "tiger@acme.example", + "auth": "dGlnZXI6cGFzczEyMzQ=" + } + } +} +``` + +{{< caution >}} +The `auth` value there is base64 encoded; it is obscured but not secret. +Anyone who can read that Secret can learn the registry access bearer token. + +It is suggested to use [credential providers](/docs/tasks/administer-cluster/kubelet-credential-provider/) to dynamically and securely provide pull secrets on-demand. +{{< /caution >}} + +### Basic authentication Secret + +The `kubernetes.io/basic-auth` type is provided for storing credentials needed +for basic authentication. When using this Secret type, the `data` field of the +Secret must contain one of the following two keys: + +- `username`: the user name for authentication +- `password`: the password or token for authentication + +Both values for the above two keys are base64 encoded strings. You can +alternatively provide the clear text content using the `stringData` field in the +Secret manifest. + +The following manifest is an example of a basic authentication Secret: + +{{% code language="yaml" file="secret/basicauth-secret.yaml" %}} + +{{< note >}} +The `stringData` field for a Secret does not work well with server-side apply. +{{< /note >}} + +The basic authentication Secret type is provided only for convenience. +You can create an `Opaque` type for credentials used for basic authentication. +However, using the defined and public Secret type (`kubernetes.io/basic-auth`) helps other +people to understand the purpose of your Secret, and sets a convention for what key names +to expect. + +### SSH authentication Secrets + +The builtin type `kubernetes.io/ssh-auth` is provided for storing data used in +SSH authentication. When using this Secret type, you will have to specify a +`ssh-privatekey` key-value pair in the `data` (or `stringData`) field +as the SSH credential to use. + +The following manifest is an example of a Secret used for SSH public/private +key authentication: + +{{% code language="yaml" file="secret/ssh-auth-secret.yaml" %}} + +The SSH authentication Secret type is provided only for convenience. +You can create an `Opaque` type for credentials used for SSH authentication. +However, using the defined and public Secret type (`kubernetes.io/ssh-auth`) helps other +people to understand the purpose of your Secret, and sets a convention for what key names +to expect. +The Kubernetes API verifies that the required keys are set for a Secret of this type. + +{{< caution >}} +SSH private keys do not establish trusted communication between an SSH client and +host server on their own. A secondary means of establishing trust is needed to +mitigate "man in the middle" attacks, such as a `known_hosts` file added to a ConfigMap. +{{< /caution >}} + +### TLS Secrets + +The `kubernetes.io/tls` Secret type is for storing +a certificate and its associated key that are typically used for TLS. + +One common use for TLS Secrets is to configure encryption in transit for +an [Ingress](/docs/concepts/services-networking/ingress/), but you can also use it +with other resources or directly in your workload. +When using this type of Secret, the `tls.key` and the `tls.crt` key must be provided +in the `data` (or `stringData`) field of the Secret configuration, although the API +server doesn't actually validate the values for each key. + +As an alternative to using `stringData`, you can use the `data` field to provide +the base64 encoded certificate and private key. For details, see +[Constraints on Secret names and data](#restriction-names-data). + +The following YAML contains an example config for a TLS Secret: + +{{% code language="yaml" file="secret/tls-auth-secret.yaml" %}} + +The TLS Secret type is provided only for convenience. +You can create an `Opaque` type for credentials used for TLS authentication. +However, using the defined and public Secret type (`kubernetes.io/tls`) +helps ensure the consistency of Secret format in your project. The API server +verifies if the required keys are set for a Secret of this type. + +To create a TLS Secret using `kubectl`, use the `tls` subcommand: + +```shell +kubectl create secret tls my-tls-secret \ + --cert=path/to/cert/file \ + --key=path/to/key/file +``` + +The public/private key pair must exist before hand. The public key certificate for `--cert` must be .PEM encoded +and must match the given private key for `--key`. + +### Bootstrap token Secrets + +The `bootstrap.kubernetes.io/token` Secret type is for +tokens used during the node bootstrap process. It stores tokens used to sign +well-known ConfigMaps. + +A bootstrap token Secret is usually created in the `kube-system` namespace and +named in the form `bootstrap-token-` where `` is a 6 character +string of the token ID. + +As a Kubernetes manifest, a bootstrap token Secret might look like the +following: + +{{% code language="yaml" file="secret/bootstrap-token-secret-base64.yaml" %}} + +A bootstrap token Secret has the following keys specified under `data`: + +- `token-id`: A random 6 character string as the token identifier. Required. +- `token-secret`: A random 16 character string as the actual token Secret. Required. +- `description`: A human-readable string that describes what the token is + used for. Optional. +- `expiration`: An absolute UTC time using [RFC3339](https://datatracker.ietf.org/doc/html/rfc3339) specifying when the token + should be expired. Optional. +- `usage-bootstrap-`: A boolean flag indicating additional usage for + the bootstrap token. +- `auth-extra-groups`: A comma-separated list of group names that will be + authenticated as in addition to the `system:bootstrappers` group. + +You can alternatively provide the values in the `stringData` field of the Secret +without base64 encoding them: + +{{% code language="yaml" file="secret/bootstrap-token-secret-literal.yaml" %}} + +{{< note >}} +The `stringData` field for a Secret does not work well with server-side apply. +{{< /note >}} + +## Working with Secrets + +### Creating a Secret + +There are several options to create a Secret: + +- [Use `kubectl`](/docs/tasks/configmap-secret/managing-secret-using-kubectl/) +- [Use a configuration file](/docs/tasks/configmap-secret/managing-secret-using-config-file/) +- [Use the Kustomize tool](/docs/tasks/configmap-secret/managing-secret-using-kustomize/) + +#### Constraints on Secret names and data {#restriction-names-data} + +The name of a Secret object must be a valid +[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). + +You can specify the `data` and/or the `stringData` field when creating a +configuration file for a Secret. The `data` and the `stringData` fields are optional. +The values for all keys in the `data` field have to be base64-encoded strings. +If the conversion to base64 string is not desirable, you can choose to specify +the `stringData` field instead, which accepts arbitrary strings as values. + +The keys of `data` and `stringData` must consist of alphanumeric characters, +`-`, `_` or `.`. All key-value pairs in the `stringData` field are internally +merged into the `data` field. If a key appears in both the `data` and the +`stringData` field, the value specified in the `stringData` field takes +precedence. + +#### Size limit {#restriction-data-size} + +Individual Secrets are limited to 1MiB in size. This is to discourage creation +of very large Secrets that could exhaust the API server and kubelet memory. +However, creation of many smaller Secrets could also exhaust memory. You can +use a [resource quota](/docs/concepts/policy/resource-quotas/) to limit the +number of Secrets (or other resources) in a namespace. + +### Editing a Secret + +You can edit an existing Secret unless it is [immutable](#secret-immutable). To +edit a Secret, use one of the following methods: + +- [Use `kubectl`](/docs/tasks/configmap-secret/managing-secret-using-kubectl/#edit-secret) +- [Use a configuration file](/docs/tasks/configmap-secret/managing-secret-using-config-file/#edit-secret) + +You can also edit the data in a Secret using the [Kustomize tool](/docs/tasks/configmap-secret/managing-secret-using-kustomize/#edit-secret). However, this +method creates a new `Secret` object with the edited data. + +Depending on how you created the Secret, as well as how the Secret is used in +your Pods, updates to existing `Secret` objects are propagated automatically to +Pods that use the data. For more information, refer to [Using Secrets as files from a Pod](#using-secrets-as-files-from-a-pod) section. + +### Using a Secret + +Secrets can be mounted as data volumes or exposed as +{{< glossary_tooltip text="environment variables" term_id="container-env-variables" >}} +to be used by a container in a Pod. Secrets can also be used by other parts of the +system, without being directly exposed to the Pod. For example, Secrets can hold +credentials that other parts of the system should use to interact with external +systems on your behalf. + +Secret volume sources are validated to ensure that the specified object +reference actually points to an object of type Secret. Therefore, a Secret +needs to be created before any Pods that depend on it. + +If the Secret cannot be fetched (perhaps because it does not exist, or +due to a temporary lack of connection to the API server) the kubelet +periodically retries running that Pod. The kubelet also reports an Event +for that Pod, including details of the problem fetching the Secret. + +#### Optional Secrets {#restriction-secret-must-exist} + +When you reference a Secret in a Pod, you can mark the Secret as _optional_, +such as in the following example. If an optional Secret doesn't exist, +Kubernetes ignores it. + +{{% code language="yaml" file="secret/optional-secret.yaml" %}} + +By default, Secrets are required. None of a Pod's containers will start until +all non-optional Secrets are available. + +If a Pod references a specific key in a non-optional Secret and that Secret +does exist, but is missing the named key, the Pod fails during startup. + +### Using Secrets as files from a Pod {#using-secrets-as-files-from-a-pod} + +If you want to access data from a Secret in a Pod, one way to do that is to +have Kubernetes make the value of that Secret be available as a file inside +the filesystem of one or more of the Pod's containers. + +For instructions, refer to +[Create a Pod that has access to the secret data through a Volume](/docs/tasks/inject-data-application/distribute-credentials-secure/#create-a-pod-that-has-access-to-the-secret-data-through-a-volume). + +When a volume contains data from a Secret, and that Secret is updated, Kubernetes tracks +this and updates the data in the volume, using an eventually-consistent approach. + +{{< note >}} +A container using a Secret as a +[subPath](/docs/concepts/storage/volumes#using-subpath) volume mount does not receive +automated Secret updates. +{{< /note >}} + +The kubelet keeps a cache of the current keys and values for the Secrets that are used in +volumes for pods on that node. +You can configure the way that the kubelet detects changes from the cached values. The +`configMapAndSecretChangeDetectionStrategy` field in the +[kubelet configuration](/docs/reference/config-api/kubelet-config.v1beta1/) controls +which strategy the kubelet uses. The default strategy is `Watch`. + +Updates to Secrets can be either propagated by an API watch mechanism (the default), based on +a cache with a defined time-to-live, or polled from the cluster API server on each kubelet +synchronisation loop. + +As a result, the total delay from the moment when the Secret is updated to the moment +when new keys are projected to the Pod can be as long as the kubelet sync period + cache +propagation delay, where the cache propagation delay depends on the chosen cache type +(following the same order listed in the previous paragraph, these are: +watch propagation delay, the configured cache TTL, or zero for direct polling). + +### Using Secrets as environment variables + +To use a Secret in an {{< glossary_tooltip text="environment variable" term_id="container-env-variables" >}} +in a Pod: + +1. For each container in your Pod specification, add an environment variable + for each Secret key that you want to use to the + `env[].valueFrom.secretKeyRef` field. +1. Modify your image and/or command line so that the program looks for values + in the specified environment variables. + +For instructions, refer to +[Define container environment variables using Secret data](/docs/tasks/inject-data-application/distribute-credentials-secure/#define-container-environment-variables-using-secret-data). + +It's important to note that the range of characters allowed for environment variable +names in pods is [restricted](/docs/tasks/inject-data-application/define-environment-variable-container/#using-environment-variables-inside-of-your-config). +If any keys do not meet the rules, those keys are not made available to your container, though +the Pod is allowed to start. + +### Container image pull Secrets {#using-imagepullsecrets} + +If you want to fetch container images from a private repository, you need a way for +the kubelet on each node to authenticate to that repository. You can configure +_image pull Secrets_ to make this possible. These Secrets are configured at the Pod +level. + +#### Using imagePullSecrets + +The `imagePullSecrets` field is a list of references to Secrets in the same namespace. +You can use an `imagePullSecrets` to pass a Secret that contains a Docker (or other) image registry +password to the kubelet. The kubelet uses this information to pull a private image on behalf of your Pod. +See the [PodSpec API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) +for more information about the `imagePullSecrets` field. + +##### Manually specifying an imagePullSecret + +You can learn how to specify `imagePullSecrets` from the +[container images](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) +documentation. + +##### Arranging for imagePullSecrets to be automatically attached + +You can manually create `imagePullSecrets`, and reference these from a ServiceAccount. Any Pods +created with that ServiceAccount or created with that ServiceAccount by default, will get their +`imagePullSecrets` field set to that of the service account. +See [Add ImagePullSecrets to a service account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) +for a detailed explanation of that process. + +### Using Secrets with static Pods {#restriction-static-pod} + +You cannot use ConfigMaps or Secrets with {{< glossary_tooltip text="static Pods" term_id="static-pod" >}}. + +## Immutable Secrets {#secret-immutable} + +{{< feature-state for_k8s_version="v1.21" state="stable" >}} + +Kubernetes lets you mark specific Secrets (and ConfigMaps) as _immutable_. +Preventing changes to the data of an existing Secret has the following benefits: + +- protects you from accidental (or unwanted) updates that could cause applications outages +- (for clusters that extensively use Secrets - at least tens of thousands of unique Secret + to Pod mounts), switching to immutable Secrets improves the performance of your cluster + by significantly reducing load on kube-apiserver. The kubelet does not need to maintain + a [watch] on any Secrets that are marked as immutable. + +### Marking a Secret as immutable {#secret-immutable-create} + +You can create an immutable Secret by setting the `immutable` field to `true`. For example, + +```yaml +apiVersion: v1 +kind: Secret +metadata: ... +data: ... +immutable: true +``` + +You can also update any existing mutable Secret to make it immutable. + +{{< note >}} +Once a Secret or ConfigMap is marked as immutable, it is _not_ possible to revert this change +nor to mutate the contents of the `data` field. You can only delete and recreate the Secret. +Existing Pods maintain a mount point to the deleted Secret - it is recommended to recreate +these pods. +{{< /note >}} + +## Information security for Secrets + +Although ConfigMap and Secret work similarly, Kubernetes applies some additional +protection for Secret objects. + +Secrets often hold values that span a spectrum of importance, many of which can +cause escalations within Kubernetes (e.g. service account tokens) and to +external systems. Even if an individual app can reason about the power of the +Secrets it expects to interact with, other apps within the same namespace can +render those assumptions invalid. + +A Secret is only sent to a node if a Pod on that node requires it. +For mounting Secrets into Pods, the kubelet stores a copy of the data into a `tmpfs` +so that the confidential data is not written to durable storage. +Once the Pod that depends on the Secret is deleted, the kubelet deletes its local copy +of the confidential data from the Secret. + +There may be several containers in a Pod. By default, containers you define +only have access to the default ServiceAccount and its related Secret. +You must explicitly define environment variables or map a volume into a +container in order to provide access to any other Secret. + +There may be Secrets for several Pods on the same node. However, only the +Secrets that a Pod requests are potentially visible within its containers. +Therefore, one Pod does not have access to the Secrets of another Pod. + +### Configure least-privilege access to Secrets + +To enhance the security measures around Secrets, use separate namespaces to isolate access to mounted secrets. + +{{< warning >}} +Any containers that run with `privileged: true` on a node can access all +Secrets used on that node. +{{< /warning >}} + +## {{% heading "whatsnext" %}} + +- For guidelines to manage and improve the security of your Secrets, refer to + [Good practices for Kubernetes Secrets](/docs/concepts/security/secrets-good-practices). +- Learn how to [manage Secrets using `kubectl`](/docs/tasks/configmap-secret/managing-secret-using-kubectl/) +- Learn how to [manage Secrets using config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/) +- Learn how to [manage Secrets using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/) +- Read the [API reference](/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/) for `Secret` diff --git a/content/fa/docs/concepts/containers/_index.md b/content/fa/docs/concepts/containers/_index.md new file mode 100644 index 0000000000000..16909ae01c068 --- /dev/null +++ b/content/fa/docs/concepts/containers/_index.md @@ -0,0 +1,39 @@ +--- +title: کانتینرها +weight: 40 +description: فناوری برای بسته‌بندی یک برنامه به همراه وابستگی‌های زمان اجرا. +reviewers: +- xirehat +content_type: concept +card: + name: concepts + weight: 50 +--- + + + +این صفحه به بررسی کانتینرها و ایمیج‌های کانتینر، و همچنین کاربرد آن‌ها در عملیات و توسعه راه‌حل‌ها می‌پردازد. + +واژه _کانتینر_ یک اصطلاح بارگذاری‌شده است. هر زمان از این واژه استفاده می‌کنید، بررسی کنید که مخاطبان شما از همان تعریف استفاده می‌کنند یا خیر. + +هر کانتینری که اجرا می‌کنید قابل تکرار است؛ استانداردسازی‌ای که با درج وابستگی‌ها به دست می‌آید این تضمین را می‌دهد که در هر نقطه‌ای که آن را اجرا کنید، رفتار یکسانی خواهید داشت. + +کانتینرها، برنامه‌ها را از زیرساخت میزبان جدا می‌کنند. این موضوع استقرار را در محیط‌های مختلف ابری یا سیستم‌عامل آسان‌تر می‌سازد. + +هر {{< glossary_tooltip text="نود" term_id="node" >}} در یک خوشه Kubernetes، کانتینرهایی را که تشکیل‌دهنده [پادها](/docs/concepts/workloads/pods/) هستند و به آن نود اختصاص یافته‌اند، اجرا می‌کند. کانتینرهای یک پاد، هم‌مکان و هم‌زمان‌بندی شده تا بر روی یک نود اجرا شوند. + + + + +## ایمیج‌های کانتینر +یک [ایمیج کانتینر](/docs/concepts/containers/images/) بسته‌ی نرم‌افزاری آماده اجراست که همه آنچه برای راه‌اندازی یک برنامه لازم است را در بر می‌گیرد: کد و هر محیط اجرای مورد نیاز، کتابخانه‌های برنامه و سیستم، و مقادیر پیش‌فرض برای هر تنظیم ضروری. + +کانتینرها قرار است بدون‌حالت (stateless) و [تغییرناپذیر](https://glossary.cncf.io/immutable-infrastructure/) باشند؛ نباید کد یک کانتینر در حال اجرا را تغییر دهید. اگر برنامه‌ای کانتینری دارید و می‌خواهید تغییری اعمال کنید، روش درست این است که یک ایمیج جدید شامل آن تغییر بسازید و سپس کانتینر را از روی ایمیج به‌روزشده مجدداً ایجاد کنید. + +## زمان‌اجرای کانتینر + +{{< glossary_definition term_id="container-runtime" length="all" >}} + +عموماً می‌توانید به خوشه اجازه دهید زمان‌اجرای پیش‌فرض را برای یک پاد انتخاب کند. اگر نیاز دارید در خوشه خود بیش از یک زمان‌اجرا داشته باشید، می‌توانید [RuntimeClass](/docs/concepts/containers/runtime-class/) را برای یک پاد مشخص کنید تا مطمئن شوید Kubernetes آن کانتینرها را با زمان‌اجرای مورد نظر شما اجرا می‌کند. + +همچنین می‌توانید با استفاده از RuntimeClass، پادهای مختلف را با یک زمان‌اجرا اما با تنظیمات متفاوت اجرا کنید. diff --git a/content/fa/docs/concepts/containers/container-environment.md b/content/fa/docs/concepts/containers/container-environment.md new file mode 100644 index 0000000000000..a33b28ea2255c --- /dev/null +++ b/content/fa/docs/concepts/containers/container-environment.md @@ -0,0 +1,63 @@ +--- +reviewers: +- xirehat +title: محیط کانتینر +content_type: concept +weight: 20 +--- + + + +این صفحه منابع موجود برای کانتینرها در محیط کانتینر را شرح می‌دهد. + + + + + + +## محیط کانتینر + +محیط کانتینر در کوبرنتیز چند منبع مهم را در اختیار کانتینرها قرار می‌دهد: + +* یک فایل‌سیستم، که ترکیبی از یک [ایمیج](/docs/concepts/containers/images/) و یک یا چند [ولوم](/docs/concepts/storage/volumes/) است. +* اطلاعات مربوط به خود کانتینر. +* اطلاعات درباره سایر اشیاء در خوشه. + +### اطلاعات کانتینر + +*نام میزبان* (hostname) یک کانتینر، همان نام پادی است که کانتینر در آن اجرا می‌شود. +این مقدار از طریق فرمان `hostname` یا فراخوانی تابع +[`gethostname`](https://man7.org/linux/man-pages/man2/gethostname.2.html) +در libc در دسترس است. + +نام پاد و فضای نام (namespace) به‌صورت متغیرهای محیطی از طریق +[API پایین‌رو](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) +در دسترس کانتینر قرار می‌گیرند. + +متغیرهای محیطی تعریف‌شده توسط کاربر در تعریف پاد نیز برای کانتینر قابل دسترسی هستند، +و همچنین هر متغیر محیطی که به‌طور ایستا در ایمیج کانتینر مشخص شده باشد. + +### اطلاعات خوشه + +لیستی از تمامی سرویس‌هایی که هنگام ایجاد یک کانتینر در حال اجرا بودند، به‌صورت متغیرهای محیطی در اختیار آن کانتینر قرار می‌گیرد. +این لیست محدود به سرویس‌های درون همان فضای نام (namespace) پاد کانتینر جدید و سرویس‌های صفحه کنترل کوبرنتیز است. + +برای سرویسی به نام *foo* که به کانتینری به نام *bar* نگاشت می‌شود، +متغیرهای زیر تعریف می‌شوند: + +```shell +FOO_SERVICE_HOST= +FOO_SERVICE_PORT= +``` + +سرویس‌ها دارای آدرس‌های IP اختصاصی هستند و در صورت فعال بودن [افزونه DNS](https://releases.k8s.io/v{{< skew currentPatchVersion >}}/cluster/addons/dns/)، از طریق DNS برای کانتینر قابل دسترسی‌اند. + + + +## {{% heading "whatsnext" %}} + + +* برای آشنایی بیشتر با [قلاب‌های چرخه عمر کانتینر](/docs/concepts/containers/container-lifecycle-hooks/) مطالعه کنید. +* تجربه عملی کسب کنید و با [اضافه کردن هندلر به رویدادهای چرخه عمر کانتینر](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) کار کنید. + + diff --git a/content/fa/docs/concepts/containers/container-lifecycle-hooks.md b/content/fa/docs/concepts/containers/container-lifecycle-hooks.md new file mode 100644 index 0000000000000..6093a6b7d5be8 --- /dev/null +++ b/content/fa/docs/concepts/containers/container-lifecycle-hooks.md @@ -0,0 +1,107 @@ +--- +reviewers: +- xirehat +title: قلاب‌های چرخه عمر کانتینر +content_type: concept +weight: 40 +--- + + + +این صفحه توضیح می‌دهد که چگونه کانتینرهای مدیریت‌شده توسط kubelet می‌توانند از چارچوب قلاب چرخه حیات کانتینر برای اجرای کدی که توسط رویدادها در طول چرخه حیات مدیریت آنها ایجاد می‌شود، استفاده کنند. + + + + + +## نمای کلی + +مشابه بسیاری از فریم‌ورک‌های زبان‌های برنامه‌نویسی که دارای قلاب‌های چرخه‌عمر مؤلفه هستند، مانند Angular، Kubernetes نیز به کانتینرها قلاب‌های چرخه‌عمر ارائه می‌دهد. این قلاب‌ها به کانتینرها امکان می‌دهند تا از رویدادهای چرخه‌عمر مدیریتی خود آگاه شوند و هنگام اجرای قلاب مربوطه، کدی را که در یک هندلر پیاده‌سازی شده اجرا کنند. + +## قلاب‌های کانتینر + +دو قلاب وجود دارد که در اختیار کانتینرها قرار می‌گیرند: + +`PostStart` + +این قلاب بلافاصله پس از ایجاد کانتینر اجرا می‌شود. با این حال، تضمینی وجود ندارد که قلاب قبل از ENTRYPOINT کانتینر اجرا شود. هیچ پارامتری به هندلر ارسال نمی‌شود. + +`PreStop` + +این قلاب درست قبل از خاتمه کانتینر در اثر یک درخواست API یا رویدادی مدیریتی مانند شکست پروب liveness/startup، پیش‌دستی (preemption)، تداخل منابع و موارد دیگر فراخوانی می‌شود. فراخوانی قلاب `PreStop` در صورتی شکست می‌خورد که کانتینر قبلاً در وضعیت خاتمه‌یافته یا تکمیل‌شده باشد. این قلاب باید قبل از ارسال سیگنال TERM برای متوقف کردن کانتینر تکمیل شود. شمارش معکوس دوره مهلت خاتمه پاد قبل از اجرای قلاب `PreStop` آغاز می‌شود، بنابراین فارغ از نتیجه هندلر، کانتینر در نهایت در دوره مهلت خاتمه پاد متوقف خواهد شد. هیچ پارامتری به هندلر ارسال نمی‌شود. + +توضیح دقیق‌تر رفتار خاتمه را می‌توانید در +[Termination of Pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) +مطالعه کنید. + +`StopSignal` + +چرخه‌عمر `StopSignal` می‌تواند برای تعریف سیگنال توقفی استفاده شود که هنگام متوقف شدن کانتینر به آن ارسال می‌شود. اگر این مقدار تنظیم شود، هرگونه دستور `STOPSIGNAL` تعریف‌شده در درون ایمیج کانتینر را نادیده می‌گیرد. + +توضیح دقیق‌تر رفتار خاتمه با سیگنال‌های توقف سفارشی را می‌توانید در +[Stop Signals](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination-stop-signals) +مطالعه کنید. + +### پیاده‌سازی هندلر قلاب + +کانتینرها می‌توانند با پیاده‌سازی و ثبت یک هندلر برای قلاب مربوطه به آن دسترسی پیدا کنند. +سه نوع هندلر قلاب وجود دارد که می‌توان برای کانتینرها پیاده‌سازی کرد: + +* Exec – اجرای یک فرمان مشخص، مانند `pre-stop.sh`، در داخل cgroups و namespaceهای کانتینر. + منابع مصرف‌شده توسط این فرمان به حساب کانتینر منظور می‌شوند. +* HTTP – ارسال یک درخواست HTTP به یک endpoint خاص درون کانتینر. +* Sleep – ایست موقت کانتینر برای مدت زمان مشخص. + این یک ویژگی در سطح بتا است که به‌طور پیش‌فرض با `PodLifecycleSleepAction` + [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) فعال می‌شود. + +{{< note >}} +بتا-level feature gate `PodLifecycleSleepActionAllowZero` که از نسخه v1.33 به‌طور پیش‌فرض فعال است، +به شما اجازه می‌دهد مدت زمان Sleep را صفر ثانیه (عملاً عملیاتی انجام نمی‌شود) +برای هندلرهای چرخه‌عمر Sleep تنظیم کنید. +{{< /note >}} + +### اجرای هندلر قلاب + +وقتی یک قلاب مدیریت چرخه‌عمر کانتینر فراخوانی می‌شود، سیستم مدیریت Kubernetes هندلر را بر اساس نوع عمل قلاب اجرا می‌کند. عملیات‌های `httpGet`، `tcpSocket` ([منسوخ شده](/docs/reference/generated/kubernetes-api/v1.31/#lifecyclehandler-v1-core)) و `sleep` توسط فرآیند kubelet اجرا می‌شوند و `exec` در داخل کانتینر اجرا می‌شود. + +فراخوانی هندلر قلاب `PostStart` هنگام ایجاد کانتینر شروع می‌شود، به این معنی که ENTRYPOINT کانتینر و قلاب `PostStart` به‌طور هم‌زمان فعال می‌شوند. با این حال، اگر اجرای قلاب `PostStart` طولانی شود یا در حین اجرا گیر کند، ممکن است مانع از انتقال کانتینر به وضعیت `running` شود. + +قلاب‌های `PreStop` به‌صورت ناهمزمان با سیگنال توقف کانتینر اجرا نمی‌شوند؛ قلاب باید اجرای خود را قبل از ارسال سیگنال TERM کامل کند. اگر قلاب `PreStop` در حین اجرا گیر کند، فاز پاد به `Terminating` تغییر می‌کند و تا زمان اتمام دوره `terminationGracePeriodSeconds` و سپس کشته شدن پاد در آن وضعیت باقی می‌ماند. این دوره مهلت شامل مجموع زمانی است که برای اجرای قلاب `PreStop` و متوقف شدن طبیعی کانتینر نیاز است. برای مثال، اگر `terminationGracePeriodSeconds` برابر ۶۰ ثانیه باشد، و قلاب ۵۵ ثانیه و کانتینر ۱۰ ثانیه بعد از دریافت سیگنال برای توقف طبیعی زمان ببرد، کانتینر قبل از توقف طبیعی کشته می‌شود، چون `terminationGracePeriodSeconds` کمتر از مجموع زمان (۵۵+۱۰) است. + +اگر هر یک از قلاب‌های `PostStart` یا `PreStop` با شکست مواجه شوند، کانتینر را نابود می‌کنند. + +کاربران باید هندلرهای قلاب خود را تا حد ممکن سبک نگه دارند. با این حال، در برخی موارد اجرای فرمان‌های طولانی‌مدت منطقی است، مانند وقتی که لازم است قبل از توقف کانتینر، وضعیت (state) ذخیره شود. + +### تضمین تحویل قلاب‌ها + +تحویل قلاب قرار است *حداقل یک‌بار* باشد، یعنی ممکن است برای هر رویداد مشخص – مانند `PostStart` یا `PreStop` – قلاب چندین بار فراخوانی شود. مدیریت صحیح این شرایط بر عهده پیاده‌سازی قلاب است. + +به‌طور کلی، معمولاً تنها یک‌بار تحویل انجام می‌شود. اگر مثلاً گیرنده HTTP قلاب از کار افتاده و قادر به دریافت درخواست نباشد، تلاشی برای ارسال مجدد صورت نمی‌گیرد. با این حال، در برخی موارد نادر ممکن است تحویل دوگانه رخ دهد. برای مثال، اگر kubelet در میانه ارسال قلاب ری‌استارت شود، ممکن است پس از برگشت، قلاب دوباره ارسال شود. + +### اشکال‌زدایی هندلرهای قلاب + +لاگ‌های مربوط به هندلر قلاب در رویدادهای پاد نمایش داده نمی‌شوند. اگر به دلیلی اجرای هندلر با شکست مواجه شود، یک رویداد منتشر می‌شود. برای `PostStart` این رویداد `FailedPostStartHook` و برای `PreStop` این رویداد `FailedPreStopHook` است. برای ایجاد دستی یک رویداد `FailedPostStartHook`، فایل [lifecycle-events.yaml](https://k8s.io/examples/pods/lifecycle-events.yaml) را ویرایش کرده و فرمان postStart را به `"badcommand"` تغییر دهید و سپس آن را اعمال کنید. در ادامه نمونه‌ای از خروجی رویدادهایی که با اجرای `kubectl describe pod lifecycle-demo` مشاهده می‌کنید آمده است: + +``` +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal Scheduled 7s default-scheduler Successfully assigned default/lifecycle-demo to ip-XXX-XXX-XX-XX.us-east-2... + Normal Pulled 6s kubelet Successfully pulled image "nginx" in 229.604315ms + Normal Pulling 4s (x2 over 6s) kubelet Pulling image "nginx" + Normal Created 4s (x2 over 5s) kubelet Created container lifecycle-demo-container + Normal Started 4s (x2 over 5s) kubelet Started container lifecycle-demo-container + Warning FailedPostStartHook 4s (x2 over 5s) kubelet Exec lifecycle hook ([badcommand]) for Container "lifecycle-demo-container" in Pod "lifecycle-demo_default(30229739-9651-4e5a-9a32-a8f1688862db)" failed - error: command 'badcommand' exited with 126: , message: "OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: \"badcommand\": executable file not found in $PATH: unknown\r\n" + Normal Killing 4s (x2 over 5s) kubelet FailedPostStartHook + Normal Pulled 4s kubelet Successfully pulled image "nginx" in 215.66395ms + Warning BackOff 2s (x2 over 3s) kubelet Back-off restarting failed container +``` + + + +## {{% heading "whatsnext" %}} + + +* برای کسب اطلاعات بیشتر درباره [محیط کانتینر](/docs/concepts/containers/container-environment/) مطالعه کنید. +* تجربه عملی به‌دست آورید و با [پیوست هندلرها به رویدادهای چرخه‌عمر کانتینر](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) کار کنید. + diff --git a/content/fa/docs/concepts/containers/images.md b/content/fa/docs/concepts/containers/images.md new file mode 100644 index 0000000000000..b2b2de64c43d0 --- /dev/null +++ b/content/fa/docs/concepts/containers/images.md @@ -0,0 +1,437 @@ +--- +reviewers: +- xirehat +title: ایمیج‌ها +content_type: concept +weight: 10 +hide_summary: true # Listed separately in section index +--- + + + +یک ایمیج کانتینر نشان‌دهنده داده‌های باینری است که یک برنامه و همه وابستگی‌های نرم‌افزاری آن را در بر می‌گیرد. ایمیج‌های کانتینر بسته‌های نرم‌افزاری اجرایی هستند که می‌توانند به‌صورت مستقل اجرا شوند و مفروضات بسیار دقیقی درباره محیط اجرای خود داشته باشند. + +شما معمولاً ایمیج کانتینر برنامه خود را ایجاد و آن را به یک رجیستری پوش می‌کنید، سپس پیش از ارجاع به آن در یک {{< glossary_tooltip text="Pod" term_id="pod" >}}، از آن استفاده می‌کنید. + +این صفحه نمای کلی‌ای از مفهوم ایمیج کانتینر ارائه می‌دهد. + +{{< note >}} +اگر به دنبال ایمیج‌های کانتینر برای یک نسخه کوبرنتیز (مانند v{{< skew latestVersion >}}، آخرین ریزنسخه) هستید، به [دانلود کوبرنتیز](https://kubernetes.io/releases/download/) مراجعه کنید. +{{< /note >}} + + +## نام‌های ایمیج + +به ایمیج‌های کانتینر معمولاً نام‌هایی مانند `pause`، `example/mycontainer` یا `kube-apiserver` اختصاص داده می‌شود. +ایمیج‌ها می‌توانند شامل نام میزبان رجیستری نیز باشند؛ برای مثال: +`fictional.registry.example/imagename` +و حتی ممکن است یک شماره پورت نیز اضافه شود؛ برای مثال: +`fictional.registry.example:10443/imagename` + +اگر نام میزبان رجیستری را مشخص نکنید، Kubernetes فرض می‌کند که منظور شما [رجیستری عمومی Docker](https://hub.docker.com/) است. +می‌توانید این رفتار را با تنظیم یک رجیستری ایمیج پیش‌فرض در پیکربندی +[زمان‌اجرای کانتینر](/docs/setup/production-environment/container-runtimes/) +تغییر دهید. + +پس از بخش نام ایمیج، می‌توانید یک _tag_ یا _digest_ اضافه کنید (دقیقا مانند زمانی که با دستورات `docker` یا `podman` کار می‌کنید). +تگ‌ها به شما امکان می‌دهند نسخه‌های مختلف از یک سری ایمیج را شناسایی کنید. +دایجست‌ها (digests) شناسه‌ای یکتا برای یک نسخه مشخص از ایمیج هستند. +دایجست‌ها هش محتوای ایمیج بوده و تغییرناپذیرند. +تگ‌ها می‌توانند به ایمیج‌های مختلف اشاره کنند، اما دایجست‌ها ثابت هستند. + +تگ‌های ایمیج از حروف کوچک و بزرگ، ارقام، زیرخط (`_`)، نقطه (`.`) و خط تیره (`-`) تشکیل شده‌اند. +طول تگ می‌تواند تا ۱۲۸ نویسه باشد و باید با الگوی زیر مطابق باشد: + +[a-zA-Z0-9_][a-zA-Z0-9._-]{0,127} + +برای مطالعه بیشتر و مشاهده عبارت باقاعده اعتبارسنجی، به +[OCI Distribution Specification](https://github.com/opencontainers/distribution-spec/blob/master/spec.md#workflow-categories) +مراجعه کنید. +اگر تگی مشخص نکنید، Kubernetes فرض می‌کند منظور شما تگ `latest` است. + +دایجست‌های ایمیج شامل یک الگوریتم هش (مانند `sha256`) و یک مقدار هش هستند. برای مثال: + +sha256:1ff6c18fbef2045af6b9c16bf034cc421a29027b800e4f9b68ae9b1cb3e9ae07 + +برای اطلاعات بیشتر درباره فرمت دایجست، به +[OCI Image Specification](https://github.com/opencontainers/image-spec/blob/master/descriptor.md#digests) +مراجعه کنید. + +نمونه‌هایی از نام‌های ایمیجی که Kubernetes می‌تواند استفاده کند: + +- `busybox` — فقط نام ایمیج، بدون تگ یا دایجست. Kubernetes از رجیستری عمومی Docker و تگ latest استفاده می‌کند. معادل `docker.io/library/busybox:latest`. +- `busybox:1.32.0` — نام ایمیج به‌علاوه تگ. Kubernetes از رجیستری عمومی Docker استفاده می‌کند. معادل `docker.io/library/busybox:1.32.0`. +- `registry.k8s.io/pause:latest` — نام ایمیج با رجیستری سفارشی و تگ latest. +- `registry.k8s.io/pause:3.5` — نام ایمیج با رجیستری سفارشی و تگ غیر-latest. +- `registry.k8s.io/pause@sha256:1ff6c18fbef2045af6b9c16bf034cc421a29027b800e4f9b68ae9b1cb3e9ae07` — نام ایمیج به‌همراه دایجست. +- `registry.k8s.io/pause:3.5@sha256:1ff6c18fbef2045af6b9c16bf034cc421a29027b800e4f9b68ae9b1cb3e9ae07` — نام ایمیج با تگ و دایجست. در زمان pull، فقط دایجست استفاده می‌شود. + +## به‌روزرسانی ایمیج‌ها + +هنگامی که برای اولین بار یک {{< glossary_tooltip text="Deployment" term_id="deployment" >}}، {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}، پاد یا هر شیء دیگری که شامل یک PodTemplate است را ایجاد می‌کنید و سیاست کشیدن (pull policy) به‌طور صریح مشخص نشده باشد، به‌طور پیش‌فرض سیاست کشیدن تمام کانتینرهای آن پاد روی `IfNotPresent` تنظیم می‌شود. این سیاست باعث می‌شود kubelet در صورتی که ایمیج قبلاً وجود داشته باشد، از کشیدن آن صرف‌نظر کند. + +### سیاست دریافت ایمیج + +مقدار `imagePullPolicy` برای یک کانتینر و تگ ایمیج هر دو بر _زمانی_ که kubelet تلاش می‌کند ایمیج مشخص‌شده را بکشد (دانلود کند) تأثیر می‌گذارند. + +در اینجا فهرستی از مقادیری که می‌توانید برای `imagePullPolicy` تنظیم کنید و تأثیرات هر یک آمده است: + +`IfNotPresent` +: ایمیج تنها در صورتی کشیده می‌شود که قبلاً به‌صورت محلی موجود نباشد. + +`Always` +: هر بار که kubelet یک کانتینر را راه‌اندازی می‌کند، kubelet از رجیستری ایمیج کانتینر برای حل نام به یک + [دایجست](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier) + استفاده می‌کند. اگر kubelet قبلاً ایمیجی با آن دایجست دقیق را در کش محلی داشته باشد، از همان کش استفاده می‌کند؛ + در غیر این صورت، ایمیجی با دایجست حل‌شده را می‌کشد و با آن کانتینر را راه‌اندازی می‌کند. + +`Never` +: kubelet تلاش به دریافت ایمیج نمی‌کند. اگر ایمیج به‌هرصورت قبلاً به‌صورت محلی موجود باشد، kubelet سعی می‌کند کانتینر را + اجرا کند؛ در غیر این صورت، راه‌اندازی با شکست مواجه می‌شود. برای جزئیات بیشتر به بخش [ایمیج‌های از پیش کش‌شده](#pre-pulled-images) مراجعه کنید. + +سمانتیک کشing (cache) ارائه‌دهنده ایمیج زیرین باعث می‌شود حتی `imagePullPolicy: Always` نیز کارآمد باشد +تا زمانی که رجیستری به‌طور قابل‌اعتمادی در دسترس باشد. زمان‌اجرای کانتینر شما می‌تواند تشخیص دهد که لایه‌های +ایمیج قبلاً روی نود وجود دارند تا دوباره دانلود نشوند. + +{{< note >}} +در محیط تولید از تگ `:latest` خودداری کنید، زیرا ردیابی نسخه در حال اجرا دشوارتر است و بازگشت به نسخه قبلی پیچیده‌تر می‌شود. + +به جای آن از تگی معنادار مانند `v1.42.0` و/یا دایجست استفاده کنید. +{{< /note >}} + +برای اطمینان از اینکه پاد همیشه از یک نسخه مشخص از ایمیج استفاده کند، می‌توانید دایجست ایمیج را مشخص کنید؛ +`:` را با `@` جایگزین کنید +(مثال: `image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`). + +هنگام استفاده از تگ‌ها، اگر رجیستری ایمیج کد مربوط به آن تگ را تغییر دهد، ممکن است پادهای شما ترکیبی از کد قدیمی و جدید اجرا کنند. +دایجست ایمیج یک نسخه یکتا را مشخص می‌کند، بنابراین هر بار که Kubernetes با آن نام و دایجست ایمیج، کانتینری را اجرا کند، +کد یکسانی راه‌اندازی خواهد شد. مشخص کردن ایمیج با دایجست باعث قفل شدن کدی می‌شود که اجرا می‌کنید، +به‌طوری که تغییر در رجیستری نتواند منجر به اجرای همزمان نسخه‌های متفاوت شود. + +کنترل‌کننده‌های ورود ثالث ([admission controllers](/docs/reference/access-authn-authz/admission-controllers/)) وجود دارند که +هنگام ایجاد پاد (و PodTemplate) آن‌ها را اصلاح می‌کنند تا بارکاری در حال اجرا بر اساس دایجست ایمیج +و نه تگ تعریف شود. این ممکن است مفید باشد اگر بخواهید تمام بارکاری خود را تضمین کنید +که همیشه کد یکسانی اجرا کند، صرف‌نظر از تغییرات تگ در رجیستری. + +#### سیاست پیش‌فرض کشیدن ایمیج {#imagepullpolicy-defaulting} + +وقتی شما (یا یک کنترلر) پادی جدید را به API سرور ارسال می‌کنید، خوشه زمانی که شرایط مشخصی برقرار باشد، فیلد `imagePullPolicy` را تنظیم می‌کند: + +- اگر فیلد `imagePullPolicy` را حذف کنید و دایجست ایمیج کانتینر را مشخص کنید، `imagePullPolicy` به‌طور خودکار روی `IfNotPresent` تنظیم می‌شود. +- اگر فیلد `imagePullPolicy` را حذف کنید و تگ ایمیج کانتینر `:latest` باشد، `imagePullPolicy` به‌طور خودکار روی `Always` تنظیم می‌شود. +- اگر فیلد `imagePullPolicy` را حذف کنید و تگی برای ایمیج کانتینر مشخص نکنید، `imagePullPolicy` به‌طور خودکار روی `Always` تنظیم می‌شود. +- اگر فیلد `imagePullPolicy` را حذف کنید و تگی غیر از `:latest` برای ایمیج کانتینر مشخص کنید، `imagePullPolicy` به‌طور خودکار روی `IfNotPresent` تنظیم می‌شود. + +{{< note >}} +مقدار `imagePullPolicy` کانتینر همیشه هنگام _ایجاد_ اولیه شیء تنظیم می‌شود و در صورت تغییر بعدی تگ یا دایجست ایمیج، به‌روزرسانی نمی‌گردد. + +برای مثال، اگر یک Deployment با ایمیجی ایجاد کنید که تگش _نه_ `:latest` باشد و سپس آن Deployment را بروزرسانی کنید تا تگش به `:latest` تغییر یابد، فیلد `imagePullPolicy` _تغییر نخواهد کرد_ تا `Always`. برای تغییر سیاست کشیدن، باید پس از ایجاد اولیه هر شیء به‌صورت دستی آن را تنظیم کنید. +{{< /note >}} + +#### کشیدن اجباری ایمیج + +اگر می‌خواهید همیشه کشیدن ایمیج را اجباری کنید، می‌توانید یکی از اقدامات زیر را انجام دهید: + +- `imagePullPolicy` کانتینر را روی `Always` تنظیم کنید. +- `imagePullPolicy` را حذف کنید و از `:latest` به‌عنوان تگ ایمیج استفاده کنید؛ Kubernetes هنگام ارسال پاد، سیاست را به `Always` تنظیم می‌کند. +- `imagePullPolicy` و تگ ایمیج را حذف کنید؛ Kubernetes هنگام ارسال پاد، سیاست را به `Always` تنظیم می‌کند. +- کنترل‌کننده admission [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) را فعال کنید. + +### ImagePullBackOff + +وقتی kubelet برای پاد کانتینر می‌سازد، ممکن است کانتینر در وضعیت [Waiting](/docs/concepts/workloads/pods/pod-lifecycle/#container-state-waiting) به‌خاطر `ImagePullBackOff` قرار گیرد. + +وضعیت `ImagePullBackOff` به این معنی است که کانتینر نتوانسته شروع به کار کند زیرا Kubernetes نتوانسته ایمیج کانتینر را بکشد (برای دلایلی مانند نام نامعتبر ایمیج یا تلاش برای دریافت از رجیستری خصوصی بدون `imagePullSecret`). قسمت `BackOff` نشان می‌دهد که Kubernetes با تأخیر افزایشی همچنان تلاش به دریافت ایمیج خواهد کرد. + +Kubernetes تأخیر بین هر تلاش را افزایش می‌دهد تا به حد مشخصی برسد که برابر ۳۰۰ ثانیه (۵ دقیقه) است. + +### دریافت ایمیج بر اساس کلاس زمان‌اجرا + +{{< feature-state feature_gate_name="RuntimeClassInImageCriApi" >}} +Kubernetes از نسخه آلفا، پشتیبانی از دریافت ایمیج را بر اساس کلاس زمان‌اجرا (RuntimeClass) یک پاد ارائه می‌دهد. + +اگر [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) +`RuntimeClassInImageCriApi` را فعال کنید، kubelet ایمیج‌های کانتینر را بر اساس زوج نام ایمیج و هندلر زمان‌اجرا (runtime handler) مرجع می‌دهد، نه فقط نام ایمیج یا دایجست. +زمان‌اجرای شما ({{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}) ممکن است رفتار خود را بر اساس هندلر انتخاب‌شده تنظیم کند. +دریافت ایمیج بر اساس کلاس زمان‌اجرا برای کانتینرهای مبتنی بر ماشین مجازی، مانند کانتینرهای Windows Hyper-V، مفید است. + +## دریافت سریالی و موازی ایمیج‌ها + +به‌طور پیش‌فرض، kubelet ایمیج‌ها را سریالی (متوالی) می‌کشد. یعنی kubelet تنها یک درخواست دریافت ایمیج را در یک زمان به سرویس ایمیج ارسال می‌کند. سایر درخواست‌ها باید تا پایان پردازش درخواست جاری صبر کنند. + +نودها تصمیمات دریافت ایمیج را به‌صورت جداگانه . حتی در حالت سریالی‌سازی دریافت ایمیج، دو نود مختلف می‌توانند به‌طور موازی همان ایمیج را بکشند. + +اگر می‌خواهید دریافت ایمیج را به‌صورت موازی فعال کنید، می‌توانید فیلد `serializeImagePulls` را در [پیکربندی kubelet](/docs/reference/config-api/kubelet-config.v1beta1/) روی false تنظیم کنید. با `serializeImagePulls: false`، درخواست‌های دریافت ایمیج فوراً به سرویس ایمیج ارسال می‌شوند و چندین ایمیج به‌طور هم‌زمان کشیده می‌شوند. + +هنگام فعال کردن دریافت موازی ایمیج‌ها، مطمئن شوید که سرویس ایمیج زمان‌اجرای شما قادر به پردازش دریافت موازی ایمیج‌ها باشد. + +kubelet هرگز برای یک پاد چند ایمیج را به‌طور موازی نمی‌کشد. برای مثال، اگر پادی یک کانتینر init و یک کانتینر برنامه داشته باشد، دریافت ایمیج‌های این دو کانتینر موازی‌سازی نمی‌شود. اما اگر دو پاد با ایمیج‌های مختلف داشته باشید و ویژگی دریافت موازی فعال باشد، kubelet ایمیج‌های آن دو پاد را به‌طور موازی می‌کشد. + +### حداکثر تعداد دریافت موازی ایمیج + +{{< feature-state for_k8s_version="v1.32" state="beta" >}} + +وقتی `serializeImagePulls` روی false تنظیم شود، kubelet به‌طور پیش‌فرض هیچ محدودیتی برای حداکثر تعداد ایمیج‌هایی که هم‌زمان کشیده می‌شوند در نظر نمی‌گیرد. اگر بخواهید تعداد دریافت موازی ایمیج‌ها را محدود کنید، می‌توانید فیلد `maxParallelImagePulls` را در پیکربندی kubelet تعیین کنید. با تنظیم `maxParallelImagePulls` روی _n_، تنها _n_ ایمیج می‌توانند هم‌زمان کشیده شوند و هر درخواست دریافت ایمیج فراتر از _n_ باید تا اتمام حداقل یکی از دریافت‌های در حال انجام منتظر بماند. + +محدود کردن تعداد دریافت موازی ایمیج‌ها از مصرف بیش‌ازحد پهنای باند شبکه یا I/O دیسک جلوگیری می‌کند، زمانی که دریافت موازی ایمیج فعال باشد. + +می‌توانید `maxParallelImagePulls` را به عددی مثبت برابر یا بزرگ‌تر از ۱ تنظیم کنید. اگر آن را به عددی برابر یا بزرگ‌تر از ۲ تنظیم کنید، باید `serializeImagePulls` را روی false قرار دهید. در غیر این صورت، kubelet با تنظیم نامعتبر `maxParallelImagePulls` موفق به راه‌اندازی نخواهد شد. + +## ایمیج چندمعماری با ایندکس ایمیج + +علاوه بر ارائه‌ی ایمیج‌های باینری، یک رجیستری کانتینر می‌تواند یک +[ایندکس ایمیج کانتینر](https://github.com/opencontainers/image-spec/blob/master/image-index.md) +نیز سرو کند. ایندکس ایمیج می‌تواند به چندین +[مانیفست ایمیج](https://github.com/opencontainers/image-spec/blob/master/manifest.md) +برای نسخه‌های معماری‌محور یک کانتینر اشاره کند. ایده این است که شما می‌توانید +یک نام برای ایمیج داشته باشید (برای مثال: `pause`، `example/mycontainer`، `kube-apiserver`) +و اجازه دهید سیستم‌های مختلف، ایمیج باینری مناسب معماری ماشینی را که استفاده می‌کنند، دریافت کنند. + +پروژه‌ی Kubernetes معمولاً ایمیج‌های کانتینر برای نسخه‌های خود را با نام‌هایی حاوی پسوند `-$(ARCH)` می‌سازد. +برای سازگاری با نسخه‌های قدیمی‌تر، ایمیج‌های قدیمی‌تر را با پسوندهای مشخص تولید می‌کند. +برای مثال، ایمیجی با نام `pause` یک تصویر چندمعماری حاوی مانیفست برای همه‌ی معماری‌های پشتیبانی‌شده خواهد بود، +در حالی که `pause-amd64` نسخه‌ای سازگار با پیکربندی‌های قبلی یا فایل‌های YAML با نام سخت‌کدشده و پسوند است. + +## استفاده از رجیستری خصوصی + +رجیستری‌های خصوصی ممکن است برای کشف و/یا دریافت ایمیج‌ها از آن‌ها به احراز هویت نیاز داشته باشند. +اطلاعات اعتبار (Credentials) را می‌توان به چند روش فراهم کرد: + +- [تعریف `imagePullSecrets` هنگام تعریف یک پاد](#specifying-imagepullsecrets-on-a-pod) + تنها پادهایی که کلیدهای خود را ارائه می‌کنند می‌توانند به رجیستری خصوصی دسترسی پیدا کنند. + +- [پیکربندی نودها برای احراز هویت به یک رجیستری خصوصی](#configuring-nodes-to-authenticate-to-a-private-registry) + - همه‌ی پادها می‌توانند هر رجیستری خصوصی پیکربندی‌شده را بخوانند. + - نیازمند پیکربندی نود توسط مدیر خوشه است. + +- استفاده از افزونه‌ی _kubelet credential provider_ برای [دریافت پویا اعتبارنامه‌ها برای رجیستری‌های خصوصی](#kubelet-credential-provider) + می‌توان kubelet را طوری پیکربندی کرد که از افزونه‌ی اجرایی Credential Provider برای + رجیستری خصوصی مربوطه استفاده کند. + +- [ایمیج‌های از پیش دریافت‌شده](#pre-pulled-images) + - همه پادها می‌توانند از هر ایمیجی که روی نود کش شده است استفاده کنند. + - نیازمند دسترسی root به تمام نودها برای پیکربندی. +- افزونه‌های مخصوص فروشنده یا محلی + + اگر از پیکربندی نود سفارشی استفاده می‌کنید، شما (یا ارائه‌دهنده خدمات ابری شما) می‌توانید مکانیزم خود را برای احراز هویت نود به رجیستری کانتینر پیاده‌سازی کنید. + +این گزینه‌ها در ادامه با جزئیات بیشتری توضیح داده شده‌اند. + +### مشخص کردن `imagePullSecrets` در پاد + +{{< note >}} +این روش توصیه‌شده برای اجرای کانتینرها بر اساس ایمیج‌های موجود در رجیستری‌های خصوصی است. +{{< /note >}} + +Kubernetes از مشخص کردن کلیدهای رجیستری ایمیج کانتینر در پاد پشتیبانی می‌کند. +تمام `imagePullSecrets` باید Secretهایی باشند که در همان +{{< glossary_tooltip term_id="namespace" >}} +پاد وجود دارند. این Secretها باید از نوع `kubernetes.io/dockercfg` یا `kubernetes.io/dockerconfigjson` باشند. + +### پیکربندی نودها برای احراز هویت به یک رجیستری خصوصی + +دستورالعمل‌های خاص برای تنظیم اعتبارنامه‌ها به زمان‌اجرای کانتینر و رجیستری مورد استفاده شما بستگی دارد. برای دقیق‌ترین اطلاعات به مستندات راه‌حل خود مراجعه کنید. + +برای مثال پیکربندی یک رجیستری ایمیج کانتینر خصوصی، به تسک +[Pull an Image from a Private Registry](/docs/tasks/configure-pod-container/pull-image-private-registry) +مراجعه کنید. آن مثال از یک رجیستری خصوصی در Docker Hub استفاده می‌کند. + +### افزونه‌ی اعتبارنامه kubelet برای دریافت ایمیج‌های احراز هویت‌شده {#kubelet-credential-provider} + +می‌توانید kubelet را طوری پیکربندی کنید که یک باینری افزونه را فراخوانی کند تا به‌صورت پویا اعتبارنامه‌های رجیستری را برای یک ایمیج کانتینر دریافت کند. این روش مقاوم‌ترین و چندمنظوره‌ترین راه برای دریافت اعتبارنامه‌ها برای رجیستری‌های خصوصی است، اما نیاز به پیکربندی در سطح kubelet دارد. + +این تکنیک می‌تواند برای اجرای {{< glossary_tooltip term_id="static-pod" text="static Pods" >}} که نیاز به ایمیج‌های کانتینر میزبانی‌شده در یک رجیستری خصوصی دارند، بسیار مفید باشد. استفاده از {{< glossary_tooltip term_id="service-account" >}} یا {{< glossary_tooltip term_id="secret" >}} برای ارائه اعتبارنامه‌های رجیستری خصوصی در مشخصات یک پاد ایستا ممکن نیست، زیرا پاد ایستا نمی‌تواند به منابع API دیگر در مشخصات خود ارجاع دهد. + +برای جزئیات بیشتر، به [Configure a kubelet image credential provider](/docs/tasks/administer-cluster/kubelet-credential-provider/) مراجعه کنید. + +### تفسیر فایل config.json {#config-json} + +تفسیر `config.json` بین پیاده‌سازی اصلی Docker و تفسیر Kubernetes متفاوت است. در Docker، کلیدهای `auths` تنها می‌توانند URLهای ریشه‌ای را مشخص کنند، در حالی که Kubernetes علاوه بر مسیرهای مطابقت پیشوندی، از URLهای الگو (glob) نیز پشتیبانی می‌کند. تنها محدودیت این است که الگوهای glob (`*`) باید برای هر زیردامنه شامل نقطه (`.`) باشند. تعداد زیردامنه‌های مطابقت‌شده باید برابر با تعداد الگوهای glob (`*.`) باشد. برای مثال: + +- `*.kubernetes.io` با `kubernetes.io` **مطابقت ندارد**، اما با `abc.kubernetes.io` **مطابقت می‌کند**. +- `*.*.kubernetes.io` با `abc.kubernetes.io` **مطابقت ندارد**، اما با `abc.def.kubernetes.io` **مطابقت می‌کند**. +- `prefix.*.io` با `prefix.kubernetes.io` **مطابقت می‌کند**. +- `*-good.kubernetes.io` با `prefix-good.kubernetes.io` **مطابقت می‌کند**. + +این بدان معناست که `config.json` زیر معتبر است: + +```json +{ + "auths": { + "my-registry.example/images": { "auth": "…" }, + "*.my-registry.example/images": { "auth": "…" } + } +} +``` + +عملیات دریافت ایمیج، اطلاعات اعتبار (Credentials) را برای هر الگوی معتبر به زمان‌اجرای کانتینر CRI ارسال می‌کند. برای مثال، نام‌های ایمیجی زیر با موفقیت مطابقت پیدا می‌کنند: + +- `my-registry.example/images` +- `my-registry.example/images/my-image` +- `my-registry.example/images/another-image` +- `sub.my-registry.example/images/my-image` + +اما این نام‌های ایمیج **مطابقت نخواهند داشت**: + +- `a.sub.my-registry.example/images/my-image` +- `a.b.sub.my-registry.example/images/my-image` + +kubelet عملیات دریافت ایمیج را به‌صورت متوالی برای هر اعتبارنامه یافت‌شده انجام می‌دهد. این بدان معناست که می‌توانید چندین ورودی مختلف در `config.json` برای مسیرهای گوناگون داشته باشید: + +```json +{ + "auths": { + "my-registry.example/images": { + "auth": "…" + }, + "my-registry.example/images/subpath": { + "auth": "…" + } + } +} +``` + +اگر اکنون یک کانتینر مشخص کند ایمیج `my-registry.example/images/subpath/my-image` باید دریافت شود، آنگاه kubelet تلاش می‌کند آن را با استفاده از هر دو منبع احراز هویت دانلود کند و اگر یکی از آن‌ها شکست بخورد، از دیگری استفاده کند. + +### ایمیج‌های از پیش دریافت‌شده + +{{< note >}} +این روش مناسب است اگر بتوانید پیکربندی نودها را کنترل کنید. اگر ارائه‌دهنده ابری شما نودها را مدیریت کرده و آن‌ها را به‌طور خودکار جایگزین کند، به‌طور قابل‌اعتمادی کار نخواهد کرد. +{{< /note >}} + +به‌طور پیش‌فرض، kubelet سعی می‌کند هر ایمیج را از رجیستری مشخص‌شده دریافت کند. با این حال، اگر ویژگی `imagePullPolicy` کانتینر روی `IfNotPresent` یا `Never` تنظیم شده باشد، ایمیج محلی استفاده می‌شود (به‌ترتیب، به‌طور ترجیحی یا انحصاری). + +اگر می‌خواهید به‌جای احراز هویت به رجیستری، به ایمیج‌های از پیش دریافت‌شده متکی باشید، باید مطمئن شوید که همه نودهای خوشه همان ایمیج‌های از پیش دریافت‌شده را دارند. + +این روش می‌تواند برای بارگذاری اولیه برخی ایمیج‌ها به‌منظور افزایش سرعت یا به‌عنوان جایگزینی برای احراز هویت به رجیستری خصوصی استفاده شود. + +مشابه استفاده از [kubelet credential provider](#kubelet-credential-provider)، ایمیج‌های از پیش دریافت‌شده همچنین برای راه‌اندازی {{< glossary_tooltip text="static Pods" term_id="static-pod" >}} که به ایمیج‌های میزبانی‌شده در رجیستری خصوصی وابسته‌اند مناسب هستند. + +{{< note >}} +{{< feature-state feature_gate_name="KubeletEnsureSecretPulledImages" >}} +دسترسی به ایمیج‌های از پیش دریافت‌شده ممکن است بر اساس [اعتبارسنجی اعتبارنامه دریافت ایمیج](#ensureimagepullcredentialverification) مجاز باشد. +{{< /note >}} + +#### اطمینان از اعتبارسنجی اعتبارنامه‌های دریافت ایمیج {#ensureimagepullcredentialverification} + +{{< feature-state feature_gate_name="KubeletEnsureSecretPulledImages" >}} + +اگر feature gate `KubeletEnsureSecretPulledImages` برای خوشه شما فعال باشد، Kubernetes اعتبارنامه‌های دریافت ایمیج را برای هر ایمیجی که نیاز به اعتبارنامه برای دریافت دارد، حتی اگر آن ایمیج قبلاً روی نود موجود باشد، اعتبارسنجی می‌کند. این اعتبارسنجی تضمین می‌کند که ایمیج‌هایی که در یک درخواست پاد وجود دارند و با اعتبارنامه‌های ارائه‌شده با موفقیت دریافت نشده‌اند، باید مجدداً از رجیستری دریافت شوند. علاوه بر این، دریافت ایمیج‌هایی که از همان اعتبارنامه‌ای استفاده می‌کنند که پیش‌تر منجر به دریافت موفق شده است، نیازی به دریافت مجدد از رجیستری ندارند و در عوض به‌صورت محلی اعتبارسنجی می‌شوند (مشروط بر اینکه ایمیج به‌صورت محلی موجود باشد). +این موضوع توسط فیلد `imagePullCredentialsVerificationPolicy` در [پیکربندی Kubelet](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-ImagePullCredentialsVerificationPolicy) کنترل می‌شود. + +این پیکربندی تعیین می‌کند که چه زمانی اعتبارنامه‌های دریافت ایمیج باید اعتبارسنجی شوند اگر ایمیج قبلاً روی نود موجود باشد: + +* `NeverVerify`: رفتار معادل غیرفعال بودن این feature gate را شبیه‌سازی می‌کند. اگر ایمیج به‌صورت محلی موجود باشد، اعتبارنامه‌های دریافت ایمیج اعتبارسنجی نمی‌شوند. +* `NeverVerifyPreloadedImages`: ایمیج‌هایی که خارج از kubelet دریافت شده‌اند، اعتبارسنجی نمی‌شوند، اما همه ایمیج‌های دیگر اعتبارنامه‌هایشان اعتبارسنجی می‌شود. این رفتار پیش‌فرض است. +* `NeverVerifyAllowListedImages`: ایمیج‌هایی که خارج از kubelet دریافت شده‌اند و در لیست `preloadedImagesVerificationAllowlist` مشخص‌شده در پیکربندی kubelet آمده‌اند، اعتبارسنجی نمی‌شوند. +* `AlwaysVerify`: همه ایمیج‌ها قبل از استفاده، اعتبارنامه‌هایشان اعتبارسنجی می‌شود. + +این اعتبارسنجی شامل [ایمیج‌های از پیش دریافت‌شده](#pre-pulled-images)، ایمیج‌هایی که با استفاده از Secretهای سراسری نود دریافت شده‌اند، و ایمیج‌هایی که با استفاده از Secretهای سطح پاد دریافت شده‌اند، می‌شود. + +{{< note >}} +در صورت گردش اعتبارنامه‌ها، اعتبارنامه‌های قبلاً استفاده‌شده برای دریافت ایمیج بدون نیاز به دسترسی به رجیستری همچنان اعتبارسنجی می‌شوند. اعتبارنامه‌های جدید یا گردش‌یافته نیاز به دریافت مجدد ایمیج از رجیستری خواهند داشت. +{{< /note >}} + +#### ایجاد یک راز با پیکربندی Docker + +برای احراز هویت در رجیستری، باید نام کاربری، رمز عبور رجیستری و آدرس ایمیل کلاینت و همچنین نام میزبان آن را بدانید. + +دستور زیر را اجرا کنید و مقادیر مناسب را جایگزین متغیرهای جایگزین کنید: + +```shell +kubectl create secret docker-registry \ + --docker-server= \ + --docker-username= \ + --docker-password= \ + --docker-email= +``` + +اگر قبلاً یک فایل اعتبارنامه Docker دارید، به‌جای استفاده از دستور بالا می‌توانید فایل اعتبارنامه را به‌عنوان یک {{< glossary_tooltip text="Secret" term_id="secret" >}} در Kubernetes وارد (import) کنید. دستورالعمل [ایجاد Secret بر اساس اعتبارنامه‌های موجود Docker](/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) نحوه انجام این کار را توضیح می‌دهد. + +این روش زمانی که از چندین رجیستری کانتینر خصوصی استفاده می‌کنید بسیار مفید است، زیرا دستور `kubectl create secret docker-registry` یک Secret ایجاد می‌کند که فقط با یک رجیستری خصوصی کار می‌کند. + +{{< note >}} +پادها تنها می‌توانند به imagePullSecrets در همان namespace خود ارجاع دهند، بنابراین این فرآیند باید برای هر namespace یک‌بار انجام شود. +{{< /note >}} + +#### ارجاع به `imagePullSecrets` در یک پاد + +اکنون می‌توانید پادهایی ایجاد کنید که با افزودن بخش `imagePullSecrets` به تعریف پاد، به آن Secret ارجاع دهند. هر آیتم در آرایه `imagePullSecrets` فقط می‌تواند به یک Secret در همان namespace اشاره کند. + +برای مثال: +```shell +cat < pod.yaml +apiVersion: v1 +kind: Pod +metadata: + name: foo + namespace: awesomeapps +spec: + containers: + - name: foo + image: janedoe/awesomeapp:v1 + imagePullSecrets: + - name: myregistrykey +EOF + +cat <> ./kustomization.yaml +resources: +- pod.yaml +EOF +``` + +برای هر پادی که از یک رجیستری خصوصی استفاده می‌کند باید این کار انجام شود. + +با این حال، می‌توانید این فرآیند را با مشخص کردن بخش `imagePullSecrets` +در یک منبع [ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/) خودکار کنید. +برای دستورالعمل‌های دقیق‌تر به بخش +[افزودن ImagePullSecrets به یک Service Account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) +مراجعه کنید. + +می‌توانید این روش را همراه با یک فایل `.docker/config.json` به ازای هر نود استفاده کنید. +اعتبارنامه‌ها با هم ادغام خواهند شد. + +## موارد استفاده + +راه‌حل‌های متعددی برای پیکربندی رجیستری‌های خصوصی وجود دارد. در اینجا برخی موارد رایج و راه‌حل‌های پیشنهاد‌شده آمده‌اند: + +1. خوشه‌ای که تنها از ایمیج‌های غیرخصوصی (مثلاً متن‌باز) استفاده می‌کند و نیازی به پنهان کردن ایمیج‌ها نیست. + - از ایمیج‌های عمومی در یک رجیستری عمومی استفاده کنید + - پیکربندی لازم نیست. + - برخی ارائه‌دهندگان ابری به‌طور خودکار ایمیج‌های عمومی را کش یا میران کنند که دسترسی‌پذیری را بهبود و زمان دریافت را کاهش می‌دهد. +1. خوشه‌ای که برخی ایمیج‌های اختصاصی دارد که باید از کاربران خارج شرکت پنهان باشد اما برای همه کاربران خوشه قابل مشاهده باشد. + - از رجیستری خصوصی میزبانی‌شده استفاده کنید + - ممکن است نیاز به پیکربندی دستی روی نودهایی باشد که باید به رجیستری خصوصی دسترسی داشته باشند. + - یا، یک رجیستری خصوصی داخلی پشت فایروال خود با دسترسی خواندن باز اجرا کنید. + - نیازی به پیکربندی Kubernetes نیست. + - از سرویس رجیستری ایمیج میزبانی‌شده‌ای استفاده کنید که دسترسی به ایمیج را کنترل می‌کند + - با autoscaling نود بهتر از پیکربندی دستی نودها کار می‌کند. + - یا، در خوشه‌ای که تغییر پیکربندی نودها دشوار است، از `imagePullSecrets` استفاده کنید. +1. خوشه‌ای با ایمیج‌های اختصاصی که برخی از آن‌ها نیاز به کنترل دسترسی سخت‌گیرانه‌تر دارند. + - مطمئن شوید کنترل‌کننده admission [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) + فعال است؛ در غیر این صورت، همه پادها ممکن است به همه ایمیج‌ها دسترسی داشته باشند. + - داده‌های حساس را به یک منبع Secret انتقال دهید، به جای بسته‌بندی در ایمیج. +1. خوشه چندمستأجری که هر مستأجر نیاز به رجیستری خصوصی خود دارد. + - مطمئن شوید کنترل‌کننده admission [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) + فعال است؛ در غیر این صورت، همه پادهای همه مستأجران ممکن است به همه ایمیج‌ها دسترسی داشته باشند. + - یک رجیستری خصوصی با احراز هویت مورد نیاز اجرا کنید. + - برای هر مستأجر اعتبارنامه رجیستری تولید کنید، در یک Secret ذخیره و آن Secret را به همه namespaceهای مستأجر انتقال دهید. + - سپس مستأجر آن Secret را به `imagePullSecrets` هر namespace اضافه می‌کند. + +اگر به چندین رجیستری نیاز دارید، می‌توانید برای هر رجیستری یک Secret جداگانه ایجاد کنید. + +## ارائه‌دهنده اعتبارنامه داخلی قدیمی kubelet + +در نسخه‌های قدیمی‌تر Kubernetes، kubelet با اعتبارنامه‌های ارائه‌دهنده ابری یکپارچه بود. این امکان را فراهم می‌کرد که به‌صورت پویا اعتبارنامه‌ها برای رجیستری‌های ایمیج دریافت شوند. + +سه پیاده‌سازی داخلی از ارائه‌دهنده اعتبارنامه kubelet وجود داشت: ACR (Azure Container Registry)، ECR (Elastic Container Registry)، و GCR (Google Container Registry). + +از نسخه 1.26 Kubernetes به بعد، این مکانیزم قدیمی حذف شده است، بنابراین باید یکی از کارهای زیر را انجام دهید: +- پیکربندی یک ارائه‌دهنده اعتبارنامه kubelet برای ایمیج روی هر نود؛ یا +- مشخص کردن اعتبارنامه‌های دریافت ایمیج با استفاده از `imagePullSecrets` و حداقل یک Secret. + +## {{% heading "whatsnext" %}} + +* مستند [OCI Image Manifest Specification](https://github.com/opencontainers/image-spec/blob/main/manifest.md) را مطالعه کنید. +* درباره [جمع‌آوری زباله ایمیج‌های کانتینر](/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection) بیشتر بیاموزید. +* اطلاعات بیشتری درباره [دریافت ایمیج از رجیستری خصوصی](/docs/tasks/configure-pod-container/pull-image-private-registry) کسب کنید. diff --git a/content/fa/docs/concepts/containers/runtime-class.md b/content/fa/docs/concepts/containers/runtime-class.md new file mode 100644 index 0000000000000..3002e01d35973 --- /dev/null +++ b/content/fa/docs/concepts/containers/runtime-class.md @@ -0,0 +1,138 @@ +--- +reviewers: + - xirehat +title: کلاس زمان اجرا +content_type: concept +weight: 30 +hide_summary: true # Listed separately in section index +--- + + + +{{< feature-state for_k8s_version="v1.20" state="stable" >}} + +این صفحه مکانیزم انتخاب منبع و زمان اجرا در RuntimeClass را شرح می‌دهد. + +RuntimeClass قابلیتی برای انتخاب پیکربندی زمان اجرای کانتینر است. پیکربندی زمان اجرای کانتینر برای اجرای کانتینرهای یک Pod استفاده می‌شود. + + + +## انگیزه + +شما می‌توانید یک RuntimeClass متفاوت بین Podهای مختلف تنظیم کنید تا تعادلی بین عملکرد و امنیت برقرار شود. به عنوان مثال، اگر بخشی از حجم کاری شما نیاز به سطح بالایی از تضمین امنیت اطلاعات دارد، می‌توانید آن Podها را طوری زمان‌بندی کنید که در یک زمان اجرای کانتینر که از مجازی‌سازی سخت‌افزار استفاده می‌کند، اجرا شوند. در این صورت، از ایزوله بودن بیشتر زمان اجرای جایگزین، به قیمت مقداری سربار اضافی، بهره‌مند خواهید شد. + +همچنین می‌توانید از RuntimeClass برای اجرای Podهای مختلف با زمان اجرای کانتینر یکسان اما با تنظیمات متفاوت استفاده کنید. + +## راه‌اندازی + +1. پیکربندی پیاده‌سازی CRI روی گره‌ها (وابسته به زمان اجرا) + +2. ایجاد منابع RuntimeClass مربوطه + +### 2. پیکربندی پیاده‌سازی CRI روی گره‌ها + +پیکربندی‌های موجود از طریق RuntimeClass به پیاده‌سازی رابط زمان اجرای کانتینر (CRI) وابسته هستند. برای نحوه پیکربندی، به مستندات مربوطه ([below](#cri-configuration)) برای پیاده‌سازی CRI خود مراجعه کنید. + +{{< note >}} +RuntimeClass به‌طور پیش‌فرض فرض می‌کند که پیکربندی نودها در سراسر خوشه همگن است (به این معنی که همه نودها از نظر زمان‌اجرای کانتینرها به یک شکل پیکربندی شده‌اند). برای پشتیبانی از پیکربندی‌های ناهمگن نود، به بخش [زمان‌بندی](#scheduling) در پایین مراجعه کنید. +{{< /note >}} + +پیکربندی‌ها نام `handler` متناظری دارند که توسط RuntimeClass ارجاع داده می‌شود. +این `handler` باید یک [نام برچسب DNS](/docs/concepts/overview/working-with-objects/names/#dns-label-names) معتبر باشد. + +### 2. ایجاد منابع متقابل RuntimeClass + +هر یک از پیکربندی‌هایی که در مرحله ۱ تنظیم شدند، باید یک نام `handler` مرتبط داشته باشند که پیکربندی را شناسایی کند. برای هر `handler`، یک شیء RuntimeClass متناظر ایجاد کنید. + +منبع RuntimeClass در حال حاضر تنها دو فیلد مهم دارد: نام RuntimeClass (`metadata.name`) و `handler`. تعریف شیء به این صورت است: +```yaml +# RuntimeClass is defined in the node.k8s.io API group +apiVersion: node.k8s.io/v1 +kind: RuntimeClass +metadata: + # The name the RuntimeClass will be referenced by. + # RuntimeClass is a non-namespaced resource. + name: myclass +# The name of the corresponding CRI configuration +handler: myconfiguration +``` + +نام یک شیء RuntimeClass باید یک [نام زیردامنه DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) معتبر باشد. + +{{< note >}} +توصیه می‌شود عملیات نوشتن روی RuntimeClass (ایجاد/به‌روزرسانی/پچ/حذف) محدود به مدیر خوشه باشد. این معمولاً پیش‌فرض است. برای جزئیات بیشتر به [مروری بر مجوزدهی](/docs/reference/access-authn-authz/authorization/) مراجعه کنید. +{{< /note >}} + +## استفاده + +پس از پیکربندی RuntimeClassها برای خوشه، می‌توانید در مشخصات پاد، `runtimeClassName` را برای استفاده از آن تعیین کنید. برای مثال: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + runtimeClassName: myclass + # ... +``` + +این دستور به kubelet می‌گوید که برای اجرای این پاد از RuntimeClass مشخص‌شده استفاده کند. اگر RuntimeClass مشخص‌شده وجود نداشته باشد یا CRI نتواند هندلر مربوطه را اجرا کند، پاد وارد [فاز نهایی](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) `Failed` می‌شود. برای مشاهده پیام خطا، به [رویداد مربوطه](/docs/tasks/debug/debug-application/debug-running-pod/) مراجعه کنید. + +اگر `runtimeClassName` مشخص نشود، از RuntimeHandler پیش‌فرض استفاده خواهد شد که معادل رفتار هنگام غیرفعال بودن قابلیت RuntimeClass است. + +### پیکربندی CRI + +برای جزئیات بیشتر در مورد تنظیم زمان‌اجراهای CRI، به [نصب CRI](/docs/setup/production-environment/container-runtimes/) مراجعه کنید. + +#### {{< glossary_tooltip term_id="containerd" >}} + +هندلرهای زمان‌اجرا از طریق پیکربندی containerd در مسیر +`/etc/containerd/config.toml` تعریف می‌شوند. هندلرهای معتبر در بخش `runtimes` پیکربندی می‌شوند: + +``` +[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}] +``` + +برای مشاهده جزئیات بیشتر به مستندات پیکربندی [containerd](https://github.com/containerd/containerd/blob/main/docs/cri/config.md) مراجعه کنید: + +#### {{< glossary_tooltip term_id="cri-o" >}} + +هندلرهای زمان‌اجرا از طریق پیکربندی CRI-O در مسیر `/etc/crio/crio.conf` تنظیم می‌شوند. هندلرهای معتبر در جدول [crio.runtime](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table) پیکربندی می‌شوند: + +``` +[crio.runtime.runtimes.${HANDLER_NAME}] + runtime_path = "${PATH_TO_BINARY}" +``` + +برای جزئیات بیشتر به مستندات پیکربندی CRI-O در [اینجا](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md) مراجعه کنید. + +## زمان‌بندی + +{{< feature-state for_k8s_version="v1.16" state="beta" >}} + +با مشخص کردن فیلد `scheduling` برای یک RuntimeClass، می‌توانید قیدهایی تعریف کنید تا اطمینان حاصل شود پادهایی که با این RuntimeClass اجرا می‌شوند، روی نودهایی زمان‌بندی شوند که از آن پشتیبانی می‌کنند. اگر `scheduling` تنظیم نشود، فرض بر این است که این RuntimeClass توسط همه نودها پشتیبانی می‌شود. + +برای اطمینان از اینکه پادها روی نودهای پشتیبانی‌کننده از یک RuntimeClass خاص قرار بگیرند، آن مجموعه نودها باید یک برچسب مشترک داشته باشند که سپس توسط فیلد `runtimeclass.scheduling.nodeSelector` انتخاب شود. nodeSelector مربوط به RuntimeClass در مرحله admission با nodeSelector پاد ترکیب می‌شود و در واقع اشتراک مجموعه نودهای انتخاب‌شده توسط هر دو گرفته می‌شود. اگر تعارضی وجود داشته باشد، پاد رد خواهد شد. + +اگر نودهای پشتیبانی‌کننده به‌منظور جلوگیری از اجرای سایر پادهای RuntimeClass روی آن نود، تِینت (taint) شده باشند، می‌توانید `tolerations` را به RuntimeClass اضافه کنید. همانند `nodeSelector`، tolerations نیز در admission با tolerations پاد ترکیب می‌شود و در واقع اجتماع مجموعه نودهای مورد تحمل هر دو گرفته می‌شود. + +برای آشنایی بیشتر با پیکربندی node selector و tolerations، به بخش +[اختصاص پادها به نودها](/docs/concepts/scheduling-eviction/assign-pod-node/) +مراجعه کنید. + +### سربار پاد + +{{< feature-state for_k8s_version="v1.24" state="stable" >}} + +شما می‌توانید منابع _سربار_ مرتبط با اجرای یک پاد را مشخص کنید. اعلام سربار به خوشه (شامل scheduler) اجازه می‌دهد در تصمیم‌گیری‌ها درباره پادها و منابع، آن را لحاظ کند. + +سربار پاد در RuntimeClass از طریق فیلد `overhead` تعریف می‌شود. با استفاده از این فیلد می‌توانید سربار اجرای پادهایی که از این RuntimeClass استفاده می‌کنند را مشخص کرده و اطمینان حاصل کنید که این سربارها در Kubernetes لحاظ شوند. + +## {{% heading "whatsnext" %}} + +- [طراحی RuntimeClass](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md) +- [طراحی زمان‌بندی RuntimeClass](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling) +- درباره مفهوم [سربار پاد](/docs/concepts/scheduling-eviction/pod-overhead/) مطالعه کنید +- [طراحی ویژگی PodOverhead](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead) + diff --git a/content/fa/docs/concepts/extend-kubernetes/_index.md b/content/fa/docs/concepts/extend-kubernetes/_index.md new file mode 100644 index 0000000000000..c021da4e2b92d --- /dev/null +++ b/content/fa/docs/concepts/extend-kubernetes/_index.md @@ -0,0 +1,334 @@ +--- +title: گسترش کوبرنتیز +weight: 999 # this section should come last +description: روش‌های مختلف برای تغییر رفتار خوشه کوبرنتیز شما. +reviewers: +- xirehat +feature: + title: طراحی شده برای توسعه‌پذیری + description: > + بدون تغییر کد منبع بالادست، ویژگی‌هایی را به خوشه کوبرنتیز خود اضافه کنید. +content_type: concept +no_list: true +--- + + + +Kubernetes is highly configurable and extensible. As a result, there is rarely a need to fork or +submit patches to the Kubernetes project code. + +This guide describes the options for customizing a Kubernetes cluster. It is aimed at +{{< glossary_tooltip text="cluster operators" term_id="cluster-operator" >}} who want to understand +how to adapt their Kubernetes cluster to the needs of their work environment. Developers who are +prospective {{< glossary_tooltip text="Platform Developers" term_id="platform-developer" >}} or +Kubernetes Project {{< glossary_tooltip text="Contributors" term_id="contributor" >}} will also +find it useful as an introduction to what extension points and patterns exist, and their +trade-offs and limitations. + +Customization approaches can be broadly divided into [configuration](#configuration), which only +involves changing command line arguments, local configuration files, or API resources; and [extensions](#extensions), +which involve running additional programs, additional network services, or both. +This document is primarily about _extensions_. + + + +## Configuration + +*Configuration files* and *command arguments* are documented in the [Reference](/docs/reference/) section of the online +documentation, with a page for each binary: + +* [`kube-apiserver`](/docs/reference/command-line-tools-reference/kube-apiserver/) +* [`kube-controller-manager`](/docs/reference/command-line-tools-reference/kube-controller-manager/) +* [`kube-scheduler`](/docs/reference/command-line-tools-reference/kube-scheduler/) +* [`kubelet`](/docs/reference/command-line-tools-reference/kubelet/) +* [`kube-proxy`](/docs/reference/command-line-tools-reference/kube-proxy/) + +Command arguments and configuration files may not always be changeable in a hosted Kubernetes service or a +distribution with managed installation. When they are changeable, they are usually only changeable +by the cluster operator. Also, they are subject to change in future Kubernetes versions, and +setting them may require restarting processes. For those reasons, they should be used only when +there are no other options. + +Built-in *policy APIs*, such as [ResourceQuota](/docs/concepts/policy/resource-quotas/), +[NetworkPolicy](/docs/concepts/services-networking/network-policies/) and Role-based Access Control +([RBAC](/docs/reference/access-authn-authz/rbac/)), are built-in Kubernetes APIs that provide declaratively configured policy settings. +APIs are typically usable even with hosted Kubernetes services and with managed Kubernetes installations. +The built-in policy APIs follow the same conventions as other Kubernetes resources such as Pods. +When you use a policy APIs that is [stable](/docs/reference/using-api/#api-versioning), you benefit from a +[defined support policy](/docs/reference/using-api/deprecation-policy/) like other Kubernetes APIs. +For these reasons, policy APIs are recommended over *configuration files* and *command arguments* where suitable. + +## Extensions + +Extensions are software components that extend and deeply integrate with Kubernetes. +They adapt it to support new types and new kinds of hardware. + +Many cluster administrators use a hosted or distribution instance of Kubernetes. +These clusters come with extensions pre-installed. As a result, most Kubernetes +users will not need to install extensions and even fewer users will need to author new ones. + +### Extension patterns + +Kubernetes is designed to be automated by writing client programs. Any +program that reads and/or writes to the Kubernetes API can provide useful +automation. *Automation* can run on the cluster or off it. By following +the guidance in this doc you can write highly available and robust automation. +Automation generally works with any Kubernetes cluster, including hosted +clusters and managed installations. + +There is a specific pattern for writing client programs that work well with +Kubernetes called the {{< glossary_tooltip term_id="controller" text="controller" >}} +pattern. Controllers typically read an object's `.spec`, possibly do things, and then +update the object's `.status`. + +A controller is a client of the Kubernetes API. When Kubernetes is the client and calls +out to a remote service, Kubernetes calls this a *webhook*. The remote service is called +a *webhook backend*. As with custom controllers, webhooks do add a point of failure. + +{{< note >}} +Outside of Kubernetes, the term “webhook” typically refers to a mechanism for asynchronous +notifications, where the webhook call serves as a one-way notification to another system or +component. In the Kubernetes ecosystem, even synchronous HTTP callouts are often +described as “webhooks”. +{{< /note >}} + +In the webhook model, Kubernetes makes a network request to a remote service. +With the alternative *binary Plugin* model, Kubernetes executes a binary (program). +Binary plugins are used by the kubelet (for example, [CSI storage plugins](https://kubernetes-csi.github.io/docs/) +and [CNI network plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)), +and by kubectl (see [Extend kubectl with plugins](/docs/tasks/extend-kubectl/kubectl-plugins/)). + +### Extension points + +This diagram shows the extension points in a Kubernetes cluster and the +clients that access it. + + + +{{< figure src="/docs/concepts/extend-kubernetes/extension-points.png" + alt="Symbolic representation of seven numbered extension points for Kubernetes" + class="diagram-large" caption="Kubernetes extension points" >}} + +#### Key to the figure + +1. Users often interact with the Kubernetes API using `kubectl`. [Plugins](#client-extensions) + customise the behaviour of clients. There are generic extensions that can apply to different clients, + as well as specific ways to extend `kubectl`. + +1. The API server handles all requests. Several types of extension points in the API server allow + authenticating requests, or blocking them based on their content, editing content, and handling + deletion. These are described in the [API Access Extensions](#api-access-extensions) section. + +1. The API server serves various kinds of *resources*. *Built-in resource kinds*, such as + `pods`, are defined by the Kubernetes project and can't be changed. + Read [API extensions](#api-extensions) to learn about extending the Kubernetes API. + +1. The Kubernetes scheduler [decides](/docs/concepts/scheduling-eviction/assign-pod-node/) + which nodes to place pods on. There are several ways to extend scheduling, which are + described in the [Scheduling extensions](#scheduling-extensions) section. + +1. Much of the behavior of Kubernetes is implemented by programs called + {{< glossary_tooltip term_id="controller" text="controllers" >}}, that are + clients of the API server. Controllers are often used in conjunction with custom resources. + Read [combining new APIs with automation](#combining-new-apis-with-automation) and + [Changing built-in resources](#changing-built-in-resources) to learn more. + +1. The kubelet runs on servers (nodes), and helps pods appear like virtual servers with their own IPs on + the cluster network. [Network Plugins](#network-plugins) allow for different implementations of + pod networking. + +1. You can use [Device Plugins](#device-plugins) to integrate custom hardware or other special + node-local facilities, and make these available to Pods running in your cluster. The kubelet + includes support for working with device plugins. + + The kubelet also mounts and unmounts + {{< glossary_tooltip text="volume" term_id="volume" >}} for pods and their containers. + You can use [Storage Plugins](#storage-plugins) to add support for new kinds + of storage and other volume types. + + +#### Extension point choice flowchart {#extension-flowchart} + +If you are unsure where to start, this flowchart can help. Note that some solutions may involve +several types of extensions. + + + +{{< figure src="/docs/concepts/extend-kubernetes/flowchart.svg" + alt="Flowchart with questions about use cases and guidance for implementers. Green circles indicate yes; red circles indicate no." + class="diagram-large" caption="Flowchart guide to select an extension approach" >}} + +--- + +## Client extensions + +Plugins for kubectl are separate binaries that add or replace the behavior of specific subcommands. +The `kubectl` tool can also integrate with [credential plugins](/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins) +These extensions only affect a individual user's local environment, and so cannot enforce site-wide policies. + +If you want to extend the `kubectl` tool, read [Extend kubectl with plugins](/docs/tasks/extend-kubectl/kubectl-plugins/). + +## API extensions + +### Custom resource definitions + +Consider adding a _Custom Resource_ to Kubernetes if you want to define new controllers, application +configuration objects or other declarative APIs, and to manage them using Kubernetes tools, such +as `kubectl`. + +For more about Custom Resources, see the +[Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) concept guide. + +### API aggregation layer + +You can use Kubernetes' [API Aggregation Layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) +to integrate the Kubernetes API with additional services such as for [metrics](/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/). + +### Combining new APIs with automation + +A combination of a custom resource API and a control loop is called the +{{< glossary_tooltip term_id="controller" text="controllers" >}} pattern. If your controller takes +the place of a human operator deploying infrastructure based on a desired state, then the controller +may also be following the {{< glossary_tooltip text="operator pattern" term_id="operator-pattern" >}}. +The Operator pattern is used to manage specific applications; usually, these are applications that +maintain state and require care in how they are managed. + +You can also make your own custom APIs and control loops that manage other resources, such as storage, +or to define policies (such as an access control restriction). + +### Changing built-in resources + +When you extend the Kubernetes API by adding custom resources, the added resources always fall +into a new API Groups. You cannot replace or change existing API groups. +Adding an API does not directly let you affect the behavior of existing APIs (such as Pods), whereas +_API Access Extensions_ do. + +## API access extensions + +When a request reaches the Kubernetes API Server, it is first _authenticated_, then _authorized_, +and is then subject to various types of _admission control_ (some requests are in fact not +authenticated, and get special treatment). See +[Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access/) +for more on this flow. + +Each of the steps in the Kubernetes authentication / authorization flow offers extension points. + +### Authentication + +[Authentication](/docs/reference/access-authn-authz/authentication/) maps headers or certificates +in all requests to a username for the client making the request. + +Kubernetes has several built-in authentication methods that it supports. It can also sit behind an +authenticating proxy, and it can send a token from an `Authorization:` header to a remote service for +verification (an [authentication webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)) +if those don't meet your needs. + +### Authorization + +[Authorization](/docs/reference/access-authn-authz/authorization/) determines whether specific +users can read, write, and do other operations on API resources. It works at the level of whole +resources -- it doesn't discriminate based on arbitrary object fields. + +If the built-in authorization options don't meet your needs, an +[authorization webhook](/docs/reference/access-authn-authz/webhook/) +allows calling out to custom code that makes an authorization decision. + +### Dynamic admission control + +After a request is authorized, if it is a write operation, it also goes through +[Admission Control](/docs/reference/access-authn-authz/admission-controllers/) steps. +In addition to the built-in steps, there are several extensions: + +* The [Image Policy webhook](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook) + restricts what images can be run in containers. +* To make arbitrary admission control decisions, a general + [Admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) + can be used. Admission webhooks can reject creations or updates. + Some admission webhooks modify the incoming request data before it is handled further by Kubernetes. + +## Infrastructure extensions + +### Device plugins + +_Device plugins_ allow a node to discover new Node resources (in addition to the +builtin ones like cpu and memory) via a +[Device Plugin](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/). + +### Storage plugins + +{{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}} (CSI) plugins provide +a way to extend Kubernetes with supports for new kinds of volumes. The volumes can be backed by +durable external storage, or provide ephemeral storage, or they might offer a read-only interface +to information using a filesystem paradigm. + +Kubernetes also includes support for [FlexVolume](/docs/concepts/storage/volumes/#flexvolume) plugins, +which are deprecated since Kubernetes v1.23 (in favour of CSI). + +FlexVolume plugins allow users to mount volume types that aren't natively supported by Kubernetes. When +you run a Pod that relies on FlexVolume storage, the kubelet calls a binary plugin to mount the volume. +The archived [FlexVolume](https://git.k8s.io/design-proposals-archive/storage/flexvolume-deployment.md) +design proposal has more detail on this approach. + +The [Kubernetes Volume Plugin FAQ for Storage Vendors](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md#kubernetes-volume-plugin-faq-for-storage-vendors) +includes general information on storage plugins. + +### Network plugins + +Your Kubernetes cluster needs a _network plugin_ in order to have a working Pod network +and to support other aspects of the Kubernetes network model. + +[Network Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) +allow Kubernetes to work with different networking topologies and technologies. + +### Kubelet image credential provider plugins + +{{< feature-state for_k8s_version="v1.26" state="stable" >}} +Kubelet image credential providers are plugins for the kubelet to dynamically retrieve image registry +credentials. The credentials are then used when pulling images from container image registries that +match the configuration. + +The plugins can communicate with external services or use local files to obtain credentials. This way, +the kubelet does not need to have static credentials for each registry, and can support various +authentication methods and protocols. + +For plugin configuration details, see +[Configure a kubelet image credential provider](/docs/tasks/administer-cluster/kubelet-credential-provider/). + +## Scheduling extensions + +The scheduler is a special type of controller that watches pods, and assigns +pods to nodes. The default scheduler can be replaced entirely, while +continuing to use other Kubernetes components, or +[multiple schedulers](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/) +can run at the same time. + +This is a significant undertaking, and almost all Kubernetes users find they +do not need to modify the scheduler. + +You can control which [scheduling plugins](/docs/reference/scheduling/config/#scheduling-plugins) +are active, or associate sets of plugins with different named [scheduler profiles](/docs/reference/scheduling/config/#multiple-profiles). +You can also write your own plugin that integrates with one or more of the kube-scheduler's +[extension points](/docs/concepts/scheduling-eviction/scheduling-framework/#extension-points). + +Finally, the built in `kube-scheduler` component supports a +[webhook](https://git.k8s.io/design-proposals-archive/scheduling/scheduler_extender.md) +that permits a remote HTTP backend (scheduler extension) to filter and / or prioritize +the nodes that the kube-scheduler chooses for a pod. + +{{< note >}} +You can only affect node filtering +and node prioritization with a scheduler extender webhook; other extension points are +not available through the webhook integration. +{{< /note >}} + +## {{% heading "whatsnext" %}} + +* Learn more about infrastructure extensions + * [Device Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) + * [Network Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) + * CSI [storage plugins](https://kubernetes-csi.github.io/docs/) +* Learn about [kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/) +* Learn more about [Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +* Learn more about [Extension API Servers](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) +* Learn about [Dynamic admission control](/docs/reference/access-authn-authz/extensible-admission-controllers/) +* Learn about the [Operator pattern](/docs/concepts/extend-kubernetes/operator/) diff --git a/content/fa/docs/concepts/overview/_index.md b/content/fa/docs/concepts/overview/_index.md new file mode 100644 index 0000000000000..2715d225bd0c8 --- /dev/null +++ b/content/fa/docs/concepts/overview/_index.md @@ -0,0 +1,138 @@ +--- +reviewers: +- xirehat +title: "نمای کلی" +description: > + کوبرنتیز یک پلتفرم متن‌باز، قابل حمل و قابل توسعه برای مدیریت حجم کار و سرویس‌های کانتینری است که پیکربندی اعلانی و اتوماسیون را تسهیل می‌کند. این پلتفرم دارای یک بن‌سازه بزرگ و به سرعت در حال رشد است. خدمات، پشتیبانی و ابزارهای کوبرنتیز به طور گسترده در دسترس هستند. +content_type: concept +weight: 20 +card: + name: concepts + weight: 10 + anchors: + - anchor: "#why-you-need-kubernetes-and-what-can-it-do" + title: چرا کوبرنتیز؟ +no_list: true +--- + + +این صفحه مروری بر کوبرنتیز است. + + + + +نام «کوبرنتیس» از واژه یونانی به‌معنای «سکان‌دار» یا «خلبان» گرفته شده است. مخفف «K8s» حاصل شمارش هشت حرف بین «K» و «s» است. گوگل پروژه کوبرنتیس را در سال ۲۰۱۴ به‌صورت متن‌باز منتشر کرد. کوبرنتیس بیش از [۱۵ سال تجربه گوگل](/blog/2015/04/borg-predecessor-to-kubernetes/) در اجرای بارهای کاری تولیدی در مقیاس بزرگ را با ایده‌ها و بهترین رویه‌های جامعه کاربری تلفیق می‌کند. + +## چرا به کوبرنتیس نیاز دارید و چه کاری می‌تواند انجام دهد {#why-you-need-kubernetes-and-what-can-it-do} + +کانتینرها راه مناسبی برای بسته‌بندی و اجرای برنامه‌های شما هستند. در یک محیط تولیدی باید کانتینرهایی را که برنامه‌ها را اجرا می‌کنند مدیریت کنید و اطمینان حاصل کنید که هیچ زمان ازکارافتادگی وجود نداشته باشد. برای مثال، اگر یک کانتینر از کار بیفتد باید کانتینر دیگری به‌جای آن راه‌اندازی شود. آیا راحت‌تر نبود اگر سامانه‌ای این رفتار را برای شما مدیریت می‌کرد؟ + +اینجاست که کوبرنتیس به کمک می‌آید! کوبرنتیس چارچوبی در اختیار شما قرار می‌دهد تا سامانه‌های توزیع‌شده را به‌صورت پایدار اجرا کنید. این سامانه مسئول مقیاس‌پذیری و جبران خرابی برای برنامه شماست، الگوهای استقرار فراهم می‌آورد و امکانات دیگری نیز در اختیار می‌گذارد. به‌عنوان مثال: کوبرنتیس می‌تواند به‌سادگی یک استقرار کَنَری را برای سامانه شما مدیریت کند. + +کوبرنتیس امکانات زیر را در اختیار شما می‌گذارد: + +* **کشف سرویس و توزیع بار** + کوبرنتیس می‌تواند یک کانتینر را با استفاده از نام DNS یا آدرس IP اختصاصی در معرض دسترس قرار دهد. اگر ترافیک ورودی به یک کانتینر بالا باشد، کوبرنتیس قادر است ترافیک شبکه را متعادل و توزیع کند تا استقرار پایدار بماند. + +* **مدیریت ذخیره‌سازی (ارکستراسیون)** + کوبرنتیس به شما اجازه می‌دهد به‌طور خودکار یک سیستم ذخیره‌سازی دلخواه ـ از دیسک‌های محلی گرفته تا ارائه‌دهندگان ابر عمومی ـ را متصل (mount) کنید. + +* **به‌روزرسانی و بازگردانی خودکار** + با استفاده از کوبرنتیس می‌توانید وضعیت مطلوب کانتینرهای مستقرشده خود را توصیف کرده و کوبرنتیس با نرخی کنترل‌شده، وضعیت واقعی را به وضعیت مطلوب تغییر دهد. برای نمونه، می‌توانید از کوبرنتیس بخواهید کانتینرهای جدید بسازد، کانتینرهای قدیمی را حذف کند و همه منابع آن‌ها را به کانتینر جدید اختصاص دهد. + +* **بسته‌بندی خودکار وظایف (Bin Packing)** + شما یک خوشه از نودها در اختیار کوبرنتیس قرار می‌دهید تا وظایف کانتینری‌شده را روی آن‌ها اجرا کند. سپس به کوبرنتیس می‌گویید هر کانتینر چه میزان CPU و حافظه (RAM) نیاز دارد؛ کوبرنتیس کانتینرها را طوری روی نودها جا می‌دهد که بهترین استفاده از منابع شما حاصل شود. + +* **خوددرمانی (Self-healing)** + کوبرنتیس کانتینرهایی را که از کار می‌افتند دوباره راه‌اندازی می‌کند، کانتینرها را جایگزین می‌کند، کانتینرهایی را که به آزمون سلامت کاربر پاسخ نمی‌دهند می‌کشد و تا زمانی که کانتینر آماده سرویس‌دهی نباشد، آن را به مشتریان معرفی نمی‌کند. + +* **مدیریت محرمانه‌ها و پیکربندی** + کوبرنتیس امکان ذخیره و مدیریت اطلاعات حساس مانند گذرواژه‌ها، توکن‌های OAuth و کلیدهای SSH را فراهم می‌کند. می‌توانید محرمانه‌ها و پیکربندی برنامه را بدون بازسازی تصاویر کانتینر و بدون افشای اسرار در پیکربندی پشته خود، استقرار داده یا به‌روزرسانی کنید. + +* **اجرای دسته‌ای (Batch)** + افزون بر سرویس‌ها، کوبرنتیس می‌تواند وظایف دسته‌ای و CI شما را نیز مدیریت کند و در صورت تمایل، کانتینرهای ازکارافتاده را جایگزین کند. + +* **مقیاس‌گذاری افقی** + برنامه خود را با یک فرمان ساده، از طریق یک رابط کاربری، یا به‌طور خودکار بر اساس مصرف CPU به بالا یا پایین مقیاس کنید. + +* **پشته دوگانه IPv4/IPv6** + تخصیص آدرس‌های IPv4 و IPv6 به پادها و سرویس‌ها. + +* **طراحی‌شده برای توسعه‌پذیری** + بدون تغییر کد منبع بالادست، ویژگی‌های جدید به خوشه کوبرنتیس خود اضافه کنید. + +## آنچه کوبرنتیز نیست + +کوبرنتیز یک سیستم PaaS (پلتفرم به عنوان سرویس) سنتی و فراگیر نیست. + +از آنجایی که کوبرنتیز در سطح کانتینر و نه در سطح سخت‌افزار عمل می‌کند، برخی از ویژگی‌های عمومی و کاربردی رایج در ارائه‌های PaaS، مانند استقرار، مقیاس‌بندی، متعادل‌سازی بار را ارائه می‌دهد و به کاربران اجازه می‌دهد تا راه‌حل‌های ثبت وقایع، نظارت و هشدار خود را ادغام کنند. با این حال، کوبرنتیز یکپارچه نیست و این راه‌حل‌های پیش‌فرض اختیاری و قابل اتصال هستند. کوبرنتیز بلوک‌های سازنده برای ساخت پلتفرم‌های توسعه‌دهندگان را فراهم می‌کند، اما در صورت لزوم، حق انتخاب و انعطاف‌پذیری کاربر را حفظ می‌کند. + +کوبرنتیز: + +* انواع برنامه‌های پشتیبانی‌شده را محدود نمی‌کند. Kubernetes قصد دارد از انواع بسیار متنوعی از بارهای کاری، از جمله بارهای کاری بدون وضعیت، با وضعیت و پردازش داده، پشتیبانی کند. اگر یک برنامه بتواند در یک کانتینر اجرا شود، باید روی Kubernetes به خوبی اجرا شود. + +* کد منبع را مستقر نمی‌کند و برنامه شما را نمی‌سازد. گردش‌های کاری ادغام مداوم، تحویل و استقرار (CI/CD) توسط فرهنگ‌ها و ترجیحات سازمانی و همچنین الزامات فنی تعیین می‌شوند. + +* خدمات سطح برنامه، مانند میان‌افزار (به عنوان مثال، گذرگاه‌های پیام)، چارچوب‌های پردازش داده (به عنوان مثال، Spark)، پایگاه‌های داده (به عنوان مثال، MySQL)، حافظه‌های پنهان و همچنین سیستم‌های ذخیره‌سازی خوشه‌ای (به عنوان مثال، Ceph) را به عنوان سرویس‌های داخلی ارائه نمی‌دهد. چنین اجزایی می‌توانند روی Kubernetes اجرا شوند و/یا می‌توانند توسط برنامه‌هایی که روی Kubernetes اجرا می‌شوند از طریق مکانیسم‌های قابل حمل، مانند [Open Service Broker](https://openservicebrokerapi.org/) قابل دسترسی باشند. + +* راه‌حل‌های ثبت وقایع، نظارت یا هشدار را دیکته نمی‌کند. این سیستم، برخی یکپارچه‌سازی‌ها را +به عنوان اثبات مفهوم، و مکانیسم‌هایی را برای جمع‌آوری و صدور معیارها ارائه می‌دهد. + +* زبان/سیستم پیکربندی (به عنوان مثال، Jsonnet) را ارائه یا الزامی نمی‌کند. +یک API اعلانی ارائه می‌دهد که ممکن است توسط اشکال دلخواه مشخصات اعلانی هدف قرار گیرد. + +* هیچ سیستم پیکربندی، نگهداری، مدیریت یا خودترمیمی جامعی را ارائه یا اتخاذ نمی‌کند. + +* علاوه بر این، Kubernetes یک سیستم ارکستراسیون صرف نیست. در واقع، نیاز به ارکستراسیون را از بین می‌برد. تعریف فنی ارکستراسیون، اجرای یک گردش کار تعریف شده است: +ابتدا A، سپس B و سپس C را انجام دهید. در مقابل، Kubernetes شامل مجموعه‌ای از فرآیندهای کنترل مستقل و قابل ترکیب است که به طور مداوم وضعیت فعلی را به سمت وضعیت مطلوب ارائه شده سوق می‌دهند. +مهم نیست که چگونه از A به C می‌رسید. کنترل متمرکز نیز مورد نیاز نیست. این +منجر به سیستمی می‌شود که استفاده از آن آسان‌تر و قدرتمندتر، مقاوم‌تر، انعطاف‌پذیرتر و قابل توسعه‌تر است. + +## پیشینه تاریخی Kubernetes {#going-back-in-time} + +بیایید با بازگشت به گذشته، نگاهی به این بیندازیم که چرا Kubernetes بسیار مفید است. + +![تکامل استقرار](/images/docs/Container_Evolution.svg) + +**دوران استقرار سنتی:** + +در اوایل، سازمان‌ها برنامه‌ها را روی سرورهای فیزیکی اجرا می‌کردند. هیچ راهی برای تعریف مرزهای منابع برای برنامه‌ها در یک سرور فیزیکی وجود نداشت و این باعث ایجاد مشکلاتی در تخصیص منابع می‌شد. به عنوان مثال، اگر چندین برنامه روی یک سرور فیزیکی اجرا شوند، ممکن است مواردی وجود داشته باشد که یک برنامه بیشتر منابع را اشغال کند و در نتیجه، برنامه‌های دیگر عملکرد ضعیفی داشته باشند. یک راه حل برای این مشکل، اجرای هر برنامه روی یک سرور فیزیکی متفاوت است. اما این روش مقیاس‌پذیر نبود زیرا منابع کمتر از حد مورد استفاده قرار می‌گرفتند و نگهداری بسیاری از سرورهای فیزیکی برای سازمان‌ها پرهزینه بود. + +**دورۀ استقرار مجازی‌شده:** + +به‌عنوان یک راه‌حل، مجازی‌سازی معرفی شد. این فناوری امکان می‌دهد چندین ماشین مجازی (VM) را روی CPU یک سرور فیزیکی واحد اجرا کنید. مجازی‌سازی باعث می‌شود برنامه‌ها در ماشین‌های مجازی از یکدیگر جدا باشند و سطحی از امنیت ایجاد شود؛ زیرا اطلاعات یک برنامه به‌صورت آزاد توسط برنامۀ دیگر قابل دسترسی نیست. + +مجازی‌سازی استفاده بهتر از منابعِ یک سرور فیزیکی را ممکن می‌سازد و مقیاس‌پذیری بهتری فراهم می‌آورد؛ چراکه افزودن یا به‌روزرسانی یک برنامه آسان است، هزینه‌های سخت‌افزاری کاهش می‌یابد و مزایای بسیار دیگری نیز به‌دنبال دارد. با مجازی‌سازی می‌توانید مجموعه‌ای از منابع فیزیکی را به‌صورت یک خوشه از ماشین‌های مجازی یک‌بارمصرف ارائه کنید. + +هر ماشین مجازی یک ماشین کامل است که تمامی مؤلفه‌ها، از جمله سیستم‌عامل خود را، بر روی سخت‌افزار مجازی‌شده اجرا می‌کند. + +**دورۀ استقرار کانتینری:** + +کانتینرها شبیه ماشین‌های مجازی هستند، اما ویژگی‌های جداسازی در آن‌ها منعطف‌تر است تا سیستم‌عامل (OS) میان برنامه‌ها به اشتراک گذاشته شود؛ ازاین‌رو کانتینرها سبک محسوب می‌شوند. مشابه یک ماشین مجازی، هر کانتینر سامانه فایل اختصاصی، سهمی از CPU، حافظه، فضای فرایند و موارد دیگر را در اختیار دارد. چون کانتینرها از زیرساخت پایه جدا شده‌اند، در میان رایانش ابری و توزیع‌های مختلف سیستم‌عامل قابل حمل‌اند. + +کانتینرها به‌دلیل مزایای اضافه‌ای همچون موارد زیر محبوب شده‌اند: + +* ایجاد و استقرار چابک برنامه: افزایش سهولت و کارایی ایجاد تصویر کانتینر در مقایسه با استفاده از تصویر ماشین مجازی. + +* توسعه، ادغام و استقرار مداوم: امکان ساخت و استقرار تصویر کانتینر قابل اعتماد و مکرر را با عقبگردهای سریع و کارآمد (به دلیل تغییرناپذیری تصویر) فراهم می‌کند. + +* جداسازی دغدغه‌های توسعه و عملیات: ایجاد تصاویر کانتینر برنامه در زمان ساخت/انتشار به جای زمان استقرار، و در نتیجه جداسازی برنامه‌ها از زیرساخت. + +* قابلیت مشاهده: نه تنها اطلاعات و معیارهای سطح سیستم عامل را نشان می‌دهد، بلکه سلامت برنامه و سایر سیگنال‌ها را نیز پوشش می‌دهد. + +* سازگاری محیطی در طول توسعه، آزمایش و تولید: همانطور که در ابر اجرا می‌شود، روی لپ‌تاپ نیز اجرا می‌شود. + +* قابلیت حمل توزیع ابر و سیستم عامل: روی اوبونتو، RHEL، CoreOS، در محل، روی ابرهای عمومی بزرگ و هر جای دیگر اجرا می‌شود. + +* مدیریت متمرکز بر برنامه: سطح انتزاع را از اجرای یک سیستم عامل روی سخت‌افزار مجازی به اجرای یک برنامه روی یک سیستم عامل با استفاده از منابع منطقی افزایش می‌دهد. * میکروسرویس‌های آزاد، توزیع‌شده، انعطاف‌پذیر و با اتصال آزاد: برنامه‌ها به قطعات کوچک‌تر و مستقل تقسیم می‌شوند و می‌توانند به صورت پویا مستقر و مدیریت شوند - نه یک پشته یکپارچه که روی یک ماشین بزرگ تک‌منظوره اجرا می‌شود. + +* ایزوله‌سازی منابع: عملکرد قابل پیش‌بینی برنامه. + +* استفاده از منابع: کارایی و تراکم بالا. + +## {{% heading "whatsnext" %}} + +* نگاهی بیندازید به [اجزای کوبرنتیز](/docs/concepts/overview/components/) +* نگاهی بیندازید به [رابط برنامه‌نویسی کوبرنتیز](/docs/concepts/overview/kubernetes-api/) +* نگاهی بیندازید به [معماری خوشه](/docs/concepts/architecture/) +* آماده‌اید تا [شروع کنید](/docs/setup/)؟ \ No newline at end of file diff --git a/content/fa/docs/concepts/overview/components.md b/content/fa/docs/concepts/overview/components.md new file mode 100644 index 0000000000000..eb5fbd0829bee --- /dev/null +++ b/content/fa/docs/concepts/overview/components.md @@ -0,0 +1,88 @@ +--- +reviewers: +- xirehat +title: اجزای کوبرنتیز +content_type: concept +description: > + مروری بر اجزای کلیدی که یک خوشه کوبرنتیز را تشکیل می‌دهند. +weight: 10 +card: + title: اجزای یک خوشه + name: concepts + weight: 20 +--- + + + +این صفحه نمایی سطح‌بالا از اجزای اساسی که یک خوشه کوبرنتیز را تشکیل می‌دهند ارائه می‌کند. + +{{< figure src="/images/docs/components-of-kubernetes.svg" alt="اجزای کوبرنتیز" caption="اجزای یک خوشه کوبرنتیز" class="diagram-large" clicktozoom="true" >}} + + + +## اجزای اصلی + +یک خوشه کوبرنتیز از یک کنترل‌پلن و یک یا چند نود کاری تشکیل شده است. +در ادامه، مرور کوتاهی بر اجزای اصلی داریم: + +### اجزای control plane + +وضعیت کلی خوشه را مدیریت می‌کنند: + +[kube-apiserver](/docs/concepts/architecture/#kube-apiserver) +: مولفه سروریِ اصلی که رابط HTTP کوبرنتیز را در دسترس قرار می‌دهد. + +[etcd](/docs/concepts/architecture/#etcd) +: یک مخزن کلید-مقدار سازگار و در دسترس‌بالا برای تمام داده‌های سرور API. + +[kube-scheduler](/docs/concepts/architecture/#kube-scheduler) +: پادهایی را که هنوز به نودی تخصیص نیافته‌اند جست‌وجو کرده و هر پاد را به نود مناسب می‌سپارد. + +[kube-controller-manager](/docs/concepts/architecture/#kube-controller-manager) +: {{< glossary_tooltip text="controllers" term_id="controller" >}} را برای پیاده‌سازی رفتار API کوبرنتیز اجرا می‌کند. + +[cloud-controller-manager](/docs/concepts/architecture/#cloud-controller-manager) (اختیاری) +: با ارائه‌دهنده(های) ابری زیرساخت ادغام می‌شود. + +### اجزای گره + +روی هر نود اجرا می‌شوند، پادهای در حال اجرا را نگه می‌دارند و محیط اجرایی کوبرنتیز را فراهم می‌کنند: + +[kubelet](/docs/concepts/architecture/#kubelet) +: اطمینان حاصل می‌کند که پادها (و کانتینرهای‌شان) در حال اجرا هستند. + +[kube-proxy](/docs/concepts/architecture/#kube-proxy) (اختیاری) +: قواعد شبکه را روی نودها نگه می‌دارد تا {{< glossary_tooltip text="Services" term_id="service" >}} را پیاده‌سازی کند. + +[Container runtime](/docs/concepts/architecture/#container-runtime) +: نرم‌افزاری که مسئول اجرای کانتینرهاست. برای اطلاعات بیشتر + [زمان‌های اجرای کانتینر](/docs/setup/production-environment/container-runtimes/) را مطالعه کنید. + +{{% thirdparty-content single="true" %}} + +خوشه شما ممکن است به نرم‌افزارهای اضافی روی هر نود نیاز داشته باشد؛ به‌عنوان مثال، ممکن است روی یک نود لینوکسی +[systemd](https://systemd.io/) را برای نظارت بر اجزای محلی اجرا کنید. + +## افزونه‌ها + +افزونه‌ها قابلیت‌های کوبرنتیز را گسترش می‌دهند. چند نمونه مهم عبارت‌اند از: + +[DNS](/docs/concepts/architecture/#dns) +: برای حل نام DNS در سراسر خوشه. + +[رابط وب](/docs/concepts/architecture/#web-ui-dashboard) (داشبورد) +: برای مدیریت خوشه از طریق رابط وب. + +[پایش منابع کانتینر](/docs/concepts/architecture/#container-resource-monitoring) +: برای جمع‌آوری و ذخیره داده‌های متریک کانتینرها. + +[لاگ‌گیری در سطح خوشه](/docs/concepts/architecture/#cluster-level-logging) +: برای ذخیره لاگ‌های کانتینرها در یک مخزن لاگ مرکزی. + +## انعطاف در معماری + +کوبرنتیز در چگونگی استقرار و مدیریت این اجزا انعطاف‌پذیر است. +این معماری می‌تواند با نیازهای گوناگون — از محیط‌های توسعه کوچک تا استقرارهای تولیدی در مقیاس بزرگ — تطبیق یابد. + +برای اطلاعات جزئی‌تر درباره هر جزء و روش‌های مختلف پیکربندی معماری خوشه، +به صفحه [معماری خوشه](/docs/concepts/architecture/) مراجعه کنید. diff --git a/content/fa/docs/concepts/overview/kubernetes-api.md b/content/fa/docs/concepts/overview/kubernetes-api.md new file mode 100644 index 0000000000000..bd0d399bdf486 --- /dev/null +++ b/content/fa/docs/concepts/overview/kubernetes-api.md @@ -0,0 +1,321 @@ +--- +reviewers: +- xirehat +title: رابط برنامه‌نویسی کاربردی کوبرنتیز +content_type: concept +weight: 40 +description: > + رابط برنامه‌نویسی کاربردی کوبرنتیز (Kubernetes API) به شما امکان می‌دهد وضعیت اشیاء را در کوبرنتیز پرس‌وجو و دستکاری کنید. هسته صفحه کنترل کوبرنتیز، سرور API و HTTP API ارائه شده توسط آن است. کاربران، بخش‌های مختلف خوشه شما و اجزای خارجی، همگی از طریق سرور API با یکدیگر ارتباط برقرار می‌کنند. +card: + name: concepts + weight: 30 +--- + + + +هسته {{< glossary_tooltip text="control plane" term_id="control-plane" >}} کوبرنتیز، {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} است. سرور API یک رابط HTTP را در دسترس قرار می‌دهد که امکان می‌دهد کاربران نهایی، بخش‌های مختلف خوشه شما و اجزای خارجی با یکدیگر ارتباط برقرار کنند. + +رابط API کوبرنتیز به شما اجازه می‌دهد وضعیت اشیای API در کوبرنتیز (برای نمونه: ‌Podها، ‌Namespaceها، ‌ConfigMapها و Eventها) را پرس‌وجو کرده و دست‌کاری نمایید. + +بیشتر عملیات را می‌توان از طریق رابط خط فرمان [kubectl](/docs/reference/kubectl/) یا ابزارهای خط فرمان دیگری مانند [kubeadm](/docs/reference/setup-tools/kubeadm/) که خود از API استفاده می‌کنند انجام داد. با این حال، می‌توانید با فراخوان‌های REST نیز به API دسترسی مستقیم داشته باشید. کوبرنتیز برای کسانی که قصد دارند با API کوبرنتیز برنامه بنویسند، مجموعه‌ای از [کتابخانه‌های کاربری](/docs/reference/using-api/client-libraries/) فراهم ساخته است. + +هر خوشه کوبرنتیز مشخصات APIهایی را که ارائه می‌کند منتشر می‌کند. دو سازوکار برای انتشار این مشخصات وجود دارد که هر دو در فراهم‌کردن تعامل‌پذیری خودکار سودمندند. به‌عنوان نمونه، ابزار `kubectl` این مشخصات را دریافت کرده و برای تکمیل خودکار خط فرمان و ویژگی‌های دیگر در کش نگه می‌دارد. دو سازوکار پشتیبانی‌شده عبارت‌اند از: + +- [Discovery API](#discovery-api) + : اطلاعاتی درباره ‌APIهای کوبرنتیز شامل نام APIها، منابع، نسخه‌ها و عملیات پشتیبانی‌شده ارائه می‌دهد. این اصطلاح ویژه کوبرنتیز است زیرا API مجزایی از OpenAPI کوبرنتیز به‌شمار می‌رود. هدف آن ارائه خلاصه کوتاهی از منابع موجود است و جزئیات طرح‌واره هر منبع را شامل نمی‌شود. برای طرح‌واره منابع، به سند OpenAPI مراجعه کنید. + +- [سند OpenAPI کوبرنتیز](#openapi-interface-definition) + : طرح‌واره‌های کامل [OpenAPI v2.0 و v3.0](https://www.openapis.org/) را برای همه پایانه‌های ‌API کوبرنتیز فراهم می‌کند. OpenAPI v3 روش ترجیحی برای دسترسی است زیرا نمایی جامع و دقیق از API ارائه می‌دهد. این سند همه مسیرهای API و منابع مصرف‌شده یا تولیدشده در هر عملیات، و نیز اجزای توسعه‌پذیری پشتیبانی‌شده توسط خوشه را در بر می‌گیرد. این داده یک مشخصات کامل است و به‌مراتب حجیم‌تر از داده Discovery API می‌باشد. + +## API اکتشاف (Discovery API) + +کوبرنتیز فهرستی از تمام نسخه‌ها و منابع هر گروه را که پشتیبانی می‌شوند از طریق Discovery API منتشر می‌کند. این فهرست برای هر منبع شامل موارد زیر است: + +- نام +- گستره خوشه‌ای یا namespaced +- نشانی پایانه (Endpoint URL) و افعال پشتیبانی‌شده +- نام‌های جایگزین +- گروه، نسخه، kind + +این API در دو شکل تجمیعی و غیرتجمیعی در دسترس است. اکتشاف تجمیعی دو پایانه ارائه می‌دهد، در حالی‌ که اکتشاف غیرتجمیعی برای هر نسخه گروه یک پایانه جداگانه فراهم می‌کند. + +### اکتشاف تجمیعی + +{{< feature-state feature_gate_name="AggregatedDiscoveryEndpoint" >}} + +کوبرنتیز به‌طور پایدار از _اکتشاف تجمیعی_ پشتیبانی می‌کند و همه منابعی را که یک خوشه پشتیبانی می‌کند از طریق دو پایانه `/api` و `/apis` منتشر می‌نماید. درخواست این پایانه‌ها تعداد درخواست‌های لازم برای دریافت داده اکتشاف از خوشه را به‌طور چشمگیری کاهش می‌دهد. برای دسترسی به داده می‌توانید پایانه مربوطه را با هدر `Accept` زیر فراخوانی کنید: +`Accept: application/json;v=v2;g=apidiscovery.k8s.io;as=APIGroupDiscoveryList` + +اگر نوع منبع را با هدر `Accept` مشخص نکنید، پاسخ پیش‌فرض پایانه‌های `/api` و `/apis` یک سند اکتشاف غیرتجمیعی خواهد بود. + +[سند اکتشاف](https://github.com/kubernetes/kubernetes/blob/release-{{< skew currentVersion >}}/api/discovery/aggregated_v2.json) +برای منابع داخلی در مخزن GitHub کوبرنتیز موجود است. زمانی‌ که به یک خوشه کوبرنتیز دسترسی ندارید، این سند می‌تواند به‌عنوان مرجع مجموعه پایه منابع قابلِ دسترس به کار رود. + +این پایانه همچنین از ETag و کدگذاری protobuf پشتیبانی می‌کند. + +### اکتشاف غیرتجمیعی + +بدون اکتشاف تجمیعی، اکتشاف به‌صورت لایه‌ای منتشر می‌شود؛ به این صورت که پایانه‌های ریشه اطلاعات اکتشاف برای اسناد پایین‌دستی را منتشر می‌کنند. + +فهرست همه نسخه‌های گروهی که یک خوشه پشتیبانی می‌کند در پایانه‌های `/api` و `/apis` منتشر می‌شود. مثال: + +``` +{ + "kind": "APIGroupList", + "apiVersion": "v1", + "groups": [ + { + "name": "apiregistration.k8s.io", + "versions": [ + { + "groupVersion": "apiregistration.k8s.io/v1", + "version": "v1" + } + ], + "preferredVersion": { + "groupVersion": "apiregistration.k8s.io/v1", + "version": "v1" + } + }, + { + "name": "apps", + "versions": [ + { + "groupVersion": "apps/v1", + "version": "v1" + } + ], + "preferredVersion": { + "groupVersion": "apps/v1", + "version": "v1" + } + }, + ... +} +``` + +برای دریافت سند اکتشاف برای هر نسخه گروه، باید درخواست‌های اضافی به نشانی +`/apis//` ارسال شود (برای مثال: +`/apis/rbac.authorization.k8s.io/v1alpha1`). این سند فهرست منابعی را که زیر آن نسخه گروه ارائه می‌شوند اعلام می‌کند. این پایانه‌ها توسط +`kubectl` برای واکشی فهرست منابع پشتیبانی‌شده توسط یک خوشه استفاده می‌شوند. + + + + + +## تعریف رابط OpenAPI + +برای جزئیات بیشتر درباره مشخصات OpenAPI به [مستندات OpenAPI](https://www.openapis.org/) مراجعه کنید. + +کوبرنتیز هر دو نسخه OpenAPI v2.0 و OpenAPI v3.0 را ارائه می‌دهد. OpenAPI v3 روش ترجیحی برای دسترسی به OpenAPI است، زیرا نمایی جامع و بدون اتلاف از منابع کوبرنتیز فراهم می‌کند. به‌دلیل محدودیت‌های نسخه ۲ OpenAPI، برخی فیلدها از سند منتشرشده حذف می‌شوند، از جمله ولی نه محدود به `default`، `nullable` و `oneOf`. + +### OpenAPI V2 + +سرور API کوبرنتیز یک مشخصات تجمیعی OpenAPI v2 را از طریق پایانه +`/openapi/v2` ارائه می‌دهد. می‌توانید قالب پاسخ را با استفاده از +هدرهای درخواست به شکل زیر مشخص کنید: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Valid request header values for OpenAPI v2 queries
HeaderPossible valuesNotes
Accept-Encodinggzipnot supplying this header is also acceptable
Acceptapplication/com.github.proto-openapi.spec.v2@v1.0+protobufmainly for intra-cluster use
application/jsondefault
*serves application/json
+ +{{< warning >}} +قوانین اعتبارسنجی که به‌عنوان بخشی از طرح‌واره‌های OpenAPI منتشر می‌شوند ممکن است کامل نباشند (و معمولاً هم نیستند). +اعتبارسنجی‌های اضافی در داخل سرور API انجام می‌شود. اگر به تأیید دقیق و کامل نیاز دارید، +دستور `kubectl apply --dry-run=server` تمام اعتبارسنجی‌های قابل اجرا را اجرا می‌کند (و همچنین بررسی‌های زمان پذیرش را فعال می‌نماید). +{{< /warning >}} + +### OpenAPI V3 + +{{< feature-state feature_gate_name="OpenAPIV3" >}} + +کوبرنتیز از انتشار توصیف APIهای خود به‌صورت OpenAPI v3 پشتیبانی می‌کند. + +یک پایانه اکتشاف به نشانی `/openapi/v3` برای مشاهده فهرست همه گروه/نسخه‌های موجود فراهم شده است. این پایانه تنها JSON بازمی‌گرداند. این گروه/نسخه‌ها در قالب زیر ارائه می‌شوند: + +```yaml +{ + "paths": { + ..., + "api/v1": { + "serverRelativeURL": "/openapi/v3/api/v1?hash=CC0E9BFD992D8C59AEC98A1E2336F899E8318D3CF4C68944C3DEC640AF5AB52D864AC50DAA8D145B3494F75FA3CFF939FCBDDA431DAD3CA79738B297795818CF" + }, + "apis/admissionregistration.k8s.io/v1": { + "serverRelativeURL": "/openapi/v3/apis/admissionregistration.k8s.io/v1?hash=E19CC93A116982CE5422FC42B590A8AFAD92CDE9AE4D59B5CAAD568F083AD07946E6CB5817531680BCE6E215C16973CD39003B0425F3477CFD854E89A9DB6597" + }, + .... + } +} +``` + + +نشانی‌های نسبی به توصیف‌های تغییرناپذیر OpenAPI اشاره می‌کنند تا +عملکرد کش سمت کاربر را بهبود دهند. هدرهای مناسب کش HTTP نیز برای این منظور +توسط سرور API تنظیم می‌شوند (`Expires` یک سال در آینده و `Cache-Control` +بر روی `immutable`). هنگامی که یک نشانی منسوخ استفاده شود، سرور API +کاربر را به جدیدترین نشانی هدایت (redirect) می‌کند. + +سرور API کوبرنتیز برای هر نسخه گروه کوبرنتیز، مشخصات OpenAPI v3 را +در پایانه `/openapi/v3/apis//?hash=` منتشر می‌کند. + +برای مشاهده هدرهای درخواستی پذیرفته‌شده، به جدول زیر مراجعه کنید. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Valid request header values for OpenAPI v3 queries
HeaderPossible valuesNotes
Accept-Encodinggzipnot supplying this header is also acceptable
Acceptapplication/com.github.proto-openapi.spec.v3@v1.0+protobufmainly for intra-cluster use
application/jsondefault
*serves application/json
+ +یک پیاده‌سازی Golang برای واکشی OpenAPI V3 در بسته +[`k8s.io/client-go/openapi3`](https://pkg.go.dev/k8s.io/client-go/openapi3) در دسترس است. + +کوبرنتیز {{< skew currentVersion >}} مشخصات +OpenAPI v2.0 و v3.0 را منتشر می‌کند؛ در حال حاضر برنامه‌ای برای پشتیبانی از نسخه 3.1 وجود ندارد. + +### سریال‌سازی Protobuf + +کوبرنتیز یک قالب سریال‌سازی جایگزین مبتنی بر Protobuf را پیاده‌سازی کرده است که +در درجه اول برای ارتباط درون‌خوشهی در نظر گرفته شده است. برای اطلاعات بیشتر +درباره این قالب، به طرح پیشنهادی +[سریال‌سازی Protobuf در کوبرنتیز](https://git.k8s.io/design-proposals-archive/api-machinery/protobuf.md) +و فایل‌های Interface Definition Language (IDL) برای هر طرح‌واره که در +بسته‌های Go تعریف‌کننده اشیای API قرار دارند مراجعه کنید. + +## پایداری داده (Persistence) + +کوبرنتیز وضعیت سریال‌شده اشیاء را با نوشتن آن‌ها در +{{< glossary_tooltip term_id="etcd" >}} ذخیره می‌کند. + +## گروه‌های API و نسخه‌بندی + +برای آسان‌تر کردن حذف فیلدها یا بازچینی نمایش منابع، +کوبرنتیز از چندین نسخه API پشتیبانی می‌کند که هر یک در مسیر API متفاوتی +مثل `/api/v1` یا `/apis/rbac.authorization.k8s.io/v1alpha1` قرار دارند. + +نسخه‌بندی در سطح API انجام می‌شود، نه در سطح منبع یا فیلد، تا +نمایی شفاف و سازگار از منابع و رفتار سیستم ارائه شده و +کنترل دسترسی به APIهایی که به پایان عمر یا آزمایشی هستند امکان‌پذیر شود. + +برای سهولت توسعه و گسترش API، کوبرنتیز +[گروه‌های API](/docs/reference/using-api/#api-groups) را پیاده‌سازی کرده که می‌توانند +[فعال یا غیرفعال](/docs/reference/using-api/#enabling-or-disabling) شوند. + +منابع API به‌واسطه گروه API، نوع منبع، نام فضا (برای منابع namespaced) و نام متمایز می‌شوند. +سرور API تبدیل بین نسخه‌های API را به‌صورت شفاف مدیریت می‌کند: +تمام نسخه‌های مختلف در واقع نمایش‌هایی از همان داده ذخیره‌شده هستند، و سرور API +ممکن است همان داده زیرساختی را از طریق چند نسخه API ارائه دهد. + +برای مثال، فرض کنید دو نسخه API، `v1` و `v1beta1`، برای یک منبع وجود دارد. +اگر در ابتدا شیئی را با نسخه `v1beta1` ایجاد کنید، تا زمانی که نسخه `v1beta1` +منقضی و حذف نشده است می‌توانید آن شیء را با هر یک از نسخه‌های `v1beta1` یا `v1` +بخوانید، به‌روزرسانی یا حذف کنید؛ پس از آن، دسترسی و تغییر شیء فقط از طریق نسخه `v1` ممکن است. + +### تغییرات API + +هر سامانه موفق باید با ظهور موارد استفاده جدید یا تغییر موارد موجود رشد کند و تغییر یابد؛ +بنابراین کوبرنتیز API خود را به گونه‌ای طراحی کرده تا پیوسته تغییر و گسترش یابد. +هدف پروژه کوبرنتیز این است که سازگاری با کلاینت‌های موجود را نشکند و این +سازگاری را برای مدتی حفظ کند تا پروژه‌های دیگر فرصت تطبیق داشته باشند. + +به‌طور کلی، افزودن منابع API یا فیلدهای جدید می‌تواند به دفعات و به‌سرعت انجام شود. +حذف منابع یا فیلدها نیازمند پیروی از +[سیاست منسوخ‌سازی API](/docs/reference/using-api/deprecation-policy/) است. + +کوبرنتیز تعهد قوی دارد که پس از رسیدن APIهای رسمی به مرحله دسترسی عمومی (GA) +— معمولاً در نسخه `v1` — سازگاری آن‌ها را حفظ کند. همچنین کوبرنتیز +سازگاری با داده‌هایی که از طریق نسخه‌های _بتا_ APIهای رسمی ذخیره شده‌اند را تضمین می‌کند +و اطمینان می‌دهد که داده‌ها هنگام پایدار شدن ویژگی‌ها قابل تبدیل و دسترس‌پذیر از طریق +نسخه‌های GA باشند. + +اگر نسخه بتای API را اتخاذ کنید، باید پس از فارغ‌التحصیل شدن API به نسخه بتا یا پایدار بعدی +مهاجرت نمایید. بهترین زمان برای این کار، دوره منسوخ‌سازی نسخه بتا است، +زیرا اشیاء به طور هم‌زمان از طریق هر دو نسخه API قابل دسترسی هستند. پس از پایان دوره +منسوخ‌سازی و توقف ارائه نسخه بتا، باید از نسخه جایگزین استفاده شود. + +{{< note >}} +هرچند کوبرنتیز تلاش می‌کند برای نسخه‌های _آلفا_ نیز سازگاری را حفظ کند، +ولی در برخی شرایط این امر ممکن نیست. اگر از هر نسخه آلفا استفاده می‌کنید، +در زمان به‌روزرسانی خوشه، یادداشت‌های انتشار کوبرنتیز را بررسی کنید، +زیرا ممکن است تغییرات ناسازگاری رخ داده باشد که نیازمند حذف تمامی +اشیای آلفا پیش از ارتقا باشد. +{{< /note >}} + +برای جزئیات بیشتر درباره تعاریف سطوح نسخه API، به +[مرجع نسخه‌های API](/docs/reference/using-api/#api-versioning) مراجعه کنید. + +## گسترش API + +API کوبرنتیز را می‌توان به یکی از دو روش زیر گسترش داد: + +1. [منابع سفارشی](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) + به شما امکان می‌دهد به‌صورت اعلان‌محور تعریف کنید که سرور API چگونه + ‌API منبع انتخابی شما را فراهم کند. +2. همچنین می‌توانید با پیاده‌سازی + [لایه تجمیع](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) + API کوبرنتیز را گسترش دهید. + +## {{% heading "whatsnext" %}} + +- بیاموزید چگونه با افزودن + [CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) + API کوبرنتیز را گسترش دهید. +- مستند + [کنترل دسترسی به API کوبرنتیز](/docs/concepts/security/controlling-access/) + توضیح می‌دهد خوشه چگونه احراز هویت و مجوزدهی برای دسترسی به API را مدیریت می‌کند. +- درباره پایانه‌های API، انواع منابع و نمونه‌ها در + [مرجع API](/docs/reference/kubernetes-api/) بخوانید. +- درباره اینکه تغییر سازگار چیست و چگونه می‌توان API را تغییر داد، در + [تغییرات API](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme) + مطالعه کنید. diff --git a/content/fa/docs/concepts/overview/working-with-objects/_index.md b/content/fa/docs/concepts/overview/working-with-objects/_index.md new file mode 100644 index 0000000000000..a1635aad48593 --- /dev/null +++ b/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 +--- + + + +این صفحه توضیح می‌دهد که اشیای کوبرنتیز چگونه در API کوبرنتیز نمایش داده می‌شوند و چگونه می‌توانید آن‌ها را در قالب `.yaml` بیان کنید. + + + +## درک اشیای کوبرنتیز {#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/) + +برای آشنایی عمیق‌تر با اشیا در کوبرنتیز، سایر صفحات همین بخش را مطالعه کنید: + diff --git a/content/fa/docs/concepts/overview/working-with-objects/annotations.md b/content/fa/docs/concepts/overview/working-with-objects/annotations.md new file mode 100644 index 0000000000000..a2710132158ad --- /dev/null +++ b/content/fa/docs/concepts/overview/working-with-objects/annotations.md @@ -0,0 +1,82 @@ +--- +title: حاشیه‌نویسی‌ها +content_type: concept +weight: 60 +--- + + +می‌توانید از حاشیه‌نویس‌های کوبرنتیز برای پیوست کردن فرا‌داده دلخواه و غیرشناسه‌ای به {{< glossary_tooltip text="اشیاء" term_id="object" >}} استفاده کنید. ابزارها و کتابخانه‌ها می‌توانند به‌عنوان کلاینت این فرا‌داده را بازیابی کنند. + + +## پیوست کردن فرا‌داده به اشیاء + +برای پیوست کردن فرا‌داده به اشیای کوبرنتیز می‌توانید از برچسب‌ها (labels) یا حاشیه‌نویس‌ها (annotations) استفاده کنید. +برچسب‌ها برای انتخاب اشیا و یافتن مجموعه‌هایی از اشیا که شرایط خاصی را دارند به‌کار می‌روند. +در مقابل، حاشیه‌نویس‌ها برای شناسایی و انتخاب اشیا استفاده نمی‌شوند. +فرا‌داده در یک حاشیه‌نویس می‌تواند کوچک یا بزرگ، ساخت‌یافته یا غیرساخت‌یافته باشد و حتی شامل نویسه‌هایی باشد که در برچسب‌ها مجاز نیستند. +همچنین می‌توانید در فرا‌داده یک شیء به‌طور هم‌زمان از برچسب‌ها و حاشیه‌نویس‌ها استفاده کنید. + +حاشیه‌نویس‌ها نیز مانند برچسب‌ها، نگاشت‌های کلید/مقدار هستند: + +```json +"metadata": { + "annotations": { + "key1" : "value1", + "key2" : "value2" + } +} +``` + +{{}} +کلیدها و مقدارهای این نگاشت باید رشته (string) باشند؛ به بیان دیگر، نمی‌توانید از انواع عددی، بولی، فهرست یا هر نوع دیگری برای کلید یا مقدار استفاده کنید. +{{}} + +در ادامه چند نمونه از اطلاعاتی که می‌توان در حاشیه‌نویس‌ها ذخیره کرد آورده شده است: + +* فیلدهایی که توسط لایه پیکربندی اعلانی مدیریت می‌شوند. افزودن این فیلدها به‌صورت حاشیه‌نویس، آن‌ها را از مقادیر پیش‌فرض تنظیم‌شده توسط کلاینت یا سرور و همچنین از فیلدهای تولیدشده خودکار یا فیلدهای تنظیم‌شده توسط سامانه‌های خوداندازه یا خودمقیاس جدا می‌کند. + +* اطلاعات ساخت (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/) را بیابید. diff --git a/content/fa/docs/concepts/overview/working-with-objects/common-labels.md b/content/fa/docs/concepts/overview/working-with-objects/common-labels.md new file mode 100644 index 0000000000000..68b349a18c03a --- /dev/null +++ b/content/fa/docs/concepts/overview/working-with-objects/common-labels.md @@ -0,0 +1,164 @@ +--- +title: برچسب‌های پیشنهادی +content_type: concept +weight: 100 +--- + + +می‌توانید اشیای کوبرنتیز را با ابزارهایی فراتر از `kubectl` و داشبورد مشاهده و مدیریت کنید. +یک مجموعه مشترک از برچسب‌ها به ابزارها اجازه می‌دهد به‌صورت میان‌عملی کار کنند و اشیا را به شیوه‌ای مشترک توصیف کنند که همه ابزارها بتوانند آن را درک کنند. + +علاوه بر پشتیبانی از ابزارها، برچسب‌های پیشنهادی برنامه‌ها را به گونه‌ای توصیف می‌کنند که بتوان آن‌ها را جست‌وجو کرد. + + + +فرا‌داده حول مفهوم یک _برنامه_ سازمان‌دهی شده است. کوبرنتیز یک پلتفرم به‌عنوان سرویس (PaaS) نیست و مفهوم رسمی‌ای از «برنامه» ندارد و آن را اعمال نمی‌کند. در عوض، برنامه‌ها غیررسمی‌اند و با فرا‌داده توصیف می‌شوند. تعریف این‌که یک برنامه چه چیزهایی را دربر می‌گیرد، انعطاف‌پذیر است. + +{{< note >}} +این‌ها برچسب‌های پیشنهادی هستند. استفاده از آن‌ها مدیریت برنامه‌ها را ساده‌تر می‌کند، اما برای هیچ ابزار هسته‌ای الزامی نیست. +{{< /note >}} + +برچسب‌ها و حاشیه‌نویس‌های مشترک، پیشوند یکسانی دارند: `app.kubernetes.io`. +برچسب‌های بدون پیشوند خصوصیِ کاربران‌اند. این پیشوند مشترک اطمینان می‌دهد که برچسب‌های مشترک با برچسب‌های سفارشی کاربر تداخل نداشته باشند. + +## برچسب‌ها + +برای بهره‌گیری کامل از این برچسب‌ها، باید آن‌ها را روی هر شیء منبع اعمال کنید. + +| Key | Description | Example | Type | +| ----------------------------------- | --------------------- | -------- | ---- | +| `app.kubernetes.io/name` | The name of the application | `mysql` | string | +| `app.kubernetes.io/instance` | A unique name identifying the instance of an application | `mysql-abcxyz` | string | +| `app.kubernetes.io/version` | The current version of the application (e.g., a [SemVer 1.0](https://semver.org/spec/v1.0.0.html), revision hash, etc.) | `5.7.21` | string | +| `app.kubernetes.io/component` | The component within the architecture | `database` | string | +| `app.kubernetes.io/part-of` | The name of a higher level application this one is part of | `wordpress` | string | +| `app.kubernetes.io/managed-by` | The tool being used to manage the operation of an application | `Helm` | string | + +برای نشان دادن این برچسب‌ها در عمل، شیء {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} زیر را در نظر بگیرید: + +```yaml +# This is an excerpt +apiVersion: apps/v1 +kind: StatefulSet +metadata: + labels: + app.kubernetes.io/name: mysql + app.kubernetes.io/instance: mysql-abcxyz + app.kubernetes.io/version: "5.7.21" + app.kubernetes.io/component: database + app.kubernetes.io/part-of: wordpress + app.kubernetes.io/managed-by: Helm +``` + +## برنامه‌ها و نمونه‌های برنامه + +یک برنامه می‌تواند یک یا چند بار در یک خوشه کوبرنتیز (و در برخی موارد در همان namespace) نصب شود. +برای نمونه، می‌توان WordPress را بیش از یک بار نصب کرد؛ به‌گونه‌ای که وب‌سایت‌های مختلف، نصب‌های متفاوتی از WordPress باشند. + +نام برنامه و نام نمونه آن به‌طور جداگانه ثبت می‌شوند. +برای مثال، WordPress دارای `app.kubernetes.io/name` برابر با `wordpress` است، در حالی که نام نمونه آن با `app.kubernetes.io/instance` مشخص می‌شود و مقداری مانند `wordpress-abcxyz` دارد. +این کار باعث می‌شود هم برنامه و هم نمونه آن قابل شناسایی باشند. +هر نمونه از یک برنامه باید نام یکتایی داشته باشد. + +## مثال‌ها + +برای نشان دادن روش‌های گوناگون استفاده از این برچسب‌ها، مثال‌های زیر سطوح مختلفی از پیچیدگی را دارند. + +### یک سرویس بی‌حالت ساده + +حالت یک سرویس بی‌حالت ساده را که با اشیای `Deployment` و `Service` استقرار یافته در نظر بگیرید. +دو قطعه زیر نشان می‌دهند که برچسب‌ها چگونه می‌توانند در ساده‌ترین شکل به کار روند. + +`Deployment` برای نظارت بر پادهایی که خودِ برنامه را اجرا می‌کنند به کار می‌رود. +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + labels: + app.kubernetes.io/name: myservice + app.kubernetes.io/instance: myservice-abcxyz +... +``` + +از `Service` برای نمایش برنامه استفاده می‌شود. +```yaml +apiVersion: v1 +kind: Service +metadata: + labels: + app.kubernetes.io/name: myservice + app.kubernetes.io/instance: myservice-abcxyz +... +``` + +### برنامه وب با یک پایگاه داده + +یک برنامه کمی پیچیده‌تر را در نظر بگیرید: یک برنامه وب (WordPress) +که از یک پایگاه داده (MySQL) استفاده می‌کند و با Helm نصب شده است. +قطعه‌های زیر آغاز اشیایی را نشان می‌دهند که برای استقرار این برنامه به‌کار می‌روند. + +بخش ابتدایی `Deployment` زیر برای WordPress به‌کار می‌رود: + +```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + labels: + app.kubernetes.io/name: wordpress + app.kubernetes.io/instance: wordpress-abcxyz + app.kubernetes.io/version: "4.9.4" + app.kubernetes.io/managed-by: Helm + app.kubernetes.io/component: server + app.kubernetes.io/part-of: wordpress +... +``` + +از `Service` برای نمایش وردپرس استفاده می‌شود: + +```yaml +apiVersion: v1 +kind: Service +metadata: + labels: + app.kubernetes.io/name: wordpress + app.kubernetes.io/instance: wordpress-abcxyz + app.kubernetes.io/version: "4.9.4" + app.kubernetes.io/managed-by: Helm + app.kubernetes.io/component: server + app.kubernetes.io/part-of: wordpress +... +``` + +MySQL به‌صورت یک `StatefulSet` در دسترس قرار می‌گیرد و برای خودش و همچنین برای برنامه بزرگ‌تری که به آن تعلق دارد، متادیتا دارد: + +```yaml +apiVersion: apps/v1 +kind: StatefulSet +metadata: + labels: + app.kubernetes.io/name: mysql + app.kubernetes.io/instance: mysql-abcxyz + app.kubernetes.io/version: "5.7.21" + app.kubernetes.io/managed-by: Helm + app.kubernetes.io/component: database + app.kubernetes.io/part-of: wordpress +... +``` + +از شیء `Service` برای در معرض قرار دادن MySQL به‌عنوان بخشی از WordPress استفاده می‌شود: + +```yaml +apiVersion: v1 +kind: Service +metadata: + labels: + app.kubernetes.io/name: mysql + app.kubernetes.io/instance: mysql-abcxyz + app.kubernetes.io/version: "5.7.21" + app.kubernetes.io/managed-by: Helm + app.kubernetes.io/component: database + app.kubernetes.io/part-of: wordpress +... +``` + +در `StatefulSet` و `Service` مربوط به MySQL مشاهده می‌کنید که اطلاعات مربوط به هر دو، یعنی MySQL و WordPress به‌عنوان برنامه گسترده‌تر، درج شده است. diff --git a/content/fa/docs/concepts/overview/working-with-objects/field-selectors.md b/content/fa/docs/concepts/overview/working-with-objects/field-selectors.md new file mode 100644 index 0000000000000..00f4f91c9e85d --- /dev/null +++ b/content/fa/docs/concepts/overview/working-with-objects/field-selectors.md @@ -0,0 +1,81 @@ +--- +title: انتخابگرهای فیلد +content_type: concept +weight: 70 +--- + +_انتخابگرهای فیلد (Field selectors)_ به شما امکان می‌دهند {{< glossary_tooltip text="اشیا" term_id="object" >}} کوبرنتیز را بر اساس مقدار یک یا چند فیلدِ منبع انتخاب کنید. در ادامه چند نمونه از جستارهای انتخابگر فیلد آمده است: + +* `metadata.name=my-service` +* `metadata.namespace!=default` +* `status.phase=Pending` + +این دستور `kubectl` تمام پادهایی را انتخاب می‌کند که مقدار فیلد [`status.phase`](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) آن‌ها `Running` باشد: + +```shell +kubectl get pods --field-selector status.phase=Running +``` + +{{< note >}} +انتخابگرهای فیلد در اصل *فیلتر* منابع هستند. به‌طور پیش‌فرض هیچ انتخابگر/فیلتری اعمال نمی‌شود؛ یعنی همه منابع از نوع مشخص‌شده برگزیده می‌شوند. به همین دلیل دو فرمان زیر در `kubectl` معادل‌اند: +`kubectl get pods` و `kubectl get pods --field-selector ""`. +{{< /note >}} + +## فیلدهای پشتیبانی‌شده + +انتخابگرهای فیلد پشتیبانی‌شده بسته به نوع منبع کوبرنتیز متفاوت‌اند. همه انواع منبع از فیلدهای `metadata.name` و `metadata.namespace` پشتیبانی می‌کنند. استفاده از انتخابگرهای فیلد پشتیبانی‌نشده باعث خطا می‌شود. برای مثال: + +```shell +kubectl get ingress --field-selector foo.bar=baz +``` +``` +Error from server (BadRequest): Unable to find "ingresses" that match label selector "", field selector "foo.bar=baz": "foo.bar" is not a known field selector: only "metadata.name", "metadata.namespace" +``` + +### فهرست فیلدهای پشتیبانی شده + +| Kind | Fields | +| ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Pod | `spec.nodeName`
`spec.restartPolicy`
`spec.schedulerName`
`spec.serviceAccountName`
`spec.hostNetwork`
`status.phase`
`status.podIP`
`status.nominatedNodeName` | +| Event | `involvedObject.kind`
`involvedObject.namespace`
`involvedObject.name`
`involvedObject.uid`
`involvedObject.apiVersion`
`involvedObject.resourceVersion`
`involvedObject.fieldPath`
`reason`
`reportingComponent`
`source`
`type` | +| Secret | `type` | +| Namespace | `status.phase` | +| ReplicaSet | `status.replicas` | +| ReplicationController | `status.replicas` | +| Job | `status.successful` | +| Node | `spec.unschedulable` | +| CertificateSigningRequest | `spec.signerName` | + +### فیلدهای منابع سفارشی + +تمام انواع منبع سفارشی از فیلدهای `metadata.name` و `metadata.namespace` پشتیبانی می‌کنند. + +علاوه بر این، فیلد `spec.versions[*].selectableFields` در یک {{< glossary_tooltip term_id="CustomResourceDefinition" text="CustomResourceDefinition" >}} تعیین می‌کند که کدام فیلدهای دیگرِ یک منبع سفارشی را می‌توان در انتخابگرهای فیلد به‌کار برد. برای اطلاعات بیشتر درباره استفاده از انتخابگرهای فیلد همراه با CustomResourceDefinitionها، به [فیلدهای قابل انتخاب برای منابع سفارشی](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#crd-selectable-fields) مراجعه کنید. + +## عملگرهای پشتیبانی‌شده + +می‌توانید از عملگرهای `=`, `==` و `!=` در انتخابگرهای فیلد استفاده کنید (دو عملگر `=` و `==` معادل هم هستند). برای مثال، این فرمان `kubectl` تمامی سرویس‌های کوبرنتیز را که در فضای نام `default` نیستند انتخاب می‌کند: + +```shell +kubectl get services --all-namespaces --field-selector metadata.namespace!=default +``` +{{< note >}} +عملگرهای [مبتنی بر مجموعه](/docs/concepts/overview/working-with-objects/labels/#set-based-requirement) +(`in`، `notin`، `exists`) برای انتخابگرهای فیلد پشتیبانی نمی‌شوند. +{{< /note >}} + +## انتخابگرهای زنجیره‌ای + +مانند [برچسب](/docs/concepts/overview/working-with-objects/labels) و سایر انتخابگرها، انتخابگرهای فیلد را می‌توان به‌صورت فهرستی جداشده با ویرگول به یکدیگر زنجیر کرد. این فرمان `kubectl` تمامی پادهایی را انتخاب می‌کند که مقدار `status.phase` آن‌ها برابر با `Running` نیست و فیلد `spec.restartPolicy` آن‌ها برابر با `Always` است: + +```shell +kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always +``` + +## چندین نوع منبع + +می‌توانید از انتخابگرهای فیلد برای انواع مختلف منبع استفاده کنید. این فرمان `kubectl` تمامی StatefulSet‌ها و Service‌ها را که در فضای نام `default` نیستند انتخاب می‌کند: + +```shell +kubectl get statefulsets,services --all-namespaces --field-selector metadata.namespace!=default +``` diff --git a/content/fa/docs/concepts/overview/working-with-objects/finalizers.md b/content/fa/docs/concepts/overview/working-with-objects/finalizers.md new file mode 100644 index 0000000000000..7ca0cc0f15d02 --- /dev/null +++ b/content/fa/docs/concepts/overview/working-with-objects/finalizers.md @@ -0,0 +1,77 @@ +--- +title: نهایی کننده ها +content_type: concept +weight: 80 +--- + + + +{{}} + +می‌توانید از **پایان‌دهنده‌ها** (finalizerها) برای کنترل {{}} +اشیاء {{< glossary_tooltip text="objects" term_id="object" >}} استفاده کنید؛ به این ترتیب که به +{{}}‌ اطلاع می‌دهید پیش از حذف منبع هدف، وظایف پاک‌سازی مشخصی را انجام دهند. + +پایان‌دهنده‌ها معمولاً کد اجرایی را مشخص نمی‌کنند؛ بلکه فهرستی از کلیدها روی یک منبع—مشابه حاشیه‌نویس‌ها—هستند. +برخی پایان‌دهنده‌ها به‌طور خودکار توسط کوبرنتیز افزوده می‌شوند، اما می‌توانید پایان‌دهنده‌های خود را نیز تعریف کنید. + +## نحوه کار پایان‌دهنده‌ها + +هنگام ایجاد یک منبع با فایل مانیفست، می‌توانید پایان‌دهنده‌ها را در فیلد `metadata.finalizers` تعیین کنید. +وقتی درخواست حذف منبع را می‌دهید، سرور API که این درخواست را پردازش می‌کند مقدارهای فیلد `finalizers` را می‌بیند و: + +* شیء را طوری تغییر می‌دهد که فیلد `metadata.deletionTimestamp` با زمان آغاز حذف افزوده شود؛ +* از حذف شیء جلوگیری می‌کند تا زمانی که تمام موارد از فیلد `metadata.finalizers` آن حذف شوند؛ +* کد وضعیت `202` ‏(HTTP «Accepted») را برمی‌گرداند. + +کنترلری که مسئول آن پایان‌دهنده است، به‌روزرسانی شیء و تنظیم فیلد `metadata.deletionTimestamp` را می‌بیند—علامتی که نشان می‌دهد حذف شیء درخواست شده است. +کنترلر سپس می‌کوشد نیازهای پایان‌دهنده‌های مشخص‌شده برای آن منبع را برآورده کند. هر بار که شرط یک پایان‌دهنده برقرار شد، کنترلر آن کلید را از فیلد `finalizers` منبع برمی‌دارد. +وقتی فیلد `finalizers` خالی شود، شیئی که فیلد `deletionTimestamp` برای آن تنظیم شده، به‌طور خودکار حذف می‌شود. +همچنین می‌توانید از پایان‌دهنده‌ها برای جلوگیری از حذف منابعی استفاده کنید که تحت مدیریت نیستند. + +یک نمونه رایج پایان‌دهنده، `kubernetes.io/pv-protection` است که از حذف تصادفی اشیای `PersistentVolume` جلوگیری می‌کند. +وقتی یک شیء `PersistentVolume` توسط یک Pod استفاده می‌شود، کوبرنتیز پایان‌دهنده `pv-protection` را اضافه می‌کند. +اگر بخواهید آن `PersistentVolume` را حذف کنید، شیء در وضعیت `Terminating` باقی می‌ماند، اما کنترلر نمی‌تواند آن را حذف کند چون پایان‌دهنده وجود دارد. +وقتی Pod دیگر از `PersistentVolume` استفاده نکند، کوبرنتیز پایان‌دهنده `pv-protection` را پاک می‌کند و کنترلر حجم را حذف می‌کند. + +{{}} +* هنگام `DELETE` کردن یک شیء، کوبرنتیز زمان‌سنج حذف را برای آن شیء اضافه می‌کند و سپس بلافاصله شروع به محدود کردن تغییرات در فیلد `.metadata.finalizers` آن شیء می‌کند که اکنون در حالت انتظار حذف است. شما می‌توانید پایان‌دهنده‌های موجود را حذف کنید (حذف یک ورودی از فهرست `finalizers`)، اما نمی‌توانید پایان‌دهنده جدیدی اضافه کنید. همچنین نمی‌توانید پس از تنظیم، `deletionTimestamp` را تغییر دهید. + +* پس از درخواست حذف، نمی‌توانید این شیء را باززنده کنید. تنها راه، حذف آن و ایجاد یک شیء مشابه جدید است. +{{}} + +{{}} +نام‌های پایان‌دهنده سفارشی **باید** نام‌های پایان‌دهنده واجد شرایط عمومی باشند، مانند `example.com/finalizer-name`. کوبرنتیز این قالب را اجرا می‌کند؛ سرور API نوشتن روی اشیایی را که تغییر آن‌ها از نام‌های واجد شرایط پایان‌دهنده برای هر پایان‌دهنده سفارشی استفاده نمی‌کند، رد می‌کند. +{{}} + +## مراجع مالک، برچسب‌ها و پایان‌دهنده‌ها {#owners-labels-finalizers} + +مانند {{}} +[مراجع مالک](/docs/concepts/overview/working-with-objects/owners-dependents/) +روابط بین اشیاء در کوبرنتیز را توصیف می‌کنند، اما برای هدف متفاوتی استفاده می‌شوند. +هنگامی که یک {{}} اشیایی مانند Pod را مدیریت می‌کند، +از برچسب‌ها برای پیگیری تغییرات گروهی از اشیاء مرتبط استفاده می‌کند. + +برای مثال، وقتی یک {{}} یک یا چند Pod ایجاد می‌کند، +کنترلر Job به آن پادها برچسب می‌زند و تغییرات هر Pod در خوشه با همان برچسب را پیگیری می‌کند. + +کنترلر Job همچنین *مراجع مالک* را به آن پادها اضافه می‌کند که به Jobی اشاره دارند +که پادها را ایجاد کرده است. +اگر Job را زمانی که این پادها در حال اجرا هستند حذف کنید، کوبرنتیز از مراجع مالک (نه برچسب‌ها) +برای تعیین این که کدام پادها در خوشه نیاز به پاک‌سازی دارند، استفاده می‌کند. + +کوبرنتیز همچنین هنگام شناسایی مراجع مالک روی منبع هدف قرار گرفته برای حذف، +پایان‌دهنده‌ها را پردازش می‌کند. + +در برخی مواقع، پایان‌دهنده‌ها می‌توانند از حذف اشیاء وابسته جلوگیری کنند، +که ممکن است باعث شود شیء مالک هدف برای مدتی طولانی‌تر از حد انتظار بدون حذف کامل باقی بماند. +در این شرایط باید پایان‌دهنده‌ها و مراجع مالک را روی شیء مالک هدف و اشیاء وابسته بررسی کنید +تا علت را عیب‌یابی کنید. + +{{}} +در مواردی که اشیاء در حالت حذف گیر کرده‌اند، از حذف دستی پایان‌دهنده‌ها خودداری کنید تا فرایند حذف ادامه یابد. پایان‌دهنده‌ها معمولاً به دلایلی به منابع اضافه می‌شوند، پس حذف اجباری آن‌ها می‌تواند به مشکلاتی در خوشه شما منجر شود. این کار تنها زمانی انجام شود که هدف پایان‌دهنده مشخص باشد و به روش دیگری (مثلاً پاک‌سازی دستی یک شیء وابسته) برآورده شده باشد. +{{}} + +## {{% heading "whatsnext" %}} + +* [استفاده از پایان‌دهنده‌ها برای کنترل حذف](/blog/2021/05/14/using-finalizers-to-control-deletion/) را در بلاگ کوبرنتیز بخوانید. diff --git a/content/fa/docs/concepts/overview/working-with-objects/labels.md b/content/fa/docs/concepts/overview/working-with-objects/labels.md new file mode 100644 index 0000000000000..4c1f07ed56c6a --- /dev/null +++ b/content/fa/docs/concepts/overview/working-with-objects/labels.md @@ -0,0 +1,364 @@ +--- +reviewers: +- xirehat +title: برچسب‌ها و انتخابگرها +content_type: concept +weight: 40 +--- + + + +_برچسب‌ها_ نگاشت‌های کلید/مقدار هستند که به {{< glossary_tooltip text="اشیاء" term_id="object" >}} مانند پادها متصل می‌شوند. +برچسب‌ها برای مشخص‌کردن ویژگی‌های شناسایی‌کننده اشیاء طراحی شده‌اند که برای کاربران معنادار و مرتبط‌اند، اما مستقیماً معنایی به سیستم هسته‌ای اضافه نمی‌کنند. +می‌توان از برچسب‌ها برای سازمان‌دهی و انتخاب زیرمجموعه‌ای از اشیاء استفاده کرد. +برچسب‌ها را می‌توان هنگام ایجاد شیء افزود و در هر زمان بعدی تغییر داد یا برچسب جدید اضافه کرد. +هر شیء می‌تواند مجموعه‌ای از برچسب‌های کلید/مقدار داشته باشد. +هر کلید باید برای یک شیء مشخص یکتا باشد. + +```json +"metadata": { + "labels": { + "key1" : "value1", + "key2" : "value2" + } +} +``` + +برچسب‌ها امکان اجرای پرس‌وجوها و واچ‌های کارا را فراهم می‌کنند و برای استفاده در رابط‌های کاربری گرافیکی (UI) و خط فرمان (CLI) ایده‌آل هستند. اطلاعات غیرشناسه‌ای باید با استفاده از [حاشیه‌نویس‌ها](/docs/concepts/overview/working-with-objects/annotations/) ثبت شوند. + + + +## انگیزه + +برچسب‌ها به کاربران اجازه می‌دهند ساختارهای سازمانی خود را به‌صورت اتصال سست (loosely coupled) بر روی اشیاء سیستم نگاشت کنند، بدون آن‌که کلاینت‌ها نیاز به ذخیره این نگاشت‌ها داشته باشند. + +استقرار سرویس‌ها و خطوط پردازش دسته‌ای (batch) اغلب موجودیت‌های چندبعدی هستند (مثلاً چند بخش یا استقرار، چند مسیر انتشار، چند لایه، چند میکروسرویس در هر لایه). در بسیاری موارد، مدیریت نیازمند انجام عملیات‌های عرضی (cross-cutting) است که انتزاع‌های صرفاً سلسله‌مراتبی—به‌ویژه سلسله‌مراتبی‌های صلبی که توسط زیرساخت تعیین شده‌اند و نه توسط کاربران—را می‌شکند. + +برچسب‌های نمونه: + +* `"release" : "stable"`, `"release" : "canary"` +* `"environment" : "dev"`, `"environment" : "qa"`, `"environment" : "production"` +* `"tier" : "frontend"`, `"tier" : "backend"`, `"tier" : "cache"` +* `"partition" : "customerA"`, `"partition" : "customerB"` +* `"track" : "daily"`, `"track" : "weekly"` + +این‌ها مثال‌هایی از +[برچسب‌های رایج](/docs/concepts/overview/working-with-objects/common-labels/) هستند؛ می‌توانید قراردادهای خود را تعریف کنید. +به خاطر داشته باشید که کلید برچسب برای هر شیء باید یکتا باشد. + +## نحو و مجموعه نویسه + +_برچسب‌ها_ نگاشت‌های کلید/مقدار هستند. کلیدهای معتبر برچسب دو بخش دارند: یک پیشوند اختیاری و یک نام که با اسلش (`/`) از هم جدا می‌شوند. بخش نام الزامی است و باید حداکثر ۶۳ نویسه باشد؛ نام باید با یک نویسه الفانامریک (`[a-z0-9A-Z]`) شروع و پایان یابد و می‌تواند در میان شامل خط تیره (`-`)، زیرخط (`_`)، نقطه (`.`) و نویسه‌های الفانامریک باشد. پیشوند اختیاری است. اگر مشخص شود، باید یک زیر‌دامنه DNS باشد: مجموعه‌ای از برچسب‌های DNS که با نقطه (`.`) از هم جدا شده‌اند، مجموعاً بیشتر از ۲۵۳ نویسه نباشند و در پایان با اسلش (`/`) دنبال شوند. + +اگر پیشوند حذف شود، فرض بر این است که کلید برچسب خصوصیِ کاربر است. اجزای خودکار سامانه (مثلاً `kube-scheduler`، `kube-controller-manager`، `kube-apiserver`، `kubectl` یا سایر اتوماسیون‌های شخص ثالث) که برچسب به اشیاء کاربر نهایی اضافه می‌کنند، باید حتماً پیشوند مشخص کنند. + +پیشوندهای `kubernetes.io/` و `k8s.io/` برای اجزای اصلی کوبرنتیز +[رزرو شده‌اند](/docs/reference/labels-annotations-taints/). + +مقدار معتبر برچسب: + +* باید حداکثر ۶۳ نویسه باشد (می‌تواند خالی باشد)، +* اگر خالی نباشد، باید با یک نویسه الفانامریک (`[a-z0-9A-Z]`) شروع و پایان یابد، +* می‌تواند شامل خط تیره (`-`)، زیرخط (`_`)، نقطه (`.`) و نویسه‌های الفانامریک بین آن‌ها باشد. + +برای مثال، در اینجا مانیفستی برای یک Pod آمده است که دو برچسب +`environment: production` و `app: nginx` دارد: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: label-demo + labels: + environment: production + app: nginx +spec: + containers: + - name: nginx + image: nginx:1.14.2 + ports: + - containerPort: 80 +``` + +## انتخابگرهای برچسب + +برخلاف [نام‌ها و UIDها](/docs/concepts/overview/working-with-objects/names/)، برچسب‌ها یکتایی را تضمین نمی‌کنند. در حالت کلی انتظار می‌رود اشیاء مختلف، برچسب(های) یکسانی داشته باشند. + +از طریق _انتخابگر برچسب_، کلاینت/کاربر می‌تواند مجموعه‌ای از اشیاء را شناسایی کند. انتخابگر برچسب، اصلی‌ترین ساختار گروه‌بندی در کوبرنتیز است. + +در حال حاضر API دو نوع انتخابگر را پشتیبانی می‌کند: _مبتنی بر برابری_ و _مبتنی بر مجموعه_. یک انتخابگر برچسب می‌تواند از چند _الزام_ تشکیل شده باشد که با ویرگول از هم جدا شده‌اند. در صورت وجود چند الزام، همه آن‌ها باید برآورده شوند، بنابراین ویرگول نقش عملگر منطقی _AND_ (`&&`) را دارد. + +معنای انتخابگرهای خالی یا مشخص‌نشده وابسته به زمینه است و انواع API که از انتخابگر استفاده می‌کنند باید در مستندات خود در مورد اعتبار و معنی این انتخابگرها توضیح دهند. + +{{< note >}} +برای برخی انواع API، مانند ReplicaSetها، انتخابگرهای برچسب دو نمونه در یک namespace نباید با هم همپوشانی داشته باشند، زیرا کنترلر ممکن است این را دستور متضاد تلقی کرده و نتواند تعیین کند چه تعداد Replica باید وجود داشته باشد. +{{< /note >}} + +{{< caution >}} +برای هر دو حالت مبتنی بر برابری و مبتنی بر مجموعه، عملگر منطقی _OR_ (`||`) وجود ندارد. مطمئن شوید شروط فیلتر شما متناسب با این محدودیت ساختاربندی شده باشند. +{{< /caution >}} + +### الزام‌های مبتنی بر برابری + +الزام‌های مبتنی بر _برابری_ یا _نابرابری_ امکان فیلتر کردن بر اساس کلید و مقدار برچسب را فراهم می‌کنند. اشیاء منطبق باید تمام محدودیت‌های برچسب مشخص‌شده را برآورده کنند، هرچند ممکن است برچسب‌های اضافی نیز داشته باشند. سه نوع عملگر مجاز هستند: `=`, `==`, `!=`. دو عملگر اول نمایانگر _برابری_ (و هم‌معنا) هستند، در حالی که عملگر سوم نمایانگر _نابرابری_ است. برای مثال: + +``` +environment = production +tier != frontend +``` + +کد اول تمام منابعی را انتخاب می‌کند که کلیدشان برابر `environment` و مقدارشان برابر `production` است. کد دوم تمام منابعی را انتخاب می‌کند که کلیدشان برابر `tier` و مقدارشان متفاوت از `frontend` است، و همچنین منابعی که اصلاً برچسبی با کلید `tier` ندارند. می‌توانید منابع در `production` به‌استثنای `frontend` را با عملگر ویرگول فیلتر کنید: `environment=production,tier!=frontend` + +یکی از سناریوهای کاربردی برای الزام مبتنی بر برابری، مشخص کردن معیارهای انتخاب نود برای پادها است. برای مثال، پاد نمونه زیر نودهایی را انتخاب می‌کند که برچسب `accelerator` در آن‌ها وجود دارد و مقدارش `nvidia-tesla-p100` است. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: cuda-test +spec: + containers: + - name: cuda-test + image: "registry.k8s.io/cuda-vector-add:v0.1" + resources: + limits: + nvidia.com/gpu: 1 + nodeSelector: + accelerator: nvidia-tesla-p100 +``` + +### الزام‌های مبتنی بر مجموعه + +الزام‌های برچسب مبتنی بر _مجموعه_ امکان فیلتر کردن کلیدها بر اساس یک مجموعه از مقادیر را فراهم می‌کنند. سه نوع عملگر پشتیبانی می‌شوند: `in`، `notin` و `exists` (فقط شناسه کلید). برای مثال: + +``` +environment in (production, qa) +tier notin (frontend, backend) +partition +!partition +``` + +- مثال اول تمام منابعی را انتخاب می‌کند که کلیدشان برابر `environment` باشد و مقدارشان برابر `production` یا `qa`. +- مثال دوم تمام منابعی را انتخاب می‌کند که کلیدشان برابر `tier` باشد و مقادیرشان غیر از `frontend` و `backend` باشد، و همچنین منابعی که اصلاً برچسبی با کلید `tier` ندارند. +- مثال سوم تمام منابعی را انتخاب می‌کند که برچسبی با کلید `partition` دارند؛ هیچ مقداری بررسی نمی‌شود. +- مثال چهارم تمام منابعی را انتخاب می‌کند که برچسبی با کلید `partition` ندارند؛ هیچ مقداری بررسی نمی‌شود. + +به‌نحوی مشابه، جداکننده ویرگول نقش عملگر _AND_ را دارد. بنابراین فیلتر کردن منابعی که کلید `partition` دارند (صرف‌نظر از مقدار) و مقادیر `environment` آن‌ها متفاوت از `qa` باشد، با عبارت زیر امکان‌پذیر است: +``partition,environment notin (qa)`` + +انتخابگر برچسب _مبتنی بر مجموعه_ یک شکل کلی از برابری است، زیرا +``environment=production`` معادل +``environment in (production)`` است؛ +که برای عملگرهای `!=` و `notin` نیز صادق است. + +_الزام‌های مبتنی بر مجموعه_ می‌توانند با _الزام‌های مبتنی بر برابری_ ترکیب شوند. +به‌عنوان مثال: `partition in (customerA, customerB),environment!=qa`. + +## API + +### فیلتر کردن LIST و WATCH + +برای عملیات **لیست** و **واچ**، می‌توانید انتخابگرهای برچسب را برای فیلتر کردن مجموعه اشیاء بازگردانده‌شده مشخص کنید؛ این فیلتر را با یک پارامتر پرس‌وجو تعیین می‌کنید. +(برای آشنایی دقیق با واچ‌ها در کوبرنتیز، بخش +[کشف مؤثر تغییرات](/docs/reference/using-api/api-concepts/#efficient-detection-of-changes) +را مطالعه کنید). +هر دو نوع الزام مجاز هستند +(در اینجا همان‌طور که در رشته پرس‌وجوی URL ظاهر می‌شوند نشان داده شده‌اند): + +* الزام‌های _مبتنی بر برابری_: `?labelSelector=environment%3Dproduction,tier%3Dfrontend` +* الزام‌های _مبتنی بر مجموعه_: `?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29` + +هر دو سبک انتخابگر برچسب را می‌توان برای لیست‌کردن یا واچ منابع از طریق یک REST client به کار برد. +برای مثال، با هدف قرار دادن `apiserver` با `kubectl` و استفاده از الزام _مبتنی بر برابری_ می‌توان نوشت: + +```shell +kubectl get pods -l environment=production,tier=frontend +``` + +یا با استفاده از الزام‌های مبتنی بر مجموعه: + +```shell +kubectl get pods -l 'environment in (production),tier in (frontend)' +``` + +همانطور که قبلاً اشاره شد، الزامات مبتنی بر مجموعه، گویاتر هستند. برای مثال، می‌توانند عملگر _OR_ را روی مقادیر پیاده‌سازی کنند: + +```shell +kubectl get pods -l 'environment in (production, qa)' +``` + +یا محدود کردن تطبیق منفی از طریق عملگر _notin_: + +```shell +kubectl get pods -l 'environment,environment notin (frontend)' +``` + +### تنظیم ارجاعات مجموعه‌ای در اشیای API + +برخی از اشیای کوبرنتیز، مانند [`service`](/docs/concepts/services-networking/service/) +و [`replicationcontroller`](/docs/concepts/workloads/controllers/replicationcontroller/)، +از انتخابگرهای برچسب برای مشخص‌کردن مجموعه‌ای از منابع دیگر (مانند [پادها](/docs/concepts/workloads/pods/)) استفاده می‌کنند. + +#### Service و ReplicationController + +مجموعه پادهایی که یک `service` به آن‌ها هدف‌گذاری می‌کند با یک انتخابگر برچسب تعریف می‌شود. +به‌طور مشابه، مجموعه پادهایی که یک `replicationcontroller` باید آن‌ها را مدیریت کند نیز با انتخابگر برچسب مشخص می‌شود. + +انتخابگرهای برچسب برای هر دو شیء در فایل‌های `json` یا `yaml` با استفاده از نقشه‌ها (maps) تعریف می‌شوند +و فقط انتخابگرهای مبتنی بر _برابری_ پشتیبانی می‌شوند: + +```json +"selector": { + "component" : "redis", +} +``` + +یا + +```yaml +selector: + component: redis +``` + +این انتخابگر (به‌ترتیب در قالب `json` یا `yaml`) معادل +`component=redis` یا `component in (redis)` است. + +#### منابعی که از الزام‌های مبتنی بر مجموعه پشتیبانی می‌کنند + +منابع جدیدتر مانند [`Job`](/docs/concepts/workloads/controllers/job/)، +[`Deployment`](/docs/concepts/workloads/controllers/deployment/)، +[`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) و +[`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) +از الزام‌های _مبتنی بر مجموعه_ نیز پشتیبانی می‌کنند. + +```yaml +selector: + matchLabels: + component: redis + matchExpressions: + - { key: tier, operator: In, values: [cache] } + - { key: environment, operator: NotIn, values: [dev] } +``` + +`matchLabels` یک نگاشت از زوج‌های `{کلید، مقدار}` است. یک `{کلید، مقدار}` تکی در نگاشت `matchLabels` +معادل یک عنصر از `matchExpressions` است که در آن فیلد `key` برابر "key"، +عملگر `operator` برابر "In" و آرایه `values` فقط شامل "value" است. +`matchExpressions` فهرستی از الزامات انتخاب پاد (pod selector) است. +عملگرهای معتبر شامل In، NotIn، Exists و DoesNotExist هستند. +در حالت استفاده از In و NotIn، مجموعه مقادیر باید خالی نباشد. +تمام الزامات، چه از `matchLabels` و چه از `matchExpressions`، به‌صورت AND با هم ترکیب می‌شوند— +یعنی همگی باید برقرار باشند تا تطبیق انجام شود. + +#### انتخاب مجموعه‌هایی از نودها + +یکی از کاربردهای انتخاب بر اساس برچسب، محدود کردن مجموعه نودهایی است +که یک پاد می‌تواند روی آن‌ها زمان‌بندی شود. +برای اطلاعات بیشتر، مستندات مربوط به +[انتخاب نود](/docs/concepts/scheduling-eviction/assign-pod-node/) را مشاهده کنید. + +## استفاده مؤثر از برچسب‌ها + +می‌توانید یک برچسب را روی هر منبعی اعمال کنید، +اما این همیشه بهترین روش نیست. +در بسیاری از سناریوها باید از چند برچسب برای تمایز مجموعه‌های منابع از یکدیگر استفاده کرد. + +برای مثال، برنامه‌های مختلف ممکن است مقادیر متفاوتی برای برچسب `app` داشته باشند، +اما یک برنامه چندلایه مانند [مثال guestbook](https://github.com/kubernetes/examples/tree/master/guestbook/) +نیاز دارد که هر لایه را نیز از هم متمایز کند. +لایه frontend می‌تواند برچسب‌های زیر را داشته باشد: + +```yaml +labels: + app: guestbook + tier: frontend +``` + +در حالی که Redis master و replica برچسب‌های `tier` متفاوتی خواهند داشت، و شاید حتی یک برچسب `role` اضافی: + +```yaml +labels: + app: guestbook + tier: backend + role: master +``` + +و + +```yaml +labels: + app: guestbook + tier: backend + role: replica +``` + +برچسب‌ها امکان برش و تفکیک منابع را در امتداد هر بُعدی که توسط یک برچسب مشخص شده است، فراهم می‌کنند: + +```shell +kubectl apply -f examples/guestbook/all-in-one/guestbook-all-in-one.yaml +kubectl get pods -Lapp -Ltier -Lrole +``` + +```none +NAME READY STATUS RESTARTS AGE APP TIER ROLE +guestbook-fe-4nlpb 1/1 Running 0 1m guestbook frontend +guestbook-fe-ght6d 1/1 Running 0 1m guestbook frontend +guestbook-fe-jpy62 1/1 Running 0 1m guestbook frontend +guestbook-redis-master-5pg3b 1/1 Running 0 1m guestbook backend master +guestbook-redis-replica-2q2yf 1/1 Running 0 1m guestbook backend replica +guestbook-redis-replica-qgazl 1/1 Running 0 1m guestbook backend replica +my-nginx-divi2 1/1 Running 0 29m nginx +my-nginx-o0ef1 1/1 Running 0 29m nginx +``` + +```shell +kubectl get pods -lapp=guestbook,role=replica +``` + +```none +NAME READY STATUS RESTARTS AGE +guestbook-redis-replica-2q2yf 1/1 Running 0 3m +guestbook-redis-replica-qgazl 1/1 Running 0 3m +``` + +## به‌روزرسانی برچسب‌ها + +گاهی ممکن است بخواهید پادهای موجود و سایر منابع را پیش از ایجاد منابع جدید، مجدداً برچسب‌گذاری کنید. +این کار را می‌توان با استفاده از دستور `kubectl label` انجام داد. +برای مثال، اگر بخواهید همه پادهای NGINX خود را به‌عنوان لایه frontend برچسب‌گذاری کنید، این دستور را اجرا کنید: + +```shell +kubectl label pods -l app=nginx tier=fe +``` + +```none +pod/my-nginx-2035384211-j5fhi labeled +pod/my-nginx-2035384211-u2c7e labeled +pod/my-nginx-2035384211-u3t6x labeled +``` + +این دستور ابتدا تمام پادها را با برچسب "app=nginx" فیلتر می‌کند و سپس آنها را با برچسب "tier=fe" مشخص می‌کند. +برای دیدن پادهایی که برچسب‌گذاری کرده‌اید، دستور زیر را اجرا کنید: + +```shell +kubectl get pods -l app=nginx -L tier +``` + +```none +NAME READY STATUS RESTARTS AGE TIER +my-nginx-2035384211-j5fhi 1/1 Running 0 23m fe +my-nginx-2035384211-u2c7e 1/1 Running 0 23m fe +my-nginx-2035384211-u3t6x 1/1 Running 0 23m fe +``` + +این دستور تمام پادهایی با برچسب "app=nginx" را نمایش می‌دهد، به‌همراه یک ستون برچسب اضافی برای tier پادها +(که با گزینه `-L` یا `--label-columns` مشخص می‌شود). + +برای اطلاعات بیشتر، به [kubectl label](/docs/reference/generated/kubectl/kubectl-commands/#label) مراجعه کنید. + +## {{% heading "whatsnext" %}} + +- یاد بگیرید چگونه [یک برچسب به نود اضافه کنید](/docs/tasks/configure-pod-container/assign-pods-nodes/#add-a-label-to-a-node) +- [برچسب‌ها، حاشیه‌نویس‌ها و تِینت‌های شناخته‌شده](/docs/reference/labels-annotations-taints/) را پیدا کنید +- [برچسب‌های پیشنهادی](/docs/concepts/overview/working-with-objects/common-labels/) را ببینید +- [اجرای استانداردهای امنیتی پاد با برچسب‌های Namespace](/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/) +- مقاله‌ای درباره [نوشتن کنترلر برای برچسب‌های پاد](/blog/2021/06/21/writing-a-controller-for-pod-labels/) بخوانید diff --git a/content/fa/docs/concepts/overview/working-with-objects/names.md b/content/fa/docs/concepts/overview/working-with-objects/names.md new file mode 100644 index 0000000000000..e676b9582d527 --- /dev/null +++ b/content/fa/docs/concepts/overview/working-with-objects/names.md @@ -0,0 +1,117 @@ +--- +reviewers: +- xirehat +title: نام‌ها و شناسه‌های اشیاء +content_type: concept +weight: 30 +--- + + + +هر {{< glossary_tooltip text="شیء" term_id="object" >}} در خوشه شما یک [_نام_](#names) دارد که برای آن نوع از منبع یکتا است. +همچنین هر شیء در کوبرنتیز یک [_UID_](#uids) دارد که در کل خوشه یکتا است. + +برای مثال، تنها می‌توانید یک پاد با نام `myapp-1234` در یک [namespace](/docs/concepts/overview/working-with-objects/namespaces/) داشته باشید، +اما می‌توانید هم یک پاد و هم یک Deployment با نام `myapp-1234` داشته باشید. + +برای ویژگی‌هایی که توسط کاربر ارائه می‌شوند و یکتا نیستند، کوبرنتیز [برچسب‌ها](/docs/concepts/overview/working-with-objects/labels/) و [حاشیه‌نویس‌ها](/docs/concepts/overview/working-with-objects/annotations/) را فراهم می‌کند. + + + +## نام‌ها + +{{< glossary_definition term_id="name" length="all" >}} + +**نام‌ها باید در تمام [نسخه‌های API](/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning) +برای یک منبع خاص یکتا باشند. منابع API با گروه API، نوع منبع، namespace (برای منابع namespaced)، و نام از هم متمایز می‌شوند. +به عبارت دیگر، نسخه API در این زمینه اهمیتی ندارد.** + +{{< note >}} +در مواردی که اشیاء نماینده موجودیت‌های فیزیکی هستند، مانند Node که نشان‌دهنده یک میزبان فیزیکی است، +اگر میزبان تحت همان نام مجدداً ایجاد شود بدون آن‌که Node قبلی حذف و دوباره ایجاد شود، +کوبرنتیز میزبان جدید را به‌عنوان همان میزبان قدیمی در نظر می‌گیرد که ممکن است به ناسازگاری‌هایی منجر شود. +{{< /note >}} + +سرور ممکن است هنگام ایجاد یک منبع، زمانی که به‌جای `name` فیلد `generateName` ارائه شود، یک نام تولید کند. +وقتی از `generateName` استفاده می‌شود، مقدار ارائه‌شده به‌عنوان پیشوند نام به‌کار می‌رود و سرور یک پسوند تولیدشده به آن اضافه می‌کند. +اگرچه نام به‌صورت خودکار تولید می‌شود، ممکن است با نام‌های موجود تداخل داشته باشد و پاسخ HTTP 409 بازگردد. +از نسخه Kubernetes v1.31 به بعد، احتمال وقوع این مشکل بسیار کمتر شده است، +زیرا سرور تا ۸ تلاش برای تولید نام یکتا انجام می‌دهد پیش از آن‌که پاسخ HTTP 409 بازگرداند. + +در ادامه چهار نوع از محدودیت‌های نام‌گذاری رایج برای منابع آورده شده است. + +### نام‌های زیردامنه‌ای DNS + +بیشتر انواع منابع نیاز به نامی دارند که بتوان از آن به‌عنوان یک زیردامنه DNS استفاده کرد، +مطابق با تعریف [RFC 1123](https://tools.ietf.org/html/rfc1123). +این به این معناست که نام باید: + +- حداکثر ۲۵۳ نویسه داشته باشد +- فقط شامل نویسه‌های الفانامریک کوچک، `-` یا `.` باشد +- با یک نویسه الفانامریک شروع شود +- با یک نویسه الفانامریک پایان یابد + +### نام‌های برچسبی RFC 1123 {#dns-label-names} + +برخی انواع منابع نیاز دارند که نام آن‌ها مطابق با استاندارد برچسب DNS +تعریف‌شده در [RFC 1123](https://tools.ietf.org/html/rfc1123) باشد. +این به این معناست که نام باید: + +- حداکثر ۶۳ نویسه داشته باشد +- فقط شامل نویسه‌های الفانامریک کوچک یا `-` باشد +- با یک نویسه الفانامریک شروع شود +- با یک نویسه الفانامریک پایان یابد + +### نام‌های برچسبی RFC 1035 + +برخی انواع منابع نیاز دارند که نام آن‌ها مطابق با استاندارد برچسب DNS +تعریف‌شده در [RFC 1035](https://tools.ietf.org/html/rfc1035) باشد. +این به این معناست که نام باید: + +- حداکثر ۶۳ نویسه داشته باشد +- فقط شامل نویسه‌های الفانامریک کوچک یا `-` باشد +- با یک نویسه الفبایی (حرف) کوچک شروع شود +- با یک نویسه الفانامریک پایان یابد + +{{< note >}} +تنها تفاوت بین استانداردهای برچسب RFC 1035 و RFC 1123 در این است که +برچسب‌های RFC 1123 اجازه دارند با عدد شروع شوند، +در حالی‌که برچسب‌های RFC 1035 فقط می‌توانند با حروف کوچک الفبایی شروع شوند. +{{< /note >}} + +### نام‌های بخش مسیر (Path Segment) + +برخی انواع منابع نیاز دارند که نام آن‌ها بتواند به‌صورت ایمن به‌عنوان یک بخش از مسیر (path segment) رمزگذاری شود. +به عبارت دیگر، نام نباید "." یا ".." باشد و همچنین نباید شامل "/" یا "%" باشد. + +در اینجا یک نمونه مانیفست برای یک Pod با نام `nginx-demo` آورده شده است: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: nginx-demo +spec: + containers: + - name: nginx + image: nginx:1.14.2 + ports: + - containerPort: 80 +``` + + +{{< note >}} +برخی انواع منابع محدودیت‌های بیشتری برای نام‌های خود دارند. +{{< /note >}} + +## UIDها + +{{< glossary_definition term_id="uid" length="all" >}} + +UIDهای کوبرنتیز شناسه‌های یکتای جهانی هستند (که با عنوان UUID نیز شناخته می‌شوند). +UUIDها مطابق با استانداردهای ISO/IEC 9834-8 و ITU-T X.667 تعریف شده‌اند. + +## {{% heading "whatsnext" %}} + +* درباره [برچسب‌ها](/docs/concepts/overview/working-with-objects/labels/) و [حاشیه‌نویس‌ها](/docs/concepts/overview/working-with-objects/annotations/) در کوبرنتیز مطالعه کنید. +* سند طراحی [شناسه‌ها و نام‌ها در کوبرنتیز](https://git.k8s.io/design-proposals-archive/architecture/identifiers.md) را ببینید. diff --git a/content/fa/docs/concepts/overview/working-with-objects/namespaces.md b/content/fa/docs/concepts/overview/working-with-objects/namespaces.md new file mode 100644 index 0000000000000..c99fe48932cd7 --- /dev/null +++ b/content/fa/docs/concepts/overview/working-with-objects/namespaces.md @@ -0,0 +1,166 @@ +--- +reviewers: +- xirehat +title: فضاهای نام +api_metadata: +- apiVersion: "v1" + kind: "Namespace" +content_type: concept +weight: 45 +--- + + + +در کوبرنتیز، _namespace_‌ها مکانیزمی برای جداسازی گروهی از منابع درون یک خوشه فراهم می‌کنند. +نام منابع باید در داخل یک فضای نام یکتا باشد، اما نیازی نیست در کل خوشه یکتا باشد. +محدوده‌بندی بر پایه فضای نام فقط برای اشیای دارای فضای نام کاربرد دارد +_(مانند Deploymentها، Serviceها و غیره)_ و برای اشیای سراسری خوشه +_(مانند StorageClass، Nodeها، PersistentVolumeها و ...)‌_ صدق نمی‌کند. + + + +## چه زمانی از چند فضای نام استفاده کنیم؟ + +فضای نام برای محیط‌هایی طراحی شده‌اند که کاربران زیادی در تیم‌ها یا پروژه‌های مختلف فعالیت دارند. +در خوشه‌هایی که تنها چند کاربر تا چند ده کاربر دارند، معمولاً نیازی به ایجاد فضای نام یا فکر کردن به آن‌ها ندارید. +زمانی از فضای نام استفاده کنید که به قابلیت‌هایی که فراهم می‌کنند نیاز دارید. + +فضای نام یک محدوده برای نام‌ها ایجاد می‌کنند. +نام منابع باید در داخل یک فضای نام یکتا باشد، اما نیازی نیست در تمام فضای نام یکتا باشد. +فضای نام را نمی‌توان درون هم تو در تو کرد و هر منبع کوبرنتیز تنها می‌تواند در یک فضای نام باشد. + +فضای نام راهی برای تقسیم منابع خوشه بین چند کاربر هستند +(از طریق [سهمیه منابع](/docs/concepts/policy/resource-quotas/)). + +برای جدا کردن منابعی که فقط کمی با هم تفاوت دارند—مثلاً نسخه‌های مختلف یک نرم‌افزار— +لازم نیست از فضای نام جداگانه استفاده کنید؛ در عوض از +{{< glossary_tooltip text="برچسب" term_id="label" >}}‌ برای متمایز کردن منابع در همان فضای نام استفاده کنید. + +{{< note >}} +برای یک خوشه تولیدی، توصیه می‌شود از فضای نام پیش‌فرض (`default`) استفاده نکنید. +در عوض، فضای نام جدید بسازید و از آن‌ها استفاده کنید. +{{< /note >}} + +## فضای نام‌های اولیه + +کوبرنتیز با چهار فضای نام اولیه آغاز به کار می‌کند: + +`default` +: کوبرنتیز این فضای نام را به‌صورت پیش‌فرض در اختیار می‌گذارد تا بتوانید بلافاصله از خوشه جدید خود استفاده کنید، بدون آن‌که ابتدا نیاز به ایجاد یک فضای نام داشته باشید. + +`kube-node-lease` +: این فضای نام شامل اشیای [Lease](/docs/concepts/architecture/leases/) مرتبط با هر نود است. +اجاره‌نامه‌های نود به kubelet اجازه می‌دهند [heartbeat](/docs/concepts/architecture/nodes/#node-heartbeats) ارسال کند +تا control plane بتواند خرابی نود را تشخیص دهد. + +`kube-public` +: این فضای نام توسط *تمامی* کلاینت‌ها (از جمله کلاینت‌های غیرمعتبرشده) قابل خواندن است. +این فضای نام عمدتاً برای استفاده داخلی خوشه رزرو شده، در صورتی که منابعی باید به‌صورت عمومی در کل خوشه قابل مشاهده و خواندن باشند. +جنبه عمومی بودن این فضای نام صرفاً یک قرارداد است، نه یک الزام. + +`kube-system` +: این فضای نام مخصوص اشیایی است که توسط سیستم کوبرنتیز ایجاد می‌شوند. + +## کار با فضاهای نام + +ایجاد و حذف فضاهای نام در +[مستندات راهنمای مدیریت برای فضاهای نام](/docs/tasks/administer-cluster/namespaces) توضیح داده شده است. + +{{< note >}} +از ایجاد فضاهای نام با پیشوند `kube-` خودداری کنید، +زیرا این پیشوند برای فضاهای نام سیستمی کوبرنتیز رزرو شده است. +{{< /note >}} + +### مشاهده فضاهای نام + +برای فهرست‌کردن فضاهای نام فعلی در یک خوشه می‌توانید از دستور زیر استفاده کنید: + +```shell +kubectl get namespace +``` +``` +NAME STATUS AGE +default Active 1d +kube-node-lease Active 1d +kube-public Active 1d +kube-system Active 1d +``` + + +### تنظیم فضای نام برای یک درخواست + +برای تنظیم فضای نام برای یک درخواست جاری، از فلگ `--namespace` استفاده کنید. + +برای مثال: + +```shell +kubectl run nginx --image=nginx --namespace= +kubectl get pods --namespace= +``` + +### تنظیم اولویت فضای نام + +شما می‌توانید فضای نام را برای تمام دستورات بعدی kubectl در آن زمینه به طور دائم ذخیره کنید. + +```shell +kubectl config set-context --current --namespace= +# Validate it +kubectl config view --minify | grep namespace: +``` + +## فضاهای نام و DNS + +هنگامی که یک [Service](/docs/concepts/services-networking/service/) ایجاد می‌کنید، +یک [ورودی DNS](/docs/concepts/services-networking/dns-pod-service/) متناظر با آن ساخته می‌شود. +این ورودی به شکل `..svc.cluster.local` است. +یعنی اگر یک کانتینر فقط از `` استفاده کند، به سرویسی که در فضای نام محلی قرار دارد ارجاع داده می‌شود. +این ویژگی زمانی مفید است که بخواهید از همان پیکربندی در چند فضای نام مانند توسعه (Development)، آزمایشی (Staging) و تولید (Production) استفاده کنید. +اگر بخواهید از یک فضای نام به فضای نام دیگر دسترسی داشته باشید، باید از نام دامنه کامل (FQDN) استفاده کنید. + +در نتیجه، تمام نام‌های فضای نام باید +[برچسب‌های معتبر RFC 1123 DNS](/docs/concepts/overview/working-with-objects/names/#dns-label-names) باشند. + +{{< warning >}} +اگر فضاهای نامی با همان نام [دامنه‌های سطح‌بالای عمومی (TLD)](https://data.iana.org/TLD/tlds-alpha-by-domain.txt) ایجاد شوند، +سرویس‌های درون این فضاهای نام می‌توانند نام‌های کوتاه DNS داشته باشند که با رکوردهای DNS عمومی تداخل پیدا می‌کنند. +اگر بار کاری (Workload) از هر فضای نامی یک جستجوی DNS بدون [نقطه پایانی](https://datatracker.ietf.org/doc/html/rfc1034#page-8) انجام دهد، +به آن سرویس‌ها ارجاع داده می‌شود و نسبت به DNS عمومی اولویت خواهد داشت. + +برای جلوگیری از این مسئله، دسترسی برای ایجاد فضاهای نام را به کاربران مورد اعتماد محدود کنید. +در صورت نیاز، می‌توانید کنترل‌های امنیتی شخص ثالث مانند +[Admission Webhookها](/docs/reference/access-authn-authz/extensible-admission-controllers/) +را پیکربندی کنید تا از ایجاد هر فضای نام با نام یکی از [TLDهای عمومی](https://data.iana.org/TLD/tlds-alpha-by-domain.txt) جلوگیری شود. +{{< /warning >}} + +## همه اشیاء در یک فضای نام قرار ندارند + +بیشتر منابع کوبرنتیز (مانند پادها، سرویس‌ها، کنترلرهای تکرار و غیره) در یک فضای نام قرار دارند. +اما خود منابع فضای نام، در فضای نام دیگری قرار ندارند. +همچنین منابع سطح پایین مانند +[nodes](/docs/concepts/architecture/nodes/) و +[persistentVolumes](/docs/concepts/storage/persistent-volumes/) +در هیچ فضای نامی قرار ندارند. + +برای مشاهده اینکه کدام منابع کوبرنتیز در یک فضای نام هستند و کدام نیستند: + +```shell +# In a namespace +kubectl api-resources --namespaced=true + +# Not in a namespace +kubectl api-resources --namespaced=false +``` + +## برچسب‌گذاری خودکار + +{{< feature-state for_k8s_version="1.22" state="stable" >}} + +سطح کنترل کوبرنتیز یک {{< glossary_tooltip text="برچسب" term_id="label" >}} تغییرناپذیر +با کلید `kubernetes.io/metadata.name` روی تمام فضاهای نام تنظیم می‌کند. +مقدار این برچسب، نام فضای نام است. + +## {{% heading "whatsnext" %}} + +* درباره [ایجاد یک فضای نام جدید](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace) بیشتر بیاموزید. +* درباره [حذف یک فضای نام](/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace) بیشتر مطالعه کنید. + diff --git a/content/fa/docs/concepts/overview/working-with-objects/object-management.md b/content/fa/docs/concepts/overview/working-with-objects/object-management.md new file mode 100644 index 0000000000000..747b37f5c7811 --- /dev/null +++ b/content/fa/docs/concepts/overview/working-with-objects/object-management.md @@ -0,0 +1,168 @@ +--- +title: مدیریت اشیاء کوبرنتیز +content_type: concept +weight: 20 +--- + + +ابزار خط فرمان `kubectl` از چندین روش مختلف برای ایجاد و مدیریت +{{< glossary_tooltip text="اشیاء" term_id="object" >}} کوبرنتیز پشتیبانی می‌کند. +این سند نمای کلی‌ای از این روش‌های مختلف ارائه می‌دهد. +برای جزئیات بیشتر درباره مدیریت اشیاء با استفاده از Kubectl، به [کتاب Kubectl](https://kubectl.docs.kubernetes.io) مراجعه کنید. + + + +## تکنیک‌های مدیریت + +{{< warning >}} +یک شیء در کوبرنتیز باید تنها با یک روش مدیریت شود. ترکیب چند روش برای یک شیء واحد می‌تواند منجر به رفتار نامشخص شود. +{{< /warning >}} + +| Management technique | Operates on |Recommended environment | Supported writers | Learning curve | +|----------------------------------|----------------------|------------------------|--------------------|----------------| +| Imperative commands | Live objects | Development projects | 1+ | Lowest | +| Imperative object configuration | Individual files | Production projects | 1 | Moderate | +| Declarative object configuration | Directories of files | Production projects | 1+ | Highest | + +## دستورات امری (Imperative) + +در روش استفاده از دستورات امری، کاربر به‌صورت مستقیم روی اشیای زنده در خوشه عمل می‌کند. +کاربر عملیات مورد نظر را به‌عنوان آرگومان یا فلگ به دستور `kubectl` ارائه می‌دهد. + +این روش برای شروع کار یا انجام یک وظیفه موقتی در خوشه توصیه می‌شود. +از آنجا که این تکنیک به‌طور مستقیم روی اشیای زنده عمل می‌کند، سابقه‌ای از پیکربندی‌های قبلی نگهداری نمی‌کند. + +### مثال‌ها + +اجرای یک نمونه از کانتینر nginx با ایجاد یک شیء Deployment: + +```sh +kubectl create deployment nginx --image nginx +``` + +### ملاحظات (مزایا و معایب) + +مزایا نسبت به پیکربندی شیء: + +- دستورات با یک کلمه عملیاتی ساده بیان می‌شوند. +- دستورات تنها با یک مرحله تغییرات را در خوشه اعمال می‌کنند. + +معایب نسبت به پیکربندی شیء: + +- دستورات با فرایندهای بررسی تغییرات یکپارچه نیستند. +- دستورات سابقه‌ای از تغییرات برای حسابرسی ارائه نمی‌دهند. +- دستورات هیچ منبعی از سوابق به‌جز وضعیت فعلی شیء فراهم نمی‌کنند. +- دستورات الگو (template)‌ای برای ایجاد اشیای جدید در اختیار نمی‌گذارند. + +## پیکربندی امری شیء + +در پیکربندی امری شیء، دستور `kubectl` نوع عملیات (مانند create، replace و غیره)، فلگ‌های اختیاری و حداقل یک نام فایل را مشخص می‌کند. +فایل مشخص‌شده باید شامل تعریف کامل شیء به فرمت YAML یا JSON باشد. + +برای اطلاعات بیشتر درباره تعریف اشیاء به [مرجع API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) مراجعه کنید. + +{{< warning >}} +دستور `replace` در روش امری، مشخصات موجود (spec) را با نمونه جدید جایگزین می‌کند +و هر تغییری که در فایل پیکربندی نیامده باشد از بین می‌برد. +این روش نباید برای انواع منابعی که مشخصات آن‌ها به‌صورت مستقل از فایل پیکربندی به‌روزرسانی می‌شود استفاده شود. +برای مثال، سرویس‌هایی از نوع `LoadBalancer` ممکن است فیلد `externalIPs` آن‌ها توسط خوشه +به‌صورت مستقل از فایل پیکربندی به‌روزرسانی شود. +{{< /warning >}} + +### مثال‌ها + +اشیاء تعریف شده در یک فایل پیکربندی را ایجاد کنید: + +```sh +kubectl create -f nginx.yaml +``` + +اشیاء تعریف شده در دو فایل پیکربندی را حذف کنید: + +```sh +kubectl delete -f nginx.yaml -f redis.yaml +``` + +اشیاء تعریف شده در یک فایل پیکربندی را با بازنویسی پیکربندی زنده به‌روزرسانی کنید: + +```sh +kubectl replace -f nginx.yaml +``` + +### ملاحظات (مزایا و معایب) + +مزایا نسبت به دستورات امری: + +- پیکربندی شیء را می‌توان در سیستم‌های کنترل نسخه مانند Git ذخیره کرد. +- پیکربندی شیء می‌تواند با فرایندهایی مانند بررسی تغییرات پیش از ارسال (push) و مسیرهای حسابرسی یکپارچه شود. +- پیکربندی شیء الگو (template)‌ای برای ایجاد اشیای جدید فراهم می‌کند. + +معایب نسبت به دستورات امری: + +- پیکربندی شیء نیازمند درک ابتدایی از ساختار (schema) شیء است. +- پیکربندی شیء نیاز به گام اضافی نوشتن فایل YAML دارد. + +مزایا نسبت به پیکربندی اعلانی شیء: + +- رفتار پیکربندی امری شیء ساده‌تر و قابل درک‌تر است. +- از نسخه 1.5 کوبرنتیز، پیکربندی امری شیء پایداری بیشتری داشته است. + +معایب نسبت به پیکربندی اعلانی شیء: + +- پیکربندی امری شیء بیشتر برای فایل‌ها مناسب است، نه دایرکتوری‌ها. +- به‌روزرسانی‌هایی که روی اشیای زنده اعمال می‌شوند، باید در فایل‌های پیکربندی نیز منعکس شوند؛ + در غیر این صورت، در جایگزینی بعدی از بین خواهند رفت. + +## پیکربندی اعلانی شیء + +در روش پیکربندی اعلانی شیء، کاربر روی فایل‌های پیکربندی اشیاء که به‌صورت محلی ذخیره شده‌اند کار می‌کند، +اما عملیات مورد نظر (ایجاد، به‌روزرسانی، حذف) را به‌طور مستقیم مشخص نمی‌کند. +دستور `kubectl` به‌صورت خودکار بر اساس هر شیء، عملیات ایجاد، به‌روزرسانی یا حذف را تشخیص می‌دهد. +این روش امکان کار با دایرکتوری‌ها را فراهم می‌کند، جایی که ممکن است عملیات مختلفی روی اشیاء مختلف نیاز باشد. + +{{< note >}} +پیکربندی اعلانی شیء تغییراتی را که توسط نویسندگان دیگر ایجاد شده‌اند حفظ می‌کند، +حتی اگر این تغییرات به فایل پیکربندی بازگردانده نشده باشند. +این کار با استفاده از عملیات API به نام `patch` ممکن می‌شود +که فقط تفاوت‌های مشاهده‌شده را می‌نویسد، به‌جای آنکه کل پیکربندی شیء را با `replace` جایگزین کند. +{{< /note >}} + +### مثال‌ها + +تمام فایل‌های پیکربندی شیء در دایرکتوری `configs` را پردازش کرده و اشیای زنده را ایجاد یا patch کنید. +می‌توانید ابتدا با استفاده از `diff` تغییراتی که قرار است اعمال شوند را مشاهده کرده و سپس اجرا کنید: + +```sh +kubectl diff -f configs/ +kubectl apply -f configs/ +``` + +پردازش بازگشتی پوشه‌ها: + +```sh +kubectl diff -R -f configs/ +kubectl apply -R -f configs/ +``` + +### ملاحظات (مزایا و معایب) + +مزایا نسبت به پیکربندی امری شیء: + +- تغییراتی که مستقیماً روی اشیای زنده اعمال می‌شوند حفظ می‌گردند، حتی اگر این تغییرات به فایل‌های پیکربندی بازگردانده نشوند. +- پیکربندی اعلانی شیء پشتیبانی بهتری برای کار با دایرکتوری‌ها دارد و به‌طور خودکار نوع عملیات (ایجاد، patch، حذف) را برای هر شیء تشخیص می‌دهد. + +معایب نسبت به پیکربندی امری شیء: + +- پیکربندی اعلانی شیء در شرایطی که نتیجه‌ها غیرمنتظره باشند، دشوارتر برای اشکال‌زدایی و درک است. +- به‌روزرسانی‌های جزئی با استفاده از diff، عملیات merge و patch پیچیده‌تری ایجاد می‌کنند. + +## {{% heading "whatsnext" %}} + +- [مدیریت اشیای کوبرنتیز با استفاده از دستورات امری](/docs/tasks/manage-kubernetes-objects/imperative-command/) +- [مدیریت امری اشیای کوبرنتیز با استفاده از فایل‌های پیکربندی](/docs/tasks/manage-kubernetes-objects/imperative-config/) +- [مدیریت اعلانی اشیای کوبرنتیز با استفاده از فایل‌های پیکربندی](/docs/tasks/manage-kubernetes-objects/declarative-config/) +- [مدیریت اعلانی اشیای کوبرنتیز با استفاده از Kustomize](/docs/tasks/manage-kubernetes-objects/kustomization/) +- [مرجع دستورات Kubectl](/docs/reference/generated/kubectl/kubectl-commands/) +- [کتاب Kubectl](https://kubectl.docs.kubernetes.io) +- [مرجع API کوبرنتیز](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) + diff --git a/content/fa/docs/concepts/overview/working-with-objects/owners-dependents.md b/content/fa/docs/concepts/overview/working-with-objects/owners-dependents.md new file mode 100644 index 0000000000000..e0336c522eb16 --- /dev/null +++ b/content/fa/docs/concepts/overview/working-with-objects/owners-dependents.md @@ -0,0 +1,84 @@ +--- +title: مالکان و تحت تکفل +content_type: concept +weight: 90 +--- + + + +در کوبرنتیز، برخی از {{< glossary_tooltip text="اشیاء" term_id="object" >}} +*مالک* اشیای دیگر هستند. +برای مثال، یک {{}} +مالک مجموعه‌ای از پادها است. اشیایی که دارای مالک هستند، *وابسته* به آن مالک محسوب می‌شوند. + +مالکیت با مکانیزم [برچسب‌ها و انتخابگرها](/docs/concepts/overview/working-with-objects/labels/) که برخی منابع نیز از آن استفاده می‌کنند تفاوت دارد. +برای مثال، یک Service که اشیای `EndpointSlice` ایجاد می‌کند، +از {{}} استفاده می‌کند تا control plane بتواند مشخص کند +کدام اشیای `EndpointSlice` برای آن Service استفاده می‌شوند. +علاوه بر برچسب‌ها، هر `EndpointSlice` که به نمایندگی از یک Service مدیریت می‌شود، دارای مرجع مالک است. +مراجع مالک به بخش‌های مختلف کوبرنتیز کمک می‌کنند تا با اشیایی که کنترلشان را بر عهده ندارند تداخلی نداشته باشند. + +## مراجع مالک در مشخصات شیء + +اشیای وابسته دارای فیلدی به نام `metadata.ownerReferences` هستند +که به شیء مالک آن‌ها ارجاع می‌دهد. +یک مرجع مالک معتبر شامل نام شیء و یک {{}} +در همان {{}} +با شیء وابسته است. +کوبرنتیز مقدار این فیلد را به‌صورت خودکار تنظیم می‌کند +برای اشیایی که وابسته به منابعی مانند ReplicaSet، DaemonSet، Deployment، Job، CronJob و ReplicationController هستند. +همچنین می‌توانید این روابط را به‌صورت دستی با تغییر مقدار این فیلد پیکربندی کنید، +اما معمولاً نیازی به این کار نیست و می‌توان اجازه داد کوبرنتیز به‌صورت خودکار این روابط را مدیریت کند. + +اشیای وابسته همچنین دارای فیلدی به نام `ownerReferences.blockOwnerDeletion` هستند +که یک مقدار بولی می‌پذیرد و کنترل می‌کند آیا وابسته خاصی می‌تواند +از حذف شدن شیء مالک توسط مکانیزم garbage collection جلوگیری کند یا نه. +کوبرنتیز این فیلد را به‌طور خودکار روی مقدار `true` قرار می‌دهد اگر +یک {{}} +(مثلاً کنترلر Deployment) مقدار فیلد `metadata.ownerReferences` را تنظیم کند. +شما همچنین می‌توانید مقدار فیلد `blockOwnerDeletion` را به‌صورت دستی تنظیم کنید +تا مشخص کنید کدام وابسته‌ها از حذف مالک جلوگیری کنند. + +یک کنترل‌کننده پذیرش (admission controller) در کوبرنتیز، دسترسی کاربران برای تغییر این فیلد در منابع وابسته را کنترل می‌کند، +بر اساس مجوز حذف شیء مالک. +این کنترل باعث می‌شود کاربران غیرمجاز نتوانند حذف شیء مالک را به تأخیر بیندازند. + +{{< note >}} +ارجاع به مالک در فضای نام متفاوت (cross-namespace owner references) به‌صورت طراحی‌شده مجاز نیستند. +وابسته‌های دارای فضای نام می‌توانند مالک‌های خوشه‌ای (cluster-scoped) یا دارای فضای نام را مشخص کنند. +یک مالک دارای فضای نام **باید** در همان فضای نام با شیء وابسته وجود داشته باشد. +در غیر این صورت، مرجع مالک بی‌اعتبار تلقی می‌شود و شیء وابسته در صورت غیبت تمام مالک‌ها، حذف خواهد شد. + +وابسته‌هایی که در سطح خوشه هستند، تنها می‌توانند به مالک‌هایی در سطح خوشه ارجاع دهند. +از نسخه 1.20 به بعد، اگر یک وابسته خوشه‌ای، نوعی با فضای نام را به‌عنوان مالک مشخص کند، +این مرجع مالک غیرقابل حل در نظر گرفته می‌شود و آن شیء قابل جمع‌آوری توسط garbage collector نخواهد بود. + +در نسخه 1.20 و بالاتر، اگر garbage collector یک `ownerReference` نامعتبر از نوع cross-namespace شناسایی کند، +یا وابسته خوشه‌ای باشد که مرجع مالک آن به نوعی namespaced اشاره دارد، +یک Event هشدار با دلیل `OwnerRefInvalidNamespace` و شیء نامعتبر به‌عنوان `involvedObject` ثبت می‌شود. +می‌توانید برای بررسی چنین Eventهایی این دستور را اجرا کنید: +`kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace` +{{< /note >}} + +## مالکیت و پایان‌دهنده‌ها (Finalizers) + +وقتی به کوبرنتیز دستور می‌دهید که یک منبع (Resource) را حذف کند، سرور API به کنترل‌کننده مدیریت‌کننده اجازه می‌دهد +تا هرگونه [قانون پایان‌دهنده (finalizer)](/docs/concepts/overview/working-with-objects/finalizers/) برای آن منبع را پردازش کند. +{{}} از حذف تصادفی منابعی که خوشه ممکن است هنوز به آن‌ها نیاز داشته باشد جلوگیری می‌کنند. +برای مثال، اگر بخواهید یک [PersistentVolume](/docs/concepts/storage/persistent-volumes/) را حذف کنید که هنوز توسط یک Pod در حال استفاده است، +حذف فوراً انجام نمی‌شود، زیرا آن `PersistentVolume` دارای پایان‌دهنده `kubernetes.io/pv-protection` است. +در عوض، [حجم](/docs/concepts/storage/volumes/) در وضعیت `Terminating` باقی می‌ماند تا زمانی که کوبرنتیز پایان‌دهنده را حذف کند، +که تنها پس از آن اتفاق می‌افتد که `PersistentVolume` دیگر به هیچ Pod متصل نباشد. + +کوبرنتیز همچنین هنگام استفاده از [حذف آبشاری foreground یا orphan](/docs/concepts/architecture/garbage-collection/#cascading-deletion)، +به منبع مالک پایان‌دهنده‌هایی اضافه می‌کند. +در حذف foreground، پایان‌دهنده `foreground` افزوده می‌شود تا کنترل‌کننده ملزم شود +منابع وابسته‌ای که `ownerReferences.blockOwnerDeletion=true` دارند را قبل از حذف منبع مالک، حذف کند. +اگر سیاست حذف orphan را مشخص کنید، کوبرنتیز پایان‌دهنده `orphan` را اضافه می‌کند +تا کنترل‌کننده پس از حذف شیء مالک، منابع وابسته را نادیده بگیرد. + +## {{% heading "whatsnext" %}} + +* اطلاعات بیشتری درباره [پایان‌دهنده‌های کوبرنتیز](/docs/concepts/overview/working-with-objects/finalizers/) کسب کنید. +* درباره [جمع‌آوری زباله (Garbage Collection)](/docs/concepts/architecture/garbage-collection) بیاموزید. +* مرجع API مربوط به [metadata اشیاء](/docs/reference/kubernetes-api/common-definitions/object-meta/#System) را مطالعه کنید. diff --git a/content/fa/docs/concepts/services-networking/dual-stack.md b/content/fa/docs/concepts/services-networking/dual-stack.md new file mode 100644 index 0000000000000..abff740480a47 --- /dev/null +++ b/content/fa/docs/concepts/services-networking/dual-stack.md @@ -0,0 +1,311 @@ +--- +title: دو پشته IPv4/IPv6 +description: >- + کوبرنتیز به شما امکان می‌دهد شبکه IPv4 تک پشته‌ای، شبکه IPv6 تک پشته‌ای یا شبکه دو پشته‌ای را با هر دو خانواده شبکه فعال پیکربندی کنید. این صفحه نحوه‌ی پیکربندی را توضیح می‌دهد.. +feature: + title: دو پشته IPv4/IPv6 + description: > + تخصیص آدرس‌های IPv4 و IPv6 به پادها و سرویس‌ها +content_type: concept +reviewers: + - xirehat +weight: 90 +--- + + + +{{< feature-state for_k8s_version="v1.23" state="stable" >}} + +IPv4/IPv6 dual-stack networking enables the allocation of both IPv4 and IPv6 addresses to +{{< glossary_tooltip text="Pods" term_id="pod" >}} and {{< glossary_tooltip text="Services" term_id="service" >}}. + +IPv4/IPv6 dual-stack networking is enabled by default for your Kubernetes cluster starting in +1.21, allowing the simultaneous assignment of both IPv4 and IPv6 addresses. + + + +## Supported Features + +IPv4/IPv6 dual-stack on your Kubernetes cluster provides the following features: + +* Dual-stack Pod networking (a single IPv4 and IPv6 address assignment per Pod) +* IPv4 and IPv6 enabled Services +* Pod off-cluster egress routing (eg. the Internet) via both IPv4 and IPv6 interfaces + +## Prerequisites + +The following prerequisites are needed in order to utilize IPv4/IPv6 dual-stack Kubernetes clusters: + +* Kubernetes 1.20 or later + + For information about using dual-stack services with earlier + Kubernetes versions, refer to the documentation for that version + of Kubernetes. + +* Provider support for dual-stack networking (Cloud provider or otherwise must be able to provide + Kubernetes nodes with routable IPv4/IPv6 network interfaces) +* A [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) that + supports dual-stack networking. + +## Configure IPv4/IPv6 dual-stack + +To configure IPv4/IPv6 dual-stack, set dual-stack cluster network assignments: + +* kube-apiserver: + * `--service-cluster-ip-range=,` +* kube-controller-manager: + * `--cluster-cidr=,` + * `--service-cluster-ip-range=,` + * `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` defaults to /24 for IPv4 and /64 for IPv6 +* kube-proxy: + * `--cluster-cidr=,` +* kubelet: + * `--node-ip=,` + * This option is required for bare metal dual-stack nodes (nodes that do not define a + cloud provider with the `--cloud-provider` flag). If you are using a cloud provider + and choose to override the node IPs chosen by the cloud provider, set the + `--node-ip` option. + * (The legacy built-in cloud providers do not support dual-stack `--node-ip`.) + +{{< note >}} +An example of an IPv4 CIDR: `10.244.0.0/16` (though you would supply your own address range) + +An example of an IPv6 CIDR: `fdXY:IJKL:MNOP:15::/64` (this shows the format but is not a valid +address - see [RFC 4193](https://tools.ietf.org/html/rfc4193)) +{{< /note >}} + +## Services + +You can create {{< glossary_tooltip text="Services" term_id="service" >}} which can use IPv4, IPv6, or both. + +The address family of a Service defaults to the address family of the first service cluster IP +range (configured via the `--service-cluster-ip-range` flag to the kube-apiserver). + +When you define a Service you can optionally configure it as dual stack. To specify the behavior you want, you +set the `.spec.ipFamilyPolicy` field to one of the following values: + +* `SingleStack`: Single-stack service. The control plane allocates a cluster IP for the Service, + using the first configured service cluster IP range. +* `PreferDualStack`: Allocates both IPv4 and IPv6 cluster IPs for the Service when dual-stack is enabled. If dual-stack is not enabled or supported, it falls back to single-stack behavior. +* `RequireDualStack`: Allocates Service `.spec.clusterIPs` from both IPv4 and IPv6 address ranges when dual-stack is enabled. If dual-stack is not enabled or supported, the Service API object creation fails. + * Selects the `.spec.clusterIP` from the list of `.spec.clusterIPs` based on the address family + of the first element in the `.spec.ipFamilies` array. + +If you would like to define which IP family to use for single stack or define the order of IP +families for dual-stack, you can choose the address families by setting an optional field, +`.spec.ipFamilies`, on the Service. + +{{< note >}} +The `.spec.ipFamilies` field is conditionally mutable: you can add or remove a secondary +IP address family, but you cannot change the primary IP address family of an existing Service. +{{< /note >}} + +You can set `.spec.ipFamilies` to any of the following array values: + +- `["IPv4"]` +- `["IPv6"]` +- `["IPv4","IPv6"]` (dual stack) +- `["IPv6","IPv4"]` (dual stack) + +The first family you list is used for the legacy `.spec.clusterIP` field. + +### Dual-stack Service configuration scenarios + +These examples demonstrate the behavior of various dual-stack Service configuration scenarios. + +#### Dual-stack options on new Services + +1. This Service specification does not explicitly define `.spec.ipFamilyPolicy`. When you create + this Service, Kubernetes assigns a cluster IP for the Service from the first configured + `service-cluster-ip-range` and sets the `.spec.ipFamilyPolicy` to `SingleStack`. ([Services + without selectors](/docs/concepts/services-networking/service/#services-without-selectors) and + [headless Services](/docs/concepts/services-networking/service/#headless-services) with selectors + will behave in this same way.) + + {{% code_sample file="service/networking/dual-stack-default-svc.yaml" %}} + +1. This Service specification explicitly defines `PreferDualStack` in `.spec.ipFamilyPolicy`. When + you create this Service on a dual-stack cluster, Kubernetes assigns both IPv4 and IPv6 + addresses for the service. The control plane updates the `.spec` for the Service to record the IP + address assignments. The field `.spec.clusterIPs` is the primary field, and contains both assigned + IP addresses; `.spec.clusterIP` is a secondary field with its value calculated from + `.spec.clusterIPs`. + + * For the `.spec.clusterIP` field, the control plane records the IP address that is from the + same address family as the first service cluster IP range. + * On a single-stack cluster, the `.spec.clusterIPs` and `.spec.clusterIP` fields both only list + one address. + * On a cluster with dual-stack enabled, specifying `RequireDualStack` in `.spec.ipFamilyPolicy` + behaves the same as `PreferDualStack`. + + {{% code_sample file="service/networking/dual-stack-preferred-svc.yaml" %}} + +1. This Service specification explicitly defines `IPv6` and `IPv4` in `.spec.ipFamilies` as well + as defining `PreferDualStack` in `.spec.ipFamilyPolicy`. When Kubernetes assigns an IPv6 and + IPv4 address in `.spec.clusterIPs`, `.spec.clusterIP` is set to the IPv6 address because that is + the first element in the `.spec.clusterIPs` array, overriding the default. + + {{% code_sample file="service/networking/dual-stack-preferred-ipfamilies-svc.yaml" %}} + +#### Dual-stack defaults on existing Services + +These examples demonstrate the default behavior when dual-stack is newly enabled on a cluster +where Services already exist. (Upgrading an existing cluster to 1.21 or beyond will enable +dual-stack.) + +1. When dual-stack is enabled on a cluster, existing Services (whether `IPv4` or `IPv6`) are + configured by the control plane to set `.spec.ipFamilyPolicy` to `SingleStack` and set + `.spec.ipFamilies` to the address family of the existing Service. The existing Service cluster IP + will be stored in `.spec.clusterIPs`. + + {{% code_sample file="service/networking/dual-stack-default-svc.yaml" %}} + + You can validate this behavior by using kubectl to inspect an existing service. + + ```shell + kubectl get svc my-service -o yaml + ``` + + ```yaml + apiVersion: v1 + kind: Service + metadata: + labels: + app.kubernetes.io/name: MyApp + name: my-service + spec: + clusterIP: 10.0.197.123 + clusterIPs: + - 10.0.197.123 + ipFamilies: + - IPv4 + ipFamilyPolicy: SingleStack + ports: + - port: 80 + protocol: TCP + targetPort: 80 + selector: + app.kubernetes.io/name: MyApp + type: ClusterIP + status: + loadBalancer: {} + ``` + +1. When dual-stack is enabled on a cluster, existing + [headless Services](/docs/concepts/services-networking/service/#headless-services) with selectors are + configured by the control plane to set `.spec.ipFamilyPolicy` to `SingleStack` and set + `.spec.ipFamilies` to the address family of the first service cluster IP range (configured via the + `--service-cluster-ip-range` flag to the kube-apiserver) even though `.spec.clusterIP` is set to + `None`. + + {{% code_sample file="service/networking/dual-stack-default-svc.yaml" %}} + + You can validate this behavior by using kubectl to inspect an existing headless service with selectors. + + ```shell + kubectl get svc my-service -o yaml + ``` + + ```yaml + apiVersion: v1 + kind: Service + metadata: + labels: + app.kubernetes.io/name: MyApp + name: my-service + spec: + clusterIP: None + clusterIPs: + - None + ipFamilies: + - IPv4 + ipFamilyPolicy: SingleStack + ports: + - port: 80 + protocol: TCP + targetPort: 80 + selector: + app.kubernetes.io/name: MyApp + ``` + +#### Switching Services between single-stack and dual-stack + +Services can be changed from single-stack to dual-stack and from dual-stack to single-stack. + +1. To change a Service from single-stack to dual-stack, change `.spec.ipFamilyPolicy` from + `SingleStack` to `PreferDualStack` or `RequireDualStack` as desired. When you change this + Service from single-stack to dual-stack, Kubernetes assigns the missing address family so that the + Service now has IPv4 and IPv6 addresses. + + Edit the Service specification updating the `.spec.ipFamilyPolicy` from `SingleStack` to `PreferDualStack`. + + Before: + + ```yaml + spec: + ipFamilyPolicy: SingleStack + ``` + + After: + + ```yaml + spec: + ipFamilyPolicy: PreferDualStack + ``` + +1. To change a Service from dual-stack to single-stack, change `.spec.ipFamilyPolicy` from + `PreferDualStack` or `RequireDualStack` to `SingleStack`. When you change this Service from + dual-stack to single-stack, Kubernetes retains only the first element in the `.spec.clusterIPs` + array, and sets `.spec.clusterIP` to that IP address and sets `.spec.ipFamilies` to the address + family of `.spec.clusterIPs`. + +### Headless Services without selector + +For [Headless Services without selectors](/docs/concepts/services-networking/service/#without-selectors) +and without `.spec.ipFamilyPolicy` explicitly set, the `.spec.ipFamilyPolicy` field defaults to +`RequireDualStack`. + +### Service type LoadBalancer + +To provision a dual-stack load balancer for your Service: + +* Set the `.spec.type` field to `LoadBalancer` +* Set `.spec.ipFamilyPolicy` field to `PreferDualStack` or `RequireDualStack` + +{{< note >}} +To use a dual-stack `LoadBalancer` type Service, your cloud provider must support IPv4 and IPv6 +load balancers. +{{< /note >}} + +## Egress traffic + +If you want to enable egress traffic in order to reach off-cluster destinations (eg. the public +Internet) from a Pod that uses non-publicly routable IPv6 addresses, you need to enable the Pod to +use a publicly routed IPv6 address via a mechanism such as transparent proxying or IP +masquerading. The [ip-masq-agent](https://github.com/kubernetes-sigs/ip-masq-agent) project +supports IP masquerading on dual-stack clusters. + +{{< note >}} +Ensure your {{< glossary_tooltip text="CNI" term_id="cni" >}} provider supports IPv6. +{{< /note >}} + +## Windows support + +Kubernetes on Windows does not support single-stack "IPv6-only" networking. However, +dual-stack IPv4/IPv6 networking for pods and nodes with single-family services +is supported. + +You can use IPv4/IPv6 dual-stack networking with `l2bridge` networks. + +{{< note >}} +Overlay (VXLAN) networks on Windows **do not** support dual-stack networking. +{{< /note >}} + +You can read more about the different network modes for Windows within the +[Networking on Windows](/docs/concepts/services-networking/windows-networking#network-modes) topic. + +## {{% heading "whatsnext" %}} + +* [Validate IPv4/IPv6 dual-stack](/docs/tasks/network/validate-dual-stack) networking +* [Enable dual-stack networking using kubeadm](/docs/setup/production-environment/tools/kubeadm/dual-stack-support/) + diff --git a/content/fa/docs/concepts/services-networking/service.md b/content/fa/docs/concepts/services-networking/service.md new file mode 100644 index 0000000000000..9925cca8eb70e --- /dev/null +++ b/content/fa/docs/concepts/services-networking/service.md @@ -0,0 +1,1084 @@ +--- +reviewers: +- xirehat +title: Service +api_metadata: +- apiVersion: "v1" + kind: "Service" +feature: + title: کشف سرویس و تعادل بار + description: > + نیازی نیست برنامه خود را برای استفاده از یک سازوکار کشف سرویس ناآشنا تغییر دهید. کوبرنتیز به Podها نشانی IP مخصوص به خودشان و یک نام DNS واحد برای مجموعه‌ای از Podها می‌دهد و می‌تواند بین آنها تعادل بار ایجاد کند. +description: >- + یک برنامه‌ی در حال اجرا در خوشه شما را پشت یک نقطه‌ی پایانی رو به بیرون قرار می‌دهد، حتی زمانی که حجم کار بین چندین backend تقسیم شده باشد. +content_type: concept +weight: 10 +--- + + + + +{{< glossary_definition term_id="service" length="short" prepend="In Kubernetes, a Service is" >}} + +A key aim of Services in Kubernetes is that you don't need to modify your existing +application to use an unfamiliar service discovery mechanism. +You can run code in Pods, whether this is a code designed for a cloud-native world, or +an older app you've containerized. You use a Service to make that set of Pods available +on the network so that clients can interact with it. + +If you use a {{< glossary_tooltip term_id="deployment" >}} to run your app, +that Deployment can create and destroy Pods dynamically. From one moment to the next, +you don't know how many of those Pods are working and healthy; you might not even know +what those healthy Pods are named. +Kubernetes {{< glossary_tooltip term_id="pod" text="Pods" >}} are created and destroyed +to match the desired state of your cluster. Pods are ephemeral resources (you should not +expect that an individual Pod is reliable and durable). + +Each Pod gets its own IP address (Kubernetes expects network plugins to ensure this). +For a given Deployment in your cluster, the set of Pods running in one moment in +time could be different from the set of Pods running that application a moment later. + +This leads to a problem: if some set of Pods (call them "backends") provides +functionality to other Pods (call them "frontends") inside your cluster, +how do the frontends find out and keep track of which IP address to connect +to, so that the frontend can use the backend part of the workload? + +Enter _Services_. + + + +## Services in Kubernetes + +The Service API, part of Kubernetes, is an abstraction to help you expose groups of +Pods over a network. Each Service object defines a logical set of endpoints (usually +these endpoints are Pods) along with a policy about how to make those pods accessible. + +For example, consider a stateless image-processing backend which is running with +3 replicas. Those replicas are fungible—frontends do not care which backend +they use. While the actual Pods that compose the backend set may change, the +frontend clients should not need to be aware of that, nor should they need to keep +track of the set of backends themselves. + +The Service abstraction enables this decoupling. + +The set of Pods targeted by a Service is usually determined +by a {{< glossary_tooltip text="selector" term_id="selector" >}} that you +define. +To learn about other ways to define Service endpoints, +see [Services _without_ selectors](#services-without-selectors). + +If your workload speaks HTTP, you might choose to use an +[Ingress](/docs/concepts/services-networking/ingress/) to control how web traffic +reaches that workload. +Ingress is not a Service type, but it acts as the entry point for your +cluster. An Ingress lets you consolidate your routing rules into a single resource, so +that you can expose multiple components of your workload, running separately in your +cluster, behind a single listener. + +The [Gateway](https://gateway-api.sigs.k8s.io/#what-is-the-gateway-api) API for Kubernetes +provides extra capabilities beyond Ingress and Service. You can add Gateway to your cluster - +it is a family of extension APIs, implemented using +{{< glossary_tooltip term_id="CustomResourceDefinition" text="CustomResourceDefinitions" >}} - +and then use these to configure access to network services that are running in your cluster. + +### Cloud-native service discovery + +If you're able to use Kubernetes APIs for service discovery in your application, +you can query the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} +for matching EndpointSlices. Kubernetes updates the EndpointSlices for a Service +whenever the set of Pods in a Service changes. + +For non-native applications, Kubernetes offers ways to place a network port or load +balancer in between your application and the backend Pods. + +Either way, your workload can use these [service discovery](#discovering-services) +mechanisms to find the target it wants to connect to. + +## Defining a Service + +A Service is an {{< glossary_tooltip text="object" term_id="object" >}} +(the same way that a Pod or a ConfigMap is an object). You can create, +view or modify Service definitions using the Kubernetes API. Usually +you use a tool such as `kubectl` to make those API calls for you. + +For example, suppose you have a set of Pods that each listen on TCP port 9376 +and are labelled as `app.kubernetes.io/name=MyApp`. You can define a Service to +publish that TCP listener: + +{{% code_sample file="service/simple-service.yaml" %}} + +Applying this manifest creates a new Service named "my-service" with the default +ClusterIP [service type](#publishing-services-service-types). The Service +targets TCP port 9376 on any Pod with the `app.kubernetes.io/name: MyApp` label. + +Kubernetes assigns this Service an IP address (the _cluster IP_), +that is used by the virtual IP address mechanism. For more details on that mechanism, +read [Virtual IPs and Service Proxies](/docs/reference/networking/virtual-ips/). + +The controller for that Service continuously scans for Pods that +match its selector, and then makes any necessary updates to the set of +EndpointSlices for the Service. + +The name of a Service object must be a valid +[RFC 1035 label name](/docs/concepts/overview/working-with-objects/names#rfc-1035-label-names). + + +{{< note >}} +A Service can map _any_ incoming `port` to a `targetPort`. By default and +for convenience, the `targetPort` is set to the same value as the `port` +field. +{{< /note >}} + +### Port definitions {#field-spec-ports} + +Port definitions in Pods have names, and you can reference these names in the +`targetPort` attribute of a Service. For example, we can bind the `targetPort` +of the Service to the Pod port in the following way: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: nginx + labels: + app.kubernetes.io/name: proxy +spec: + containers: + - name: nginx + image: nginx:stable + ports: + - containerPort: 80 + name: http-web-svc + +--- +apiVersion: v1 +kind: Service +metadata: + name: nginx-service +spec: + selector: + app.kubernetes.io/name: proxy + ports: + - name: name-of-service-port + protocol: TCP + port: 80 + targetPort: http-web-svc +``` + +This works even if there is a mixture of Pods in the Service using a single +configured name, with the same network protocol available via different +port numbers. This offers a lot of flexibility for deploying and evolving +your Services. For example, you can change the port numbers that Pods expose +in the next version of your backend software, without breaking clients. + +The default protocol for Services is +[TCP](/docs/reference/networking/service-protocols/#protocol-tcp); you can also +use any other [supported protocol](/docs/reference/networking/service-protocols/). + +Because many Services need to expose more than one port, Kubernetes supports +[multiple port definitions](#multi-port-services) for a single Service. +Each port definition can have the same `protocol`, or a different one. + +### Services without selectors + +Services most commonly abstract access to Kubernetes Pods thanks to the selector, +but when used with a corresponding set of +{{}} +objects and without a selector, the Service can abstract other kinds of backends, +including ones that run outside the cluster. + +For example: + +* You want to have an external database cluster in production, but in your + test environment you use your own databases. +* You want to point your Service to a Service in a different + {{< glossary_tooltip term_id="namespace" >}} or on another cluster. +* You are migrating a workload to Kubernetes. While evaluating the approach, + you run only a portion of your backends in Kubernetes. + +In any of these scenarios you can define a Service _without_ specifying a +selector to match Pods. For example: + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + ports: + - name: http + protocol: TCP + port: 80 + targetPort: 9376 +``` + +Because this Service has no selector, the corresponding EndpointSlice +objects are not created automatically. You can map the Service +to the network address and port where it's running, by adding an EndpointSlice +object manually. For example: + +```yaml +apiVersion: discovery.k8s.io/v1 +kind: EndpointSlice +metadata: + name: my-service-1 # by convention, use the name of the Service + # as a prefix for the name of the EndpointSlice + labels: + # You should set the "kubernetes.io/service-name" label. + # Set its value to match the name of the Service + kubernetes.io/service-name: my-service +addressType: IPv4 +ports: + - name: http # should match with the name of the service port defined above + appProtocol: http + protocol: TCP + port: 9376 +endpoints: + - addresses: + - "10.4.5.6" + - addresses: + - "10.1.2.3" +``` + +#### Custom EndpointSlices + +When you create an [EndpointSlice](#endpointslices) object for a Service, you can +use any name for the EndpointSlice. Each EndpointSlice in a namespace must have a +unique name. You link an EndpointSlice to a Service by setting the +`kubernetes.io/service-name` {{< glossary_tooltip text="label" term_id="label" >}} +on that EndpointSlice. + +{{< note >}} +The endpoint IPs _must not_ be: loopback (127.0.0.0/8 for IPv4, ::1/128 for IPv6), or +link-local (169.254.0.0/16 and 224.0.0.0/24 for IPv4, fe80::/64 for IPv6). + +The endpoint IP addresses cannot be the cluster IPs of other Kubernetes Services, +because {{< glossary_tooltip term_id="kube-proxy" >}} doesn't support virtual IPs +as a destination. +{{< /note >}} + +For an EndpointSlice that you create yourself, or in your own code, +you should also pick a value to use for the label +[`endpointslice.kubernetes.io/managed-by`](/docs/reference/labels-annotations-taints/#endpointslicekubernetesiomanaged-by). +If you create your own controller code to manage EndpointSlices, consider using a +value similar to `"my-domain.example/name-of-controller"`. If you are using a third +party tool, use the name of the tool in all-lowercase and change spaces and other +punctuation to dashes (`-`). +If people are directly using a tool such as `kubectl` to manage EndpointSlices, +use a name that describes this manual management, such as `"staff"` or +`"cluster-admins"`. You should +avoid using the reserved value `"controller"`, which identifies EndpointSlices +managed by Kubernetes' own control plane. + +#### Accessing a Service without a selector {#service-no-selector-access} + +Accessing a Service without a selector works the same as if it had a selector. +In the [example](#services-without-selectors) for a Service without a selector, +traffic is routed to one of the two endpoints defined in +the EndpointSlice manifest: a TCP connection to 10.1.2.3 or 10.4.5.6, on port 9376. + +{{< note >}} +The Kubernetes API server does not allow proxying to endpoints that are not mapped to +pods. Actions such as `kubectl port-forward service/ forwardedPort:servicePort` where the service has no +selector will fail due to this constraint. This prevents the Kubernetes API server +from being used as a proxy to endpoints the caller may not be authorized to access. +{{< /note >}} + +An `ExternalName` Service is a special case of Service that does not have +selectors and uses DNS names instead. For more information, see the +[ExternalName](#externalname) section. + +### EndpointSlices + +{{< feature-state for_k8s_version="v1.21" state="stable" >}} + +[EndpointSlices](/docs/concepts/services-networking/endpoint-slices/) are objects that +represent a subset (a _slice_) of the backing network endpoints for a Service. + +Your Kubernetes cluster tracks how many endpoints each EndpointSlice represents. +If there are so many endpoints for a Service that a threshold is reached, then +Kubernetes adds another empty EndpointSlice and stores new endpoint information +there. +By default, Kubernetes makes a new EndpointSlice once the existing EndpointSlices +all contain at least 100 endpoints. Kubernetes does not make the new EndpointSlice +until an extra endpoint needs to be added. + +See [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/) for more +information about this API. + +### Endpoints (deprecated) {#endpoints} + +{{< feature-state for_k8s_version="v1.33" state="deprecated" >}} + +The EndpointSlice API is the evolution of the older +[Endpoints](/docs/reference/kubernetes-api/service-resources/endpoints-v1/) +API. The deprecated Endpoints API has several problems relative to +EndpointSlice: + + - It does not support dual-stack clusters. + - It does not contain information needed to support newer features, such as + [trafficDistribution](/docs/concepts/services-networking/service/#traffic-distribution). + - It will truncate the list of endpoints if it is too long to fit in a single object. + +Because of this, it is recommended that all clients use the +EndpointSlice API rather than Endpoints. + +#### Over-capacity endpoints + +Kubernetes limits the number of endpoints that can fit in a single Endpoints +object. When there are over 1000 backing endpoints for a Service, Kubernetes +truncates the data in the Endpoints object. Because a Service can be linked +with more than one EndpointSlice, the 1000 backing endpoint limit only +affects the legacy Endpoints API. + +In that case, Kubernetes selects at most 1000 possible backend endpoints to store +into the Endpoints object, and sets an +{{< glossary_tooltip text="annotation" term_id="annotation" >}} on the Endpoints: +[`endpoints.kubernetes.io/over-capacity: truncated`](/docs/reference/labels-annotations-taints/#endpoints-kubernetes-io-over-capacity). +The control plane also removes that annotation if the number of backend Pods drops below 1000. + +Traffic is still sent to backends, but any load balancing mechanism that relies on the +legacy Endpoints API only sends traffic to at most 1000 of the available backing endpoints. + +The same API limit means that you cannot manually update an Endpoints to have more than 1000 endpoints. + +### Application protocol + +{{< feature-state for_k8s_version="v1.20" state="stable" >}} + +The `appProtocol` field provides a way to specify an application protocol for +each Service port. This is used as a hint for implementations to offer +richer behavior for protocols that they understand. +The value of this field is mirrored by the corresponding +Endpoints and EndpointSlice objects. + +This field follows standard Kubernetes label syntax. Valid values are one of: + +* [IANA standard service names](https://www.iana.org/assignments/service-names). + +* Implementation-defined prefixed names such as `mycompany.com/my-custom-protocol`. + +* Kubernetes-defined prefixed names: + +| Protocol | Description | +|----------|-------------| +| `kubernetes.io/h2c` | HTTP/2 over cleartext as described in [RFC 7540](https://www.rfc-editor.org/rfc/rfc7540) | +| `kubernetes.io/ws` | WebSocket over cleartext as described in [RFC 6455](https://www.rfc-editor.org/rfc/rfc6455) | +| `kubernetes.io/wss` | WebSocket over TLS as described in [RFC 6455](https://www.rfc-editor.org/rfc/rfc6455) | + +### Multi-port Services + +For some Services, you need to expose more than one port. +Kubernetes lets you configure multiple port definitions on a Service object. +When using multiple ports for a Service, you must give all of your ports names +so that these are unambiguous. +For example: + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + selector: + app.kubernetes.io/name: MyApp + ports: + - name: http + protocol: TCP + port: 80 + targetPort: 9376 + - name: https + protocol: TCP + port: 443 + targetPort: 9377 +``` + +{{< note >}} +As with Kubernetes {{< glossary_tooltip term_id="name" text="names">}} in general, names for ports +must only contain lowercase alphanumeric characters and `-`. Port names must +also start and end with an alphanumeric character. + +For example, the names `123-abc` and `web` are valid, but `123_abc` and `-web` are not. +{{< /note >}} + +## Service type {#publishing-services-service-types} + +For some parts of your application (for example, frontends) you may want to expose a +Service onto an external IP address, one that's accessible from outside of your +cluster. + +Kubernetes Service types allow you to specify what kind of Service you want. + +The available `type` values and their behaviors are: + +[`ClusterIP`](#type-clusterip) +: Exposes the Service on a cluster-internal IP. Choosing this value + makes the Service only reachable from within the cluster. This is the + default that is used if you don't explicitly specify a `type` for a Service. + You can expose the Service to the public internet using an + [Ingress](/docs/concepts/services-networking/ingress/) or a + [Gateway](https://gateway-api.sigs.k8s.io/). + +[`NodePort`](#type-nodeport) +: Exposes the Service on each Node's IP at a static port (the `NodePort`). + To make the node port available, Kubernetes sets up a cluster IP address, + the same as if you had requested a Service of `type: ClusterIP`. + +[`LoadBalancer`](#loadbalancer) +: Exposes the Service externally using an external load balancer. Kubernetes + does not directly offer a load balancing component; you must provide one, or + you can integrate your Kubernetes cluster with a cloud provider. + +[`ExternalName`](#externalname) +: Maps the Service to the contents of the `externalName` field (for example, + to the hostname `api.foo.bar.example`). The mapping configures your cluster's + DNS server to return a `CNAME` record with that external hostname value. + No proxying of any kind is set up. + +The `type` field in the Service API is designed as nested functionality - each level +adds to the previous. However there is an exception to this nested design. You can +define a `LoadBalancer` Service by +[disabling the load balancer `NodePort` allocation](/docs/concepts/services-networking/service/#load-balancer-nodeport-allocation). + +### `type: ClusterIP` {#type-clusterip} + +This default Service type assigns an IP address from a pool of IP addresses that +your cluster has reserved for that purpose. + +Several of the other types for Service build on the `ClusterIP` type as a +foundation. + +If you define a Service that has the `.spec.clusterIP` set to `"None"` then +Kubernetes does not assign an IP address. See [headless Services](#headless-services) +for more information. + +#### Choosing your own IP address + +You can specify your own cluster IP address as part of a `Service` creation +request. To do this, set the `.spec.clusterIP` field. For example, if you +already have an existing DNS entry that you wish to reuse, or legacy systems +that are configured for a specific IP address and difficult to re-configure. + +The IP address that you choose must be a valid IPv4 or IPv6 address from within the +`service-cluster-ip-range` CIDR range that is configured for the API server. +If you try to create a Service with an invalid `clusterIP` address value, the API +server will return a 422 HTTP status code to indicate that there's a problem. + +Read [avoiding collisions](/docs/reference/networking/virtual-ips/#avoiding-collisions) +to learn how Kubernetes helps reduce the risk and impact of two different Services +both trying to use the same IP address. + +### `type: NodePort` {#type-nodeport} + +If you set the `type` field to `NodePort`, the Kubernetes control plane +allocates a port from a range specified by `--service-node-port-range` flag (default: 30000-32767). +Each node proxies that port (the same port number on every Node) into your Service. +Your Service reports the allocated port in its `.spec.ports[*].nodePort` field. + +Using a NodePort gives you the freedom to set up your own load balancing solution, +to configure environments that are not fully supported by Kubernetes, or even +to expose one or more nodes' IP addresses directly. + +For a node port Service, Kubernetes additionally allocates a port (TCP, UDP or +SCTP to match the protocol of the Service). Every node in the cluster configures +itself to listen on that assigned port and to forward traffic to one of the ready +endpoints associated with that Service. You'll be able to contact the `type: NodePort` +Service, from outside the cluster, by connecting to any node using the appropriate +protocol (for example: TCP), and the appropriate port (as assigned to that Service). + +#### Choosing your own port {#nodeport-custom-port} + +If you want a specific port number, you can specify a value in the `nodePort` +field. The control plane will either allocate you that port or report that +the API transaction failed. +This means that you need to take care of possible port collisions yourself. +You also have to use a valid port number, one that's inside the range configured +for NodePort use. + +Here is an example manifest for a Service of `type: NodePort` that specifies +a NodePort value (30007, in this example): + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + type: NodePort + selector: + app.kubernetes.io/name: MyApp + ports: + - port: 80 + # By default and for convenience, the `targetPort` is set to + # the same value as the `port` field. + targetPort: 80 + # Optional field + # By default and for convenience, the Kubernetes control plane + # will allocate a port from a range (default: 30000-32767) + nodePort: 30007 +``` + +#### Reserve Nodeport ranges to avoid collisions {#avoid-nodeport-collisions} + +The policy for assigning ports to NodePort services applies to both the auto-assignment and +the manual assignment scenarios. When a user wants to create a NodePort service that +uses a specific port, the target port may conflict with another port that has already been assigned. + +To avoid this problem, the port range for NodePort services is divided into two bands. +Dynamic port assignment uses the upper band by default, and it may use the lower band once the +upper band has been exhausted. Users can then allocate from the lower band with a lower risk of port collision. + +#### Custom IP address configuration for `type: NodePort` Services {#service-nodeport-custom-listen-address} + +You can set up nodes in your cluster to use a particular IP address for serving node port +services. You might want to do this if each node is connected to multiple networks (for example: +one network for application traffic, and another network for traffic between nodes and the +control plane). + +If you want to specify particular IP address(es) to proxy the port, you can set the +`--nodeport-addresses` flag for kube-proxy or the equivalent `nodePortAddresses` +field of the [kube-proxy configuration file](/docs/reference/config-api/kube-proxy-config.v1alpha1/) +to particular IP block(s). + +This flag takes a comma-delimited list of IP blocks (e.g. `10.0.0.0/8`, `192.0.2.0/25`) +to specify IP address ranges that kube-proxy should consider as local to this node. + +For example, if you start kube-proxy with the `--nodeport-addresses=127.0.0.0/8` flag, +kube-proxy only selects the loopback interface for NodePort Services. +The default for `--nodeport-addresses` is an empty list. +This means that kube-proxy should consider all available network interfaces for NodePort. +(That's also compatible with earlier Kubernetes releases.) +{{< note >}} +This Service is visible as `:spec.ports[*].nodePort` and `.spec.clusterIP:spec.ports[*].port`. +If the `--nodeport-addresses` flag for kube-proxy or the equivalent field +in the kube-proxy configuration file is set, `` would be a filtered +node IP address (or possibly IP addresses). +{{< /note >}} + +### `type: LoadBalancer` {#loadbalancer} + +On cloud providers which support external load balancers, setting the `type` +field to `LoadBalancer` provisions a load balancer for your Service. +The actual creation of the load balancer happens asynchronously, and +information about the provisioned balancer is published in the Service's +`.status.loadBalancer` field. +For example: + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + selector: + app.kubernetes.io/name: MyApp + ports: + - protocol: TCP + port: 80 + targetPort: 9376 + clusterIP: 10.0.171.239 + type: LoadBalancer +status: + loadBalancer: + ingress: + - ip: 192.0.2.127 +``` + +Traffic from the external load balancer is directed at the backend Pods. The cloud +provider decides how it is load balanced. + +To implement a Service of `type: LoadBalancer`, Kubernetes typically starts off +by making the changes that are equivalent to you requesting a Service of +`type: NodePort`. The cloud-controller-manager component then configures the external +load balancer to forward traffic to that assigned node port. + +You can configure a load balanced Service to +[omit](#load-balancer-nodeport-allocation) assigning a node port, provided that the +cloud provider implementation supports this. + +Some cloud providers allow you to specify the `loadBalancerIP`. In those cases, the load-balancer is created +with the user-specified `loadBalancerIP`. If the `loadBalancerIP` field is not specified, +the load balancer is set up with an ephemeral IP address. If you specify a `loadBalancerIP` +but your cloud provider does not support the feature, the `loadbalancerIP` field that you +set is ignored. + + +{{< note >}} +The`.spec.loadBalancerIP` field for a Service was deprecated in Kubernetes v1.24. + +This field was under-specified and its meaning varies across implementations. +It also cannot support dual-stack networking. This field may be removed in a future API version. + +If you're integrating with a provider that supports specifying the load balancer IP address(es) +for a Service via a (provider specific) annotation, you should switch to doing that. + +If you are writing code for a load balancer integration with Kubernetes, avoid using this field. +You can integrate with [Gateway](https://gateway-api.sigs.k8s.io/) rather than Service, or you +can define your own (provider specific) annotations on the Service that specify the equivalent detail. +{{< /note >}} + +#### Node liveness impact on load balancer traffic + +Load balancer health checks are critical to modern applications. They are used to +determine which server (virtual machine, or IP address) the load balancer should +dispatch traffic to. The Kubernetes APIs do not define how health checks have to be +implemented for Kubernetes managed load balancers, instead it's the cloud providers +(and the people implementing integration code) who decide on the behavior. Load +balancer health checks are extensively used within the context of supporting the +`externalTrafficPolicy` field for Services. + +#### Load balancers with mixed protocol types + +{{< feature-state feature_gate_name="MixedProtocolLBService" >}} + +By default, for LoadBalancer type of Services, when there is more than one port defined, all +ports must have the same protocol, and the protocol must be one which is supported +by the cloud provider. + +The feature gate `MixedProtocolLBService` (enabled by default for the kube-apiserver as of v1.24) allows the use of +different protocols for LoadBalancer type of Services, when there is more than one port defined. + +{{< note >}} +The set of protocols that can be used for load balanced Services is defined by your +cloud provider; they may impose restrictions beyond what the Kubernetes API enforces. +{{< /note >}} + +#### Disabling load balancer NodePort allocation {#load-balancer-nodeport-allocation} + +{{< feature-state for_k8s_version="v1.24" state="stable" >}} + +You can optionally disable node port allocation for a Service of `type: LoadBalancer`, by setting +the field `spec.allocateLoadBalancerNodePorts` to `false`. This should only be used for load balancer implementations +that route traffic directly to pods as opposed to using node ports. By default, `spec.allocateLoadBalancerNodePorts` +is `true` and type LoadBalancer Services will continue to allocate node ports. If `spec.allocateLoadBalancerNodePorts` +is set to `false` on an existing Service with allocated node ports, those node ports will **not** be de-allocated automatically. +You must explicitly remove the `nodePorts` entry in every Service port to de-allocate those node ports. + +#### Specifying class of load balancer implementation {#load-balancer-class} + +{{< feature-state for_k8s_version="v1.24" state="stable" >}} + +For a Service with `type` set to `LoadBalancer`, the `.spec.loadBalancerClass` field +enables you to use a load balancer implementation other than the cloud provider default. + +By default, `.spec.loadBalancerClass` is not set and a `LoadBalancer` +type of Service uses the cloud provider's default load balancer implementation if the +cluster is configured with a cloud provider using the `--cloud-provider` component +flag. + +If you specify `.spec.loadBalancerClass`, it is assumed that a load balancer +implementation that matches the specified class is watching for Services. +Any default load balancer implementation (for example, the one provided by +the cloud provider) will ignore Services that have this field set. +`spec.loadBalancerClass` can be set on a Service of type `LoadBalancer` only. +Once set, it cannot be changed. +The value of `spec.loadBalancerClass` must be a label-style identifier, +with an optional prefix such as "`internal-vip`" or "`example.com/internal-vip`". +Unprefixed names are reserved for end-users. + +#### Load balancer IP address mode {#load-balancer-ip-mode} + +{{< feature-state feature_gate_name="LoadBalancerIPMode" >}} + +For a Service of `type: LoadBalancer`, a controller can set `.status.loadBalancer.ingress.ipMode`. +The `.status.loadBalancer.ingress.ipMode` specifies how the load-balancer IP behaves. +It may be specified only when the `.status.loadBalancer.ingress.ip` field is also specified. + +There are two possible values for `.status.loadBalancer.ingress.ipMode`: "VIP" and "Proxy". +The default value is "VIP" meaning that traffic is delivered to the node +with the destination set to the load-balancer's IP and port. +There are two cases when setting this to "Proxy", depending on how the load-balancer +from the cloud provider delivers the traffics: + +- If the traffic is delivered to the node then DNATed to the pod, the destination would be set to the node's IP and node port; +- If the traffic is delivered directly to the pod, the destination would be set to the pod's IP and port. + +Service implementations may use this information to adjust traffic routing. + +#### Internal load balancer + +In a mixed environment it is sometimes necessary to route traffic from Services inside the same +(virtual) network address block. + +In a split-horizon DNS environment you would need two Services to be able to route both external +and internal traffic to your endpoints. + +To set an internal load balancer, add one of the following annotations to your Service +depending on the cloud service provider you're using: + +{{< tabs name="service_tabs" >}} +{{% tab name="Default" %}} +Select one of the tabs. +{{% /tab %}} + +{{% tab name="GCP" %}} + +```yaml +metadata: + name: my-service + annotations: + networking.gke.io/load-balancer-type: "Internal" +``` +{{% /tab %}} +{{% tab name="AWS" %}} + +```yaml +metadata: + name: my-service + annotations: + service.beta.kubernetes.io/aws-load-balancer-internal: "true" +``` + +{{% /tab %}} +{{% tab name="Azure" %}} + +```yaml +metadata: + name: my-service + annotations: + service.beta.kubernetes.io/azure-load-balancer-internal: "true" +``` + +{{% /tab %}} +{{% tab name="IBM Cloud" %}} + +```yaml +metadata: + name: my-service + annotations: + service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private" +``` + +{{% /tab %}} +{{% tab name="OpenStack" %}} + +```yaml +metadata: + name: my-service + annotations: + service.beta.kubernetes.io/openstack-internal-load-balancer: "true" +``` + +{{% /tab %}} +{{% tab name="Baidu Cloud" %}} + +```yaml +metadata: + name: my-service + annotations: + service.beta.kubernetes.io/cce-load-balancer-internal-vpc: "true" +``` + +{{% /tab %}} +{{% tab name="Tencent Cloud" %}} + +```yaml +metadata: + annotations: + service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: subnet-xxxxx +``` + +{{% /tab %}} +{{% tab name="Alibaba Cloud" %}} + +```yaml +metadata: + annotations: + service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet" +``` + +{{% /tab %}} +{{% tab name="OCI" %}} + +```yaml +metadata: + name: my-service + annotations: + service.beta.kubernetes.io/oci-load-balancer-internal: true +``` +{{% /tab %}} +{{< /tabs >}} + +### `type: ExternalName` {#externalname} + +Services of type ExternalName map a Service to a DNS name, not to a typical selector such as +`my-service` or `cassandra`. You specify these Services with the `spec.externalName` parameter. + +This Service definition, for example, maps +the `my-service` Service in the `prod` namespace to `my.database.example.com`: + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service + namespace: prod +spec: + type: ExternalName + externalName: my.database.example.com +``` + +{{< note >}} +A Service of `type: ExternalName` accepts an IPv4 address string, +but treats that string as a DNS name comprised of digits, +not as an IP address (the internet does not however allow such names in DNS). +Services with external names that resemble IPv4 +addresses are not resolved by DNS servers. + +If you want to map a Service directly to a specific IP address, consider using +[headless Services](#headless-services). +{{< /note >}} + +When looking up the host `my-service.prod.svc.cluster.local`, the cluster DNS Service +returns a `CNAME` record with the value `my.database.example.com`. Accessing +`my-service` works in the same way as other Services but with the crucial +difference that redirection happens at the DNS level rather than via proxying or +forwarding. Should you later decide to move your database into your cluster, you +can start its Pods, add appropriate selectors or endpoints, and change the +Service's `type`. + +{{< caution >}} +You may have trouble using ExternalName for some common protocols, including HTTP and HTTPS. +If you use ExternalName then the hostname used by clients inside your cluster is different from +the name that the ExternalName references. + +For protocols that use hostnames this difference may lead to errors or unexpected responses. +HTTP requests will have a `Host:` header that the origin server does not recognize; +TLS servers will not be able to provide a certificate matching the hostname that the client connected to. +{{< /caution >}} + +## Headless Services + +Sometimes you don't need load-balancing and a single Service IP. In +this case, you can create what are termed _headless Services_, by explicitly +specifying `"None"` for the cluster IP address (`.spec.clusterIP`). + +You can use a headless Service to interface with other service discovery mechanisms, +without being tied to Kubernetes' implementation. + +For headless Services, a cluster IP is not allocated, kube-proxy does not handle +these Services, and there is no load balancing or proxying done by the platform for them. + +A headless Service allows a client to connect to whichever Pod it prefers, directly. Services that are headless don't +configure routes and packet forwarding using +[virtual IP addresses and proxies](/docs/reference/networking/virtual-ips/); instead, headless Services report the +endpoint IP addresses of the individual pods via internal DNS records, served through the cluster's +[DNS service](/docs/concepts/services-networking/dns-pod-service/). +To define a headless Service, you make a Service with `.spec.type` set to ClusterIP (which is also the default for `type`), +and you additionally set `.spec.clusterIP` to None. + +The string value None is a special case and is not the same as leaving the `.spec.clusterIP` field unset. + +How DNS is automatically configured depends on whether the Service has selectors defined: + +### With selectors + +For headless Services that define selectors, the endpoints controller creates +EndpointSlices in the Kubernetes API, and modifies the DNS configuration to return +A or AAAA records (IPv4 or IPv6 addresses) that point directly to the Pods backing the Service. + +### Without selectors + +For headless Services that do not define selectors, the control plane does +not create EndpointSlice objects. However, the DNS system looks for and configures +either: + +* DNS CNAME records for [`type: ExternalName`](#externalname) Services. +* DNS A / AAAA records for all IP addresses of the Service's ready endpoints, + for all Service types other than `ExternalName`. + * For IPv4 endpoints, the DNS system creates A records. + * For IPv6 endpoints, the DNS system creates AAAA records. + +When you define a headless Service without a selector, the `port` must +match the `targetPort`. + +## Discovering services + +For clients running inside your cluster, Kubernetes supports two primary modes of +finding a Service: environment variables and DNS. + +### Environment variables + +When a Pod is run on a Node, the kubelet adds a set of environment variables +for each active Service. It adds `{SVCNAME}_SERVICE_HOST` and `{SVCNAME}_SERVICE_PORT` variables, +where the Service name is upper-cased and dashes are converted to underscores. + + +For example, the Service `redis-primary` which exposes TCP port 6379 and has been +allocated cluster IP address 10.0.0.11, produces the following environment +variables: + +```shell +REDIS_PRIMARY_SERVICE_HOST=10.0.0.11 +REDIS_PRIMARY_SERVICE_PORT=6379 +REDIS_PRIMARY_PORT=tcp://10.0.0.11:6379 +REDIS_PRIMARY_PORT_6379_TCP=tcp://10.0.0.11:6379 +REDIS_PRIMARY_PORT_6379_TCP_PROTO=tcp +REDIS_PRIMARY_PORT_6379_TCP_PORT=6379 +REDIS_PRIMARY_PORT_6379_TCP_ADDR=10.0.0.11 +``` + +{{< note >}} +When you have a Pod that needs to access a Service, and you are using +the environment variable method to publish the port and cluster IP to the client +Pods, you must create the Service *before* the client Pods come into existence. +Otherwise, those client Pods won't have their environment variables populated. + +If you only use DNS to discover the cluster IP for a Service, you don't need to +worry about this ordering issue. +{{< /note >}} + +Kubernetes also supports and provides variables that are compatible with Docker +Engine's "_[legacy container links](https://docs.docker.com/network/links/)_" feature. +You can read [`makeLinkVariables`](https://github.com/kubernetes/kubernetes/blob/dd2d12f6dc0e654c15d5db57a5f9f6ba61192726/pkg/kubelet/envvars/envvars.go#L72) +to see how this is implemented in Kubernetes. + +### DNS + +You can (and almost always should) set up a DNS service for your Kubernetes +cluster using an [add-on](/docs/concepts/cluster-administration/addons/). + +A cluster-aware DNS server, such as CoreDNS, watches the Kubernetes API for new +Services and creates a set of DNS records for each one. If DNS has been enabled +throughout your cluster then all Pods should automatically be able to resolve +Services by their DNS name. + +For example, if you have a Service called `my-service` in a Kubernetes +namespace `my-ns`, the control plane and the DNS Service acting together +create a DNS record for `my-service.my-ns`. Pods in the `my-ns` namespace +should be able to find the service by doing a name lookup for `my-service` +(`my-service.my-ns` would also work). + +Pods in other namespaces must qualify the name as `my-service.my-ns`. These names +will resolve to the cluster IP assigned for the Service. + +Kubernetes also supports DNS SRV (Service) records for named ports. If the +`my-service.my-ns` Service has a port named `http` with the protocol set to +`TCP`, you can do a DNS SRV query for `_http._tcp.my-service.my-ns` to discover +the port number for `http`, as well as the IP address. + +The Kubernetes DNS server is the only way to access `ExternalName` Services. +You can find more information about `ExternalName` resolution in +[DNS for Services and Pods](/docs/concepts/services-networking/dns-pod-service/). + + + + + + + + + + +## Virtual IP addressing mechanism + +Read [Virtual IPs and Service Proxies](/docs/reference/networking/virtual-ips/) explains the +mechanism Kubernetes provides to expose a Service with a virtual IP address. + +### Traffic policies + +You can set the `.spec.internalTrafficPolicy` and `.spec.externalTrafficPolicy` fields +to control how Kubernetes routes traffic to healthy (“ready”) backends. + +See [Traffic Policies](/docs/reference/networking/virtual-ips/#traffic-policies) for more details. + +### Traffic distribution + +{{< feature-state feature_gate_name="ServiceTrafficDistribution" >}} + +The `.spec.trafficDistribution` field provides another way to influence traffic +routing within a Kubernetes Service. While traffic policies focus on strict +semantic guarantees, traffic distribution allows you to express _preferences_ +(such as routing to topologically closer endpoints). This can help optimize for +performance, cost, or reliability. In Kubernetes {{< skew currentVersion >}}, the +following field value is supported: + +`PreferClose` +: Indicates a preference for routing traffic to endpoints that are in the same + zone as the client. + +{{< feature-state feature_gate_name="PreferSameTrafficDistribution" >}} + +Two additional values are available when the `PreferSameTrafficDistribution` +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is +enabled: + +`PreferSameZone` +: This is an alias for `PreferClose` that is clearer about the intended semantics. + +`PreferSameNode` +: Indicates a preference for routing traffic to endpoints that are on the same + node as the client. + +If the field is not set, the implementation will apply its default routing strategy. + +See [Traffic +Distribution](/docs/reference/networking/virtual-ips/#traffic-distribution) for +more details + +### Session stickiness + +If you want to make sure that connections from a particular client are passed to +the same Pod each time, you can configure session affinity based on the client's +IP address. Read [session affinity](/docs/reference/networking/virtual-ips/#session-affinity) +to learn more. + +## External IPs + +If there are external IPs that route to one or more cluster nodes, Kubernetes Services +can be exposed on those `externalIPs`. When network traffic arrives into the cluster, with +the external IP (as destination IP) and the port matching that Service, rules and routes +that Kubernetes has configured ensure that the traffic is routed to one of the endpoints +for that Service. + +When you define a Service, you can specify `externalIPs` for any +[service type](#publishing-services-service-types). +In the example below, the Service named `"my-service"` can be accessed by clients using TCP, +on `"198.51.100.32:80"` (calculated from `.spec.externalIPs[]` and `.spec.ports[].port`). + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + selector: + app.kubernetes.io/name: MyApp + ports: + - name: http + protocol: TCP + port: 80 + targetPort: 49152 + externalIPs: + - 198.51.100.32 +``` + +{{< note >}} +Kubernetes does not manage allocation of `externalIPs`; these are the responsibility +of the cluster administrator. +{{< /note >}} + +## API Object + +Service is a top-level resource in the Kubernetes REST API. You can find more details +about the [Service API object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core). + +## {{% heading "whatsnext" %}} + +Learn more about Services and how they fit into Kubernetes: + +* Follow the [Connecting Applications with Services](/docs/tutorials/services/connect-applications-service/) + tutorial. +* Read about [Ingress](/docs/concepts/services-networking/ingress/), which + exposes HTTP and HTTPS routes from outside the cluster to Services within + your cluster. +* Read about [Gateway](/docs/concepts/services-networking/gateway/), an extension to + Kubernetes that provides more flexibility than Ingress. + +For more context, read the following: + +* [Virtual IPs and Service Proxies](/docs/reference/networking/virtual-ips/) +* [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/) +* [Service API reference](/docs/reference/kubernetes-api/service-resources/service-v1/) +* [EndpointSlice API reference](/docs/reference/kubernetes-api/service-resources/endpoint-slice-v1/) +* [Endpoint API reference (legacy)](/docs/reference/kubernetes-api/service-resources/endpoints-v1/) diff --git a/content/fa/docs/concepts/storage/persistent-volumes.md b/content/fa/docs/concepts/storage/persistent-volumes.md new file mode 100644 index 0000000000000..f2182be8e3021 --- /dev/null +++ b/content/fa/docs/concepts/storage/persistent-volumes.md @@ -0,0 +1,1304 @@ +--- +reviewers: +- xirehat +title: حجم‌های پایدار +api_metadata: +- apiVersion: "v1" + kind: "PersistentVolume" +- apiVersion: "v1" + kind: "PersistentVolumeClaim" +feature: + title: ارکستراسیون ذخیره‌سازی + description: > + سیستم ذخیره‌سازی مورد نظر خود را، چه از ذخیره‌سازی محلی، چه از یک ارائه‌دهنده ابر عمومی یا یک سیستم ذخیره‌سازی شبکه‌ای مانند iSCSI یا NFS، به‌طور خودکار نصب کنید. +content_type: concept +weight: 20 +--- + + + +This document describes _persistent volumes_ in Kubernetes. Familiarity with +[volumes](/docs/concepts/storage/volumes/), [StorageClasses](/docs/concepts/storage/storage-classes/) +and [VolumeAttributesClasses](/docs/concepts/storage/volume-attributes-classes/) is suggested. + + + +## Introduction + +Managing storage is a distinct problem from managing compute instances. +The PersistentVolume subsystem provides an API for users and administrators +that abstracts details of how storage is provided from how it is consumed. +To do this, we introduce two new API resources: PersistentVolume and PersistentVolumeClaim. + +A _PersistentVolume_ (PV) is a piece of storage in the cluster that has been +provisioned by an administrator or dynamically provisioned using +[Storage Classes](/docs/concepts/storage/storage-classes/). It is a resource in +the cluster just like a node is a cluster resource. PVs are volume plugins like +Volumes, but have a lifecycle independent of any individual Pod that uses the PV. +This API object captures the details of the implementation of the storage, be that +NFS, iSCSI, or a cloud-provider-specific storage system. + +A _PersistentVolumeClaim_ (PVC) is a request for storage by a user. It is similar +to a Pod. Pods consume node resources and PVCs consume PV resources. Pods can +request specific levels of resources (CPU and Memory). Claims can request specific +size and access modes (e.g., they can be mounted ReadWriteOnce, ReadOnlyMany, +ReadWriteMany, or ReadWriteOncePod, see [AccessModes](#access-modes)). + +While PersistentVolumeClaims allow a user to consume abstract storage resources, +it is common that users need PersistentVolumes with varying properties, such as +performance, for different problems. Cluster administrators need to be able to +offer a variety of PersistentVolumes that differ in more ways than size and access +modes, without exposing users to the details of how those volumes are implemented. +For these needs, there is the _StorageClass_ resource. + +See the [detailed walkthrough with working examples](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/). + +## Lifecycle of a volume and claim + +PVs are resources in the cluster. PVCs are requests for those resources and also act +as claim checks to the resource. The interaction between PVs and PVCs follows this lifecycle: + +### Provisioning + +There are two ways PVs may be provisioned: statically or dynamically. + +#### Static + +A cluster administrator creates a number of PVs. They carry the details of the +real storage, which is available for use by cluster users. They exist in the +Kubernetes API and are available for consumption. + +#### Dynamic + +When none of the static PVs the administrator created match a user's PersistentVolumeClaim, +the cluster may try to dynamically provision a volume specially for the PVC. +This provisioning is based on StorageClasses: the PVC must request a +[storage class](/docs/concepts/storage/storage-classes/) and +the administrator must have created and configured that class for dynamic +provisioning to occur. Claims that request the class `""` effectively disable +dynamic provisioning for themselves. + +To enable dynamic storage provisioning based on storage class, the cluster administrator +needs to enable the `DefaultStorageClass` +[admission controller](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) +on the API server. This can be done, for example, by ensuring that `DefaultStorageClass` is +among the comma-delimited, ordered list of values for the `--enable-admission-plugins` flag of +the API server component. For more information on API server command-line flags, +check [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) documentation. + +### Binding + +A user creates, or in the case of dynamic provisioning, has already created, +a PersistentVolumeClaim with a specific amount of storage requested and with +certain access modes. A control loop in the control plane watches for new PVCs, finds +a matching PV (if possible), and binds them together. If a PV was dynamically +provisioned for a new PVC, the loop will always bind that PV to the PVC. Otherwise, +the user will always get at least what they asked for, but the volume may be in +excess of what was requested. Once bound, PersistentVolumeClaim binds are exclusive, +regardless of how they were bound. A PVC to PV binding is a one-to-one mapping, +using a ClaimRef which is a bi-directional binding between the PersistentVolume +and the PersistentVolumeClaim. + +Claims will remain unbound indefinitely if a matching volume does not exist. +Claims will be bound as matching volumes become available. For example, a +cluster provisioned with many 50Gi PVs would not match a PVC requesting 100Gi. +The PVC can be bound when a 100Gi PV is added to the cluster. + +### Using + +Pods use claims as volumes. The cluster inspects the claim to find the bound +volume and mounts that volume for a Pod. For volumes that support multiple +access modes, the user specifies which mode is desired when using their claim +as a volume in a Pod. + +Once a user has a claim and that claim is bound, the bound PV belongs to the +user for as long as they need it. Users schedule Pods and access their claimed +PVs by including a `persistentVolumeClaim` section in a Pod's `volumes` block. +See [Claims As Volumes](#claims-as-volumes) for more details on this. + +### Storage Object in Use Protection + +The purpose of the Storage Object in Use Protection feature is to ensure that +PersistentVolumeClaims (PVCs) in active use by a Pod and PersistentVolume (PVs) +that are bound to PVCs are not removed from the system, as this may result in data loss. + +{{< note >}} +PVC is in active use by a Pod when a Pod object exists that is using the PVC. +{{< /note >}} + +If a user deletes a PVC in active use by a Pod, the PVC is not removed immediately. +PVC removal is postponed until the PVC is no longer actively used by any Pods. Also, +if an admin deletes a PV that is bound to a PVC, the PV is not removed immediately. +PV removal is postponed until the PV is no longer bound to a PVC. + +You can see that a PVC is protected when the PVC's status is `Terminating` and the +`Finalizers` list includes `kubernetes.io/pvc-protection`: + +```shell +kubectl describe pvc hostpath +Name: hostpath +Namespace: default +StorageClass: example-hostpath +Status: Terminating +Volume: +Labels: +Annotations: volume.beta.kubernetes.io/storage-class=example-hostpath + volume.beta.kubernetes.io/storage-provisioner=example.com/hostpath +Finalizers: [kubernetes.io/pvc-protection] +... +``` + +You can see that a PV is protected when the PV's status is `Terminating` and +the `Finalizers` list includes `kubernetes.io/pv-protection` too: + +```shell +kubectl describe pv task-pv-volume +Name: task-pv-volume +Labels: type=local +Annotations: +Finalizers: [kubernetes.io/pv-protection] +StorageClass: standard +Status: Terminating +Claim: +Reclaim Policy: Delete +Access Modes: RWO +Capacity: 1Gi +Message: +Source: + Type: HostPath (bare host directory volume) + Path: /tmp/data + HostPathType: +Events: +``` + +### Reclaiming + +When a user is done with their volume, they can delete the PVC objects from the +API that allows reclamation of the resource. The reclaim policy for a PersistentVolume +tells the cluster what to do with the volume after it has been released of its claim. +Currently, volumes can either be Retained, Recycled, or Deleted. + +#### Retain + +The `Retain` reclaim policy allows for manual reclamation of the resource. +When the PersistentVolumeClaim is deleted, the PersistentVolume still exists +and the volume is considered "released". But it is not yet available for +another claim because the previous claimant's data remains on the volume. +An administrator can manually reclaim the volume with the following steps. + +1. Delete the PersistentVolume. The associated storage asset in external infrastructure + still exists after the PV is deleted. +1. Manually clean up the data on the associated storage asset accordingly. +1. Manually delete the associated storage asset. + +If you want to reuse the same storage asset, create a new PersistentVolume with +the same storage asset definition. + +#### Delete + +For volume plugins that support the `Delete` reclaim policy, deletion removes +both the PersistentVolume object from Kubernetes, as well as the associated +storage asset in the external infrastructure. Volumes that were dynamically provisioned +inherit the [reclaim policy of their StorageClass](#reclaim-policy), which +defaults to `Delete`. The administrator should configure the StorageClass +according to users' expectations; otherwise, the PV must be edited or +patched after it is created. See +[Change the Reclaim Policy of a PersistentVolume](/docs/tasks/administer-cluster/change-pv-reclaim-policy/). + +#### Recycle + +{{< warning >}} +The `Recycle` reclaim policy is deprecated. Instead, the recommended approach +is to use dynamic provisioning. +{{< /warning >}} + +If supported by the underlying volume plugin, the `Recycle` reclaim policy performs +a basic scrub (`rm -rf /thevolume/*`) on the volume and makes it available again for a new claim. + +However, an administrator can configure a custom recycler Pod template using +the Kubernetes controller manager command line arguments as described in the +[reference](/docs/reference/command-line-tools-reference/kube-controller-manager/). +The custom recycler Pod template must contain a `volumes` specification, as +shown in the example below: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: pv-recycler + namespace: default +spec: + restartPolicy: Never + volumes: + - name: vol + hostPath: + path: /any/path/it/will/be/replaced + containers: + - name: pv-recycler + image: "registry.k8s.io/busybox" + command: ["/bin/sh", "-c", "test -e /scrub && rm -rf /scrub/..?* /scrub/.[!.]* /scrub/* && test -z \"$(ls -A /scrub)\" || exit 1"] + volumeMounts: + - name: vol + mountPath: /scrub +``` + +However, the particular path specified in the custom recycler Pod template in the +`volumes` part is replaced with the particular path of the volume that is being recycled. + +### PersistentVolume deletion protection finalizer +{{< feature-state feature_gate_name="HonorPVReclaimPolicy" >}} + +Finalizers can be added on a PersistentVolume to ensure that PersistentVolumes +having `Delete` reclaim policy are deleted only after the backing storage are deleted. + +The finalizer `external-provisioner.volume.kubernetes.io/finalizer`(introduced +in v1.31) is added to both dynamically provisioned and statically provisioned +CSI volumes. + +The finalizer `kubernetes.io/pv-controller`(introduced in v1.31) is added to +dynamically provisioned in-tree plugin volumes and skipped for statically +provisioned in-tree plugin volumes. + +The following is an example of dynamically provisioned in-tree plugin volume: + +```shell +kubectl describe pv pvc-74a498d6-3929-47e8-8c02-078c1ece4d78 +Name: pvc-74a498d6-3929-47e8-8c02-078c1ece4d78 +Labels: +Annotations: kubernetes.io/createdby: vsphere-volume-dynamic-provisioner + pv.kubernetes.io/bound-by-controller: yes + pv.kubernetes.io/provisioned-by: kubernetes.io/vsphere-volume +Finalizers: [kubernetes.io/pv-protection kubernetes.io/pv-controller] +StorageClass: vcp-sc +Status: Bound +Claim: default/vcp-pvc-1 +Reclaim Policy: Delete +Access Modes: RWO +VolumeMode: Filesystem +Capacity: 1Gi +Node Affinity: +Message: +Source: + Type: vSphereVolume (a Persistent Disk resource in vSphere) + VolumePath: [vsanDatastore] d49c4a62-166f-ce12-c464-020077ba5d46/kubernetes-dynamic-pvc-74a498d6-3929-47e8-8c02-078c1ece4d78.vmdk + FSType: ext4 + StoragePolicyName: vSAN Default Storage Policy +Events: +``` + +The finalizer `external-provisioner.volume.kubernetes.io/finalizer` is added for CSI volumes. +The following is an example: + +```shell +Name: pvc-2f0bab97-85a8-4552-8044-eb8be45cf48d +Labels: +Annotations: pv.kubernetes.io/provisioned-by: csi.vsphere.vmware.com +Finalizers: [kubernetes.io/pv-protection external-provisioner.volume.kubernetes.io/finalizer] +StorageClass: fast +Status: Bound +Claim: demo-app/nginx-logs +Reclaim Policy: Delete +Access Modes: RWO +VolumeMode: Filesystem +Capacity: 200Mi +Node Affinity: +Message: +Source: + Type: CSI (a Container Storage Interface (CSI) volume source) + Driver: csi.vsphere.vmware.com + FSType: ext4 + VolumeHandle: 44830fa8-79b4-406b-8b58-621ba25353fd + ReadOnly: false + VolumeAttributes: storage.kubernetes.io/csiProvisionerIdentity=1648442357185-8081-csi.vsphere.vmware.com + type=vSphere CNS Block Volume +Events: +``` + +When the `CSIMigration{provider}` feature flag is enabled for a specific in-tree volume plugin, +the `kubernetes.io/pv-controller` finalizer is replaced by the +`external-provisioner.volume.kubernetes.io/finalizer` finalizer. + +The finalizers ensure that the PV object is removed only after the volume is deleted +from the storage backend provided the reclaim policy of the PV is `Delete`. This +also ensures that the volume is deleted from storage backend irrespective of the +order of deletion of PV and PVC. + +### Reserving a PersistentVolume + +The control plane can [bind PersistentVolumeClaims to matching PersistentVolumes](#binding) +in the cluster. However, if you want a PVC to bind to a specific PV, you need to pre-bind them. + +By specifying a PersistentVolume in a PersistentVolumeClaim, you declare a binding +between that specific PV and PVC. If the PersistentVolume exists and has not reserved +PersistentVolumeClaims through its `claimRef` field, then the PersistentVolume and +PersistentVolumeClaim will be bound. + +The binding happens regardless of some volume matching criteria, including node affinity. +The control plane still checks that [storage class](/docs/concepts/storage/storage-classes/), +access modes, and requested storage size are valid. + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: foo-pvc + namespace: foo +spec: + storageClassName: "" # Empty string must be explicitly set otherwise default StorageClass will be set + volumeName: foo-pv + ... +``` + +This method does not guarantee any binding privileges to the PersistentVolume. +If other PersistentVolumeClaims could use the PV that you specify, you first +need to reserve that storage volume. Specify the relevant PersistentVolumeClaim +in the `claimRef` field of the PV so that other PVCs can not bind to it. + +```yaml +apiVersion: v1 +kind: PersistentVolume +metadata: + name: foo-pv +spec: + storageClassName: "" + claimRef: + name: foo-pvc + namespace: foo + ... +``` + +This is useful if you want to consume PersistentVolumes that have their `persistentVolumeReclaimPolicy` set +to `Retain`, including cases where you are reusing an existing PV. + +### Expanding Persistent Volumes Claims + +{{< feature-state for_k8s_version="v1.24" state="stable" >}} + +Support for expanding PersistentVolumeClaims (PVCs) is enabled by default. You can expand +the following types of volumes: + +* {{< glossary_tooltip text="csi" term_id="csi" >}} (including some CSI migrated +volme types) +* flexVolume (deprecated) +* portworxVolume (deprecated) + +You can only expand a PVC if its storage class's `allowVolumeExpansion` field is set to true. + +```yaml +apiVersion: storage.k8s.io/v1 +kind: StorageClass +metadata: + name: example-vol-default +provisioner: vendor-name.example/magicstorage +parameters: + resturl: "http://192.168.10.100:8080" + restuser: "" + secretNamespace: "" + secretName: "" +allowVolumeExpansion: true +``` + +To request a larger volume for a PVC, edit the PVC object and specify a larger +size. This triggers expansion of the volume that backs the underlying PersistentVolume. A +new PersistentVolume is never created to satisfy the claim. Instead, an existing volume is resized. + +{{< warning >}} +Directly editing the size of a PersistentVolume can prevent an automatic resize of that volume. +If you edit the capacity of a PersistentVolume, and then edit the `.spec` of a matching +PersistentVolumeClaim to make the size of the PersistentVolumeClaim match the PersistentVolume, +then no storage resize happens. +The Kubernetes control plane will see that the desired state of both resources matches, +conclude that the backing volume size has been manually +increased and that no resize is necessary. +{{< /warning >}} + +#### CSI Volume expansion + +{{< feature-state for_k8s_version="v1.24" state="stable" >}} + +Support for expanding CSI volumes is enabled by default but it also requires a +specific CSI driver to support volume expansion. Refer to documentation of the +specific CSI driver for more information. + +#### Resizing a volume containing a file system + +You can only resize volumes containing a file system if the file system is XFS, Ext3, or Ext4. + +When a volume contains a file system, the file system is only resized when a new Pod is using +the PersistentVolumeClaim in `ReadWrite` mode. File system expansion is either done when a Pod is starting up +or when a Pod is running and the underlying file system supports online expansion. + +FlexVolumes (deprecated since Kubernetes v1.23) allow resize if the driver is configured with the +`RequiresFSResize` capability to `true`. The FlexVolume can be resized on Pod restart. + +#### Resizing an in-use PersistentVolumeClaim + +{{< feature-state for_k8s_version="v1.24" state="stable" >}} + +In this case, you don't need to delete and recreate a Pod or deployment that is using an existing PVC. +Any in-use PVC automatically becomes available to its Pod as soon as its file system has been expanded. +This feature has no effect on PVCs that are not in use by a Pod or deployment. You must create a Pod that +uses the PVC before the expansion can complete. + +Similar to other volume types - FlexVolume volumes can also be expanded when in-use by a Pod. + +{{< note >}} +FlexVolume resize is possible only when the underlying driver supports resize. +{{< /note >}} + +#### Recovering from Failure when Expanding Volumes + +If a user specifies a new size that is too big to be satisfied by underlying +storage system, expansion of PVC will be continuously retried until user or +cluster administrator takes some action. This can be undesirable and hence +Kubernetes provides following methods of recovering from such failures. + +{{< tabs name="recovery_methods" >}} +{{% tab name="Manually with Cluster Administrator access" %}} + +If expanding underlying storage fails, the cluster administrator can manually +recover the Persistent Volume Claim (PVC) state and cancel the resize requests. +Otherwise, the resize requests are continuously retried by the controller without +administrator intervention. + +1. Mark the PersistentVolume(PV) that is bound to the PersistentVolumeClaim(PVC) + with `Retain` reclaim policy. +2. Delete the PVC. Since PV has `Retain` reclaim policy - we will not lose any data + when we recreate the PVC. +3. Delete the `claimRef` entry from PV specs, so as new PVC can bind to it. + This should make the PV `Available`. +4. Re-create the PVC with smaller size than PV and set `volumeName` field of the + PVC to the name of the PV. This should bind new PVC to existing PV. +5. Don't forget to restore the reclaim policy of the PV. + +{{% /tab %}} +{{% tab name="By requesting expansion to smaller size" %}} +{{< feature-state feature_gate_name="RecoverVolumeExpansionFailure" >}} + +{{< note >}} +Recover from failing PVC expansion by users (`RecoverVolumeExpansionFailure`) is available as an beta feature +since Kubernetes 1.32 and should be enabled by default. Refer to the +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) +documentation for more information. +{{< /note >}} + + +When using `RecoverVolumeExpansionFailure` feature, if expansion has failed for a PVC, you can retry expansion with a +smaller size than the previously requested value. To request a new expansion attempt with a +smaller proposed size, edit `.spec.resources` for that PVC and choose a value that is less than the +value you previously tried. +This is useful if expansion to a higher value did not succeed because of capacity constraint. +If that has happened, or you suspect that it might have, you can retry expansion by specifying a +size that is within the capacity limits of underlying storage provider. You can monitor status of +resize operation by watching `.status.allocatedResourceStatuses` and events on the PVC. + +Note that, +although you can specify a lower amount of storage than what was requested previously, +the new value must still be higher than `.status.capacity`. +Kubernetes does not support shrinking a PVC to less than its current size. +{{% /tab %}} +{{% /tabs %}} + +## Types of Persistent Volumes + +PersistentVolume types are implemented as plugins. Kubernetes currently supports the following plugins: + +* [`csi`](/docs/concepts/storage/volumes/#csi) - Container Storage Interface (CSI) +* [`fc`](/docs/concepts/storage/volumes/#fc) - Fibre Channel (FC) storage +* [`hostPath`](/docs/concepts/storage/volumes/#hostpath) - HostPath volume + (for single node testing only; WILL NOT WORK in a multi-node cluster; + consider using `local` volume instead) +* [`iscsi`](/docs/concepts/storage/volumes/#iscsi) - iSCSI (SCSI over IP) storage +* [`local`](/docs/concepts/storage/volumes/#local) - local storage devices + mounted on nodes. +* [`nfs`](/docs/concepts/storage/volumes/#nfs) - Network File System (NFS) storage + +The following types of PersistentVolume are deprecated but still available. +If you are using these volume types except for `flexVolume`, `cephfs` and `rbd`, +please install corresponding CSI drivers. + +* [`awsElasticBlockStore`](/docs/concepts/storage/volumes/#awselasticblockstore) - AWS Elastic Block Store (EBS) + (**migration on by default** starting v1.23) +* [`azureDisk`](/docs/concepts/storage/volumes/#azuredisk) - Azure Disk + (**migration on by default** starting v1.23) +* [`azureFile`](/docs/concepts/storage/volumes/#azurefile) - Azure File + (**migration on by default** starting v1.24) +* [`cinder`](/docs/concepts/storage/volumes/#cinder) - Cinder (OpenStack block storage) + (**migration on by default** starting v1.21) +* [`flexVolume`](/docs/concepts/storage/volumes/#flexvolume) - FlexVolume + (**deprecated** starting v1.23, no migration plan and no plan to remove support) +* [`gcePersistentDisk`](/docs/concepts/storage/volumes/#gcePersistentDisk) - GCE Persistent Disk + (**migration on by default** starting v1.23) +* [`portworxVolume`](/docs/concepts/storage/volumes/#portworxvolume) - Portworx volume + (**migration on by default** starting v1.31) +* [`vsphereVolume`](/docs/concepts/storage/volumes/#vspherevolume) - vSphere VMDK volume + (**migration on by default** starting v1.25) + +Older versions of Kubernetes also supported the following in-tree PersistentVolume types: + +* [`cephfs`](/docs/concepts/storage/volumes/#cephfs) + (**not available** starting v1.31) +* `flocker` - Flocker storage. + (**not available** starting v1.25) +* `glusterfs` - GlusterFS storage. + (**not available** starting v1.26) +* `photonPersistentDisk` - Photon controller persistent disk. + (**not available** starting v1.15) +* `quobyte` - Quobyte volume. + (**not available** starting v1.25) +* [`rbd`](/docs/concepts/storage/volumes/#rbd) - Rados Block Device (RBD) volume + (**not available** starting v1.31) +* `scaleIO` - ScaleIO volume. + (**not available** starting v1.21) +* `storageos` - StorageOS volume. + (**not available** starting v1.25) + +## Persistent Volumes + +Each PV contains a spec and status, which is the specification and status of the volume. +The name of a PersistentVolume object must be a valid +[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). + +```yaml +apiVersion: v1 +kind: PersistentVolume +metadata: + name: pv0003 +spec: + capacity: + storage: 5Gi + volumeMode: Filesystem + accessModes: + - ReadWriteOnce + persistentVolumeReclaimPolicy: Recycle + storageClassName: slow + mountOptions: + - hard + - nfsvers=4.1 + nfs: + path: /tmp + server: 172.17.0.2 +``` + +{{< note >}} +Helper programs relating to the volume type may be required for consumption of +a PersistentVolume within a cluster. In this example, the PersistentVolume is +of type NFS and the helper program /sbin/mount.nfs is required to support the +mounting of NFS filesystems. +{{< /note >}} + +### Capacity + +Generally, a PV will have a specific storage capacity. This is set using the PV's +`capacity` attribute which is a {{< glossary_tooltip term_id="quantity" >}} value. + +Currently, storage size is the only resource that can be set or requested. +Future attributes may include IOPS, throughput, etc. + +### Volume Mode + +{{< feature-state for_k8s_version="v1.18" state="stable" >}} + +Kubernetes supports two `volumeModes` of PersistentVolumes: `Filesystem` and `Block`. + +`volumeMode` is an optional API parameter. +`Filesystem` is the default mode used when `volumeMode` parameter is omitted. + +A volume with `volumeMode: Filesystem` is *mounted* into Pods into a directory. If the volume +is backed by a block device and the device is empty, Kubernetes creates a filesystem +on the device before mounting it for the first time. + +You can set the value of `volumeMode` to `Block` to use a volume as a raw block device. +Such volume is presented into a Pod as a block device, without any filesystem on it. +This mode is useful to provide a Pod the fastest possible way to access a volume, without +any filesystem layer between the Pod and the volume. On the other hand, the application +running in the Pod must know how to handle a raw block device. +See [Raw Block Volume Support](#raw-block-volume-support) +for an example on how to use a volume with `volumeMode: Block` in a Pod. + +### Access Modes + +A PersistentVolume can be mounted on a host in any way supported by the resource +provider. As shown in the table below, providers will have different capabilities +and each PV's access modes are set to the specific modes supported by that particular +volume. For example, NFS can support multiple read/write clients, but a specific +NFS PV might be exported on the server as read-only. Each PV gets its own set of +access modes describing that specific PV's capabilities. + +The access modes are: + +`ReadWriteOnce` +: the volume can be mounted as read-write by a single node. ReadWriteOnce access + mode still can allow multiple pods to access (read from or write to) that volume when the pods are + running on the same node. For single pod access, please see ReadWriteOncePod. + +`ReadOnlyMany` +: the volume can be mounted as read-only by many nodes. + +`ReadWriteMany` +: the volume can be mounted as read-write by many nodes. + + `ReadWriteOncePod` +: {{< feature-state for_k8s_version="v1.29" state="stable" >}} + the volume can be mounted as read-write by a single Pod. Use ReadWriteOncePod + access mode if you want to ensure that only one pod across the whole cluster can + read that PVC or write to it. + +{{< note >}} +The `ReadWriteOncePod` access mode is only supported for +{{< glossary_tooltip text="CSI" term_id="csi" >}} volumes and Kubernetes version +1.22+. To use this feature you will need to update the following +[CSI sidecars](https://kubernetes-csi.github.io/docs/sidecar-containers.html) +to these versions or greater: + +* [csi-provisioner:v3.0.0+](https://github.com/kubernetes-csi/external-provisioner/releases/tag/v3.0.0) +* [csi-attacher:v3.3.0+](https://github.com/kubernetes-csi/external-attacher/releases/tag/v3.3.0) +* [csi-resizer:v1.3.0+](https://github.com/kubernetes-csi/external-resizer/releases/tag/v1.3.0) +{{< /note >}} + +In the CLI, the access modes are abbreviated to: + +* RWO - ReadWriteOnce +* ROX - ReadOnlyMany +* RWX - ReadWriteMany +* RWOP - ReadWriteOncePod + +{{< note >}} +Kubernetes uses volume access modes to match PersistentVolumeClaims and PersistentVolumes. +In some cases, the volume access modes also constrain where the PersistentVolume can be mounted. +Volume access modes do **not** enforce write protection once the storage has been mounted. +Even if the access modes are specified as ReadWriteOnce, ReadOnlyMany, or ReadWriteMany, +they don't set any constraints on the volume. For example, even if a PersistentVolume is +created as ReadOnlyMany, it is no guarantee that it will be read-only. If the access modes +are specified as ReadWriteOncePod, the volume is constrained and can be mounted on only a single Pod. +{{< /note >}} + +> __Important!__ A volume can only be mounted using one access mode at a time, +> even if it supports many. + +| Volume Plugin | ReadWriteOnce | ReadOnlyMany | ReadWriteMany | ReadWriteOncePod | +| :--- | :---: | :---: | :---: | - | +| AzureFile | ✓ | ✓ | ✓ | - | +| CephFS | ✓ | ✓ | ✓ | - | +| CSI | depends on the driver | depends on the driver | depends on the driver | depends on the driver | +| FC | ✓ | ✓ | - | - | +| FlexVolume | ✓ | ✓ | depends on the driver | - | +| HostPath | ✓ | - | - | - | +| iSCSI | ✓ | ✓ | - | - | +| NFS | ✓ | ✓ | ✓ | - | +| RBD | ✓ | ✓ | - | - | +| VsphereVolume | ✓ | - | - (works when Pods are collocated) | - | +| PortworxVolume | ✓ | - | ✓ | - | - | + +### Class + +A PV can have a class, which is specified by setting the +`storageClassName` attribute to the name of a +[StorageClass](/docs/concepts/storage/storage-classes/). +A PV of a particular class can only be bound to PVCs requesting +that class. A PV with no `storageClassName` has no class and can only be bound +to PVCs that request no particular class. + +In the past, the annotation `volume.beta.kubernetes.io/storage-class` was used instead +of the `storageClassName` attribute. This annotation is still working; however, +it will become fully deprecated in a future Kubernetes release. + +### Reclaim Policy + +Current reclaim policies are: + +* Retain -- manual reclamation +* Recycle -- basic scrub (`rm -rf /thevolume/*`) +* Delete -- delete the volume + +For Kubernetes {{< skew currentVersion >}}, only `nfs` and `hostPath` volume types support recycling. + +### Mount Options + +A Kubernetes administrator can specify additional mount options for when a +Persistent Volume is mounted on a node. + +{{< note >}} +Not all Persistent Volume types support mount options. +{{< /note >}} + +The following volume types support mount options: + +* `csi` (including CSI migrated volume types) +* `iscsi` +* `nfs` + +Mount options are not validated. If a mount option is invalid, the mount fails. + +In the past, the annotation `volume.beta.kubernetes.io/mount-options` was used instead +of the `mountOptions` attribute. This annotation is still working; however, +it will become fully deprecated in a future Kubernetes release. + +### Node Affinity + +{{< note >}} +For most volume types, you do not need to set this field. +You need to explicitly set this for [local](/docs/concepts/storage/volumes/#local) volumes. +{{< /note >}} + +A PV can specify node affinity to define constraints that limit what nodes this +volume can be accessed from. Pods that use a PV will only be scheduled to nodes +that are selected by the node affinity. To specify node affinity, set +`nodeAffinity` in the `.spec` of a PV. The +[PersistentVolume](/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-v1/#PersistentVolumeSpec) +API reference has more details on this field. + +### Phase + +A PersistentVolume will be in one of the following phases: + +`Available` +: a free resource that is not yet bound to a claim + +`Bound` +: the volume is bound to a claim + +`Released` +: the claim has been deleted, but the associated storage resource is not yet reclaimed by the cluster + +`Failed` +: the volume has failed its (automated) reclamation + +You can see the name of the PVC bound to the PV using `kubectl describe persistentvolume `. + +#### Phase transition timestamp + +{{< feature-state feature_gate_name="PersistentVolumeLastPhaseTransitionTime" >}} + +The `.status` field for a PersistentVolume can include an alpha `lastPhaseTransitionTime` field. This field records +the timestamp of when the volume last transitioned its phase. For newly created +volumes the phase is set to `Pending` and `lastPhaseTransitionTime` is set to +the current time. + +## PersistentVolumeClaims + +Each PVC contains a spec and status, which is the specification and status of the claim. +The name of a PersistentVolumeClaim object must be a valid +[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: myclaim +spec: + accessModes: + - ReadWriteOnce + volumeMode: Filesystem + resources: + requests: + storage: 8Gi + storageClassName: slow + selector: + matchLabels: + release: "stable" + matchExpressions: + - {key: environment, operator: In, values: [dev]} +``` + +### Access Modes + +Claims use [the same conventions as volumes](#access-modes) when requesting +storage with specific access modes. + +### Volume Modes + +Claims use [the same convention as volumes](#volume-mode) to indicate the +consumption of the volume as either a filesystem or block device. + +### Volume Name + +Claims can use the `volumeName` field to explicitly bind to a specific PersistentVolume. You can also leave +`volumeName` unset, indicating that you'd like Kubernetes to set up a new PersistentVolume +that matches the claim. +If the specified PV is already bound to another PVC, the binding will be stuck +in a pending state. + +### Resources + +Claims, like Pods, can request specific quantities of a resource. In this case, +the request is for storage. The same +[resource model](https://git.k8s.io/design-proposals-archive/scheduling/resources.md) +applies to both volumes and claims. + +{{< note >}} +For `Filesystem` volumes, the storage request refers to the "outer" volume size +(i.e. the allocated size from the storage backend). +This means that the writeable size may be slightly lower for providers that +build a filesystem on top of a block device, due to filesystem overhead. +This is especially visible with XFS, where many metadata features are enabled by default. +{{< /note >}} + +### Selector + +Claims can specify a +[label selector](/docs/concepts/overview/working-with-objects/labels/#label-selectors) +to further filter the set of volumes. +Only the volumes whose labels match the selector can be bound to the claim. +The selector can consist of two fields: + +* `matchLabels` - the volume must have a label with this value +* `matchExpressions` - a list of requirements made by specifying key, list of values, + and operator that relates the key and values. + Valid operators include `In`, `NotIn`, `Exists`, and `DoesNotExist`. + +All of the requirements, from both `matchLabels` and `matchExpressions`, are +ANDed together – they must all be satisfied in order to match. + +### Class + +A claim can request a particular class by specifying the name of a +[StorageClass](/docs/concepts/storage/storage-classes/) +using the attribute `storageClassName`. +Only PVs of the requested class, ones with the same `storageClassName` as the PVC, +can be bound to the PVC. + +PVCs don't necessarily have to request a class. A PVC with its `storageClassName` set +equal to `""` is always interpreted to be requesting a PV with no class, so it +can only be bound to PVs with no class (no annotation or one set equal to `""`). +A PVC with no `storageClassName` is not quite the same and is treated differently +by the cluster, depending on whether the +[`DefaultStorageClass` admission plugin](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) +is turned on. + +* If the admission plugin is turned on, the administrator may specify a default StorageClass. + All PVCs that have no `storageClassName` can be bound only to PVs of that default. + Specifying a default StorageClass is done by setting the annotation + `storageclass.kubernetes.io/is-default-class` equal to `true` in a StorageClass object. + If the administrator does not specify a default, the cluster responds to PVC creation + as if the admission plugin were turned off. + If more than one default StorageClass is specified, the newest default is used when + the PVC is dynamically provisioned. +* If the admission plugin is turned off, there is no notion of a default StorageClass. + All PVCs that have `storageClassName` set to `""` can be bound only to PVs + that have `storageClassName` also set to `""`. + However, PVCs with missing `storageClassName` can be updated later once default StorageClass becomes available. + If the PVC gets updated it will no longer bind to PVs that have `storageClassName` also set to `""`. + +See [retroactive default StorageClass assignment](#retroactive-default-storageclass-assignment) for more details. + +Depending on installation method, a default StorageClass may be deployed +to a Kubernetes cluster by addon manager during installation. + +When a PVC specifies a `selector` in addition to requesting a StorageClass, +the requirements are ANDed together: only a PV of the requested class and with +the requested labels may be bound to the PVC. + +{{< note >}} +Currently, a PVC with a non-empty `selector` can't have a PV dynamically provisioned for it. +{{< /note >}} + +In the past, the annotation `volume.beta.kubernetes.io/storage-class` was used instead +of `storageClassName` attribute. This annotation is still working; however, +it won't be supported in a future Kubernetes release. + +#### Retroactive default StorageClass assignment + +{{< feature-state for_k8s_version="v1.28" state="stable" >}} + +You can create a PersistentVolumeClaim without specifying a `storageClassName` +for the new PVC, and you can do so even when no default StorageClass exists +in your cluster. In this case, the new PVC creates as you defined it, and the +`storageClassName` of that PVC remains unset until default becomes available. + +When a default StorageClass becomes available, the control plane identifies any +existing PVCs without `storageClassName`. For the PVCs that either have an empty +value for `storageClassName` or do not have this key, the control plane then +updates those PVCs to set `storageClassName` to match the new default StorageClass. +If you have an existing PVC where the `storageClassName` is `""`, and you configure +a default StorageClass, then this PVC will not get updated. + +In order to keep binding to PVs with `storageClassName` set to `""` +(while a default StorageClass is present), you need to set the `storageClassName` +of the associated PVC to `""`. + +This behavior helps administrators change default StorageClass by removing the +old one first and then creating or setting another one. This brief window while +there is no default causes PVCs without `storageClassName` created at that time +to not have any default, but due to the retroactive default StorageClass +assignment this way of changing defaults is safe. + +## Claims As Volumes + +Pods access storage by using the claim as a volume. Claims must exist in the +same namespace as the Pod using the claim. The cluster finds the claim in the +Pod's namespace and uses it to get the PersistentVolume backing the claim. +The volume is then mounted to the host and into the Pod. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: myfrontend + image: nginx + volumeMounts: + - mountPath: "/var/www/html" + name: mypd + volumes: + - name: mypd + persistentVolumeClaim: + claimName: myclaim +``` + +### A Note on Namespaces + +PersistentVolumes binds are exclusive, and since PersistentVolumeClaims are +namespaced objects, mounting claims with "Many" modes (`ROX`, `RWX`) is only +possible within one namespace. + +### PersistentVolumes typed `hostPath` + +A `hostPath` PersistentVolume uses a file or directory on the Node to emulate +network-attached storage. See +[an example of `hostPath` typed volume](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume). + +## Raw Block Volume Support + +{{< feature-state for_k8s_version="v1.18" state="stable" >}} + +The following volume plugins support raw block volumes, including dynamic provisioning where +applicable: + +* CSI (including some CSI migrated volume types) +* FC (Fibre Channel) +* iSCSI +* Local volume + +### PersistentVolume using a Raw Block Volume {#persistent-volume-using-a-raw-block-volume} + +```yaml +apiVersion: v1 +kind: PersistentVolume +metadata: + name: block-pv +spec: + capacity: + storage: 10Gi + accessModes: + - ReadWriteOnce + volumeMode: Block + persistentVolumeReclaimPolicy: Retain + fc: + targetWWNs: ["50060e801049cfd1"] + lun: 0 + readOnly: false +``` + +### PersistentVolumeClaim requesting a Raw Block Volume {#persistent-volume-claim-requesting-a-raw-block-volume} + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: block-pvc +spec: + accessModes: + - ReadWriteOnce + volumeMode: Block + resources: + requests: + storage: 10Gi +``` + +### Pod specification adding Raw Block Device path in container + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: pod-with-block-volume +spec: + containers: + - name: fc-container + image: fedora:26 + command: ["/bin/sh", "-c"] + args: [ "tail -f /dev/null" ] + volumeDevices: + - name: data + devicePath: /dev/xvda + volumes: + - name: data + persistentVolumeClaim: + claimName: block-pvc +``` + +{{< note >}} +When adding a raw block device for a Pod, you specify the device path in the +container instead of a mount path. +{{< /note >}} + +### Binding Block Volumes + +If a user requests a raw block volume by indicating this using the `volumeMode` +field in the PersistentVolumeClaim spec, the binding rules differ slightly from +previous releases that didn't consider this mode as part of the spec. +Listed is a table of possible combinations the user and admin might specify for +requesting a raw block device. The table indicates if the volume will be bound or +not given the combinations: Volume binding matrix for statically provisioned volumes: + +| PV volumeMode | PVC volumeMode | Result | +| --------------|:---------------:| ----------------:| +| unspecified | unspecified | BIND | +| unspecified | Block | NO BIND | +| unspecified | Filesystem | BIND | +| Block | unspecified | NO BIND | +| Block | Block | BIND | +| Block | Filesystem | NO BIND | +| Filesystem | Filesystem | BIND | +| Filesystem | Block | NO BIND | +| Filesystem | unspecified | BIND | + +{{< note >}} +Only statically provisioned volumes are supported for alpha release. Administrators +should take care to consider these values when working with raw block devices. +{{< /note >}} + +## Volume Snapshot and Restore Volume from Snapshot Support + +{{< feature-state for_k8s_version="v1.20" state="stable" >}} + +Volume snapshots only support the out-of-tree CSI volume plugins. +For details, see [Volume Snapshots](/docs/concepts/storage/volume-snapshots/). +In-tree volume plugins are deprecated. You can read about the deprecated volume +plugins in the +[Volume Plugin FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md). + +### Create a PersistentVolumeClaim from a Volume Snapshot {#create-persistent-volume-claim-from-volume-snapshot} + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: restore-pvc +spec: + storageClassName: csi-hostpath-sc + dataSource: + name: new-snapshot-test + kind: VolumeSnapshot + apiGroup: snapshot.storage.k8s.io + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 10Gi +``` + +## Volume Cloning + +[Volume Cloning](/docs/concepts/storage/volume-pvc-datasource/) +only available for CSI volume plugins. + +### Create PersistentVolumeClaim from an existing PVC {#create-persistent-volume-claim-from-an-existing-pvc} + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: cloned-pvc +spec: + storageClassName: my-csi-plugin + dataSource: + name: existing-src-pvc-name + kind: PersistentVolumeClaim + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 10Gi +``` + +## Volume populators and data sources + +{{< feature-state for_k8s_version="v1.24" state="beta" >}} + +Kubernetes supports custom volume populators. +To use custom volume populators, you must enable the `AnyVolumeDataSource` +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for +the kube-apiserver and kube-controller-manager. + +Volume populators take advantage of a PVC spec field called `dataSourceRef`. Unlike the +`dataSource` field, which can only contain either a reference to another PersistentVolumeClaim +or to a VolumeSnapshot, the `dataSourceRef` field can contain a reference to any object in the +same namespace, except for core objects other than PVCs. For clusters that have the feature +gate enabled, use of the `dataSourceRef` is preferred over `dataSource`. + +## Cross namespace data sources + +{{< feature-state for_k8s_version="v1.26" state="alpha" >}} + +Kubernetes supports cross namespace volume data sources. +To use cross namespace volume data sources, you must enable the `AnyVolumeDataSource` +and `CrossNamespaceVolumeDataSource` +[feature gates](/docs/reference/command-line-tools-reference/feature-gates/) for +the kube-apiserver and kube-controller-manager. +Also, you must enable the `CrossNamespaceVolumeDataSource` feature gate for the csi-provisioner. + +Enabling the `CrossNamespaceVolumeDataSource` feature gate allows you to specify +a namespace in the dataSourceRef field. + +{{< note >}} +When you specify a namespace for a volume data source, Kubernetes checks for a +ReferenceGrant in the other namespace before accepting the reference. +ReferenceGrant is part of the `gateway.networking.k8s.io` extension APIs. +See [ReferenceGrant](https://gateway-api.sigs.k8s.io/api-types/referencegrant/) +in the Gateway API documentation for details. +This means that you must extend your Kubernetes cluster with at least ReferenceGrant from the +Gateway API before you can use this mechanism. +{{< /note >}} + +## Data source references + +The `dataSourceRef` field behaves almost the same as the `dataSource` field. If one is +specified while the other is not, the API server will give both fields the same value. Neither +field can be changed after creation, and attempting to specify different values for the two +fields will result in a validation error. Therefore the two fields will always have the same +contents. + +There are two differences between the `dataSourceRef` field and the `dataSource` field that +users should be aware of: + +* The `dataSource` field ignores invalid values (as if the field was blank) while the + `dataSourceRef` field never ignores values and will cause an error if an invalid value is + used. Invalid values are any core object (objects with no apiGroup) except for PVCs. +* The `dataSourceRef` field may contain different types of objects, while the `dataSource` field + only allows PVCs and VolumeSnapshots. + +When the `CrossNamespaceVolumeDataSource` feature is enabled, there are additional differences: + +* The `dataSource` field only allows local objects, while the `dataSourceRef` field allows + objects in any namespaces. +* When namespace is specified, `dataSource` and `dataSourceRef` are not synced. + +Users should always use `dataSourceRef` on clusters that have the feature gate enabled, and +fall back to `dataSource` on clusters that do not. It is not necessary to look at both fields +under any circumstance. The duplicated values with slightly different semantics exist only for +backwards compatibility. In particular, a mixture of older and newer controllers are able to +interoperate because the fields are the same. + +### Using volume populators + +Volume populators are {{< glossary_tooltip text="controllers" term_id="controller" >}} that can +create non-empty volumes, where the contents of the volume are determined by a Custom Resource. +Users create a populated volume by referring to a Custom Resource using the `dataSourceRef` field: + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: populated-pvc +spec: + dataSourceRef: + name: example-name + kind: ExampleDataSource + apiGroup: example.storage.k8s.io + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 10Gi +``` + +Because volume populators are external components, attempts to create a PVC that uses one +can fail if not all the correct components are installed. External controllers should generate +events on the PVC to provide feedback on the status of the creation, including warnings if +the PVC cannot be created due to some missing component. + +You can install the alpha [volume data source validator](https://github.com/kubernetes-csi/volume-data-source-validator) +controller into your cluster. That controller generates warning Events on a PVC in the case that no populator +is registered to handle that kind of data source. When a suitable populator is installed for a PVC, it's the +responsibility of that populator controller to report Events that relate to volume creation and issues during +the process. + +### Using a cross-namespace volume data source + +{{< feature-state for_k8s_version="v1.26" state="alpha" >}} + +Create a ReferenceGrant to allow the namespace owner to accept the reference. +You define a populated volume by specifying a cross namespace volume data source +using the `dataSourceRef` field. You must already have a valid ReferenceGrant +in the source namespace: + + ```yaml + apiVersion: gateway.networking.k8s.io/v1beta1 + kind: ReferenceGrant + metadata: + name: allow-ns1-pvc + namespace: default + spec: + from: + - group: "" + kind: PersistentVolumeClaim + namespace: ns1 + to: + - group: snapshot.storage.k8s.io + kind: VolumeSnapshot + name: new-snapshot-demo + ``` + + ```yaml + apiVersion: v1 + kind: PersistentVolumeClaim + metadata: + name: foo-pvc + namespace: ns1 + spec: + storageClassName: example + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 1Gi + dataSourceRef: + apiGroup: snapshot.storage.k8s.io + kind: VolumeSnapshot + name: new-snapshot-demo + namespace: default + volumeMode: Filesystem + ``` + +## Writing Portable Configuration + +If you're writing configuration templates or examples that run on a wide range of clusters +and need persistent storage, it is recommended that you use the following pattern: + +- Include PersistentVolumeClaim objects in your bundle of config (alongside + Deployments, ConfigMaps, etc). +- Do not include PersistentVolume objects in the config, since the user instantiating + the config may not have permission to create PersistentVolumes. +- Give the user the option of providing a storage class name when instantiating + the template. + - If the user provides a storage class name, put that value into the + `persistentVolumeClaim.storageClassName` field. + This will cause the PVC to match the right storage + class if the cluster has StorageClasses enabled by the admin. + - If the user does not provide a storage class name, leave the + `persistentVolumeClaim.storageClassName` field as nil. This will cause a + PV to be automatically provisioned for the user with the default StorageClass + in the cluster. Many cluster environments have a default StorageClass installed, + or administrators can create their own default StorageClass. +- In your tooling, watch for PVCs that are not getting bound after some time + and surface this to the user, as this may indicate that the cluster has no + dynamic storage support (in which case the user should create a matching PV) + or the cluster has no storage system (in which case the user cannot deploy + config requiring PVCs). + +## {{% heading "whatsnext" %}} + +* Learn more about [Creating a PersistentVolume](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume). +* Learn more about [Creating a PersistentVolumeClaim](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim). +* Read the [Persistent Storage design document](https://git.k8s.io/design-proposals-archive/storage/persistent-storage.md). + +### API references {#reference} + +Read about the APIs described in this page: + +* [`PersistentVolume`](/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-v1/) +* [`PersistentVolumeClaim`](/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-claim-v1/) diff --git a/content/fa/docs/concepts/workloads/_index.md b/content/fa/docs/concepts/workloads/_index.md new file mode 100644 index 0000000000000..2d9c17c6cad85 --- /dev/null +++ b/content/fa/docs/concepts/workloads/_index.md @@ -0,0 +1,92 @@ +--- +title: "بارکاری" +weight: 55 +description: > + پادها، کوچکترین شیء محاسباتی قابل استقرار در کوبرنتیز، و انتزاع‌های سطح بالاتری که به شما در اجرای آنها کمک می‌کنند را درک کنید. +no_list: true +card: + title: بارکاری و پادها + name: concepts + weight: 60 +--- + +{{< glossary_definition term_id="workload" length="short" >}} +چه وظیفه شما یک مؤلفه واحد باشد یا چندین مؤلفه که با هم کار می‌کنند، در کوبرنتیز آن را +درون مجموعه‌ای از [_Pods_](/docs/concepts/workloads/pods) اجرا می‌کنید. +در کوبرنتیز، یک Pod نمایانگر مجموعه‌ای از +{{< glossary_tooltip text="Containers" term_id="container" >}} +در حال اجرا روی خوشه شماست. + +Pods در کوبرنتیز یک [چرخه عمر تعریف‌شده](/docs/concepts/workloads/pods/pod-lifecycle/) دارند. +برای مثال، وقتی یک Pod در خوشه شما در حال اجراست، یک خطای بحرانی در +{{< glossary_tooltip text="Node" term_id="node" >}} +که آن Pod روی آن اجرا می‌شود، به معنای از کار افتادن همه Podهای آن Node است. +کوبرنتیز این سطح از خطا را نهایی در نظر می‌گیرد: برای بازیابی باید یک Pod جدید ایجاد کنید، +حتی اگر آن Node بعداً سالم شود. + +با این حال، برای ساده‌تر شدن کار، نیازی نیست هر Pod را مستقیماً مدیریت کنید. +در عوض می‌توانید از _Workload resources_ استفاده کنید که مجموعه‌ای از Pods را به نمایندگی از شما مدیریت می‌کنند. +این منابع {{< glossary_tooltip term_id="controller" text="Controllers" >}} +را پیکربندی می‌کنند تا مطمئن شوند تعداد مناسب و نوع صحیح Pod در حال اجرا باشد، +مطابق با حالتی که شما مشخص کرده‌اید. + +کوبرنتیز چند منبع پیش‌فرض برای Workload فراهم می‌کند: + +* [Deployment](/docs/concepts/workloads/controllers/deployment/) و [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) + (جایگزین منبع قدیمی + {{< glossary_tooltip text="ReplicationController" term_id="replication-controller" >}}). + Deployment برای مدیریت یک بار کاری بدون وضعیت (stateless) در خوشه شما مناسب است، + جایی که هر Pod در این Deployment قابل تعویض بوده و در صورت لزوم می‌توان آن را جایگزین کرد. + +* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) + به شما اجازه می‌دهد یک یا چند Pod مرتبط که به نوعی وضعیت (state) را دنبال می‌کنند، اجرا کنید. + برای مثال، اگر بار کاری شما داده‌ها را به‌صورت مداوم ثبت می‌کند، می‌توانید یک StatefulSet + اجرا کنید که هر Pod را به یک + [PersistentVolume](/docs/concepts/storage/persistent-volumes/) + اختصاص دهد. کد شما، که در Pods متعلق به آن StatefulSet اجرا می‌شود، می‌تواند داده‌ها را + بین سایر Pods در همان StatefulSet تکرار کند تا مقاومت کلی افزایش یابد. + +* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) + Pods‌ای را تعریف می‌کند که خدمات محلی (local) به هر Node ارائه می‌دهند. + هر بار که یک Node جدید به خوشه شما اضافه شود و با مشخصات یک DaemonSet مطابقت داشته باشد، + کنترل‌پلن یک Pod از آن DaemonSet را روی Node جدید زمان‌بندی می‌کند. + هر Pod در یک DaemonSet کاری شبیه یک سرویس سیستم (system daemon) در سرورهای کلاسیک Unix/POSIX انجام می‌دهد. + یک DaemonSet ممکن است برای عملکرد خوشه شما اساسی باشد، مانند افزونه‌ای برای اجرای + [شبکه‌بندی خوشه](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-network-model)، + یا ممکن است به مدیریت Node کمک کند، یا رفتاری اختیاری فراهم کند که پلتفرم کانتینری شما را بهبود دهد. + +* [Job](/docs/concepts/workloads/controllers/job/) و + [CronJob](/docs/concepts/workloads/controllers/cron-jobs/) + روش‌های متفاوتی برای تعریف وظایفی فراهم می‌کنند که تا پایان اجرا شده و سپس متوقف می‌شوند. + می‌توانید از [Job](/docs/concepts/workloads/controllers/job/) + برای تعریف یک وظیفه که یک بار و تا پایان اجرا شود استفاده کنید. + می‌توانید از [CronJob](/docs/concepts/workloads/controllers/cron-jobs/) + برای اجرای مکرر همان Job طبق یک زمان‌بندی مشخص استفاده کنید. + +در بن‌سازه گسترده‌تر کوبرنتیز، می‌توانید منابع workload شخص ثالث را بیابید که رفتارهای اضافی ارائه می‌دهند. +با استفاده از یک +[Custom Resource Definition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)، +می‌توانید منبع workload شخص ثالثی اضافه کنید اگر به رفتار خاصی نیاز دارید که در هسته کوبرنتیز موجود نیست. +برای مثال، اگر می‌خواستید گروهی از Pods را برای برنامه‌تان اجرا کنید اما کار را تا زمانی که _همه_ Pods در دسترس نباشند متوقف کنید +(شاید برای بعضی کارهای توزیع‌شده با توان بالا)، +می‌توانید افزونه‌ای پیاده‌سازی یا نصب کنید که آن ویژگی را فراهم آورد. + +## {{% heading "whatsnext" %}} + +هم‌چنین علاوه بر مطالعه هر نوع API برای مدیریت Workload، می‌توانید یاد بگیرید چگونه کارهای خاص را انجام دهید: + +* [اجرای یک برنامه بدون وضعیت با استفاده از Deployment](/docs/tasks/run-application/run-stateless-application-deployment/) +* اجرای یک برنامه با وضعیت به‌صورت [یک نمونه واحد](/docs/tasks/run-application/run-single-instance-stateful-application/) + یا به‌صورت [مجموعه تکرارشده](/docs/tasks/run-application/run-replicated-stateful-application/) +* [اجرای وظایف خودکار با CronJob](/docs/tasks/job/automated-tasks-with-cron-jobs/) + +برای آشنایی با مکانیزم‌های کوبرنتیز برای جدا کردن کد از پیکربندی، به [Configuration](/docs/concepts/configuration/) مراجعه کنید. + +دو مفهوم پشتیبان وجود دارند که زمینه نحوه مدیریت Pods برای برنامه‌ها توسط کوبرنتیز را توضیح می‌دهند: +* [Garbage collection](/docs/concepts/architecture/garbage-collection/) اشیاء را پس از حذف _منبع مالک_ آن‌ها از بین می‌برد. +* [_time-to-live after finished_ controller](/docs/concepts/workloads/controllers/ttlafterfinished/) + پس از گذشت زمان مشخصی از تکمیل Jobs، آن‌ها را حذف می‌کند. + +پس از اجرای برنامه شما، ممکن است بخواهید آن را به‌صورت یک [Service](/docs/concepts/services-networking/service/) +در اینترنت در دسترس قرار دهید یا برای برنامه‌های وب فقط با استفاده از یک [Ingress](/docs/concepts/services-networking/ingress/) منتشر کنید. + diff --git a/content/fa/docs/concepts/workloads/autoscaling.md b/content/fa/docs/concepts/workloads/autoscaling.md new file mode 100644 index 0000000000000..6e3e28e1457c8 --- /dev/null +++ b/content/fa/docs/concepts/workloads/autoscaling.md @@ -0,0 +1,129 @@ +--- +title: مقیاس‌بندی خودکار بارهای کاری +description: >- + با مقیاس‌بندی خودکار، می‌توانید بارهای کاری خود را به طور خودکار به یک روش یا روش دیگر به‌روزرسانی کنید. این به خوشه شما اجازه می‌دهد تا به تغییرات در تقاضای منابع، انعطاف‌پذیرتر و کارآمدتر واکنش نشان دهد. +content_type: concept +weight: 40 +--- + + + +در Kubernetes، می‌توانید بسته به تقاضای فعلی منابع، حجم کار را _مقیاس_ کنید. + +این به خوشه شما اجازه می‌دهد تا به تغییرات در تقاضای منابع، انعطاف‌پذیرتر و کارآمدتر واکنش نشان دهد. + +هنگامی که یک حجم کار را مقیاس‌بندی می‌کنید، می‌توانید تعداد کپی‌های مدیریت‌شده توسط حجم کار را افزایش یا کاهش دهید، یا منابع موجود برای کپی‌های موجود را تنظیم کنید. + +رویکرد اول به عنوان _مقیاس‌بندی افقی_ و رویکرد دوم به عنوان _مقیاس‌بندی عمودی_ شناخته می‌شود. + +بسته به مورد استفاده شما، روش‌های دستی و خودکار برای مقیاس‌بندی حجم کار شما وجود دارد. + + + +## مقیاس‌بندی دستی بارهای کاری + +کوبرنتیز از _مقیاس‌بندی دستی_ بارهای کاری پشتیبانی می‌کند. مقیاس‌بندی افقی را می‌توانید +با استفاده از ابزار `kubectl` انجام دهید. +برای مقیاس‌بندی عمودی، باید تعریف منبع بار کاری خود را _patch_ کنید. + +مثال هر دو استراتژی را در ادامه ببینید: + +- **مقیاس‌بندی افقی**: [اجرای چند نمونه از برنامه شما](/docs/tutorials/kubernetes-basics/scale/scale-intro/) +- **مقیاس‌بندی عمودی**: [تغییر اندازه منابع CPU و حافظه اختصاص‌یافته به کانتینرها](/docs/tasks/configure-pod-container/resize-container-resources) + +## مقیاس‌بندی خودکار بارهای کاری + +کوبرنتیز همچنین از _مقیاس‌بندی خودکار_ بارهای کاری پشتیبانی می‌کند که موضوع این صفحه است. + +مفهوم _Autoscaling_ در کوبرنتیز به توانایی به‌روزرسانی خودکار یک +شیٔی که مجموعه‌ای از Pods را مدیریت می‌کند (برای مثال +{{< glossary_tooltip text="Deployment" term_id="deployment" >}}) اشاره دارد. + +### مقیاس‌بندی بارهای کاری به‌صورت افقی + +در کوبرنتیز، می‌توانید به‌صورت خودکار بار کاری را به‌صورت افقی با استفاده از _HorizontalPodAutoscaler_ مقیاس‌بندی کنید. + +این قابلیت به‌عنوان یک منبع API کوبرنتیز و یک {{< glossary_tooltip text="controller" term_id="controller" >}} پیاده‌سازی شده و به‌طور دوره‌ای تعداد {{< glossary_tooltip text="replicas" term_id="replica" >}} را در یک بار کاری تنظیم می‌کند تا با مصرف منابع مشاهده‌شده مانند استفاده از CPU یا حافظه هم‌خوانی داشته باشد. + +یک [آموزش گام‌به‌گام](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough) برای پیکربندی _HorizontalPodAutoscaler_ برای یک Deployment وجود دارد. + +### مقیاس‌بندی بارهای کاری به‌صورت عمودی + +{{< feature-state for_k8s_version="v1.25" state="stable" >}} + +می‌توانید به‌صورت خودکار بار کاری را به‌صورت عمودی با استفاده از _VerticalPodAutoscaler_ مقیاس‌بندی کنید. بر خلاف HPA، VPA به‌طور پیش‌فرض همراه کوبرنتیز عرضه نمی‌شود، بلکه یک پروژه مستقل است که در [GitHub](https://github.com/kubernetes/autoscaler/tree/9f87b78df0f1d6e142234bb32e8acbd71295585a/vertical-pod-autoscaler) در دسترس قرار دارد. + +پس از نصب، می‌توانید برای بارهای کاری خود {{< glossary_tooltip text="CustomResourceDefinitions" term_id="customresourcedefinition" >}} (CRD) ایجاد کنید که تعریف می‌کنند _چگونه_ و _چه زمانی_ منابع نسخه‌های مدیریت‌شده را مقیاس‌بندی کنند. + +{{< note >}} +برای کارکرد VPA نیاز است که [Metrics Server](https://github.com/kubernetes-sigs/metrics-server) در خوشه شما نصب شده باشد. +{{< /note >}} + +در حال حاضر، VPA می‌تواند در چهار حالت مختلف کار کند: + +{{< table caption="حالت‌های مختلف VPA" >}} +حالت | توضیحات +:----|:----------- +`Auto` | در حال حاضر `Recreate`. ممکن است در آینده به به‌روزرسانی درجا (in-place) تغییر یابد. +`Recreate` | VPA درخواست‌های منابع را هنگام ایجاد پاد تنظیم می‌کند و همچنین با بیرون‌کردن پادهای موجود، آن‌ها را به‌روزرسانی می‌کند وقتی درخواست منابع به‌طور قابل توجهی با پیشنهاد جدید متفاوت باشد. +`Initial` | VPA تنها هنگام ایجاد پاد درخواست‌های منابع را تنظیم می‌کند و پس از آن هرگز آن‌ها را تغییر نمی‌دهد. +`Off` | VPA به‌صورت خودکار نیازمندی‌های منابع پادها را تغییر نمی‌دهد. پیشنهادها محاسبه می‌شوند و می‌توان آن‌ها را در شی VPA بررسی کرد. +{{< /table >}} + +#### مقیاس‌بندی عمودی پاد درجا + +{{< feature-state feature_gate_name="InPlacePodVerticalScaling" >}} + +از زمان Kubernetes {{< skew currentVersion >}}، VPA از تغییر اندازه پادها درجا پشتیبانی نمی‌کند، اما این ادغام در دست کار است. +برای تغییر اندازه دستی پادها درجا، به [Resize Container Resources In-Place](/docs/tasks/configure-pod-container/resize-container-resources/) مراجعه کنید. + +### مقیاس‌بندی خودکار بر اساس اندازه خوشه + +برای بارهای کاری که نیاز به مقیاس‌بندی بر اساس اندازه خوشه دارند (برای مثال `cluster-dns` یا سایر اجزای سیستمی)، می‌توانید از +[_Cluster Proportional Autoscaler_](https://github.com/kubernetes-sigs/cluster-proportional-autoscaler) استفاده کنید. +مانند VPA، این ابزار بخشی از هسته کوبرنتیز نیست و به‌صورت یک پروژه مستقل در GitHub میزبانی می‌شود. + +Cluster Proportional Autoscaler تعداد {{< glossary_tooltip text="Nodes" term_id="node" >}} قابل زمان‌بندی و هسته‌ها را پایش کرده و +تعداد Replicaهای بار کاری هدف را بر همان اساس تنظیم می‌کند. + +اگر قرار است تعداد Replicaها ثابت بماند، می‌توانید بارهای کاری خود را به‌صورت عمودی بر اساس اندازه خوشه مقیاس دهید +با استفاده از [_Cluster Proportional Vertical Autoscaler_](https://github.com/kubernetes-sigs/cluster-proportional-vertical-autoscaler). +این پروژه **در حال حاضر در مرحله بتا** قرار دارد و در GitHub در دسترس است. + +در حالی که Cluster Proportional Autoscaler تعداد Replicaهای یک بار کاری را مقیاس می‌دهد، +Cluster Proportional Vertical Autoscaler درخواست‌های منابع (برای مثال در یک Deployment یا DaemonSet) را +بر اساس تعداد Nodes و/یا هسته‌ها در خوشه تنظیم می‌کند. + +### مقیاس‌بندی خودکار مبتنی بر رویداد + +همچنین امکان مقیاس‌بندی بارهای کاری بر اساس رویدادها وجود دارد، برای مثال با استفاده از +[_Kubernetes Event Driven Autoscaler_ (**KEDA**)](https://keda.sh/). + +KEDA یک پروژه فارغ‌التحصیل‌شده از CNCF است که به شما امکان می‌دهد بارهای کاری خود را +بر اساس تعداد رویدادهای قابل پردازش—مثلاً تعداد پیام‌ها در یک صف—مقیاس دهید. +برای منابع رویداد مختلف، آداپتورهای متنوعی در دسترس هستند. + +### مقیاس‌بندی خودکار بر اساس زمان‌بندی‌ها + +استراتژی دیگری برای مقیاس‌بندی بارهای کاری شما این است که عملیات مقیاس‌بندی را **زمان‌بندی** کنید، برای مثال جهت کاهش مصرف منابع در ساعات کم‌بار. + +مشابه مقیاس‌بندی خودکار مبتنی بر رویداد، این رفتار را می‌توان با استفاده از KEDA همراه با +[`Cron` scaler](https://keda.sh/docs/latest/scalers/cron/) +دستیابی کرد. +`Cron` scaler به شما امکان می‌دهد زمان‌بندی‌ها (و مناطق زمانی) را برای مقیاس دادن بارهای کاری خود به داخل یا خارج تعریف کنید. + +## مقیاس‌بندی زیرساخت خوشه + +اگر مقیاس‌بندی بارهای کاری برای رفع نیازهای شما کافی نیست، می‌توانید زیرساخت خوشه خود را نیز مقیاس دهید. + +مقیاس‌بندی زیرساخت خوشه به‌طور معمول افزودن یا حذف {{< glossary_tooltip text="nodes" term_id="node" >}} را شامل می‌شود. +برای اطلاعات بیشتر، [Node autoscaling](/docs/concepts/cluster-administration/node-autoscaling/) را ببینید. + +## {{% heading "whatsnext" %}} + +- یادگیری بیشتر درباره مقیاس‌بندی افقی + - [مقیاس یک StatefulSet](/docs/tasks/run-application/scale-stateful-set/) + - [آموزش گام‌به‌گام HorizontalPodAutoscaler](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) +- [تغییر اندازه منابع کانتینر به‌صورت درجا](/docs/tasks/configure-pod-container/resize-container-resources/) +- [مقیاس‌بندی خودکار سرویس DNS در خوشه](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/) +- آشنایی با [Node autoscaling](/docs/concepts/cluster-administration/node-autoscaling/) diff --git a/content/fa/docs/concepts/workloads/controllers/deployment.md b/content/fa/docs/concepts/workloads/controllers/deployment.md new file mode 100644 index 0000000000000..c312037f23dde --- /dev/null +++ b/content/fa/docs/concepts/workloads/controllers/deployment.md @@ -0,0 +1,1367 @@ +--- +reviewers: +- xirehat +title: Deployments +api_metadata: +- apiVersion: "apps/v1" + kind: "Deployment" +feature: + title: انتشار و انتشار مجدد خودکار + description: > + کوبرنتیز به تدریج تغییرات را در برنامه یا پیکربندی آن اعمال می‌کند، ضمن اینکه سلامت برنامه را رصد می‌کند تا مطمئن شود که همه نمونه‌های شما را به طور همزمان از بین نمی‌برد. اگر مشکلی پیش بیاید، کوبرنتیز تغییر را برای شما به حالت اولیه برمی‌گرداند. از یک بن‌سازه رو به رشد از راه‌حل‌های استقرار بهره‌مند شوید. +description: >- + یک Deployment مجموعه‌ای از Podها را برای اجرای یک بار کاری برنامه مدیریت می‌کند، که معمولاً برنامه‌ای است که وضعیت (state) را حفظ نمی‌کند. +content_type: concept +weight: 10 +hide_summary: true # Listed separately in section index +--- + + + +A _Deployment_ provides declarative updates for {{< glossary_tooltip text="Pods" term_id="pod" >}} and +{{< glossary_tooltip term_id="replica-set" text="ReplicaSets" >}}. + +You describe a _desired state_ in a Deployment, and the Deployment {{< glossary_tooltip term_id="controller" >}} changes the actual state to the desired state at a controlled rate. You can define Deployments to create new ReplicaSets, or to remove existing Deployments and adopt all their resources with new Deployments. + +{{< note >}} +Do not manage ReplicaSets owned by a Deployment. Consider opening an issue in the main Kubernetes repository if your use case is not covered below. +{{< /note >}} + + + +## Use Case + +The following are typical use cases for Deployments: + +* [Create a Deployment to rollout a ReplicaSet](#creating-a-deployment). The ReplicaSet creates Pods in the background. Check the status of the rollout to see if it succeeds or not. +* [Declare the new state of the Pods](#updating-a-deployment) by updating the PodTemplateSpec of the Deployment. A new ReplicaSet is created and the Deployment manages moving the Pods from the old ReplicaSet to the new one at a controlled rate. Each new ReplicaSet updates the revision of the Deployment. +* [Rollback to an earlier Deployment revision](#rolling-back-a-deployment) if the current state of the Deployment is not stable. Each rollback updates the revision of the Deployment. +* [Scale up the Deployment to facilitate more load](#scaling-a-deployment). +* [Pause the rollout of a Deployment](#pausing-and-resuming-a-deployment) to apply multiple fixes to its PodTemplateSpec and then resume it to start a new rollout. +* [Use the status of the Deployment](#deployment-status) as an indicator that a rollout has stuck. +* [Clean up older ReplicaSets](#clean-up-policy) that you don't need anymore. + +## Creating a Deployment + +The following is an example of a Deployment. It creates a ReplicaSet to bring up three `nginx` Pods: + +{{% code_sample file="controllers/nginx-deployment.yaml" %}} + +In this example: + +* A Deployment named `nginx-deployment` is created, indicated by the + `.metadata.name` field. This name will become the basis for the ReplicaSets + and Pods which are created later. See [Writing a Deployment Spec](#writing-a-deployment-spec) + for more details. +* The Deployment creates a ReplicaSet that creates three replicated Pods, indicated by the `.spec.replicas` field. +* The `.spec.selector` field defines how the created ReplicaSet finds which Pods to manage. + In this case, you select a label that is defined in the Pod template (`app: nginx`). + However, more sophisticated selection rules are possible, + as long as the Pod template itself satisfies the rule. + + {{< note >}} + The `.spec.selector.matchLabels` field is a map of {key,value} pairs. + A single {key,value} in the `matchLabels` map is equivalent to an element of `matchExpressions`, + whose `key` field is "key", the `operator` is "In", and the `values` array contains only "value". + All of the requirements, from both `matchLabels` and `matchExpressions`, must be satisfied in order to match. + {{< /note >}} + +* The `.spec.template` field contains the following sub-fields: + * The Pods are labeled `app: nginx`using the `.metadata.labels` field. + * The Pod template's specification, or `.spec` field, indicates that + the Pods run one container, `nginx`, which runs the `nginx` + [Docker Hub](https://hub.docker.com/) image at version 1.14.2. + * Create one container and name it `nginx` using the `.spec.containers[0].name` field. + +Before you begin, make sure your Kubernetes cluster is up and running. +Follow the steps given below to create the above Deployment: + +1. Create the Deployment by running the following command: + + ```shell + kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml + ``` + +2. Run `kubectl get deployments` to check if the Deployment was created. + + If the Deployment is still being created, the output is similar to the following: + ``` + NAME READY UP-TO-DATE AVAILABLE AGE + nginx-deployment 0/3 0 0 1s + ``` + When you inspect the Deployments in your cluster, the following fields are displayed: + * `NAME` lists the names of the Deployments in the namespace. + * `READY` displays how many replicas of the application are available to your users. It follows the pattern ready/desired. + * `UP-TO-DATE` displays the number of replicas that have been updated to achieve the desired state. + * `AVAILABLE` displays how many replicas of the application are available to your users. + * `AGE` displays the amount of time that the application has been running. + + Notice how the number of desired replicas is 3 according to `.spec.replicas` field. + +3. To see the Deployment rollout status, run `kubectl rollout status deployment/nginx-deployment`. + + The output is similar to: + ``` + Waiting for rollout to finish: 2 out of 3 new replicas have been updated... + deployment "nginx-deployment" successfully rolled out + ``` + +4. Run the `kubectl get deployments` again a few seconds later. + The output is similar to this: + ``` + NAME READY UP-TO-DATE AVAILABLE AGE + nginx-deployment 3/3 3 3 18s + ``` + Notice that the Deployment has created all three replicas, and all replicas are up-to-date (they contain the latest Pod template) and available. + +5. To see the ReplicaSet (`rs`) created by the Deployment, run `kubectl get rs`. The output is similar to this: + ``` + NAME DESIRED CURRENT READY AGE + nginx-deployment-75675f5897 3 3 3 18s + ``` + ReplicaSet output shows the following fields: + + * `NAME` lists the names of the ReplicaSets in the namespace. + * `DESIRED` displays the desired number of _replicas_ of the application, which you define when you create the Deployment. This is the _desired state_. + * `CURRENT` displays how many replicas are currently running. + * `READY` displays how many replicas of the application are available to your users. + * `AGE` displays the amount of time that the application has been running. + + Notice that the name of the ReplicaSet is always formatted as + `[DEPLOYMENT-NAME]-[HASH]`. This name will become the basis for the Pods + which are created. + + The `HASH` string is the same as the `pod-template-hash` label on the ReplicaSet. + +6. To see the labels automatically generated for each Pod, run `kubectl get pods --show-labels`. + The output is similar to: + ``` + NAME READY STATUS RESTARTS AGE LABELS + nginx-deployment-75675f5897-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=75675f5897 + nginx-deployment-75675f5897-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=75675f5897 + nginx-deployment-75675f5897-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=75675f5897 + ``` + The created ReplicaSet ensures that there are three `nginx` Pods. + +{{< note >}} +You must specify an appropriate selector and Pod template labels in a Deployment +(in this case, `app: nginx`). + +Do not overlap labels or selectors with other controllers (including other Deployments and StatefulSets). Kubernetes doesn't stop you from overlapping, and if multiple controllers have overlapping selectors those controllers might conflict and behave unexpectedly. +{{< /note >}} + +### Pod-template-hash label + +{{< caution >}} +Do not change this label. +{{< /caution >}} + +The `pod-template-hash` label is added by the Deployment controller to every ReplicaSet that a Deployment creates or adopts. + +This label ensures that child ReplicaSets of a Deployment do not overlap. It is generated by hashing the `PodTemplate` of the ReplicaSet and using the resulting hash as the label value that is added to the ReplicaSet selector, Pod template labels, +and in any existing Pods that the ReplicaSet might have. + +## Updating a Deployment + +{{< note >}} +A Deployment's rollout is triggered if and only if the Deployment's Pod template (that is, `.spec.template`) +is changed, for example if the labels or container images of the template are updated. Other updates, such as scaling the Deployment, do not trigger a rollout. +{{< /note >}} + +Follow the steps given below to update your Deployment: + +1. Let's update the nginx Pods to use the `nginx:1.16.1` image instead of the `nginx:1.14.2` image. + + ```shell + kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1 + ``` + + or use the following command: + + ```shell + kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 + ``` + where `deployment/nginx-deployment` indicates the Deployment, + `nginx` indicates the Container the update will take place and + `nginx:1.16.1` indicates the new image and its tag. + + + The output is similar to: + + ``` + deployment.apps/nginx-deployment image updated + ``` + + Alternatively, you can `edit` the Deployment and change `.spec.template.spec.containers[0].image` from `nginx:1.14.2` to `nginx:1.16.1`: + + ```shell + kubectl edit deployment/nginx-deployment + ``` + + The output is similar to: + + ``` + deployment.apps/nginx-deployment edited + ``` + +2. To see the rollout status, run: + + ```shell + kubectl rollout status deployment/nginx-deployment + ``` + + The output is similar to this: + + ``` + Waiting for rollout to finish: 2 out of 3 new replicas have been updated... + ``` + + or + + ``` + deployment "nginx-deployment" successfully rolled out + ``` + +Get more details on your updated Deployment: + +* After the rollout succeeds, you can view the Deployment by running `kubectl get deployments`. + The output is similar to this: + + ``` + NAME READY UP-TO-DATE AVAILABLE AGE + nginx-deployment 3/3 3 3 36s + ``` + +* Run `kubectl get rs` to see that the Deployment updated the Pods by creating a new ReplicaSet and scaling it +up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas. + + ```shell + kubectl get rs + ``` + + The output is similar to this: + ``` + NAME DESIRED CURRENT READY AGE + nginx-deployment-1564180365 3 3 3 6s + nginx-deployment-2035384211 0 0 0 36s + ``` + +* Running `get pods` should now show only the new Pods: + + ```shell + kubectl get pods + ``` + + The output is similar to this: + ``` + NAME READY STATUS RESTARTS AGE + nginx-deployment-1564180365-khku8 1/1 Running 0 14s + nginx-deployment-1564180365-nacti 1/1 Running 0 14s + nginx-deployment-1564180365-z9gth 1/1 Running 0 14s + ``` + + Next time you want to update these Pods, you only need to update the Deployment's Pod template again. + + Deployment ensures that only a certain number of Pods are down while they are being updated. By default, + it ensures that at least 75% of the desired number of Pods are up (25% max unavailable). + + Deployment also ensures that only a certain number of Pods are created above the desired number of Pods. + By default, it ensures that at most 125% of the desired number of Pods are up (25% max surge). + + For example, if you look at the above Deployment closely, you will see that it first creates a new Pod, + then deletes an old Pod, and creates another new one. It does not kill old Pods until a sufficient number of + new Pods have come up, and does not create new Pods until a sufficient number of old Pods have been killed. + It makes sure that at least 3 Pods are available and that at max 4 Pods in total are available. In case of + a Deployment with 4 replicas, the number of Pods would be between 3 and 5. + +* Get details of your Deployment: + ```shell + kubectl describe deployments + ``` + The output is similar to this: + ``` + Name: nginx-deployment + Namespace: default + CreationTimestamp: Thu, 30 Nov 2017 10:56:25 +0000 + Labels: app=nginx + Annotations: deployment.kubernetes.io/revision=2 + Selector: app=nginx + Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable + StrategyType: RollingUpdate + MinReadySeconds: 0 + RollingUpdateStrategy: 25% max unavailable, 25% max surge + Pod Template: + Labels: app=nginx + Containers: + nginx: + Image: nginx:1.16.1 + Port: 80/TCP + Environment: + Mounts: + Volumes: + Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True NewReplicaSetAvailable + OldReplicaSets: + NewReplicaSet: nginx-deployment-1564180365 (3/3 replicas created) + Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal ScalingReplicaSet 2m deployment-controller Scaled up replica set nginx-deployment-2035384211 to 3 + Normal ScalingReplicaSet 24s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 1 + Normal ScalingReplicaSet 22s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 2 + Normal ScalingReplicaSet 22s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 2 + Normal ScalingReplicaSet 19s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 1 + Normal ScalingReplicaSet 19s deployment-controller Scaled up replica set nginx-deployment-1564180365 to 3 + Normal ScalingReplicaSet 14s deployment-controller Scaled down replica set nginx-deployment-2035384211 to 0 + ``` + Here you see that when you first created the Deployment, it created a ReplicaSet (nginx-deployment-2035384211) + and scaled it up to 3 replicas directly. When you updated the Deployment, it created a new ReplicaSet + (nginx-deployment-1564180365) and scaled it up to 1 and waited for it to come up. Then it scaled down the old ReplicaSet + to 2 and scaled up the new ReplicaSet to 2 so that at least 3 Pods were available and at most 4 Pods were created at all times. + It then continued scaling up and down the new and the old ReplicaSet, with the same rolling update strategy. + Finally, you'll have 3 available replicas in the new ReplicaSet, and the old ReplicaSet is scaled down to 0. + +{{< note >}} +Kubernetes doesn't count terminating Pods when calculating the number of `availableReplicas`, which must be between +`replicas - maxUnavailable` and `replicas + maxSurge`. As a result, you might notice that there are more Pods than +expected during a rollout, and that the total resources consumed by the Deployment is more than `replicas + maxSurge` +until the `terminationGracePeriodSeconds` of the terminating Pods expires. +{{< /note >}} + +### Rollover (aka multiple updates in-flight) + +Each time a new Deployment is observed by the Deployment controller, a ReplicaSet is created to bring up +the desired Pods. If the Deployment is updated, the existing ReplicaSet that controls Pods whose labels +match `.spec.selector` but whose template does not match `.spec.template` are scaled down. Eventually, the new +ReplicaSet is scaled to `.spec.replicas` and all old ReplicaSets is scaled to 0. + +If you update a Deployment while an existing rollout is in progress, the Deployment creates a new ReplicaSet +as per the update and start scaling that up, and rolls over the ReplicaSet that it was scaling up previously +-- it will add it to its list of old ReplicaSets and start scaling it down. + +For example, suppose you create a Deployment to create 5 replicas of `nginx:1.14.2`, +but then update the Deployment to create 5 replicas of `nginx:1.16.1`, when only 3 +replicas of `nginx:1.14.2` had been created. In that case, the Deployment immediately starts +killing the 3 `nginx:1.14.2` Pods that it had created, and starts creating +`nginx:1.16.1` Pods. It does not wait for the 5 replicas of `nginx:1.14.2` to be created +before changing course. + +### Label selector updates + +It is generally discouraged to make label selector updates and it is suggested to plan your selectors up front. +In any case, if you need to perform a label selector update, exercise great caution and make sure you have grasped +all of the implications. + +{{< note >}} +In API version `apps/v1`, a Deployment's label selector is immutable after it gets created. +{{< /note >}} + +* Selector additions require the Pod template labels in the Deployment spec to be updated with the new label too, +otherwise a validation error is returned. This change is a non-overlapping one, meaning that the new selector does +not select ReplicaSets and Pods created with the old selector, resulting in orphaning all old ReplicaSets and +creating a new ReplicaSet. +* Selector updates changes the existing value in a selector key -- result in the same behavior as additions. +* Selector removals removes an existing key from the Deployment selector -- do not require any changes in the +Pod template labels. Existing ReplicaSets are not orphaned, and a new ReplicaSet is not created, but note that the +removed label still exists in any existing Pods and ReplicaSets. + +## Rolling Back a Deployment + +Sometimes, you may want to rollback a Deployment; for example, when the Deployment is not stable, such as crash looping. +By default, all of the Deployment's rollout history is kept in the system so that you can rollback anytime you want +(you can change that by modifying revision history limit). + +{{< note >}} +A Deployment's revision is created when a Deployment's rollout is triggered. This means that the +new revision is created if and only if the Deployment's Pod template (`.spec.template`) is changed, +for example if you update the labels or container images of the template. Other updates, such as scaling the Deployment, +do not create a Deployment revision, so that you can facilitate simultaneous manual- or auto-scaling. +This means that when you roll back to an earlier revision, only the Deployment's Pod template part is +rolled back. +{{< /note >}} + +* Suppose that you made a typo while updating the Deployment, by putting the image name as `nginx:1.161` instead of `nginx:1.16.1`: + + ```shell + kubectl set image deployment/nginx-deployment nginx=nginx:1.161 + ``` + + The output is similar to this: + ``` + deployment.apps/nginx-deployment image updated + ``` + +* The rollout gets stuck. You can verify it by checking the rollout status: + + ```shell + kubectl rollout status deployment/nginx-deployment + ``` + + The output is similar to this: + ``` + Waiting for rollout to finish: 1 out of 3 new replicas have been updated... + ``` + +* Press Ctrl-C to stop the above rollout status watch. For more information on stuck rollouts, +[read more here](#deployment-status). + +* You see that the number of old replicas (adding the replica count from + `nginx-deployment-1564180365` and `nginx-deployment-2035384211`) is 3, and the number of + new replicas (from `nginx-deployment-3066724191`) is 1. + + ```shell + kubectl get rs + ``` + + The output is similar to this: + ``` + NAME DESIRED CURRENT READY AGE + nginx-deployment-1564180365 3 3 3 25s + nginx-deployment-2035384211 0 0 0 36s + nginx-deployment-3066724191 1 1 0 6s + ``` + +* Looking at the Pods created, you see that 1 Pod created by new ReplicaSet is stuck in an image pull loop. + + ```shell + kubectl get pods + ``` + + The output is similar to this: + ``` + NAME READY STATUS RESTARTS AGE + nginx-deployment-1564180365-70iae 1/1 Running 0 25s + nginx-deployment-1564180365-jbqqo 1/1 Running 0 25s + nginx-deployment-1564180365-hysrc 1/1 Running 0 25s + nginx-deployment-3066724191-08mng 0/1 ImagePullBackOff 0 6s + ``` + + {{< note >}} + The Deployment controller stops the bad rollout automatically, and stops scaling up the new ReplicaSet. This depends on the rollingUpdate parameters (`maxUnavailable` specifically) that you have specified. Kubernetes by default sets the value to 25%. + {{< /note >}} + +* Get the description of the Deployment: + ```shell + kubectl describe deployment + ``` + + The output is similar to this: + ``` + Name: nginx-deployment + Namespace: default + CreationTimestamp: Tue, 15 Mar 2016 14:48:04 -0700 + Labels: app=nginx + Selector: app=nginx + Replicas: 3 desired | 1 updated | 4 total | 3 available | 1 unavailable + StrategyType: RollingUpdate + MinReadySeconds: 0 + RollingUpdateStrategy: 25% max unavailable, 25% max surge + Pod Template: + Labels: app=nginx + Containers: + nginx: + Image: nginx:1.161 + Port: 80/TCP + Host Port: 0/TCP + Environment: + Mounts: + Volumes: + Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True ReplicaSetUpdated + OldReplicaSets: nginx-deployment-1564180365 (3/3 replicas created) + NewReplicaSet: nginx-deployment-3066724191 (1/1 replicas created) + Events: + FirstSeen LastSeen Count From SubObjectPath Type Reason Message + --------- -------- ----- ---- ------------- -------- ------ ------- + 1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-2035384211 to 3 + 22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 1 + 22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 2 + 22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 2 + 21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 1 + 21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 3 + 13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 0 + 13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-3066724191 to 1 + ``` + + To fix this, you need to rollback to a previous revision of Deployment that is stable. + +### Checking Rollout History of a Deployment + +Follow the steps given below to check the rollout history: + +1. First, check the revisions of this Deployment: + ```shell + kubectl rollout history deployment/nginx-deployment + ``` + The output is similar to this: + ``` + deployments "nginx-deployment" + REVISION CHANGE-CAUSE + 1 kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml + 2 kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 + 3 kubectl set image deployment/nginx-deployment nginx=nginx:1.161 + ``` + + `CHANGE-CAUSE` is copied from the Deployment annotation `kubernetes.io/change-cause` to its revisions upon creation. You can specify the`CHANGE-CAUSE` message by: + + * Annotating the Deployment with `kubectl annotate deployment/nginx-deployment kubernetes.io/change-cause="image updated to 1.16.1"` + * Manually editing the manifest of the resource. + +2. To see the details of each revision, run: + ```shell + kubectl rollout history deployment/nginx-deployment --revision=2 + ``` + + The output is similar to this: + ``` + deployments "nginx-deployment" revision 2 + Labels: app=nginx + pod-template-hash=1159050644 + Annotations: kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 + Containers: + nginx: + Image: nginx:1.16.1 + Port: 80/TCP + QoS Tier: + cpu: BestEffort + memory: BestEffort + Environment Variables: + No volumes. + ``` + +### Rolling Back to a Previous Revision +Follow the steps given below to rollback the Deployment from the current version to the previous version, which is version 2. + +1. Now you've decided to undo the current rollout and rollback to the previous revision: + ```shell + kubectl rollout undo deployment/nginx-deployment + ``` + + The output is similar to this: + ``` + deployment.apps/nginx-deployment rolled back + ``` + Alternatively, you can rollback to a specific revision by specifying it with `--to-revision`: + + ```shell + kubectl rollout undo deployment/nginx-deployment --to-revision=2 + ``` + + The output is similar to this: + ``` + deployment.apps/nginx-deployment rolled back + ``` + + For more details about rollout related commands, read [`kubectl rollout`](/docs/reference/generated/kubectl/kubectl-commands#rollout). + + The Deployment is now rolled back to a previous stable revision. As you can see, a `DeploymentRollback` event + for rolling back to revision 2 is generated from Deployment controller. + +2. Check if the rollback was successful and the Deployment is running as expected, run: + ```shell + kubectl get deployment nginx-deployment + ``` + + The output is similar to this: + ``` + NAME READY UP-TO-DATE AVAILABLE AGE + nginx-deployment 3/3 3 3 30m + ``` +3. Get the description of the Deployment: + ```shell + kubectl describe deployment nginx-deployment + ``` + The output is similar to this: + ``` + Name: nginx-deployment + Namespace: default + CreationTimestamp: Sun, 02 Sep 2018 18:17:55 -0500 + Labels: app=nginx + Annotations: deployment.kubernetes.io/revision=4 + kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 + Selector: app=nginx + Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable + StrategyType: RollingUpdate + MinReadySeconds: 0 + RollingUpdateStrategy: 25% max unavailable, 25% max surge + Pod Template: + Labels: app=nginx + Containers: + nginx: + Image: nginx:1.16.1 + Port: 80/TCP + Host Port: 0/TCP + Environment: + Mounts: + Volumes: + Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True NewReplicaSetAvailable + OldReplicaSets: + NewReplicaSet: nginx-deployment-c4747d96c (3/3 replicas created) + Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal ScalingReplicaSet 12m deployment-controller Scaled up replica set nginx-deployment-75675f5897 to 3 + Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 1 + Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 2 + Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 2 + Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 1 + Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-c4747d96c to 3 + Normal ScalingReplicaSet 11m deployment-controller Scaled down replica set nginx-deployment-75675f5897 to 0 + Normal ScalingReplicaSet 11m deployment-controller Scaled up replica set nginx-deployment-595696685f to 1 + Normal DeploymentRollback 15s deployment-controller Rolled back deployment "nginx-deployment" to revision 2 + Normal ScalingReplicaSet 15s deployment-controller Scaled down replica set nginx-deployment-595696685f to 0 + ``` + +## Scaling a Deployment + +You can scale a Deployment by using the following command: + +```shell +kubectl scale deployment/nginx-deployment --replicas=10 +``` +The output is similar to this: +``` +deployment.apps/nginx-deployment scaled +``` + +Assuming [horizontal Pod autoscaling](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) is enabled +in your cluster, you can set up an autoscaler for your Deployment and choose the minimum and maximum number of +Pods you want to run based on the CPU utilization of your existing Pods. + +```shell +kubectl autoscale deployment/nginx-deployment --min=10 --max=15 --cpu-percent=80 +``` +The output is similar to this: +``` +deployment.apps/nginx-deployment scaled +``` + +### Proportional scaling + +RollingUpdate Deployments support running multiple versions of an application at the same time. When you +or an autoscaler scales a RollingUpdate Deployment that is in the middle of a rollout (either in progress +or paused), the Deployment controller balances the additional replicas in the existing active +ReplicaSets (ReplicaSets with Pods) in order to mitigate risk. This is called *proportional scaling*. + +For example, you are running a Deployment with 10 replicas, [maxSurge](#max-surge)=3, and [maxUnavailable](#max-unavailable)=2. + +* Ensure that the 10 replicas in your Deployment are running. + ```shell + kubectl get deploy + ``` + The output is similar to this: + + ``` + NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE + nginx-deployment 10 10 10 10 50s + ``` + +* You update to a new image which happens to be unresolvable from inside the cluster. + ```shell + kubectl set image deployment/nginx-deployment nginx=nginx:sometag + ``` + + The output is similar to this: + ``` + deployment.apps/nginx-deployment image updated + ``` + +* The image update starts a new rollout with ReplicaSet nginx-deployment-1989198191, but it's blocked due to the +`maxUnavailable` requirement that you mentioned above. Check out the rollout status: + ```shell + kubectl get rs + ``` + The output is similar to this: + ``` + NAME DESIRED CURRENT READY AGE + nginx-deployment-1989198191 5 5 0 9s + nginx-deployment-618515232 8 8 8 1m + ``` + +* Then a new scaling request for the Deployment comes along. The autoscaler increments the Deployment replicas +to 15. The Deployment controller needs to decide where to add these new 5 replicas. If you weren't using +proportional scaling, all 5 of them would be added in the new ReplicaSet. With proportional scaling, you +spread the additional replicas across all ReplicaSets. Bigger proportions go to the ReplicaSets with the +most replicas and lower proportions go to ReplicaSets with less replicas. Any leftovers are added to the +ReplicaSet with the most replicas. ReplicaSets with zero replicas are not scaled up. + +In our example above, 3 replicas are added to the old ReplicaSet and 2 replicas are added to the +new ReplicaSet. The rollout process should eventually move all replicas to the new ReplicaSet, assuming +the new replicas become healthy. To confirm this, run: + +```shell +kubectl get deploy +``` + +The output is similar to this: +``` +NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE +nginx-deployment 15 18 7 8 7m +``` +The rollout status confirms how the replicas were added to each ReplicaSet. +```shell +kubectl get rs +``` + +The output is similar to this: +``` +NAME DESIRED CURRENT READY AGE +nginx-deployment-1989198191 7 7 0 7m +nginx-deployment-618515232 11 11 11 7m +``` + +## Pausing and Resuming a rollout of a Deployment {#pausing-and-resuming-a-deployment} + +When you update a Deployment, or plan to, you can pause rollouts +for that Deployment before you trigger one or more updates. When +you're ready to apply those changes, you resume rollouts for the +Deployment. This approach allows you to +apply multiple fixes in between pausing and resuming without triggering unnecessary rollouts. + +* For example, with a Deployment that was created: + + Get the Deployment details: + ```shell + kubectl get deploy + ``` + The output is similar to this: + ``` + NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE + nginx 3 3 3 3 1m + ``` + Get the rollout status: + ```shell + kubectl get rs + ``` + The output is similar to this: + ``` + NAME DESIRED CURRENT READY AGE + nginx-2142116321 3 3 3 1m + ``` + +* Pause by running the following command: + ```shell + kubectl rollout pause deployment/nginx-deployment + ``` + + The output is similar to this: + ``` + deployment.apps/nginx-deployment paused + ``` + +* Then update the image of the Deployment: + ```shell + kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 + ``` + + The output is similar to this: + ``` + deployment.apps/nginx-deployment image updated + ``` + +* Notice that no new rollout started: + ```shell + kubectl rollout history deployment/nginx-deployment + ``` + + The output is similar to this: + ``` + deployments "nginx" + REVISION CHANGE-CAUSE + 1 + ``` +* Get the rollout status to verify that the existing ReplicaSet has not changed: + ```shell + kubectl get rs + ``` + + The output is similar to this: + ``` + NAME DESIRED CURRENT READY AGE + nginx-2142116321 3 3 3 2m + ``` + +* You can make as many updates as you wish, for example, update the resources that will be used: + ```shell + kubectl set resources deployment/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi + ``` + + The output is similar to this: + ``` + deployment.apps/nginx-deployment resource requirements updated + ``` + + The initial state of the Deployment prior to pausing its rollout will continue its function, but new updates to + the Deployment will not have any effect as long as the Deployment rollout is paused. + +* Eventually, resume the Deployment rollout and observe a new ReplicaSet coming up with all the new updates: + ```shell + kubectl rollout resume deployment/nginx-deployment + ``` + + The output is similar to this: + ``` + deployment.apps/nginx-deployment resumed + ``` +* {{< glossary_tooltip text="Watch" term_id="watch" >}} the status of the rollout until it's done. + ```shell + kubectl get rs --watch + ``` + + The output is similar to this: + ``` + NAME DESIRED CURRENT READY AGE + nginx-2142116321 2 2 2 2m + nginx-3926361531 2 2 0 6s + nginx-3926361531 2 2 1 18s + nginx-2142116321 1 2 2 2m + nginx-2142116321 1 2 2 2m + nginx-3926361531 3 2 1 18s + nginx-3926361531 3 2 1 18s + nginx-2142116321 1 1 1 2m + nginx-3926361531 3 3 1 18s + nginx-3926361531 3 3 2 19s + nginx-2142116321 0 1 1 2m + nginx-2142116321 0 1 1 2m + nginx-2142116321 0 0 0 2m + nginx-3926361531 3 3 3 20s + ``` +* Get the status of the latest rollout: + ```shell + kubectl get rs + ``` + + The output is similar to this: + ``` + NAME DESIRED CURRENT READY AGE + nginx-2142116321 0 0 0 2m + nginx-3926361531 3 3 3 28s + ``` +{{< note >}} +You cannot rollback a paused Deployment until you resume it. +{{< /note >}} + +## Deployment status + +A Deployment enters various states during its lifecycle. It can be [progressing](#progressing-deployment) while +rolling out a new ReplicaSet, it can be [complete](#complete-deployment), or it can [fail to progress](#failed-deployment). + +### Progressing Deployment + +Kubernetes marks a Deployment as _progressing_ when one of the following tasks is performed: + +* The Deployment creates a new ReplicaSet. +* The Deployment is scaling up its newest ReplicaSet. +* The Deployment is scaling down its older ReplicaSet(s). +* New Pods become ready or available (ready for at least [MinReadySeconds](#min-ready-seconds)). + +When the rollout becomes “progressing”, the Deployment controller adds a condition with the following +attributes to the Deployment's `.status.conditions`: + +* `type: Progressing` +* `status: "True"` +* `reason: NewReplicaSetCreated` | `reason: FoundNewReplicaSet` | `reason: ReplicaSetUpdated` + +You can monitor the progress for a Deployment by using `kubectl rollout status`. + +### Complete Deployment + +Kubernetes marks a Deployment as _complete_ when it has the following characteristics: + +* All of the replicas associated with the Deployment have been updated to the latest version you've specified, meaning any +updates you've requested have been completed. +* All of the replicas associated with the Deployment are available. +* No old replicas for the Deployment are running. + +When the rollout becomes “complete”, the Deployment controller sets a condition with the following +attributes to the Deployment's `.status.conditions`: + +* `type: Progressing` +* `status: "True"` +* `reason: NewReplicaSetAvailable` + +This `Progressing` condition will retain a status value of `"True"` until a new rollout +is initiated. The condition holds even when availability of replicas changes (which +does instead affect the `Available` condition). + +You can check if a Deployment has completed by using `kubectl rollout status`. If the rollout completed +successfully, `kubectl rollout status` returns a zero exit code. + +```shell +kubectl rollout status deployment/nginx-deployment +``` +The output is similar to this: +``` +Waiting for rollout to finish: 2 of 3 updated replicas are available... +deployment "nginx-deployment" successfully rolled out +``` +and the exit status from `kubectl rollout` is 0 (success): +```shell +echo $? +``` +``` +0 +``` + +### Failed Deployment + +Your Deployment may get stuck trying to deploy its newest ReplicaSet without ever completing. This can occur +due to some of the following factors: + +* Insufficient quota +* Readiness probe failures +* Image pull errors +* Insufficient permissions +* Limit ranges +* Application runtime misconfiguration + +One way you can detect this condition is to specify a deadline parameter in your Deployment spec: +([`.spec.progressDeadlineSeconds`](#progress-deadline-seconds)). `.spec.progressDeadlineSeconds` denotes the +number of seconds the Deployment controller waits before indicating (in the Deployment status) that the +Deployment progress has stalled. + +The following `kubectl` command sets the spec with `progressDeadlineSeconds` to make the controller report +lack of progress of a rollout for a Deployment after 10 minutes: + +```shell +kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}' +``` +The output is similar to this: +``` +deployment.apps/nginx-deployment patched +``` +Once the deadline has been exceeded, the Deployment controller adds a DeploymentCondition with the following +attributes to the Deployment's `.status.conditions`: + +* `type: Progressing` +* `status: "False"` +* `reason: ProgressDeadlineExceeded` + +This condition can also fail early and is then set to status value of `"False"` due to reasons as `ReplicaSetCreateError`. +Also, the deadline is not taken into account anymore once the Deployment rollout completes. + +See the [Kubernetes API conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties) for more information on status conditions. + +{{< note >}} +Kubernetes takes no action on a stalled Deployment other than to report a status condition with +`reason: ProgressDeadlineExceeded`. Higher level orchestrators can take advantage of it and act accordingly, for +example, rollback the Deployment to its previous version. +{{< /note >}} + +{{< note >}} +If you pause a Deployment rollout, Kubernetes does not check progress against your specified deadline. +You can safely pause a Deployment rollout in the middle of a rollout and resume without triggering +the condition for exceeding the deadline. +{{< /note >}} + +You may experience transient errors with your Deployments, either due to a low timeout that you have set or +due to any other kind of error that can be treated as transient. For example, let's suppose you have +insufficient quota. If you describe the Deployment you will notice the following section: + +```shell +kubectl describe deployment nginx-deployment +``` +The output is similar to this: +``` +<...> +Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True ReplicaSetUpdated + ReplicaFailure True FailedCreate +<...> +``` + +If you run `kubectl get deployment nginx-deployment -o yaml`, the Deployment status is similar to this: + +``` +status: + availableReplicas: 2 + conditions: + - lastTransitionTime: 2016-10-04T12:25:39Z + lastUpdateTime: 2016-10-04T12:25:39Z + message: Replica set "nginx-deployment-4262182780" is progressing. + reason: ReplicaSetUpdated + status: "True" + type: Progressing + - lastTransitionTime: 2016-10-04T12:25:42Z + lastUpdateTime: 2016-10-04T12:25:42Z + message: Deployment has minimum availability. + reason: MinimumReplicasAvailable + status: "True" + type: Available + - lastTransitionTime: 2016-10-04T12:25:39Z + lastUpdateTime: 2016-10-04T12:25:39Z + message: 'Error creating: pods "nginx-deployment-4262182780-" is forbidden: exceeded quota: + object-counts, requested: pods=1, used: pods=3, limited: pods=2' + reason: FailedCreate + status: "True" + type: ReplicaFailure + observedGeneration: 3 + replicas: 2 + unavailableReplicas: 2 +``` + +Eventually, once the Deployment progress deadline is exceeded, Kubernetes updates the status and the +reason for the Progressing condition: + +``` +Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing False ProgressDeadlineExceeded + ReplicaFailure True FailedCreate +``` + +You can address an issue of insufficient quota by scaling down your Deployment, by scaling down other +controllers you may be running, or by increasing quota in your namespace. If you satisfy the quota +conditions and the Deployment controller then completes the Deployment rollout, you'll see the +Deployment's status update with a successful condition (`status: "True"` and `reason: NewReplicaSetAvailable`). + +``` +Conditions: + Type Status Reason + ---- ------ ------ + Available True MinimumReplicasAvailable + Progressing True NewReplicaSetAvailable +``` + +`type: Available` with `status: "True"` means that your Deployment has minimum availability. Minimum availability is dictated +by the parameters specified in the deployment strategy. `type: Progressing` with `status: "True"` means that your Deployment +is either in the middle of a rollout and it is progressing or that it has successfully completed its progress and the minimum +required new replicas are available (see the Reason of the condition for the particulars - in our case +`reason: NewReplicaSetAvailable` means that the Deployment is complete). + +You can check if a Deployment has failed to progress by using `kubectl rollout status`. `kubectl rollout status` +returns a non-zero exit code if the Deployment has exceeded the progression deadline. + +```shell +kubectl rollout status deployment/nginx-deployment +``` +The output is similar to this: +``` +Waiting for rollout to finish: 2 out of 3 new replicas have been updated... +error: deployment "nginx" exceeded its progress deadline +``` +and the exit status from `kubectl rollout` is 1 (indicating an error): +```shell +echo $? +``` +``` +1 +``` + +### Operating on a failed deployment + +All actions that apply to a complete Deployment also apply to a failed Deployment. You can scale it up/down, roll back +to a previous revision, or even pause it if you need to apply multiple tweaks in the Deployment Pod template. + +## Clean up Policy + +You can set `.spec.revisionHistoryLimit` field in a Deployment to specify how many old ReplicaSets for +this Deployment you want to retain. The rest will be garbage-collected in the background. By default, +it is 10. + +{{< note >}} +Explicitly setting this field to 0, will result in cleaning up all the history of your Deployment +thus that Deployment will not be able to roll back. +{{< /note >}} + +The cleanup only starts **after** a Deployment reaches a +[complete state](/docs/concepts/workloads/controllers/deployment/#complete-deployment). +If you set `.spec.revisionHistoryLimit` to 0, any rollout nonetheless triggers creation of a new +ReplicaSet before Kubernetes removes the old one. + +Even with a non-zero revision history limit, you can have more ReplicaSets than the limit +you configure. For example, if pods are crash looping, and there are multiple rolling updates +events triggered over time, you might end up with more ReplicaSets than the +`.spec.revisionHistoryLimit` because the Deployment never reaches a complete state. + +## Canary Deployment + +If you want to roll out releases to a subset of users or servers using the Deployment, you +can create multiple Deployments, one for each release, following the canary pattern described in +[managing resources](/docs/concepts/workloads/management/#canary-deployments). + +## Writing a Deployment Spec + +As with all other Kubernetes configs, a Deployment needs `.apiVersion`, `.kind`, and `.metadata` fields. +For general information about working with config files, see +[deploying applications](/docs/tasks/run-application/run-stateless-application-deployment/), +configuring containers, and [using kubectl to manage resources](/docs/concepts/overview/working-with-objects/object-management/) documents. + +When the control plane creates new Pods for a Deployment, the `.metadata.name` of the +Deployment is part of the basis for naming those Pods. The name of a Deployment must be a valid +[DNS subdomain](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) +value, but this can produce unexpected results for the Pod hostnames. For best compatibility, +the name should follow the more restrictive rules for a +[DNS label](/docs/concepts/overview/working-with-objects/names#dns-label-names). + +A Deployment also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). + +### Pod Template + +The `.spec.template` and `.spec.selector` are the only required fields of the `.spec`. + +The `.spec.template` is a [Pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`. + +In addition to required fields for a Pod, a Pod template in a Deployment must specify appropriate +labels and an appropriate restart policy. For labels, make sure not to overlap with other controllers. See [selector](#selector). + +Only a [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) equal to `Always` is +allowed, which is the default if not specified. + +### Replicas + +`.spec.replicas` is an optional field that specifies the number of desired Pods. It defaults to 1. + +Should you manually scale a Deployment, example via `kubectl scale deployment +deployment --replicas=X`, and then you update that Deployment based on a manifest +(for example: by running `kubectl apply -f deployment.yaml`), +then applying that manifest overwrites the manual scaling that you previously did. + +If a [HorizontalPodAutoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/) (or any +similar API for horizontal scaling) is managing scaling for a Deployment, don't set `.spec.replicas`. + +Instead, allow the Kubernetes +{{< glossary_tooltip text="control plane" term_id="control-plane" >}} to manage the +`.spec.replicas` field automatically. + +### Selector + +`.spec.selector` is a required field that specifies a [label selector](/docs/concepts/overview/working-with-objects/labels/) +for the Pods targeted by this Deployment. + +`.spec.selector` must match `.spec.template.metadata.labels`, or it will be rejected by the API. + +In API version `apps/v1`, `.spec.selector` and `.metadata.labels` do not default to `.spec.template.metadata.labels` if not set. So they must be set explicitly. Also note that `.spec.selector` is immutable after creation of the Deployment in `apps/v1`. + +A Deployment may terminate Pods whose labels match the selector if their template is different +from `.spec.template` or if the total number of such Pods exceeds `.spec.replicas`. It brings up new +Pods with `.spec.template` if the number of Pods is less than the desired number. + +{{< note >}} +You should not create other Pods whose labels match this selector, either directly, by creating +another Deployment, or by creating another controller such as a ReplicaSet or a ReplicationController. If you +do so, the first Deployment thinks that it created these other Pods. Kubernetes does not stop you from doing this. +{{< /note >}} + +If you have multiple controllers that have overlapping selectors, the controllers will fight with each +other and won't behave correctly. + +### Strategy + +`.spec.strategy` specifies the strategy used to replace old Pods by new ones. +`.spec.strategy.type` can be "Recreate" or "RollingUpdate". "RollingUpdate" is +the default value. + +#### Recreate Deployment + +All existing Pods are killed before new ones are created when `.spec.strategy.type==Recreate`. + +{{< note >}} +This will only guarantee Pod termination previous to creation for upgrades. If you upgrade a Deployment, all Pods +of the old revision will be terminated immediately. Successful removal is awaited before any Pod of the new +revision is created. If you manually delete a Pod, the lifecycle is controlled by the ReplicaSet and the +replacement will be created immediately (even if the old Pod is still in a Terminating state). If you need an +"at most" guarantee for your Pods, you should consider using a +[StatefulSet](/docs/concepts/workloads/controllers/statefulset/). +{{< /note >}} + +#### Rolling Update Deployment + +The Deployment updates Pods in a rolling update +fashion when `.spec.strategy.type==RollingUpdate`. You can specify `maxUnavailable` and `maxSurge` to control +the rolling update process. + +##### Max Unavailable + +`.spec.strategy.rollingUpdate.maxUnavailable` is an optional field that specifies the maximum number +of Pods that can be unavailable during the update process. The value can be an absolute number (for example, 5) +or a percentage of desired Pods (for example, 10%). The absolute number is calculated from percentage by +rounding down. The value cannot be 0 if `.spec.strategy.rollingUpdate.maxSurge` is 0. The default value is 25%. + +For example, when this value is set to 30%, the old ReplicaSet can be scaled down to 70% of desired +Pods immediately when the rolling update starts. Once new Pods are ready, old ReplicaSet can be scaled +down further, followed by scaling up the new ReplicaSet, ensuring that the total number of Pods available +at all times during the update is at least 70% of the desired Pods. + +##### Max Surge + +`.spec.strategy.rollingUpdate.maxSurge` is an optional field that specifies the maximum number of Pods +that can be created over the desired number of Pods. The value can be an absolute number (for example, 5) or a +percentage of desired Pods (for example, 10%). The value cannot be 0 if `MaxUnavailable` is 0. The absolute number +is calculated from the percentage by rounding up. The default value is 25%. + +For example, when this value is set to 30%, the new ReplicaSet can be scaled up immediately when the +rolling update starts, such that the total number of old and new Pods does not exceed 130% of desired +Pods. Once old Pods have been killed, the new ReplicaSet can be scaled up further, ensuring that the +total number of Pods running at any time during the update is at most 130% of desired Pods. + +Here are some Rolling Update Deployment examples that use the `maxUnavailable` and `maxSurge`: + +{{< tabs name="tab_with_md" >}} +{{% tab name="Max Unavailable" %}} + + ```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: nginx-deployment + labels: + app: nginx +spec: + replicas: 3 + selector: + matchLabels: + app: nginx + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx:1.14.2 + ports: + - containerPort: 80 + strategy: + type: RollingUpdate + rollingUpdate: + maxUnavailable: 1 + ``` + +{{% /tab %}} +{{% tab name="Max Surge" %}} + + ```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: nginx-deployment + labels: + app: nginx +spec: + replicas: 3 + selector: + matchLabels: + app: nginx + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx:1.14.2 + ports: + - containerPort: 80 + strategy: + type: RollingUpdate + rollingUpdate: + maxSurge: 1 + ``` + +{{% /tab %}} +{{% tab name="Hybrid" %}} + + ```yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: nginx-deployment + labels: + app: nginx +spec: + replicas: 3 + selector: + matchLabels: + app: nginx + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx:1.14.2 + ports: + - containerPort: 80 + strategy: + type: RollingUpdate + rollingUpdate: + maxSurge: 1 + maxUnavailable: 1 + ``` + +{{% /tab %}} +{{< /tabs >}} + +### Progress Deadline Seconds + +`.spec.progressDeadlineSeconds` is an optional field that specifies the number of seconds you want +to wait for your Deployment to progress before the system reports back that the Deployment has +[failed progressing](#failed-deployment) - surfaced as a condition with `type: Progressing`, `status: "False"`. +and `reason: ProgressDeadlineExceeded` in the status of the resource. The Deployment controller will keep +retrying the Deployment. This defaults to 600. In the future, once automatic rollback will be implemented, the Deployment +controller will roll back a Deployment as soon as it observes such a condition. + +If specified, this field needs to be greater than `.spec.minReadySeconds`. + +### Min Ready Seconds + +`.spec.minReadySeconds` is an optional field that specifies the minimum number of seconds for which a newly +created Pod should be ready without any of its containers crashing, for it to be considered available. +This defaults to 0 (the Pod will be considered available as soon as it is ready). To learn more about when +a Pod is considered ready, see [Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes). + +### Terminating Pods + +{{< feature-state feature_gate_name="DeploymentReplicaSetTerminatingReplicas" >}} + +You can enable this feature it by setting the `DeploymentReplicaSetTerminatingReplicas` +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) +on the [API server](/docs/reference/command-line-tools-reference/kube-apiserver/) +and on the [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) + +Pods that become terminating due to deletion or scale down may take a long time to terminate, and may consume +additional resources during that period. As a result, the total number of all pods can temporarily exceed +`.spec.replicas`. Terminating pods can be tracked using the `.status.terminatingReplicas` field of the Deployment. + +### Revision History Limit + +A Deployment's revision history is stored in the ReplicaSets it controls. + +`.spec.revisionHistoryLimit` is an optional field that specifies the number of old ReplicaSets to retain +to allow rollback. These old ReplicaSets consume resources in `etcd` and crowd the output of `kubectl get rs`. The configuration of each Deployment revision is stored in its ReplicaSets; therefore, once an old ReplicaSet is deleted, you lose the ability to rollback to that revision of Deployment. By default, 10 old ReplicaSets will be kept, however its ideal value depends on the frequency and stability of new Deployments. + +More specifically, setting this field to zero means that all old ReplicaSets with 0 replicas will be cleaned up. +In this case, a new Deployment rollout cannot be undone, since its revision history is cleaned up. + +### Paused + +`.spec.paused` is an optional boolean field for pausing and resuming a Deployment. The only difference between +a paused Deployment and one that is not paused, is that any changes into the PodTemplateSpec of the paused +Deployment will not trigger new rollouts as long as it is paused. A Deployment is not paused by default when +it is created. + +## {{% heading "whatsnext" %}} + +* Learn more about [Pods](/docs/concepts/workloads/pods). +* [Run a stateless application using a Deployment](/docs/tasks/run-application/run-stateless-application-deployment/). +* Read the {{< api-reference page="workload-resources/deployment-v1" >}} to understand the Deployment API. +* Read about [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) and how + you can use it to manage application availability during disruptions. +* Use kubectl to [create a Deployment](/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/). diff --git a/content/fa/docs/concepts/workloads/controllers/job.md b/content/fa/docs/concepts/workloads/controllers/job.md new file mode 100644 index 0000000000000..bfe16c50523ca --- /dev/null +++ b/content/fa/docs/concepts/workloads/controllers/job.md @@ -0,0 +1,1216 @@ +--- +reviewers: +- xirehat +title: Jobs +api_metadata: +- apiVersion: "batch/v1" + kind: "Job" +content_type: concept +description: >- + کارها نمایانگر وظایف یک‌باره هستند که تا اتمام اجرا می‌شوند و سپس متوقف می‌شوند.. +feature: + title: اجرای دسته‌ای + description: > + علاوه بر سرویس‌ها، کوبرنتیز می‌تواند بارهای کاری دسته‌ای و CI شما را مدیریت کند و در صورت تمایل، کانتینرهایی را که از کار می‌افتند، جایگزین کند. +weight: 50 +hide_summary: true # Listed separately in section index +--- + + + +A Job creates one or more Pods and will continue to retry execution of the Pods until a specified number of them successfully terminate. +As pods successfully complete, the Job tracks the successful completions. When a specified number +of successful completions is reached, the task (ie, Job) is complete. Deleting a Job will clean up +the Pods it created. Suspending a Job will delete its active Pods until the Job +is resumed again. + +A simple case is to create one Job object in order to reliably run one Pod to completion. +The Job object will start a new Pod if the first Pod fails or is deleted (for example +due to a node hardware failure or a node reboot). + +You can also use a Job to run multiple Pods in parallel. + +If you want to run a Job (either a single task, or several in parallel) on a schedule, +see [CronJob](/docs/concepts/workloads/controllers/cron-jobs/). + + + +## Running an example Job + +Here is an example Job config. It computes π to 2000 places and prints it out. +It takes around 10s to complete. + +{{% code_sample file="controllers/job.yaml" %}} + +You can run the example with this command: + +```shell +kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml +``` + +The output is similar to this: + +``` +job.batch/pi created +``` + +Check on the status of the Job with `kubectl`: + +{{< tabs name="Check status of Job" >}} +{{< tab name="kubectl describe job pi" codelang="bash" >}} +Name: pi +Namespace: default +Selector: batch.kubernetes.io/controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c +Labels: batch.kubernetes.io/controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c + batch.kubernetes.io/job-name=pi + ... +Annotations: batch.kubernetes.io/job-tracking: "" +Parallelism: 1 +Completions: 1 +Start Time: Mon, 02 Dec 2019 15:20:11 +0200 +Completed At: Mon, 02 Dec 2019 15:21:16 +0200 +Duration: 65s +Pods Statuses: 0 Running / 1 Succeeded / 0 Failed +Pod Template: + Labels: batch.kubernetes.io/controller-uid=c9948307-e56d-4b5d-8302-ae2d7b7da67c + batch.kubernetes.io/job-name=pi + Containers: + pi: + Image: perl:5.34.0 + Port: + Host Port: + Command: + perl + -Mbignum=bpi + -wle + print bpi(2000) + Environment: + Mounts: + Volumes: +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal SuccessfulCreate 21s job-controller Created pod: pi-xf9p4 + Normal Completed 18s job-controller Job completed +{{< /tab >}} +{{< tab name="kubectl get job pi -o yaml" codelang="bash" >}} +apiVersion: batch/v1 +kind: Job +metadata: + annotations: batch.kubernetes.io/job-tracking: "" + ... + creationTimestamp: "2022-11-10T17:53:53Z" + generation: 1 + labels: + batch.kubernetes.io/controller-uid: 863452e6-270d-420e-9b94-53a54146c223 + batch.kubernetes.io/job-name: pi + name: pi + namespace: default + resourceVersion: "4751" + uid: 204fb678-040b-497f-9266-35ffa8716d14 +spec: + backoffLimit: 4 + completionMode: NonIndexed + completions: 1 + parallelism: 1 + selector: + matchLabels: + batch.kubernetes.io/controller-uid: 863452e6-270d-420e-9b94-53a54146c223 + suspend: false + template: + metadata: + creationTimestamp: null + labels: + batch.kubernetes.io/controller-uid: 863452e6-270d-420e-9b94-53a54146c223 + batch.kubernetes.io/job-name: pi + spec: + containers: + - command: + - perl + - -Mbignum=bpi + - -wle + - print bpi(2000) + image: perl:5.34.0 + imagePullPolicy: IfNotPresent + name: pi + resources: {} + terminationMessagePath: /dev/termination-log + terminationMessagePolicy: File + dnsPolicy: ClusterFirst + restartPolicy: Never + schedulerName: default-scheduler + securityContext: {} + terminationGracePeriodSeconds: 30 +status: + active: 1 + ready: 0 + startTime: "2022-11-10T17:53:57Z" + uncountedTerminatedPods: {} +{{< /tab >}} +{{< /tabs >}} + +To view completed Pods of a Job, use `kubectl get pods`. + +To list all the Pods that belong to a Job in a machine readable form, you can use a command like this: + +```shell +pods=$(kubectl get pods --selector=batch.kubernetes.io/job-name=pi --output=jsonpath='{.items[*].metadata.name}') +echo $pods +``` + +The output is similar to this: + +``` +pi-5rwd7 +``` + +Here, the selector is the same as the selector for the Job. The `--output=jsonpath` option specifies an expression +with the name from each Pod in the returned list. + +View the standard output of one of the pods: + +```shell +kubectl logs $pods +``` + +Another way to view the logs of a Job: + +```shell +kubectl logs jobs/pi +``` + +The output is similar to this: + +``` +3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901 +``` + +## Writing a Job spec + +As with all other Kubernetes config, a Job needs `apiVersion`, `kind`, and `metadata` fields. + +When the control plane creates new Pods for a Job, the `.metadata.name` of the +Job is part of the basis for naming those Pods. The name of a Job must be a valid +[DNS subdomain](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) +value, but this can produce unexpected results for the Pod hostnames. For best compatibility, +the name should follow the more restrictive rules for a +[DNS label](/docs/concepts/overview/working-with-objects/names#dns-label-names). +Even when the name is a DNS subdomain, the name must be no longer than 63 +characters. + +A Job also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). + +### Job Labels + +Job labels will have `batch.kubernetes.io/` prefix for `job-name` and `controller-uid`. + +### Pod Template + +The `.spec.template` is the only required field of the `.spec`. + +The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/#pod-templates). +It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, +except it is nested and does not have an `apiVersion` or `kind`. + +In addition to required fields for a Pod, a pod template in a Job must specify appropriate +labels (see [pod selector](#pod-selector)) and an appropriate restart policy. + +Only a [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) +equal to `Never` or `OnFailure` is allowed. + +### Pod selector + +The `.spec.selector` field is optional. In almost all cases you should not specify it. +See section [specifying your own pod selector](#specifying-your-own-pod-selector). + +### Parallel execution for Jobs {#parallel-jobs} + +There are three main types of task suitable to run as a Job: + +1. Non-parallel Jobs + - normally, only one Pod is started, unless the Pod fails. + - the Job is complete as soon as its Pod terminates successfully. +1. Parallel Jobs with a *fixed completion count*: + - specify a non-zero positive value for `.spec.completions`. + - the Job represents the overall task, and is complete when there are `.spec.completions` successful Pods. + - when using `.spec.completionMode="Indexed"`, each Pod gets a different index in the range 0 to `.spec.completions-1`. +1. Parallel Jobs with a *work queue*: + - do not specify `.spec.completions`, default to `.spec.parallelism`. + - the Pods must coordinate amongst themselves or an external service to determine + what each should work on. For example, a Pod might fetch a batch of up to N items from the work queue. + - each Pod is independently capable of determining whether or not all its peers are done, + and thus that the entire Job is done. + - when _any_ Pod from the Job terminates with success, no new Pods are created. + - once at least one Pod has terminated with success and all Pods are terminated, + then the Job is completed with success. + - once any Pod has exited with success, no other Pod should still be doing any work + for this task or writing any output. They should all be in the process of exiting. + +For a _non-parallel_ Job, you can leave both `.spec.completions` and `.spec.parallelism` unset. +When both are unset, both are defaulted to 1. + +For a _fixed completion count_ Job, you should set `.spec.completions` to the number of completions needed. +You can set `.spec.parallelism`, or leave it unset and it will default to 1. + +For a _work queue_ Job, you must leave `.spec.completions` unset, and set `.spec.parallelism` to +a non-negative integer. + +For more information about how to make use of the different types of job, +see the [job patterns](#job-patterns) section. + +#### Controlling parallelism + +The requested parallelism (`.spec.parallelism`) can be set to any non-negative value. +If it is unspecified, it defaults to 1. +If it is specified as 0, then the Job is effectively paused until it is increased. + +Actual parallelism (number of pods running at any instant) may be more or less than requested +parallelism, for a variety of reasons: + +- For _fixed completion count_ Jobs, the actual number of pods running in parallel will not exceed the number of + remaining completions. Higher values of `.spec.parallelism` are effectively ignored. +- For _work queue_ Jobs, no new Pods are started after any Pod has succeeded -- remaining Pods are allowed to complete, however. +- If the Job {{< glossary_tooltip term_id="controller" >}} has not had time to react. +- If the Job controller failed to create Pods for any reason (lack of `ResourceQuota`, lack of permission, etc.), + then there may be fewer pods than requested. +- The Job controller may throttle new Pod creation due to excessive previous pod failures in the same Job. +- When a Pod is gracefully shut down, it takes time to stop. + +### Completion mode + +{{< feature-state for_k8s_version="v1.24" state="stable" >}} + +Jobs with _fixed completion count_ - that is, jobs that have non null +`.spec.completions` - can have a completion mode that is specified in `.spec.completionMode`: + +- `NonIndexed` (default): the Job is considered complete when there have been + `.spec.completions` successfully completed Pods. In other words, each Pod + completion is homologous to each other. Note that Jobs that have null + `.spec.completions` are implicitly `NonIndexed`. +- `Indexed`: the Pods of a Job get an associated completion index from 0 to + `.spec.completions-1`. The index is available through four mechanisms: + - The Pod annotation `batch.kubernetes.io/job-completion-index`. + - The Pod label `batch.kubernetes.io/job-completion-index` (for v1.28 and later). Note + the feature gate `PodIndexLabel` must be enabled to use this label, and it is enabled + by default. + - As part of the Pod hostname, following the pattern `$(job-name)-$(index)`. + When you use an Indexed Job in combination with a + {{< glossary_tooltip term_id="Service" >}}, Pods within the Job can use + the deterministic hostnames to address each other via DNS. For more information about + how to configure this, see [Job with Pod-to-Pod Communication](/docs/tasks/job/job-with-pod-to-pod-communication/). + - From the containerized task, in the environment variable `JOB_COMPLETION_INDEX`. + + The Job is considered complete when there is one successfully completed Pod + for each index. For more information about how to use this mode, see + [Indexed Job for Parallel Processing with Static Work Assignment](/docs/tasks/job/indexed-parallel-processing-static/). + +{{< note >}} +Although rare, more than one Pod could be started for the same index (due to various reasons such as node failures, +kubelet restarts, or Pod evictions). In this case, only the first Pod that completes successfully will +count towards the completion count and update the status of the Job. The other Pods that are running +or completed for the same index will be deleted by the Job controller once they are detected. +{{< /note >}} + +## Handling Pod and container failures + +A container in a Pod may fail for a number of reasons, such as because the process in it exited with +a non-zero exit code, or the container was killed for exceeding a memory limit, etc. If this +happens, and the `.spec.template.spec.restartPolicy = "OnFailure"`, then the Pod stays +on the node, but the container is re-run. Therefore, your program needs to handle the case when it is +restarted locally, or else specify `.spec.template.spec.restartPolicy = "Never"`. +See [pod lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/#example-states) for more information on `restartPolicy`. + +An entire Pod can also fail, for a number of reasons, such as when the pod is kicked off the node +(node is upgraded, rebooted, deleted, etc.), or if a container of the Pod fails and the +`.spec.template.spec.restartPolicy = "Never"`. When a Pod fails, then the Job controller +starts a new Pod. This means that your application needs to handle the case when it is restarted in a new +pod. In particular, it needs to handle temporary files, locks, incomplete output and the like +caused by previous runs. + +By default, each pod failure is counted towards the `.spec.backoffLimit` limit, +see [pod backoff failure policy](#pod-backoff-failure-policy). However, you can +customize handling of pod failures by setting the Job's [pod failure policy](#pod-failure-policy). + +Additionally, you can choose to count the pod failures independently for each +index of an [Indexed](#completion-mode) Job by setting the `.spec.backoffLimitPerIndex` field +(for more information, see [backoff limit per index](#backoff-limit-per-index)). + +Note that even if you specify `.spec.parallelism = 1` and `.spec.completions = 1` and +`.spec.template.spec.restartPolicy = "Never"`, the same program may +sometimes be started twice. + +If you do specify `.spec.parallelism` and `.spec.completions` both greater than 1, then there may be +multiple pods running at once. Therefore, your pods must also be tolerant of concurrency. + +If you specify the `.spec.podFailurePolicy` field, the Job controller does not consider a terminating +Pod (a pod that has a `.metadata.deletionTimestamp` field set) as a failure until that Pod is +terminal (its `.status.phase` is `Failed` or `Succeeded`). However, the Job controller +creates a replacement Pod as soon as the termination becomes apparent. Once the +pod terminates, the Job controller evaluates `.backoffLimit` and `.podFailurePolicy` +for the relevant Job, taking this now-terminated Pod into consideration. + +If either of these requirements is not satisfied, the Job controller counts +a terminating Pod as an immediate failure, even if that Pod later terminates +with `phase: "Succeeded"`. + +### Pod backoff failure policy + +There are situations where you want to fail a Job after some amount of retries +due to a logical error in configuration etc. +To do so, set `.spec.backoffLimit` to specify the number of retries before +considering a Job as failed. + +The `.spec.backoffLimit` is set by default to 6, unless the +[backoff limit per index](#backoff-limit-per-index) (only Indexed Job) is specified. +When `.spec.backoffLimitPerIndex` is specified, then `.spec.backoffLimit` defaults +to 2147483647 (MaxInt32). + +Failed Pods associated with the Job are recreated by the Job controller with an +exponential back-off delay (10s, 20s, 40s ...) capped at six minutes. + +The number of retries is calculated in two ways: + +- The number of Pods with `.status.phase = "Failed"`. +- When using `restartPolicy = "OnFailure"`, the number of retries in all the + containers of Pods with `.status.phase` equal to `Pending` or `Running`. + +If either of the calculations reaches the `.spec.backoffLimit`, the Job is +considered failed. + +{{< note >}} +If your job has `restartPolicy = "OnFailure"`, keep in mind that your Pod running the Job +will be terminated once the job backoff limit has been reached. This can make debugging +the Job's executable more difficult. We suggest setting +`restartPolicy = "Never"` when debugging the Job or using a logging system to ensure output +from failed Jobs is not lost inadvertently. +{{< /note >}} + +### Backoff limit per index {#backoff-limit-per-index} + +{{< feature-state feature_gate_name="JobBackoffLimitPerIndex" >}} + +When you run an [indexed](#completion-mode) Job, you can choose to handle retries +for pod failures independently for each index. To do so, set the +`.spec.backoffLimitPerIndex` to specify the maximal number of pod failures +per index. + +When the per-index backoff limit is exceeded for an index, Kubernetes considers the index as failed and adds it to the +`.status.failedIndexes` field. The succeeded indexes, those with a successfully +executed pods, are recorded in the `.status.completedIndexes` field, regardless of whether you set +the `backoffLimitPerIndex` field. + +Note that a failing index does not interrupt execution of other indexes. +Once all indexes finish for a Job where you specified a backoff limit per index, +if at least one of those indexes did fail, the Job controller marks the overall +Job as failed, by setting the Failed condition in the status. The Job gets +marked as failed even if some, potentially nearly all, of the indexes were +processed successfully. + +You can additionally limit the maximal number of indexes marked failed by +setting the `.spec.maxFailedIndexes` field. +When the number of failed indexes exceeds the `maxFailedIndexes` field, the +Job controller triggers termination of all remaining running Pods for that Job. +Once all pods are terminated, the entire Job is marked failed by the Job +controller, by setting the Failed condition in the Job status. + +Here is an example manifest for a Job that defines a `backoffLimitPerIndex`: + +{{< code_sample file="/controllers/job-backoff-limit-per-index-example.yaml" >}} + +In the example above, the Job controller allows for one restart for each +of the indexes. When the total number of failed indexes exceeds 5, then +the entire Job is terminated. + +Once the job is finished, the Job status looks as follows: + +```sh +kubectl get -o yaml job job-backoff-limit-per-index-example +``` + +```yaml + status: + completedIndexes: 1,3,5,7,9 + failedIndexes: 0,2,4,6,8 + succeeded: 5 # 1 succeeded pod for each of 5 succeeded indexes + failed: 10 # 2 failed pods (1 retry) for each of 5 failed indexes + conditions: + - message: Job has failed indexes + reason: FailedIndexes + status: "True" + type: FailureTarget + - message: Job has failed indexes + reason: FailedIndexes + status: "True" + type: Failed +``` + +The Job controller adds the `FailureTarget` Job condition to trigger +[Job termination and cleanup](#job-termination-and-cleanup). When all of the +Job Pods are terminated, the Job controller adds the `Failed` condition +with the same values for `reason` and `message` as the `FailureTarget` Job +condition. For details, see [Termination of Job Pods](#termination-of-job-pods). + +Additionally, you may want to use the per-index backoff along with a +[pod failure policy](#pod-failure-policy). When using +per-index backoff, there is a new `FailIndex` action available which allows you to +avoid unnecessary retries within an index. + +### Pod failure policy {#pod-failure-policy} + +{{< feature-state feature_gate_name="JobPodFailurePolicy" >}} + +A Pod failure policy, defined with the `.spec.podFailurePolicy` field, enables +your cluster to handle Pod failures based on the container exit codes and the +Pod conditions. + +In some situations, you may want to have a better control when handling Pod +failures than the control provided by the [Pod backoff failure policy](#pod-backoff-failure-policy), +which is based on the Job's `.spec.backoffLimit`. These are some examples of use cases: + +* To optimize costs of running workloads by avoiding unnecessary Pod restarts, + you can terminate a Job as soon as one of its Pods fails with an exit code + indicating a software bug. +* To guarantee that your Job finishes even if there are disruptions, you can + ignore Pod failures caused by disruptions (such as {{< glossary_tooltip text="preemption" term_id="preemption" >}}, + {{< glossary_tooltip text="API-initiated eviction" term_id="api-eviction" >}} + or {{< glossary_tooltip text="taint" term_id="taint" >}}-based eviction) so + that they don't count towards the `.spec.backoffLimit` limit of retries. + +You can configure a Pod failure policy, in the `.spec.podFailurePolicy` field, +to meet the above use cases. This policy can handle Pod failures based on the +container exit codes and the Pod conditions. + +Here is a manifest for a Job that defines a `podFailurePolicy`: + +{{% code_sample file="/controllers/job-pod-failure-policy-example.yaml" %}} + +In the example above, the first rule of the Pod failure policy specifies that +the Job should be marked failed if the `main` container fails with the 42 exit +code. The following are the rules for the `main` container specifically: + +- an exit code of 0 means that the container succeeded +- an exit code of 42 means that the **entire Job** failed +- any other exit code represents that the container failed, and hence the entire + Pod. The Pod will be re-created if the total number of restarts is + below `backoffLimit`. If the `backoffLimit` is reached the **entire Job** failed. + +{{< note >}} +Because the Pod template specifies a `restartPolicy: Never`, +the kubelet does not restart the `main` container in that particular Pod. +{{< /note >}} + +The second rule of the Pod failure policy, specifying the `Ignore` action for +failed Pods with condition `DisruptionTarget` excludes Pod disruptions from +being counted towards the `.spec.backoffLimit` limit of retries. + +{{< note >}} +If the Job failed, either by the Pod failure policy or Pod backoff +failure policy, and the Job is running multiple Pods, Kubernetes terminates all +the Pods in that Job that are still Pending or Running. +{{< /note >}} + +These are some requirements and semantics of the API: + +- if you want to use a `.spec.podFailurePolicy` field for a Job, you must + also define that Job's pod template with `.spec.restartPolicy` set to `Never`. +- the Pod failure policy rules you specify under `spec.podFailurePolicy.rules` + are evaluated in order. Once a rule matches a Pod failure, the remaining rules + are ignored. When no rule matches the Pod failure, the default + handling applies. +- you may want to restrict a rule to a specific container by specifying its name + in`spec.podFailurePolicy.rules[*].onExitCodes.containerName`. When not specified the rule + applies to all containers. When specified, it should match one the container + or `initContainer` names in the Pod template. +- you may specify the action taken when a Pod failure policy is matched by + `spec.podFailurePolicy.rules[*].action`. Possible values are: + - `FailJob`: use to indicate that the Pod's job should be marked as Failed and + all running Pods should be terminated. + - `Ignore`: use to indicate that the counter towards the `.spec.backoffLimit` + should not be incremented and a replacement Pod should be created. + - `Count`: use to indicate that the Pod should be handled in the default way. + The counter towards the `.spec.backoffLimit` should be incremented. + - `FailIndex`: use this action along with [backoff limit per index](#backoff-limit-per-index) + to avoid unnecessary retries within the index of a failed pod. + +{{< note >}} +When you use a `podFailurePolicy`, the job controller only matches Pods in the +`Failed` phase. Pods with a deletion timestamp that are not in a terminal phase +(`Failed` or `Succeeded`) are considered still terminating. This implies that +terminating pods retain a [tracking finalizer](#job-tracking-with-finalizers) +until they reach a terminal phase. +Since Kubernetes 1.27, Kubelet transitions deleted pods to a terminal phase +(see: [Pod Phase](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)). This +ensures that deleted pods have their finalizers removed by the Job controller. +{{< /note >}} + +{{< note >}} +Starting with Kubernetes v1.28, when Pod failure policy is used, the Job controller recreates +terminating Pods only once these Pods reach the terminal `Failed` phase. This behavior is similar +to `podReplacementPolicy: Failed`. For more information, see [Pod replacement policy](#pod-replacement-policy). +{{< /note >}} + +When you use the `podFailurePolicy`, and the Job fails due to the pod +matching the rule with the `FailJob` action, then the Job controller triggers +the Job termination process by adding the `FailureTarget` condition. +For more details, see [Job termination and cleanup](#job-termination-and-cleanup). + +## Success policy {#success-policy} + +When creating an Indexed Job, you can define when a Job can be declared as succeeded using a `.spec.successPolicy`, +based on the pods that succeeded. + +By default, a Job succeeds when the number of succeeded Pods equals `.spec.completions`. +These are some situations where you might want additional control for declaring a Job succeeded: + +* When running simulations with different parameters, + you might not need all the simulations to succeed for the overall Job to be successful. +* When following a leader-worker pattern, only the success of the leader determines the success or + failure of a Job. Examples of this are frameworks like MPI and PyTorch etc. + +You can configure a success policy, in the `.spec.successPolicy` field, +to meet the above use cases. This policy can handle Job success based on the +succeeded pods. After the Job meets the success policy, the job controller terminates the lingering Pods. +A success policy is defined by rules. Each rule can take one of the following forms: + +* When you specify the `succeededIndexes` only, + once all indexes specified in the `succeededIndexes` succeed, the job controller marks the Job as succeeded. + The `succeededIndexes` must be a list of intervals between 0 and `.spec.completions-1`. +* When you specify the `succeededCount` only, + once the number of succeeded indexes reaches the `succeededCount`, the job controller marks the Job as succeeded. +* When you specify both `succeededIndexes` and `succeededCount`, + once the number of succeeded indexes from the subset of indexes specified in the `succeededIndexes` reaches the `succeededCount`, + the job controller marks the Job as succeeded. + +Note that when you specify multiple rules in the `.spec.successPolicy.rules`, +the job controller evaluates the rules in order. Once the Job meets a rule, the job controller ignores remaining rules. + +Here is a manifest for a Job with `successPolicy`: + +{{% code_sample file="/controllers/job-success-policy.yaml" %}} + +In the example above, both `succeededIndexes` and `succeededCount` have been specified. +Therefore, the job controller will mark the Job as succeeded and terminate the lingering Pods +when either of the specified indexes, 0, 2, or 3, succeed. +The Job that meets the success policy gets the `SuccessCriteriaMet` condition with a `SuccessPolicy` reason. +After the removal of the lingering Pods is issued, the Job gets the `Complete` condition. + +Note that the `succeededIndexes` is represented as intervals separated by a hyphen. +The number are listed in represented by the first and last element of the series, separated by a hyphen. + +{{< note >}} +When you specify both a success policy and some terminating policies such as `.spec.backoffLimit` and `.spec.podFailurePolicy`, +once the Job meets either policy, the job controller respects the terminating policy and ignores the success policy. +{{< /note >}} + +## Job termination and cleanup + +When a Job completes, no more Pods are created, but the Pods are [usually](#pod-backoff-failure-policy) not deleted either. +Keeping them around allows you to still view the logs of completed pods to check for errors, warnings, or other diagnostic output. +The job object also remains after it is completed so that you can view its status. It is up to the user to delete +old jobs after noting their status. Delete the job with `kubectl` (e.g. `kubectl delete jobs/pi` or `kubectl delete -f ./job.yaml`). +When you delete the job using `kubectl`, all the pods it created are deleted too. + +By default, a Job will run uninterrupted unless a Pod fails (`restartPolicy=Never`) +or a Container exits in error (`restartPolicy=OnFailure`), at which point the Job defers to the +`.spec.backoffLimit` described above. Once `.spec.backoffLimit` has been reached the Job will +be marked as failed and any running Pods will be terminated. + +Another way to terminate a Job is by setting an active deadline. +Do this by setting the `.spec.activeDeadlineSeconds` field of the Job to a number of seconds. +The `activeDeadlineSeconds` applies to the duration of the job, no matter how many Pods are created. +Once a Job reaches `activeDeadlineSeconds`, all of its running Pods are terminated and the Job status +will become `type: Failed` with `reason: DeadlineExceeded`. + +Note that a Job's `.spec.activeDeadlineSeconds` takes precedence over its `.spec.backoffLimit`. +Therefore, a Job that is retrying one or more failed Pods will not deploy additional Pods once +it reaches the time limit specified by `activeDeadlineSeconds`, even if the `backoffLimit` is not yet reached. + +Example: + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: pi-with-timeout +spec: + backoffLimit: 5 + activeDeadlineSeconds: 100 + template: + spec: + containers: + - name: pi + image: perl:5.34.0 + command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] + restartPolicy: Never +``` + +Note that both the Job spec and the [Pod template spec](/docs/concepts/workloads/pods/init-containers/#detailed-behavior) +within the Job have an `activeDeadlineSeconds` field. Ensure that you set this field at the proper level. + +Keep in mind that the `restartPolicy` applies to the Pod, and not to the Job itself: +there is no automatic Job restart once the Job status is `type: Failed`. +That is, the Job termination mechanisms activated with `.spec.activeDeadlineSeconds` +and `.spec.backoffLimit` result in a permanent Job failure that requires manual intervention to resolve. + +### Terminal Job conditions + +A Job has two possible terminal states, each of which has a corresponding Job +condition: +* Succeeded: Job condition `Complete` +* Failed: Job condition `Failed` + +Jobs fail for the following reasons: +- The number of Pod failures exceeded the specified `.spec.backoffLimit` in the Job + specification. For details, see [Pod backoff failure policy](#pod-backoff-failure-policy). +- The Job runtime exceeded the specified `.spec.activeDeadlineSeconds` +- An indexed Job that used `.spec.backoffLimitPerIndex` has failed indexes. + For details, see [Backoff limit per index](#backoff-limit-per-index). +- The number of failed indexes in the Job exceeded the specified + `spec.maxFailedIndexes`. For details, see [Backoff limit per index](#backoff-limit-per-index) +- A failed Pod matches a rule in `.spec.podFailurePolicy` that has the `FailJob` + action. For details about how Pod failure policy rules might affect failure + evaluation, see [Pod failure policy](#pod-failure-policy). + +Jobs succeed for the following reasons: +- The number of succeeded Pods reached the specified `.spec.completions` +- The criteria specified in `.spec.successPolicy` are met. For details, see + [Success policy](#success-policy). + +In Kubernetes v1.31 and later the Job controller delays the addition of the +terminal conditions,`Failed` or `Complete`, until all of the Job Pods are terminated. + +In Kubernetes v1.30 and earlier, the Job controller added the `Complete` or the +`Failed` Job terminal conditions as soon as the Job termination process was +triggered and all Pod finalizers were removed. However, some Pods would still +be running or terminating at the moment that the terminal condition was added. + +In Kubernetes v1.31 and later, the controller only adds the Job terminal conditions +_after_ all of the Pods are terminated. You can control this behavior by using the +`JobManagedBy` and the `JobPodReplacementPolicy` (both enabled by default) +[feature gates](/docs/reference/command-line-tools-reference/feature-gates/). + +### Termination of Job pods + +The Job controller adds the `FailureTarget` condition or the `SuccessCriteriaMet` +condition to the Job to trigger Pod termination after a Job meets either the +success or failure criteria. + +Factors like `terminationGracePeriodSeconds` might increase the amount of time +from the moment that the Job controller adds the `FailureTarget` condition or the +`SuccessCriteriaMet` condition to the moment that all of the Job Pods terminate +and the Job controller adds a [terminal condition](#terminal-job-conditions) +(`Failed` or `Complete`). + +You can use the `FailureTarget` or the `SuccessCriteriaMet` condition to evaluate +whether the Job has failed or succeeded without having to wait for the controller +to add a terminal condition. + +For example, you might want to decide when to create a replacement Job +that replaces a failed Job. If you replace the failed Job when the `FailureTarget` +condition appears, your replacement Job runs sooner, but could result in Pods +from the failed and the replacement Job running at the same time, using +extra compute resources. + +Alternatively, if your cluster has limited resource capacity, you could choose to +wait until the `Failed` condition appears on the Job, which would delay your +replacement Job but would ensure that you conserve resources by waiting +until all of the failed Pods are removed. + +## Clean up finished jobs automatically + +Finished Jobs are usually no longer needed in the system. Keeping them around in +the system will put pressure on the API server. If the Jobs are managed directly +by a higher level controller, such as +[CronJobs](/docs/concepts/workloads/controllers/cron-jobs/), the Jobs can be +cleaned up by CronJobs based on the specified capacity-based cleanup policy. + +### TTL mechanism for finished Jobs + +{{< feature-state for_k8s_version="v1.23" state="stable" >}} + +Another way to clean up finished Jobs (either `Complete` or `Failed`) +automatically is to use a TTL mechanism provided by a +[TTL controller](/docs/concepts/workloads/controllers/ttlafterfinished/) for +finished resources, by specifying the `.spec.ttlSecondsAfterFinished` field of +the Job. + +When the TTL controller cleans up the Job, it will delete the Job cascadingly, +i.e. delete its dependent objects, such as Pods, together with the Job. Note +that when the Job is deleted, its lifecycle guarantees, such as finalizers, will +be honored. + +For example: + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: pi-with-ttl +spec: + ttlSecondsAfterFinished: 100 + template: + spec: + containers: + - name: pi + image: perl:5.34.0 + command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] + restartPolicy: Never +``` + +The Job `pi-with-ttl` will be eligible to be automatically deleted, `100` +seconds after it finishes. + +If the field is set to `0`, the Job will be eligible to be automatically deleted +immediately after it finishes. If the field is unset, this Job won't be cleaned +up by the TTL controller after it finishes. + +{{< note >}} +It is recommended to set `ttlSecondsAfterFinished` field because unmanaged jobs +(Jobs that you created directly, and not indirectly through other workload APIs +such as CronJob) have a default deletion +policy of `orphanDependents` causing Pods created by an unmanaged Job to be left around +after that Job is fully deleted. +Even though the {{< glossary_tooltip text="control plane" term_id="control-plane" >}} eventually +[garbage collects](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection) +the Pods from a deleted Job after they either fail or complete, sometimes those +lingering pods may cause cluster performance degradation or in worst case cause the +cluster to go offline due to this degradation. + +You can use [LimitRanges](/docs/concepts/policy/limit-range/) and +[ResourceQuotas](/docs/concepts/policy/resource-quotas/) to place a +cap on the amount of resources that a particular namespace can +consume. +{{< /note >}} + +## Job patterns + +The Job object can be used to process a set of independent but related *work items*. +These might be emails to be sent, frames to be rendered, files to be transcoded, +ranges of keys in a NoSQL database to scan, and so on. + +In a complex system, there may be multiple different sets of work items. Here we are just +considering one set of work items that the user wants to manage together — a *batch job*. + +There are several different patterns for parallel computation, each with strengths and weaknesses. +The tradeoffs are: + +- One Job object for each work item, versus a single Job object for all work items. + One Job per work item creates some overhead for the user and for the system to manage + large numbers of Job objects. + A single Job for all work items is better for large numbers of items. +- Number of Pods created equals number of work items, versus each Pod can process multiple work items. + When the number of Pods equals the number of work items, the Pods typically + requires less modification to existing code and containers. Having each Pod + process multiple work items is better for large numbers of items. +- Several approaches use a work queue. This requires running a queue service, + and modifications to the existing program or container to make it use the work queue. + Other approaches are easier to adapt to an existing containerised application. +- When the Job is associated with a + [headless Service](/docs/concepts/services-networking/service/#headless-services), + you can enable the Pods within a Job to communicate with each other to + collaborate in a computation. + +The tradeoffs are summarized here, with columns 2 to 4 corresponding to the above tradeoffs. +The pattern names are also links to examples and more detailed description. + +| Pattern | Single Job object | Fewer pods than work items? | Use app unmodified? | +| ----------------------------------------------- |:-----------------:|:---------------------------:|:-------------------:| +| [Queue with Pod Per Work Item] | ✓ | | sometimes | +| [Queue with Variable Pod Count] | ✓ | ✓ | | +| [Indexed Job with Static Work Assignment] | ✓ | | ✓ | +| [Job with Pod-to-Pod Communication] | ✓ | sometimes | sometimes | +| [Job Template Expansion] | | | ✓ | + +When you specify completions with `.spec.completions`, each Pod created by the Job controller +has an identical [`spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status). +This means that all pods for a task will have the same command line and the same +image, the same volumes, and (almost) the same environment variables. These patterns +are different ways to arrange for pods to work on different things. + +This table shows the required settings for `.spec.parallelism` and `.spec.completions` for each of the patterns. +Here, `W` is the number of work items. + +| Pattern | `.spec.completions` | `.spec.parallelism` | +| ----------------------------------------------- |:-------------------:|:--------------------:| +| [Queue with Pod Per Work Item] | W | any | +| [Queue with Variable Pod Count] | null | any | +| [Indexed Job with Static Work Assignment] | W | any | +| [Job with Pod-to-Pod Communication] | W | W | +| [Job Template Expansion] | 1 | should be 1 | + +[Queue with Pod Per Work Item]: /docs/tasks/job/coarse-parallel-processing-work-queue/ +[Queue with Variable Pod Count]: /docs/tasks/job/fine-parallel-processing-work-queue/ +[Indexed Job with Static Work Assignment]: /docs/tasks/job/indexed-parallel-processing-static/ +[Job with Pod-to-Pod Communication]: /docs/tasks/job/job-with-pod-to-pod-communication/ +[Job Template Expansion]: /docs/tasks/job/parallel-processing-expansion/ + +## Advanced usage + +### Suspending a Job + +{{< feature-state for_k8s_version="v1.24" state="stable" >}} + +When a Job is created, the Job controller will immediately begin creating Pods +to satisfy the Job's requirements and will continue to do so until the Job is +complete. However, you may want to temporarily suspend a Job's execution and +resume it later, or start Jobs in suspended state and have a custom controller +decide later when to start them. + +To suspend a Job, you can update the `.spec.suspend` field of +the Job to true; later, when you want to resume it again, update it to false. +Creating a Job with `.spec.suspend` set to true will create it in the suspended +state. + +When a Job is resumed from suspension, its `.status.startTime` field will be +reset to the current time. This means that the `.spec.activeDeadlineSeconds` +timer will be stopped and reset when a Job is suspended and resumed. + +When you suspend a Job, any running Pods that don't have a status of `Completed` +will be [terminated](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) +with a SIGTERM signal. The Pod's graceful termination period will be honored and +your Pod must handle this signal in this period. This may involve saving +progress for later or undoing changes. Pods terminated this way will not count +towards the Job's `completions` count. + +An example Job definition in the suspended state can be like so: + +```shell +kubectl get job myjob -o yaml +``` + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: myjob +spec: + suspend: true + parallelism: 1 + completions: 5 + template: + spec: + ... +``` + +You can also toggle Job suspension by patching the Job using the command line. + +Suspend an active Job: + +```shell +kubectl patch job/myjob --type=strategic --patch '{"spec":{"suspend":true}}' +``` + +Resume a suspended Job: + +```shell +kubectl patch job/myjob --type=strategic --patch '{"spec":{"suspend":false}}' +``` + +The Job's status can be used to determine if a Job is suspended or has been +suspended in the past: + +```shell +kubectl get jobs/myjob -o yaml +``` + +```yaml +apiVersion: batch/v1 +kind: Job +# .metadata and .spec omitted +status: + conditions: + - lastProbeTime: "2021-02-05T13:14:33Z" + lastTransitionTime: "2021-02-05T13:14:33Z" + status: "True" + type: Suspended + startTime: "2021-02-05T13:13:48Z" +``` + +The Job condition of type "Suspended" with status "True" means the Job is +suspended; the `lastTransitionTime` field can be used to determine how long the +Job has been suspended for. If the status of that condition is "False", then the +Job was previously suspended and is now running. If such a condition does not +exist in the Job's status, the Job has never been stopped. + +Events are also created when the Job is suspended and resumed: + +```shell +kubectl describe jobs/myjob +``` + +``` +Name: myjob +... +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal SuccessfulCreate 12m job-controller Created pod: myjob-hlrpl + Normal SuccessfulDelete 11m job-controller Deleted pod: myjob-hlrpl + Normal Suspended 11m job-controller Job suspended + Normal SuccessfulCreate 3s job-controller Created pod: myjob-jvb44 + Normal Resumed 3s job-controller Job resumed +``` + +The last four events, particularly the "Suspended" and "Resumed" events, are +directly a result of toggling the `.spec.suspend` field. In the time between +these two events, we see that no Pods were created, but Pod creation restarted +as soon as the Job was resumed. + +### Mutable Scheduling Directives + +{{< feature-state for_k8s_version="v1.27" state="stable" >}} + +In most cases, a parallel job will want the pods to run with constraints, +like all in the same zone, or all either on GPU model x or y but not a mix of both. + +The [suspend](#suspending-a-job) field is the first step towards achieving those semantics. Suspend allows a +custom queue controller to decide when a job should start; However, once a job is unsuspended, +a custom queue controller has no influence on where the pods of a job will actually land. + +This feature allows updating a Job's scheduling directives before it starts, which gives custom queue +controllers the ability to influence pod placement while at the same time offloading actual +pod-to-node assignment to kube-scheduler. This is allowed only for suspended Jobs that have never +been unsuspended before. + +The fields in a Job's pod template that can be updated are node affinity, node selector, +tolerations, labels, annotations and [scheduling gates](/docs/concepts/scheduling-eviction/pod-scheduling-readiness/). + +### Specifying your own Pod selector + +Normally, when you create a Job object, you do not specify `.spec.selector`. +The system defaulting logic adds this field when the Job is created. +It picks a selector value that will not overlap with any other jobs. + +However, in some cases, you might need to override this automatically set selector. +To do this, you can specify the `.spec.selector` of the Job. + +Be very careful when doing this. If you specify a label selector which is not +unique to the pods of that Job, and which matches unrelated Pods, then pods of the unrelated +job may be deleted, or this Job may count other Pods as completing it, or one or both +Jobs may refuse to create Pods or run to completion. If a non-unique selector is +chosen, then other controllers (e.g. ReplicationController) and their Pods may behave +in unpredictable ways too. Kubernetes will not stop you from making a mistake when +specifying `.spec.selector`. + +Here is an example of a case when you might want to use this feature. + +Say Job `old` is already running. You want existing Pods +to keep running, but you want the rest of the Pods it creates +to use a different pod template and for the Job to have a new name. +You cannot update the Job because these fields are not updatable. +Therefore, you delete Job `old` but _leave its pods +running_, using `kubectl delete jobs/old --cascade=orphan`. +Before deleting it, you make a note of what selector it uses: + +```shell +kubectl get job old -o yaml +``` + +The output is similar to this: + +```yaml +kind: Job +metadata: + name: old + ... +spec: + selector: + matchLabels: + batch.kubernetes.io/controller-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002 + ... +``` + +Then you create a new Job with name `new` and you explicitly specify the same selector. +Since the existing Pods have label `batch.kubernetes.io/controller-uid=a8f3d00d-c6d2-11e5-9f87-42010af00002`, +they are controlled by Job `new` as well. + +You need to specify `manualSelector: true` in the new Job since you are not using +the selector that the system normally generates for you automatically. + +```yaml +kind: Job +metadata: + name: new + ... +spec: + manualSelector: true + selector: + matchLabels: + batch.kubernetes.io/controller-uid: a8f3d00d-c6d2-11e5-9f87-42010af00002 + ... +``` + +The new Job itself will have a different uid from `a8f3d00d-c6d2-11e5-9f87-42010af00002`. Setting +`manualSelector: true` tells the system that you know what you are doing and to allow this +mismatch. + +### Job tracking with finalizers + +{{< feature-state for_k8s_version="v1.26" state="stable" >}} + +The control plane keeps track of the Pods that belong to any Job and notices if +any such Pod is removed from the API server. To do that, the Job controller +creates Pods with the finalizer `batch.kubernetes.io/job-tracking`. The +controller removes the finalizer only after the Pod has been accounted for in +the Job status, allowing the Pod to be removed by other controllers or users. + +{{< note >}} +See [My pod stays terminating](/docs/tasks/debug/debug-application/debug-pods/) if you +observe that pods from a Job are stuck with the tracking finalizer. +{{< /note >}} + +### Elastic Indexed Jobs + +{{< feature-state feature_gate_name="ElasticIndexedJob" >}} + +You can scale Indexed Jobs up or down by mutating both `.spec.parallelism` +and `.spec.completions` together such that `.spec.parallelism == .spec.completions`. +When scaling down, Kubernetes removes the Pods with higher indexes. + +Use cases for elastic Indexed Jobs include batch workloads which require +scaling an indexed Job, such as MPI, Horovod, Ray, and PyTorch training jobs. + +### Delayed creation of replacement pods {#pod-replacement-policy} + +{{< feature-state for_k8s_version="v1.29" state="beta" >}} + +{{< note >}} +You can only set `podReplacementPolicy` on Jobs if you enable the `JobPodReplacementPolicy` +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) +(enabled by default). +{{< /note >}} + +By default, the Job controller recreates Pods as soon they either fail or are terminating (have a deletion timestamp). +This means that, at a given time, when some of the Pods are terminating, the number of running Pods for a Job +can be greater than `parallelism` or greater than one Pod per index (if you are using an Indexed Job). + +You may choose to create replacement Pods only when the terminating Pod is fully terminal (has `status.phase: Failed`). +To do this, set the `.spec.podReplacementPolicy: Failed`. +The default replacement policy depends on whether the Job has a `podFailurePolicy` set. +With no Pod failure policy defined for a Job, omitting the `podReplacementPolicy` field selects the +`TerminatingOrFailed` replacement policy: +the control plane creates replacement Pods immediately upon Pod deletion +(as soon as the control plane sees that a Pod for this Job has `deletionTimestamp` set). +For Jobs with a Pod failure policy set, the default `podReplacementPolicy` is `Failed`, and no other +value is permitted. +See [Pod failure policy](#pod-failure-policy) to learn more about Pod failure policies for Jobs. + +```yaml +kind: Job +metadata: + name: new + ... +spec: + podReplacementPolicy: Failed + ... +``` + +Provided your cluster has the feature gate enabled, you can inspect the `.status.terminating` field of a Job. +The value of the field is the number of Pods owned by the Job that are currently terminating. + +```shell +kubectl get jobs/myjob -o yaml +``` + +```yaml +apiVersion: batch/v1 +kind: Job +# .metadata and .spec omitted +status: + terminating: 3 # three Pods are terminating and have not yet reached the Failed phase +``` + +### Delegation of managing a Job object to external controller + +{{< feature-state feature_gate_name="JobManagedBy" >}} + +{{< note >}} +You can only set the `managedBy` field on Jobs if you enable the `JobManagedBy` +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) +(enabled by default). +{{< /note >}} + +This feature allows you to disable the built-in Job controller, for a specific +Job, and delegate reconciliation of the Job to an external controller. + +You indicate the controller that reconciles the Job by setting a custom value +for the `spec.managedBy` field - any value +other than `kubernetes.io/job-controller`. The value of the field is immutable. + +{{< note >}} +When using this feature, make sure the controller indicated by the field is +installed, otherwise the Job may not be reconciled at all. +{{< /note >}} + +{{< note >}} +When developing an external Job controller be aware that your controller needs +to operate in a fashion conformant with the definitions of the API spec and +status fields of the Job object. + +Please review these in detail in the [Job API](/docs/reference/kubernetes-api/workload-resources/job-v1/). +We also recommend that you run the e2e conformance tests for the Job object to +verify your implementation. + +Finally, when developing an external Job controller make sure it does not use the +`batch.kubernetes.io/job-tracking` finalizer, reserved for the built-in controller. +{{< /note >}} + +{{< warning >}} +If you are considering to disable the `JobManagedBy` feature gate, or to +downgrade the cluster to a version without the feature gate enabled, check if +there are jobs with a custom value of the `spec.managedBy` field. If there +are such jobs, there is a risk that they might be reconciled by two controllers +after the operation: the built-in Job controller and the external controller +indicated by the field value. +{{< /warning >}} + +## Alternatives + +### Bare Pods + +When the node that a Pod is running on reboots or fails, the pod is terminated +and will not be restarted. However, a Job will create new Pods to replace terminated ones. +For this reason, we recommend that you use a Job rather than a bare Pod, even if your application +requires only a single Pod. + +### Replication Controller + +Jobs are complementary to [Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/). +A Replication Controller manages Pods which are not expected to terminate (e.g. web servers), and a Job +manages Pods that are expected to terminate (e.g. batch tasks). + +As discussed in [Pod Lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/), `Job` is *only* appropriate +for pods with `RestartPolicy` equal to `OnFailure` or `Never`. +(Note: If `RestartPolicy` is not set, the default value is `Always`.) + +### Single Job starts controller Pod + +Another pattern is for a single Job to create a Pod which then creates other Pods, acting as a sort +of custom controller for those Pods. This allows the most flexibility, but may be somewhat +complicated to get started with and offers less integration with Kubernetes. + +One example of this pattern would be a Job which starts a Pod which runs a script that in turn +starts a Spark master controller (see [spark example](https://github.com/kubernetes/examples/tree/master/staging/spark/README.md)), +runs a spark driver, and then cleans up. + +An advantage of this approach is that the overall process gets the completion guarantee of a Job +object, but maintains complete control over what Pods are created and how work is assigned to them. + +## {{% heading "whatsnext" %}} + +* Learn about [Pods](/docs/concepts/workloads/pods). +* Read about different ways of running Jobs: + * [Coarse Parallel Processing Using a Work Queue](/docs/tasks/job/coarse-parallel-processing-work-queue/) + * [Fine Parallel Processing Using a Work Queue](/docs/tasks/job/fine-parallel-processing-work-queue/) + * Use an [indexed Job for parallel processing with static work assignment](/docs/tasks/job/indexed-parallel-processing-static/) + * Create multiple Jobs based on a template: [Parallel Processing using Expansions](/docs/tasks/job/parallel-processing-expansion/) +* Follow the links within [Clean up finished jobs automatically](#clean-up-finished-jobs-automatically) + to learn more about how your cluster can clean up completed and / or failed tasks. +* `Job` is part of the Kubernetes REST API. + Read the {{< api-reference page="workload-resources/job-v1" >}} + object definition to understand the API for jobs. +* Read about [`CronJob`](/docs/concepts/workloads/controllers/cron-jobs/), which you + can use to define a series of Jobs that will run based on a schedule, similar to + the UNIX tool `cron`. +* Practice how to configure handling of retriable and non-retriable pod failures + using `podFailurePolicy`, based on the step-by-step [examples](/docs/tasks/job/pod-failure-policy/). diff --git a/content/fa/docs/concepts/workloads/management.md b/content/fa/docs/concepts/workloads/management.md new file mode 100644 index 0000000000000..0e063f7f5c993 --- /dev/null +++ b/content/fa/docs/concepts/workloads/management.md @@ -0,0 +1,439 @@ +--- +title: مدیریت بارکاری +content_type: concept +reviewers: +- xirehat +weight: 40 +--- + + + +شما برنامه خود را مستقر کرده و از طریق یک سرویس آن را در معرض نمایش قرار داده‌اید. حالا چه باید کرد؟ کوبرنتیز ابزارهای متعددی را برای کمک به شما در مدیریت استقرار برنامه، از جمله مقیاس‌بندی و به‌روزرسانی، ارائه می‌دهد. + + + +## سازمان‌دهی پیکربندی منابع + +بسیاری از برنامه‌ها نیاز به ایجاد چندین منبع دارند، مانند یک Deployment همراه با یک Service. +مدیریت چندین منبع را می‌توان با گروه‌بندی آن‌ها در یک فایل واحد (جداشده با `---` در YAML) ساده کرد. برای مثال: + +{{% code_sample file="application/nginx-app.yaml" %}} + +می‌توان چندین منبع را به همان روشی که یک منبع واحد ایجاد می‌شود، ساخت: + +```shell +kubectl apply -f https://k8s.io/examples/application/nginx-app.yaml +``` + +```none +service/my-nginx-svc created +deployment.apps/my-nginx created +``` + +منابع به ترتیبی که در فایل manifest ظاهر می‌شوند ایجاد می‌شوند. بنابراین بهتر است ابتدا Service را مشخص کنید، زیرا این کار اطمینان می‌دهد که زمان‌بندی‌کننده بتواند پادهای مرتبط با آن Service را هنگام ایجاد توسط کنترلرها (مانند Deployment) پخش کند. + +`kubectl apply` همچنین چندین آرگومان `-f` را می‌پذیرد: + +```shell +kubectl apply -f https://k8s.io/examples/application/nginx/nginx-svc.yaml \ + -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml +``` + + +توصیه می‌شود منابع مربوط به یک میکروسرویس یا لایه برنامه را در یک فایل قرار دهید و تمام فایل‌های مرتبط با برنامه خود را در یک دایرکتوری گروه‌بندی کنید. اگر لایه‌های برنامه شما با استفاده از DNS به یکدیگر متصل شوند، می‌توانید تمام اجزای پشته خود را با هم مستقر کنید. + +همچنین می‌توان یک URL را به عنوان منبع پیکربندی مشخص کرد که برای استقرار مستقیم از مانیفست‌ها در سیستم کنترل منبع شما مفید است: + +```shell +kubectl apply -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml +``` + +```none +deployment.apps/my-nginx created +``` + +اگر نیاز باشد تا مانیفست‌های بیشتری تعریف کنید، مانند افزودن یک ConfigMap، می‌توانید این کار را نیز انجام دهید. + +### ابزارهای خارجی + +در این بخش فقط رایج‌ترین ابزارهای مورد استفاده برای مدیریت بارکاری‌ها در کوبرنتیز فهرست شده‌اند. برای مشاهده فهرست کامل‌تر، قسمت [تعریف برنامه و ساخت تصویر](https://landscape.cncf.io/guide#app-definition-and-development--application-definition-image-build) در منظره {{< glossary_tooltip text="CNCF" term_id="cncf" >}} را ببینید. + +#### Helm {#external-tool-helm} + +{{% thirdparty-content single="true" %}} + +[Helm](https://helm.sh/) ابزاری برای مدیریت بسته‌های منابع از پیش‌پیکربندی‌شده‌ی کوبرنتیز است. این بسته‌ها به عنوان _Helm charts_ شناخته می‌شوند. + +#### Kustomize {#external-tool-kustomize} + +[Kustomize](https://kustomize.io/) یک مانیفست کوبرنتیز را پیمایش می‌کند تا گزینه‌های پیکربندی را اضافه، حذف یا به‌روزرسانی کند. این ابزار هم به صورت یک باینری مستقل و هم به عنوان یک [ویژگی بومی](/docs/tasks/manage-kubernetes-objects/kustomization/) در kubectl در دسترس است. + +## عملیات دسته جمعی در kubectl + +ایجاد منابع تنها عملیاتی نیست که `kubectl` می‌تواند به صورت دسته جمعی انجام دهد. همچنین می‌تواند نام منابع را از فایل‌های پیکربندی استخراج کند تا عملیات دیگری را انجام دهد، به ویژه برای حذف همان منابعی که ایجاد کرده‌اید: + +```shell +kubectl delete -f https://k8s.io/examples/application/nginx-app.yaml +``` + +```none +deployment.apps "my-nginx" deleted +service "my-nginx-svc" deleted +``` + +در مورد دو منبع، می‌توانید هر دو منبع را در خط فرمان با استفاده از سینتکس resource/name مشخص کنید: + +```shell +kubectl delete deployments/my-nginx services/my-nginx-svc +``` + +برای تعداد بیشتری از منابع، مشخص کردن انتخابگر (پرس و جوی برچسب) که با استفاده از `-l` یا `--selector` مشخص می‌شود، برای فیلتر کردن منابع بر اساس برچسب‌هایشان، آسان‌تر خواهد بود: + +```shell +kubectl delete deployment,services -l app=nginx +``` + +```none +deployment.apps "my-nginx" deleted +service "my-nginx-svc" deleted +``` + +### زنجیره‌سازی و فیلتر کردن + +از آنجا که `kubectl` نام منابع را با همان سینتکس پذیرفته شده خود نمایش می‌دهد، می‌توانید عملیات را زنجیره‌ای کنید +با استفاده از `$()` یا `xargs`: + +```shell +kubectl get $(kubectl create -f docs/concepts/cluster-administration/nginx/ -o name | grep service/ ) +kubectl create -f docs/concepts/cluster-administration/nginx/ -o name | grep service/ | xargs -i kubectl get '{}' +``` + +خروجی ممکن است مشابه زیر باشد: + +```none +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +my-nginx-svc LoadBalancer 10.0.0.208 80/TCP 0s +``` + +با استفاده از دستورات بالا، ابتدا منابع را زیر مسیر `examples/application/nginx/` ایجاد می‌کنید و با قالب خروجی `-o name` (هر منبع به صورت resource/name) آن‌ها را نمایش می‌دهید. سپس فقط سرویس‌ها را با `grep` فیلتر کرده و با دستور [`kubectl get`](/docs/reference/kubectl/generated/kubectl_get/) نمایش می‌دهید. + +### عملیات بازگشتی روی فایل‌های محلی + +اگر فایل‌های منبع خود را در چند زیرشاخه درون یک پوشه سازمان‌دهی کرده باشید، می‌توانید عملیات را به‌صورت بازگشتی روی زیرشاخه‌ها نیز انجام دهید، با اضافه کردن گزینه‌ی `--recursive` یا `-R` همراه با آرگومان `--filename`/`-f`. + +برای مثال، فرض کنید پوشه‌ای به نام `project/k8s/development` وجود دارد که تمام {{< glossary_tooltip text="manifست‌ها" term_id="manifest" >}} مورد نیاز برای محیط توسعه را بر اساس نوع منبع سازمان‌دهی کرده است: + +```none +project/k8s/development +├── configmap +│   └── my-configmap.yaml +├── deployment +│   └── my-deployment.yaml +└── pvc + └── my-pvc.yaml +``` + +به طور پیش‌فرض، انجام یک عملیات دسته‌ای در `project/k8s/development` در سطح اول دایرکتوری متوقف می‌شود و هیچ زیردایرکتوری را پردازش نمی‌کند. اگر سعی می‌کردید منابع را در این دایرکتوری با استفاده از دستور زیر ایجاد کنید، با خطا مواجه می‌شدیم: + +```shell +kubectl apply -f project/k8s/development +``` + +```none +error: you must provide one or more resources by argument or filename (.json|.yaml|.yml|stdin) +``` + +در عوض، آرگومان خط فرمان `--recursive` یا `-R` را به همراه آرگومان `--filename`/`-f` مشخص کنید: + +```shell +kubectl apply -f project/k8s/development --recursive +``` + +```none +configmap/my-config created +deployment.apps/my-deployment created +persistentvolumeclaim/my-pvc created +``` + +گزینه‌ی `--recursive` با هر عملیاتی که آرگومان `--filename`/`-f` را قبول می‌کند کار می‌کند، مانند: `kubectl create`، `kubectl get`، `kubectl delete`، `kubectl describe` یا حتی `kubectl rollout`. + +گزینه‌ی `--recursive` زمانی که چندین آرگومان `-f` ارائه شود نیز کار می‌کند: + +```shell +kubectl apply -f project/k8s/namespaces -f project/k8s/development --recursive +``` + +```none +namespace/development created +namespace/staging created +configmap/my-config created +deployment.apps/my-deployment created +persistentvolumeclaim/my-pvc created +``` + +اگر علاقه‌مندید درباره‌ی `kubectl` بیشتر بدانید، به سراغ مطالعه‌ی [ابزار خط فرمان (kubectl)](/docs/reference/kubectl/) بروید. + +## به‌روزرسانی برنامه بدون قطعی + +در مقطعی لازم است برنامه‌ی مستقر شما به‌روزرسانی شود، معمولاً با مشخص کردن +یک ایمیج یا تگ جدید. `kubectl` چندین عملیات به‌روزرسانی را پشتیبانی می‌کند که +هر کدام برای سناریوهای مختلف کاربرد دارد. + +می‌توانید چند نسخه از برنامه‌ی خود را اجرا کنید و از _rollout_ +برای انتقال تدریجی ترافیک به پادهای سالم جدید استفاده کنید. در نهایت، +همه‌ی پادهای اجراشده نرم‌افزار جدید را خواهند داشت. + +این بخش از صفحه راهنمای شما برای ایجاد و به‌روزرسانی برنامه‌ها با استفاده از Deployment‌هاست. + +فرض کنید شما در حال اجرای نسخه‌ی 1.14.2 از nginx بودید: + +```shell +kubectl create deployment my-nginx --image=nginx:1.14.2 +``` + +```none +deployment.apps/my-nginx created +``` + +مطمئن شوید که ۱ کپی وجود دارد: + +```shell +kubectl scale --replicas 1 deployments/my-nginx --subresource='scale' --type='merge' -p '{"spec":{"replicas": 1}}' +``` + +```none +deployment.apps/my-nginx scaled +``` + +و با تنظیم حداکثر افزایش ناگهانی (surge maximum) روی ۱۰۰٪، به کوبرنتیز اجازه دهید در طول یک انتشار، کپی‌های موقت بیشتری اضافه کند: + +```shell +kubectl patch --type='merge' -p '{"spec":{"strategy":{"rollingUpdate":{"maxSurge": "100%" }}}}' +``` + +```none +deployment.apps/my-nginx patched +``` + +برای به‌روزرسانی به نسخه 1.16.1، با استفاده از `kubectl edit`، `.spec.template.spec.containers[0].image` را از `nginx:1.14.2` به `nginx:1.16.1` تغییر دهید: + +```shell +kubectl edit deployment/my-nginx +# مانیفست را تغییر دهید تا از تصویر کانتینر جدیدتر استفاده کند، سپس تغییرات خود را ذخیره کنید +``` + +همین بود! Deployment به‌صورت بیانی (declarative) برنامه‌ی nginx مستقر را به‌تدریج در پس‌زمینه به‌روزرسانی می‌کند. این کار تضمین می‌کند که در حین به‌روزرسانی تنها تعدادی مشخص از نسخه‌های قدیمی ممکن است از دسترس خارج شوند و تنها تعداد مشخصی از نسخه‌های جدید بالاتر از تعداد مطلوب پادها ایجاد شوند. برای آگاهی از جزئیات بیشتر درباره‌ی نحوه‌ی انجام این عملیات، به [Deployment](/docs/concepts/workloads/controllers/deployment/) مراجعه کنید. + +می‌توانید از rollout با DaemonSetها، Deploymentها یا StatefulSetها استفاده کنید. + +### مدیریت rolloutها + +می‌توانید از دستور [`kubectl rollout`](/docs/reference/kubectl/generated/kubectl_rollout/) برای مدیریت به‌روزرسانی تدریجی برنامه‌ی موجود بهره ببرید. + +برای مثال: + +```shell +kubectl apply -f my-deployment.yaml + +# منتظر بمانید تا انتشار به پایان برسد +kubectl rollout status deployment/my-deployment --timeout 10m # تایم اوت ۱۰ دقیقه‌ای +``` + +or + +```shell +kubectl apply -f backing-stateful-component.yaml + +# منتظر پایان انتشار نباشید، فقط وضعیت را بررسی کنید +kubectl rollout status statefulsets/backing-stateful-component --watch=false +``` + +می‌توانید rollout را متوقف (`pause`)، ادامه (`resume`) یا لغو (`cancel`) کنید. +برای کسب اطلاعات بیشتر به [`kubectl rollout`](/docs/reference/kubectl/generated/kubectl_rollout/) مراجعه کنید. + +## استقرارهای Canary + + + +سناریوی دیگری که به چند برچسب نیاز دارد، تمایز بین استقرارهای نسخه‌ها یا پیکربندی‌های مختلف از یک مؤلفه مشابه است. معمولاً نسخه‌ای آزمایشی (*canary*) از انتشار جدید یک برنامه (مشخص‌شده از طریق تگ ایمیج در قالب پاد) کنار نسخه‌ی قبلی مستقر می‌شود تا انتشار جدید بتواند ترافیک تولید زنده را قبل از استقرار کامل دریافت کند. + +برای مثال، می‌توانید از برچسب `track` برای تمایز انتشارهای مختلف استفاده کنید. + +انتشار اصلی و پایدار دارای برچسب `track` با مقدار `stable` خواهد بود: + +```none +name: frontend +replicas: 3 +... +labels: + app: guestbook + tier: frontend + track: stable +... +image: gb-frontend:v3 +``` + +و سپس می‌توانید یک نسخه جدید از frontend guestbook ایجاد کنید که برچسب `track` را با مقدار متفاوت (مثلاً `canary`) داشته باشد، به طوری که دو مجموعه از podها با هم همپوشانی نداشته باشند: + +```none +name: frontend-canary +replicas: 1 +... +labels: + app: guestbook + tier: frontend + track: canary +... +image: gb-frontend:v4 +``` + +سرویس frontend با انتخاب زیرمجموعه مشترک برچسب‌های هر دو مجموعه کپی (replica) (یعنی حذف برچسب `track`) آنها، هر دو مجموعه را پوشش می‌دهد، به طوری که ترافیک به هر دو برنامه هدایت شود: + +```yaml +selector: + app: guestbook + tier: frontend +``` + +شما می‌توانید تعداد کپی‌های نسخه‌های پایدار و قناری را تغییر دهید تا نسبت هر نسخه‌ای که ترافیک تولید زنده را دریافت می‌کند (در این مورد، ۳:۱) را تعیین کنید. + +پس از اطمینان، می‌توانید مسیر پایدار را با نسخه جدید برنامه به‌روزرسانی کرده و مسیر قناری را حذف کنید. + +## به‌روزرسانی حاشیه‌نویسی‌ها + +گاهی اوقات می‌خواهید حاشیه‌نویسی‌ها را به منابع پیوست کنید. حاشیه‌نویسی‌ها، فراداده‌های دلخواه و غیرشناسایی هستند که برای بازیابی توسط کلاینت‌های API مانند ابزارها یا کتابخانه‌ها استفاده می‌شوند. + +این کار را می‌توان با `kubectl annotate` انجام داد. به عنوان مثال: + +```shell +kubectl annotate pods my-nginx-v4-9gw19 description='my frontend running nginx' +kubectl get pods my-nginx-v4-9gw19 -o yaml +``` + +```shell +apiVersion: v1 +kind: pod +metadata: + annotations: + description: my frontend running nginx +... +``` + +برای اطلاعات بیشتر، به [annotations](/docs/concepts/overview/working-with-objects/annotations/) +و [kubectl annotate](/docs/reference/kubectl/generated/kubectl_annotate/) مراجعه کنید. + +## مقیاس‌دهی برنامه شما + +وقتی بار روی برنامه شما افزایش یا کاهش می‌یابد، از `kubectl` برای مقیاس‌دهی برنامه خود استفاده کنید. +برای مثال، برای کاهش تعداد replica‌های nginx از ۳ به ۱، دستور زیر را اجرا کنید: + +```shell +kubectl scale deployment/my-nginx --replicas=1 +``` + +```none +deployment.apps/my-nginx scaled +``` + +حالا شما فقط یک پاد دارید که توسط استقرار مدیریت می‌شود. + +```shell +kubectl get pods -l app=nginx +``` + +```none +NAME READY STATUS RESTARTS AGE +my-nginx-2035384211-j5fhi 1/1 Running 0 30m +``` + +برای اینکه سیستم به طور خودکار تعداد کپی‌های nginx مورد نیاز را از ۱ تا ۳ انتخاب کند، مراحل زیر را انجام دهید: + +```shell +# این امر مستلزم وجود منبع موجود از معیارهای کانتینر و پاد است. +kubectl autoscale deployment/my-nginx --min=1 --max=3 +``` + +```none +horizontalpodautoscaler.autoscaling/my-nginx autoscaled +``` + +اکنون replica‌های nginx شما به‌طور خودکار بر اساس نیاز بالا و پایین مقیاس‌دهی خواهند شد. + +برای اطلاعات بیشتر، لطفاً به مستندات +[kubectl scale](/docs/reference/kubectl/generated/kubectl_scale/) +[kubectl autoscale](/docs/reference/kubectl/generated/kubectl_autoscale/) +و [horizontal pod autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/) مراجعه کنید. + +## به‌روزرسانی منابع در محل + +گاهی لازم است به‌روزرسانی‌های جزئی و غیرمخرب روی منابعی که ایجاد کرده‌اید انجام دهید. + +### kubectl apply + +پیشنهاد می‌شود مجموعه‌ای از فایل‌های پیکربندی را در کنترل نسخه نگه دارید +(برای اطلاعات بیشتر نگاه کنید به [configuration as code](https://martinfowler.com/bliki/InfrastructureAsCode.html)) +تا بتوان آن‌ها را همراه با کد منابع‌شان نگهداری و نسخه‌بندی کرد. +سپس می‌توانید از [`kubectl apply`](/docs/reference/kubectl/generated/kubectl_apply/) +برای اعمال تغییرات پیکربندی خود به خوشه استفاده کنید. + +این دستور نسخه‌ی پیکربندی ارسالی شما را با نسخه‌ی قبلی مقایسه کرده و تغییراتی را که اعمال کرده‌اید به‌کار می‌گیرد، +بدون آنکه تغییرات خودکار روی ویژگی‌هایی که مشخص نکرده‌اید را بازنویسی کند. + +```shell +kubectl apply -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml +``` + +```none +deployment.apps/my-nginx configured +``` + +برای آشنایی بیشتر با مکانیزم زیرساخت، [server-side apply](/docs/reference/using-api/server-side-apply/) را بخوانید. + +### kubectl edit + +به‌علاوه، می‌توانید منابع را با دستور [`kubectl edit`](/docs/reference/kubectl/generated/kubectl_edit/) نیز به‌روزرسانی کنید: + +```shell +kubectl edit deployment/my-nginx +``` + +این معادل این است که ابتدا منبع را با `get` دریافت کنید، آن را در ویرایشگر متن ویرایش کنید و سپس با نسخه به‌روزرسانی‌شده، منبع را با `apply` اعمال نمایید: + +```shell +kubectl get deployment my-nginx -o yaml > /tmp/nginx.yaml +vi /tmp/nginx.yaml +# کمی ویرایش انجام دهید و سپس فایل را ذخیره کنید + +kubectl apply -f /tmp/nginx.yaml +deployment.apps/my-nginx configured + +rm /tmp/nginx.yaml +``` + +این امکان را فراهم می‌کند تا تغییرات بزرگ‌تر را با سهولت بیشتری انجام دهید. توجه کنید که می‌توانید ویرایشگر را با متغیرهای محیطی `EDITOR` یا `KUBE_EDITOR` مشخص کنید. + +برای اطلاعات بیشتر، لطفاً [kubectl edit](/docs/reference/kubectl/generated/kubectl_edit/) را ببینید. + +### kubectl patch + +می‌توانید با استفاده از دستور [`kubectl patch`](/docs/reference/kubectl/generated/kubectl_patch/) اشیاء API را در محل به‌روزرسانی کنید. این زیر‌دستور از JSON patch، JSON merge patch و strategic merge patch پشتیبانی می‌کند. + +برای جزئیات بیشتر، به [به‌روزرسانی اشیاء API در محل با استفاده از kubectl patch](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/) مراجعه کنید. + +## به‌روزرسانی‌های مخرب + +در برخی موارد، ممکن است نیاز باشد فیلدهای منبعی را که پس از مقداردهی اولیه قابل به‌روزرسانی نیستند، تغییر دهید، یا بخواهید بلافاصله تغییر بازگشتی انجام دهید، مثلاً برای اصلاح پادهای شکسته ایجادشده توسط یک Deployment. برای تغییر چنین فیلدهایی، از `replace --force` استفاده کنید که منبع را حذف کرده و مجدداً ایجاد می‌کند. در این حالت، می‌توانید فایل پیکربندی اصلی خود را ویرایش کنید: + +```shell +kubectl replace -f https://k8s.io/examples/application/nginx/nginx-deployment.yaml --force +``` + +```none +deployment.apps/my-nginx deleted +deployment.apps/my-nginx replaced +``` + + +## {{% heading "whatsnext" %}} + +- درباره‌ی [نحوه استفاده از `kubectl` برای بازرسی و اشکال‌زدایی برنامه](/docs/tasks/debug/debug-application/debug-running-pod/) بیاموزید. diff --git a/content/fa/docs/contribute/_index.md b/content/fa/docs/contribute/_index.md new file mode 100644 index 0000000000000..35953d9c4d5c5 --- /dev/null +++ b/content/fa/docs/contribute/_index.md @@ -0,0 +1,33 @@ +--- +content_type: concept +title: مشارکت در کوبرنتیز +linkTitle: مشارکت +main_menu: true +no_list: true +weight: 80 +card: + name: contribute + weight: 10 + title: مشارکت در کوبرنتیز +--- + +. + +راه‌های زیادی برای مشارکت در کوبرنتیز وجود دارد. می‌توانید روی طراحی قابلیت‌های جدید کار کنید، +کد موجود را مستند کنید یا برای [وب نوشت‌های ما](/docs/contribute/blog/) بنویسید. +بیش از این‌ها: می‌توانید آن قابلیت‌های جدید را پیاده‌سازی کرده یا باگ‌ها را رفع کنید. +می‌توانید به افراد برای پیوستن به جامعه مشارکت‌کنندگان کمک کنید یا از مشارکت‌کنندگان فعلی پشتیبانی کنید. + +با وجود این همه روش برای تأثیرگذاری بر پروژه، ما – کوبرنتیز – یک تارنما اختصاصی ساخته‌ایم: +https://k8s.dev. می‌توانید به آنجا بروید تا بیشتر درباره +مشارکت در کوبرنتیز بدانید. + +اگر به طور خاص می‌خواهید درباره مشارکت در مستندات یا بخش‌های دیگر _این_ تارنما یاد بگیرید، +[مشارکت در مستندات کوبرنتیز](/docs/contribute/docs/) را مطالعه کنید. +اگر به طور خاص می‌خواهید در وب نوشت‌های رسمی کوبرنتیز کمک کنید، +[مشارکت در وب نوشت‌های کوبرنتیز](/docs/contribute/blog/) را بخوانید. + +همچنین می‌توانید صفحه +[مشارکت‌کنندگان](https://contribute.cncf.io/contributors/projects/#kubernetes) +{{< glossary_tooltip text="CNCF" term_id="cncf" >}} +درباره مشارکت در کوبرنتیز را مطالعه کنید. diff --git a/content/fa/docs/contribute/blog/_index.md b/content/fa/docs/contribute/blog/_index.md new file mode 100644 index 0000000000000..741ba9af62d0e --- /dev/null +++ b/content/fa/docs/contribute/blog/_index.md @@ -0,0 +1,61 @@ +--- +title: مشارکت در وب نوشت‌های کوبرنتیز +slug: blog-contribution +content_type: concept +weight: 15 +simple_list: true +--- + + + +دو وب نوشت رسمی کوبرنتیز وجود دارد و CNCF نیز [وب نوشت اختصاصی خودش](https://www.cncf.io/blog/) را دارد که می‌توانید در آن نیز درباره کوبرنتیز بنویسید. +برای وب نوشت اصلی کوبرنتیز ما (پروژه کوبرنتیز) علاقه داریم مقالاتی با دیدگاه‌های گوناگون و تمرکزهای ویژه منتشر کنیم که به‌نوعی با کوبرنتیز در ارتباط باشند. + +به‌جز چند استثنای خاص، ما فقط محتوایی را منتشر می‌کنیم که پیش‌تر در هیچ جای دیگری ارسال یا منتشر نشده باشد. + +برای اطلاعات بیشتر در این باره، [راهنمای وب نوشت](/docs/contribute/blog/guidelines/#what-we-publish) را مطالعه کنید. + +## وب نوشت‌های رسمی کوبرنتیز + +### وب نوشت اصلی + +وب نوشت اصلی [کوبرنتیز](/blog/)توسط پروژه برای اطلاع‌رسانی درباره قابلیت‌های جدید، گزارش‌های جامعه و هر خبر مرتبط با جامعه کوبرنتیز استفاده می‌شود. این جامعه شامل کاربران نهایی و توسعه‌دهندگان است. بیش‌تر محتوای وب نوشت درباره رویدادهایی است که در هسته پروژه رخ می‌دهد؛ با این حال، پروژه کوبرنتیز شما را تشویق می‌کند که درباره اتفاقات دیگر در بن‌سازه نیز مطلب ارسال کنید! + +هر کسی می‌تواند یک مطلب وب نوشتی بنویسد و آن را برای انتشار ارسال کند. به‌جز چند استثنای خاص، ما فقط محتوایی را منتشر می‌کنیم که پیش‌تر در هیچ جای دیگری ارسال یا منتشر نشده باشد. + +### وب نوشت مشارکت‌کنندگان + +[وب نوشت مشارکت‌کنندگان کوبرنتیز](https://k8s.dev/blog/) برای مخاطبانی است که بیشتر **بر روی** کوبرنتیز کار می‌کنند تا افرادی که **با** کوبرنتیز کار می‌کنند. +پروژه کوبرنتیز عمداً برخی مقالات را در هر دو وبلاگ منتشر می‌کند. + +هر کسی می‌تواند یک مطلب وب نوشتی بنویسد و آن را برای بازبینی ارسال کند. + +## به‌روزرسانی و نگهداری مقاله {#maintenance} + +پروژه کوبرنتیز مقالات قدیمی وب نوشت‌های خود را نگه‌داری نمی‌کند. این بدان معناست که هر +مقاله منتشرشده‌ای که بیش از یک سال از انتشارش گذشته باشد، معمولاً برای دریافت مسئله +یا درخواست ادغام جهت اعمال تغییرات **واجد شرایط نیست**. برای جلوگیری از ایجاد رویه، حتی +درخواست ادغام‌های فنی و درست هم به احتمال زیاد رد می‌شوند. + +بااین‌حال، استثناهایی وجود دارند؛ مانند: + +* (به‌روزرسانی‌های) مقالاتی که به‌عنوان [همیشه‌سبز](#maintenance-evergreen) علامت خورده‌اند +* حذف یا اصلاح مقالاتی که اکنون توصیه‌های نادرست و خطرناک ارائه می‌دهند +* رفع خطاها برای اطمینان از این‌که یک مقاله موجود هنوز به‌درستی نمایش داده می‌شود + +برای هر مقاله‌ای که بیش از یک سال از انتشارش گذشته و به‌عنوان _evergreen_ علامت نخورده +است، تارنما به‌طور خودکار پیامی را نمایش می‌دهد مبنی بر این‌که محتوا ممکن است قدیمی باشد. + +### مقالات همیشه سبز {#maintenance-evergreen} + +می‌توانید با قرار دادن `evergreen: true` در مقدمه، یک مقاله را به‌عنوان همیشه‌سبز علامت‌گذاری کنید. + +ما فقط زمانی مقالات وب نوشت را به‌عنوان نگه‌داری‌شده (`evergreen: true` در مقدمه) علامت می‌زنیم که پروژه کوبرنتیز بتواند متعهد شود آن‌ها را برای همیشه نگه‌داری کند. برخی مقالات وب نوشت بدون تردید شایسته این هستند؛ برای نمونه، تیم ارتباطات انتشار همواره اعلان‌های رسمی را به‌عنوان همیشه‌سبز علامت می‌زند. + +## {{% heading "whatsnext" %}} + +* وب نوشت‌های رسمی را بخوانید: + * [وب نوشت کوبرنتیز](/blog/) + * [وب نوشت مشارکت‌کنندگان کوبرنتیز](https://k8s.dev/blog/) + +* درباره [درخواست ادغام بررسی وب نوشت](/docs/contribute/review/reviewing-prs/#blog) بخوانید. diff --git a/content/fa/docs/contribute/docs.md b/content/fa/docs/contribute/docs.md new file mode 100644 index 0000000000000..7ccc7d6eeb2ea --- /dev/null +++ b/content/fa/docs/contribute/docs.md @@ -0,0 +1,125 @@ +--- +content_type: concept +title: مشارکت در مستندات کوبرنتیز +weight: 09 +card: + name: contribute + weight: 11 + title: مشارکت در مستندات +--- + +این تارنما توسط [Kubernetes SIG Docs](/docs/contribute/#get-involved-with-sig-docs) نگه‌داری می‌شود. +پروژه کوبرنتیز از کمک همه مشارکت‌کنندگان، چه تازه‌کار و چه باتجربه، استقبال می‌کند! + +مشارکت‌کنندگان مستندات کوبرنتیز: + +- بهبود محتوای موجود +- ایجاد محتوای جدید +- ترجمه مستندات +- مدیریت و انتشار بخش‌های مستندات در چرخه انتشار کوبرنتیز + +تیم وب نوشت، که بخشی از SIG Docs است، به مدیریت وب نوشت‌های رسمی کمک می‌کند. برای کسب اطلاعات بیشتر، +[مشارکت در وب نوشت‌های کوبرنتیز](/docs/contribute/blog/) را بخوانید. + +--- + +{{< note >}} +برای کسب اطلاعات بیشتر درباره مشارکت در کوبرنتیز به‌طور کلی، به تارنما +[مستندات مشارکت‌کنندگان](https://www.kubernetes.dev/docs/) مراجعه کنید. +{{< /note >}} + + + + +## شروع کنید + +هر کسی می‌تواند برای مستندات یک مسئله باز کند یا تغییری را با یک +درخواست ادغام (PR) به +[مخزن GitHub `kubernetes/website`](https://github.com/kubernetes/website) ارائه کند. +برای کار مؤثر در جامعه کوبرنتیز لازم است با +[git](https://git-scm.com/) و +[GitHub](https://skills.github.com/) +آشنایی کافی داشته باشید. + +برای مشارکت در مستندات: + +1. توافق‌نامه مجوز مشارکت‌کنندگان CNCF را امضا کنید: + [Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md). +2. با [مخزن مستندات](https://github.com/kubernetes/website) + و [مولد سایت ایستای](https://gohugo.io) این تارنما آشنا شوید. +3. اطمینان حاصل کنید که فرآیندهای پایه برای + [باز کردن یک درخواست ادغام](/docs/contribute/new-content/open-a-pr/) و + [بازبینی تغییرات](/docs/contribute/review/reviewing-prs/) را می‌دانید. + + + + +قدم ۱. شروع به کار برای یک مشارکت‌کننده جدید. + +قدم ۱ یک نقشه راه برای مشارکت‌کنندگان تازه‌وارد ترسیم می‌کند. می‌توانید برخی یا همه مراحل «ثبت‌نام» (`Sign up`) و «بازبینی» (`Review`) را دنبال کنید. اکنون آماده‌اید تا PRهایی را باز کنید که اهداف مشارکت شما را برآورده سازند؛ برخی از این اهداف در بخش «ایجاد PR» (`Open PR`) فهرست شده‌اند. باز هم، پرسش‌ها همیشه خوش‌آمدند! + +برخی کارها به اعتماد و دسترسی بیشتری در سازمان کوبرنتیز نیاز دارند. برای جزئیات بیشتر درباره نقش‌ها و سطح دسترسی، [مشارکت در SIG Docs](/docs/contribute/participate/) را ببینید. + + +## اولین مشارکت شما + +شما می‌توانید با مرور چندین مرحله از قبل، برای اولین مشارکت خود آماده شوید. + +قدم ۲ مراحل و جزئیات بعدی را شرح می‌دهد. + + + + +قدم ۲. آماده‌سازی برای نخستین مشارکت شما. + +- برای آشنایی با روش‌های گوناگون مشارکت، [نمای کلی مشارکت](/docs/contribute/new-content/) را بخوانید. +- فهرست مسائل [`kubernetes/website`](https://github.com/kubernetes/website/issues/) را بررسی کنید تا سرنخ‌های مناسبی برای شروع بیابید. +- با [باز کردن یک درخواست ادغام با استفاده از GitHub](/docs/contribute/new-content/open-a-pr/#changes-using-github) برای مستندات موجود، با نحوه ثبت Issue در GitHub بیشتر آشنا شوید. +- [درخواست ادغام‌ها](/docs/contribute/review/reviewing-prs/)ی سایر اعضای جامعه کوبرنتیز را از نظر درستی و نگارش بازبینی کنید. +- راهنماهای [محتوا](/docs/contribute/style/content-guide/) و [سبک](/docs/contribute/style/style-guide/) کوبرنتیز را مطالعه کنید تا بتوانید دیدگاه‌های آگاهانه ارائه دهید. +- درباره [انواع محتوای صفحه](/docs/contribute/style/page-content-types/) و [کدهای کوتاه Hugo](/docs/contribute/style/hugo-shortcodes/) بیشتر بیاموزید. + + +## هنگام مشارکت کمک بگیرید + +ارائه نخستین مشارکت می‌تواند دلهره‌آور باشد. +[سفیران مشارکت‌کنندگان جدید](https://github.com/kubernetes/website#new-contributor-ambassadors) +برای همراهی شما در انجام چند مشارکت اول حضور دارند. می‌توانید از طریق +[Slack کوبرنتیز](https://slack.k8s.io/) و ترجیحاً در کانال `#sig-docs` با آن‌ها ارتباط بگیرید. +همچنین تماس [آشنایی و خوشامدگویی به مشارکت‌کنندگان جدید](https://www.kubernetes.dev/resources/calendar/) +در اولین سه‌شنبه هر ماه برگزار می‌شود. در آنجا می‌توانید با سفیران مشارکت‌کنندگان جدید تعامل کرده +و پرسش‌های خود را مطرح کنید. + + +## قدم‌های بعدی + + +- یاد بگیرید چگونه با [یک clone محلی مخزن](/docs/contribute/new-content/open-a-pr/#fork-the-repo) کار کنید. +- قابلیت‌های یک نسخه را [مستند کنید](/docs/contribute/new-content/new-features/). +- در [SIG Docs](/docs/contribute/participate/) مشارکت کنید و [عضو یا بازبین](/docs/contribute/participate/roles-and-responsibilities/) شوید. +- یک [بومی‌سازی](/docs/contribute/localization/) را آغاز کنید یا در آن کمک کنید. + + +## با SIG Docs همراه شوید + +[SIG Docs](/docs/contribute/participate/) گروهی از مشارکت‌کنندگان است که مستندات کوبرنتیز و تارنما آن را منتشر و نگه‌داری می‌کنند. درگیر شدن با SIG Docs راهی عالی برای مشارکت‌کنندگان کوبرنتیز (چه توسعه‌دهندگان قابلیت‌ها و چه سایر افراد) است تا تأثیر بزرگی بر پروژه کوبرنتیز بگذارند. + +SIG Docs با روش‌های مختلفی ارتباط برقرار می‌کند: + +- [به کانال `#sig-docs` در Slack کوبرنتیز بپیوندید](https://slack.k8s.io/). حتماً خودتان را معرفی کنید! +- به [لیست‌پستی `kubernetes-sig-docs`](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) ملحق شوید؛ مباحث گسترده‌تر در اینجا انجام می‌شود و تصمیم‌های رسمی ثبت می‌شوند. +- در [جلسه ویدئویی SIG Docs](https://github.com/kubernetes/community/tree/master/sig-docs) که هر دو هفته یک‌بار برگزار می‌شود شرکت کنید. این جلسات همیشه در `#sig-docs` اعلام شده و به [تقویم جلسات جامعه کوبرنتیز](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles) افزوده می‌شوند. لازم است [Zoom client](https://zoom.us/download) را نصب کنید یا از طریق تلفن وارد شوید. +- در هفته‌هایی که جلسه حضوری Zoom برگزار نمی‌شود، در جلسه ایستای غیرهمزمان (Async Stand-up) SIG Docs در Slack شرکت کنید. این جلسات نیز همیشه در `#sig-docs` اعلام می‌شوند. تا ۲۴ ساعت پس از اعلام جلسه می‌توانید در یکی از رشته‌ها مشارکت کنید. + + +## راه‌های دیگر برای مشارکت کردن + +- به [تارنما جامعه کوبرنتیز](/community/) سر بزنید. در توییتر یا Stack Overflow مشارکت کنید، + درباره گردهمایی‌ها و رویدادهای محلی کوبرنتیز و موارد دیگر مطلع شوید. +- [برگه تقلب مشارکت‌کنندگان](https://www.kubernetes.dev/docs/contributor-cheatsheet/) را بخوانید + تا در توسعه قابلیت‌های کوبرنتیز مشارکت کنید. +- از تارنما مشارکت‌کنندگان دیدن کنید تا درباره [مشارکت‌کنندگان کوبرنتیز](https://www.kubernetes.dev/) + و [منابع اضافی مشارکت‌کنندگان](https://www.kubernetes.dev/resources/) بیشتر بدانید. +- بیاموزید چگونه در [وب نوشت‌های رسمی مشارکت کنید](/docs/contribute/blog/) +- یک [مطالعه موردی](/docs/contribute/new-content/case-studies/) ارسال کنید + diff --git a/content/fa/docs/home/_index.md b/content/fa/docs/home/_index.md new file mode 100644 index 0000000000000..318c39edbc497 --- /dev/null +++ b/content/fa/docs/home/_index.md @@ -0,0 +1,67 @@ +--- +approvers: +- xirehat +title: مستندات کوبرنتیز +noedit: true +cid: docsHome +layout: docsportal_home +class: gridPage gridPageHome +linkTitle: "مستندات" +main_menu: true +weight: 10 +hide_feedback: true +menu: + main: + title: "مستندات" + weight: 10 +description: > + کوبرنتیز یک موتور هماهنگ‌سازی کانتینر متن‌باز برای خودکارسازی استقرار، مقیاس‌پذیری و مدیریت برنامه‌های کانتینری است. این پروژه متن‌باز توسط Cloud Native Computing Foundation میزبانی می‌شود. +overview: > + کوبرنتیز یک موتور ارکستراسیون کانتینر متن‌باز برای خودکارسازی استقرار، مقیاس‌گذاری و مدیریت برنامه‌های کانتینری است. این پروژه متن‌باز توسط Cloud Native Computing Foundation (CNCF) میزبانی می‌شود. +cards: +- name: concepts + title: "کوبرنتیز را درک کنید" + description: "آشنایی با کوبرنتیز و مفاهیم پایه آن." + button: "مشاهده مفاهیم" + button_path: "/docs/concepts" +- name: tutorials + title: "کوبرنتیز را امتحان کنید" + description: "برای یادگیری نحوه استقرار برنامه‌ها در کوبرنتیز، آموزش‌ها را دنبال کنید.." + button: "مشاهده آموزش‌ها" + button_path: "/docs/tutorials" +- name: setup + title: "یک خوشه کوبرنتیز راه‌اندازی کنید" + description: "اجرای کوبرنتیز بر اساس منابع و نیازهای شما." + button: "کوبرنتیز را راه‌اندازی کنید" + button_path: "/docs/setup" +- name: tasks + title: "یادگیری استفاده از کوبرنتیز" + description: "وظایف رایج و نحوه انجام آنها را با استفاده از یک توالی کوتاه از مراحل دنبال کنید." + button: "مشاهده وظایف" + button_path: "/docs/tasks" +- name: reference + title: جستجوی اطلاعات مرجع + description: مرور اصطلاحات، نحو خط فرمان، انواع منابع API و مستندات ابزار راه‌اندازی. + button: مشاهده مرجع + button_path: /docs/reference +- name: contribute + title: مشارکت در کوبرنتیز + description: دریابید که چگونه می‌توانید به بهبود کوبرنتیز کمک کنید. + button: راه‌های مشارکت را ببینید + button_path: "/docs/contribute" +- name: training + title: "آموزش" + description: "گواهینامه کوبرنتیز را دریافت کنید و پروژه‌های Cloud Native خود را با موفقیت به انجام برسانید.!" + button: "مشاهده آموزش" + button_path: "/training" +- name: Download + title: دانلود کوبرنتیز + description: کوبرنتیز را نصب کنید یا به جدیدترین نسخه ارتقا دهید. + button: "دانلود کوبرنتیز" + button_path: "/releases/download" +- name: about + title: درباره مستندات + description: این تارنما شامل مستندات مربوط به نسخه فعلی و ۴ نسخه قبلی کوبرنتیز است. + button: "نسخه‌های موجود را ببینید" + button_path: "/docs/home/supported-doc-versions" +--- diff --git a/content/fa/docs/home/supported-doc-versions.md b/content/fa/docs/home/supported-doc-versions.md new file mode 100644 index 0000000000000..bb52490d2b697 --- /dev/null +++ b/content/fa/docs/home/supported-doc-versions.md @@ -0,0 +1,10 @@ +--- +title: نسخه‌های مستندات موجود +content_type: custom +layout: supported-versions +weight: 10 +--- + +این وب‌سایت شامل مستندات نسخه فعلی کوبرنتیز و چهار نسخه پیشین آن است. + +وجود مستندات برای یک نسخه کوبرنتیز لزوماً به معنای پشتیبانی فعلی از آن انتشار نیست. برای آگاهی از این‌که کدام نسخه‌های کوبرنتیز به‌طور رسمی پشتیبانی می‌شوند و این پشتیبانی چه مدت ادامه دارد، [دوره پشتیبانی](/releases/patch-releases/#support-period) را مطالعه کنید. diff --git a/content/fa/docs/images/diagram-guide-example-3.svg b/content/fa/docs/images/diagram-guide-example-3.svg new file mode 100644 index 0000000000000..85fef139102a5 --- /dev/null +++ b/content/fa/docs/images/diagram-guide-example-3.svg @@ -0,0 +1 @@ +mecontrol planeapi-servercontrol planeetcd datastorecontrol planecontrollermanagercontrol planeschedulernodekubeletnodecontainerruntime1. kubectl create -f pod.yaml2. save new state3. check for changes4. watch for unassigned pods(s)5. notify about pod w nodename=" "6. assign pod to node7. save new state8. look for newly assigned pod(s)9. bind pod to node10. start container11. update pod status12. save new statemecontrol planeapi-servercontrol planeetcd datastorecontrol planecontrollermanagercontrol planeschedulernodekubeletnodecontainerruntime \ No newline at end of file diff --git a/content/fa/docs/images/gateway-kind-relationships.svg b/content/fa/docs/images/gateway-kind-relationships.svg new file mode 100644 index 0000000000000..cca73e75ce74f --- /dev/null +++ b/content/fa/docs/images/gateway-kind-relationships.svg @@ -0,0 +1 @@ +
cluster
GatewayClass
Gateway
HTTPRoute
 \ No newline at end of file diff --git a/content/fa/docs/images/gateway-request-flow.svg b/content/fa/docs/images/gateway-request-flow.svg new file mode 100644 index 0000000000000..a02852868ba2e --- /dev/null +++ b/content/fa/docs/images/gateway-request-flow.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/content/fa/docs/images/ha-control-plane.svg b/content/fa/docs/images/ha-control-plane.svg new file mode 100644 index 0000000000000..eb5bbdba81ce3 --- /dev/null +++ b/content/fa/docs/images/ha-control-plane.svg @@ -0,0 +1,4 @@ + + + + diff --git a/content/fa/docs/images/ingress.svg b/content/fa/docs/images/ingress.svg new file mode 100644 index 0000000000000..450a0aae9b4fa --- /dev/null +++ b/content/fa/docs/images/ingress.svg @@ -0,0 +1 @@ +
cluster
Ingress-managed
load balancer
routing rule
Ingress
Pod
Service
Pod
client
 \ No newline at end of file diff --git a/content/fa/docs/images/ingressFanOut.svg b/content/fa/docs/images/ingressFanOut.svg new file mode 100644 index 0000000000000..a6bf202635164 --- /dev/null +++ b/content/fa/docs/images/ingressFanOut.svg @@ -0,0 +1 @@ +
cluster
Ingress-managed
load balancer
/foo
/bar
Ingress, 178.91.123.132
Pod
Service service1:4200
Pod
Pod
Service service2:8080
Pod
client
 \ No newline at end of file diff --git a/content/fa/docs/images/ingressNameBased.svg b/content/fa/docs/images/ingressNameBased.svg new file mode 100644 index 0000000000000..7e1d7be98c60f --- /dev/null +++ b/content/fa/docs/images/ingressNameBased.svg @@ -0,0 +1 @@ +
cluster
Ingress-managed
load balancer
Host: foo.bar.com
Host: bar.foo.com
Ingress, 178.91.123.132
Pod
Service service1:80
Pod
Pod
Service service2:80
Pod
client
 \ No newline at end of file diff --git a/content/fa/docs/images/kubernetes-cluster-network.svg b/content/fa/docs/images/kubernetes-cluster-network.svg new file mode 100644 index 0000000000000..9fd7a49e18b44 --- /dev/null +++ b/content/fa/docs/images/kubernetes-cluster-network.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/content/fa/docs/images/podSchedulingGates.svg b/content/fa/docs/images/podSchedulingGates.svg new file mode 100644 index 0000000000000..c87b23a7c6ef4 --- /dev/null +++ b/content/fa/docs/images/podSchedulingGates.svg @@ -0,0 +1 @@ +
scheduling gate removed
no
yes
pod created
pod scheduling gated
pod scheduling ready
pod running
empty scheduling gates?
 \ No newline at end of file diff --git a/content/fa/docs/images/tutor-service-nodePort-fig01.svg b/content/fa/docs/images/tutor-service-nodePort-fig01.svg new file mode 100644 index 0000000000000..bb4d866f853f3 --- /dev/null +++ b/content/fa/docs/images/tutor-service-nodePort-fig01.svg @@ -0,0 +1 @@ +
SNAT
SNAT
client
Node 2
Node 1
Endpoint
 \ No newline at end of file diff --git a/content/fa/docs/images/tutor-service-nodePort-fig02.svg b/content/fa/docs/images/tutor-service-nodePort-fig02.svg new file mode 100644 index 0000000000000..1a891575e5f58 --- /dev/null +++ b/content/fa/docs/images/tutor-service-nodePort-fig02.svg @@ -0,0 +1 @@ +
client
Node 1
Node 2
endpoint
 \ No newline at end of file diff --git a/content/fa/docs/reference/_index.md b/content/fa/docs/reference/_index.md new file mode 100644 index 0000000000000..018f918309ac1 --- /dev/null +++ b/content/fa/docs/reference/_index.md @@ -0,0 +1,107 @@ +--- +title: مرجع +approvers: +- xirehat +linkTitle: "مرجع" +main_menu: true +weight: 70 +content_type: concept +no_list: true +--- + + + +این بخش از مستندات کوبرنتیز شامل ارجاعات است. + + + +## مرجع API + +* [واژه‌نامه](/docs/reference/glossary/) - فهرستی جامع و استاندارد از اصطلاحات کوبرنتیز + +* [مرجع API کوبرنتیز](/docs/reference/kubernetes-api/) +* [مرجع تک‌صفحه‌ای API برای کوبرنتیز {{< param "version" >}}](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) +* [استفاده از API کوبرنتیز](/docs/reference/using-api/) - نمای کلی API در کوبرنتیز +* [کنترل دسترسی API](/docs/reference/access-authn-authz/) - جزئیاتی درباره نحوه کنترل دسترسی به API در کوبرنتیز +* [برچسب‌ها، حاشیه‌نویسی‌ها و لکه‌های (Taints) شناخته‌شده](/docs/reference/labels-annotations-taints/) + +## کتابخانه‌های client با پشتیبانی رسمی + +برای فراخوانی API کوبرنتیز از یک زبان برنامه‌نویسی، می‌توانید از +[کتابخانه‌ها](/docs/reference/using-api/client-libraries/) استفاده کنید. +کتابخانه‌هایی که به‌طور رسمی پشتیبانی می‌شوند: + +- [Kubernetes Go client library](https://github.com/kubernetes/client-go/) +- [Kubernetes Python client library](https://github.com/kubernetes-client/python) +- [Kubernetes Java client library](https://github.com/kubernetes-client/java) +- [Kubernetes JavaScript client library](https://github.com/kubernetes-client/javascript) +- [Kubernetes C# client library](https://github.com/kubernetes-client/csharp) +- [Kubernetes Haskell client library](https://github.com/kubernetes-client/haskell) + +## خط فرمان + +* [kubectl](/docs/reference/kubectl/) - ابزار خط فرمان اصلی برای اجرای دستورها و مدیریت خوشه‌های کوبرنتیز. + * [JSONPath](/docs/reference/kubectl/jsonpath/) - راهنمای نحوی برای استفاده از [عبارات JSONPath](https://goessner.net/articles/JsonPath/) با kubectl. +* [kubeadm](/docs/reference/setup-tools/kubeadm/) - ابزار خط فرمانی برای راه‌اندازی آسان یک خوشه ایمن کوبرنتیز. + +## اجزا + +* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) - عامل اصلی‌ای که روی هر گره اجرا می‌شود. kubelet مجموعه‌ای از PodSpecها را می‌گیرد و اطمینان حاصل می‌کند کانتینرهای توصیف‌شده در حال اجرا و سالم هستند. +* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) - یک REST API که داده‌های اشیای API مانند پادها، سرویس‌ها و replication controllerها را اعتبارسنجی و پیکربندی می‌کند. +* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) - یک Daemon ای که حلقه‌های کنترل اصلی همراه کوبرنتیز را در خود جای داده است. +* [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - می‌تواند ارسال ساده جریان TCP/UDP یا ارسال TCP/UDP به‌صورت round-robin را بین مجموعه‌ای از بک‌اندها انجام دهد. +* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) - زمان‌بندی‌کننده‌ای که دسترس‌پذیری، عملکرد و ظرفیت را مدیریت می‌کند. + * [Scheduler Policies](/docs/reference/scheduling/policies) + * [Scheduler Profiles](/docs/reference/scheduling/config#profiles) + +* فهرست [ports and protocols](/docs/reference/networking/ports-and-protocols/) که باید روی گره‌های Control Plain و Worker باز باشند + +## پیکربندی APIها + +This section hosts the documentation for "unpublished" APIs which are used to +configure kubernetes components or tools. Most of these APIs are not exposed +by the API server in a RESTful way though they are essential for a user or an +operator to use or manage a cluster. + +این بخش میزبان مستندات APIهای «منتشر نشده» است که برای پیکربندی اجزا یا ابزارهای کوبرنتیز استفاده می‌شوند. اکثر این APIها توسط سرور API به روش RESTful در معرض نمایش قرار نمی‌گیرند، اگرچه برای کاربر یا اپراتور جهت استفاده یا مدیریت یک خوشه ضروری هستند. + +* [kubeconfig (v1)](/docs/reference/config-api/kubeconfig.v1/) +* [kuberc (v1alpha1)](/docs/reference/config-api/kuberc.v1alpha1/) +* [kube-apiserver admission (v1)](/docs/reference/config-api/apiserver-admission.v1/) +* [kube-apiserver configuration (v1alpha1)](/docs/reference/config-api/apiserver-config.v1alpha1/) و +* [kube-apiserver configuration (v1beta1)](/docs/reference/config-api/apiserver-config.v1beta1/) و + [kube-apiserver configuration (v1)](/docs/reference/config-api/apiserver-config.v1/) +* [kube-apiserver event rate limit (v1alpha1)](/docs/reference/config-api/apiserver-eventratelimit.v1alpha1/) +* [kubelet configuration (v1alpha1)](/docs/reference/config-api/kubelet-config.v1alpha1/) و + [kubelet configuration (v1beta1)](/docs/reference/config-api/kubelet-config.v1beta1/) + [kubelet configuration (v1)](/docs/reference/config-api/kubelet-config.v1/) +* [kubelet credential providers (v1)](/docs/reference/config-api/kubelet-credentialprovider.v1/) + [kube-scheduler configuration (v1)](/docs/reference/config-api/kube-scheduler-config.v1/) +* [kube-controller-manager configuration (v1alpha1)](/docs/reference/config-api/kube-controller-manager-config.v1alpha1/) +* [kube-proxy configuration (v1alpha1)](/docs/reference/config-api/kube-proxy-config.v1alpha1/) +* [`audit.k8s.io/v1` API](/docs/reference/config-api/apiserver-audit.v1/) +* [Client authentication API (v1beta1)](/docs/reference/config-api/client-authentication.v1beta1/) و + [Client authentication API (v1)](/docs/reference/config-api/client-authentication.v1/) +* [WebhookAdmission configuration (v1)](/docs/reference/config-api/apiserver-webhookadmission.v1/) +* [ImagePolicy API (v1alpha1)](/docs/reference/config-api/imagepolicy.v1alpha1/) + +## پیکربندی API برای kubeadm + +* [v1beta3](/docs/reference/config-api/kubeadm-config.v1beta3/) +* [v1beta4](/docs/reference/config-api/kubeadm-config.v1beta4/) + +## API های خارجی + +اینها APIهایی هستند که توسط پروژه کوبرنتیز تعریف شده‌اند، اما توسط پروژه اصلی پیاده‌سازی نشده‌اند: + +* [Metrics API (v1beta1)](/docs/reference/external-api/metrics.v1beta1/) +* [Custom Metrics API (v1beta2)](/docs/reference/external-api/custom-metrics.v1beta2) +* [External Metrics API (v1beta1)](/docs/reference/external-api/external-metrics.v1beta1) + +## اسناد طراحی + +آرشیوی از اسناد طراحی برای قابلیت‌های کوبرنتیز. نقاط شروع خوبی وجود دارد + +[معماری کوبرنتیز](https://git.k8s.io/design-proposals-archive/architecture/architecture.md) و +[مرور کلی طراحی کوبرنتیز](https://git.k8s.io/design-proposals-archive). + diff --git a/content/fa/docs/reference/glossary/addons.md b/content/fa/docs/reference/glossary/addons.md new file mode 100644 index 0000000000000..5f4cd52f432ea --- /dev/null +++ b/content/fa/docs/reference/glossary/addons.md @@ -0,0 +1,16 @@ +--- +title: افزونه‌ها +id: addons +date: 2019-12-15 +full_link: /docs/concepts/cluster-administration/addons/ +short_description: > + منابعی که عملکرد کوبرنتیز را گسترش می‌دهند. + +aka: +tags: +- tool +--- + منابعی که عملکرد کوبرنتیز را گسترش می‌دهند. + + +[نصب افزونه‌ها](/docs/concepts/cluster-administration/addons/) اطلاعات بیشتری در مورد استفاده از افزونه‌ها در خوشه شما ارائه می‌دهد و برخی از افزونه‌های محبوب را فهرست می‌کند. \ No newline at end of file diff --git a/content/fa/docs/reference/glossary/admission-controller.md b/content/fa/docs/reference/glossary/admission-controller.md new file mode 100644 index 0000000000000..115ae74c28396 --- /dev/null +++ b/content/fa/docs/reference/glossary/admission-controller.md @@ -0,0 +1,20 @@ +--- +title: مسئول پذیرش +id: admission-controller +date: 2019-06-28 +full_link: /docs/reference/access-authn-authz/admission-controllers/ +short_description: > + قطعه کدی که درخواست‌های ارسالی به سرور Kubernetes API را قبل از ماندگاری شیء، رهگیری می‌کند. + +aka: +tags: +- extension +- security +--- +قطعه کدی که درخواست‌های ارسالی به سرور Kubernetes API را قبل از ماندگاری شیء، رهگیری می‌کند. + + + +کنترل‌کننده‌های پذیرش برای سرور API کوبرنتیز قابل پیکربندی هستند و می‌توانند "اعتبارسنجی"، "تغییر" یا هر دو باشند. هر کنترل‌کننده پذیرش می‌تواند درخواست را رد کند. کنترل‌کننده‌های تغییر ممکن است اشیاء پذیرفته‌شده را تغییر دهند؛ کنترل‌کننده‌های اعتبارسنجی ممکن است این کار را نکنند. + +* [کنترل‌کننده‌های پذیرش در مستندات کوبرنتیز](/docs/reference/access-authn-authz/admission-controllers/) \ No newline at end of file diff --git a/content/fa/docs/reference/glossary/affinity.md b/content/fa/docs/reference/glossary/affinity.md new file mode 100644 index 0000000000000..66bec422c5718 --- /dev/null +++ b/content/fa/docs/reference/glossary/affinity.md @@ -0,0 +1,22 @@ +--- +title: وابستگی +id: affinity +date: 2019-01-11 +full_link: /docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity +short_description: > + قوانینی که توسط زمانبند برای تعیین محل قرارگیری پادها استفاده می‌شود +aka: +tags: +- fundamental +--- + +در Kubernetes، _affinity_ مجموعه‌ای از قوانین است که به برنامه‌ریز در مورد محل قرارگیری پادها راهنمایی می‌کند. + + +دو نوع affinity وجود دارد: +* [node affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity) +* [pod-to-pod affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity) + +قوانین با استفاده از Kubernetes {{< glossary_tooltip term_id="label" text="برچسب‌ها">}} +و {{< glossary_tooltip term_id="selector" text="انتخابگرها">}} که در {{< glossary_tooltip term_id="pod" text="پادها">}} مشخص شده‌اند تعریف می‌شوند، +و بسته به اینکه چقدر می‌خواهید Scheduler آنها را سخت‌گیرانه اعمال کند، می‌توانند اجباری (required) یا ترجیحی (preferred) باشند. diff --git a/content/fa/docs/reference/glossary/aggregation-layer.md b/content/fa/docs/reference/glossary/aggregation-layer.md new file mode 100644 index 0000000000000..817afacf36222 --- /dev/null +++ b/content/fa/docs/reference/glossary/aggregation-layer.md @@ -0,0 +1,19 @@ +--- +title: لایه تجمیع +id: aggregation-layer +date: 2018-10-08 +full_link: /docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/ +short_description: > + لایه تجمیع به شما امکان می‌دهد APIهای اضافی به سبک کوبرنتیز را در خوشه خود نصب کنید. + +aka: +tags: +- architecture +- extension +- operation +--- + لایه تجمیع به شما امکان می‌دهد APIهای اضافی به سبک کوبرنتیز را در خوشه خود نصب کنید. + + + +وقتی {{< glossary_tooltip text="سرور API کوبرنتیز" term_id="kube-apiserver" >}} را برای [پشتیبانی از APIهای اضافی](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) پیکربندی کرده‌اید، می‌توانید اشیای `APIService` را برای «ادعا کردن» یک مسیر URL در API کوبرنتیز اضافه کنید. diff --git a/content/fa/docs/reference/glossary/annotation.md b/content/fa/docs/reference/glossary/annotation.md new file mode 100644 index 0000000000000..ef228dca340d5 --- /dev/null +++ b/content/fa/docs/reference/glossary/annotation.md @@ -0,0 +1,16 @@ +--- +title: حاشیه‌نویسی +id: annotation +date: 2018-04-12 +full_link: /docs/concepts/overview/working-with-objects/annotations +short_description: > + یک جفت کلید-مقدار که برای الصاق فراداده‌های دلخواه و غیرشناسایی به اشیاء استفاده می‌شود. +aka: +tags: +- fundamental +--- + یک جفت کلید-مقدار که برای الصاق فراداده‌های دلخواه و غیرشناسایی به اشیاء استفاده می‌شود. + + + +فراداده‌های موجود در یک حاشیه‌نویسی می‌توانند کوچک یا بزرگ، ساختاریافته یا بدون ساختار باشند و می‌توانند شامل کاراکترهایی باشند که توسط {{< glossary_tooltip text="labels" term_id="label" >}} مجاز نیستند. کلاینت‌هایی مانند ابزارها و کتابخانه‌ها می‌توانند این فراداده‌ها را بازیابی کنند. diff --git a/content/fa/docs/reference/glossary/api-eviction.md b/content/fa/docs/reference/glossary/api-eviction.md new file mode 100644 index 0000000000000..80f792399ebdc --- /dev/null +++ b/content/fa/docs/reference/glossary/api-eviction.md @@ -0,0 +1,23 @@ +--- +title: اخراج با ابتکار API +id: api-eviction +date: 2021-04-27 +full_link: /docs/concepts/scheduling-eviction/api-eviction/ +short_description: > + حذف آغاز شده توسط API فرآیندی است که طی آن شما از API حذف برای ایجاد یک شیء حذف که باعث خاتمه غلاف دلپذیر می‌شود، استفاده می‌کنید. +aka: +tags: +- operation +--- +تبعید آغازشده توسط API فرایندی است که در آن از [API تبعید](/docs/reference/generated/kubernetes-api/{{}}/#create-eviction-pod-v1-core) برای ایجاد یک شیء `Eviction` استفاده می‌کنید که خاتمه‌ی نرم (graceful) پاد را راه‌اندازی می‌کند. + + + +شما می‌توانید درخواست تبعید را هم با فراخوانی مستقیم API تبعید از طریق یک کلاینت سرور API کوبرنتیز، مانند دستور `kubectl drain`، ارسال کنید. +وقتی یک شیء `Eviction` ایجاد شود، سرور API پاد را خاتمه می‌دهد. + +تبعید آغازشده توسط API از [`PodDisruptionBudgets`](/docs/tasks/run-application/configure-pdb/) و [`terminationGracePeriodSeconds`](/docs/concepts/workloads/pods/pod-lifecycle#pod-termination) پیکربندی‌شده‌ی شما پیروی می‌کند. + +تبعید آغازشده توسط API با [تبعید بر اثر فشار گره](/docs/concepts/scheduling-eviction/node-pressure-eviction/) یکسان نیست. + +* برای اطلاعات بیشتر به [تبعید آغازشده توسط API](/docs/concepts/scheduling-eviction/api-eviction/) مراجعه کنید. diff --git a/content/fa/docs/reference/glossary/api-group.md b/content/fa/docs/reference/glossary/api-group.md new file mode 100644 index 0000000000000..9615a07df7662 --- /dev/null +++ b/content/fa/docs/reference/glossary/api-group.md @@ -0,0 +1,19 @@ +--- +title: گروه API +id: api-group +date: 2019-09-02 +full_link: /docs/concepts/overview/kubernetes-api/#api-groups-and-versioning +short_description: > + مجموعه‌ای از مسیرهای مرتبط در API کوبرنتیز. + +aka: +tags: +- fundamental +- architecture +--- +مجموعه‌ای از مسیرهای مرتبط در API کوبرنتیز. + + +شما می‌توانید هر گروه API را با تغییر پیکربندی سرور API خود فعال یا غیرفعال کنید. همچنین می‌توانید مسیرهای مربوط به منابع خاص را غیرفعال یا فعال نمایید. گروه API افزودن قابلیت به API کوبرنتیز را آسان‌تر می‌کند. گروه API در مسیر REST و در فیلد `apiVersion` یک شیء سریال‌شده مشخص می‌شود. + +* برای اطلاعات بیشتر [گروه API](/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning) را بخوانید. diff --git a/content/fa/docs/reference/glossary/api-resource.md b/content/fa/docs/reference/glossary/api-resource.md new file mode 100644 index 0000000000000..436ee55673d0d --- /dev/null +++ b/content/fa/docs/reference/glossary/api-resource.md @@ -0,0 +1,17 @@ +--- +title: منبع API +id: api-resource +date: 2025-02-09 +full_link: /docs/reference/using-api/api-concepts/#standard-api-terminology +short_description: > + یک موجودیت کوبرنتیز، که نشان‌دهنده‌ی یک نقطه‌ی پایانی روی سرور کوبرنتیز API است. +aka: + - Resource +tags: +- architecture +--- +یک موجودیت در سیستم نوع کوبرنتیز، متناظر با یک نقطه‌انتهایی در {{< glossary_tooltip text="رابط برنامه‌نویسی کوبرنتیز" term_id="kubernetes-api" >}}. +یک منبع معمولاً نمایانگر یک {{< glossary_tooltip text="شیء" term_id="object" >}} است. +برخی از منابع نمایانگر عملیاتی روی اشیاء دیگر هستند، مانند بررسی مجوز. + +هر منبع یک نقطه‌انتهایی HTTP (URI) در سرور API کوبرنتیز را نمایش می‌دهد و طرح‌واره اشیاء یا عملیات روی آن منبع را تعریف می‌کند. \ No newline at end of file diff --git a/content/fa/docs/reference/glossary/app-container.md b/content/fa/docs/reference/glossary/app-container.md new file mode 100644 index 0000000000000..f25bb2e782923 --- /dev/null +++ b/content/fa/docs/reference/glossary/app-container.md @@ -0,0 +1,18 @@ +--- +title: کانتینر برنامه +id: app-container +date: 2019-02-12 +full_link: +short_description: > + کانتینری که برای اجرای بخشی از یک بار کاری استفاده می‌شود. با کانتینر init مقایسه کنید. + +aka: +tags: +- workload +--- + کانتینرهای برنامه (یا اپلیکیشن) {{< glossary_tooltip text="کانتینرها" term_id="container" >}} در یک {{< glossary_tooltip text="پاد" term_id="pod" >}} هستند که پس از اتمام هر {{< glossary_tooltip text="کانتینر‌های init" term_id="init-container" >}} اجرا می‌شوند. + + + +کانتینر init به شما اجازه می‌دهد جزئیات راه‌اندازی را که برای کل {{< glossary_tooltip text="بارکاری" term_id="workload" >}} مهم است و پس از شروع کانتینر برنامه نیازی به ادامه اجرا ندارند، جدا نگه دارید. +اگر برای یک پاد هیچ کانتینر init پیکربندی نشده باشد، تمام کانتینرهای آن پاد، کانتینر برنامه محسوب می‌شوند. diff --git a/content/fa/docs/reference/glossary/application-architect.md b/content/fa/docs/reference/glossary/application-architect.md new file mode 100644 index 0000000000000..6508a2979b4ca --- /dev/null +++ b/content/fa/docs/reference/glossary/application-architect.md @@ -0,0 +1,17 @@ +--- +title: معمار برنامه کاربردی +id: application-architect +date: 2018-04-12 +full_link: +short_description: > + شخصی که مسئول طراحی سطح بالای یک برنامه کاربردی است. + +aka: +tags: +- user-type +--- + شخصی که مسئول طراحی سطح بالای یک برنامه کاربردی است. + + + +یک معمار تضمین می‌کند که پیاده‌سازی یک برنامه به آن اجازه می‌دهد تا با اجزای اطراف خود به روشی مقیاس‌پذیر و قابل نگهداری تعامل داشته باشد. اجزای اطراف شامل پایگاه‌های داده، زیرساخت ثبت وقایع و سایر میکروسرویس‌ها هستند. diff --git a/content/fa/docs/reference/glossary/application-developer.md b/content/fa/docs/reference/glossary/application-developer.md new file mode 100644 index 0000000000000..79e034e33c91a --- /dev/null +++ b/content/fa/docs/reference/glossary/application-developer.md @@ -0,0 +1,17 @@ +--- +title: توسعه‌دهنده اپلیکیشن +id: application-developer +date: 2018-04-12 +full_link: +short_description: > + شخصی که برنامه‌ای می‌نویسد که در یک خوشه کوبرنتیز اجرا می‌شود. + +aka: +tags: +- user-type +--- + شخصی که برنامه‌ای می‌نویسد که در یک خوشه کوبرنتیز اجرا می‌شود. + + + +یک توسعه‌دهنده‌ی اپلیکیشن روی یک بخش از اپلیکیشن تمرکز می‌کند. مقیاس تمرکز آنها ممکن است از نظر اندازه به طور قابل توجهی متفاوت باشد. diff --git a/content/fa/docs/reference/glossary/applications.md b/content/fa/docs/reference/glossary/applications.md new file mode 100644 index 0000000000000..dd6ac949e64ce --- /dev/null +++ b/content/fa/docs/reference/glossary/applications.md @@ -0,0 +1,12 @@ +--- +title: اپلیکیشن +id: applications +date: 2019-05-12 +full_link: +short_description: > + لایه‌ای که برنامه‌های مختلف کانتینر شده در آن اجرا می‌شوند. +aka: +tags: +- fundamental +--- + لایه‌ای که برنامه‌های مختلف کانتینر شده در آن اجرا می‌شوند. diff --git a/content/fa/docs/reference/glossary/approver.md b/content/fa/docs/reference/glossary/approver.md new file mode 100644 index 0000000000000..c9a9b57a711cb --- /dev/null +++ b/content/fa/docs/reference/glossary/approver.md @@ -0,0 +1,17 @@ +--- +title: تأییدکننده +id: approver +date: 2018-04-12 +full_link: +short_description: > + شخصی که می‌تواند مشارکت‌های کد کوبرنتیز را بررسی و تأیید کند. + +aka: +tags: +- community +--- + شخصی که می‌تواند مشارکت‌های کد کوبرنتیز را بررسی و تأیید کند. + + + +در حالی که بررسی کد بر کیفیت و صحت کد متمرکز است، تأیید بر پذیرش جامع یک مشارکت متمرکز است. پذیرش جامع شامل سازگاری رو به عقب/رو به جلو، رعایت API و قراردادهای پرچم، مسائل جزئی عملکرد و صحت، تعامل با سایر بخش‌های سیستم و موارد دیگر می‌شود. وضعیت تأییدکننده به بخشی از پایگاه کد محدود می‌شود. قبلاً به تأییدکنندگان، نگهدارندگان گفته می‌شد. diff --git a/content/fa/docs/reference/glossary/cadvisor.md b/content/fa/docs/reference/glossary/cadvisor.md new file mode 100644 index 0000000000000..18c4b0af5c5ac --- /dev/null +++ b/content/fa/docs/reference/glossary/cadvisor.md @@ -0,0 +1,16 @@ +--- +title: cAdvisor +id: cadvisor +date: 2021-12-09 +full_link: https://github.com/google/cadvisor/ +short_description: > + ابزاری که درک درستی از میزان استفاده از منابع و ویژگی‌های عملکرد کانتینرها ارائه می‌دهد +aka: +tags: +- tool +--- +cAdvisor (Container Advisor) به کاربران {{< glossary_tooltip text="کانتینرها" term_id="container" >}} کمک می‌کند تا با مصرف منابع و ویژگی‌های عملکرد کانتینرهای در حال اجرای خود آشنا شوند. + + + +این ابزار یک دیمن در حال اجرا است که اطلاعات مربوط به کانتینرهای در حال اجرا را جمع‌آوری، تجمیع، پردازش و صادر می‌کند. به طور مشخص، برای هر کانتینر پارامترهای جداسازی منابع، مصرف تاریخی منابع، نمودارهای هیستوگرام مصرف کامل منابع در طول زمان و آمار شبکه را نگهداری می‌کند. این داده‌ها به تفکیک کانتینر و در سطح کل ماشین صادر می‌شوند. diff --git a/content/fa/docs/reference/glossary/certificate.md b/content/fa/docs/reference/glossary/certificate.md new file mode 100644 index 0000000000000..25c34b50291e9 --- /dev/null +++ b/content/fa/docs/reference/glossary/certificate.md @@ -0,0 +1,17 @@ +--- +title: گواهی +id: certificate +date: 2018-04-12 +full_link: /docs/tasks/tls/managing-tls-in-a-cluster/ +short_description: > + یک فایل رمزنگاری‌شده‌ی امن که برای اعتبارسنجی دسترسی به خوشه کوبرنتیز استفاده می‌شود. + +aka: +tags: +- security +--- + یک فایل رمزنگاری‌شده‌ی امن که برای اعتبارسنجی دسترسی به خوشه کوبرنتیز استفاده می‌شود. + + + +گواهینامه‌ها به برنامه‌های درون یک خوشه کوبرنتیز امکان دسترسی ایمن به API کوبرنتیز را می‌دهند. گواهینامه‌ها تأیید می‌کنند که کلاینت‌ها مجاز به دسترسی به API هستند. diff --git a/content/fa/docs/reference/glossary/cgroup.md b/content/fa/docs/reference/glossary/cgroup.md new file mode 100644 index 0000000000000..0dfdc3eb46c49 --- /dev/null +++ b/content/fa/docs/reference/glossary/cgroup.md @@ -0,0 +1,17 @@ +--- +title: cgroup (control group) +id: cgroup +date: 2019-06-25 +full_link: +short_description: > + گروهی از فرآیندهای لینوکس با جداسازی منابع، حسابداری و محدودیت‌های اختیاری. + +aka: +tags: +- fundamental +--- +گروهی از فرآیندهای لینوکس با جداسازی منابع، حسابداری و محدودیت‌های اختیاری. + + + +cgroup یک ویژگی هسته لینوکس است که میزان استفاده از منابع (پردازنده، حافظه، ورودی/خروجی دیسک، شبکه) را برای مجموعه‌ای از فرآیندها محدود، محاسبه و ایزوله می‌کند.. diff --git a/content/fa/docs/reference/glossary/cidr.md b/content/fa/docs/reference/glossary/cidr.md new file mode 100644 index 0000000000000..a1a513f8636c3 --- /dev/null +++ b/content/fa/docs/reference/glossary/cidr.md @@ -0,0 +1,18 @@ +--- +title: CIDR +id: cidr +date: 2019-11-12 +full_link: +short_description: > + CIDR یک نمادگذاری برای توصیف بلوک‌های آدرس‌های IP است و به طور گسترده در پیکربندی‌های مختلف شبکه استفاده می‌شود. + +aka: +tags: +- networking +--- +CIDR (Classless Inter-Domain Routing) یک نگاشت برای توصیف بلوک‌های آدرس IP است و به‌طور گسترده در پیکربندی‌های مختلف شبکه استفاده می‌شود. + + + +در زمینه کوبرنتیز، به هر {{< glossary_tooltip text="گره" term_id="node" >}} با استفاده از یک آدرس شروع و یک ماسک زیرشبکه در قالب CIDR، محدوده‌ای از آدرس‌های IP اختصاص داده می‌شود. این امکان را فراهم می‌کند که هر {{< glossary_tooltip text="پاد" term_id="pod" >}} یک آدرس IP یکتا دریافت کند. اگرچه این مفهوم در اصل برای IPv4 ارائه شد، اما CIDR به IPv6 نیز گسترش یافته است. + diff --git a/content/fa/docs/reference/glossary/cla.md b/content/fa/docs/reference/glossary/cla.md new file mode 100644 index 0000000000000..da904afb896d2 --- /dev/null +++ b/content/fa/docs/reference/glossary/cla.md @@ -0,0 +1,18 @@ +--- +title: CLA (توافقنامه مجوز مشارکت‌کننده) +id: cla +date: 2018-04-12 +full_link: https://github.com/kubernetes/community/blob/master/CLA.md +short_description: > + شرایطی که تحت آن یک مشارکت‌کننده، مجوزی را برای مشارکت‌های خود به یک پروژه متن‌باز اعطا می‌کند. + +aka: +tags: +- community +--- + شرایطی که تحت آن یک {{< glossary_tooltip text="مشارکت‌کننده" term_id="contributor" >}} به یک پروژه متن‌باز برای مشارکت‌های خود مجوز اعطا می‌کند. + + + +CLAs به حل اختلافات حقوقی مربوط به مطالب مشارکتی و مالکیت فکری (IP) کمک می‌کنند. + diff --git a/content/fa/docs/reference/glossary/cloud-controller-manager.md b/content/fa/docs/reference/glossary/cloud-controller-manager.md new file mode 100644 index 0000000000000..1f641166f9dfc --- /dev/null +++ b/content/fa/docs/reference/glossary/cloud-controller-manager.md @@ -0,0 +1,19 @@ +--- +title: مدیر کنترل‌کننده ابری +id: cloud-controller-manager +date: 2018-04-12 +full_link: /docs/concepts/architecture/cloud-controller/ +short_description: > + کامپوننت صفحه کنترل که Kubernetes را با ارائه دهندگان ابری شخص ثالث ادغام می‌کند. +aka: +tags: +- architecture +- operation +--- + یک جزء از {{< glossary_tooltip text="صف کنترل" term_id="control-plane" >}} کوبرنتیز است که منطق کنترلی مخصوص ابر را در خود جای داده است. مدیر کنترل ابری به شما اجازه می‌دهد خوشه‌تان را به API ارائه‌دهنده ابری‌تان متصل کنید و اجزایی که با آن پلتفرم ابری تعامل دارند را از اجزایی که تنها با خوشه شما تعامل می‌کنند جدا می‌کند. + + + +با جدا کردن منطق تعامل‌پذیری بین کوبرنتیز و زیرساخت ابری زیربنایی، جزء cloud-controller-manager به ارائه‌دهندگان ابری امکان می‌دهد ویژگی‌ها را با سرعتی متفاوت نسبت به پروژه اصلی کوبرنتیز عرضه کنند. + + diff --git a/content/fa/docs/reference/glossary/cloud-provider.md b/content/fa/docs/reference/glossary/cloud-provider.md new file mode 100644 index 0000000000000..b851547dc90e5 --- /dev/null +++ b/content/fa/docs/reference/glossary/cloud-provider.md @@ -0,0 +1,23 @@ +--- +title: ارائه دهنده ابر +id: cloud-provider +date: 2018-04-12 +short_description: > + سازمانی که پلتفرم رایانش ابری ارائه می‌دهد. + +aka: +- Cloud Service Provider +tags: +- community +--- + یک کسب و کار یا سازمان دیگر که یک پلتفرم رایانش ابری ارائه می‌دهد. + + + +ارائه‌دهندگان ابری، که گاهی ارائه‌دهندگان خدمات ابری (Cloud Service Providers یا CSPها) نامیده می‌شوند، پلتفرم‌ها یا خدمات رایانش ابری را ارائه می‌کنند. + +بسیاری از ارائه‌دهندگان ابری زیرساخت مدیریت‌شده (که گاهی زیرساخت به‌عنوان خدمت یا Infrastructure as a Service – IaaS نامیده می‌شود) ارائه می‌دهند. +با زیرساخت مدیریت‌شده، ارائه‌دهنده ابری مسئول سرورها، ذخیره‌سازی و شبکه است، در حالی که شما لایه‌های بالاتر مانند اجرای خوشه کوبرنتیز را مدیریت می‌کنید. + +همچنین می‌توانید کوبرنتیز را به‌صورت سرویس مدیریت‌شده پیدا کنید؛ که گاهی پلتفرم به‌عنوان خدمت یا Platform as a Service – PaaS نامیده می‌شود. +با کوبرنتیز مدیریت‌شده، ارائه‌دهنده ابری شما مسئول صفحه کنترل کوبرنتیز و {{< glossary_tooltip term_id="node" text="گره‌ها" >}} و زیرساخت‌های وابسته به آن‌ها (شبکه، ذخیره‌سازی و احتمالاً سایر اجزا مانند متوازن‌کننده‌های بار) است. diff --git a/content/fa/docs/reference/glossary/cluster-architect.md b/content/fa/docs/reference/glossary/cluster-architect.md new file mode 100644 index 0000000000000..e5d943161cad4 --- /dev/null +++ b/content/fa/docs/reference/glossary/cluster-architect.md @@ -0,0 +1,18 @@ +--- +title: معمار خوشه‌ +id: cluster-architect +date: 2018-04-12 +full_link: +short_description: > + شخصی که زیرساختی را طراحی می‌کند که شامل یک یا چند خوشه Kubernetes است. + +aka: +tags: +- user-type +--- + شخصی که زیرساختی را طراحی می‌کند که شامل یک یا چند خوشه Kubernetes است. + + + +معماران خوشه به بهترین روش‌ها برای سیستم‌های توزیع‌شده، مانند دسترسی‌پذیری بالا و امنیت، اهمیت می‌دهند. + diff --git a/content/fa/docs/reference/glossary/cluster-infrastructure.md b/content/fa/docs/reference/glossary/cluster-infrastructure.md new file mode 100644 index 0000000000000..ed61032bc92b4 --- /dev/null +++ b/content/fa/docs/reference/glossary/cluster-infrastructure.md @@ -0,0 +1,13 @@ +--- +title: زیرساخت خوشه‌ +id: cluster-infrastructure +date: 2019-05-12 +full_link: +short_description: > + لایه زیرساخت، ماشین‌های مجازی، شبکه، گروه‌های امنیتی و موارد دیگر را فراهم و نگهداری می‌کند. + +aka: +tags: +- operation +--- + لایه زیرساخت، ماشین‌های مجازی، شبکه، گروه‌های امنیتی و موارد دیگر را فراهم و نگهداری می‌کند. diff --git a/content/fa/docs/reference/glossary/cluster-operations.md b/content/fa/docs/reference/glossary/cluster-operations.md new file mode 100644 index 0000000000000..169d4885e2922 --- /dev/null +++ b/content/fa/docs/reference/glossary/cluster-operations.md @@ -0,0 +1,17 @@ +--- +title: عملیات خوشه +id: cluster-operations +date: 2019-05-12 +full_link: +short_description: > + کاری که در مدیریت یک خوشه Kubernetes انجام می‌شود. + +aka: +tags: +- operation +--- + کاری که در مدیریت یک خوشه کوبرنتیز انجام می‌شود: مدیریت عملیات روزمره و هماهنگی به‌روزرسانی‌ها. + + + +نمونه‌هایی از کارهای عملیات خوشه شامل موارد زیر است: استقرار {{< glossary_tooltip text="گره" term_id="node" >}}های جدید برای مقیاس‌بندی خوشه؛ انجام به‌روزرسانی نرم‌افزار؛ اجرای کنترل‌های امنیتی؛ افزودن یا حذف ذخیره‌سازی؛ پیکربندی شبکه خوشه؛ مدیریت قابلیت مشاهده در سطح خوشه؛ و پاسخ به رویدادها. diff --git a/content/fa/docs/reference/glossary/cluster-operator.md b/content/fa/docs/reference/glossary/cluster-operator.md new file mode 100644 index 0000000000000..5ae0505d237d9 --- /dev/null +++ b/content/fa/docs/reference/glossary/cluster-operator.md @@ -0,0 +1,22 @@ +--- +title: عملگر خوشه +id: cluster-operator +date: 2018-04-12 +full_link: +short_description: > + شخصی که خوشهها را پیکربندی، کنترل و نظارت می‌کند. + +aka: +tags: +- user-type +--- + شخصی که خوشهها را پیکربندی، کنترل و نظارت می‌کند. + + + +مسئولیت اصلی آن‌ها حفظ فعال و در حال کار بودن یک خوشه است، که ممکن است شامل فعالیت‌های نگهداری دوره‌ای یا ارتقاءها باشد.
+ +{{< note >}} +اپراتورهای خوشه با [الگوی Operator](/docs/concepts/extend-kubernetes/operator/) که API کوبرنتیز را گسترش می‌دهد، تفاوت دارند. +{{< /note >}} + diff --git a/content/fa/docs/reference/glossary/cluster.md b/content/fa/docs/reference/glossary/cluster.md new file mode 100644 index 0000000000000..2bf8f21067b59 --- /dev/null +++ b/content/fa/docs/reference/glossary/cluster.md @@ -0,0 +1,19 @@ +--- +title: خوشه +id: cluster +date: 2019-06-15 +full_link: +short_description: > + مجموعه‌ای از ماشین‌های کاری، به نام گره‌ها، که برنامه‌های کانتینر شده را اجرا می‌کنند. هر خوشه حداقل یک گره کارگر دارد. +aka: +tags: +- fundamental +- operation +--- +مجموعه‌ای از ماشین‌های کاری، که {{< glossary_tooltip text="گره‌ها" term_id="node" >}} نامیده می‌شوند، +که برنامه‌های کانتینری‌شده را اجرا می‌کنند. هر خوشه حداقل یک گره کاری دارد. + + +گره(های) کاری میزبان {{< glossary_tooltip text="پادها" term_id="pod" >}} هستند که اجزای بارکاری برنامه را تشکیل می‌دهند. +{{< glossary_tooltip text="صف کنترل" term_id="control-plane" >}}، گره‌های کاری و پادهای خوشه را مدیریت می‌کند. +در محیط‌های تولیدی، معمولاً صف کنترل روی چندین کامپیوتر اجرا می‌شود و یک خوشه معمولاً شامل چندین گره است تا تحمل خطا و دسترسی‌پذیری بالا را فراهم کند. diff --git a/content/fa/docs/reference/glossary/cncf.md b/content/fa/docs/reference/glossary/cncf.md new file mode 100644 index 0000000000000..7d79ee8539579 --- /dev/null +++ b/content/fa/docs/reference/glossary/cncf.md @@ -0,0 +1,13 @@ +--- +title: بنیاد محاسبات بومی ابری (CNCF) +id: cncf +date: 2019-05-26 +full_link: https://cncf.io/ +short_description: > + بنیاد محاسبات بومی ابری + +aka: +tags: +- community +--- + بنیاد محاسبات بومی ابری (CNCF) بن‌سازه‌های پایدار ایجاد می‌کند و جامعه‌ای پیرامون [پروژه‌ها](https://www.cncf.io/projects/) پرورش می‌دهد که کانتینرها را به‌عنوان بخشی از معماری میکروسرویس‌ها ارکسترا diff --git a/content/fa/docs/reference/glossary/cni.md b/content/fa/docs/reference/glossary/cni.md new file mode 100644 index 0000000000000..f420d5f224f64 --- /dev/null +++ b/content/fa/docs/reference/glossary/cni.md @@ -0,0 +1,18 @@ +--- +title: رابط شبکه کانتینر (CNI) +id: cni +date: 2018-05-25 +full_link: /docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/ +short_description: > + افزونه‌های رابط شبکه کانتینر (CNI) نوعی افزونه شبکه هستند که به مشخصات appc/CNI پایبند هستند. + + +aka: +tags: +- networking +--- + افزونه‌های رابط شبکه کانتینر (CNI) نوعی افزونه شبکه هستند که به مشخصات appc/CNI پایبند هستند. + + + +* برای اطلاعات بیشتر در مورد کوبرنتیز و CNI، به [**پلاگین‌های شبکه**](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) مراجعه کنید. \ No newline at end of file diff --git a/content/fa/docs/reference/glossary/code-contributor.md b/content/fa/docs/reference/glossary/code-contributor.md new file mode 100644 index 0000000000000..085cca1fdd803 --- /dev/null +++ b/content/fa/docs/reference/glossary/code-contributor.md @@ -0,0 +1,19 @@ +--- +title: مشارکت‌کننده کد +id: code-contributor +date: 2018-04-12 +full_link: https://github.com/kubernetes/community/tree/master/contributors/devel +short_description: > + شخصی که کد پایگاه داده متن‌باز Kubernetes را توسعه داده و در آن مشارکت می‌کند. + +aka: +tags: +- community +- user-type +--- + شخصی که کد پایگاه داده متن‌باز Kubernetes را توسعه داده و در آن مشارکت می‌کند. + + + +آن‌ها همچنین یک {{< glossary_tooltip text="عضو جامعه" term_id="member" >}} فعال هستند که در یک یا چند {{< glossary_tooltip text="گروه‌های علاقه‌مندی ویژه (SIGها)" term_id="sig" >}} شرکت می‌کنند. + diff --git a/content/fa/docs/reference/glossary/configmap.md b/content/fa/docs/reference/glossary/configmap.md new file mode 100644 index 0000000000000..0046f1abdffbf --- /dev/null +++ b/content/fa/docs/reference/glossary/configmap.md @@ -0,0 +1,18 @@ +--- +title: ConfigMap +id: configmap +date: 2018-04-12 +full_link: /docs/concepts/configuration/configmap/ +short_description: > + یک شیء API که برای ذخیره داده‌های غیرمحرمانه در جفت‌های کلید-مقدار استفاده می‌شود. می‌تواند به عنوان متغیرهای محیطی، آرگومان‌های خط فرمان یا فایل‌های پیکربندی در یک حجم استفاده شود. + +aka: +tags: +- core-object +--- +یک شیء API است که برای ذخیره داده‌های غیرمحرمانه به‌صورت جفت‌های کلید–مقدار استفاده می‌شود. +{{< glossary_tooltip text="پادها" term_id="pod" >}} می‌توانند ConfigMapها را به‌عنوان متغیرهای محیطی، آرگومان‌های خط فرمان یا به‌عنوان فایل‌های پیکربندی در یک {{< glossary_tooltip text="والوم" term_id="volume" >}} مصرف کنند. + + + +یک ConfigMap به شما اجازه می‌دهد پیکربندی وابسته به محیط را از {{< glossary_tooltip text="تصاویر کانتینر" term_id="image" >}} جدا کنید، تا برنامه‌های شما به‌راحتی قابل حمل باشند. diff --git a/content/fa/docs/reference/glossary/container-env-variables.md b/content/fa/docs/reference/glossary/container-env-variables.md new file mode 100644 index 0000000000000..977d549d28bf0 --- /dev/null +++ b/content/fa/docs/reference/glossary/container-env-variables.md @@ -0,0 +1,17 @@ +--- +title: متغیرهای محیطی کانتینر +id: container-env-variables +date: 2018-04-12 +full_link: /docs/concepts/containers/container-environment/ +short_description: > + متغیرهای محیطی کانتینر، جفت‌های نام=مقدار هستند که اطلاعات مفیدی را در مورد کانتینرهای در حال اجرا در یک پاد ارائه می‌دهند. + +aka: +tags: +- fundamental +--- + متغیرهای محیطی کانتینر، جفت‌های نام=مقدار هستند که اطلاعات مفیدی را در مورد کانتینرهای در حال اجرا در یک {{< glossary_tooltip text="پاد" term_id="pod" >}} ارائه می‌دهند. + + + +متغیرهای محیطی کانتینر اطلاعاتی را فراهم می‌کنند که توسط برنامه‌های کانتینری در حال اجرا نیاز است و همچنین اطلاعاتی درباره منابع مهم برای {{< glossary_tooltip text="کانتینرها" term_id="container" >}} ارائه می‌دهند. برای مثال، جزئیات سیستم فایل، اطلاعات مربوط به خود کانتینر و سایر منابع خوشه مانند نقاط پایانی سرویس. diff --git a/content/fa/docs/reference/glossary/container-lifecycle-hooks.md b/content/fa/docs/reference/glossary/container-lifecycle-hooks.md new file mode 100644 index 0000000000000..d423ee69418e4 --- /dev/null +++ b/content/fa/docs/reference/glossary/container-lifecycle-hooks.md @@ -0,0 +1,17 @@ +--- +title: قلاب‌های چرخه عمر کانتینر +id: container-lifecycle-hooks +date: 2018-10-08 +full_link: /docs/concepts/containers/container-lifecycle-hooks/ +short_description: > + قلاب‌های چرخه عمر، رویدادها را در چرخه عمر مدیریت کانتینر نمایش می‌دهند و به کاربر اجازه می‌دهند هنگام وقوع رویدادها، کدی را اجرا کند. + +aka: +tags: +- extension +--- + قلاب‌های چرخه عمر، رویدادها را در چرخه عمر مدیریت {{< glossary_tooltip text="کانتینر" term_id="container" >}} نمایش می‌دهند و به کاربر اجازه می‌دهند هنگام وقوع رویدادها، کدی را اجرا کند. + + + +دو قلاب در معرض کانتینرها قرار دارند: PostStart که بلافاصله پس از ایجاد کانتینر اجرا می‌شود و PreStop که مسدودکننده است و بلافاصله قبل از خاتمه کانتینر فراخوانی می‌شود. \ No newline at end of file diff --git a/content/fa/docs/reference/glossary/container-runtime.md b/content/fa/docs/reference/glossary/container-runtime.md new file mode 100644 index 0000000000000..e992dd8188073 --- /dev/null +++ b/content/fa/docs/reference/glossary/container-runtime.md @@ -0,0 +1,21 @@ +--- +title: زمان اجرای کانتینر +id: container-runtime +date: 2019-06-05 +full_link: /docs/setup/production-environment/container-runtimes +short_description: > + زمان اجرای کانتینر، نرم‌افزاری است که مسئول اجرای کانتینرها است. + +aka: +tags: +- fundamental +- workload +--- + یک جزء بنیادی که به کوبرنتیز امکان اجرای مؤثر کانتینرها را می‌دهد. + این جزء مسئول مدیریت اجرای کانتینرها و چرخه عمر آن‌ها در محیط کوبرنتیز است. + + + +کوبرنتیز از محیط‌های اجرای کانتینر مانند +{{< glossary_tooltip term_id="containerd" >}}، {{< glossary_tooltip term_id="cri-o" >}} +و هر پیاده‌سازی دیگری از [CRI کوبرنتیز (رابط اجرای کانتینر)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md) پشتیبانی می‌کند. diff --git a/content/fa/docs/reference/glossary/container.md b/content/fa/docs/reference/glossary/container.md new file mode 100644 index 0000000000000..b6224b27baf9f --- /dev/null +++ b/content/fa/docs/reference/glossary/container.md @@ -0,0 +1,19 @@ +--- +title: کانتینر +id: container +date: 2018-04-12 +full_link: /docs/concepts/containers/ +short_description: > + یک ایمیج اجرایی سبک و قابل حمل که شامل نرم‌افزار و تمام وابستگی‌های آن است. + +aka: +tags: +- fundamental +- workload +--- + یک ایمیج اجرایی سبک و قابل حمل که شامل نرم‌افزار و تمام وابستگی‌های آن است. + + + +کانتینرها برنامه‌ها را از زیرساخت میزبان اصلی جدا می‌کنند تا استقرار در محیط‌های ابری یا سیستم‌عامل‌های مختلف آسان‌تر شود و مقیاس‌پذیری آسان‌تری داشته باشند. +برنامه‌هایی که درون کانتینرها اجرا می‌شوند، برنامه‌های کانتینری‌شده نامیده می‌شوند. فرآیند دسته‌بندی این برنامه‌ها و وابستگی‌های آنها در یک تصویر کانتینر، کانتینرسازی نامیده می‌شود. \ No newline at end of file diff --git a/content/fa/docs/reference/glossary/containerd.md b/content/fa/docs/reference/glossary/containerd.md new file mode 100644 index 0000000000000..5796f5e31e822 --- /dev/null +++ b/content/fa/docs/reference/glossary/containerd.md @@ -0,0 +1,17 @@ +--- +title: containerd +id: containerd +date: 2019-05-14 +full_link: https://containerd.io/docs/ +short_description: > + یک محیط اجرای کانتینر با تأکید بر سادگی، استحکام و قابلیت حمل + +aka: +tags: +- tool +--- + یک محیط اجرای کانتینر با تأکید بر سادگی، استحکام و قابلیت حمل + + + +containerd یک محیط اجرای {{< glossary_tooltip text="کانتینر" term_id="container" >}} است که به‌صورت یک دیمن در لینوکس یا ویندوز اجرا می‌شود. containerd مسئول دریافت و ذخیره تصاویر کانتینر، اجرای کانتینرها، فراهم‌سازی دسترسی شبکه و موارد دیگر است. diff --git a/content/fa/docs/reference/glossary/contributor.md b/content/fa/docs/reference/glossary/contributor.md new file mode 100644 index 0000000000000..e6bcfeddc8e8d --- /dev/null +++ b/content/fa/docs/reference/glossary/contributor.md @@ -0,0 +1,18 @@ +--- +title: مشارکت‌کننده +id: contributor +date: 2018-04-12 +full_link: +short_description: > + کسی که کد، مستندات یا وقت خود را برای کمک به پروژه یا جامعه Kubernetes اهدا می‌کند. + +aka: +tags: +- community +--- + کسی که کد، مستندات یا وقت خود را برای کمک به پروژه یا جامعه Kubernetes اهدا می‌کند. + + + +مشارکت‌ها شامل pull requestها (PR)، issueها، بازخورد، شرکت در {{< glossary_tooltip text="گروه‌های علاقه‌مندی ویژه (SIG)" term_id="sig" >}} یا سازماندهی رویدادهای جامعه است. + diff --git a/content/fa/docs/reference/glossary/control-plane.md b/content/fa/docs/reference/glossary/control-plane.md new file mode 100644 index 0000000000000..f8e7099efcb09 --- /dev/null +++ b/content/fa/docs/reference/glossary/control-plane.md @@ -0,0 +1,25 @@ +--- +title: صفحه کنترل +id: control-plane +date: 2019-05-12 +full_link: +short_description: > + لایه هماهنگ‌سازی کانتینر که API و رابط‌ها را برای تعریف، استقرار و مدیریت چرخه عمر کانتینرها در معرض دید قرار می‌دهد.. + +aka: +tags: +- fundamental +--- + لایه هماهنگ‌سازی کانتینر که API و رابط‌ها را برای تعریف، استقرار و مدیریت چرخه عمر کانتینرها در معرض دید قرار می‌دهد. + + + +این لایه از اجزای مختلفی تشکیل شده است، مانند (اما محدود به): + +* {{< glossary_tooltip text="etcd" term_id="etcd" >}} +* {{< glossary_tooltip text="سرور API" term_id="kube-apiserver" >}} +* {{< glossary_tooltip text="زمان‌بند" term_id="kube-scheduler" >}} +* {{< glossary_tooltip text="مدیر کنترل" term_id="kube-controller-manager" >}} +* {{< glossary_tooltip text="مدیر کنترل ابری" term_id="cloud-controller-manager" >}} + +این اجزا می‌توانند به‌عنوان سرویس‌های سنتی سیستم‌عامل (دایمون) یا به‌صورت کانتینر اجرا شوند. میزبان‌هایی که این اجزا روی آن‌ها اجرا می‌شدند، Historically به‌عنوان {{< glossary_tooltip text="مسترها" term_id="master" >}} شناخته می‌شدند. diff --git a/content/fa/docs/reference/glossary/controller.md b/content/fa/docs/reference/glossary/controller.md new file mode 100644 index 0000000000000..421bde4ab1227 --- /dev/null +++ b/content/fa/docs/reference/glossary/controller.md @@ -0,0 +1,21 @@ +--- +title: کنترل کننده +id: controller +date: 2018-04-12 +full_link: /docs/concepts/architecture/controller/ +short_description: > + یک حلقه کنترلی که وضعیت مشترک خوشه را از طریق apiserver رصد می‌کند و با ایجاد تغییرات، سعی در انتقال وضعیت فعلی به سمت وضعیت مطلوب دارد. + +aka: +tags: +- architecture +- fundamental +--- +در کوبرنتیز، کنترلرها حلقه‌های کنترلی هستند که وضعیت {{< glossary_tooltip term_id="cluster" text="خوشه" >}} شما را زیر نظر می‌گیرند و سپس در صورت نیاز تغییراتی را اعمال یا درخواست می‌کنند. +هر کنترلر سعی می‌کند وضعیت فعلی خوشه را به وضعیت مطلوب نزدیک‌تر کند. + + + +کنترلرها وضعیت مشترک خوشه شما را از طریق {{< glossary_tooltip term_id="kube-apiserver" text="سرور API" >}} (جزئی از {{< glossary_tooltip term_id="control-plane" text="صف کنترل" >}}) مشاهده می‌کنند. + +برخی از کنترلرها همچنین در داخل صف کنترل اجرا می‌شوند و حلقه‌های کنترلی را فراهم می‌کنند که برای عملیات کوبرنتیز اساسی‌اند. به‌عنوان مثال: کنترلر استقرار (deployment controller)، کنترلر daemonset، کنترلر namespace و کنترلر persistent volume (و دیگر موارد) همگی درون {{< glossary_tooltip term_id="kube-controller-manager" text="مدیر کنترل" >}} اجرا می‌شوند. diff --git a/content/fa/docs/reference/glossary/cri-o.md b/content/fa/docs/reference/glossary/cri-o.md new file mode 100644 index 0000000000000..2128ca0b0f412 --- /dev/null +++ b/content/fa/docs/reference/glossary/cri-o.md @@ -0,0 +1,22 @@ +--- +title: CRI-O +id: cri-o +date: 2019-05-14 +full_link: https://cri-o.io/#what-is-cri-o +short_description: > + یک کانتینر سبک مخصوص Kubernetes + +aka: +tags: +- tool +--- +یک ابزار که به شما امکان می‌دهد از زمان‌اجراهای کانتینر OCI با CRI کوبرنتس استفاده کنید. + + + +CRI-O پیاده‌سازی {{< glossary_tooltip term_id="cri" >}} +است تا استفاده از زمان‌اجراهای {{< glossary_tooltip text="container" term_id="container" >}} +سازگار با مشخصات زمان‌اجرا Open Container Initiative (OCI) +[runtime spec](https://www.github.com/opencontainers/runtime-spec) را ممکن سازد. + +استقرار CRI-O اجازه می‌دهد کوبرنتس از هر زمان‌اجرای سازگار با OCI به‌عنوان زمان‌اجرای کانتینر برای اجرای {{< glossary_tooltip text="Pods" term_id="pod" >}} استفاده کند و تصاویر کانتینر OCI را از رجیستری‌های راه دور دریافت نماید. diff --git a/content/fa/docs/reference/glossary/cri.md b/content/fa/docs/reference/glossary/cri.md new file mode 100644 index 0000000000000..6ffc379d6d42b --- /dev/null +++ b/content/fa/docs/reference/glossary/cri.md @@ -0,0 +1,19 @@ +--- +title: رابط زمان اجرای کانتینر (CRI) +id: cri +date: 2021-11-24 +full_link: /docs/concepts/architecture/cri +short_description: > + پروتکلی برای ارتباط بین kubelet و محیط اجرایی کانتینر محلی. + +aka: +tags: + - fundamental +--- + +پروتکل اصلی برای ارتباط بین {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} و زمان‌اجرای کانتینر. + + + +رابط زمان‌اجرای کانتینر کوبرنتس (CRI) پروتکل اصلی [gRPC](https://grpc.io) را برای ارتباط بین {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} و {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}، از جمله [کامپوننت‌های Node](/docs/concepts/architecture/#node-components)، تعریف می‌کند. + diff --git a/content/fa/docs/reference/glossary/cronjob.md b/content/fa/docs/reference/glossary/cronjob.md new file mode 100644 index 0000000000000..a0623d40984d6 --- /dev/null +++ b/content/fa/docs/reference/glossary/cronjob.md @@ -0,0 +1,18 @@ +--- +title: CronJob +id: cronjob +date: 2018-04-12 +full_link: /docs/concepts/workloads/controllers/cron-jobs/ +short_description: > + یک وظیفه تکرارشونده (یک Job) که طبق یک برنامه منظم اجرا می‌شود. + +aka: +tags: +- core-object +- workload +--- +مدیریت یک [Job](/docs/concepts/workloads/controllers/job/) که بر اساس زمان‌بندی دوره‌ای اجرا می‌شود. + + + +مشابه یک خط در فایل *crontab*، شی CronJob با استفاده از قالب [cron](https://en.wikipedia.org/wiki/Cron) زمان‌بندی خود را مشخص می‌کند. diff --git a/content/fa/docs/reference/glossary/csi.md b/content/fa/docs/reference/glossary/csi.md new file mode 100644 index 0000000000000..2db613ed61137 --- /dev/null +++ b/content/fa/docs/reference/glossary/csi.md @@ -0,0 +1,21 @@ +--- +title: رابط ذخیره‌سازی کانتینر (CSI) +id: csi +date: 2018-06-25 +full_link: /docs/concepts/storage/volumes/#csi +short_description: > + رابط ذخیره‌سازی کانتینر (CSI) یک رابط استاندارد برای نمایش سیستم‌های ذخیره‌سازی به کانتینرها تعریف می‌کند. + + +aka: +tags: +- storage +--- + رابط ذخیره‌سازی کانتینر (CSI) یک رابط استاندارد برای نمایش سیستم‌های ذخیره‌سازی به کانتینرها تعریف می‌کند. + + + +CSI به فروشندگان اجازه می‌دهد افزونه‌های ذخیره‌سازی سفارشی برای کوبرنتیز ایجاد کنند بدون افزودن آنها به مخزن کوبرنتیز (افزونه‌های خارج از درخت). برای استفاده از درایور CSI از یک ارائه‌دهنده ذخیره‌سازی، ابتدا باید [آن را در خوشه خود مستقر کنید](https://kubernetes-csi.github.io/docs/deploying.html). سپس خواهید توانست یک {{< glossary_tooltip text="Storage Class" term_id="storage-class" >}} ایجاد کنید که از آن درایور CSI استفاده می‌کند. + +* [CSI در مستندات کوبرنتیز](/docs/concepts/storage/volumes/#csi) +* [فهرست درایورهای CSI موجود](https://kubernetes-csi.github.io/docs/drivers.html) diff --git a/content/fa/docs/reference/glossary/customresourcedefinition.md b/content/fa/docs/reference/glossary/customresourcedefinition.md new file mode 100644 index 0000000000000..df95c0d4cef95 --- /dev/null +++ b/content/fa/docs/reference/glossary/customresourcedefinition.md @@ -0,0 +1,19 @@ +--- +title: CustomResourceDefinition +id: CustomResourceDefinition +date: 2018-04-12 +full_link: /docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/ +short_description: > + کد سفارشی که منبعی را برای اضافه کردن به سرور API Kubernetes شما بدون ساخت یک سرور سفارشی کامل تعریف می‌کند. + +aka: +tags: +- fundamental +- operation +- extension +--- + کد سفارشی که منبعی را برای اضافه کردن به سرور API Kubernetes شما بدون ساخت یک سرور سفارشی کامل تعریف می‌کند. + + + +تعریف منابع سفارشی به شما امکان می‌دهد در صورتی که منابع API با پشتیبانی عمومی نتوانند نیازهای شما را برآورده کنند، API کوبرنتیز را برای محیط خود گسترش دهید. \ No newline at end of file diff --git a/content/fa/docs/reference/glossary/daemonset.md b/content/fa/docs/reference/glossary/daemonset.md new file mode 100644 index 0000000000000..8fa4bfe559f4a --- /dev/null +++ b/content/fa/docs/reference/glossary/daemonset.md @@ -0,0 +1,19 @@ +--- +title: DaemonSet +id: daemonset +date: 2018-04-12 +full_link: /docs/concepts/workloads/controllers/daemonset +short_description: > + تضمین می‌کند که یک کپی از یک Pod در مجموعه‌ای از گره‌ها در یک خوشه در حال اجرا است. + +aka: +tags: +- fundamental +- core-object +- workload +--- + اطمینان می‌دهد که یک نسخه از {{< glossary_tooltip text="Pod" term_id="pod" >}} در میان مجموعه‌ای از گره‌ها در یک {{< glossary_tooltip text="cluster" term_id="cluster" >}} در حال اجرا باشد. + + + +برای استقرار دیمن‌های سیستمی مانند جمع‌آورنده‌های لاگ و عامل‌های نظارتی که معمولاً باید روی هر {{< glossary_tooltip term_id="node" >}} اجرا شوند، استفاده می‌گردد. diff --git a/content/fa/docs/reference/glossary/data-plane.md b/content/fa/docs/reference/glossary/data-plane.md new file mode 100644 index 0000000000000..20c0078f22893 --- /dev/null +++ b/content/fa/docs/reference/glossary/data-plane.md @@ -0,0 +1,13 @@ +--- +title: صفحه داده +id: data-plane +date: 2019-05-12 +full_link: +short_description: > + لایه‌ای که ظرفیت‌هایی مانند پردازنده، حافظه، شبکه و فضای ذخیره‌سازی را فراهم می‌کند تا کانتینرها بتوانند اجرا شوند و به شبکه متصل شوند. + +aka: +tags: +- fundamental +--- + لایه‌ای که ظرفیت‌هایی مانند پردازنده، حافظه، شبکه و فضای ذخیره‌سازی را فراهم می‌کند تا کانتینرها بتوانند اجرا شوند و به شبکه متصل شوند. diff --git a/content/fa/docs/reference/glossary/deployment.md b/content/fa/docs/reference/glossary/deployment.md new file mode 100644 index 0000000000000..03542612d66cc --- /dev/null +++ b/content/fa/docs/reference/glossary/deployment.md @@ -0,0 +1,20 @@ +--- +title: Deployment +id: deployment +date: 2018-04-12 +full_link: /docs/concepts/workloads/controllers/deployment/ +short_description: > + یک برنامه‌ی تکثیر شده را در خوشه شما مدیریت می‌کند. + +aka: +tags: +- fundamental +- core-object +- workload +--- +یک شی API که یک برنامه تکثیری را مدیریت می‌کند، معمولاً با اجرای Podها بدون وضعیت محلی. + + + +هر نسخه تکثیری توسط یک {{< glossary_tooltip term_id="pod" >}} نمایندگی می‌شود و Podها در میان {{< glossary_tooltip text="nodes" term_id="node" >}} یک خوشه پخش می‌شوند. +برای بارکاری‌هایی که نیاز به وضعیت محلی دارند، استفاده از {{< glossary_tooltip term_id="StatefulSet" >}} را مدنظر قرار دهید. diff --git a/content/fa/docs/reference/glossary/developer.md b/content/fa/docs/reference/glossary/developer.md new file mode 100644 index 0000000000000..f81dd2d3f221f --- /dev/null +++ b/content/fa/docs/reference/glossary/developer.md @@ -0,0 +1,19 @@ +--- +title: توسعه‌دهنده (ابهام‌زدایی) +id: developer +date: 2018-04-12 +full_link: +short_description: > + ممکن است به توسعه‌دهنده برنامه، مشارکت‌کننده کد یا توسعه‌دهنده پلتفرم اشاره داشته باشد. + +aka: +tags: +- community +- user-type +--- + ممکن است اشاره داشته باشد به: {{< glossary_tooltip text="Application Developer" term_id="application-developer" >}}, {{< glossary_tooltip text="Code Contributor" term_id="code-contributor" >}}, یا {{< glossary_tooltip text="Platform Developer" term_id="platform-developer" >}}. + + + +این اصطلاح چندمنظوره ممکن است بسته به زمینه معانی مختلفی داشته باشد. + diff --git a/content/fa/docs/reference/glossary/device-plugin.md b/content/fa/docs/reference/glossary/device-plugin.md new file mode 100644 index 0000000000000..5533d1dff3b4b --- /dev/null +++ b/content/fa/docs/reference/glossary/device-plugin.md @@ -0,0 +1,21 @@ +--- +title: افزونه دستگاه +id: device-plugin +date: 2019-02-02 +full_link: /docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/ +short_description: > + افزونه‌های نرم‌افزاری برای دسترسی پادها به دستگاه‌هایی که نیاز به راه‌اندازی یا تنظیمات خاص فروشنده دارند +aka: +tags: +- fundamental +- extension +--- + افزونه‌های دستگاه بر روی گره‌های {{< glossary_tooltip term_id="node" text="Nodes">}} اجرا می‌شوند و به {{< glossary_tooltip term_id="pod" text="Pods">}} دسترسی به منابعی مانند سخت‌افزار محلی که نیازمند مراحل راه‌اندازی یا پیکربندی خاص فروشنده است را فراهم می‌کنند. + + + +افزونه‌های دستگاه منابع را به {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} اعلام می‌کنند تا Pod‌های کاری بتوانند از ویژگی‌های سخت‌افزاری مربوط به گره‌ای که آن Pod روی آن اجرا می‌شود استفاده کنند. شما می‌توانید یک افزونه دستگاه را به‌صورت {{< glossary_tooltip term_id="daemonset" >}} مستقر کنید یا نرم‌افزار افزونه دستگاه را مستقیماً روی هر گره هدف نصب نمایید. + +برای اطلاعات بیشتر به +[Device Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) +مراجعه کنید. diff --git a/content/fa/docs/reference/glossary/disruption.md b/content/fa/docs/reference/glossary/disruption.md new file mode 100644 index 0000000000000..869e30a7aa023 --- /dev/null +++ b/content/fa/docs/reference/glossary/disruption.md @@ -0,0 +1,18 @@ +--- +title: اختلال +id: disruption +date: 2019-09-10 +full_link: /docs/concepts/workloads/pods/disruptions/ +short_description: > + رویدادی که منجر به از سرویس خارج شدن پاد(ها) می‌شود +aka: +tags: +- fundamental +--- + اختلال‌ها رویدادهایی هستند که منجر به خارج شدن یک یا چند {{< glossary_tooltip term_id="pod" text="Pods" >}} از سرویس می‌شوند. یک اختلال برای منابع بارکاری مانند {{< glossary_tooltip term_id="deployment" >}} که به Podهای آسیب‌دیده وابسته‌اند، پیامدهایی به همراه دارد. + + + +اگر شما به‌عنوان اپراتور خوشه، یک Pod را که به یک برنامه تعلق دارد حذف کنید، کوبرنتیز آن را «اختلال داوطلبانه» می‌نامد. اگر یک Pod به دلیل خرابی یک Node یا قطعی در یک ناحیه‌ی وسیع‌تر از دسترس خارج شود، کوبرنتیز آن را «اختلال غیرداوطلبانه» می‌نامد. + +برای اطلاعات بیشتر به [Disruptions](/docs/concepts/workloads/pods/disruptions/) مراجعه کنید. diff --git a/content/fa/docs/reference/glossary/docker.md b/content/fa/docs/reference/glossary/docker.md new file mode 100644 index 0000000000000..fb58095d53f72 --- /dev/null +++ b/content/fa/docs/reference/glossary/docker.md @@ -0,0 +1,17 @@ +--- +title: Docker +id: docker +date: 2018-04-12 +full_link: https://docs.docker.com/engine/ +short_description: > + Docker یک فناوری نرم‌افزاری است که مجازی‌سازی در سطح سیستم‌عامل (که به عنوان کانتینر نیز شناخته می‌شود) را فراهم می‌کند. + +aka: +tags: +- fundamental +--- +Docker (مخصوصاً Docker Engine) یک فناوری نرم‌افزاری است که مجازی‌سازی در سطح سیستم‌عامل، معروف به {{< glossary_tooltip text="containers" term_id="container" >}}، را فراهم می‌کند. + + + +Docker از ویژگی‌های جداسازی منابع کرنل لینوکس مانند cgroups و kernel namespaces و سیستم فایل‌های با قابلیت union مانند OverlayFS و دیگران استفاده می‌کند تا امکان اجرای کانتینرهای مستقل در یک نمونه لینوکس را فراهم آورد و از بار اضافی راه‌اندازی و نگهداری ماشین‌های مجازی (VMs) جلوگیری کند. diff --git a/content/fa/docs/reference/glossary/dockershim.md b/content/fa/docs/reference/glossary/dockershim.md new file mode 100644 index 0000000000000..8a0e5717c2e02 --- /dev/null +++ b/content/fa/docs/reference/glossary/dockershim.md @@ -0,0 +1,17 @@ +--- +title: Dockershim +id: dockershim +date: 2022-04-15 +full_link: /dockershim +short_description: > + جزئی از Kubernetes نسخه 1.23 و قبل از آن، که به اجزای سیستم Kubernetes اجازه می‌دهد تا با Docker Engine ارتباط برقرار کنند. + +aka: +tags: +- fundamental +--- +dockershim یک کامپوننت از کوبرنتیز نسخه 1.23 و قبل‌تر است. این امکان را برای {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} فراهم می‌کند تا با {{< glossary_tooltip text="Docker Engine" term_id="docker" >}} ارتباط برقرار نماید. + + + +از نسخه 1.24 به بعد، dockershim از کوبرنتیز حذف شده است. برای اطلاعات بیشتر، به [پرسش‌های متداول Dockershim](/dockershim) مراجعه کنید. diff --git a/content/fa/docs/reference/glossary/downstream.md b/content/fa/docs/reference/glossary/downstream.md new file mode 100644 index 0000000000000..06dd544920967 --- /dev/null +++ b/content/fa/docs/reference/glossary/downstream.md @@ -0,0 +1,19 @@ +--- +title: پایین‌دست (ابهام‌زدایی) +id: downstream +date: 2018-04-12 +full_link: +short_description: > + ممکن است به کدی در بن‌سازه Kubernetes اشاره داشته باشد که به کدبیس اصلی Kubernetes یا یک مخزن منشعب شده وابسته است. + +aka: +tags: +- community +--- + ممکن است به کدی در بن‌سازه Kubernetes اشاره داشته باشد که به کدبیس اصلی Kubernetes یا یک مخزن منشعب شده وابسته است. + + + +* در **جامعه کوبرنتیز**: در مکالمات اغلب از *downstream* برای اشاره به بن‌سازه، کد یا ابزارهای شخص ثالثی استفاده می‌شود که به کد اصلی کوبرنتیز وابسته‌اند. برای مثال، یک قابلیت جدید در کوبرنتیز ممکن است توسط برنامه‌های *downstream* برای بهبود عملکردشان پذیرفته شود. +* در **GitHub** یا **git**: عرف بر این است که یک مخزن فورک‌شده را *downstream* بنامند، در حالی که مخزن منبع را *upstream* در نظر می‌گیرند. + diff --git a/content/fa/docs/reference/glossary/downward-api.md b/content/fa/docs/reference/glossary/downward-api.md new file mode 100644 index 0000000000000..a913451babbd2 --- /dev/null +++ b/content/fa/docs/reference/glossary/downward-api.md @@ -0,0 +1,24 @@ +--- +title: API رو به پایین +id: downward-api +date: 2022-03-21 +short_description: > + مکانیزمی برای نمایش مقادیر فیلدهای Pod و container به کدی که در یک container اجرا می‌شود. +aka: +full_link: /docs/concepts/workloads/pods/downward-api/ +tags: +- architecture +--- +مکانیزم کوبرنتیز برای در معرض قرار دادن مقادیر فیلدهای Pod و کانتینر به کد در حال اجرا در یک کانتینر. + +گاهی مفید است که یک کانتینر بدون نیاز به اعمال تغییرات در کد کانتینر که آن را مستقیماً به کوبرنتیز متصل می‌کند، اطلاعاتی درباره خود داشته باشد. + +Downward API کوبرنتیز به کانتینرها اجازه می‌دهد اطلاعاتی درباره خود یا زمینه‌شان در یک خوشه کوبرنتیز مصرف کنند. برنامه‌های درون کانتینر می‌توانند به آن اطلاعات دسترسی داشته باشند، بدون آنکه برنامه نیاز داشته باشد به‌عنوان یک کلاینت API کوبرنتیز عمل کند. + +دو روش برای در معرض قرار دادن فیلدهای Pod و کانتینر به یک کانتینر در حال اجرا وجود دارد: + +- استفاده از [متغیرهای محیطی](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/) +- استفاده از یک حجم `downwardAPI`(/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) + +این دو روش در مجموع به‌عنوان _downward API_ شناخته می‌شوند. + diff --git a/content/fa/docs/reference/glossary/drain.md b/content/fa/docs/reference/glossary/drain.md new file mode 100644 index 0000000000000..59890910894ea --- /dev/null +++ b/content/fa/docs/reference/glossary/drain.md @@ -0,0 +1,18 @@ +--- +title: تخلیه +id: drain +date: 2024-12-27 +full_link: +short_description: > + پادها را به طور ایمن از یک گره خارج می‌کند تا برای تعمیر و نگهداری یا حذف آماده شود. +tags: +- fundamental +- operation +--- +فرایند تخلیه ایمن {{< glossary_tooltip text="Pods" term_id="pod" >}} از یک {{< glossary_tooltip text="Node" term_id="node" >}} برای آماده‌سازی آن جهت نگه‌داری یا حذف از یک {{< glossary_tooltip text="cluster" term_id="cluster" >}}. + + + +دستور `kubectl drain` برای علامت‌گذاری یک {{< glossary_tooltip text="Node" term_id="node" >}} به‌عنوان خارج از سرویس استفاده می‌شود. +وقتی اجرا شود، همه {{< glossary_tooltip text="Pods" term_id="pod" >}} را از آن {{< glossary_tooltip text="Node" term_id="node" >}} بیرون می‌کند. +اگر یک درخواست تخلیه موقتاً رد شود، `kubectl drain` دوباره تلاش می‌کند تا همه {{< glossary_tooltip text="Pods" term_id="pod" >}} خاتمه یابند یا مهلت قابل پیکربندی تمام شود. diff --git a/content/fa/docs/reference/glossary/duration.md b/content/fa/docs/reference/glossary/duration.md new file mode 100644 index 0000000000000..3f5311b76c432 --- /dev/null +++ b/content/fa/docs/reference/glossary/duration.md @@ -0,0 +1,19 @@ +--- +title: مدت زمان +id: duration +date: 2024-10-05 +full_link: +short_description: > + یک مقدار رشته‌ای که نشان‌دهنده‌ی مدت زمان است. +tags: +- fundamental +--- +یک مقدار رشته‌ای که نشان‌دهنده‌ی مدت زمان است. + + + +فرمت یک مدت‌زمان (در کوبرنتیز) بر پایه نوع [`time.Duration`](https://pkg.go.dev/time#Duration) در زبان برنامه‌نویسی Go است. + +در APIهای کوبرنتیز که از مدت‌زمان‌ها استفاده می‌کنند، مقدار به‌صورت رشته‌ای از اعداد صحیح نامنفی به‌همراه پسوند واحد زمان بیان می‌شود. می‌توانید بیش از یک کمیت زمانی داشته باشید و مدت‌زمان برابر با مجموع آن کمیت‌های زمانی است. واحدهای زمان معتبر عبارت‌اند از «ns»، «µs» (یا «us»)، «ms»، «s»، «m» و «h». + +برای مثال: `5s` نشان‌دهنده مدت‌زمان پنج ثانیه است و `1m30s` نشان‌دهنده مدت‌زمان یک دقیقه و سی ثانیه است. diff --git a/content/fa/docs/reference/glossary/dynamic-volume-provisioning.md b/content/fa/docs/reference/glossary/dynamic-volume-provisioning.md new file mode 100644 index 0000000000000..662dd62db4afc --- /dev/null +++ b/content/fa/docs/reference/glossary/dynamic-volume-provisioning.md @@ -0,0 +1,18 @@ +--- +title: تأمین پویای volume +id: dynamicvolumeprovisioning +date: 2018-04-12 +full_link: /docs/concepts/storage/dynamic-provisioning +short_description: > + به کاربران اجازه می‌دهد تا درخواست ایجاد خودکار Volumeهای ذخیره‌سازی را بدهند. + +aka: +tags: +- storage +--- + به کاربران اجازه می‌دهد تا درخواست ایجاد خودکار {{< glossary_tooltip text="Volumes" term_id="volume" >}}های ذخیره‌سازی را بدهند. + + + +تأمین پویای حجم، نیاز مدیران خوشه را به پیش‌تخصیص ذخیره‌سازی از میان برمی‌دارد. در عوض، ذخیره‌سازی به‌طور خودکار بر اساس درخواست کاربر فراهم می‌شود. تأمین پویای حجم بر پایه یک شیء API به نام {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}} است که به یک {{< glossary_tooltip text="Volume Plugin" term_id="volume-plugin" >}} اشاره می‌کند؛ این افزونه یک {{< glossary_tooltip text="Volume" term_id="volume" >}} را فراهم کرده و مجموعه‌ای از پارامترها را برای ارسال به Volume Plugin تعیین می‌کند. + diff --git a/content/fa/docs/reference/glossary/endpoint-slice.md b/content/fa/docs/reference/glossary/endpoint-slice.md new file mode 100644 index 0000000000000..128421f6aa31a --- /dev/null +++ b/content/fa/docs/reference/glossary/endpoint-slice.md @@ -0,0 +1,17 @@ +--- +title: EndpointSlice +id: endpoint-slice +date: 2018-04-12 +full_link: /docs/concepts/services-networking/endpoint-slices/ +short_description: > + EndpointSliceها آدرس‌های IP مربوط به Podها را با انتخابگرهای سرویس منطبق، ردیابی می‌کنند. + +aka: +tags: +- networking +--- +EndpointSliceها آدرس‌های IP پادهایی را که دارای {{< glossary_tooltip text="selectors" term_id="selector" >}} منطبق هستند، پیگیری می‌کنند. + + + +می‌توان EndpointSliceها را برای {{< glossary_tooltip text="Services" term_id="service" >}}ی که بدون تعیین انتخابگر هستند، به‌صورت دستی پیکربندی کرد. diff --git a/content/fa/docs/reference/glossary/endpoint.md b/content/fa/docs/reference/glossary/endpoint.md new file mode 100644 index 0000000000000..309f168e872be --- /dev/null +++ b/content/fa/docs/reference/glossary/endpoint.md @@ -0,0 +1,23 @@ +--- +title: نقاط پایانی +id: endpoints +date: 2020-04-23 +full_link: +short_description: > + نقطه پایانی یک سرویس، یکی از پادها (یا سرورهای خارجی) است که سرویس را پیاده‌سازی می‌کند. + +aka: +tags: +- networking +--- +نقطه پایانی یک {{< glossary_tooltip text="Service" term_id="service" >}} یکی از {{< glossary_tooltip text="Pods" term_id="pod" >}} (یا سرورهای خارجی) است که آن سرویس را پیاده‌سازی می‌کند. + + + +برای سرویس‌هایی با {{< glossary_tooltip text="selectors" term_id="selector" >}}، +کنترلر EndpointSlice به‌طور خودکار یک یا چند {{< +glossary_tooltip text="EndpointSlices" term_id="endpoint-slice" >}} ایجاد می‌کند +که آدرس‌های IP پادهای انتهاییِ انتخاب‌شده را ارائه می‌دهند. + +همچنین می‌توان EndpointSliceها را به‌صورت دستی ایجاد کرد تا نقاط پایانیِ +سرویس‌هایی را که selector مشخص نکرده‌اند، نشان دهند. diff --git a/content/fa/docs/reference/glossary/ephemeral-container.md b/content/fa/docs/reference/glossary/ephemeral-container.md new file mode 100644 index 0000000000000..cf6848962cecf --- /dev/null +++ b/content/fa/docs/reference/glossary/ephemeral-container.md @@ -0,0 +1,19 @@ +--- +title: کانتینر زودگذر +id: ephemeral-container +date: 2019-08-26 +full_link: /docs/concepts/workloads/pods/ephemeral-containers/ +short_description: > + نوعی کانتینر که می‌توانید به طور موقت درون یک Pod اجرا کنید. + +aka: +tags: +- fundamental +--- +یک نوع {{< glossary_tooltip term_id="container" >}} که می‌توانید آن را به‌طور موقت داخل یک {{< glossary_tooltip term_id="pod" >}} اجرا کنید. + + + +اگر می‌خواهید پادی را که با مشکل اجرا می‌شود بررسی کنید، می‌توانید یک کانتینر موقتی به آن پاد اضافه کرده و عملیات عیب‌یابی را انجام دهید. کانتینرهای موقتی هیچ تضمین منابع یا زمان‌بندی ندارند و نباید از آن‌ها برای اجرای هیچ بخشی از بار کاری اصلی استفاده کنید. + +کانتینرهای موقتی توسط {{< glossary_tooltip text="static pods" term_id="static-pod" >}} پشتیبانی نمی‌شوند. diff --git a/content/fa/docs/reference/glossary/etcd.md b/content/fa/docs/reference/glossary/etcd.md new file mode 100644 index 0000000000000..1561b07fda495 --- /dev/null +++ b/content/fa/docs/reference/glossary/etcd.md @@ -0,0 +1,20 @@ +--- +title: etcd +id: etcd +date: 2018-04-12 +full_link: /docs/tasks/administer-cluster/configure-upgrade-etcd/ +short_description: > + مخزن کلید-مقدارِ سازگار و با دسترسی بالا که به عنوان مخزن پشتیبان کوبرنتیز برای تمام داده‌های خوشه‌ای استفاده می‌شود. + +aka: +tags: +- architecture +- storage +--- + مخزن کلید-مقدارِ سازگار و با دسترسی بالا که به عنوان مخزن پشتیبان کوبرنتیز برای تمام داده‌های خوشه‌ای استفاده می‌شود. + + + +اگر خوشه کوبرنتیز شما از etcd به‌عنوان مخزن پشتیبان استفاده می‌کند، مطمئن شوید که برای داده‌ها یک طرح [پشتیبان‌گیری](/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster) داشته باشید. + +می‌توانید اطلاعات عمیق درباره etcd را در [مستندات](https://etcd.io/docs/) رسمی بیابید. diff --git a/content/fa/docs/reference/glossary/event.md b/content/fa/docs/reference/glossary/event.md new file mode 100644 index 0000000000000..348023cdd7bda --- /dev/null +++ b/content/fa/docs/reference/glossary/event.md @@ -0,0 +1,23 @@ +--- +title: رویداد +id: event +date: 2022-01-16 +full_link: /docs/reference/kubernetes-api/cluster-resources/event-v1/ +short_description: > + رویدادها، اشیاء کوبرنتیز هستند که برخی از تغییرات حالت در سیستم را توصیف می‌کنند. +aka: +tags: +- core-object +- fundamental +--- +Event یک شیء کوبرنتیز است که تغییر وضعیت یا رخدادهای قابل توجه در سیستم را توصیف می‌کند. + + + +رویدادها زمان نگهداری محدودی دارند و محرک‌ها و پیام‌ها ممکن است با گذشت زمان تغییر کنند. +مصرف‌کنندگان رویداد نباید بر زمان‌بندی یک رویداد با دلیل مشخص که نشانگر محرکی پایدار باشد اتکا کنند، +یا انتظار داشته باشند رویدادهایی با آن دلیل همواره موجود بمانند. + +رویدادها باید به‌عنوان داده‌های تکمیلی اطلاع‌رسانیِ مبتنی بر بهترین تلاش در نظر گرفته شوند. + +در کوبرنتیز، [ممیزی](/docs/tasks/debug/debug-cluster/audit/) نوع متفاوتی از رکورد Event را تولید می‌کند (گروه API `audit.k8s.io`). diff --git a/content/fa/docs/reference/glossary/eviction.md b/content/fa/docs/reference/glossary/eviction.md new file mode 100644 index 0000000000000..2a57650c3accc --- /dev/null +++ b/content/fa/docs/reference/glossary/eviction.md @@ -0,0 +1,19 @@ +--- +title: اخراج +id: eviction +date: 2021-05-08 +full_link: /docs/concepts/scheduling-eviction/ +short_description: > + فرآیند خاتمه دادن به یک یا چند Pod روی گره‌ها +aka: +tags: +- operation +--- + +اخراج فرایند خاتمه دادن به یک یا چند پاد روی نودها است. + + + +دو نوع تخلیه وجود دارد: +* [اخراج در اثر فشار نود](/docs/concepts/scheduling-eviction/node-pressure-eviction/) +* [اخراج آغازشده توسط API](/docs/concepts/scheduling-eviction/api-eviction/) diff --git a/content/fa/docs/reference/glossary/extensions.md b/content/fa/docs/reference/glossary/extensions.md new file mode 100644 index 0000000000000..81b8236fef43e --- /dev/null +++ b/content/fa/docs/reference/glossary/extensions.md @@ -0,0 +1,18 @@ +--- +title: افزونه‌ها +id: Extensions +date: 2019-02-01 +full_link: /docs/concepts/extend-kubernetes/#extensions +short_description: > + افزونه‌ها اجزای نرم‌افزاری هستند که گسترش می‌یابند و عمیقاً با کوبرنتیز ادغام می‌شوند تا از انواع جدید سخت‌افزار پشتیبانی کنند. + +aka: +tags: +- fundamental +- extension +--- + افزونه‌ها اجزای نرم‌افزاری هستند که گسترش می‌یابند و عمیقاً با کوبرنتیز ادغام می‌شوند تا از انواع جدید سخت‌افزار پشتیبانی کنند. + + + +بسیاری از مدیران خوشه از نسخه میزبانی‌شده یا توزیعیِ کوبرنتیز استفاده می‌کنند. این خوشه‌ها با افزونه‌های از پیش نصب‌شده ارائه می‌شوند. در نتیجه، اغلب کاربران کوبرنتیز نیازی به نصب [افزونه‌ها](/docs/concepts/extend-kubernetes/) ندارند و تعداد بسیار کمی از کاربران لازم است افزونه‌های جدیدی بنویسند. diff --git a/content/fa/docs/reference/glossary/feature-gates.md b/content/fa/docs/reference/glossary/feature-gates.md new file mode 100644 index 0000000000000..e5498509fcb5b --- /dev/null +++ b/content/fa/docs/reference/glossary/feature-gates.md @@ -0,0 +1,21 @@ +--- +title: دروازه ویژگی +id: feature-gate +date: 2023-01-12 +full_link: /docs/reference/command-line-tools-reference/feature-gates/ +short_description: > + راهی برای کنترل فعال بودن یا نبودن یک ویژگی خاص کوبرنتیز. + +aka: +tags: +- fundamental +- operation +--- + +دروازه‌های ویژگی (Feature gates) مجموعه‌ای از کلیدها (رشته‌های مبهم) هستند که می‌توانید با آن‌ها تعیین کنید کدام قابلیت‌های کوبرنتیز در خوشه شما فعال باشند. + + + +می‌توانید این قابلیت‌ها را با استفاده از فلگ خط فرمان `--feature-gates` روی هر مؤلفه کوبرنتیز روشن یا خاموش کنید. +هر مؤلفه کوبرنتیز مجموعه‌ای از دروازه‌های ویژگی مرتبط با همان مؤلفه را برای فعال یا غیرفعال‌سازی در اختیار می‌گذارد. +مستندات کوبرنتیز فهرست کاملِ [دروازه‌های ویژگی](/docs/reference/command-line-tools-reference/feature-gates/) فعلی و مواردی را که کنترل می‌کنند ارائه می‌دهد. diff --git a/content/fa/docs/reference/glossary/finalizer.md b/content/fa/docs/reference/glossary/finalizer.md new file mode 100644 index 0000000000000..94d00f6389517 --- /dev/null +++ b/content/fa/docs/reference/glossary/finalizer.md @@ -0,0 +1,19 @@ +--- +title: نهایی کننده +id: finalizer +date: 2021-07-07 +full_link: /docs/concepts/overview/working-with-objects/finalizers/ +short_description: > + یک کلید فضای نامی که به کوبرنتیز می‌گوید تا زمان برآورده شدن شرایط خاص، قبل از حذف کامل یک شیء علامت‌گذاری شده برای حذف، منتظر بماند. +aka: +tags: +- fundamental +- operation +--- +Finalizerها کلیدهای namespaced هستند که به کوبرنتیز می‌گویند تا زمانی که شرایط خاصی برآورده نشده، منابع علامت‌گذاری‌شده برای حذف را به‌طور کامل حذف نکند. Finalizerها به {{}} هشدار می‌دهند تا منابعی را که شیء حذف‌شده مالک آن‌ها بوده پاک‌سازی کنند. + + + +وقتی به کوبرنتیز دستور می‌دهید شیئی را که دارای finalizer است حذف کند، API کوبرنتیز با مقداردهی به `.metadata.deletionTimestamp` آن شیء را برای حذف علامت‌گذاری کرده و کد وضعیت `202` (HTTP «Accepted») را برمی‌گرداند. شئ هدف در وضعیت terminating باقی می‌ماند تا صفحه کنترل یا دیگر مؤلفه‌ها اقدامات تعریف‌شده توسط finalizerها را انجام دهند. پس از تکمیل این اقدامات، کنترلر finalizerهای مربوطه را از شئ هدف حذف می‌کند. زمانی که فیلد `metadata.finalizers` خالی شود، کوبرنتیز حذف را کامل تلقی کرده و شیء را حذف می‌کند. + +می‌توانید از finalizerها برای کنترل {{}} منابع استفاده کنید. برای مثال، می‌توانید یک finalizer تعریف کنید تا پیش از آنکه کنترلر منبع هدف را حذف کند، منابع یا زیرساخت‌های مرتبط را پاک‌سازی نماید. diff --git a/content/fa/docs/reference/glossary/flexvolume.md b/content/fa/docs/reference/glossary/flexvolume.md new file mode 100644 index 0000000000000..48a8d6cb72d2a --- /dev/null +++ b/content/fa/docs/reference/glossary/flexvolume.md @@ -0,0 +1,22 @@ +--- +title: FlexVolume +id: flexvolume +date: 2018-06-25 +full_link: /docs/concepts/storage/volumes/#flexvolume +short_description: > + FlexVolume یک رابط منسوخ برای ایجاد افزونه‌های حجم خارج از درخت است. {{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}} یک رابط جدیدتر است که چندین مشکل FlexVolume را برطرف می‌کند. + + +aka: +tags: +- storage +--- + FlexVolume یک رابط منسوخ برای ایجاد افزونه‌های حجم خارج از درخت است. {{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}} یک رابط جدیدتر است که چندین مشکل FlexVolume را برطرف می‌کند. + + + +FlexVolumeها به کاربران اجازه می‌دهند درایورهای خود را بنویسند و پشتیبانی از حجم‌هایشان را در کوبرنتیز اضافه کنند. فایل‌های باینری درایور FlexVolume و وابستگی‌های آن باید روی ماشین‌های میزبان نصب شوند که به دسترسی ریشه نیاز دارد. گروه SIG Storage پیشنهاد می‌کند در صورت امکان یک درایور {{< glossary_tooltip text="CSI" term_id="csi" >}} پیاده‌سازی شود، زیرا محدودیت‌های FlexVolume را رفع می‌کند. + +* [FlexVolume در مستندات کوبرنتیز](/docs/concepts/storage/volumes/#flexvolume) +* [اطلاعات بیشتر درباره FlexVolumeها](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md) +* [سؤالات متداول افزونه حجم برای فروشندگان ذخیره‌سازی](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md) diff --git a/content/fa/docs/reference/glossary/garbage-collection.md b/content/fa/docs/reference/glossary/garbage-collection.md new file mode 100644 index 0000000000000..84a68d9a96cdc --- /dev/null +++ b/content/fa/docs/reference/glossary/garbage-collection.md @@ -0,0 +1,25 @@ +--- +title: جمع‌آوری زباله +id: garbage-collection +date: 2021-07-07 +full_link: /docs/concepts/architecture/garbage-collection/ +short_description: > + اصطلاحی کلی برای مکانیزم‌های مختلفی که کوبرنتیز برای پاک‌سازی منابع خوشه استفاده می‌کند. + +aka: +tags: +- fundamental +- operation +--- + +حذف زباله (Garbage collection) اصطلاحی کلی برای مکانیزم‌های مختلفی است که کوبرنتیز برای پاک‌سازی منابع خوشه به‌کار می‌برد. + + + +کوبرنتیز از حذف زباله برای پاک‌سازی منابعی همچون +[کانتینرها و تصاویر بدون استفاده](/docs/concepts/architecture/garbage-collection/#containers-images)، +[پادهای ناموفق](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)، +[اشیائی که متعلق به منبع هدف هستند](/docs/concepts/overview/working-with-objects/owners-dependents/)، +[Jobهای تکمیل‌شده](/docs/concepts/workloads/controllers/ttlafterfinished/)، و منابعی +که منقضی شده یا با شکست مواجه شده‌اند، استفاده می‌کند. + diff --git a/content/fa/docs/reference/glossary/gateway.md b/content/fa/docs/reference/glossary/gateway.md new file mode 100644 index 0000000000000..c9fdfd2b25f2c --- /dev/null +++ b/content/fa/docs/reference/glossary/gateway.md @@ -0,0 +1,19 @@ +--- +title: API دروازه +id: gateway-api +date: 2023-10-19 +full_link: /docs/concepts/services-networking/gateway/ +short_description: > + یک API برای مدل‌سازی شبکه‌سازی سرویس در کوبرنتیز. + +aka: +tags: +- networking +- architecture +- extension +--- + مجموعه‌ای از گونه‌های API برای مدل‌سازی شبکه‌سازی سرویس در کوبرنتیز. + + + +Gateway API مجموعه‌ای از گونه‌های API قابل‌گسترش، نقش‌محور و آگاه از پروتکل را برای مدل‌سازی شبکه‌سازی سرویس در کوبرنتیز فراهم می‌کند. diff --git a/content/fa/docs/reference/glossary/group-version-resource.md b/content/fa/docs/reference/glossary/group-version-resource.md new file mode 100644 index 0000000000000..cdbf1dd2dee62 --- /dev/null +++ b/content/fa/docs/reference/glossary/group-version-resource.md @@ -0,0 +1,17 @@ +--- +title: منبع نسخه گروهی +id: gvr +date: 2023-07-24 +short_description: > + گروه API، نسخه API و نام یک API در کوبرنتیز. + +aka: ["GVR"] +tags: +- architecture +--- +روش نمایش یک منبع منحصربه‌فرد API کوبرنتیز. + + + +Group Version Resourceها (GVR) گروه API، نسخه API و منبع (نام نوع شیء همان‌طور که در URI نمایش داده می‌شود) مرتبط با دسترسی به شناسه مشخص یک شیء در کوبرنتیز را مشخص می‌کنند. +GVRها به شما اجازه می‌دهند اشیای مختلف کوبرنتیز را تعریف کرده و از یکدیگر متمایز کنید، و روشی برای دسترسی به اشیاء ارائه می‌کنند که حتی با تغییر APIها پایدار باقی بماند. diff --git a/content/fa/docs/reference/glossary/helm-chart.md b/content/fa/docs/reference/glossary/helm-chart.md new file mode 100644 index 0000000000000..277b1bb6cf4d1 --- /dev/null +++ b/content/fa/docs/reference/glossary/helm-chart.md @@ -0,0 +1,19 @@ +--- +title: Helm Chart +id: helm-chart +date: 2018-04-12 +full_link: https://helm.sh/docs/topics/charts/ +short_description: > + یک بسته از منابع ازپیش‌پیکربندی‌شده کوبرنتیز که می‌توان آن را با ابزار Helm مدیریت کرد. + +aka: +tags: +- tool +--- + یک بسته از منابع ازپیش‌پیکربندی‌شده کوبرنتیز که می‌توان آن را با ابزار Helm مدیریت کرد. + + + +چارت‌ها روشی قابل تکرار برای ایجاد و به‌اشتراک‌گذاری برنامه‌های کوبرنتیز فراهم می‌کنند. +یک چارت می‌تواند برای استقرار چیزی ساده مانند یک پاد memcached یا چیزی پیچیده مانند یک پشته کامل وب‌اپ با سرورهای HTTP، پایگاه‌های داده، کش‌ها و غیره استفاده شود. + diff --git a/content/fa/docs/reference/glossary/horizontal-pod-autoscaler.md b/content/fa/docs/reference/glossary/horizontal-pod-autoscaler.md new file mode 100644 index 0000000000000..26ca31788725c --- /dev/null +++ b/content/fa/docs/reference/glossary/horizontal-pod-autoscaler.md @@ -0,0 +1,18 @@ +--- +title: مقیاس‌دهنده خودکار افقی پاد +id: horizontal-pod-autoscaler +date: 2018-04-12 +full_link: /docs/tasks/run-application/horizontal-pod-autoscale/ +short_description: > + یک منبع API که تعداد رپلیکای پاد را بر اساس میزان استفاده هدف CPU یا اهداف سفارشی متریک به‌طور خودکار مقیاس می‌کند. + +aka: +- HPA +tags: +- operation +--- + یک منبع API که تعداد رپلیکای {{< glossary_tooltip term_id="pod" >}} را بر اساس میزان استفاده هدف CPU یا اهداف سفارشی متریک به‌طور خودکار مقیاس می‌کند. + + + +HPA معمولاً همراه با {{< glossary_tooltip text="ReplicationControllers" term_id="replication-controller" >}}، {{< glossary_tooltip text="Deployments" term_id="deployment" >}} یا {{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}} استفاده می‌شود. این قابلیت را نمی‌توان روی اشیائی که قابل مقیاس نیستند اعمال کرد؛ برای مثال {{< glossary_tooltip text="DaemonSets" term_id="daemonset" >}}. diff --git a/content/fa/docs/reference/glossary/host-aliases.md b/content/fa/docs/reference/glossary/host-aliases.md new file mode 100644 index 0000000000000..e43cc6d6f9bd1 --- /dev/null +++ b/content/fa/docs/reference/glossary/host-aliases.md @@ -0,0 +1,17 @@ +--- +title: نام‌های مستعار میزبان +id: HostAliases +date: 2019-01-31 +full_link: /docs/reference/generated/kubernetes-api/{{< param "version" >}}/#hostalias-v1-core +short_description: > + یک HostAliases نگاشتی میان نشانی IP و نام میزبان است که در فایل hosts یک پاد تزریق می‌شود. + +aka: +tags: +- operation +--- + یک HostAliases نگاشتی میان نشانی IP و نام میزبان است که در فایل hosts یک {{< glossary_tooltip text="Pod" term_id="pod" >}} تزریق می‌شود. + + + +[HostAliases](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#hostalias-v1-core) فهرستی اختیاری از نام‌های میزبان و نشانی‌های IP است که در صورت مشخص‌شدن، در فایل hosts پاد تزریق می‌شود. این گزینه فقط برای پادهایی معتبر است که hostNetwork نیستند. diff --git a/content/fa/docs/reference/glossary/image.md b/content/fa/docs/reference/glossary/image.md new file mode 100644 index 0000000000000..2303a4c53cd4d --- /dev/null +++ b/content/fa/docs/reference/glossary/image.md @@ -0,0 +1,17 @@ +--- +title: ایمیج +id: image +date: 2018-04-12 +full_link: +short_description: > + نمونه ذخیره‌شده‌ای از یک کانتینر که مجموعه نرم‌افزارهای لازم برای اجرای یک برنامه را در خود دارد. + +aka: +tags: +- fundamental +--- + نمونه ذخیره‌شده یک {{< glossary_tooltip term_id="container" >}} که مجموعه نرم‌افزارهای لازم برای اجرای یک برنامه را در خود دارد. + + + +روشی برای بسته‌بندی نرم‌افزار که امکان ذخیره‌سازی آن در یک رجیستری کانتینر، کشیدن به سامانه محلی و اجرای آن به‌عنوان یک برنامه را فراهم می‌کند. فراداده‌هایی نیز در ایمیج وجود دارد که می‌تواند مشخص کند چه اجرایی باید اجرا شود، چه کسی آن را ساخته است و اطلاعات دیگر. diff --git a/content/fa/docs/reference/glossary/immutable-infrastructure.md b/content/fa/docs/reference/glossary/immutable-infrastructure.md new file mode 100644 index 0000000000000..4ae982f78e0a0 --- /dev/null +++ b/content/fa/docs/reference/glossary/immutable-infrastructure.md @@ -0,0 +1,23 @@ +--- +title: زیرساخت تغییرناپذیر +id: immutable-infrastructure +date: 2024-03-25 +full_link: +short_description: > + زیرساخت تغییرناپذیر به زیرساخت رایانه‌ای (ماشین‌های مجازی، کانتینرها، تجهیزات شبکه) اشاره دارد که پس از استقرار دیگر قابل تغییر نیست. + +aka: +tags: +- architecture +--- + زیرساخت تغییرناپذیر به زیرساخت رایانه‌ای (ماشین‌های مجازی، کانتینرها، تجهیزات شبکه) اشاره دارد که پس از استقرار دیگر قابل تغییر نیست. + + + +تغییرناپذیری می‌تواند از طریق فرایندی خودکار که تغییرات غیرمجاز را بازنویسی می‌کند یا سیستمی که اساساً اجازه تغییر نمی‌دهد، اعمال شود. +{{< glossary_tooltip text="Containers" term_id="container" >}} نمونه خوبی از زیرساخت تغییرناپذیر هستند، زیرا ایجاد تغییرات پایدار در کانتینرها فقط با ساخت نسخه جدید کانتینر یا بازآفرینی کانتینر موجود از روی ایمیج آن امکان‌پذیر است. + +با جلوگیری یا شناسایی تغییرات غیرمجاز، زیرساخت‌های تغییرناپذیر شناسایی و کاهش ریسک‌های امنیتی را آسان‌تر می‌کنند. +عملیات چنین سیستمی بسیار ساده‌تر می‌شود، زیرا مدیران می‌توانند با اطمینان فرض کنند که هیچ‌کس اشتباه یا تغییری را بدون اطلاع‌رسانی اعمال نکرده است. +زیرساخت تغییرناپذیر دست در دست «زیرساخت به‌عنوان کد» پیش می‌رود؛ جایی که تمام خودکاریِ لازم برای ایجاد زیرساخت در کنترل نسخه (مانند Git) ذخیره می‌شود. +این ترکیب از تغییرناپذیری و کنترل نسخه به این معناست که یک گزارش حسابرسی ماندگار از هر تغییر مجاز در سیستم وجود دارد. diff --git a/content/fa/docs/reference/glossary/index.md b/content/fa/docs/reference/glossary/index.md new file mode 100644 index 0000000000000..b0d9d1c432b5f --- /dev/null +++ b/content/fa/docs/reference/glossary/index.md @@ -0,0 +1,15 @@ +--- +approvers: +- xirehat +title: واژه‌نامه +layout: glossary +noedit: true +body_class: glossary +default_active_tag: fundamental +weight: 5 +card: + name: reference + weight: 10 + title: واژه‌نامه +--- + diff --git a/content/fa/docs/reference/glossary/infrastructure-resource.md b/content/fa/docs/reference/glossary/infrastructure-resource.md new file mode 100644 index 0000000000000..5c01bfe2c4bbb --- /dev/null +++ b/content/fa/docs/reference/glossary/infrastructure-resource.md @@ -0,0 +1,22 @@ +--- +title: منبع (زیرساخت) +id: infrastructure-resource +date: 2025-02-09 +short_description: > + مقدار مشخصی از زیرساخت که برای مصرف در دسترس است (CPU، حافظه و غیره). + +aka: +tags: +- architecture +--- + قابلیت‌هایی که به یک یا چند {{< glossary_tooltip text="nodes" term_id="node" >}} (CPU، حافظه، GPUها و غیره) اختصاص داده می‌شود و برای مصرف توسط {{< glossary_tooltip text="Pods" term_id="pod" >}} در حال اجرا روی آن نودها در دسترس قرار می‌گیرد. + +کوبرنتیز همچنین از اصطلاح _منبع_ برای توصیف یک {{< glossary_tooltip text="API resource" term_id="api-resource" >}} استفاده می‌کند. + + + +رایانه‌ها امکانات سخت‌افزاری پایه‌ای را فراهم می‌کنند: توان پردازشی، حافظه ذخیره‌سازی، شبکه و غیره. +این منابع ظرفیت محدودی دارند که با واحد مناسب همان منبع اندازه‌گیری می‌شود (تعداد CPUها، بایت‌های حافظه و غیره). +کوبرنتیز منابع رایج را برای تخصیص به بارهای کاری مجرد می‌کند و از سازوکارهای ابتدایی سیستم‌عامل (برای مثال، {{< glossary_tooltip text="cgroups" term_id="cgroup" >}} در لینوکس) برای مدیریت مصرف توسط {{< glossary_tooltip text="workloads" term_id="workload" >}} بهره می‌برد. + +همچنین می‌توانید از [تخصیص پویای منابع](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/) برای مدیریت خودکار تخصیص‌های پیچیده منابع استفاده کنید. diff --git a/content/fa/docs/reference/glossary/ingress.md b/content/fa/docs/reference/glossary/ingress.md new file mode 100644 index 0000000000000..b1491fe5af12f --- /dev/null +++ b/content/fa/docs/reference/glossary/ingress.md @@ -0,0 +1,19 @@ +--- +title: اینگرس +id: ingress +date: 2018-04-12 +full_link: /docs/concepts/services-networking/ingress/ +short_description: > + یک شیء API که دسترسی خارجی به سرویس‌های یک خوشه، معمولاً HTTP، را مدیریت می‌کند. + +aka: +tags: +- networking +- architecture +- extension +--- + یک شیء API که دسترسی خارجی به سرویس‌های یک خوشه، معمولاً HTTP، را مدیریت می‌کند. + + + +اینگرس ممکن است توازن بار، پایان‌دهی SSL و میزبانی مجازی مبتنی بر نام را فراهم کند. diff --git a/content/fa/docs/reference/glossary/init-container.md b/content/fa/docs/reference/glossary/init-container.md new file mode 100644 index 0000000000000..0298ab4436da9 --- /dev/null +++ b/content/fa/docs/reference/glossary/init-container.md @@ -0,0 +1,20 @@ +--- +title: کانتینر آغازگر +id: init-container +date: 2018-04-12 +full_link: /docs/concepts/workloads/pods/init-containers/ +short_description: > + یک یا چند کانتینر آغازگر که باید پیش از اجرای هر کانتینر برنامه به‌طور کامل اجرا شوند. +aka: +tags: +- fundamental +--- + یک یا چند کانتینر آغازگر {{< glossary_tooltip text="containers" term_id="container" >}} که باید پیش از اجرای هر کانتینر برنامه به‌طور کامل اجرا شوند. + + + +کانتینرهای آغازگر (init) شبیه کانتینرهای معمولیِ برنامه هستند، با یک تفاوت: کانتینرهای آغازگر باید پیش از آنکه هر کانتینر برنامه‌ای بتواند شروع به کار کند، به‌طور کامل اجرا شوند. کانتینرهای آغازگر به‌صورت سری اجرا می‌شوند؛ هر کانتینر آغازگر باید پیش از شروع کانتینر آغازگر بعدی به پایان برسد. + +برخلاف {{< glossary_tooltip text="sidecar containers" term_id="sidecar-container" >}}، کانتینرهای آغازگر پس از راه‌اندازی پاد همچنان در حال اجرا نمی‌مانند. + +برای اطلاعات بیشتر، [کانتینرهای آغازگر](/docs/concepts/workloads/pods/init-containers/) را مطالعه کنید. diff --git a/content/fa/docs/reference/glossary/istio.md b/content/fa/docs/reference/glossary/istio.md new file mode 100644 index 0000000000000..d867be29b9075 --- /dev/null +++ b/content/fa/docs/reference/glossary/istio.md @@ -0,0 +1,19 @@ +--- +title: Istio +id: istio +date: 2018-04-12 +full_link: https://istio.io/latest/about/service-mesh/#what-is-istio +short_description: > + یک پلتفرم متن‌باز (غیر اختصاصی به کوبرنتیز) که روشی یکنواخت برای یکپارچه‌سازی میکروسرویس‌ها، مدیریت جریان ترافیک، اعمال سیاست‌ها و تجمیع داده‌های تله‌متری فراهم می‌کند. + +aka: +tags: +- networking +- architecture +- extension +--- + یک پلتفرم متن‌باز (غیر مختص کوبرنتیز) که راهی یکنواخت برای یکپارچه‌سازی میکروسرویس‌ها، مدیریت جریان ترافیک، اعمال سیاست‌ها و جمع‌آوری داده‌های تله‌متری فراهم می‌کند. + + + +افزودن Istio نیازی به تغییر کد برنامه ندارد. این یک لایه زیرساختی میان سرویس و شبکه است که همراه با استقرار سرویس‌ها معمولاً «مش سرویس» (service mesh) نامیده می‌شود. صفحه کنترل Istio لایه مدیریت خوشه زیرین را انتزاع می‌کند؛ این پلتفرم می‌تواند کوبرنتیز، Mesosphere و غیره باشد. diff --git a/content/fa/docs/reference/glossary/job.md b/content/fa/docs/reference/glossary/job.md new file mode 100644 index 0000000000000..fda671313ed2b --- /dev/null +++ b/content/fa/docs/reference/glossary/job.md @@ -0,0 +1,19 @@ +--- +title: وظیفه +id: job +date: 2018-04-12 +full_link: /docs/concepts/workloads/controllers/job/ +short_description: > + یک وظیفه محدود یا دسته‌ای که تا تکمیل اجرا می‌شود. + +aka: +tags: +- fundamental +- core-object +- workload +--- + یک وظیفه محدود یا دسته‌ای که تا تکمیل اجرا می‌شود. + + + +یک Job یک یا چند شیء {{< glossary_tooltip term_id="pod" >}} ایجاد می‌کند و تضمین می‌کند که تعداد مشخصی از آن‌ها با موفقیت خاتمه یابند. با تکمیل موفق پادها، Job تکمیل‌های موفق را پیگیری می‌کند. diff --git a/content/fa/docs/reference/glossary/jwt.md b/content/fa/docs/reference/glossary/jwt.md new file mode 100644 index 0000000000000..01aea919232cf --- /dev/null +++ b/content/fa/docs/reference/glossary/jwt.md @@ -0,0 +1,20 @@ +--- +title: JSON Web Token (JWT) +id: jwt +date: 2023-01-17 +full_link: https://www.rfc-editor.org/rfc/rfc7519 +short_description: > + روشی برای نمایش ادعاهایی که باید بین دو طرف منتقل شوند. + +aka: +tags: +- security +- architecture +--- + روشی برای نمایش ادعاهایی که باید بین دو طرف منتقل شوند. + + + +JWTها می‌توانند به‌صورت دیجیتالی امضا و رمزگذاری شوند. کوبرنتیز از JWTها به‌عنوان +توکن‌های احراز هویت استفاده می‌کند تا هویت موجودیت‌هایی را که می‌خواهند در یک خوشه +اقداماتی انجام دهند، تأیید کند. diff --git a/content/fa/docs/reference/glossary/kops.md b/content/fa/docs/reference/glossary/kops.md new file mode 100644 index 0000000000000..aa1c7d3e6fe7f --- /dev/null +++ b/content/fa/docs/reference/glossary/kops.md @@ -0,0 +1,29 @@ +--- +title: kOps (Kubernetes Operation) +id: kops +date: 2018-04-12 +full_link: /docs/setup/production-environment/kops/ +short_description: > + kOps نه‌تنها به شما کمک می‌کند یک خوشه کوبرنتیز در سطح تولید با دسترس‌پذیری بالا ایجاد، نابود، ارتقا و نگهداری کنید، بلکه زیرساخت ابری موردنیاز را نیز فراهم می‌کند. + +aka: +tags: +- tool +- operation +--- + +`kOps` نه‌تنها به شما کمک می‌کند یک خوشه کوبرنتیز در سطح تولید و با دسترس‌پذیری بالا را ایجاد، نابود، ارتقا و نگهداری کنید، بلکه زیرساخت ابری موردنیاز را نیز فراهم می‌کند. + + + +{{< note >}} +AWS (Amazon Web Services) در حال حاضر به‌صورت رسمی پشتیبانی می‌شود؛ DigitalOcean، GCE و OpenStack در وضعیت بتا و Azure در وضعیت آلفا هستند. +{{< /note >}} + +`kOps` یک سیستم تأمین خودکار است: + * نصب کاملاً خودکار + * استفاده از DNS برای شناسایی خوشه‌ها + * خودترمیمی: همه‌چیز در گروه‌های مقیاس‌پذیری خودکار اجرا می‌شود + * پشتیبانی از چندین سیستم‌عامل (Amazon Linux، Debian، Flatcar، RHEL، Rocky و Ubuntu) + * پشتیبانی از دسترس‌پذیری بالا + * امکان تأمین مستقیم یا تولید مانیفست‌های Terraform diff --git a/content/fa/docs/reference/glossary/kube-apiserver.md b/content/fa/docs/reference/glossary/kube-apiserver.md new file mode 100644 index 0000000000000..241f889acf47b --- /dev/null +++ b/content/fa/docs/reference/glossary/kube-apiserver.md @@ -0,0 +1,21 @@ +--- +title: سرور API +id: kube-apiserver +date: 2018-04-12 +full_link: /docs/concepts/architecture/#kube-apiserver +short_description: > + مؤلفه کنترل پلین که API کوبرنتیز را ارائه می‌کند. + +aka: +- kube-apiserver +tags: +- architecture +- fundamental +--- + سرور API مؤلفه‌ای از {{< glossary_tooltip text="control plane" term_id="control-plane" >}} کوبرنتیز است که API کوبرنتیز را در معرض قرار می‌دهد. سرور API رابط جلوییِ کنترل پلین کوبرنتیز است. + + + +پیاده‌سازی اصلیِ سرور API کوبرنتیز، [kube-apiserver](/docs/reference/generated/kube-apiserver/) است. +kube-apiserver برای مقیاس‌پذیری افقی طراحی شده است—یعنی با استقرار نمونه‌های بیشتر مقیاس می‌شود. +می‌توانید چندین نمونه kube-apiserver را اجرا کرده و ترافیک را میان آن‌ها متعادل کنید. diff --git a/content/fa/docs/reference/glossary/kube-controller-manager.md b/content/fa/docs/reference/glossary/kube-controller-manager.md new file mode 100644 index 0000000000000..37d8bc1403761 --- /dev/null +++ b/content/fa/docs/reference/glossary/kube-controller-manager.md @@ -0,0 +1,18 @@ +--- +title: مدیر کنترل‌کننده کوبرنتیز +id: kube-controller-manager +date: 2018-04-12 +full_link: /docs/reference/command-line-tools-reference/kube-controller-manager/ +short_description: > + یک مؤلفه کنترل پلین که فرایندهای کنترلر را اجرا می‌کند. + +aka: +tags: +- architecture +- fundamental +--- + یک مؤلفه کنترل پلین که فرایندهای {{< glossary_tooltip text="controller" term_id="controller" >}} را اجرا می‌کند. + + + +از نظر منطقی، هر {{< glossary_tooltip text="controller" term_id="controller" >}} یک فرایند جداگانه است، اما برای کاهش پیچیدگی، همه آن‌ها در یک باینری واحد کامپایل شده و در یک فرایند واحد اجرا می‌شوند. diff --git a/content/fa/docs/reference/glossary/kube-proxy.md b/content/fa/docs/reference/glossary/kube-proxy.md new file mode 100644 index 0000000000000..1e415566f2fbf --- /dev/null +++ b/content/fa/docs/reference/glossary/kube-proxy.md @@ -0,0 +1,25 @@ +--- +title: پراکسی کوبرنتیز +id: kube-proxy +date: 2018-04-12 +full_link: /docs/reference/command-line-tools-reference/kube-proxy/ +short_description: > + `kube-proxy` یک پراکسی شبکه است که روی هر نود در خوشه اجرا می‌شود. + +aka: +tags: +- fundamental +- networking +--- + `kube-proxy` یک پراکسی شبکه است که روی هر +{{< glossary_tooltip text="node" term_id="node" >}} در خوشه شما اجرا می‌شود و بخشی از مفهوم +{{< glossary_tooltip term_id="service">}} کوبرنتیز را پیاده‌سازی می‌کند. + + + +[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) +قوانین شبکه را روی نودها نگهداری می‌کند. این قوانین شبکه امکان برقراری +ارتباط با پادهای شما را از نشست‌های شبکه داخل یا خارج از خوشه فراهم می‌سازد. + +kube-proxy در صورت وجود و در دسترس بودن، از لایه فیلتر بسته سیستم‌عامل استفاده می‌کند؛ +در غیر این صورت، kube-proxy خود ترافیک را هدایت می‌کند. diff --git a/content/fa/docs/reference/glossary/kube-scheduler.md b/content/fa/docs/reference/glossary/kube-scheduler.md new file mode 100644 index 0000000000000..1bc1035ff82f5 --- /dev/null +++ b/content/fa/docs/reference/glossary/kube-scheduler.md @@ -0,0 +1,22 @@ +--- +title: زمان‌بند کوبرنتیز +id: kube-scheduler +date: 2018-04-12 +full_link: /docs/reference/command-line-tools-reference/kube-scheduler/ +short_description: > + یک مؤلفه کنترل پلین که پادهای تازه ایجادشده بدون نود تخصیص‌یافته را پایش می‌کند و نودی را برای اجرای آن‌ها برمی‌گزیند. + +aka: +tags: +- architecture +--- + یک مؤلفه کنترل پلین که پادهای تازه ایجادشده‌ای را که نودی به آن‌ها اختصاص داده نشده است +({{< glossary_tooltip term_id="pod" text="Pods" >}} بی‌نود) پایش می‌کند و نودی را برای اجرای آن‌ها +({{< glossary_tooltip term_id="node" text="node" >}}) انتخاب می‌کند. + + + +عواملی که در تصمیم‌گیری زمان‌بندی در نظر گرفته می‌شوند عبارت‌اند از: +نیازهای منابع به‌صورت فردی و جمعی، محدودیت‌های سخت‌افزاری/نرم‌افزاری/سیاستی، +مشخصات همبستگی (affinity) و ناهمبستگی (anti-affinity)، محلی‌بودن داده‌ها، +تداخل میان بارهای کاری و ضرب‌الاجل‌ها. diff --git a/content/fa/docs/reference/glossary/kubeadm.md b/content/fa/docs/reference/glossary/kubeadm.md new file mode 100644 index 0000000000000..67294d05beac1 --- /dev/null +++ b/content/fa/docs/reference/glossary/kubeadm.md @@ -0,0 +1,18 @@ +--- +title: Kubeadm +id: kubeadm +date: 2018-04-12 +full_link: /docs/reference/setup-tools/kubeadm/ +short_description: > + ابزاری برای نصب سریع کوبرنتیز و راه‌اندازی یک خوشه ایمن. + +aka: +tags: +- tool +- operation +--- + ابزاری برای نصب سریع کوبرنتیز و راه‌اندازی یک خوشه ایمن. + + + +می‌توانید از kubeadm برای نصب هر دو جزء کنترل پلین و اجزای {{< glossary_tooltip text="worker node" term_id="node" >}} استفاده کنید. diff --git a/content/fa/docs/reference/glossary/kubectl.md b/content/fa/docs/reference/glossary/kubectl.md new file mode 100644 index 0000000000000..d378240400c58 --- /dev/null +++ b/content/fa/docs/reference/glossary/kubectl.md @@ -0,0 +1,22 @@ +--- +title: Kubectl +id: kubectl +date: 2018-04-12 +full_link: /docs/reference/kubectl/ +short_description: > + یک ابزار خط فرمان برای ارتباط با خوشه کوبرنتیز. + +aka: +- kubectl +tags: +- tool +- fundamental +--- + ابزاری خط فرمان برای ارتباط با {{< glossary_tooltip text="control plane" term_id="control-plane" >}} خوشه کوبرنتیز با استفاده از API کوبرنتیز است. + + + +می‌توانید با استفاده از `kubectl` اشیای کوبرنتیز را ایجاد، بازرسی، به‌روزرسانی و حذف کنید. + + +در انگلیسی، `kubectl` به‌طور رسمی /kjuːb/ /kənˈtɹəʊl/ («کیوب کنترل») تلفظ می‌شود. diff --git a/content/fa/docs/reference/glossary/kubelet.md b/content/fa/docs/reference/glossary/kubelet.md new file mode 100644 index 0000000000000..848183a5d53e6 --- /dev/null +++ b/content/fa/docs/reference/glossary/kubelet.md @@ -0,0 +1,17 @@ +--- +title: Kubelet +id: kubelet +date: 2018-04-12 +full_link: /docs/reference/generated/kubelet +short_description: > + یک عامل (agent) که روی هر نود در خوشه اجرا می‌شود و اطمینان می‌دهد کانتینرها در یک پاد در حال اجرا باشند. + +aka: +tags: +- fundamental +--- + یک عامل که روی هر {{< glossary_tooltip text="node" term_id="node" >}} در خوشه اجرا می‌شود و اطمینان می‌دهد {{< glossary_tooltip text="containers" term_id="container" >}} در یک {{< glossary_tooltip text="Pod" term_id="pod" >}} در حال اجرا باشند. + + + +[kubelet](/docs/reference/command-line-tools-reference/kubelet/) مجموعه‌ای از PodSpecهایی را که از طریق سازوکارهای مختلف فراهم می‌شوند دریافت می‌کند و اطمینان می‌دهد کانتینرهای توصیف‌شده در آن PodSpecها در حال اجرا و سالم باشند. kubelet کانتینرهایی را که توسط کوبرنتیز ایجاد نشده‌اند مدیریت نمی‌کند. diff --git a/content/fa/docs/reference/glossary/kubernetes-api.md b/content/fa/docs/reference/glossary/kubernetes-api.md new file mode 100644 index 0000000000000..b37d4fa5ac0fd --- /dev/null +++ b/content/fa/docs/reference/glossary/kubernetes-api.md @@ -0,0 +1,18 @@ +--- +title: Kubernetes API +id: kubernetes-api +date: 2018-04-12 +full_link: /docs/concepts/overview/kubernetes-api/ +short_description: > + برنامه‌ای که قابلیت‌های کوبرنتیز را از طریق یک رابط RESTful ارائه می‌دهد و وضعیت خوشه را ذخیره می‌کند. + +aka: +tags: +- fundamental +- architecture +--- + برنامه‌ای که قابلیت‌های کوبرنتیز را از طریق یک رابط RESTful ارائه می‌دهد و وضعیت خوشه را ذخیره می‌کند. + + + +منابع کوبرنتیز و «سوابق قصد» همگی به‌صورت اشیای API ذخیره می‌شوند و از طریق فراخوانی‌های RESTful به API تغییر می‌یابند. این API امکان مدیریت پیکربندی را به‌صورت اعلامی فراهم می‌کند. کاربران می‌توانند مستقیماً یا از طریق ابزارهایی مانند `kubectl` با Kubernetes API تعامل داشته باشند. هسته Kubernetes API منعطف است و می‌تواند برای پشتیبانی از منابع سفارشی نیز گسترش یابد. diff --git a/content/fa/docs/reference/glossary/label.md b/content/fa/docs/reference/glossary/label.md new file mode 100644 index 0000000000000..398d22c947c52 --- /dev/null +++ b/content/fa/docs/reference/glossary/label.md @@ -0,0 +1,17 @@ +--- +title: برچسب +id: label +date: 2018-04-12 +full_link: /docs/concepts/overview/working-with-objects/labels +short_description: > + اشیاء را با ویژگی‌های شناسایی‌کننده‌ای که برای کاربران معنادار و مرتبط هستند نشان می‌کند. + +aka: +tags: +- fundamental +--- + اشیاء را با ویژگی‌های شناسایی‌کننده‌ای که برای کاربران معنادار و مرتبط هستند نشان می‌کند. + + + +برچسب‌ها جفت‌های کلید/مقدار هستند که به اشیائی مانند {{< glossary_tooltip text="Pods" term_id="pod" >}} متصل می‌شوند. از آن‌ها برای سازمان‌دهی و انتخاب زیرمجموعه‌ای از اشیاء استفاده می‌شود. diff --git a/content/fa/docs/reference/glossary/limitrange.md b/content/fa/docs/reference/glossary/limitrange.md new file mode 100644 index 0000000000000..1ea487f99931b --- /dev/null +++ b/content/fa/docs/reference/glossary/limitrange.md @@ -0,0 +1,22 @@ +--- +title: محدوده محدودیت +id: limitrange +date: 2019-04-15 +full_link: /docs/concepts/policy/limit-range/ +short_description: > + محدودیت‌هایی را برای مصرف منابع هر کانتینر یا پاد در یک نام‌فضا فراهم می‌کند. + +aka: +tags: +- core-object +- fundamental +- architecture +related: + - pod + - container + +--- + محدودیت‌هایی را فراهم می‌کند تا مصرف منابع هر {{< glossary_tooltip text="Containers" term_id="container" >}} یا {{< glossary_tooltip text="Pods" term_id="pod" >}} در یک نام‌فضا را محدود کند. + + +LimitRange تعداد اشیائی را که می‌توان بر اساس نوعشان ایجاد کرد، و همچنین میزان منابع محاسباتی‌ای را که ممکن است توسط هر {{< glossary_tooltip text="Containers" term_id="container" >}} یا {{< glossary_tooltip text="Pods" term_id="pod" >}} در یک نام‌فضا درخواست یا مصرف شود، محدود می‌کند. diff --git a/content/fa/docs/reference/glossary/logging.md b/content/fa/docs/reference/glossary/logging.md new file mode 100644 index 0000000000000..f6c44a8cc05e9 --- /dev/null +++ b/content/fa/docs/reference/glossary/logging.md @@ -0,0 +1,18 @@ +--- +title: لاگ‌گیری +id: logging +date: 2019-04-04 +full_link: /docs/concepts/cluster-administration/logging/ +short_description: > + لاگ‌ها فهرست رویدادهایی هستند که توسط خوشه یا برنامه ثبت می‌شوند. + +aka: +tags: +- architecture +- fundamental +--- + لاگ‌ها فهرست رویدادهایی هستند که توسط {{< glossary_tooltip text="cluster" term_id="cluster" >}} یا برنامه ثبت می‌شوند. + + + +لاگ‌های برنامه و سیستم می‌توانند به شما کمک کنند درک کنید درون خوشه شما چه می‌گذرد. این لاگ‌ها به‌ویژه برای اشکال‌زدایی مشکلات و پایش فعالیت خوشه بسیار سودمند هستند. diff --git a/content/fa/docs/reference/glossary/managed-service.md b/content/fa/docs/reference/glossary/managed-service.md new file mode 100644 index 0000000000000..316dfeb786ccf --- /dev/null +++ b/content/fa/docs/reference/glossary/managed-service.md @@ -0,0 +1,18 @@ +--- +title: سرویس مدیریت‌شده +id: managed-service +date: 2018-04-12 +full_link: +short_description: > + یک ارائه نرم‌افزاری که توسط یک ارائه‌دهنده ثالث نگهداری می‌شود. + +aka: +tags: +- extension +--- + یک ارائه نرم‌افزاری که توسط یک ارائه‌دهنده ثالث نگهداری می‌شود. + + + +برخی نمونه‌های سرویس مدیریت‌شده عبارت‌اند از AWS EC2، Azure SQL Database و +GCP Pub/Sub؛ اما هر ارائه نرم‌افزاری‌ای که بتواند توسط یک برنامه استفاده شود می‌تواند سرویس مدیریت‌شده باشد. diff --git a/content/fa/docs/reference/glossary/manifest.md b/content/fa/docs/reference/glossary/manifest.md new file mode 100644 index 0000000000000..c68745c2c9a93 --- /dev/null +++ b/content/fa/docs/reference/glossary/manifest.md @@ -0,0 +1,18 @@ +--- +title: مانیفست +id: manifest +date: 2019-06-28 +short_description: > + مشخصات سریال‌شده یک یا چند شیء API کوبرنتیز. + +aka: +tags: +- fundamental +--- + مشخصات یک شیء API کوبرنتیز در قالب [JSON](https://www.json.org/json-en.html) + یا [YAML](https://yaml.org/) است. + + + +یک مانیفست وضعیت مطلوب یک شیء را مشخص می‌کند تا کوبرنتیز پس از اعمال مانیفست آن را حفظ کند. +در قالب YAML، هر فایل می‌تواند شامل چندین مانیفست باشد. diff --git a/content/fa/docs/reference/glossary/master.md b/content/fa/docs/reference/glossary/master.md new file mode 100644 index 0000000000000..77fe10939f24d --- /dev/null +++ b/content/fa/docs/reference/glossary/master.md @@ -0,0 +1,15 @@ +--- +title: مستر +id: master +date: 2020-04-16 +short_description: > + اصطلاحی قدیمی که به‌عنوان مترادف نودهایی به کار می‌رود که کنترل پلین را اجرا می‌کنند. + +aka: +tags: +- fundamental +--- + اصطلاحی قدیمی که به‌عنوان مترادف برای {{< glossary_tooltip text="nodes" term_id="node" >}} میزبان {{< glossary_tooltip text="control plane" term_id="control-plane" >}} به کار می‌رود. + + +این اصطلاح همچنان توسط برخی ابزارهای تأمین، مانند {{< glossary_tooltip text="kubeadm" term_id="kubeadm" >}}، و سرویس‌های مدیریت‌شده استفاده می‌شود تا {{< glossary_tooltip text="label" term_id="label" >}} کردن {{< glossary_tooltip text="nodes" term_id="node" >}} با `kubernetes.io/role` و کنترل جای‌گذاری {{< glossary_tooltip text="control plane" term_id="control-plane" >}} {{< glossary_tooltip text="pods" term_id="pod" >}} را امکان‌پذیر سازد. diff --git a/content/fa/docs/reference/glossary/member.md b/content/fa/docs/reference/glossary/member.md new file mode 100644 index 0000000000000..6e4433e139d88 --- /dev/null +++ b/content/fa/docs/reference/glossary/member.md @@ -0,0 +1,19 @@ +--- +title: عضو +id: member +date: 2018-04-12 +full_link: +short_description: > + یک مشارکت‌کننده فعال مستمر در جامعه K8s. + +aka: +tags: +- community +--- + یک {{< glossary_tooltip text="contributor" term_id="contributor" >}} فعال و مداوم در جامعه K8s. + + + +اعضا می‌توانند اِیشوها و درخواست‌های کشش (PR) به آن‌ها اختصاص داده شود و از طریق تیم‌های GitHub در {{< glossary_tooltip text="special interest groups (SIGs)" term_id="sig" >}} مشارکت کنند. +آزمون‌های پیش‌ارسال به‌طور خودکار برای PRهای اعضا اجرا می‌شود. +انتظار می‌رود یک عضو به‌عنوان مشارکت‌کننده‌ای فعال در جامعه باقی بماند. diff --git a/content/fa/docs/reference/glossary/minikube.md b/content/fa/docs/reference/glossary/minikube.md new file mode 100644 index 0000000000000..d0b5af5360504 --- /dev/null +++ b/content/fa/docs/reference/glossary/minikube.md @@ -0,0 +1,20 @@ +--- +title: Minikube +id: minikube +date: 2018-04-12 +full_link: /docs/tasks/tools/#minikube +short_description: > + ابزاری برای اجرای کوبرنتیز به‌صورت محلی. + +aka: +tags: +- fundamental +- tool +--- + ابزاری برای اجرای کوبرنتیز به‌صورت محلی. + + + +Minikube یک خوشه کوبرنتیز محلیِ تک‌گره‌ای یا چندگره‌ای را در یک ماشین مجازی روی رایانه شما اجرا می‌کند. +می‌توانید از Minikube برای +[امتحان کوبرنتیز در محیط آموزشی](/docs/tasks/tools/#minikube) استفاده کنید. diff --git a/content/fa/docs/reference/glossary/mirror-pod.md b/content/fa/docs/reference/glossary/mirror-pod.md new file mode 100644 index 0000000000000..ac2e93a71e2b6 --- /dev/null +++ b/content/fa/docs/reference/glossary/mirror-pod.md @@ -0,0 +1,21 @@ +--- +title: پاد آینه‌ای +id: mirror-pod +date: 2019-08-06 +short_description: > + شیئی در سرور API که یک پاد ایستا روی kubelet را دنبال می‌کند. + +aka: +tags: +- fundamental +--- + شیء {{< glossary_tooltip text="pod" term_id="pod" >}} که یک {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} + برای نمایش یک {{< glossary_tooltip text="static pod" term_id="static-pod" >}} استفاده می‌کند. + + + +هنگامی که kubelet در پیکربندی خود یک پاد ایستا پیدا می‌کند، به‌طور خودکار تلاش می‌کند +یک شیء پاد در سرور API کوبرنتیز برای آن ایجاد کند. این به این معناست که پاد +روی سرور API قابل مشاهده خواهد بود، اما نمی‌توان آن را از آنجا کنترل کرد. + +(برای مثال، حذف یک پاد آینه‌ای باعث نمی‌شود که سرویس kubelet اجرای آن را متوقف کند). diff --git a/content/fa/docs/reference/glossary/mixed-version-proxy.md b/content/fa/docs/reference/glossary/mixed-version-proxy.md new file mode 100644 index 0000000000000..d3f55e3bbf393 --- /dev/null +++ b/content/fa/docs/reference/glossary/mixed-version-proxy.md @@ -0,0 +1,21 @@ +--- +title: پراکسی نسخه مختلط (MVP) +id: mvp +date: 2023-07-24 +full_link: /docs/concepts/architecture/mixed-version-proxy/ +short_description: > + ویژگی‌ای که به kube-apiserver امکان می‌دهد یک درخواست منبع را به سرور API همتای دیگری پروکسی کند. +aka: ["MVP"] +tags: +- architecture +--- + ویژگی‌ای برای اینکه kube-apiserver درخواست یک منبع را به سرور API همتای دیگری پروکسی کند. + + + +وقتی یک خوشه چندین سرور API با نسخه‌های متفاوت کوبرنتیز داشته باشد، +این ویژگی امکان می‌دهد درخواست‌های منبع توسط سرور API مناسب سرویس‌دهی شوند. + +MVP به‌صورت پیش‌فرض غیرفعال است و می‌توان آن را با فعال کردن +[دروازه ویژگی](/docs/reference/command-line-tools-reference/feature-gates/) به نام `UnknownVersionInteroperabilityProxy` +هنگام راه‌اندازی {{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}} فعال کرد. diff --git a/content/fa/docs/reference/glossary/name.md b/content/fa/docs/reference/glossary/name.md new file mode 100644 index 0000000000000..f6a1c76ed7e01 --- /dev/null +++ b/content/fa/docs/reference/glossary/name.md @@ -0,0 +1,17 @@ +--- +title: نام +id: name +date: 2018-04-12 +full_link: /docs/concepts/overview/working-with-objects/names +short_description: > + رشته‌ای که توسط کلاینت فراهم می‌شود و در یک URL منبع به شیء اشاره می‌کند، مانند `/api/v1/pods/some-name`. + +aka: +tags: +- fundamental +--- + رشته‌ای که توسط کلاینت فراهم می‌شود و در یک URL منبع به شیء اشاره می‌کند، مانند `/api/v1/pods/some-name`. + + + +در هر زمان فقط یک شیء از یک نوع مشخص می‌تواند یک نام معین داشته باشد. با این حال، اگر آن شیء را حذف کنید، می‌توانید یک شیء جدید با همان نام ایجاد کنید. diff --git a/content/fa/docs/reference/glossary/namespace.md b/content/fa/docs/reference/glossary/namespace.md new file mode 100644 index 0000000000000..b6ef7761d2c8b --- /dev/null +++ b/content/fa/docs/reference/glossary/namespace.md @@ -0,0 +1,19 @@ +--- +title: فضای نام +id: namespace +date: 2018-04-12 +full_link: /docs/concepts/overview/working-with-objects/namespaces +short_description: > + انتزاعی که کوبرنتیز برای جداسازی گروهی از منابع درون یک خوشه به‌کار می‌بَرد. + +aka: +tags: +- fundamental +--- + انتزاعی که کوبرنتیز برای جداسازی گروه‌هایی از منابع درون یک {{< glossary_tooltip text="cluster" term_id="cluster" >}} به‌کار می‌بَرد. + + + +فضاهای نام برای سازمان‌دهی اشیاء در یک خوشه استفاده می‌شوند و روشی برای تقسیم منابع خوشه فراهم می‌کنند. +نام منابع باید درون یک فضای نام یکتا باشد، اما لزومی ندارد میان فضاهای نام مختلف یکتا باشد. +محدوده‌بندی مبتنی بر فضای نام تنها برای اشیای دارای فضای نام _(مانند Deployment، Service و …)_ کاربرد دارد و بر اشیای سراسری خوشه _(مانند StorageClass، Node، PersistentVolume و …)_ قابل اعمال نیست. diff --git a/content/fa/docs/reference/glossary/network-policy.md b/content/fa/docs/reference/glossary/network-policy.md new file mode 100644 index 0000000000000..323ad6e3ffbaa --- /dev/null +++ b/content/fa/docs/reference/glossary/network-policy.md @@ -0,0 +1,20 @@ +--- +title: سیاست شبکه +id: network-policy +date: 2018-04-12 +full_link: /docs/concepts/services-networking/network-policies/ +short_description: > + مشخصه‌ای که تعیین می‌کند گروه‌های پاد چگونه مجازند با یکدیگر و با دیگر نقاط پایانی شبکه ارتباط برقرار کنند. + +aka: +tags: +- networking +- architecture +- extension +- core-object +--- + مشخصه‌ای که تعیین می‌کند گروه‌های پاد چگونه مجازند با یکدیگر و با دیگر نقاط پایانی شبکه ارتباط برقرار کنند. + + + +سیاست‌های شبکه به شما کمک می‌کنند به‌شکل اعلامی پیکربندی کنید کدام پادها مجاز به اتصال به یکدیگر هستند، کدام فضاهای نام اجازه ارتباط دارند، و به‌صورت دقیق روی کدام شماره‌پورت‌ها هر سیاست اجرا شود. منابع `NetworkPolicy` از برچسب‌ها برای انتخاب پادها استفاده می‌کنند و قوانینی را تعریف می‌کنند که مشخص می‌کند چه ترافیکی به پادهای انتخاب‌شده مجاز است. سیاست‌های شبکه توسط افزونه شبکه‌ای که ارائه‌دهنده شبکه پشتیبانی می‌کند، پیاده‌سازی می‌شوند. توجه داشته باشید ایجاد یک منبع سیاست شبکه بدون وجود کنترلری که آن را پیاده‌سازی کند، اثری نخواهد داشت. diff --git a/content/fa/docs/reference/glossary/node-pressure-eviction.md b/content/fa/docs/reference/glossary/node-pressure-eviction.md new file mode 100644 index 0000000000000..7da6bf4d48f74 --- /dev/null +++ b/content/fa/docs/reference/glossary/node-pressure-eviction.md @@ -0,0 +1,22 @@ +--- +title: تخلیه در اثر فشار نود +id: node-pressure-eviction +date: 2021-05-13 +full_link: /docs/concepts/scheduling-eviction/node-pressure-eviction/ +short_description: > + تخلیه در اثر فشار نود فرایندی است که kubelet به‌صورت پیشگیرانه پادها را برای بازیابی منابع روی نودها از کار می‌اندازد. +aka: +- kubelet eviction +tags: +- operation +--- + تخلیه در اثر فشار نود فرایندی است که {{}} به‌طور پیشگیرانه پادها را خاتمه می‌دهد + تا منابع را روی نودها بازیابی کند. + + + +kubelet منابعی مانند CPU، حافظه، فضای دیسک و inodes سامانه فایل را روی نودهای خوشه شما پایش می‌کند. +وقتی یک یا چند مورد از این منابع به سطح مصرف مشخصی برسند، kubelet می‌تواند به‌طور پیشگیرانه یک یا چند پاد را +روی آن نود از کار بیندازد تا منابع را بازیابی کرده و از گرسنگی منابع جلوگیری کند. + +تخلیه در اثر فشار نود با [تخلیه آغازشده توسط API](/docs/concepts/scheduling-eviction/api-eviction/) تفاوت دارد. diff --git a/content/fa/docs/reference/glossary/node.md b/content/fa/docs/reference/glossary/node.md new file mode 100644 index 0000000000000..350c6b73f0d3a --- /dev/null +++ b/content/fa/docs/reference/glossary/node.md @@ -0,0 +1,22 @@ +--- +title: گره +id: node +date: 2018-04-12 +full_link: /docs/concepts/architecture/nodes/ +short_description: > + یک گره، ماشین کارگر در کوبرنتیز است. + +aka: +tags: +- core-object +- fundamental +--- + یک گره، ماشین کارگر در کوبرنتیز است. + + + +یک گره کارگر می‌تواند بسته به خوشه، یک ماشین مجازی یا ماشین فیزیکی باشد. +این ماشین شامل سرویس‌ها و دیمون‌های محلی لازم برای اجرای {{< glossary_tooltip text="Pods" term_id="pod" >}} است و توسط کنترل پلین مدیریت می‌شود. +دیمون‌های روی یک گره شامل {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}، {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}} و یک زمان‌اجرای کانتینر که {{< glossary_tooltip text="CRI" term_id="cri" >}} را پیاده‌سازی می‌کند (مانند {{< glossary_tooltip term_id="docker" >}}) هستند. + +در نسخه‌های اولیه کوبرنتیز، گره‌ها «Minion» نامیده می‌شدند. diff --git a/content/fa/docs/reference/glossary/object.md b/content/fa/docs/reference/glossary/object.md new file mode 100644 index 0000000000000..132ce88b4fdf6 --- /dev/null +++ b/content/fa/docs/reference/glossary/object.md @@ -0,0 +1,21 @@ +--- +title: شیء +id: object +date: 2020-10-12 +full_link: /docs/concepts/overview/working-with-objects/#kubernetes-objects +short_description: > + یک موجودیت در سیستم کوبرنتیز که بخشی از وضعیت خوشه شما را نمایندگی می‌کند. +aka: +tags: +- architecture +- fundamental +--- +یک موجودیت در سیستم کوبرنتیز است. یک شیء یک +{{< glossary_tooltip text="API resource" term_id="api-resource" >}} است که API کوبرنتیز +برای نمایش وضعیت خوشه شما از آن استفاده می‌کند. + +یک شیء در کوبرنتیز معمولاً «رکوردی از قصد» است—پس از اینکه شیء را ایجاد می‌کنید، +{{< glossary_tooltip text="control plane" term_id="control-plane" >}} کوبرنتیز به‌طور مداوم تلاش می‌کند +اطمینان یابد موردی که این شیء نمایندگی می‌کند واقعاً وجود داشته باشد. +با ایجاد یک شیء، در واقع به سیستم کوبرنتیز می‌گویید که می‌خواهید آن بخش از بار کاری +خوشه‌ٔ شما چه شکلی داشته باشد؛ این همان وضعیت مطلوب خوشه شما است. diff --git a/content/fa/docs/reference/glossary/operator-pattern.md b/content/fa/docs/reference/glossary/operator-pattern.md new file mode 100644 index 0000000000000..bed25cf25de87 --- /dev/null +++ b/content/fa/docs/reference/glossary/operator-pattern.md @@ -0,0 +1,23 @@ +--- +title: الگوی اپراتور +id: operator-pattern +date: 2019-05-21 +full_link: /docs/concepts/extend-kubernetes/operator/ +short_description: > + یک کنترلر تخصصی برای مدیریت یک منبع سفارشی + +aka: +tags: +- architecture +--- + [الگوی اپراتور](/docs/concepts/extend-kubernetes/operator/) یک طرح سیستم +است که یک {{< glossary_tooltip term_id="controller" >}} را به یک یا چند منبع سفارشی پیوند می‌دهد. + + + +می‌توانید با افزودن کنترلرهای اضافی به خوشه خود، فراتر از کنترلرهای داخلیِ +کوبرنتیز، آن را گسترش دهید. + +اگر یک برنامه در حال اجرا به‌عنوان کنترلر عمل کند و دسترسی API برای انجام وظایف +روی یک منبع سفارشی تعریف‌شده در کنترل پلین داشته باشد، این نمونه‌ای از +الگوی اپراتور است. diff --git a/content/fa/docs/reference/glossary/persistent-volume-claim.md b/content/fa/docs/reference/glossary/persistent-volume-claim.md new file mode 100644 index 0000000000000..3189cc85fcd16 --- /dev/null +++ b/content/fa/docs/reference/glossary/persistent-volume-claim.md @@ -0,0 +1,18 @@ +--- +title: درخواست حجم پایدار +id: persistent-volume-claim +date: 2018-04-12 +full_link: /docs/concepts/storage/persistent-volumes/#persistentvolumeclaims +short_description: > + منابع ذخیره‌سازی تعریف‌شده در یک PersistentVolume را مطالبه می‌کند تا بتوان آن را به‌عنوان یک وُلِیوم در یک کانتینر مونت کرد. + +aka: +tags: +- core-object +- storage +--- + منابع ذخیره‌سازی تعریف‌شده در یک {{< glossary_tooltip text="PersistentVolume" term_id="persistent-volume" >}} را مطالبه می‌کند تا بتوان آن را به‌عنوان یک وُلِیوم در یک {{< glossary_tooltip text="container" term_id="container" >}} مونت کرد. + + + +مقدار فضای ذخیره‌سازی، نحوه دسترسی به آن (فقط‌خواندنی، خواندن‌نوشتن و/یا انحصاری) و چگونگی بازیابی آن (نگه‌داشتن، بازیافت یا حذف) را مشخص می‌کند. جزئیات خود فضای ذخیره‌سازی در شیء PersistentVolume توصیف شده است. diff --git a/content/fa/docs/reference/glossary/persistent-volume.md b/content/fa/docs/reference/glossary/persistent-volume.md new file mode 100644 index 0000000000000..ebeea13ddb4ec --- /dev/null +++ b/content/fa/docs/reference/glossary/persistent-volume.md @@ -0,0 +1,20 @@ +--- +title: حجم پایدار +id: persistent-volume +date: 2018-04-12 +full_link: /docs/concepts/storage/persistent-volumes/ +short_description: > + یک شیء API که نمایانگر بخشی از فضای ذخیره‌سازی در خوشه است؛ به‌عنوان یک منبع پلاگ‌شدنی عمومی در دسترس است و فراتر از چرخه عمر هر پاد به حیات خود ادامه می‌دهد. + +aka: +tags: +- core-object +- storage +--- + یک شیء API که نمایانگر بخشی از فضای ذخیره‌سازی در خوشه است؛ به‌عنوان یک منبع پلاگ‌شدنی عمومی در دسترس است و فراتر از چرخه عمر هر {{< glossary_tooltip text="Pod" term_id="pod" >}} پایدار می‌ماند. + + + +PersistentVolumeها (PV) یک API ارائه می‌دهند که جزئیات نحوه تأمین فضای ذخیره‌سازی را از نحوه مصرف آن جدا می‌کند. +PVها مستقیماً در سناریوهایی استفاده می‌شوند که فضای ذخیره‌سازی می‌تواند از پیش ایجاد شود (تأمین ایستا). +برای سناریوهایی که نیاز به فضای ذخیره‌سازی در لحظه دارند (تأمین پویا)، به‌جای PV از PersistentVolumeClaimها (PVC) استفاده می‌شود. diff --git a/content/fa/docs/reference/glossary/platform-developer.md b/content/fa/docs/reference/glossary/platform-developer.md new file mode 100644 index 0000000000000..b17eb38733bad --- /dev/null +++ b/content/fa/docs/reference/glossary/platform-developer.md @@ -0,0 +1,24 @@ +--- +title: توسعه‌دهنده پلتفرم +id: platform-developer +date: 2018-04-12 +full_link: +short_description: > + فردی که پلتفرم کوبرنتیز را بر اساس نیازهای پروژه خود سفارشی می‌کند. + +aka: +tags: +- user-type +--- + فردی که پلتفرم کوبرنتیز را بر اساس نیازهای پروژه خود سفارشی می‌کند. + + + +یک توسعه‌دهنده پلتفرم ممکن است—برای مثال—از +[منابع سفارشی](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +یا +[گسترش API کوبرنتیز با لایه تجمیع](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) +استفاده کند تا قابلیت‌هایی را به نمونه کوبرنتیز خود بیفزاید که به‌طور خاص برای برنامه‌شان لازم است. +برخی توسعه‌دهندگان پلتفرم همچنین {{< glossary_tooltip text="contributors" term_id="contributor" >}} هستند و +افزونه‌هایی را توسعه می‌دهند که به جامعه کوبرنتیز اهدا می‌شود. +دیگران افزونه‌های تجاری متن‌بسته یا ویژه سایت توسعه می‌دهند. diff --git a/content/fa/docs/reference/glossary/pod-disruption-budget.md b/content/fa/docs/reference/glossary/pod-disruption-budget.md new file mode 100644 index 0000000000000..cda2da6041b4a --- /dev/null +++ b/content/fa/docs/reference/glossary/pod-disruption-budget.md @@ -0,0 +1,25 @@ +--- +id: pod-disruption-budget +title: بودجه اختلال پاد +full-link: /docs/concepts/workloads/pods/disruptions/ +date: 2019-02-12 +short_description: > + شیئی که تعداد پادهای یک برنامه تکرارشده را که هم‌زمان به‌دلیل اختلالات داوطلبانه از دسترس خارج می‌شوند، محدود می‌کند. + +aka: + - PDB +related: + - pod + - container +tags: + - operation +--- + + یک [بودجه اختلال پاد](/docs/concepts/workloads/pods/disruptions/) به مالک برنامه اجازه می‌دهد + شیئی برای یک برنامه تکرارشده بسازد که تضمین کند تعداد یا درصد مشخصی از + {{< glossary_tooltip text="Pods" term_id="pod" >}} با برچسب تعیین‌شده در هیچ لحظه‌ای + به‌صورت داوطلبانه حذف یا جابه‌جا نشوند. + + + +اختلالات غیرداوطلبانه را نمی‌توان با PDB جلوگیری کرد؛ با این حال، این اختلالات در بودجه حساب می‌شوند. diff --git a/content/fa/docs/reference/glossary/pod-disruption.md b/content/fa/docs/reference/glossary/pod-disruption.md new file mode 100644 index 0000000000000..81f2c0ec48e2e --- /dev/null +++ b/content/fa/docs/reference/glossary/pod-disruption.md @@ -0,0 +1,23 @@ +--- +title: اختلال پاد +id: pod-disruption +full_link: /docs/concepts/workloads/pods/disruptions/ +date: 2021-05-12 +short_description: > + فرایندی که در آن پادها روی گره‌ها به‌صورت داوطلبانه یا غیرداوطلبانه خاتمه می‌یابند. + +aka: +related: + - pod + - container +tags: + - operation +--- + +[اختلال پاد](/docs/concepts/workloads/pods/disruptions/) فرایندی است که در آن +پادها روی گره‌ها به‌صورت داوطلبانه یا غیرداوطلبانه خاتمه می‌یابند. + + + +اختلالات داوطلبانه عمداً توسط مالکان برنامه یا مدیران خوشه آغاز می‌شوند. +اختلالات غیرداوطلبانه غیرعمدی هستند و می‌توانند بر اثر مشکلات اجتناب‌ناپذیر مانند کمبود منابع گره‌ها یا حذف‌های تصادفی ایجاد شوند. diff --git a/content/fa/docs/reference/glossary/pod-lifecycle.md b/content/fa/docs/reference/glossary/pod-lifecycle.md new file mode 100644 index 0000000000000..f1bebc7aaa6ea --- /dev/null +++ b/content/fa/docs/reference/glossary/pod-lifecycle.md @@ -0,0 +1,19 @@ +--- +title: چرخه عمر پاد +id: pod-lifecycle +date: 2019-02-17 +full-link: /docs/concepts/workloads/pods/pod-lifecycle/ +related: + - pod + - container +tags: + - fundamental +short_description: > + توالی وضعیت‌هایی که یک پاد در طول عمر خود طی می‌کند. + +--- + توالی وضعیت‌هایی که یک پاد در طول عمر خود طی می‌کند. + + + +[چرخه عمر پاد](/docs/concepts/workloads/pods/pod-lifecycle/) با فازهای یک پاد تعریف می‌شود. پنج فاز ممکن برای پاد وجود دارد: Pending، Running، Succeeded، Failed و Unknown. توضیح سطح بالای وضعیت پاد در فیلد `phase` از [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core) خلاصه می‌شود. diff --git a/content/fa/docs/reference/glossary/pod-priority.md b/content/fa/docs/reference/glossary/pod-priority.md new file mode 100644 index 0000000000000..a3ddac3e24901 --- /dev/null +++ b/content/fa/docs/reference/glossary/pod-priority.md @@ -0,0 +1,17 @@ +--- +title: اولویت پاد +id: pod-priority +date: 2019-01-31 +full_link: /docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority +short_description: > + اولویت پاد میزان اهمیت یک پاد را نسبت به پادهای دیگر نشان می‌دهد. + +aka: +tags: +- operation +--- + اولویت پاد میزان اهمیت یک {{< glossary_tooltip term_id="pod" >}} را نسبت به پادهای دیگر نشان می‌دهد. + + + +[اولویت پاد](/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority) امکان تعیین اولویت زمان‌بندی یک پاد را بالاتر یا پایین‌تر از سایر پادها فراهم می‌کند—ویژگی‌ای مهم برای بارهای کاری در خوشه‌های تولیدی. diff --git a/content/fa/docs/reference/glossary/pod-security-policy.md b/content/fa/docs/reference/glossary/pod-security-policy.md new file mode 100644 index 0000000000000..2a4a088960417 --- /dev/null +++ b/content/fa/docs/reference/glossary/pod-security-policy.md @@ -0,0 +1,21 @@ +--- +title: سیاست امنیتی پاد +id: pod-security-policy +date: 2018-04-12 +full_link: /docs/concepts/security/pod-security-policy/ +short_description: > + امکان مجوزدهی دقیق برای ایجاد و به‌روزرسانی پاد را فراهم می‌کند. + +aka: +tags: +- core-object +- fundamental +--- + امکان مجوزدهی دقیق برای ایجاد و به‌روزرسانی {{< glossary_tooltip term_id="pod" >}} را فراهم می‌کند. + + + +یک منبع در سطح خوشه که جنبه‌های حساس به امنیتِ مشخصات پاد را کنترل می‌کند. اشیای `PodSecurityPolicy` مجموعه‌ای از شرایط را تعریف می‌کنند که یک پاد باید با آن‌ها اجرا شود تا در سیستم پذیرفته شود، و همچنین مقادیر پیش‌فرض را برای فیلدهای مرتبط تعیین می‌کنند. کنترل «سیاست امنیتی پاد» به‌عنوان یک کنترلر پذیرش اختیاری پیاده‌سازی شده است. + +`PodSecurityPolicy` از نسخه v1.21 کوبرنتیز منسوخ و در v1.25 حذف شد. +به‌عنوان جایگزین، از [Pod Security Admission](/docs/concepts/security/pod-security-admission/) یا یک افزونه پذیرش شخص ثالث استفاده کنید. diff --git a/content/fa/docs/reference/glossary/pod-template.md b/content/fa/docs/reference/glossary/pod-template.md new file mode 100644 index 0000000000000..9f251e03cfcce --- /dev/null +++ b/content/fa/docs/reference/glossary/pod-template.md @@ -0,0 +1,28 @@ +--- +title: قالب پاد +id: pod-template +date: 2024-10-13 +short_description: > + قالبی برای ایجاد پادها. + +aka: + - pod template +tags: +- core-object + +--- +یک شیء API که قالبی برای ایجاد {{< glossary_tooltip text="Pods" term_id="pod" >}} تعریف می‌کند. +رابط PodTemplate همچنین در تعاریف API برای مدیریت بار کاری، مانند +{{< glossary_tooltip text="Deployment" term_id="deployment" >}} یا +{{< glossary_tooltip text="StatefulSets" term_id="StatefulSet" >}}, تعبیه شده است. + + + +قالب‌های پاد به شما اجازه می‌دهند فراداده مشترک (مانند برچسب‌ها یا قالبی برای نام پاد جدید) +و نیز وضعیت مطلوب یک پاد را مشخص کنید. +کنترلرهای [مدیریت بار کاری](/docs/concepts/workloads/controllers/) از قالب‌های پاد +(که در شیء دیگری مانند Deployment یا StatefulSet جای گرفته‌اند) +برای تعریف و مدیریت یک یا چند {{< glossary_tooltip text="Pods" term_id="pod" >}} استفاده می‌کنند. +وقتی چندین پاد بر اساس یک قالب واحد ایجاد شوند، به آن‌ها +{{< glossary_tooltip term_id="replica" text="رپلیکا" >}} گفته می‌شود. +اگرچه می‌توانید یک شیء PodTemplate را مستقیماً ایجاد کنید، معمولاً نیازی به این کار ندارید. diff --git a/content/fa/docs/reference/glossary/pod.md b/content/fa/docs/reference/glossary/pod.md new file mode 100644 index 0000000000000..6d6cb30b0f3bb --- /dev/null +++ b/content/fa/docs/reference/glossary/pod.md @@ -0,0 +1,18 @@ +--- +title: پاد +id: pod +date: 2018-04-12 +full_link: /docs/concepts/workloads/pods/ +short_description: > + یک پاد نمایانگر مجموعه‌ای از کانتینرهای در حال اجرا در خوشه شما است. + +aka: +tags: +- core-object +- fundamental +--- + کوچک‌ترین و ساده‌ترین شیء کوبرنتیز. یک پاد نمایانگر مجموعه‌ای از {{< glossary_tooltip text="containers" term_id="container" >}} در حال اجرا روی خوشه شما است. + + + +یک پاد معمولاً برای اجرای یک کانتینر اصلی تنظیم می‌شود. همچنین می‌تواند کانتینرهای سایدکار اختیاری را اجرا کند که ویژگی‌های کمکی مانند لاگ‌گیری را اضافه می‌کنند. پادها معمولاً توسط یک {{< glossary_tooltip term_id="deployment" >}} مدیریت می‌شوند. diff --git a/content/fa/docs/reference/glossary/preemption.md b/content/fa/docs/reference/glossary/preemption.md new file mode 100644 index 0000000000000..58fb88d4b9069 --- /dev/null +++ b/content/fa/docs/reference/glossary/preemption.md @@ -0,0 +1,17 @@ +--- +title: پیش‌دستی +id: preemption +date: 2019-01-31 +full_link: /docs/concepts/scheduling-eviction/pod-priority-preemption/#preemption +short_description: > + منطق پیش‌دستی در کوبرنتیز به یک پاد معلق کمک می‌کند با تخلیه پادهای کم‌اولویت روی همان گره، گره مناسب خود را بیابد. + +aka: +tags: +- operation +--- + منطق پیش‌دستی در کوبرنتیز به یک {{< glossary_tooltip term_id="pod" >}} معلق کمک می‌کند با تخلیه پادهای کم‌اولویت موجود روی آن {{< glossary_tooltip term_id="node" >}}، گره مناسب خود را بیابد. + + + +اگر یک پاد نتواند زمان‌بندی شود، زمان‌بند تلاش می‌کند [پیش‌دستی](/docs/concepts/scheduling-eviction/pod-priority-preemption/#preemption) کرده و پادهای کم‌اولویت را تخلیه کند تا زمان‌بندی پاد معلق ممکن شود. diff --git a/content/fa/docs/reference/glossary/priority-class.md b/content/fa/docs/reference/glossary/priority-class.md new file mode 100644 index 0000000000000..86cf40a819fda --- /dev/null +++ b/content/fa/docs/reference/glossary/priority-class.md @@ -0,0 +1,20 @@ +--- +title: کلاس اولویت +id: priority-class +date: 2024-03-19 +full_link: /docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass +short_description: > + نگاشتی از یک نام کلاس به اولویت زمان‌بندی که یک پاد باید داشته باشد. +aka: +tags: +- core-object +--- + یک PriorityClass کلاسی نام‌گذاری‌شده برای اولویت زمان‌بندی است که باید به پادهای آن کلاس اختصاص یابد. + + + +یک [PriorityClass](/docs/concepts/scheduling-eviction/pod-priority-preemption/#how-to-use-priority-and-preemption) +شیئی غیرِ نام‌فضا‌دار است که یک نام را به یک مقدار عددی اولویت برای یک {{< glossary_tooltip term_id="pod" text="Pod" >}} نگاشت می‌کند. +نام در فیلد `metadata.name` و مقدار اولویت در فیلد `value` مشخص می‌شود. +مقادیر اولویت در بازه -2147483648 تا 1000000000 (شامل هر دو حد) قرار دارند؛ +اعداد بزرگ‌تر نشان‌دهنده اولویت بالاتر هستند. \ No newline at end of file diff --git a/content/fa/docs/reference/glossary/probe.md b/content/fa/docs/reference/glossary/probe.md new file mode 100644 index 0000000000000..23b4d039299cd --- /dev/null +++ b/content/fa/docs/reference/glossary/probe.md @@ -0,0 +1,17 @@ +--- +title: Probe +id: probe +date: 2023-03-21 +full_link: /docs/concepts/workloads/pods/pod-lifecycle/#container-probes + +short_description: > + بررسی دوره‌ای که kubelet روی یک کانتینر در یک پاد انجام می‌دهد. + +tags: +- tool +--- + بررسی‌ای است که {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} به‌طور دوره‌ای روی یک کانتینرِ در حال اجرای یک پاد انجام می‌دهد تا وضعیت و سلامت آن را تعیین کرده و چرخه عمر کانتینر را به‌روز کند. + + + +برای اطلاعات بیشتر، [پروب‌های کانتینر](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes) را بخوانید. diff --git a/content/fa/docs/reference/glossary/proxy.md b/content/fa/docs/reference/glossary/proxy.md new file mode 100644 index 0000000000000..66ce77ebb0250 --- /dev/null +++ b/content/fa/docs/reference/glossary/proxy.md @@ -0,0 +1,25 @@ +--- +title: پراکسی +id: proxy +date: 2019-09-10 +short_description: > + برنامه‌ای که به‌عنوان واسطه بین کلاینت‌ها و سرورها عمل می‌کند. + +aka: +tags: +- networking +--- + در محاسبات، پراکسی سروری است که به‌عنوان واسطه برای یک سرویس راه دور عمل می‌کند. + + + +کلاینت با پراکسی تعامل می‌کند؛ پراکسی داده‌های کلاینت را به سرور واقعی منتقل می‌کند؛ +سرور واقعی به پراکسی پاسخ می‌دهد؛ پراکسی پاسخ سرور واقعی را به کلاینت می‌فرستد. + +[kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) یک +پراکسی شبکه است که روی هر گره در خوشه شما اجرا می‌شود و بخشی از مفهوم +{{< glossary_tooltip term_id="service">}} کوبرنتیز را پیاده‌سازی می‌کند. + +می‌توانید kube-proxy را به‌عنوان یک سرویس پراکسی ساده در فضای کاربری اجرا کنید. +اگر سیستم‌عامل شما از آن پشتیبانی می‌کند، می‌توانید به‌جای آن kube-proxy را در حالت ترکیبی اجرا کنید +که با مصرف منابع سیستمی کمتر، همان اثر کلی را به دست می‌آورد. diff --git a/content/fa/docs/reference/glossary/qos-class.md b/content/fa/docs/reference/glossary/qos-class.md new file mode 100644 index 0000000000000..6bb2ced64d3a1 --- /dev/null +++ b/content/fa/docs/reference/glossary/qos-class.md @@ -0,0 +1,23 @@ +--- +title: QoS Class +id: qos-class +date: 2019-04-15 +full_link: /docs/concepts/workloads/pods/pod-qos/ +short_description: > + QoS Class (Quality of Service Class) provides a way for Kubernetes to classify pods within the cluster into several classes and make decisions about scheduling and eviction. + +aka: +tags: +- fundamental +- architecture +related: + - pod + +--- + QoS Class (Quality of Service Class) provides a way for Kubernetes to classify Pods within the cluster into several classes and make decisions about scheduling and eviction. + + +QoS Class of a Pod is set at creation time based on its compute resources requests and limits settings. QoS classes are used to make decisions about Pods scheduling and eviction. +Kubernetes can assign one of the following QoS classes to a Pod: `Guaranteed`, `Burstable` or `BestEffort`. + + diff --git a/content/fa/docs/reference/glossary/quantity.md b/content/fa/docs/reference/glossary/quantity.md new file mode 100644 index 0000000000000..17d29e7ca0c20 --- /dev/null +++ b/content/fa/docs/reference/glossary/quantity.md @@ -0,0 +1,25 @@ +--- +title: کمیت +id: quantity +date: 2018-08-07 +full_link: +short_description: > + نمایش اعداد کوچک یا بزرگ به‌صورت عدد صحیح با استفاده از پسوندهای SI. + +aka: +tags: +- fundamental + +--- + نمایش اعداد کوچک یا بزرگ به‌صورت عدد صحیح با استفاده از پسوندهای [SI](https://en.wikipedia.org/wiki/International_System_of_Units). + + + +کمیت‌ها نمایش اعداد کوچک یا بزرگ هستند که از یادداشت فشرده عدد صحیح همراه با پسوندهای SI استفاده می‌کنند. +اعداد کسری با واحد میلی نمایش داده می‌شوند، در حالی که اعداد بزرگ می‌توانند با واحدهای کیلو، مگا یا گیگا بیان شوند. + +به‌عنوان مثال، عدد `1.5` به‌صورت `1500m` نمایش داده می‌شود، در حالی که عدد `1000` می‌تواند به‌صورت `1k` و `1000000` به‌صورت `1M` بیان شود. همچنین می‌توانید از پسوندهای [نمادگذاری دودویی](https://en.wikipedia.org/wiki/Binary_prefix) استفاده کنید؛ عدد 2048 را می‌توان به شکل `2Ki` نوشت. + +واحدهای ده‌دهی (توانِ ۱۰) پذیرفته‌شده عبارت‌اند از: `m` (میلی)، `k` (کیلو، عمداً با حروف کوچک)، `M` (مگا)، `G` (گیگا)، `T` (ترا)، `P` (پتا)، `E` (اگزا). + +واحدهای دودویی (توانِ ۲) پذیرفته‌شده عبارت‌اند از: `Ki` (کیبی)، `Mi` (مبی)، `Gi` (گیبی)، `Ti` (تبی)، `Pi` (پبی)، `Ei` (اِکسی). diff --git a/content/fa/docs/reference/glossary/rbac.md b/content/fa/docs/reference/glossary/rbac.md new file mode 100644 index 0000000000000..0989f812dfa22 --- /dev/null +++ b/content/fa/docs/reference/glossary/rbac.md @@ -0,0 +1,32 @@ +--- +title: RBAC (Role-Based Access Control) +id: rbac +date: 2018-04-12 +full_link: /docs/reference/access-authn-authz/rbac/ +short_description: > + تصمیم‌گیری‌های مجوزدهی را مدیریت می‌کند و به مدیران اجازه می‌دهد خط‌مشی‌های دسترسی را به‌صورت پویا از طریق Kubernetes API پیکربندی کنند. + +aka: +tags: +- security +- fundamental +--- + تصمیم‌گیری‌های مجوزدهی را مدیریت می‌کند و به مدیران اجازه می‌دهد خط‌مشی‌های دسترسی را به‌صورت پویا از طریق {{< glossary_tooltip text="Kubernetes API" term_id="kubernetes-api" >}} پیکربندی کنند. + + + +RBAC از چهار نوع شیء در کوبرنتیز استفاده می‌کند: + +Role +: قوانین مجوز را در یک فضای نام مشخص تعریف می‌کند. + +ClusterRole +: قوانین مجوز را در سطح کل خوشه تعریف می‌کند. + +RoleBinding +: مجوزهای تعریف‌شده در یک Role را به مجموعه‌ای از کاربران در یک فضای نام مشخص اعطا می‌کند. + +ClusterRoleBinding +: مجوزهای تعریف‌شده در یک ClusterRole را به مجموعه‌ای از کاربران در سطح کل خوشه اعطا می‌کند. + +برای اطلاعات بیشتر، [RBAC](/docs/reference/access-authn-authz/rbac/) را ببینید. diff --git a/content/fa/docs/reference/glossary/replica-set.md b/content/fa/docs/reference/glossary/replica-set.md new file mode 100644 index 0000000000000..b013bd50c59e3 --- /dev/null +++ b/content/fa/docs/reference/glossary/replica-set.md @@ -0,0 +1,21 @@ +--- +title: ReplicaSet +id: replica-set +date: 2018-04-12 +full_link: /docs/concepts/workloads/controllers/replicaset/ +short_description: > + ReplicaSet تضمین می‌کند که تعداد مشخصی از رپلیکای پاد به‌طور همزمان در حال اجرا باشند. + +aka: +tags: +- fundamental +- core-object +- workload +--- + یک ReplicaSet (هدفش این است که) مجموعه‌ای از پادهای رپلیکا را در هر لحظه در حال اجرا نگه دارد. + + + +اشیای بارکاری مانند {{< glossary_tooltip term_id="deployment" >}} از ReplicaSet استفاده می‌کنند +تا بر اساس مشخصات آن ReplicaSet اطمینان یابند تعداد پیکربندی‌شده‌ای از +{{< glossary_tooltip term_id="pod" text="Pods" >}} در خوشه شما در حال اجرا باشند. diff --git a/content/fa/docs/reference/glossary/replica.md b/content/fa/docs/reference/glossary/replica.md new file mode 100644 index 0000000000000..1860b8f829cf2 --- /dev/null +++ b/content/fa/docs/reference/glossary/replica.md @@ -0,0 +1,25 @@ +--- +title: Replica +id: replica +date: 2023-06-11 +full_link: +short_description: > + رپلیکاها نسخه‌های کپی پادها هستند که با حفظ نمونه‌های یکسان، دسترس‌پذیری، مقیاس‌پذیری و تحمل خطا را تضمین می‌کنند. +aka: +tags: +- fundamental +- workload +--- + یک نسخه کپی از یک {{< glossary_tooltip text="Pod" term_id="pod" >}} یا مجموعه‌ای از پادها. +رپلیکاها با نگهداری چندین نمونه یکسان از یک پاد، دسترس‌پذیری بالا، مقیاس‌پذیری و تحمل خطا را فراهم می‌کنند. + + + +رپلیکاها در کوبرنتیز معمولاً برای دستیابی به وضعیت مطلوب برنامه و قابلیت اطمینان به‌کار می‌روند. +آن‌ها امکان مقیاس و توزیع بار کاری را میان چند گره در خوشه فراهم می‌کنند. + +با تعیین تعداد رپلیکا در یک Deployment یا ReplicaSet، کوبرنتیز تضمین می‌کند که +تعداد مشخص‌شده نمونه‌ها در حال اجرا باشد و در صورت نیاز این تعداد را به‌طور خودکار تنظیم می‌کند. + +مدیریت رپلیکاها امکان متعادل‌سازی بار کارا، به‌روزرسانی غلتان و +قابلیت خودترمیم را در یک خوشه کوبرنتیز فراهم می‌کند. diff --git a/content/fa/docs/reference/glossary/replication-controller.md b/content/fa/docs/reference/glossary/replication-controller.md new file mode 100644 index 0000000000000..2d767c0093abb --- /dev/null +++ b/content/fa/docs/reference/glossary/replication-controller.md @@ -0,0 +1,26 @@ +--- +title: ReplicationController +id: replication-controller +date: 2018-04-12 +full_link: +short_description: > + یک شیء API (منسوخ) که یک برنامه تکرارشده را مدیریت می‌کند. + +aka: +tags: +- workload +- core-object +--- + یک منبع بارکاری که یک برنامه تکرارشده را مدیریت می‌کند و تضمین می‌کند +تعداد مشخصی از نمونه‌های یک {{< glossary_tooltip text="Pod" term_id="pod" >}} در حال اجرا باشند. + + + +کنترل پلین تضمین می‌کند که تعداد تعریف‌شده‌ای از پادها در حال اجرا بمانند، +حتی اگر بعضی از پادها از کار بیفتند، شما پادها را به‌صورت دستی حذف کنید +یا بیش از حد پاد به‌اشتباه راه‌اندازی شود. + +{{< note >}} +ReplicationController منسوخ شده است. به +{{< glossary_tooltip text="Deployment" term_id="deployment" >}} مراجعه کنید که مشابه است. +{{< /note >}} diff --git a/content/fa/docs/reference/glossary/resource-quota.md b/content/fa/docs/reference/glossary/resource-quota.md new file mode 100644 index 0000000000000..3de0eababf4b8 --- /dev/null +++ b/content/fa/docs/reference/glossary/resource-quota.md @@ -0,0 +1,19 @@ +--- +title: سهمیه منابع +id: resource-quota +date: 2018-04-12 +full_link: /docs/concepts/policy/resource-quotas/ +short_description: > + محدودیت‌هایی را فراهم می‌کند که مصرف تجمعی منابع در هر فضای نام را محدود می‌کند. + +aka: +tags: +- fundamental +- operation +- architecture +--- + محدودیت‌هایی را فراهم می‌کند که مصرف تجمعی منابع در هر {{< glossary_tooltip term_id="namespace" >}} را محدود می‌کند. + + + +تعداد اشیائی را که می‌توان بر اساس نوع در یک فضای نام ایجاد کرد، و همچنین مجموع منابع محاسباتی‌ای را که ممکن است توسط منابع در آن پروژه مصرف شود، محدود می‌کند. diff --git a/content/fa/docs/reference/glossary/reviewer.md b/content/fa/docs/reference/glossary/reviewer.md new file mode 100644 index 0000000000000..f4ede6b290cdd --- /dev/null +++ b/content/fa/docs/reference/glossary/reviewer.md @@ -0,0 +1,17 @@ +--- +title: بازبین +id: reviewer +date: 2018-04-12 +full_link: +short_description: > + فردی که کد را از نظر کیفیت و درستی در بخشی از پروژه بررسی می‌کند. + +aka: +tags: +- community +--- + فردی که کد را از نظر کیفیت و درستی در بخشی از پروژه بررسی می‌کند. + + + +بازبین‌ها هم از پایگاه کد و هم از اصول مهندسی نرم‌افزار آگاهی دارند. وضعیت بازبین به بخشی از پایگاه کد محدود می‌شود. diff --git a/content/fa/docs/reference/glossary/secret.md b/content/fa/docs/reference/glossary/secret.md new file mode 100644 index 0000000000000..714d027ea2b03 --- /dev/null +++ b/content/fa/docs/reference/glossary/secret.md @@ -0,0 +1,27 @@ +--- +title: Secret +id: secret +date: 2018-04-12 +full_link: /docs/concepts/configuration/secret/ +short_description: > + اطلاعات حساس مانند گذرواژه‌ها، توکن‌های OAuth و کلیدهای SSH را ذخیره می‌کند. + +aka: +tags: +- core-object +- security +--- + اطلاعات حساس مانند گذرواژه‌ها، توکن‌های OAuth و کلیدهای SSH را ذخیره می‌کند. + + + +Secret‌ها کنترل بیشتری بر نحوه استفاده از اطلاعات حساس در اختیار شما می‌گذارند و +خطر افشای تصادفی را کاهش می‌دهند. مقادیر Secret به‌صورت رشته‌های base64 کدگذاری می‌شوند و +به‌طور پیش‌فرض بدون رمزنگاری ذخیره می‌شوند، اما می‌توان آن‌ها را طوری پیکربندی کرد که +[در حالت سکون رمزنگاری شوند](/docs/tasks/administer-cluster/encrypt-data/#ensure-all-secrets-are-encrypted). + +یک {{< glossary_tooltip text="Pod" term_id="pod" >}} می‌تواند به روش‌های گوناگون به Secret ارجاع دهد؛ +برای نمونه از طریق ماونت یک وُلِیوم یا به‌صورت متغیر محیطی. +Secretها برای داده‌های محرمانه طراحی شده‌اند و +[ConfigMapها](/docs/tasks/configure-pod-container/configure-pod-configmap/) +برای داده‌های غیرمحرمانه در نظر گرفته شده‌اند. diff --git a/content/fa/docs/reference/glossary/security-context.md b/content/fa/docs/reference/glossary/security-context.md new file mode 100644 index 0000000000000..0503c8f329fe2 --- /dev/null +++ b/content/fa/docs/reference/glossary/security-context.md @@ -0,0 +1,23 @@ +--- +title: Security Context +id: security-context +date: 2018-04-12 +full_link: /docs/tasks/configure-pod-container/security-context/ +short_description: > + فیلد securityContext تنظیمات امتیاز و کنترل دسترسی برای یک پاد یا کانتینر را تعریف می‌کند. + +aka: +tags: +- security +--- + فیلد `securityContext` تنظیمات امتیاز و کنترل دسترسی را برای +یک {{< glossary_tooltip text="Pod" term_id="pod" >}} یا +{{< glossary_tooltip text="container" term_id="container" >}} تعریف می‌کند. + + + +در یک `securityContext` می‌توانید موارد زیر را تعریف کنید: کاربری که فرایندها با آن اجرا می‌شوند، +گروهی که فرایندها با آن اجرا می‌شوند و تنظیمات امتیاز. +همچنین می‌توانید سیاست‌های امنیتی را پیکربندی کنید (برای نمونه: SELinux، AppArmor یا seccomp). + +تنظیم `PodSpec.securityContext` برای همه کانتینرهای یک پاد اعمال می‌شود. diff --git a/content/fa/docs/reference/glossary/selector.md b/content/fa/docs/reference/glossary/selector.md new file mode 100644 index 0000000000000..546e5c4cbce88 --- /dev/null +++ b/content/fa/docs/reference/glossary/selector.md @@ -0,0 +1,17 @@ +--- +title: انتخاب‌گر +id: selector +date: 2018-04-12 +full_link: /docs/concepts/overview/working-with-objects/labels/ +short_description: > + به کاربران اجازه می‌دهد فهرستی از منابع را بر اساس برچسب‌ها فیلتر کنند. + +aka: +tags: +- fundamental +--- + به کاربران اجازه می‌دهد فهرستی از منابع را بر اساس {{< glossary_tooltip text="labels" term_id="label" >}} فیلتر کنند. + + + +هنگام پرس‌وجوی فهرست منابع، سلکتورها اعمال می‌شوند تا آن‌ها را بر اساس برچسب‌ها فیلتر کنند. diff --git a/content/fa/docs/reference/glossary/service-account.md b/content/fa/docs/reference/glossary/service-account.md new file mode 100644 index 0000000000000..aeded5f8efc92 --- /dev/null +++ b/content/fa/docs/reference/glossary/service-account.md @@ -0,0 +1,18 @@ +--- +title: ServiceAccount +id: service-account +date: 2018-04-12 +full_link: /docs/tasks/configure-pod-container/configure-service-account/ +short_description: > + هویت لازم برای فرآیندهایی که در یک پاد اجرا می‌شوند را فراهم می‌کند. + +aka: +tags: +- fundamental +- core-object +--- + هویتی برای فرآیندهایی فراهم می‌کند که در یک {{< glossary_tooltip text="Pod" term_id="pod" >}} اجرا می‌شوند. + + + +وقتی فرآیندهای درون پاد به خوشه دسترسی پیدا می‌کنند، سرور API آن‌ها را به‌عنوان یک حساب سرویس مشخص (برای مثال `default`) احراز هویت می‌کند. هنگام ایجاد یک پاد، اگر حساب سرویس مشخص نکنید، به‌طور خودکار حساب سرویس پیش‌فرض در همان {{< glossary_tooltip text="Namespace" term_id="namespace" >}} به آن اختصاص داده می‌شود. diff --git a/content/fa/docs/reference/glossary/service-catalog.md b/content/fa/docs/reference/glossary/service-catalog.md new file mode 100644 index 0000000000000..6c2dfc2869a08 --- /dev/null +++ b/content/fa/docs/reference/glossary/service-catalog.md @@ -0,0 +1,17 @@ +--- +title: کاتالوگ سرویس +id: service-catalog +date: 2018-04-12 +full_link: +short_description: > + یک API افزونه‌ای پیشین که به برنامه‌های در حال اجرای خوشه‌های کوبرنتیز اجازه می‌داد به‌آسانی از ارائه‌های نرم‌افزاری مدیریت‌شده خارجی، مانند سرویس پایگاه داده ارائه‌شده توسط یک ارائه‌دهنده ابری، استفاده کنند. + +aka: +tags: +- extension +--- + یک API افزونه‌ای پیشین که به برنامه‌های در حال اجرای خوشه‌های کوبرنتیز اجازه می‌داد به‌آسانی از ارائه‌های نرم‌افزاری مدیریت‌شده خارجی، مانند سرویس پایگاه داده ارائه‌شده توسط یک ارائه‌دهنده ابری، استفاده کنند. + + + +راهکاری برای فهرست‌کردن، تأمین و پیوند با {{< glossary_tooltip text="Managed Services" term_id="managed-service" >}} خارجی فراهم می‌کرد، بی‌آنکه نیاز به دانش دقیق درباره نحوه ایجاد یا مدیریت آن خدمات باشد. diff --git a/content/fa/docs/reference/glossary/service.md b/content/fa/docs/reference/glossary/service.md new file mode 100644 index 0000000000000..44d01cd433cb2 --- /dev/null +++ b/content/fa/docs/reference/glossary/service.md @@ -0,0 +1,25 @@ +--- +title: سرویس +id: service +date: 2018-04-12 +full_link: /docs/concepts/services-networking/service/ +short_description: > + روشی برای در معرض قرار دادن یک برنامه در حال اجرا روی مجموعه‌ای از پادها به‌عنوان یک سرویس شبکه. +tags: +- fundamental +- core-object +--- + روشی برای در معرض قرار دادن یک برنامه شبکه‌ای که به‌صورت یک یا چند +{{< glossary_tooltip text="Pods" term_id="pod" >}} در خوشه شما اجرا می‌شود. + + + +مجموعه پادهایی که یک سرویس هدف قرار می‌دهد (معمولاً) با یک +{{< glossary_tooltip text="selector" term_id="selector" >}} تعیین می‌شود. اگر پادهای بیشتری اضافه یا حذف شوند، +مجموعه پادهای منطبق با این سلکتور تغییر خواهد کرد. سرویس تضمین می‌کند که ترافیک شبکه +بتواند به مجموعه فعلی پادهای این بار کاری هدایت شود. + +سرویس‌های کوبرنتیز یا از شبکه IP (IPv4، IPv6 یا هر دو) استفاده می‌کنند، یا یک نام خارجی را در +سامانه نام دامنه (DNS) ارجاع می‌دهند. + +انتزاع سرویس سازوکارهای دیگری مانند Ingress و Gateway را ممکن می‌سازد. diff --git a/content/fa/docs/reference/glossary/shuffle-sharding.md b/content/fa/docs/reference/glossary/shuffle-sharding.md new file mode 100644 index 0000000000000..edfbb09be7813 --- /dev/null +++ b/content/fa/docs/reference/glossary/shuffle-sharding.md @@ -0,0 +1,22 @@ +--- +title: Shuffle-sharding +id: shuffle-sharding +date: 2020-03-04 +full_link: +short_description: > + روشی برای تخصیص درخواست‌ها به صف‌ها که ایزوله‌سازی بهتری نسبت به «هش باقیمانده به تعداد صف‌ها» فراهم می‌کند. + +aka: +tags: +- fundamental +--- + روشی برای تخصیص درخواست‌ها به صف‌ها که ایزوله‌سازی بهتری نسبت به «هش باقیمانده به تعداد صف‌ها» فراهم می‌کند. + + + +اغلب دغدغه ما جداسازی جریان‌های مختلفِ درخواست از یکدیگر است تا یک جریان پُرشدت نتواند جریان‌های کم‌شدت را از میدان به در کند. +یک راه ساده برای قرار دادن درخواست‌ها در صف‌ها آن است که برخی ویژگی‌های درخواست را هش کرده و باقیمانده تقسیم بر تعداد صف‌ها را به‌عنوان شاخص صف به کار گیریم. تابع هش، ویژگی‌هایی از درخواست را دریافت می‌کند که با جریان‌های ترافیک همسو هستند؛ برای نمونه در اینترنت معمولاً ۵‌تاییِ نشانی مبدأ و مقصد، پروتکل، و پورت مبدأ و مقصد استفاده می‌شود. + +این طرح ساده مبتنی بر هش چنین خاصیتی دارد که هر جریان پُرشدت، تمام جریان‌های کم‌شدتِ هَش‌شده به همان صف را کنار می‌زند. برای ایزوله‌سازی مناسب تعداد زیادی جریان، به تعداد زیادی صف نیاز است که دردسرساز است. شافل‌شاردینگ تکنیکی چابک‌تر است که می‌تواند جریان‌های کم‌شدت را بهتر از جریان‌های پُرشدت جدا کند. در اصطلاح شافل‌شاردینگ از استعاره «تقسیم یک دست ورق از یک دسته کارت» بهره می‌برد؛ هر صف یک «کارت» استعاری است. این تکنیک با هش‌کردن ویژگی‌های شناسایی جریان آغاز می‌شود تا یک مقدار هش با ده‌ها بیت یا بیشتر تولید کند. سپس از این مقدار هش به‌عنوان منبع تصادفی برای «بر زدن» دسته و «دادن» یک دست کارت (صف) استفاده می‌شود. همه صف‌های داده‌شده بررسی می‌شوند و درخواست در یکی از صف‌های بررسی‌شده با کوتاه‌ترین طول قرار می‌گیرد. + +با اندازه دستِ نسبتاً کوچک، بررسی همه کارت‌های داده‌شده هزینه زیادی ندارد و یک جریان کم‌شدت شانس خوبی دارد که از تأثیر یک جریان پُرشدت بگریزد. با اندازه دست بزرگ، بررسی صف‌های داده‌شده هزینه‌بر است و برای جریان‌های کم‌شدت دشوارتر می‌شود که از اثر جمعیِ مجموعه‌ای از جریان‌های پُرشدت بگریزند. بنابراین، اندازه دست باید با دقت انتخاب شود. diff --git a/content/fa/docs/reference/glossary/sidecar-container.md b/content/fa/docs/reference/glossary/sidecar-container.md new file mode 100644 index 0000000000000..3fc9b0d4eca04 --- /dev/null +++ b/content/fa/docs/reference/glossary/sidecar-container.md @@ -0,0 +1,19 @@ +--- +title: کانتینر سایدکار +id: sidecar-container +date: 2018-04-12 +full_link: +short_description: > + یک کانتینر کمکی که در سراسر چرخه عمر یک پاد در حال اجرا باقی می‌ماند. +full_link: /docs/concepts/workloads/pods/sidecar-containers/ +tags: +- fundamental +--- + یک یا چند {{< glossary_tooltip text="containers" term_id="container" >}} که معمولاً پیش از شروع کانتینرهای برنامه اجرا می‌شوند. + + + +کانتینرهای سایدکار مشابه کانتینرهای معمولیِ برنامه هستند، اما هدف متفاوتی دارند: سایدکار یک سرویس محلی در سطح پاد را برای کانتینر اصلی برنامه فراهم می‌کند. +برخلاف {{< glossary_tooltip text="init containers" term_id="init-container" >}}، کانتینرهای سایدکار پس از راه‌اندازی پاد همچنان در حال اجرا می‌مانند. + +برای اطلاعات بیشتر، [کانتینرهای سایدکار](/docs/concepts/workloads/pods/sidecar-containers/) را بخوانید. diff --git a/content/fa/docs/reference/glossary/sig.md b/content/fa/docs/reference/glossary/sig.md new file mode 100644 index 0000000000000..f9dc3b4ce4851 --- /dev/null +++ b/content/fa/docs/reference/glossary/sig.md @@ -0,0 +1,20 @@ +--- +title: SIG (گروه علاقه‌مندی ویژه) +id: sig +date: 2018-04-12 +full_link: https://github.com/kubernetes/community/blob/master/sig-list.md#special-interest-groups +short_description: > + اعضای جامعه که به‌طور جمعی بخشی یا جنبه‌ای مستمر از پروژه متن‌باز بزرگ‌تر کوبرنتیز را مدیریت می‌کنند. + +aka: +tags: +- community +--- + {{< glossary_tooltip text="Community members" term_id="member" >}} که به‌طور جمعی بخشی یا جنبه‌ای مستمر از پروژه متن‌باز بزرگ‌تر کوبرنتیز را مدیریت می‌کنند. + + + +اعضا در یک SIG علاقه مشترکی به پیشبرد حوزه‌ای خاص دارند، مانند معماری، ماشین‌آلات API یا مستندسازی. +SIGها باید از [دستورالعمل‌های راهبری SIG](https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance.md) پیروی کنند، اما می‌توانند سیاست مشارکت و کانال‌های ارتباطی خود را داشته باشند. + +برای اطلاعات بیشتر، مخزن [kubernetes/community](https://github.com/kubernetes/community) و فهرست فعلی [SIGها و گروه‌های کاری](https://github.com/kubernetes/community/blob/master/sig-list.md) را ببینید. diff --git a/content/fa/docs/reference/glossary/spec.md b/content/fa/docs/reference/glossary/spec.md new file mode 100644 index 0000000000000..4c0cc0d4c0210 --- /dev/null +++ b/content/fa/docs/reference/glossary/spec.md @@ -0,0 +1,22 @@ +--- +title: مشخصات +id: spec +date: 2023-12-17 +full_link: /docs/concepts/overview/working-with-objects/#object-spec-and-status +short_description: > + این فیلد در مانیفست‌های کوبرنتیز حالت یا پیکربندی مطلوب برای اشیای خاص کوبرنتیز را تعریف می‌کند. + +aka: +tags: +- fundamental +- architecture +--- + تعیین می‌کند هر شیء—مانند Pod یا Service—چگونه باید پیکربندی شود و چه وضعیت مطلوبی داشته باشد. + + + +تقریباً هر شیء کوبرنتیز دو فیلد تو در تو دارد که پیکربندی آن را کنترل می‌کنند: **spec** و **status** شیء. +برای اشیائی که فیلد spec دارند، هنگام ایجاد شیء باید آن را تنظیم کنید و ویژگی‌هایی را که می‌خواهید منبع داشته باشد—یعنی وضعیت مطلوبش—توصیف کنید. + +محتوای spec بسته به نوع شیء (Pod، StatefulSet، Service و …) متفاوت است و می‌تواند مواردی مانند کانتینرها، وُلِیوم‌ها، رپلیکاها، پورت‌ها +و سایر تنظیمات ویژه هر نوع شیء را شامل شود. این فیلد مشخص می‌کند که کوبرنتیز باید چه وضعیتی را برای شیء تعریف‌شده حفظ کند. diff --git a/content/fa/docs/reference/glossary/statefulset.md b/content/fa/docs/reference/glossary/statefulset.md new file mode 100644 index 0000000000000..562622dfb8dff --- /dev/null +++ b/content/fa/docs/reference/glossary/statefulset.md @@ -0,0 +1,24 @@ +--- +title: StatefulSet +id: statefulset +date: 2018-04-12 +full_link: /docs/concepts/workloads/controllers/statefulset/ +short_description: > + یک StatefulSet استقرار و مقیاس‌گذاری مجموعه‌ای از پادها را با ذخیره‌سازی پایدار و شناسه‌های ماندگار برای هر پاد مدیریت می‌کند. + +aka: +tags: +- fundamental +- core-object +- workload +- storage +--- + استقرار و مقیاس‌گذاری مجموعه‌ای از {{< glossary_tooltip text="Pods" term_id="pod" >}} را مدیریت می‌کند *و ضمانت‌هایی درباره ترتیب و یکتایی* این پادها ارائه می‌دهد. + + + +مانند یک {{< glossary_tooltip term_id="deployment" >}}، یک StatefulSet پادهایی را که بر اساس مشخصات کانتینر یکسان هستند مدیریت می‌کند. +اما برخلاف Deployment، StatefulSet برای هر یک از پادهای خود یک هویت چسبنده حفظ می‌کند. این پادها از یک مشخصات واحد ایجاد می‌شوند ولی قابل تعویض نیستند؛ هر پاد یک شناسه پایدار دارد که در طول هر زمان‌بندی مجدد حفظ می‌شود. + +اگر می‌خواهید برای بار کاری خود از وُلِیوم‌های ذخیره‌سازی برای فراهم‌کردن پایداری داده استفاده کنید، می‌توانید StatefulSet را به‌عنوان بخشی از راه‌حل به کار بگیرید. +گرچه پادهای منفرد در یک StatefulSet ممکن است دچار خطا شوند، اما شناسه‌های پایدار پادها تطبیق وُلِیوم‌های موجود با پادهای جدیدی را که جایگزین پادهای ازکارافتاده می‌شوند آسان‌تر می‌کند. diff --git a/content/fa/docs/reference/glossary/static-pod.md b/content/fa/docs/reference/glossary/static-pod.md new file mode 100644 index 0000000000000..ed801b51b2370 --- /dev/null +++ b/content/fa/docs/reference/glossary/static-pod.md @@ -0,0 +1,21 @@ +--- +title: پاد ایستا +id: static-pod +date: 2019-02-12 +full_link: /docs/tasks/configure-pod-container/static-pod/ +short_description: > + یک پاد که مستقیماً توسط دیمون kubelet روی یک گره مشخص مدیریت می‌شود. + +aka: +tags: +- fundamental +--- + +یک {{< glossary_tooltip text="pod" term_id="pod" >}} که مستقیماً توسط دیمون {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} +روی یک گره مشخص مدیریت می‌شود. + + + +بدون اینکه سرور API آن را مشاهده کند. + +پادهای ایستا از {{< glossary_tooltip text="ephemeral containers" term_id="ephemeral-container" >}} پشتیبانی نمی‌کنند. diff --git a/content/fa/docs/reference/glossary/storage-class.md b/content/fa/docs/reference/glossary/storage-class.md new file mode 100644 index 0000000000000..34b0f6d83505b --- /dev/null +++ b/content/fa/docs/reference/glossary/storage-class.md @@ -0,0 +1,20 @@ +--- +title: Storage Class +id: storageclass +date: 2018-04-12 +full_link: /docs/concepts/storage/storage-classes +short_description: > + یک StorageClass روشی برای توصیف انواع مختلف ذخیره‌سازی موجود توسط مدیران فراهم می‌کند. + +aka: +tags: +- core-object +- storage +--- + یک StorageClass روشی برای توصیف انواع مختلف ذخیره‌سازی موجود توسط مدیران فراهم می‌کند. + + + +StorageClassها می‌توانند به سطوح کیفیت سرویس، سیاست‌های پشتیبان‌گیری یا سیاست‌های دلخواه تعیین‌شده توسط مدیران خوشه نگاشت شوند. +هر StorageClass شامل فیلدهای `provisioner`، `parameters` و `reclaimPolicy` است که هنگام نیاز به تأمین پویای یک {{< glossary_tooltip text="Persistent Volume" term_id="persistent-volume" >}} متعلق به آن کلاس به‌کار می‌روند. +کاربران می‌توانند با استفاده از نام یک شیء StorageClass، کلاس موردنظر خود را درخواست کنند. diff --git a/content/fa/docs/reference/glossary/sysctl.md b/content/fa/docs/reference/glossary/sysctl.md new file mode 100644 index 0000000000000..0d09298c0d498 --- /dev/null +++ b/content/fa/docs/reference/glossary/sysctl.md @@ -0,0 +1,19 @@ +--- +title: sysctl +id: sysctl +date: 2019-02-12 +full_link: /docs/tasks/administer-cluster/sysctl-cluster/ +short_description: > + رابطی برای خواندن و تنظیم پارامترهای هسته یونیکس + +aka: +tags: +- tool +--- + `sysctl` یک رابط نیمه‌استاندارد برای خواندن یا تغییر ویژگی‌های هسته در حال اجرای یونیکس است. + + + +در سیستم‌های شبه‌یونیکس، `sysctl` هم نام ابزاری است که مدیران برای مشاهده و تغییر این تنظیمات استفاده می‌کنند و هم فراخوانی سیستمی که این ابزار از آن بهره می‌برد. + +زمان‌اجرای {{< glossary_tooltip text="Container" term_id="container" >}} و افزونه‌های شبکه ممکن است برای کارکرد صحیح به تنظیم مقادیر `sysctl` به‌شکلی مشخص وابسته باشند. diff --git a/content/fa/docs/reference/glossary/taint.md b/content/fa/docs/reference/glossary/taint.md new file mode 100644 index 0000000000000..769cbc56fa730 --- /dev/null +++ b/content/fa/docs/reference/glossary/taint.md @@ -0,0 +1,17 @@ +--- +title: Taint +id: taint +date: 2019-01-11 +full_link: /docs/concepts/scheduling-eviction/taint-and-toleration/ +short_description: > + یک شیء هسته‌ای که شامل سه ویژگی اجباری است: کلید، مقدار و اثر. Taintها از زمان‌بندی پادها روی نودها یا گروه‌های نود جلوگیری می‌کنند. + +aka: +tags: +- fundamental +--- + یک شیء هسته‌ای که شامل سه ویژگی اجباری است: کلید، مقدار و اثر. Taintها از زمان‌بندی {{< glossary_tooltip text="Pods" term_id="pod" >}} روی {{< glossary_tooltip text="nodes" term_id="node" >}} یا گروه‌های نود جلوگیری می‌کنند. + + + +Taintها و {{< glossary_tooltip text="tolerations" term_id="toleration" >}} با هم کار می‌کنند تا اطمینان حاصل شود پادها روی نودهای نامناسب زمان‌بندی نمی‌شوند. یک یا چند Taint به یک نود اعمال می‌شود. یک نود باید تنها پادهایی را زمان‌بندی کند که Tolerationهای متناسب با Taintهای پیکربندی‌شده را داشته باشند. diff --git a/content/fa/docs/reference/glossary/toleration.md b/content/fa/docs/reference/glossary/toleration.md new file mode 100644 index 0000000000000..67656ff89e68f --- /dev/null +++ b/content/fa/docs/reference/glossary/toleration.md @@ -0,0 +1,18 @@ +--- +title: Toleration +id: toleration +date: 2019-01-11 +full_link: /docs/concepts/scheduling-eviction/taint-and-toleration/ +short_description: > + یک شیء هسته‌ای که شامل سه ویژگی اجباری است: کلید، مقدار و اثر. Tolerationها امکان زمان‌بندی پادها روی نودها یا گروه‌های نود با Taintهای منطبق را فراهم می‌کنند. + +aka: +tags: +- core-object +- fundamental +--- + یک شیء هسته‌ای که شامل سه ویژگی اجباری است: کلید، مقدار و اثر. Tolerationها امکان زمان‌بندی پادها روی نودها یا گروه‌های نود با {{< glossary_tooltip text="taints" term_id="taint" >}} منطبق را فراهم می‌کنند. + + + +Tolerationها و {{< glossary_tooltip text="taints" term_id="taint" >}} با هم کار می‌کنند تا اطمینان حاصل شود پادها روی نودهای نامناسب زمان‌بندی نمی‌شوند. یک یا چند Toleration به یک {{< glossary_tooltip text="pod" term_id="pod" >}} اعمال می‌شود. یک Toleration نشان می‌دهد که آن {{< glossary_tooltip text="pod" term_id="pod" >}} مجاز است (اما مجبور نیست) روی نودها یا گروه‌های نود با {{< glossary_tooltip text="taints" term_id="taint" >}} منطبق زمان‌بندی شود. diff --git a/content/fa/docs/reference/glossary/uid.md b/content/fa/docs/reference/glossary/uid.md new file mode 100644 index 0000000000000..9696b2439ab0b --- /dev/null +++ b/content/fa/docs/reference/glossary/uid.md @@ -0,0 +1,17 @@ +--- +title: UID +id: uid +date: 2018-04-12 +full_link: /docs/concepts/overview/working-with-objects/names +short_description: > + رشته‌ای که توسط سیستم کوبرنتیز تولید می‌شود تا اشیاء را به‌طور منحصر‌به‌فرد شناسایی کند. + +aka: +tags: +- fundamental +--- + رشته‌ای که توسط سیستم کوبرنتیز تولید می‌شود تا اشیاء را به‌طور منحصر‌به‌فرد شناسایی کند. + + + +هر شیئی که در طول عمر یک خوشه کوبرنتیز ایجاد شود، یک UID متمایز دارد. این UID برای تفکیک رخدادهای تاریخیِ موجودیت‌های مشابه در نظر گرفته شده است. diff --git a/content/fa/docs/reference/glossary/upstream.md b/content/fa/docs/reference/glossary/upstream.md new file mode 100644 index 0000000000000..1ad08c2d84130 --- /dev/null +++ b/content/fa/docs/reference/glossary/upstream.md @@ -0,0 +1,18 @@ +--- +title: Upstream (ابهام‌زدایی) +id: upstream +date: 2018-04-12 +full_link: +short_description: > + ممکن است به موارد زیر اشاره کند: هسته کوبرنتیز یا مخزن مبنایی که یک مخزن از آن منشعب شده است. + +aka: +tags: +- community +--- + ممکن است به موارد زیر اشاره کند: هسته کوبرنتیز یا مخزن مبنایی که یک مخزن از آن منشعب شده است. + + + +* در **جامعه کوبرنتیز**: در مکالمات غالباً از «upstream» برای اشاره به کد پایه کوبرنتیز استفاده می‌شود، که بن‌سازه عمومی، کدهای دیگر یا ابزارهای ثالث بر آن تکیه دارند. برای مثال، [اعضای جامعه](#term-member) ممکن است پیشنهاد کنند که یک قابلیت «به upstream منتقل شود» تا به جای افزونه یا ابزار ثالث، در کد پایه هسته قرار گیرد. +* در **GitHub** یا **git**: رویه این است که مخزن اصلی را «upstream» بنامند، در حالی که مخزن منشعب‌شده «downstream» محسوب می‌شود. diff --git a/content/fa/docs/reference/glossary/userns.md b/content/fa/docs/reference/glossary/userns.md new file mode 100644 index 0000000000000..6fbd4edb11dfc --- /dev/null +++ b/content/fa/docs/reference/glossary/userns.md @@ -0,0 +1,23 @@ +--- +title: فضای نام کاربری +id: userns +date: 2021-07-13 +full_link: https://man7.org/linux/man-pages/man7/user_namespaces.7.html +short_description: > + ویژگی هسته لینوکس برای شبیه‌سازی امتیازات کاربر ریشه برای کاربران بدون امتیاز. + +aka: +tags: +- security +--- + +ویژگی هسته که امکان شبیه‌سازی دسترسی ریشه را فراهم می‌کند. برای «کانتینرهای بدون ریشه» استفاده می‌شود. + + + +فضاهای نام کاربری (User namespaces) ویژگی‌ای از هسته لینوکس هستند که به یک کاربر غیرریشه اجازه می‌دهند امتیازات کاربر ریشه (superuser) را شبیه‌سازی کند، +برای مثال برای اجرای کانتینرها بدون نیاز به دسترسی ریشه خارج از کانتینر. + +فضای نام کاربری در کاهش آسیب‌های ناشی از حملات احتمالی فرار از کانتینر مؤثر است. + +در زمینه فضاهای نام کاربری، منظور از فضای نام یک ویژگی هسته لینوکس است و به فضای نام در معنای کوبرنتیز اشاره نمی‌کند. diff --git a/content/fa/docs/reference/glossary/volume-plugin.md b/content/fa/docs/reference/glossary/volume-plugin.md new file mode 100644 index 0000000000000..a58ceea0623e0 --- /dev/null +++ b/content/fa/docs/reference/glossary/volume-plugin.md @@ -0,0 +1,17 @@ +--- +title: افزونه حجم +id: volumeplugin +date: 2018-04-12 +full_link: +short_description: > + یک Volume Plugin امکان یکپارچه‌سازی فضای ذخیره‌سازی را درون یک {{< glossary_tooltip text="Pod" term_id="pod" >}} فراهم می‌کند. + +aka: +tags: +- storage +--- + یک Volume Plugin امکان یکپارچه‌سازی فضای ذخیره‌سازی را درون یک {{< glossary_tooltip text="Pod" term_id="pod" >}} فراهم می‌کند. + + + +یک Volume Plugin به شما اجازه می‌دهد تا وُلِیوم‌های ذخیره‌سازی را متصل و مونت کنید تا یک {{< glossary_tooltip text="Pod" term_id="pod" >}} بتواند از آن‌ها استفاده کند. افزونه‌های حجم می‌توانند _in tree_ یا _out of tree_ باشند. افزونه‌های _in tree_ بخشی از مخزن کد کوبرنتیز هستند و از چرخه انتشار آن پیروی می‌کنند. افزونه‌های _out of tree_ به‌طور مستقل توسعه داده می‌شوند. diff --git a/content/fa/docs/reference/glossary/volume.md b/content/fa/docs/reference/glossary/volume.md new file mode 100644 index 0000000000000..3a832aedc35e1 --- /dev/null +++ b/content/fa/docs/reference/glossary/volume.md @@ -0,0 +1,20 @@ +--- +title: حجم +id: volume +date: 2018-04-12 +full_link: /docs/concepts/storage/volumes/ +short_description: > + پوشه‌ای حاوی داده که برای کانتینرهای درون یک {{< glossary_tooltip term_id="pod" >}} قابل دسترسی است. + +aka: +tags: +- fundamental +--- + پوشه‌ای حاوی داده که برای {{< glossary_tooltip text="containers" term_id="container" >}} در یک {{< glossary_tooltip term_id="pod" >}} قابل دسترسی است. + + + +یک حجم کوبرنتیز به اندازه عمر پادِ احاطه‌کننده خود زنده می‌ماند. +بنابراین حجم بیش از طول عمر هر کانتینری که درون پاد اجرا می‌شود باقی می‌ماند و داده‌های موجود در حجم حتی پس از راه‌اندازی مجدد کانتینرها حفظ می‌شوند. + +برای اطلاعات بیشتر، به [مفاهیم ذخیره‌سازی](/docs/concepts/storage/) مراجعه کنید. diff --git a/content/fa/docs/reference/glossary/watch.md b/content/fa/docs/reference/glossary/watch.md new file mode 100644 index 0000000000000..f42f46a47fb87 --- /dev/null +++ b/content/fa/docs/reference/glossary/watch.md @@ -0,0 +1,19 @@ +--- +title: پایش +id: watch +date: 2024-07-02 +full_link: /docs/reference/using-api/api-concepts/#api-verbs +short_description: > + فعلی که برای پیگیری تغییرات یک شیء در کوبرنتیز به‌صورت جریان به‌کار می‌رود. +aka: +tags: +- API verb +- fundamental +--- +فعلی که برای پیگیری تغییرات یک شیء در کوبرنتیز به‌صورت جریان به‌کار می‌رود و برای تشخیص بهینه تغییرات استفاده می‌شود. + + + +فعلی که برای پیگیری تغییرات یک شیء در کوبرنتیز به‌صورت جریان به‌کار می‌رود. پایش‌ها امکان تشخیص بهینه تغییرات را فراهم می‌کنند؛ برای مثال، یک {{< glossary_tooltip term_id="controller" text="controller">}} که نیاز دارد هر زمان یک ConfigMap تغییر کرد مطلع شود، می‌تواند به‌جای پیمایش مداوم از پایش استفاده کند. + +برای اطلاعات بیشتر به [تشخیص بهینه تغییرات در مفاهیم API](/docs/reference/using-api/api-concepts/#efficient-detection-of-changes) مراجعه کنید. diff --git a/content/fa/docs/reference/glossary/wg.md b/content/fa/docs/reference/glossary/wg.md new file mode 100644 index 0000000000000..eecbaacf78848 --- /dev/null +++ b/content/fa/docs/reference/glossary/wg.md @@ -0,0 +1,19 @@ +--- +title: WG (گروه کاری) +id: wg +date: 2018-04-12 +full_link: https://github.com/kubernetes/community/blob/master/sig-list.md#master-working-group-list +short_description: > + تسهیل بحث و/یا پیاده‌سازی پروژه‌ای کوتاه‌مدت، باریک‌محدوده یا جداشده برای یک کمیته، {{< glossary_tooltip text="SIG" term_id="sig" >}} یا تلاش میان‌SIG. + +aka: +tags: +- community +--- + تسهیل بحث و/یا پیاده‌سازی پروژه‌ای کوتاه‌مدت، باریک‌محدوده یا جداشده برای یک کمیته، {{< glossary_tooltip text="SIG" term_id="sig" >}} یا تلاش میان‌SIG. + + + +گروه‌های کاری روشی برای سازمان‌دهی افراد جهت انجام یک کار مشخص هستند. + +برای اطلاعات بیشتر، مخزن [kubernetes/community](https://github.com/kubernetes/community) و فهرست فعلی [SIGها و گروه‌های کاری](https://github.com/kubernetes/community/blob/master/sig-list.md) را ببینید. diff --git a/content/fa/docs/reference/glossary/workload.md b/content/fa/docs/reference/glossary/workload.md new file mode 100644 index 0000000000000..e9b533820246a --- /dev/null +++ b/content/fa/docs/reference/glossary/workload.md @@ -0,0 +1,19 @@ +--- +title: Workload +id: workload +date: 2019-02-13 +full_link: /docs/concepts/workloads/ +short_description: > + Workload به یک برنامه در حال اجرا روی کوبرنتیز اشاره دارد. + +aka: +tags: +- fundamental +--- + Workload به یک برنامه در حال اجرا روی کوبرنتیز اشاره دارد. + + + +اشیاء اصلی مختلفی که انواع یا بخش‌های متفاوتی از یک Workload را نمایندگی می‌کنند شامل DaemonSet، Deployment، Job، ReplicaSet و StatefulSet هستند. + +برای مثال، یک Workload که شامل یک سرور وب و یک پایگاه داده است ممکن است پایگاه داده را در یک {{< glossary_tooltip term_id="StatefulSet" >}} و سرور وب را در یک {{< glossary_tooltip term_id="Deployment" >}} اجرا کند. diff --git a/content/fa/docs/setup/_index.md b/content/fa/docs/setup/_index.md new file mode 100644 index 0000000000000..dd2992d3779d7 --- /dev/null +++ b/content/fa/docs/setup/_index.md @@ -0,0 +1,59 @@ +--- +reviewers: +- xirehat +title: شروع کنید +main_menu: true +weight: 20 +content_type: concept +no_list: true +card: + name: setup + weight: 20 + anchors: + - anchor: "#learning-environment" + title: محیط یادگیری + - anchor: "#production-environment" + title: محیط عملیاتی +--- + + + +این بخش روش‌های مختلف راه‌اندازی و اجرای کوبرنتیز را فهرست می‌کند. +هنگام نصب کوبرنتیز، نوع نصب را بر اساس موارد زیر انتخاب کنید: سهولت نگهداری، امنیت، کنترل، منابع موجود و تخصص مورد نیاز برای راه‌اندازی و مدیریت یک خوشه. + +می‌توانید با [دانلود کوبرنتیز](/releases/download/) یک خوشه کوبرنتیز را روی ماشین محلی، در فضای ابری یا در مرکز داده خودتان مستقر کنید. + +چندین [مؤلفه کوبرنتیز](/docs/concepts/overview/components/) مانند {{< glossary_tooltip text="kube-apiserver" term_id="kube-apiserver" >}} یا {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}} نیز می‌توانند به‌صورت [ایمیج کانتینر](/releases/download/#container-images) در داخل خوشه مستقر شوند. + +**توصیه می‌شود** هرجا امکان‌پذیر است، مؤلفه‌های کوبرنتیز را به‌شکل ایمیج‌های کانتینری اجرا کرده و مدیریت آن‌ها را به خود کوبرنتیز بسپارید. +مؤلفه‌هایی که کانتینرها را اجرا می‌کنند—به‌ویژه kubelet—در این دسته قرار نمی‌گیرند. + +اگر نمی‌خواهید خودتان یک خوشه کوبرنتیز را مدیریت کنید، می‌توانید یک سرویس مدیریت‌شده، از جمله [بُن‌سازه‌های تأییدشده](/docs/setup/production-environment/turnkey-solutions/) را انتخاب کنید. +همچنین راهکارهای استاندارد و سفارشی دیگری در طیف گسترده‌ای از محیط‌های ابری و سرورهای فیزیکی (bare metal) وجود دارد. + + + +## محیط یادگیری + +اگر در حال یادگیری کوبرنتیز هستید، از ابزارهای پشتیبانی شده توسط جامعه کوبرنتیز یا ابزارهای موجود در بوم‌سازگان برای راه‌اندازی یک خوشه کوبرنتیز روی یک دستگاه محلی استفاده کنید. به [نصب ابزارها](/docs/tasks/tools/) مراجعه کنید. + +## محیط عملیاتی + +هنگام ارزیابی یک راهکار برای یک +[محیط عملیاتی](/docs/setup/production-environment/)، در نظر بگیرید کدام جنبه‌های +عملیاتی یک خوشه کوبرنتیز را می‌خواهید خودتان مدیریت کنید و +کدام‌ها را ترجیح می‌دهید به یک ارائه‌دهنده بسپارید. + +برای خوشه‌ای که خودتان مدیریت می‌کنید، ابزار رسمیِ پشتیبانی‌شده برای استقرار +کوبرنتیز، [kubeadm](/docs/setup/production-environment/tools/kubeadm/) است. + +## {{% heading "whatsnext" %}} + +- [دانلود کوبرنتیز](/releases/download/) +- ابزارها را بارگیری کرده و [نصب کنید](/docs/tasks/tools/) از جمله `kubectl` +- برای خوشه جدید خود یک [برنامه زمان اجرای کانتینر](/docs/setup/production-environment/container-runtimes/) انتخاب کنید +- درباره [بهترین شیوه‌ها](/docs/setup/best-practices/) برای راه‌اندازی خوشه بیاموزید + +کوبرنتیز طوری طراحی شده است که {{< glossary_tooltip term_id="control-plane" text="Control Plane" >}} آن روی لینوکس اجرا شود. درون خوشه خود می‌توانید برنامه‌ها را روی لینوکس یا سامانه‌های عامل دیگر، از جمله ویندوز، اجرا کنید. + +- نحوه [راه‌اندازی خوشه با گره‌های(Node) ویندوز](/docs/concepts/windows/) را بیاموزید diff --git a/content/fa/docs/setup/best-practices/_index.md b/content/fa/docs/setup/best-practices/_index.md new file mode 100644 index 0000000000000..52de72c56f548 --- /dev/null +++ b/content/fa/docs/setup/best-practices/_index.md @@ -0,0 +1,4 @@ +--- +title: بهترین شیوه‌ها +weight: 40 +--- diff --git a/content/fa/docs/setup/best-practices/certificates.md b/content/fa/docs/setup/best-practices/certificates.md new file mode 100644 index 0000000000000..c9e0cf5092a1e --- /dev/null +++ b/content/fa/docs/setup/best-practices/certificates.md @@ -0,0 +1,243 @@ +--- +title: گواهینامه‌ها و الزامات PKI +content_type: concept +weight: 50 +--- + + + +کوبرنتیز برای احراز هویت از طریق TLS به گواهینامه‌های PKI نیاز دارد. +اگر کوبرنتیز را با [kubeadm](/docs/reference/setup-tools/kubeadm/) نصب کنید، گواهینامه‌هایی که خوشه شما نیاز دارد به طور خودکار تولید می‌شوند. +همچنین می‌توانید گواهینامه‌های خودتان را تولید کنید -- به عنوان مثال، برای ایمن‌تر نگه داشتن کلیدهای خصوصی خود +با ذخیره نکردن آنها در سرور API. +این صفحه گواهینامه‌هایی را که خوشه شما نیاز دارد توضیح می‌دهد. + + + +## نحوه استفاده از گواهی‌ها توسط خوشه شما + +کوبرنتیز برای عملیات‌های زیر به PKI نیاز دارد: + +### گواهینامه‌های سرور + +* گواهینامه سرور برای نقطه پایانی (endpoint) سرور API +* گواهینامه سرور برای سرور etcd +* [گواهینامه‌های سرور](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/#client-and-serving-certificates) + برای هر kubelet (هر {{< glossary_tooltip text="گره" term_id="node" >}} یک kubelet اجرا می‌کند) +* گواهینامه سرور اختیاری برای [front-proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) + +### گواهینامه‌های Client + +* گواهی‌های کلاینت برای هر kubelet، برای احراز هویت به سرور API به عنوان یک کلاینت از API کوبرنتیز +* گواهی کلاینت برای هر سرور API، برای احراز هویت به etcd +* گواهی کلاینت برای مدیر کنترل (controller manager) برای ارتباط امن با سرور API +* گواهی کلاینت برای زمان‌بند (scheduler) برای ارتباط امن با سرور API +* گواهی‌های کلاینت، یکی برای هر گره، برای kube-proxy جهت احراز هویت به سرور API +* گواهی‌های کلاینت اختیاری برای مدیران خوشه جهت احراز هویت به سرور API +* گواهی کلاینت اختیاری برای [front-proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) + +### گواهینامه‌های سرور و کلاینت Kubelet + +برای ایجاد یک اتصال امن و احراز هویت خود به kubelet، سرور API +به یک گواهی کلاینت و جفت کلید نیاز دارد. + +در این سناریو، دو رویکرد برای استفاده از گواهی وجود دارد: + +* گواهی‌های مشترک: kube-apiserver می‌تواند از همان گواهی و جفت کلید مورد استفاده خود برای احراز هویت کلاینت‌های خود استفاده کند. این بدان معناست که گواهی‌های موجود، مانند `apiserver.crt` و `apiserver.key`، می‌توانند برای ارتباط با سرورهای kubelet استفاده شوند. + +* گواهی‌های جداگانه: به عنوان یک جایگزین، kube-apiserver می‌تواند یک گواهی کلاینت و جفت کلید جدید برای احراز هویت ارتباط خود با سرورهای kubelet ایجاد کند. در این حالت، یک گواهی مجزا به نام `kubelet-client.crt` و کلید خصوصی مربوطه آن، `kubelet-client.key` ایجاد می‌شوند. + +{{< note >}} +گواهی‌های `front-proxy` فقط در صورتی لازم هستند که kube-proxy را برای پشتیبانی از [افزونه سرور API](/docs/tasks/extend-kubernetes/setup-extension-api-server/) اجرا کنید. +{{< /note >}} + +etcd همچنین TLS متقابل را برای احراز هویت کلاینت‌ها و نظیرها پیاده‌سازی می‌کند. + +## محل نگهداری گواهینامه‌ها + +اگر کوبرنتیز را با kubeadm نصب کنید، بیشتر گواهینامه‌ها در `/etc/kubernetes/pki` ذخیره می‌شوند. +تمام مسیرهای موجود در این مستندات به آن پوشه مربوط می‌شوند، به استثنای گواهینامه‌های حساب کاربری که kubeadm آنها را در `/etc/kubernetes` قرار می‌دهد. + +## پیکربندی دستی گواهینامه‌ها + +اگر نمی‌خواهید kubeadm گواهی‌های مورد نیاز را تولید کند، می‌توانید آنها را با استفاده از یک CA ریشه واحد یا با ارائه همه گواهی‌ها ایجاد کنید. برای جزئیات بیشتر در مورد ایجاد مرجع صدور گواهی خود، به [گواهینماه‌ها](/docs/tasks/administer-cluster/certificates/) مراجعه کنید. برای اطلاعات بیشتر در مورد مدیریت گواهی‌ها، به [مدیریت گواهینامه با kubeadm](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/) مراجعه کنید. + +### CA تک ریشه + +شما می‌توانید یک root CA واحد ایجاد کنید که توسط یک مدیر کنترل می‌شود. این root CA می‌تواند چندین CA میانی ایجاد کند و تمام مراحل ایجاد بیشتر را به خود کوبرنتیز واگذار کند. + +CA های مورد نیاز: + +| Path | Default CN | Description | +|------------------------|---------------------------|----------------------------------| +| ca.crt,key | kubernetes-ca | Kubernetes general CA | +| etcd/ca.crt,key | etcd-ca | For all etcd-related functions | +| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | For the [front-end proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) | + +علاوه بر CA های فوق، دریافت یک جفت کلید عمومی/خصوصی برای مدیریت حساب سرویس، `sa.key` و `sa.pub` نیز ضروری است. + +مثال زیر کلید CA و فایل‌های گواهی نشان داده شده در جدول قبلی را نشان می‌دهد: + +``` +/etc/kubernetes/pki/ca.crt +/etc/kubernetes/pki/ca.key +/etc/kubernetes/pki/etcd/ca.crt +/etc/kubernetes/pki/etcd/ca.key +/etc/kubernetes/pki/front-proxy-ca.crt +/etc/kubernetes/pki/front-proxy-ca.key +``` + +### همه گواهینامه‌ها + +اگر نمی‌خواهید کلیدهای خصوصی CA را در خوشه خود کپی کنید، می‌توانید خودتان تمام گواهینامه‌ها را تولید کنید. + +گواهینامه‌های مورد نیاز: + +| Default CN | Parent CA | O (in Subject) | kind | hosts (SAN) | +|-------------------------------|---------------------------|----------------|------------------|-----------------------------------------------------| +| kube-etcd | etcd-ca | | server, client | ``, ``, `localhost`, `127.0.0.1` | +| kube-etcd-peer | etcd-ca | | server, client | ``, ``, `localhost`, `127.0.0.1` | +| kube-etcd-healthcheck-client | etcd-ca | | client | | +| kube-apiserver-etcd-client | etcd-ca | | client | | +| kube-apiserver | kubernetes-ca | | server | ``, ``, ``[^1] | +| kube-apiserver-kubelet-client | kubernetes-ca | system:masters | client | | +| front-proxy-client | kubernetes-front-proxy-ca | | client | | + +{{< note >}} +به جای استفاده از گروه کاربر ارشد `system:masters` برای `kube-apiserver-kubelet-client`، می‌توان از یک گروه با امتیاز کمتر استفاده کرد. kubeadm برای این منظور از گروه `kubeadm:cluster-admins` استفاده می‌کند. +{{< /note >}} + +که در آن `kind` به یک یا چند مورد از کاربردهای کلید x509 نگاشت می‌شود، که در `.spec.usages` از یک [CertificateSigningRequest](/docs/reference/kubernetes-api/authentication-resources/certificate-signing-request-v1#CertificateSigningRequest) نیز مستند شده است: + +| kind | Key usage | +|--------|---------------------------------------------------------------------------------| +| server | digital signature, key encipherment, server auth | +| client | digital signature, key encipherment, client auth | + +{{< note >}} +هاست‌ها/SANهای ذکر شده در بالا، موارد توصیه شده برای ایجاد یک خوشه فعال هستند؛ در صورت نیاز به تنظیمات خاص، می‌توان SANهای اضافی را روی تمام گواهینامه‌های سرور اضافه کرد. +{{< /note >}} + +{{< note >}} + +فقط برای کاربران kubeadm: + +* سناریویی که در آن شما گواهی‌های CA خوشه خود را بدون کلیدهای خصوصی رونوشت می‌گیرید، در مستندات kubeadm به عنوان CA خارجی شناخته می‌شود. + +* اگر فهرست بالا را با PKI تولید شده توسط kubeadm مقایسه می‌کنید، لطفاً توجه داشته باشید که گواهی‌های `kube-etcd`، `kube-etcd-peer` و `kube-etcd-healthcheck-client` در صورت etcd خارجی تولید نمی‌شوند. + +{{< /note >}} + +### مسیرهای گواهینامه + +گواهی‌ها باید در یک مسیر پیشنهادی قرار گیرند (مطابق با مسیری که [kubeadm](/docs/reference/setup-tools/kubeadm/) استفاده می‌کند). مسیرها باید با استفاده از آرگومان داده شده، صرف نظر از مکان، مشخص شوند. + +| DefaultCN | recommendedkeypath | recommendedcertpath | command | keyargument | certargument | +| --------- | ------------------ | ------------------- | ------- | ----------- | ------------ | +| etcd-ca | etcd/ca.key | etcd/ca.crt | kube-apiserver | | --etcd-cafile | +| kube-apiserver-etcd-client | apiserver-etcd-client.key | apiserver-etcd-client.crt | kube-apiserver | --etcd-keyfile | --etcd-certfile | +| kubernetes-ca | ca.key | ca.crt | kube-apiserver | | --client-ca-file | +| kubernetes-ca | ca.key | ca.crt | kube-controller-manager | --cluster-signing-key-file | --client-ca-file,--root-ca-file,--cluster-signing-cert-file | +| kube-apiserver | apiserver.key | apiserver.crt| kube-apiserver | --tls-private-key-file | --tls-cert-file | +| kube-apiserver-kubelet-client | apiserver-kubelet-client.key | apiserver-kubelet-client.crt | kube-apiserver | --kubelet-client-key | --kubelet-client-certificate | +| front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-apiserver | | --requestheader-client-ca-file | +| front-proxy-ca | front-proxy-ca.key | front-proxy-ca.crt | kube-controller-manager | | --requestheader-client-ca-file | +| front-proxy-client | front-proxy-client.key | front-proxy-client.crt | kube-apiserver | --proxy-client-key-file | --proxy-client-cert-file | +| etcd-ca | etcd/ca.key | etcd/ca.crt | etcd | | --trusted-ca-file,--peer-trusted-ca-file | +| kube-etcd | etcd/server.key | etcd/server.crt | etcd | --key-file | --cert-file | +| kube-etcd-peer | etcd/peer.key | etcd/peer.crt | etcd | --peer-key-file | --peer-cert-file | +| etcd-ca| | etcd/ca.crt | etcdctl | | --cacert | +| kube-etcd-healthcheck-client | etcd/healthcheck-client.key | etcd/healthcheck-client.crt | etcdctl | --key | --cert | + +ملاحظات مشابهی برای جفت کلید service account اعمال می‌شود: + +| private key path | public key path | command | argument | +|-------------------|------------------|-------------------------|--------------------------------------| +| sa.key | | kube-controller-manager | --service-account-private-key-file | +| | sa.pub | kube-apiserver | --service-account-key-file | + +مثال زیر مسیرهای فایل [از جداول قبلی](#certificate-paths) را نشان می‌دهد که در صورت تولید تمام کلیدها و گواهی‌های خودتان، باید ارائه دهید: + +``` +/etc/kubernetes/pki/etcd/ca.key +/etc/kubernetes/pki/etcd/ca.crt +/etc/kubernetes/pki/apiserver-etcd-client.key +/etc/kubernetes/pki/apiserver-etcd-client.crt +/etc/kubernetes/pki/ca.key +/etc/kubernetes/pki/ca.crt +/etc/kubernetes/pki/apiserver.key +/etc/kubernetes/pki/apiserver.crt +/etc/kubernetes/pki/apiserver-kubelet-client.key +/etc/kubernetes/pki/apiserver-kubelet-client.crt +/etc/kubernetes/pki/front-proxy-ca.key +/etc/kubernetes/pki/front-proxy-ca.crt +/etc/kubernetes/pki/front-proxy-client.key +/etc/kubernetes/pki/front-proxy-client.crt +/etc/kubernetes/pki/etcd/server.key +/etc/kubernetes/pki/etcd/server.crt +/etc/kubernetes/pki/etcd/peer.key +/etc/kubernetes/pki/etcd/peer.crt +/etc/kubernetes/pki/etcd/healthcheck-client.key +/etc/kubernetes/pki/etcd/healthcheck-client.crt +/etc/kubernetes/pki/sa.key +/etc/kubernetes/pki/sa.pub +``` + +## پیکربندی گواهینامه‌ها برای حساب‌های کاربری + +شما باید این حساب‌های کاربری مدیر و حساب‌های کاربری سرویس را به صورت دستی پیکربندی کنید: + +| Filename | Credential name | Default CN | O (in Subject) | +|-------------------------|----------------------------|-------------------------------------|------------------------| +| admin.conf | default-admin | kubernetes-admin | `` | +| super-admin.conf | default-super-admin | kubernetes-super-admin | system:masters | +| kubelet.conf | default-auth | system:node:`` (see note) | system:nodes | +| controller-manager.conf | default-controller-manager | system:kube-controller-manager | | +| scheduler.conf | default-scheduler | system:kube-scheduler | | + +{{< note >}} +مقدار `` برای `kubelet.conf` **باید** دقیقاً با مقدار نام گره ارائه شده توسط kubelet هنگام ثبت نام در apiserver مطابقت داشته باشد. برای جزئیات بیشتر، [مجوز گره](/docs/reference/access-authn-authz/node/) را مطالعه کنید. +{{< /note >}} + +{{< note >}} +در مثال بالا، `` مختص پیاده‌سازی است. برخی ابزارها گواهی موجود در فایل پیش‌فرض `admin.conf` را امضا می‌کنند تا بخشی از گروه `system:masters` باشد. `system:masters` یک گروه کاربر ویژه (super user group) است که می‌تواند لایه مجوز کوبرنتیز مانند RBAC را دور بزند. همچنین برخی ابزارها یک `super-admin.conf` جداگانه با گواهی متصل به این گروه کاربر ویژه ایجاد نمی‌کنند. + +kubeadm دو گواهی مدیر جداگانه در فایل‌های kubeconfig ایجاد می‌کند. +یکی در `admin.conf` است و دارای `Subject: O = kubeadm:cluster-admins, CN = kubernetes-admin` است. +`kubeadm:cluster-admins` یک گروه سفارشی است که به ClusterRole `cluster-admin` متصل است. +این فایل در تمام ماشین‌های control plane مدیریت‌شده kubeadm ایجاد می‌شود. + +یکی دیگر در `super-admin.conf` است که دارای `Subject: O = system:masters, CN = kubernetes-super-admin` است. +این فایل فقط در گره‌ای که `kubeadm init` در آن فراخوانی شده است، ایجاد می‌شود. +{{< /note >}} + +1. برای هر پیکربندی، یک جفت گواهی/کلید x509 با نام مشترک (CN) و سازمان (O) داده شده ایجاد کنید. + +1. برای هر پیکربندی، `kubectl` را به صورت زیر اجرا کنید: + + ``` + KUBECONFIG= kubectl config set-cluster default-cluster --server=https://:6443 --certificate-authority --embed-certs + KUBECONFIG= kubectl config set-credentials --client-key .pem --client-certificate .pem --embed-certs + KUBECONFIG= kubectl config set-context default-system --cluster default-cluster --user + KUBECONFIG= kubectl config use-context default-system + ``` + +این فایل‌ها به صورت زیر استفاده می‌شوند: + +| Filename | Command | Comment | +|-------------------------|-------------------------|-----------------------------------------------------------------------| +| admin.conf | kubectl | Configures administrator user for the cluster | +| super-admin.conf | kubectl | Configures super administrator user for the cluster | +| kubelet.conf | kubelet | One required for each node in the cluster. | +| controller-manager.conf | kube-controller-manager | Must be added to manifest in `manifests/kube-controller-manager.yaml` | +| scheduler.conf | kube-scheduler | Must be added to manifest in `manifests/kube-scheduler.yaml` | + +فایل‌های زیر مسیرهای کامل فایل‌های فهرست‌شده در جدول قبلی را نشان می‌دهند: + +``` +/etc/kubernetes/admin.conf +/etc/kubernetes/super-admin.conf +/etc/kubernetes/kubelet.conf +/etc/kubernetes/controller-manager.conf +/etc/kubernetes/scheduler.conf +``` diff --git a/content/fa/docs/setup/best-practices/cluster-large.md b/content/fa/docs/setup/best-practices/cluster-large.md new file mode 100644 index 0000000000000..f6fb97b78bd3b --- /dev/null +++ b/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) +به شما کمک می‌کند تا با تغییر مقیاس خوشه، اندازه افزونه‌ها را به طور خودکار تغییر دهید. \ No newline at end of file diff --git a/content/fa/docs/setup/best-practices/enforcing-pod-security-standards.md b/content/fa/docs/setup/best-practices/enforcing-pod-security-standards.md new file mode 100644 index 0000000000000..dfdb00d365673 --- /dev/null +++ b/content/fa/docs/setup/best-practices/enforcing-pod-security-standards.md @@ -0,0 +1,54 @@ +--- +reviewers: +- xirehat +title: اجرای استانداردهای امنیتی pod +weight: 40 +--- + + + +این صفحه مروری بر بهترین شیوه‌ها در مورد اجرای [استانداردهای امنیتی پاد](/docs/concepts/security/pod-security-standards) ارائه می‌دهد. + + + +## استفاده از کنترل‌کننده پذیرش امنیتی داخلی 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) در مقابل یک ابزار شخص ثالث، کاملاً به شرایط شما بستگی دارد. هنگام ارزیابی هر راهکاری، اعتماد به زنجیره تأمین شما بسیار مهم است. در نهایت، استفاده از هر یک از رویکردهای فوق‌الذکر بهتر از انجام ندادن هیچ کاری خواهد بود. \ No newline at end of file diff --git a/content/fa/docs/setup/best-practices/multiple-zones.md b/content/fa/docs/setup/best-practices/multiple-zones.md new file mode 100644 index 0000000000000..4c83a8b2d540f --- /dev/null +++ b/content/fa/docs/setup/best-practices/multiple-zones.md @@ -0,0 +1,129 @@ +--- +reviewers: +- xirehat +title: اجرا در چندین منطقه +weight: 20 +content_type: concept +--- + + + +این صفحه اجرای کوبرنتیز را در چندین منطقه توضیح می‌دهد.. + + + +## پیشینه + +کوبرنتیز به گونه‌ای طراحی شده است که یک خوشه کوبرنتیز می‌تواند در چندین منطقه خرابی اجرا شود، که معمولاً این مناطق در یک گروه‌بندی منطقی به نام _region_ قرار می‌گیرند. ارائه دهندگان اصلی ابر، یک منطقه را به عنوان مجموعه‌ای از مناطق خرابی (که به آن _availability zones_ نیز می‌گویند) تعریف می‌کنند که مجموعه‌ای از ویژگی‌ها را ارائه می‌دهند: در یک منطقه، هر منطقه APIها و خدمات یکسانی را ارائه می‌دهد. + +معماری‌های ابری معمول با هدف به حداقل رساندن احتمال اینکه خرابی در یک منطقه، خدمات در منطقه دیگر را نیز مختل کند، طراحی شده‌اند. + +## رفتار Control Plane + +همه [اجزای control plane](/docs/concepts/architecture/#control-plane-components) +از اجرا به عنوان مجموعه‌ای از منابع قابل تعویض، که برای هر جزء تکرار می‌شوند، پشتیبانی می‌کنند. + +هنگامی که یک صفحه کنترل خوشه‌ای را مستقر می‌کنید، کپی‌هایی از اجزای صفحه کنترل را در چندین منطقه خرابی قرار دهید. اگر در دسترس بودن +یک نگرانی مهم است، حداقل سه منطقه خرابی را انتخاب کنید و هر جزء صفحه کنترل (API server, scheduler, etcd, +cluster controller manager) را در حداقل سه منطقه خرابی تکرار کنید. + +اگر یک مدیر کنترل‌کننده ابری را اجرا می‌کنید، باید +این را در تمام مناطق خرابی که انتخاب کرده‌اید نیز تکرار کنید. + +{{< note >}} +کوبرنتیز برای نقاط پایانی سرور API، انعطاف‌پذیری بین منطقه‌ای ارائه نمی‌دهد. شما می‌توانید از تکنیک‌های مختلفی برای بهبود در دسترس بودن برای سرور API خوشه، از جمله DNS round-robin، رکوردهای SRV یا یک راه‌حل متعادل‌سازی بار شخص ثالث با بررسی سلامت، استفاده کنید. +{{< /note >}} + +## رفتار گره + +کوبرنتیز به‌طور خودکار پادهای منابع بارکاری (مانند {{< glossary_tooltip text="Deployment" term_id="deployment" >}} +یا {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}) +را روی گره‌های مختلف یک خوشه توزیع می‌کند. این توزیع، اثر خرابی‌ها را کاهش می‌دهد. + +وقتی گره‌ها راه‌اندازی می‌شوند، kubelet روی هر گره به‌طور خودکار +{{< glossary_tooltip text="labels" term_id="label" >}} را به شیء Node +که نماینده همان kubelet در API کوبرنتیز است، اضافه می‌کند. +این برچسب‌ها می‌توانند شامل +[اطلاعات ناحیه](/docs/reference/labels-annotations-taints/#topologykubernetesiozone) باشند. + +اگر خوشه شما چندین ناحیه یا منطقه را پوشش می‌دهد، می‌توانید برچسب‌های گره را +به‌همراه +[محدودیت‌های گسترش توپولوژی پاد](/docs/concepts/scheduling-eviction/topology-spread-constraints/) +به‌کار بگیرید تا کنترل کنید پادها در میان دامنه‌های خطا—ناحیه‌ها، مناطق و حتی گره‌های خاص— +چطور در خوشه پخش شوند. این راهنماها به +{{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}} کمک می‌کنند +تا پادها را طوری جای دهد که دسترسی مورد انتظار بهبود یابد و خطر تأثیر یک خرابی همبسته +بر کل بارکاری کاهش پیدا کند. + +برای نمونه، می‌توانید محدودیتی تعیین کنید تا اطمینان حاصل شود +سه تکرار یک StatefulSet، هر یک در ناحیه‌ای متفاوت اجرا شوند، +هر زمان که امکان‌پذیر باشد. شما می‌توانید این را به‌صورت اعلامی تعریف کنید +بی‌آن‌که صراحتاً مشخص کنید کدام ناحیه‌های در دسترس برای هر بارکاری استفاده می‌شوند. + +### توزیع گره‌ها در مناطق مختلف + +هسته کوبرنتیز خودش برای شما گره ایجاد نمی‌کند؛ باید این کار را خودتان انجام دهید +یا از ابزاری مانند [Cluster API](https://cluster-api.sigs.k8s.io/) +برای مدیریت گره‌ها به نمایندگی از شما استفاده کنید. + +با بهره‌گیری از ابزارهایی مثل Cluster API می‌توانید مجموعه‌ای از ماشین‌ها را تعریف کنید +تا به‌عنوان گره‌های کارگر خوشه در چندین دامنه خطا اجرا شوند، و همچنین قوانینی +برای ترمیم خودکار خوشه در صورت اختلال کامل یک ناحیه وضع کنید. + +## تخصیص دستی منطقه برای Podها + +می‌توانید [محدودیت‌های انتخاب‌گر گره](/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) +را به پادهایی که ایجاد می‌کنید، و نیز به قالب‌های پاد در منابع بارکاری +مانند Deployment، StatefulSet یا Job اعمال کنید. + +## دسترسی به فضای ذخیره‌سازی برای مناطق + +هنگامی که حجم‌های پایدار ایجاد می‌شوند، کوبرنتیز به‌طور خودکار برچسب‌های ناحیه را +به هر PersistentVolume که به یک ناحیه خاص متصل است اضافه می‌کند. +{{< glossary_tooltip text="scheduler" term_id="kube-scheduler" >}} سپس از طریق +گزاره `NoVolumeZoneConflict` اطمینان حاصل می‌کند که پادهایی که یک PersistentVolume +مشخص را درخواست می‌کنند، تنها در همان ناحیه آن حجم قرار گیرند. + +توجه داشته باشید که روش افزودن برچسب‌های ناحیه می‌تواند به ارائه‌دهنده +ابر شما و فراهم‌کننده ذخیره‌سازی‌ای که استفاده می‌کنید وابسته باشد. +همیشه به مستندات اختصاصی محیط خود مراجعه کنید تا پیکربندی صحیح را تضمین کنید. + +می‌توانید یک {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}} +را برای PersistentVolumeClaimها مشخص کنید که دامنه‌های خطا (ناحیه‌ها) را که +ذخیره‌سازی در آن کلاس می‌تواند از آن‌ها استفاده کند تعریف می‌کند. +برای یادگیری پیکربندی یک StorageClass که از دامنه‌های خطا یا ناحیه‌ها آگاه است، +به [توپولوژی‌های مجاز](/docs/concepts/storage/storage-classes/#allowed-topologies) مراجعه کنید. + +## شبکه‌سازی + +به‌خودیِ‌خود، کوبرنتیز شبکه آگاه از ناحیه در اختیار ندارد. می‌توانید با استفاده از +[افزونه شبکه](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) +شبکه خوشه را پیکربندی کنید؛ این راهکار شبکه ممکن است اجزای مخصوص به ناحیه داشته باشد. +برای نمونه، اگر ارائه‌دهنده ابر شما از Serviceهایی با +`type=LoadBalancer` پشتیبانی کند، توازن‌بار احتمالاً ترافیک را تنها به پادهایی می‌فرستد +که در همان ناحیه‌ای اجرا می‌شوند که مؤلفه توازن‌بار در آن اتصال را پردازش می‌کند. +برای جزئیات بیشتر، به مستندات ارائه‌دهنده ابری خود مراجعه کنید. + +برای استقرارهای سفارشی یا درون‌سازمانی نیز ملاحظات مشابهی وجود دارد. +رفتار {{< glossary_tooltip text="Service" term_id="service" >}} و +{{< glossary_tooltip text="Ingress" term_id="ingress" >}}—از جمله نحوه رسیدگی به +نواحی خطای مختلف—بسته به چگونگی پیکربندی خوشه شما متفاوت است. + +## بازیابی خطا + +هنگامی که خوشه خود را راه‌اندازی می‌کنید، ممکن است لازم باشد بررسی کنید +که آیا و چگونه پیاده‌سازی شما می‌تواند سرویس را بازیابی کند اگر همه نواحی خطا +در یک منطقه به‌طور هم‌زمان از دسترس خارج شوند. برای نمونه، آیا +به این وابسته هستید که دست‌کم یک گره در یک ناحیه بتواند پادها را اجرا کند؟ +اطمینان حاصل کنید که هر کار تعمیر حیاتی خوشه به وجود دست‌کم یک گره سالم +وابسته نباشد. برای مثال، اگر تمام گره‌ها ناسالم شوند، شاید لازم باشد یک Job +تعمیر با {{< glossary_tooltip text="toleration" term_id="toleration" >}} ویژه اجرا کنید +تا تعمیر به‌اندازه‌ای پیش برود که دست‌کم یک گره دوباره به سرویس بازگردد. + +کوبرنتیز پاسخی از پیش آماده برای این چالش ارائه نمی‌دهد؛ +بااین‌حال، موضوعی است که باید در نظر داشته باشید. + +## {{% heading "whatsnext" %}} + +برای آشنایی با نحوه قرار دادن پادها در خوشه توسط scheduler با رعایت محدودیت‌های پیکربندی‌شده، +به صفحه [Scheduling and Eviction](/docs/concepts/scheduling-eviction/) مراجعه کنید. diff --git a/content/fa/docs/setup/best-practices/node-conformance.md b/content/fa/docs/setup/best-practices/node-conformance.md new file mode 100644 index 0000000000000..09cc4a8225880 --- /dev/null +++ b/content/fa/docs/setup/best-practices/node-conformance.md @@ -0,0 +1,93 @@ +--- +reviewers: +- xirehat +title: اعتبارسنجی تنظیمات گره +weight: 30 +--- + +## تست انطباق گره + +*آزمون انطباق گره* یک چارچوب آزمون کانتینری‌شده است که برای یک گره، +راستی‌آزمایی سامانه و آزمون کارکرد فراهم می‌کند. این آزمون بررسی می‌کند +آیا گره حداقل نیازمندی‌های کوبرنتیز را برآورده می‌کند یا نه؛ +گره‌ای که این آزمون را با موفقیت پشت سر بگذارد، +صلاحیت پیوستن به یک خوشه کوبرنتیز را دارد. + +## پیش‌نیاز گره + +هشدارها برای اجرای تست انطباق گره، یک گره باید همان پیش‌نیازهای یک گره استاندارد کوبرنتیز را داشته باشد. حداقل، گره باید سرویس‌های زیر را نصب کرده باشد: + +* زمان‌های اجرای کانتینر سازگار با CRI مانند Docker، containerd و CRI-O +* kubelet + +## اجرای تست انطباق گره + + +To run the node conformance test, perform the following steps: + +برای اجرای آزمون انطباق گره، مراحل زیر را انجام دهید: + +۱. مقدار گزینه `--kubeconfig` را برای kubelet تعیین کنید؛ برای مثال: + `--kubeconfig=/var/lib/kubelet/config.yaml`. + از آنجا که چارچوب آزمون برای بررسی kubelet یک کنترل‌پلین محلی راه‌اندازی می‌کند، + از `http://localhost:8080` به‌عنوان نشانی سرور API استفاده کنید. + چند پارامتر خط فرمان دیگر برای kubelet وجود دارد که ممکن است بخواهید به کار ببرید: + + * `--cloud-provider`: اگر از `--cloud-provider=gce` استفاده می‌کنید، + این پرچم را برای اجرای آزمون حذف کنید. + +۲. آزمون انطباق گره را با فرمان زیر اجرا کنید: + + ```shell + # $CONFIG_DIR is the pod manifest path of your kubelet. + # $LOG_DIR is the test output path. + sudo docker run -it --rm --privileged --net=host \ + -v /:/rootfs -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ + registry.k8s.io/node-test:0.2 + ``` + +## اجرای تست انطباق گره برای سایر معماری‌ها + +کوبرنتیز همچنین ایمیج‌های داکر تست انطباق گره را برای معماری‌های دیگر ارائه می‌دهد: + +| Arch | Image | +|--------|:-----------------:| +| amd64 | node-test-amd64 | +| arm | node-test-arm | +| arm64 | node-test-arm64 | + +## اجرای آزمون انتخاب شده + +برای اجرای تست‌های خاص، متغیر محیطی `FOCUS` را با عبارت منظم تست‌هایی که می‌خواهید اجرا کنید، بازنویسی کنید. + +```shell +sudo docker run -it --rm --privileged --net=host \ + -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ + -e FOCUS=MirrorPod \ # Only run MirrorPod test + registry.k8s.io/node-test:0.2 +``` + +برای رد کردن تست‌های خاص، متغیر محیطی `SKIP` را با عبارت منظم تست‌هایی که می‌خواهید رد کنید، بازنویسی کنید. + +```shell +sudo docker run -it --rm --privileged --net=host \ + -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \ + -e SKIP=MirrorPod \ # Run all conformance tests but skip MirrorPod test + registry.k8s.io/node-test:0.2 +``` + +آزمون انطباق گره نسخه کانتینری‌شده +[node e2e test](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/e2e-node-tests.md) +است و به‌طور پیش‌فرض همه آزمون‌های انطباق را اجرا می‌کند. + +از نظر تئوری، اگر کانتینر را به‌درستی پیکربندی کرده و +حجم‌های موردنیاز را مناسب مانت کنید، می‌توانید هر آزمون e2e گره را اجرا کنید. +اما **به‌شدت توصیه می‌شود فقط آزمون انطباق را اجرا کنید**، +زیرا اجرای آزمون‌های غیرانطباق به پیکربندی بسیار پیچیده‌تری نیاز دارد. + +## هشدارها + +* آزمون تعدادی image داکر را روی گره باقی می‌گذارد؛ از جمله image آزمون انطباق گره و تصاویر + کانتینرهایی که در آزمون کارکرد استفاده شدند. +* آزمون چند کانتینر مرده را روی گره باقی می‌گذارد. این کانتینرها در طول آزمون کارکرد + ایجاد می‌شوند. diff --git a/content/fa/docs/setup/learning-environment/_index.md b/content/fa/docs/setup/learning-environment/_index.md new file mode 100644 index 0000000000000..018b95a08a259 --- /dev/null +++ b/content/fa/docs/setup/learning-environment/_index.md @@ -0,0 +1,35 @@ +--- +title: محیط یادگیری +weight: 20 +--- + + + + diff --git a/content/fa/docs/setup/production-environment/_index.md b/content/fa/docs/setup/production-environment/_index.md new file mode 100644 index 0000000000000..e4375a77ff880 --- /dev/null +++ b/content/fa/docs/setup/production-environment/_index.md @@ -0,0 +1,140 @@ +--- +title: "محیط عملیاتی" +description: ایجاد یک خوشه کوبرنتیز با کیفیت عملیاتی +weight: 30 +no_list: true +--- + + +یک خوشه کوبرنتیز با کیفیت تولید، نیاز به برنامه‌ریزی و آماده‌سازی دارد. +اگر خوشه کوبرنتیز شما قرار است بارهای کاری حیاتی را اجرا کند، باید طوری پیکربندی شود که انعطاف‌پذیر باشد. +این صفحه مراحلی را که می‌توانید برای راه‌اندازی یک خوشه آماده تولید، یا ارتقاء یک خوشه موجود برای استفاده در تولید، انجام دهید، توضیح می‌دهد. +اگر از قبل با راه‌اندازی تولید آشنا هستید و لینک‌ها را می‌خواهید، به [قدم بعدی](#what-s-next) بروید. + + + +## ملاحظات عملیاتی + +به‌طور معمول، یک محیط خوشۀ کوبرنتیز در سطح **تولید** نیازمندی‌های بیشتری از یک محیط شخصیِ یادگیری، توسعه یا آزمون دارد. یک محیط تولید ممکن است به دسترسی ایمن توسط کاربران متعدد، دسترس‌پذیری مداوم و منابعی برای سازگاری با نیازهای متغیّر احتیاج داشته باشد. + +هنگامی که تصمیم می‌گیرید محیط تولیدی کوبرنتیز شما کجا قرار بگیرد (در محل خودتان یا در یک سرویس ابری) و چه میزان از مدیریت را خودتان بر عهده بگیرید یا به دیگران واگذار کنید، در نظر داشته باشید که نیازهای شما برای یک خوشۀ کوبرنتیز تحت تأثیر موضوعات زیر است: + +- *دسترس‌پذیری*: یک [محیط یادگیری](/docs/setup/#learning-environment) کوبرنتیز تک‌ماشینه تنها یک نقطۀ شکست دارد. برای ایجاد یک خوشۀ با دسترس‌پذیری بالا باید موارد زیر را در نظر بگیرید: + - جدا کردن *کنترل پلِین* (Control Plane) از نودهای کارگر. + - تکثیر مؤلفه‌های کنترل پلِین روی چند نود. + - متوازن‌سازی بار ترافیک به {{< glossary_tooltip term_id="kube-apiserver" text="API server" >}} خوشه. + - در اختیار داشتن نودهای کارگر کافی، یا توانایی فراهم کردن سریع آن‌ها، زمانی که بار کاری تغییر می‌کند. + +- *مقیاس‌پذیری*: اگر انتظار دارید محیط تولیدی کوبرنتیز شما با بار ثابتی روبه‌رو شود، شاید بتوانید ظرفیتی را که لازم دارید یک‌بار پیکربندی کنید و کار تمام شود. اما اگر انتظار دارید بار در طول زمان رشد کند یا بر اساس عواملی مانند فصول یا رویدادهای ویژه به‌شدّت تغییر کند، باید برنامه‌ای برای مقیاس‌پذیری داشته باشید تا فشارِ ناشی از درخواست‌های بیشتر به کنترل پلِین و نودهای کارگر را کاهش دهید، یا در زمان کاهش بار منابع بلااستفاده را کم کنید. + +- *امنیت و مدیریت دسترسی*: در خوشۀ یادگیری شخصی خودتان، شما دسترسی کامل ادمین دارید. امّا خوشه‌های مشترک با بارهای کاری مهم و بیش از یکی دو کاربر به رویکرد دقیق‌تری برای اینکه چه کسی و چه چیزی می‌تواند به منابع خوشه دسترسی داشته باشد نیاز دارند. می‌توانید با کنترل دسترسی مبتنی بر نقش ([RBAC](/docs/reference/access-authn-authz/rbac/)) و سازوکارهای امنیتی دیگر اطمینان حاصل کنید که کاربران و بارهای کاری به منابع موردنیاز خود دسترسی پیدا می‌کنند، در حالی که خود بارهای کاری و خوشه ایمن باقی بمانند. همچنین می‌توانید با مدیریت [سیاست‌ها](/docs/concepts/policy/) و [منابع کانتینر](/docs/concepts/configuration/manage-resources-containers/) محدودیت‌هایی برای منابع قابل استفاده توسط کاربران و بارهای کاری تعیین کنید. + +پیش از آنکه خودتان اقدام به ساخت یک محیط تولیدی کوبرنتیز کنید، در نظر بگیرید که بخشی یا تمام این کار را به ارائه‌دهندگان +[راهکارهای ابری آماده](/docs/setup/production-environment/turnkey-solutions/) +یا سایر [شرکای کوبرنتیز](/partners/) واگذار کنید. +گزینه‌ها شامل موارد زیر است: + +- *بدون سرور (Serverless)*: فقط بارهای کاری را روی تجهیزات شخص ثالث اجرا کنید بدون آنکه هیچ خوشه‌ای را مدیریت کنید. هزینه‌ها معمولاً بر اساس مصرف CPU، حافظه و درخواست‌های دیسک محاسبه می‌شود. +- *کنترل پلِین مدیریت‌شده*: مقیاس و دسترس‌پذیری کنترل پلِین خوشه، به‌همراه اعمال وصله‌ها و به‌روزرسانی‌ها، بر عهدۀ ارائه‌دهنده خواهد بود. +- *نودهای کارگر مدیریت‌شده*: شما استخرهایی از نودها را مطابق نیازتان پیکربندی می‌کنید و ارائه‌دهنده اطمینان می‌دهد این نودها در دسترس باشند و هنگام لزوم به‌روزرسانی شوند. +- *یکپارچه‌سازی (Integration)*: برخی ارائه‌دهندگان کوبرنتیز را با سرویس‌های دیگری که ممکن است نیاز داشته باشید ــ مانند ذخیره‌سازی، رجیستری کانتینر، روش‌های احراز هویت و ابزارهای توسعه ــ یکپارچه می‌کنند. + +چه خودتان یک خوشۀ تولیدی کوبرنتیز بسازید و چه با شرکا کار کنید، برای ارزیابی نیازهای‌تان در ارتباط با *کنترل پلِین*، *نودهای کارگر*، *دسترسی کاربران* و *منابع بارهای کاری*، بخش‌های زیر را مرور کنید. + +## راه‌اندازی خوشه عملیاتی + +در یک خوشه کوبرنتیز با کیفیت عملیاتی، صفحه کنترل، خوشه را از سرویس‌هایی که می‌توانند به روش‌های مختلف در چندین کامپیوتر پخش شوند، مدیریت می‌کند. با این حال، هر گره کارگر، یک موجودیت واحد را نشان می‌دهد که برای اجرای پادهای کوبرنتیز پیکربندی شده است. + +### Control plane عملیاتی + +ساده‌ترین خوشۀ کوبرنتیز تمام سرویس‌های **کنترل پلِین** و نودهای کارگر را روی یک ماشین اجرا می‌کند. می‌توانید با افزودن نودهای کارگر، همان‌طور که در نمودار بخش [اجزای کوبرنتیز](/docs/concepts/overview/components/) نمایش داده شده است، آن محیط را گسترش دهید. اگر خوشه قرار است برای مدت کوتاهی در دسترس باشد یا در صورت بروز مشکل جدی بتوان آن را کنار گذاشت، این پیکربندی ممکن است نیازهای شما را برآورده کند. + +اما اگر به خوشه‌ای دائمی و با دسترس‌پذیری بالا نیاز دارید، باید راه‌هایی برای گسترش کنترل پلِین در نظر بگیرید. اجرای سرویس‌های کنترل پلِین روی یک ماشین واحد ذاتاً **دسترس‌پذیر** نیست. اگر سرپا نگه‌داشتن خوشه و امکان ترمیم آن در صورت بروز مشکل برایتان مهم است، گام‌های زیر را در نظر بگیرید: + +- *انتخاب ابزارهای استقرار*: می‌توانید کنترل پلِین را با ابزارهایی مانند **kubeadm**، **kops** و **kubespray** مستقر کنید. برای نکته‌های استقرار در سطح تولید، به صفحه [نصب کوبرنتیز با ابزارهای استقرار](/docs/setup/production-environment/tools/) مراجعه کنید. گزینه‌های متفاوتی از [موتورهای اجرایی کانتینر](/docs/setup/production-environment/container-runtimes/) نیز در دسترس است. +- *مدیریت گواهی‌ها*: ارتباطات ایمن بین سرویس‌های کنترل پلِین با استفاده از گواهی‌ها پیاده می‌شود. گواهی‌ها می‌توانند در زمان استقرار به‌طور خودکار ایجاد شوند یا توسط مرجع صدور گواهی شخصیِ شما تولید شوند. جزئیات را در [گواهی‌های PKI و الزامات](/docs/setup/best-practices/certificates/) ببینید. +- *پیکربندی متوازن‌کننده بار برای apiserver*: یک متوازن‌کننده بار راه‌اندازی کنید تا درخواست‌های خارجی API را بین نمونه‌های سرویس **apiserver** که روی نودهای مختلف اجرا می‌شوند توزیع کند. به [ایجاد متوازن‌کننده بار خارجی](/docs/tasks/access-application-cluster/create-external-load-balancer/) مراجعه کنید. +- *تفکیک و پشتیبان‌گیری از سرویس etcd*: سرویس‌های **etcd** می‌توانند همراه با سایر سرویس‌های کنترل پلِین روی همان ماشین‌ها یا برای امنیت و دسترس‌پذیری بیشتر روی ماشین‌های جداگانه اجرا شوند. از آنجا که etcd داده‌های پیکربندی خوشه را ذخیره می‌کند، باید به‌طور منظم از پایگاه داده آن نسخه پشتیبان تهیه شود تا در صورت لزوم بتوان آن را بازیابی کرد. برای جزئیات پیکربندی و استفاده از etcd به [سؤالات متداول etcd](https://etcd.io/docs/v3.5/faq/) مراجعه کنید. همچنین صفحات [عملیات روی خوشه‌های etcd برای کوبرنتیز](/docs/tasks/administer-cluster/configure-upgrade-etcd/) و [راه‌اندازی خوشه etcd با دسترس‌پذیری بالا توسط kubeadm](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) را ببینید. +- *ایجاد سامانه‌های چندگانه برای کنترل پلِین*: برای دسترس‌پذیری بالا، کنترل پلِین نباید به یک ماشین محدود شود. اگر سرویس‌های کنترل پلِین را یک سرویس init (مانند systemd) اجرا کند، هر سرویس باید حداقل روی سه ماشین اجرا شود. با این حال، اجرای سرویس‌های کنترل پلِین به‌صورت پاد در کوبرنتیز تضمین می‌کند که تعداد تکرارهای درخواستی شما همیشه در دسترس باشد. زمان‌بند باید **تحمل خطا** داشته باشد، اما ضرورتی ندارد که به‌خودی‌خود Highly Available باشد. برخی ابزارهای استقرار از الگوریتم اجماع [Raft](https://raft.github.io/) برای انتخاب رهبر سرویس‌های کوبرنتیز استفاده می‌کنند؛ اگر سرویس اولیه از دسترس خارج شود، سرویس دیگری خود را انتخاب کرده و مسئولیت را به‌عهده می‌گیرد. +- *گسترش در چند منطقه (Zone)*: اگر بالا بودن مداوم خوشه حیاتی است، خوشه‌ای بسازید که در چند مرکز داده (zone در محیط‌های ابری) اجرا شود. گروهی از zoneها یک **region** را تشکیل می‌دهند. با پراکندن خوشه در چند zone در یک region، شانس عملکرد خوشه حتی در صورت عدم دسترس یک zone افزایش می‌یابد. جزئیات در [اجرای خوشه در چند zone](/docs/setup/best-practices/multiple-zones/). +- *مدیریت قابلیت‌های مداوم*: اگر قصد دارید خوشه را برای مدت طولانی نگه دارید، وظایفی برای حفظ سلامت و امنیت آن دارید. به‌عنوان مثال، اگر با kubeadm نصب کرده‌اید، دستورالعمل‌های [مدیریت گواهی‌ها](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/) و [ارتقای خوشه‌های kubeadm](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) را دنبال کنید. فهرست طولانی‌تری از کارهای مدیریتی را در [مدیریت یک خوشه](/docs/tasks/administer-cluster/) بیابید. + +برای آشنایی با گزینه‌های موجود هنگام اجرای سرویس‌های کنترل پلِین، صفحات مؤلفه‌های [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)، [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) و [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) را ببینید. برای نمونه‌های کنترل پلِین با دسترس‌پذیری بالا به [گزینه‌های توپولوژی Highly Available](/docs/setup/production-environment/tools/kubeadm/ha-topology/)، [ایجاد خوشه‌های Highly Available با kubeadm](/docs/setup/production-environment/tools/kubeadm/high-availability/) و [عملیات روی خوشه‌های etcd برای کوبرنتیز](/docs/tasks/administer-cluster/configure-upgrade-etcd/) مراجعه کنید. برای برنامه‌ریزی پشتیبان‌گیری از etcd، بخش [پشتیبان‌گیری از خوشه etcd](/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster) را مطالعه کنید. + +### گره‌های Worker عملیاتی + +بارهای کاری در سطح تولید باید **تاب‌آور** (Resilient) باشند و هر چیزی که به آن‌ها وابسته است (مانند CoreDNS) نیز باید تاب‌آور باشد. چه خودتان کنترل پلِین را مدیریت کنید و چه یک ارائه‌دهنده ابری این کار را برایتان انجام دهد، همچنان باید تصمیم بگیرید که چگونه می‌خواهید **نودهای کارگر** (که به‌اختصار *نود* نیز نامیده می‌شوند) را مدیریت کنید. + +- *پیکربندی نودها*: نودها می‌توانند ماشین فیزیکی یا مجازی باشند. اگر می‌خواهید نودهای خودتان را ایجاد و مدیریت کنید، می‌توانید یک سیستم‌عامل پشتیبانی‌شده نصب کرده، سپس سرویس‌های + [نود](/docs/concepts/architecture/#node-components) مناسب را اجرا کنید. در نظر داشته باشید: + - در زمان راه‌اندازی نودها، با توجه به نیاز بارهای کاری، حافظه، CPU، سرعت و ظرفیت دیسک مناسبی فراهم کنید. + - آیا سیستم‌های کامپیوتری عمومی کفایت می‌کنند یا بارهای کاری شما به پردازنده GPU، نودهای ویندوزی، یا جداسازی VM نیاز دارند؟ +- *اعتبارسنجی نودها*: برای اطمینان از اینکه یک نود شرایط لازم برای پیوستن به خوشه کوبرنتیز را دارد، بخش [راه‌اندازی معتبر نود](/docs/setup/best-practices/node-conformance/) را ببینید. +- *افزودن نودها به خوشه*: اگر خودتان خوشه را مدیریت می‌کنید، می‌توانید با راه‌اندازی ماشین‌های خود و افزودن دستی آن‌ها یا ثبت خودکارشان در apiserver خوشه، نودها را اضافه کنید. برای اطلاعات درباره این روش‌ها، به بخش [نودها](/docs/concepts/architecture/nodes/) مراجعه کنید. +- *مقیاس‌گذاری نودها*: برای افزایش ظرفیتی که در نهایت خوشه شما نیاز خواهد داشت برنامه داشته باشید. بخش [ملاحظات خوشه‌های بزرگ](/docs/setup/best-practices/cluster-large/) به شما کمک می‌کند بر اساس تعداد پادها و کانتینرهایی که باید اجرا شوند، تعیین کنید به چند نود نیاز دارید. اگر خودتان نودها را مدیریت می‌کنید، این کار می‌تواند به معنای خرید و نصب تجهیزات فیزیکی باشد. +- *مقیاس‌گذاری خودکار نودها*: برای آشنایی با ابزارهایی که به‌طور خودکار نودها و ظرفیت آن‌ها را مدیریت می‌کنند، [مقیاس‌گذاری خودکار نود](/docs/concepts/cluster-administration/node-autoscaling) را مطالعه کنید. +- *راه‌اندازی بررسی سلامت نودها*: برای بارهای کاری حیاتی، باید مطمئن شوید نودها و پادهای در حال اجرا روی آن‌ها سالم هستند. با استفاده از دمون [Node Problem Detector](/docs/tasks/debug/debug-cluster/monitor-node-health/) می‌توانید سلامت نودهای خود را تضمین کنید. + +## مدیریت کاربر عملیاتی + +در محیط تولید، ممکن است از مدلی که تنها شما یا گروه کوچکی از افراد به خوشه دسترسی داشتید، به حالتی برسید که ده‌ها یا حتی صدها نفر بتوانند از آن استفاده کنند. در یک محیط یادگیری یا نمونۀ اولیه، شاید فقط یک حساب کاربری مدیریتی برای همۀ کارها داشته باشید؛ ولی در محیط تولید به حساب‌های بیشتری با سطوح دسترسی گوناگون به نام‌فضاهای (namespaceهای) مختلف نیاز خواهید داشت. + +راه‌اندازی خوشه‌ای با کیفیت تولید یعنی تصمیم بگیرید چگونه به-طور گزینشی دسترسی سایر کاربران را فراهم کنید. به‌ویژه باید راهبردهایی برای تأیید هویت افرادی که سعی می‌کنند به خوشه دسترسی پیدا کنند (*احراز هویت*) و تعیین اینکه آیا مجاز به انجام کاری که می‌خواهند هستند یا نه (*مجازسازی*) برگزینید: + +- *احراز هویت (Authentication)*: سرویس ‌**apiserver** می‌تواند کاربران را با گواهی مشتری، توکن bearer، پروکسی احراز هویت یا HTTP basic auth شناسایی کند. شما می‌توانید روش‌های دلخواه خود را انتخاب کنید. به کمک پلاگین‌ها، ‌**apiserver** می‌تواند از سامانه‌های احراز هویت موجود سازمان شما (مثل LDAP یا Kerberos) بهره بگیرد. توضیحات بیشتر در [احراز هویت](/docs/reference/access-authn-authz/authentication/). + +- *مجازسازی (Authorization)*: زمانی که می‌خواهید به کاربران عادی مجوز بدهید، معمولاً میان «RBAC» و «ABAC» یکی را برمی‌گزینید. برای مرور شیوه‌های گوناگون مجوزدهی حساب‌های کاربری (و نیز دسترسی حساب‌های سرویس) به [مرور کلی مجازسازی](/docs/reference/access-authn-authz/authorization/) مراجعه کنید: + - *کنترل دسترسی مبتنی بر نقش* ([RBAC](/docs/reference/access-authn-authz/rbac/)): با اختصاص مجموعه‌ای از مجوزها به کاربران احرازشده، دسترسی آن‌ها را کنترل می‌کند. مجوزها می‌توانند در یک نام‌فضا خاص (Role) یا در کل خوشه (ClusterRole) تعریف شوند. سپس با RoleBinding و ClusterRoleBinding این مجوزها به کاربران موردنظر وصل می‌شوند. + - *کنترل دسترسی مبتنی بر ویژگی* ([ABAC](/docs/reference/access-authn-authz/abac/)): به شما اجازه می‌دهد سیاست‌هایی بر پایه ویژگی‌های منبع بسازید تا دسترسی را براساس همان ویژگی‌ها اجازه یا رد کند. هر خط از فایل سیاست، ویژگی‌های نسخه (apiVersion و kind) و نگاشتی از ویژگی‌های spec را برای تطابق موضوع (کاربر یا گروه)، ویژگی منبع، ویژگی غیرمنبعی (/version یا /apis) و readonly مشخص می‌کند. برای جزئیات به [نمونه‌ها](/docs/reference/access-authn-authz/abac/#examples) مراجعه کنید. + +به‌عنوان کسی که احراز هویت و مجوزدهی را در خوشۀ تولیدی کوبرنتیز پیکربندی می‌کند، این نکته‌ها را در نظر داشته باشید: + +- *تنظیم حالت مجوزدهی*: هنگام راه‌اندازی سرویس **kube-apiserver** ([kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/))، باید حالت‌های پشتیبانی‌شده مجوزدهی را با فایل *--authorization-config* یا فلگ *--authorization-mode* تعیین کنید. برای مثال، در فایل *kube-adminserver.yaml* (در مسیر */etc/kubernetes/manifests*) می‌توانید این فلگ را روی `Node,RBAC` بگذارید تا مجوزدهی Node و RBAC برای درخواست‌های احرازشده فعال شود. + +- *ایجاد گواهی کاربران و اتصال نقش‌ها (RBAC)*: اگر از RBAC استفاده می‌کنید، کاربران می‌توانند یک **CertificateSigningRequest** (CSR) ایجاد کنند تا CA خوشه آن را امضا کند. سپس می‌توانید Role یا ClusterRoleها را به هر کاربر متصل کنید. جزئیات بیش‌تر در [درخواست امضای گواهی](/docs/reference/access-authn-authz/certificate-signing-requests/). + +- *ایجاد سیاست‌های ترکیبی (ABAC)*: اگر رویکرد ABAC را برگزیده‌اید، می‌توانید با ترکیب ویژگی‌ها سیاست‌هایی تعریف کنید تا به کاربران یا گروه‌های منتخب برای دسترسی به منابع مشخص (مثلاً یک پاد)، یک نام‌فضا یا apiGroup مجوز بدهد. برای اطلاعات بیشتر، به [نمونه‌ها](/docs/reference/access-authn-authz/abac/#examples) نگاهی بیندازید. + +- *در نظر گرفتن Admission Controllerها*: شکل‌های اضافی مجوزدهی برای درخواست‌هایی که از طریق API سرور می‌آیند، مانند [احراز هویت توکن وب‌هوک](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)، نیاز دارند تا با افزودن [Admission Controller](/docs/reference/access-authn-authz/admission-controllers/) به API سرور فعال شوند. + +## محدودیت‌هایی را برای منابع بار کاری تعیین کنید + +تقاضاهای ناشی از بارهای کاری **تولیدی** می‌توانند هم در داخل و هم در خارجِ کنترل پلِین کوبرنتیز فشار ایجاد کنند. هنگام آماده‌سازی برای نیازهای بارهای کاری خوشۀ خود، موارد زیر را در نظر داشته باشید: + +- *تنظیم محدودیت‌های نام‌فضا*: برای منابعی همچون حافظه و CPU، سهمیه‌هایی به‌صورت هر نام‌فضا تعیین کنید. برای جزئیات، به + [مدیریت حافظه، CPU و منابع API](/docs/tasks/administer-cluster/manage-resources/) مراجعه کنید. +- *آماده‌سازی برای تقاضای DNS*: اگر انتظار دارید بارهای کاری به‌شدّت مقیاس بگیرند، سرویس DNS شما نیز باید آمادۀ مقیاس‌گیری باشد. به + [مقیاس‌گذاری خودکار سرویس DNS در یک خوشه](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/) مراجعه کنید. +- *ایجاد حساب‌های سرویس اضافی*: حساب‌های کاربری تعیین می‌کنند کاربران در خوشه چه کاری می‌توانند انجام دهند، در حالی که یک حساب سرویس دسترسی پادها را در نام‌فضای مشخص تعریف می‌کند. به‌طور پیش‌فرض، یک پاد از حساب سرویس پیش‌فرض نام‌فضای خود استفاده می‌کند. برای ایجاد حساب سرویس جدید، بخش + [مدیریت حساب‌های سرویس](/docs/reference/access-authn-authz/service-accounts-admin/) را ببینید. برای نمونه، ممکن است بخواهید: + - سِکریت‌هایی اضافه کنید که یک پاد بتواند با آن‌ها تصویرها را از رجیستری کانتینر خاصی دریافت کند. نمونه‌ای را در + [پیکربندی حساب سرویس برای پادها](/docs/tasks/configure-pod-container/configure-service-account/) ببینید. + - مجوزهای RBAC را به یک حساب سرویس اختصاص دهید. برای جزئیات به + [مجوزهای حساب سرویس](/docs/reference/access-authn-authz/rbac/#service-account-permissions) مراجعه کنید. + +## {{% heading "whatsnext" %}} + +- تصمیم بگیرید که آیا می‌خواهید یک خوشۀ کوبرنتیز تولیدی را **خودتان** بسازید یا از + [راهکارهای آماده ابری](/docs/setup/production-environment/turnkey-solutions/) + یا [شرکای کوبرنتیز](/partners/) تهیه کنید. +- اگر ساخت خوشه را خودتان انتخاب می‌کنید، برنامه‌ریزی کنید که چگونه + [گواهی‌ها](/docs/setup/best-practices/certificates/) را مدیریت کنید و برای قابلیت دسترس‌پذیری بالا + در مؤلفه‌هایی مانند + [etcd](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) + و + [سرور API](/docs/setup/production-environment/tools/kubeadm/ha-topology/) + آماده شوید. +- از میان روش‌های استقرار + [kubeadm](/docs/setup/production-environment/tools/kubeadm/)، + [kops](https://kops.sigs.k8s.io/) یا + [Kubespray](https://kubespray.io/) یکی را برگزینید. +- با تعیین روش‌های + [احراز هویت](/docs/reference/access-authn-authz/authentication/) + و + [مجازسازی](/docs/reference/access-authn-authz/authorization/) + خود، مدیریت کاربران را پیکربندی کنید. +- برای آماده‌سازی بارهای کاریِ برنامه‌های کاربردی، موارد زیر را تنظیم کنید: + [محدودیت منابع](/docs/tasks/administer-cluster/manage-resources/)، + [مقیاس‌گذاری خودکار DNS](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/) + و + [حساب‌های سرویس](/docs/reference/access-authn-authz/service-accounts-admin/). diff --git a/content/fa/docs/setup/production-environment/container-runtimes.md b/content/fa/docs/setup/production-environment/container-runtimes.md new file mode 100644 index 0000000000000..ebeafca2f4482 --- /dev/null +++ b/content/fa/docs/setup/production-environment/container-runtimes.md @@ -0,0 +1,308 @@ +--- +reviewers: +- xirehat +title: برنامه‌های زمان‌اجرای کانتینر +content_type: concept +weight: 20 +--- + + +{{% dockershim-removal %}} + +شما باید یک +{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}} +روی هر گره در خوشه نصب کنید تا پادها بتوانند در آن اجرا شوند. این صفحه توضیح می‌دهد چه مواردی درگیر هستند و وظایف مرتبط برای راه‌اندازی گره‌ها را توصیف می‌کند. + +کوبرنتیز {{< skew currentVersion >}} نیاز دارد که از یک Runtime استفاده کنید که با +{{< glossary_tooltip term_id="cri" text="Container Runtime Interface">}} (CRI) سازگار باشد. + +برای اطلاعات بیشتر به [پشتیبانی نسخه‌های CRI](#cri-versions) مراجعه کنید. + +این صفحه نمای کلی از نحوه استفاده از چند Runtime رایج کانتینر با کوبرنتیز را ارائه می‌کند. + +- [containerd](#containerd) +- [CRI-O](#cri-o) +- [Docker Engine](#docker) +- [Mirantis Container Runtime](#mcr) + + +{{< note >}} +نسخه‌های کوبرنتیز پیش از v1.24 یک ادغام مستقیم با Docker Engine داشتند که توسط +مولفه‌ای به نام _dockershim_ فراهم می‌شد. این ادغام مستقیم ویژه دیگر بخشی از +کوبرنتیز نیست (این حذف به‌عنوان بخشی از انتشار v1.20 +[اعلام شد](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)). +برای درک این‌که این تغییر چه تأثیری بر شما می‌گذارد، بخش +[بررسی کنید که آیا حذف Dockershim بر شما تأثیر می‌گذارد](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/) +را مطالعه کنید. برای آشنایی با نحوه مهاجرت از dockershim نیز به +[مهاجرت از dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/) +مراجعه کنید. + +اگر نسخه‌ای از کوبرنتیز غیر از v{{< skew currentVersion >}} را اجرا می‌کنید، +مستندات همان نسخه را بررسی کنید. +{{< /note >}} + + +## نصب و پیکربندی پیش‌نیازها + +### پیکربندی شبکه + +به‌طور پیش‌فرض، هسته لینوکس اجازه نمی‌دهد بسته‌های IPv4 بین رابط‌ها مسیریابی شوند. اکثر پیاده‌سازی‌های شبکه خوشه کوبرنتیز این تنظیم را (در صورت نیاز) تغییر می‌دهند، اما بعضی ممکن است انتظار داشته باشند که مدیر سیستم خودش این کار را انجام دهد. (همچنین ممکن است انتظار داشته باشند پارامترهای sysctl دیگری تنظیم شود، ماژول‌های هسته بارگذاری شوند و غیره؛ مستندات پیاده‌سازی شبکه خاص خود را بررسی کنید.) + +### فعال کردن ارسال بسته IPv4 {#prerequisite-ipv4-forwarding-optional} + +برای فعال کردن دستی ارسال بسته IPv4: + +```bash +# sysctl params required by setup, params persist across reboots +cat <}} برای محدود کردن منابع اختصاص‌یافته به فرایندها به کار می‌روند. + +هم {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} و هم موتور کانتینر زیرساخت باید برای اعمال +[مدیریت منابع پادها و کانتینرها](/docs/concepts/configuration/manage-resources-containers/) +و تنظیم منابعی مانند درخواست‌ها و محدودیت‌های CPU/حافظه با control groupها تعامل داشته باشند. برای این تعامل، kubelet و موتور کانتینر باید از یک *درایور cgroup* استفاده کنند. +مهم است که kubelet و موتور کانتینر از **همان** درایور cgroup استفاده کرده و به‌گونه‌ای یکسان پیکربندی شوند. + +دو درایور cgroup در دسترس هستند: + +* [`cgroupfs`](#cgroupfs-cgroup-driver) +* [`systemd`](#systemd-cgroup-driver) + +### درایور cgroupfs {#cgroupfs-cgroup-driver} + +درایور `cgroupfs` [درایور پیش‌فرض cgroup در kubelet](/docs/reference/config-api/kubelet-config.v1beta1) است. +زمانی که از درایور `cgroupfs` استفاده می‌شود، kubelet و موتور کانتینر به‌طور مستقیم با +فایل‌سیستم cgroup برای پیکربندی cgroupها تعامل می‌کنند. + +درایور `cgroupfs` هنگامی که +[systemd](https://www.freedesktop.org/wiki/Software/systemd/) به‌عنوان سامانه init استفاده می‌شود **توصیه نمی‌شود**، +چرا که systemd انتظار دارد در سیستم تنها یک مدیر cgroup وجود داشته باشد. افزون بر این، +اگر از [cgroup v2](/docs/concepts/architecture/cgroups) استفاده می‌کنید، به‌جای `cgroupfs` +از درایور `systemd` بهره بگیرید. + +### درایور systemd cgroup {#systemd-cgroup-driver} + +هنگامی که [systemd](https://www.freedesktop.org/wiki/Software/systemd/) به‌عنوان سامانه init در یک توزیع لینوکس انتخاب می‌شود، فرایند init یک گروه کنترل ریشه (`cgroup`) ایجاد کرده و از آن استفاده می‌کند و در نقش مدیر cgroup عمل می‌کند. + +systemd با cgroupها یکپارچگی تنگاتنگی دارد و برای هر واحد systemd یک cgroup اختصاص می‌دهد. بنابراین، اگر systemd سامانه init باشد ولی از درایور `cgroupfs` استفاده کنید، سیستم دو مدیر cgroup متفاوت خواهد داشت. + +وجود دو مدیر cgroup باعث می‌شود دو نما از منابعِ در دسترس و در حال استفاده سیستم شکل گیرد. در برخی موارد، نودهایی که kubelet و موتور کانتینر آن‌ها از `cgroupfs` استفاده می‌کند اما سایر فرایندها زیر نظر systemd اجرا می‌شوند، زیر فشار منابع دچار ناپایداری می‌گردند. + +راهکار کاهش این ناپایداری آن است که وقتی systemd به‌عنوان init استفاده می‌شود، برای kubelet و موتور کانتینر نیز درایور cgroup را `systemd` قرار دهید. + +برای تنظیم `systemd` به‌عنوان درایور cgroup، گزینه `cgroupDriver` را در +[`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/) +ویرایش کرده و مقدار آن را `systemd` بگذارید. برای مثال: + +```yaml +apiVersion: kubelet.config.k8s.io/v1beta1 +kind: KubeletConfiguration +... +cgroupDriver: systemd +``` + +{{< note >}} +از نسخه v1.22 به بعد، هنگام ایجاد یک خوشه با **kubeadm**، اگر کاربر فیلد `cgroupDriver` را در بخش `KubeletConfiguration` تنظیم نکند، **kubeadm** به‌صورت پیش‌فرض آن را روی `systemd` قرار می‌دهد. +{{< /note >}} + +اگر `systemd` را به‌عنوان درایور cgroup برای **kubelet** پیکربندی می‌کنید، باید برای +موتور کانتینر نیز همین درایور را تنظیم کنید. برای دستورالعمل‌های لازم، به مستندات +موتور کانتینر خود رجوع کنید. برای مثال: + +* [containerd](#containerd-systemd) +* [CRI-O](#cri-o) + +در کوبرنتیز {{< skew currentVersion >}}، با فعال بودن +دروازه ویژگی `KubeletCgroupDriverFromCRI` +و وجود موتور کانتینری که فراخوان (RPC) ‏`RuntimeConfig` را در رابط CRI پشتیبانی کند، +**kubelet** درایور cgroup مناسب را به‌طور خودکار از موتور تشخیص می‌دهد +و تنظیم `cgroupDriver` در پیکربندی kubelet را نادیده می‌گیرد. + +{{< caution >}} +تغییر درایور cgroup نودی که به یک خوشه پیوسته، عملی حساس است. اگر **kubelet** +پادهایی را با قواعد مربوط به یک درایور cgroup ایجاد کرده باشد، تغییر +موتور کانتینر به درایور دیگری می‌تواند هنگام بازایجاد *Pod Sandbox* برای آن +پادهای موجود خطا ایجاد کند. راه‌اندازی مجدد kubelet ممکن است این خطاها را رفع نکند. + +اگر امکان اتوماسیون دارید، نود را با نودی تازه و پیکربندی به‌روز جایگزین کرده +یا با استفاده از ابزارهای خودکار مجدداً نصبش کنید. +{{< /caution >}} + + +### مهاجرت به درایور `systemd` در خوشه‌های مدیریت‌شده توسط kubeadm + +اگر می‌خواهید در خوشه‌های موجودِ مدیریت‌شده با `kubeadm` به درایور cgroup `systemd` مهاجرت کنید، راهنمای [پیکربندی درایور cgroup](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/) را دنبال کنید. + +## پشتیبانی از نسخه CRI {#cri-versions} + +موتور کانتینر شما باید دست‌کم از نسخه **v1alpha2** رابط اجرای کانتینر (CRI) پشتیبانی کند. + +کوبرنتیز از [نسخه v1.26 به بعد](/blog/2022/11/18/upcoming-changes-in-kubernetes-1-26/#cri-api-removal) +_تنها با_ نسخه **v1** رابط CRI کار می‌کند. نسخه‌های پیشین به‌طور پیش‌فرض از همین نسخه v1 استفاده می‌کنند؛ +اما اگر موتور کانتینر از API نسخه v1 پشتیبانی نکند، **kubelet** به‌جای آن به نسخه قدیمی +(منسوخ‌شده) **v1alpha2** بازمی‌گردد. + +## Container runtimes + +{{% thirdparty-content %}} + +### containerd + +این بخش گام‌های لازم برای استفاده از **containerd** به‌عنوان محیط اجرای CRI را شرح می‌دهد. + +برای نصب containerd روی سیستم خود، دستورالعمل‌های +[شروع به کار با containerd](https://github.com/containerd/containerd/blob/main/docs/getting-started.md) +را دنبال کنید. پس از آنکه یک پرونده پیکربندی معتبر `config.toml` ایجاد کردید، به این مرحله بازگردید. + +{{< tabs name="Finding your config.toml file" >}} +{{% tab name="Linux" %}} +می‌توانید این پرونده را در مسیر `/etc/containerd/config.toml` پیدا کنید. +{{% /tab %}} +{{% tab name="Windows" %}} +می‌توانید این پرونده را در مسیر `C:\Program Files\containerd\config.toml` پیدا کنید. +{{% /tab %}} +{{< /tabs >}} + +در لینوکس، سوکت پیش‌فرض CRI برای containerd مسیر `/run/containerd/containerd.sock` است. +در ویندوز، نقطه پایانی پیش‌فرض CRI مقدار `npipe://./pipe/containerd-containerd` است. + +#### پیکربندی درایور cgroup مربوط به systemd {#containerd-systemd} + +برای استفاده از درایور cgroup `systemd` در فایل `/etc/containerd/config.toml` همراه با `runc`، مقدار زیر را تنظیم کنید + +``` +[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc] + ... + [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options] + SystemdCgroup = true +``` + +درایور cgroup `systemd` در صورتی که از [cgroup v2](/docs/concepts/architecture/cgroups) استفاده می‌کنید توصیه می‌شود. + +{{< note >}} +اگر containerd را از طریق بسته نصبی (مثلاً RPM یا `.deb`) نصب کرده باشید، ممکن است +افزونه یکپارچه‌سازی CRI به‌طور پیش‌فرض غیرفعال باشد. + +برای استفاده از containerd با Kubernetes باید پشتیبانی CRI فعال باشد. مطمئن شوید که `cri` +در فهرست `disabled_plugins` در فایل `/etc/containerd/config.toml` درج نشده است؛ +اگر در این فایل تغییری ایجاد کردید، حتماً `containerd` را نیز راه‌اندازی مجدد کنید. + +اگر پس از نصب اولیه خوشه یا نصب یک CNI با حلقه کرش کانتینر مواجه شدید، +احتمالاً پیکربندی containerd ارائه‌شده در بسته شامل پارامترهای ناسازگار است. +در این صورت، پیکربندی containerd را با اجرای دستور +`containerd config default > /etc/containerd/config.toml` +طبق مستند +[getting-started.md](https://github.com/containerd/containerd/blob/main/docs/getting-started.md#advanced-topics) +بازنشانی کنید و سپس پارامترهای پیکربندی بالا را مطابق نیاز تنظیم نمایید. +{{< /note >}} + +اگر این تغییر را اعمال کردید، حتماً containerd را بازراه‌اندازی کنید: + +```shell +sudo systemctl restart containerd +``` + +هنگام استفاده از **kubeadm**، درایور cgroup برای **kubelet** را به‌صورت دستی پیکربندی کنید: +[cgroup driver for kubelet](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/#configuring-the-kubelet-cgroup-driver). + +در کوبرنتیز نسخه v1.28، می‌توانید شناسایی خودکار درایور cgroup را به‌عنوان یک قابلیت آلفا فعال کنید. برای جزئیات بیش‌تر، بخش +[درایور cgroup systemd](#systemd-cgroup-driver) را ببینید. + +#### نادیده گرفتن sandbox (pause) image {#override-pause-image-containerd} + +در [پیکربندی containerd](https://github.com/containerd/containerd/blob/main/docs/cri/config.md) خود می‌توانید تصویر sandbox را با تنظیم زیر بازنویسی کنید: + +```toml +[plugins."io.containerd.grpc.v1.cri"] + sandbox_image = "registry.k8s.io/pause:3.10" +``` + +پس از به‌روزرسانی فایل پیکربندی، ممکن است نیاز باشد `containerd` را نیز بازراه‌اندازی کنید: +`systemctl restart containerd` + +### CRI-O + +این بخش شامل گام‌های لازم برای نصب **CRI-O** به‌عنوان محیط اجرای کانتینر است. + +برای نصب CRI-O، دستورالعمل‌های [نصب CRI-O](https://github.com/cri-o/packaging/blob/main/README.md#usage) را دنبال کنید. + +#### درایور cgroup + +CRI-O به‌طور پیش‌فرض از درایور cgroup ‌`systemd` استفاده می‌کند که احتمالاً برای شما به‌خوبی کار خواهد کرد. +برای تغییر به درایور cgroup ‌`cgroupfs`، یا فایل `/etc/crio/crio.conf` را ویرایش کنید یا یک پیکربندی drop-in در مسیر `/etc/crio/crio.conf.d/02-cgroup-manager.conf` قرار دهید؛ برای مثال: + +```toml +[crio.runtime] +conmon_cgroup = "pod" +cgroup_manager = "cgroupfs" +``` + +همچنین باید به گزینه تغییر‌یافته `conmon_cgroup` توجه کنید؛ هنگام استفاده از CRI-O همراه با `cgroupfs`، این گزینه باید روی مقدار `pod` تنظیم شود. به‌طور کلی، لازم است پیکربندی درایور cgroup در kubelet (که معمولاً با kubeadm انجام می‌شود) و در CRI-O با هم همگام باشند. + +در کوبرنتیز نسخه v1.28، می‌توانید تشخیص خودکار درایور cgroup را به‌عنوان یک ویژگی آلفا فعال کنید. برای جزئیات بیش‌تر به [درایور cgroup systemd](#systemd-cgroup-driver) مراجعه کنید. + +در CRI-O، سوکت CRI به‌صورت پیش‌فرض `/var/run/crio/crio.sock` است. + +#### نادیده گرفتن sandbox (pause) image {#override-pause-image-cri-o} + +در پیکربندی [CRI-O](https://github.com/cri-o/cri-o/blob/main/docs/crio.conf.5.md) خود می‌توانید مقدار پیکربندی زیر را تنظیم کنید: + +```toml +[crio.image] +pause_image="registry.k8s.io/pause:3.10" +``` + +این گزینه پیکربندی از **بارگذاری زنده پیکربندی** برای اعمال تغییر پشتیبانی می‌کند؛ کافی است دستور +`systemctl reload crio` را اجرا کنید یا سیگنال `SIGHUP` را به فرایند `crio` بفرستید. + +### Docker Engine {#docker} + +{{< note >}} +این دستورالعمل‌ها فرض می‌کنند که شما از +[`cri-dockerd`](https://mirantis.github.io/cri-dockerd/) برای یکپارچه‌سازی Docker Engine +با Kubernetes استفاده می‌کنید. +{{< /note >}} + +1. روی هر یک از نودها، Docker را برای توزیع لینوکسی خود طبق + [راهنمای نصب Docker Engine](https://docs.docker.com/engine/install/#server) نصب کنید. + +2. طبق بخش «نصب» در مستندات، [`cri-dockerd`](https://mirantis.github.io/cri-dockerd/usage/install) را نصب کنید. + +به‌طور پیش‌فرض، سوکت CRI برای `cri-dockerd` مسیر `/run/cri-dockerd.sock` است. + +### Mirantis Container Runtime {#mcr} + +[Mirantis Container Runtime](https://docs.mirantis.com/mcr/20.10/overview.html) (MCR) یک محیط اجرای کانتینر تجاری است که پیش‌تر با نام Docker Enterprise Edition شناخته می‌شد. + +می‌توانید Mirantis Container Runtime را با استفاده از مؤلفۀ متن‌باز +[`cri-dockerd`](https://mirantis.github.io/cri-dockerd/) ــ که همراه با MCR عرضه می‌شود ــ در Kubernetes به کار بگیرید. + +برای آگاهی بیش‌تر از نحوه نصب Mirantis Container Runtime، +به راهنمای [MCR Deployment Guide](https://docs.mirantis.com/mcr/20.10/install.html) مراجعه کنید. + +واحد systemd با نام `cri-docker.socket` را بررسی کنید تا مسیر سوکت CRI را بیابید. + +#### نادیده گرفتن sandbox (pause) image {#override-pause-image-cri-dockerd-mcr} + +آداپتور `cri-dockerd` یک آرگومان خط فرمان می‌پذیرد تا مشخص کند کدام تصویر کانتینر باید به‌عنوان کانتینر زیرساخت پاد («pause image») استفاده شود. +آرگومان خط فرمان مورد نیاز `--pod-infra-container-image` است. + +## {{% heading "whatsnext" %}} + +علاوه بر یک محیط اجرای کانتینر، خوشۀ شما به یک +[افزونه شبکه](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-network-model) +سالم و فعال نیز نیاز دارد. diff --git a/content/fa/docs/setup/production-environment/tools/_index.md b/content/fa/docs/setup/production-environment/tools/_index.md new file mode 100644 index 0000000000000..c8129684ade8e --- /dev/null +++ b/content/fa/docs/setup/production-environment/tools/_index.md @@ -0,0 +1,21 @@ +--- +title: نصب کوبرنتیز با ابزارهای استقرار +weight: 30 +no_list: true +--- + +روش‌ها و ابزارهای گوناگونی برای راه‌اندازی یک خوشۀ کوبرنتیز در سطح تولید وجود دارد؛ برای نمونه: + +- [kubeadm](/docs/setup/production-environment/tools/kubeadm/) + +- [Cluster API](https://cluster-api.sigs.k8s.io/): زیرپروژه‌ای از کوبرنتیز که بر ارائه APIهای اعلانی و ابزارهایی متمرکز است تا روند فراهم‌سازی، ارتقا و عملیات روی چندین خوشۀ کوبرنتیز را ساده کند. + +- [kops](https://kops.sigs.k8s.io/): ابزاری خودکار برای فراهم‌سازی خوشه. برای آموزش‌ها، بهترین شیوه‌ها، گزینه‌های پیکربندی و راه‌های ارتباط با جامعه کاربران، به + [وب‌سایت ‌kOps](https://kops.sigs.k8s.io/) مراجعه کنید. + +- [kubespray](https://kubespray.io/): + مجموعه‌ای از دفترچه‌های [Ansible](https://docs.ansible.com/)، + [inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible/inventory.md)، + ابزارهای فراهم‌سازی و دانش دامنه برای وظایف مدیریت پیکربندی سیستم‌عامل/خوشه‌های کوبرنتیز. می‌توانید در کانال اسلک + [#kubespray](https://kubernetes.slack.com/messages/kubespray/) با جامعه در ارتباط باشید. + diff --git a/content/fa/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md b/content/fa/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md new file mode 100644 index 0000000000000..375aaa0e9f172 --- /dev/null +++ b/content/fa/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md @@ -0,0 +1,222 @@ +--- +reviewers: +- xirehat +title: سفارشی‌سازی اجزا با API مربوط به kubeadm +content_type: concept +weight: 40 +--- + + + +این صفحه نحوه **سفارشی‌سازی مؤلفه‌هایی** را توضیح می‌دهد که ‌kubeadm استقرار می‌دهد. +برای مؤلفه‌های *کنترل پلِین* می‌توانید از فلگ‌ها در ساختار `ClusterConfiguration` یا از پچ‌های تک‌نودی استفاده کنید. +برای **kubelet** و **kube-proxy** نیز به ترتیب از `KubeletConfiguration` و `KubeProxyConfiguration` بهره بگیرید. + +همه این گزینه‌ها از طریق **API پیکربندی kubeadm** قابل اعمال است. +برای جزئیات بیش‌تر درباره هر فیلد در این پیکربندی‌ها می‌توانید به صفحات مرجع +[API](/docs/reference/config-api/kubeadm-config.v1beta4/) مراجعه کنید. + +{{< note >}} +در حال حاضر سفارشی‌سازی استقرار **CoreDNS** توسط kubeadm پشتیبانی نمی‌شود. +باید به صورت دستی {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}} مربوط به +`kube-system/coredns` را پچ کرده و سپس {{< glossary_tooltip text="Pods" term_id="pod" >}} +های CoreDNS را دوباره ایجاد کنید. به‌عنوان جایگزین، می‌توانید از استقرار پیش‌فرض CoreDNS صرف‌نظر کرده و +نسخه دلخواه خود را پیاده کنید. برای جزئیات بیش‌تر، به بخش +[استفاده از فازهای init در kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm-init/#init-phases) مراجعه کنید. +{{< /note >}} + +{{< note >}} +برای **پیکربندی مجدد** یک خوشه‌ای که پیش‌تر ایجاد شده، به +[Reconfiguring a kubeadm cluster](/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure) مراجعه کنید. +{{< /note >}} + + + +## سفارشی‌سازی Control Plane با پرچم‌ها در `ClusterConfiguration` + +شیٔ `ClusterConfiguration` در **kubeadm** راهی در اختیار کاربر می‌گذارد تا فلگ‌های پیش‌فرض +ارسال‌شده به مؤلفه‌های کنترل پلِین مانند *APIServer*، *ControllerManager*، *Scheduler* و *Etcd* را +بازنویسی (override) کند. این مؤلفه‌ها با ساختارهای زیر تعریف می‌شوند: + +- `apiServer` +- `controllerManager` +- `scheduler` +- `etcd` + +همۀ این ساختارها دارای فیلد مشترک `extraArgs` هستند که از جفت‌های `نام / مقدار` تشکیل می‌شود. +برای بازنویسی یک فلگ در مؤلفه کنترل پلِین: + +1. فیلد `extraArgs` مناسب را به پیکربندی خود بیفزایید. +2. فلگ‌های موردنظر را در فیلد `extraArgs` قرار دهید. +3. فرمان `kubeadm init` را با گزینه `--config ` اجرا کنید. + +{{< note >}} +می‌توانید با اجرای دستور `kubeadm config print init-defaults` و ذخیرۀ خروجی در فایلی دلخواه، +یک شیٔ `ClusterConfiguration` با مقادیر پیش‌فرض تولید کنید. +{{< /note >}} + +{{< note >}} +شیٔ `ClusterConfiguration` در حال حاضر در خوشه‌های kubeadm *سراسری* است؛ +یعنی هر فلگی که اضافه کنید برای تمام نمونه‌های همان مؤلفه روی نودهای مختلف اعمال می‌شود. +برای اعمال پیکربندی جداگانه بر مؤلفه‌های یکسان در نودهای متفاوت می‌توانید از +[وصله‌ها](#patches) استفاده کنید. +{{< /note >}} + +{{< note >}} +فلگ‌های تکراری (کلیدهای مشابه) یا ارسال چندباره یک فلگ مانند `--foo` در حال حاضر +پشتیبانی نمی‌شود. برای دور زدن این محدودیت باید از +[وصله‌ها](#patches) بهره بگیرید. +{{< /note >}} + + +### پرچم‌های APIServer + +برای جزئیات بیش‌تر، به [مستند مرجع kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) مراجعه کنید. + +نمونه استفاده: + +```yaml +apiVersion: kubeadm.k8s.io/v1beta4 +kind: ClusterConfiguration +kubernetesVersion: v1.16.0 +apiServer: + extraArgs: + - name: "enable-admission-plugins" + value: "AlwaysPullImages,DefaultStorageClass" + - name: "audit-log-path" + value: "/home/johndoe/audit.log" +``` + +### پرچم‌های ControllerManager + +برای جزئیات بیش‌تر، به [مستند مرجع kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) مراجعه کنید. + +نمونه استفاده: + +```yaml +apiVersion: kubeadm.k8s.io/v1beta4 +kind: ClusterConfiguration +kubernetesVersion: v1.16.0 +controllerManager: + extraArgs: + - name: "cluster-signing-key-file" + value: "/home/johndoe/keys/ca.key" + - name: "deployment-controller-sync-period" + value: "50" +``` + +### پرچم‌های Scheduler + +برای جزئیات بیشتر، به [مستند مرجع kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) مراجعه کنید. + +نمونه استفاده: + +```yaml +apiVersion: kubeadm.k8s.io/v1beta4 +kind: ClusterConfiguration +kubernetesVersion: v1.16.0 +scheduler: + extraArgs: + - name: "config" + value: "/etc/kubernetes/scheduler-config.yaml" + extraVolumes: + - name: schedulerconfig + hostPath: /home/johndoe/schedconfig.yaml + mountPath: /etc/kubernetes/scheduler-config.yaml + readOnly: true + pathType: "File" +``` + +### پرچم‌های Etcd + +برای جزئیات بیشتر، به [مستندات سرور etcd](https://etcd.io/docs/) مراجعه کنید. + +نمونه استفاده: + +```yaml +apiVersion: kubeadm.k8s.io/v1beta4 +kind: ClusterConfiguration +etcd: + local: + extraArgs: + - name: "election-timeout" + value: 1000 +``` + +## سفارشی‌سازی با وصله‌ها {#patches} + +{{< feature-state for_k8s_version="v1.22" state="beta" >}} + +**kubeadm** به شما اجازه می‌دهد مسیری شامل فایل‌های وصله را به `InitConfiguration` و `JoinConfiguration` +روی هر نود بدهید. این پچ‌ها می‌توانند به‌عنوان آخرین گام سفارشی‌سازی، پیش از آنکه پیکربندی مؤلفه‌ها روی دیسک نوشته شود، به کار روند. + +می‌توانید این فایل را با گزینه `--config ` به دستور `kubeadm init` بدهید: + +```yaml +apiVersion: kubeadm.k8s.io/v1beta4 +kind: InitConfiguration +patches: + directory: /home/user/somedir +``` + +{{< note >}} +برای `kubeadm init` می‌توانید فایلی ارائه کنید که هر دو بخش `ClusterConfiguration` و `InitConfiguration` را در خود داشته باشد و با `---` از هم جدا شده باشند. +{{< /note >}} + +می‌توانید این فایل را با گزینه `--config ` به `kubeadm join` بدهید: + +```yaml +apiVersion: kubeadm.k8s.io/v1beta4 +kind: JoinConfiguration +patches: + directory: /home/user/somedir +``` + +دایرکتوری باید فایل‌هایی با الگوی نام `target[suffix][+patchtype].extension` داشته باشد؛ +برای مثال: `kube-apiserver0+merge.yaml` یا به‌سادگی `etcd.json`. + +- **`target`** می‌تواند یکی از این موارد باشد: `kube-apiserver`، `kube-controller-manager`، `kube-scheduler`، `etcd` + و `kubeletconfiguration`. +- **`suffix`** یک رشته اختیاری است که می‌توان از آن برای تعیین ترتیب اعمال پچ‌ها به‌صورت الفباـعددی استفاده کرد. +- **`patchtype`** می‌تواند یکی از `strategic`، `merge` یا `json` باشد و باید با قالب‌های پچی که + [kubectl پشتیبانی می‌کند](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch) + سازگار باشد. مقدار پیش‌فرض `strategic` است. +- **`extension`** باید `json` یا `yaml` باشد. + +{{< note >}} +اگر برای ارتقای نودهای kubeadm از `kubeadm upgrade` استفاده می‌کنید، باید دوباره همان پچ‌ها را +ارائه دهید تا سفارشی‌سازی‌ها پس از ارتقا حفظ شوند. برای این کار می‌توانید از فلگ `--patches` +استفاده کنید که باید به همان دایرکتوری اشاره کند. در حال حاضر `kubeadm upgrade` ساختار API +پیکربندی جداگانه‌ای برای این منظور ندارد. +{{< /note >}} + +## سفارشی سازی kubelet {#kubelet} + +برای سفارشی‌سازی **kubelet** می‌توانید یک [`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/) +را در همان فایل پیکربندی، کنار `ClusterConfiguration` یا `InitConfiguration` و جدا شده با `---` قرار دهید. +سپس این فایل را به `kubeadm init` بدهید؛ kubeadm همان پیکربندی پایه `KubeletConfiguration` +را روی تمام نودهای خوشه اعمال می‌کند. + +برای اعمال پیکربندی ویژه هر نود بر روی `KubeletConfiguration` پایه می‌توانید از +هدف پچ [`kubeletconfiguration`](#patches) استفاده کنید. + +روش دیگر این است که فلگ‌های kubelet را به‌عنوان جایگزین در فیلد +`nodeRegistration.kubeletExtraArgs` (که هم در `InitConfiguration` و هم در `JoinConfiguration` پشتیبانی می‌شود) قرار دهید. +برخی فلگ‌های kubelet منسوخ شده‌اند؛ بنابراین قبل از استفاده، وضعیت آن‌ها را در +[مستند مرجع kubelet](/docs/reference/command-line-tools-reference/kubelet) بررسی کنید. + +برای جزئیات بیشتر به +[پیکربندی هر kubelet در خوشه با استفاده از kubeadm](/docs/setup/production-environment/tools/kubeadm/kubelet-integration) +مراجعه کنید. + +## سفارشی سازی kube-proxy + +برای سفارشی‌سازی **kube-proxy** می‌توانید یک `KubeProxyConfiguration` را کنار `ClusterConfiguration` +یا `InitConfiguration` (جداشده با `---`) در دستور `kubeadm init` بگنجانید. + +برای جزئیات بیشتر به صفحات مرجع [API](/docs/reference/config-api/kubeadm-config.v1beta4/) مراجعه کنید. + +{{< note >}} +kubeadm، ‌kube-proxy را به‌صورت یک {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}} مستقر می‌کند؛ +بنابراین `KubeProxyConfiguration` روی تمام نمونه‌های kube-proxy در خوشه اعمال خواهد شد. +{{< /note >}} diff --git a/content/fa/docs/setup/production-environment/turnkey-solutions.md b/content/fa/docs/setup/production-environment/turnkey-solutions.md new file mode 100644 index 0000000000000..5c5811f622f93 --- /dev/null +++ b/content/fa/docs/setup/production-environment/turnkey-solutions.md @@ -0,0 +1,12 @@ +--- +title: راهکارهای ابری آماده به کار +content_type: concept +weight: 40 +--- + + +این صفحه فهرستی از ارائه‌دهندگان راه‌حل‌های دارای گواهینامه کوبرنتیز را ارائه می‌دهد. از صفحه هر ارائه‌دهنده، می‌توانید نحوه نصب و راه‌اندازی خوشه‌های آماده برای عملیات را بیاموزید. + + + +{{< cncf-landscape helpers=true category="platform--certified-kubernetes-hosted" >}} diff --git a/content/fa/docs/tasks/_index.md b/content/fa/docs/tasks/_index.md new file mode 100644 index 0000000000000..e679926d250c0 --- /dev/null +++ b/content/fa/docs/tasks/_index.md @@ -0,0 +1,14 @@ +--- +title: کارها +main_menu: true +weight: 50 +content_type: concept +--- + + + +این بخش از مستندات کوبرنتیز شامل صفحاتی است که نحوه انجام کارهای منفرد را نشان می‌دهند. یک صفحه کار (Task) توضیح می‌دهد چگونه یک کار واحد را انجام دهید، معمولاً با ارائه یک توالی کوتاه از مراحل همراه است. + +اگر می‌خواهید یک صفحه کار(Task) بنویسید، به +[ایجاد یک درخواست ادغام برای مستندات](/docs/contribute/new-content/open-a-pr/) مراجعه کنید. + diff --git a/content/fa/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/fa/docs/tasks/access-application-cluster/web-ui-dashboard.md new file mode 100644 index 0000000000000..673c3a1bdfd06 --- /dev/null +++ b/content/fa/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -0,0 +1,235 @@ +--- +reviewers: +- xirehat +title: استقرار و دسترسی به داشبورد کوبرنتیز +description: >- + رابط کاربری وب (داشبورد کوبرنتیز) را مستقر کرده و به آن دسترسی پیدا کنید. +content_type: concept +weight: 10 +card: + name: tasks + weight: 30 + title: از داشبورد رابط کاربری وب استفاده کنید +--- + + + +Dashboard یک رابط کاربری وب‌محور برای کوبرنتیز است. +شما می‌توانید از Dashboard برای استقرار برنامه‌های کانتینری‌شده در یک خوشه کوبرنتیز، +عیب‌یابی برنامه کانتینری‌شده خود و مدیریت منابع خوشه استفاده کنید. +همچنین می‌توانید با استفاده از Dashboard نمای کلی از برنامه‌های در حال اجرا در خوشه‌تان به‌دست آورید +و منابع جداگانه کوبرنتیز (مانند Deploymentها، Jobها، DaemonSetها و غیره) را ایجاد یا ویرایش کنید. +به‌عنوان مثال، می‌توانید یک Deployment را مقیاس دهید، به‌روزرسانی مرحله‌ای (rolling update) را آغاز کنید، یک پاد را راه‌اندازی مجدد کنید +یا با استفاده از راهنمای استقرار (deploy wizard) برنامه‌های جدید را مستقر نمایید. + +Dashboard همچنین اطلاعاتی درباره وضعیت منابع کوبرنتیز در خوشه شما و هرگونه خطایی که ممکن است رخ داده باشد ارائه می‌دهد. + +![رابط کاربری داشبورد کوبرنتیز](/images/docs/ui-dashboard.png) + + + +## استقرار رابط کاربری Dashboard + +{{< note >}} +در حال حاضر نصب Dashboard تنها با استفاده از Helm پشتیبانی می‌شود زیرا سریع‌تر است +و کنترل بهتری بر تمام وابستگی‌های مورد نیاز Dashboard برای اجرا به ما می‌دهد. +{{< /note >}} + +رابط کاربری Dashboard به‌صورت پیش‌فرض مستقر نیست. برای استقرار آن، فرمان زیر را اجرا کنید: + +```shell +# مخزن kubernetes-dashboard را اضافه کنید +helm repo add kubernetes-dashboard https://kubernetes.github.io/dashboard/ +# با استفاده از نمودار kubernetes-dashboard، یک نسخه Helm با نام "kubernetes-dashboard" مستقر کنید. +helm upgrade --install kubernetes-dashboard kubernetes-dashboard/kubernetes-dashboard --create-namespace --namespace kubernetes-dashboard +``` + +## دسترسی به رابط کاربری Dashboard + +برای محافظت از داده‌های خوشه، Dashboard به‌طور پیش‌فرض با یک پیکربندی حداقلی RBAC مستقر می‌شود. +در حال حاضر، Dashboard تنها ورود با توکن Bearer را پشتیبانی می‌کند. +برای ایجاد یک توکن برای این نمایش، می‌توانید راهنمای ما در +[ایجاد یک کاربر نمونه](https://github.com/kubernetes/dashboard/blob/master/docs/user/access-control/creating-sample-user.md) +را دنبال کنید. + +{{< warning >}} +کاربر نمونه‌ی ایجادشده در این آموزش دارای دسترسی‌های مدیریتی است و تنها برای مقاصد آموزشی می‌باشد. +{{< /warning >}} + +### پراکسی خط فرمان + +می‌توانید دسترسی به Dashboard را با استفاده از ابزار خط فرمان `kubectl` و اجرای فرمان زیر فعال کنید: + +``` +kubectl -n kubernetes-dashboard port-forward svc/kubernetes-dashboard-kong-proxy 8443:443 +``` + +Kubectl داشبورد را در آدرس [https://localhost:8443](https://localhost:8443) در دسترس قرار می‌دهد. + +این رابط کاربری _فقط_ از ماشینی که فرمان روی آن اجرا شده قابل دسترسی است. برای گزینه‌های بیشتر به `kubectl port-forward --help` مراجعه کنید. + +{{< note >}} +روش احراز هویت kubeconfig از ارائه‌دهنده‌های هویت خارجی یا احراز هویت مبتنی بر گواهی X.509 **پشتیبانی نمی‌کند**. +{{< /note >}} + +## نمای خوش‌آمدگویی + +وقتی به Dashboard روی یک خوشه خالی دسترسی پیدا می‌کنید، صفحه خوش‌آمدگویی را می‌بینید. +این صفحه شامل لینک این سند و همچنین دکمه‌ای برای استقرار اولین برنامه شما است. +علاوه بر این، می‌توانید ببینید که چه برنامه‌های سیستمی به‌صورت پیش‌فرض در [namespace](/docs/tasks/administer-cluster/namespaces/) `kube-system` خوشه شما در حال اجرا هستند، برای مثال خود Dashboard. + +![صفحه خوش‌آمدگویی Kubernetes Dashboard](/images/docs/ui-dashboard-zerostate.png) + +## استقرار برنامه‌های کانتینری‌شده + +Dashboard به شما امکان می‌دهد با استفاده از یک راهنمای ساده، یک برنامه‌ی کانتینری‌شده را به‌صورت یک Deployment و سرویس اختیاری (Service) ایجاد و مستقر کنید. +می‌توانید جزئیات برنامه را به‌صورت دستی وارد کنید یا یک فایل _مانیفست_ YAML یا JSON حاوی پیکربندی برنامه را بارگذاری نمایید. + +برای شروع، روی دکمه‌ی **CREATE** در گوشه‌ی بالای سمت راست هر صفحه کلیک کنید. + +### مشخص‌کردن جزئیات برنامه + +راهنمای استقرار انتظار دارد اطلاعات زیر را ارائه دهید: + +- **نام برنامه** (اجباری): نام برنامه‌ی شما. + یک [برچسب](/docs/concepts/overview/working-with-objects/labels/) با این نام به Deployment و Service (در صورت وجود) افزوده خواهد شد. + + نام برنامه در [namespace](/docs/tasks/administer-cluster/namespaces/) انتخاب‌شده باید یکتا باشد. + باید با یک حرف کوچک شروع شود، با یک حرف کوچک یا عدد پایان یابد، و تنها شامل حروف کوچک، اعداد و خط تیره (-) باشد. حداکثر طول آن ۲۴ کاراکتر است. + فاصله‌های قبل و بعد نادیده گرفته می‌شوند. + +- **ایمیج کانتینر** (اجباری): + URL یک [ایمیج کانتینر](/docs/concepts/containers/images/) عمومی در هر رجیستری یا یک ایمیج خصوصی (معمولاً در Google Container Registry یا Docker Hub)؛ + مشخصه‌ی ایمیج باید با یک دونقطه (:) پایان یابد. + +- **تعداد پادها** (اجباری): + تعداد هدف از پادها که می‌خواهید برنامه‌ی شما در آن استقرار یابد. مقدار باید یک عدد صحیح مثبت باشد. + + یک [Deployment](/docs/concepts/workloads/controllers/deployment/) ایجاد می‌شود تا تعداد دلخواه پادها را در سراسر خوشه حفظ کند. + +- **Service** (اختیاری): + برای برخی قسمت‌های برنامه (مثلاً فرانت‌اند) ممکن است بخواهید یک [Service](/docs/concepts/services-networking/service/) را در یک آدرس IP خارجی (شاید عمومی) خارج از خوشه در دسترس قرار دهید (Service خارجی). + + {{< note >}} + برای Serviceهای خارجی، ممکن است نیاز باشد یک یا چند پورت را باز کنید. + {{< /note >}} + + سایر Serviceها که تنها از داخل خوشه قابل مشاهده‌اند، Service داخلی نامیده می‌شوند. + + صرف‌نظر از نوع Service، اگر تصمیم به ایجاد Service گرفتید و کانتینر شما روی پورتی (ورودی) گوش می‌دهد، باید دو پورت را مشخص کنید. + Service ایجادشده پورت ورودی را به پورت هدف درون کانتینر نگاشت می‌کند و به پادهای مستقرشده‌ی شما مسیر می‌دهد. پروتکل‌های پشتیبانی‌شده TCP و UDP هستند. + نام DNS داخلی این Service همان مقداری خواهد بود که در بخش نام برنامه مشخص کردید. + +اگر لازم باشد، می‌توانید بخش **گزینه‌های پیشرفته** را باز کنید تا تنظیمات بیشتری را مشخص کنید: + +- **توضیحات**: متنی که اینجا وارد می‌کنید به‌عنوان یک + [annotation](/docs/concepts/overview/working-with-objects/annotations/) + به Deployment افزوده می‌شود و در جزئیات برنامه نمایش داده می‌شود. + +- **برچسب‌ها**: برچسب‌های پیش‌فرض برای برنامه شامل نام برنامه و نسخه است. + می‌توانید برچسب‌های اضافی مانند release، environment، tier، partition و release track را + برای Deployment، Service (در صورت وجود) و Pods مشخص کنید. + +مثال: + + ```conf + release=1.0 + tier=frontend + environment=pod + track=stable + ``` + +- **Namespace**: کوبرنتیز از چندین خوشه مجازی که توسط یک خوشه فیزیکی پشتیبانی می‌شوند، پشتیبانی می‌کند. این خوشه‌های مجازی را [namespace](/docs/tasks/administer-cluster/namespaces/) می‌نامند. آن‌ها به شما اجازه می‌دهند منابع را به گروه‌های منطقی نام‌گذاری‌شده تقسیم کنید. + + داشبورد همه namespaceهای موجود را در یک فهرست کشویی نمایش می‌دهد و امکان ایجاد namespace جدید را فراهم می‌کند. نام namespace می‌تواند حداکثر ۶۳ کاراکتر الفانومریک و خط تیره (-) داشته باشد و نباید شامل حروف بزرگ باشد. نام‌های namespace نباید فقط از اعداد تشکیل شوند. اگر نام به‌صورت عددی مانند `10` تنظیم شود، پاد در namespace پیش‌فرض قرار می‌گیرد. + + در صورت موفقیت‌آمیز بودن ایجاد namespace، به‌صورت پیش‌فرض انتخاب می‌شود. اگر ایجاد شکست بخورد، اولین namespace از فهرست انتخاب خواهد شد. + +- **Image Pull Secret**: + اگر ایمیج داکر مشخص‌شده خصوصی باشد، ممکن است به اعتبارات [pull secret](/docs/concepts/configuration/secret/) نیاز داشته باشد. + + داشبورد همه Secretهای موجود را در یک فهرست کشویی نمایش می‌دهد و امکان ایجاد یک Secret جدید را فراهم می‌کند. نام Secret باید از قواعد نام دامنه DNS پیروی کند، برای مثال `new.image-pull.secret`. محتوای Secret باید با base64 رمزگذاری شده و در فایل [`.dockercfg`](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) مشخص شود. نام Secret می‌تواند حداکثر ۲۵۳ کاراکتر باشد. + + در صورت موفقیت‌آمیز بودن ایجاد pull secret، به‌صورت پیش‌فرض انتخاب می‌شود. اگر ایجاد شکست بخورد، هیچ Secretای اعمال نمی‌شود. + +- **محدودیت CPU (هسته‌ها)** و **محدودیت حافظه (MiB)**: + می‌توانید حداقل [محدودیت منابع](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) برای کانتینر را مشخص کنید. به‌طور پیش‌فرض، پادها با محدودیت نامحدود CPU و حافظه اجرا می‌شوند. + +- **دستور اجرا** و **آرگومان‌های دستور اجرا**: + به‌طور پیش‌فرض، کانتینرها دستور نقطه ورود ([entrypoint command](/docs/tasks/inject-data-application/define-command-argument-container/)) پیش‌فرض ایمیج داکر را اجرا می‌کنند. می‌توانید با استفاده از گزینه‌ها و آرگومان‌های دستور، مقدار پیش‌فرض را بازنویسی کنید. + +- **اجرای با امتیازات ویژه (privileged)**: + این تنظیم مشخص می‌کند آیا فرایندهای داخل [کانتینرهای privileged](/docs/concepts/workloads/pods/#privileged-mode-for-containers) معادل فرایندهای در حال اجرا با کاربر root در میزبان هستند یا خیر. کانتینرهای privileged می‌توانند از قابلیت‌هایی مانند دستکاری پشته شبکه و دسترسی به دستگاه‌ها استفاده کنند. + +- **متغیرهای محیطی**: + کوبرنتیز سرویس‌ها را از طریق [متغیرهای محیطی](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/) در دسترس قرار می‌دهد. می‌توانید متغیرهای محیطی را تعریف کنید یا با استفاده از مقادیر آن‌ها آرگومان‌هایی به دستورات خود ارسال نمایید. این متغیرها می‌توانند در برنامه‌ها برای یافتن یک سرویس استفاده شوند. مقادیر می‌توانند با نحو `$(VAR_NAME)` به متغیرهای دیگر ارجاع دهند. + +### بارگذاری یک فایل YAML یا JSON + +Kubernetes از پیکربندی بیانی (declarative configuration) پشتیبانی می‌کند. +در این روش، تمام پیکربندی‌ها در فایل‌های مانیفست (YAML یا JSON) ذخیره می‌شوند. +این مانیفست‌ها از اسکیماهای منابع [API](/docs/concepts/overview/kubernetes-api/) کوبرنتیز استفاده می‌کنند. + +به‌جای مشخص کردن جزئیات برنامه در راهنمای استقرار، +می‌توانید برنامه‌ی خود را در یک یا چند مانیفست تعریف کرده و فایل‌ها را با استفاده از Dashboard بارگذاری کنید. + +## استفاده از Dashboard + +بخش‌های زیر نماهای رابط کاربری Dashboard را توضیح می‌دهند؛ اینکه چه ارائه می‌دهند و چگونه می‌توان از آن‌ها استفاده کرد. + +### ناوبری + +وقتی اشیاء کوبرنتیز در خوشه تعریف شده باشند، Dashboard آن‌ها را در نمای اولیه نمایش می‌دهد. +به‌طور پیش‌فرض تنها اشیاء از namespace _default_ نشان داده می‌شوند و +این حالت را می‌توان با استفاده از انتخاب‌کننده‌ی namespace در منوی ناوبری تغییر داد. + +Dashboard اکثر انواع اشیاء کوبرنتیز را نمایش می‌دهد و آن‌ها را در چند دسته‌بندی منو گروه‌بندی می‌کند. + +#### مرور کلی برای مدیران + +برای مدیران خوشه و namespace، داشبورد فهرستی از Nodeها، Namespaceها و PersistentVolumeها را نمایش می‌دهد و نماهای جزئیات برای هر کدام دارد. +نمای فهرست Node شامل معیارهای مصرف CPU و حافظه است که در همه‌ی Nodeها تجمیع شده‌اند. +نمای جزئیات متریک‌های یک Node، مشخصات آن، وضعیت، منابع تخصیص‌یافته، رویدادها و پادهای در حال اجرا روی آن را نمایش می‌دهد. + +#### Workloads + +تمام برنامه‌های در حال اجرا در namespace انتخاب‌شده را نمایش می‌دهد. +این نما، برنامه‌ها را بر اساس نوع Workload (برای مثال: Deploymentها، ReplicaSetها، StatefulSetها) فهرست می‌کند. +هر نوع Workload را می‌توان به‌صورت جداگانه مشاهده کرد. +فهرست‌ها اطلاعات قابل اقدام درباره‌ی Workloadها را خلاصه می‌کنند، +مانند تعداد پادهای آماده برای یک ReplicaSet یا مصرف فعلی حافظه برای یک Pod. + +نماهای جزئیات Workload اطلاعات وضعیت و مشخصات را نمایش می‌دهند و +ارتباطات بین اشیاء را نشان می‌دهند. +برای مثال، پادهایی که یک ReplicaSet کنترل می‌کند یا ReplicaSetها و HorizontalPodAutoscalerهای جدید برای Deploymentها. + +#### Services + +منابع کوبرنتیز را نمایش می‌دهد که امکان در دسترس قرار دادن سرویس‌ها برای دنیای خارج و +کشف آن‌ها در داخل خوشه را فراهم می‌کنند. +به همین دلیل، نماهای Service و Ingress پادهای هدف‌گیری‌شده توسط آن‌ها، +نقاط انتهایی داخلی برای ارتباطات خوشه و نقاط انتهایی خارجی برای کاربران خارج را نمایش می‌دهند. + +#### ذخیره‌سازی + +نمای Storage منابع PersistentVolumeClaim را نمایش می‌دهد که برنامه‌ها برای ذخیره‌سازی داده از آن‌ها استفاده می‌کنند. + +#### ConfigMaps و Secrets {#config-maps-and-secrets} + +تمام منابع کوبرنتیز که برای پیکربندی زنده‌ی برنامه‌های در حال اجرا در خوشه‌ها استفاده می‌شوند را نمایش می‌دهد. +این نما امکان ویرایش و مدیریت اشیاء پیکربندی را فراهم می‌کند و Secrets را که به‌طور پیش‌فرض مخفی هستند، نمایش می‌دهد. + +#### نمایشگر لاگ‌ها + +فهرست پادها و صفحات جزئیات لینک به نمایشگر لاگ تعبیه‌شده در Dashboard دارند. +این نمایشگر امکان بررسی عمیق لاگ‌های کانتینرهای متعلق به یک پاد را فراهم می‌کند. + +![نمایشگر لاگ‌ها](/images/docs/ui-dashboard-logs-view.png) + +## {{% heading "whatsnext" %}} + +برای اطلاعات بیشتر، به +[صفحه‌ی پروژه‌ی Kubernetes Dashboard](https://github.com/kubernetes/dashboard) +مراجعه کنید. + + diff --git a/content/fa/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/fa/docs/tasks/configure-pod-container/configure-pod-configmap.md new file mode 100644 index 0000000000000..6314ebb50a6b5 --- /dev/null +++ b/content/fa/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -0,0 +1,872 @@ +--- +title: پیکربندی یک Pod برای استفاده از ConfigMap +content_type: task +weight: 190 +card: + name: tasks + weight: 50 +--- + + +بسیاری از برنامه‌ها به پیکربندی‌ای متکی هستند که در زمان اولیه‌سازی یا زمان اجرا استفاده می‌شود. +اغلب نیاز است مقادیر تخصیص‌یافته به پارامترهای پیکربندی را تنظیم کنید. +ConfigMapها مکانیزمی در کوبرنتیز هستند که به شما اجازه می‌دهند داده‌های پیکربندی را به +{{< glossary_tooltip text="پادها" term_id="pod" >}} برنامه تزریق کنید. + +مفهوم ConfigMap به شما امکان می‌دهد مصنوعات پیکربندی را از محتوای ایمیج جدا نگه دارید تا +برنامه‌های کانتینری‌شده قابل حمل باقی بمانند. برای مثال، می‌توانید یک +{{< glossary_tooltip text="ایمیج کانتینر" term_id="image" >}} یکسان را برای راه‌اندازی کانتینرها +برای اهداف توسعه محلی، تست سیستم یا اجرای بارکاری زنده کاربران نهایی دانلود و اجرا کنید. + +این صفحه مجموعه‌ای از مثال‌های کاربردی را ارائه می‌دهد که نشان می‌دهد چگونه ConfigMap ایجاد کنید +و پادها را با استفاده از داده‌های ذخیره‌شده در ConfigMap پیکربندی نمایید. + +## {{% heading "پیش‌نیازها" %}} + +{{< include "task-tutorial-prereqs.md" >}} + +شما باید ابزار `wget` را نصب داشته باشید. اگر ابزاری مانند `curl` دارید و `wget` نصب نیست، +باید مرحله‌ای را که داده‌های نمونه را دانلود می‌کند مطابق ابزار خود تنظیم کنید. + + + +## ایجاد یک ConfigMap + +می‌توانید از `kubectl create configmap` یا از مولد ConfigMap در `kustomization.yaml` برای ایجاد یک ConfigMap استفاده کنید. + +### ایجاد ConfigMap با استفاده از `kubectl create configmap` + +برای ایجاد ConfigMapها از +[دایرکتوری‌ها](#create-configmaps-from-directories)، +[فایل‌ها](#create-configmaps-from-files) +یا [مقادیر متنی](#create-configmaps-from-literal-values) +از فرمان `kubectl create configmap` استفاده کنید: + +```shell +kubectl create configmap +``` + +که در آن \ نامی است که می‌خواهید به ConfigMap اختصاص دهید و \ دایرکتوری، فایل یا مقدار متنی است که داده‌ها از آن استخراج می‌شوند. +نام یک شیء ConfigMap باید یک +[نام زیردامنه DNS معتبر](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) +باشد. + +وقتی ConfigMap را بر اساس یک فایل ایجاد می‌کنید، کلید در `` به‌طور پیش‌فرض نام پایه‌ی فایل خواهد بود و مقدار به‌طور پیش‌فرض محتوای فایل است. + +می‌توانید از [`kubectl describe`](/docs/reference/generated/kubectl/kubectl-commands/#describe) یا +[`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get) +برای دریافت اطلاعات درباره‌ی یک ConfigMap استفاده کنید. + +#### ایجاد ConfigMap از یک دایرکتوری {#create-configmaps-from-directories} + +می‌توانید از `kubectl create configmap` برای ایجاد ConfigMap از چندین فایل در یک دایرکتوری استفاده کنید. +وقتی ConfigMap را بر اساس یک دایرکتوری ایجاد می‌کنید، kubectl فایل‌هایی را که نام آن‌ها کلید معتبری است شناسایی می‌کند و هر یک از آن فایل‌ها را در ConfigMap جدید قرار می‌دهد. +هر ورودی دایرکتوری به جز فایل‌های معمولی نادیده گرفته می‌شود (برای مثال: زیرشاخه‌ها، لینک‌های نمادین، دستگاه‌ها، پایپ‌ها و غیره). + +{{< note >}} +نام هر فایلی که برای ایجاد ConfigMap استفاده می‌شود باید تنها شامل کاراکترهای مجاز باشد، که عبارت‌اند از: حروف (`A` تا `Z` و `a` تا `z`)، ارقام (`0` تا `9`)، `-`، `_` یا `.`. +اگر از `kubectl create configmap` با دایرکتوری‌ای استفاده کنید که نام هر یک از فایل‌هایش شامل کاراکتر نامجاز باشد، ممکن است فرمان `kubectl` با خطا مواجه شود. + +فرمان `kubectl` هنگام برخورد با نام فایل نامعتبر، خطایی چاپ نمی‌کند. +{{< /note >}} + +دایرکتوری محلی را ایجاد کنید: + +```shell +mkdir -p configure-pod-container/configmap/ +``` + +اکنون، پیکربندی نمونه را دانلود کنید و ConfigMap را ایجاد کنید: + +```shell +# فایل‌های نمونه را در دایرکتوری `configure-pod-container/configmap/` دانلود کنید. +wget https://kubernetes.io/examples/configmap/game.properties -O configure-pod-container/configmap/game.properties +wget https://kubernetes.io/examples/configmap/ui.properties -O configure-pod-container/configmap/ui.properties + +# ایجاد ConfigMap +kubectl create configmap game-config --from-file=configure-pod-container/configmap/ +``` + +فرمان فوق هر فایل را، در این مثال `game.properties` و `ui.properties`، +در دایرکتوری `configure-pod-container/configmap/` در ConfigMap با نام game-config بسته‌بندی می‌کند. +می‌توانید جزئیات ConfigMap را با استفاده از فرمان زیر نمایش دهید: + +```shell +kubectl describe configmaps game-config +``` + +خروجی مشابه این است: +``` +Name: game-config +Namespace: default +Labels: +Annotations: + +Data +==== +game.properties: +---- +enemies=aliens +lives=3 +enemies.cheat=true +enemies.cheat.level=noGoodRotten +secret.code.passphrase=UUDDLRLRBABAS +secret.code.allowed=true +secret.code.lives=30 +ui.properties: +---- +color.good=purple +color.bad=yellow +allow.textmode=true +how.nice.to.look=fairlyNice +``` + +فایل‌های `game.properties` و `ui.properties` در دایرکتوری `configure-pod-container/configmap/` در بخش `data` از ConfigMap نمایش داده می‌شوند. + +```shell +kubectl get configmaps game-config -o yaml +``` +خروجی مشابه این است: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + creationTimestamp: 2022-02-18T18:52:05Z + name: game-config + namespace: default + resourceVersion: "516" + uid: b4952dc3-d670-11e5-8cd0-68f728db1985 +data: + game.properties: | + enemies=aliens + lives=3 + enemies.cheat=true + enemies.cheat.level=noGoodRotten + secret.code.passphrase=UUDDLRLRBABAS + secret.code.allowed=true + secret.code.lives=30 + ui.properties: | + color.good=purple + color.bad=yellow + allow.textmode=true + how.nice.to.look=fairlyNice +``` + +#### ایجاد ConfigMaps از فایل‌ها + +شما می‌توانید از `kubectl create configmap` برای ایجاد یک ConfigMap از یک فایل منفرد یا از چندین فایل استفاده کنید. + +به عنوان مثال، + +```shell +kubectl create configmap game-config-2 --from-file=configure-pod-container/configmap/game.properties +``` + +ConfigMap زیر را تولید می‌کند: + +```shell +kubectl describe configmaps game-config-2 +``` + +که خروجی آن مشابه این است: + +``` +Name: game-config-2 +Namespace: default +Labels: +Annotations: + +Data +==== +game.properties: +---- +enemies=aliens +lives=3 +enemies.cheat=true +enemies.cheat.level=noGoodRotten +secret.code.passphrase=UUDDLRLRBABAS +secret.code.allowed=true +secret.code.lives=30 +``` + +شما می‌توانید چندین بار آرگومان `--from-file` را برای ایجاد یک ConfigMap از چندین منبع داده ارسال کنید. + +```shell +kubectl create configmap game-config-2 --from-file=configure-pod-container/configmap/game.properties --from-file=configure-pod-container/configmap/ui.properties +``` + +شما می‌توانید جزئیات ConfigMap مربوط به `game-config-2` را با استفاده از دستور زیر نمایش دهید: + +```shell +kubectl describe configmaps game-config-2 +``` + +خروجی مشابه این است: + +``` +Name: game-config-2 +Namespace: default +Labels: +Annotations: + +Data +==== +game.properties: +---- +enemies=aliens +lives=3 +enemies.cheat=true +enemies.cheat.level=noGoodRotten +secret.code.passphrase=UUDDLRLRBABAS +secret.code.allowed=true +secret.code.lives=30 +ui.properties: +---- +color.good=purple +color.bad=yellow +allow.textmode=true +how.nice.to.look=fairlyNice +``` + +برای ایجاد یک ConfigMap از یک فایل env، از گزینه `--from-env-file` استفاده کنید، برای مثال: + +```shell +# Env-files contain a list of environment variables. +# These syntax rules apply: +# Each line in an env file has to be in VAR=VAL format. +# Lines beginning with # (i.e. comments) are ignored. +# Blank lines are ignored. +# There is no special handling of quotation marks (i.e. they will be part of the ConfigMap value)). + +# Download the sample files into `configure-pod-container/configmap/` directory +wget https://kubernetes.io/examples/configmap/game-env-file.properties -O configure-pod-container/configmap/game-env-file.properties +wget https://kubernetes.io/examples/configmap/ui-env-file.properties -O configure-pod-container/configmap/ui-env-file.properties + +# The env-file `game-env-file.properties` looks like below +cat configure-pod-container/configmap/game-env-file.properties +enemies=aliens +lives=3 +allowed="true" + +# This comment and the empty line above it are ignored +``` + +```shell +kubectl create configmap game-config-env-file \ + --from-env-file=configure-pod-container/configmap/game-env-file.properties +``` + +یک ConfigMap تولید می‌کند. مشاهده‌ی ConfigMap: + +```shell +kubectl get configmap game-config-env-file -o yaml +``` + +the output is similar to: +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + creationTimestamp: 2019-12-27T18:36:28Z + name: game-config-env-file + namespace: default + resourceVersion: "809965" + uid: d9d1ca5b-eb34-11e7-887b-42010a8002b8 +data: + allowed: '"true"' + enemies: aliens + lives: "3" +``` + +با شروع از Kubernetes نسخه 1.23 `kubectl` از آرگومان `--from-env-file` پشتیبانی می‌کند که باید چندین بار برای ایجاد یک ConfigMap از چندین منبع داده مشخص شود. + +```shell +kubectl create configmap config-multi-env-files \ + --from-env-file=configure-pod-container/configmap/game-env-file.properties \ + --from-env-file=configure-pod-container/configmap/ui-env-file.properties +``` + +ConfigMap زیر را تولید می‌کند: + +```shell +kubectl get configmap config-multi-env-files -o yaml +``` + +که خروجی آن مشابه این است: +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + creationTimestamp: 2019-12-27T18:38:34Z + name: config-multi-env-files + namespace: default + resourceVersion: "810136" + uid: 252c4572-eb35-11e7-887b-42010a8002b8 +data: + allowed: '"true"' + color: purple + enemies: aliens + how: fairlyNice + lives: "3" + textmode: "true" +``` + +#### کلید مورد استفاده هنگام ایجاد ConfigMap از یک فایل را تعریف کنید + +شما می‌توانید هنگام استفاده از آرگومان `--from-file` در بخش `data` از ConfigMap خود، کلیدی غیر از نام فایل را تعریف کنید: + +```shell +kubectl create configmap game-config-3 --from-file== +``` + +که در آن `` کلیدی است که می‌خواهید در ConfigMap استفاده کنید و `` محل فایل منبع داده‌ای است که می‌خواهید کلید نشان دهد. + +برای مثال: + +```shell +kubectl create configmap game-config-3 --from-file=game-special-key=configure-pod-container/configmap/game.properties +``` + +ConfigMap زیر را تولید می‌کند: +``` +kubectl get configmaps game-config-3 -o yaml +``` + +که خروجی آن مشابه این است: +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + creationTimestamp: 2022-02-18T18:54:22Z + name: game-config-3 + namespace: default + resourceVersion: "530" + uid: 05f8da22-d671-11e5-8cd0-68f728db1985 +data: + game-special-key: | + enemies=aliens + lives=3 + enemies.cheat=true + enemies.cheat.level=noGoodRotten + secret.code.passphrase=UUDDLRLRBABAS + secret.code.allowed=true + secret.code.lives=30 +``` + +#### ایجاد ConfigMaps از مقادیر تحت‌اللفظی + +شما می‌توانید از دستور `kubectl create configmap` به همراه آرگومان `--from-literal` برای تعریف یک مقدار تحت‌اللفظی از خط فرمان استفاده کنید: + +```shell +kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=charm +``` + +شما می‌توانید چندین جفت کلید-مقدار ارسال کنید. هر جفتی که در خط فرمان ارائه می‌شود، به عنوان یک ورودی جداگانه در بخش `data` از ConfigMap نمایش داده می‌شود. + +```shell +kubectl get configmaps special-config -o yaml +``` + +خروجی مشابه این است: +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + creationTimestamp: 2022-02-18T19:14:38Z + name: special-config + namespace: default + resourceVersion: "651" + uid: dadce046-d673-11e5-8cd0-68f728db1985 +data: + special.how: very + special.type: charm +``` + +### ایجاد یک ConfigMap از generator + +همچنین می‌توانید یک ConfigMap از generators ایجاد کنید و سپس آن را برای ایجاد شیء در سرور API خوشه اعمال کنید. + +شما باید generators را در یک فایل `kustomization.yaml` در یک دایرکتوری مشخص کنید. + +#### تولید ConfigMap از فایل‌ها + +به عنوان مثال، برای تولید یک ConfigMap از فایل‌های `configure-pod-container/configmap/game.properties` + +```shell +# یک فایل kustomization.yaml با ConfigMapGenerator ایجاد کنید +cat <./kustomization.yaml +configMapGenerator: +- name: game-config-4 + options: + labels: + game-config: config-4 + files: + - configure-pod-container/configmap/game.properties +EOF +``` + +برای ایجاد شیء ConfigMap، دایرکتوری kustomization را اعمال کنید: + +```shell +kubectl apply -k . +``` +``` +configmap/game-config-4-m9dm2f92bt created +``` + +می‌توانید بررسی کنید که ConfigMap به این صورت ایجاد شده است: + +```shell +kubectl get configmap +``` +``` +NAME DATA AGE +game-config-4-m9dm2f92bt 1 37s +``` + +و همچنین: + +```shell +kubectl describe configmaps/game-config-4-m9dm2f92bt +``` +``` +Name: game-config-4-m9dm2f92bt +Namespace: default +Labels: game-config=config-4 +Annotations: kubectl.kubernetes.io/last-applied-configuration: + {"apiVersion":"v1","data":{"game.properties":"enemies=aliens\nlives=3\nenemies.cheat=true\nenemies.cheat.level=noGoodRotten\nsecret.code.p... + +Data +==== +game.properties: +---- +enemies=aliens +lives=3 +enemies.cheat=true +enemies.cheat.level=noGoodRotten +secret.code.passphrase=UUDDLRLRBABAS +secret.code.allowed=true +secret.code.lives=30 +Events: +``` + +توجه داشته باشید که نام ConfigMap تولیدشده با افزودن پسوندی که از هش محتوا به‌دست می‌آید تکمیل می‌شود. این کار تضمین می‌کند که هر بار که محتوا تغییر کند، یک ConfigMap جدید تولید شود. + +#### تعریف کلید برای استفاده هنگام تولید ConfigMap از یک فایل + +می‌توانید کلیدی غیر از نام فایل را برای استفاده در مولد ConfigMap تعریف کنید. +برای مثال، برای تولید ConfigMap از فایل `configure-pod-container/configmap/game.properties` +با کلید `game-special-key` + +```shell +# یک فایل kustomization.yaml با ConfigMapGenerator ایجاد کنید +cat <./kustomization.yaml +configMapGenerator: +- name: game-config-5 + options: + labels: + game-config: config-5 + files: + - game-special-key=configure-pod-container/configmap/game.properties +EOF +``` + +برای ایجاد شیء ConfigMap، دایرکتوری kustomization را اعمال کنید. +```shell +kubectl apply -k . +``` +``` +configmap/game-config-5-m67dt67794 created +``` + +#### تولید ConfigMap از مقادیر متنی + +این مثال نشان می‌دهد چگونه با استفاده از Kustomize و kubectl یک `ConfigMap` از دو جفت کلید/مقدار متنی ایجاد کنید: +`special.type=charm` و `special.how=very`. +برای این کار، می‌توانید مولد `ConfigMap` را مشخص کنید. +فایل `kustomization.yaml` را ایجاد (یا جایگزین) کنید تا محتوای زیر را داشته باشد: + +```yaml +--- +# محتویات kustomization.yaml برای ایجاد یک ConfigMap از لیترال‌ها +configMapGenerator: +- name: special-config-2 + literals: + - special.how=very + - special.type=charm +``` + +برای ایجاد شیء ConfigMap، دایرکتوری kustomization را اعمال کنید: +```shell +kubectl apply -k . +``` +``` +configmap/special-config-2-c92b5mmcf2 created +``` + +## پاکسازی موقت + +قبل از ادامه، برخی از ConfigMaps هایی که ایجاد کرده‌اید را پاک کنید: + +```bash +kubectl delete configmap special-config +kubectl delete configmap env-config +kubectl delete configmap -l 'game-config in (config-4,config-5)' +``` + +حال که یاد گرفتید چگونه ConfigMapها را تعریف کنید، می‌توانید به بخش بعدی بروید و بیاموزید چگونه از این اشیاء با Podها استفاده کنید. + +--- + +## تعریف متغیرهای محیطی کانتینر با استفاده از داده‌های ConfigMap + +### تعریف یک متغیر محیطی کانتینر با داده‌ای از یک ConfigMap واحد + +1. یک متغیر محیطی را به صورت یک جفت کلید-مقدار در یک ConfigMap تعریف کنید: + + ```shell + kubectl create configmap special-config --from-literal=special.how=very + ``` + +2. مقدار `special.how` تعریف‌شده در ConfigMap را به متغیر محیطی `SPECIAL_LEVEL_KEY` در مشخصات Pod اختصاص دهید. + + {{% code_sample file="pods/pod-single-configmap-env-variable.yaml" %}} + + Pod را ایجاد کنید: + + ```shell + kubectl create -f https://kubernetes.io/examples/pods/pod-single-configmap-env-variable.yaml + ``` + + اکنون خروجی Pod شامل متغیر محیطی `SPECIAL_LEVEL_KEY=very` است. + +### تعریف متغیرهای محیطی کانتینر با داده از چند ConfigMap + +مانند مثال قبلی، ابتدا ConfigMapها را ایجاد کنید. +در اینجا فایل مانیفستی که استفاده خواهید کرد آورده شده است: + +{{% code_sample file="configmap/configmaps.yaml" %}} + +* ConfigMap را ایجاد کنید: + + ```shell + kubectl create -f https://kubernetes.io/examples/configmap/configmaps.yaml + ``` + +* متغیرهای محیطی را در مشخصات Pod تعریف کنید. + + {{% code_sample file="pods/pod-multiple-configmap-env-variable.yaml" %}} + + Pod را ایجاد کنید: + + ```shell + kubectl create -f https://kubernetes.io/examples/pods/pod-multiple-configmap-env-variable.yaml + ``` + + اکنون خروجی Pod شامل متغیرهای محیطی `SPECIAL_LEVEL_KEY=very` و `LOG_LEVEL=INFO` است. + + وقتی آماده ادامه هستید، آن Pod و ConfigMap را حذف کنید: + ```shell + kubectl delete pod dapi-test-pod --now + kubectl delete configmap special-config + kubectl delete configmap env-config + ``` + +## پیکربندی تمام جفت‌های کلید-مقدار در یک ConfigMap به‌عنوان متغیرهای محیطی کانتینر + +* یک ConfigMap شامل چندین جفت کلید-مقدار ایجاد کنید. + + {{% code_sample file="configmap/configmap-multikeys.yaml" %}} + + ConfigMap را ایجاد کنید: + + ```shell + kubectl create -f https://kubernetes.io/examples/configmap/configmap-multikeys.yaml + ``` + +* با استفاده از `envFrom` تمام داده‌های ConfigMap را به‌عنوان متغیرهای محیطی کانتینر تعریف کنید. کلید ConfigMap به نام متغیر محیطی در Pod تبدیل می‌شود. + + {{% code_sample file="pods/pod-configmap-envFrom.yaml" %}} + + Pod را ایجاد کنید: + + ```shell + kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-envFrom.yaml + ``` + اکنون خروجی Pod شامل متغیرهای محیطی `SPECIAL_LEVEL=very` و `SPECIAL_TYPE=charm` است. + + وقتی آماده ادامه هستید، آن Pod را حذف کنید: + ```shell + kubectl delete pod dapi-test-pod --now + ``` + +## استفاده از متغیرهای محیطی تعریف‌شده در ConfigMap در دستورات Pod + +می‌توانید از متغیرهای محیطی تعریف‌شده در ConfigMap در فیلدهای `command` و `args` کانتینر با استفاده از نحو جایگزینی Kubernetes یعنی `$(VAR_NAME)` استفاده کنید. + +برای مثال، مانیفست Pod زیر: + +{{% code_sample file="pods/pod-configmap-env-var-valueFrom.yaml" %}} + +برای ایجاد آن Pod، فرمان زیر را اجرا کنید: + +```shell +kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-env-var-valueFrom.yaml +``` + +آن غلاف خروجی زیر را از کانتینر `test-container` تولید می‌کند: +```shell +kubectl logs dapi-test-pod +``` + +``` +very charm +``` + +وقتی از ادامه دادن راضی شدید، آن پاد را حذف کنید: +```shell +kubectl delete pod dapi-test-pod --now +``` + +## افزودن داده‌های ConfigMap به Volume + +همان‌طور که در [ایجاد ConfigMap از فایل‌ها](#create-configmaps-from-files) توضیح داده شد، وقتی با استفاده از `--from-file` یک ConfigMap ایجاد می‌کنید، نام فایل به‌عنوان یک کلید در بخش `data` آن ConfigMap ذخیره می‌شود. محتوای فایل تبدیل به مقدار (value) آن کلید می‌شود. + +مثال‌های این بخش به ConfigMap‌ای با نام `special-config` اشاره دارند: + +{{% code_sample file="configmap/configmap-multikeys.yaml" %}} + +ConfigMap را ایجاد کنید: + +```shell +kubectl create -f https://kubernetes.io/examples/configmap/configmap-multikeys.yaml +``` + +### پر کردن Volume با داده‌های ذخیره‌شده در یک ConfigMap + +نام ConfigMap را در بخش `volumes` مشخصات Pod اضافه کنید. +این کار داده‌های ConfigMap را به دایرکتوری تعیین‌شده در `volumeMounts.mountPath` (در این مثال، `/etc/config`) اضافه می‌کند. بخش `command` فایل‌های دایرکتوری را با نام‌هایی که با کلیدهای ConfigMap مطابقت دارند، لیست می‌کند. + +{{% code_sample file="pods/pod-configmap-volume.yaml" %}} + +Pod را ایجاد کنید: + +```shell +kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-volume.yaml +``` + +وقتی پاد اجرا می‌شود، دستور `ls /etc/config/` خروجی زیر را تولید می‌کند: + +``` +SPECIAL_LEVEL +SPECIAL_TYPE +``` + +داده‌های متنی با استفاده از رمزگذاری UTF-8 به‌عنوان فایل‌ها نمایش داده می‌شوند. برای استفاده از رمزگذاری کاراکتری دیگر، از `binaryData` استفاده کنید (برای اطلاعات بیشتر به [شیء ConfigMap](/docs/concepts/configuration/configmap/#configmap-object) مراجعه کنید). + +{{< note >}} +اگر هر فایلی در دایرکتوری `/etc/config` آن ایمیج کانتینر وجود داشته باشد، اتصال Volume باعث می‌شود آن فایل‌ها از ایمیج غیرقابل دسترس شوند. +{{< /note >}} + +وقتی آماده ادامه هستید، آن Pod را حذف کنید: +```shell +kubectl delete pod dapi-test-pod --now +``` + +### افزودن داده‌های ConfigMap به مسیر خاصی در Volume + +برای مشخص کردن مسیر فایل دلخواه برای آیتم‌های خاص ConfigMap، از فیلد `path` استفاده کنید. +در این مثال، آیتم `SPECIAL_LEVEL` در Volume با نام `config-volume` در مسیر `/etc/config/keys` مونت می‌شود. + +{{% code_sample file="pods/pod-configmap-volume-specific-key.yaml" %}} + +Pod را ایجاد کنید: + +```shell +kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-volume-specific-key.yaml +``` + +وقتی پاد اجرا می‌شود، دستور `cat /etc/config/keys` خروجی زیر را تولید می‌کند: + +``` +very +``` + +{{< caution >}} +مانند قبل، همه فایل‌های قبلی در دایرکتوری `/etc/config/` حذف خواهند شد. +{{< /caution >}} + +آن Pod را حذف کنید: +```shell +kubectl delete pod dapi-test-pod --now +``` + +### نگاشت کلیدها به مسیرهای خاص و سطح دسترسی فایل + +می‌توانید کلیدها را به مسیرهای خاص نگاشت کنید. برای نحو مناسب به بخش مربوطه در راهنمای [Secrets](/docs/tasks/inject-data-application/distribute-credentials-secure/#project-secret-keys-to-specific-file-paths) مراجعه کنید. +می‌توانید مجوزهای POSIX را برای کلیدها تنظیم کنید. برای نحو مناسب به بخش مربوطه در راهنمای [Secrets](/docs/tasks/inject-data-application/distribute-credentials-secure/#set-posix-permissions-for-secret-keys) مراجعه کنید. + +### ارجاعات اختیاری + +ارجاع به یک ConfigMap ممکن است _اختیاری_ باشد. اگر آن ConfigMap وجود نداشته باشد، حجم مونت‌شده خالی خواهد بود. اگر ConfigMap وجود داشته باشد ولی کلید مورد ارجاع وجود نداشته باشد، آن مسیر زیر نقطه مونت موجود نخواهد بود. برای جزئیات بیشتر به بخش [ConfigMap‌های اختیاری](#optional-configmaps) مراجعه کنید. + +### ConfigMapهای مونت‌شده به‌طور خودکار به‌روزرسانی می‌شوند + +وقتی یک ConfigMap مونت‌شده به‌روزرسانی می‌شود، محتوای ارائه‌شده نهایتاً به‌روز می‌شود. این موضوع در حالتی که یک ConfigMap با ارجاع اختیاری پس از شروع یک پاد موجود شود نیز صدق می‌کند. + +کیوبلیت در هر هماهنگ‌سازی دوره‌ای بررسی می‌کند که آیا ConfigMap مونت‌شده تازه است یا خیر. با این حال، برای دریافت مقدار فعلی ConfigMap از کش محلی مبتنی بر TTL خود استفاده می‌کند. در نتیجه، تأخیر کلی از لحظه‌ای که ConfigMap به‌روزرسانی می‌شود تا لحظه‌ای که کلیدهای جدید به پاد ارائه می‌شوند می‌تواند تا دوره هماهنگ‌سازی کیوبلیت (به‌طور پیش‌فرض ۱ دقیقه) + TTL کش ConfigMapها (به‌طور پیش‌فرض ۱ دقیقه) در کیوبلیت طول بکشد. شما می‌توانید با به‌روزرسانی یکی از annotationهای پاد، یک تازه‌سازی فوری را تحریک کنید. + +{{< note >}} +کانتینری که از ConfigMap به‌عنوان حجم [subPath](/docs/concepts/storage/volumes/#using-subpath) استفاده می‌کند، به‌روزرسانی‌های ConfigMap را دریافت نخواهد کرد. +{{< /note >}} + + + +## درک ConfigMapها و Podها + +منبع API نوع ConfigMap داده‌های پیکربندی را به‌صورت جفت‌های کلید-مقدار ذخیره می‌کند. این داده‌ها می‌توانند توسط Podها مصرف شوند یا پیکربندی لازم برای اجزای سیستمی مانند کنترلرها را فراهم کنند. ConfigMap شبیه به [Secrets](/docs/concepts/configuration/secret/) است، اما راهکاری برای کار با رشته‌هایی ارائه می‌دهد که حاوی اطلاعات حساس نیستند. هم کاربران و هم اجزای سیستمی می‌توانند داده‌های پیکربندی را در ConfigMap ذخیره کنند. + +{{< note >}} +ConfigMapها باید به فایل‌های properties ارجاع دهند، نه اینکه آن‌ها را جایگزین کنند. به ConfigMap به‌عنوان چیزی مشابه دایرکتوری `/etc` در لینوکس و محتوای آن فکر کنید. برای مثال، اگر از یک ConfigMap یک [Volume در Kubernetes](/docs/concepts/storage/volumes/) ایجاد کنید، هر آیتم داده در ConfigMap به‌عنوان یک فایل مجزا در Volume نمایش داده می‌شود. +{{< /note >}} + +فیلد `data` در ConfigMap شامل داده‌های پیکربندی است. همان‌طور که در مثال زیر نشان داده شده، این داده‌ها می‌توانند ساده باشند (مانند propertiesهای جداگانه تعریف‌شده با `--from-literal`) یا پیچیده (مانند فایل‌های پیکربندی یا تکه‌های JSON تعریف‌شده با `--from-file`). + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + creationTimestamp: 2016-02-18T19:14:38Z + name: example-config + namespace: default +data: + # مثالی از یک ویژگی ساده که با استفاده از --from-literal تعریف شده است + example.property.1: hello + example.property.2: world + # مثالی از یک ویژگی پیچیده که با استفاده از --from-file تعریف شده است + example.property.file: |- + property.1=value-1 + property.2=value-2 + property.3=value-3 +``` + +وقتی `kubectl` یک ConfigMap را از ورودی‌هایی که ASCII یا UTF-8 نیستند ایجاد می‌کند، این داده‌ها را در فیلد `binaryData` ConfigMap قرار می‌دهد و نه در `data`. هر دو منبع داده متنی و دودویی می‌توانند در یک ConfigMap ترکیب شوند. + +اگر می‌خواهید کلیدهای `binaryData` (و مقادیرشان) را در یک ConfigMap مشاهده کنید، می‌توانید فرمان زیر را اجرا کنید: + +`kubectl get configmap -o jsonpath='{.binaryData}' ` + + +Podها می‌توانند داده‌ها را از یک ConfigMap که از `data` یا `binaryData` استفاده می‌کند بارگذاری کنند. + +## ConfigMapهای اختیاری + +می‌توانید در مشخصات یک Pod ارجاع به ConfigMap را به‌طور _اختیاری_ علامت‌گذاری کنید. +اگر آن ConfigMap وجود نداشته باشد، پیکربندی‌ای که داده‌هایش را برای Pod فراهم می‌کند (برای مثال: متغیر محیطی یا حجم مونت‌شده) خالی خواهد بود. +اگر ConfigMap وجود داشته باشد اما کلید ارجاع‌شده وجود نداشته باشد، داده نیز خالی خواهد بود. + +برای مثال، مشخصات Pod زیر یک متغیر محیطی از ConfigMap را به‌عنوان اختیاری علامت‌گذاری می‌کند: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: dapi-test-pod +spec: + containers: + - name: test-container + image: gcr.io/google_containers/busybox + command: ["/bin/sh", "-c", "env"] + env: + - name: SPECIAL_LEVEL_KEY + valueFrom: + configMapKeyRef: + name: a-config + key: akey + optional: true # متغیر را به عنوان اختیاری علامت گذاری کنید + restartPolicy: Never +``` + +اگر این پاد را اجرا کنید و ConfigMap‌ای با نام `a-config` وجود نداشته باشد، خروجی خالی خواهد بود. +اگر این پاد را اجرا کنید و ConfigMap‌ای با نام `a-config` وجود داشته باشد اما آن ConfigMap کلیدی با نام `akey` نداشته باشد، خروجی نیز خالی خواهد بود. اگر برای `akey` در ConfigMap با نام `a-config` مقدار تعیین کنید، این پاد آن مقدار را چاپ کرده و سپس خاتمه می‌یابد. + +همچنین می‌توانید حجم‌ها و فایل‌های ارائه‌شده توسط یک ConfigMap را به‌صورت اختیاری علامت‌گذاری کنید. کوبرنتیز همیشه مسیرهای مونت را برای حجم ایجاد می‌کند، حتی اگر ConfigMap یا کلید ارجاع‌شده وجود نداشته باشد. برای مثال، مشخصات پاد زیر حجم ارجاع‌دهنده به یک ConfigMap را به‌صورت اختیاری علامت‌گذاری می‌کند: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: dapi-test-pod +spec: + containers: + - name: test-container + image: gcr.io/google_containers/busybox + command: ["/bin/sh", "-c", "ls /etc/config"] + volumeMounts: + - name: config-volume + mountPath: /etc/config + volumes: + - name: config-volume + configMap: + name: no-config + optional: true # منبع ConfigMap را به عنوان اختیاری علامت گذاری کنید + restartPolicy: Never +``` + + + +## محدودیت‌ها + +- شما باید شیء `ConfigMap` را قبل از ارجاع به آن در مشخصات یک Pod ایجاد کنید. به‌عنوان جایگزین، می‌توانید ارجاع به ConfigMap را در مشخصات Pod به‌صورت `optional` علامت‌گذاری کنید (به بخش [ConfigMap‌های اختیاری](#optional-configmaps) مراجعه کنید). اگر به یک ConfigMap که وجود ندارد ارجاع دهید و آن را `optional` علامت نزنید، Pod شروع به کار نخواهد کرد. به‌طور مشابه، ارجاعات به کلیدهایی که در ConfigMap وجود ندارند نیز مانع از راه‌اندازی Pod می‌شوند، مگر اینکه آن ارجاعات کلید را به‌صورت `optional` علامت‌گذاری کنید. + +- اگر از `envFrom` برای تعریف متغیرهای محیطی از ConfigMapها استفاده کنید، کلیدهایی که نامعتبر محسوب شوند نادیده گرفته می‌شوند. در این صورت Pod اجازه راه‌اندازی خواهد داشت، اما نام‌های نامعتبر در لاگ وقایع به‌عنوان `InvalidVariableNames` ثبت می‌شوند. پیام لاگ هر کلید نادیده گرفته‌شده را فهرست می‌کند. برای مثال: + + ```shell + kubectl get events + ``` + + خروجی مشابه این است: + ``` + LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON SOURCE MESSAGE + 0s 0s 1 dapi-test-pod Pod Warning InvalidEnvironmentVariableNames {kubelet, 127.0.0.1} Keys [1badkey, 2alsobad] from the EnvFrom configMap default/myconfig were skipped since they are considered invalid environment variable names. + ``` + +- ConfigMapها در یک {{< glossary_tooltip term_id="namespace" >}} مشخص قرار دارند. + Podها می‌توانند تنها به ConfigMapهایی ارجاع دهند که در همان namespace خود Pod قرار دارند. + +- نمی‌توانید از ConfigMapها برای + {{< glossary_tooltip text="static pods" term_id="static-pod" >}} + استفاده کنید، زیرا kubelet این مورد را پشتیبانی نمی‌کند. + +## {{% heading "پاک‌سازی" %}} + +ConfigMapها و Podهایی که ایجاد کرده‌اید را حذف کنید: + +```bash +kubectl delete configmaps/game-config configmaps/game-config-2 configmaps/game-config-3 \ + configmaps/game-config-env-file +kubectl delete pod dapi-test-pod --now + +# ممکن است مجموعه بعدی را از قبل حذف کرده باشید +kubectl delete configmaps/special-config configmaps/env-config +kubectl delete configmap -l 'game-config in (config-4,config-5)' +``` + +فایل `kustomization.yaml` که برای تولید ConfigMap استفاده کردید را حذف کنید.: + +```bash +rm kustomization.yaml +``` + +اگر دایرکتوری `configure-pod-container` ایجاد کرده‌اید و دیگر به آن نیازی ندارید، باید آن را نیز حذف کنید، یا آن را به محل سطل زباله / فایل‌های حذف شده منتقل کنید. + +```bash +rm -r configure-pod-container +``` + +## {{% heading "whatsnext" %}} + +* یک مثال دنیای واقعی از + [پیکربندی Redis با استفاده از ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/) را دنبال کنید. +* یک مثال از [به‌روزرسانی پیکربندی از طریق ConfigMap](/docs/tutorials/configuration/updating-configuration-via-a-configmap/) را دنبال کنید. diff --git a/content/fa/docs/tasks/debug/_index.md b/content/fa/docs/tasks/debug/_index.md new file mode 100644 index 0000000000000..de4a0ff45cba1 --- /dev/null +++ b/content/fa/docs/tasks/debug/_index.md @@ -0,0 +1,100 @@ +--- +title: "نظارت، ثبت وقایع و اشکال‌زدایی" +description: راه‌اندازی نظارت و ثبت وقایع برای عیب‌یابی یک خوشه یا اشکال‌زدایی یک برنامه کانتینری. +weight: 40 +reviewers: +- xirehat +content_type: concept +no_list: true +card: + name: tasks + weight: 999 + title: دریافت کمک +--- + + + +گاهی اوقات اوضاع خراب می‌شود. این راهنما برای رفع آن‌ها طراحی شده است. شامل دو بخش است: + +* [عیب‌یابی برنامه شما](/docs/tasks/debug/debug-application/) – مفید برای کاربرانی که کد خود را در کوبرنتیز مستقر می‌کنند و می‌پرسند چرا برنامه‌شان کار نمی‌کند. +* [عیب‌یابی خوشه شما](/docs/tasks/debug/debug-cluster/) – مفید برای مدیران خوشه و افرادی که خوشه کوبرنتیزشان دچار مشکل است. + +شما همچنین باید مشکلات شناخته‌شده‌ی [نسخه](https://github.com/kubernetes/kubernetes/releases)‌ای را که استفاده می‌کنید بررسی کنید. + + + +## دریافت کمک + +اگر هیچ‌یک از راهنماهای بالا پاسخگوی مشکل شما نبود، روش‌های مختلفی برای دریافت کمک از جامعه‌ی کوبرنتیز وجود دارد. + +### پرسش‌ها + +مستندات این سایت طوری ساختاربندی شده که پاسخ طیف گسترده‌ای از پرسش‌ها را فراهم کند. [مفاهیم](/docs/concepts/) معماری کوبرنتیز و عملکرد هر مولفه را توضیح می‌دهد، در حالی که [نصب](/docs/setup/) دستورالعمل‌های عملی برای شروع کار ارائه می‌کند. [وظایف](/docs/tasks/) نشان می‌دهد چگونه کارهای رایج را انجام دهید، و [آموزش‌ها](/docs/tutorials/) راهنماهای جامع‌تری برای سناریوهای واقعی، صنعتی یا توسعه‌ی انتها به انتها هستند. بخش [مرجع](/docs/reference/) مستندات دقیقی درباره‌ی [API کوبرنتیز](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) و رابط‌های خط فرمان (CLI)، مانند [`kubectl`](/docs/reference/kubectl/)، در اختیار شما قرار می‌دهد. + +## کمک! سوال من پوشش داده نشده! الان به کمک نیاز دارم! + +### Stack Exchange، Stack Overflow یا Server Fault {#stack-exchange} + +اگر سوالاتی مرتبط با **توسعه نرم‌افزار** برای برنامه‌ی کانتینری‌شده‌تان دارید، می‌توانید آن‌ها را در [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) بپرسید. + +اگر سوالات کوبرنتیز شما مربوط به **مدیریت خوشه** یا **پیکربندی** است، می‌توانید آن‌ها را در [Server Fault](https://serverfault.com/questions/tagged/kubernetes) مطرح کنید. + +همچنین چند سایت خاص دیگر در شبکه‌ی Stack Exchange وجود دارد که ممکن است مکان مناسبی برای پرسش‌های کوبرنتیز در حوزه‌هایی مانند +[DevOps](https://devops.stackexchange.com/questions/tagged/kubernetes)، +[مهندسی نرم‌افزار](https://softwareengineering.stackexchange.com/questions/tagged/kubernetes) +یا [امنیت اطلاعات (InfoSec)](https://security.stackexchange.com/questions/tagged/kubernetes) +باشند. + +ممکن است شخص دیگری در جامعه قبلاً پرسش مشابهی را مطرح کرده باشد یا بتواند در حل مشکل شما کمک کند. + +تیم کوبرنتیز نیز پست‌های با تگ Kubernetes را زیر نظر دارد. اگر هیچ پرسش موجودی کمک نکرد، **لطفاً مطمئن شوید که سوال شما [موضوعی برای Stack Overflow](https://stackoverflow.com/help/on-topic)، [Server Fault](https://serverfault.com/help/on-topic) یا سایت شبکه‌ی Stack Exchange مربوطه است** و قبل از پرسش جدید، راهنمایی‌های [چگونه یک سوال جدید بپرسیم](https://stackoverflow.com/help/how-to-ask) را مطالعه کنید! + +### Slack + +بسیاری از اعضای جامعه‌ی کوبرنتیز در اسلک کوبرنتیز در کانال `#kubernetes-users` حضور دارند. +اسلک نیاز به ثبت‌نام دارد؛ شما می‌توانید [درخواست دعوتنامه کنید](https://slack.kubernetes.io)، و ثبت‌نام برای همه باز است. احساس راحتی کنید و هر سوالی دارید بپرسید. +پس از ثبت‌نام، از طریق مرورگر وب یا اپ اختصاصی اسلک به [سازمان Kubernetes در Slack](https://kubernetes.slack.com) دسترسی پیدا کنید. + +وقتی ثبت‌نام کردید، فهرست در حال رشد کانال‌ها را برای موضوعات مختلف مرور کنید. برای مثال، افراد تازه‌وارد به کوبرنتیز ممکن است بخواهند به کانال +[`#kubernetes-novice`](https://kubernetes.slack.com/messages/kubernetes-novice) بپیوندند. به‌عنوان مثال دیگر، توسعه‌دهندگان باید به کانال +[`#kubernetes-contributors`](https://kubernetes.slack.com/messages/kubernetes-contributors) ملحق شوند. + +همچنین کانال‌های زیادی مختص کشورها یا زبان‌های محلی وجود دارد. برای دریافت پشتیبانی و اطلاعات محلی، می‌توانید به این کانال‌ها بپیوندید: + +{{< table caption="کانال‌های Slack مختص کشور / زبان" >}} +کشور | کانال +:---------|:------------ +China | [`#cn-users`](https://kubernetes.slack.com/messages/cn-users), [`#cn-events`](https://kubernetes.slack.com/messages/cn-events) +Finland | [`#fi-users`](https://kubernetes.slack.com/messages/fi-users) +France | [`#fr-users`](https://kubernetes.slack.com/messages/fr-users), [`#fr-events`](https://kubernetes.slack.com/messages/fr-events) +Germany | [`#de-users`](https://kubernetes.slack.com/messages/de-users), [`#de-events`](https://kubernetes.slack.com/messages/de-events) +India | [`#in-users`](https://kubernetes.slack.com/messages/in-users), [`#in-events`](https://kubernetes.slack.com/messages/in-events) +Italy | [`#it-users`](https://kubernetes.slack.com/messages/it-users), [`#it-events`](https://kubernetes.slack.com/messages/it-events) +Japan | [`#jp-users`](https://kubernetes.slack.com/messages/jp-users), [`#jp-events`](https://kubernetes.slack.com/messages/jp-events) +Korea | [`#kr-users`](https://kubernetes.slack.com/messages/kr-users) +Netherlands | [`#nl-users`](https://kubernetes.slack.com/messages/nl-users) +Norway | [`#norw-users`](https://kubernetes.slack.com/messages/norw-users) +Poland | [`#pl-users`](https://kubernetes.slack.com/messages/pl-users) +Russia | [`#ru-users`](https://kubernetes.slack.com/messages/ru-users) +Spain | [`#es-users`](https://kubernetes.slack.com/messages/es-users) +Sweden | [`#se-users`](https://kubernetes.slack.com/messages/se-users) +Turkey | [`#tr-users`](https://kubernetes.slack.com/messages/tr-users), [`#tr-events`](https://kubernetes.slack.com/messages/tr-events) +{{< /table >}} + +### انجمن + +از پیوستن به انجمن رسمی Kubernetes استقبال می‌شود: [discuss.kubernetes.io](https://discuss.kubernetes.io). + +### باگ‌ها و درخواست ویژگی + +اگر مشکلی که مشاهده می‌کنید شبیه یک باگ است، یا می‌خواهید یک درخواست قابلیت ثبت کنید، لطفاً از [سیستم پیگیری مسائل در گیت‌هاب](https://github.com/kubernetes/kubernetes/issues) استفاده کنید. + +قبل از ثبت یک مسئله، لطفاً در میان مسائل موجود جستجو کنید تا ببینید آیا مشکل شما قبلاً پوشش داده شده است یا خیر. + +اگر در حال ثبت یک باگ هستید، لطفاً اطلاعات دقیقی درباره نحوه بازتولید مشکل ارائه دهید، مانند: + +* نسخه Kubernetes: `kubectl version` +* ارائه‌دهنده ابری، توزیع سیستم‌عامل، پیکربندی شبکه و نسخه زمان‌اجرای کانتینر +* مراحل لازم برای بازتولید مشکل + + diff --git a/content/fa/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/fa/docs/tasks/run-application/horizontal-pod-autoscale.md new file mode 100644 index 0000000000000..f6c165dd6230b --- /dev/null +++ b/content/fa/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -0,0 +1,670 @@ +--- +reviewers: +- xirehat +title: مقیاس‌بندی خودکار افقی +feature: + title: مقیاس‌بندی خودکار افقی + description: > + مقیاس برنامه خود را با یک دستور ساده، با یک رابط کاربری یا به طور خودکار بر اساس میزان استفاده از CPU، کم و زیاد کنید. +content_type: concept +weight: 90 +math: true +--- + + + +In Kubernetes, a _HorizontalPodAutoscaler_ automatically updates a workload resource (such as +a {{< glossary_tooltip text="Deployment" term_id="deployment" >}} or +{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}), with the +aim of automatically scaling the workload to match demand. + +Horizontal scaling means that the response to increased load is to deploy more +{{< glossary_tooltip text="Pods" term_id="pod" >}}. +This is different from _vertical_ scaling, which for Kubernetes would mean +assigning more resources (for example: memory or CPU) to the Pods that are already +running for the workload. + +If the load decreases, and the number of Pods is above the configured minimum, +the HorizontalPodAutoscaler instructs the workload resource (the Deployment, StatefulSet, +or other similar resource) to scale back down. + +Horizontal pod autoscaling does not apply to objects that can't be scaled (for example: +a {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}.) + +The HorizontalPodAutoscaler is implemented as a Kubernetes API resource and a +{{< glossary_tooltip text="controller" term_id="controller" >}}. +The resource determines the behavior of the controller. +The horizontal pod autoscaling controller, running within the Kubernetes +{{< glossary_tooltip text="control plane" term_id="control-plane" >}}, periodically adjusts the +desired scale of its target (for example, a Deployment) to match observed metrics such as average +CPU utilization, average memory utilization, or any other custom metric you specify. + +There is [walkthrough example](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) of using +horizontal pod autoscaling. + + + +## How does a HorizontalPodAutoscaler work? + +{{< mermaid >}} +graph BT + +hpa[Horizontal Pod Autoscaler] --> scale[Scale] + +subgraph rc[RC / Deployment] + scale +end + +scale -.-> pod1[Pod 1] +scale -.-> pod2[Pod 2] +scale -.-> pod3[Pod N] + +classDef hpa fill:#D5A6BD,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D; +classDef rc fill:#F9CB9C,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D; +classDef scale fill:#B6D7A8,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D; +classDef pod fill:#9FC5E8,stroke:#1E1E1D,stroke-width:1px,color:#1E1E1D; +class hpa hpa; +class rc rc; +class scale scale; +class pod1,pod2,pod3 pod +{{< /mermaid >}} + +Figure 1. HorizontalPodAutoscaler controls the scale of a Deployment and its ReplicaSet + +Kubernetes implements horizontal pod autoscaling as a control loop that runs intermittently +(it is not a continuous process). The interval is set by the +`--horizontal-pod-autoscaler-sync-period` parameter to the +[`kube-controller-manager`](/docs/reference/command-line-tools-reference/kube-controller-manager/) +(and the default interval is 15 seconds). + +Once during each period, the controller manager queries the resource utilization against the +metrics specified in each HorizontalPodAutoscaler definition. The controller manager +finds the target resource defined by the `scaleTargetRef`, +then selects the pods based on the target resource's `.spec.selector` labels, +and obtains the metrics from either the resource metrics API (for per-pod resource metrics), +or the custom metrics API (for all other metrics). + +- For per-pod resource metrics (like CPU), the controller fetches the metrics + from the resource metrics API for each Pod targeted by the HorizontalPodAutoscaler. + Then, if a target utilization value is set, the controller calculates the utilization + value as a percentage of the equivalent + [resource request](/docs/concepts/configuration/manage-resources-containers/#requests-and-limits) + on the containers in each Pod. If a target raw value is set, the raw metric values are used directly. + The controller then takes the mean of the utilization or the raw value (depending on the type + of target specified) across all targeted Pods, and produces a ratio used to scale + the number of desired replicas. + + Please note that if some of the Pod's containers do not have the relevant resource request set, + CPU utilization for the Pod will not be defined and the autoscaler will + not take any action for that metric. See the [algorithm details](#algorithm-details) section below + for more information about how the autoscaling algorithm works. + +- For per-pod custom metrics, the controller functions similarly to per-pod resource metrics, + except that it works with raw values, not utilization values. + +- For object metrics and external metrics, a single metric is fetched, which describes + the object in question. This metric is compared to the target + value, to produce a ratio as above. In the `autoscaling/v2` API + version, this value can optionally be divided by the number of Pods before the + comparison is made. + +The common use for HorizontalPodAutoscaler is to configure it to fetch metrics from +{{< glossary_tooltip text="aggregated APIs" term_id="aggregation-layer" >}} +(`metrics.k8s.io`, `custom.metrics.k8s.io`, or `external.metrics.k8s.io`). The `metrics.k8s.io` API is +usually provided by an add-on named Metrics Server, which needs to be launched separately. +For more information about resource metrics, see +[Metrics Server](/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/#metrics-server). + +[Support for metrics APIs](#support-for-metrics-apis) explains the stability guarantees and support status for these +different APIs. + +The HorizontalPodAutoscaler controller accesses corresponding workload resources that support scaling (such as Deployments +and StatefulSet). These resources each have a subresource named `scale`, an interface that allows you to dynamically set the +number of replicas and examine each of their current states. +For general information about subresources in the Kubernetes API, see +[Kubernetes API Concepts](/docs/reference/using-api/api-concepts/). + +### Algorithm details + +From the most basic perspective, the HorizontalPodAutoscaler controller +operates on the ratio between desired metric value and current metric +value: + +```math +\begin{equation*} +desiredReplicas = ceil\left\lceil currentReplicas \times \frac{currentMetricValue}{desiredMetricValue} \right\rceil +\end{equation*} +``` + +For example, if the current metric value is `200m`, and the desired value +is `100m`, the number of replicas will be doubled, since +\\( { 200.0 \div 100.0 } = 2.0 \\). +If the current value is instead `50m`, you'll halve the number of +replicas, since \\( { 50.0 \div 100.0 } = 0.5 \\). The control plane skips any scaling +action if the ratio is sufficiently close to 1.0 (within a +[configurable tolerance](#tolerance), 0.1 by default). + +When a `targetAverageValue` or `targetAverageUtilization` is specified, +the `currentMetricValue` is computed by taking the average of the given +metric across all Pods in the HorizontalPodAutoscaler's scale target. + +Before checking the tolerance and deciding on the final values, the control +plane also considers whether any metrics are missing, and how many Pods +are [`Ready`](/docs/concepts/workloads/pods/pod-lifecycle/#pod-conditions). +All Pods with a deletion timestamp set (objects with a deletion timestamp are +in the process of being shut down / removed) are ignored, and all failed Pods +are discarded. + +If a particular Pod is missing metrics, it is set aside for later; Pods +with missing metrics will be used to adjust the final scaling amount. + +When scaling on CPU, if any pod has yet to become ready (it's still +initializing, or possibly is unhealthy) _or_ the most recent metric point for +the pod was before it became ready, that pod is set aside as well. + +Due to technical constraints, the HorizontalPodAutoscaler controller +cannot exactly determine the first time a pod becomes ready when +determining whether to set aside certain CPU metrics. Instead, it +considers a Pod "not yet ready" if it's unready and transitioned to +ready within a short, configurable window of time since it started. +This value is configured with the `--horizontal-pod-autoscaler-initial-readiness-delay` +flag, and its default is 30 seconds. +Once a pod has become ready, it considers any transition to +ready to be the first if it occurred within a longer, configurable time +since it started. This value is configured with the +`--horizontal-pod-autoscaler-cpu-initialization-period` flag, and its +default is 5 minutes. + +The \\( currentMetricValue \over desiredMetricValue \\) base scale ratio is then +calculated, using the remaining pods not set aside or discarded from above. + +If there were any missing metrics, the control plane recomputes the average more +conservatively, assuming those pods were consuming 100% of the desired +value in case of a scale down, and 0% in case of a scale up. This dampens +the magnitude of any potential scale. + +Furthermore, if any not-yet-ready pods were present, and the workload would have +scaled up without factoring in missing metrics or not-yet-ready pods, +the controller conservatively assumes that the not-yet-ready pods are consuming 0% +of the desired metric, further dampening the magnitude of a scale up. + +After factoring in the not-yet-ready pods and missing metrics, the +controller recalculates the usage ratio. If the new ratio reverses the scale +direction, or is within the tolerance, the controller doesn't take any scaling +action. In other cases, the new ratio is used to decide any change to the +number of Pods. + +Note that the _original_ value for the average utilization is reported +back via the HorizontalPodAutoscaler status, without factoring in the +not-yet-ready pods or missing metrics, even when the new usage ratio is +used. + +If multiple metrics are specified in a HorizontalPodAutoscaler, this +calculation is done for each metric, and then the largest of the desired +replica counts is chosen. If any of these metrics cannot be converted +into a desired replica count (e.g. due to an error fetching the metrics +from the metrics APIs) and a scale down is suggested by the metrics which +can be fetched, scaling is skipped. This means that the HPA is still capable +of scaling up if one or more metrics give a `desiredReplicas` greater than +the current value. + +Finally, right before HPA scales the target, the scale recommendation is recorded. The +controller considers all recommendations within a configurable window choosing the +highest recommendation from within that window. This value can be configured using the +`--horizontal-pod-autoscaler-downscale-stabilization` flag, which defaults to 5 minutes. +This means that scaledowns will occur gradually, smoothing out the impact of rapidly +fluctuating metric values. + +### Pod readiness and autoscaling metrics + +The HorizontalPodAutoscaler (HPA) controller includes two flags that influence how CPU metrics are collected from Pods during startup: + +1. `--horizontal-pod-autoscaler-cpu-initialization-period` (default: 5 minutes) + + This defines the time window after a Pod starts during which its **CPU usage is ignored** unless: + - The Pod is in a `Ready` state **and** + - The metric sample was taken entirely during the period it was `Ready`. + + This flag helps **exclude misleading high CPU usage** from initializing Pods (e.g., Java apps warming up) in HPA scaling decisions. + +2. `--horizontal-pod-autoscaler-initial-readiness-delay` (default: 30 seconds) + + This defines a short delay period after a Pod starts during which the HPA controller treats Pods that are currently `Unready` as still initializing, **even if they have previously transitioned to `Ready` briefly**. + + It is designed to: + - Avoid including Pods that rapidly fluctuate between `Ready` and `Unready` during startup. + - Ensure stability in the initial readiness signal before HPA considers their metrics valid. + +**Key behaviors:** +- If a Pod is `Ready` and remains `Ready`, it can be counted as contributing metrics even within the delay. +- If a Pod rapidly toggles between `Ready` and `Unready`, metrics are ignored until it’s considered stably `Ready`. + +#### Best Practice: +If your Pod has a startup phase with high CPU usage, configure both: +- `--horizontal-pod-autoscaler-cpu-initialization-period` to **cover the startup duration**. +- Ensure your **readinessProbe** only reports `Ready` **after the CPU spike subsides**, using `initialDelaySeconds`. + +This avoids scaling based on temporary spikes that do not reflect long-term workload needs. + + +## API Object + +The Horizontal Pod Autoscaler is an API resource in the Kubernetes +`autoscaling` API group. The current stable version can be found in +the `autoscaling/v2` API version which includes support for scaling on +memory and custom metrics. The new fields introduced in +`autoscaling/v2` are preserved as annotations when working with +`autoscaling/v1`. + +When you create a HorizontalPodAutoscaler API object, make sure the name specified is a valid +[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). +More details about the API object can be found at +[HorizontalPodAutoscaler Object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v2-autoscaling). + +## Stability of workload scale {#flapping} + +When managing the scale of a group of replicas using the HorizontalPodAutoscaler, +it is possible that the number of replicas keeps fluctuating frequently due to the +dynamic nature of the metrics evaluated. This is sometimes referred to as _thrashing_, +or _flapping_. It's similar to the concept of _hysteresis_ in cybernetics. + +## Autoscaling during rolling update + +Kubernetes lets you perform a rolling update on a Deployment. In that +case, the Deployment manages the underlying ReplicaSets for you. +When you configure autoscaling for a Deployment, you bind a +HorizontalPodAutoscaler to a single Deployment. The HorizontalPodAutoscaler +manages the `replicas` field of the Deployment. The deployment controller is responsible +for setting the `replicas` of the underlying ReplicaSets so that they add up to a suitable +number during the rollout and also afterwards. + +If you perform a rolling update of a StatefulSet that has an autoscaled number of +replicas, the StatefulSet directly manages its set of Pods (there is no intermediate resource +similar to ReplicaSet). + +## Support for resource metrics + +Any HPA target can be scaled based on the resource usage of the pods in the scaling target. +When defining the pod specification the resource requests like `cpu` and `memory` should +be specified. This is used to determine the resource utilization and used by the HPA controller +to scale the target up or down. To use resource utilization based scaling specify a metric source +like this: + +```yaml +type: Resource +resource: + name: cpu + target: + type: Utilization + averageUtilization: 60 +``` +With this metric the HPA controller will keep the average utilization of the pods in the scaling +target at 60%. Utilization is the ratio between the current usage of resource to the requested +resources of the pod. See [Algorithm](#algorithm-details) for more details about how the utilization +is calculated and averaged. + +{{< note >}} +Since the resource usages of all the containers are summed up the total pod utilization may not +accurately represent the individual container resource usage. This could lead to situations where +a single container might be running with high usage and the HPA will not scale out because the overall +pod usage is still within acceptable limits. +{{< /note >}} + +### Container resource metrics + +{{< feature-state feature_gate_name="HPAContainerMetrics" >}} + +The HorizontalPodAutoscaler API also supports a container metric source where the HPA can track the +resource usage of individual containers across a set of Pods, in order to scale the target resource. +This lets you configure scaling thresholds for the containers that matter most in a particular Pod. +For example, if you have a web application and a sidecar container that provides logging, you can scale based on the resource +use of the web application, ignoring the sidecar container and its resource use. + +If you revise the target resource to have a new Pod specification with a different set of containers, +you should revise the HPA spec if that newly added container should also be used for +scaling. If the specified container in the metric source is not present or only present in a subset +of the pods then those pods are ignored and the recommendation is recalculated. See [Algorithm](#algorithm-details) +for more details about the calculation. To use container resources for autoscaling define a metric +source as follows: + +```yaml +type: ContainerResource +containerResource: + name: cpu + container: application + target: + type: Utilization + averageUtilization: 60 +``` + +In the above example the HPA controller scales the target such that the average utilization of the cpu +in the `application` container of all the pods is 60%. + +{{< note >}} +If you change the name of a container that a HorizontalPodAutoscaler is tracking, you can +make that change in a specific order to ensure scaling remains available and effective +whilst the change is being applied. Before you update the resource that defines the container +(such as a Deployment), you should update the associated HPA to track both the new and +old container names. This way, the HPA is able to calculate a scaling recommendation +throughout the update process. + +Once you have rolled out the container name change to the workload resource, tidy up by removing +the old container name from the HPA specification. +{{< /note >}} + +## Scaling on custom metrics + +{{< feature-state for_k8s_version="v1.23" state="stable" >}} + +(the `autoscaling/v2beta2` API version previously provided this ability as a beta feature) + +Provided that you use the `autoscaling/v2` API version, you can configure a HorizontalPodAutoscaler +to scale based on a custom metric (that is not built in to Kubernetes or any Kubernetes component). +The HorizontalPodAutoscaler controller then queries for these custom metrics from the Kubernetes +API. + +See [Support for metrics APIs](#support-for-metrics-apis) for the requirements. + +## Scaling on multiple metrics + +{{< feature-state for_k8s_version="v1.23" state="stable" >}} + +(the `autoscaling/v2beta2` API version previously provided this ability as a beta feature) + +Provided that you use the `autoscaling/v2` API version, you can specify multiple metrics for a +HorizontalPodAutoscaler to scale on. Then, the HorizontalPodAutoscaler controller evaluates each metric, +and proposes a new scale based on that metric. The HorizontalPodAutoscaler takes the maximum scale +recommended for each metric and sets the workload to that size (provided that this isn't larger than the +overall maximum that you configured). + +## Support for metrics APIs + +By default, the HorizontalPodAutoscaler controller retrieves metrics from a series of APIs. +In order for it to access these APIs, cluster administrators must ensure that: + +- The [API aggregation layer](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) is enabled. + +- The corresponding APIs are registered: + + - For resource metrics, this is the `metrics.k8s.io` [API](/docs/reference/external-api/metrics.v1beta1/), + generally provided by [metrics-server](https://github.com/kubernetes-sigs/metrics-server). + It can be launched as a cluster add-on. + + - For custom metrics, this is the `custom.metrics.k8s.io` [API](/docs/reference/external-api/custom-metrics.v1beta2/). + It's provided by "adapter" API servers provided by metrics solution vendors. + Check with your metrics pipeline to see if there is a Kubernetes metrics adapter available. + + - For external metrics, this is the `external.metrics.k8s.io` [API](/docs/reference/external-api/external-metrics.v1beta1/). + It may be provided by the custom metrics adapters provided above. + +For more information on these different metrics paths and how they differ please see the relevant design proposals for +[the HPA V2](https://git.k8s.io/design-proposals-archive/autoscaling/hpa-v2.md), +[custom.metrics.k8s.io](https://git.k8s.io/design-proposals-archive/instrumentation/custom-metrics-api.md) +and [external.metrics.k8s.io](https://git.k8s.io/design-proposals-archive/instrumentation/external-metrics-api.md). + +For examples of how to use them see +[the walkthrough for using custom metrics](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-multiple-metrics-and-custom-metrics) +and [the walkthrough for using external metrics](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-metrics-not-related-to-kubernetes-objects). + +## Configurable scaling behavior + +{{< feature-state for_k8s_version="v1.23" state="stable" >}} + +(the `autoscaling/v2beta2` API version previously provided this ability as a beta feature) + +If you use the `v2` HorizontalPodAutoscaler API, you can use the `behavior` field +(see the [API reference](/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2/#HorizontalPodAutoscalerSpec)) +to configure separate scale-up and scale-down behaviors. +You specify these behaviours by setting `scaleUp` and / or `scaleDown` +under the `behavior` field. + +Scaling policies let you control the rate of change of replicas while scaling. +Also two settings can be used to prevent [flapping](#flapping): you can specify a +_stabilization window_ for smoothing replica counts, and a tolerance to ignore +minor metric fluctuations below a specified threshold. + +### Scaling policies + +One or more scaling policies can be specified in the `behavior` section of the spec. +When multiple policies are specified the policy which allows the highest amount of +change is the policy which is selected by default. The following example shows this behavior +while scaling down: + +```yaml +behavior: + scaleDown: + policies: + - type: Pods + value: 4 + periodSeconds: 60 + - type: Percent + value: 10 + periodSeconds: 60 +``` + +`periodSeconds` indicates the length of time in the past for which the policy must hold true. +The maximum value that you can set for `periodSeconds` is 1800 (half an hour). +The first policy _(Pods)_ allows at most 4 replicas to be scaled down in one minute. The second policy +_(Percent)_ allows at most 10% of the current replicas to be scaled down in one minute. + +Since by default the policy which allows the highest amount of change is selected, the second policy will +only be used when the number of pod replicas is more than 40. With 40 or less replicas, the first policy will be applied. +For instance if there are 80 replicas and the target has to be scaled down to 10 replicas +then during the first step 8 replicas will be reduced. In the next iteration when the number +of replicas is 72, 10% of the pods is 7.2 but the number is rounded up to 8. On each loop of +the autoscaler controller the number of pods to be change is re-calculated based on the number +of current replicas. When the number of replicas falls below 40 the first policy _(Pods)_ is applied +and 4 replicas will be reduced at a time. + +The policy selection can be changed by specifying the `selectPolicy` field for a scaling +direction. By setting the value to `Min` which would select the policy which allows the +smallest change in the replica count. Setting the value to `Disabled` completely disables +scaling in that direction. + +### Stabilization window + +The stabilization window is used to restrict the [flapping](#flapping) of +replica count when the metrics used for scaling keep fluctuating. The autoscaling algorithm +uses this window to infer a previous desired state and avoid unwanted changes to workload +scale. + +For example, in the following example snippet, a stabilization window is specified for `scaleDown`. + +```yaml +behavior: + scaleDown: + stabilizationWindowSeconds: 300 +``` + +When the metrics indicate that the target should be scaled down the algorithm looks +into previously computed desired states, and uses the highest value from the specified +interval. In the above example, all desired states from the past 5 minutes will be considered. + +This approximates a rolling maximum, and avoids having the scaling algorithm frequently +remove Pods only to trigger recreating an equivalent Pod just moments later. + +### Tolerance {#tolerance} + +{{< feature-state feature_gate_name="HPAConfigurableTolerance" >}} + +The `tolerance` field configures a threshold for metric variations, preventing the +autoscaler from scaling for changes below that value. + +This tolerance is defined as the amount of variation around the desired metric value under +which no scaling will occur. For example, consider a HorizontalPodAutoscaler configured +with a target memory consumption of 100MiB and a scale-up tolerance of 5%: + +```yaml +behavior: + scaleUp: + tolerance: 0.05 # 5% tolerance for scale up +``` + +With this configuration, the HPA algorithm will only consider scaling up if the memory +consumption is higher than 105MiB (that is: 5% above the target). + +If you don't set this field, the HPA applies the default cluster-wide tolerance of 10%. This +default can be updated for both scale-up and scale-down using the +[kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) +`--horizontal-pod-autoscaler-tolerance` command line argument. (You can't use the Kubernetes API +to configure this default value.) + +### Default Behavior + +To use the custom scaling not all fields have to be specified. Only values which need to be +customized can be specified. These custom values are merged with default values. The default values +match the existing behavior in the HPA algorithm. + +```yaml +behavior: + scaleDown: + stabilizationWindowSeconds: 300 + policies: + - type: Percent + value: 100 + periodSeconds: 15 + scaleUp: + stabilizationWindowSeconds: 0 + policies: + - type: Percent + value: 100 + periodSeconds: 15 + - type: Pods + value: 4 + periodSeconds: 15 + selectPolicy: Max +``` +For scaling down the stabilization window is _300_ seconds (or the value of the +`--horizontal-pod-autoscaler-downscale-stabilization` flag if provided). There is only a single policy +for scaling down which allows a 100% of the currently running replicas to be removed which +means the scaling target can be scaled down to the minimum allowed replicas. +For scaling up there is no stabilization window. When the metrics indicate that the target should be +scaled up the target is scaled up immediately. There are 2 policies where 4 pods or a 100% of the currently +running replicas may at most be added every 15 seconds till the HPA reaches its steady state. + +### Example: change downscale stabilization window + +To provide a custom downscale stabilization window of 1 minute, the following +behavior would be added to the HPA: + +```yaml +behavior: + scaleDown: + stabilizationWindowSeconds: 60 +``` + +### Example: limit scale down rate + +To limit the rate at which pods are removed by the HPA to 10% per minute, the +following behavior would be added to the HPA: + +```yaml +behavior: + scaleDown: + policies: + - type: Percent + value: 10 + periodSeconds: 60 +``` + +To ensure that no more than 5 Pods are removed per minute, you can add a second scale-down +policy with a fixed size of 5, and set `selectPolicy` to minimum. Setting `selectPolicy` to `Min` means +that the autoscaler chooses the policy that affects the smallest number of Pods: + +```yaml +behavior: + scaleDown: + policies: + - type: Percent + value: 10 + periodSeconds: 60 + - type: Pods + value: 5 + periodSeconds: 60 + selectPolicy: Min +``` + +### Example: disable scale down + +The `selectPolicy` value of `Disabled` turns off scaling the given direction. +So to prevent downscaling the following policy would be used: + +```yaml +behavior: + scaleDown: + selectPolicy: Disabled +``` + +## Support for HorizontalPodAutoscaler in kubectl + +HorizontalPodAutoscaler, like every API resource, is supported in a standard way by `kubectl`. +You can create a new autoscaler using `kubectl create` command. +You can list autoscalers by `kubectl get hpa` or get detailed description by `kubectl describe hpa`. +Finally, you can delete an autoscaler using `kubectl delete hpa`. + +In addition, there is a special `kubectl autoscale` command for creating a HorizontalPodAutoscaler object. +For instance, executing `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80` +will create an autoscaler for ReplicaSet _foo_, with target CPU utilization set to `80%` +and the number of replicas between 2 and 5. + +## Implicit maintenance-mode deactivation + +You can implicitly deactivate the HPA for a target without the +need to change the HPA configuration itself. If the target's desired replica count +is set to 0, and the HPA's minimum replica count is greater than 0, the HPA +stops adjusting the target (and sets the `ScalingActive` Condition on itself +to `false`) until you reactivate it by manually adjusting the target's desired +replica count or HPA's minimum replica count. + +### Migrating Deployments and StatefulSets to horizontal autoscaling + +When an HPA is enabled, it is recommended that the value of `spec.replicas` of +the Deployment and / or StatefulSet be removed from their +{{< glossary_tooltip text="manifest(s)" term_id="manifest" >}}. If this isn't done, any time +a change to that object is applied, for example via `kubectl apply -f +deployment.yaml`, this will instruct Kubernetes to scale the current number of Pods +to the value of the `spec.replicas` key. This may not be +desired and could be troublesome when an HPA is active, resulting in thrashing or flapping behavior. + +Keep in mind that the removal of `spec.replicas` may incur a one-time +degradation of Pod counts as the default value of this key is 1 (reference +[Deployment Replicas](/docs/concepts/workloads/controllers/deployment#replicas)). +Upon the update, all Pods except 1 will begin their termination procedures. Any +deployment application afterwards will behave as normal and respect a rolling +update configuration as desired. You can avoid this degradation by choosing one of the following two +methods based on how you are modifying your deployments: + +{{< tabs name="fix_replicas_instructions" >}} +{{% tab name="Client Side Apply (this is the default)" %}} + +1. `kubectl apply edit-last-applied deployment/` +2. In the editor, remove `spec.replicas`. When you save and exit the editor, `kubectl` + applies the update. No changes to Pod counts happen at this step. +3. You can now remove `spec.replicas` from the manifest. If you use source code management, + also commit your changes or take whatever other steps for revising the source code + are appropriate for how you track updates. +4. From here on out you can run `kubectl apply -f deployment.yaml` + +{{% /tab %}} +{{% tab name="Server Side Apply" %}} + +When using the [Server-Side Apply](/docs/reference/using-api/server-side-apply/) +you can follow the [transferring ownership](/docs/reference/using-api/server-side-apply/#transferring-ownership) +guidelines, which cover this exact use case. + +{{% /tab %}} +{{< /tabs >}} + +## {{% heading "whatsnext" %}} + +If you configure autoscaling in your cluster, you may also want to consider using +[node autoscaling](/docs/concepts/cluster-administration/node-autoscaling/) +to ensure you are running the right number of nodes. + +For more information on HorizontalPodAutoscaler: + +- Read a [walkthrough example](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for horizontal pod autoscaling. +- Read documentation for [`kubectl autoscale`](/docs/reference/generated/kubectl/kubectl-commands/#autoscale). +- If you would like to write your own custom metrics adapter, check out the + [boilerplate](https://github.com/kubernetes-sigs/custom-metrics-apiserver) to get started. +- Read the [API reference](/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2/) for HorizontalPodAutoscaler. diff --git a/content/fa/docs/tutorials/_index.md b/content/fa/docs/tutorials/_index.md new file mode 100644 index 0000000000000..4eade044ad3b6 --- /dev/null +++ b/content/fa/docs/tutorials/_index.md @@ -0,0 +1,61 @@ +--- +title: آموزش‌ها +main_menu: true +no_list: true +weight: 60 +content_type: concept +--- + + + +این بخش از مستندات کوبرنتیز شامل آموزش‌ها است. +یک آموزش نشان می‌دهد چگونه هدفی را که بزرگ‌تر از یک [کار](/docs/tasks/) واحد است، انجام دهید. معمولاً یک آموزش چند بخش دارد که هر بخش شامل توالی‌ای از مراحل است. پیش از مرور هر آموزش، شاید بخواهید صفحه [واژه‌نامه استاندارد](/docs/reference/glossary/) را برای مراجعات بعدی نشان کنید. + + + +## مبانی + +* [مبانی کوبرنتیز](/docs/tutorials/kubernetes-basics/) یک آموزش تعاملی عمیق است که به شما کمک می‌کند سیستم کوبرنتیز را بشناسید و برخی قابلیت‌های پایه آن را امتحان کنید. +* [مقدمه‌ای بر کوبرنتیز (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x#) +* [سلام Minikube](/docs/tutorials/hello-minikube/) + +## پیکربندی + +* [پیکربندی Redis با استفاده از ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/) + +## نگارش pod + +* [بکارگیری کانتینرهای کناری](/docs/tutorials/configuration/pod-sidecar-containers/) + +## برنامه‌های بدون وضعیت + +* [در معرض قرار دادن یک نشانی IP خارجی برای دسترسی به یک برنامه در خوشه](/docs/tutorials/stateless-application/expose-external-ip-address/) +* [مثال: استقرار برنامه دفتر میهمان PHP با Redis](/docs/tutorials/stateless-application/guestbook/) + +## برنامه‌های دارای وضعیت + +* [مبانی StatefulSet](/docs/tutorials/stateful-application/basic-stateful-set/) +* [مثال: Wordpress و MySQL با حجم‌های پایدار](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/) +* [مثال: استقرار Cassandra با StatefulSetها](/docs/tutorials/stateful-application/cassandra/) +* [اجرای ZooKeeper، یک سیستم توزیع‌شده CP](/docs/tutorials/stateful-application/zookeeper/) + +## سرویس‌ها + +* [اتصال برنامه‌ها با سرویس‌ها](/docs/tutorials/services/connect-applications-service/) +* [استفاده از آدرس IP منبع](/docs/tutorials/services/source-ip/) + +## امنیت + +* [اعمال استانداردهای امنیتی پاد در سطح خوشه](/docs/tutorials/security/cluster-level-pss/) +* [اعمال استانداردهای امنیتی pod در سطح فضای نام](/docs/tutorials/security/ns-level-pss/) +* [محدود کردن دسترسی یک کانتینر به منابع با AppArmor](/docs/tutorials/security/apparmor/) +* [Seccomp](/docs/tutorials/security/seccomp/) + +## مدیریت خوشه + +* [اجرای Kubelet در حالت مستقل](/docs/tutorials/cluster-management/kubelet-standalone/) + + +## {{% heading "whatsnext" %}} + +اگر تمایل دارید یک آموزش بنویسید، برای اطلاعات درباره نوع صفحه آموزش به [انواع صفحات محتوا](/docs/contribute/style/page-content-types/) مراجعه کنید. diff --git a/content/fa/docs/tutorials/configuration/_index.md b/content/fa/docs/tutorials/configuration/_index.md new file mode 100644 index 0000000000000..bdd265f65274a --- /dev/null +++ b/content/fa/docs/tutorials/configuration/_index.md @@ -0,0 +1,5 @@ +--- +title: "پیکربندی" +weight: 30 +--- + diff --git a/content/fa/docs/tutorials/configuration/configure-redis-using-configmap.md b/content/fa/docs/tutorials/configuration/configure-redis-using-configmap.md new file mode 100644 index 0000000000000..c080abab55e52 --- /dev/null +++ b/content/fa/docs/tutorials/configuration/configure-redis-using-configmap.md @@ -0,0 +1,245 @@ +--- +reviewers: +- xirehat +title: پیکربندی Redis با استفاده از ConfigMap +content_type: tutorial +weight: 30 +--- + + + +این صفحه یک نمونه واقعی از نحوه پیکربندی Redis با استفاده از یک ConfigMap ارائه می‌دهد و بر روی وظیفه [پیکربندی یک پاد برای استفاده از یک ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) بنا شده است. + +## {{% heading "objectives" %}} + +* یک ConfigMap با مقادیر پیکربندی Redis ایجاد کنید +* یک پاد Redis ایجاد کنید که ConfigMap ساخته‌شده را mount کرده و از آن استفاده کند +* بررسی کنید که پیکربندی به‌درستی اعمال شده باشد. + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +* مثال نشان داده شده در این صفحه با `kubectl` 1.14 و بالاتر کار می‌کند. +* [پیکربندی یک پاد برای استفاده از ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) را درک کنید. + + + + +## مثال دنیای واقعی: پیکربندی Redis با استفاده از ConfigMap + +برای پیکربندی حافظه پنهان Redis با استفاده از داده‌های ذخیره شده در ConfigMap، مراحل زیر را دنبال کنید. + +ابتدا یک ConfigMap با یک بلوک پیکربندی خالی ایجاد کنید: + +```shell +cat <./example-redis-config.yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: example-redis-config +data: + redis-config: "" +EOF +``` + +ConfigMap ایجاد شده در بالا را به همراه یک Redis pod manifest اعمال کنید: + +```shell +kubectl apply -f example-redis-config.yaml +kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/config/redis-pod.yaml +``` + +محتویات فایل Manifest مربوط به Redis pod را بررسی کنید و به موارد زیر توجه کنید: + +* یک volume به نام `config` به‌وسیله `spec.volumes[1]` ایجاد می‌شود +* کلیدهای `key` و `path` در `spec.volumes[1].configMap.items[0]`، کلید `redis-config` را از + ConfigMap به نام `example-redis-config` به‌صورت فایلی با نام `redis.conf` روی volume `config` در دسترس قرار می‌دهد. +* سپس volume `config` با استفاده از `spec.containers[0].volumeMounts[1]` در مسیر `/redis-master` mount می‌شود. + +در نتیجه، داده موجود در `data.redis-config` از ConfigMap ‌`example-redis-config` داخل پاد به شکل فایل +`/redis-master/redis.conf` در دسترس خواهد بود. + +{{% code_sample file="pods/config/redis-pod.yaml" %}} + +اشیاء ایجاد شده را بررسی کنید: + +```shell +kubectl get pod/redis configmap/example-redis-config +``` + +شما باید خروجی زیر را ببینید: + +``` +NAME READY STATUS RESTARTS AGE +pod/redis 1/1 Running 0 8s + +NAME DATA AGE +configmap/example-redis-config 1 14s +``` + +به یاد داشته باشید که ما کلید `redis-config` را در `example-redis-config` ConfigMap خالی گذاشتیم: + +```shell +kubectl describe configmap/example-redis-config +``` + +شما باید یک کلید خالی `redis-config` را ببینید: + +```shell +Name: example-redis-config +Namespace: default +Labels: +Annotations: + +Data +==== +redis-config: +``` + +از `kubectl exec` برای ورود به پاد و اجرای ابزار `redis-cli` برای بررسی پیکربندی فعلی استفاده کنید: + +```shell +kubectl exec -it redis -- redis-cli +``` + +بررسی `maxmemory`: + +```shell +127.0.0.1:6379> CONFIG GET maxmemory +``` + +باید مقدار پیش‌فرض ۰ را نشان دهد: + +```shell +1) "maxmemory" +2) "0" +``` + +به طور مشابه، `maxmemory-policy` را بررسی کنید: + +```shell +127.0.0.1:6379> CONFIG GET maxmemory-policy +``` + +که باید مقدار پیش‌فرض `noeviction` را نیز داشته باشد: + +```shell +1) "maxmemory-policy" +2) "noeviction" +``` + +حالا بیایید برخی از مقادیر پیکربندی را به ConfigMap مربوط به `example-redis-config` اضافه کنیم: + +{{% code_sample file="pods/config/example-redis-config.yaml" %}} + +ConfigMap به‌روزرسانی‌شده را اعمال کنید: + +```shell +kubectl apply -f example-redis-config.yaml +``` + +تأیید کنید که ConfigMap به‌روزرسانی شده است: + +```shell +kubectl describe configmap/example-redis-config +``` + +شما باید مقادیر پیکربندی که اضافه کردیم را ببینید: + +```shell +Name: example-redis-config +Namespace: default +Labels: +Annotations: + +Data +==== +redis-config: +---- +maxmemory 2mb +maxmemory-policy allkeys-lru +``` + +دوباره Redis Pod را با استفاده از `redis-cli` از طریق `kubectl exec` بررسی کنید تا ببینید آیا پیکربندی اعمال شده است یا خیر: + +```shell +kubectl exec -it redis -- redis-cli +``` + +بررسی `maxmemory`: + +```shell +127.0.0.1:6379> CONFIG GET maxmemory +``` + +در مقدار پیش‌فرض ۰ باقی می‌ماند: + +```shell +1) "maxmemory" +2) "0" +``` + +به طور مشابه، `maxmemory-policy` در تنظیمات پیش‌فرض `noeviction` باقی می‌ماند: + +```shell +127.0.0.1:6379> CONFIG GET maxmemory-policy +``` + +خروجی: + +```shell +1) "maxmemory-policy" +2) "noeviction" +``` + +مقادیر پیکربندی تغییر نکرده‌اند زیرا پاد برای دریافت مقادیر به‌روزرسانی‌شده از ConfigMaps مرتبط، نیاز به راه‌اندازی مجدد دارد. بیایید پاد را حذف و دوباره ایجاد کنیم: + +```shell +kubectl delete pod redis +kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/config/redis-pod.yaml +``` + +حالا برای آخرین بار مقادیر پیکربندی را دوباره بررسی کنید: + +```shell +kubectl exec -it redis -- redis-cli +``` + +بررسی `maxmemory`: + +```shell +127.0.0.1:6379> CONFIG GET maxmemory +``` + +اکنون باید مقدار به‌روزرسانی‌شده‌ی ۲۰۹۷۱۵۲ را برگرداند: + +```shell +1) "maxmemory" +2) "2097152" +``` + +به طور مشابه، `maxmemory-policy` نیز به‌روزرسانی شده است: + +```shell +127.0.0.1:6379> CONFIG GET maxmemory-policy +``` + +اکنون مقدار مورد نظر برای `allkeys-lru` را نشان می‌دهد: + +```shell +1) "maxmemory-policy" +2) "allkeys-lru" +``` + +با حذف منابع ایجاد شده، کارتان را مرتب کنید: + +```shell +kubectl delete pod/redis configmap/example-redis-config +``` + +## {{% heading "whatsnext" %}} + +* درباره [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) بیشتر بدانید. +* مثال [به‌روزرسانی پیکربندی از طریق ConfigMap](/docs/tutorials/configuration/updating-configuration-via-a-configmap/) را دنبال کنید. diff --git a/content/fa/docs/tutorials/configuration/pod-sidecar-containers.md b/content/fa/docs/tutorials/configuration/pod-sidecar-containers.md new file mode 100644 index 0000000000000..123e5da2ed27d --- /dev/null +++ b/content/fa/docs/tutorials/configuration/pod-sidecar-containers.md @@ -0,0 +1,195 @@ +--- +title: استفاده از کانتینرهای sidecar +content_type: tutorial +weight: 40 +min-kubernetes-server-version: 1.29 +--- + + + +این بخش برای افرادی مناسب است که قصد دارند قابلیت داخلی جدیدِ +[کانتینرهای sidecar](/docs/concepts/workloads/pods/sidecar-containers/) +را برای بارهای کاری خود به کار بگیرند. + +کانتینر sidecar مفهوم تازه‌ای نیست؛ همان‌طور که در +[این مطلب وب نوشتی](/blog/2015/06/the-distributed-system-toolkit-patterns/) +اشاره شده است. کوبرنتیس اجرای چندین کانتینر در یک پاد را برای پیاده‌سازی این مفهوم +امکان‌پذیر می‌کند. بااین‌حال، اجرای یک کانتینر sidecar به‌عنوان کانتینر معمولی +محدودیت‌های زیادی دارد که اکنون با پشتیبانی داخلی جدید از کانتینرهای sidecar برطرف شده‌اند. + +{{< feature-state feature_gate_name="SidecarContainers" >}} + +## {{% heading "objectives" %}} + +- نیاز به کانتینرهای sidecar را درک کنید +- بتوانید مشکلات مربوط به کانتینرهای sidecar را عیب‌یابی کنید +- گزینه‌های "تزریق" جهانی کانتینرهای sidecar به هر حجم کاری را درک کنید + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + +## نمای کلی کانتینرهای sidecar + +کانتینرهای سایدکار، کانتینرهای ثانویه‌ای هستند که همراه با کانتینر اصلیِ برنامه در همان +{{< glossary_tooltip text="Pod" term_id="pod" >}} اجرا می‌شوند. +این کانتینرها با ارائه خدمات یا قابلیت‌های اضافی—مانند ثبت لاگ، پایش، امنیت، +یا همگام‌سازی داده—بدون تغییر مستقیم کد برنامه اصلی، کارایی یا امکانات آن +را افزایش و گسترش می‌دهند. برای اطلاعات بیشتر به صفحه +[کانتینرهای سایدکار](/docs/concepts/workloads/pods/sidecar-containers/) مراجعه کنید. + +مفهوم کانتینرهای سایدکار جدید نیست و پیاده‌سازی‌های متعددی از آن وجود دارد. +علاوه بر کانتینرهای سایدکاری که خودِ شما—به‌عنوان تعریف‌کننده پاد—تمایل دارید اجرا شوند، +ممکن است برخی {{< glossary_tooltip text="addons" term_id="addons" >}} نیز، پیش از شروع به کار پاد، +آن را دست‌کاری کرده و کانتینرهای سایدکار اضافی تزریق کنند. مکانیزم متداول برای **تزریق** +این سایدکارهای اضافی معمولاً +[وب‌هوک‌های تغییر‌دهنده (Mutating Webhooks)](/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook) +هستند. برای نمونه، یک افزودنی «سرویس مش» ممکن است سایدکاری تزریق کند که +TLS دوطرفه و رمزنگاری حین انتقال را میان پادهای مختلف پیکربندی می‌کند. + +با اینکه ایده کانتینرهای سایدکار تازگی ندارد، +پیاده‌سازی بومی این قابلیت در کوبرنتیس تازه است و—as با هر ویژگی تازه— +استفاده از آن می‌تواند چالش‌هایی به‌همراه داشته باشد. + +این راهنما به بررسی چالش‌ها و راهکارهایی می‌پردازد که ممکن است هم کاربران نهایی و +هم سازندگان کانتینرهای سایدکار با آن‌ها روبه‌رو شوند. + +## مزایای کانتینر sidecar داخلی + +استفاده از پشتیبانی بومی کوبرنتیس برای کانتینرهای سایدکار چندین مزیت دارد: + +1. می‌توانید یک کانتینر سایدکار بومی را طوری پیکربندی کنید که پیش از + {{< glossary_tooltip text="init containers" term_id="init-container" >}} اجرا شود. +1. کانتینرهای سایدکار داخلی را می‌توان طوری نوشت که تضمین شود آخرین کانتینرهایی باشند که خاتمه می‌یابند. + وقتی همه کانتینرهای معمولی کامل شده و خاتمه یافتند، به کانتینر سایدکار سیگنال `SIGTERM` فرستاده می‌شود. + اگر این کانتینر به‌طور تمیز متوقف نشود، سیگنال `SIGKILL` برای خاتمه آن به کار می‌رود. +1. در Jobها، زمانی که مقدار `restartPolicy` پاد `OnFailure` یا `Never` است، + کانتینرهای سایدکار بومی جلوی کامل شدن پاد را نمی‌گیرند؛ در حالی که برای کانتینرهای سایدکار قدیمی باید + تمهیدات ویژه‌ای در این حالت در نظر گرفته شود. +1. همچنین در Jobها، حتی اگر کانتینرهای معمولی با `restartPolicy: Never` دوباره اجرا نشوند، + کانتینرهای سایدکار داخلی پس از پایان دوباره راه‌اندازی می‌شوند. + +برای آگاهی بیش‌تر، بخش +[تفاوت‌ها با کانتینرهای init](/docs/concepts/workloads/pods/sidecar-containers/#differences-from-application-containers) +را مطالعه کنید. + +## استفاده از کانتینرهای sidecar داخلی + +درگاه ویژگی `SidecarContainers` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) +از نسخه ۱٫۲۹ کوبرنتیس در حالت بتا قرار دارد و به‌طور پیش‌فرض فعال است. +برخی خوشهها ممکن است این قابلیت را غیرفعال کرده باشند یا نرم‌افزاری نصب داشته باشند +که با آن ناسازگار باشد. + +در چنین شرایطی ممکن است پاد رد شود یا کانتینرهای سایدکار جلوی راه‌اندازی پاد را بگیرند +و پاد عملاً بی‌استفاده شود. تشخیص این وضعیت آسان است، زیرا پاد در مرحله +راه‌اندازی اولیه متوقف می‌شود؛ اما اغلب مشخص نیست چه عاملی باعث بروز مشکل شده است. + +در ادامه ملاحظات و گام‌های عیب‌یابی‌ای آورده شده است که هنگام به‌کارگیری کانتینرهای +سایدکار برای بارِ کاری خود می‌توانید از آن‌ها بهره ببرید. + +### مطمئن شوید که دروازه ویژگی فعال است + +به‌عنوان نخستین گام، مطمئن شوید که هم سرور API و هم نودها روی نسخه v1.29 یا بالاترِ کوبرنتیس باشند. این قابلیت در خوشههایی که نودهای آن نسخه‌های قدیمی‌تری اجرا می‌کنند—که در آن‌ها این ویژگی فعال نیست—از کار خواهد افتاد. + +{{< alert title="Note" color="info" >}} + +می‌توان این ویژگی را روی نودهایی با نسخه ۱٫۲۸ نیز فعال کرد. رفتار خاتمه کانتینر سایدکار داخلی در نسخه ۱٫۲۸ متفاوت بود و توصیه نمی‌شود که رفتار سایدکار را با آن هماهنگ کنید. بااین‌حال، اگر تنها نگرانی ترتیب راه‌اندازی است، می‌توان جمله بالا را به «نودهایی با نسخه ۱٫۲۸ و درگاه ویژگی فعال» تغییر داد. + +{{< /alert >}} + +باید اطمینان حاصل کنید که درگاه ویژگی هم برای سرور(های) API در صفحه کنترل **و** هم برای تمامی نودها فعال است. + +یکی از روش‌های بررسی فعال بودن درگاه ویژگی، اجرای دستوری مشابه زیر است: + +- برای سرور API: + + ```shell + kubectl get --raw /metrics | grep kubernetes_feature_enabled | grep SidecarContainers + ``` + +- برای گره منفرد: + + ```shell + kubectl get --raw /api/v1/nodes//proxy/metrics | grep kubernetes_feature_enabled | grep SidecarContainers + ``` + +اگر چیزی شبیه به این را دیدید: + +``` +kubernetes_feature_enabled{name="SidecarContainers",stage="BETA"} 1 +``` + +یعنی اینکه اون قابلیت فعال شده. + +### ابزارهای شخص ثالث و webhookهای تغییردهنده را بررسی کنید + +اگر هنگام ارزیابی این قابلیت با مشکل مواجه شدید، ممکن است نشان‌دهنده آن باشد که یکی از +ابزارهای شخص ثالث یا وب‌هوک‌های تغییردهنده دچار ایراد شده است. + +زمانی که درگاه ویژگی `SidecarContainers` فعال باشد، پادها یک فیلد جدید در API خود به دست می‌آورند. +برخی ابزارها یا وب‌هوک‌های تغییردهنده ممکن است با نسخه‌های قدیمی‌تر API کوبرنتیس ساخته شده باشند. + +اگر این ابزارها فیلدهای ناشناخته را همان‌گونه که هستند و با استفاده از راهبردهای مختلف وصله (patch) برای تغییر یک شیء پاد عبور دهند، مشکلی پیش نمی‌آید. بااین‌حال، ابزارهایی وجود دارند که +فیلدهای ناشناخته را حذف می‌کنند؛ در این صورت باید با نسخه v1.28+ از کد کلاینت API کوبرنتیس مجدداً کامپایل شوند. + +برای بررسی این موضوع می‌توانید از دستور `kubectl describe pod` روی پادی که از پذیرش تغییردهنده گذشته است استفاده کنید. اگر ابزارها فیلد جدید (`restartPolicy:Always`) را حذف کرده باشند، +این فیلد را در خروجی دستور نخواهید دید. + +اگر با چنین مشکلی روبه‌رو شدید، به نویسنده ابزار یا وب‌هوک توصیه کنید +به‌جای به‌روزرسانی کامل شیء، از یکی از راهبردهای وصله برای تغییر اشیا استفاده کند. + +{{< alert title="Note" color="info" >}} + +یک وب‌هوک تغییردهنده ممکن است بر اساس برخی شرایط پادها را به‌روزرسانی کند؛ +بنابراین، کانتینرهای سایدکار ممکن است برای برخی پادها کار کنند و برای برخی دیگر نه. + +{{< /alert >}} + +### تزریق خودکار sidecar + +اگر از نرم‌افزاری استفاده می‌کنید که به‌طور خودکار سایدکارها را تزریق می‌کند، +چند راهبرد وجود دارد که می‌توانید برای اطمینان از قابل استفاده بودن کانتینرهای سایدکار بومی دنبال کنید. +همه این راهبردها در اصل گزینه‌هایی هستند که می‌توانید انتخاب کنید تا تصمیم بگیرید +پادی که سایدکار در آن تزریق می‌شود روی نودی قرار بگیرد که این قابلیت را پشتیبانی می‌کند یا خیر. + +به‌عنوان نمونه می‌توانید +[این گفت‌وگو در جامعه Istio](https://github.com/istio/istio/issues/48794) را دنبال کنید. +این بحث گزینه‌های زیر را بررسی می‌کند. + +1. پادهایی را که روی نودهای پشتیبان سایدکار قرار می‌گیرند علامت‌گذاری کنید. + می‌توانید از برچسب‌های نود و وابستگی نود (node affinity) برای علامت‌گذاری نودهایی که از + کانتینرهای سایدکار پشتیبانی می‌کنند و پادهایی که روی آن نودها قرار می‌گیرند استفاده کنید. +1. سازگاری نودها را هنگام تزریق بررسی کنید. در زمان تزریق سایدکار می‌توانید + راهبردهای زیر را برای بررسی سازگاری نود به کار ببرید: + - نسخه نود را پرس‌وجو کرده و فرض کنید در نسخه ۱٫۲۹+ درگاه ویژگی فعال است + - متریک‌های پرومتئوس نود را پرس‌وجو کرده و وضعیت فعال بودن ویژگی را بررسی کنید + - فرض کنید نودها با [قوانین انحراف نسخه پشتیبانی‌شده](/releases/version-skew-policy/#supported-version-skew) + نسبت به سرور API در حال اجرا هستند + - روش‌های سفارشی دیگری نیز ممکن است برای تشخیص سازگاری نود وجود داشته باشد. +1. یک تزریق‌کننده سایدکار سراسری توسعه دهید. ایده یک تزریق‌کننده سایدکار سراسری این است که + یک کانتینر سایدکار را هم به‌عنوان کانتینر معمولی و هم به‌عنوان کانتینر سایدکار بومی تزریق کند + و منطقی در زمان اجرا داشته باشد تا تصمیم بگیرد کدام‌یک کار خواهد کرد. + تزریق‌کننده سایدکار سراسری منابع را دو بار مصرف می‌کند، زیرا درخواست‌ها را دو بار حساب می‌کند، + اما ممکن است به‌عنوان راهکاری عملی برای موارد ویژه در نظر گرفته شود. + - یک راه این است که در شروع کانتینر سایدکار بومی، + نسخه نود را تشخیص داده و اگر نسخه از ویژگی سایدکار پشتیبانی نمی‌کند فوراً خارج شود. + - طراحی تشخیص ویژگی در زمان اجرا را در نظر بگیرید: + - یک دایرکتوری خالی تعریف کنید تا کانتینرها بتوانند با هم ارتباط برقرار کنند + - یک کانتینر init تزریق کنید که آن را `NativeSidecar` بنامیم با `restartPolicy=Always`. + - `NativeSidecar` باید هنگام اولین اجرا فایلی در دایرکتوری خالی بنویسد و فوراً با کد خروج `0` خارج شود. + - `NativeSidecar` در اجرای مجدد (زمانی که سایدکارهای بومی پشتیبانی می‌شوند) بررسی می‌کند + که آن فایل در دایرکتوری وجود دارد و آن را تغییر می‌دهد—نشان می‌دهد کانتینرهای سایدکار داخلی + پشتیبانی شده و در حال اجرا هستند. + - یک کانتینر معمولی تزریق کنید که آن را `OldWaySidecar` بنامیم. + - `OldWaySidecar` در شروع وجود فایل را در دایرکتوری خالی بررسی می‌کند. + - اگر فایل نشان دهد که `NativeSidecar` در حال اجرا **نیست**، فرض می‌کند + ویژگی سایدکار پشتیبانی نمی‌شود و خودش را به‌عنوان سایدکار فعال می‌کند. + - اگر فایل نشان دهد که `NativeSidecar` در حال اجرا است، یا هیچ کاری انجام نمی‌دهد و همیشه می‌خوابد + (در حالتی که `restartPolicy=Always` برای پاد باشد) یا فوراً با کد خروج `0` خارج می‌شود + (در حالتی که `restartPolicy!=Always` باشد). + +## {{% heading "whatsnext" %}} + +- درباره [sidecar containers](/docs/concepts/workloads/pods/sidecar-containers/) بیشتر بدانید. diff --git a/content/fa/docs/tutorials/configuration/updating-configuration-via-a-configmap.md b/content/fa/docs/tutorials/configuration/updating-configuration-via-a-configmap.md new file mode 100644 index 0000000000000..6f58746b0da03 --- /dev/null +++ b/content/fa/docs/tutorials/configuration/updating-configuration-via-a-configmap.md @@ -0,0 +1,720 @@ +--- +title: به‌روزرسانی پیکربندی از طریق ConfigMap +content_type: tutorial +weight: 20 +--- + + +این صفحه یک مثال گام‌به‌گام از به‌روزرسانی پیکربندی داخل یک پاد از طریق یک ConfigMap ارائه می‌دهد و بر پایه وظیفه [پیکربندی یک پاد برای استفاده از یک ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) بنا شده است. +در پایان این آموزش، نحوه تغییر پیکربندی برای یک برنامه در حال اجرا را درک خواهید کرد. +در این آموزش از image `alpine` و `nginx` به‌عنوان نمونه استفاده شده است. + +## {{% heading "prerequisites" %}} +{{< include "task-tutorial-prereqs.md" >}} + +برای ارسال درخواست‌های HTTP از ترمینال یا خط فرمان، به ابزار خط فرمان [curl](https://curl.se/) نیاز دارید. +اگر `curl` روی سیستم شما در دسترس نیست، می‌توانید آن را نصب کنید. برای نصب، به مستندات سیستم‌عامل خود مراجعه کنید. + +## {{% heading "objectives" %}} +* به‌روزرسانی پیکربندی از طریق یک ConfigMap نصب‌شده به عنوان یک Volume +* به‌روزرسانی متغیرهای محیطی یک Pod از طریق یک ConfigMap +* به‌روزرسانی پیکربندی از طریق یک ConfigMap در یک Pod چندکانتینری +* به‌روزرسانی پیکربندی از طریق یک ConfigMap در یک Pod دارای یک کانتینر Sidecar + + + +## به‌روزرسانی پیکربندی از طریق یک ConfigMap که به عنوان یک Volume نصب شده است {#rollout-configmap-volume} + +از دستور `kubectl create configmap` برای ایجاد یک ConfigMap از +[مقادیر صریح](/docs/tasks/configure-pod-container/configure-pod-configmap/#create-configmaps-from-literal-values) استفاده کنید: + +```shell +kubectl create configmap sport --from-literal=sport=football +``` + +در زیر یک نمونه از مانیفست Deployment آورده شده است که ConfigMap با نام `sport` به عنوان یک +{{< glossary_tooltip text="volume" term_id="volume" >}} در تنها کانتینر پاد سوار (mount) شده است. +{{% code_sample file="deployments/deployment-with-configmap-as-volume.yaml" %}} + +Deployment را ایجاد کنید: + +```shell +kubectl apply -f https://k8s.io/examples/deployments/deployment-with-configmap-as-volume.yaml +``` + +پادهای این Deployment را بررسی کنید تا مطمئن شوید آماده هستند (با تطبیق بر اساس +{{< glossary_tooltip text="selector" term_id="selector" >}}): + +```shell +kubectl get pods --selector=app.kubernetes.io/name=configmap-volume +``` + +شما باید خروجی مشابه زیر را ببینید: + +``` +NAME READY STATUS RESTARTS AGE +configmap-volume-6b976dfdcf-qxvbm 1/1 Running 0 72s +configmap-volume-6b976dfdcf-skpvm 1/1 Running 0 72s +configmap-volume-6b976dfdcf-tbc6r 1/1 Running 0 72s +``` + +در هر نودی که یکی از این پادها اجرا می‌شود، kubelet داده‌های مربوط به آن ConfigMap را واکشی کرده و آن‌ها را به فایل‌هایی در یک volume محلی تبدیل می‌کند. +سپس kubelet آن volume را مطابق با الگوی پاد در کانتینر سوار (mount) می‌کند. +کدی که در کانتیر اجرا می‌شود، اطلاعات را از فایل بارگذاری کرده +و با استفاده از آن گزارشی را در stdout چاپ می‌کند. +می‌توانید این گزارش را با مشاهده لاگ‌های یکی از پادهای این Deployment بررسی کنید: + +```shell +# Pick one Pod that belongs to the Deployment, and view its logs +kubectl logs deployments/configmap-volume +``` + +شما باید خروجی مشابه زیر را ببینید: + +``` +Found 3 pods, using pod/configmap-volume-76d9c5678f-x5rgj +Thu Jan 4 14:06:46 UTC 2024 My preferred sport is football +Thu Jan 4 14:06:56 UTC 2024 My preferred sport is football +Thu Jan 4 14:07:06 UTC 2024 My preferred sport is football +Thu Jan 4 14:07:16 UTC 2024 My preferred sport is football +Thu Jan 4 14:07:26 UTC 2024 My preferred sport is football +``` + +ویرایش ConfigMap: + +```shell +kubectl edit configmap sport +``` + +در ویرایشگری که ظاهر می‌شود، مقدار کلید `sport` را از `football` به `cricket` تغییر دهید. تغییرات خود را ذخیره کنید. +ابزار kubectl، ConfigMap را بر این اساس به‌روزرسانی می‌کند (اگر خطایی مشاهده کردید، دوباره امتحان کنید). + +در اینجا مثالی از نحوه‌ی عملکرد مانیفست پس از ویرایش آن آورده شده است: + +```yaml +apiVersion: v1 +data: + sport: cricket +kind: ConfigMap +# You can leave the existing metadata as they are. +# The values you'll see won't exactly match these. +metadata: + creationTimestamp: "2024-01-04T14:05:06Z" + name: sport + namespace: default + resourceVersion: "1743935" + uid: 024ee001-fe72-487e-872e-34d6464a8a23 +``` + +شما باید خروجی زیر را ببینید: + +``` +configmap/sport edited +``` + +لاگ‌های یکی از پادهای متعلق به این استقرار را دنبال کنید (آخرین مطالب را دنبال کنید): + +```shell +kubectl logs deployments/configmap-volume --follow +``` + +پس از چند ثانیه، باید تغییر خروجی لاگ را به صورت زیر مشاهده کنید: + +``` +Thu Jan 4 14:11:36 UTC 2024 My preferred sport is football +Thu Jan 4 14:11:46 UTC 2024 My preferred sport is football +Thu Jan 4 14:11:56 UTC 2024 My preferred sport is football +Thu Jan 4 14:12:06 UTC 2024 My preferred sport is cricket +Thu Jan 4 14:12:16 UTC 2024 My preferred sport is cricket +``` + +هنگامی که یک ConfigMap را با استفاده از یک ولوم `configMap` یا یک ولوم `projected` در یک پاد در حال اجرا نگاشت کرده باشید و آن ConfigMap را به‌روزرسانی کنید، پاد در حال اجرا تقریباً بلافاصله این تغییر را تشخیص می‌دهد. +با این حال، برنامه شما تنها در صورتی متوجه این تغییر می‌شود که طوری نوشته شده باشد که یا به‌صورت دوره‌ای برای تغییرات، پرس‌و‌جو (poll) کند یا به‌روزرسانی فایل را پایش (watch) نماید. +برنامه‌ای که پیکربندی خود را فقط در زمان راه‌اندازی بارگذاری می‌کند، متوجه این تغییر نخواهد شد. + +{{< note >}} +کل تأخیر از لحظه به‌روزرسانی ConfigMap تا زمانی که کلیدهای جدید در پاد منعکس شوند، می‌تواند به‌اندازه دوره همگام‌سازی kubelet طول بکشد. +همچنین [ConfigMapهای سوارشده به‌طور خودکار به‌روز می‌شوند](/docs/tasks/configure-pod-container/configure-pod-configmap/#mounted-configmaps-are-updated-automatically) را نیز بررسی کنید. +{{< /note >}} + +## به‌روزرسانی متغیرهای محیطی یک Pod از طریق ConfigMap {#rollout-configmap-env} + +از دستور `kubectl create configmap` برای ایجاد یک ConfigMap از +[مقادیر صریح](/docs/tasks/configure-pod-container/configure-pod-configmap/#create-configmaps-from-literal-values) استفاده کنید: + +```shell +kubectl create configmap fruits --from-literal=fruits=apples +``` + +در زیر مثالی از مانیفست استقرار با متغیر محیطی پیکربندی شده از طریق ConfigMap `fruits` آورده شده است. + +{{% code_sample file="deployments/deployment-with-configmap-as-envvar.yaml" %}} + +ایجاد استقرار: + +```shell +kubectl apply -f https://k8s.io/examples/deployments/deployment-with-configmap-as-envvar.yaml +``` + +پادهای این Deployment را بررسی کنید تا مطمئن شوید آماده هستند (با تطبیق بر اساس +{{< glossary_tooltip text="selector" term_id="selector" >}}): + +```shell +kubectl get pods --selector=app.kubernetes.io/name=configmap-env-var +``` + +شما باید خروجی مشابه زیر را ببینید: + +``` +NAME READY STATUS RESTARTS AGE +configmap-env-var-59cfc64f7d-74d7z 1/1 Running 0 46s +configmap-env-var-59cfc64f7d-c4wmj 1/1 Running 0 46s +configmap-env-var-59cfc64f7d-dpr98 1/1 Running 0 46s +``` + +جفت کلید-مقدار در ConfigMap به عنوان یک متغیر محیطی در کانتینر Pod پیکربندی شده است. +این را با مشاهده گزارش‌های یک Pod که متعلق به Deployment است، بررسی کنید. + +```shell +kubectl logs deployment/configmap-env-var +``` + +شما باید خروجی مشابه زیر را ببینید: + +``` +Found 3 pods, using pod/configmap-env-var-7c994f7769-l74nq +Thu Jan 4 16:07:06 UTC 2024 The basket is full of apples +Thu Jan 4 16:07:16 UTC 2024 The basket is full of apples +Thu Jan 4 16:07:26 UTC 2024 The basket is full of apples +``` + +ویرایش ConfigMap: + +```shell +kubectl edit configmap fruits +``` + +در ویرایشگری که ظاهر می‌شود، مقدار کلید `fruits` را از `apples` به `mangoes` تغییر دهید. تغییرات خود را ذخیره کنید. +ابزار kubectl، ConfigMap را بر این اساس به‌روزرسانی می‌کند (اگر خطایی مشاهده کردید، دوباره امتحان کنید). +در اینجا مثالی از نحوه‌ی عملکرد مانیفست پس از ویرایش آن آورده شده است: + +```yaml +apiVersion: v1 +data: + fruits: mangoes +kind: ConfigMap +# You can leave the existing metadata as they are. +# The values you'll see won't exactly match these. +metadata: + creationTimestamp: "2024-01-04T16:04:19Z" + name: fruits + namespace: default + resourceVersion: "1749472" +``` + +شما باید خروجی زیر را ببینید: + +``` +configmap/fruits edited +``` + +لاگ‌های Deployment را دنبال کنید و خروجی را برای چند ثانیه مشاهده کنید: + +```shell +# As the text explains, the output does NOT change +kubectl logs deployments/configmap-env-var --follow +``` + +توجه داشته باشید که خروجی **بدون تغییر** باقی می‌ماند، حتی با اینکه ConfigMap را ویرایش کرده‌اید: + +``` +Thu Jan 4 16:12:56 UTC 2024 The basket is full of apples +Thu Jan 4 16:13:06 UTC 2024 The basket is full of apples +Thu Jan 4 16:13:16 UTC 2024 The basket is full of apples +Thu Jan 4 16:13:26 UTC 2024 The basket is full of apples +``` + +{{< note >}} +گرچه مقدار کلید درون ConfigMap تغییر کرده است، متغیر محیطی در پاد هنوز مقدار قبلی را نمایش می‌دهد. دلیل این امر آن است که متغیرهای محیطی برای یک فرایند در حال اجرا داخل یک پاد هنگام تغییر داده منبع **به‌روزرسانی نمی‌شوند**؛ اگر بخواهید این به‌روزرسانی را وادار کنید، لازم است کوبرنتیز پادهای موجود شما را جایگزین کند. +پادهای جدید سپس با اطلاعات به‌روزشده اجرا خواهند شد. +{{< /note >}} + +می‌توانید این جایگزینی را آغاز کنید. با استفاده از [`kubectl rollout`](/docs/reference/kubectl/generated/kubectl_rollout/) یک rollout برای Deployment انجام دهید: + +```shell +# Trigger the rollout +kubectl rollout restart deployment configmap-env-var + +# Wait for the rollout to complete +kubectl rollout status deployment configmap-env-var --watch=true +``` + +در مرحله بعد، Deployment را بررسی کنید: + +```shell +kubectl get deployment configmap-env-var +``` + +شما باید خروجی مشابه زیر را ببینید: + +``` +NAME READY UP-TO-DATE AVAILABLE AGE +configmap-env-var 3/3 3 3 12m +``` + +پادها را بررسی کنید: + +```shell +kubectl get pods --selector=app.kubernetes.io/name=configmap-env-var +``` + +اجرای رول‌اوت باعث می‌شود کوبرنتیز یک {{< glossary_tooltip term_id="replica-set" text="ReplicaSet" >}} +جدید برای Deployment بسازد؛ یعنی پادهای موجود در نهایت خاتمه می‌یابند و پادهای جدید ایجاد می‌شوند. +پس از چند ثانیه باید خروجی‌ای مشابه زیر مشاهده کنید: + +``` +NAME READY STATUS RESTARTS AGE +configmap-env-var-6d94d89bf5-2ph2l 1/1 Running 0 13s +configmap-env-var-6d94d89bf5-74twx 1/1 Running 0 8s +configmap-env-var-6d94d89bf5-d5vx8 1/1 Running 0 11s +``` + +{{< note >}} +لطفاً قبل از ادامه مراحل بعدی، منتظر بمانید تا پادهای قدیمی‌تر به‌طور کامل از کار بیفتند. +{{< /note >}} + +مشاهده گزارش‌های مربوط به یک Pod در این استقرار: + +```shell +# Pick one Pod that belongs to the Deployment, and view its logs +kubectl logs deployment/configmap-env-var +``` + +شما باید خروجی مشابه زیر را ببینید: + +``` +Found 3 pods, using pod/configmap-env-var-6d9ff89fb6-bzcf6 +Thu Jan 4 16:30:35 UTC 2024 The basket is full of mangoes +Thu Jan 4 16:30:45 UTC 2024 The basket is full of mangoes +Thu Jan 4 16:30:55 UTC 2024 The basket is full of mangoes +``` + +این سناریوی به‌روزرسانی متغیرهای محیطی در یک Pod که از یک ConfigMap مشتق شده‌اند را نشان می‌دهد. تغییرات در مقادیر ConfigMap در طول انتشار بعدی به Pod اعمال می‌شوند. اگر Podها به دلیل دیگری مانند افزایش مقیاس Deployment ایجاد شوند، Podهای جدید نیز از آخرین مقادیر پیکربندی استفاده می‌کنند. اگر انتشار را آغاز نکنید، ممکن است متوجه شوید که برنامه شما با ترکیبی از مقادیر متغیرهای محیطی قدیمی و جدید اجرا می‌شود. + +## به‌روزرسانی پیکربندی از طریق ConfigMap در یک Pod چندکانتینری {#rollout-configmap-multiple-containers} + +از دستور `kubectl create configmap` برای ایجاد یک ConfigMap از +[مقادیر ثابت](/docs/tasks/configure-pod-container/configure-pod-configmap/#create-configmaps-from-literal-values) استفاده کنید: + +```shell +kubectl create configmap color --from-literal=color=red +``` + +در ادامه یک نمونه مانیفست برای یک Deployment آورده شده است که مجموعه‌ای از پادها را مدیریت می‌کند و هر پاد دو کانتینر دارد. +این دو کانتینر یک حجم `emptyDir`‌ را به اشتراک می‌گذارند که برای برقراری ارتباط از آن استفاده می‌کنند. +کانتینر نخست یک وب‌سرور (`nginx`) را اجرا می‌کند و مسیر مانت این حجمِ مشترک در آن،‌ `/usr/share/nginx/html` است. +کانتینر کمکی دوم بر پایه `alpine` ساخته شده و در این کانتینر، حجم `emptyDir` در مسیر `/pod-data` مانت می‌شود. +کانتینر کمکی فایلی HTML می‌نویسد که محتوای آن بر اساس یک ConfigMap است؛ +کانتینر وب‌سرور این فایل HTML را از طریق HTTP ارائه می‌دهد. + +{{% code_sample file="deployments/deployment-with-configmap-two-containers.yaml" %}} + +ایجاد Deployment: + +```shell +kubectl apply -f https://k8s.io/examples/deployments/deployment-with-configmap-two-containers.yaml +``` + +پادهای این Deployment را بررسی کنید تا مطمئن شوید آماده هستند (با تطبیق بر اساس +{{< glossary_tooltip text="selector" term_id="selector" >}}): + +```shell +kubectl get pods --selector=app.kubernetes.io/name=configmap-two-containers +``` + +شما باید خروجی مشابه زیر را ببینید: + +``` +NAME READY STATUS RESTARTS AGE +configmap-two-containers-565fb6d4f4-2xhxf 2/2 Running 0 20s +configmap-two-containers-565fb6d4f4-g5v4j 2/2 Running 0 20s +configmap-two-containers-565fb6d4f4-mzsmf 2/2 Running 0 20s +``` + +نمایش Deployment (ابزار `kubectl` یک {{}} برای شما ایجاد می‌کند): + +```shell +kubectl expose deployment configmap-two-containers --name=configmap-service --port=8080 --target-port=80 +``` + +برای ارسال پورت از `kubectl` استفاده کنید: + +```shell +# this stays running in the background +kubectl port-forward service/configmap-service 8080:8080 & +``` + +به سرویس دسترسی پیدا کنید. + +```shell +curl http://localhost:8080 +``` + +شما باید خروجی مشابه زیر را ببینید: + +``` +Fri Jan 5 08:08:22 UTC 2024 My preferred color is red +``` + +ویرایش ConfigMap: + +```shell +kubectl edit configmap color +``` + +در ویرایشگری که ظاهر می‌شود، مقدار کلید `color` را از `red` به `blue` تغییر دهید. تغییرات خود را ذخیره کنید. +ابزار kubectl، ConfigMap را بر این اساس به‌روزرسانی می‌کند (اگر خطایی مشاهده کردید، دوباره امتحان کنید). + +در اینجا مثالی از نحوه‌ی نمایش مانیفست پس از ویرایش آن آورده شده است: + +```yaml +apiVersion: v1 +data: + color: blue +kind: ConfigMap +# می‌توانید فراداده‌های موجود را به همان صورت که هستند، رها کنید. +# مقادیری که خواهید دید دقیقاً با این مقادیر مطابقت نخواهند داشت. +metadata: + creationTimestamp: "2024-01-05T08:12:05Z" + name: color + namespace: configmap + resourceVersion: "1801272" + uid: 80d33e4a-cbb4-4bc9-ba8c-544c68e425d6 +``` + +برای چند ثانیه روی URL سرویس بچرخید. + +```shell +# وقتی از آن راضی بودید، آن را لغو کنید (Ctrl-C) +while true; do curl --connect-timeout 7.5 http://localhost:8080; sleep 10; done +``` + +باید ببینید که خروجی به شکل زیر تغییر می‌کند: + +``` +Fri Jan 5 08:14:00 UTC 2024 My preferred color is red +Fri Jan 5 08:14:02 UTC 2024 My preferred color is red +Fri Jan 5 08:14:20 UTC 2024 My preferred color is red +Fri Jan 5 08:14:22 UTC 2024 My preferred color is red +Fri Jan 5 08:14:32 UTC 2024 My preferred color is blue +Fri Jan 5 08:14:43 UTC 2024 My preferred color is blue +Fri Jan 5 08:15:00 UTC 2024 My preferred color is blue +``` + +## به‌روزرسانی پیکربندی از طریق ConfigMap در یک Pod دارای کانتینر sidecar {#rollout-configmap-sidecar} + +می‌توان سناریوی بالا را با استفاده از یک [کانتینر سایدکار](/docs/concepts/workloads/pods/sidecar-containers/) +به‌عنوان کانتینر کمکی برای نوشتن فایل HTML بازآفرینی کرد. +از آنجا که یک کانتینر سایدکار از نظر مفهومی همانند یک Init Container است، تضمین می‌شود که پیش از کانتینر اصلی وب‌سرور آغاز به کار کند. +به این ترتیب، اطمینان حاصل می‌شود که فایل HTML همواره زمانی که وب‌سرور آماده ارائه آن است در دسترس باشد. + +اگر از سناریوی قبلی ادامه می‌دهید، می‌توانید ConfigMap‌ با نام `color` را برای این سناریو دوباره به‌ کار ببرید. +اگر این سناریو را به‌طور مستقل اجرا می‌کنید، با دستور `kubectl create configmap` +از [مقادیر ثابت](/docs/tasks/configure-pod-container/configure-pod-configmap/#create-configmaps-from-literal-values) یک ConfigMap ایجاد کنید: + +```shell +kubectl create configmap color --from-literal=color=blue +``` + +در ادامه یک نمونه مانیفست برای یک Deployment آورده شده است که مجموعه‌ای از پادها را مدیریت می‌کند؛ هر پاد یک کانتینر اصلی و یک کانتینر سایدکار دارد. +این دو کانتینر یک حجم `emptyDir` را برای برقراری ارتباط به‌اشتراک می‌گذارند. +کانتینر اصلی یک وب‌سرور (NGINX) را اجرا می‌کند و مسیر مانت این حجم مشترک در آن `/usr/share/nginx/html` است. +کانتینر دوم یک کانتینر سایدکار بر پایه Alpine Linux است که نقش کانتینر کمکی را دارد. در این کانتینر، حجم `emptyDir` در مسیر `/pod-data` مانت می‌شود. +کانتینر سایدکار فایلی HTML ایجاد می‌کند که محتوای آن بر اساس یک ConfigMap است؛ کانتینر وب‌سرور این فایل HTML را از طریق HTTP ارائه می‌دهد. + +{{% code_sample file="deployments/deployment-with-configmap-and-sidecar-container.yaml" %}} + +ایجاد Deployment: + +```shell +kubectl apply -f https://k8s.io/examples/deployments/deployment-with-configmap-and-sidecar-container.yaml +``` + +پادهای این Deployment را بررسی کنید تا از آماده بودن آنها اطمینان حاصل کنید (مطابق با {{< glossary_tooltip text="selector" term_id="selector" >}}): + +```shell +kubectl get pods --selector=app.kubernetes.io/name=configmap-sidecar-container +``` + +شما باید خروجی مشابه زیر را ببینید: + +``` +NAME READY STATUS RESTARTS AGE +configmap-sidecar-container-5fb59f558b-87rp7 2/2 Running 0 94s +configmap-sidecar-container-5fb59f558b-ccs7s 2/2 Running 0 94s +configmap-sidecar-container-5fb59f558b-wnmgk 2/2 Running 0 94s +``` + +نمایش Deployment (ابزار `kubectl` یک {{}} برای شما ایجاد می‌کند): + + +```shell +kubectl expose deployment configmap-sidecar-container --name=configmap-sidecar-service --port=8081 --target-port=80 +``` + +برای ارسال پورت از `kubectl` استفاده کنید: + +```shell +# این در پس‌زمینه اجرا می‌شود +kubectl port-forward service/configmap-sidecar-service 8081:8081 & +``` + +به سرویس دسترسی پیدا کنید. + +```shell +curl http://localhost:8081 +``` + +شما باید خروجی مشابه زیر را ببینید: + +``` +Sat Feb 17 13:09:05 UTC 2024 My preferred color is blue +``` + +ویرایش ConfigMap: + +```shell +kubectl edit configmap color +``` + +در ویرایشگری که ظاهر می‌شود، مقدار کلید `color` را از `blue` به `green` تغییر دهید. تغییرات خود را ذخیره کنید. +ابزار kubectl، ConfigMap را بر این اساس به‌روزرسانی می‌کند (اگر خطایی مشاهده کردید، دوباره امتحان کنید). + +در اینجا مثالی از نحوه‌ی نمایش مانیفست پس از ویرایش آن آورده شده است: + +```yaml +apiVersion: v1 +data: + color: green +kind: ConfigMap +# می‌توانید فراداده‌های موجود را به همان صورت که هستند، رها کنید. +# مقادیری که خواهید دید دقیقاً با این مقادیر مطابقت نخواهند داشت. +metadata: + creationTimestamp: "2024-02-17T12:20:30Z" + name: color + namespace: default + resourceVersion: "1054" + uid: e40bb34c-58df-4280-8bea-6ed16edccfaa +``` + +برای چند ثانیه روی URL سرویس بچرخید. + +```shell +# وقتی از آن راضی بودید، آن را لغو کنید (Ctrl-C) +while true; do curl --connect-timeout 7.5 http://localhost:8081; sleep 10; done +``` + +باید ببینید که خروجی به شکل زیر تغییر می‌کند: + +``` +Sat Feb 17 13:12:35 UTC 2024 My preferred color is blue +Sat Feb 17 13:12:45 UTC 2024 My preferred color is blue +Sat Feb 17 13:12:55 UTC 2024 My preferred color is blue +Sat Feb 17 13:13:05 UTC 2024 My preferred color is blue +Sat Feb 17 13:13:15 UTC 2024 My preferred color is green +Sat Feb 17 13:13:25 UTC 2024 My preferred color is green +Sat Feb 17 13:13:35 UTC 2024 My preferred color is green +``` + +## پیکربندی را از طریق یک ConfigMap تغییرناپذیر که به عنوان یک volume نصب شده است، به‌روزرسانی کنید. {#rollout-configmap-immutable-volume} + +{{< note >}} +ConfigMapهای تغییرناپذیر (Immutable) به‌طور ویژه برای پیکربندی‌هایی استفاده می‌شوند که ثابت هستند و انتظار **نمی‌رود** در گذر زمان تغییر کنند. علامت‌گذاری یک ConfigMap به‌عنوان «تغییرناپذیر» به گونه‌ای است که موجب بهبود عملکرد می‌شود؛ زیرا kubelet دیگر برای یافتن تغییرات آن را پایش نمی‌کند. + +اگر نیاز داشتید تغییری اعمال کنید، باید یکی از کارهای زیر را در نظر بگیرید: + +- نام ConfigMap را عوض کنید و سپس پادهایی را اجرا کنید که به نام جدید ارجاع می‌دهند +- تمام نودهای خوشه را که پیش‌تر پادی با مقدار قدیمی اجرا کرده‌اند، جایگزین کنید +- kubelet را در هر نودی که قبلاً ConfigMap قدیمی را بارگذاری کرده، بازراه‌اندازی (restart) کنید +{{< /note >}} + +در ادامه مانیفست نمونه‌ای برای یک [ConfigMap تغییرناپذیر](/docs/concepts/configuration/configmap/#configmap-immutable) نمایش داده شده است. +{{% code_sample file="configmap/immutable-configmap.yaml" %}} + +ConfigMap تغییرناپذیر را ایجاد کنید: + +```shell +kubectl apply -f https://k8s.io/examples/configmap/immutable-configmap.yaml +``` + +در زیر مثالی از یک مانیفست Deployment با ConfigMap تغییرناپذیر `company-name-20150801` که به عنوان یک {{< glossary_tooltip text="volume" term_id="volume" >}} در تنها کانتینر Pod نصب شده است، آورده شده است. + +{{% code_sample file="deployments/deployment-with-immutable-configmap-as-volume.yaml" %}} + +ایجاد Deployment: + +```shell +kubectl apply -f https://k8s.io/examples/deployments/deployment-with-immutable-configmap-as-volume.yaml +``` + +پادهای این Deployment را بررسی کنید تا از آماده بودن آنها اطمینان حاصل کنید (مطابق با {{< glossary_tooltip text="selector" term_id="selector" >}}): + +```shell +kubectl get pods --selector=app.kubernetes.io/name=immutable-configmap-volume +``` + +شما باید خروجی مشابه زیر را ببینید: + +``` +NAME READY STATUS RESTARTS AGE +immutable-configmap-volume-78b6fbff95-5gsfh 1/1 Running 0 62s +immutable-configmap-volume-78b6fbff95-7vcj4 1/1 Running 0 62s +immutable-configmap-volume-78b6fbff95-vdslm 1/1 Running 0 62s +``` + +کانتینر Pod به داده‌های تعریف‌شده در ConfigMap اشاره دارد و از آن برای چاپ گزارش در stdout استفاده می‌کند. می‌توانید این گزارش را با مشاهده گزارش‌های مربوط به یکی از Podها در آن Deployment بررسی کنید: + +```shell +# یک Pod متعلق به Deployment را انتخاب کنید و گزارش‌های آن را مشاهده کنید +kubectl logs deployments/immutable-configmap-volume +``` + +شما باید خروجی مشابه زیر را ببینید: + +``` +Found 3 pods, using pod/immutable-configmap-volume-78b6fbff95-5gsfh +Wed Mar 20 03:52:34 UTC 2024 The name of the company is ACME, Inc. +Wed Mar 20 03:52:44 UTC 2024 The name of the company is ACME, Inc. +Wed Mar 20 03:52:54 UTC 2024 The name of the company is ACME, Inc. +``` + +{{< note >}} +وقتی یک ConfigMap به‌عنوان «تغییرناپذیر» (immutable) علامت‌گذاری شود، دیگر نمی‌توان این تغییر را برگرداند +و نه محتوای فیلدهای `data` یا `binaryData` را دست‌کاری کرد. +برای تغییر رفتار پادهایی که از این پیکربندی استفاده می‌کنند، +باید یک ConfigMap تغییرناپذیر جدید بسازید و Deployment را ویرایش کنید +تا یک الگوی پاد کمی متفاوت تعریف کند که به ConfigMap جدید ارجاع می‌دهد. +{{< /note >}} + +یک ConfigMap تغییرناپذیر جدید با استفاده از مانیفست زیر ایجاد کنید: + +{{% code_sample file="configmap/new-immutable-configmap.yaml" %}} + +```shell +kubectl apply -f https://k8s.io/examples/configmap/new-immutable-configmap.yaml +``` + +شما باید خروجی مشابه زیر را ببینید: + +``` +configmap/company-name-20240312 created +``` + +ConfigMap تازه ایجاد شده را بررسی کنید: + +```shell +kubectl get configmap +``` + +شما باید خروجی‌ای را ببینید که هر دو ConfigMaps قدیمی و جدید را نمایش می‌دهد: + +``` +NAME DATA AGE +company-name-20150801 1 22m +company-name-20240312 1 24s +``` + +Deployment را برای ارجاع به ConfigMap جدید تغییر دهید. + +ویرایش Deployment: + +```shell +kubectl edit deployment immutable-configmap-volume +``` + +در ویرایشگری که ظاهر می‌شود، تعریف حجم موجود را به‌روزرسانی کنید تا از ConfigMap جدید استفاده کند. + +```yaml +volumes: +- configMap: + defaultMode: 420 + name: company-name-20240312 # Update this field + name: config-volume +``` + +شما باید خروجی زیر را ببینید: + +``` +deployment.apps/immutable-configmap-volume edited +``` + +این باعث راه‌اندازی یک به‌روزرسانی می‌شود. منتظر بمانید تا تمام پادهای قبلی خاتمه یابند و پادهای جدید در حالت آماده قرار گیرند. + +وضعیت پادها را زیر نظر داشته باشید: + +```shell +kubectl get pods --selector=app.kubernetes.io/name=immutable-configmap-volume +``` + +``` +NAME READY STATUS RESTARTS AGE +immutable-configmap-volume-5fdb88fcc8-29v8n 1/1 Running 0 13s +immutable-configmap-volume-5fdb88fcc8-52ddd 1/1 Running 0 14s +immutable-configmap-volume-5fdb88fcc8-n5jx4 1/1 Running 0 15s +immutable-configmap-volume-78b6fbff95-5gsfh 1/1 Terminating 0 32m +immutable-configmap-volume-78b6fbff95-7vcj4 1/1 Terminating 0 32m +immutable-configmap-volume-78b6fbff95-vdslm 1/1 Terminating 0 32m +``` + +در نهایت باید خروجی مشابه زیر را مشاهده کنید: + +``` +NAME READY STATUS RESTARTS AGE +immutable-configmap-volume-5fdb88fcc8-29v8n 1/1 Running 0 43s +immutable-configmap-volume-5fdb88fcc8-52ddd 1/1 Running 0 44s +immutable-configmap-volume-5fdb88fcc8-n5jx4 1/1 Running 0 45s +``` + +مشاهده گزارش‌های مربوط به یک Pod در این استقرار: + +```shell +# Pick one Pod that belongs to the Deployment, and view its logs +kubectl logs deployment/immutable-configmap-volume +``` + +شما باید خروجی مشابه زیر را ببینید: + +``` +Found 3 pods, using pod/immutable-configmap-volume-5fdb88fcc8-n5jx4 +Wed Mar 20 04:24:17 UTC 2024 The name of the company is Fiktivesunternehmen GmbH +Wed Mar 20 04:24:27 UTC 2024 The name of the company is Fiktivesunternehmen GmbH +Wed Mar 20 04:24:37 UTC 2024 The name of the company is Fiktivesunternehmen GmbH +``` + +پس از اینکه تمام پیاده‌سازی‌ها برای استفاده از ConfigMap تغییرناپذیر جدید مهاجرت کردند، توصیه می‌شود که نسخه قدیمی را حذف کنید. + +```shell +kubectl delete configmap company-name-20150801 +``` + +## خلاصه + +تغییرات در یک ConfigMap که به عنوان یک Volume روی یک Pod نصب شده است، پس از همگام‌سازی بعدی kubelet به طور یکپارچه در دسترس هستند. + +تغییرات در یک ConfigMap که متغیرهای محیطی را برای یک Pod پیکربندی می‌کند، پس از راه‌اندازی بعدی برای Pod در دسترس هستند. + +هنگامی که یک ConfigMap به عنوان تغییرناپذیر علامت‌گذاری می‌شود، امکان بازگشت این تغییر وجود ندارد (شما نمی‌توانید یک ConfigMap تغییرناپذیر را تغییرپذیر کنید) و همچنین نمی‌توانید هیچ تغییری در محتوای `data` یا فیلد `binaryData` ایجاد کنید. می‌توانید ConfigMap را حذف و دوباره ایجاد کنید، یا می‌توانید یک ConfigMap متفاوت جدید ایجاد کنید. هنگامی که یک ConfigMap را حذف می‌کنید، کانتینرهای در حال اجرا و Podهای آنها یک نقطه اتصال به هر Volume که به آن ConfigMap موجود ارجاع داده است، حفظ می‌کنند. + +## {{% heading "cleanup" %}} + +در صورت اجرا، دستورات `kubectl port-forward` را خاتمه دهید. + +منابع ایجاد شده در طول آموزش را حذف کنید: + +```shell +kubectl delete deployment configmap-volume configmap-env-var configmap-two-containers configmap-sidecar-container immutable-configmap-volume +kubectl delete service configmap-service configmap-sidecar-service +kubectl delete configmap sport fruits color company-name-20240312 + +kubectl delete configmap company-name-20150801 # در صورتی که در حین اجرای وظیفه(Task) رسیدگی نشده باشد +``` diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/badge-01.svg b/content/fa/docs/tutorials/kubernetes-basics/public/images/badge-01.svg new file mode 100644 index 0000000000000..8354a3e47b819 --- /dev/null +++ b/content/fa/docs/tutorials/kubernetes-basics/public/images/badge-01.svg @@ -0,0 +1 @@ +16.07.28_K8S_badge \ No newline at end of file diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/badge-02.svg b/content/fa/docs/tutorials/kubernetes-basics/public/images/badge-02.svg new file mode 100644 index 0000000000000..0179f9b3bb29b --- /dev/null +++ b/content/fa/docs/tutorials/kubernetes-basics/public/images/badge-02.svg @@ -0,0 +1 @@ +16.07.28_K8S_badge \ No newline at end of file diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/badge-03.svg b/content/fa/docs/tutorials/kubernetes-basics/public/images/badge-03.svg new file mode 100644 index 0000000000000..bae5d5a9b083f --- /dev/null +++ b/content/fa/docs/tutorials/kubernetes-basics/public/images/badge-03.svg @@ -0,0 +1 @@ +16.07.28_K8S_badge \ No newline at end of file diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/badge-04.svg b/content/fa/docs/tutorials/kubernetes-basics/public/images/badge-04.svg new file mode 100644 index 0000000000000..d54fcdf8202f3 --- /dev/null +++ b/content/fa/docs/tutorials/kubernetes-basics/public/images/badge-04.svg @@ -0,0 +1 @@ +16.07.28_K8S_badge \ No newline at end of file diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/badge-05.svg b/content/fa/docs/tutorials/kubernetes-basics/public/images/badge-05.svg new file mode 100644 index 0000000000000..07c9a64399e99 --- /dev/null +++ b/content/fa/docs/tutorials/kubernetes-basics/public/images/badge-05.svg @@ -0,0 +1 @@ +16.07.28_K8S_badge \ No newline at end of file diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/badge-06.svg b/content/fa/docs/tutorials/kubernetes-basics/public/images/badge-06.svg new file mode 100644 index 0000000000000..4d12b74c160b1 --- /dev/null +++ b/content/fa/docs/tutorials/kubernetes-basics/public/images/badge-06.svg @@ -0,0 +1 @@ +16.07.28_K8S_badge \ No newline at end of file diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/badge-07.svg b/content/fa/docs/tutorials/kubernetes-basics/public/images/badge-07.svg new file mode 100644 index 0000000000000..da3b5bcfb2c97 --- /dev/null +++ b/content/fa/docs/tutorials/kubernetes-basics/public/images/badge-07.svg @@ -0,0 +1 @@ +16.07.28_K8S_badge \ No newline at end of file diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/badge-08.svg b/content/fa/docs/tutorials/kubernetes-basics/public/images/badge-08.svg new file mode 100644 index 0000000000000..9a36550166b0f --- /dev/null +++ b/content/fa/docs/tutorials/kubernetes-basics/public/images/badge-08.svg @@ -0,0 +1 @@ +16.07.28_K8S_badge \ No newline at end of file diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/badge-09.svg b/content/fa/docs/tutorials/kubernetes-basics/public/images/badge-09.svg new file mode 100644 index 0000000000000..da3b5bcfb2c97 --- /dev/null +++ b/content/fa/docs/tutorials/kubernetes-basics/public/images/badge-09.svg @@ -0,0 +1 @@ +16.07.28_K8S_badge \ No newline at end of file diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/badge-1.png b/content/fa/docs/tutorials/kubernetes-basics/public/images/badge-1.png new file mode 100644 index 0000000000000..8853f855bec23 Binary files /dev/null and b/content/fa/docs/tutorials/kubernetes-basics/public/images/badge-1.png differ diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/dislike.svg b/content/fa/docs/tutorials/kubernetes-basics/public/images/dislike.svg new file mode 100644 index 0000000000000..510103ea20dde --- /dev/null +++ b/content/fa/docs/tutorials/kubernetes-basics/public/images/dislike.svg @@ -0,0 +1 @@ +16.07.27_K8S_like_dislike \ No newline at end of file diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/like.svg b/content/fa/docs/tutorials/kubernetes-basics/public/images/like.svg new file mode 100644 index 0000000000000..f2365bbcc9c84 --- /dev/null +++ b/content/fa/docs/tutorials/kubernetes-basics/public/images/like.svg @@ -0,0 +1 @@ +16.07.27_K8S_like_dislike \ No newline at end of file diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/logo.png b/content/fa/docs/tutorials/kubernetes-basics/public/images/logo.png new file mode 100644 index 0000000000000..44d3512221ace Binary files /dev/null and b/content/fa/docs/tutorials/kubernetes-basics/public/images/logo.png differ diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/logo.svg b/content/fa/docs/tutorials/kubernetes-basics/public/images/logo.svg new file mode 100644 index 0000000000000..4f8413b1c0494 --- /dev/null +++ b/content/fa/docs/tutorials/kubernetes-basics/public/images/logo.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/logo_2.svg b/content/fa/docs/tutorials/kubernetes-basics/public/images/logo_2.svg new file mode 100644 index 0000000000000..7833a726b3baa --- /dev/null +++ b/content/fa/docs/tutorials/kubernetes-basics/public/images/logo_2.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/logo_mobile.png b/content/fa/docs/tutorials/kubernetes-basics/public/images/logo_mobile.png new file mode 100644 index 0000000000000..7eac53acf7248 Binary files /dev/null and b/content/fa/docs/tutorials/kubernetes-basics/public/images/logo_mobile.png differ diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/module_01.svg b/content/fa/docs/tutorials/kubernetes-basics/public/images/module_01.svg new file mode 100644 index 0000000000000..a1c42e9d658a0 --- /dev/null +++ b/content/fa/docs/tutorials/kubernetes-basics/public/images/module_01.svg @@ -0,0 +1 @@ +16.07.28_k8s_visual_diagrams \ No newline at end of file diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/module_01_cluster.svg b/content/fa/docs/tutorials/kubernetes-basics/public/images/module_01_cluster.svg new file mode 100644 index 0000000000000..b18337746749a --- /dev/null +++ b/content/fa/docs/tutorials/kubernetes-basics/public/images/module_01_cluster.svg @@ -0,0 +1,526 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Docker + Kubelt + + + Layer 1 + + + + + + + + + + + + + + + + + + + + + Kubernetes Cluster + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Control Plane + Node + Node Processes + diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/module_02.svg b/content/fa/docs/tutorials/kubernetes-basics/public/images/module_02.svg new file mode 100644 index 0000000000000..7742de99e28db --- /dev/null +++ b/content/fa/docs/tutorials/kubernetes-basics/public/images/module_02.svg @@ -0,0 +1 @@ +16.07.28_k8s_visual_diagrams \ No newline at end of file diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/module_02_first_app.svg b/content/fa/docs/tutorials/kubernetes-basics/public/images/module_02_first_app.svg new file mode 100644 index 0000000000000..cf8c922916ff7 --- /dev/null +++ b/content/fa/docs/tutorials/kubernetes-basics/public/images/module_02_first_app.svg @@ -0,0 +1,624 @@ + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Docker + Kubelt + + + Layer 1 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Node + containerized app + Deployment + Control Plane + node processes + Kubernetes Cluster + + + + diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/module_03.svg b/content/fa/docs/tutorials/kubernetes-basics/public/images/module_03.svg new file mode 100644 index 0000000000000..7873332414f6b --- /dev/null +++ b/content/fa/docs/tutorials/kubernetes-basics/public/images/module_03.svg @@ -0,0 +1 @@ +16.07.28_k8s_visual_diagrams \ No newline at end of file diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/module_03_nodes.svg b/content/fa/docs/tutorials/kubernetes-basics/public/images/module_03_nodes.svg new file mode 100644 index 0000000000000..0c7e61a980ae5 --- /dev/null +++ b/content/fa/docs/tutorials/kubernetes-basics/public/images/module_03_nodes.svg @@ -0,0 +1,521 @@ + + + + + + + + + + + + + + + + + + + + + + + Docker + + Kubelt + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/module_03_pods.svg b/content/fa/docs/tutorials/kubernetes-basics/public/images/module_03_pods.svg new file mode 100644 index 0000000000000..b63f415f3019e --- /dev/null +++ b/content/fa/docs/tutorials/kubernetes-basics/public/images/module_03_pods.svg @@ -0,0 +1,484 @@ + + + + + + + + + + + + + + + + + + + + + + + Docker + + Kubelt + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/module_04.svg b/content/fa/docs/tutorials/kubernetes-basics/public/images/module_04.svg new file mode 100644 index 0000000000000..0e37631afa618 --- /dev/null +++ b/content/fa/docs/tutorials/kubernetes-basics/public/images/module_04.svg @@ -0,0 +1 @@ +16.07.28_k8s_visual_diagrams \ No newline at end of file diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/module_04_labels.svg b/content/fa/docs/tutorials/kubernetes-basics/public/images/module_04_labels.svg new file mode 100644 index 0000000000000..781bfa0888e5a --- /dev/null +++ b/content/fa/docs/tutorials/kubernetes-basics/public/images/module_04_labels.svg @@ -0,0 +1,1054 @@ + + + + diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/module_04_services.svg b/content/fa/docs/tutorials/kubernetes-basics/public/images/module_04_services.svg new file mode 100644 index 0000000000000..a12c097bcc5ce --- /dev/null +++ b/content/fa/docs/tutorials/kubernetes-basics/public/images/module_04_services.svg @@ -0,0 +1,304 @@ + + + + + + + + + + + + + + + + + + + Docker + Kubelt + + + Layer 1 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Pod + + + Node + + + + + \ No newline at end of file diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/module_05.svg b/content/fa/docs/tutorials/kubernetes-basics/public/images/module_05.svg new file mode 100644 index 0000000000000..ef209965b949e --- /dev/null +++ b/content/fa/docs/tutorials/kubernetes-basics/public/images/module_05.svg @@ -0,0 +1 @@ +16.07.28_k8s_visual_diagrams \ No newline at end of file diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/module_05_scaling1.svg b/content/fa/docs/tutorials/kubernetes-basics/public/images/module_05_scaling1.svg new file mode 100644 index 0000000000000..14513aee8bea4 --- /dev/null +++ b/content/fa/docs/tutorials/kubernetes-basics/public/images/module_05_scaling1.svg @@ -0,0 +1,313 @@ + + + + + + + + + + + + + + + + + + + + + + + Docker + + Kubelt + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/module_05_scaling2.svg b/content/fa/docs/tutorials/kubernetes-basics/public/images/module_05_scaling2.svg new file mode 100644 index 0000000000000..86be02afb272e --- /dev/null +++ b/content/fa/docs/tutorials/kubernetes-basics/public/images/module_05_scaling2.svg @@ -0,0 +1,395 @@ + + + + + + + + + + + + + + + + + + + + + + + Docker + + Kubelt + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/module_06.svg b/content/fa/docs/tutorials/kubernetes-basics/public/images/module_06.svg new file mode 100644 index 0000000000000..411455d72130e --- /dev/null +++ b/content/fa/docs/tutorials/kubernetes-basics/public/images/module_06.svg @@ -0,0 +1 @@ +16.07.28_k8s_visual_diagrams \ No newline at end of file diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates1.svg b/content/fa/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates1.svg new file mode 100644 index 0000000000000..86be02afb272e --- /dev/null +++ b/content/fa/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates1.svg @@ -0,0 +1,395 @@ + + + + + + + + + + + + + + + + + + + + + + + Docker + + Kubelt + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates2.svg b/content/fa/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates2.svg new file mode 100644 index 0000000000000..9544b8b56898b --- /dev/null +++ b/content/fa/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates2.svg @@ -0,0 +1,543 @@ + + + + + + + + + + + + + + + + + + + + + + + Docker + + Kubelt + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates3.svg b/content/fa/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates3.svg new file mode 100644 index 0000000000000..55a392dc4c9d2 --- /dev/null +++ b/content/fa/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates3.svg @@ -0,0 +1,493 @@ + + + + + + + + + + + + + + + + + + + + + + + Docker + + Kubelt + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates4.svg b/content/fa/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates4.svg new file mode 100644 index 0000000000000..39437d7e7dc2b --- /dev/null +++ b/content/fa/docs/tutorials/kubernetes-basics/public/images/module_06_rollingupdates4.svg @@ -0,0 +1,508 @@ + + + + + + + + + + + + + + + + + + + + + + + Docker + + Kubelt + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/nav_point.png b/content/fa/docs/tutorials/kubernetes-basics/public/images/nav_point.png new file mode 100644 index 0000000000000..f9873cf9ac407 Binary files /dev/null and b/content/fa/docs/tutorials/kubernetes-basics/public/images/nav_point.png differ diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/nav_point.svg b/content/fa/docs/tutorials/kubernetes-basics/public/images/nav_point.svg new file mode 100644 index 0000000000000..42a6ae4bd57bf --- /dev/null +++ b/content/fa/docs/tutorials/kubernetes-basics/public/images/nav_point.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/nav_point_active.png b/content/fa/docs/tutorials/kubernetes-basics/public/images/nav_point_active.png new file mode 100644 index 0000000000000..f288046b6f657 Binary files /dev/null and b/content/fa/docs/tutorials/kubernetes-basics/public/images/nav_point_active.png differ diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/nav_point_active.svg b/content/fa/docs/tutorials/kubernetes-basics/public/images/nav_point_active.svg new file mode 100644 index 0000000000000..82e67411af35c --- /dev/null +++ b/content/fa/docs/tutorials/kubernetes-basics/public/images/nav_point_active.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/nav_point_sub.svg b/content/fa/docs/tutorials/kubernetes-basics/public/images/nav_point_sub.svg new file mode 100644 index 0000000000000..f3f731c1c4c5a --- /dev/null +++ b/content/fa/docs/tutorials/kubernetes-basics/public/images/nav_point_sub.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/quiz_false.png b/content/fa/docs/tutorials/kubernetes-basics/public/images/quiz_false.png new file mode 100644 index 0000000000000..028242c2ea1f8 Binary files /dev/null and b/content/fa/docs/tutorials/kubernetes-basics/public/images/quiz_false.png differ diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/quiz_true.png b/content/fa/docs/tutorials/kubernetes-basics/public/images/quiz_true.png new file mode 100644 index 0000000000000..0573d9312e3e7 Binary files /dev/null and b/content/fa/docs/tutorials/kubernetes-basics/public/images/quiz_true.png differ diff --git a/content/fa/docs/tutorials/kubernetes-basics/public/images/twitter.png b/content/fa/docs/tutorials/kubernetes-basics/public/images/twitter.png new file mode 100644 index 0000000000000..ec490d7a9e2cb Binary files /dev/null and b/content/fa/docs/tutorials/kubernetes-basics/public/images/twitter.png differ diff --git a/content/fa/docs/tutorials/security/_index.md b/content/fa/docs/tutorials/security/_index.md new file mode 100644 index 0000000000000..43b4bd300102c --- /dev/null +++ b/content/fa/docs/tutorials/security/_index.md @@ -0,0 +1,8 @@ +--- +title: "امنیت" +weight: 40 +--- + +امنیت یک دغدغه مهم برای بیشتر سازمان‌ها و افرادی است که خوشه‌های کوبرنتیز را اجرا می‌کنند. شما می‌توانید یک [فهرست بررسی امنیتی](/docs/concepts/security/security-checklist/) پایه را در بخش دیگری از مستندات کوبرنتیز بیابید. + +برای یادگیری نحوه استقرار و مدیریت جنبه‌های امنیتی کوبرنتیز، می‌توانید آموزش‌های این بخش را دنبال کنید. diff --git a/content/fa/docs/tutorials/security/apparmor.md b/content/fa/docs/tutorials/security/apparmor.md new file mode 100644 index 0000000000000..c71f72e210580 --- /dev/null +++ b/content/fa/docs/tutorials/security/apparmor.md @@ -0,0 +1,291 @@ +--- +reviewers: +- xirehat +title: محدود کردن دسترسی کانتینر به منابع با AppArmor +content_type: tutorial +weight: 30 +--- + + + +{{< feature-state feature_gate_name="AppArmor" >}} + +این صفحه به شما نشان می‌دهد که چگونه پروفایل‌های AppArmor را روی گره‌های خود بارگذاری کنید و آن پروفایل‌ها را در Pods اعمال کنید. برای کسب اطلاعات بیشتر در مورد اینکه چگونه Kubernetes می‌تواند Pods را با استفاده از AppArmor محدود کند، به [محدودیت‌های امنیتی هسته لینوکس برای پادها و کانتینرها](/docs/concepts/security/linux-kernel-security-constraints/#apparmor) مراجعه کنید. + +## {{% heading "objectives" %}} + + +* مثالی از نحوه بارگذاری یک پروفایل در یک گره را ببینید +* یاد بگیرید که چگونه پروفایل را در یک پاد اجرا کنید +* یاد بگیرید که چگونه بررسی کنید که پروفایل بارگذاری شده است +* ببینید چه اتفاقی می‌افتد وقتی یک پروفایل نقض می‌شود +* ببینید چه اتفاقی می‌افتد وقتی یک پروفایل نمی‌تواند بارگذاری شود + + +## {{% heading "prerequisites" %}} + + +AppArmor یک ماژول اختیاری هسته و قابلیتی در کوبرنتیز است؛ بنابراین پیش از ادامه، مطمئن شوید که روی +گره‌های شما پشتیبانی می‌شود: + +1. ماژول هسته AppArmor فعال است — برای آن‌که هسته لینوکس بتواند یک پروفایل AppArmor را اعمال کند، + ماژول هسته AppArmor باید نصب و فعال باشد. چندین توزیع این ماژول را به‌صورت پیش‌فرض فعال می‌کنند، + مانند Ubuntu و SUSE، و بسیاری دیگر پشتیبانی اختیاری ارائه می‌دهند. برای بررسی فعال بودن ماژول، + فایل `/sys/module/apparmor/parameters/enabled` را بررسی کنید: + + ```shell + cat /sys/module/apparmor/parameters/enabled + Y + ``` + + kubelet پیش از پذیرش پادی که به‌طور صریح با AppArmor پیکربندی شده باشد، + بررسی می‌کند که AppArmor روی میزبان فعال باشد. + +1. زمان اجرای کانتینر از AppArmor پشتیبانی می‌کند — همه زمان‌اجرای‌های کانتینری + متداول که کوبرنتیز پشتیبانی می‌کند باید از AppArmor پشتیبانی کنند، از جمله + {{< glossary_tooltip term_id="containerd" >}} و + {{< glossary_tooltip term_id="cri-o" >}}. لطفاً به مستندات زمانِ اجرای مربوطه + مراجعه کرده و اطمینان حاصل کنید که خوشه شرایط لازم برای استفاده از AppArmor + را دارد. + +1. پروفایل بارگذاری شده است — AppArmor با مشخص‌کردن پروفایل AppArmor برای هر + کانتینر روی یک پاد اعمال می‌شود. اگر هر یک از پروفایل‌های تعیین‌شده در هسته + بارگذاری نشده باشد، kubelet پاد را رد می‌کند. می‌توانید با بررسی فایل + `/sys/kernel/security/apparmor/profiles` ببینید کدام پروفایل‌ها روی یک گره + بارگذاری شده‌اند. برای مثال: + + ```shell + ssh gke-test-default-pool-239f5d02-gyn2 "sudo cat /sys/kernel/security/apparmor/profiles | sort" + ``` + ``` + apparmor-test-deny-write (enforce) + apparmor-test-audit-write (enforce) + docker-default (enforce) + k8s-nginx (enforce) + ``` + + برای جزئیات بیشتر درباره بارگذاری پروفایل‌ها روی گره‌ها، به + [راه‌اندازی گره‌ها با پروفایل](#setting-up-nodes-with-profiles) مراجعه کنید. + + + +## ایمن‌سازی یک پاد + +{{< note >}} +پیش از Kubernetes نسخه v1.30، AppArmor از طریق annotationها مشخص می‌شد. با استفاده از انتخابگر نسخه +مستندات، می‌توانید مستندات مربوط به این API منسوخ‌شده را مشاهده کنید. +{{< /note >}} + +پروفایل‌های AppArmor را می‌توان در سطح pod یا سطح container مشخص کرد. پروفایل AppArmor کانتینر بر پروفایل pod اولویت دارد. + +```yaml +securityContext: + appArmorProfile: + type: +``` + +در این‌جا مقدار `` می‌تواند یکی از گزینه‌های زیر باشد: + +* `RuntimeDefault` برای استفاده از پروفایل پیش‌فرض زمان‌اجرا +* `Localhost` برای استفاده از پروفایلی که روی میزبان بارگذاری شده است (نگاه کنید به پایین) +* `Unconfined` برای اجرا بدون AppArmor + +برای آگاهی از جزئیات کامل API پروفایل AppArmor، به +[مشخص‌کردن محدودسازی AppArmor](#specifying-apparmor-confinement) مراجعه کنید. + +برای اطمینان از این‌که پروفایل اعمال شده است، می‌توانید با بررسی ویژگی proc +فرآیند ریشه کانتینر، ببینید که با پروفایل درست اجرا می‌شود: + +```shell +kubectl exec -- cat /proc/1/attr/current +``` + +خروجی باید چیزی شبیه به این باشد: + +``` +cri-containerd.apparmor.d (enforce) +``` + +## مثال + +*این مثال فرض می‌کند که شما قبلاً خوشهی با پشتیبانی از AppArmor راه‌اندازی کرده‌اید.* + +ابتدا، پروفایلی را که می‌خواهید استفاده کنید روی گره‌های خود بارگذاری کنید. این پروفایل همه عملیات نوشتن روی فایل را مسدود می‌کند: + +``` +#include + +profile k8s-apparmor-example-deny-write flags=(attach_disconnected) { + #include + + file, + + # Deny all file writes. + deny /** w, +} +``` + +پروفایل باید روی همه گره‌ها بارگذاری شود، زیرا نمی‌دانید پاد در کدام گره زمان‌بندی خواهد شد. +در این مثال می‌توانید از SSH برای نصب پروفایل‌ها استفاده کنید، اما رویکردهای دیگری نیز +در [راه‌اندازی گره‌ها با پروفایل](#setting-up-nodes-with-profiles) مطرح شده‌اند. + +```shell +# این مثال فرض می‌کند که نام گره‌ها با نام میزبان‌ها مطابقت دارد و از طریق SSH قابل دسترسی هستند. +NODES=($( kubectl get node -o jsonpath='{.items[*].status.addresses[?(.type == "Hostname")].address}' )) + +for NODE in ${NODES[*]}; do ssh $NODE 'sudo apparmor_parser -q < + +profile k8s-apparmor-example-deny-write flags=(attach_disconnected) { + #include + + file, + + # Deny all file writes. + deny /** w, +} +EOF' +done +``` + +سپس، یک پاد ساده‌ی "Hello AppArmor" را با پروفایل deny-write اجرا کنید: + +{{% code_sample file="pods/security/hello-apparmor.yaml" %}} + +```shell +kubectl create -f hello-apparmor.yaml +``` + +شما می‌توانید با بررسی `/proc/1/attr/current` تأیید کنید که کانتینر واقعاً با آن پروفایل در حال اجرا است: + +```shell +kubectl exec hello-apparmor -- cat /proc/1/attr/current +``` + +خروجی باید این باشد: +``` +k8s-apparmor-example-deny-write (enforce) +``` + +در نهایت، می‌توانید ببینید اگر با نوشتن در یک فایل، پروفایل را نقض کنید چه اتفاقی می‌افتد: + +```shell +kubectl exec hello-apparmor -- touch /tmp/test +``` +``` +touch: /tmp/test: Permission denied +error: error executing remote command: command terminated with non-zero exit code: Error executing in Docker Container: 1 +``` + +برای جمع‌بندی، ببینید اگر سعی کنید نمایه‌ای را مشخص کنید که بارگذاری نشده است، چه اتفاقی می‌افتد: + +```shell +kubectl create -f /dev/stdin < +Annotations: container.apparmor.security.beta.kubernetes.io/hello=localhost/k8s-apparmor-example-allow-write +Status: Pending +... +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal Scheduled 10s default-scheduler Successfully assigned default/hello-apparmor to gke-test-default-pool-239f5d02-x1kf + Normal Pulled 8s kubelet Successfully pulled image "busybox:1.28" in 370.157088ms (370.172701ms including waiting) + Normal Pulling 7s (x2 over 9s) kubelet Pulling image "busybox:1.28" + Warning Failed 7s (x2 over 8s) kubelet Error: failed to get container spec opts: failed to generate apparmor spec opts: apparmor profile not found k8s-apparmor-example-allow-write + Normal Pulled 7s kubelet Successfully pulled image "busybox:1.28" in 90.980331ms (91.005869ms including waiting) +``` + +یک رویداد، پیام خطا را به همراه دلیل آن ارائه می‌دهد، که نحوه‌ی بیان آن وابسته به زمان اجرا است: +``` + Warning Failed 7s (x2 over 8s) kubelet Error: failed to get container spec opts: failed to generate apparmor spec opts: apparmor profile not found +``` + +## اداره کردن + +### راه‌اندازی گره‌ها با پروفایل‌ها + +Kubernetes {{< skew currentVersion >}} هیچ سازوکار داخلی برای بارگذاری پروفایل‌های AppArmor روی +گره‌ها در اختیار نمی‌گذارد. می‌توان پروفایل‌ها را از طریق زیرساخت سفارشی یا ابزارهایی مانند +[Kubernetes Security Profiles Operator](https://github.com/kubernetes-sigs/security-profiles-operator) +بارگذاری کرد. + +زمان‌بند از این‌که کدام پروفایل روی کدام گره بارگذاری شده است آگاه نیست؛ بنابراین مجموعه کامل +پروفایل‌ها باید روی هر گره بارگذاری شود. رویکرد جایگزین این است که برای هر پروفایل (یا دسته‌ای +از پروفایل‌ها) یک برچسب گره اضافه کنید و با استفاده از +[node selector](/docs/concepts/scheduling-eviction/assign-pod-node/) +اطمینان حاصل کنید که پاد روی گره‌ای اجرا شود که پروفایل مورد نیاز را دارد. + +## ایجاد پروفایل‌ها + +دریافت و مشخص‌کردن صحیح پروفایل‌های AppArmor می‌تواند کار دشواری باشد. خوشبختانه ابزارهایی برای کمک به این کار وجود دارد: + +* `aa-genprof` و `aa-logprof` با نظارت بر فعالیت برنامه و لاگ‌ها، قوانین پروفایل را ایجاد کرده و اقداماتی را که انجام می‌شود مجاز می‌کنند. دستورالعمل‌های بیشتر در [مستندات AppArmor](https://gitlab.com/apparmor/apparmor/wikis/Profiling_with_tools) ارائه شده است. +* [bane](https://github.com/jfrazelle/bane) یک تولیدکننده پروفایل AppArmor برای Docker است که از زبان پروفایل ساده‌شده استفاده می‌کند. + +برای اشکال‌زدایی مشکلات AppArmor می‌توانید لاگ‌های سیستم را بررسی کنید تا ببینید دقیقاً چه عملی رد شده است. AppArmor پیام‌های مفصلی را در `dmesg` ثبت می‌کند و خطاها معمولاً در لاگ‌های سیستم یا از طریق `journalctl` قابل یافتن هستند. اطلاعات بیشتر در [خرابی‌های AppArmor](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Failures) موجود است. + + +## مشخص‌کردن محدودسازی AppArmor + +{{< caution >}} +پیش از Kubernetes نسخه v1.30، AppArmor از طریق annotationها مشخص می‌شد. با استفاده از انتخابگر نسخه مستندات می‌توانید مستندات مربوط به این API منسوخ‌شده را مشاهده کنید. +{{< /caution >}} + +### پروفایل AppArmor درون securityContext {#appArmorProfile} + +می‌توانید `appArmorProfile` را در `securityContext` یک کانتینر یا در `securityContext` یک پاد مشخص کنید. +اگر پروفایل در سطح پاد تنظیم شود، به‌عنوان پروفایل پیش‌فرض برای همه کانتینرهای پاد (شامل init، sidecar و ephemeral containerها) به کار می‌رود. +اگر هم در سطح پاد و هم در سطح کانتینر پروفایل AppArmor تعیین شده باشد، پروفایل کانتینر ملاک خواهد بود. + +یک پروفایل AppArmor دو فیلد دارد: + +`type` _(required)_ — تعیین می‌کند چه نوع پروفایل AppArmor اعمال خواهد شد. گزینه‌های معتبر: + +`Localhost` +: پروفایلی که از پیش روی گره بارگذاری شده است (به‌وسیله `localhostProfile` مشخص می‌شود). + +`RuntimeDefault` +: پروفایل پیش‌فرض زمان‌اجرای کانتینر. + +`Unconfined` +: بدون اِعمال محدودیت‌های AppArmor. + +`localhostProfile` — نام پروفایلی که روی گره بارگذاری شده و باید استفاده شود. +پروفایل باید از پیش روی گره پیکربندی شده باشد. این گزینه دقیقاً زمانی باید ارائه شود که مقدار `type` برابر `Localhost` باشد. + + +## {{% heading "whatsnext" %}} + +منابع بیشتر: + +* [راهنمای سریع زبان پروفایل AppArmor](https://gitlab.com/apparmor/apparmor/wikis/QuickProfileLanguage) +* [مرجع سیاست‌های اصلی AppArmor](https://gitlab.com/apparmor/apparmor/wikis/Policy_Layout) diff --git a/content/fa/docs/tutorials/security/cluster-level-pss.md b/content/fa/docs/tutorials/security/cluster-level-pss.md new file mode 100644 index 0000000000000..f69ecc8bae083 --- /dev/null +++ b/content/fa/docs/tutorials/security/cluster-level-pss.md @@ -0,0 +1,326 @@ +--- +title: استانداردهای امنیتی پاد را در سطح خوشه اعمال کنید +content_type: tutorial +weight: 10 +--- + +{{% alert title="Note" %}} +این آموزش فقط برای خوشه‌های جدید کاربرد دارد. +{{% /alert %}} + +Pod Security یک کنترل‌کننده admission است که هنگام ایجاد پادهای جدید، بررسی‌هایی را بر اساس +[استانداردهای امنیت پاد](/docs/concepts/security/pod-security-standards/) کوبرنتیز انجام می‌دهد. +این قابلیت در نسخه v1.25 به GA رسیده است. +این راهنما به شما نشان می‌دهد چگونه استاندارد امنیت پاد `baseline` را در سطح خوشه اجرا کنید +تا یک پیکربندی یکسان به همه namespaceهای خوشه اعمال شود. + +برای اعمال استانداردهای امنیت پاد روی namespaceهای مشخص، به +[اعمال استانداردهای امنیت پاد در سطح namespace](/docs/tutorials/security/ns-level-pss) مراجعه کنید. + +اگر نسخه‌ای غیر از v{{< skew currentVersion >}} از Kubernetes را اجرا می‌کنید، +مستندات همان نسخه را بررسی کنید. + +## {{% heading "prerequisites" %}} + +روی ایستگاه کاری خود موارد زیر را نصب کنید: + +- [kind](https://kind.sigs.k8s.io/docs/user/quick-start/#installation) +- [kubectl](/docs/tasks/tools/) + +این راهنما پیکربندی‌هایی را نشان می‌دهد که برای خوشهی از Kubernetes که کنترل کامل آن را در دست دارید +می‌توانید انجام دهید. اگر قصد دارید Pod Security Admission را برای خوشه مدیریت‌شده‌ای پیکربندی کنید +که در آن امکان تغییر کنترل‌پلین را ندارید، +[اعمال استانداردهای امنیت پاد در سطح namespace](/docs/tutorials/security/ns-level-pss) را مطالعه کنید. + +## انتخاب استاندارد مناسب امنیت پاد برای اعمال + +[Pod Security Admission](/docs/concepts/security/pod-security-admission/) +به شما اجازه می‌دهد [استانداردهای امنیت پاد](/docs/concepts/security/pod-security-standards/) +داخلی را با حالت‌های `enforce`، `audit` و `warn` اعمال کنید. + +برای جمع‌آوری اطلاعاتی که به انتخاب استاندارد امنیت پاد مناسب برای پیکربندی‌تان کمک می‌کند، این مراحل را طی کنید: + +1. یک خوشه بدون اعمال هیچ استاندارد امنیت پاد ایجاد کنید: + + ```shell + kind create cluster --name psa-wo-cluster-pss + ``` + The output is similar to: + ``` + Creating cluster "psa-wo-cluster-pss" ... + ✓ Ensuring node image (kindest/node:v{{< skew currentPatchVersion >}}) 🖼 + ✓ Preparing nodes 📦 + ✓ Writing configuration 📜 + ✓ Starting control-plane 🕹️ + ✓ Installing CNI 🔌 + ✓ Installing StorageClass 💾 + Set kubectl context to "kind-psa-wo-cluster-pss" + You can now use your cluster with: + + kubectl cluster-info --context kind-psa-wo-cluster-pss + + Thanks for using kind! 😊 + ``` + +1. زمینه kubectl را روی خوشه جدید تنظیم کنید: + + ```shell + kubectl cluster-info --context kind-psa-wo-cluster-pss + ``` + The output is similar to this: + + ``` + Kubernetes control plane is running at https://127.0.0.1:61350 + + CoreDNS is running at https://127.0.0.1:61350/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy + + To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. + ``` + +1. لیستی از فضاهای نام موجود در خوشه را دریافت کنید: + + ```shell + kubectl get ns + ``` + The output is similar to this: + ``` + NAME STATUS AGE + default Active 9m30s + kube-node-lease Active 9m32s + kube-public Active 9m32s + kube-system Active 9m32s + local-path-storage Active 9m26s + ``` + +1. برای درک اینکه هنگام اعمال استانداردهای مختلف امنیتی پاد چه اتفاقی می‌افتد، از `--dry-run=server` استفاده کنید: + + 1. Privileged + ```shell + kubectl label --dry-run=server --overwrite ns --all \ + pod-security.kubernetes.io/enforce=privileged + ``` + + The output is similar to: + ``` + namespace/default labeled + namespace/kube-node-lease labeled + namespace/kube-public labeled + namespace/kube-system labeled + namespace/local-path-storage labeled + ``` + 2. Baseline + ```shell + kubectl label --dry-run=server --overwrite ns --all \ + pod-security.kubernetes.io/enforce=baseline + ``` + + خروجی مشابه زیر است: + ``` + namespace/default labeled + namespace/kube-node-lease labeled + namespace/kube-public labeled + Warning: existing pods in namespace "kube-system" violate the new PodSecurity enforce level "baseline:latest" + Warning: etcd-psa-wo-cluster-pss-control-plane (and 3 other pods): host namespaces, hostPath volumes + Warning: kindnet-vzj42: non-default capabilities, host namespaces, hostPath volumes + Warning: kube-proxy-m6hwf: host namespaces, hostPath volumes, privileged + namespace/kube-system labeled + namespace/local-path-storage labeled + ``` + + 3. Restricted + ```shell + kubectl label --dry-run=server --overwrite ns --all \ + pod-security.kubernetes.io/enforce=restricted + ``` + + The output is similar to: + ``` + namespace/default labeled + namespace/kube-node-lease labeled + namespace/kube-public labeled + Warning: existing pods in namespace "kube-system" violate the new PodSecurity enforce level "restricted:latest" + Warning: coredns-7bb9c7b568-hsptc (and 1 other pod): unrestricted capabilities, runAsNonRoot != true, seccompProfile + Warning: etcd-psa-wo-cluster-pss-control-plane (and 3 other pods): host namespaces, hostPath volumes, allowPrivilegeEscalation != false, unrestricted capabilities, restricted volume types, runAsNonRoot != true + Warning: kindnet-vzj42: non-default capabilities, host namespaces, hostPath volumes, allowPrivilegeEscalation != false, unrestricted capabilities, restricted volume types, runAsNonRoot != true, seccompProfile + Warning: kube-proxy-m6hwf: host namespaces, hostPath volumes, privileged, allowPrivilegeEscalation != false, unrestricted capabilities, restricted volume types, runAsNonRoot != true, seccompProfile + namespace/kube-system labeled + Warning: existing pods in namespace "local-path-storage" violate the new PodSecurity enforce level "restricted:latest" + Warning: local-path-provisioner-d6d9f7ffc-lw9lh: allowPrivilegeEscalation != false, unrestricted capabilities, runAsNonRoot != true, seccompProfile + namespace/local-path-storage labeled + ``` + +از خروجی قبلی متوجه می‌شوید که اعمال استاندارد امنیت پاد `privileged` برای هیچ ‌namespaceای هشداری نشان نمی‌دهد. +اما استانداردهای `baseline` و `restricted` هر دو هشدارهایی دارند، به‌ویژه در namespace `kube-system`. + +## تنظیم حالت‌ها، نسخه‌ها و استانداردها + +در این بخش، استانداردهای امنیت پاد زیر را بر روی نسخه `latest` اعمال می‌کنید: + +* استاندارد `baseline` در حالت `enforce` +* استاندارد `restricted` در حالت‌های `warn` و `audit` + +استاندارد امنیت پاد `baseline` یک میانه مناسب فراهم می‌کند که +فهرست استثناها را کوتاه نگه می‌دارد و از افزایش امتیازهای شناخته‌شده جلوگیری می‌کند. + +همچنین، برای جلوگیری از خطای پادها در `kube-system`، این namespace را +از اعمال استانداردهای امنیت پاد مستثنا خواهید کرد. + +هنگام پیاده‌سازی Pod Security Admission در محیط خود، موارد زیر را در نظر بگیرید: + +1. بر اساس وضعیت ریسک در یک خوشه، ممکن است استاندارد سخت‌گیرانه‌ترِ + `restricted` انتخاب بهتری باشد. +1. مستثناکردن namespace‌ `kube-system` اجازه می‌دهد پادها در این فضا با + حالت `privileged` اجرا شوند. در کاربردهای واقعی، پروژه Kubernetes + به‌شدت توصیه می‌کند که با پیروی از اصل حداقل امتیاز،‌ سیاست‌های RBAC + سخت‌گیرانه‌ای اعمال کنید که دسترسی به `kube-system` را محدود می‌کند. + +برای پیاده‌سازی استانداردهای فوق، این مراحل را انجام دهید: + +1. یک فایل پیکربندی ایجاد کنید که کنترلر Pod Security Admission بتواند از آن + برای اعمال این استانداردهای امنیت پاد استفاده کند: + + ``` + mkdir -p /tmp/pss + cat < /tmp/pss/cluster-level-pss.yaml + apiVersion: apiserver.config.k8s.io/v1 + kind: AdmissionConfiguration + plugins: + - name: PodSecurity + configuration: + apiVersion: pod-security.admission.config.k8s.io/v1 + kind: PodSecurityConfiguration + defaults: + enforce: "baseline" + enforce-version: "latest" + audit: "restricted" + audit-version: "latest" + warn: "restricted" + warn-version: "latest" + exemptions: + usernames: [] + runtimeClasses: [] + namespaces: [kube-system] + EOF + ``` + + {{< note >}} +پیکربندی `pod-security.admission.config.k8s.io/v1` نیازمند نسخه v1.25+ است. +برای نسخه‌های v1.23 و v1.24 از [v1beta1](https://v1-24.docs.kubernetes.io/docs/tasks/configure-pod-container/enforce-standards-admission-controller/) استفاده کنید. +برای v1.22 از [v1alpha1](https://v1-22.docs.kubernetes.io/docs/tasks/configure-pod-container/enforce-standards-admission-controller/) استفاده کنید. + {{< /note >}} + + +1. سرور API را طوری پیکربندی کنید که در طول ایجاد خوشه، از این فایل استفاده کند: + + ``` + cat < /tmp/pss/cluster-config.yaml + kind: Cluster + apiVersion: kind.x-k8s.io/v1alpha4 + nodes: + - role: control-plane + kubeadmConfigPatches: + - | + kind: ClusterConfiguration + apiServer: + extraArgs: + admission-control-config-file: /etc/config/cluster-level-pss.yaml + extraVolumes: + - name: accf + hostPath: /etc/config + mountPath: /etc/config + readOnly: false + pathType: "DirectoryOrCreate" + extraMounts: + - hostPath: /tmp/pss + containerPath: /etc/config + # optional: if set, the mount is read-only. + # default false + readOnly: false + # optional: if set, the mount needs SELinux relabeling. + # default false + selinuxRelabel: false + # optional: set propagation mode (None, HostToContainer or Bidirectional) + # see https://kubernetes.io/docs/concepts/storage/volumes/#mount-propagation + # default None + propagation: None + EOF + ``` + + {{}} +اگر از Docker Desktop با *kind* در macOS استفاده می‌کنید، می‌توانید `/tmp` را به عنوان یک دایرکتوری مشترک در زیر آیتم منو اضافه کنید. + **Preferences > Resources > File Sharing**. + {{}} + +1. خوشه‌ای ایجاد کنید که از Pod Security Admission برای اعمال این استانداردهای Pod Security استفاده کند: + + ```shell + kind create cluster --name psa-with-cluster-pss --config /tmp/pss/cluster-config.yaml + ``` + خروجی مشابه این است: + ``` + Creating cluster "psa-with-cluster-pss" ... + ✓ Ensuring node image (kindest/node:v{{< skew currentPatchVersion >}}) 🖼 + ✓ Preparing nodes 📦 + ✓ Writing configuration 📜 + ✓ Starting control-plane 🕹️ + ✓ Installing CNI 🔌 + ✓ Installing StorageClass 💾 + Set kubectl context to "kind-psa-with-cluster-pss" + You can now use your cluster with: + + kubectl cluster-info --context kind-psa-with-cluster-pss + + Have a question, bug, or feature request? Let us know! https://kind.sigs.k8s.io/#community 🙂 + ``` + +1. kubectl را به خوشه اشاره دهید: + ```shell + kubectl cluster-info --context kind-psa-with-cluster-pss + ``` + خروجی مشابه این است: + ``` + Kubernetes control plane is running at https://127.0.0.1:63855 + CoreDNS is running at https://127.0.0.1:63855/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy + + To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. + ``` + +1. یک Pod در فضای نام پیش‌فرض ایجاد کنید: + + {{% code_sample file="security/example-baseline-pod.yaml" %}} + + ```shell + kubectl apply -f https://k8s.io/examples/security/example-baseline-pod.yaml + ``` + + پاد به طور عادی شروع به کار می‌کند، اما خروجی شامل یک هشدار است: + ``` + Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "nginx" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "nginx" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "nginx" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost") + pod/nginx created + ``` + +## تمیز کردن + +حالا با اجرای دستور زیر، خوشههایی که در بالا ایجاد کردید را حذف کنید: + +```shell +kind delete cluster --name psa-with-cluster-pss +``` +```shell +kind delete cluster --name psa-wo-cluster-pss +``` + +## {{% heading "whatsnext" %}} + +- اجرای یک + [اسکریپت شِل](/examples/security/kind-with-cluster-level-baseline-pod-security.sh) + برای انجام همه مراحل فوق به‌صورت یک‌جا: + 1. ایجاد یک پیکربندی سطح خوشه بر پایه استانداردهای امنیت پاد + 2. ایجاد فایلی تا سرور API بتواند این پیکربندی را مصرف کند + 3. ایجاد خوشهی که یک سرور API با این پیکربندی راه‌اندازی می‌کند + 4. تنظیم context ابزار `kubectl` روی این خوشه جدید + 5. ایجاد یک فایل YAML حداقلی برای پاد + 6. اعمال این فایل برای ایجاد یک پاد در خوشه جدید +- [پذیرش امنیت پاد](/docs/concepts/security/pod-security-admission/) +- [استانداردهای امنیت پاد](/docs/concepts/security/pod-security-standards/) +- [اعمال استانداردهای امنیت پاد در سطح namespace](/docs/tutorials/security/ns-level-pss/) \ No newline at end of file diff --git a/content/fa/docs/tutorials/security/ns-level-pss.md b/content/fa/docs/tutorials/security/ns-level-pss.md new file mode 100644 index 0000000000000..9498a2045f77c --- /dev/null +++ b/content/fa/docs/tutorials/security/ns-level-pss.md @@ -0,0 +1,154 @@ +--- +title: اعمال استانداردهای امنیتی Pod در سطح فضای نام +content_type: tutorial +weight: 20 +--- + +{{% alert title="Note" %}} +این آموزش فقط برای خوشه‌های جدید کاربرد دارد. +{{% /alert %}} + +Pod Security Admission یک کنترل‌کننده پذیرش است که هنگام ایجاد پادها، +[استانداردهای امنیت پاد](/docs/concepts/security/pod-security-standards/) را اعمال می‌کند. +این قابلیت در نسخه ۱٫۲۵ به وضعیت GA (عرضه عمومی) رسید. +در این آموزش، استاندارد امنیت پاد `baseline` را به‌صورت جداگانه روی هر فضای نام اعمال خواهید کرد. + +همچنین می‌توانید استانداردهای امنیت پاد را در سطح خوشه و به‌طور هم‌زمان روی چند فضای نام اعمال کنید. +برای دستورالعمل‌ها، به +[اعمال استانداردهای امنیت پاد در سطح خوشه](/docs/tutorials/security/cluster-level-pss/) مراجعه کنید. + +## {{% heading "prerequisites" %}} + +موارد زیر را روی ایستگاه کاری خود نصب کنید: + +- [kind](https://kind.sigs.k8s.io/docs/user/quick-start/#installation) +- [kubectl](/docs/tasks/tools/) + +## ساخت خوشه + +1. یک خوشه `kind` به صورت زیر ایجاد کنید: + + ```shell + kind create cluster --name psa-ns-level + ``` + + خروجی مشابه این است: + + ``` + Creating cluster "psa-ns-level" ... + ✓ Ensuring node image (kindest/node:v{{< skew currentPatchVersion >}}) 🖼 + ✓ Preparing nodes 📦 + ✓ Writing configuration 📜 + ✓ Starting control-plane 🕹️ + ✓ Installing CNI 🔌 + ✓ Installing StorageClass 💾 + Set kubectl context to "kind-psa-ns-level" + You can now use your cluster with: + + kubectl cluster-info --context kind-psa-ns-level + + Not sure what to do next? 😅 Check out https://kind.sigs.k8s.io/docs/user/quick-start/ + ``` + +1. زمینه kubectl را روی خوشه جدید تنظیم کنید: + + ```shell + kubectl cluster-info --context kind-psa-ns-level + ``` + خروجی مشابه این است: + + ``` + Kubernetes control plane is running at https://127.0.0.1:50996 + CoreDNS is running at https://127.0.0.1:50996/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy + + To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. + ``` + +## ساخت فضای نام + +یک فضای نام جدید به نام `example` ایجاد کنید: + +```shell +kubectl create ns example +``` + +خروجی مشابه این است: + +``` +namespace/example created +``` + +## فعال کردن استانداردهای امنیتی پاد برای بررسی آن فضای نام + +1. استانداردهای امنیتی پاد را در این فضای نام با استفاده از برچسب‌های پشتیبانی‌شده توسط پذیرش امنیتی پاد داخلی فعال کنید. در این مرحله، بررسی را پیکربندی خواهید کرد تا به پادهایی که آخرین نسخه استاندارد امنیتی پاد _baseline_ را رعایت نمی‌کنند، هشدار دهد. + + ```shell + kubectl label --overwrite ns example \ + pod-security.kubernetes.io/warn=baseline \ + pod-security.kubernetes.io/warn-version=latest + ``` + +2. شما می‌توانید با استفاده از برچسب‌ها، چندین بررسی استاندارد امنیتی پاد را روی هر فضای نامی پیکربندی کنید. +دستور زیر استاندارد امنیتی پاد «پایه» را «اجرا» می‌کند، اما استانداردهای امنیتی پاد «محدود» را مطابق با آخرین نسخه «هشدار» و «ممیزی» می‌دهد (مقدار پیش‌فرض) + + ```shell + kubectl label --overwrite ns example \ + pod-security.kubernetes.io/enforce=baseline \ + pod-security.kubernetes.io/enforce-version=latest \ + pod-security.kubernetes.io/warn=restricted \ + pod-security.kubernetes.io/warn-version=latest \ + pod-security.kubernetes.io/audit=restricted \ + pod-security.kubernetes.io/audit-version=latest + ``` + +## اجرای استاندارد امنیت پاد را تأیید کنید + +1. یک پاد پایه در فضای نام `example` ایجاد کنید: + + ```shell + kubectl apply -n example -f https://k8s.io/examples/security/example-baseline-pod.yaml + ``` + پاد بدون مشکل شروع به کار می‌کند؛ خروجی شامل یک هشدار است. برای مثال: + + ``` + Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "nginx" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "nginx" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "nginx" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost") + pod/nginx created + ``` + +1. یک پاد پایه در فضای نام `default` ایجاد کنید: + + ```shell + kubectl apply -n default -f https://k8s.io/examples/security/example-baseline-pod.yaml + ``` + خروجی مشابه این است: + + ``` + pod/nginx created + ``` + +تنظیمات اعمال و هشدارهای استانداردهای امنیت پاد فقط بر روی نام‌فضای `example` اعمال شدند. +می‌توانید همان پاد را در نام‌فضای `default` ایجاد کنید بدون آنکه هشدار دریافت کنید. + +## تمیز کردن + +حالا با اجرای دستور زیر، خوشه‌ای که در بالا ایجاد کردید را حذف کنید: + +```shell +kind delete cluster --name psa-ns-level +``` + +## {{% heading "whatsnext" %}} + +- یک + [اسکریپت شِل](/examples/security/kind-with-namespace-level-baseline-pod-security.sh) + اجرا کنید تا همه مراحل بالا را یکجا انجام دهد. + + 1. ایجاد یک خوشه kind + 2. ایجاد یک نام‌فضای جدید + 3. اعمال استاندارد امنیت پاد `baseline` در حالت `enforce` و همزمان اعمال + استاندارد امنیت پاد `restricted` در حالت‌های `warn` و `audit` + 4. ایجاد یک پاد جدید با استانداردهای امنیت پاد زیر: + +- [پذیرش امنیت پاد](/docs/concepts/security/pod-security-admission/) +- [استانداردهای امنیتی پاد](/docs/concepts/security/pod-security-standards/) +- [اعمال استانداردهای امنیت پاد در سطح خوشه](/docs/tutorials/security/cluster-level-pss/) diff --git a/content/fa/docs/tutorials/security/seccomp.md b/content/fa/docs/tutorials/security/seccomp.md new file mode 100644 index 0000000000000..534774074914f --- /dev/null +++ b/content/fa/docs/tutorials/security/seccomp.md @@ -0,0 +1,477 @@ +--- +reviewers: +- xirehat +title: محدود کردن فراخوانی‌های سیستمی یک کانتینر با seccomp +content_type: tutorial +weight: 40 +min-kubernetes-server-version: v1.22 +--- + + + +{{< feature-state for_k8s_version="v1.19" state="stable" >}} + +Seccomp مخفف *secure computing mode* است و از نسخه 2.6.12 در هسته لینوکس وجود دارد. +می‌توان از آن برای سندباکس کردن سطح دسترسی یک فرایند استفاده کرد و فراخوانی‌هایی را که این فرایند از فضای کاربری به هسته انجام می‌دهد محدود نمود. +کوبرنتیز به شما اجازه می‌دهد پروفایل‌های seccomp بارگذاری‌شده روی یک +{{< glossary_tooltip text="node" term_id="node" >}} +را به‌صورت خودکار روی پادها و کانتینرهایتان اعمال کنید. + +تشخیص مجوزهای موردنیاز برای بارهای کاری می‌تواند دشوار باشد. در این آموزش می‌آموزید چگونه پروفایل‌های seccomp را در یک خوشه محلی کوبرنتیز بارگذاری کنید، آن‌ها را به یک پاد اعمال کنید و پروفایل‌هایی بسازید که فقط دسترسی‌های لازم را به فرایندهای کانتینری بدهند. + +## {{% heading "objectives" %}} + +* یاد بگیرید چگونه پروفایل‌های seccomp را روی یک گره بارگذاری کنید +* یاد بگیرید چگونه یک پروفایل seccomp را روی یک کانتینر اعمال کنید +* مشاهده ممیزی فراخوان‌های سیستمیِ انجام‌شده توسط فرایند کانتینر +* مشاهده رفتار زمانی که یک پروفایلِ موجود نیست مشخص می‌شود +* مشاهده نقض یک پروفایل seccomp +* یاد بگیرید چگونه پروفایل‌های seccomp دقیق و جزئی بسازید +* یاد بگیرید چگونه پروفایل seccomp پیش‌فرض زمان‌اجرای کانتینر را اعمال کنید + +## {{% heading "prerequisites" %}} + +برای انجام همه مراحل این آموزش باید [kind](/docs/tasks/tools/#kind) و [kubectl](/docs/tasks/tools/#kubectl) را نصب کنید. + +دستورات استفاده‌شده در این راهنما فرض می‌کنند که شما از +[Docker](https://www.docker.com/) +به‌عنوان زمان‌اجرای کانتینر استفاده می‌کنید (خوشهی که `kind` می‌سازد ممکن است درونی از زمان‌اجرای دیگری استفاده کند). +می‌توانید از [Podman](https://podman.io/) نیز بهره ببرید، اما در آن صورت باید طبق +[دستورالعمل‌های ویژه](https://kind.sigs.k8s.io/docs/user/rootless/) +عمل کنید تا کارها با موفقیت انجام شوند. + +این آموزش نمونه‌هایی را نشان می‌دهد که برخی هنوز در وضعیت بتا هستند (از v1.25) و برخی دیگر از قابلیت‌های seccomp عمومی استفاده می‌کنند. اطمینان حاصل کنید که خوشه شما برای نسخه‌ای که استفاده می‌کنید +[به‌درستی پیکربندی شده باشد](https://kind.sigs.k8s.io/docs/user/quick-start/#setting-kubernetes-version). + +در این آموزش برای بارگیری مثال‌ها از ابزار `curl` استفاده می‌شود؛ اگر مایلید می‌توانید از ابزار دیگری استفاده کنید. + +{{< note >}} +امکان اعمال یک پروفایل seccomp به کانتینری که در `securityContext` آن +`privileged: true` +تنظیم شده نیست. کانتینرهای *privileged* همیشه با حالت `Unconfined` اجرا می‌شوند. +{{< /note >}} + + + +## دانلود پروفایل‌های نمونه seccomp {#download-profiles} + +محتوای این پروفایل‌ها را بعداً بررسی خواهیم کرد، اما فعلاً آن‌ها را در پوشه‌ای به نام `profiles/` دانلود کنید تا بتوان در خوشه بارگذاری‌شان کرد. + +{{< tabs name="tab_with_code" >}} +{{< tab name="audit.json" >}} +{{% code_sample file="pods/security/seccomp/profiles/audit.json" %}} +{{< /tab >}} +{{< tab name="violation.json" >}} +{{% code_sample file="pods/security/seccomp/profiles/violation.json" %}} +{{< /tab >}} +{{< tab name="fine-grained.json" >}} +{{% code_sample file="pods/security/seccomp/profiles/fine-grained.json" %}} +{{< /tab >}} +{{< /tabs >}} + +این دستورات را اجرا کنید: + +```shell +mkdir ./profiles +curl -L -o profiles/audit.json https://k8s.io/examples/pods/security/seccomp/profiles/audit.json +curl -L -o profiles/violation.json https://k8s.io/examples/pods/security/seccomp/profiles/violation.json +curl -L -o profiles/fine-grained.json https://k8s.io/examples/pods/security/seccomp/profiles/fine-grained.json +ls profiles +``` + +در پایان مرحله آخر باید سه پروفایل را مشاهده کنید: +``` +audit.json fine-grained.json violation.json +``` + +## ایجاد یک خوشه محلی کوبرنتیز با kind + +برای سادگی، می‌توان از [kind](https://kind.sigs.k8s.io/) برای ایجاد یک خوشه تک‌گره‌ای استفاده کرد که پروفایل‌های seccomp در آن بارگذاری شده‌اند. kind کوبرنتیز را داخل Docker اجرا می‌کند، بنابراین هر گره خوشه یک کانتینر است. این امکان فراهم می‌شود که فایل‌ها در فایل‌سیستم هر کانتینر سوار (mount) شوند، مشابهِ بارگذاری فایل‌ها روی یک گره. + +{{% code_sample file="pods/security/seccomp/kind.yaml" %}} + +پیکربندی kind نمونه را بارگیری کنید و آن را در فایلی با نام `kind.yaml` ذخیره کنید: +```shell +curl -L -O https://k8s.io/examples/pods/security/seccomp/kind.yaml +``` + +می‌توانید با تعیین ایمیج کانتینرِ گره، نسخه مشخصی از Kubernetes را تنظیم کنید. +برای جزئیات بیشتر، به بخش [Nodes](https://kind.sigs.k8s.io/docs/user/configuration/#nodes) در مستندات kind درباره پیکربندی مراجعه کنید. +این آموزش فرض می‌کند که شما از Kubernetes {{< param "version" >}} استفاده می‌کنید. + +به عنوان یک قابلیت بتا، می‌توانید Kubernetes را طوری پیکربندی کنید که به‌جای بازگشت به `Unconfined`، از پروفایلی که +{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}} +به طور پیش‌فرض ترجیح می‌دهد استفاده کند. +اگر می‌خواهید این کار را امتحان کنید، پیش از ادامه، بخش +[فعالسازی استفاده از `RuntimeDefault` به عنوان پروفایل پیش‌فرض seccomp برای همه کارها](#enable-the-use-of-runtimedefault-as-the-default-seccomp-profile-for-all-workloads) +را ببینید. + +پس از آن‌که پیکربندی kind را آماده کردید، خوشه kind را با همان پیکربندی ایجاد کنید: + +```shell +kind create cluster --config=kind.yaml +``` + +پس از آماده شدن خوشه جدید Kubernetes، کانتینر Docker در حال اجرا را به عنوان خوشه تک گره‌ای شناسایی کنید: + +```shell +docker ps +``` + +باید خروجی را ببینید که نشان می‌دهد یک کانتینر با نام `kind-control-plane` در حال اجرا است. خروجی مشابه زیر است: + +``` +CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES +6a96207fed4b kindest/node:v1.18.2 "/usr/local/bin/entr…" 27 seconds ago Up 24 seconds 127.0.0.1:42223->6443/tcp kind-control-plane +``` + +اگر فایل‌سیستم آن کانتینر را بررسی کنید، باید ببینید که پوشه `profiles/` با موفقیت در مسیر پیش‌فرض seccomp مربوط به kubelet بارگذاری شده است. از `docker exec` برای اجرای یک دستور در پاد استفاده کنید: + +```shell +# 6a96207fed4b را به شناسه کانتینری که در "docker ps" دیدید، تغییر دهید. +docker exec -it 6a96207fed4b ls /var/lib/kubelet/seccomp/profiles +``` + +``` +audit.json fine-grained.json violation.json +``` + +شما تأیید کرده‌اید که این پروفایل‌های seccomp برای kubelet که در kind اجرا می‌شود در دسترس هستند. + +## ایجاد یک پاد که از پروفایل seccomp پیش‌فرض زمان‌اجرای کانتینر استفاده می‌کند + +بیشتر زمان‌اجرای‌های کانتینر مجموعه‌ای معقول از syscalls مجاز یا غیرمجاز را فراهم می‌کنند. +می‌توانید با قرار دادن نوع seccomp در `securityContext` پاد یا کانتینر روی `RuntimeDefault`, +این پیش‌فرض‌ها را برای بار کاری خود به کار بگیرید. + +{{< note >}} +اگر پیکربندی `seccompDefault` +[کوبه‌لت](/docs/reference/config-api/kubelet-config.v1beta1/) را فعال کرده باشید، +پاد‌ها هر زمان که پروفایل seccomp دیگری مشخص نشده باشد از پروفایل `RuntimeDefault` +استفاده می‌کنند. در غیر این صورت، مقدار پیش‌فرض `Unconfined` است. +{{< /note >}} + +در این‌جا یک مانیفست برای پادی آمده است که برای همه کانتینرهای خود پروفایل seccomp +`RuntimeDefault` را درخواست می‌کند: + +{{% code_sample file="pods/security/seccomp/ga/default-pod.yaml" %}} + +این پاد را ایجاد کنید: +```shell +kubectl apply -f https://k8s.io/examples/pods/security/seccomp/ga/default-pod.yaml +``` + +```shell +kubectl get pod default-pod +``` + +پاد باید با موفقیت شروع به کار کرده باشد: +``` +NAME READY STATUS RESTARTS AGE +default-pod 1/1 Running 0 20s +``` + +قبل از رفتن به بخش بعدی، Pod را حذف کنید: + +```shell +kubectl delete pod default-pod --wait --now +``` + +## ایجاد یک پاد با پروفایل seccomp برای ممیزی فراخوان‌های سیستمی + +در ابتدا، پروفایل `audit.json` را که تمام فراخوان‌های سیستمیِ فرایند را لاگ می‌کند +به یک پاد جدید اعمال کنید. + +در این‌جا مانیفست آن پاد آمده است: + +{{% code_sample file="pods/security/seccomp/ga/audit-pod.yaml" %}} + +{{< note >}} +در نسخه‌های قدیمی‌تر Kubernetes می‌توانستید رفتار seccomp را با استفاده از +{{< glossary_tooltip text="annotations" term_id="annotation" >}} پیکربندی کنید. +Kubernetes {{< skew currentVersion >}} فقط استفاده از فیلدهای درون +`.spec.securityContext` را برای پیکربندی seccomp پشتیبانی می‌کند و این +آموزش همین روش را توضیح می‌دهد. +{{< /note >}} + +پاد را در خوشه ایجاد کنید: + +```shell +kubectl apply -f https://k8s.io/examples/pods/security/seccomp/ga/audit-pod.yaml +``` + +این پروفایل هیچ فراخوانی سیستمی را محدود نمی‌کند، بنابراین Pod باید با موفقیت شروع به کار کند. + +```shell +kubectl get pod audit-pod +``` + +``` +NAME READY STATUS RESTARTS AGE +audit-pod 1/1 Running 0 30s +``` + +برای آن‌که بتوانید با این نقطه پایانی که توسط این کانتینر در دسترس قرار گرفته است تعامل کنید، +یک NodePort {{< glossary_tooltip text="Service" term_id="service" >}} ایجاد کنید که +دسترسی به این نقطه پایانی را از داخل کانتینر control plane در kind امکان‌پذیر کند. + +```shell +kubectl expose pod audit-pod --type NodePort --port 5678 +``` + +بررسی کنید که چه پورتی به سرویس روی گره اختصاص داده شده است. + +```shell +kubectl get service audit-pod +``` + +خروجی مشابه زیر است: +``` +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +audit-pod NodePort 10.111.36.142 5678:32373/TCP 72s +``` + +اکنون می‌توانید با استفاده از `curl` از داخل کانتینر control plane در kind به آن +نقطه پایانی در پورتی که این Service در معرض قرار داده است دسترسی پیدا کنید. +از `docker exec` استفاده کنید تا فرمان `curl` را درون همان کانتینر control plane اجرا کنید: + +```shell +# عدد 6a96207fed4b را به شناسه کانتینر صفحه کنترل و عدد 32373 را به شماره پورتی که در "docker ps" مشاهده کردید، تغییر دهید. +docker exec -it 6a96207fed4b curl localhost:32373 +``` + +``` +just made some syscalls! +``` + +می‌توانید ببینید که فرایند در حال اجراست؛ اما دقیقاً چه فراخوان‌های سیستمی انجام داده است؟ +از آنجا که این پاد در یک خوشه محلی اجرا می‌شود، باید بتوانید این فراخوان‌ها را در +`/var/log/syslog` روی سیستم محلی خود مشاهده کنید. یک پنجره ترمینال جدید باز کنید و با دستور `tail` +خروجی مربوط به فراخوان‌های `http-echo` را بررسی کنید: + +```shell +# مسیر گزارش در رایانه شما ممکن است با "/var/log/syslog" متفاوت باشد. +tail -f /var/log/syslog | grep 'http-echo' +``` + +شما باید از قبل برخی از لاگ‌های مربوط به فراخوانی‌های سیستمی انجام شده توسط `http-echo` را مشاهده کنید، و اگر `curl` را دوباره درون کانتینر صفحه کنترل اجرا کنید، خروجی‌های بیشتری را که در لاگ نوشته شده‌اند، خواهید دید. + +For example: +``` +Jul 6 15:37:40 my-machine kernel: [369128.669452] audit: type=1326 audit(1594067860.484:14536): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=51 compat=0 ip=0x46fe1f code=0x7ffc0000 +Jul 6 15:37:40 my-machine kernel: [369128.669453] audit: type=1326 audit(1594067860.484:14537): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=54 compat=0 ip=0x46fdba code=0x7ffc0000 +Jul 6 15:37:40 my-machine kernel: [369128.669455] audit: type=1326 audit(1594067860.484:14538): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=202 compat=0 ip=0x455e53 code=0x7ffc0000 +Jul 6 15:37:40 my-machine kernel: [369128.669456] audit: type=1326 audit(1594067860.484:14539): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=288 compat=0 ip=0x46fdba code=0x7ffc0000 +Jul 6 15:37:40 my-machine kernel: [369128.669517] audit: type=1326 audit(1594067860.484:14540): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=0 compat=0 ip=0x46fd44 code=0x7ffc0000 +Jul 6 15:37:40 my-machine kernel: [369128.669519] audit: type=1326 audit(1594067860.484:14541): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=270 compat=0 ip=0x4559b1 code=0x7ffc0000 +Jul 6 15:38:40 my-machine kernel: [369188.671648] audit: type=1326 audit(1594067920.488:14559): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=270 compat=0 ip=0x4559b1 code=0x7ffc0000 +Jul 6 15:38:40 my-machine kernel: [369188.671726] audit: type=1326 audit(1594067920.488:14560): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=29064 comm="http-echo" exe="/http-echo" sig=0 arch=c000003e syscall=202 compat=0 ip=0x455e53 code=0x7ffc0000 +``` + +می‌توانید با نگاه‌کردن به ورودی `syscall=` در هر خط، شروع به درک فراخوان‌های سیستمی موردنیاز برای فرایند `http-echo` کنید. گرچه این‌ها به‌احتمال زیاد همه فراخوان‌های سیستمیِ مورد استفاده را در بر نمی‌گیرند، اما می‌توانند مبنایی برای ایجاد یک پروفایل seccomp برای این کانتینر باشند. + +پیش از رفتن به بخش بعدی، Service و Pod را حذف کنید: + +```shell +kubectl delete service audit-pod --wait +kubectl delete pod audit-pod --wait --now +``` + +## ایجاد یک پاد با پروفایل seccomp که موجب نقض می‌شود + +برای نمایش، پروفایلی را به پاد اعمال کنید که هیچ فراخوان سیستمی را مجاز نمی‌کند. + +مانیفست این دموی آموزشی به شکل زیر است: + +{{% code_sample file="pods/security/seccomp/ga/violation-pod.yaml" %}} + +تلاش کنید پاد را در خوشه ایجاد کنید: + +```shell +kubectl apply -f https://k8s.io/examples/pods/security/seccomp/ga/violation-pod.yaml +``` + +پاد ایجاد می‌شود، اما مشکلی وجود دارد. اگر وضعیت پاد را بررسی کنید، باید ببینید که شروع به کار نکرده است. + +```shell +kubectl get pod violation-pod +``` + +``` +NAME READY STATUS RESTARTS AGE +violation-pod 0/1 CrashLoopBackOff 1 6s +``` + +همان‌طور که در مثال قبلی دیدید، فرایند `http-echo` به فراخوان‌های سیستمی نسبتاً زیادی نیاز دارد. +در این‌جا با تنظیم `"defaultAction": "SCMP_ACT_ERRNO"` به seccomp دستور داده شده است +که برای هر فراخوان سیستمی خطا برگرداند. این رویکرد از نظر امنیتی بسیار سخت‌گیرانه است، +اما امکان انجام هر عمل معناداری را سلب می‌کند. آنچه واقعاً می‌خواهید این است که به بارهای کاری +فقط دسترسی‌های موردنیازشان را بدهید. + +پیش از رفتن به بخش بعدی، پاد را حذف کنید: + +```shell +kubectl delete pod violation-pod --wait --now +``` + +## ایجاد یک پاد با پروفایل seccomp که فقط فراخوان‌های سیستمی لازم را مجاز می‌کند + +اگر به پروفایل `fine-grained.json` نگاهی بیندازید، برخی از فراخوان‌های سیستمی‌ای را خواهید دید که در syslogِ مثال اول—جایی که `"defaultAction": "SCMP_ACT_LOG"` تنظیم شده بود—مشاهده کردید. +اکنون این پروفایل مقدار `"defaultAction": "SCMP_ACT_ERRNO"` را تعیین می‌کند، اما مجموعه‌ای از فراخوان‌های سیستمی را به‌طور صریح در بلوک `"action": "SCMP_ACT_ALLOW"` مجاز اعلام می‌کند. در حالت ایده‌آل، کانتینر بدون مشکل اجرا می‌شود و هیچ پیامی به `syslog` ارسال نخواهد شد. + +مانیفست این مثال به شکل زیر است: + +{{% code_sample file="pods/security/seccomp/ga/fine-pod.yaml" %}} + +پاد را در خوشه خود ایجاد کنید: + +```shell +kubectl apply -f https://k8s.io/examples/pods/security/seccomp/ga/fine-pod.yaml +``` + +```shell +kubectl get pod fine-pod +``` + +پاد باید با موفقیت شروع به کار کرده باشد: +``` +NAME READY STATUS RESTARTS AGE +fine-pod 1/1 Running 0 30s +``` + +یک پنجره ترمینال جدید باز کنید و از `tail` برای نظارت بر ورودی‌های لاگ که به فراخوانی‌های `http-echo` اشاره می‌کنند، استفاده کنید: + +```shell +# مسیر گزارش در رایانه شما ممکن است با "/var/log/syslog" متفاوت باشد. +tail -f /var/log/syslog | grep 'http-echo' +``` + +در مرحله بعد، Pod را با یک سرویس NodePort در معرض نمایش قرار دهید: + +```shell +kubectl expose pod fine-pod --type NodePort --port 5678 +``` + +بررسی کنید که چه پورتی به سرویس روی گره اختصاص داده شده است: + +```shell +kubectl get service fine-pod +``` + +خروجی مشابه زیر است: +``` +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +fine-pod NodePort 10.111.36.142 5678:32373/TCP 72s +``` + +برای دسترسی به آن نقطه پایانی از داخل کانتینر صفحه کنترل نوع، از `curl` استفاده کنید: + +```shell +# عدد 6a96207fed4b را به شناسه کانتینر صفحه کنترل و عدد 32373 را به شماره پورتی که در "docker ps" مشاهده کردید، تغییر دهید. +docker exec -it 6a96207fed4b curl localhost:32373 +``` + +``` +just made some syscalls! +``` + +نباید هیچ خروجی‌ای در `syslog` مشاهده کنید. دلیلش این است که پروفایل همه فراخوان‌های سیستمی ضروری را مجاز کرده و تعیین ‌کرده است اگر فراخوانی خارج از این فهرست انجام شود خطا رخ دهد. از دیدگاه امنیتی، این وضعیت ایده‌آلی است؛ ولی برای رسیدن به آن باید زمان و تلاش صرف تحلیل برنامه می‌شد. عالی می‌شد اگر راه ساده‌تری برای نزدیک‌شدن به این سطح امنیت بدون این‌همه تلاش وجود داشت. + +پیش از رفتن به بخش بعدی، Service و Pod را حذف کنید: + +```shell +kubectl delete service fine-pod --wait +kubectl delete pod fine-pod --wait --now +``` + +## فعال‌سازی استفاده از `RuntimeDefault` به‌عنوان پروفایل seccomp پیش‌فرض برای همه بارهای کاری + +{{< feature-state state="stable" for_k8s_version="v1.27" >}} + +برای بهره‌گیری از پیش‌فرض‌گذاریِ پروفایل seccomp، باید برای هر گره‌ای که می‌خواهید از این قابلیت استفاده کند، kubelet را با فلگ خط فرمان +`--seccomp-default` +[command line flag](/docs/reference/command-line-tools-reference/kubelet) +اجرا کنید. + +اگر این قابلیت فعال شود، kubelet به‌طور پیش‌فرض از پروفایل seccomp با نام `RuntimeDefault` که توسط زمان‌اجرای کانتینر تعریف می‌شود استفاده خواهد کرد و دیگر حالت `Unconfined` (غیرفعال بودن seccomp) به کار نمی‌رود. +پروفایل‌های پیش‌فرض در تلاش‌اند مجموعه‌ای قدرتمند از تنظیمات امنیتی را بدون لطمه به کارکرد بار کاری فراهم کنند. +ممکن است این پروفایل‌های پیش‌فرض در میان زمان‌اجرای‌های کانتینر و نسخه‌های انتشار آن‌ها (برای نمونه CRI-O و containerd) متفاوت باشند. + +{{< note >}} +فعالسازی این قابلیت، فیلد API مربوط به `securityContext.seccompProfile` در Kubernetes را تغییر نداده و annotationهای منسوخ‌شده بار کاری را نیز اضافه نمی‌کند. +به این ترتیب، کاربران هر زمان که بخواهند می‌توانند بدون تغییر واقعی در پیکربندی بار کاری به وضعیت قبلی بازگردند. +برای اطمینان از این‌که یک کانتینر از کدام پروفایل seccomp استفاده می‌کند، می‌توان از ابزارهایی همچون +[`crictl inspect`](https://github.com/kubernetes-sigs/cri-tools) بهره برد. +{{< /note >}} + +برخی بارهای کاری ممکن است به محدودیت‌های کمتری بر روی فراخوان‌های سیستمی نیاز داشته باشند؛ بنابراین حتی با پروفایل `RuntimeDefault` نیز ممکن است در زمان اجرا با خطا مواجه شوند. برای رفع این مشکل می‌توانید: + +- بار کاری را صراحتاً با حالت `Unconfined` اجرا کنید. +- قابلیت `SeccompDefault` را برای گره‌ها غیرفعال کنید و اطمینان یابید که بارهای کاری روی گره‌هایی زمان‌بندی شوند که این قابلیت غیرفعال است. +- یک پروفایل seccomp سفارشی برای بار کاری ایجاد کنید. + +اگر قصد دارید این قابلیت را در یک خوشه شبیه محیط تولید فعال کنید، پروژه Kubernetes توصیه می‌کند ابتدا این درگاه قابلیت (feature gate) را بر روی زیرمجموعه‌ای از گره‌ها فعال کرده و پس از آزمایش اجرای بارهای کاری، آن را در کل خوشه گسترش دهید. + +اطلاعات مفصل‌تر درباره راهبرد ارتقا و بازگشت (downgrade) را می‌توانید در پیشنهاد تکمیلی Kubernetes (KEP) مرتبط بیابید: +[Enable seccomp by default](https://github.com/kubernetes/enhancements/tree/9a124fd29d1f9ddf2ff455c49a630e3181992c25/keps/sig-node/2413-seccomp-by-default#upgrade--downgrade-strategy). + +Kubernetes {{< skew currentVersion >}} اجازه می‌دهد پروفایل seccompی را پیکربندی کنید که در صورت تعریف‌نشدن پروفایل مشخص در spec پاد اعمال می‌شود؛ با این حال همچنان باید این پیش‌فرض‌گذاری را برای هر گره‌ای که می‌خواهید فعال کنید. + +اگر از خوشه Kubernetes {{< skew currentVersion >}} استفاده می‌کنید و می‌خواهید این قابلیت را فعال کنید، یا kubelet را با فلگ خط فرمان `--seccomp-default` اجرا کنید، یا آن را از طریق [فایل پیکربندی kubelet](/docs/tasks/administer-cluster/kubelet-config-file/) فعال سازید. +برای فعال‌کردن این درگاه قابلیت در [kind](https://kind.sigs.k8s.io)، مطمئن شوید که `kind` نسخه حداقل موردنیاز Kubernetes را فراهم می‌کند و قابلیت `SeccompDefault` را +[در پیکربندی kind](https://kind.sigs.k8s.io/docs/user/quick-start/#enable-feature-gates-in-your-cluster) +فعال کرده است: + +```yaml +kind: Cluster +apiVersion: kind.x-k8s.io/v1alpha4 +nodes: + - role: control-plane + image: kindest/node:v1.28.0@sha256:9f3ff58f19dcf1a0611d11e8ac989fdb30a28f40f236f59f0bea31fb956ccf5c + kubeadmConfigPatches: + - | + kind: JoinConfiguration + nodeRegistration: + kubeletExtraArgs: + seccomp-default: "true" + - role: worker + image: kindest/node:v1.28.0@sha256:9f3ff58f19dcf1a0611d11e8ac989fdb30a28f40f236f59f0bea31fb956ccf5c + kubeadmConfigPatches: + - | + kind: JoinConfiguration + nodeRegistration: + kubeletExtraArgs: + seccomp-default: "true" +``` + +اگر خوشه آماده باشد، آنگاه یک پاد اجرا می‌شود: + +```shell +kubectl run --rm -it --restart=Never --image=alpine alpine -- sh +``` + +اکنون باید پروفایل پیش‌فرض seccomp پیوست شده باشد. این موضوع را می‌توان با استفاده از `docker exec` برای اجرای `crictl inspect` برای کانتینر روی worker نوع تأیید کرد: + +```shell +docker exec -it kind-worker bash -c \ + 'crictl inspect $(crictl ps --name=alpine -q) | jq .info.runtimeSpec.linux.seccomp' +``` + +```json +{ + "defaultAction": "SCMP_ACT_ERRNO", + "architectures": ["SCMP_ARCH_X86_64", "SCMP_ARCH_X86", "SCMP_ARCH_X32"], + "syscalls": [ + { + "names": ["..."] + } + ] +} +``` + +## {{% heading "whatsnext" %}} + +می‌توانید درباره seccomp در لینوکس بیشتر بیاموزید: + +* [مروری بر seccomp](https://lwn.net/Articles/656307/) +* [پروفایل‌های امنیتی seccomp برای Docker](https://docs.docker.com/engine/security/seccomp/) diff --git a/content/fa/docs/tutorials/services/_index.md b/content/fa/docs/tutorials/services/_index.md new file mode 100644 index 0000000000000..8817636117b5d --- /dev/null +++ b/content/fa/docs/tutorials/services/_index.md @@ -0,0 +1,5 @@ +--- +title: "سرویس‌ها" +weight: 70 +--- + diff --git a/content/fa/docs/tutorials/services/connect-applications-service.md b/content/fa/docs/tutorials/services/connect-applications-service.md new file mode 100644 index 0000000000000..9660ded56e9b6 --- /dev/null +++ b/content/fa/docs/tutorials/services/connect-applications-service.md @@ -0,0 +1,510 @@ +--- +reviewers: +- xirehat +title: اتصال برنامه‌ها با سرویس‌ها +content_type: tutorial +weight: 20 +--- + + + + +## مدل کوبرنتیز برای اتصال کانتینرها + +حالا که یک برنامه مداوم و تکثیرشونده دارید، می‌توانید آن را روی یک شبکه در معرض دید قرار دهید. + +کوبرنتیز فرض می‌کند پادها، فارغ از اینکه روی کدام میزبان قرار بگیرند، می‌توانند با یکدیگر ارتباط برقرار کنند. +کوبرنتیز به هر پاد یک نشانی IP اختصاصی درونِ خوشه می‌دهد؛ بنابراین نیازی نیست صراحتاً +بین پادها پیوند ایجاد کنید یا پورت‌های کانتینر را به پورت‌های میزبان نگاشت کنید. این یعنی کانتینرهای +درون یک پاد می‌توانند از طریق `localhost` به پورت‌های یکدیگر دسترسی داشته باشند و همه پادهای +خوشه بدون نیاز به NAT یکدیگر را ببینند. ادامه این سند توضیح می‌دهد چگونه می‌توانید سرویس‌های +قابل‌اعتماد را روی چنین مدل شبکه‌ای اجرا کنید. + +این راهنما از یک وب‌سرور ساده **nginx** برای نمایش این مفهوم بهره می‌برد. + + + +## در معرض قرار دادن پادها برای خوشه + +این کار را در مثال قبلی انجام دادیم، اما بیایید دوباره آن را انجام دهیم و بر دیدگاه شبکه‌ای تمرکز کنیم. +یک پاد **nginx** ایجاد کنید و توجه کنید که یک مشخصه پورت کانتینر دارد: + +{{% code_sample file="service/networking/run-my-nginx.yaml" %}} + +این باعث می‌شود پاد از هر نودی در خوشه شما قابل‌دسترس باشد. نودهایی که پاد روی آن‌ها در حال اجراست را بررسی کنید: + +```shell +kubectl apply -f ./run-my-nginx.yaml +kubectl get pods -l run=my-nginx -o wide +``` +``` +NAME READY STATUS RESTARTS AGE IP NODE +my-nginx-3800858182-jr4a2 1/1 Running 0 13s 10.244.3.4 kubernetes-minion-905m +my-nginx-3800858182-kna2y 1/1 Running 0 13s 10.244.2.5 kubernetes-minion-ljyd +``` + +آی‌پی‌های پادهای خود را بررسی کنید: + +```shell +kubectl get pods -l run=my-nginx -o custom-columns=POD_IP:.status.podIPs + POD_IP + [map[ip:10.244.3.4]] + [map[ip:10.244.2.5]] +``` + +شما باید بتوانید به هر نود در خوشه خود از طریق SSH متصل شوید و با ابزاری مثل `curl` +از هر دو نشانی IP درخواست بفرستید. توجه کنید که کانتینرها *پورت ۸۰* روی نود را استفاده نمی‌کنند +و هیچ قانون NAT‌ ویژه‌ای برای مسیریابی ترافیک به پاد وجود ندارد. این یعنی می‌توانید +چندین پاد nginx را روی یک نود به‌طور هم‌زمان و با همان `containerPort` اجرا کنید، +و از هر پاد یا نود دیگری در خوشه با استفاده از نشانی IP اختصاصی پاد به آن‌ها دسترسی +پیدا کنید. اگر بخواهید پورت مشخصی روی نود میزبان را به پادهای پشتیبان فوروارد کنید، +امکانش هست ــ اما مدل شبکه‌ای باید طوری باشد که معمولاً به این کار نیازی نداشته باشید. + +اگر کنجکاو هستید، می‌توانید درباره +[مدل شبکه‌ای کوبرنتیز](/docs/concepts/cluster-administration/networking/#the-kubernetes-network-model) +بیشتر بخوانید. + +## ایجاد یک سرویس (Service) + +حال پادهایی داریم که nginx را در یک فضاى آدرس تخت و سراسری خوشه اجرا می‌کنند. در تئوری +می‌توانید مستقیماً با این پادها ارتباط بگیرید، اما وقتی یک نود از کار بیفتد چه می‌شود؟ +پادها همراه با آن می‌میرند و ReplicaSet‌ داخل Deployment پادهای جدیدی با IPهای متفاوت +می‌سازد. این همان مشکلی است که یک Service حل می‌کند. + +یک سرویس کوبرنتیز انتزاعی است که یک مجموعه منطقی از پادهایی را تعریف می‌کند +که در جایی از خوشه شما اجرا می‌شوند و همگی عملکرد یکسانی ارائه می‌دهند. هنگام ایجاد، +به هر سرویس یک نشانی IP یکتا (که clusterIP هم نامیده می‌شود) تخصیص داده می‌شود. +این نشانی تا زمانی که سرویس زنده است تغییر نخواهد کرد. پادها می‌توانند طوری پیکربندی شوند +که با سرویس صحبت کنند و مطمئن باشند ارتباط با سرویس به‌طور خودکار میان پادهای عضو سرویس +بارگذاری متعادل (load-balanced) می‌شود. + +می‌توانید برای دو رپلیکای nginx خود با دستور `kubectl expose` یک سرویس بسازید: + +```shell +kubectl expose deployment/my-nginx +``` +``` +service/my-nginx exposed +``` + +این معادل اجرای `kubectl apply -f` روی YAML زیر است: + +{{% code_sample file="service/networking/nginx-svc.yaml" %}} + +این مشخصات سرویسی می‌سازد که پورت 80/TCP روی هر پادی با برچسب `run: my-nginx` +را هدف قرار می‌دهد و آن را روی یک پورت انتزاعی سرویس در معرض دید قرار می‌دهد +(`targetPort`: پورتی است که کانتینر درخواست‌ها را روی آن می‌پذیرد، `port`: پورت +انتزاعی سرویس است که می‌تواند هر پورتی باشد که پادهای دیگر برای دسترسی به سرویس +به کار ببرند). +برای مشاهده فهرست فیلدهای پشتیبانی‌شده در تعریف سرویس، به شیٔ API +[Service](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core) +مراجعه کنید. +سرویس خود را بررسی کنید: + +```shell +kubectl get svc my-nginx +``` +``` +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +my-nginx ClusterIP 10.0.162.149 80/TCP 21s +``` + +همان‌طور که پیش‌تر اشاره شد، یک **Service** توسط مجموعه‌ای از *Pod*ها پشتیبانی می‌شود. +این پادها از طریق {{}} در معرض دید قرار می‌گیرند. +**selector** سرویس به‌طور پیوسته ارزیابی می‌شود و نتایج به یک EndpointSlice که با استفاده از {{< glossary_tooltip text="labels" term_id="label" >}} به سرویس متصل است، ‌POST می‌شود. + +وقتی یک پاد از بین برود، به‌طور خودکار از EndpointSliceهایی که آن را به‌عنوان *endpoint* دارند حذف می‌شود. +پادهای جدیدی که با selector سرویس مطابقت داشته باشند، به‌طور خودکار به یک EndpointSlice مربوط به آن سرویس افزوده می‌شوند. + +اندپوینت‌ها را بررسی کنید و دقت کنید که IPها همان‌هایی هستند که در پادهای ایجادشده در گام نخست مشاهده کردید: + +```shell +kubectl describe svc my-nginx +``` +``` +Name: my-nginx +Namespace: default +Labels: run=my-nginx +Annotations: +Selector: run=my-nginx +Type: ClusterIP +IP Family Policy: SingleStack +IP Families: IPv4 +IP: 10.0.162.149 +IPs: 10.0.162.149 +Port: 80/TCP +TargetPort: 80/TCP +Endpoints: 10.244.2.5:80,10.244.3.4:80 +Session Affinity: None +Events: +``` +```shell +kubectl get endpointslices -l kubernetes.io/service-name=my-nginx +``` +``` +NAME ADDRESSTYPE PORTS ENDPOINTS AGE +my-nginx-7vzhx IPv4 80 10.244.2.5,10.244.3.4 21s +``` + +اکنون باید بتوانید از هر نود در خوشه خود فرمان `curl` را برای سرویس nginx روی +`:` اجرا کنید. توجه داشته باشید که IP سرویس کاملاً مجازی است و هرگز +بر روی سیم منتقل نمی‌شود. اگر کنجکاو هستید که این موضوع چگونه کار می‌کند، +می‌توانید درباره [پروکسی سرویس](/docs/reference/networking/virtual-ips/) بیشتر بخوانید. + +## دسترسی به سرویس + +کوبرنتیز دو روش اصلی برای یافتن یک سرویس پشتیبانی می‌کند: متغیرهای محیطی +و DNS. روش نخست به‌صورت پیش‌فرض فعال است، در حالی که دومی به افزونه +[CoreDNS cluster addon](https://releases.k8s.io/v{{< skew currentPatchVersion >}}/cluster/addons/dns/coredns) +نیاز دارد. + +{{< note >}} +اگر متغیرهای محیطی سرویس مطلوب نیستند (به دلیل احتمال تداخل با متغیرهای مورد انتظار +برنامه، تعداد زیاد متغیرها برای پردازش، استفاده صرف از DNS و غیره) می‌توانید این قابلیت +را با قرار دادن فلگ `enableServiceLinks` روی مقدار `false` در +[مشخصات پاد](/docs/reference/generated/kubernetes-api/v{{< skew latestVersion >}}/#pod-v1-core) +غیرفعال کنید. +{{< /note >}} + +### متغیرهای محیطی + +وقتی یک پاد روی یک نود اجرا می‌شود، kubelet برای هر سرویس فعال مجموعه‌ای از +متغیرهای محیطی اضافه می‌کند. این کار باعث بروز مشکل ترتیب (ordering) می‌شود. +برای درک دلیل آن، محیط متغیرهای پادهای nginx در حال اجرا را بررسی کنید +(نام پاد شما متفاوت خواهد بود): + +```shell +kubectl exec my-nginx-3800858182-jr4a2 -- printenv | grep SERVICE +``` +``` +KUBERNETES_SERVICE_HOST=10.0.0.1 +KUBERNETES_SERVICE_PORT=443 +KUBERNETES_SERVICE_PORT_HTTPS=443 +``` + +توجه کنید که هیچ اشاره‌ای به سرویس شما نشده است. این به این دلیل است که رپلیکاها را پیش از سرویس ایجاد کرده‌اید. +عیب دیگر این کار این است که زمان‌بند ممکن است هر دو پاد را روی یک ماشین قرار دهد؛ در نتیجه اگر آن ماشین از کار بیفتد، کل سرویس از دسترس خارج می‌شود. +می‌توانیم این کار را به‌شیوه درست انجام دهیم: دو پاد را حذف کنیم و منتظر بمانیم تا Deployment آن‌ها را دوباره بسازد. +این بار سرویس *پیش از* رپلیکاها وجود خواهد داشت. +به این ترتیب، زمان‌بند پادهای شما را در سطح سرویس به‌طور پراکنده توزیع می‌کند (به‌شرط آنکه همه نودها ظرفیت برابر داشته باشند) و همچنین متغیرهای محیطی درست را فراهم می‌آورد: + +```shell +kubectl scale deployment my-nginx --replicas=0; kubectl scale deployment my-nginx --replicas=2; + +kubectl get pods -l run=my-nginx -o wide +``` +``` +NAME READY STATUS RESTARTS AGE IP NODE +my-nginx-3800858182-e9ihh 1/1 Running 0 5s 10.244.2.7 kubernetes-minion-ljyd +my-nginx-3800858182-j4rm4 1/1 Running 0 5s 10.244.3.8 kubernetes-minion-905m +``` + +ممکن است متوجه شده باشید که غلاف‌ها نام‌های مختلفی دارند، زیرا کشته و دوباره ساخته می‌شوند. + +```shell +kubectl exec my-nginx-3800858182-e9ihh -- printenv | grep SERVICE +``` +``` +KUBERNETES_SERVICE_PORT=443 +MY_NGINX_SERVICE_HOST=10.0.162.149 +KUBERNETES_SERVICE_HOST=10.0.0.1 +MY_NGINX_SERVICE_PORT=80 +KUBERNETES_SERVICE_PORT_HTTPS=443 +``` + +### DNS + +کوبرنتیز یک سرویس افزونه خوشه DNS ارائه می‌دهد که به طور خودکار نام‌های DNS را به سایر سرویس‌ها اختصاص می‌دهد. می‌توانید بررسی کنید که آیا این سرویس روی خوشه شما اجرا می‌شود یا خیر: + +```shell +kubectl get services kube-dns --namespace=kube-system +``` +``` +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +kube-dns ClusterIP 10.0.0.10 53/UDP,53/TCP 8m +``` + +باقیِ این بخش فرض می‌کند که یک سرویس با یک IP طولانی‌عمر (`my-nginx`) در اختیار دارید و یک سرور DNS نامی را به آن IP اختصاص داده است. +در اینجا از افزونه خوشه **CoreDNS** (نام برنامه `kube-dns`) استفاده می‌کنیم؛ بنابراین می‌توانید از هر پادی در خوشه با روش‌های استاندارد (مثلاً `gethostbyname()`) با سرویس صحبت کنید. +اگر CoreDNS در حال اجرا نیست، می‌توانید با مراجعه به [README ‏CoreDNS](https://github.com/coredns/deployment/tree/master/kubernetes) یا بخش +[Installing CoreDNS](/docs/tasks/administer-cluster/coredns/#installing-coredns) آن را فعال کنید. + +بیایید برای آزمایش، یک برنامه curl دیگر اجرا کنیم: + +```shell +kubectl run curl --image=radial/busyboxplus:curl -i --tty --rm +``` +``` +Waiting for pod default/curl-131556218-9fnch to be running, status is Pending, pod ready: false +Hit enter for command prompt +``` + +سپس، اینتر را بزنید و دستور `nslookup my-nginx` را اجرا کنید: + +```shell +[ root@curl-131556218-9fnch:/ ]$ nslookup my-nginx +Server: 10.0.0.10 +Address 1: 10.0.0.10 + +Name: my-nginx +Address 1: 10.0.162.149 +``` + +## ایمن‌سازی سرویس + +تا اینجا فقط از داخل خوشه به سرور nginx دسترسی داشته‌ایم. قبل از آنکه سرویس را به اینترنت در معرض دید قرار دهید، باید مطمئن شوید کانال ارتباطی امن است. برای این کار به موارد زیر نیاز دارید: + +* گواهی‌های خودامضا برای HTTPS (مگر اینکه قبلاً یک گواهی هویت معتبر داشته باشید) +* یک سرور nginx که برای استفاده از این گواهی‌ها پیکربندی شده باشد +* یک [Secret](/docs/concepts/configuration/secret/) که گواهی‌ها را در اختیار پادها قرار دهد + +می‌توانید همه این موارد را از +[نمونه nginx با HTTPS](https://github.com/kubernetes/examples/tree/master/staging/https-nginx/) +تهیه کنید. این کار نیازمند نصب ابزارهای **go** و **make** است. اگر تمایلی به نصب آن‌ها ندارید، +می‌توانید مراحل دستی را که بعداً می‌آید دنبال کنید. به طور خلاصه: + +```shell +make keys KEY=/tmp/nginx.key CERT=/tmp/nginx.crt +kubectl create secret tls nginxsecret --key /tmp/nginx.key --cert /tmp/nginx.crt +``` +``` +secret/nginxsecret created +``` +```shell +kubectl get secrets +``` +``` +NAME TYPE DATA AGE +nginxsecret kubernetes.io/tls 2 1m +``` +و همچنین configmap: +```shell +kubectl create configmap nginxconfigmap --from-file=default.conf +``` + +می‌توانید نمونه‌ای از فایل `default.conf` را در +[مخزن پروژه نمونه‌های Kubernetes](https://github.com/kubernetes/examples/tree/bc9ca4ca32bb28762ef216386934bef20f1f9930/staging/https-nginx/) +پیدا کنید. + +``` +configmap/nginxconfigmap created +``` +```shell +kubectl get configmaps +``` +``` +NAME DATA AGE +nginxconfigmap 1 114s +``` + +شما می‌توانید جزئیات ConfigMap مربوط به `nginxconfigmap` را با استفاده از دستور زیر مشاهده کنید: + +```shell +kubectl describe configmap nginxconfigmap +``` + +خروجی مشابه زیر است: + +```console +Name: nginxconfigmap +Namespace: default +Labels: +Annotations: + +Data +==== +default.conf: +---- +server { + listen 80 default_server; + listen [::]:80 default_server ipv6only=on; + + listen 443 ssl; + + root /usr/share/nginx/html; + index index.html; + + server_name localhost; + ssl_certificate /etc/nginx/ssl/tls.crt; + ssl_certificate_key /etc/nginx/ssl/tls.key; + + location / { + try_files $uri $uri/ =404; + } +} + +BinaryData +==== + +Events: +``` + +در صورت بروز مشکل در اجرای make (مثلاً در ویندوز)، مراحل دستی زیر را دنبال کنید: + +```shell +# ایجاد یک جفت کلید عمومی-خصوصی +openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /d/tmp/nginx.key -out /d/tmp/nginx.crt -subj "/CN=my-nginx/O=my-nginx" +# تبدیل کلیدها به کدگذاری base64 +cat /d/tmp/nginx.crt | base64 +cat /d/tmp/nginx.key | base64 +``` + +از خروجی دستورات قبلی برای ایجاد یک فایل yaml به صورت زیر استفاده کنید. +مقدار کدگذاری شده base64 باید همگی در یک خط باشند. + +```yaml +apiVersion: "v1" +kind: "Secret" +metadata: + name: "nginxsecret" + namespace: "default" +type: kubernetes.io/tls +data: + tls.crt: "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURIekNDQWdlZ0F3SUJBZ0lKQUp5M3lQK0pzMlpJTUEwR0NTcUdTSWIzRFFFQkJRVUFNQ1l4RVRBUEJnTlYKQkFNVENHNW5hVzU0YzNaak1SRXdEd1lEVlFRS0V3aHVaMmx1ZUhOMll6QWVGdzB4TnpFd01qWXdOekEzTVRKYQpGdzB4T0RFd01qWXdOekEzTVRKYU1DWXhFVEFQQmdOVkJBTVRDRzVuYVc1NGMzWmpNUkV3RHdZRFZRUUtFd2h1CloybHVlSE4yWXpDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBSjFxSU1SOVdWM0IKMlZIQlRMRmtobDRONXljMEJxYUhIQktMSnJMcy8vdzZhU3hRS29GbHlJSU94NGUrMlN5ajBFcndCLzlYTnBwbQppeW1CL3JkRldkOXg5UWhBQUxCZkVaTmNiV3NsTVFVcnhBZW50VWt1dk1vLzgvMHRpbGhjc3paenJEYVJ4NEo5Ci82UVRtVVI3a0ZTWUpOWTVQZkR3cGc3dlVvaDZmZ1Voam92VG42eHNVR0M2QURVODBpNXFlZWhNeVI1N2lmU2YKNHZpaXdIY3hnL3lZR1JBRS9mRTRqakxCdmdONjc2SU90S01rZXV3R0ljNDFhd05tNnNTSzRqYUNGeGpYSnZaZQp2by9kTlEybHhHWCtKT2l3SEhXbXNhdGp4WTRaNVk3R1ZoK0QrWnYvcW1mMFgvbVY0Rmo1NzV3ajFMWVBocWtsCmdhSXZYRyt4U1FVQ0F3RUFBYU5RTUU0d0hRWURWUjBPQkJZRUZPNG9OWkI3YXc1OUlsYkROMzhIYkduYnhFVjcKTUI4R0ExVWRJd1FZTUJhQUZPNG9OWkI3YXc1OUlsYkROMzhIYkduYnhFVjdNQXdHQTFVZEV3UUZNQU1CQWY4dwpEUVlKS29aSWh2Y05BUUVGQlFBRGdnRUJBRVhTMW9FU0lFaXdyMDhWcVA0K2NwTHI3TW5FMTducDBvMm14alFvCjRGb0RvRjdRZnZqeE04Tzd2TjB0clcxb2pGSW0vWDE4ZnZaL3k4ZzVaWG40Vm8zc3hKVmRBcStNZC9jTStzUGEKNmJjTkNUekZqeFpUV0UrKzE5NS9zb2dmOUZ3VDVDK3U2Q3B5N0M3MTZvUXRUakViV05VdEt4cXI0Nk1OZWNCMApwRFhWZmdWQTRadkR4NFo3S2RiZDY5eXM3OVFHYmg5ZW1PZ05NZFlsSUswSGt0ejF5WU4vbVpmK3FqTkJqbWZjCkNnMnlwbGQ0Wi8rUUNQZjl3SkoybFIrY2FnT0R4elBWcGxNSEcybzgvTHFDdnh6elZPUDUxeXdLZEtxaUMwSVEKQ0I5T2wwWW5scE9UNEh1b2hSUzBPOStlMm9KdFZsNUIyczRpbDlhZ3RTVXFxUlU9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K" + tls.key: "LS0tLS1CRUdJTiBQUklWQVRFIEtFWS0tLS0tCk1JSUV2UUlCQURBTkJna3Foa2lHOXcwQkFRRUZBQVNDQktjd2dnU2pBZ0VBQW9JQkFRQ2RhaURFZlZsZHdkbFIKd1V5eFpJWmVEZWNuTkFhbWh4d1NpeWF5N1AvOE9ta3NVQ3FCWmNpQ0RzZUh2dGtzbzlCSzhBZi9WemFhWm9zcApnZjYzUlZuZmNmVUlRQUN3WHhHVFhHMXJKVEVGSzhRSHA3VkpMcnpLUC9QOUxZcFlYTE0yYzZ3MmtjZUNmZitrCkU1bEVlNUJVbUNUV09UM3c4S1lPNzFLSWVuNEZJWTZMMDUrc2JGQmd1Z0ExUE5JdWFubm9UTWtlZTRuMG4rTDQKb3NCM01ZUDhtQmtRQlAzeE9JNHl3YjREZXUraURyU2pKSHJzQmlIT05Xc0RadXJFaXVJMmdoY1kxeWIyWHI2UAozVFVOcGNSbC9pVG9zQngxcHJHclk4V09HZVdPeGxZZmcvbWIvNnBuOUYvNWxlQlkrZStjSTlTMkQ0YXBKWUdpCkwxeHZzVWtGQWdNQkFBRUNnZ0VBZFhCK0xkbk8ySElOTGo5bWRsb25IUGlHWWVzZ294RGQwci9hQ1Zkank4dlEKTjIwL3FQWkUxek1yall6Ry9kVGhTMmMwc0QxaTBXSjdwR1lGb0xtdXlWTjltY0FXUTM5SjM0VHZaU2FFSWZWNgo5TE1jUHhNTmFsNjRLMFRVbUFQZytGam9QSFlhUUxLOERLOUtnNXNrSE5pOWNzMlY5ckd6VWlVZWtBL0RBUlBTClI3L2ZjUFBacDRuRWVBZmI3WTk1R1llb1p5V21SU3VKdlNyblBESGtUdW1vVlVWdkxMRHRzaG9reUxiTWVtN3oKMmJzVmpwSW1GTHJqbGtmQXlpNHg0WjJrV3YyMFRrdWtsZU1jaVlMbjk4QWxiRi9DSmRLM3QraTRoMTVlR2ZQegpoTnh3bk9QdlVTaDR2Q0o3c2Q5TmtEUGJvS2JneVVHOXBYamZhRGR2UVFLQmdRRFFLM01nUkhkQ1pKNVFqZWFKClFGdXF4cHdnNzhZTjQyL1NwenlUYmtGcVFoQWtyczJxWGx1MDZBRzhrZzIzQkswaHkzaE9zSGgxcXRVK3NHZVAKOWRERHBsUWV0ODZsY2FlR3hoc0V0L1R6cEdtNGFKSm5oNzVVaTVGZk9QTDhPTm1FZ3MxMVRhUldhNzZxelRyMgphRlpjQ2pWV1g0YnRSTHVwSkgrMjZnY0FhUUtCZ1FEQmxVSUUzTnNVOFBBZEYvL25sQVB5VWs1T3lDdWc3dmVyClUycXlrdXFzYnBkSi9hODViT1JhM05IVmpVM25uRGpHVHBWaE9JeXg5TEFrc2RwZEFjVmxvcG9HODhXYk9lMTAKMUdqbnkySmdDK3JVWUZiRGtpUGx1K09IYnRnOXFYcGJMSHBzUVpsMGhucDBYSFNYVm9CMUliQndnMGEyOFVadApCbFBtWmc2d1BRS0JnRHVIUVV2SDZHYTNDVUsxNFdmOFhIcFFnMU16M2VvWTBPQm5iSDRvZUZKZmcraEppSXlnCm9RN3hqWldVR3BIc3AyblRtcHErQWlSNzdyRVhsdlhtOElVU2FsbkNiRGlKY01Pc29RdFBZNS9NczJMRm5LQTQKaENmL0pWb2FtZm1nZEN0ZGtFMXNINE9MR2lJVHdEbTRpb0dWZGIwMllnbzFyb2htNUpLMUI3MkpBb0dBUW01UQpHNDhXOTVhL0w1eSt5dCsyZ3YvUHM2VnBvMjZlTzRNQ3lJazJVem9ZWE9IYnNkODJkaC8xT2sybGdHZlI2K3VuCnc1YytZUXRSTHlhQmd3MUtpbGhFZDBKTWU3cGpUSVpnQWJ0LzVPbnlDak9OVXN2aDJjS2lrQ1Z2dTZsZlBjNkQKckliT2ZIaHhxV0RZK2Q1TGN1YSt2NzJ0RkxhenJsSlBsRzlOZHhrQ2dZRUF5elIzT3UyMDNRVVV6bUlCRkwzZAp4Wm5XZ0JLSEo3TnNxcGFWb2RjL0d5aGVycjFDZzE2MmJaSjJDV2RsZkI0VEdtUjZZdmxTZEFOOFRwUWhFbUtKCnFBLzVzdHdxNWd0WGVLOVJmMWxXK29xNThRNTBxMmk1NVdUTThoSDZhTjlaMTltZ0FGdE5VdGNqQUx2dFYxdEYKWSs4WFJkSHJaRnBIWll2NWkwVW1VbGc9Ci0tLS0tRU5EIFBSSVZBVEUgS0VZLS0tLS0K" +``` +حالا با استفاده از فایل، رمزها را ایجاد کنید: + +```shell +kubectl apply -f nginxsecrets.yaml +kubectl get secrets +``` +``` +NAME TYPE DATA AGE +nginxsecret kubernetes.io/tls 2 1m +``` + +اکنون رپلیکای‌های nginx خود را طوری تغییر دهید که با استفاده از گواهی موجود در Secret +یک سرور HTTPS راه‌اندازی کنند و سرویس نیز هر دو پورت (80 و 443) را در معرض دید قرار دهد: + +{{% code_sample file="service/networking/nginx-secure-app.yaml" %}} + +نکات قابل توجه درباره مانیفست **nginx-secure-app**: + +- هم مشخصات Deployment و هم Service در یک فایل قرار دارند. +- [سرور nginx](https://github.com/kubernetes/examples/tree/master/staging/https-nginx/default.conf) + ترافیک HTTP را روی پورت 80 و ترافیک HTTPS را روی 443 سرو می‌کند و سرویس nginx + هر دو پورت را اکسپوز می‌کند. +- هر کانتینر از طریق یک volume که در مسیر `/etc/nginx/ssl` مونت شده به کلیدها دسترسی دارد. + این volume *پیش از* راه‌اندازی سرور nginx تنظیم می‌شود. + +```shell +kubectl delete deployments,svc my-nginx; kubectl create -f ./nginx-secure-app.yaml +``` + +در این مرحله می‌توانید از هر گره‌ای به سرور nginx دسترسی پیدا کنید. + +```shell +kubectl get pods -l run=my-nginx -o custom-columns=POD_IP:.status.podIPs + POD_IP + [map[ip:10.244.3.5]] +``` + +```shell +node $ curl -k https://10.244.3.5 +... +

Welcome to nginx!

+``` + +توجه کنید که در گام پیشین به فرمان `curl` گزینه `-k` را افزودیم؛ +علت این است که هنگام ایجاد گواهی، هیچ اطلاعی از پادهای در حال اجرای nginx نداریم، +بنابراین باید به curl بگوییم ناسازگاری CName را نادیده بگیرد. +با ساختن یک Service، CName‌ موجود در گواهی را به نام DNS واقعی‌ای که پادها هنگام جستجوی سرویس استفاده می‌کنند، پیوند دادیم. +حالا بیایید این را از درون یک پاد آزمایش کنیم +(برای سادگی همان Secret دوباره استفاده می‌شود؛ پاد فقط به فایل `nginx.crt` برای دسترسی به سرویس نیاز دارد): + +{{% code_sample file="service/networking/curlpod.yaml" %}} + +```shell +kubectl apply -f ./curlpod.yaml +kubectl get pods -l app=curlpod +``` +``` +NAME READY STATUS RESTARTS AGE +curl-deployment-1515033274-1410r 1/1 Running 0 1m +``` +```shell +kubectl exec curl-deployment-1515033274-1410r -- curl https://my-nginx --cacert /etc/nginx/ssl/tls.crt +... +Welcome to nginx! +... +``` + +## در معرض قرار دادن سرویس + +برای برخی قسمت‌های برنامه‌تان ممکن است بخواهید یک سرویس را روی یک نشانی IP خارجی قرار دهید. +کوبرنتیز دو شیوه برای این کار پشتیبانی می‌کند: **NodePort** و **LoadBalancer**. +سرویسی که در بخش پیشین ساختید از قبل از نوع `NodePort` بود؛ بنابراین اگر نود شما یک IP عمومی داشته باشد، رپلیکای HTTPS nginx آماده است تا ترافیک اینترنتی را پاسخ دهد. + +```shell +kubectl get svc my-nginx -o yaml | grep nodePort -C 5 + uid: 07191fb3-f61a-11e5-8ae5-42010af00002 +spec: + clusterIP: 10.0.162.149 + ports: + - name: http + nodePort: 31704 + port: 8080 + protocol: TCP + targetPort: 80 + - name: https + nodePort: 32453 + port: 443 + protocol: TCP + targetPort: 443 + selector: + run: my-nginx +``` +```shell +kubectl get nodes -o yaml | grep ExternalIP -C 1 + - address: 104.197.41.11 + type: ExternalIP + allocatable: +-- + - address: 23.251.152.56 + type: ExternalIP + allocatable: +... + +$ curl https://: -k +... +

Welcome to nginx!

+``` + +حالا بیایید سرویس را دوباره بسازیم تا از یک لود بالانسر ابری استفاده کند. +نوع سرویس `my-nginx` را از `NodePort` به `LoadBalancer` تغییر دهید: + +```shell +kubectl edit svc my-nginx +kubectl get svc my-nginx +``` +``` +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +my-nginx LoadBalancer 10.0.162.149 xx.xxx.xxx.xxx 8080:30163/TCP 21s +``` +``` +curl https:// -k +... +Welcome to nginx! +``` + +آدرس IP موجود در ستون `EXTERNAL-IP` همان آدرسی است که در اینترنت عمومی در دسترس قرار می‌گیرد. +`CLUSTER-IP` تنها در داخل خوشه یا شبکه ابری خصوصی شما قابل استفاده است. + +توجه کنید که در AWS، نوع `LoadBalancer` یک ELB ایجاد می‌کند که به‌جای IP از یک hostname (طولانی) استفاده می‌کند. این hostname آن‌قدر بلند است که در خروجی استاندارد `kubectl get svc` جا نمی‌شود؛ بنابراین باید از دستور `kubectl describe service my-nginx` استفاده کنید تا آن را ببینید. خروجی چیزی شبیه به این خواهد بود: + +```shell +kubectl describe service my-nginx +... +LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.elb.amazonaws.com +... +``` + + + +## {{% heading "whatsnext" %}} + + +* درباره [استفاده از یک Service برای دسترسی به یک برنامه در خوشه](/docs/tasks/access-application-cluster/service-access-application-cluster/) بیشتر بخوانید +* درباره [اتصال یک فرانت‌اند به یک بک‌اند با استفاده از Service](/docs/tasks/access-application-cluster/connecting-frontend-backend/) بیشتر بخوانید +* درباره [ایجاد یک لود بالانسر خارجی](/docs/tasks/access-application-cluster/create-external-load-balancer/) بیشتر بخوانید diff --git a/content/fa/docs/tutorials/services/pods-and-endpoint-termination-flow.md b/content/fa/docs/tutorials/services/pods-and-endpoint-termination-flow.md new file mode 100644 index 0000000000000..a861d4ee0f061 --- /dev/null +++ b/content/fa/docs/tutorials/services/pods-and-endpoint-termination-flow.md @@ -0,0 +1,172 @@ +--- +title: بررسی رفتار خاتمه برای Podها و Endpoint آنها +content_type: tutorial +weight: 60 +--- + + + + +پس از آنکه برنامه خود را طبق مراحلی شبیه به +[اتصال برنامه‌ها به سرویس‌ها](/docs/tutorials/services/connect-applications-service/) +به یک **Service** متصل کردید، اکنون یک برنامه تکرارشونده و همیشه‌درحال‌اجرا دارید که روی یک شبکه در معرض دید قرار گرفته است. +این آموزش به شما کمک می‌کند جریان خاتمه پادها را بررسی کرده و روش‌های پیاده‌سازی تخلیه تدریجی (graceful connection draining) را بشناسید. + + + +## فرایند خاتمه پادها و اندپوینت‌های آن‌ها + +اغلب پیش می‌آید که لازم است یک پاد را خاتمه دهید؛ چه برای به‌روزرسانی و چه برای کاهش مقیاس. +برای بهبود دسترس‌پذیری برنامه، اجرای یک تخلیه صحیحِ اتصال‌های فعال اهمیت دارد. + +این آموزش با استفاده از یک وب‌سرور ساده **nginx** برای نمایش مفهوم، +جریان خاتمه پاد را در ارتباط با وضعیت و حذف اندپوینت متناظر توضیح می‌دهد. + + + +## جریان نمونه با خاتمه اندپوینت + +آنچه در ادامه می‌آید، جریان نمونه‌ای است که در سند +[خاتمه پادها](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) +توصیف شده است. + +فرض کنید یک Deployment با تنها یک رپلیکای `nginx` +(صرفاً برای مقاصد نمایشی) و یک Service در اختیار دارید: + +{{% code_sample file="service/pod-with-graceful-termination.yaml" %}} + +{{% code_sample file="service/explore-graceful-termination-nginx.yaml" %}} + +اکنون پاد Deployment و سرویس را با استفاده از فایل‌های بالا ایجاد کنید: + +```shell +kubectl apply -f pod-with-graceful-termination.yaml +kubectl apply -f explore-graceful-termination-nginx.yaml +``` + +پس از اجرای Pod و Service، می‌توانید نام هر EndpointSlice مرتبط را دریافت کنید: + +```shell +kubectl get endpointslice +``` + +خروجی مشابه این است: + +```none +NAME ADDRESSTYPE PORTS ENDPOINTS AGE +nginx-service-6tjbr IPv4 80 10.12.1.199,10.12.1.201 22m +``` + +می‌توانید وضعیت آن را مشاهده کنید و تأیید کنید که یک نقطه پایانی ثبت شده است: + +```shell +kubectl get endpointslices -o json -l kubernetes.io/service-name=nginx-service +``` + +خروجی مشابه این است: + +```none +{ + "addressType": "IPv4", + "apiVersion": "discovery.k8s.io/v1", + "endpoints": [ + { + "addresses": [ + "10.12.1.201" + ], + "conditions": { + "ready": true, + "serving": true, + "terminating": false +``` + +حالا بیایید Pod را خاتمه دهیم و اعتبارسنجی کنیم که Pod با رعایت پیکربندی دوره خاتمه تدریجی خاتمه می‌یابد: + +```shell +kubectl delete pod nginx-deployment-7768647bf9-b4b9s +``` + +همه پادها: + +```shell +kubectl get pods +``` + +خروجی مشابه این است: + +```none +NAME READY STATUS RESTARTS AGE +nginx-deployment-7768647bf9-b4b9s 1/1 Terminating 0 4m1s +nginx-deployment-7768647bf9-rkxlw 1/1 Running 0 8s +``` + +می‌توانید ببینید که پاد جدید زمان‌بندی شده است. + +در حالی که نقطه پایانی جدید برای پاد جدید ایجاد می‌شود، نقطه پایانی قدیمی هنوز در حالت خاتمه است: + +```shell +kubectl get endpointslice -o json nginx-service-6tjbr +``` + +خروجی مشابه این است: + +```none +{ + "addressType": "IPv4", + "apiVersion": "discovery.k8s.io/v1", + "endpoints": [ + { + "addresses": [ + "10.12.1.201" + ], + "conditions": { + "ready": false, + "serving": true, + "terminating": true + }, + "nodeName": "gke-main-default-pool-dca1511c-d17b", + "targetRef": { + "kind": "Pod", + "name": "nginx-deployment-7768647bf9-b4b9s", + "namespace": "default", + "uid": "66fa831c-7eb2-407f-bd2c-f96dfe841478" + }, + "zone": "us-central1-c" + }, + { + "addresses": [ + "10.12.1.202" + ], + "conditions": { + "ready": true, + "serving": true, + "terminating": false + }, + "nodeName": "gke-main-default-pool-dca1511c-d17b", + "targetRef": { + "kind": "Pod", + "name": "nginx-deployment-7768647bf9-rkxlw", + "namespace": "default", + "uid": "722b1cbe-dcd7-4ed4-8928-4a4d0e2bbe35" + }, + "zone": "us-central1-c" +``` + +این کار به برنامه‌ها اجازه می‌دهد در هنگام خاتمه، وضعیت خود را اطلاع دهند +و کلاینت‌ها (مانند لود بالانسرها) بتوانند قابلیت «تخلیه اتصال» (connection draining) را پیاده کنند. +چنین کلاینت‌هایی می‌توانند اندپوینت‌های در حال خاتمه را شناسایی کرده و برای آن‌ها منطق ویژه‌ای اعمال کنند. + +در کوبرنتیز، اندپوینت‌هایی که در حال خاتمه هستند همیشه وضعیت `ready` آن‌ها روی `false` تنظیم می‌شود. +این کار برای حفظ سازگاری رو به عقب ضروری است تا لود بالانسرهای موجود از این اندپوینت‌ها برای ترافیک عادی استفاده نکنند. +اگر نیاز به تخلیه ترافیک روی پاد در حال خاتمه باشد، می‌توان آمادگی واقعی را با شرط `serving` بررسی کرد. + +وقتی پادی حذف می‌شود، اندپوینت قدیمی نیز حذف خواهد شد. + + +## {{% heading "whatsnext" %}} + +* بیاموزید چگونه [برنامه‌ها را با سرویس‌ها متصل کنید](/docs/tutorials/services/connect-applications-service/) +* درباره [استفاده از سرویس برای دسترسی به یک برنامه در خوشه](/docs/tasks/access-application-cluster/service-access-application-cluster/) بیشتر بخوانید +* درباره [اتصال یک فرانت‌اند به بک‌اند با استفاده از سرویس](/docs/tasks/access-application-cluster/connecting-frontend-backend/) بیشتر بخوانید +* درباره [ایجاد یک لود بالانسر خارجی](/docs/tasks/access-application-cluster/create-external-load-balancer/) بیشتر بخوانید + diff --git a/content/fa/docs/tutorials/services/source-ip.md b/content/fa/docs/tutorials/services/source-ip.md new file mode 100644 index 0000000000000..2d15c7728d4f1 --- /dev/null +++ b/content/fa/docs/tutorials/services/source-ip.md @@ -0,0 +1,410 @@ +--- +title: استفاده از IP منبع +content_type: tutorial +min-kubernetes-server-version: v1.5 +weight: 40 +--- + + + +برنامه‌هایی که در یک خوشه کوبرنتیز اجرا می‌شوند از طریق انتزاع **Service** یکدیگر و همچنین دنیای بیرون را پیدا کرده و با هم ارتباط برقرار می‌کنند. +این سند توضیح می‌دهد چه بلایی سر IP مبدأ بسته‌هایی که به انواع مختلف سرویس‌ها فرستاده می‌شوند می‌آید و چگونه می‌توانید این رفتار را بر اساس نیازهای خود تغییر دهید. + + + +## {{% heading "prerequisites" %}} + + +### واژه‌نامه + +این سند از اصطلاحات زیر استفاده می‌کند: + +{{< comment >}} +اگر این بخش را بومی‌سازی می‌کنید، به صفحات ویکی‌پدیای معادل در زبان مقصد پیوند دهید. +{{< /comment >}} + +[NAT](https://en.wikipedia.org/wiki/Network_address_translation) +: **Network Address Translation** ـ ترجمه نشانی شبکه + +[Source NAT](https://en.wikipedia.org/wiki/Network_address_translation#SNAT) +: جایگزینی IP مبدأ در یک بسته؛ در این صفحه معمولاً به معنی جایگزینی با نشانی IP یک نود است. + +[Destination NAT](https://en.wikipedia.org/wiki/Network_address_translation#DNAT) +: جایگزینی IP مقصد در یک بسته؛ در این صفحه معمولاً به معنی جایگزینی با نشانی IP یک {{< glossary_tooltip term_id="pod" >}} است. + +[VIP](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies) +: یک نشانی IP مجازی؛ برای مثال نشانی‌ای که به هر {{< glossary_tooltip text="Service" term_id="service" >}} در کوبرنتیز اختصاص داده می‌شود. + +[kube-proxy](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies) +: یک دیمن شبکه‌ای که مدیریت VIP سرویس‌ها را روی هر نود هماهنگ می‌کند. + +### پیش‌نیازها + +{{< include "task-tutorial-prereqs.md" >}} + +در مثال‌ها از یک وب‌سرور کوچک **nginx** استفاده می‌شود که IP مبدأ درخواست‌های دریافتی را در یک هدر HTTP بازتاب (echo) می‌کند. می‌توانید آن را به شکل زیر ایجاد کنید: + +{{< note >}} +ایمیج مورد استفاده در فرمان زیر فقط روی معماری‌های *AMD64* اجرا می‌شود. +{{< /note >}} + + +```shell +kubectl create deployment source-ip-app --image=registry.k8s.io/echoserver:1.10 +``` +خروجی این است: +``` +deployment.apps/source-ip-app created +``` + + +## {{% heading "objectives" %}} + + +* یک برنامه ساده را از طریق انواع مختلف سرویس‌ها در معرض دید قرار دهید +* درک کنید که هر نوع سرویس چگونه NAT نشانی IP مبدأ را مدیریت می‌کند +* معامله‌های مربوط به حفظ نشانی IP مبدأ را درک کنید + + + + + +## نشانی IP مبدأ برای سرویس‌های با `Type=ClusterIP` + +اگر kube-proxy را در +[حالت iptables](/docs/reference/networking/virtual-ips/#proxy-mode-iptables) +(حالت پیش‌فرض) اجرا کنید، بسته‌هایی که از داخل خوشه به یک ClusterIP فرستاده می‌شوند هرگز دچار NAT مبدأ نمی‌شوند. +می‌توانید حالت kube-proxy را با واکشی `http://localhost:10249/proxyMode` روی نودی که kube-proxy در آن اجرا می‌شود، بررسی کنید. + +```console +kubectl get nodes +``` +خروجی مشابه این است: +``` +NAME STATUS ROLES AGE VERSION +kubernetes-node-6jst Ready 2h v1.13.0 +kubernetes-node-cx31 Ready 2h v1.13.0 +kubernetes-node-jj1t Ready 2h v1.13.0 +``` + +حالت پروکسی را روی یکی از گره‌ها فعال کنید (kube-proxy روی پورت 10249 فعال است): +```shell +# Run this in a shell on the node you want to query. +curl http://localhost:10249/proxyMode +``` +خروجی این است: +``` +iptables +``` + +شما می‌توانید با ایجاد یک سرویس روی برنامه‌ی IP منبع، حفظ IP منبع را آزمایش کنید: + +```shell +kubectl expose deployment source-ip-app --name=clusterip --port=80 --target-port=8080 +``` +خروجی این است: +``` +service/clusterip exposed +``` +```shell +kubectl get svc clusterip +``` +خروجی مشابه این است: +``` +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +clusterip ClusterIP 10.0.170.92 80/TCP 51s +``` + +و ضربه زدن به `ClusterIP` از یک پاد در همان خوشه: + +```shell +kubectl run busybox -it --image=busybox:1.28 --restart=Never --rm +``` +خروجی مشابه این است: +``` +Waiting for pod default/busybox to be running, status is Pending, pod ready: false +If you don't see a command prompt, try pressing enter. + +``` +سپس می‌توانید دستوری را درون آن پاد اجرا کنید: + +```shell +# این دستور را در ترمینال با استفاده از دستور "kubectl run" اجرا کنید. +ip addr +``` +``` +1: lo: mtu 65536 qdisc noqueue + link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 + inet 127.0.0.1/8 scope host lo + valid_lft forever preferred_lft forever + inet6 ::1/128 scope host + valid_lft forever preferred_lft forever +3: eth0: mtu 1460 qdisc noqueue + link/ether 0a:58:0a:f4:03:08 brd ff:ff:ff:ff:ff:ff + inet 10.244.3.8/24 scope global eth0 + valid_lft forever preferred_lft forever + inet6 fe80::188a:84ff:feb0:26a5/64 scope link + valid_lft forever preferred_lft forever +``` + +... سپس از `wget` برای پرس و جو از وب سرور محلی استفاده کنید +```shell +# به جای "10.0.170.92" آدرس IPv4 سرویس با نام "clusterip" را قرار دهید. +wget -qO - 10.0.170.92 +``` +``` +CLIENT VALUES: +client_address=10.244.3.8 +command=GET +... +``` +نشانی `client_address` همیشه نشانی IP پاد کلاینت است، چه پاد کلاینت و پاد سرور روی یک نود باشند و چه روی نودهای متفاوت. + +## نشانی IP مبدأ برای سرویس‌های با `Type=NodePort` + +بسته‌هایی که به سرویس‌هایی با +[`Type=NodePort`](/docs/concepts/services-networking/service/#type-nodeport) +ارسال می‌شوند به‌صورت پیش‌فرض دچار NAT مبدأ می‌شوند. می‌توانید این موضوع را با ایجاد یک سرویس `NodePort` آزمایش کنید: + +```shell +kubectl expose deployment source-ip-app --name=nodeport --port=80 --target-port=8080 --type=NodePort +``` +خروجی این است: +``` +service/nodeport exposed +``` + +```shell +NODEPORT=$(kubectl get -o jsonpath="{.spec.ports[0].nodePort}" services nodeport) +NODES=$(kubectl get nodes -o jsonpath='{ $.items[*].status.addresses[?(@.type=="InternalIP")].address }') +``` + +اگر خوشه خود را روی یک ارائه‌دهنده ابری اجرا می‌کنید، ممکن است لازم باشد قانون فایروالی برای +`nodes:nodeport` ذکرشده در بالا باز کنید. +اکنون می‌توانید از بیرون خوشه و از طریق همان پورت نودی که در بالا تخصیص داده شد، +به سرویس دسترسی پیدا کنید. + +```shell +for node in $NODES; do curl -s $node:$NODEPORT | grep -i client_address; done +``` +خروجی مشابه زیر است: +``` +client_address=10.180.1.1 +client_address=10.240.0.5 +client_address=10.240.0.3 +``` + +توجه داشته باشید که این‌ها آدرس‌های IP صحیح کلاینت نیستند؛ این‌ها IPهای داخلی خوشه هستند. روند به این صورت است: + +* کلاینت یک بسته به `node2:nodePort` می‌فرستد +* `node2` آدرس IP مبدأ را در بسته با آدرس IP خودش جایگزین می‌کند (SNAT) +* `node2` آدرس IP مقصد در بسته را با IP پاد جایگزین می‌کند +* بسته به نود ۱ و سپس به اندپوینت هدایت می‌شود +* پاسخ پاد به `node2` برگردانده می‌شود +* پاسخ پاد به کلاینت ارسال می‌شود + +به‌صورت تصویری: + +{{< figure src="/docs/images/tutor-service-nodePort-fig01.svg" alt="source IP nodeport figure 01" class="diagram-large" caption="Figure. Source IP Type=NodePort using SNAT" link="https://mermaid.live/edit#pako:eNqNkV9rwyAUxb-K3LysYEqS_WFYKAzat9GHdW9zDxKvi9RoMIZtlH732ZjSbE970cu5v3s86hFqJxEYfHjRNeT5ZcUtIbXRaMNN2hZ5vrYRqt52cSXV-4iMSuwkZiYtyX739EqWaahMQ-V1qPxDVLNOvkYrO6fj2dupWMR2iiT6foOKdEZoS5Q2hmVSStoH7w7IMqXUVOefWoaG3XVftHbGeZYVRbH6ZXJ47CeL2-qhxvt_ucTe1SUlpuMN6CX12XeGpLdJiaMMFFr0rdAyvvfxjHEIDbbIgcVSohKDCRy4PUV06KQIuJU6OA9MCdMjBTEEt_-2NbDgB7xAGy3i97VJPP0ABRmcqg" >}} + + +برای جلوگیری از این مشکل، کوبرنتیز قابلیتی برای +[حفظ IP مبدأ کلاینت](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip) +دارد. اگر مقدار `service.spec.externalTrafficPolicy` را روی `Local` قرار دهید، +`kube-proxy` فقط درخواست‌ها را به اندپوینت‌های محلی (روی همان نود) پروکسی می‌کند +و ترافیک را به نودهای دیگر فوروارد نمی‌کند. این روش، نشانی IP مبدأ اصلی را حفظ +می‌کند. اگر هیچ اندپوینت محلی وجود نداشته باشد، بسته‌هایی که به نود فرستاده +می‌شوند حذف می‌شوند؛ بنابراین می‌توانید در هر قانونِ پردازش بسته به درستی به IP +مبدأ اصلی اعتماد کنید، چون تنها بسته‌هایی به اندپوینت می‌رسند که این شرط را دارند. + +فیلد `service.spec.externalTrafficPolicy` را به‌این‌شکل تنظیم کنید: + +```shell +kubectl patch svc nodeport -p '{"spec":{"externalTrafficPolicy":"Local"}}' +``` +خروجی این است: +``` +service/nodeport patched +``` + +حالا، تست را دوباره اجرا کنید: + +```shell +for node in $NODES; do curl --connect-timeout 1 -s $node:$NODEPORT | grep -i client_address; done +``` +خروجی مشابه زیر است: +``` +client_address=198.51.100.79 +``` + +توجه کنید که تنها یک پاسخ دریافت کردید ــ آن هم با IP **صحیح** کلاینت ــ از همان نودی که پادِ اندپوینت روی آن اجرا می‌شود. + +این‌گونه رخ می‌دهد: + +* کلاینت بسته‌ای به `node2:nodePort` می‌فرستد؛ این نود هیچ اندپوینتی ندارد. +* بسته حذف می‌شود. +* کلاینت بسته‌ای به `node1:nodePort` می‌فرستد؛ این نود *دارای* اندپوینت است. +* `node1` بسته را با IP مبدأ صحیح به اندپوینت هدایت می‌کند. + +به‌صورت تصویری: + +{{< figure src="/docs/images/tutor-service-nodePort-fig02.svg" alt="source IP nodeport figure 02" class="diagram-large" caption="Figure. Source IP Type=NodePort preserves client source IP address" link="" >}} + +## نشانی IP مبدأ برای سرویس‌های با `Type=LoadBalancer` + +بسته‌هایی که به سرویس‌های +[`Type=LoadBalancer`](/docs/concepts/services-networking/service/#loadbalancer) +ارسال می‌شوند، به‌طور پیش‌فرض دچار **NAT مبدأ** می‌شوند؛ زیرا تمام نودهای قابل زمان‌بندیِ کوبرنتیز در وضعیت `Ready` شایسته دریافت ترافیک لودبالانسر هستند. بنابراین اگر بسته‌ای به نودی بدون اندپوینت برسد، سیستم آن را به نودی *دارای* اندپوینت پروکسی می‌کند و IP مبدأ بسته را با IP همان نود جایگزین می‌نماید (مطابق آنچه در بخش پیش توضیح داده شد). + +می‌توانید این موضوع را با در معرض قرار دادن **source-ip-app** از طریق یک لود بالانسر آزمایش کنید: + +```shell +kubectl expose deployment source-ip-app --name=loadbalancer --port=80 --target-port=8080 --type=LoadBalancer +``` +خروجی این است: +``` +service/loadbalancer exposed +``` + +آدرس‌های IP سرویس را چاپ کنید: +```console +kubectl get svc loadbalancer +``` +خروجی مشابه این است: +``` +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +loadbalancer LoadBalancer 10.0.65.118 203.0.113.140 80/TCP 5m +``` + +در مرحله بعد، یک درخواست به آدرس IP خارجی این سرویس ارسال کنید: + +```shell +curl 203.0.113.140 +``` +خروجی مشابه این است: +``` +CLIENT VALUES: +client_address=10.240.0.5 +... +``` + +با این حال، اگر خوشه را روی **Google Kubernetes Engine/GCE** اجرا می‌کنید، تنظیم همان فیلد +`service.spec.externalTrafficPolicy` بر روی مقدار `Local` +باعث می‌شود نودهایی که *اندپوینت سرویس ندارند* عمداً آزمایش‌های سلامت را ناموفق پشت سر بگذارند +و خود را از فهرست نودهای واجد شرایط برای دریافت ترافیک لودبالانسر حذف کنند. + +به‌صورت تصویری: + +![IP مبدأ با externalTrafficPolicy](/images/docs/sourceip-externaltrafficpolicy.svg) + +می‌توانید این موضوع را با افزودن انوتیشن زیر آزمایش کنید: + +```shell +kubectl patch svc loadbalancer -p '{"spec":{"externalTrafficPolicy":"Local"}}' +``` + +شما باید فوراً فیلد `service.spec.healthCheckNodePort` که توسط کوبرنتیز اختصاص داده شده است را مشاهده کنید: + +```shell +kubectl get svc loadbalancer -o yaml | grep -i healthCheckNodePort +``` +خروجی مشابه این است: +```yaml + healthCheckNodePort: 32122 +``` + +فیلد `service.spec.healthCheckNodePort` به یک پورت در هر گره‌ای که بررسی سلامت را در `/healthz` انجام می‌دهد، اشاره می‌کند. می‌توانید این را آزمایش کنید: + +```shell +kubectl get pod -o wide -l app=source-ip-app +``` +خروجی مشابه این است: +``` +NAME READY STATUS RESTARTS AGE IP NODE +source-ip-app-826191075-qehz4 1/1 Running 0 20h 10.180.1.136 kubernetes-node-6jst +``` + +از `curl` برای دریافت نقطه پایانی `/healthz` در گره‌های مختلف استفاده کنید: +```shell +# این را به صورت محلی روی گره‌ای که انتخاب می‌کنید اجرا کنید +curl localhost:32122/healthz +``` +``` +1 Service Endpoints found +``` + +در یک گره متفاوت، ممکن است نتیجه متفاوتی بگیرید: +```shell +# این را به صورت محلی روی گره‌ای که انتخاب می‌کنید اجرا کنید +curl localhost:32122/healthz +``` +``` +No Service Endpoints Found +``` + +یک کنترلری که روی +{{< glossary_tooltip text="control plane" term_id="control-plane" >}} +اجرا می‌شود مسئول تخصیص لود بالانسر ابری است. همان کنترلر همچنین بررسی‌های +سلامت HTTP را که به این پورت/مسیر روی هر نود اشاره می‌کنند، ایجاد می‌کند. +حدود ۱۰ ثانیه صبر کنید تا دو نودی که اندپوینت ندارند در آزمون‌های سلامت +مردود شوند، سپس با استفاده از `curl` نشانی IPv4 لود بالانسر را پرس‌وجو کنید: + +```shell +curl 203.0.113.140 +``` +خروجی مشابه این است: +``` +CLIENT VALUES: +client_address=198.51.100.79 +... +``` + +## پشتیبانی در پلتفرم‌های گوناگون + +فقط برخی ارائه‌دهندگان ابری از حفظ IP مبدأ در سرویس‌هایی با +`Type=LoadBalancer` پشتیبانی می‌کنند. +ارائه‌دهنده ابری‌ای که روی آن کار می‌کنید ممکن است درخواست ایجاد یک +لود بالانسر را به یکی از روش‌های زیر برآورده کند: + +1. با یک پراکسی که اتصال کلاینت را خاتمه می‌دهد و یک اتصال جدید به + نودها / اندپوینت‌های شما باز می‌کند. در چنین حالتی، IP مبدأ همیشه + آدرس لود بالانسر ابری خواهد بود، نه آدرس کلاینت. + +2. با یک *packet forwarder*، به‌طوری‌که درخواست‌های کلاینت که به VIP + لود بالانسر فرستاده می‌شوند، با IP مبدأ کلاینت (و نه یک پراکسی + واسط) به نود برسند. + +لود بالانسرهای دسته اول باید از یک پروتکل توافق‌شده میان لود بالانسر و +بک‌اند برای انتقال IP واقعی کلاینت استفاده کنند؛ مانند هدرهای HTTP +[Forwarded](https://tools.ietf.org/html/rfc7239#section-5.2) یا +[X-FORWARDED-FOR](https://en.wikipedia.org/wiki/X-Forwarded-For)، +یا [proxy protocol](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt). +لود بالانسرهای دسته دوم می‌توانند از قابلیت توضیح‌داده‌شده در بخش پیش +بهره بگیرند؛ بدین صورت که یک *health check*‌ HTTP ایجاد می‌کنند که به +پورتی اشاره دارد که در فیلد +`service.spec.healthCheckNodePort` +سرویس ذخیره شده است. + + + +## {{% heading "cleanup" %}} + + +سرویس‌ها را حذف کنید: + +```shell +kubectl delete svc -l app=source-ip-app +``` + +Deployment، ReplicaSet و Pod را حذف کنید: + +```shell +kubectl delete deployment source-ip-app +``` + + + +## {{% heading "whatsnext" %}} + +* درباره [اتصال برنامه‌ها از طریق سرویس‌ها](/docs/tutorials/services/connect-applications-service/) بیشتر بیاموزید +* بخوانید چگونه [یک لود بالانسر خارجی بسازید](/docs/tasks/access-application-cluster/create-external-load-balancer/) diff --git a/content/fa/docs/update-user-guide-links.py b/content/fa/docs/update-user-guide-links.py new file mode 100644 index 0000000000000..7c449d73efb08 --- /dev/null +++ b/content/fa/docs/update-user-guide-links.py @@ -0,0 +1,85 @@ +import subprocess +import re + +# Finds the documents to rewrite for files that include user-guide-content-moved.md. +# Then opens these files and processes the stuff after those lines to figure out where +# the line should move to. +# Returns a list of ('old/path', 'new/path') tuples. +def find_documents_to_rewrite(): + cmd = "ag --markdown -Q -l \"{% include user-guide-content-moved.md %}\"" + moved_docs = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE).stdout.read().splitlines() + + rewrites = [] + for doc in moved_docs: + location = doc_location(doc) + destinations = get_destinations_for_doc(doc) + + if len(destinations) == 0: + print("Unable to get possible destinations for %s" % doc) + elif len(destinations) > 1: + print("%s has multiple potential destinations. Not rewriting links." % doc) + else: + # print("%s --> %s" % (location, destinations[0])) + rewrites.append((location, destinations[0])) + + return rewrites + +# Returns the location of the documentation as we will refer to it in the markdown. +# /docs/path/to/foo/index.md are available at /docs/path/to/foo/ +# /docs/path/to/foo/bar.md are available at /docs/path/to/foo/bar/ +def doc_location(filename): + if filename.endswith('/index.md'): + return "/docs/" + filename[:-9] + "/" + else: + return "/docs/" + filename[:-3] + "/" + +REDIRECT_REGEX = re.compile("^.*\[(.*)\]\((.*)\)$") + +def get_destinations_for_doc(filename): + destination_paths = [] + with open(filename) as f: + lines = [line.rstrip('\n').rstrip('\r') for line in f.readlines()] + + # Remove empty lines + lines = filter(bool, lines) + + content_moved_index = lines.index("{% include user-guide-content-moved.md %}") + + # Get everything after that line. + destinations = lines[content_moved_index + 1:] + for destination in destinations: + result = REDIRECT_REGEX.match(destination) + if not result: + return [] + doc_title = result.group(1) # Unused, can print it out for more info. + new_path = result.group(2) + destination_paths.append(new_path) + + return destination_paths + +# Given a list of (old/path, new/path) tuples executes a sed command across all files in +# to replace (/docs/path/to/old/doc/) with (/docs/path/to/new/doc/). +def rewrite_documents(rewrites): + cmd = "find . -name '*.md' -type f -exec sed -i.bak 's@(%s)@(%s)@g' '{}' \;" + for original, new in rewrites: + + print("%s --> %s" % (original, new)) + original = original.replace('-', '\-') + new = new.replace('-', '\-') + + #print(cmd % (original, new)) + subprocess.call(cmd % (original, new), shell=True) + +# We can't have in-line replace across multiple files without sudo (I think), so it +# creates a lot of backups that we have to delete. +def remove_sed_backups(): + cmd = "find . -name '*.bak' -delete" + subprocess.call(cmd, shell=True) + +def main(): + rewrites = find_documents_to_rewrite() + rewrite_documents(rewrites) + remove_sed_backups() + +if __name__ == "__main__": + main() diff --git a/content/fa/examples/README.md b/content/fa/examples/README.md new file mode 100644 index 0000000000000..fd542ff5df398 --- /dev/null +++ b/content/fa/examples/README.md @@ -0,0 +1,11 @@ +برای اجرای تست‌های محلی‌سازی، از دستور زیر استفاده کنید: + +``` +go test k8s.io/website/content//examples +``` + +where `` is the two character representation of a language. For example: + +``` +go test k8s.io/website/content/en/examples +``` diff --git a/content/fa/examples/access/certificate-signing-request/clusterrole-approve.yaml b/content/fa/examples/access/certificate-signing-request/clusterrole-approve.yaml new file mode 100644 index 0000000000000..e5bcfdc44e2d8 --- /dev/null +++ b/content/fa/examples/access/certificate-signing-request/clusterrole-approve.yaml @@ -0,0 +1,28 @@ +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: csr-approver +rules: +- apiGroups: + - certificates.k8s.io + resources: + - certificatesigningrequests + verbs: + - get + - list + - watch +- apiGroups: + - certificates.k8s.io + resources: + - certificatesigningrequests/approval + verbs: + - update +- apiGroups: + - certificates.k8s.io + resources: + - signers + resourceNames: + - example.com/my-signer-name # example.com/* can be used to authorize for all signers in the 'example.com' domain + verbs: + - approve + diff --git a/content/fa/examples/access/certificate-signing-request/clusterrole-create.yaml b/content/fa/examples/access/certificate-signing-request/clusterrole-create.yaml new file mode 100644 index 0000000000000..def1b879d8e88 --- /dev/null +++ b/content/fa/examples/access/certificate-signing-request/clusterrole-create.yaml @@ -0,0 +1,14 @@ +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: csr-creator +rules: +- apiGroups: + - certificates.k8s.io + resources: + - certificatesigningrequests + verbs: + - create + - get + - list + - watch diff --git a/content/fa/examples/access/certificate-signing-request/clusterrole-sign.yaml b/content/fa/examples/access/certificate-signing-request/clusterrole-sign.yaml new file mode 100644 index 0000000000000..6d1a2f7882cd1 --- /dev/null +++ b/content/fa/examples/access/certificate-signing-request/clusterrole-sign.yaml @@ -0,0 +1,27 @@ +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: csr-signer +rules: +- apiGroups: + - certificates.k8s.io + resources: + - certificatesigningrequests + verbs: + - get + - list + - watch +- apiGroups: + - certificates.k8s.io + resources: + - certificatesigningrequests/status + verbs: + - update +- apiGroups: + - certificates.k8s.io + resources: + - signers + resourceNames: + - example.com/my-signer-name # example.com/* can be used to authorize for all signers in the 'example.com' domain + verbs: + - sign diff --git a/content/fa/examples/access/deployment-replicas-policy.yaml b/content/fa/examples/access/deployment-replicas-policy.yaml new file mode 100644 index 0000000000000..d7d11e9a20ced --- /dev/null +++ b/content/fa/examples/access/deployment-replicas-policy.yaml @@ -0,0 +1,19 @@ +apiVersion: admissionregistration.k8s.io/v1 +kind: ValidatingAdmissionPolicy +metadata: + name: "deploy-replica-policy.example.com" +spec: + paramKind: + apiVersion: rules.example.com/v1 + kind: ReplicaLimit + matchConstraints: + resourceRules: + - apiGroups: ["apps"] + apiVersions: ["v1"] + operations: ["CREATE", "UPDATE"] + resources: ["deployments"] + validations: + - expression: "object.spec.replicas <= params.maxReplicas" + messageExpression: "'object.spec.replicas must be no greater than ' + string(params.maxReplicas)" + reason: Invalid + diff --git a/content/fa/examples/access/endpoints-aggregated.yaml b/content/fa/examples/access/endpoints-aggregated.yaml new file mode 100644 index 0000000000000..d238820056afb --- /dev/null +++ b/content/fa/examples/access/endpoints-aggregated.yaml @@ -0,0 +1,20 @@ +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + annotations: + kubernetes.io/description: |- + Add endpoints write permissions to the edit and admin roles. This was + removed by default in 1.22 because of CVE-2021-25740. See + https://issue.k8s.io/103675. This can allow writers to direct LoadBalancer + or Ingress implementations to expose backend IPs that would not otherwise + be accessible, and can circumvent network policies or security controls + intended to prevent/isolate access to those backends. + EndpointSlices were never included in the edit or admin roles, so there + is nothing to restore for the EndpointSlice API. + labels: + rbac.authorization.k8s.io/aggregate-to-edit: "true" + name: custom:aggregate-to-edit:endpoints # you can change this if you wish +rules: + - apiGroups: [""] + resources: ["endpoints"] + verbs: ["create", "delete", "deletecollection", "patch", "update"] diff --git a/content/fa/examples/access/image-matches-namespace-environment.policy.yaml b/content/fa/examples/access/image-matches-namespace-environment.policy.yaml new file mode 100644 index 0000000000000..cf7508d253091 --- /dev/null +++ b/content/fa/examples/access/image-matches-namespace-environment.policy.yaml @@ -0,0 +1,28 @@ +# This policy enforces that all containers of a deployment has the image repo match the environment label of its namespace. +# Except for "exempt" deployments, or any containers that do not belong to the "example.com" organization (e.g. common sidecars). +# For example, if the namespace has a label of {"environment": "staging"}, all container images must be either staging.example.com/* +# or do not contain "example.com" at all, unless the deployment has {"exempt": "true"} label. +apiVersion: admissionregistration.k8s.io/v1 +kind: ValidatingAdmissionPolicy +metadata: + name: "image-matches-namespace-environment.policy.example.com" +spec: + failurePolicy: Fail + matchConstraints: + resourceRules: + - apiGroups: ["apps"] + apiVersions: ["v1"] + operations: ["CREATE", "UPDATE"] + resources: ["deployments"] + variables: + - name: environment + expression: "'environment' in namespaceObject.metadata.labels ? namespaceObject.metadata.labels['environment'] : 'prod'" + - name: exempt + expression: "'exempt' in object.metadata.labels && object.metadata.labels['exempt'] == 'true'" + - name: containers + expression: "object.spec.template.spec.containers" + - name: containersToCheck + expression: "variables.containers.filter(c, c.image.contains('example.com/'))" + validations: + - expression: "variables.exempt || variables.containersToCheck.all(c, c.image.startsWith(variables.environment + '.'))" + messageExpression: "'only ' + variables.environment + ' images are allowed in namespace ' + namespaceObject.metadata.name" \ No newline at end of file diff --git a/content/fa/examples/access/simple-clusterrole.yaml b/content/fa/examples/access/simple-clusterrole.yaml new file mode 100644 index 0000000000000..4b4f2afcce3db --- /dev/null +++ b/content/fa/examples/access/simple-clusterrole.yaml @@ -0,0 +1,12 @@ +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + # "namespace" omitted since ClusterRoles are not namespaced + name: secret-reader +rules: +- apiGroups: [""] + # + # at the HTTP level, the name of the resource for accessing Secret + # objects is "secrets" + resources: ["secrets"] + verbs: ["get", "watch", "list"] diff --git a/content/fa/examples/access/simple-clusterrolebinding.yaml b/content/fa/examples/access/simple-clusterrolebinding.yaml new file mode 100644 index 0000000000000..3887326c415a9 --- /dev/null +++ b/content/fa/examples/access/simple-clusterrolebinding.yaml @@ -0,0 +1,13 @@ +apiVersion: rbac.authorization.k8s.io/v1 +# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace. +kind: ClusterRoleBinding +metadata: + name: read-secrets-global +subjects: +- kind: Group + name: manager # Name is case sensitive + apiGroup: rbac.authorization.k8s.io +roleRef: + kind: ClusterRole + name: secret-reader + apiGroup: rbac.authorization.k8s.io diff --git a/content/fa/examples/access/simple-role.yaml b/content/fa/examples/access/simple-role.yaml new file mode 100644 index 0000000000000..2f7e6c47de766 --- /dev/null +++ b/content/fa/examples/access/simple-role.yaml @@ -0,0 +1,9 @@ +apiVersion: rbac.authorization.k8s.io/v1 +kind: Role +metadata: + namespace: default + name: pod-reader +rules: +- apiGroups: [""] # "" indicates the core API group + resources: ["pods"] + verbs: ["get", "watch", "list"] diff --git a/content/fa/examples/access/simple-rolebinding-with-clusterrole.yaml b/content/fa/examples/access/simple-rolebinding-with-clusterrole.yaml new file mode 100644 index 0000000000000..c9e310cbbd1ac --- /dev/null +++ b/content/fa/examples/access/simple-rolebinding-with-clusterrole.yaml @@ -0,0 +1,18 @@ +apiVersion: rbac.authorization.k8s.io/v1 +# This role binding allows "dave" to read secrets in the "development" namespace. +# You need to already have a ClusterRole named "secret-reader". +kind: RoleBinding +metadata: + name: read-secrets + # + # The namespace of the RoleBinding determines where the permissions are granted. + # This only grants permissions within the "development" namespace. + namespace: development +subjects: +- kind: User + name: dave # Name is case sensitive + apiGroup: rbac.authorization.k8s.io +roleRef: + kind: ClusterRole + name: secret-reader + apiGroup: rbac.authorization.k8s.io diff --git a/content/fa/examples/access/simple-rolebinding-with-role.yaml b/content/fa/examples/access/simple-rolebinding-with-role.yaml new file mode 100644 index 0000000000000..6ddfce7bba498 --- /dev/null +++ b/content/fa/examples/access/simple-rolebinding-with-role.yaml @@ -0,0 +1,17 @@ +apiVersion: rbac.authorization.k8s.io/v1 +# This role binding allows "jane" to read pods in the "default" namespace. +# You need to already have a Role named "pod-reader" in that namespace. +kind: RoleBinding +metadata: + name: read-pods + namespace: default +subjects: +# You can specify more than one "subject" +- kind: User + name: jane # "name" is case sensitive + apiGroup: rbac.authorization.k8s.io +roleRef: + # "roleRef" specifies the binding to a Role / ClusterRole + kind: Role #this must be Role or ClusterRole + name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to + apiGroup: rbac.authorization.k8s.io diff --git a/content/fa/examples/access/validating-admission-policy-audit-annotation.yaml b/content/fa/examples/access/validating-admission-policy-audit-annotation.yaml new file mode 100644 index 0000000000000..1c422a825447f --- /dev/null +++ b/content/fa/examples/access/validating-admission-policy-audit-annotation.yaml @@ -0,0 +1,18 @@ +apiVersion: admissionregistration.k8s.io/v1 +kind: ValidatingAdmissionPolicy +metadata: + name: "demo-policy.example.com" +spec: + failurePolicy: Fail + matchConstraints: + resourceRules: + - apiGroups: ["apps"] + apiVersions: ["v1"] + operations: ["CREATE", "UPDATE"] + resources: ["deployments"] + validations: + - expression: "object.spec.replicas > 50" + messageExpression: "'Deployment spec.replicas set to ' + string(object.spec.replicas)" + auditAnnotations: + - key: "high-replica-count" + valueExpression: "'Deployment spec.replicas set to ' + string(object.spec.replicas)" diff --git a/content/fa/examples/access/validating-admission-policy-match-conditions.yaml b/content/fa/examples/access/validating-admission-policy-match-conditions.yaml new file mode 100644 index 0000000000000..eafebd2c2c274 --- /dev/null +++ b/content/fa/examples/access/validating-admission-policy-match-conditions.yaml @@ -0,0 +1,22 @@ +apiVersion: admissionregistration.k8s.io/v1 +kind: ValidatingAdmissionPolicy +metadata: + name: "demo-policy.example.com" +spec: + failurePolicy: Fail + matchConstraints: + resourceRules: + - apiGroups: ["*"] + apiVersions: ["*"] + operations: ["CREATE", "UPDATE"] + resources: ["*"] + matchConditions: + - name: 'exclude-leases' # Each match condition must have a unique name + expression: '!(request.resource.group == "coordination.k8s.io" && request.resource.resource == "leases")' # Match non-lease resources. + - name: 'exclude-kubelet-requests' + expression: '!("system:nodes" in request.userInfo.groups)' # Match requests made by non-node users. + - name: 'rbac' # Skip RBAC requests. + expression: 'request.resource.group != "rbac.authorization.k8s.io"' + validations: + - expression: "!object.metadata.name.contains('demo') || object.metadata.namespace == 'demo'" + diff --git a/content/fa/examples/admin/cloud/ccm-example.yaml b/content/fa/examples/admin/cloud/ccm-example.yaml new file mode 100644 index 0000000000000..91b7ef2b8944f --- /dev/null +++ b/content/fa/examples/admin/cloud/ccm-example.yaml @@ -0,0 +1,73 @@ +# This is an example of how to set up cloud-controller-manager as a Daemonset in your cluster. +# It assumes that your masters can run pods and has the role node-role.kubernetes.io/master +# Note that this Daemonset will not work straight out of the box for your cloud, this is +# meant to be a guideline. + +--- +apiVersion: v1 +kind: ServiceAccount +metadata: + name: cloud-controller-manager + namespace: kube-system +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRoleBinding +metadata: + name: system:cloud-controller-manager +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: cluster-admin +subjects: +- kind: ServiceAccount + name: cloud-controller-manager + namespace: kube-system +--- +apiVersion: apps/v1 +kind: DaemonSet +metadata: + labels: + k8s-app: cloud-controller-manager + name: cloud-controller-manager + namespace: kube-system +spec: + selector: + matchLabels: + k8s-app: cloud-controller-manager + template: + metadata: + labels: + k8s-app: cloud-controller-manager + spec: + serviceAccountName: cloud-controller-manager + containers: + - name: cloud-controller-manager + # for in-tree providers we use registry.k8s.io/cloud-controller-manager + # this can be replaced with any other image for out-of-tree providers + image: registry.k8s.io/cloud-controller-manager:v1.8.0 + command: + - /usr/local/bin/cloud-controller-manager + - --cloud-provider=[YOUR_CLOUD_PROVIDER] # Add your own cloud provider here! + - --leader-elect=true + - --use-service-account-credentials + # these flags will vary for every cloud provider + - --allocate-node-cidrs=true + - --configure-cloud-routes=true + - --cluster-cidr=172.17.0.0/16 + tolerations: + # this is required so CCM can bootstrap itself + - key: node.cloudprovider.kubernetes.io/uninitialized + value: "true" + effect: NoSchedule + # these tolerations are to have the daemonset runnable on control plane nodes + # remove them if your control plane nodes should not run pods + - key: node-role.kubernetes.io/control-plane + operator: Exists + effect: NoSchedule + - key: node-role.kubernetes.io/master + operator: Exists + effect: NoSchedule + # this is to restrict CCM to only run on master nodes + # the node selector may vary depending on your cluster setup + nodeSelector: + node-role.kubernetes.io/master: "" diff --git a/content/fa/examples/admin/dns/busybox.yaml b/content/fa/examples/admin/dns/busybox.yaml new file mode 100644 index 0000000000000..31f009d307291 --- /dev/null +++ b/content/fa/examples/admin/dns/busybox.yaml @@ -0,0 +1,14 @@ +apiVersion: v1 +kind: Pod +metadata: + name: busybox + namespace: default +spec: + containers: + - name: busybox + image: busybox:1.28 + command: + - sleep + - "3600" + imagePullPolicy: IfNotPresent + restartPolicy: Always diff --git a/content/fa/examples/admin/dns/dns-horizontal-autoscaler.yaml b/content/fa/examples/admin/dns/dns-horizontal-autoscaler.yaml new file mode 100644 index 0000000000000..3182fed3c8052 --- /dev/null +++ b/content/fa/examples/admin/dns/dns-horizontal-autoscaler.yaml @@ -0,0 +1,87 @@ +kind: ServiceAccount +apiVersion: v1 +metadata: + name: kube-dns-autoscaler + namespace: kube-system +--- +kind: ClusterRole +apiVersion: rbac.authorization.k8s.io/v1 +metadata: + name: system:kube-dns-autoscaler +rules: + - apiGroups: [""] + resources: ["nodes"] + verbs: ["list", "watch"] + - apiGroups: [""] + resources: ["replicationcontrollers/scale"] + verbs: ["get", "update"] + - apiGroups: ["apps"] + resources: ["deployments/scale", "replicasets/scale"] + verbs: ["get", "update"] +# Remove the configmaps rule once below issue is fixed: +# kubernetes-incubator/cluster-proportional-autoscaler#16 + - apiGroups: [""] + resources: ["configmaps"] + verbs: ["get", "create"] +--- +kind: ClusterRoleBinding +apiVersion: rbac.authorization.k8s.io/v1 +metadata: + name: system:kube-dns-autoscaler +subjects: + - kind: ServiceAccount + name: kube-dns-autoscaler + namespace: kube-system +roleRef: + kind: ClusterRole + name: system:kube-dns-autoscaler + apiGroup: rbac.authorization.k8s.io + +--- +apiVersion: apps/v1 +kind: Deployment +metadata: + name: kube-dns-autoscaler + namespace: kube-system + labels: + k8s-app: kube-dns-autoscaler + kubernetes.io/cluster-service: "true" +spec: + selector: + matchLabels: + k8s-app: kube-dns-autoscaler + template: + metadata: + labels: + k8s-app: kube-dns-autoscaler + spec: + priorityClassName: system-cluster-critical + securityContext: + seccompProfile: + type: RuntimeDefault + supplementalGroups: [ 65534 ] + fsGroup: 65534 + nodeSelector: + kubernetes.io/os: linux + containers: + - name: autoscaler + image: registry.k8s.io/cpa/cluster-proportional-autoscaler:1.8.4 + resources: + requests: + cpu: "20m" + memory: "10Mi" + command: + - /cluster-proportional-autoscaler + - --namespace=kube-system + - --configmap=kube-dns-autoscaler + # Should keep target in sync with cluster/addons/dns/kube-dns.yaml.base + - --target= + # When cluster is using large nodes(with more cores), "coresPerReplica" should dominate. + # If using small nodes, "nodesPerReplica" should dominate. + - --default-params={"linear":{"coresPerReplica":256,"nodesPerReplica":16,"preventSinglePointFailure":true,"includeUnschedulableNodes":true}} + - --logtostderr=true + - --v=2 + tolerations: + - key: "CriticalAddonsOnly" + operator: "Exists" + serviceAccountName: kube-dns-autoscaler diff --git a/content/fa/examples/admin/dns/dnsutils.yaml b/content/fa/examples/admin/dns/dnsutils.yaml new file mode 100644 index 0000000000000..3633ecfbdd9ee --- /dev/null +++ b/content/fa/examples/admin/dns/dnsutils.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: Pod +metadata: + name: dnsutils + namespace: default +spec: + containers: + - name: dnsutils + image: registry.k8s.io/e2e-test-images/agnhost:2.39 + imagePullPolicy: IfNotPresent + restartPolicy: Always diff --git a/content/fa/examples/admin/konnectivity/egress-selector-configuration.yaml b/content/fa/examples/admin/konnectivity/egress-selector-configuration.yaml new file mode 100644 index 0000000000000..631e6cc26862e --- /dev/null +++ b/content/fa/examples/admin/konnectivity/egress-selector-configuration.yaml @@ -0,0 +1,21 @@ +apiVersion: apiserver.k8s.io/v1beta1 +kind: EgressSelectorConfiguration +egressSelections: +# Since we want to control the egress traffic to the cluster, we use the +# "cluster" as the name. Other supported values are "etcd", and "controlplane". +- name: cluster + connection: + # This controls the protocol between the API Server and the Konnectivity + # server. Supported values are "GRPC" and "HTTPConnect". There is no + # end user visible difference between the two modes. You need to set the + # Konnectivity server to work in the same mode. + proxyProtocol: GRPC + transport: + # This controls what transport the API Server uses to communicate with the + # Konnectivity server. UDS is recommended if the Konnectivity server + # locates on the same machine as the API Server. You need to configure the + # Konnectivity server to listen on the same UDS socket. + # The other supported transport is "tcp". You will need to set up TLS + # config to secure the TCP transport. + uds: + udsName: /etc/kubernetes/konnectivity-server/konnectivity-server.socket diff --git a/content/fa/examples/admin/konnectivity/konnectivity-agent.yaml b/content/fa/examples/admin/konnectivity/konnectivity-agent.yaml new file mode 100644 index 0000000000000..cbcbf89114a94 --- /dev/null +++ b/content/fa/examples/admin/konnectivity/konnectivity-agent.yaml @@ -0,0 +1,55 @@ +apiVersion: apps/v1 +# Alternatively, you can deploy the agents as Deployments. It is not necessary +# to have an agent on each node. +kind: DaemonSet +metadata: + labels: + addonmanager.kubernetes.io/mode: Reconcile + k8s-app: konnectivity-agent + namespace: kube-system + name: konnectivity-agent +spec: + selector: + matchLabels: + k8s-app: konnectivity-agent + template: + metadata: + labels: + k8s-app: konnectivity-agent + spec: + priorityClassName: system-cluster-critical + tolerations: + - key: "CriticalAddonsOnly" + operator: "Exists" + containers: + - image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-agent:v0.0.37 + name: konnectivity-agent + command: ["/proxy-agent"] + args: [ + "--logtostderr=true", + "--ca-cert=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt", + # Since the konnectivity server runs with hostNetwork=true, + # this is the IP address of the master machine. + "--proxy-server-host=35.225.206.7", + "--proxy-server-port=8132", + "--admin-server-port=8133", + "--health-server-port=8134", + "--service-account-token-path=/var/run/secrets/tokens/konnectivity-agent-token" + ] + volumeMounts: + - mountPath: /var/run/secrets/tokens + name: konnectivity-agent-token + livenessProbe: + httpGet: + port: 8134 + path: /healthz + initialDelaySeconds: 15 + timeoutSeconds: 15 + serviceAccountName: konnectivity-agent + volumes: + - name: konnectivity-agent-token + projected: + sources: + - serviceAccountToken: + path: konnectivity-agent-token + audience: system:konnectivity-server diff --git a/content/fa/examples/admin/konnectivity/konnectivity-rbac.yaml b/content/fa/examples/admin/konnectivity/konnectivity-rbac.yaml new file mode 100644 index 0000000000000..7687f49b77e82 --- /dev/null +++ b/content/fa/examples/admin/konnectivity/konnectivity-rbac.yaml @@ -0,0 +1,24 @@ +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRoleBinding +metadata: + name: system:konnectivity-server + labels: + kubernetes.io/cluster-service: "true" + addonmanager.kubernetes.io/mode: Reconcile +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: system:auth-delegator +subjects: + - apiGroup: rbac.authorization.k8s.io + kind: User + name: system:konnectivity-server +--- +apiVersion: v1 +kind: ServiceAccount +metadata: + name: konnectivity-agent + namespace: kube-system + labels: + kubernetes.io/cluster-service: "true" + addonmanager.kubernetes.io/mode: Reconcile diff --git a/content/fa/examples/admin/konnectivity/konnectivity-server.yaml b/content/fa/examples/admin/konnectivity/konnectivity-server.yaml new file mode 100644 index 0000000000000..4dfbf5db9d11a --- /dev/null +++ b/content/fa/examples/admin/konnectivity/konnectivity-server.yaml @@ -0,0 +1,73 @@ +apiVersion: v1 +kind: Pod +metadata: + name: konnectivity-server + namespace: kube-system +spec: + priorityClassName: system-cluster-critical + hostNetwork: true + containers: + - name: konnectivity-server-container + image: registry.k8s.io/kas-network-proxy/proxy-server:v0.0.37 + command: ["/proxy-server"] + args: [ + "--logtostderr=true", + # This needs to be consistent with the value set in egressSelectorConfiguration. + "--uds-name=/etc/kubernetes/konnectivity-server/konnectivity-server.socket", + "--delete-existing-uds-file", + # The following two lines assume the Konnectivity server is + # deployed on the same machine as the apiserver, and the certs and + # key of the API Server are at the specified location. + "--cluster-cert=/etc/kubernetes/pki/apiserver.crt", + "--cluster-key=/etc/kubernetes/pki/apiserver.key", + # This needs to be consistent with the value set in egressSelectorConfiguration. + "--mode=grpc", + "--server-port=0", + "--agent-port=8132", + "--admin-port=8133", + "--health-port=8134", + "--agent-namespace=kube-system", + "--agent-service-account=konnectivity-agent", + "--kubeconfig=/etc/kubernetes/konnectivity-server.conf", + "--authentication-audience=system:konnectivity-server" + ] + livenessProbe: + httpGet: + scheme: HTTP + host: 127.0.0.1 + port: 8134 + path: /healthz + initialDelaySeconds: 30 + timeoutSeconds: 60 + ports: + - name: agentport + containerPort: 8132 + hostPort: 8132 + - name: adminport + containerPort: 8133 + hostPort: 8133 + - name: healthport + containerPort: 8134 + hostPort: 8134 + volumeMounts: + - name: k8s-certs + mountPath: /etc/kubernetes/pki + readOnly: true + - name: kubeconfig + mountPath: /etc/kubernetes/konnectivity-server.conf + readOnly: true + - name: konnectivity-uds + mountPath: /etc/kubernetes/konnectivity-server + readOnly: false + volumes: + - name: k8s-certs + hostPath: + path: /etc/kubernetes/pki + - name: kubeconfig + hostPath: + path: /etc/kubernetes/konnectivity-server.conf + type: FileOrCreate + - name: konnectivity-uds + hostPath: + path: /etc/kubernetes/konnectivity-server + type: DirectoryOrCreate diff --git a/content/fa/examples/admin/logging/fluentd-sidecar-config.yaml b/content/fa/examples/admin/logging/fluentd-sidecar-config.yaml new file mode 100644 index 0000000000000..eea1849b033fa --- /dev/null +++ b/content/fa/examples/admin/logging/fluentd-sidecar-config.yaml @@ -0,0 +1,25 @@ +apiVersion: v1 +kind: ConfigMap +metadata: + name: fluentd-config +data: + fluentd.conf: | + + type tail + format none + path /var/log/1.log + pos_file /var/log/1.log.pos + tag count.format1 + + + + type tail + format none + path /var/log/2.log + pos_file /var/log/2.log.pos + tag count.format2 + + + + type google_cloud + diff --git a/content/fa/examples/admin/logging/two-files-counter-pod-agent-sidecar.yaml b/content/fa/examples/admin/logging/two-files-counter-pod-agent-sidecar.yaml new file mode 100644 index 0000000000000..a621a9fb2acce --- /dev/null +++ b/content/fa/examples/admin/logging/two-files-counter-pod-agent-sidecar.yaml @@ -0,0 +1,39 @@ +apiVersion: v1 +kind: Pod +metadata: + name: counter +spec: + containers: + - name: count + image: busybox:1.28 + args: + - /bin/sh + - -c + - > + i=0; + while true; + do + echo "$i: $(date)" >> /var/log/1.log; + echo "$(date) INFO $i" >> /var/log/2.log; + i=$((i+1)); + sleep 1; + done + volumeMounts: + - name: varlog + mountPath: /var/log + - name: count-agent + image: registry.k8s.io/fluentd-gcp:1.30 + env: + - name: FLUENTD_ARGS + value: -c /etc/fluentd-config/fluentd.conf + volumeMounts: + - name: varlog + mountPath: /var/log + - name: config-volume + mountPath: /etc/fluentd-config + volumes: + - name: varlog + emptyDir: {} + - name: config-volume + configMap: + name: fluentd-config diff --git a/content/fa/examples/admin/logging/two-files-counter-pod-streaming-sidecar.yaml b/content/fa/examples/admin/logging/two-files-counter-pod-streaming-sidecar.yaml new file mode 100644 index 0000000000000..ac19efe4a2350 --- /dev/null +++ b/content/fa/examples/admin/logging/two-files-counter-pod-streaming-sidecar.yaml @@ -0,0 +1,38 @@ +apiVersion: v1 +kind: Pod +metadata: + name: counter +spec: + containers: + - name: count + image: busybox:1.28 + args: + - /bin/sh + - -c + - > + i=0; + while true; + do + echo "$i: $(date)" >> /var/log/1.log; + echo "$(date) INFO $i" >> /var/log/2.log; + i=$((i+1)); + sleep 1; + done + volumeMounts: + - name: varlog + mountPath: /var/log + - name: count-log-1 + image: busybox:1.28 + args: [/bin/sh, -c, 'tail -n+1 -F /var/log/1.log'] + volumeMounts: + - name: varlog + mountPath: /var/log + - name: count-log-2 + image: busybox:1.28 + args: [/bin/sh, -c, 'tail -n+1 -F /var/log/2.log'] + volumeMounts: + - name: varlog + mountPath: /var/log + volumes: + - name: varlog + emptyDir: {} diff --git a/content/fa/examples/admin/logging/two-files-counter-pod.yaml b/content/fa/examples/admin/logging/two-files-counter-pod.yaml new file mode 100644 index 0000000000000..31bbed3cf8683 --- /dev/null +++ b/content/fa/examples/admin/logging/two-files-counter-pod.yaml @@ -0,0 +1,26 @@ +apiVersion: v1 +kind: Pod +metadata: + name: counter +spec: + containers: + - name: count + image: busybox:1.28 + args: + - /bin/sh + - -c + - > + i=0; + while true; + do + echo "$i: $(date)" >> /var/log/1.log; + echo "$(date) INFO $i" >> /var/log/2.log; + i=$((i+1)); + sleep 1; + done + volumeMounts: + - name: varlog + mountPath: /var/log + volumes: + - name: varlog + emptyDir: {} diff --git a/content/fa/examples/admin/namespace-dev.json b/content/fa/examples/admin/namespace-dev.json new file mode 100644 index 0000000000000..cb3ed7cdc1efa --- /dev/null +++ b/content/fa/examples/admin/namespace-dev.json @@ -0,0 +1,10 @@ +{ + "apiVersion": "v1", + "kind": "Namespace", + "metadata": { + "name": "development", + "labels": { + "name": "development" + } + } +} diff --git a/content/fa/examples/admin/namespace-dev.yaml b/content/fa/examples/admin/namespace-dev.yaml new file mode 100644 index 0000000000000..5e753b693f03b --- /dev/null +++ b/content/fa/examples/admin/namespace-dev.yaml @@ -0,0 +1,6 @@ +apiVersion: v1 +kind: Namespace +metadata: + name: development + labels: + name: development diff --git a/content/fa/examples/admin/namespace-prod.json b/content/fa/examples/admin/namespace-prod.json new file mode 100644 index 0000000000000..878ba7866ca59 --- /dev/null +++ b/content/fa/examples/admin/namespace-prod.json @@ -0,0 +1,10 @@ +{ + "apiVersion": "v1", + "kind": "Namespace", + "metadata": { + "name": "production", + "labels": { + "name": "production" + } + } +} diff --git a/content/fa/examples/admin/namespace-prod.yaml b/content/fa/examples/admin/namespace-prod.yaml new file mode 100644 index 0000000000000..761d6325cb404 --- /dev/null +++ b/content/fa/examples/admin/namespace-prod.yaml @@ -0,0 +1,6 @@ +apiVersion: v1 +kind: Namespace +metadata: + name: production + labels: + name: production diff --git a/content/fa/examples/admin/resource/cpu-constraints-pod-2.yaml b/content/fa/examples/admin/resource/cpu-constraints-pod-2.yaml new file mode 100644 index 0000000000000..b5c7348f26ee0 --- /dev/null +++ b/content/fa/examples/admin/resource/cpu-constraints-pod-2.yaml @@ -0,0 +1,13 @@ +apiVersion: v1 +kind: Pod +metadata: + name: constraints-cpu-demo-2 +spec: + containers: + - name: constraints-cpu-demo-2-ctr + image: nginx + resources: + limits: + cpu: "1.5" + requests: + cpu: "500m" diff --git a/content/fa/examples/admin/resource/cpu-constraints-pod-3.yaml b/content/fa/examples/admin/resource/cpu-constraints-pod-3.yaml new file mode 100644 index 0000000000000..0a2083acd8ec6 --- /dev/null +++ b/content/fa/examples/admin/resource/cpu-constraints-pod-3.yaml @@ -0,0 +1,13 @@ +apiVersion: v1 +kind: Pod +metadata: + name: constraints-cpu-demo-3 +spec: + containers: + - name: constraints-cpu-demo-3-ctr + image: nginx + resources: + limits: + cpu: "800m" + requests: + cpu: "100m" diff --git a/content/fa/examples/admin/resource/cpu-constraints-pod-4.yaml b/content/fa/examples/admin/resource/cpu-constraints-pod-4.yaml new file mode 100644 index 0000000000000..3c102158db509 --- /dev/null +++ b/content/fa/examples/admin/resource/cpu-constraints-pod-4.yaml @@ -0,0 +1,8 @@ +apiVersion: v1 +kind: Pod +metadata: + name: constraints-cpu-demo-4 +spec: + containers: + - name: constraints-cpu-demo-4-ctr + image: vish/stress diff --git a/content/fa/examples/admin/resource/cpu-constraints-pod.yaml b/content/fa/examples/admin/resource/cpu-constraints-pod.yaml new file mode 100644 index 0000000000000..7db23f26c8842 --- /dev/null +++ b/content/fa/examples/admin/resource/cpu-constraints-pod.yaml @@ -0,0 +1,13 @@ +apiVersion: v1 +kind: Pod +metadata: + name: constraints-cpu-demo +spec: + containers: + - name: constraints-cpu-demo-ctr + image: nginx + resources: + limits: + cpu: "800m" + requests: + cpu: "500m" diff --git a/content/fa/examples/admin/resource/cpu-constraints.yaml b/content/fa/examples/admin/resource/cpu-constraints.yaml new file mode 100644 index 0000000000000..6fc4239027c86 --- /dev/null +++ b/content/fa/examples/admin/resource/cpu-constraints.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: LimitRange +metadata: + name: cpu-min-max-demo-lr +spec: + limits: + - max: + cpu: "800m" + min: + cpu: "200m" + type: Container diff --git a/content/fa/examples/admin/resource/cpu-defaults-pod-2.yaml b/content/fa/examples/admin/resource/cpu-defaults-pod-2.yaml new file mode 100644 index 0000000000000..9ca216dee1557 --- /dev/null +++ b/content/fa/examples/admin/resource/cpu-defaults-pod-2.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: Pod +metadata: + name: default-cpu-demo-2 +spec: + containers: + - name: default-cpu-demo-2-ctr + image: nginx + resources: + limits: + cpu: "1" diff --git a/content/fa/examples/admin/resource/cpu-defaults-pod-3.yaml b/content/fa/examples/admin/resource/cpu-defaults-pod-3.yaml new file mode 100644 index 0000000000000..214cdee34bfff --- /dev/null +++ b/content/fa/examples/admin/resource/cpu-defaults-pod-3.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: Pod +metadata: + name: default-cpu-demo-3 +spec: + containers: + - name: default-cpu-demo-3-ctr + image: nginx + resources: + requests: + cpu: "0.75" diff --git a/content/fa/examples/admin/resource/cpu-defaults-pod.yaml b/content/fa/examples/admin/resource/cpu-defaults-pod.yaml new file mode 100644 index 0000000000000..56b06d9a690e5 --- /dev/null +++ b/content/fa/examples/admin/resource/cpu-defaults-pod.yaml @@ -0,0 +1,8 @@ +apiVersion: v1 +kind: Pod +metadata: + name: default-cpu-demo +spec: + containers: + - name: default-cpu-demo-ctr + image: nginx diff --git a/content/fa/examples/admin/resource/cpu-defaults.yaml b/content/fa/examples/admin/resource/cpu-defaults.yaml new file mode 100644 index 0000000000000..b53d297181683 --- /dev/null +++ b/content/fa/examples/admin/resource/cpu-defaults.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: LimitRange +metadata: + name: cpu-limit-range +spec: + limits: + - default: + cpu: 1 + defaultRequest: + cpu: 0.5 + type: Container diff --git a/content/fa/examples/admin/resource/limit-mem-cpu-container.yaml b/content/fa/examples/admin/resource/limit-mem-cpu-container.yaml new file mode 100644 index 0000000000000..3c2b30f29ccef --- /dev/null +++ b/content/fa/examples/admin/resource/limit-mem-cpu-container.yaml @@ -0,0 +1,19 @@ +apiVersion: v1 +kind: LimitRange +metadata: + name: limit-mem-cpu-per-container +spec: + limits: + - max: + cpu: "800m" + memory: "1Gi" + min: + cpu: "100m" + memory: "99Mi" + default: + cpu: "700m" + memory: "900Mi" + defaultRequest: + cpu: "110m" + memory: "111Mi" + type: Container diff --git a/content/fa/examples/admin/resource/limit-mem-cpu-pod.yaml b/content/fa/examples/admin/resource/limit-mem-cpu-pod.yaml new file mode 100644 index 0000000000000..0ce0f69ac8130 --- /dev/null +++ b/content/fa/examples/admin/resource/limit-mem-cpu-pod.yaml @@ -0,0 +1,10 @@ +apiVersion: v1 +kind: LimitRange +metadata: + name: limit-mem-cpu-per-pod +spec: + limits: + - max: + cpu: "2" + memory: "2Gi" + type: Pod diff --git a/content/fa/examples/admin/resource/limit-memory-ratio-pod.yaml b/content/fa/examples/admin/resource/limit-memory-ratio-pod.yaml new file mode 100644 index 0000000000000..859fc20ecec38 --- /dev/null +++ b/content/fa/examples/admin/resource/limit-memory-ratio-pod.yaml @@ -0,0 +1,9 @@ +apiVersion: v1 +kind: LimitRange +metadata: + name: limit-memory-ratio-pod +spec: + limits: + - maxLimitRequestRatio: + memory: 2 + type: Pod diff --git a/content/fa/examples/admin/resource/limit-range-pod-1.yaml b/content/fa/examples/admin/resource/limit-range-pod-1.yaml new file mode 100644 index 0000000000000..b9bd20d06a2c7 --- /dev/null +++ b/content/fa/examples/admin/resource/limit-range-pod-1.yaml @@ -0,0 +1,37 @@ +apiVersion: v1 +kind: Pod +metadata: + name: busybox1 +spec: + containers: + - name: busybox-cnt01 + image: busybox:1.28 + command: ["/bin/sh"] + args: ["-c", "while true; do echo hello from cnt01; sleep 10;done"] + resources: + requests: + memory: "100Mi" + cpu: "100m" + limits: + memory: "200Mi" + cpu: "500m" + - name: busybox-cnt02 + image: busybox:1.28 + command: ["/bin/sh"] + args: ["-c", "while true; do echo hello from cnt02; sleep 10;done"] + resources: + requests: + memory: "100Mi" + cpu: "100m" + - name: busybox-cnt03 + image: busybox:1.28 + command: ["/bin/sh"] + args: ["-c", "while true; do echo hello from cnt03; sleep 10;done"] + resources: + limits: + memory: "200Mi" + cpu: "500m" + - name: busybox-cnt04 + image: busybox:1.28 + command: ["/bin/sh"] + args: ["-c", "while true; do echo hello from cnt04; sleep 10;done"] diff --git a/content/fa/examples/admin/resource/limit-range-pod-2.yaml b/content/fa/examples/admin/resource/limit-range-pod-2.yaml new file mode 100644 index 0000000000000..40da19c1aee05 --- /dev/null +++ b/content/fa/examples/admin/resource/limit-range-pod-2.yaml @@ -0,0 +1,37 @@ +apiVersion: v1 +kind: Pod +metadata: + name: busybox2 +spec: + containers: + - name: busybox-cnt01 + image: busybox:1.28 + command: ["/bin/sh"] + args: ["-c", "while true; do echo hello from cnt01; sleep 10;done"] + resources: + requests: + memory: "100Mi" + cpu: "100m" + limits: + memory: "200Mi" + cpu: "500m" + - name: busybox-cnt02 + image: busybox:1.28 + command: ["/bin/sh"] + args: ["-c", "while true; do echo hello from cnt02; sleep 10;done"] + resources: + requests: + memory: "100Mi" + cpu: "100m" + - name: busybox-cnt03 + image: busybox:1.28 + command: ["/bin/sh"] + args: ["-c", "while true; do echo hello from cnt03; sleep 10;done"] + resources: + limits: + memory: "200Mi" + cpu: "500m" + - name: busybox-cnt04 + image: busybox:1.28 + command: ["/bin/sh"] + args: ["-c", "while true; do echo hello from cnt04; sleep 10;done"] diff --git a/content/fa/examples/admin/resource/limit-range-pod-3.yaml b/content/fa/examples/admin/resource/limit-range-pod-3.yaml new file mode 100644 index 0000000000000..5b6b835e38b62 --- /dev/null +++ b/content/fa/examples/admin/resource/limit-range-pod-3.yaml @@ -0,0 +1,14 @@ +apiVersion: v1 +kind: Pod +metadata: + name: busybox3 +spec: + containers: + - name: busybox-cnt01 + image: busybox:1.28 + command: ["sleep", "3600"] + resources: + limits: + memory: "300Mi" + requests: + memory: "100Mi" diff --git a/content/fa/examples/admin/resource/memory-available-cgroupv2.sh b/content/fa/examples/admin/resource/memory-available-cgroupv2.sh new file mode 100644 index 0000000000000..47b9f6802bdfd --- /dev/null +++ b/content/fa/examples/admin/resource/memory-available-cgroupv2.sh @@ -0,0 +1,30 @@ +#!/bin/bash + +# This script reproduces what the kubelet does +# to calculate memory.available relative to kubepods cgroup. + +# current memory usage +memory_capacity_in_kb=$(cat /proc/meminfo | grep MemTotal | awk '{print $2}') +memory_capacity_in_bytes=$((memory_capacity_in_kb * 1024)) +memory_usage_in_bytes=$(cat /sys/fs/cgroup/kubepods.slice/memory.current) +memory_total_inactive_file=$(cat /sys/fs/cgroup/kubepods.slice/memory.stat | grep inactive_file | awk '{print $2}') + +memory_working_set=${memory_usage_in_bytes} +if [ "$memory_working_set" -lt "$memory_total_inactive_file" ]; +then + memory_working_set=0 +else + memory_working_set=$((memory_usage_in_bytes - memory_total_inactive_file)) +fi + +memory_available_in_bytes=$((memory_capacity_in_bytes - memory_working_set)) +memory_available_in_kb=$((memory_available_in_bytes / 1024)) +memory_available_in_mb=$((memory_available_in_kb / 1024)) + +echo "memory.capacity_in_bytes $memory_capacity_in_bytes" +echo "memory.usage_in_bytes $memory_usage_in_bytes" +echo "memory.total_inactive_file $memory_total_inactive_file" +echo "memory.working_set $memory_working_set" +echo "memory.available_in_bytes $memory_available_in_bytes" +echo "memory.available_in_kb $memory_available_in_kb" +echo "memory.available_in_mb $memory_available_in_mb" diff --git a/content/fa/examples/admin/resource/memory-available.sh b/content/fa/examples/admin/resource/memory-available.sh new file mode 100644 index 0000000000000..a699b1d2e2046 --- /dev/null +++ b/content/fa/examples/admin/resource/memory-available.sh @@ -0,0 +1,31 @@ +#!/bin/bash +#!/usr/bin/env bash + +# This script reproduces what the kubelet does +# to calculate memory.available relative to root cgroup. + +# current memory usage +memory_capacity_in_kb=$(cat /proc/meminfo | grep MemTotal | awk '{print $2}') +memory_capacity_in_bytes=$((memory_capacity_in_kb * 1024)) +memory_usage_in_bytes=$(cat /sys/fs/cgroup/memory/memory.usage_in_bytes) +memory_total_inactive_file=$(cat /sys/fs/cgroup/memory/memory.stat | grep total_inactive_file | awk '{print $2}') + +memory_working_set=${memory_usage_in_bytes} +if [ "$memory_working_set" -lt "$memory_total_inactive_file" ]; +then + memory_working_set=0 +else + memory_working_set=$((memory_usage_in_bytes - memory_total_inactive_file)) +fi + +memory_available_in_bytes=$((memory_capacity_in_bytes - memory_working_set)) +memory_available_in_kb=$((memory_available_in_bytes / 1024)) +memory_available_in_mb=$((memory_available_in_kb / 1024)) + +echo "memory.capacity_in_bytes $memory_capacity_in_bytes" +echo "memory.usage_in_bytes $memory_usage_in_bytes" +echo "memory.total_inactive_file $memory_total_inactive_file" +echo "memory.working_set $memory_working_set" +echo "memory.available_in_bytes $memory_available_in_bytes" +echo "memory.available_in_kb $memory_available_in_kb" +echo "memory.available_in_mb $memory_available_in_mb" diff --git a/content/fa/examples/admin/resource/memory-constraints-pod-2.yaml b/content/fa/examples/admin/resource/memory-constraints-pod-2.yaml new file mode 100644 index 0000000000000..0b1ae569c4962 --- /dev/null +++ b/content/fa/examples/admin/resource/memory-constraints-pod-2.yaml @@ -0,0 +1,13 @@ +apiVersion: v1 +kind: Pod +metadata: + name: constraints-mem-demo-2 +spec: + containers: + - name: constraints-mem-demo-2-ctr + image: nginx + resources: + limits: + memory: "1.5Gi" + requests: + memory: "800Mi" diff --git a/content/fa/examples/admin/resource/memory-constraints-pod-3.yaml b/content/fa/examples/admin/resource/memory-constraints-pod-3.yaml new file mode 100644 index 0000000000000..f97cd4a8ac07f --- /dev/null +++ b/content/fa/examples/admin/resource/memory-constraints-pod-3.yaml @@ -0,0 +1,13 @@ +apiVersion: v1 +kind: Pod +metadata: + name: constraints-mem-demo-3 +spec: + containers: + - name: constraints-mem-demo-3-ctr + image: nginx + resources: + limits: + memory: "800Mi" + requests: + memory: "100Mi" diff --git a/content/fa/examples/admin/resource/memory-constraints-pod-4.yaml b/content/fa/examples/admin/resource/memory-constraints-pod-4.yaml new file mode 100644 index 0000000000000..657530c41e7fc --- /dev/null +++ b/content/fa/examples/admin/resource/memory-constraints-pod-4.yaml @@ -0,0 +1,9 @@ +apiVersion: v1 +kind: Pod +metadata: + name: constraints-mem-demo-4 +spec: + containers: + - name: constraints-mem-demo-4-ctr + image: nginx + diff --git a/content/fa/examples/admin/resource/memory-constraints-pod.yaml b/content/fa/examples/admin/resource/memory-constraints-pod.yaml new file mode 100644 index 0000000000000..06954d10d65ad --- /dev/null +++ b/content/fa/examples/admin/resource/memory-constraints-pod.yaml @@ -0,0 +1,13 @@ +apiVersion: v1 +kind: Pod +metadata: + name: constraints-mem-demo +spec: + containers: + - name: constraints-mem-demo-ctr + image: nginx + resources: + limits: + memory: "800Mi" + requests: + memory: "600Mi" diff --git a/content/fa/examples/admin/resource/memory-constraints.yaml b/content/fa/examples/admin/resource/memory-constraints.yaml new file mode 100644 index 0000000000000..3a2924c032e50 --- /dev/null +++ b/content/fa/examples/admin/resource/memory-constraints.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: LimitRange +metadata: + name: mem-min-max-demo-lr +spec: + limits: + - max: + memory: 1Gi + min: + memory: 500Mi + type: Container diff --git a/content/fa/examples/admin/resource/memory-defaults-pod-2.yaml b/content/fa/examples/admin/resource/memory-defaults-pod-2.yaml new file mode 100644 index 0000000000000..aa80610d84492 --- /dev/null +++ b/content/fa/examples/admin/resource/memory-defaults-pod-2.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: Pod +metadata: + name: default-mem-demo-2 +spec: + containers: + - name: default-mem-demo-2-ctr + image: nginx + resources: + limits: + memory: "1Gi" diff --git a/content/fa/examples/admin/resource/memory-defaults-pod-3.yaml b/content/fa/examples/admin/resource/memory-defaults-pod-3.yaml new file mode 100644 index 0000000000000..09ee8b39a9b42 --- /dev/null +++ b/content/fa/examples/admin/resource/memory-defaults-pod-3.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: Pod +metadata: + name: default-mem-demo-3 +spec: + containers: + - name: default-mem-demo-3-ctr + image: nginx + resources: + requests: + memory: "128Mi" diff --git a/content/fa/examples/admin/resource/memory-defaults-pod.yaml b/content/fa/examples/admin/resource/memory-defaults-pod.yaml new file mode 100644 index 0000000000000..ce7a50fb555e0 --- /dev/null +++ b/content/fa/examples/admin/resource/memory-defaults-pod.yaml @@ -0,0 +1,8 @@ +apiVersion: v1 +kind: Pod +metadata: + name: default-mem-demo +spec: + containers: + - name: default-mem-demo-ctr + image: nginx diff --git a/content/fa/examples/admin/resource/memory-defaults.yaml b/content/fa/examples/admin/resource/memory-defaults.yaml new file mode 100644 index 0000000000000..b98a5ae262561 --- /dev/null +++ b/content/fa/examples/admin/resource/memory-defaults.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: LimitRange +metadata: + name: mem-limit-range +spec: + limits: + - default: + memory: 512Mi + defaultRequest: + memory: 256Mi + type: Container diff --git a/content/fa/examples/admin/resource/pvc-limit-greater.yaml b/content/fa/examples/admin/resource/pvc-limit-greater.yaml new file mode 100644 index 0000000000000..2d92bf92b3121 --- /dev/null +++ b/content/fa/examples/admin/resource/pvc-limit-greater.yaml @@ -0,0 +1,10 @@ +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: pvc-limit-greater +spec: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 5Gi diff --git a/content/fa/examples/admin/resource/pvc-limit-lower.yaml b/content/fa/examples/admin/resource/pvc-limit-lower.yaml new file mode 100644 index 0000000000000..ef819b6292049 --- /dev/null +++ b/content/fa/examples/admin/resource/pvc-limit-lower.yaml @@ -0,0 +1,10 @@ +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: pvc-limit-lower +spec: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 500Mi diff --git a/content/fa/examples/admin/resource/quota-mem-cpu-pod-2.yaml b/content/fa/examples/admin/resource/quota-mem-cpu-pod-2.yaml new file mode 100644 index 0000000000000..380e900fda52f --- /dev/null +++ b/content/fa/examples/admin/resource/quota-mem-cpu-pod-2.yaml @@ -0,0 +1,15 @@ +apiVersion: v1 +kind: Pod +metadata: + name: quota-mem-cpu-demo-2 +spec: + containers: + - name: quota-mem-cpu-demo-2-ctr + image: redis + resources: + limits: + memory: "1Gi" + cpu: "800m" + requests: + memory: "700Mi" + cpu: "400m" diff --git a/content/fa/examples/admin/resource/quota-mem-cpu-pod.yaml b/content/fa/examples/admin/resource/quota-mem-cpu-pod.yaml new file mode 100644 index 0000000000000..b0fd0a9451bf2 --- /dev/null +++ b/content/fa/examples/admin/resource/quota-mem-cpu-pod.yaml @@ -0,0 +1,15 @@ +apiVersion: v1 +kind: Pod +metadata: + name: quota-mem-cpu-demo +spec: + containers: + - name: quota-mem-cpu-demo-ctr + image: nginx + resources: + limits: + memory: "800Mi" + cpu: "800m" + requests: + memory: "600Mi" + cpu: "400m" diff --git a/content/fa/examples/admin/resource/quota-mem-cpu.yaml b/content/fa/examples/admin/resource/quota-mem-cpu.yaml new file mode 100644 index 0000000000000..5c4bcd81b8b35 --- /dev/null +++ b/content/fa/examples/admin/resource/quota-mem-cpu.yaml @@ -0,0 +1,10 @@ +apiVersion: v1 +kind: ResourceQuota +metadata: + name: mem-cpu-demo +spec: + hard: + requests.cpu: "1" + requests.memory: 1Gi + limits.cpu: "2" + limits.memory: 2Gi diff --git a/content/fa/examples/admin/resource/quota-objects-pvc-2.yaml b/content/fa/examples/admin/resource/quota-objects-pvc-2.yaml new file mode 100644 index 0000000000000..2539c2d3093a8 --- /dev/null +++ b/content/fa/examples/admin/resource/quota-objects-pvc-2.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: pvc-quota-demo-2 +spec: + storageClassName: manual + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 4Gi diff --git a/content/fa/examples/admin/resource/quota-objects-pvc.yaml b/content/fa/examples/admin/resource/quota-objects-pvc.yaml new file mode 100644 index 0000000000000..728bb4d708c27 --- /dev/null +++ b/content/fa/examples/admin/resource/quota-objects-pvc.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: pvc-quota-demo +spec: + storageClassName: manual + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 3Gi diff --git a/content/fa/examples/admin/resource/quota-objects.yaml b/content/fa/examples/admin/resource/quota-objects.yaml new file mode 100644 index 0000000000000..e97748decd53a --- /dev/null +++ b/content/fa/examples/admin/resource/quota-objects.yaml @@ -0,0 +1,9 @@ +apiVersion: v1 +kind: ResourceQuota +metadata: + name: object-quota-demo +spec: + hard: + persistentvolumeclaims: "1" + services.loadbalancers: "2" + services.nodeports: "0" diff --git a/content/fa/examples/admin/resource/quota-pod-deployment.yaml b/content/fa/examples/admin/resource/quota-pod-deployment.yaml new file mode 100644 index 0000000000000..86e85aa468e13 --- /dev/null +++ b/content/fa/examples/admin/resource/quota-pod-deployment.yaml @@ -0,0 +1,17 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: pod-quota-demo +spec: + selector: + matchLabels: + purpose: quota-demo + replicas: 3 + template: + metadata: + labels: + purpose: quota-demo + spec: + containers: + - name: pod-quota-demo + image: nginx diff --git a/content/fa/examples/admin/resource/quota-pod.yaml b/content/fa/examples/admin/resource/quota-pod.yaml new file mode 100644 index 0000000000000..0a07f055ca853 --- /dev/null +++ b/content/fa/examples/admin/resource/quota-pod.yaml @@ -0,0 +1,7 @@ +apiVersion: v1 +kind: ResourceQuota +metadata: + name: pod-demo +spec: + hard: + pods: "2" diff --git a/content/fa/examples/admin/resource/storagelimits.yaml b/content/fa/examples/admin/resource/storagelimits.yaml new file mode 100644 index 0000000000000..7f597e4dfe9b1 --- /dev/null +++ b/content/fa/examples/admin/resource/storagelimits.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: LimitRange +metadata: + name: storagelimits +spec: + limits: + - type: PersistentVolumeClaim + max: + storage: 2Gi + min: + storage: 1Gi diff --git a/content/fa/examples/admin/sched/clusterrole.yaml b/content/fa/examples/admin/sched/clusterrole.yaml new file mode 100644 index 0000000000000..554b8659db5b0 --- /dev/null +++ b/content/fa/examples/admin/sched/clusterrole.yaml @@ -0,0 +1,37 @@ +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + annotations: + rbac.authorization.kubernetes.io/autoupdate: "true" + labels: + kubernetes.io/bootstrapping: rbac-defaults + name: system:kube-scheduler +rules: + - apiGroups: + - coordination.k8s.io + resources: + - leases + verbs: + - create + - apiGroups: + - coordination.k8s.io + resourceNames: + - kube-scheduler + - my-scheduler + resources: + - leases + verbs: + - get + - update + - apiGroups: + - "" + resourceNames: + - kube-scheduler + - my-scheduler + resources: + - endpoints + verbs: + - delete + - get + - patch + - update diff --git a/content/fa/examples/admin/sched/my-scheduler.yaml b/content/fa/examples/admin/sched/my-scheduler.yaml new file mode 100644 index 0000000000000..026ad81f63401 --- /dev/null +++ b/content/fa/examples/admin/sched/my-scheduler.yaml @@ -0,0 +1,113 @@ +apiVersion: v1 +kind: ServiceAccount +metadata: + name: my-scheduler + namespace: kube-system +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRoleBinding +metadata: + name: my-scheduler-as-kube-scheduler +subjects: +- kind: ServiceAccount + name: my-scheduler + namespace: kube-system +roleRef: + kind: ClusterRole + name: system:kube-scheduler + apiGroup: rbac.authorization.k8s.io +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRoleBinding +metadata: + name: my-scheduler-as-volume-scheduler +subjects: +- kind: ServiceAccount + name: my-scheduler + namespace: kube-system +roleRef: + kind: ClusterRole + name: system:volume-scheduler + apiGroup: rbac.authorization.k8s.io +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: RoleBinding +metadata: + name: my-scheduler-extension-apiserver-authentication-reader + namespace: kube-system +roleRef: + kind: Role + name: extension-apiserver-authentication-reader + apiGroup: rbac.authorization.k8s.io +subjects: +- kind: ServiceAccount + name: my-scheduler + namespace: kube-system +--- +apiVersion: v1 +kind: ConfigMap +metadata: + name: my-scheduler-config + namespace: kube-system +data: + my-scheduler-config.yaml: | + apiVersion: kubescheduler.config.k8s.io/v1 + kind: KubeSchedulerConfiguration + profiles: + - schedulerName: my-scheduler + leaderElection: + leaderElect: false +--- +apiVersion: apps/v1 +kind: Deployment +metadata: + labels: + component: scheduler + tier: control-plane + name: my-scheduler + namespace: kube-system +spec: + selector: + matchLabels: + component: scheduler + tier: control-plane + replicas: 1 + template: + metadata: + labels: + component: scheduler + tier: control-plane + version: second + spec: + serviceAccountName: my-scheduler + containers: + - command: + - /usr/local/bin/kube-scheduler + - --config=/etc/kubernetes/my-scheduler/my-scheduler-config.yaml + image: gcr.io/my-gcp-project/my-kube-scheduler:1.0 + livenessProbe: + httpGet: + path: /healthz + port: 10259 + scheme: HTTPS + initialDelaySeconds: 15 + name: kube-second-scheduler + readinessProbe: + httpGet: + path: /healthz + port: 10259 + scheme: HTTPS + resources: + requests: + cpu: '0.1' + securityContext: + privileged: false + volumeMounts: + - name: config-volume + mountPath: /etc/kubernetes/my-scheduler + hostNetwork: false + hostPID: false + volumes: + - name: config-volume + configMap: + name: my-scheduler-config diff --git a/content/fa/examples/admin/sched/pod1.yaml b/content/fa/examples/admin/sched/pod1.yaml new file mode 100644 index 0000000000000..1b5a89c49d0f0 --- /dev/null +++ b/content/fa/examples/admin/sched/pod1.yaml @@ -0,0 +1,10 @@ +apiVersion: v1 +kind: Pod +metadata: + name: no-annotation + labels: + name: multischeduler-example +spec: + containers: + - name: pod-with-no-annotation-container + image: registry.k8s.io/pause:3.8 \ No newline at end of file diff --git a/content/fa/examples/admin/sched/pod2.yaml b/content/fa/examples/admin/sched/pod2.yaml new file mode 100644 index 0000000000000..dc3377d1d58dc --- /dev/null +++ b/content/fa/examples/admin/sched/pod2.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: Pod +metadata: + name: annotation-default-scheduler + labels: + name: multischeduler-example +spec: + schedulerName: default-scheduler + containers: + - name: pod-with-default-annotation-container + image: registry.k8s.io/pause:3.8 diff --git a/content/fa/examples/admin/sched/pod3.yaml b/content/fa/examples/admin/sched/pod3.yaml new file mode 100644 index 0000000000000..fde319d0ad92a --- /dev/null +++ b/content/fa/examples/admin/sched/pod3.yaml @@ -0,0 +1,11 @@ +apiVersion: v1 +kind: Pod +metadata: + name: annotation-second-scheduler + labels: + name: multischeduler-example +spec: + schedulerName: my-scheduler + containers: + - name: pod-with-second-annotation-container + image: registry.k8s.io/pause:3.8 diff --git a/content/fa/examples/admin/snowflake-deployment.yaml b/content/fa/examples/admin/snowflake-deployment.yaml new file mode 100644 index 0000000000000..21b6738ba4e6d --- /dev/null +++ b/content/fa/examples/admin/snowflake-deployment.yaml @@ -0,0 +1,20 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + labels: + app: snowflake + name: snowflake +spec: + replicas: 2 + selector: + matchLabels: + app: snowflake + template: + metadata: + labels: + app: snowflake + spec: + containers: + - image: registry.k8s.io/serve_hostname + imagePullPolicy: Always + name: snowflake diff --git a/content/fa/examples/application/basic-daemonset.yaml b/content/fa/examples/application/basic-daemonset.yaml new file mode 100644 index 0000000000000..f343544c29eeb --- /dev/null +++ b/content/fa/examples/application/basic-daemonset.yaml @@ -0,0 +1,34 @@ +apiVersion: apps/v1 +kind: DaemonSet +metadata: + name: example-daemonset +spec: + selector: + matchLabels: + app.kubernetes.io/name: example + template: + metadata: + labels: + app.kubernetes.io/name: example + spec: + containers: + - name: pause + image: registry.k8s.io/pause + initContainers: + - name: log-machine-id + image: busybox:1.37 + command: ['sh', '-c', 'cat /etc/machine-id > /var/log/machine-id.log'] + volumeMounts: + - name: machine-id + mountPath: /etc/machine-id + readOnly: true + - name: log-dir + mountPath: /var/log + volumes: + - name: machine-id + hostPath: + path: /etc/machine-id + type: File + - name: log-dir + hostPath: + path: /var/log \ No newline at end of file diff --git a/content/fa/examples/application/cassandra/cassandra-service.yaml b/content/fa/examples/application/cassandra/cassandra-service.yaml new file mode 100644 index 0000000000000..31bee74b58732 --- /dev/null +++ b/content/fa/examples/application/cassandra/cassandra-service.yaml @@ -0,0 +1,12 @@ +apiVersion: v1 +kind: Service +metadata: + labels: + app: cassandra + name: cassandra +spec: + clusterIP: None + ports: + - port: 9042 + selector: + app: cassandra diff --git a/content/fa/examples/application/cassandra/cassandra-statefulset.yaml b/content/fa/examples/application/cassandra/cassandra-statefulset.yaml new file mode 100644 index 0000000000000..7e8bf30d85add --- /dev/null +++ b/content/fa/examples/application/cassandra/cassandra-statefulset.yaml @@ -0,0 +1,100 @@ +apiVersion: apps/v1 +kind: StatefulSet +metadata: + name: cassandra + labels: + app: cassandra +spec: + serviceName: cassandra + replicas: 3 + selector: + matchLabels: + app: cassandra + template: + metadata: + labels: + app: cassandra + spec: + terminationGracePeriodSeconds: 500 + containers: + - name: cassandra + image: gcr.io/google-samples/cassandra:v13 + imagePullPolicy: Always + ports: + - containerPort: 7000 + name: intra-node + - containerPort: 7001 + name: tls-intra-node + - containerPort: 7199 + name: jmx + - containerPort: 9042 + name: cql + resources: + limits: + cpu: "500m" + memory: 1Gi + requests: + cpu: "500m" + memory: 1Gi + securityContext: + capabilities: + add: + - IPC_LOCK + lifecycle: + preStop: + exec: + command: + - /bin/sh + - -c + - nodetool drain + env: + - name: MAX_HEAP_SIZE + value: 512M + - name: HEAP_NEWSIZE + value: 100M + - name: CASSANDRA_SEEDS + value: "cassandra-0.cassandra.default.svc.cluster.local" + - name: CASSANDRA_CLUSTER_NAME + value: "K8Demo" + - name: CASSANDRA_DC + value: "DC1-K8Demo" + - name: CASSANDRA_RACK + value: "Rack1-K8Demo" + - name: POD_IP + valueFrom: + fieldRef: + fieldPath: status.podIP + readinessProbe: + exec: + command: + - /bin/bash + - -c + - /ready-probe.sh + initialDelaySeconds: 15 + timeoutSeconds: 5 + # These volume mounts are persistent. They are like inline claims, + # but not exactly because the names need to match exactly one of + # the stateful pod volumes. + volumeMounts: + - name: cassandra-data + mountPath: /cassandra_data + # These are converted to volume claims by the controller + # and mounted at the paths mentioned above. + # do not use these in production until ssd GCEPersistentDisk or other ssd pd + volumeClaimTemplates: + - metadata: + name: cassandra-data + spec: + accessModes: [ "ReadWriteOnce" ] + storageClassName: fast + resources: + requests: + storage: 1Gi +--- +kind: StorageClass +apiVersion: storage.k8s.io/v1 +metadata: + name: fast +provisioner: k8s.io/minikube-hostpath +parameters: + type: pd-ssd diff --git a/content/fa/examples/application/deployment-patch.yaml b/content/fa/examples/application/deployment-patch.yaml new file mode 100644 index 0000000000000..af12f4cb0c4ec --- /dev/null +++ b/content/fa/examples/application/deployment-patch.yaml @@ -0,0 +1,21 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: patch-demo +spec: + replicas: 2 + selector: + matchLabels: + app: nginx + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: patch-demo-ctr + image: nginx + tolerations: + - effect: NoSchedule + key: dedicated + value: test-team diff --git a/content/fa/examples/application/deployment-retainkeys.yaml b/content/fa/examples/application/deployment-retainkeys.yaml new file mode 100644 index 0000000000000..af63f46d37294 --- /dev/null +++ b/content/fa/examples/application/deployment-retainkeys.yaml @@ -0,0 +1,19 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: retainkeys-demo +spec: + selector: + matchLabels: + app: nginx + strategy: + rollingUpdate: + maxSurge: 30% + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: retainkeys-demo-ctr + image: nginx diff --git a/content/fa/examples/application/deployment-scale.yaml b/content/fa/examples/application/deployment-scale.yaml new file mode 100644 index 0000000000000..838576375ef6f --- /dev/null +++ b/content/fa/examples/application/deployment-scale.yaml @@ -0,0 +1,19 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: nginx-deployment +spec: + selector: + matchLabels: + app: nginx + replicas: 4 # Update the replicas from 2 to 4 + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx:1.16.1 + ports: + - containerPort: 80 diff --git a/content/fa/examples/application/deployment-sidecar.yaml b/content/fa/examples/application/deployment-sidecar.yaml new file mode 100644 index 0000000000000..3f1b841d31ebf --- /dev/null +++ b/content/fa/examples/application/deployment-sidecar.yaml @@ -0,0 +1,34 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: myapp + labels: + app: myapp +spec: + replicas: 1 + selector: + matchLabels: + app: myapp + template: + metadata: + labels: + app: myapp + spec: + containers: + - name: myapp + image: alpine:latest + command: ['sh', '-c', 'while true; do echo "logging" >> /opt/logs.txt; sleep 1; done'] + volumeMounts: + - name: data + mountPath: /opt + initContainers: + - name: logshipper + image: alpine:latest + restartPolicy: Always + command: ['sh', '-c', 'tail -F /opt/logs.txt'] + volumeMounts: + - name: data + mountPath: /opt + volumes: + - name: data + emptyDir: {} \ No newline at end of file diff --git a/content/fa/examples/application/deployment-update.yaml b/content/fa/examples/application/deployment-update.yaml new file mode 100644 index 0000000000000..1c0b9d1ab8a4f --- /dev/null +++ b/content/fa/examples/application/deployment-update.yaml @@ -0,0 +1,19 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: nginx-deployment +spec: + selector: + matchLabels: + app: nginx + replicas: 2 + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx:1.16.1 # Update the version of nginx from 1.14.2 to 1.16.1 + ports: + - containerPort: 80 diff --git a/content/fa/examples/application/deployment.yaml b/content/fa/examples/application/deployment.yaml new file mode 100644 index 0000000000000..dbed8bc72b9fc --- /dev/null +++ b/content/fa/examples/application/deployment.yaml @@ -0,0 +1,19 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: nginx-deployment +spec: + selector: + matchLabels: + app: nginx + replicas: 2 # tells deployment to run 2 pods matching the template + template: + metadata: + labels: + app: nginx + spec: + containers: + - name: nginx + image: nginx:1.14.2 + ports: + - containerPort: 80 diff --git a/content/fa/examples/application/guestbook/frontend-deployment.yaml b/content/fa/examples/application/guestbook/frontend-deployment.yaml new file mode 100644 index 0000000000000..b4639929ad424 --- /dev/null +++ b/content/fa/examples/application/guestbook/frontend-deployment.yaml @@ -0,0 +1,29 @@ +# SOURCE: https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook +apiVersion: apps/v1 +kind: Deployment +metadata: + name: frontend +spec: + replicas: 3 + selector: + matchLabels: + app: guestbook + tier: frontend + template: + metadata: + labels: + app: guestbook + tier: frontend + spec: + containers: + - name: php-redis + image: us-docker.pkg.dev/google-samples/containers/gke/gb-frontend:v5 + env: + - name: GET_HOSTS_FROM + value: "dns" + resources: + requests: + cpu: 100m + memory: 100Mi + ports: + - containerPort: 80 diff --git a/content/fa/examples/application/guestbook/frontend-service.yaml b/content/fa/examples/application/guestbook/frontend-service.yaml new file mode 100644 index 0000000000000..410c6bbaf2950 --- /dev/null +++ b/content/fa/examples/application/guestbook/frontend-service.yaml @@ -0,0 +1,19 @@ +# SOURCE: https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook +apiVersion: v1 +kind: Service +metadata: + name: frontend + labels: + app: guestbook + tier: frontend +spec: + # if your cluster supports it, uncomment the following to automatically create + # an external load-balanced IP for the frontend service. + # type: LoadBalancer + #type: LoadBalancer + ports: + # the port that this service should serve on + - port: 80 + selector: + app: guestbook + tier: frontend \ No newline at end of file diff --git a/content/fa/examples/application/guestbook/redis-follower-deployment.yaml b/content/fa/examples/application/guestbook/redis-follower-deployment.yaml new file mode 100644 index 0000000000000..c32a16e46c879 --- /dev/null +++ b/content/fa/examples/application/guestbook/redis-follower-deployment.yaml @@ -0,0 +1,30 @@ +# SOURCE: https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook +apiVersion: apps/v1 +kind: Deployment +metadata: + name: redis-follower + labels: + app: redis + role: follower + tier: backend +spec: + replicas: 2 + selector: + matchLabels: + app: redis + template: + metadata: + labels: + app: redis + role: follower + tier: backend + spec: + containers: + - name: follower + image: us-docker.pkg.dev/google-samples/containers/gke/gb-redis-follower:v2 + resources: + requests: + cpu: 100m + memory: 100Mi + ports: + - containerPort: 6379 \ No newline at end of file diff --git a/content/fa/examples/application/guestbook/redis-follower-service.yaml b/content/fa/examples/application/guestbook/redis-follower-service.yaml new file mode 100644 index 0000000000000..53283d35c423e --- /dev/null +++ b/content/fa/examples/application/guestbook/redis-follower-service.yaml @@ -0,0 +1,17 @@ +# SOURCE: https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook +apiVersion: v1 +kind: Service +metadata: + name: redis-follower + labels: + app: redis + role: follower + tier: backend +spec: + ports: + # the port that this service should serve on + - port: 6379 + selector: + app: redis + role: follower + tier: backend \ No newline at end of file diff --git a/content/fa/examples/application/guestbook/redis-leader-deployment.yaml b/content/fa/examples/application/guestbook/redis-leader-deployment.yaml new file mode 100644 index 0000000000000..9c7547291c376 --- /dev/null +++ b/content/fa/examples/application/guestbook/redis-leader-deployment.yaml @@ -0,0 +1,30 @@ +# SOURCE: https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook +apiVersion: apps/v1 +kind: Deployment +metadata: + name: redis-leader + labels: + app: redis + role: leader + tier: backend +spec: + replicas: 1 + selector: + matchLabels: + app: redis + template: + metadata: + labels: + app: redis + role: leader + tier: backend + spec: + containers: + - name: leader + image: "docker.io/redis:6.0.5" + resources: + requests: + cpu: 100m + memory: 100Mi + ports: + - containerPort: 6379 \ No newline at end of file diff --git a/content/fa/examples/application/guestbook/redis-leader-service.yaml b/content/fa/examples/application/guestbook/redis-leader-service.yaml new file mode 100644 index 0000000000000..e04cc183d09bf --- /dev/null +++ b/content/fa/examples/application/guestbook/redis-leader-service.yaml @@ -0,0 +1,17 @@ +# SOURCE: https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook +apiVersion: v1 +kind: Service +metadata: + name: redis-leader + labels: + app: redis + role: leader + tier: backend +spec: + ports: + - port: 6379 + targetPort: 6379 + selector: + app: redis + role: leader + tier: backend \ No newline at end of file diff --git a/content/fa/examples/application/hpa/php-apache.yaml b/content/fa/examples/application/hpa/php-apache.yaml new file mode 100644 index 0000000000000..1c49aca6a1ff5 --- /dev/null +++ b/content/fa/examples/application/hpa/php-apache.yaml @@ -0,0 +1,18 @@ +apiVersion: autoscaling/v2 +kind: HorizontalPodAutoscaler +metadata: + name: php-apache +spec: + scaleTargetRef: + apiVersion: apps/v1 + kind: Deployment + name: php-apache + minReplicas: 1 + maxReplicas: 10 + metrics: + - type: Resource + resource: + name: cpu + target: + type: Utilization + averageUtilization: 50 diff --git a/content/fa/examples/application/job/cronjob.yaml b/content/fa/examples/application/job/cronjob.yaml new file mode 100644 index 0000000000000..78d0e2d314792 --- /dev/null +++ b/content/fa/examples/application/job/cronjob.yaml @@ -0,0 +1,19 @@ +apiVersion: batch/v1 +kind: CronJob +metadata: + name: hello +spec: + schedule: "* * * * *" + jobTemplate: + spec: + template: + spec: + containers: + - name: hello + image: busybox:1.28 + imagePullPolicy: IfNotPresent + command: + - /bin/sh + - -c + - date; echo Hello from the Kubernetes cluster + restartPolicy: OnFailure diff --git a/content/fa/examples/application/job/indexed-job-vol.yaml b/content/fa/examples/application/job/indexed-job-vol.yaml new file mode 100644 index 0000000000000..ed40e1cc44606 --- /dev/null +++ b/content/fa/examples/application/job/indexed-job-vol.yaml @@ -0,0 +1,27 @@ +apiVersion: batch/v1 +kind: Job +metadata: + name: 'indexed-job' +spec: + completions: 5 + parallelism: 3 + completionMode: Indexed + template: + spec: + restartPolicy: Never + containers: + - name: 'worker' + image: 'docker.io/library/busybox' + command: + - "rev" + - "/input/data.txt" + volumeMounts: + - mountPath: /input + name: input + volumes: + - name: input + downwardAPI: + items: + - path: "data.txt" + fieldRef: + fieldPath: metadata.annotations['batch.kubernetes.io/job-completion-index'] \ No newline at end of file diff --git a/content/fa/examples/application/job/indexed-job.yaml b/content/fa/examples/application/job/indexed-job.yaml new file mode 100644 index 0000000000000..5b80d3526491f --- /dev/null +++ b/content/fa/examples/application/job/indexed-job.yaml @@ -0,0 +1,35 @@ +apiVersion: batch/v1 +kind: Job +metadata: + name: 'indexed-job' +spec: + completions: 5 + parallelism: 3 + completionMode: Indexed + template: + spec: + restartPolicy: Never + initContainers: + - name: 'input' + image: 'docker.io/library/bash' + command: + - "bash" + - "-c" + - | + items=(foo bar baz qux xyz) + echo ${items[$JOB_COMPLETION_INDEX]} > /input/data.txt + volumeMounts: + - mountPath: /input + name: input + containers: + - name: 'worker' + image: 'docker.io/library/busybox' + command: + - "rev" + - "/input/data.txt" + volumeMounts: + - mountPath: /input + name: input + volumes: + - name: input + emptyDir: {} diff --git a/content/fa/examples/application/job/job-sidecar.yaml b/content/fa/examples/application/job/job-sidecar.yaml new file mode 100644 index 0000000000000..9787ad88515b2 --- /dev/null +++ b/content/fa/examples/application/job/job-sidecar.yaml @@ -0,0 +1,26 @@ +apiVersion: batch/v1 +kind: Job +metadata: + name: myjob +spec: + template: + spec: + containers: + - name: myjob + image: alpine:latest + command: ['sh', '-c', 'echo "logging" > /opt/logs.txt'] + volumeMounts: + - name: data + mountPath: /opt + initContainers: + - name: logshipper + image: alpine:latest + restartPolicy: Always + command: ['sh', '-c', 'tail -F /opt/logs.txt'] + volumeMounts: + - name: data + mountPath: /opt + restartPolicy: Never + volumes: + - name: data + emptyDir: {} \ No newline at end of file diff --git a/content/fa/examples/application/job/job-tmpl.yaml b/content/fa/examples/application/job/job-tmpl.yaml new file mode 100644 index 0000000000000..d7dbbafd62bc5 --- /dev/null +++ b/content/fa/examples/application/job/job-tmpl.yaml @@ -0,0 +1,18 @@ +apiVersion: batch/v1 +kind: Job +metadata: + name: process-item-$ITEM + labels: + jobgroup: jobexample +spec: + template: + metadata: + name: jobexample + labels: + jobgroup: jobexample + spec: + containers: + - name: c + image: busybox:1.28 + command: ["sh", "-c", "echo Processing item $ITEM && sleep 5"] + restartPolicy: Never diff --git a/content/fa/examples/application/job/rabbitmq/Dockerfile b/content/fa/examples/application/job/rabbitmq/Dockerfile new file mode 100644 index 0000000000000..50faab23f439c --- /dev/null +++ b/content/fa/examples/application/job/rabbitmq/Dockerfile @@ -0,0 +1,10 @@ +# Specify BROKER_URL and QUEUE when running +FROM ubuntu:18.04 + +RUN apt-get update && \ + apt-get install -y curl ca-certificates amqp-tools python \ + --no-install-recommends \ + && rm -rf /var/lib/apt/lists/* +COPY ./worker.py /worker.py + +CMD /usr/bin/amqp-consume --url=$BROKER_URL -q $QUEUE -c 1 /worker.py diff --git a/content/fa/examples/application/job/rabbitmq/job.yaml b/content/fa/examples/application/job/rabbitmq/job.yaml new file mode 100644 index 0000000000000..4e1a61892be6b --- /dev/null +++ b/content/fa/examples/application/job/rabbitmq/job.yaml @@ -0,0 +1,20 @@ +apiVersion: batch/v1 +kind: Job +metadata: + name: job-wq-1 +spec: + completions: 8 + parallelism: 2 + template: + metadata: + name: job-wq-1 + spec: + containers: + - name: c + image: gcr.io//job-wq-1 + env: + - name: BROKER_URL + value: amqp://guest:guest@rabbitmq-service:5672 + - name: QUEUE + value: job1 + restartPolicy: OnFailure diff --git a/content/fa/examples/application/job/rabbitmq/rabbitmq-service.yaml b/content/fa/examples/application/job/rabbitmq/rabbitmq-service.yaml new file mode 100644 index 0000000000000..2f7fb06dcfed6 --- /dev/null +++ b/content/fa/examples/application/job/rabbitmq/rabbitmq-service.yaml @@ -0,0 +1,12 @@ +apiVersion: v1 +kind: Service +metadata: + labels: + component: rabbitmq + name: rabbitmq-service +spec: + ports: + - port: 5672 + selector: + app.kubernetes.io/name: task-queue + app.kubernetes.io/component: rabbitmq diff --git a/content/fa/examples/application/job/rabbitmq/rabbitmq-statefulset.yaml b/content/fa/examples/application/job/rabbitmq/rabbitmq-statefulset.yaml new file mode 100644 index 0000000000000..502598ddf947e --- /dev/null +++ b/content/fa/examples/application/job/rabbitmq/rabbitmq-statefulset.yaml @@ -0,0 +1,36 @@ +apiVersion: apps/v1 +kind: StatefulSet +metadata: + labels: + component: rabbitmq + name: rabbitmq +spec: + replicas: 1 + serviceName: rabbitmq-service + selector: + matchLabels: + app.kubernetes.io/name: task-queue + app.kubernetes.io/component: rabbitmq + template: + metadata: + labels: + app.kubernetes.io/name: task-queue + app.kubernetes.io/component: rabbitmq + spec: + containers: + - image: rabbitmq + name: rabbitmq + ports: + - containerPort: 5672 + resources: + requests: + memory: 16M + limits: + cpu: 250m + memory: 512M + volumeMounts: + - mountPath: /var/lib/rabbitmq + name: rabbitmq-data + volumes: + - name: rabbitmq-data + emptyDir: {} diff --git a/content/fa/examples/application/job/rabbitmq/worker.py b/content/fa/examples/application/job/rabbitmq/worker.py new file mode 100644 index 0000000000000..88a7fcf96d91a --- /dev/null +++ b/content/fa/examples/application/job/rabbitmq/worker.py @@ -0,0 +1,7 @@ +#!/usr/bin/env python + +# Just prints standard out and sleeps for 10 seconds. +import sys +import time +print("Processing " + sys.stdin.readlines()[0]) +time.sleep(10) diff --git a/content/fa/examples/application/job/redis/Dockerfile b/content/fa/examples/application/job/redis/Dockerfile new file mode 100644 index 0000000000000..2de23b3c98340 --- /dev/null +++ b/content/fa/examples/application/job/redis/Dockerfile @@ -0,0 +1,6 @@ +FROM python +RUN pip install redis +COPY ./worker.py /worker.py +COPY ./rediswq.py /rediswq.py + +CMD python worker.py diff --git a/content/fa/examples/application/job/redis/job.yaml b/content/fa/examples/application/job/redis/job.yaml new file mode 100644 index 0000000000000..ee7a06c732986 --- /dev/null +++ b/content/fa/examples/application/job/redis/job.yaml @@ -0,0 +1,14 @@ +apiVersion: batch/v1 +kind: Job +metadata: + name: job-wq-2 +spec: + parallelism: 2 + template: + metadata: + name: job-wq-2 + spec: + containers: + - name: c + image: gcr.io/myproject/job-wq-2 + restartPolicy: OnFailure diff --git a/content/fa/examples/application/job/redis/redis-pod.yaml b/content/fa/examples/application/job/redis/redis-pod.yaml new file mode 100644 index 0000000000000..ae0c43a793570 --- /dev/null +++ b/content/fa/examples/application/job/redis/redis-pod.yaml @@ -0,0 +1,15 @@ +apiVersion: v1 +kind: Pod +metadata: + name: redis-master + labels: + app: redis +spec: + containers: + - name: master + image: redis + env: + - name: MASTER + value: "true" + ports: + - containerPort: 6379 diff --git a/content/fa/examples/application/job/redis/redis-service.yaml b/content/fa/examples/application/job/redis/redis-service.yaml new file mode 100644 index 0000000000000..85f2ca2271d0b --- /dev/null +++ b/content/fa/examples/application/job/redis/redis-service.yaml @@ -0,0 +1,10 @@ +apiVersion: v1 +kind: Service +metadata: + name: redis +spec: + ports: + - port: 6379 + targetPort: 6379 + selector: + app: redis diff --git a/content/fa/examples/application/job/redis/rediswq.py b/content/fa/examples/application/job/redis/rediswq.py new file mode 100644 index 0000000000000..2b8e81ceab79d --- /dev/null +++ b/content/fa/examples/application/job/redis/rediswq.py @@ -0,0 +1,130 @@ +#!/usr/bin/env python + +# Based on http://peter-hoffmann.com/2012/python-simple-queue-redis-queue.html +# and the suggestion in the redis documentation for RPOPLPUSH, at +# http://redis.io/commands/rpoplpush, which suggests how to implement a work-queue. + + +import redis +import uuid +import hashlib + +class RedisWQ(object): + """Simple Finite Work Queue with Redis Backend + + This work queue is finite: as long as no more work is added + after workers start, the workers can detect when the queue + is completely empty. + + The items in the work queue are assumed to have unique values. + + This object is not intended to be used by multiple threads + concurrently. + """ + def __init__(self, name, **redis_kwargs): + """The default connection parameters are: host='localhost', port=6379, db=0 + + The work queue is identified by "name". The library may create other + keys with "name" as a prefix. + """ + self._db = redis.StrictRedis(**redis_kwargs) + # The session ID will uniquely identify this "worker". + self._session = str(uuid.uuid4()) + # Work queue is implemented as two queues: main, and processing. + # Work is initially in main, and moved to processing when a client picks it up. + self._main_q_key = name + self._processing_q_key = name + ":processing" + self._lease_key_prefix = name + ":leased_by_session:" + + def sessionID(self): + """Return the ID for this session.""" + return self._session + + def _main_qsize(self): + """Return the size of the main queue.""" + return self._db.llen(self._main_q_key) + + def _processing_qsize(self): + """Return the size of the main queue.""" + return self._db.llen(self._processing_q_key) + + def empty(self): + """Return True if the queue is empty, including work being done, False otherwise. + + False does not necessarily mean that there is work available to work on right now, + """ + return self._main_qsize() == 0 and self._processing_qsize() == 0 + +# TODO: implement this +# def check_expired_leases(self): +# """Return to the work queueReturn True if the queue is empty, False otherwise.""" +# # Processing list should not be _too_ long since it is approximately as long +# # as the number of active and recently active workers. +# processing = self._db.lrange(self._processing_q_key, 0, -1) +# for item in processing: +# # If the lease key is not present for an item (it expired or was +# # never created because the client crashed before creating it) +# # then move the item back to the main queue so others can work on it. +# if not self._lease_exists(item): +# TODO: transactionally move the key from processing queue to +# to main queue, while detecting if a new lease is created +# or if either queue is modified. + + def _itemkey(self, item): + """Returns a string that uniquely identifies an item (bytes).""" + return hashlib.sha224(item).hexdigest() + + def _lease_exists(self, item): + """True if a lease on 'item' exists.""" + return self._db.exists(self._lease_key_prefix + self._itemkey(item)) + + def lease(self, lease_secs=60, block=True, timeout=None): + """Begin working on an item the work queue. + + Lease the item for lease_secs. After that time, other + workers may consider this client to have crashed or stalled + and pick up the item instead. + + If optional args block is true and timeout is None (the default), block + if necessary until an item is available.""" + if block: + item = self._db.brpoplpush(self._main_q_key, self._processing_q_key, timeout=timeout) + else: + item = self._db.rpoplpush(self._main_q_key, self._processing_q_key) + if item: + # Record that we (this session id) are working on a key. Expire that + # note after the lease timeout. + # Note: if we crash at this line of the program, then GC will see no lease + # for this item a later return it to the main queue. + itemkey = self._itemkey(item) + self._db.setex(self._lease_key_prefix + itemkey, lease_secs, self._session) + return item + + def complete(self, value): + """Complete working on the item with 'value'. + + If the lease expired, the item may not have completed, and some + other worker may have picked it up. There is no indication + of what happened. + """ + self._db.lrem(self._processing_q_key, 0, value) + # If we crash here, then the GC code will try to move the value, but it will + # not be here, which is fine. So this does not need to be a transaction. + itemkey = self._itemkey(value) + self._db.delete(self._lease_key_prefix + itemkey) + +# TODO: add functions to clean up all keys associated with "name" when +# processing is complete. + +# TODO: add a function to add an item to the queue. Atomically +# check if the queue is empty and if so fail to add the item +# since other workers might think work is done and be in the process +# of exiting. + +# TODO(etune): move to my own github for hosting, e.g. github.com/erictune/rediswq-py and +# make it so it can be pip installed by anyone (see +# http://stackoverflow.com/questions/8247605/configuring-so-that-pip-install-can-work-from-github) + +# TODO(etune): finish code to GC expired leases, and call periodically +# e.g. each time lease times out. + diff --git a/content/fa/examples/application/job/redis/worker.py b/content/fa/examples/application/job/redis/worker.py new file mode 100644 index 0000000000000..c3523a4e21a48 --- /dev/null +++ b/content/fa/examples/application/job/redis/worker.py @@ -0,0 +1,23 @@ +#!/usr/bin/env python + +import time +import rediswq + +host="redis" +# Uncomment next two lines if you do not have Kube-DNS working. +# import os +# host = os.getenv("REDIS_SERVICE_HOST") + +q = rediswq.RedisWQ(name="job2", host=host) +print("Worker with sessionID: " + q.sessionID()) +print("Initial queue state: empty=" + str(q.empty())) +while not q.empty(): + item = q.lease(lease_secs=10, block=True, timeout=2) + if item is not None: + itemstr = item.decode("utf-8") + print("Working on " + itemstr) + time.sleep(10) # Put your actual work here instead of sleep. + q.complete(item) + else: + print("Waiting for work") +print("Queue empty, exiting") diff --git a/content/fa/examples/application/mongodb/mongo-deployment.yaml b/content/fa/examples/application/mongodb/mongo-deployment.yaml new file mode 100644 index 0000000000000..04908ce25b1dc --- /dev/null +++ b/content/fa/examples/application/mongodb/mongo-deployment.yaml @@ -0,0 +1,31 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: mongo + labels: + app.kubernetes.io/name: mongo + app.kubernetes.io/component: backend +spec: + selector: + matchLabels: + app.kubernetes.io/name: mongo + app.kubernetes.io/component: backend + replicas: 1 + template: + metadata: + labels: + app.kubernetes.io/name: mongo + app.kubernetes.io/component: backend + spec: + containers: + - name: mongo + image: mongo:4.2 + args: + - --bind_ip + - 0.0.0.0 + resources: + requests: + cpu: 100m + memory: 100Mi + ports: + - containerPort: 27017 diff --git a/content/fa/examples/application/mongodb/mongo-service.yaml b/content/fa/examples/application/mongodb/mongo-service.yaml new file mode 100644 index 0000000000000..b9cef607bcf79 --- /dev/null +++ b/content/fa/examples/application/mongodb/mongo-service.yaml @@ -0,0 +1,14 @@ +apiVersion: v1 +kind: Service +metadata: + name: mongo + labels: + app.kubernetes.io/name: mongo + app.kubernetes.io/component: backend +spec: + ports: + - port: 27017 + targetPort: 27017 + selector: + app.kubernetes.io/name: mongo + app.kubernetes.io/component: backend diff --git a/content/fa/examples/application/mysql/mysql-configmap.yaml b/content/fa/examples/application/mysql/mysql-configmap.yaml new file mode 100644 index 0000000000000..9adb0344a31a6 --- /dev/null +++ b/content/fa/examples/application/mysql/mysql-configmap.yaml @@ -0,0 +1,17 @@ +apiVersion: v1 +kind: ConfigMap +metadata: + name: mysql + labels: + app: mysql + app.kubernetes.io/name: mysql +data: + primary.cnf: | + # Apply this config only on the primary. + [mysqld] + log-bin + replica.cnf: | + # Apply this config only on replicas. + [mysqld] + super-read-only + diff --git a/content/fa/examples/application/mysql/mysql-deployment.yaml b/content/fa/examples/application/mysql/mysql-deployment.yaml new file mode 100644 index 0000000000000..4630b4d84abe9 --- /dev/null +++ b/content/fa/examples/application/mysql/mysql-deployment.yaml @@ -0,0 +1,43 @@ +apiVersion: v1 +kind: Service +metadata: + name: mysql +spec: + ports: + - port: 3306 + selector: + app: mysql + clusterIP: None +--- +apiVersion: apps/v1 +kind: Deployment +metadata: + name: mysql +spec: + selector: + matchLabels: + app: mysql + strategy: + type: Recreate + template: + metadata: + labels: + app: mysql + spec: + containers: + - image: mysql:9 + name: mysql + env: + # Use secret in real usage + - name: MYSQL_ROOT_PASSWORD + value: password + ports: + - containerPort: 3306 + name: mysql + volumeMounts: + - name: mysql-persistent-storage + mountPath: /var/lib/mysql + volumes: + - name: mysql-persistent-storage + persistentVolumeClaim: + claimName: mysql-pv-claim diff --git a/content/fa/examples/application/mysql/mysql-pv.yaml b/content/fa/examples/application/mysql/mysql-pv.yaml new file mode 100644 index 0000000000000..c89779a83fd23 --- /dev/null +++ b/content/fa/examples/application/mysql/mysql-pv.yaml @@ -0,0 +1,26 @@ +apiVersion: v1 +kind: PersistentVolume +metadata: + name: mysql-pv-volume + labels: + type: local +spec: + storageClassName: manual + capacity: + storage: 20Gi + accessModes: + - ReadWriteOnce + hostPath: + path: "/mnt/data" +--- +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: mysql-pv-claim +spec: + storageClassName: manual + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 20Gi diff --git a/content/fa/examples/application/mysql/mysql-services.yaml b/content/fa/examples/application/mysql/mysql-services.yaml new file mode 100644 index 0000000000000..bc015066780c3 --- /dev/null +++ b/content/fa/examples/application/mysql/mysql-services.yaml @@ -0,0 +1,32 @@ +# Headless service for stable DNS entries of StatefulSet members. +apiVersion: v1 +kind: Service +metadata: + name: mysql + labels: + app: mysql + app.kubernetes.io/name: mysql +spec: + ports: + - name: mysql + port: 3306 + clusterIP: None + selector: + app: mysql +--- +# Client service for connecting to any MySQL instance for reads. +# For writes, you must instead connect to the primary: mysql-0.mysql. +apiVersion: v1 +kind: Service +metadata: + name: mysql-read + labels: + app: mysql + app.kubernetes.io/name: mysql + readonly: "true" +spec: + ports: + - name: mysql + port: 3306 + selector: + app: mysql diff --git a/content/fa/examples/application/mysql/mysql-statefulset.yaml b/content/fa/examples/application/mysql/mysql-statefulset.yaml new file mode 100644 index 0000000000000..67755dbb9e830 --- /dev/null +++ b/content/fa/examples/application/mysql/mysql-statefulset.yaml @@ -0,0 +1,168 @@ +apiVersion: apps/v1 +kind: StatefulSet +metadata: + name: mysql +spec: + selector: + matchLabels: + app: mysql + app.kubernetes.io/name: mysql + serviceName: mysql + replicas: 3 + template: + metadata: + labels: + app: mysql + app.kubernetes.io/name: mysql + spec: + initContainers: + - name: init-mysql + image: mysql:5.7 + command: + - bash + - "-c" + - | + set -ex + # Generate mysql server-id from pod ordinal index. + [[ $HOSTNAME =~ -([0-9]+)$ ]] || exit 1 + ordinal=${BASH_REMATCH[1]} + echo [mysqld] > /mnt/conf.d/server-id.cnf + # Add an offset to avoid reserved server-id=0 value. + echo server-id=$((100 + $ordinal)) >> /mnt/conf.d/server-id.cnf + # Copy appropriate conf.d files from config-map to emptyDir. + if [[ $ordinal -eq 0 ]]; then + cp /mnt/config-map/primary.cnf /mnt/conf.d/ + else + cp /mnt/config-map/replica.cnf /mnt/conf.d/ + fi + volumeMounts: + - name: conf + mountPath: /mnt/conf.d + - name: config-map + mountPath: /mnt/config-map + - name: clone-mysql + image: gcr.io/google-samples/xtrabackup:1.0 + command: + - bash + - "-c" + - | + set -ex + # Skip the clone if data already exists. + [[ -d /var/lib/mysql/mysql ]] && exit 0 + # Skip the clone on primary (ordinal index 0). + [[ `hostname` =~ -([0-9]+)$ ]] || exit 1 + ordinal=${BASH_REMATCH[1]} + [[ $ordinal -eq 0 ]] && exit 0 + # Clone data from previous peer. + ncat --recv-only mysql-$(($ordinal-1)).mysql 3307 | xbstream -x -C /var/lib/mysql + # Prepare the backup. + xtrabackup --prepare --target-dir=/var/lib/mysql + volumeMounts: + - name: data + mountPath: /var/lib/mysql + subPath: mysql + - name: conf + mountPath: /etc/mysql/conf.d + containers: + - name: mysql + image: mysql:5.7 + env: + - name: MYSQL_ALLOW_EMPTY_PASSWORD + value: "1" + ports: + - name: mysql + containerPort: 3306 + volumeMounts: + - name: data + mountPath: /var/lib/mysql + subPath: mysql + - name: conf + mountPath: /etc/mysql/conf.d + resources: + requests: + cpu: 500m + memory: 1Gi + livenessProbe: + exec: + command: ["mysqladmin", "ping"] + initialDelaySeconds: 30 + periodSeconds: 10 + timeoutSeconds: 5 + readinessProbe: + exec: + # Check we can execute queries over TCP (skip-networking is off). + command: ["mysql", "-h", "127.0.0.1", "-e", "SELECT 1"] + initialDelaySeconds: 5 + periodSeconds: 2 + timeoutSeconds: 1 + - name: xtrabackup + image: gcr.io/google-samples/xtrabackup:1.0 + ports: + - name: xtrabackup + containerPort: 3307 + command: + - bash + - "-c" + - | + set -ex + cd /var/lib/mysql + + # Determine binlog position of cloned data, if any. + if [[ -f xtrabackup_slave_info && "x$( change_master_to.sql.in + # Ignore xtrabackup_binlog_info in this case (it's useless). + rm -f xtrabackup_slave_info xtrabackup_binlog_info + elif [[ -f xtrabackup_binlog_info ]]; then + # We're cloning directly from primary. Parse binlog position. + [[ `cat xtrabackup_binlog_info` =~ ^(.*?)[[:space:]]+(.*?)$ ]] || exit 1 + rm -f xtrabackup_binlog_info xtrabackup_slave_info + echo "CHANGE MASTER TO MASTER_LOG_FILE='${BASH_REMATCH[1]}',\ + MASTER_LOG_POS=${BASH_REMATCH[2]}" > change_master_to.sql.in + fi + + # Check if we need to complete a clone by starting replication. + if [[ -f change_master_to.sql.in ]]; then + echo "Waiting for mysqld to be ready (accepting connections)" + until mysql -h 127.0.0.1 -e "SELECT 1"; do sleep 1; done + + echo "Initializing replication from clone position" + mysql -h 127.0.0.1 \ + -e "$(&2 ; i=$((i+1)); sleep 1; done'] diff --git a/content/fa/examples/debug/counter-pod.yaml b/content/fa/examples/debug/counter-pod.yaml new file mode 100644 index 0000000000000..a91b2f8915830 --- /dev/null +++ b/content/fa/examples/debug/counter-pod.yaml @@ -0,0 +1,10 @@ +apiVersion: v1 +kind: Pod +metadata: + name: counter +spec: + containers: + - name: count + image: busybox:1.28 + args: [/bin/sh, -c, + 'i=0; while true; do echo "$i: $(date)"; i=$((i+1)); sleep 1; done'] diff --git a/content/fa/examples/debug/event-exporter.yaml b/content/fa/examples/debug/event-exporter.yaml new file mode 100644 index 0000000000000..7d2fe2791ac9a --- /dev/null +++ b/content/fa/examples/debug/event-exporter.yaml @@ -0,0 +1,47 @@ +apiVersion: v1 +kind: ServiceAccount +metadata: + name: event-exporter-sa + namespace: default + labels: + app: event-exporter +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRoleBinding +metadata: + name: event-exporter-rb + labels: + app: event-exporter +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: view +subjects: +- kind: ServiceAccount + name: event-exporter-sa + namespace: default +--- +apiVersion: apps/v1 +kind: Deployment +metadata: + name: event-exporter-v0.2.3 + namespace: default + labels: + app: event-exporter +spec: + selector: + matchLabels: + app: event-exporter + replicas: 1 + template: + metadata: + labels: + app: event-exporter + spec: + serviceAccountName: event-exporter-sa + containers: + - name: event-exporter + image: registry.k8s.io/event-exporter:v0.2.3 + command: + - '/event-exporter' + terminationGracePeriodSeconds: 30 diff --git a/content/fa/examples/debug/fluentd-gcp-configmap.yaml b/content/fa/examples/debug/fluentd-gcp-configmap.yaml new file mode 100644 index 0000000000000..4abdbc8b910f3 --- /dev/null +++ b/content/fa/examples/debug/fluentd-gcp-configmap.yaml @@ -0,0 +1,379 @@ +apiVersion: v1 +kind: ConfigMap +data: + containers.input.conf: |- + # This configuration file for Fluentd is used + # to watch changes to Docker log files that live in the + # directory /var/lib/docker/containers/ and are symbolically + # linked to from the /var/log/containers directory using names that capture the + # pod name and container name. These logs are then submitted to + # Google Cloud Logging which assumes the installation of the cloud-logging plug-in. + # + # Example + # ======= + # A line in the Docker log file might look like this JSON: + # + # {"log":"2014/09/25 21:15:03 Got request with path wombat\\n", + # "stream":"stderr", + # "time":"2014-09-25T21:15:03.499185026Z"} + # + # The record reformer is used to write the tag to focus on the pod name + # and the Kubernetes container name. For example a Docker container's logs + # might be in the directory: + # /var/lib/docker/containers/997599971ee6366d4a5920d25b79286ad45ff37a74494f262e3bc98d909d0a7b + # and in the file: + # 997599971ee6366d4a5920d25b79286ad45ff37a74494f262e3bc98d909d0a7b-json.log + # where 997599971ee6... is the Docker ID of the running container. + # The Kubernetes kubelet makes a symbolic link to this file on the host machine + # in the /var/log/containers directory which includes the pod name and the Kubernetes + # container name: + # synthetic-logger-0.25lps-pod_default-synth-lgr-997599971ee6366d4a5920d25b79286ad45ff37a74494f262e3bc98d909d0a7b.log + # -> + # /var/lib/docker/containers/997599971ee6366d4a5920d25b79286ad45ff37a74494f262e3bc98d909d0a7b/997599971ee6366d4a5920d25b79286ad45ff37a74494f262e3bc98d909d0a7b-json.log + # The /var/log directory on the host is mapped to the /var/log directory in the container + # running this instance of Fluentd and we end up collecting the file: + # /var/log/containers/synthetic-logger-0.25lps-pod_default-synth-lgr-997599971ee6366d4a5920d25b79286ad45ff37a74494f262e3bc98d909d0a7b.log + # This results in the tag: + # var.log.containers.synthetic-logger-0.25lps-pod_default-synth-lgr-997599971ee6366d4a5920d25b79286ad45ff37a74494f262e3bc98d909d0a7b.log + # The record reformer is used is discard the var.log.containers prefix and + # the Docker container ID suffix and "kubernetes." is pre-pended giving the tag: + # kubernetes.synthetic-logger-0.25lps-pod_default-synth-lgr + # Tag is then parsed by google_cloud plugin and translated to the metadata, + # visible in the log viewer + + # Example: + # {"log":"[info:2016-02-16T16:04:05.930-08:00] Some log text here\n","stream":"stdout","time":"2016-02-17T00:04:05.931087621Z"} + + type tail + format json + time_key time + path /var/log/containers/*.log + pos_file /var/log/gcp-containers.log.pos + time_format %Y-%m-%dT%H:%M:%S.%N%Z + tag reform.* + read_from_head true + + + + type parser + format /^(?\w)(? + + + type record_reformer + enable_ruby true + tag raw.kubernetes.${tag_suffix[4].split('-')[0..-2].join('-')} + + + # Detect exceptions in the log output and forward them as one log entry. + + @type copy + + + @type prometheus + + + type counter + name logging_line_count + desc Total number of lines generated by application containers + + tag ${tag} + + + + + @type detect_exceptions + + remove_tag_prefix raw + message log + stream stream + multiline_flush_interval 5 + max_bytes 500000 + max_lines 1000 + + + system.input.conf: |- + # Example: + # Dec 21 23:17:22 gke-foo-1-1-4b5cbd14-node-4eoj startupscript: Finished running startup script /var/run/google.startup.script + + type tail + format syslog + path /var/log/startupscript.log + pos_file /var/log/gcp-startupscript.log.pos + tag startupscript + + + # Examples: + # time="2016-02-04T06:51:03.053580605Z" level=info msg="GET /containers/json" + # time="2016-02-04T07:53:57.505612354Z" level=error msg="HTTP Error" err="No such image: -f" statusCode=404 + + type tail + format /^time="(?