مشاركة عبر

أفضل ممارسات النشر وموثوقية نظام المجموعة لخدمة Azure Kubernetes (AKS)

  • مقالة

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

يتم تنظيم أفضل الممارسات في هذه المقالة في الفئات التالية:

الفئة أفضل الممارسات
أفضل ممارسات مستوى التوزيع • ميزانيات تعطيل الجراب (PDBs)
• وحدة المعالجة المركزية وحدود الذاكرة
• خطافات ما قبل الإيقاف
• maxUnavailable
• طوبولوجيا جراب انتشار القيود
• الاستعداد والحيوية وفحوصات الشركات الناشئة
• تطبيقات متعددة النسخ المتماثلة
أفضل ممارسات مستوى المجموعة وتجمع العقدة • مناطق التوفر
• التحجيم التلقائي لنظام المجموعة
• موازن التحميل القياسي
• تجمعات عقد النظام
• الشبكات المتسارعة
• إصدارات الصور
• Azure CNI لتخصيص IP الديناميكي
• v5 SKU VMs
• عدم استخدام الأجهزة الظاهرية من السلسلة B
• الأقراص المتميزة
• نتائج تحليلات الحاوية
• نهج Azure

أفضل ممارسات مستوى التوزيع

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

إشعار

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

ميزانيات تعطيل الجراب (PDBs)

إرشادات أفضل الممارسات

استخدم ميزانيات تعطيل الجراب (PDBs) للتأكد من أن الحد الأدنى لعدد القرون يظل متاحا أثناء الاضطرابات الطوعية، مثل عمليات الترقية أو عمليات حذف الجراب العرضية.

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

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

في ملف تعريف PDB المثال التالي، minAvailable يعين الحقل الحد الأدنى لعدد القرون التي يجب أن تظل متاحة أثناء الاضطرابات الطوعية. يمكن أن تكون القيمة رقما مطلقا (على سبيل المثال، 3) أو نسبة مئوية من العدد المطلوب من pods (على سبيل المثال، 10٪).

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
   name: mypdb
spec:
   minAvailable: 3 # Minimum number of pods that must remain available during voluntary disruptions
   selector:
    matchLabels:
      app: myapp

لمزيد من المعلومات، راجع التخطيط للتوفر باستخدام PDBs وتحديد موازنة التعطيل للتطبيق الخاص بك.

وحدة المعالجة المركزية والجراب وحدود الذاكرة

إرشادات أفضل الممارسات

قم بتعيين حدود وحدة المعالجة المركزية والذاكرة لكل وحدات الجراب للتأكد من أن الجرابات لا تستهلك جميع الموارد على عقدة ولتوفير الحماية أثناء تهديدات الخدمة، مثل هجمات DDoS.

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

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

في المثال التالي لملف تعريف pod، resources يعين القسم حدود وحدة المعالجة المركزية والذاكرة للحجيرة:

kind: Pod
apiVersion: v1
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
      limits:
        cpu: 250m
        memory: 256Mi

تلميح

يمكنك استخدام kubectl describe node الأمر لعرض وحدة المعالجة المركزية وسعة الذاكرة للعقد الخاصة بك، كما هو موضح في المثال التالي:

kubectl describe node <node-name>

# Example output
Capacity:
 cpu:                8
 ephemeral-storage:  129886128Ki
 hugepages-1Gi:      0
 hugepages-2Mi:      0
 memory:             32863116Ki
 pods:               110
Allocatable:
 cpu:                7820m
 ephemeral-storage:  119703055367
 hugepages-1Gi:      0
 hugepages-2Mi:      0
 memory:             28362636Ki
 pods:               110

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

خطافات ما قبل الإيقاف

إرشادات أفضل الممارسات

عند الاقتضاء، استخدم خطافات الإيقاف المسبق لضمان الإنهاء بأمان للحاوية.

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

يوضح ملف تعريف جراب المثال التالي كيفية استخدام خطاف PreStop لضمان الإنهاء بأمان للحاوية:

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: nginx
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]
      preStop:
        exec:
          command: ["/bin/sh","-c","nginx -s quit; while killall -0 nginx; do sleep 1; done"]

لمزيد من المعلومات، راجع خطافات دورة حياة الحاوية وإنهاء الجرابات.

maxUnavailable

إرشادات أفضل الممارسات

حدد الحد الأقصى لعدد pods التي يمكن أن تكون غير متوفرة أثناء التحديث المتداول باستخدام maxUnavailable الحقل في النشر الخاص بك للتأكد من أن الحد الأدنى لعدد pods يظل متوفرا أثناء الترقية.

