مفاهيم Kubernetes الأساسية لخدمة Azure Kubernetes (AKS)

توضح هذه المقالة المفاهيم الأساسية لخدمة Azure Kubernetes Service (AKS)، وهي خدمة Kubernetes مدارة يمكنك استخدامها لنشر التطبيقات الحاوية وتشغيلها على نطاق واسع على Azure. يساعدك على التعرف على مكونات البنية الأساسية ل Kubernetes والحصول على فهم أعمق لكيفية عمل Kubernetes في AKS.

ما Kubernetes؟

Kubernetes هي منصة سريعة التطور تدير التطبيقات المستندة إلى الحاويات ومكونات الشبكات والتخزين المرتبطة بها. يركز Kubernetes على أحمال عمل التطبيق وليس مكونات البنية الأساسية. يوفر Kubernetes نهجاً تعريفياً لعمليات النشر، تدعمه مجموعة قوية من واجهات برمجة التطبيقات لعمليات الإدارة.

يمكنك إنشاء وتشغيل التطبيقات الحديثة والمحمولة والمستندة إلى الخدمات المصغرة باستخدام Kubernetes لتنسيق وإدارة توفر مكونات التطبيق. يدعم Kubernetes كلا من التطبيقات عديمة الحالة والحالة.

كمنصة مفتوحة، يسمح لك Kubernetes ببناء التطبيقات الخاصة بك مع لغة البرمجة المفضلة لديك، نظام التشغيل، والمكتبات، أو ناقل الرسائل. يمكن أن تتكامل أدوات التكامل المستمر والتسليم المستمر (CI/CD) مع Kubernetes لجدولة وتوزيع الإصدارات.

توفر AKS خدمة Kubernetes مدارة تقلل من تعقيد مهام النشر والإدارة الأساسية. تدير المنصة Azure وحدة التحكم AKS، وتدفع فقط مقابل عقد AKS التي تقوم بتشغيل التطبيقات الخاصة بك.

البنية الأساسية لمجموعة Kubernetes

ينقسم نظام مجموعة Kubernetes إلى مكونين أساسيين:

• وحدة التحكم، التي توفر خدمات Kubernetes الأساسية وتنسيق أحمال عمل التطبيق، و
• العقد، التي تقوم بتشغيل أحمال عمل التطبيق الخاص بك.

وحدة التحكم

عند إنشاء نظام مجموعة AKS، يقوم النظام الأساسي Azure تلقائيا بإنشاء وتكوين وحدة التحكم المقترنة به. يتم توفير مستوى التحكم المستأجر الفردي هذا دون أي تكلفة كمورد Azure مدار تم تجريده من المستخدم. تدفع فقط للعُقد المرفقة بنظام مجموعة AKS. توجد وحدة التحكم ومواردها فقط في المنطقة التي أنشأت فيها نظام المجموعة.

تتضمن وحدة التحكم مكونات Kubernetes الأساسية التالية:

المكون	‏‏الوصف
kube-apiserver	يعرض خادم API واجهات برمجة تطبيقات Kubernetes الأساسية ويوفر التفاعل لأدوات الإدارة، مثل kubectl أو لوحة معلومات Kubernetes.
etcd	etcd هو مخزن ذي قيمة مفتاحية عالية التوفر داخل Kubernetes يساعد في الحفاظ على حالة مجموعة Kubernetes وتكوينها.
kube-scheduler	عند إنشاء تطبيقات أو تغيير حجمها، يحدد المجدول العقد التي يمكنها تشغيل حمل العمل ويبدأ العقد المحددة.
kube-controller-manager	يشرف مدير وحدة التحكم على عدد من وحدات التحكم الأصغر التي تنفذ إجراءات مثل النسخ المتماثل للقرون ومعالجة عمليات العقدة.

ضع في اعتبارك أنه لا يمكنك الوصول مباشرة إلى وحدة التحكم. يتم تنسيق ترقيات مستوى التحكم والعقدة Kubernetes من خلال Azure CLI أو مدخل Microsoft Azure. لاستكشاف المشكلات المحتملة وإصلاحها، يمكنك مراجعة سجلات وحدة التحكم باستخدام Azure Monitor.

إشعار

إذا كنت ترغب في تكوين وحدة تحكم أو الوصول إليها مباشرة، يمكنك نشر مجموعة Kubernetes المدارة ذاتيا باستخدام موفر واجهة برمجة تطبيقات نظام المجموعة Azure.

الُعقد

لتشغيل التطبيقات والخدمات الداعمة، تحتاج إلى عقدة Kubernetes. تحتوي كل مجموعة AKS على عقدة واحدة على الأقل، وجهاز Azure الظاهري (VM) الذي يقوم بتشغيل مكونات عقدة Kubernetes، ووقت تشغيل الحاوية.

تتضمن العقد مكونات Kubernetes الأساسية التالية:

المكون	‏‏الوصف
kubelet	عامل Kubernetes الذي يعالج طلبات التزامن من مستوى التحكم جنباً إلى جنب مع جدولة الحاويات المطلوبة وتشغيلها.
kube-proxy	يعالج الوكيل الشبكات الظاهرية على كل عقدة، وتوجيه نسبة استخدام الشبكة وإدارة عناوين IP للخدمات والقرون.
وقت تشغيل الحاوية	يسمح وقت تشغيل الحاوية للتطبيقات الحاوية بتشغيل الموارد الأخرى والتفاعل معها، مثل الشبكة الظاهرية أو التخزين. لمزيد من المعلومات، راجع تكوين وقت تشغيل الحاوية.

يحدد حجم Azure VM للعقد وحدات المعالجة المركزية والذاكرة والحجم ونوع التخزين المتوفر، مثل SSD عالي الأداء أو HDD العادي. تخطيط حجم العقدة حول ما إذا كانت تطبيقاتك قد تتطلب كميات كبيرة من وحدة المعالجة المركزية والذاكرة أو التخزين عالي الأداء. توسيع عدد العُقد في نظام مجموعة AKS لتلبية الطلب. لمزيد من المعلومات حول التحجيم، راجع خيارات التحجيم للتطبيقات في AKS.

في AKS، تستند صورة الجهاز الظاهري لعقد نظام المجموعة إلى Ubuntu Linux أو Azure Linux أو Windows Server 2022. عند إنشاء نظام مجموعة AKS أو توسيع عدد العقد، يعمل النظام الأساسي Azure تلقائيًا على إنشاء وتكوين عدد الأجهزة الظاهرية المطلوبة. تتم فوترة عقد العامل كلأجهزة الظاهرية القياسية، لذلك يتم تطبيق أي خصومات على حجم الجهاز الظاهري، بما في ذلك حجوزات Azure، تلقائيا.

بالنسبة للأقراص المدارة، يتم تعيين حجم القرص الافتراضي والأداء وفقا لعدد وحدات SKU VM وvCPU المحددة. لمزيد من المعلومات، راجع تغيير حجم قرص OS الافتراضي.

إشعار

إذا كنت بحاجة إلى تكوين وتحكم متقدمين في وقت تشغيل حاوية عقدة Kubernetes ونظام التشغيل، فيمكنك توزيع مجموعة مُدارة ذاتياً باستخدام Cluster API Provider Azure.

تكوين نظام التشغيل

يدعم AKS Ubuntu 22.04 وAzure Linux 2.0 كنظام تشغيل العقدة (OS) للمجموعات مع Kubernetes 1.25 والإصدارات الأحدث. يمكن أيضا تحديد Ubuntu 18.04 في إنشاء تجمع العقدة لإصدارات Kubernetes 1.24 والإصدارات أدناه.

يدعم AKS Windows Server 2022 باعتباره نظام التشغيل الافتراضي لتجمعات عقد Windows في مجموعات مع Kubernetes 1.25 والإصدارات الأحدث. يمكن أيضا تحديد Windows Server 2019 عند إنشاء تجمع العقدة لإصدارات Kubernetes 1.32 والإصدارات الأحدث. يتم إيقاف Windows Server 2019 بعد أن يصل الإصدار 1.32 من Kubernetes إلى نهاية العمر الافتراضي ولا يتم دعمه في الإصدارات المستقبلية. لمزيد من المعلومات حول هذا الإيقاف، راجع ملاحظات إصدار AKS.

تكوين وقت تشغيل الحاوية

وقت تشغيل الحاوية هو برنامج ينفذ الحاويات ويدير صور الحاوية على العقدة. يساعد وقت التشغيل على تجريد استدعاءات sys أو وظائف خاصة بنظام التشغيل لتشغيل الحاويات على Linux أو Windows. بالنسبة إلى تجمعات عقد Linux، containerd يتم استخدام على Kubernetes الإصدار 1.19 والإصدارات الأحدث. بالنسبة لتجمعات عقد Windows Server 2019 و2022، containerd يتوفر بشكل عام وهو خيار وقت التشغيل الوحيد على الإصدار 1.23 من Kubernetes والإصدارات الأحدث. اعتبارا من مايو 2023، تم إيقاف Docker ولم يعد مدعوما. لمزيد من المعلومات حول هذا الإيقاف، راجع ملاحظات إصدار AKS.

Containerd هو وقت تشغيل حاوية أساسية متوافق مع OCI (مبادرة حاوية مفتوحة) يوفر الحد الأدنى من مجموعة الوظائف المطلوبة لتنفيذ الحاويات وإدارة الصور على العقدة. معcontainerd العقد المستندة إلى تجمعات العقد، يتحدث kubelet مباشرة إلى containerd استخدام المكون الإضافي CRI (واجهة وقت تشغيل الحاوية)، وإزالة القفزات الإضافية في تدفق البيانات بالمقارنة مع تنفيذ Docker CRI. على هذا النحو، ترى زمن انتقال بدء تشغيل pod أفضل واستخدام موارد أقل (وحدة المعالجة المركزية والذاكرة).

Containerd يعمل على كل إصدار GA من Kubernetes في AKS، في كل إصدار Kubernetes يبدأ من الإصدار 1.19، ويدعم جميع ميزات Kubernetes وAKS.

هام

مجموعات مع تجمعات عقدة Linux التي تم إنشاؤها على Kubernetes v1.19 أو أعلى افتراضيا إلى وقت تشغيل الحاوية containerd . تتلقى المجموعات ذات تجمعات العقد على إصدارات Kubernetes المدعومة سابقا Docker لوقت تشغيل الحاوية الخاصة بها. سيتم تحديث تجمعات عقد Linux إلى containerd بمجرد تحديث إصدار Kubernetes لتجمع العقدة إلى إصدار يدعم containerd.

containerd يتوفر بشكل عام للمجموعات التي تحتوي على تجمعات عقدة Windows Server 2019 و2022 وهو خيار وقت تشغيل الحاوية الوحيد ل Kubernetes v1.23 والإصدارات الأحدث. يمكنك الاستمرار في استخدام تجمعات عقد Docker ومجموعاتها على إصدارات أقدم من 1.23، ولكن لم يعد Docker مدعوما اعتبارا من مايو 2023. لمزيد من المعلومات، راجع إضافة تجمع عقدة Windows Server باستخدام containerd.

نوصي بشدة باختبار أحمال العمل الخاصة بك على تجمعات عقد AKS قبل containerd استخدام المجموعات مع إصدار Kubernetes الذي يدعم containerd تجمعات العقد الخاصة بك.

قيود/اختلافات containerd

• بالنسبة إلى containerd، نوصي باستخدام crictl كبديل ل Docker CLI لاستكشاف أخطاء القرون والحاويات وصور الحاوية على عقد Kubernetes وإصلاحها. لمزيد من المعلومات حول crictl، راجع خيارات الاستخدام العام وتكوين العميل.

  • Containerd لا يوفر الوظائف الكاملة ل Docker CLI. وهي متاحة لاستكشاف الأخطاء وإصلاحها فقط.
  • crictl يقدم طريقة عرض أكثر ملاءمة ل Kubernetes للحاويات، مع وجود مفاهيم مثل pods، وما إلى ذلك.

• Containerd إعداد التسجيل باستخدام تنسيق التسجيل الموحد cri . يحتاج حل التسجيل إلى دعم cri تنسيق التسجيل، مثل Azure Monitor for Containers.

• لم يعد بإمكانك الوصول إلى محرك Docker أو /var/run/docker.sockاستخدام Docker-in-Docker (DinD).

  • إذا قمت حاليا باستخراج سجلات التطبيق أو مراقبة البيانات من محرك Docker، فاستخدم Container Insights بدلا من ذلك. لا تدعم AKS تشغيل أي أوامر خارج النطاق على عقد العامل التي قد تتسبب في عدم الاستقرار.
  • لا نوصي بإنشاء صور أو استخدام محرك Docker مباشرة. لا يدرك Kubernetes تماما تلك الموارد المستهلكة، وهذه الأساليب تمثل العديد من المشكلات كما هو موضح هنا وهنا.

• عند إنشاء الصور، يمكنك الاستمرار في استخدام سير عمل بناء Docker الحالي كالمعتاد، إلا إذا كنت تقوم بإنشاء صور داخل نظام مجموعة AKS. في هذه الحالة، ضع في اعتبارك التبديل إلى النهج الموصى به لإنشاء الصور باستخدام مهام ACR، أو خيار أكثر أمانا في نظام المجموعة مثل Docker Buildx.

حجوزات الموارد

يستخدم AKS موارد العُقدة لمساعدة دالة العُقدة كجزء من نظام المجموعة. يمكن أن يؤدي هذا الاستخدام إلى حدوث تعارض بين إجمالي موارد العُقدة والموارد القابلة للتخصيص في AKS. تذكر هذه المعلومات عند إعداد الطلبات والحدود الخاصة بوحدات الجراب التي نشرها المستخدم.

للعثور على مورد العقدة القابل للتخصيص، يمكنك استخدام kubectl describe node الأمر :

kubectl describe node [NODE_NAME]

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

إشعار

استخدام وظائف AKS الإضافية، مثل Container Insights (OMS)، يستهلك موارد عقدة إضافية.

CPU

تعتمد وحدة المعالجة المركزية المحجوزة على نوع العقدة وتكوين نظام المجموعة، ما قد يسبب وحدة معالجة مركزية أقل قابلية للتخصيص بسبب تشغيل ميزات إضافية. يوضح الجدول التالي حجز وحدة المعالجة المركزية بالملليكور:

الذكرة الأساسية للمعالج على المضيف	1	2	4	8	16	32	64
Kube-reserved (ملليكورس)	60	100	140	180	260	420	740

