Configure LocalDNS in Azure Kubernetes Service

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

للتعرف على ماهية LocalDNS، بما في ذلك تفاصيل البنية والقدرات الرئيسية، يرجى الرجوع إلى DNS Resolution في خدمة Azure Kubernetes ‏(AKS).

أفضل الممارسات لتكوين LocalDNS

عند تنفيذ LocalDNS في مجموعات AKS، ضع في اعتبارك أفضل الممارسات التالية:

• ابدأ بتكوين بسيط: ابدأ بتكوين بسيط يستخدم الوضع Preferred للتحقق من صياغة تكوين LocalDNS قبل الانتقال إلى Required الوضع. يقوم الوضع Preferred بالتحقق من إعدادك دون تفعيل LocalDNS، مما يسمح لك باكتشاف أخطاء التكوين مبكرا دون التأثير على العنقود.

• تنفيذ استراتيجيات التخزين المؤقت المناسبة: تكوين إعدادات ذاكرة التخزين المؤقت استنادا إلى خصائص حمل العمل:

  • بالنسبة للسجلات المتغيرة بشكل متكرر، استخدم قيما أقصر cacheDurationInSeconds . عند القيام بذلك ، من المهم ملاحظة أن cacheDurationInSeconds يعمل كحد أقصى لسجل DNS TTL ولكنه لا يزيده. TTL الناتج هو أصغر ما يتم إرجاعه من المنبع أو ما تم تعيينه في المكون الإضافي لذاكرة التخزين المؤقت.
  • بالنسبة للسجلات الثابتة، استخدم مدد ذاكرة التخزين المؤقت الأطول لتقليل استعلامات DNS.
  • تمكين serveStale مع الإعدادات المناسبة للحفاظ على الخدمة أثناء انقطاع DNS.
  • يعمل التخزين المؤقت باستخدام LocalDNS على أساس أفضل الجهود ولا يضمن استجابات قديمة. تنقسم ذاكرة التخزين المؤقت إلى 256 قطعة وبحد أقصى افتراضي يبلغ 10,000 إدخال ، مما يسمح لكل قطعة بالاحتفاظ بحوالي 39 إدخالا. عندما تكون القطعة ممتلئة وتحتاج إلى إضافة إدخال جديد ، يتم اختيار أحد الإدخالات الموجودة بشكل عشوائي ليتم إخلاؤه. لا يوجد تفضيل للإدخالات القديمة أو منتهية الصلاحية. ونتيجة لذلك، قد لا يتوفر سجل قديم دائما، خاصة في ظل حجم الاستعلام المرتفع.

• مراقبة أداء DNS: بعد تمكين LocalDNS، راقب أداء DNS للتطبيق باستخدام:

  • مقاييس أداء التطبيق.
  • مقاييس العقدة للكشف عن ضغط الشبكة المنخفض.
  • تسجيل الإدخالات عند queryLogging تعيين إلى Log.

• اتبع مبدأ الامتياز الأقل: عند تكوين قواعد إعادة توجيه DNS، اسمح فقط بالوصول إلى خوادم DNS والمجالات المطلوبة.

• الاختبار قبل نشر الإنتاج: اختبر دائما تكوين LocalDNS في بيئة غير إنتاجية قبل طرحه إلى مجموعات الإنتاج.

• استخدام البنية الأساسية كتعليق برمجي (IaC): قم بتخزين ملف localdnsconfig.json في مستودع البنية الأساسية الخاص بك وقم بتضمينه في قوالب توزيع AKS.

• تكوين الشبكة لإعادة توجيه TCP: عند استخدام TCP لإعادة توجيه DNS إلى VnetDNS، تأكد من أن مجموعات أمان الشبكة (NSGs) أو جدران الحماية أو الأجهزة الظاهرية للشبكة (NVAs) لا تمنع حركة مرور TCP بين خوادم CoreDNS/LocalDNS وVnetDNS.

• تجنب تمكين كل من NodeLocal DNSCache و LocalDNS: لا يوصى بتمكين كل من Kubernetes NodeLocal DNSCache و LocalDNS في تجمع العقدة الخاص بك. بينما لا يمنع AKS هذا التكوين، يتم توجيه جميع حركة مرور DNS عبر LocalDNS، مما قد يؤدي إلى سلوك غير متوقع أو تقليل الفوائد من NodeLocal DNSCache.