maxUnavailable يحدد الحقل الحد الأقصى لعدد الجرابات التي يمكن أن تكون غير متوفرة أثناء عملية التحديث. يمكن أن تكون القيمة رقما مطلقا (على سبيل المثال، 3) أو نسبة مئوية من العدد المطلوب من pods (على سبيل المثال، 10٪). maxUnavailable يتعلق بواجهة برمجة تطبيقات حذف، والتي يتم استخدامها أثناء التحديثات المتداولة.

يستخدم maxAvailable مثال بيان النشر التالي الحقل لتعيين الحد الأقصى لعدد pods التي يمكن أن تكون غير متوفرة أثناء عملية التحديث:

apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
 labels:
   app: nginx
spec:
 replicas: 3
 selector:
   matchLabels:
     app: nginx
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - name: nginx
       image: nginx:1.14.2
       ports:
       - containerPort: 80
 strategy:
   type: RollingUpdate
   rollingUpdate:
     maxUnavailable: 1 # Maximum number of pods that can be unavailable during the upgrade

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

قيود انتشار مخطط الجراب

إرشادات أفضل الممارسات

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

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

يوضح ملف تعريف pod المثال التالي كيفية استخدام topologySpreadConstraints الحقل لنشر pods عبر عقد مختلفة:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  # Configure a topology spread constraint
  topologySpreadConstraints:
    - maxSkew: <integer>
      minDomains: <integer> # optional
      topologyKey: <string>
      whenUnsatisfiable: <string>
      labelSelector: <object>
      matchLabelKeys: <list> # optional
      nodeAffinityPolicy: [Honor|Ignore] # optional
      nodeTaintsPolicy: [Honor|Ignore] # optional

لمزيد من المعلومات، راجع Pod Topology Spread Constraints.

الاستعداد والحيوية وفحوصات بدء التشغيل

إرشادات أفضل الممارسات

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

فحوصات الجاهزية

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

يوضح ملف تعريف pod المثال التالي تكوين فحص الجاهزية:

readinessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
  initialDelaySeconds: 5
  periodSeconds: 5

لمزيد من المعلومات، راجع تكوين فحوصات الجاهزية.

فحوصات الحياة

في Kubernetes، يستخدم kubelet تحقيقات الحياة لمعرفة متى يتم إعادة تشغيل حاوية. إذا فشلت الحاوية في فحص فعالية الحاوية، تتم إعادة تشغيل الحاوية. لمزيد من المعلومات، راجع تحقيقات الحياة في Kubernetes.

يوضح ملف تعريف pod المثال التالي تكوين فحص الحياة:

livenessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy

يستخدم نوع آخر من فحص الحياة طلب HTTP GET. يعرض ملف تعريف pod المثال التالي تكوين فحص فعالية طلب HTTP GET:

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: registry.k8s.io/liveness
    args:
    - /server
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

لمزيد من المعلومات، راجع تكوين تحقيقات الحياة وتحديد طلب HTTP للحيوية.

فحوصات بدء التشغيل

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

يوضح مثال ملف تعريف pod التالي تكوين فحص بدء التشغيل:

startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  failureThreshold: 30
  periodSeconds: 10

تطبيقات متعددة النسخ المتماثلة

إرشادات أفضل الممارسات

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

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

يوضح مثال ملف تعريف pod التالي كيفية استخدام replicas الحقل لتحديد عدد pods التي تريد تشغيلها:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

لمزيد من المعلومات، راجع نظرة عامة على حل التوفر العالي النشط النشط الموصى به ل AKS والنسخ المتماثلة في مواصفات النشر.

أفضل ممارسات مستوى المجموعة وتجمع العقدة

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

مجموعات التوافر

إرشادات أفضل الممارسات

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

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

التحجيم التلقائي للكتلة

إرشادات أفضل الممارسات

استخدم التحجيم التلقائي لنظام المجموعة للتأكد من أن نظام المجموعة الخاص بك يمكنه التعامل مع زيادة الحمل وتقليل التكاليف أثناء الحمل المنخفض.

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

يمكنك استخدام المعلمة --enable-cluster-autoscaler عند إنشاء نظام مجموعة AKS لتمكين مقياس المجموعة التلقائي، كما هو موضح في المثال التالي:

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 2 \
    --vm-set-type VirtualMachineScaleSets \
    --load-balancer-sku standard \
    --enable-cluster-autoscaler  \
    --min-count 1 \
    --max-count 3 \
    --generate-ssh-keys

يمكنك أيضا تمكين مقياس المجموعة التلقائي على تجمع عقدة موجود وتكوين تفاصيل أكثر دقة من مقياس المجموعة التلقائي عن طريق تغيير القيم الافتراضية في ملف تعريف التحجيم التلقائي على مستوى المجموعة.

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

Standard Load Balancer

إرشادات أفضل الممارسات

استخدم موازن التحميل القياسي لتوفير قدر أكبر من الموثوقية والموارد، ودعم مناطق توفر متعددة، وفحوصات HTTP، والوظائف عبر مراكز بيانات متعددة.

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

