سیاست اختلاف نسخه

این مستندات حداکثر اختلاف نسخه (version skew) پشتیبانی‌شده بین اجزای مختلف کوبرنتیز را توضیح می‌دهد. ابزارهای خاص استقرار خوشه (cluster) ممکن است محدودیت‌های بیشتری بر اختلاف نسخه اعمال کنند.

ورژن های قابل پشتیبانی شده

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

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

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

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

نسخه پشتیبانی شده skew

kube-apiserver

در خوشه های مقیاس پذیر، جدیدترین و قدیمی‌ترین نمونه‌های kube-apiserver باید حداکثر یک نسخه فرعی (minor) اختلاف داشته باشند.

مثال:

نسخه جدید kube-apiserver در 1.33
سایر نمونه‌های kube-apiserver در نسخه‌ی زیر پشتیبانی می‌شوند:1.33 و 1.32

kubelet

kubelet نبایدجدید تر از kube-apiserver.
kubelet ممکن است تا سه نسخه فرعی (minor) قدیمی‌تر از نسخه زیر باشند kube-apiserver (kubelet < نسخه 1.25 ممکن است حداکثر تا دو نسخه فرعی (minor) قدیمی‌تر از نسخه زیر باشد: kube-apiserver).

مثال:

kube-apiserver در 1.33
kubeletپشتیبانی میشود در 1.33, 1.32, 1.31, و 1.30

Note:

اگر اختلاف نسخه (version skew) بین نمونه‌های kube-apiserver در یک HA cluster وجود داشته باشد، این موضوع دامنه نسخه‌های مجاز برای kubelet را محدود می‌کند.

اگر نسخه skew بین مثال:

نمونه‌های kube-apiserver در نسخه‌های 1.33 و 1.32 قرار دارند.
kubeletپشتیبانی میشود در 1.32, 1.31, و 1.30 (1.33 پشتیبانی نمی شود به دلیل اینکه ممکن است نسخه جدیدتری نسبت به kube-apiserver نمونه در نسخه 1.32) پشتیبانی نمی شود به دلیل اینکه ممکن است نسخه جدیدتری نسبت به

kube-proxy

kube-proxy نباید جدیدتر از kube-apiserver.
kube-proxyممکن است تا سه نسخه minor قدیمی‌تر از kube-apiserver (kube-proxy < 1.25 ممکن است فقط تا دو نسخه minor قدیمی‌تر از kube-apiserver).
kube-proxy ممکن است تا سه نسخه minor قدیمی‌تر یا جدیدتر از kubeletنمونه ای که در کنار آن اجرا می‌شود (برای مثال، kube-proxy نسخه‌های کمتر از 1.25 ممکن است حداکثر تا دو نسخه فرعی قدیمی‌تر یا جدیدتر از نمونه kubelet که کنار آن اجرا می‌شود باشد).

مثال:

kube-apiserverدر 1.33
kube-proxy پشتیبانی میشود در 1.33, 1.32, 1.31, و 1.30

Note:

اگر اختلاف نسخه (version skew) بین نمونه‌های kube-apiserver در یک HA cluster وجود داشته باشد، این موضوع دامنه نسخه‌های مجاز برای kube-proxy را محدود می‌کند.

مثال:

kube-apiserver نمونه ها در 1.33 و 1.32
kube-proxy پشتیبانی می شود در 1.32, 1.31, و 1.30 (1.33 پشتیبانی نمی‌شود زیرا این نسخه جدیدتر از نمونه kube-apiserver در نسخه 1.32) خواهد بود.

kube-controller-manager, kube-scheduler, , cloud-controller-manager

kube-controller-manager، kube-schedulerو cloud-controller-manager نباید جدیدتر از نمونه‌های kube-apiserver که با آنها ارتباط دارند باشند. انتظار می‌رود که نسخه فرعی (minor) آنها با نسخه kube-apiserver مطابقت داشته باشد، اما ممکن است حداکثر تا یک نسخه فرعی قدیمی‌تر باشند (برای اجازه دادن به ارتقاء در لحظه)

مثال:

kube-apiserver در 1.33
kube-controller-manager, kube-scheduler, و cloud-controller-manager در اینجا پشتیبانی میشود 1.33 و 1.32