Prerequisites

• يجب أن يكون لديك عنقود AKS موجود مع إصدارات Kubernetes 1.31 وما بعدها لاستخدام LocalDNS. إذا كنت بحاجة إلى عنقود AKS، يمكنك إنشاء واحد باستخدام Azure CLI، Azure PowerShell، أو بوابة Azure.

• تتطلب هذه المقالة إصدار Azure CLI 2.80.0 وما بعدها. إذا كنت تستخدم Azure Cloud Shell، فإن الإصدار الأخير مثبت بالفعل.

• يدعم LocalDNS فقط على مجموعات العقد التي تعمل بنظام Azure Linux أو Ubuntu 22.04 وما بعده.

• يجب أن يحتوي SKU للجهاز الظاهري (VM) المستخدم لتجمع العقدة على 4 وحدات معالجة مركزية افتراضية (أساسيات) على الأقل لدعم LocalDNS.

• LocalDNS غير متوافق مع سياسات تصفية أسماء النطاقات المؤهلة بالكامل (FQDN) المطبقة في خدمات شبكات الحاويات المتقدمة (ACNS).

إدارة LocalDNS على عنقود AKS

يتم تكوين LocalDNS على مستوى تجمع العقدة في AKS، ما يعني أنه يمكنك تمكين LocalDNS أو تعطيله بشكل مستقل لكل تجمع عقدة في نظام المجموعة الخاص بك. هذا يصمم سلوك دقة DNS استنادا إلى المتطلبات المحددة لأحمال العمل أو البيئات المختلفة. لتمكين LocalDNS على تجمع عقدة، تحتاج إلى توفير ملف تكوين: localdnsconfig.json يحدد كيفية عمل LocalDNS لتجمع العقدة هذا.

تمكين

Note

إذا كنت تستخدم التوفير التلقائي للعقد (NAP)، راجع إعدادات LocalDNS للحصول على تعليمات حول كيفية تفعيل LocalDNS مع NAP.

لتمكين LocalDNS أثناء إنشاء تجمع العقدة، استخدم الأمر التالي مع ملف التكوين المخصص:

az aks nodepool add --name mynodepool1 --cluster-name myAKSCluster --resource-group myResourceGroup --localdns-config ./localdnsconfig.json

لتمكين LocalDNS على تجمع عقدة موجود، استخدم الأمر التالي مع ملف التكوين المخصص:

az aks nodepool update --name mynodepool1 --cluster-name myAKSCluster --resource-group myResourceGroup --localdns-config ./localdnsconfig.json

Important

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

Note

إذا كنت تستخدم التوفير التلقائي للعقد (NAP)، راجع إعدادات LocalDNS للحصول على تعليمات حول كيفية تعطيل LocalDNS باستخدام NAP.

لتعطيل LocalDNS لتجمع عقد، يجب عليك تحديث ملف localdnsconfig.json عن طريق تعيين الخاصية mode إلى Disabled. يرشد هذا التغيير AKS إلى إيقاف تشغيل وكيل DNS المحلي على جميع العقد في التجمع المحدد، مع إرجاع دقة DNS إلى سلوك نظام المجموعة الافتراضي. بعد تحديث ملف التكوين، قم بتطبيقه على مجموعة العقد باستخدام Azure CLI لضمان تطبيق التغيير.

az aks nodepool update --name mynodepool1 --cluster-name myAKSCluster --resource-group myResourceGroup --localdns-config ./localdnsconfig.json

تحقق

بمجرد تفعيل LocalDNS، يمكنك التحقق من عمليته عن طريق تشغيل استعلامات DNS من البودات في تجمع العقد المحددة وفحص الحقل SERVER في الردود للتأكد من عودة عناوين LocalDNS (169.254.10.10 أو 169.254.10.11).

قبل تشغيل خطوات التحقق من الصحة، تأكد من استيفاء الشروط التالية:

1. لقد قمت kubectl بتثبيت وتكوين للوصول إلى نظام مجموعة AKS.
2. حساب المستخدم الخاص بك لديه أذونات كافية لإنشاء و exec في pods.
3. تجمع العقد الذي تريد التحقق منه من LocalDNS في حالة جاهزة .
4. يمكن الوصول إلى صورة BusyBox (busybox:1.28) من عقد نظام المجموعة.

