استكشاف الأخطاء وإصلاحها باستخدام نهج Azure

  • مقالة

قد تواجه أخطاء عند إنشاء تعريفات النهج أو العمل مع مجموعات SDKs أو إعداد نهج Azure للمكون الإضافي لـ Kubernetes. تصف هذه المقالة الأخطاء العامة المختلفة التي قد تحدث، وتقترح طرقاً لحلها.

البحث عن تفاصيل الخطأ

يعتمد موقع تفاصيل الخطأ على جانب نهج Azure الذي تستخدمه.

  • إذا كنت تستخدم نهجاً مخصصاً، فانتقل إلى مدخل Microsoft Azure للحصول على ملاحظات تحليلية حول المخطط، أو راجع بيانات التوافق الناتجة لمعرفة كيفية تقييم الموارد.
  • إذا كنت تستخدم أيّاً من مجموعات SDKs المختلفة، فإن SDK يوفر تفاصيل حول سبب فشل الوظيفة.
  • وإذا كنت تستخدم المكون الإضافي لـ Kubernetes، فابدأ بتسجيل الدخول إلى خادم نظام المجموعة.

أخطاء عامة

السيناريو: لم يتم العثور على الاسم المستعار

المشكلة

اسم مستعار غير صحيح أو غير موجود مستخدم في تعريف النهج. يستخدم نهج Azure الأسماء المستعارة لتعيين خصائص Azure Resource Manager.

السبب

اسم مستعار غير صحيح أو غير موجود مستخدم في تعريف النهج.

نوع الحل

أولاً، تحقق من أن خاصية Resource Manager تحمل اسماً مستعاراً. للبحث عن الأسماء المستعارة المتوفرة، انتقل إلى ملحق نهج Azure للحصول على Visual Studio Code أو SDK. إذا لم يكن الاسم المستعار لخاصية Resource Manager موجوداً، فقم بإنشاء تذكرة دعم.

السيناريو: تفاصيل التقييم غير محدثة

المشكلة

المورد في حالة لم يتم البدء، أو تفاصيل التوافق غير محدثة.

السبب

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

نوع الحل

أولاً، انتظر مدة مناسبة من الوقت حتى ينتهي التقييم وتصبح نتائج التوافق متاحة في مدخل Microsoft Azure أو SDK. لبدء فحص تقييم جديد باستخدام Azure PowerShell أو واجهة برمجة تطبيقات REST، راجع فحص التقييم عند الطلب.

السيناريو: التوافق ليس كما هو متوقع

المشكلة

المورد ليس في حالة التقييم المتوافقة أو غير المتوافقة المتوقعة له.

السبب

المورد ليس في النطاق الصحيح لتعيين النهج، أو لا يعمل تعريف النهج بالشكل المطلوب.

نوع الحل

لاستكشاف أخطاء تعريف النهج وإصلاحها، قم بما يلي:

  1. أولاً، انتظر مدة مناسبة من الوقت حتى ينتهي التقييم وتصبح نتائج التوافق متاحة في مدخل Microsoft Azure أو SDK.

  2. لبدء فحص تقييم جديد باستخدام Azure PowerShell أو واجهة برمجة تطبيقات REST، راجع فحص التقييم عند الطلب.

  3. تأكد من وضع معلمات التعيين ونطاق التعيين بشكل صحيح.

  4. تحقق من وضع تعريف النهج:

    • يجب أن يكون الوضع all لجميع أنواع الموارد.
    • يجب أن يكون الوضع indexed إذا كان تعريف النهج يتحقق من العلامات أو الموقع.

  5. تأكد من أن نطاق المورد غير مستبعد أو مستثنى.

  6. إذا قام الامتثال لتعيين النهج بإظهار الموارد 0/0، فهذا يعني أنه لم تُحدد أي موارد قابلة للتطبيق ضمن نطاق التعيين. تحقق من كل تعريف من تعريفات النهج ونطاق التعيين.

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

    • إذا كانت القيمة المستهدفة خطأ، فراجع تعريف النهج.
    • إذا كانت القيمة الحالية خطأ، فتحقق من صحة البيانات الأساسية للمورد من خلال resources.azure.com.

  8. بالنسبة لتعريف وضع موفر الموارد الذي يدعم معلمة سلسلة RegEx (مثل Microsoft.Kubernetes.Data والتعريف المضمن "يجب نشر صور الحاوية من السجلات الموثوق بها فقط")، تحقق من صحة معلمة سلسلة RegEx.

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

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

السيناريو: الإنفاذ ليس كما هو متوقع

المشكلة

لا يتم العمل على مورد تتوقع أن يعمل عليه نهج Azure، ولا يوجد إدخال في سجل نشاط Azure.

السبب

تم تكوين تعيين النهج لإعداد enforcementMode لـ Disabled. أثناء تعطل enforcementMode، لا يتم إنفاذ تأثير النهج، ولا يوجد إدخال في سجل النشاط.

نوع الحل

استكشف أخطاء إنفاذ تعيين النهج وإصلاحها عن طريق القيام بما يلي:

  1. أولاً، انتظر فترة مناسبة من الوقت حتى ينتهي التقييم وتصبح نتائج التوافق متاحة في مدخل Microsoft Azure أو SDK.

  2. لبدء فحص تقييم جديد باستخدام Azure PowerShell أو واجهة برمجة تطبيقات REST، راجع فحص التقييم عند الطلب.

  3. تأكد من تعيين معلمات التعيين ونطاق التعيين بشكل صحيح وأن وضع الإنفاذممكن.

  4. تحقق من وضع تعريف النهج:

    • يجب أن يكون الوضع all لجميع أنواع الموارد.
    • يجب أن يكون الوضع indexed إذا كان تعريف النهج يتحقق من العلامات أو الموقع.

  5. تأكد من أن نطاق المورد غير مستبعد أو مستثنى.

  6. تحقق من أن البيانات الأساسية للمورد تطابق منطق النهج. يمكن القيام بذلك عن طريق التقاط تتبع أرشيف HTTP (HAR) أو مراجعة خصائص قالب Azure Resource Manager (قالب ARM).

  7. بالنسبة للمشكلات والحلول الشائعة الأخرى، راجع استكشاف الأخطاء وإصلاحها: التوافق ليس كما هو متوقع.

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

السيناريو: مرفوض بواسطة نهج Azure

المشكلة

تم رفض إنشاء مورد أو تحديثه.

السبب

يفي تعيين النهج إلى نطاق موردك الجديد أو المحدث بمعايير تعريف النهج مع تأثير الرفض. تُمنع الموارد التي تطابق هذه التعريفات من الإنشاء أو التحديث.

نوع الحل

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

السيناريو: يستهدف التعريف أنواعاً متعددة من الموارد

المشكلة

يفشل تعريف النهج الذي يتضمن أنواعاً متعددة من الموارد في التحقق من الصحة أثناء الإنشاء أو التحديث مع الخطأ التالي:

The policy definition '{0}' targets multiple resource types, but the policy rule is authored in a way that makes the policy not applicable to the target resource types '{1}'.

السبب

تحتوي قاعدة تعريف النهج على شرط واحد أو أكثر لا يتم تقييمه بواسطة أنواع الموارد المستهدفة.

نوع الحل

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

السيناريو: تم تجاوز حد الاشتراك

المشكلة

تظهر رسالة خطأ في صفحة التوافق في مدخل Microsoft Azure عند استرداد التوافق لتعيينات النهج.

السبب

تجاوز عدد الاشتراكات ضمن النطاقات المحددة في الطلب حد 5000 اشتراك. قد يتم عرض نتائج التوافق جزئياً.

نوع الحل

حدد نطاقاً أكثر دقة مع عدد أقل من الاشتراكات التابعة لمشاهدة النتائج الكاملة.

