Cloud-Native | The .NET Blog

كتابة Hooks في azd بـ Python وTypeScript و.NET: وداعًا لسكريبتات Shell

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

تمت ترجمة هذا المنشور تلقائيًا. للاطلاع على النسخة الأصلية، انقر هنا.

إن كنت قد امتلكت مشروعًا بالكامل بـ .NET واضطررت رغم ذلك إلى كتابة سكريبتات Bash لـ hooks في azd، فأنت تعرف هذا الألم. لماذا التبديل إلى صياخة shell في خطوة pre-provisioning بينما كل شيء آخر في المشروع مكتوب بـ C#؟

هذا الإحباط لديه الآن حل رسمي. أطلقت Azure Developer CLI دعم متعدد اللغات لـ hooks، وهو بالضبط بقدر ما يبدو جيدًا.

ما هي الـ Hooks

الـ Hooks هي سكريبتات تعمل في نقاط حيوية من دورة حياة azd — قبل provisioning، وبعد deployment، والمزيد. تُعرَّف في azure.yaml وتتيح حقن منطق مخصص دون تعديل الـ CLI.

في السابق، دُعم فقط Bash وPowerShell. الآن يمكن استخدام Python أو JavaScript أو TypeScript أو .NET — ويتولى azd الباقي تلقائيًا.

كيف يعمل الاستدلال

ما عليك سوى الإشارة إلى ملف وسيستنتج azd اللغة من الامتداد:

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

لا إعداد إضافي. إذا كان الامتداد غامضًا، يمكنك إضافة kind: python (أو اللغة المناسبة) صراحةً.

تفاصيل مهمة حسب اللغة

Python

ضع requirements.txt أو pyproject.toml بجانب السكريبت (أو في أي دليل أعلى). سينشئ azd بيئة افتراضية تلقائيًا، ويثبت التبعيات، ويشغل السكريبت.

JavaScript وTypeScript

نفس النمط — ضع package.json بالقرب من السكريبت وسيشغل azd أولاً npm install. بالنسبة لـ TypeScript يستخدم npx tsx دون خطوة تجميع ودون tsconfig.json.

.NET

وضعان متاحان:

وضع المشروع: إذا كان هناك .csproj بجانب السكريبت، سيشغل azd تلقائيًا dotnet restore وdotnet build.
وضع الملف الواحد: في .NET 10+ يمكن تشغيل ملفات .cs المستقلة مباشرةً عبر dotnet run script.cs. لا حاجة لملف مشروع.

إعداد خاص بكل منفذ

تدعم كل لغة كتلة config اختيارية:

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

لماذا يهم هذا لمطوري .NET

كانت الـ hooks آخر مكان في مشروع قائم على azd يجبر على تغيير اللغة. الآن يمكن لكامل pipeline النشر — من كود التطبيق إلى lifecycle hooks — أن يعيش في لغة واحدة. يمكنك إعادة استخدام أدوات .NET الموجودة في hooks، والإشارة إلى مكتبات مشتركة، والتخلص من صيانة سكريبتات shell.

خلاصة

أحد تلك التغييرات التي تبدو صغيرة لكنها تزيل الكثير من الاحتكاك اليومي مع azd. دعم متعدد اللغات لـ hooks متاح الآن — تحقق من المنشور الرسمي للحصول على التوثيق الكامل.

Aspire 13.2 يضيف MongoDB EF Core وAzure Data Lake — تكاملان يستحقان التجربة

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

تمت ترجمة هذا المقال تلقائياً. للنسخة الأصلية، انقر هنا.

صدر Aspire 13.2 للتو مع تكاملَين جديدَين لقواعد البيانات يستحقان اهتمامك: MongoDB Entity Framework Core وAzure Data Lake Storage. إذا كنت تريد استخدام EF Core مع MongoDB في تطبيق Aspire، أو تحتاج إلى ربط أعباء عمل data lake مع سرد خدمات صحيح، فهذا الإصدار يقدّم الاثنين.