فيما يلي مثال على كيفية التحقق:

1. إنشاء جراب تتبع الأخطاء في تجمع العقدة حيث يتم تمكين LocalDNS:

   kubectl run dnstest --image=busybox:1.28 -- sleep 3600
   

2. بمجرد تشغيل الجراب، قم بتنفيذ الأمر التالي للتحقق من دقة DNS:

   kubectl exec -it dnstest -- nslookup kubernetes.default
   

   تحقق من الإخراج. إذا كان localDNS يعمل بشكل صحيح، يجب أن تشاهد استجابة بعنوان الخادم 169.254.10.10 أو 169.254.10.11:

   Server:    169.254.10.10
   Address 1: 169.254.10.10
   
   Name:      kubernetes.default
   Address 1: 10.0.0.1 kubernetes.default.svc.cluster.local
   

تكوين

Note

إذا كنت تستخدم التوفير التلقائي للعقد (NAP)، راجع تكوين LocalDNS للحصول على تعليمات حول كيفية تكوين LocalDNS باستخدام NAP.

يستخدم LocalDNS localdnsconfig.json ملف تكوين يستند إلى JSON لتحديد سلوك دقة DNS لكل تجمع عقدة. يسمح لك هذا الملف بتحديد أوضاع التشغيل وكتل الخادم لمجالات DNS المختلفة وإعدادات المكون الإضافي مثل التخزين المؤقت وإعادة التوجيه والتسجيل.

تكوين LocalDNS الافتراضي

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

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

{
  "mode": "Required",
  "vnetDNSOverrides": {
    ".": {
      "queryLogging": "Error",
      "protocol": "PreferUDP",
      "forwardDestination": "VnetDNS",
      "forwardPolicy": "Sequential",
      "maxConcurrent": 1000,
      "cacheDurationInSeconds": 3600,
      "serveStaleDurationInSeconds": 3600,
      "serveStale": "Immediate"
    },
    "cluster.local": {
      "queryLogging": "Error",
      "protocol": "ForceTCP",
      "forwardDestination": "ClusterCoreDNS",
      "forwardPolicy": "Sequential",
      "maxConcurrent": 1000,
      "cacheDurationInSeconds": 3600,
      "serveStaleDurationInSeconds": 3600,
      "serveStale": "Immediate"
    }
  },
  "kubeDNSOverrides": {
    ".": {
      "queryLogging": "Error",
      "protocol": "PreferUDP",
      "forwardDestination": "ClusterCoreDNS",
      "forwardPolicy": "Sequential",
      "maxConcurrent": 1000,
      "cacheDurationInSeconds": 3600,
      "serveStaleDurationInSeconds": 3600,
      "serveStale": "Immediate"
    },
    "cluster.local": {
      "queryLogging": "Error",
      "protocol": "ForceTCP",
      "forwardDestination": "ClusterCoreDNS",
      "forwardPolicy": "Sequential",
      "maxConcurrent": 1000,
      "cacheDurationInSeconds": 3600,
      "serveStaleDurationInSeconds": 3600,
      "serveStale": "Immediate"
    }
  }
}

تكوين mode ل LocalDNS

يمكن تمكين LocalDNS في ثلاثة أوضاع ممكنة تحدد مدى إنفاذ LocalDNS لحمل العمل:

• Required: في هذا الوضع، يتم فرض LocalDNS على تجمع العقدة إذا تم استيفاء جميع المتطلبات الأساسية. إذا لم يتم استيفاء المتطلبات، يفشل النشر.

• Disabled: يعطل ميزة DNS المحلية، مما يعني أن استفسارات DNS لا تحل محليا على العقدة.

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

يلخص الجدول التالي سلوك LocalDNS لكل وضع وإصدار Kubernetes:

إصدار Kubernetes	مفضل	Required	Disabled
أقل من 1.31	غير مدعوم	غير مدعوم	غير مدعوم
أكبر من 1.31	التكوين الذي تم التحقق من صحته، غير مثبت	مثبت ومفرض	التكوين الذي تم التحقق من صحته، غير مثبت

Note

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

كتل الخادم والمكونات الإضافية المدعومة ل LocalDNS