أخطاء القالب

السيناريو: وظائف النهج المدعومة تتم معالجتها حسب القالب

المشكلة

يدعم نهج Azure عدداً من دوال قالب ARM والدوالِ المتوفرة فقط في تعريف النهج. يعالج Resource Manager هذه الدوال كجزء من عملية النشر بدلاً من أن تكون جزءاً من تعريف النهج.

السبب

يؤدي استخدام الدوال المدعومة، مثل parameter() أو resourceGroup()، إلى أن ينتج عنها مخرج معالج للدالة في وقت النشر بدلاً من السماح للدالة لتعريف النهج ومحرك نهج Azure بمعالجتها.

نوع الحل

لتمرير دالة كجزء من تعريف النهج، تجاوز السلسلة بأكملها حتى [ تبدو الخاصية مثل [[resourceGroup().tags.myTag]. تؤدي خاصية حرف الإلغاء إلى تعامل Resource Manager مع القيمة كسلسلة عند معالجة القالب. ثم يضع نهج Azure الدالة في تعريف النهج، الأمر الذي يسمح لها أن تكون ديناميكية كما هو متوقع. لمزيد من المعلومات، راجع بناء الجملة والتعبيرات في قوالب Azure Resource Manager.

المكون الإضافي لأخطاء تثبيت Kubernetes

السيناريو: فشل التثبيت باستخدام مخطط Helm بسبب خطأ في كلمة المرور

المشكلة

يفشل الأمر helm install azure-policy-addon، ويظهر أحد الأخطاء التالية:

  • !: event not found
  • Error: failed parsing --set data: key "<key>" has no value (cannot end with ,)

السبب

تتضمن كلمة المرور التي تم إنشاؤها فاصلة (,)، والتي تم تقسيم مخطط Helm عليها.

نوع الحل

عند تشغيل helm install azure-policy-addon، قم بإلغاء الفاصلة (,) في قيمة كلمة المرور باستخدام مائل عكسي (\).

السيناريو: فشل التثبيت باستخدام مخطط Helm لأن الاسم موجود بالفعل

المشكلة

يفشل الأمر helm install azure-policy-addon، ويظهر الخطأ التالي:

  • Error: cannot re-use a name that is still in use

السبب

تم بالفعل تثبيت مخطط Helm بالاسم azure-policy-addon أو تثبيته جزئياً.

نوع الحل

اتبع الإرشادات لإزالة نهج Azure للمكون الإضافي Kubernetes، ثم أعد تشغيل الأمر helm install azure-policy-addon.

السيناريو: استبدال الهويات المعينة من قبل المستخدم لجهاز Azure الظاهري بهويات مدارة يعينها النظام

المشكلة

بعد تعيين مبادرات نهج تكوين الضيف لتدقيق الإعدادات داخل الجهاز، لن يتم تعيين الهويات المدارة التي عيّنها المستخدم والتي تم تعيينها للجهاز. ويتم تعيين هوية مدارة معينة من قبل النظام فقط.

السبب

تضمن تعريفات النهج التي تم استخدامها مسبقاً في تعريفات Guest Configuration DeployIfNotExists تعيين هوية معينة من قبل النظام إلى الجهاز، لكنها أزالت أيضاً تعيينات الهوية المعينة من قبل المستخدم.

نوع الحل

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

للحصول على سرد مفصل، راجع منشور المدونة تغيير مهم تم إصداره لنُهج تدقيق تكوين الضيف.

المكون الإضافي لأخطاء Kubernetes العامة

السيناريو: المكون الإضافي غير قادر على الوصول إلى نقطة نهاية خدمة نهج Azure بسبب قيود الخروج

المشكلة

لا يمكن للمكون الإضافي الوصول إلى نقطة نهاية خدمة نهج Azure، ويُظهر أحد الأخطاء التالية:

  • failed to fetch token, service not reachable
  • Error getting file "Get https://raw.githubusercontent.com/Azure/azure-policy/master/built-in-references/Kubernetes/container-allowed-images/template.yaml: dial tcp 151.101.228.133.443: connect: connection refused

السبب

تحدث هذه المشكلة عند قفل خروج نظام المجموعة.

نوع الحل

تأكد من فتح المجالات والمنافذ المذكورة في المقالة التالية:

السيناريو: المكون الإضافي غير قادر على الوصول إلى نقطة نهاية خدمة نهج Azure بسبب تكوين هوية aad-pod

المشكلة

لا يمكن للمكون الإضافي الوصول إلى نقطة نهاية خدمة نهج Azure، ويُظهر أحد الأخطاء التالية:

  • azure.BearerAuthorizer#WithAuthorization: Failed to refresh the Token for request to https://gov-prod-policy-data.trafficmanager.net/checkDataPolicyCompliance?api-version=2019-01-01-preview: StatusCode=404
  • adal: Refresh request failed. Status Code = '404'. Response body: getting assigned identities for pod kube-system/azure-policy-8c785548f-r882p in CREATED state failed after 16 attempts, retry duration [5]s, error: <nil>

السبب

يحدث هذا الخطأ عند تثبيت هوية aad-pod على نظام المجموعة ولا يتم استبعاد جرابات نظام kube في هوية aad-pod.

تقوم aad-pod-identity وعنصر الهوية المدارة للجزء (NMI) بتعديل أجزاء iptables لاعتراض المكالمات إلى نقطة نهاية بيانات تعريف مثيل Azure. وهذا التكوين يعني أن أي طلب يتم إجراؤه إلى نقطة نهاية بيانات التعريف يتم اعتراضه بواسطة NMI حتى إذا لم يتم استخدام add-pod-identity . يمكن تكوين AzurePodIdentityException وتعريف المورد المخصص (CRD) لإعلام aad-pod-identity بأن أي طلبات إلى نقطة نهاية بيانات التعريف التي تنشأ من جراب يطابق التسميات المحددة في CRD يجب أن تكون موكلة دون أي معالجة في NMI.

نوع الحل

استبعد جرابات النظام التي تحتوي على التسمية kubernetes.azure.com/managedby: aks في مساحة اسم نظام kube في aad-pod-identity عن طريق تكوين استبعاد هوية جراب AzurePodIdentityException CRD.

لمزيد من المعلومات، راجع تعطيل هوية جراب Azure Active Directory (Azure AD) لجراب/تطبيق معين.

لتكوين استثناء، اتبع هذا المثال:

apiVersion: "aadpodidentity.k8s.io/v1"
kind: AzurePodIdentityException
metadata:
  name: mic-exception
  namespace: default
spec:
  podLabels:
    app: mic
    component: mic
---
apiVersion: "aadpodidentity.k8s.io/v1"
kind: AzurePodIdentityException
metadata:
  name: aks-addon-exception
  namespace: kube-system
spec:
  podLabels:
    kubernetes.azure.com/managedby: aks

السيناريو: لم يتم تسجيل موفر الموارد

المشكلة

يمكن أن يصل المكون الإضافي إلى نقطة نهاية خدمة نهج Azure، ولكن تعرض سجلات المكون الإضافي أحد الأخطاء التالية:

  • The resource provider 'Microsoft.PolicyInsights' is not registered in subscription '{subId}'. See https://aka.ms/policy-register-subscription for how to register subscriptions.

  • policyinsightsdataplane.BaseClient#CheckDataPolicyCompliance: Failure responding to request: StatusCode=500 -- Original Error: autorest/azure: Service returned an error. Status=500 Code="InternalServerError" Message="Encountered an internal server error.

السبب

موفر الموارد 'Microsoft.PolicyInsights' غير مسجل. يجب تسجيله للمكون الإضافي للحصول على تعريفات النهج وإرجاع بيانات التوافق.

نوع الحل

تسجيل موفر الموارد 'Microsoft.PolicyInsights' في اشتراك نظام المجموعة. للحصول على الإرشادات، راجع تسجيل موفر موارد.

السيناريو: تم تعطيل الاشتراك

المشكلة

يمكن أن يصل المكون الإضافي إلى نقطة نهاية خدمة نهج Azure، ولكن يتم عرض الخطأ التالي:

The subscription '{subId}' has been disabled for azure data-plane policy. Please contact support.

السبب

هذا الخطأ يعني أنه تم تحديد الاشتراك على أنه إشكالية، وتمت إضافة علامة الميزة Microsoft.PolicyInsights/DataPlaneBlocked لحظر الاشتراك.

نوع الحل

للتحقيق في هذه المشكلة وحلها، تواصل مع فريق الميزات.

السيناريو: لا يمكن تكرار التعريفات في فئة "تكوين الضيف" من مدخل Microsoft Azure

المشكلة

عند محاولة إنشاء تعريف نهج مخصص من صفحة مدخل Microsoft Azure لتعريفات النهج، يمكنك اختيار الزر "Duplicate definition". بعد تعيين النهج، تجد أن الأجهزة غير متوافقة لأنه لا يوجد مورد تعيين تكوين ضيف.

السبب

يعتمد تكوين الضيف على بيانات التعريف المخصصة المضافة إلى تعريفات النهج عند إنشاء موارد تعيين تكوين الضيف. لا ينسخ نشاط "التعريف المكرر" في مدخل Microsoft Azure بيانات التعريف المخصصة.

نوع الحل

بدلاً من استخدام المدخل، كرر تعريف النهج باستخدام واجهة برمجة تطبيقات Policy Insights. يوفر نموذج PowerShell التالي أحد الخيارات.

# duplicates the built-in policy which audits Windows machines for pending reboots
$def = Get-AzPolicyDefinition -id '/providers/Microsoft.Authorization/policyDefinitions/4221adbc-5c0f-474f-88b7-037a99e6114c' | % Properties
New-AzPolicyDefinition -name (new-guid).guid -DisplayName "$($def.DisplayName) (Copy)" -Description $def.Description -Metadata ($def.Metadata | convertto-json) -Parameter ($def.Parameters | convertto-json) -Policy ($def.PolicyRule | convertto-json -depth 15)

السيناريو: يتم إنشاء مورد Kubernetes أثناء فشل الاتصال على الرغم من تعيين نهج الرفض

المشكلة

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

السبب

يكون نموذج فشل فتح GK حسب التصميم واستناداً إلى ملاحظات المجتمع. تتوسع وثائق Gatekeeper استناداً إلى هذه الأسباب هنا: https://open-policy-agent.github.io/gatekeeper/website/docs/failing-closed#considerations.

نوع الحل

في الحالة أعلاه، يمكن مراقبة حالة الخطأ من مقاييس إخطار القبول على الويب التي يوفرها kube-apiserver. وحتى إذا تم تجاوز التقييم في وقت الإنشاء وتم إنشاء كائن، فسيظل يتم الإبلاغ عنه بخصوص توافق نهج Azure على أنه غير متوافق كعلامة للعملاء.

وبغض النظر عما سبق، في مثل هذا السيناريو، سيظل نهج Azure يحتفظ بآخر نهج معروف على نظام المجموعة ويبقي حواجز الحماية في مكانها.

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

إذا لم تكن مشكلتك مدرجة في هذه المقالة أو تعذر عليك حلها، فاحصل على الدعم من خلال زيارة إحدى القنوات التالية:

  • احصل على إجابات من الخبراء من خلال Microsoft Q&A.
  • تواصل مع @AzureSupport. يساعد مورد Microsoft Azure الرسمي هذا على تويتر على تحسين تجربة العملاء من خلال ربط مجتمع Azure بالإجابات والدعم والخبراء المناسبين.
  • وإذا كنت لا تزال بحاجة إلى المساعدة، فانتقل إلى Azure support site وحدد Submit a support request.