مشاركة عبر

استكشاف الأخطاء وإصلاحها باستخدام نهج 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. تأكد من تعيين معلمات التعيين ونطاق التعيين بشكل صحيح وأنه enforcementMode ممكن.
  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 الظاهري بهويات مدارة يعينها النظام

المشكلة

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

السبب

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

نوع الحل

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

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

المكون الإضافي لأخطاء 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-identity تثبيته على نظام المجموعة ولا يتم استبعاد جرابات نظام kube في aad-pod-identity.

aad-pod-identity تقوم pods المكونة Node Managed Identity (NMI) بتعديل iptables للعقد لاعتراض المكالمات إلى نقطة نهاية بيانات تعريف مثيل Azure. يعني هذا الإعداد أن أي طلب يتم إجراؤه على نقطة نهاية بيانات التعريف يتم اعتراضه بواسطة NMI، حتى إذا لم يستخدم aad-pod-identitypod . AzurePodIdentityException يمكن تكوين CustomResourceDefinition (CRD) لإعلام aad-pod-identity أن أي طلبات إلى نقطة نهاية بيانات التعريف التي تنشأ من جراب مطابقة التسميات المحددة في CRD يجب أن تكون مدعومة دون أي معالجة في NMI.

نوع الحل

استبعاد pods النظام التي تحتوي على 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 لتعريفات النهج، يمكنك تحديد الزر تكرار التعريف . بعد تعيين النهج، تجد أن الأجهزة غير متوافقة لأنه لا يوجد مورد تعيين تكوين ضيف.

السبب

يعتمد تكوين الضيف على بيانات التعريف المخصصة المضافة إلى تعريفات النهج عند إنشاء موارد تعيين تكوين الضيف. لا ينسخ نشاط تعريف التكرار في مدخل 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 الرسمي هذا على X على تحسين تجربة العملاء من خلال ربط مجتمع Azure بالإجابات والدعم والخبراء المناسبين.
  • إذا كنت لا تزال بحاجة إلى مساعدة، فانتقل إلى موقع دعم Azure وحدد إرسال تذكرة دعم.