.NET 8 ve .NET 9, 10 Kasım'da destekten çıkıyor; image etiketleri hangi pod'ların etkilendiğini göstermeyecek

İki .NET sürümü aynı gün destekten çıkıyor

dev.to'da yayınlanan bir yazıya göre .NET 8 ve .NET 9, 10 Kasım 2026'da destek ömrünün sonuna ulaşıyor. .NET 8 uzun süreli destek (LTS) sürümüydü, .NET 9 ise kısa süreli destek (STS) sürümüydü ve destek süreleri eşzamanlı olarak kapanıyor. Bu tarihten itibaren iki runtime da güvenlik yaması almayacak. Önerilen hedef ise mevcut LTS sürümü olan .NET 10; yazıya göre desteği 14 Kasım 2028'e kadar sürecek.

Envanter sorunu

Geçiş yapılmadan önce ekiplerin, hangi iş yüklerinin gerçekten eski runtime'ları çalıştırdığını bilmesi gerekiyor ve dev.to'daki yazar, Kubernetes kullanıcıları için bunun göründüğünden daha zor olduğunu savunuyor. mcr.microsoft.com/dotnet/aspnet:8.0 gibi base image etiketleri sürümünü açıkça belirtir; ancak neredeyse hiç kimse bu image'ı doğrudan çalıştırmaz. Uygulamalar bunun üzerine inşa edilir ve orders-api:1.42 gibi uygulamaya özgü bir etiketle push edilir. Bu noktada .NET sürümü, kubectl'in çalışan pod'lar hakkında gösterdiği hiçbir şeyde görünmez durumdadır.

Bir pod'un içine girip dotnet --list-runtimes çalıştırmak gibi bilinen bir yöntemin iki sakıncası var: chiseled container image'ları shell olmadan gelir ve bu yaklaşım, özünde bir envanter sorusu olan bir şeyi yanıtlamak için production pod'larına girmek anlamına gelir.

Sürümü image config'inden okumak

Yazıda belirtildiğine göre Microsoft'un resmi Dockerfile'ları, runtime sürümünü image içinde ortam değişkenleri olarak gömüyor. 8.0 runtime image'ları — chiseled varyantlar dahil — DOTNET_VERSION tanımlar (örneğin 8.0.33) ve ASP.NET image'ları ek olarak ASPNET_VERSION belirler. Ortam değişkenleri base image katmanlarından miras alındığı için bu değerler türetilmiş uygulama image'larında da korunur.

Bu sayede hiçbir şey pull etmeden veya çalıştırmadan bir cluster denetlenebilir. Önce kubectl get pods -A -o json çıktısı jq ile filtrelenerek init container'lar dahil tüm pod'lardaki image referansları toplanır. Ardından her image'ın config'i go-containerregistry'den crane ile sorgulanır ve Env listesindeki iki sürüm değişkeni çıkarılır. 8. veya 9. ile başlayan bir sürüm bildiren her image, artık yama almayan bir runtime üzerinde demektir. Yazar, her iki komutun da yalnızca okuma yaptığını ve node'da halihazırda bulunan image'lar için docker image inspect komutunun aynı Env verilerini gösterdiğini belirtiyor.

Denetimin yetersiz kaldığı yer

Self-contained dağıtımlar kör noktadır. runtime-deps image'ı üzerine --self-contained ile yayınlanan uygulamalar runtime'ı uygulama klasörü içinde taşır ve runtime-deps, DOTNET_VERSION tanımlamaz; dolayısıyla ortam değişkeni denetimi boş döner.

Bu durumlar için yazı, image'ın yazılım bom'una (SBOM) başvuruyor: runtime, Microsoft.NETCore.App.Runtime.* bileşeni olarak görünür ve Trivy, adını ve sürümünü listeleyen bir CycloneDX SBOM üretebilir. Trivy'nin image katmanlarını fetch edip açması gerektiğinden bu yol, config okumaktan daha yavaştır; bu yüzden yazar, önce her şeyde ortam değişkeni denetimini çalıştırmayı ve SBOM taramasını yalnızca denetimin boş döndüğü ama bir .NET servisinin bulunduğunun bilindiği image'lara ayırmayı öneriyor.

Geçiş ve önceliklendirme

Çoğu servis için mekanik geçiş küçüktür: base image'ı 10.0'a yükseltin, TargetFramework'i net10.0 yapın, yeniden derleyin ve test paketini çalıştırın. Ancak yazı, bu atlanmanın bedelsiz olduğunu varsaymamak konusunda uyarıyor ve okuyucuları, .NET 10 için Microsoft'un breaking-changes dokümanına yönlendiriyor; bu doküman alana göre gruplandırıldığından ekipler kullanmadıkları kısımları atlayabilir.

Önceliklendirme konusunda yazar, internete açık servislerle başlamayı, ardından kimlik doğrulama veya ödeme işleyen her şeyi, sonra da dahili işleri ve batch çalışmaları öneriyor. Gerçekten hemen taşınamayacak servisler, bir sahip ve hedef tarihle birlikte yazılı hale getirilmeli — belgelenmiş, yama almayan bir runtime en azından bilinçli bir tercihtir; oysa kimsenin keşfetmediği bir runtime, kendisi için bir CVE çıktığı gün bir krize dönüşür.

Neden önemli

Desteklenmeyen bir runtime, 8 ve 9 sürümlerindeki gelecekteki her .NET güvenlik açığının yamalanmadan kalması demektir ve dev.to'da anlatılan denetim boşluğu bu riski küçümsemeyi kolaylaştırır: uygulama image etiketleri framework sürümünü bilerek gizler ve dağıtımın tüm kategorileri — chiseled image'lar, self-contained yayınlar — ekiplerin alışkanlıkla güvendiği hızlı denetimlere direnir. .NET 10'un 2028 sonuna kadar desteklenmesiyle geçiş, sınırsız bir güvenlik yükünü ortadan kaldıran, sınırlı ve tek seferlik bir maliyettir; ama yalnızca ekiplerin son tarihi geçmeden bulmayı başardığı iş yükleri için.