Cloud-Native | The .NET Blog

Python, TypeScript ve .NET ile azd Hook Yazma: Shell Script'lere Veda

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

Bu gönderi otomatik olarak çevrilmiştir. Orijinal sürüm için buraya tıklayın.

Tamamen .NET ile yazılmış bir projeniz olmasına rağmen azd hook’ları için Bash scriptleri yazmak zorunda kaldıysanız, bu acıyı iyi biliyorsunuzdur. Projenin geri kalanı C# iken, neden bir pre-provisioning adımı için shell sözdizimine geçiş yapmak zorunda kalınsın?

Bu hayal kırıklığı artık resmi bir çözüme kavuştu. Azure Developer CLI hook’lar için çok dilli destek yayımladı ve tam olarak duyulduğu kadar iyi.

Hook nedir?

Hook’lar, azd yaşam döngüsünün kritik noktalarında çalışan scriptlerdir — provisioning öncesi, deployment sonrası vb. azure.yaml içinde tanımlanır ve CLI’yi değiştirmeden özel mantık eklemenizi sağlar.

Önceden yalnızca Bash ve PowerShell destekleniyordu. Artık Python, JavaScript, TypeScript veya .NET kullanılabilir — azd geri kalanını otomatik olarak halleder.

Algılama nasıl çalışır

Yalnızca hook’u bir dosyaya yönlendirin; azd uzantıdan dili çıkarır:

hooks:
 preprovision:
 run: ./hooks/setup.py
 postdeploy:
 run: ./hooks/seed.ts
 postprovision:
 run: ./hooks/migrate.cs

Ek yapılandırma gerekmez. Uzantı belirsizse kind: python (veya ilgili dil) ile açıkça belirtebilirsiniz.

Dile göre önemli ayrıntılar

Python

Scriptin yanına (veya herhangi bir üst dizine) requirements.txt ya da pyproject.toml koyun. azd otomatik olarak sanal ortam oluşturur, bağımlılıkları kurar ve scripti çalıştırır.

JavaScript ve TypeScript

Aynı desen — script yakınına package.json koyun ve azd önce npm install çalıştırır. TypeScript için derleme adımı ve tsconfig.json gerekmeden npx tsx kullanılır.

.NET

İki mod mevcuttur:

Proje modu: Script yanında .csproj varsa azd otomatik olarak dotnet restore ve dotnet build çalıştırır.
Tek dosya modu: .NET 10+ sürümünde bağımsız .cs dosyaları dotnet run script.cs ile doğrudan çalıştırılabilir. Proje dosyası gerekmez.

Executor’a özgü yapılandırma

Her dil isteğe bağlı bir config bloğunu destekler:

hooks:
 preprovision:
 run: ./hooks/setup.ts
 config:
 packageManager: pnpm
 postprovision:
 run: ./hooks/migrate.cs
 config:
 configuration: Release
 framework: net10.0

.NET geliştiricileri için önemi

Hook’lar, azd tabanlı bir projede dil değiştirmeyi zorunlu kılan son yerdi. Artık uygulama kodu, altyapı scriptleri ve yaşam döngüsü hook’ları dahil tüm deployment pipeline’ı tek bir dilde yaşayabilir. Mevcut .NET yardımcı programlarını hook’larda yeniden kullanabilir, paylaşılan kütüphanelere referans verebilir ve shell script bakımından kurtulabilirsiniz.

Sonuç

Küçük görünse de azd günlük iş akışından çok fazla sürtünme kaldıran değişikliklerden biri. Hook’lar için çok dilli destek şu anda kullanılabilir — resmi gönderinde tam belgelere ulaşabilirsiniz.

Aspire 13.2, MongoDB EF Core ve Azure Data Lake Desteği Kazandı — Denemeye Değer İki Entegrasyon

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Bu yazı otomatik olarak çevrilmiştir. Orijinal için buraya tıklayın.

Aspire 13.2 dikkatinizi çekmeye değer iki yeni veritabanı entegrasyonuyla yayımlandı: MongoDB Entity Framework Core ve Azure Data Lake Storage. Bir Aspire uygulamasında MongoDB ile EF Core kullanmak istiyorsanız veya uygun servis keşfiyle data lake iş yüklerini bağlamanız gerekiyorsa, bu sürüm her ikisini de sunuyor.

MongoDB, Aspire’da EF Core ile buluşuyor

En çok heyecanlandığım bu. Aspire bir süredir MongoDB’yi destekliyordu ama her zaman ham sürücüydü — EF Core yok, DbContext yok, belgelerinize karşı LINQ sorgusu yok. Artık MongoDB ile tam EF Core deneyimini, ayrıca Aspire’ın otomatik sağlık kontrolleri ve servis keşfini elde ediyorsunuz.

Kurulum, tipik Aspire desenidir. AppHost’unuzda:

var mongodb = builder.AddMongoDB("mongodb")
 .WithDataVolume()
 .WithLifetime(ContainerLifetime.Persistent);

var apiService = builder.AddProject<Projects.ApiService>("api")
 .WithReference(mongodb);

Ardından tüketen projenize EF Core entegrasyonunu ekleyin:

dotnet add package Aspire.MongoDB.EntityFrameworkCore

Ve DbContext‘inizi kaydedin:

builder.AddMongoDbContext<MyDbContext>("mongodb", "mydb");

Oradan itibaren standart EF Core. Varlıklarınızı tanımlayın, DbContext‘inizi herhangi bir sağlayıcıyla kullandığınız gibi kullanın. Entegrasyon, bağlantı havuzlamasını, OpenTelemetry izlerini ve sağlık kontrollerini arka planda yönetir.

Ham sürücüyle MongoDB kullanan ve bağlantı dizelerini manuel olarak ayarlayan .NET geliştiricileri için bu, güzel bir yaşam kalitesi yükseltmesi. Aspire’ın servis keşfini kaybetmeden tam EF Core soyutlamasını elde ediyorsunuz.

Azure Data Lake Storage katılıyor

İkinci büyük ekleme, Azure Data Lake Storage (ADLS) entegrasyonu. Veri pipeline’ları, ETL süreçleri veya analitik platformlar geliştiriyorsanız, artık Data Lake kaynaklarını herhangi bir diğer Aspire bağımlılığını bağladığınız gibi bağlayabilirsiniz.

AppHost’ta:

var storage = builder.AddAzureStorage("azure-storage");
var dataLake = storage.AddDataLake("data-lake");
var fileSystem = storage.AddDataLakeFileSystem("data-lake-file-system");

var analyticsService = builder.AddProject<Projects.AnalyticsService>("analytics")
 .WithReference(dataLake)
 .WithReference(fileSystem);

Tüketen projede:

builder.AddAzureDataLakeServiceClient("data-lake");
builder.AddAzureDataLakeFileSystemClient("data-lake-file-system");

Manuel bağlantı dizesi yönetimi yok, kimlik bilgisi avcılığı yok. Aspire kaynakları sağlar ve enjekte eder. Hem operasyonel veriye hem de analitik iş yüklerine dokunan cloud-native .NET uygulamaları geliştiriyorsanız, bu data lake’i Aspire modelinde birinci sınıf vatandaş gibi hissettiriyor.

Önemli küçük düzeltmeler

Manşet özelliklerin ötesinde, dikkate değer birkaç yaşam kalitesi iyileştirmesi var:

MongoDB bağlantı dizesi düzeltmesi — veritabanı adından önce eğik çizgi artık doğru şekilde işleniyor. Bunun etrafından dolaşıyorsanız, o geçici çözümü kaldırabilirsiniz
SQL Server dışa aktarmaları — Aspire.Hosting.SqlServer artık daha ince ayarlı kontrol için ek sunucu yapılandırma seçenekleri dışa aktarıyor
Emülatör güncellemeleri — ServiceBus emülatörü 2.0.0, App Configuration emülatörü 1.0.2 ve CosmosDB’nin önizleme emülatörü artık bir hazır olma kontrolü içeriyor
Azure Managed Redis — artık varsayılan olarak rediss:// (Redis Secure) kullanıyor; bağlantılar kutudan çıktığı gibi şifreli

Son madde ince ama önemli — varsayılan olarak şifreli Redis, üretimde yapılandırılacak bir şey daha az demek.

Sonuç

Aspire 13.2 artımlı bir sürüm, ancak MongoDB EF Core ve Data Lake entegrasyonları gerçek boşlukları dolduruyor. Aspire’da MongoDB için uygun EF Core desteğini bekliyorsanız veya Data Lake’in birinci sınıf bağımlılık olmasına ihtiyacınız varsa, 13.2’ye yükseltin ve bir deneyin. aspire add komutu ihtiyacınız olan her şeyi iskelet haline getiriyor.

Daha fazla ayrıntı için tam sürüm notlarını okuyun ve tam liste için entegrasyon galerisine göz atın.

Azure Smart Tier Genel Kullanıma Açıldı — Yaşam Döngüsü Kuralları Olmadan Otomatik Blob Depolama Maliyet Optimizasyonu

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Bu yazı otomatik olarak çevrilmiştir. Orijinal için buraya tıklayın.

Azure Blob Storage yaşam döngüsü politikalarını ayarlamak için zaman harcadınız ve ardından erişim kalıpları değişince bunların çöktüğünü izlediyseniz, bu yazı sizin için. Microsoft, Azure Blob ve Data Lake Storage için smart tier’ın genel kullanıma açıldığını duyurdu — nesneleri gerçek kullanıma göre hot, cool ve cold katmanları arasında otomatik olarak taşıyan, tam yönetimli bir katmanlama özelliği.

Smart tier aslında ne yapıyor

Konsept basit: smart tier, depolama hesabınızdaki her nesnenin son erişim zamanını sürekli değerlendiriyor. Sık erişilen veriler hot’ta kalıyor, etkin olmayan veriler 30 gün sonra cool’a geçiyor ve ardından 60 gün sonra cold’a iniyor. Verilere tekrar erişildiğinde hemen hot’a geri yükseltiliyor. Döngü yeniden başlıyor.

Yapılandırılacak yaşam döngüsü kuralı yok. Erişim kalıbı tahmini yok. Manuel ayarlama yok.

Önizleme sürecinde Microsoft, smart tier tarafından yönetilen kapasitenin %50’sinden fazlasının gerçek erişim kalıplarına göre otomatik olarak daha soğuk katmanlara geçtiğini bildirdi. Büyük depolama hesapları için bu anlamlı bir maliyet azalması.

Bu .NET geliştiricileri için neden önemli

Günlük, telemetri, analitik veri veya büyüyen herhangi bir veri kümesi üreten uygulamalar geliştiriyorsanız — ki dürüst olmak gerekirse kim üretmiyor — depolama maliyetleri hızla artıyor. Geleneksel yaklaşım, yaşam döngüsü yönetim politikaları yazmak, bunları test etmek ve uygulamanızın erişim kalıpları değiştiğinde yeniden ayarlamaktı. Smart tier bu iş akışının tamamını ortadan kaldırıyor.

Bunun işe yaradığı pratik senaryolar:

Uygulama telemetrisi ve günlükleri — hata ayıklama sırasında hot, birkaç hafta sonra nadiren erişilen
Veri pipeline’ları ve ETL çıktıları — işleme sırasında yoğun erişim, ardından çoğunlukla cold
Kullanıcı tarafından oluşturulan içerik — son yüklemeler hot, eski içerik zamanla soğuyor
Yedekleme ve arşiv verileri — uyumluluk için ara sıra erişilen, çoğunlukla atıl

Kurulum

Smart tier’ı etkinleştirmek tek seferlik bir yapılandırma:

Yeni hesaplar: Depolama hesabı oluşturma sırasında varsayılan erişim katmanı olarak smart tier’ı seçin (bölgesel yedeklilik gereklidir)
Mevcut hesaplar: Blob erişim katmanını mevcut varsayılandan smart tier’a geçirin

128 KiB’den küçük nesneler hot’ta kalır ve izleme ücretine tabi değildir. Diğer her şey için katman geçiş ücreti, erken silme ücreti ve veri alma maliyeti olmaksızın standart hot/cool/cold kapasite ücretleri ödüyorsunuz. Nesne başına aylık bir izleme ücreti orkestrasyon maliyetini karşılıyor.

Bilmeniz gereken takas

Smart tier’ın katmanlama kuralları sabit (30 gün → cool, 90 gün → cold). Belirli bir iş yükü için 7 günde cool’a geçmek gibi özel eşikler ihtiyacınız varsa, yaşam döngüsü kuralları hâlâ doğru seçenek. İkisini de karıştırmayın: smart tier tarafından yönetilen nesnelerde yaşam döngüsü kurallarından kaçının, çünkü çakışabilirler.

Sonuç

Bu devrim niteliğinde değil, ama gerçek bir operasyonel baş ağrısını çözüyor. Büyüyen blob depolama hesaplarını yönetiyorsanız ve yaşam döngüsü politikalarını korumaktan bıktıysanız, smart tier’ı etkinleştirin ve Azure’un üstlenmesine izin verin. Neredeyse tüm bölgesel genel bulut bölgelerinde bugün itibariyle kullanılabilir.

Azure'da AI Ajanlarınızı Nerede Barındırmalısınız? Pratik Bir Karar Rehberi

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Bu yazı otomatik olarak çevrilmiştir. Orijinal için buraya tıklayın.

Şu an .NET ile AI ajanları geliştiriyorsanız, muhtemelen bunu fark etmişsinizdir: Azure’da bunları barındırmanın pek çok yolu var. Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents — ve gerçekten birini seçmeniz gerekene kadar hepsi makul görünüyor. Microsoft, bunu netleştiren Azure AI ajan barındırma için kapsamlı bir rehber yayımladı ve ben bunu pratik bir .NET geliştirici perspektifinden ele almak istiyorum.

Altı seçeneğe genel bakış

Ortamı şöyle özetlerim:

Seçenek	En iyi kullanım	Siz yönetirsiniz
Container Apps	K8s karmaşıklığı olmadan tam container kontrolü	Gözlemlenebilirlik, durum, yaşam döngüsü
AKS	Kurumsal uyumluluk, çok kümeli, özel ağ	Her şey (bu onun amacı)
Azure Functions	Olay odaklı, kısa süren ajan görevleri	Çok az — gerçek serverless
App Service	Basit HTTP ajanları, öngörülebilir trafik	Dağıtım, ölçeklendirme yapılandırması
Foundry Agents	Portal/SDK aracılığıyla kod gerektirmeyen ajanlar	Neredeyse hiçbir şey
Foundry Hosted Agents	Yönetilen altyapıyla özel framework ajanları	Yalnızca ajan kodunuz

İlk dördü genel amaçlı işlem — üzerlerinde ajan çalıştırabilirsiniz, ancak bunlar bunun için tasarlanmadı. Son ikisi ajan doğasında: konuşmaları, araç çağrılarını ve ajan yaşam döngülerini birinci sınıf kavramlar olarak anlıyorlar.

Foundry Hosted Agents — .NET ajan geliştiricileri için tatlı nokta

İşte dikkatimi çeken kısım. Foundry Hosted Agents tam ortada duruyor: kendi kodunuzu çalıştırma esnekliğini alıyorsunuz (Semantic Kernel, Agent Framework, LangGraph — her neyse), ancak platform altyapıyı, gözlemlenebilirliği ve konuşma yönetimini üstleniyor.

Kilit parça Hosting Adapter — ajan framework’ünüzü Foundry platformuna köprüleyen ince bir soyutlama katmanı. Microsoft Agent Framework için şöyle görünüyor:

