مشاركة عبر

استخدام موازن تحميل قياسي عام في خدمة Azure Kubernetes (AKS)

  • مقالة

يعمل Azure Load Balancer في الطبقة 4 من نموذج Open Systems Interconnection (OSI) الذي يدعم كلا من السيناريوهات الواردة والصادرة. يوزع التدفقات الواردة التي تصل إلى الواجهة الأمامية لموازن التحميل إلى مثيلات تجمع النهاية الخلفية.

يخدم موازن التحميل العام المتكامل مع AKS غرضين:

  1. لتوفير اتصالات صادرة إلى عقد نظام المجموعة داخل شبكة AKS الظاهرية عن طريق ترجمة عنوان IP الخاص إلى جزء عنوان IP عام من تجمع الصادر الخاص به.
  2. لتوفير الوصول إلى التطبيقات عبر خدمات Kubernetes من النوع LoadBalancer، مما يتيح لك توسيع نطاق تطبيقاتك بسهولة وإنشاء خدمات عالية التوفر.

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

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

قبل البدء

  • يتوفر موازن تحميل Azure في وحدتي SKU: أساسي وقياسي. يتم استخدام SKU القياسي بشكل افتراضي عند إنشاء نظام مجموعة AKS. يتيح Standard SKU لك الوصول إلى الوظائف المضافة، مثل تجمع خلفية أكبر، وتجمعات عقد متعددة، ومناطق توافر، كما أنه مؤمن بشكل افتراضي. إنه SKU موازن التحميل الموصى به ل AKS. لمزيد من المعلومات حول وحدات SKU الأساسية والقياسية، راجع مقارنة Azure Load Balancer SKU.
  • للحصول على قائمة كاملة بالتعليقات التوضيحية المدعومة لخدمات Kubernetes ذات النوع LoadBalancer، راجع التعليقات التوضيحية ل LoadBalancer.
  • تفترض هذه المقالة أن لديك نظام مجموعة AKS مع موازن تحميل SKU Azure القياسي . إذا كنت بحاجة إلى نظام مجموعة AKS، يمكنك إنشاء مجموعة باستخدام Azure CLI أو Azure PowerShell أو مدخل Azure.
  • تدير AKS دورة حياة عقد العامل وعملياتها. تعديل موارد IaaS المقترنة بعقد العامل غير مدعوم. مثال على عملية غير مدعومة هو إجراء تغييرات يدوية على مجموعة موارد موازن التحميل.

هام

إذا كنت تفضل استخدام البوابة الخاصة بك أو جدار الحماية أو الوكيل لتوفير اتصال صادر، يمكنك تخطي إنشاء تجمع موازن التحميل الصادر وعنوان IP للواجهة الأمامية المعنية باستخدام النوع الصادر ك UserDefinedRouting (UDR). يحدد النوع الصادر أسلوب الخروج لنظام مجموعة ويكتب افتراضيا LoadBalancer.

أنشئ موازن تحميل قياسي عام

بعد إنشاء نظام مجموعة AKS بنوع LoadBalancer صادر (افتراضي)، تكون مجموعتك جاهزة لاستخدام موازن التحميل لعرض الخدمات.

إنشاء بيان خدمة باسم public-svc.yaml، والذي ينشئ خدمة عامة من النوع LoadBalancer.

apiVersion: v1
kind: Service
metadata:
  name: public-svc
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: public-app

تحديد عنوان IP لموازن التحميل

إذا كنت تريد استخدام عنوان IP محدد مع موازن التحميل، فهناك طريقتان:

هام

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

  • تعيين التعليقات التوضيحية للخدمة: استخدم service.beta.kubernetes.io/azure-load-balancer-ipv4 لعنوان IPv4 ولعنوان service.beta.kubernetes.io/azure-load-balancer-ipv6 IPv6.
  • أضف الخاصية LoadBalancerIP إلى بيان YAML لموازن التحميل: أضف الخاصية Service.Spec.LoadBalancerIP إلى بيان YAML لموازن التحميل. هذا الحقل مهمل متابعة Kubernetes المصدر، ولا يمكنه دعم المكدس المزدوج. يظل الاستخدام الحالي كما هو ومن المتوقع أن تعمل الخدمات الحالية دون تعديل.

نشر بيان الخدمة

انشر بيان الخدمة العامة باستخدام kubectl apply وحدد اسم بيان YAML الخاص بك.

kubectl apply -f public-svc.yaml

يتم تكوين Azure Load Balancer باستخدام IP عام جديد أمام الخدمة الجديدة. نظرا لأن Azure Load Balancer يمكن أن يحتوي على عناوين IP متعددة للواجهة الأمامية، فإن كل خدمة جديدة تقوم بنشرها تحصل على IP واجهة أمامية مخصصة جديدة للوصول إليها بشكل فريد.

تأكد من إنشاء الخدمة وتكوين موازن التحميل باستخدام الأمر التالي.

kubectl get service public-svc

NAMESPACE     NAME          TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)         AGE
default       public-svc    LoadBalancer   10.0.39.110    52.156.88.187   80:32068/TCP    52s

عند عرض تفاصيل الخدمة، يتم عرض عنوان IP الخاص بموازن التحميل العام الذي تم إنشاؤه في موازن التحميل في العمود EXTERNAL-IP. قد يستغرق الأمر بضع دقائق حتى يتغير عنوان IP من <معلق> إلى عنوان IP عام فعلي.