Note:

اگر اختلاف نسخه (version skew) بین نمونه‌های kube-apiserver در یک HA cluster وجود داشته باشد و این اجزا بتوانند با هر نمونه kube-apiserver در خوشه ارتباط برقرار کنند (مثلاً از طریق یک load balancer)، این موضوع دامنه نسخه‌های مجاز این اجزا را محدود می‌کند.

مثال:

نمونه‌های kube-apiserver در نسخه‌های 1.33 و 1.32 قرار دارن
kube-controller-manager، kube-scheduler و cloud-controller-manager با یک load balancer ارتباط برقرار می‌کنند که می‌تواند درخواست‌ها را به هر نمونه‌ی kube-apiserver هدایت کند.

kube-controller-manager،kube-scheduler و cloud-controller-manager در نسخه 1.32 پشتیبانی می‌شوند (نسخه (1.33 پشتیبانی نمی‌شود زیرا جدیدتر از نمونه kube-apiserver در نسخه 1.32 خواهد بود).

kubectl

kubectl در یک نسخه فرعی (minor) قبل یا بعد از kube-apiserver پشتیبانی می‌شود.

مثال:

kube-apiserver در نسخه 1.33
kubectl در نسخه‌های 1.34، 1.33 و 1.32

Note:

اگر اختلاف نسخه (version skew) بین نمونه‌های kube-apiserver در یک HA cluster وجود داشته باشد، این موضوع نسخه‌های پشتیبانی شده kubectl را محدود می‌کند.

مثال:

نمونه‌های kube-apiserver در نسخه‌های 1.33 و 1.32 قرار دارند.
kubectl در نسخه‌های 1.33 و 1.32 پشتیبانی می‌شود (نسخه‌های دیگر بیش از یک نسخه فرعی (minor) با یکی از اجزای kube-apiserver اختلاف نسخه دارند)

سفارش ارتقاء مؤلفه پشتیبانی شده

اختلاف نسخه (version skew) پشتیبانی شده بین اجزا تأثیراتی بر ترتیب به‌روزرسانی آن‌ها دارد. این بخش ترتیب به‌روزرسانی اجزا را برای انتقال یک خوشه موجود از نسخه 1.32 به نسخه 1.33 توضیح می‌دهد.

به طور اختیاری، هنگام آماده‌سازی برای ارتقا، پروژه کوبرنتیز توصیه می‌کند که موارد زیر را انجام دهید تا از بیشترین تعداد اصلاحات برگشتی (regression) و رفع اشکالات در طول فرآیند ارتقا بهره‌مند شوید:

اطمینان حاصل کنید که اجزا در جدیدترین نسخه patch از نسخه فرعی (minor) فعلی شما قرار دارند.
اجزای سیستم را به جدیدترین نسخه patch از نسخه فرعی (minor) هدف ارتقا دهید.

برای مثال، اگر در حال اجرای نسخه 1.32 هستید، اطمینان حاصل کنید که از جدیدترین نسخه patch آن استفاده می‌کنید. سپس، به جدیدترین نسخه patch از 1.33 ارتقا دهید.

kube-apiserver

پیش‌نیازها:

در یک خوشه تک‌ نمونه ای (single-instance)، نمونه‌ی موجود kube-apiserver دارای نسخه 1.32 است. *در یک خوشه HA، تمام نمونه‌های kube-apiserver دارای نسخه 1.32 یا 1.33 هستند (این موضوع اطمینان می‌دهد که اختلاف نسخه بین قدیمی‌ترین و جدیدترین نمونه‌ی kube-apiserver حداکثر یک نسخه‌ی جزئی است). *نمونه‌های kube-controller-manager، kube-scheduler و cloud-controller-manager که با این سرور ارتباط دارند، در نسخه 1.32 قرار دارند (این موضوع تضمین می‌کند که نسخه آن‌ها از نسخه فعلی سرور API جدیدتر نباشد و حداکثر یک نسخه جزئی با نسخه جدید سرور API اختلاف داشته باشند)
نمونه‌های kubelet در تمام نودها در نسخه 1.32 یا 1.31 هستند. (یعنی نسخه آن‌ها حداکثر یک یا دو نسخه جزئی پایین‌تر از نسخه جدید سرور API است). (این موضوع تضمین می‌کند که نسخه آن‌ها از نسخه فعلی سرور API جدیدتر نباشد و حداکثر دو نسخه جزئی با نسخه جدید سرور API اختلاف داشته باشند).
وب‌هوک‌های پذیرش (admission webhooks) ثبت‌شده قادر هستند داده‌هایی را که نمونه جدید kube-apiserver برای آن‌ها ارسال می‌کند، پردازش کنند:
- شیءهای ValidatingWebhookConfiguration و MutatingWebhookConfiguration به‌روزرسانی شده‌اند تا شامل هر نسخه جدیدی از منابع REST که در 1.33 اضافه شده‌اند باشند. (یا از گزینه matchPolicy: Equivalent option که از نسخه v1.15 به بعد در دسترس است استفاده کنید)
- وب‌هوک‌ها قادرند هر نسخه جدید از منابع REST که به آن‌ها ارسال می‌شود را پردازش کنند، و همچنین هر فیلد جدیدی که به نسخه‌های موجود در 1.33 اضافه شده باشد را مدیریت نمایند.

kube-apiserver به‌روزرسانی کنید 1.33 به نسخه

Note:

قوانین پروژه برای API منسوخ شدن و API دستور العمل های تغیرات در لازم است که kube-apiserver هنگام ارتقا، حتی در تک نمونه‌ای، نسخه‌های فرعی را نادیده نگیرد. نیازمند این هست که Kube-apiserver در نسخه minor رد نشود در هنگام بروزرسانی، حتی در حالت یک خوشه داریم

kube-controller-manager, kube-scheduler, and cloud-controller-manager

نیازمندی ها:

نمونه‌های kube-apiserver که این مولفه (component) با آن‌ها ارتباط برقرار می‌کنند در نسخه 1.33 قرار دارند در خوشه های HA که این مولفه control plane می‌توانند با هر نمونه ای از kube-apiserver در خوشه ارتباط برقرار کنند، تمام نمونه‌های kube-apiserver باید قبل از ارتقاء این مولفه (component) به‌روزرسانی شوند).