ينطبق التكوين الافتراضي على الاستعلامات من pods باستخدام dnsPolicy:default (ضمن vnetDNSOverrides) وpods باستخدام dnsPolicy:ClusterFirst (ضمن kubeDNSOverrides). داخل كل منها، هناك كتل خادم افتراضية معرفة: . و cluster.local.

• . تمثل جميع استعلامات DNS الخارجية من البودات التي تحاول حل النطاقات العامة أو غير العنقودية (على سبيل المثال، microsoft.com).

• cluster.local يمثل جميع استعلامات اكتشاف خدمة Kubernetes الداخلية من pods التي تحاول حل أسماء خدمة kubernetes أو موارد نظام المجموعة الداخلية. يتم توجيه هذه الاستعلامات من خلال CoreDNS للحل داخل نظام المجموعة.

الإضافات المدعومة

Plugin	Description	Default	المدخلات المسموح بها
queryLogging	حدد مستوى تسجيل استعلامات DNS.	Error	Error Log
protocol	تعيين البروتوكول المستخدم في استعلامات DNS (تفضيل UDP/TCP).	ForceTCP ل cluster.local، وإلا PreferUDP	PreferUDP ForceTCP
forwardDestination	تحديد خادم DNS لإعادة توجيه الاستعلامات إليه.	ClusterCoreDNS لحركة مرور cluster.local وkubeDNS، غير ذلك VnetDNS	VnetDNS ClusterCoreDNS
forwardPolicy	تحديد النهج الذي يجب استخدامه عند تحديد خادم DNS المصدر.	Sequential	Random RoundRobin Sequential
maxConcurrent	الحد الأقصى لعدد استعلامات DNS المتزامنة التي يتم التعامل معها بواسطة LocalDNS.	1000	Integer
cacheDurationInSeconds	الحد الأقصى ل TTL (مدة البقاء) بالثوان التي يتم تخزين استجابات DNS لها مؤقتا.	3600	Integer
serveStaleDurationInSeconds	المدة (بالثوان) لخدمة استجابات DNS القديمة إذا كانت المصدر غير متوفرة.	3600	Integer
serveStale	نهج لخدمة استجابات DNS التي لا معنى لها أثناء حالات فشل المصدر.	Immediate	Verify Immediate Disabled

قواعد التحقق من صحة التكوين

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

• قيود منطقة الجذر (.): ضمن vnetDNSOverrides، forwardDestination لا يمكن أن يكون ClusterCoreDNSلمنطقة الجذر .

• قيود المنطقة Cluster.local: ضمن كلا vnetDNSOverrides و kubeDNSOverrides، لا يمكن أن forwardDestination يكون cluster.localfor VnetDNS .

• توافق البروتوكول و serveStale: عندما protocol يتم تعيينه على ForceTCP، serveStale لا يمكن تعيينه على Verify. استخدم Immediate بدلاً من ذلك.

Note

يتم فرض قواعد التحقق من الصحة هذه أثناء نشر التكوين. يؤدي انتهاكها إلى فشل التحقق من صحة تكوين LocalDNS.

إنشاء كتلة خادم مخصصة في LocalDNS

يطابق CoreDNS الاستعلامات بكتلة خادم معينة استنادا إلى تطابق تام للمجال الذي يتم الاستعلام فيه وليس على التطابقات الجزئية. إذا كنت بحاجة إلى كتل خادم مخصصة، فيمكنك إضافتها إلى تكوين LocalDNS الخاص بك عن طريق إنشاء ملف يسمى localdnsconfig.json مع التكوينات المضافة.

على سبيل المثال، إذا كان لديك احتياجات DNS محددة عند الوصول إلى microsoft.com، يمكنك استخدام كتلة الخادم التالية:

"microsoft.com": {
  "queryLogging": "Error",
  "protocol": "ForceTCP",
  "forwardDestination": "ClusterCoreDNS",
  "forwardPolicy": "Sequential",
  "maxConcurrent": 1000,
  "cacheDurationInSeconds": 3600,
  "serveStaleDurationInSeconds": 3600,
  "serveStale": "Immediate"
}

مراقبة LocalDNS

يعرض LocalDNS مقاييس بروميثيوس يمكنك استخدامها للمراقبة والتنبيه. يتم عرض هذه المقاييس على منفذ 9253 عنوان IP للعقدة ويمكن كشطها من هناك.