هام

في 30 سبتمبر 2025، سيتم إيقاف موازن التحميل الأساسي. لمزيد من المعلومات، راجع الإعلان الرسمي. نوصي باستخدام موازن التحميل القياسي لإجراء عمليات نشر جديدة وترقية عمليات التوزيع الحالية إلى موازن التحميل القياسي. لمزيد من المعلومات، راجع الترقية من موازن التحميل الأساسي.

يوضح LoadBalancer المثال التالي بيان خدمة يستخدم موازن التحميل القياسي:

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-ipv4 # Service annotation for an IPv4 address
  name: azure-load-balancer
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: azure-load-balancer

لمزيد من المعلومات، راجع استخدام موازن تحميل قياسي في AKS.

تلميح

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

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

استخدام تجمعات عقد النظام المخصصة

إرشادات أفضل الممارسات

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

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

التحجيم التلقائي لتجمعات عقد النظام

إرشادات أفضل الممارسات

قم بتكوين مقياس تلقائي لتجمعات عقد النظام لتعيين الحد الأدنى والحد الأقصى لحدود المقياس لتجمع العقدة.

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

لمزيد من المعلومات، راجع استخدام مقياس المجموعة التلقائي على تجمعات العقد.

ثلاث عقد على الأقل لكل تجمع عقدة نظام

إرشادات أفضل الممارسات

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

يتم استخدام تجمعات عقد النظام لتشغيل قرون النظام، مثل kube-proxy وcoredns والمكون الإضافي Azure CNI. نوصي بالتأكد من أن تجمعات عقد النظام تحتوي على ثلاث عقد على الأقل لضمان المرونة مقابل سيناريوهات التجميد/الترقية، والتي يمكن أن تؤدي إلى إعادة تشغيل العقد أو إيقاف تشغيلها. لمزيد من المعلومات، راجع إدارة تجمعات عقد النظام في AKS.

تسريع الشبكات

إرشادات أفضل الممارسات

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

تمكن الشبكات المسرعة ظاهرية الإدخال/الإخراج الجذرية الفردية (SR-IOV) على أنواع الأجهزة الظاهرية المدعومة، مما يحسن أداء الشبكات بشكل كبير.

يوضح الرسم التخطيطي التالي كيفية اتصال جهازين ظاهريين بالشبكات المتسارعة وبدونهما:

لقطة شاشة تعرض الاتصال بين أجهزة Azure الظاهرية مع الشبكات المتسارعة وبدونها.

لمزيد من المعلومات، راجع نظرة عامة على الشبكات المسرعة.

إصدارات الصور

إرشادات أفضل الممارسات

يجب ألا تستخدم الصور العلامة latest .

علامات صورة الحاوية

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

ترقية صورة العقدة

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

المستوى القياسي لأحمال عمل الإنتاج

إرشادات أفضل الممارسات

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

يوفر المستوى القياسي لخدمة Azure Kubernetes (AKS) اتفاقية مستوى خدمة وقت التشغيل (SLA) المدعومة ماليا بنسبة 99.9٪ لأحمال عمل الإنتاج الخاصة بك. يوفر المستوى القياسي أيضا موثوقية وموارد أكبر للمجموعة، ودعما لما يصل إلى 5000 عقدة في نظام مجموعة، وتمكين اتفاقية مستوى الخدمة في وقت التشغيل بشكل افتراضي. لمزيد من المعلومات، راجع مستويات التسعير لإدارة نظام مجموعة AKS.

Azure CNI لتخصيص IP الديناميكي

إرشادات أفضل الممارسات

تكوين Azure CNI لتخصيص IP الديناميكي لتحسين استخدام IP ومنع استنفاد IP لمجموعات AKS.