با ارتقا دادن kube-controller-manager, kube-scheduler, و cloud-controller-manager to 1.33. ترتیب مشخص و اجباری برای ارتقاء بین kube-controller-manager، kube-scheduler و cloud-controller-manager وجود ندارد. می‌توانید این مولفه (component) را به هر ترتیبی که می‌خواهید یا حتی به‌صورت همزمان ارتقاء دهید.

kubelet

نیازمندی ها:

نمونه‌های kube-apiserver که kubelet با آن‌ها ارتباط برقرار می‌کند، در نسخه 1.33 هستند.

اختیاری است که نمونه‌های kubelet را به نسخه 1.33 ارتقاء دهید (یا می‌توان آن‌ها را در نسخه‌های 1.32، 1.31، یا 1.30 باقی گذاشت).

Note:

قبل از انجام ارتقاء نسخه minor kubelet، پادهای آن (node)گره را خالی کنید drain. ارتقاء نسخه minor kubelet به صورت (in-place) پشتیبانی نمی‌شود.

Note:

اجرای یک خوشه با نمونه‌های kubelet که به طور مداوم سه نسخه جزئی از kube-apiserver عقب‌تر هستند، به این معنی است که آن‌ها باید قبل از ارتقاء control plane به‌روزرسانی شوند.

kube-proxy

نیازمندی ها:

نمونه‌های kube-apiserver که kube-proxy با آن‌ها ارتباط برقرار می‌کند در نسخه 1.33 قرار دارند.

اختیاری است که نمونه‌های kube-proxy را به نسخه 1.33 ارتقاء دهید (یا می‌توان آن‌ها را در نسخه‌های 1.32، 1.31، یا 1.30 باقی گذاشت).

Note:

اجرای یک خوشه با نمونه‌های kube-proxy که به‌طور مداوم سه نسخه جزئی از kube-apiserver عقب‌تر هستند، به این معنی است که آن‌ها باید قبل از ارتقاء control plane، به‌روزرسانی شوند.