from azure.ai.agentserver.agentframework import from_agent_framework

agent = ChatAgent(
 chat_client=AzureAIAgentClient(...),
 instructions="You are a helpful assistant.",
 tools=[get_local_time],
)

if __name__ == "__main__":
 from_agent_framework(agent).run()

Barındırma hikayenizin tamamı bu. Adapter, protokol çevirisini, server-sent events aracılığıyla streaming’i, konuşma geçmişini ve OpenTelemetry izlemeyi otomatik olarak hallediyor. Özel middleware yok, manuel bağlantı yok.

Dağıtım gerçekten basit

Daha önce Container Apps’e ajan dağıttım ve çalışıyor, ancak durum yönetimi ve gözlemlenebilirlik için çok fazla yapıştırıcı kod yazıyorsunuz. Hosted Agents ve azd ile dağıtım şöyle:

# AI agent uzantısını yükle
azd ext install azure.ai.agents

# Bir şablondan başlat
azd ai agent init

# Derle, gönder, dağıt — tamam
azd up

Tek azd up komutu, container’ınızı derliyor, ACR’a gönderiyor, Foundry projesini oluşturuyor, model endpoint’lerini dağıtıyor ve ajanınızı başlatıyor. Beş adım tek komuta indirgeniyor.

Yerleşik konuşma yönetimi

Bu, üretimde en çok zaman kazandıran kısım. Kendi konuşma durum deposunuzu oluşturmak yerine, Hosted Agents bunu doğal olarak hallediyor:

# Kalıcı bir konuşma oluştur
conversation = openai_client.conversations.create()

# İlk tur
response1 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Unutma: favori numaram 42.",
)

# İkinci tur — bağlam korunuyor
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Favori numamı 10 ile çarp.",
)

Redis yok. Cosmos DB oturum deposu yok. Mesaj serileştirme için özel middleware yok. Platform sadece hallediyor.

Karar çerçevem

Altı seçeneğin tamamını inceledikten sonra, işte hızlı zihinsel modelim:

Sıfır altyapı mı istiyorsunuz? → Foundry Agents (portal/SDK, container yok)
Özel ajan kodunuz var ama yönetilen barındırma mı istiyorsunuz? → Foundry Hosted Agents
Olay odaklı, kısa ömürlü ajan görevlerine mi ihtiyacınız var? → Azure Functions
K8s olmadan maksimum container kontrolü mü istiyorsunuz? → Container Apps
Katı uyumluluk ve çok kümeli mimariye mi ihtiyacınız var? → AKS
Öngörülebilir trafikli basit bir HTTP ajanınız mı var? → App Service

Semantic Kernel veya Microsoft Agent Framework ile geliştiren çoğu .NET geliştirici için, Hosted Agents muhtemelen doğru başlangıç noktası. Sıfıra ölçekleme, yerleşik OpenTelemetry, konuşma yönetimi ve framework esnekliği alıyorsunuz — Kubernetes yönetmeden veya kendi gözlemlenebilirlik yığınınızı bağlamadan.

Özet

Azure’daki ajan barındırma ortamı hızla olgunlaşıyor. Bugün yeni bir AI ajan projesi başlatıyorsanız, alışkanlıkla Container Apps veya AKS’e uzanmadan önce Foundry Hosted Agents’ı ciddi olarak değerlendirirdim. Yönetilen altyapı gerçek zaman kazandırıyor ve hosting adapter modeli, framework seçiminizi korumanıza olanak tanıyor.

Çalışan örnekler için Microsoft’ın tam rehberine ve Foundry Samples reposuna göz atın.

KubeCon Avrupa 2026: .NET Geliştiricilerinin Gerçekten Önemsemesi Gerekenler

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

Bu yazı otomatik olarak çevrilmiştir. Orijinal için buraya tıklayın.