تخصص إمكانية تخصيص IP الديناميكية في Azure CNI عناوين IP الخاصة بالجراب من شبكة فرعية منفصلة عن الشبكة الفرعية التي تستضيف مجموعة AKS وتقدم الفوائد التالية:

  • استخدام أفضل لـ IP:يتم تخصيص IP بشكل حيوي إلى مجموعة وحدات الجراب من الشبكة الفرعية لوحدات الجراب. وهذا يؤدي إلى استخدام أفضل لـ IPs في نظام المجموعة مقارنةً مع حل CNI التقليدي، الذي لا يمتلك تخصيص ثابت من عناوين الإنترنت لكل عقدة.
  • القابلية للتحجيم والمرونة: يمكن تحجيم الشبكات الفرعية للعقدة ووحدة الجراب بشكلٍ مستقل. يمكن مشاركة شبكة فرعية واحدة لوحدة جراب عبر تجمعات عقد متعددة لنظام مجموعة أو عبر أنظمة مجموعات AKS المتعددة المنشورة في نفس الشبكة الظاهرية. يمكنك أيضاً تكوين شبكة فرعية منفصلة لوحدة الجراب وتجمع العقدة.
  • أداء عال: نظرا لتعيين وحدات الجراب ل IPs للشبكة الظاهرية، فإن لديها اتصالا مباشرا بوحدات نظام المجموعة والموارد الأخرى في الشبكة الظاهرية. يدعم الحل أنظمة مجموعات كبيرة جداً دون أي تدهور في الأداء.
  • نُهج الشبكة الظاهرية المنفصلة لوحدات الجراب: نظرًا لأن وحدات الجراب لها شبكة فرعية منفصلة، يمكنك تكوين نُهج شبكة ظاهرية منفصلة لهم تختلف عن نُهج العقدة. يتيح هذا العديد من السيناريوهات المفيدة مثل السماح بالاتصال بالإنترنت فقط للقرون وليس للعقد، وإصلاح IP المصدر للحجيرة في تجمع عقدة باستخدام بوابة Azure NAT، واستخدام NSGs لتصفية نسبة استخدام الشبكة بين تجمعات العقد.
  • نهج شبكة Kubernetes: تعمل كل من نهج شبكة Azure وCalico مع هذا الحل.

لمزيد من المعلومات، راجع تكوين شبكة Azure CNI للتخصيص الديناميكي لعناوين IP ودعم الشبكة الفرعية المحسن.

v5 SKU VMs

إرشادات أفضل الممارسات

استخدم v5 VM SKUs لتحسين الأداء أثناء التحديثات وبعدها، وتأثير أقل إجماليا، واتصال أكثر موثوقية لتطبيقاتك.

بالنسبة لتجمعات العقد في AKS، استخدم v5 SKU VMs مع أقراص نظام التشغيل سريعة الزوال لتوفير موارد حساب كافية لوحدات kube-system. لمزيد من المعلومات، راجع أفضل الممارسات للأداء وتوسيع نطاق أحمال العمل الكبيرة في AKS.

لا تستخدم الأجهزة الظاهرية لسلسلة B

إرشادات أفضل الممارسات

لا تستخدم الأجهزة الظاهرية من السلسلة B لمجموعات AKS لأنها منخفضة الأداء ولا تعمل بشكل جيد مع AKS.

الأجهزة الظاهرية من السلسلة B منخفضة الأداء ولا تعمل بشكل جيد مع AKS. بدلا من ذلك، نوصي باستخدام v5 SKU VMs.

الأقراص المتميزة

إرشادات أفضل الممارسات

استخدم الأقراص المتميزة لتحقيق توفر بنسبة 99.9٪ في جهاز ظاهري واحد (VM).

توفر Azure Premium Disks زمن انتقال ثابت للقرص دون الثانية وIOOPS عالي وفي جميع أنحاء. تم تصميم الأقراص المتميزة لتوفير أداء قرص منخفض الكمون وعالي الأداء ومتسق للأجهزة الظاهرية.

يوضح مثال بيان YAML التالي تعريف فئة التخزين لقرص متميز:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
   name: premium2-disk-sc
parameters:
   cachingMode: None
   skuName: PremiumV2_LRS
   DiskIOPSReadWrite: "4000"
   DiskMBpsReadWrite: "1000"
provisioner: disk.csi.azure.com
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true

لمزيد من المعلومات، راجع استخدام أقراص Azure Premium SSD v2 على AKS.

نتائج تحليلات الحاوية

إرشادات أفضل الممارسات

تمكين Container Insights لمراقبة وتشخيص أداء التطبيقات الحاوية.

Container Insights هي ميزة من ميزات Azure Monitor التي تجمع وتحلل سجلات الحاويات من AKS. يمكنك تحليل البيانات التي تم جمعها باستخدام مجموعة من طرق العرض والمصنفات التي تم إنشاؤها مسبقا.

يمكنك تمكين مراقبة Container Insights على مجموعة AKS الخاصة بك باستخدام أساليب مختلفة. يوضح المثال التالي كيفية تمكين مراقبة Container Insights على مجموعة موجودة باستخدام Azure CLI:

az aks enable-addons -a monitoring --name myAKSCluster --resource-group myResourceGroup

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

نهج Azure

إرشادات أفضل الممارسات

تطبيق وفرض متطلبات الأمان والتوافق لمجموعات AKS باستخدام نهج Azure.

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

لمزيد من المعلومات، راجع تأمين مجموعات AKS باستخدام نهج Azure.

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

ركزت هذه المقالة على أفضل الممارسات للتوزيع وموثوقية نظام المجموعة لمجموعات Azure Kubernetes Service (AKS). لمزيد من أفضل الممارسات، راجع المقالات التالية: