Kubernetes v1.35 — Timbernetes (The World Tree Release) 🌳 با معرفی workload identity، امنیت و اعتبارسنجی workloads را بهبود میدهد و مدیریت خوشههای کانتینری را سادهتر میکند.
Spotlight on key updates with workload identity
کلیدواژههای اصلی شامل workload identity، node topology labels، storage version migration و native workload identity است.
Kubernetes v1.35 — Timbernetes (The World Tree Release) 🌳
نسخهی v1.35 مانند انتشارهای قبلی، مجموعهای از قابلیتهای جدید در سطوح stable، beta و alpha را عرضه کرده است. این استمرار در کیفیت و تحویل منظم نشاندهندهی یک چرخهی توسعه قوی و پشتیبانی فعال از سوی جامعهی Kubernetes است.
این نسخه شامل 60 بهبود است: 17 مورد در سطح stable، 19 مورد در beta و 22 مورد در alpha. همچنین چند مورد deprecation و removal هم وجود دارد؛ حتماً بخش مربوطه را مرور کنید تا از تغییرات سازگاریزای API و رفتارها آگاه شوید. ⚠️
Release theme and logo
سال 2025 را با طنین Octarine: The Color of Magic (v1.33) شروع کردیم، سپس با gusts Of Wind & Will در v1.34 ادامه دادیم، و حالا سال را با World Tree بستهایم — الهامگرفته از Yggdrasil، درخت زندگی که جهانها را به هم پیوند میدهد. درست مثل یک درخت بزرگ، Kubernetes هم با هر ریلیز یک حلقه به رشدش اضافه میکند، و این رشد با مشارکت و مراقبت جامعه شکل میگیرد.
در مرکز تصویر، چرخ Kubernetes دور زمین پیچیده شده و ریشهاش را maintainers، contributors و کاربران مقاوم نگه میدارند؛ افرادی که بین کار روزمره، تغییرات زندگی و نگهداری متنباز، APIهای قدیمی را پاکسازی، قابلیتهای جدید را پیوند میزنند و پروژه را سالم نگه میدارند.
سه سنجاب نگهبان در طرح حضور دارند: یک جادوگر که اسکرول LGTM برای reviewers دارد، یک جنگجو با تبر و shield برای release crew که شاخههای جدید را قطع میکند، و یک rogue با فانوس برای triagerها که صفهای issues تاریک را روشن میکند. 🐿️✨
این نمادها نمایندهی یک گروه بسیار بزرگتر از مشارکتکنندگان هستند. Kubernetes v1.35 یک حلقهی رشد تازه به World Tree اضافه میکند؛ برشی شکلگرفته از دستهای بسیار، مسیرهای متفاوت و جامعهای که شاخههایش هر روز بالاتر میروند و ریشهاش عمیقتر میشود.
Spotlight on key updates
Kubernetes v1.35 پر از قابلیتها و بهبودهای عملی برای محیطهای production است. در ادامه، نکات کلیدی که برای تیمهای DevOps / SRE اهمیت دارد را برجسته کردهام:
Stable: In-place update of Pod resources
قابلیت in-place updates برای Pod resources حالا به General Availability (GA) رسیده است. این امکان به شما اجازه میدهد CPU و memory را بدون ریاستارت کردن Pod یا Containerها تغییر دهید. قبلاً برای تغییر چنین تنظیماتی باید Pod را بازسازی میکردید که برای workloadهای stateful یا batch میتوانست مشکلساز باشد. این قابلیت باعث scale عمودی غیراختلالی، افزایش کارایی و سادهتر شدن چرخهی توسعه میشود. (KEP #1287 — SIG Node)
Beta: Pod certificates for workload identity and security 🔐
تا پیش از این، تحویل گواهی به Podها معمولاً به کنترلرهای خارجی مثل cert-manager یا SPIFFE/SPIRE، CRDها و مدیریت Secret نیاز داشت و rotation معمولاً با sidecar یا init container انجام میشد. در v1.35 امکان native workload identity با خود Kubernetes فراهم شده و rotation خودکار گواهیها پشتیبانی میشود که معماریهای service mesh و zero-trust را بسیار سادهتر میکند. اکنون kubelet کلیدها را تولید، از طریق PodCertificateRequest گواهی را درخواست و bundleهای credential را مستقیماً در filesystem مربوط به Pod مینویسد. kube-apiserver هم با node restriction در admission از نقض مرزهای node isolation جلوگیری میکند؛ این مسیر اجازه فراهم شدن جریانهای pure mTLS را بدون استفاده از bearer token در مسیر صدور میدهد. (KEP #4317 — SIG Auth)
Alpha: Node declared features before scheduling
وقتی کنترلپلن قابلیت جدیدی را فعال میکند اما نودها به آن نرسیدهاند (بر اساس skew policy)، scheduler ممکن است پادهایی را روی نودهای ناسازگار قرار دهد. فریمورک node-declaration features به نودها اجازه میدهد قابلیتهای پشتیبانیشدهی خود را اعلام کنند. در حالت alpha، یک Node میتواند ویژگیهای خودش را در فیلد .status.declaredFeatures گزارش کند و این اطلاعات را به control plane ارسال کند. سپس kube-scheduler، admission controllers و اجزای ثالث میتوانند از این اعلانها استفاده کنند تا scheduling و validation تضمین کنند که Pods فقط روی نودهای سازگار اجرا شوند. (KEP #5328 — SIG Node)
Features graduating to Stable
چند مورد از بهبودها که در v1.35 به stable رسیدهاند و برای معماریهای توزیعشده اهمیت دارند:
PreferSameNode traffic distribution
فیلد trafficDistribution برای Services گسترش یافته تا کنترل دقیقتری روی مسیریابی ترافیک داشته باشید. گزینه جدید PreferSameNode اضافه شده تا سرویس در صورت وجود endpointهای محلی، اولویت را به آنها بدهد و در غیر این صورت به remote endpoints برگردد. گزینه قبلی PreferClose به PreferSameZone تغییر نام داده تا مشخصاً نشان دهد اولویت در سطح availability zone است. (PreferClose هم برای backward compatibility حفظ شده.) این تغییر API را خواناتر میکند و تفاوت بین ترجیحات node-level و zone-level را مشخص میسازد. (KEP #3015 — SIG Network)
Job API managed-by mechanism
اکنون Job API شامل فیلد managedBy شده که اجازه میدهد یک کنترلر خارجی مسئول همگامسازی status مربوط به Job باشد. این قابلیت که در v1.35 به stable میرسد، عمدتاً برای سناریوهایی مثل MultiKueue طراحی شده است؛ جایی که Job در یک management cluster ساخته میشود، در worker cluster اجرا میشود و وضعیت اجرا به management cluster بازمیگردد. برای این جریان کاری، کنترلر built-in Job نباید روی آن Job خاص عمل کند تا کنترلر Kueue بتواند status را مدیریت کند. هدف این ویژگی واگذاری واضح همگامسازی status به کنترلر دیگر است؛ هدف ارسال پارامتر سفارشی یا تغییر سیاستهای concurrency CronJob نیست. (KEP #4368 — SIG Apps)
Reliable Pod update tracking with .metadata.generation
تاریخچهی Pod API نشان میداد که فیلد metadata.generation که در دیگر اشیا مثل Deployment وجود دارد، برای Podها غایب بود؛ در نتیجه هیچ راه قابلاعتمادی برای فهمیدن اینکه kubelet واقعاً آخرین spec را پردازش کرده وجود نداشت. این به خصوص برای قابلیتهایی مثل In-Place Pod Vertical Scaling مشکلزا بود. در v1.33 فیلد .metadata.generation برای Podها به صورت alpha اضافه شد و حالا در v1.35 این فیلد stable شده است؛ یعنی هر بار spec یک Pod بهروزرسانی شود، مقدار .metadata.generation افزایش مییابد. همچنین فیلد .status.observedGeneration گزارش میدهد که kubelet کدام generation را دیده و پردازش کرده است. هر condition هم observedGeneration مخصوص به خودش را دارد که کلاینتها میتوانند آن را گزارش یا مشاهده کنند. این به کنترلرها و اپراتورها یک منبع قابلاعتماد برای ردیابی بهروزرسانیهای Pod میدهد. (KEP #5067 — SIG Node)
Configurable NUMA node limit for topology manager
topology manager قبلاً یک محدودیت سختکد شده 8 برای حداکثر تعداد NUMA nodes داشت تا از انفجار حالتها در محاسبات affinity جلوگیری کند. اما سرورهای مدرن ممکن است بیش از 8 NUMA node داشته باشند و این محدودیت مانع استفاده کامل از سختافزارهای پیشرفته میشد. در v1.31 گزینه beta ای به نام max-allowable-numa-nodes اضافه شد و در v1.35 این گزینه پایدار شده است؛ پس cluster admins میتوانند نودهایی با بیش از 8 NUMA node را فعال کنند. با این وجود جامعه از مشکلات عملکردی برای هاستهای NUMA بزرگ آگاه است و یک KEP پیشنهادی (KEP-5726) برای بهبود این وضعیت مطرح شده است. برای جزئیات بیشتر بخش Control Topology Management Policies را مطالعه کنید. (KEP #4622 — SIG Node)
New features in Beta
چند قابلیت جدید که حالا در سطح beta هستند و برای طراحی سیستمهای مقاوم و ایمن مفیدند:
Expose node topology labels via Downward API
دریافت اطلاعات topology نود، مثل region و zone، از داخل یک Pod تا پیش از این معمولاً نیاز به پرسوجو از kube-apiserver داشت که به مجوزهای RBAC گسترده یا استفاده از sidecar نیازمند بود و این نقطهضعفی امنیتی و پیچیدگیزا ایجاد میکرد. در v1.35 امکان expose کردن node topology labels مستقیماً از طریق Downward API به beta ارتقا یافته است. اکنون kubelet میتواند برچسبهای استاندارد topology مثل topology.kubernetes.io/zone و topology.kubernetes.io/region را به عنوان environment variable یا فایلهای projected volume در اختیار Pod قرار دهد. این روش امنتر و کارآمدتر است و اجازه میدهد اپلیکیشنها بدون وابستگی به API server نسبت به zone یا region خود-aware شوند و اصل least privilege را بهتر رعایت کنند. توجه کنید که با آپگرید به v1.35، kubelet این labels را به هر Pod تزریق میکند و ممکن است مدیران خوشه چند برچسب جدید را در هر Pod ببینند؛ این رفتار طراحیشده و مورد انتظار است. (KEP #4742 — SIG Node)
Native support for storage version migration
در v1.35 پشتیبانی native از storage version migration به beta رسیده و به طور پیشفرض فعال است. این تغییر منطق مهاجرت نسخهی ذخیرهسازی را مستقیماً در control plane اصلی ادغام میکند (in-tree) و نیاز به ابزارهای خارجی برای این کار را حذف میکند. نتیجه برای اپراتورها: سادهتر شدن فرآیند آپگرید، کاهش پیچیدگی و ریسک کمتر در هنگام مهاجرت schema/versions برای منابع API.