الذاكرة

تتضمن الذاكرة المحجوزة في AKS مجموع قيمتين:

هام

معاينات AKS 1.29 في يناير 2024 وتتضمن تغييرات معينة على حجوزات الذاكرة. هذه التغييرات مفصلة في القسم التالي.

AKS 1.29 والإحدث

1. kubelet يحتوي daemon على قاعدة الإخلاء memory.available<100Mi بشكل افتراضي. تضمن هذه القاعدة أن العقدة لديها ما لا يقل عن 100Mi قابلة للتخصيص في جميع الأوقات. عندما يكون المضيف أقل من عتبة الذاكرة المتوفرة kubelet ، يقوم بتشغيل إنهاء أحد القرون قيد التشغيل ويحرر الذاكرة على الجهاز المضيف.

2. يتم تعيين معدل حجوزات الذاكرة وفقا للقيمة الأقل: 20 ميغابايت * الحد الأقصى للوحدات المدعومة على العقدة + 50 ميغابايت أو 25٪ من إجمالي موارد ذاكرة النظام.

   أمثلة:

   • إذا كان الجهاز الظاهري يوفر 8 غيغابايت من الذاكرة وتدعم العقدة ما يصل إلى 30 حاوية، فإن AKS تحتفظ ب 20 ميغابايت * 30 كحد أقصى من الجرابات + 50 ميغابايت = 650 ميغابايت ل kube المحجوزة. Allocatable space = 8GB - 0.65GB (kube-reserved) - 0.1GB (eviction threshold) = 7.25GB or 90.625% allocatable.
   • إذا كان الجهاز الظاهري يوفر 4 غيغابايت من الذاكرة وتدعم العقدة ما يصل إلى 70 pods، فإن AKS تحتفظ بنسبة 25٪ * 4 غيغابايت = 1000 ميغابايت ل kube المحجوزة، لأن هذا أقل من 20 ميغابايت * 70 كحد أقصى من الجرابات + 50 ميغابايت = 1450 ميغابايت.

   لمزيد من المعلومات، راجع تكوين الحد الأقصى للقرون لكل عقدة في نظام مجموعة AKS.

إصدارات AKS قبل 1.29

1. kubelet يحتوي daemon على قاعدة الإخلاء memory.available<750Mi بشكل افتراضي. تضمن هذه القاعدة أن العقدة لديها ما لا يقل عن 750Mi قابلة للتخصيص في جميع الأوقات. عندما يكون المضيف أقل من عتبة الذاكرة المتوفرة kubelet ، يقوم بتشغيل إنهاء إحدى الجرابات قيد التشغيل وتحرير الذاكرة على الجهاز المضيف.
2. معدل تنازلي من تحفظات الذاكرة للتطبيق الخفي kubelet لكي يعمل بشكل صحيح (kube-reserved).
   • 25٪ من أول 4 غيغابايت من الذاكرة
   • 20٪ من السعة التخزينية التالية البالغة 4 غيغابايت (حتى 8 غيغابايت)
   • 10٪ من الذاكرة التالية التي تبلغ 8 غيغابايت (حتى 16 غيغابايت)
   • 6٪ من الذاكرة التالية التي تبلغ 112 غيغابايت (حتى 128 غيغابايت)
   • 2٪ من أي ذاكرة تزيد عن 128 غيغابايت

إشعار

تحتفظ AKS بسعة 2 غيغابايت إضافية لعمليات النظام في عقد Windows التي ليست جزءا من الذاكرة المحسوبة.

تم تصميم قواعد تخصيص الذاكرة وCPU من أجل:

• الحفاظ على حالة عُقد الوكيل، بما في ذلك بعض وحدات الجراب لنظام استضافة حيوي لحالة نظام المجموعة.
• يتسبب في أن تبلغ العقدة عن ذاكرة وCPU أقل قابلية للتخصيص مما كانت ستبلغ عنه إذا لم تكن جزءا من مجموعة Kubernetes.

على سبيل المثال، إذا كانت العقدة توفر 7 غيغابايت، فإنها ستصدر تقرير عن 34٪ من الذاكرة غير القابلة للتخصيص بما في ذلك حد الإخلاء الثابت 750Mi.

0.75 + (0.25*4) + (0.20*3) = 0.75GB + 1GB + 0.6GB = 2.35GB / 7GB = 33.57% reserved

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

للحصول على أفضل الممارسات المرتبطة بها، راجع أفضل الممارسات لمزايا المجدول الأساسية في AKS.

تجمعات العقدة

إشعار

تجمع عقدة Azure Linux متاح الآن بشكل عام (GA). للتعرف على المزايا وخطوات النشر، راجع مقدمة إلى مضيف حاوية Azure Linux ل AKS.

يتم تجميع العقد اللذين من نفس التكوين معا في تجمعات عقدة. تحتوي كل مجموعة Kubernetes على تجمع عقدة واحد على الأقل. يمكنك تحديد العدد الأولي للعقد والأحجام عند إنشاء نظام مجموعة AKS، والذي ينشئ تجمع عقدة افتراضي. يحتوي تجمع العقدة الافتراضي في AKS على نظام VMs الأساسي الذي يقوم بتشغيل عقد الوكيل.

إشعار

للتأكد من أن نظام المجموعة يعمل بشكل موثوق، يجب تشغيل عقدتين على الأقل في تجمع العقدة الافتراضي.

يمكنك قياس أو ترقية نظام مجموعة AKS مقابل تجمع العقدة الافتراضية. يمكنك اختيار مقياس تجمع عقدة معين أو ترقيتها. لعمليات الترقية، يتم جدولة تشغيل الحاويات على العُقد الأخرى في تجمع العقدة حتى تتم ترقية كل العقد بنجاح.

لمزيد من المعلومات، راجع إنشاء تجمعات العقد وإدارة تجمعات العقد.

تغيير حجم قرص نظام التشغيل الافتراضي

عند إنشاء مجموعة جديدة أو إضافة تجمع عقدة جديد إلى مجموعة موجودة، يحدد عدد وحدات المعالجة المركزية الظاهرية بشكل افتراضي حجم قرص نظام التشغيل. يعتمد عدد وحدات vCPUs على VM SKU. يسرد الجدول التالي حجم قرص نظام التشغيل الافتراضي لكل وحدة SKU للجهاز الظاهري:

VM SKU Cores (vCPUs)	طبقة قرص نظام التشغيل الافتراضية	IOPS المتوفر	معدل النقل المقدم (ميغابت في الثانية)
1 - 7	P10/128G	500	100
8 - 15	P15/256G	1100	125
16 - 63	P20/512G	2300	150
64+	P30/1024G	5000	200

هام

يتم استخدام تغيير حجم قرص نظام التشغيل الافتراضي فقط على مجموعات أو تجمعات عقد جديدة عندما لا تكون أقراص نظام التشغيل المؤقتة مدعومة ولا يتم تحديد حجم قرص نظام التشغيل الافتراضي. قد يؤثر حجم قرص نظام التشغيل الافتراضي على أداء نظام المجموعة أو تكلفته. لا يمكنك تغيير حجم قرص نظام التشغيل بعد إنشاء المجموعة أو تجمع العقدة. يؤثر تغيير حجم القرص الافتراضي هذا على المجموعات أو تجمعات العقد التي تم إنشاؤها في يوليو 2022 أو أحدث.

محددات العقد

في نظام مجموعة AKS مع تجمعات عقد متعددة، قد تحتاج إلى إخبار Kubernetes Scheduler بتجمع العقدة الذي يجب استخدامه لمورد معين. على سبيل المثال، لا يجب تشغيل وحدة تحكم الدخول على ‏‏عقدة نظام المجموعة Windows. يمكنك استخدام محددات العقد لتعريف معلمات مختلفة، مثل نظام تشغيل العقدة، للتحكم في مكان جدولة الجراب.

المثال الأساسي التالي جداول مثيل NGINX على عقدة Linux باستخدام محدد العقدة "kubernetes.io/os": linux:

kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
    - name: myfrontend
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.12-alpine
  nodeSelector:
    "kubernetes.io/os": linux

لمزيد من المعلومات، راجع أفضل الممارسات لميزات المجدول المتقدمة في AKS.

مجموعة موارد العقدة

عند إنشاء نظام مجموعة AKS، يمكنك تحديد مجموعة موارد Azure لإنشاء موارد نظام المجموعة فيها. بالإضافة إلى مجموعة الموارد هذه، يقوم موفر موارد AKS بإنشاء وإدارة مجموعة موارد منفصلة تسمى مجموعة موارد العقدة. تحتوي مجموعة موارد العقدة على موارد البنية الأساسية التالية:

• مجموعات مقياس الجهاز الظاهري والأجهزة الظاهرية لكل عقدة في تجمعات العقد
• الشبكة الظاهرية لنظام المجموعة
• تخزين نظام المجموعة

يتم تعيين اسم لمجموعة موارد العقدة بشكل افتراضي بالتنسيق التالي: MC_resourceGroupName_clusterName_location. أثناء إنشاء نظام المجموعة، يمكنك تحديد الاسم المعين لمجموعة موارد العقدة. عند استخدام قالب Azure Resource Manager، يمكنك تعريف الاسم باستخدام الخاصية nodeResourceGroup . عند استخدام Azure CLI، يمكنك استخدام المعلمة --node-resource-groupaz aks create مع الأمر ، كما هو موضح في المثال التالي:

az aks create --name myAKSCluster --resource-group myResourceGroup --node-resource-group myNodeResourceGroup

عند حذف مجموعة AKS الخاصة بك، يقوم موفر موارد AKS تلقائيا بحذف مجموعة موارد العقدة.

تحتوي مجموعة موارد العقدة على القيود التالية:

• لا يمكنك تحديد مجموعة موارد موجودة لمجموعة موارد العقدة.
• لا يمكنك تحديد اشتراك مختلف لمجموعة موارد العقدة.
• لا يمكنك تغيير اسم مجموعة موارد العقدة بعد إنشاء نظام المجموعة.
• لا يمكنك تحديد أسماء الموارد المدارة داخل مجموعة موارد العقدة.
• لا يمكنك تعديل أو حذف علامات Azure التي تم إنشاؤها للموارد المدارة داخل مجموعة موارد العقدة.

يعد تعديل أي علامات تم إنشاؤها بواسطة Azure على الموارد ضمن مجموعة موارد العقدة في نظام مجموعة AKS إجراء غير مدعوم، والذي يكسر هدف مستوى الخدمة (SLO). إذا قمت بتعديل أو حذف العلامات التي تم إنشاؤها بواسطة Azure أو خصائص الموارد الأخرى في مجموعة موارد العقدة، فقد تحصل على نتائج غير متوقعة، مثل أخطاء التحجيم والترقية. تدير AKS دورة حياة البنية الأساسية في مجموعة موارد العقدة، لذا فإن إجراء أي تغييرات ينقل نظام المجموعة إلى حالة غير مدعومة. لمزيد من المعلومات، راجع هل تقدم AKS اتفاقية مستوى الخدمة؟

يسمح لك AKS بإنشاء وتعديل العلامات التي يتم نشرها إلى الموارد في مجموعة موارد العقدة، ويمكنك إضافة هذه العلامات عند إنشاء نظام المجموعة أو تحديثه . قد تحتاج إلى إنشاء علامات مخصصة أو تعديلها لتعيين وحدة عمل أو مركز تكلفة، على سبيل المثال. يمكنك أيضا إنشاء نهج Azure مع نطاق على مجموعة الموارد المدارة.

لتقليل فرصة حدوث تغييرات في مجموعة موارد العقدة التي تؤثر على مجموعاتك، يمكنك تمكين تأمين مجموعة موارد العقدة لتطبيق تعيين رفض على موارد AKS. لمزيد من المعلومات، راجع مجموعة الموارد المدارة بالكامل (معاينة).

تحذير

إذا لم يكن لديك تأمين مجموعة موارد العقدة ممكنا، يمكنك تعديل أي مورد مباشرة في مجموعة موارد العقدة. يمكن أن يؤدي تعديل الموارد مباشرة في مجموعة موارد العقدة إلى أن تصبح المجموعة غير مستقرة أو غير مستجيبة.

Pods

يستخدم Kubernetes pods لتشغيل مثيلات التطبيق الخاص بك. يمثل جراب واحد مثيلا واحدا للتطبيق الخاص بك.

تحتوي وحدات الجراب عادةً على تعيين بنسبة 1: 1 مع حاوية. في السيناريوهات المتقدمة، قد تحتوي الجراب على حاويات متعددة. تتم جدولة الحجيرات متعددة الحاويات معا على نفس العقدة والسماح للحاويات بمشاركة الموارد ذات الصلة.

عند إنشاء جراب، يمكنك تعريف طلبات الموارد لكمية معينة من وحدة المعالجة المركزية أو الذاكرة. يحاول مجدول Kubernetes تلبية الطلب عن طريق جدولة وحدات الجراب للتشغيل على عقدة ذات موارد متاحة. يمكنك أيضًا تحديد الحد الأقصى لحدود الموارد لمنع وحدة الجراب من استهلاك الكثير من موارد الحوسبة من العقدة الأساسية. أفضل الممارسات الموصى بها هي تضمين حدود الموارد لجميع القرون لمساعدة Kubernetes Scheduler على تحديد الموارد الضرورية المسموح بها.

لمزيد من المعلومات، راجع وحدات جراب Kubernetes ودورة حياة وحدات جراب Kubernetes.

وحدة الجراب هي مورد منطقي، لكن أحمال عمل التطبيق تعمل على الحاويات. الحجيرات عادة تكون موارد زائلة قابلة للتصرف. تفتقد وحدات الجراب المجدولة فرديًا بعض ميزات Kubernetes ذات التوافر العالي والتكرار. بدلا من ذلك، تقوم وحدات تحكم Kubernetes، مثل وحدة التحكم في النشر، بنشر القرون وإدارتها.

عمليات التوزيع و بيانات YAML

يمثل التوزيع وحدة الجراب المتطابقة التي تديرها وحدة تحكم توزيع Kubernetes. يعرف التوزيع عدد النسخ المتماثل لوحدات الجراب من أجل الإنشاء. يضمن Kubernetes Scheduler جدولة وحدات الجراب الإضافية على العقد السليمة إذا واجهت الحجيرات أو العقد مشكلات. يمكنك تحديث عمليات النشر لتغيير تكوين pods أو صورة الحاوية أو التخزين المرفق.

تدير وحدة التحكم في النشر دورة حياة التوزيع وتنفذ الإجراءات التالية:

• يفرغ وينهي عدد معين من النسخ المماثلة.
• إنشاء نسخ مماثلة من تعريف التوزيع الجديد.
• متابعة العملية حتى يتم تحديث كل النسخ المماثلة في التوزيع.

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

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

عادة ما يتم إنشاء عمليات التوزيع وإدارتها باستخدام kubectl create أو kubectl apply. يمكنك إنشاء نشر عن طريق تعريف ملف بيان بتنسيق YAML. يوضح المثال التالي ملف بيان نشر أساسي لخادم ويب NGINX:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: mcr.microsoft.com/oss/nginx/nginx:1.15.2-alpine
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 250m
            memory: 64Mi
          limits:
            cpu: 500m
            memory: 256Mi

فيما يلي تصنيف تفصيلي لمواصفات التوزيع في ملف بيان YAML:

المواصفات	‏‏الوصف
.apiVersion	يحدد مجموعة API ومورد API الذي تريد استخدامه عند إنشاء المورد.
.kind	يحدد نوع المورد الذي تريد إنشاءه.
.metadata.name	تحديد اسم النشر. يقوم ملف YAML هذا بتشغيل صورة nginx من Docker Hub.
.spec.replicas	تحديد عدد pods المراد إنشاؤها. ينشئ ملف YAML هذا المثال ثلاثة pods مكررة.
.spec.selector	تحديد القرون التي ستتأثر بهذا النشر.
.spec.selector.matchLabels	يحتوي على خريطة من أزواج {key, value} التي تسمح للتوزيع بالعثور على القرون التي تم إنشاؤها وإدارتها.
.spec.selector.matchLabels.app	يجب أن يتطابق مع .spec.template.metadata.labels.
.spec.template.labels	تحديد أزواج {key, value} المرفقة بالكائن.
.spec.template.app	يجب أن يتطابق مع .spec.selector.matchLabels.
.spec.spec.containers	تحديد قائمة الحاويات التي تنتمي إلى الجراب.
.spec.spec.containers.name	تحديد اسم الحاوية المحددة كتسمية DNS.
.spec.spec.containers.image	تحديد اسم صورة الحاوية.
.spec.spec.containers.ports	تحديد قائمة المنافذ التي تريد عرضها من الحاوية.
.spec.spec.containers.ports.containerPort	يحدد عدد المنافذ التي يجب عرضها على عنوان IP الخاص بالجراب.
.spec.spec.resources	تحديد موارد الحوسبة المطلوبة من قبل الحاوية.
.spec.spec.resources.requests	تحديد الحد الأدنى لمقدار موارد الحوسبة المطلوبة.
.spec.spec.resources.requests.cpu	تحديد الحد الأدنى من وحدة المعالجة المركزية المطلوبة.
.spec.spec.resources.requests.memory	تحديد الحد الأدنى من الذاكرة المطلوبة.
.spec.spec.resources.limits	تحديد الحد الأقصى لمقدار موارد الحوسبة المسموح بها. يفرض kubelet هذا الحد.
.spec.spec.resources.limits.cpu	تحديد الحد الأقصى لمقدار وحدة المعالجة المركزية المسموح به. يفرض kubelet هذا الحد.
.spec.spec.resources.limits.memory	تحديد الحد الأقصى لمقدار الذاكرة المسموح به. يفرض kubelet هذا الحد.

يمكن إنشاء تطبيقات أكثر تعقيدا عن طريق تضمين الخدمات، مثل موازنات التحميل، داخل بيان YAML.

لمزيد من المعلومات، راجع حالات توزيع Kubernetes.

إدارة الحزمة باستخدام Helm

يُستخدم Helm عادةً لإدارة التطبيقات في Kubernetes. يمكنك توزيع الموارد عن طريق إنشاء واستخدام المخططات العامة Helm الموجودة التي تحتوي على إصدار معبأ من التعليمات البرمجية للتطبيق وبيانات YAML Kubernetes. يمكنك تخزين المخططات Helm إمّا محليًا أو في مستودع بعيد، مثل مخطط Helm لسجل الحاويات Azure.

لاستخدام Helm، قم بتثبيت عميل Helm على الكمبيوتر الخاص بك، أو استخدم عميل Helm في Azure Cloud Shell. ابحث عن المخططات Helm أو قم بإنشائها، ثم تثبيتها على نظام مجموعة Kubernetes. لمزيد من المعلومات، راجع تثبيت التطبيقات الموجودة باستخدام Helm في نظام مجموعة Azure Kubernetes Service ‏(AKS).

StatefulSets وDaemonSets