المثال التالي في YAML يظهر تكوين scrape يمكنك استخدامه مع إضافة Azure Managed Prometheus كمجموعة DaemonSet:

kind: ConfigMap
apiVersion: v1
metadata:
  name: ama-metrics-prometheus-config-node
  namespace: kube-system
data:
  prometheus-config: |-
    global:
      scrape_interval: 1m
    scrape_configs:
    - job_name: localdns-metrics
      scrape_interval: 1m
      scheme: http
      metrics_path: /metrics
      relabel_configs:
      - source_labels: [__metrics_path__]
        regex: (.*)
        target_label: metrics_path
      - source_labels: [__address__]
        replacement: '$NODE_NAME'
        target_label: instance
      static_configs:
      - targets: ['$NODE_IP:9253']

استكشاف أخطاء LocalDNS وإصلاحها

فشل استعلامات DNS إلى مجالات محددة

إذا فشلت استعلامات DNS إلى مجالات معينة بعد تمكين LocalDNS:

1. تحقق مما إذا كانت لديك عمليات إلغاء خاصة بالنطاق في localdnsconfig.json قد تكون قد تم ضبطها بشكل خاطئ.
2. حاول بشكل مؤقت إزالة التجاوزات الخاصة بالمجال واستخدام التكوين الافتراضي . فقط.
3. تحقق مما إذا كانت المشكلة تحدث مع كل من بروتوكول مخطط بيانات المستخدم (UDP) وبروتوكول التحكم في الإرسال (TCP) عن طريق ضبط protocol الإعداد.

تحديث خوادم Vnet DNS ل LocalDNS

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

لضمان أن عقد AKS تلتقط إعدادات خادم DNS الجديدة في Vnet:

1. قم بتحديث تكوين DNS الخاص ب Vnet باستخدام بوابة Azure أو واجهات برمجة التطبيقات حسب الحاجة.

2. استخدم مزود موارد AKS لإعادة تصوير مجموعة العقد، مع التأكد من تطبيق إعدادات DNS المحدثة والاحتفاظ بها:

   az aks nodepool upgrade --resource-group myResourceGroup --cluster-name myAKSCluster --name mynodepool --node-image-only
   

تضمن هذه العملية أن موفر موارد AKS على دراية بتغييرات DNS وتطبيقها على جميع العقد في تجمع العقدة.

قم بتحديث سياسات شبكة Cilium للسماح بحل DNS باستخدام LocalDNS

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

سياسات الشبكة تفرض نموذج رفض افتراضي للوجهات غير المحددة، لذا يتم حظر حركة مرور DNS إلى LocalDNS ما لم يكن مسموحا بذلك صراحة.

• على نظام CNI Azure المدعوم بسيليوم <=v1.16 مع k8s <=1.31)، يمكن تحقيق ذلك من خلال سياسة قائمة على CIDR.
• على نظام Azure CNI المدعوم بسيليوم >=v1.17 مع K8s >=1.32)، يمكن استخدام سياسة شبكة Cilium التي تسمح بالخروج إلى الكيانات المضيفة.

يمكن استخدام سياسة شبكة Cilium التالية للسماح بحركة المرور عبر جميع الإصدارات:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "allow-azure-dns-egress"
  namespace: default
spec:
  endpointSelector:
    matchLabels: {} # This selects ALL pods in the namespace
  egress:
    - toCIDR:
        - 169.254.10.0/24
      toPorts:
        - ports:
            - port: "53"
              protocol: UDP
            - port: "53"
              protocol: TCP
    - toEntities:
        - host
      toPorts:
        - ports:
            - port: "53"
              protocol: UDP
            - port: "53"
              protocol: TCP

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

للحصول على معلومات حول LocalDNS في AKS، انظر LocalDNS في Azure Kubernetes Service (مفاهيمي).

للحصول على إرشادات شاملة لحل المشكلات المتعلقة ب DNS عند استخدام LocalDNS، راجع استكشاف مشاكل LocalDNS في AKS.

للحصول على تفاصيل حول كيفية تخصيص CoreDNS في AKS، راجع دليل تخصيص CoreDNS.

للحصول على معلومات بخصوص مشروع CoreDNS، راجع صفحة مشروع CoreDNS في المصدر.

لمعرفة المزيد بخصوص مفاهيم الشبكة الأساسية، راجع مفاهيم الشبكة للتطبيقات في AKS.