لمزيد من المعلومات التفصيلية حول الخدمة، استخدم الأمر التالي.

kubectl describe service public-svc

إخراج المثال التالي هو إصدار مكثف من الإخراج بعد تشغيل kubectl describe service. يعرض دخول LoadBalancer عنوان IP الخارجي الذي تعرضه خدمتك. يظهر IP العناوين الداخلية.

Name:                        public-svc
Namespace:                   default
Labels:                      <none>
Annotations:                 <none>
Selector:                    app=public-app
...
IP:                          10.0.39.110
...
LoadBalancer Ingress:        52.156.88.187
...
TargetPort:                  80/TCP
NodePort:                    32068/TCP
...
Session Affinity:            None
External Traffic Policy:     Cluster
...

تكوين موازن تحميل قياسي عام

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

  • تعيين عدد عناوين IP الصادرة المدارة أو تغيير حجمها.
  • أحضر عناوين IP الصادرة المخصصة أو بادئة IP الصادرة.
  • تخصيص عدد المنافذ الصادرة المخصصة لكل عقدة على نظام المجموعة.
  • تكوين إعداد المهلة للاتصالات الخاملة.

هام

يمكن استخدام خيار IP صادر واحد فقط (عناوين IP المدارة أو إحضار IP الخاص بك أو بادئة IP) في وقت معين.

تغيير نوع التجمع الوارد

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

يتوفر نوعان مختلفان من عضوية التجمع:

  • nodeIPConfiguration - نوع عضوية التجمع المستند إلى تكوين مجموعات مقياس الجهاز الظاهري القديم
  • nodeIP - نوع العضوية المستندة إلى IP

المتطلبات

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

إنشاء مجموعة AKS جديدة مع عضوية مجموعة واردة مستندة إلى IP

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-backend-pool-type=nodeIP \
    --generate-ssh-keys

تحديث نظام مجموعة AKS موجود لاستخدام عضوية التجمع الوارد المستند إلى IP

تحذير

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

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-backend-pool-type=nodeIP

قياس عدد عناوين IP الصادرة المدارة

يوفر Azure Load Balancer اتصالا صادرا وواردا من شبكة ظاهرية. تجعل القواعد الصادرة من السهل تكوين ترجمة عنوان الشبكة لموازن التحميل القياسي العام.

تتبع القواعد الصادرة نفس بناء الجملة مثل موازنة التحميل وقواعد NAT الواردة:

عناوين IP الأمامية + المعلمات + تجمع الخلفية

تكوِّن قاعدة الصادر NAT الصادر لجميع الأجهزة الظاهرية التي يحددها تجمع الواجهة الخلفية لترجمتها إلى الواجهة الأمامية. توفر المعلمات مزيدا من التحكم في خوارزمية NAT الصادرة.

بينما يمكنك استخدام قاعدة صادرة بعنوان IP عام واحد، فإن القواعد الصادرة رائعة لتوسيع نطاق NAT الصادر لأنها تخفف من عبء التكوين. يمكنك استخدام عناوين IP متعددة للتخطيط لسيناريوهات واسعة النطاق وقواعد صادرة للتخفيف من الأنماط المعرضة لاستنفاد SNAT. يوفر كل عنوان IP توفره الواجهة الأمامية منافذ سريعة الزوال 64 ألف لموازن التحميل لاستخدامها كمنافذ SNAT.

عند استخدام موازن تحميل SKU قياسي مع عناوين IP العامة الصادرة المدارة (التي يتم إنشاؤها بشكل افتراضي)، يمكنك قياس عدد عناوين IP العامة الصادرة المدارة باستخدام المعلمة --load-balancer-managed-outbound-ip-count .

استخدم الأمر التالي لتحديث نظام مجموعة موجود. يمكنك أيضا تعيين هذه المعلمة إلى عناوين IP عامة صادرة متعددة مدارة.

هام

لا نوصي باستخدام مدخل Microsoft Azure لإجراء أي تغييرات في القاعدة الصادرة. عند إجراء هذه التغييرات، يجب الانتقال من خلال نظام مجموعة AKS وليس مباشرة على مورد Load Balancer.

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

استخدم Azure CLI، كما هو موضح في الأمثلة. تغييرات القاعدة الصادرة التي يتم إجراؤها باستخدام az aks أوامر CLI دائمة عبر وقت تعطل نظام المجموعة.

لمزيد من المعلومات، راجع قواعد Azure Load Balancer الصادرة.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-managed-outbound-ip-count 2

المثال أعلاه يعين عدد عناوين IP المدارة الصادرة العامة إلى 2 لنظام المجموعة myAKSCluster في myResourceGroup.

في وقت إنشاء نظام المجموعة، يمكنك أيضا تعيين العدد الأولي من عناوين IP العامة الصادرة المدارة عن طريق إلحاق المعلمة --load-balancer-managed-outbound-ip-count وتعيينها إلى القيمة المطلوبة. العدد الافتراضي ل IPs العامة الصادرة المدارة هو 1.

توفير عناوين الصادرة العامة الخاصة بك أو البادئات

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

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

تتضمن متطلبات استخدام IP أو البادئة العامة الخاصة بك ما يلي:

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

تحديث نظام المجموعة مع IP العامة الصادرة الخاصة بك

az network public-ip show استخدم الأمر لسرد معرفات عناوين IP العامة.

az network public-ip show --resource-group myResourceGroup --name myPublicIP --query id -o tsv