Büyük bir duyuru yazısı yayımlandığında ve “harika, ama bu benim için ne değiştiriyor ki” diye düşünerek kaydırma yaptığınız o hissi bilirsiniz, değil mi? Ben her KubeCon sezonunda böyle hissediyorum.

Microsoft, KubeCon Avrupa 2026 tam özetini yayımladı — bizzat Brendan Burns tarafından yazıldı — ve dürüst olmak gerekirse? Burada gerçek bir içerik var. Yalnızca özellik onay kutuları değil, üretimdeki çalışma biçiminizi değiştiren türden operasyonel iyileştirmeler.

.NET geliştiricileri olarak bizim için gerçekten önemli olanları ele alayım.

Service Mesh Yükü Olmadan mTLS

Service mesh’ler hakkında şunu söylemek gerekir: herkes güvenlik garantilerini istiyor, kimse operasyonel yükü istemiyor. AKS nihayet bu boşluğu kapatıyor.

Azure Kubernetes Application Network, ağır sidecar’lı bir mesh dağıtmadan karşılıklı TLS, uygulama farkında yetkilendirme ve trafik telemetrisi sunuyor. Advanced Container Networking Services’deki Cilium mTLS ile birleşince, kimlik yönetimi için X.509 sertifikaları ve SPIRE kullanan şifreli pod-to-pod iletişimi elde ediyorsunuz.

Pratikte ne anlama geliyor: arka plan worker’larıyla konuşan ASP.NET Core API’leriniz, birbirini çağıran gRPC servisleriniz — sıfır uygulama kodu değişikliğiyle ağ düzeyinde şifreli ve kimlik doğrulamalı. Bu büyük bir şey.

ingress-nginx‘ten geçiş yapan ekipler için tam Kubernetes Gateway API desteğiyle Application Routing with Meshless Istio da mevcut. Sidecar yok. Standart tabanlı. Ve kademeli geçiş için ingress2gateway araçlarını gönderdiler.

Sonradan Düşünülmemiş GPU Gözlemlenebilirliği

.NET servislerinizin yanında AI çıkarımı çalıştırıyorsanız (ve dürüst olalım, kim başlamıyor?), GPU izleme kör noktasına çarpmış olabilirsiniz. Harika CPU/bellek dashboard’larınız olur ve ardından… manuel exporter bağlantıları olmadan GPU’lar için hiçbir şey.

AKS artık GPU metriklerini yönetilen Prometheus ve Grafana’ya yerel olarak sunuyor. Aynı yığın, aynı dashboard’lar, aynı uyarı pipeline’ı. Özel exporter yok, üçüncü taraf ajan yok.

Ağ tarafında, tek tıklamalı Azure Monitor deneyimiyle HTTP, gRPC ve Kafka trafiği için akış başına görünürlük eklediler. IP’ler, portlar, iş yükleri, akış yönü, politika kararları — hepsi yerleşik dashboard’larda.

Ve beni iki kez baktıran şu oldu: agentic container networking kümenizin ağ durumu hakkında doğal dil soruları sorabileceğiniz bir web UI ekliyor. “Pod X neden servis Y’ye ulaşamıyor?” → canlı telemetriden salt okunur tanılamalar. Gece 2’de gerçekten kullanışlı.

PhD Gerektirmeyen Kümeler Arası Ağ

Multi-cluster Kubernetes, tarihsel olarak “kendi ağ yapıştırıcınızı getirin” deneyimiydi. Azure Kubernetes Fleet Manager artık yönetilen Cilium cluster mesh üzerinden kümeler arası ağ sunuyor:

AKS kümeleri arasında birleşik bağlantı
Kümeler arası keşif için global servis kaydı
Merkezi olarak yönetilen, küme başına tekrarlanmayan konfigürasyon

Dayanıklılık veya uyumluluk için bölgeler arasında .NET mikro servisler çalıştırıyorsanız, bu çok sayıda kırılgan özel yapıştırıcının yerini alıyor. West Europe’daki A Servisi, tutarlı yönlendirme ve güvenlik politikalarıyla mesh üzerinden East US’deki B Servisini keşfedebilir ve çağırabilir.