MongoDB يلتقي بـ EF Core في Aspire

هذا هو ما أنا أكثر حماساً له. دعمت Aspire MongoDB لفترة، لكنه كان دائماً المشغّل الخام — لا EF Core، ولا DbContext، ولا استعلامات LINQ مقابل مستنداتك. الآن تحصل على تجربة EF Core الكاملة مع MongoDB، بالإضافة إلى فحوصات الصحة التلقائية وسرد الخدمات من Aspire.

الإعداد يتبع نمط Aspire المعتاد. في AppHost:

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

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

ثم في مشروعك المُستهلِك، أضف تكامل EF Core:

dotnet add package Aspire.MongoDB.EntityFrameworkCore

وسجّل DbContext الخاص بك:

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

من هنا، الأمر EF Core قياسي. عرّف كياناتك، استخدم DbContext كما تفعل مع أي مزوّد آخر. يعالج التكامل تجميع الاتصالات وتتبعات OpenTelemetry وفحوصات الصحة خلف الكواليس.

لمطوّري .NET الذين استخدموا MongoDB مع المشغّل الخام وربطوا سلاسل الاتصال يدوياً، هذا تحسين ملموس في جودة الحياة. تحصل على تجريد EF Core الكامل دون فقدان سرد خدمات Aspire.

Azure Data Lake Storage ينضم إلى الحفلة

الإضافة الكبيرة الثانية هي تكامل Azure Data Lake Storage (ADLS). إذا كنت تبني مسارات بيانات أو عمليات ETL أو منصات تحليلات، يمكنك الآن ربط موارد Data Lake بنفس الطريقة التي تربط بها أي تبعية Aspire أخرى.

في AppHost:

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);

في المشروع المُستهلِك:

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

لا إدارة يدوية لسلاسل الاتصال، ولا بحث عن بيانات الاعتماد. تُوفّر Aspire الموارد وتحقنها. لمن يبنون تطبيقات .NET سحابية أصلية تلمس كلاً من البيانات التشغيلية وأعباء عمل التحليلات، يجعل هذا data lake مواطناً من الدرجة الأولى في نموذج Aspire.

الإصلاحات الصغيرة التي تهمّ

بعيداً عن الميزات الرئيسية، هناك بعض تحسينات جودة الحياة التي تستحق الذكر:

إصلاح سلسلة اتصال MongoDB — الشرطة المائلة للأمام قبل اسم قاعدة البيانات تُعالَج الآن بشكل صحيح. إذا كنت تعمل حول هذه المشكلة، يمكنك إزالة الحل البديل
تصدير SQL Server — يُصدّر Aspire.Hosting.SqlServer الآن خيارات إعداد خادم إضافية للتحكم الدقيق
تحديثات المحاكيات — محاكي ServiceBus 2.0.0، ومحاكي App Configuration 1.0.2، والمحاكي التجريبي لـ CosmosDB يتضمن الآن فحص الجاهزية
Azure Managed Redis — يُعيَّن الآن افتراضياً إلى rediss:// (Redis Secure)، لذا الاتصالات مشفّرة بشكل افتراضي

ذلك الأخير دقيق لكن مهمّ — Redis المشفّر افتراضياً يعني شيئاً أقل للإعداد في الإنتاج.

خلاصة القول

Aspire 13.2 إصدار تدريجي، لكن تكاملَي MongoDB EF Core وData Lake يسدّان فجوات حقيقية. إذا كنت تنتظر دعماً صحيحاً لـ EF Core مع MongoDB في Aspire، أو احتجت Data Lake أن يكون تبعية من الدرجة الأولى، قم بالترقية إلى 13.2 وجرّبهما. يُسقّل الأمر aspire add كل ما تحتاجه.

اقرأ ملاحظات الإصدار الكاملة لمزيد من التفاصيل، واطّلع على معرض التكاملات للقائمة الكاملة.