يُظهر الأمر أعلاه معرف IP العام myPublicIP في مجموعة موارد myResourceGroup.

استخدم الأمر az aks update مع المعلمة load-balancer-outbound-ips لتحديث نظام المجموعة بعناوين IP العامة.

يستخدم المثال التالي المعلمة load-balancer-outbound-ips مع معرفات من الأمر السابق.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-outbound-ips <publicIpId1>,<publicIpId2>

تحديث نظام المجموعة ببادئة IP العامة الصادرة الخاصة بك

يمكنك أيضا استخدام بادئات IP العامة للخروج بموازن تحميل SKU قياسي. يستخدم المثال التالي الأمر az network public-ip prefix show لسرد معرفات بادئات IP العامة.

az network public-ip prefix show --resource-group myResourceGroup --name myPublicIPPrefix --query id -o tsv

يُظهر الأمر أعلاه معرف بادئة IP العام myPublicIPPrefix في مجموعة موارد myResourceGroup.

يستخدم المثال التالي المعلمة load-balancer-outbound-ip-prefixes مع معرفات من الأمر السابق.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-outbound-ip-prefixes <publicIpPrefixId1>,<publicIpPrefixId2>

إنشاء نظام المجموعة بـIP العام أو البادئات الخاصة بك

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

az aks create استخدم الأمر مع المعلمة load-balancer-outbound-ips لإنشاء نظام مجموعة جديد مع عناوين IP العامة الخاصة بك.

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-outbound-ips <publicIpId1>,<publicIpId2> \
    --generate-ssh-keys

az aks create استخدم الأمر مع المعلمة load-balancer-outbound-ip-prefixes لإنشاء نظام مجموعة جديد مع بادئات IP العامة الخاصة بك.

az aks create \
    --resource-group myResourceGroup \
    --load-balancer-outbound-ip-prefixes <publicIpPrefixId1>,<publicIpPrefixId2> \
    --generate-ssh-keys

تكوين المنافذ الصادرة المخصصة

هام

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

لمزيد من المعلومات حول SNAT، راجع استخدام SNAT للاتصالات الصادرة.

بشكل افتراضي، يقوم AKS بتعيين AllocatedOutboundPorts في موازنة التحميل الخاصة به على 0، إذ يمكن تعيين المنفذ الصادر تلقائيًا استنادًا إلى حجم تجمع الخلفية عند إنشاء نظام مجموعة ما. على سبيل المثال، إذا كان نظام المجموعة يحتوي على 50 عقدة أو أقل، يخصَّص 1024 منفذًا لكل عقدة. مع زيادة عدد العقد في نظام المجموعة، يتوفر عدد أقل من المنافذ لكل عقدة.

هام

هناك حد ثابت يبلغ 1024 منفذا بغض النظر عما إذا كانت عناوين IP للواجهة الأمامية تضاف عندما يكون حجم العقدة أقل من أو يساوي 50 (1-50).

لإظهار قيمة AllocatedOutboundPorts في موازنة التحميل لدى نظام مجموعة AKS، استخدم az network lb outbound-rule list.

NODE_RG=$(az aks show --resource-group myResourceGroup --name myAKSCluster --query nodeResourceGroup -o tsv)
az network lb outbound-rule list --resource-group $NODE_RG --lb-name kubernetes -o table

يوضح إخراج المثال التالي تمكين تعيين المنفذ الصادر التلقائي استنادا إلى حجم تجمع الخلفية لنظام المجموعة.

AllocatedOutboundPorts    EnableTcpReset    IdleTimeoutInMinutes    Name             Protocol    ProvisioningState    ResourceGroup
------------------------  ----------------  ----------------------  ---------------  ----------  -------------------  -------------
0                         True              30                      aksOutboundRule  All         Succeeded            MC_myResourceGroup_myAKSCluster_eastus

لتكوين قيمة معينة في AllocatedOutboundPorts وعنوان IP الصادر عند إنشاء مجموعة ما أو تحديثها، استخدم load-balancer-outbound-ports وإما load-balancer-managed-outbound-ip-count أو load-balancer-outbound-ips أو load-balancer-outbound-ip-prefixes. قبل تعيين قيمة معينة أو زيادة قيمة موجودة إما للمنافذ الصادرة أو عناوين IP الصادرة، يجب حساب العدد المناسب من المنافذ الصادرة وعناوين IP. استخدم المعادلة التالية في هذه العملية الحسابية مع تقريبه إلى أقرب عدد صحيح: 64,000 ports per IP / <outbound ports per node> * <number of outbound IPs> = <maximum number of nodes in the cluster>.

عند حساب عدد المنافذ الصادرة وIPs وتعيين القيم، ضع المعلومات التالية في الاعتبار:

  • يتم إصلاح عدد المنافذ الصادرة لكل عقدة استنادا إلى القيمة التي قمت بتعيينها.
  • يجب أن تكون قيمة المنافذ الصادرة من مضاعفات العدد 8.
  • لا تضيف إضافة المزيد من عناوين IP المزيد من المنافذ إلى أي عقدة، ولكنها توفر سعة لمزيد من العقد في نظام المجموعة.
  • يجب حساب العقد التي قد تتم إضافتها كجزء من الترقيات، بما في ذلك عدد العقد المحددة عبر قيم maxSurge.

توضح الأمثلة التالية كيفية تأثير القيم التي قمت بتعيينها على عدد المنافذ الصادرة وعناوين IP:

  • إذا تم استخدام القيم الافتراضية وكان نظام المجموعة يحتوي على 48 عقدة، فإن كل عقدة تحتوي على 1024 منفذا متوفرا.
  • إذا تم استخدام القيم الافتراضية وتدرج نظام المجموعة من 48 إلى 52 عقدة، يتم تحديث كل عقدة من 1024 منفذا متوفرا إلى 512 منفذا متوفرا.
  • إذا تم تعيين عدد المنافذ الصادرة إلى 1000 وتم تعيين عدد IP الصادر إلى 2، فيمكن لنظام المجموعة دعم 128 عقدة كحد أقصى: 64,000 ports per IP / 1,000 ports per node * 2 IPs = 128 nodes.
  • إذا تم تعيين عدد المنافذ الصادرة إلى 1000 وتم تعيين عدد IP الصادر إلى 7، فيمكن لنظام المجموعة دعم 448 عقدة كحد أقصى: 64,000 ports per IP / 1,000 ports per node * 7 IPs = 448 nodes.
  • إذا تم تعيين عدد المنافذ الصادرة إلى 4000 وتم تعيين عدد IP الصادر إلى 2، فيمكن لنظام المجموعة دعم 32 عقدة كحد أقصى: 64,000 ports per IP / 4,000 ports per node * 2 IPs = 32 nodes.
  • إذا تم تعيين عدد المنافذ الصادرة إلى 4000 وتم تعيين عدد IP الصادر إلى 7، فيمكن لنظام المجموعة دعم 112 عقدة كحد أقصى: 64,000 ports per IP / 4,000 ports per node * 7 IPs = 112 nodes.

هام

بعد حساب عدد المنافذ الصادرة وعناوين IP، تحقق من أن لديك سعة إضافية للمنافذ الصادرة للتعامل مع زيادة العقد في أثناء الترقيات. من الضروري تخصيص منافذ زائدة كافية للعقد الإضافية اللازمة للترقية والعمليات الأخرى. يتم تعيين AKS افتراضيًا إلى عقدة مخزن مؤقت واحدة في عمليات الترقية. إذا كنت تستخدم قيم maxSurge، فاضرب عدد المنافذ الصادرة لكل عقدة بقيمة maxSurge لتحديد عدد المنافذ المطلوبة. على سبيل المثال، إذا قمت بحساب أنك بحاجة إلى 4000 منفذ لكل عقدة مع عنوان IP 7 على نظام مجموعة بحد أقصى 100 عقدة وبحد أقصى زيادة قدرها 2:

  • 2 عقدة تدفق * 4000 منفذ لكل عقدة = 8000 منفذ يلزم توفيرهم لزيادة تدفق العقد أثناء الترقيات.
  • 100 عقدة * 4000 منفذ لكل عقدة = 400,000 منفذ يلزم توفيرهم في نظام المجموعة.
  • 7 عناوين IP * 64000 منفذ لكل عنوان IP = 448,000 منفذ متاحين في نظام المجموعة.

يوضح المثال المذكور أعلاه أن نظام المجموعة يحتوي على سعة زائدة تضم 48,000 منفذ، وهو ما يكفي للتعامل مع 8000 منفذ يلزم توفيرهم لزيادة تدفق العقد في أثناء الترقيات.

بمجرد حساب القيم والتحقق منها، يمكنك تطبيق هذه القيم باستخدام load-balancer-outbound-ports وإما load-balancer-managed-outbound-ip-count أو load-balancer-outbound-ips أو load-balancer-outbound-ip-prefixes عند إنشاء نظام مجموعة ما أو تحديثه.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-managed-outbound-ip-count 7 \
    --load-balancer-outbound-ports 4000

تكوين مهلة الخمول موازن التحميل

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

يمكنك أيضا استخدام النقل (على سبيل المثال، TCP keepalives أو application-layer keepalives) لتحديث تدفق الخمول وإعادة تعيين مهلة الخمول هذه إذا لزم الأمر. يمكنك تكوين هذه المهلة باتباع المثال أدناه.

az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --load-balancer-idle-timeout 4

إذا كنت تتوقع أن يكون لديك العديد من الاتصالات قصيرة الأجل ولا توجد اتصالات طويلة الأمد قد يكون لها أوقات طويلة من الخمول، مثل استخدام kubectl proxy أو kubectl port-forward، ففكر في استخدام قيمة مهلة منخفضة مثل 4 دقائق. عند استخدام TCP النشطة، يكفي تمكينها على جانب واحد من الاتصال. على سبيل المثال، يكفي تمكينها على جانب الخادم فقط لإعادة تعيين مؤقت الخمول للتدفق. ليس من الضروري لكلا الجانبين بدء TCP keepalives. توجد مفاهيم مماثلة لطبقة التطبيق، بما في ذلك تكوينات قاعدة بيانات الخادم-العميل. تحقق من جانب الخادم بحثًا عن الخيارات الموجودة لـ keepalives الخاصة بالتطبيق.

هام

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

يتم إرسال TCP RST فقط أثناء اتصال TCP في حالة التأسيس. يمكنك قراءة المزيد عن ذلك من هنا.

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

تحذير

قد يؤدي تغيير قيم AllocatedOutboundPorts وIdleTimeoutInMinutes إلى تغيير كبير في سلوك القاعدة الصادرة لموازن التحميل الخاص بك ولا ينبغي القيام به بشكل خفيف. تحقق من قسم استكشاف أخطاء SNAT وإصلاحها وراجع القواعد الصادرة ل Load Balancer والاتصالات الصادرة في Azure قبل تحديث هذه القيم لفهم تأثير التغييرات بشكل كامل.

تقييد نسبة استخدام الشبكة الواردة لنطاقات IP محددة

يستخدم البيان التالي loadBalancerSourceRanges لتحديد نطاق IP جديد لنسبة استخدام الشبكة الخارجية الواردة.

apiVersion: v1
kind: Service
metadata:
  name: azure-vote-front
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: azure-vote-front
  loadBalancerSourceRanges:
  - MY_EXTERNAL_IP_RANGE

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

إشعار

  • تتدفق نسبة استخدام الشبكة الخارجية الواردة من موازن التحميل إلى الشبكة الظاهرية الخاصة بمجموعة AKS. تحتوي الشبكة الظاهرية على مجموعة أمان شبكة (NSG) تسمح لجميع نسبة استخدام الشبكة الواردة من موازن التحميل. يستخدم NSG هذا علامة خدمة من نوع LoadBalancer للسماح بنسبة استخدام الشبكة من موازن التحميل.
  • يجب إضافة Pod CIDR إلى loadBalancerSourceRanges إذا كانت هناك Pods تحتاج إلى الوصول إلى عنوان IP LoadBalancer للخدمة للمجموعات ذات الإصدار v1.25 أو أعلى.

الاحتفاظ بعنوان IP للعميل على الاتصالات الواردة

بشكل افتراضي، لا تستمر خدمة من نوع LoadBalancer في Kubernetes وفي AKS في عنوان IP الخاص بالعميل على الاتصال بالجراب. يصبح IP المصدر على الحزمة التي يتم تسليمها إلى الحاوية عنوان IP الخاص للعقدة. للاحتفاظ بعنوان IP العميل، يجب أن تعين service.spec.externalTrafficPolicy إلى local في تعريف الخدمة. يظهر البيان التالي مثالا.

apiVersion: v1
kind: Service
metadata:
  name: azure-vote-front
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local
  ports:
  - port: 80
  selector:
    app: azure-vote-front

التخصيصات عبر التعليقات التوضيحية ل Kubernetes

يتم دعم التعليقات التوضيحية التالية لخدمات Kubernetes ذات النوع LoadBalancer، وتنطبق فقط على التدفقات الواردة .

تعليق توضيحي قيمة ‏‏الوصف
service.beta.kubernetes.io/azure-load-balancer-internal true أو false تحديد ما إذا كان يجب أن يكون موازن التحميل داخليًا أم لا. إذا لم يتم تعيينه، تعيينه افتراضيا إلى عام.
service.beta.kubernetes.io/azure-load-balancer-internal-subnet اسم الشبكة الفرعية حدد الشبكة الفرعية التي يجب ربط موازن التحميل الداخلي بها. إذا لم يتم تعيينه، تعيينه افتراضيا إلى الشبكة الفرعية المكونة في ملف تكوين السحابة.
service.beta.kubernetes.io/azure-dns-label-name اسم تسمية DNS على عناوين IP العامة تحديد اسم تسمية DNS للخدمة العامة. إذا تم تعيينه إلى سلسلة فارغة، فلن يتم استخدام إدخال DNS في IP العام.
service.beta.kubernetes.io/azure-shared-securityrule true أو false حدد تعريض الخدمة من خلال قاعدة أمان Azure مشتركة محتملة لزيادة التعرض للخدمة، باستخدام قواعد الأمان المعززة ل Azure في مجموعات أمان الشبكة.
service.beta.kubernetes.io/azure-load-balancer-resource-group اسم مجموعة الموارد تحديد مجموعة الموارد من موازن التحميل عناوين IP العامة التي ليست في نفس مجموعة الموارد مثل البنية التحتية لنظام المجموعة (مجموعة موارد العقدة).
service.beta.kubernetes.io/azure-allowed-service-tags قائمة بعلامات الخدمة المسموح بها حدد قائمة بعلامات الخدمة المسموح بها مفصولة بفواصل.
service.beta.kubernetes.io/azure-load-balancer-tcp-idle-timeout مهلة خمول TCP بالدقائق حدد الوقت بالدقائق حتى تحدث مهلات الخمول لاتصال TCP على موازن التحميل. القيمة الافتراضية والحد الأدنى هو 4. القيمة القصوى هي 30. يجب أن تكون القيمة عددا صحيحا.
service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset true أو false حدد ما إذا كان يجب على موازن التحميل تعطيل إعادة تعيين TCP عند انتهاء مهلة الخمول.
service.beta.kubernetes.io/azure-load-balancer-ipv4 عنوان IPv4 حدد عنوان IPv4 لتعيينه إلى موازن التحميل.
service.beta.kubernetes.io/azure-load-balancer-ipv6 عنوان IPv6 حدد عنوان IPv6 لتعيينه إلى موازن التحميل.

تخصيص فحص صحة موازن التحميل

تعليق توضيحي قيمة ‏‏الوصف
service.beta.kubernetes.io/azure-load-balancer-health-probe-interval الفاصل الزمني لفحص السلامة
service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe الحد الأدنى لعدد الاستجابات غير الصحية لفحص الصحة
service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path مسار طلب فحص السلامة
service.beta.kubernetes.io/port_{port}_no_lb_rule خطأ صحيح {port} هو رقم منفذ الخدمة. عند التعيين إلى true، لا يتم إنشاء قاعدة lb أو قاعدة فحص السلامة لهذا المنفذ. يجب ألا تتعرض خدمة فحص الصحة للإنترنت العام (على سبيل المثال، خدمة الفحص الصحي istio/envoy)
service.beta.kubernetes.io/port_{port}_no_probe_rule خطأ صحيح {port} هو رقم منفذ الخدمة. عند التعيين إلى true، لا يتم إنشاء قاعدة فحص السلامة لهذا المنفذ.
service.beta.kubernetes.io/port_{port}_health-probe_protocol بروتوكول فحص السلامة {port} هو رقم منفذ الخدمة. بروتوكول صريح للتحقيق الصحي لمنفذ الخدمة {port}، مع تجاوز port.appProtocol إذا تم تعيينه.
service.beta.kubernetes.io/port_{port}_health-probe_port رقم المنفذ أو اسم المنفذ في بيان الخدمة {port} هو رقم منفذ الخدمة. منفذ صريح لفحص السلامة لمنفذ الخدمة {port}، متجاوزا القيمة الافتراضية.
service.beta.kubernetes.io/port_{port}_health-probe_interval الفاصل الزمني لفحص السلامة {port} هو رقم منفذ الخدمة.
service.beta.kubernetes.io/port_{port}_health-probe_num-of-probe الحد الأدنى لعدد الاستجابات غير الصحية لفحص الصحة {port} هو رقم منفذ الخدمة.
service.beta.kubernetes.io/port_{port}_health-probe_request-path مسار طلب فحص السلامة {port} هو رقم منفذ الخدمة.

كما هو موثق هنا، Tcp وHttp وHttps هي ثلاثة بروتوكولات مدعومة من قبل خدمة موازن التحميل.

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

  1. بالنسبة للخدمات المحلية، سيتم استخدام HTTP و/healthz. سيقوم فحص السلامة بالاستعلام عن NodeHealthPort بدلا من خدمة الخلفية الفعلية
  2. لخدمات TCP للمجموعة، سيتم استخدام TCP.
  3. لخدمات نظام المجموعة UDP، لا توجد تحقيقات صحية.

إشعار

بالنسبة للخدمات المحلية مع تمكين تكامل PLS وبروتوكول وكيل PLS، لا يعمل فحص صحة HTTP+/healthz الافتراضي. وبالتالي يمكن تخصيص فحص السلامة بنفس الطريقة التي يتم بها تخصيص خدمات نظام المجموعة لدعم هذا السيناريو.

منذ الإصدار 1.20، يتم تقديم تعليق توضيحي service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path للخدمة لتحديد سلوك التحقيق الصحي.

  • بالنسبة للمجموعات <=1.23، spec.ports.appProtocol سيتم استخدام فقط كبروتوكول فحص عند service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path تعيين أيضا.
  • بالنسبة للمجموعات >1.24، spec.ports.appProtocol سيتم استخدامها كبروتوكول / فحص وسيتم استخدامها كمسار طلب فحص افتراضي (service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path يمكن استخدامه للتغيير إلى مسار طلب مختلف).

لاحظ أنه سيتم تجاهل مسار الطلب عند استخدام TCP أو يكون فارغا spec.ports.appProtocol . أكثر تحديدًا:

وحدة sku لموازن التحميل externalTrafficPolicy spec.ports.Protocol spec.ports.AppProtocol service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path بروتوكول فحص LB مسار طلب فحص LB
قياسي محلي أي أي أي http /healthz
قياسي نظام مجموعة udp أي أي قيمة فارغة قيمة فارغة
قياسي نظام مجموعة tcp (تم تجاهله) tcp قيمة فارغة
قياسي نظام مجموعة tcp tcp (تم تجاهله) tcp قيمة فارغة
قياسي نظام مجموعة tcp http/https TCP(<=1.23) أو http/https(>=1.24) null(<=1.23) أو /(>=1.24)
قياسي نظام مجموعة tcp http/https /custom-path http/https /custom-path
قياسي نظام مجموعة tcp بروتوكول غير معتمد /custom-path tcp قيمة فارغة
أساسي محلي أي أي أي http /healthz
أساسي نظام مجموعة tcp (تم تجاهله) tcp قيمة فارغة
أساسي نظام مجموعة tcp tcp (تم تجاهله) tcp قيمة فارغة
أساسي نظام مجموعة tcp http TCP(<=1.23) أو http/https(>=1.24) null(<=1.23) أو /(>=1.24)
أساسي نظام مجموعة tcp http /custom-path http /custom-path
أساسي نظام مجموعة tcp بروتوكول غير معتمد /custom-path tcp قيمة فارغة

منذ الإصدار 1.21، يتم تقديم تعليقين توضيحيين للخدمة service.beta.kubernetes.io/azure-load-balancer-health-probe-interval و load-balancer-health-probe-num-of-probe ، والتي تخصص تكوين فحص السلامة. إذا service.beta.kubernetes.io/azure-load-balancer-health-probe-interval لم يتم تعيين، يتم تطبيق القيمة الافتراضية 5. إذا load-balancer-health-probe-num-of-probe لم يتم تعيين، يتم تطبيق القيمة الافتراضية 2. ويجب أن يكون إجمالي الفحص أقل من 120 ثانية.

فحص صحة موازن التحميل المخصص للمنفذ

يمكن أن تتطلب المنافذ المختلفة في الخدمة تكوينات فحص صحة مختلفة. قد يكون هذا بسبب تصميم الخدمة (مثل نقطة نهاية صحية واحدة تتحكم في منافذ متعددة)، أو ميزات Kubernetes مثل MixedProtocolLBService.

يمكن استخدام التعليقات التوضيحية التالية لتخصيص تكوين الفحص لكل منفذ خدمة.

تعليق توضيحي خاص بالمنفذ التعليق التوضيحي للمسبار العمومي الاستخدام
service.beta.kubernetes.io/port_{port}_no_lb_rule غير متاح (لا يوجد ما يعادله عالميا) إذا تم تعيين true، فلن يتم إنشاء قواعد lb وقواعد الفحص
service.beta.kubernetes.io/port_{port}_no_probe_rule غير متاح (لا يوجد ما يعادله عالميا) إذا تم تعيين true، فلن يتم إنشاء أي قواعد فحص
service.beta.kubernetes.io/port_{port}_health-probe_protocol غير متاح (لا يوجد ما يعادله عالميا) تعيين بروتوكول فحص السلامة لمنفذ الخدمة هذا (على سبيل المثال Http وHttps وTcp)
service.beta.kubernetes.io/port_{port}_health-probe_port غير متاح (لا يوجد ما يعادله عالميا) تعيين منفذ فحص السلامة لمنفذ الخدمة هذا (على سبيل المثال 15021)
service.beta.kubernetes.io/port_{port}مسار _health-probe_request service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path بالنسبة إلى Http أو Https، قم بتعيين مسار طلب فحص السلامة. الإعدادات الافتراضية إلى /
service.beta.kubernetes.io/port_{port}_health-probe_num-of-probe service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe عدد حالات فشل الفحص المتتالية قبل اعتبار المنفذ غير سليم
service.beta.kubernetes.io/port_{port}_health-probe_interval service.beta.kubernetes.io/azure-load-balancer-health-probe-interval مقدار الوقت بين محاولات الفحص

بالنسبة إلى البيان التالي، تختلف قاعدة الفحص لمنفذ httpsserver عن قاعدة httpserver بسبب تحديد التعليقات التوضيحية لمنفذ httpsserver.

apiVersion: v1
kind: Service
metadata:
  name: appservice
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-health-probe-num-of-probe: "5"
    service.beta.kubernetes.io/port_443_health-probe_num-of-probe: "4"
spec:
  type: LoadBalancer
  selector:
    app: server
  ports:
    - name: httpserver
      protocol: TCP
      port: 80
      targetPort: 30102
    - name: httpsserver
      protocol: TCP
      appProtocol: HTTPS
      port: 443
      targetPort: 30104

في هذا البيان، تستخدم منافذ https منفذ عقدة مختلف، فحص جاهزية HTTP في المنفذ 10256 على /healthz(نقطة نهاية healthz ل kube-proxy).

apiVersion: v1
kind: Service
metadata:
  name: istio
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
    service.beta.kubernetes.io/port_443_health-probe_protocol: "http"
    service.beta.kubernetes.io/port_443_health-probe_port: "10256"
    service.beta.kubernetes.io/port_443_health-probe_request-path: "/healthz"
spec:
  ports:
    - name: https
      protocol: TCP
      port: 443
      targetPort: 8443
      nodePort: 30104
      appProtocol: https
  selector:
    app: istio-ingressgateway
    gateway: istio-ingressgateway
    istio: ingressgateway
  type: LoadBalancer
  sessionAffinity: None
  externalTrafficPolicy: Local
  ipFamilies:
    - IPv4
  ipFamilyPolicy: SingleStack
  allocateLoadBalancerNodePorts: true
  internalTrafficPolicy: Cluster

في هذا البيان، تستخدم منافذ https نقطة نهاية فحص صحة مختلفة، فحص جاهزية HTTP في المنفذ 30000 على /healthz/ready.

apiVersion: v1
kind: Service
metadata:
  name: istio
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
    service.beta.kubernetes.io/port_443_health-probe_protocol: "http"
    service.beta.kubernetes.io/port_443_health-probe_port: "30000"
    service.beta.kubernetes.io/port_443_health-probe_request-path: "/healthz/ready"
spec:
  ports:
    - name: https
      protocol: TCP
      port: 443
      targetPort: 8443
      appProtocol: https
  selector:
    app: istio-ingressgateway
    gateway: istio-ingressgateway
    istio: ingressgateway
  type: LoadBalancer
  sessionAffinity: None
  externalTrafficPolicy: Local
  ipFamilies:
    - IPv4
  ipFamilyPolicy: SingleStack
  allocateLoadBalancerNodePorts: true
  internalTrafficPolicy: Cluster

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

إذا كنت تعرف أنك تبدأ العديد من اتصالات TCP أو UDP الصادرة إلى نفس عنوان IP الوجهة والمنفذ، وكنت تلاحظ فشل الاتصالات الصادرة أو الدعم يعلمك بأنك تستنفد منافذ SNAT (المنافذ المؤقتة المخصصة مسبقا التي يستخدمها PAT)، فلديك العديد من خيارات التخفيف العامة. راجع هذه الخيارات وقرر ما هو الأفضل للسيناريو الخاص بك. من الممكن أن يساعد واحد أو أكثر في إدارة السيناريو الخاص بك. للحصول على معلومات مفصلة، راجع دليل استكشاف أخطاء الاتصالات الصادرة وإصلاحها.

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

‏‏الخطوات

  1. تحقق مما إذا كانت الاتصالات الخاصة بك تبقى خاملة لفترة طويلة وتعتمد على المهلة الافتراضية للتعطل عن تحرير هذا المنفذ. إذا كان الأمر كذلك، فقد تحتاج المهلة الافتراضية البالغة 30 دقيقة إلى تقليلها للسيناريو الخاص بك.
  2. تحقق من كيفية إنشاء تطبيقك للاتصال الصادر (على سبيل المثال، مراجعة التعليمات البرمجية أو التقاط الحزمة).
  3. تحديد ما إذا كان هذا النشاط هو السلوك المتوقع أو ما إذا كان التطبيق يتصرف بشكل خطأ. استخدم المقاييس والسجلات في Azure Monitor لإثبات النتائج التي توصلت إليها. على سبيل المثال، استخدم الفئة "Failed" لمقياس اتصالات SNAT.
  4. تقييم ما إذا كان يتم اتباع الأنماط المناسبة.
  5. تقييم ما إذا كان يجب تخفيف استنفاد منفذ SNAT مع المزيد من عناوين IP الصادرة + المزيد من المنافذ الصادرة المخصصة.

أنماط التصميم

استفد من إعادة استخدام الاتصال وتجميع الاتصال كلما أمكن ذلك. تساعدك هذه الأنماط على تجنب مشاكل استنفاد الموارد وتؤدي إلى سلوك يمكن التنبؤ به. يمكن العثور على البدائيات لهذه الأنماط في العديد من مكتبات التطوير وأطر العمل.

  • الطلبات الذرية (طلب واحد لكل اتصال) بشكل عام ليست خيارا جيدا للتصميم. تعمل هذه الأنماط المضادة على الحد من التحجيم وتقليل الأداء وتقليل الموثوقية. بدلًا من ذلك، إعادة استخدام اتصالات HTTP/S لتقليل عدد الاتصالات ومنافذ SNAT المقترنة. يزيد مقياس التطبيق ويتحسن الأداء بسبب انخفاض المصافحات والنفقات العامة وتكلفة عملية التشفير عند استخدام TLS.
  • إذا كنت تستخدم خارج نظام المجموعة/DNS المخصص، أو خوادم المصدر المخصصة على coreDNS، فضع في اعتبارك أن DNS يمكن أن يقدم العديد من التدفقات الفردية في وحدة التخزين عندما لا يقوم العميل بالتخزين المؤقت لنتيجة محللات DNS. تأكد من تخصيص coreDNS أولا بدلا من استخدام خوادم DNS المخصصة وتحديد قيمة تخزين مؤقت جيدة.
  • تخصص تدفقات UDP (على سبيل المثال، عمليات بحث DNS) منافذ SNAT أثناء مهلة الخمول. كلما طالت مهلة الخمول، كلما ارتفع الضغط على منافذ SNAT. استخدم مهلة الخمول القصيرة (على سبيل المثال، 4 دقائق).
  • استخدم تجمعات اتصالات لتشكيل حجم الاتصال.
  • لا تتخلى عن تدفق TCP بشكل صامت وتعتمد على مؤقت TCP لتنظيف التدفق. إذا لم تسمح ل TCP بإغلاق الاتصال بشكل صريح، تظل الحالة مخصصة في الأنظمة الوسيطة ونقاط النهاية، وتجعل منافذ SNAT غير متوفرة للاتصالات الأخرى. يمكن أن يؤدي هذا النمط فشل التطبيق واستنفاد SNAT.
  • لا تقم بتغيير قيم مؤقت ذات صلة قريبة TCP على مستوى نظام التشغيل دون معرفة كبيرة بالتأثير. أثناء استرداد مكدس TCP، يمكن أن يتأثر أداء التطبيق سلبا عندما تكون نقاط نهاية الاتصال غير متطابقة مع التوقعات. الرغبة في تغيير أجهزة المؤقت عادة ما تكون علامة على وجود مشكلة أساسية بالتصميم. استعرض التوصيات التالية.

الانتقال من موازن تحميل SKU الأساسي إلى SKU القياسي

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

على سبيل المثال، يعد إجراء عمليات نشر زرقاء/خضراء لترحيل المجموعات ممارسة شائعة نظرا load-balancer-sku لنوع نظام المجموعة ولا يمكن تعريفه إلا في وقت إنشاء نظام المجموعة. ومع ذلك، تستخدم موازنات تحميل SKU الأساسية عناوين IP الأساسية SKU، والتي لا تتوافق مع موازنات تحميل SKU القياسية. تتطلب موازنات تحميل SKU القياسية عناوين IP SKU القياسية. عند ترحيل أنظمة المجموعات لترقية وحدات SKU لموازن التحميل، يلزم وجود عنوان IP جديد مع عنوان IP متوافق SKU.

لمزيد من الاعتبارات حول كيفية ترحيل المجموعات، تفضل بزيارة وثائقنا حول اعتبارات الترحيل.

القيود

تنطبق القيود التالية عند إنشاء وإدارة أنظمة مجموعة AKS التي تدعم تجمعات موازن تحميل بSKU قياسي:

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

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

لمعرفة المزيد حول خدمات Kubernetes، راجع وثائق خدمات Kubernetes.

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