Cesaret Gerektirmeyen Yükseltmeler

Dürüst olalım — üretimdeki Kubernetes yükseltmeleri streslidir. “Yükselt ve umut et” pek çok ekip için fiili strateji olmuştur ve kümelerin sürümlerin gerisinde kalmasının ana nedenidir.

İki yeni özellik bunu değiştiriyor:

Mavi-yeşil agent pool yükseltmeleri yeni konfigürasyonla paralel bir node pool oluşturur. Davranışı doğrulayın, trafiği kademeli olarak kaydırın ve temiz bir geri alma yolu tutun. Üretim node’larında artık yerinde mutasyon yok.

Agent pool rollback, bir yükseltme ters gittiğinde kümeyi yeniden oluşturmadan bir node pool’u önceki Kubernetes sürümüne ve node imajına döndürmenizi sağlar.

Birlikte ele alındığında, bunlar nihayet operatörlere yükseltme yaşam döngüsü üzerinde gerçek kontrol veriyor. .NET ekipleri için bu önemlidir çünkü platform hızı, yeni runtime’ları, güvenlik yamalarını ve ağ özelliklerini ne kadar hızlı benimseyebileceğinizi doğrudan belirler.

AI İş Yükleri Birinci Sınıf Kubernetes Vatandaşı Oluyor

Upstream açık kaynak çalışması da eşit derecede önemli. Dynamic Resource Allocation (DRA) Kubernetes 1.36’da GA’ya geçti, GPU planlamasını bir geçici çözüm yerine gerçek anlamda birinci sınıf bir özellik haline getirdi.

İzlemeye değer birkaç proje:

Proje	Ne Yapıyor
AI Runway	Çıkarım için ortak Kubernetes API’si — K8s bilmeden model dağıtın, HuggingFace keşfi ve maliyet tahminleriyle
HolmesGPT	Cloud-native için agentic sorun giderme — artık CNCF Sandbox projesi
Dalec	SBOM üretimiyle bildirimsel container imaj oluşturma — derleme aşamasında daha az CVE

Yön açık: .NET API’niz, Semantic Kernel orkestrasyon katmanınız ve çıkarım iş yüklerinizin hepsi tek tutarlı bir platform modelinde çalışmalı. Oraya doğru ilerliyoruz.

Bu Hafta Nereden Başlardım

Bu değişiklikleri ekibiniz için değerlendiriyorsanız, işte dürüst öncelik listem:

Önce gözlemlenebilirlik — üretim dışı bir kümede GPU metriklerini ve ağ akış günlüklerini etkinleştirin. Neyi kaçırdığınızı görün.
Mavi-yeşil yükseltmeleri deneyin — bir sonraki üretim kümesi yükseltmenizden önce rollback iş akışını test edin. Sürece güven inşa edin.
Kimlik farkında ağı pilot edin — bir dahili servis yolu seçin ve Cilium ile mTLS’i etkinleştirin. Yükü ölçün (spoiler: minimumdur).
Fleet Manager’ı değerlendirin — ikiden fazla küme çalıştırıyorsanız, kümeler arası ağ azaltılan özel yapıştırıcıyla kendini amorti eder.

Küçük deneyler, hızlı geri bildirim. Her zaman doğru hamle budur.

Son Söz

KubeCon duyuruları bunaltıcı olabiliyor, ancak bu grup gerçekten AKS’teki .NET ekipleri için iğneyi hareket ettiriyor. Mesh yükü olmadan daha iyi ağ güvenliği, gerçek GPU gözlemlenebilirliği, daha güvenli yükseltmeler ve daha güçlü AI altyapısı temelleri.

Halihazırda AKS’teyseniz, bu operasyonel temelinizi sıkılaştırmak için harika bir an. .NET iş yüklerini Kubernetes’e taşımayı planlıyorsanız — platform önemli ölçüde daha üretim hazır hale geldi.