Azure Smart Tier متاح للعموم — تحسين تكاليف تخزين Blob تلقائياً بدون قواعد دورة الحياة

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

تمت ترجمة هذا المقال تلقائياً. للنسخة الأصلية، انقر هنا.

إذا قضيت وقتاً في ضبط سياسات دورة حياة Azure Blob Storage ثم شاهدتها تنهار عندما تتغير أنماط الوصول، فهذا المقال يخصك. أعلنت Microsoft للتو عن التوافر العام لـ smart tier لـ Azure Blob وData Lake Storage — قدرة تدرّج مُدارة بالكامل تنقل الكائنات تلقائياً بين الطبقات الساخنة والباردة والمتجمدة بناءً على الاستخدام الفعلي.

ما الذي يفعله smart tier فعلاً

المفهوم واضح: يقيّم smart tier باستمرار وقت آخر وصول لكل كائن في حساب التخزين الخاص بك. البيانات التي يُوصل إليها بشكل متكرر تبقى في الطبقة الساخنة، وتنتقل البيانات غير النشطة إلى الطبقة الباردة بعد 30 يوماً، ثم إلى الطبقة المتجمدة بعد 60 يوماً أخرى. عند الوصول إلى البيانات مجدداً، تُرقَّى فوراً إلى الطبقة الساخنة. تبدأ الدورة من جديد.

لا قواعد دورة حياة للضبط. لا تنبؤات بأنماط الوصول. لا ضبط يدوي.

خلال فترة المعاينة، أفادت Microsoft بأن أكثر من 50% من السعة المُدارة بـ smart tier انتقلت تلقائياً إلى طبقات أبرد بناءً على أنماط الوصول الفعلية. هذا تخفيض ذو معنى في التكاليف لحسابات التخزين الكبيرة.

لماذا هذا مهم لمطوري .NET

إذا كنت تبني تطبيقات تولّد سجلات أو بيانات قياس أو بيانات تحليلية أو أي نوع من ممتلكات البيانات المتنامية — وبصراحة، من لا يفعل — فتكاليف التخزين تتراكم بسرعة. النهج التقليدي كان كتابة سياسات إدارة دورة الحياة واختبارها وإعادة ضبطها عندما تتغير أنماط الوصول في تطبيقك. يزيل smart tier سير العمل بأكمله.

بعض السيناريوهات العملية التي يساعد فيها هذا:

بيانات القياس والسجلات — ساخنة أثناء تصحيح الأخطاء، نادراً ما يُوصل إليها بعد أسابيع قليلة
مسارات البيانات ومخرجات ETL — يُوصل إليها بكثافة أثناء المعالجة، ثم تبرد في معظمها
المحتوى الذي ينشئه المستخدمون — التحميلات الحديثة ساخنة، والمحتوى الأقدم يبرد تدريجياً
بيانات النسخ الاحتياطي والأرشفة — يُوصل إليها أحياناً للامتثال، في الغالب خاملة

كيفية الإعداد

تفعيل smart tier إعداد لمرة واحدة:

الحسابات الجديدة: اختر smart tier كطبقة الوصول الافتراضية أثناء إنشاء حساب التخزين (يُشترط التكرار المنطقي)
الحسابات القائمة: بدّل طبقة الوصول للـ blob من افتراضيتك الحالية إلى smart tier

الكائنات الأصغر من 128 كيلوبايت تبقى في الطبقة الساخنة ولا تتحمل رسوم المراقبة. لكل شيء آخر، تدفع أسعار السعة القياسية للطبقات الساخنة والباردة والمتجمدة بدون رسوم انتقال الطبقات، ولا رسوم حذف مبكر، ولا تكاليف استرداد البيانات. رسوم مراقبة شهرية لكل كائن تغطي التنسيق.

المقايضة التي يجب معرفتها

قواعد التدرّج في smart tier ثابتة (30 يوماً إلى بارد، 90 يوماً إلى متجمد). إذا احتجت إلى عتبات مخصصة — مثلاً الانتقال إلى البارد بعد 7 أيام لحمل عمل محدد — فقواعد دورة الحياة هي الحل المناسب. ولا تخلط بينهما: تجنب استخدام قواعد دورة الحياة على الكائنات المُدارة بـ smart tier، إذ يمكن أن تتعارض.

خلاصة القول

هذا ليس ثورياً، لكنه يحل صداعاً تشغيلياً حقيقياً. إذا كنت تدير حسابات blob storage متنامية وتعبت من صيانة سياسات دورة الحياة، فعّل smart tier ودع Azure يتولى الأمر. إنه متاح اليوم في جميع مناطق السحابة العامة المنطقية تقريباً.

أين تستضيف وكلاء الذكاء الاصطناعي على Azure؟ دليل عملي للقرار

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

تمت ترجمة هذا المقال تلقائياً. للنسخة الأصلية، انقر هنا.

إن كنت تبني وكلاء ذكاء اصطناعي بـ .NET في الوقت الراهن، ربما لاحظت شيئاً: ثمة الكثير من طرق استضافتها على Azure. Container Apps، وAKS، وFunctions، وApp Service، وFoundry Agents، وFoundry Hosted Agents — وكلها تبدو معقولة حتى تحتاج فعلاً إلى اختيار واحدة. نشرت Microsoft للتو دليلاً شاملاً لاستضافة وكلاء Azure AI يوضّح هذا الأمر، وأريد تحليله من منظور مطوّر .NET عملي.

الخيارات الستة في لمحة

إليك كيف أُلخّص المشهد:

الخيار	الأنسب لـ	أنت تُدير
Container Apps	التحكم الكامل في الحاويات دون تعقيد K8s	إمكانية المراقبة، الحالة، دورة الحياة
AKS	الامتثال للمؤسسات، متعدد المجموعات، شبكات مخصصة	كل شيء (هذا هو الهدف)
Azure Functions	المهام الوكيلة قصيرة الأمد المدفوعة بالأحداث	شبه لا شيء — خادم حقيقي بلا خوادم
App Service	وكلاء HTTP البسيطة، حركة المرور المتوقعة	النشر، إعداد التوسّع
Foundry Agents	وكلاء بدون كود عبر البوابة/SDK	شبه لا شيء
Foundry Hosted Agents	وكلاء بأُطر مخصصة مع بنية تحتية مُدارة	كود وكيلك فقط

الخيارات الأربعة الأولى هي حوسبة للأغراض العامة — يمكنك تشغيل وكلاء عليها، لكنها لم تُصمَّم لذلك. الخياران الأخيران وكيل-أصيل: يفهمان المحادثات ومكالمات الأدوات ودورات حياة الوكلاء كمفاهيم أولى.

Foundry Hosted Agents — النقطة الأمثل لمطوّري وكلاء .NET

ها هو ما لفت انتباهي. تقع Foundry Hosted Agents في المنتصف تماماً: تحصل على مرونة تشغيل كودك الخاص (Semantic Kernel، Agent Framework، LangGraph — ما تشاء) لكن المنصة تتولى إدارة البنية التحتية وإمكانية المراقبة وإدارة المحادثات.

القطعة الرئيسية هي Hosting Adapter — طبقة تجريد رفيعة تربط إطار وكيلك بمنصة Foundry. بالنسبة لـ Microsoft Agent Framework يبدو هكذا:

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()

هذه هي قصة استضافتك بالكامل. يتولى المحوّل ترجمة البروتوكول، والبثّ عبر server-sent events، وسجل المحادثات، وتتبع OpenTelemetry — كل ذلك تلقائياً. لا middleware مخصص، لا سباكة يدوية.

النشر بسيط بشكل حقيقي

نشرت وكلاء إلى Container Apps من قبل وتعمل، لكنك تنتهي بكتابة الكثير من كود الربط لإدارة الحالة وإمكانية المراقبة. مع Hosted Agents وـazd، يكون النشر:

# تثبيت إضافة وكلاء AI
azd ext install azure.ai.agents

# التهيئة من قالب
azd ai agent init

# بناء، رفع، نشر — انتهى
azd up

ذلك الأمر الواحد azd up يبني حاويتك، ويرفعها إلى ACR، ويُوفّر مشروع Foundry، ويُنشئ نقاط نهاية النماذج، ويُشغّل وكيلك. خمس خطوات في أمر واحد.

إدارة المحادثات المدمجة

هذا الجانب هو الذي يُوفّر أكثر الوقت في الإنتاج. بدلاً من بناء مخزن حالة محادثة خاص بك، تتولى Hosted Agents ذلك بشكل أصيل:

# إنشاء محادثة دائمة
conversation = openai_client.conversations.create()

# الدور الأول
response1 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Remember: my favorite number is 42.",
)

# الدور الثاني — السياق محفوظ
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

لا Redis. لا مخزن جلسات Cosmos DB. لا middleware مخصص لتسلسل الرسائل. المنصة تتولى الأمر ببساطة.

إطاري للقرار

بعد مراجعة الخيارات الستة جميعها، إليك نموذجي الذهني السريع:

هل تحتاج إلى بنية تحتية صفرية؟ ← Foundry Agents (بوابة/SDK، بلا حاويات)
هل لديك كود وكيل مخصص لكنك تريد استضافة مُدارة؟ ← Foundry Hosted Agents
هل تحتاج مهاماً وكيلة مدفوعة بالأحداث قصيرة الأمد؟ ← Azure Functions
هل تحتاج أقصى تحكم في الحاويات دون K8s؟ ← Container Apps
هل تحتاج امتثالاً صارماً ومتعدد المجموعات؟ ← AKS
هل لديك وكيل HTTP بسيط بحركة مرور متوقعة؟ ← App Service

لمعظم مطوّري .NET الذين يبنون بـ Semantic Kernel أو Microsoft Agent Framework، من المرجح أن تكون Hosted Agents نقطة البداية الصحيحة. تحصل على التوسّع إلى الصفر، وOpenTelemetry المدمج، وإدارة المحادثات، ومرونة الإطار — دون إدارة Kubernetes أو تمديد سلسلة إمكانية مراقبة خاصة بك.

خلاصة القول

مشهد استضافة الوكلاء على Azure ينضج بسرعة. إن كنت تبدأ مشروع وكيل ذكاء اصطناعي جديداً اليوم، أُوصي بجدية بالنظر في Foundry Hosted Agents قبل الوصول إلى Container Apps أو AKS من عادة. البنية التحتية المُدارة توفّر وقتاً حقيقياً، ونمط Hosting Adapter يتيح لك الحفاظ على اختيار إطارك.

اطّلع على الدليل الكامل من Microsoft ومستودع Foundry Samples للحصول على أمثلة عملية.

KubeCon أوروبا 2026: ما يجب أن يهتمّ به مطوّرو .NET فعلاً

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

تمت ترجمة هذا المقال تلقائياً. للنسخة الأصلية، انقر هنا.

تعرف ذلك الشعور حين يصدر منشور إعلانات ضخم وأنت تتصفحه تفكّر “رائع، لكن ما الذي يغيّره هذا فعلاً بالنسبة لي”؟ هذا بالضبط شعوري في كل موسم KubeCon.

نشرت Microsoft للتوّ ملخصها الكامل لـ KubeCon Europe 2026 — كتبه Brendan Burns بنفسه — وفي الحقيقة؟ ثمة مضمون حقيقي هنا. لا مجرد مربعات اختيار للميزات، بل تحسينات تشغيلية من النوع الذي يغيّر طريقة تشغيل الأشياء في الإنتاج.

دعني أُفصّل ما يهمّ فعلاً لنا كمطوّري .NET.

mTLS دون ضريبة service mesh

إليك الحقيقة بشأن شبكات الخدمات: الجميع يريد ضمانات الأمان، ولا أحد يريد الأعباء التشغيلية. AKS يسدّ تلك الفجوة أخيراً.

Azure Kubernetes Application Network يمنحك TLS المتبادل، والتفويض الواعي بالتطبيق، وبيانات تتبع حركة المرور — دون نشر شبكة كاملة ثقيلة بالحاويات الجانبية. مدمجاً مع Cilium mTLS في Advanced Container Networking Services، تحصل على اتصال مشفّر بين الـ pods باستخدام شهادات X.509 وSPIRE لإدارة الهوية.

ما يعنيه هذا عملياً: واجهات ASP.NET Core APIs تتحدث إلى العمال الخلفيين، وخدمات gRPC تستدعي بعضها — كل ذلك مشفّر ومُتحقق من الهوية على مستوى الشبكة، بدون أي تغييرات في كود التطبيق. هذا ضخم.

للفرق التي تنقل من ingress-nginx، ثمة أيضاً Application Routing with Meshless Istio مع دعم كامل لـ Kubernetes Gateway API. لا حاويات جانبية. قائم على المعايير. وشحنوا أداة ingress2gateway للهجرة التدريجية.

إمكانية مراقبة GPU ليست مُلحقةً بعد الواقعة

إذا كنت تشغّل استدلال الذكاء الاصطناعي جنباً إلى جنب مع خدمات .NET (وبصراحة، من لا يبدأ في فعل ذلك؟)، فربما اصطدمت بنقطة عمياء في مراقبة GPU. كنت تحصل على لوحات معلومات رائعة للمعالج والذاكرة، ثم… لا شيء لـ GPUs دون تجهيز أدوات تصدير يدوياً.

AKS يعرض الآن مقاييس GPU بشكل أصلي إلى Prometheus وGrafana المُدارَين. نفس المنظومة، نفس لوحات المعلومات، نفس خط أنابيب التنبيه. لا أدوات تصدير مخصصة، لا وكلاء من جهات خارجية.

على صعيد الشبكة، أضافوا رؤية لكل تدفق لحركة HTTP وgRPC وKafka مع تجربة Azure Monitor بنقرة واحدة. عناوين IP، والمنافذ، وأحمال العمل، واتجاه التدفق، وقرارات السياسة — كل ذلك في لوحات معلومات مدمجة.

وإليك ما أوقفني مندهشاً: شبكات الحاويات الوكيلية تضيف واجهة ويب تتيح لك طرح أسئلة باللغة الطبيعية حول حالة شبكة مجموعتك. “لماذا لا يصل pod X إلى الخدمة Y؟” ← تشخيصات للقراءة فقط من بيانات تتبع حية. هذا مفيد فعلاً في الساعة الثانية صباحاً.

شبكة متعددة العناقيد لا تتطلب شهادة دكتوراه

كان Kubernetes متعدد العناقيد تاريخياً تجربة “أحضر معك الصمغ الشبكي الخاص بك”. يشحن Azure Kubernetes Fleet Manager الآن شبكة متعددة العناقيد عبر شبكة Cilium cluster mesh المُدارة:

اتصال موحّد عبر عناقيد AKS
سجل خدمات عالمي للاكتشاف متعدد العناقيد
تهيئة مُدارة مركزياً، لا تكرار لكل عنقود

إذا كنت تشغّل خدمات .NET المصغّرة عبر مناطق متعددة للمرونة أو الامتثال، فهذا يستبدل الكثير من التجهيزات المخصصة الهشّة. الخدمة A في West Europe تستطيع اكتشاف واستدعاء الخدمة B في East US عبر الشبكة، مع سياسات توجيه وأمان متسقة.

ترقيات لا تتطلب شجاعة

لنكن صريحين — ترقيات Kubernetes في الإنتاج مُجهِدة. “رقّي وتأمّل الخير” كانت الاستراتيجية الفعلية لفرق كثيرة جداً، وهي السبب الرئيسي في تخلّف العناقيد عن الإصدارات.

