☸️ راهنمای به‌روزرسانی کلاستر و نودپول کوبرنتیز

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

نسخه‌های کوبرنتیز ستون

نسخه‌های کوبرنتیز ستون از دو بخش تشکیل شده‌اند:

• نسخه‌ی کوبرنتیز: مانند 1.31.2 که همان نسخه‌ی رسمی کوبرنتیز است.
• نسخه‌ی ستون (patch): مانند ske.1 که نسخه‌ی ایمیج و تنظیمات ستون را مشخص می‌کند.

این دو بخش در پنل به شکل 1.31.2-ske.1 نمایش داده می‌شوند. ستون ممکن است برای یک نسخه‌ی کوبرنتیز، چند نسخه‌ی patch منتشر کند (برای مثال 1.31.2-ske.0 و 1.31.2-ske.1) که شامل رفع مشکلات یا به‌روزرسانی‌های امنیتی ایمیج نودها هستند. ارتقا از یک patch به patch بالاتر هم مانند ارتقای نسخه‌ی کوبرنتیز از طریق پنل انجام می‌شود.

به‌روزرسانی چگونه انجام می‌شود؟

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

1. ارتقای کلاستر (کنترل‌پلین): نودهای کنترل‌پلین که توسط ستون مدیریت می‌شوند به نسخه‌ی جدید ارتقا پیدا می‌کنند.
2. ارتقای نودپول‌ها (نودهای ورکر): نودهای ورکر هر نودپول به نسخه‌ی کلاستر ارتقا پیدا می‌کنند.

توجه

ارتقای کلاستر، نودپول‌ها را به صورت خودکار ارتقا نمی‌دهد. پس از پایان ارتقای کلاستر، باید هر یک از نودپول‌های خود را جداگانه ارتقا دهید.

ارتقای کلاستر (کنترل‌پلین)

نودهای کنترل‌پلین به روش rolling update جایگزین می‌شوند؛ یعنی ابتدا یک نود کنترل‌پلین با نسخه‌ی جدید به کلاستر اضافه می‌شود و پس از آماده شدن آن، یکی از نودهای قدیمی حذف می‌شود. این روند تا جایگزینی همه‌ی نودهای کنترل‌پلین ادامه پیدا می‌کند. کلاستر در طی انجام این فرایند همیشه در دسترس خواهد بود. نودهای ورکر در طی فرایند به‌روزرسانی کلاستر تغییری نخواهند داشت و سرویس‌های دیپلوی شده بر روی کلاستر به عملکرد خود ادامه می‌دهند.

ارتقای نودپول (نودهای ورکر)

برای ارتقای نودهای ورکر دو روش وجود دارد:

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

در ارتقای مستقیم، نودهای ورکر به روش rolling update جایگزین می‌شوند. ستون در هر مرحله:

1. یک نود جدید با نسخه‌ی جدید به نودپول اضافه می‌کند و منتظر آماده شدن آن می‌ماند.
2. قدیمی‌ترین نود نودپول را cordon می‌کند تا پاد جدیدی روی آن زمان‌بندی نشود.
3. نود قدیمی را drain می‌کند تا پادهای آن به نودهای دیگر منتقل شوند.
4. نود قدیمی را حذف می‌کند.

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

نکته

نودها در فرایند ارتقا جایگزین می‌شوند و نود قبلی به‌روزرسانی نمی‌شود. بنابراین:

• برچسب‌ها (labels)، sysctlها و security groupهایی که از طریق پنل برای نودپول تنظیم کرده‌اید روی نودهای جدید هم اعمال می‌شوند.
• برچسب‌ها و taintهایی که به صورت دستی و با kubectl روی نودها گذاشته‌اید، روی نودهای جدید وجود نخواهند داشت.
• داده‌هایی که روی دیسک محلی نود ذخیره شده‌اند (مانند emptyDir و hostPath) از بین می‌روند.

نکات مهم پیش از ارتقا

۱- ورژن های مجاز ارتقا را بشناسید

• ارتقا فقط به یک نسخه‌ی minor بالاتر امکان‌پذیر است. برای مثال، برای رفتن از نسخه‌ی 1.30 به 1.32 باید ابتدا کلاستر و نودپول‌ها را به 1.31 و سپس به 1.32 ارتقا دهید.
• در پنل، حداکثر دو گزینه برای ارتقا نمایش داده می‌شود: آخرین patch نسخه‌ی فعلی، و آخرین patch نسخه‌ی minor بعدی.

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