تستخدم وحدة تحكم النشر Kubernetes Scheduler وتشغل النسخ المتماثلة على أي عقدة متوفرة بالموارد المتوفرة. في حين أن هذا الأسلوب قد يكون كافيا للتطبيقات عديمة الحالة، فإن وحدة التحكم في النشر ليست مثالية للتطبيقات التي تتطلب المواصفات التالية:

• إصلاح تسمية متواصل أو تخزين.
• نسخة مماثلة موجودة على كل عقدة محددة داخل نظام مجموعة.

ومع ذلك، يتيح لك موردان من موارد Kubernetes إدارة هذه الأنواع من التطبيقات: StatefulSets وDemonSets.

تحافظ StatefulSets على حالة التطبيقات بعد دورة حياة جراب فردية. تضمن DaemonSets مثيلا قيد التشغيل على كل عقدة في وقت مبكر من عملية تمهيد Kubernetes.

StatefulSets

غالبًا ما يهدف تطوير التطبيقات الحديثة إلى تقديم طلبات عديمة الحالة. أمّا تطبيقات الحالة، مثل تلك التي تتضمن مكونات قاعدة البيانات، يمكنك استخدام StatefulSets. مثل عمليات التوزيع، تقوم مجموعة StatefulSet بإنشاء وحدات جراب واحد متطابق وإدارته على الأقل. تتبع النسخ المتماثلة في StatefulSet نهجا رشيقا ومتسلسلا لعمليات النشر والتحجيم والترقية والإنهاء. اصطلاح التسمية وأسماء شبكة الاتصال والتخزين تستمر كما يتم إعادة جدولة النسخ المماثلة مع StatefulSet.

يمكنك تعريف التطبيق بتنسيق YAML باستخدام kind: StatefulSet. من ذلك الموضع، تعالج مقابض التحكم StatefulSet توزيع وإدارة النسخ المماثل المطلوب. تكتب البيانات إلى التخزين المستمر، التي توفرها Azure Managed Disks أو Azure Files. مع StatefulSets، يبقى التخزين المستمر الأساسي حتى عند حذف StatefulSet.

لمزيد من المعلومات، راجع Kubernetes StatefulSets.

هام

تتم جدولة النسخ المماثلة في StatefulSet وتشغيلها عبر أي عقدة متوفرة في نظام مجموعة AKS. لضمان تشغيل جراب واحد على الأقل في المجموعة على عقدة، يجب عليك استخدام DaemonSet بدلا من ذلك.

DaemonSets

لمجموعة سجل معينة أو مراقبة معينة، قد تحتاج إلى تشغيل جراب على جميع العقد أو مجموعة محددة من العقد. يمكنك استخدام DaemonSets للنشر إلى حاوية واحدة أو أكثر متطابقة. تضمن وحدة تحكم DaemonSet تشغيل كل عقدة محددة لمثيل pod.

يمكن لوحدة تحكم DaemonSet جدولة الحجيرات على العقد في وقت مبكر من عملية تمهيد نظام المجموعة قبل بدء مجدول Kubernetes الافتراضي. تضمن هذه القدرة جدولة الحجيرات في حالة DaemonSet قبل الجرابات التقليدية في Deployment أو StatefulSet.

مثل StatefulSets، يمكنك تعريف DaemonSet كجزء من تعريف YAML باستخدام kind: DaemonSet.

لمزيد من المعلومات، راجع Kubernetes DaemonSets.

إشعار

إذا كنت تستخدم الوظيفة الإضافية للعقد الظاهرية، فإن DaemonSets لا تنشئ pods على العقدة الظاهرية.

مساحة الاسم

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

تتوفر مساحات الأسماء التالية عند إنشاء نظام مجموعة AKS:

مساحة الاسم	‏‏الوصف
افتراضي	حيث يتم إنشاء وحدات الجراب والتوزيع بشكل افتراضي عند عدم توفير أي منها. في بيئات أصغر، يمكنك نشر التطبيقات مباشرة في مساحة الاسم الافتراضية دون إنشاء فصل منطقي إضافي. عند التفاعل مع API Kubernetes، مثل مع kubectl get pods، يتم استخدام مساحة الاسم الافتراضية عند عدم التحديد.
نظام kube	حيث توجد الموارد الأساسية، مثل ميزات الشبكة مثل DNS والوكيل، أو لوحة معلومات Kubernetes. عادة لا تقوم بتوزيع التطبيقات الخاصة بك في مساحة الاسم هذه.
kube-public	عادة لا يتم استخدامه، يمكنك استخدامه للموارد لتكون مرئية عبر المجموعة بأكملها، ويمكن عرضها من قبل أي مستخدم.

لمزيد من المعلومات، راجع مساحات أسماء Kubernetes.

الخطوات التالية

لمزيد من المعلومات حول مفاهيم Kubernetes وAKS الأساسية، راجع المقالات التالية:

• الوصول إلى AKS والهوية
• أمان AKS
• شبكات AKS الظاهرية
• تخزين AKS
• مقياس AKS