قدرتان جديدتان تُغيّران هذا:

ترقيات agent pool بالأزرق والأخضر تُنشئ pool عقد موازياً بالتهيئة الجديدة. تحقق من السلوك، وانقل حركة المرور تدريجياً، واحتفظ بمسار تراجع واضح. لا مزيد من التعديلات في المكان على عقد الإنتاج.

التراجع عن agent pool يتيح لك العودة بـ pool العقد إلى إصدار Kubernetes وصورة العقدة السابقة بعد ترقية فاشلة — دون إعادة بناء العنقود.

معاً، تمنح هذه القدرات المشغّلين أخيراً تحكماً حقيقياً في دورة حياة الترقية. لفرق .NET، هذا مهم لأن سرعة المنصة تُحدِّد مباشرةً مدى سرعة تبنّي بيئات التشغيل الجديدة وتصحيحات الأمان وقدرات الشبكة.

أحمال العمل بالذكاء الاصطناعي تصبح مواطنين من الدرجة الأولى في Kubernetes

العمل مفتوح المصدر في المنبع لا يقل أهمية. Dynamic Resource Allocation (DRA) وصل للإتاحة العامة في Kubernetes 1.36، مما يجعل جدولة GPU ميزة من الدرجة الأولى بدلاً من حلّ مؤقت.

عدة مشاريع تستحق المتابعة:

المشروع	ما يفعله
AI Runway	واجهة Kubernetes مشتركة للاستدلال — انشر النماذج دون معرفة K8s، مع اكتشاف HuggingFace وتقديرات التكلفة
HolmesGPT	تشخيص وكيلي لبيئات السحابة الأصيلة — أصبح الآن مشروع CNCF Sandbox
Dalec	إنشاء صور حاويات تصريحي مع توليد SBOM — ثغرات أمنية أقل في مرحلة البناء

الاتجاه واضح: يجب أن تعمل واجهة .NET API الخاصة بك، وطبقة تنسيق Semantic Kernel، وأحمال عمل الاستدلال جميعها على نموذج منصة متسق واحد. نحن في طريقنا إلى ذلك.

من أين أبدأ هذا الأسبوع

إذا كنت تُقيِّم هذه التغييرات لفريقك، فإليك قائمة الأولويات الصادقة:

إمكانية المراقبة أولاً — فعّل مقاييس GPU وسجلات تدفق الشبكة في عنقود غير الإنتاج. انظر ما الذي كنت تفتقده.
جرّب ترقيات الأزرق والأخضر — اختبر سير عمل التراجع قبل ترقية عنقود الإنتاج التالية. ابنِ الثقة في العملية.
جرّب الشبكة الواعية بالهوية — اختر مسار خدمة داخلي واحد وفعّل mTLS مع Cilium. قِس الأعباء الإضافية (تنبيه: إنها ضئيلة).
قيّم Fleet Manager — إذا كنت تشغّل أكثر من عنقودين، فإن الشبكة متعددة العناقيد تؤتي ثمارها في تقليل التجهيزات المخصصة.

تجارب صغيرة، تغذية راجعة سريعة. هذه دائماً هي الحركة الصحيحة.

خلاصة

إعلانات KubeCon قد تكون ساحقة، لكن هذه الدفعة تُحرِّك الإبرة فعلاً لفرق .NET على AKS. أمان شبكي أفضل دون أعباء شبكة الخدمات، وإمكانية مراقبة GPU حقيقية، وترقيات أكثر أماناً، وأسس بنية تحتية للذكاء الاصطناعي أقوى.

إذا كنت على AKS بالفعل، فهذه لحظة رائعة لتحسين مستوى عملياتك. وإذا كنت تخطط لنقل أحمال عمل .NET إلى Kubernetes — المنصة أصبحت للتوّ أكثر جاهزيةً للإنتاج بشكل ملموس.