۲- تغییرات نسخه‌ی جدید را مطالعه کنید

کوبرنتیز در هر نسخه تغییرات مهمی ایجاد می‌کند و ممکن است برخی APIها حذف شوند. پیش از ارتقا، یادداشت‌های انتشار کوبرنتیز و راهنمای APIهای منسوخ‌شده را برای نسخه‌ی مقصد مطالعه کنید. برای پیدا کردن APIهای منسوخ در کلاستر خود می‌توانید از ابزار kubent استفاده کنید.

۳- ابتدا در محیط تست آزمایش کنید

در صورتی که کلاستر مجزایی برای محیط تست خود دارید، پیش از ارتقای کلاستر پروداکشن، همان ارتقا را روی آن کلاستر تست با سرویس‌های مشابه انجام دهید و از سازگاری سرویس‌ها، Helm chartها و اپراتورهای خود با نسخه‌ی جدید اطمینان حاصل کنید.

۴- سازگاری افزونه‌ها را بررسی کنید

افزونه‌های کلاستر (مانند Calico، CoreDNS، SKE-CSI و مانیتورینگ) همراه با ارتقای کلاستر به‌روزرسانی نمی‌شوند. پیش از ارتقا به تب «افزونه‌ها» در صفحه‌ی کلاستر بروید و در صورت وجود نسخه‌ی جدید برای افزونه‌ها، ابتدا آن‌ها را ارتقا دهید. اگر نسخه‌ی یک افزونه با نسخه‌ی مقصد کوبرنتیز سازگار نباشد، درخواست ارتقای کلاستر رد می‌شود و پیام خطا نام افزونه را نشان می‌دهد.

۵- کلاستر را برای جابه‌جایی پادها آماده کنید

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

• سرویس‌های مهم را با بیش از یک replica و در صورت امکان روی نودهای مختلف اجرا کنید.
• برای سرویس‌های مهم PodDisruptionBudget تعریف کنید. فرایند drain مقدار PodDisruptionBudgetها را در نظر میگیرد.
• مطمئن شوید هیچ PodDisruptionBudgetی خروج همه‌ی پادها را مسدود نمی‌کند (برای مثال maxUnavailable: 0 یا minAvailable برابر با تعداد replicaها). در این حالت drain نود قدیمی کامل نمی‌شود و ارتقای نودپول متوقف می‌ماند.
• برای داده‌های ماندگار از دیسک مانا استفاده کنید، نه دیسک محلی نود.
• در روش جایگزینی نودپول، نودپول جدید تا زمان حذف نودپول قدیمی کنار آن اجرا می‌شود. مطمئن شوید سقف منابع ورک اسپیس شما اجازه‌ی ساخت نودپول جدید را می‌دهد (در ارتقای مستقیم، حداکثر یک نود اضافه به صورت موقت ساخته می‌شود).

۶- نسخه‌ی فعلی کلاستر و نودها را بررسی کنید

نسخه‌ی کلاستر و نودپول‌ها در پنل نمایش داده می‌شود. با kubectl هم می‌توانید آن‌ها را ببینید:

# نسخه‌ی کلاستر (Server Version) و kubectl (Client Version)
kubectl version
 
# نسخه‌ی kubelet هر نود
kubectl get nodes -o wide

مراحل ارتقای کلاستر

۱- وارد پنل کوبرنتیز شوید، از «لیست کلاسترها» کلاستر مورد نظر را انتخاب کنید و به تب «اطلاعات کلی» بروید.

۲- اگر نسخه‌ی جدیدی برای کلاستر شما وجود داشته باشد، پیام «نسخه جدید آماده بروزرسانی است!» در بالای صفحه نمایش داده می‌شود. روی دکمه‌ی «ارتقا نسخه» کلیک کنید.

اگر این پیام را نمی‌بینید، کلاستر شما روی آخرین نسخه‌ی موجود است.

۳- در پنجره‌ی «نسخه‌های موجود برای ارتقا»، نسخه‌ی فعلی و نسخه‌های قابل انتخاب نمایش داده می‌شوند. نسخه‌ی مقصد را انتخاب کنید، هشدارها را با دقت بخوانید و روی «ارتقا نسخه» کلیک کنید.

۴- وضعیت کلاستر به Upgrading تغییر می‌کند و نودهای کنترل‌پلین یکی‌یکی جایگزین می‌شوند. در این مدت:

• امکان ارسال درخواست ارتقای دیگر برای کلاستر وجود ندارد.
• امکان ارتقای نودپول‌ها وجود ندارد.

۵- پس از پایان ارتقا، وضعیت کلاستر به Highly Available (یا در کلاسترهای تک‌کنترل‌پلین به Ready) بازمی‌گردد و نسخه‌ی جدید در صفحه‌ی کلاستر نمایش داده می‌شود. اگر پس از گذشت حدود نیم ساعت وضعیت کلاستر تغییر نکرد یا به Failed تغییر کرد، در کانال پشتیبانی اختصاصی پیام دهید.

۶- در صورت نیاز kubectl را به‌روزرسانی کنید. نسخه‌ی kubectl باید حداکثر یک نسخه‌ی minor با نسخه‌ی کلاستر فاصله داشته باشد. برای مثال kubectl نسخه‌ی 1.32 می‌تواند کلاسترهای 1.31، 1.32 و 1.33 را مدیریت کند.

kubectl version --client

۷- اکنون نودپول‌ها را مطابق بخش بعد ارتقا دهید.

مراحل ارتقای نودپول‌ها

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

روش ۱: جایگزینی نودپول (روش پیشنهادی ستون)

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

چرا این روش امن‌تر است؟

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

مراحل

۱- در تب «نودپول‌ها» یک نودپول جدید با تنظیمات مشابه نودپول قدیمی (نوع و تعداد ماشین، برچسب‌ها، sysctlها و security groupها) بسازید. نسخه‌ی نودپول جدید برابر با نسخه‌ی کلاستر خواهد بود.

نکته

تنظیماتی مانند sysctl و برچسب‌های نودپول قدیمی به صورت خودکار به نودپول جدید منتقل نمی‌شوند و باید هنگام ساخت نودپول جدید آن‌ها را دوباره تنظیم کنید.

۲- پس از آماده شدن نودهای جدید، از سالم بودن آن‌ها و نسخه‌ی صحیحشان اطمینان حاصل کنید:

kubectl get nodes -o wide

۳- همه‌ی نودهای نودپول قدیمی را cordon کنید تا پاد جدیدی روی آن‌ها زمان‌بندی نشود و پادهایی که در مراحل بعد جابه‌جا می‌شوند، روی نودهای نودپول جدید اجرا شوند:

kubectl cordon NODE_NAME

۴- به صفحه‌ی نودپول قدیمی بروید و از بخش «تغییر تعداد نودهای ورکر»، تعداد نودها را یک عدد کاهش دهید. ستون پیش از حذف نود، آن را drain می‌کند تا پادهایش به نودهای دیگر منتقل شوند و سپس نود را حذف می‌کند.

نکته

اگر می‌خواهید جابه‌جایی پادها را کاملا خودتان کنترل کنید، می‌توانید پیش از کاهش تعداد نودها، نودهای قدیمی را با دستور زیر drain کنید:

kubectl drain NODE_NAME --ignore-daemonsets --delete-emptydir-data

با فلگ --delete-emptydir-data، داده‌های emptyDir پادهای آن نود حذف می‌شوند. اگر داده‌ی مهمی روی دیسک محلی نود دارید، پیش از drain آن را منتقل کنید. برای اطلاعات بیشتر راهنمای drain کوبرنتیز را مطالعه کنید.

۵- صبر کنید تا نود حذف شود و نودپول به وضعیت Running بازگردد، سپس از عملکرد صحیح سرویس‌های خود اطمینان حاصل کنید. تا زمانی که نودپول به وضعیت Running برنگشته باشد، امکان کاهش دوباره‌ی تعداد نودها وجود ندارد.

۶- مراحل ۴ و ۵ را تکرار کنید تا تنها یک نود در نودپول قدیمی باقی بماند. سپس با اطمینان از اینکه همه‌ی سرویس‌ها روی نودپول جدید به درستی کار می‌کنند، نودپول قدیمی را از پنل حذف کنید.

پیشنهاد

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

۷- این مراحل را برای سایر نودپول‌های کلاستر تکرار کنید.

روش ۲: ارتقای مستقیم نودپول

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

توجه

ارتقای مستقیم نودپول پس از شروع قابل توقف یا بازگشت نیست.

۱- در صفحه‌ی کلاستر به تب «نودپول‌ها» بروید. در جدول «لیست نودپول‌ها»، کنار نودپول‌هایی که نسخه‌ی جدید برایشان وجود دارد، برچسب «نسخه‌ی جدید موجود است.» در ستون «نسخه کوبرنتیز نودپول» نمایش داده می‌شود.

۲- روی نودپول مورد نظر کلیک کنید. در بالای صفحه‌ی نودپول، پیام «نسخه جدید آماده بروزرسانی است!» را می‌بینید. روی «ارتقا نسخه» کلیک کنید.

۳- در پنجره‌ی «نسخه‌های موجود برای ارتقا»، نسخه‌ی مقصد را انتخاب کرده و روی «ارتقا نسخه» کلیک کنید.

۴- نودهای نودپول یکی‌یکی جایگزین می‌شوند. در تب «ماشین‌های مجازی» می‌توانید روند ساخته شدن نودهای جدید (Provisioning) و حذف نودهای قدیمی (Deleting) را ببینید. با kubectl هم می‌توانید روند را دنبال کنید:

kubectl get nodes -o wide --watch

۵- ارتقای نودپول زمانی تمام شده است که همه‌ی نودهای آن نسخه‌ی جدید را نشان دهند و نودپول به وضعیت Running بازگردد. در طول ارتقا ممکن است وضعیت نودپول ScalingUp یا ScalingDown نمایش داده شود و در این مدت امکان کاهش تعداد نودهای نودپول وجود ندارد.

۶- اگر از این روش استفاده می‌کنید، نودپول‌ها را یکی پس از دیگری ارتقا دهید و پس از بازگشت هر نودپول به وضعیت Running و اطمینان از سلامت سرویس‌ها، نودپول بعدی را ارتقا دهید.

اگر حذف نود قدیمی متوقف شد

در هر دو روش، اگر حذف یک نود قدیمی برای مدت طولانی متوقف مانده است، معمولا یک PodDisruptionBudget یا پادی که نمی‌تواند روی نود دیگری اجرا شود (به دلیل کمبود منابع، nodeSelector یا affinity) مانع drain شدن نود است. پادهای باقی‌مانده روی نود و PodDisruptionBudgetها را بررسی کنید:

kubectl get pods -A -o wide --field-selector spec.nodeName=NODE_NAME
kubectl get pdb -A

بررسی APIهای منسوخ با kubent

با هر نسخه‌ی جدید کوبرنتیز، ممکن است برخی نسخه‌های API منسوخ یا حذف شوند. اگر منابع کلاستر شما (یا Helm chartهایی که استفاده می‌کنید) هنوز از این APIها استفاده کنند، پس از ارتقا با خطا مواجه می‌شوند. با ابزار kubent (Kube No Trouble) می‌توانید پیش از ارتقا این موارد را پیدا کنید.

برای نصب kubent:

sh -c "$(curl -sSL https://git.io/install-kubent)"

kubent با استفاده از kubeconfig به کلاستر متصل می‌شود و منابع همه‌ی namespaceهای قابل دسترسی را بررسی می‌کند. با فلگ --target-version می‌توانید نسخه‌ی مقصد ارتقا را مشخص کنید:

kubent --kubeconfig kubeconfig.yaml --target-version 1.32.0

پیش از ارتقا، همه‌ی منابعی که در خروجی kubent نمایش داده می‌شوند را به نسخه‌ی جدید API منتقل کنید.

چک‌لیست ارتقا

• تغییرات نسخه‌ی مقصد را مطالعه کرده‌ام.
• APIهای منسوخ را با kubent بررسی و اصلاح کرده‌ام.
• ارتقا را روی کلاستر staging آزمایش کرده‌ام.
• افزونه‌های کلاستر را به آخرین نسخه ارتقا داده‌ام.
• سرویس‌های مهم بیش از یک replica و PodDisruptionBudget مناسب دارند.
• کلاستر را ارتقا داده‌ام و وضعیت آن به Highly Available بازگشته است.
• برای هر نودپول، نودپول جدید با نسخه‌ی کلاستر ساخته‌ام و نودپول قدیمی را پس از کاهش تدریجی نودهایش حذف کرده‌ام.
• نسخه‌ی kubectl را به‌روزرسانی کرده‌ام.