Kubernetes 1.37؛ آمادگی ارتقا را از API و نودها بسنجیم

کدام تغییرها برای تیم عملیاتی مهم‌اند؟

Kubernetes 1.37 با نام Garhwal در ۲۶ اوت ۲۰۲۶ معرفی شد. یادداشت رسمی ترکیبی از ویژگی‌های Stable، Beta و Alpha را توضیح می‌دهد؛ نباید همه آن‌ها را هم‌سطح یا مناسب فعال‌سازی فوری فرض کنیم. برای تیم عملیاتی، تغییر رفتار API، runtime و تنظیمات موجود معمولاً مهم‌تر از شمار ویژگی‌های تازه است. این مقاله برنامه آمادگی ارتقا را بررسی می‌کند و دستورها عمداً فقط وضعیت را می‌خوانند. زمان و روش ارتقای یک کلاستر واقعی به توزیع، ارائه‌دهنده و افزونه‌های فعال آن وابسته است.

در این نسخه، API metrics.k8s.io به وضعیت Stable رسیده است؛ این API در مسیرهایی مثل سنجش CPU و حافظه و autoscaling اهمیت دارد. در مقابل، بعضی تغییرها محدودیت ایجاد می‌کنند: static Pod دیگر نباید مستقیم به Secret یا ConfigMap ارجاع بدهد. خبر انتشار همچنین ادامه کنارگذاشتن cgroup v1 و مسیر deprecation حالت ipvs در kube-proxy را شرح می‌دهد. این‌ها به معنی حذف فوری همه آن قابلیت‌ها در همین نسخه نیستند؛ تاریخ و وضعیت هر تغییر را جدا از عنوان کلی نسخه بخوانید.

پیش از ارتقا، موجودی واقعی را ببینید

فهرست نودها، kubelet، container runtime، CNI، CSI و metrics-server را ثبت کنید. دسترسی API برای کاربر توسعه‌دهنده با قابلیت نصب‌شده در کلاستر یکی نیست؛ خطای Forbidden را از نبودن API جدا بررسی کنید. پیشنهاد تحریریه این است که برای هر افزونه، نسخه سازگار مقصد و صاحب نگهداری مشخص شود. در کلاستر مدیریت‌شده، محدودیت مسیر ارتقا و سیاست نسخه ارائه‌دهنده نیز تعیین‌کننده است. وجود یک manifest سالم در git ثابت نمی‌کند منابع واقعی کلاستر یا تنظیم نودها همان وضعیت را دارند.

manifestها و ابزارهای اتوماسیون را برای APIهای منسوخ و قابلیت‌های آزمایشی مرور کنید. اگر metrics API تازه قابل استفاده است، سازگاری client و metrics-server را هم بررسی کنید؛ صرفاً شماره control plane کافی نیست. برای static Pod و تنظیمات cgroup، مسیر توزیع و node image را دنبال کنید. برخی اصلاح‌ها به تعویض image نود یا تغییر runtime نیاز دارند. اعمال override موقت برای عبور از خطا، راهبرد بلندمدت نیست؛ اگر چنین تصمیمی ضروری شد، تاریخ حذف و صاحب آن باید در برنامه نگهداری ثبت شود.

پیش از rollout، محیط staging باید بار کاری نماینده داشته باشد: سرویس دارای PVC، ingress، job، سیاست شبکه و workload حساس به منابع. هنگام ارتقای مرحله‌ای، readiness، restart، خطای API، autoscaling و دسترسی storage را کنترل کنید. تغییر control plane را از تغییر هم‌زمان همه افزونه‌ها جدا کنید تا علت خطا قابل تشخیص باشد. رفتار drain، PodDisruptionBudget و زمان جابه‌جایی ترافیک را هم آزمایش کنید. برنامه برگشت باید با روش پشتیبانی‌شده ارائه‌دهنده سازگار باشد؛ کاهش مستقیم نسخه همه اجزا را فرض نکنید.

kubectl config current-context
kubectl version -o yaml
kubectl get nodes -o wide
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.nodeInfo.kubeletVersion}{"\t"}{.status.nodeInfo.containerRuntimeVersion}{"\n"}{end}'
kubectl api-versions
kubectl get --raw /apis/metrics.k8s.io
kubectl -n kube-system get deployments
kubectl -n kube-system get configmap kube-proxy -o yaml

عرضه مرحله‌ای و بررسی اثر تغییر

گزارش آمادگی باید APIهای مصرف‌شده، نودهای ناسازگار، افزونه‌های بررسی‌شده و سناریوهای آزمون را نشان دهد. دستورهای زیر نقطه شروع بررسی هستند، نه چراغ سبز ارتقا. خطای هر فرمان را به نیاز مجوز، نبودن component یا تفاوت نسخه نسبت دهید و شواهد ذخیره کنید. پس از عرضه، هشدارها و شاخص‌های سرویس را با baseline مقایسه کنید. تصمیم خوب برای 1.37، استفاده آگاهانه از قابلیت‌های پایدار همراه با رسیدگی به تغییرهای مؤثر بر محیط شماست؛ فعال کردن هر feature تازه از روی فهرست خبر، معیار بلوغ نیست.

تاریخ انتشار منبع: 2026-08-26. توضیح‌ها و پیشنهادهای اجرایی این مطلب، تحلیل تحریریه دانشنامه لیان هستند.منابع: Kubernetes — v1.37 Garhwal release · Kubernetes — Deprecation policy · Kubernetes — Cluster upgrade

این مطلب بازنویسی تحلیلی دانشنامه لیان بر پایه منبع اصلی است.مشاهده منبع اصلی