این حالت نمایش چند صفحه ای قابل پرینت این قسمت می‌باشد. برای پرینت کلیک کنید..

بازگشت به حالت نمایش عادی این قسمت.

انتشارها

پروژه کوبرنتیز شاخه‌های انتشار (release branches) را برای سه نسخه جزئی (minor) اخیر نگهداری می‌کند. (1.33, 1.32, 1.31). کوبرنتیز 1.19 و نسخه های جدید تر ان تقریباً ۱ سال پشتیبانی patch دارند. نسخه‌های 1.18 و قدیمی‌تر کوبرنتیز تقریباً به‌مدت ۹ ماه پشتیبانی اصلاحی (patch support) دریافت می‌کردند.

نسخه‌های کوبرنتیز به‌صورت زیر بیان می‌شوند: x.y.z, که در آن x نسخه اصلی (major version)، y نسخه فرعی (minor version)، و z نسخه اصلاحی (patch version) است. که از اصطلاحات نسخه‌بندی معنایی پیروی می‌کند. سیاست ناسازگاری نسخه‌ها اطلاعات بیشتر در سند سیاست ناسازگاری نسخه‌ها موجود است.

تاریخچه انتشار

1.33

Latest Release:1.33.4 (released: )
End of Life:
Patch Releases: 1.33.1, 1.33.2, 1.33.3, 1.33.4

Complete 1.33 Schedule and Changelog

1.32

Latest Release:1.32.8 (released: )
End of Life:

Complete 1.32 Schedule and Changelog

1.31

Latest Release:1.31.12 (released: )
End of Life:

Complete 1.31 Schedule and Changelog

انتشار آینده

نگاهی بیندازید به برنامه ریزی برای انتشار نسخه بعدی 1.34 کوبرنتیز!

منابع مفید

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

1 - انتشارات وصله (patch)

اطلاعات تماس و زمان‌بندی تیم برای انتشار وصله‌(patch)های کوبرنتیز. برای اطلاعات کلی در مورد چرخه انتشار کوبرنتیز، به شرح فرآیند انتشار مراجعه کنید.

ریتم

ریتم انتشار وصله(patch) ما معمولاً ماهانه است. معمولاً برای اولین انتشارهای وصله (patch) کمی سریع‌تر (۱ تا ۲ هفته) پس از انتشار جزئی 1.X است. رفع اشکالات بحرانی ممکن است باعث انتشار فوری‌تر و خارج از ریتم معمول شود. ما همچنین قصد داریم در دوره‌های تعطیلات مهم، انتشاری نداشته باشیم.

تماس بگیرید

برای اطلاعات کامل تماس با تیم انتشار وصله، به صفحه مدیران انتشار مراجعه کنید.

لطفا یک روز کاری برای پاسخ به ما فرصت دهید - ممکن است منطقه زمانی ما متفاوت باشد!

در فاصله بین انتشار نسخه‌ها، تیم به صورت هفتگی درخواست‌های cherry pick را بررسی می‌کند. این تیم از طریق PR گیت‌هاب، کانال sig در اسلک ،یا پیام به صورت مستقیم در اسلک و یا از طریق ایمیل با ارسال‌کنندگان تماس خواهد گرفت.

Cherry picks

لطفا فرایند cherry pick را دنبال کنید.

cherry-picks باید در گیت‌هاب با برچسب‌های مناسب (مثلاً، آماده ادغام باشند(approved, lgtm, release-note) و قبولی در آزمون‌های CI قبل از مهلت پایانی cherry-picks است. این معمولاً دو روز قبل از انتشار هدف است، اما ممکن است بیشتر هم باشد. آمادگی اولیه برای PR بهتر است، زیرا ما به زمان نیاز داریم تا پس از ادغام cherry pick های شما، قبل از انتشار اصلی، سیگنال CI را دریافت کنیم.

PR های Cherry Pick که معیارهای ادغام را نداشته باشند، به نسخه‌های بعدی منتقل شده و برای انتشار وصله بعدی پیگیری خواهند شد.

دوره پشتیبانی

پشتیبانی سالیانه KEP،مطابق با انجمن کوبرنتیز از انتشار سری‌های فعال وصله‌ها برای مدت تقریبی چهارده (14) ماه پشتیبانی خواهد کرد.

دوازده ماه اول این بازه زمانی، دوره استاندارد در نظر گرفته خواهد شد.

در پایان ماه دوازدهم، موارد زیر اتفاق خواهد افتاد:

  • مدیران انتشار، انتشار را قطع خواهد کرد
  • سری انتشار وصله‌ها(patch) وارد حالت تعمیر و نگهداری خواهد شد.

در طول دوره دو ماهه حالت نگهداری، مدیران انتشار ممکن است انتشارهای نگهداری اضافی را برای حل موارد زیر حذف کنند:

  • آسیب پذیری‌هایی که یک شناسه CVE اختصاص داده شده دارند (طبق توصیه کمیته واکنش امنیتی)
  • مشکلات وابستگی (از جمله به‌روزرسانی‌های base image)
  • مشکلات بحرانی اجزای اصلی

در پایان دوره دو ماهه حالت نگهداری، سری انتشار وصله‌ها به عنوان EOL (پایان عمر) در نظر گرفته می‌شود و Cherry-pick برای شاخه مرتبط به زودی پس از آن بسته می‌شوند.

توجه داشته باشید که بیست و هشتم روز هر ماه برای حالت تعمیر و نگهداری و تاریخ‌های هدف EOL برای سادگی انتخاب شده‌اند (هر ماه این تاریخ را دارد).

انتشارات ماهانه آینده

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

Monthly Patch Release Cherry Pick Deadline Target Date
سپتامبر 2025
اکتبر 2025
نوامبر 2025

تاریخچه انتشار دقیق برای شاخه‌های فعال

1.33

Next patch release is 1.33.5.

Kubernetes 1.33 enters maintenance mode on ; the End of Life date for Kubernetes 1.33 is .

Patch Release Cherry Pick Deadline Target Date Note
1.33.4
1.33.3
1.33.2
1.33.1

1.32

ℹ️ Kubernetes 1.32 entered maintenance mode on .

The End of Life date for Kubernetes 1.32 is .

Patch Release Cherry Pick Deadline Target Date Note
1.32.8
1.32.7
1.32.6
1.32.5
1.32.4
1.32.3
1.32.2
1.32.1
1.32.0 -

1.31

ℹ️ Kubernetes 1.31 entered maintenance mode on .

The End of Life date for Kubernetes 1.31 is .

Patch Release Cherry Pick Deadline Target Date Note
1.31.12
1.31.11
1.31.10
1.31.9
1.31.8
1.31.7
1.31.6
1.31.5
1.31.4
1.31.3
1.31.2
1.31.1
1.31.0 -

تاریخچه شاخه غیرفعال

این نسخه‌ها دیگر پشتیبانی نمی‌شوند.

Minor Version Final Patch Release End Of Life Date Note
1.30 1.30.14
1.29 1.29.14
1.28 1.28.15
1.27 1.27.16
1.26 1.26.15 1.26.15 was released in March 2024 (after the EOL date) to pick up a new version of Go to address several Go CVEs
1.25 1.25.16 1.25.16 was released in November 2023 (after the EOL date) to fix CVE-2023-5528
1.24 1.24.17 1.24.17 was released in August 2023 (after the EOL date) to fix CVE-2023-3676 and CVE-2023-3955
1.23 1.23.17
1.22 1.22.17 1.22.17 was released in December 2022 (after the EOL date) to backport registry changes and fix two critical issues.
1.21 1.21.14
1.20 1.20.15
1.19 1.19.16
1.18 1.18.20 Created to solve regression introduced in 1.18.19
1.17 1.17.17
1.16 1.16.15
1.15 1.15.12
1.14 1.14.10
1.13 1.13.12
1.12 1.12.10
1.11 1.11.10
1.10 1.10.13
1.9 1.9.11
1.8 1.8.15
1.7 1.7.16
1.6 1.6.13
1.5 1.5.8
1.4 1.4.12
1.3 1.3.10
1.2 1.2.7

2 - دانلود کوبرنتیز

کوبرنتیز باینری‌هایی را برای هر بخش، همراه با مجموعه‌ای استاندارد از برنامه‌های کلاینت برای راه‌اندازی (bootstrap) یا تعامل با یک کلاستر ارائه می‌دهد. بخش‌هایی مانند API Server قابلیت اجرا در قالب ایمیج‌های کانتینری داخل کلاستر را دارند. این بخش‌ها همچنین به‌عنوان بخشی از فرآیند انتشار رسمی، در قالب ایمیج‌های کانتینری نیز عرضه می‌شوند. تمام باینری‌ها و ایمیج‌های کانتینری برای سیستم‌عامل‌ها و معماری‌های سخت‌افزاری مختلف در دسترس هستند.

kubectl

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

شما می‌توانید از kubectl برای استقرار (deploy) برنامه‌ها، بررسی و مدیریت منابع کلاستر، و مشاهده لاگ‌ها استفاده کنید. برای اطلاعات بیشتر، از جمله فهرست کامل عملیات‌های kubectl، به kubectl مستندات مرجع. مراجعه کنید.

ابزار kubectl قابل نصب روی انواع پلتفرم‌های لینوکس، macOS و ویندوز است. سیستم‌عامل مورد نظر خود را از لیست زیر انتخاب کنید.

ایمیج‌های کانتینری

تمام ایمیج‌های کانتینری کوبرنتیز در رجیستری ایمیج کانتینری registry.k8s.io منتشر می‌شوند.

ایمیج‌های کانتینری معماری های قابل پشتیبانی
registry.k8s.io/kube-apiserver:v1.33.0 amd64, arm, arm64, ppc64le, s390x
registry.k8s.io/kube-controller-manager:v1.33.0 amd64, arm, arm64, ppc64le, s390x
registry.k8s.io/kube-proxy:v1.33.0 amd64, arm, arm64, ppc64le, s390x
registry.k8s.io/kube-scheduler:v1.33.0 amd64, arm, arm64, ppc64le, s390x
registry.k8s.io/conformance:v1.33.0 amd64, arm, arm64, ppc64le, s390x

معماری ایمیج‌های کانتینری

تمام ایمیج‌های کانتینری برای معماری‌های مختلف در دسترس هستند، و runtime کانتینر باید بر اساس پلتفرم زیرساختی، ایمیج مناسب را انتخاب کند. همچنین این امکان وجود دارد که یک معماری خاص را به‌طور مستقیم فراخوانی (pull) کنید، با افزودن پسوند به نام ایمیج کانتینر؛ برای مثال: registry.k8s.io/kube-apiserver-arm64:v1.33.0.

امضای ایمیج های کانتینری

FEATURE STATE: Kubernetes v1.26 [beta]

برای کوبرنتیز نسخه v1.33، ایمیج‌های کانتینری با استفاده از امضاهای sigstoreامضا می‌شوند:

پروژه کوبرنتیز فهرستی از ایمیج‌های کانتینری امضاشده کوبرنتیز را در قالب SPDX 2.3 منتشر می‌کند. شما می‌توانید این فهرست را با استفاده از دستور زیر دریافت کنید:

curl -Ls "https://sbom.k8s.io/$(curl -Ls https://dl.k8s.io/release/stable.txt)/release" | grep "SPDXID: SPDXRef-Package-registry.k8s.io" |  grep -v sha256 | cut -d- -f3- | sed 's/-/\//' | sed 's/-v1/:v1/'

برای تأیید دستی ایمیج‌های کانتینری امضاشده بخش‌های اصلی کوبرنتیز، به مطلب تأیید ایمیج‌های کانتینری امضاشده مراجعه کنید. اگر ایمیج کانتینری را برای یک معماری خاص دریافت (pull) کنید، ایمیج تک‌معماری به همان شیوه‌ای که برای لیست‌های مانیفست چندمعماری امضا می‌شود، امضا خواهد شد.

باینری ها

You can find links to download Kubernetes components (and their checksums) in the CHANGELOG files. Alternately, use downloadkubernetes.com to filter by version and architecture.

3 - مدیران انتشار

«مدیران انتشار» یک اصطلاح کلی است که شامل مجموعه‌ای از مشارکت‌کنندگان کوبرنتیز می‌شود که مسئول نگهداری شاخه‌های انتشار و ایجاد نسخه‌ها با استفاده از ابزارهایی هستند که SIG Release ارائه می‌دهد.

مسئولیت‌های هر نقش در ادامه شرح داده شده است.

تماس بگیرید

لیست پستی Slack دید کاربرد عضویت
release-managers@kubernetes.io #release-management (channel) / @release-managers (user group) عمومی بحث عمومی برای مدیران اتشار همه مدیران انتشار (شامل همکاران و روسای SIG)
release-managers-private@kubernetes.io N/A خصوصی خصوصی بحث برای مدیران انتشار ممتاز مدیران انتشار، رهبری انتشار SIG
security-release-team@kubernetes.io #security-release-team (channel) / @security-rel-team (user group) خصوصی هماهنگی انتشار اطلاعات امنیتی با کمیته واکنش امنیتی security-discuss-private@kubernetes.io, release-managers-private@kubernetes.io

سیاست تحریم امنیتی

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

کتاب های راهنما

توجه: کتابچه‌های راهنمای تیم انتشار وصله (patch) و مدیر (branch) در تاریخ دیگری از حالت تکراری خارج خواهند شد.

مدیران انتشار

توجه: مستندات ممکن است به تیم انتشار وصله و نقش مدیریت شاخه اشاره داشته باشد. این دو نقش در نقش مدیران انتشار ادغام شده‌اند.

حداقل الزامات برای مدیران انتشار و همکاران مدیر انتشار عبارتند از:

  • آشنایی با دستورات پایه یونیکس و توانایی اشکال‌زدایی اسکریپت‌های shell
  • آشنایی با گردش‌های کاری کد منبع شاخه‌بندی شده از طریق git و موارد مرتبط فراخوانی‌های خط فرمان git.
  • آشنایی عمومی با فضای ابری گوگل (ساخت فضای ابری و ذخیره‌سازی ابری).
  • پذیرای درخواست کمک و برقراری ارتباط شفاف است. -انجمن کوبرنتیزعضویت

مدیران انتشار مسئول موارد زیر هستند:

  • هماهنگی و کاهش انتشارهای کوبرنتیز:
  • نگهداری شاخه‌های انتشار:
    • بررسی Cherry-picks
    • اطمینان از سالم ماندن شاخه انتشار و عدم وجود وصله ناخواسته ادغام می شود
  • راهنمایی همکاران مدیر انتشار گروه
  • توسعه فعال ویژگی‌ها و نگهداری کد در k/release
  • حمایت از همکاران و مشارکت‌کنندگان مدیر انتشار از طریق فعالیت‌های فعال شرکت در برنامه‌ی buddy
    • ماهانه با همکاران خود در ارتباط باشید و وظایف را به آنها واگذار کنید، به آنها اختیار دهید تا کارها را کاهش دهند منتشر شده، و مربی
    • در دسترس بودن برای پشتیبانی از همکاران در جذب مشارکت‌کنندگان جدید، مثلاً پاسخ به سوالات و پیشنهاد کار مناسب برای انجام آنها

این تیم گاهی اوقات به‌طور نزدیک با کمیته پاسخ‌گویی به مسائل امنیتی همکاری می‌کند و بنابراین باید از دستورالعمل‌های تعیین‌شده در [فرآیند انتشار امنیتی] پیروی کندsecurity-release-process.

کنترل‌های دسترسی در گیت‌هاب:@kubernetes/release-managers اشاره‌های گیت‌هاب: @kubernetes/release-engineering

تبدیل شدن به یک مدیر انتشار

برای تبدیل شدن به یک مدیر انتشار (Release Manager)، ابتدا باید به عنوان دستیار مدیر انتشار (Release Manager Associate) فعالیت کرد. دستیاران با فعالیت مستمر در فرآیندهای انتشار طی چند چرخه، به مدیر انتشار ارتقاء می‌یابند و همچنین:

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

همکاران مدیر انتشار

همکاران مدیر انتشار، کارآموزان مدیران انتشار هستند که قبلاً به عنوان سایه‌های مدیر انتشار شناخته می‌شدند. آنها مسئول موارد زیر هستند:

  • کار انتشار وصله(patch)، بررسی cherry pick
  • مشارکت در انتشار k/release: به‌روزرسانی وابستگی‌ها و عادت کردن به کد منبع
  • مشارکت در مستندسازی: نگهداری کتابچه‌های راهنما، حصول اطمینان از مستندسازی فرآیندهای انتشار
  • با کمک مدیر انتشار: همکاری با تیم انتشار در طول چرخه انتشار و حذف انتشار های کوبرنتیز
  • جستجوی فرصت‌هایی برای کمک به اولویت‌بندی و ارتباطات
    • ارسال پیش‌اعلان‌ها و به‌روزرسانی‌ها در مورد انتشار وصله‌ها
    • به‌روزرسانی تقویم، کمک به تاریخ‌های انتشار و مراحل مهم از جدول زمانی چرخه انتشار
  • از طریق برنامه‌ی Buddy، جذب مشارکت‌کنندگان جدید و جفت‌سازی با آنها در انجام وظایف

اشاره‌های گیت‌هاب: @kubernetes/release-engineering

تبدیل شدن به یک همکار مدیر انتشار

مشارکت‌کنندگان می‌توانند با ارائه موارد زیر به عنوان همکار (همکار) فعالیت کنند:

  • مشارکت مداوم، شامل ۶ تا ۱۲ ماه انتشار فعال کارهای مرتبط با مهندسی
  • تجربه انجام نقش سرپرست فنی در تیم انتشار در طول چرخه انتشار
    • این تجربه، مبنای محکمی برای درک چگونگی عملکرد کلی SIG Release فراهم می‌کند - از جمله انتظارات ما در مورد مهارت‌های فنی، ارتباطات/پاسخگویی و قابلیت اطمینان
  • کار روی آیتم‌های k/release که تعاملات ما با Testgrid را بهبود می‌بخشند، پاکسازی کتابخانه‌ها و غیره.
    • این تلاش‌ها نیازمند تعامل و همکاری با مدیران انتشار و همکاران است

رهبران SIG Release

روسای انتشار SIG و سرپرستان فنی مسئول موارد زیر هستند:

  • حاکمیت انتشار SIG
  • برگزاری جلسات تبادل دانش برای مدیران و همکاران انتشار
  • مربیگری در رهبری و اولویت‌بندی

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

تیم گیت‌هاب: @kubernetes/sig-release-leads

رؤسا

رهبران فنی

مدیران شاخه های قبلی، در [فهرست انتشارها] قابل مشاهده هستند.k-sig-release-releases از مخزن kubernetes/sig-release در داخل release-x.y/release_team.md.

مثال: 1.15 تیم انتشار

4 - یادداشت‌ها

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

یادداشت‌های انتشار (Release Notes) را می‌توانید با مطالعه فهرست تغییرات که با نسخه کوبرنتیز شما مطابقت دارد، بیابید. برای مشاهده تغییرات نسخه 1.33، به GitHub مراجعه کنید.

همچنین، یادداشت‌های انتشار را می‌توانید به صورت آنلاین جستجو و فیلتر کنید در: relnotes.k8s.io. برای مشاهده یادداشت‌های انتشار فیلتر شده برای نسخه 1.33 به relnotes.k8s.io مراجعه کنید.