تأمين نسبة استخدام الشبكة بين القرون باستخدام نهج الشبكة في AKS

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

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

نظرة عامة على نهج الشبكة

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

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

يتم تعريف قواعد نهج الشبكة على أنها بيانات YAML. يمكن تضمين نهج الشبكة كجزء من بيان أوسع ينشئ أيضًا عملية نشر أو خدمة.

خيارات نهج الشبكة في AKS

يوفر Azure ثلاثة محركات لنهج الشبكة لفرض نهج الشبكة:

Cilium هو محرك نهج الشبكة الموصى به. يفرض Cilium نهج الشبكة على نسبة استخدام الشبكة باستخدام Linux Berkeley Packet Filter (BPF)، وهو بشكل عام أكثر كفاءة من "IPTables". راجع المزيد من التفاصيل في وثائق Azure CNI التي يتم تشغيلها بواسطة Cilium.
لفرض النهج المحددة، يستخدم Azure Network Policy Manager لنظام التشغيل Linux IPTables. يستخدم Azure Network Policy Manager لنظام التشغيل Windows نهج ACLPolicies لخدمة شبكة المضيف (HNS). يتم ترجمة النُهج إلى مجموعات من أزواج IP المسموح بها وغير المسموح بها. ثم تتم برمجة هذه الأزواج كقواد IPTable أو HNS ACLPolicy تصفية.

الاختلافات بين محركات نهج الشبكة: Cilium وAzure NPM وCalico

الإمكانية Azure Network Policy Manager Calico هدب
الأنظمة الأساسية المدعومة Linux، Windows Server 2022 (معاينة). Linux وWindows Server 2019 و2022. Linux.
خيارات شبكة الاتصال المعتمدة واجهة شبكة حاويات Azure (CNI). Azure CNI (Linux وWindows Server 2019 و2022) وkubenet (Linux). Azure CNI.
الامتثال لمواصفات Kubernetes جميع أنواع النُهج المعتمدة جميع أنواع النهج مدعومة. جميع أنواع النهج مدعومة.
ميزات أخرى لا يوجد. نموذج نهج موسع يتكون من نهج الشبكة العمومية، ومجموعة الشبكة العمومية، ونقطة النهاية المضيفة. لمزيد من المعلومات حول استخدام calicoctl CLI لإدارة هذه الميزات الموسعة، راجع مرجع مستخدم calicoctl. لا يوجد.
يدعم مدعوم من قبل فريق دعم وهندسة Azure. مدعوم من قبل فريق دعم وهندسة Azure. مدعوم من قبل فريق دعم وهندسة Azure.

قيود Azure Network Policy Manager

إشعار

مع Azure NPM لنظام Linux، لا نسمح بالتحجيم لأكثر من 250 عقدة و20000 حاوية. إذا حاولت توسيع نطاق هذه الحدود، فقد تواجه أخطاء نفاد الذاكرة (OOM ). لتحسين قابلية التوسع ودعم IPv6، وإذا كانت القيود التالية تثير القلق، نوصي باستخدام أو الترقية إلى Azure CNI المشغل بواسطة Cilium لاستخدام Cilium كمحرك نهج الشبكة.

لا يدعم Azure NPM IPv6. وإلا، فإنه يدعم بالكامل مواصفات نهج الشبكة في Linux.

في Windows، لا يدعم Azure NPM الميزات التالية لمواصفات نهج الشبكة:

  • المنافذ المسماة.
  • بروتوكول نقل التحكم بالبث (SCTP).
  • محددات تسمية المطابقة السالبة أو مساحة الاسم. على سبيل المثال، جميع التسميات باستثناء debug=true.
  • except كتل التوجيه بين المجالات (CIDR) بدون فئة (CIDR مع استثناءات).

إشعار

تسجل سجلات جراب Azure Network Policy Manager خطأ إذا تم إنشاء نهج شبكة غير مدعوم.

تحرير/حذف نهج الشبكة

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

إذا حدث شرط السباق هذا لعقدة، تدخل جراب Azure NPM على تلك العقدة حالة حيث لا يمكنها تحديث قواعد الأمان، ما قد يؤدي إلى اتصال غير متوقع للاتصالات الجديدة من/إلى pods على العقدة المتأثرة. للتخفيف من المشكلة، يقوم Azure NPM pod تلقائيا بإعادة تشغيل ~15 ثانية بعد إدخال هذه الحالة. أثناء إعادة تشغيل Azure NPM على العقدة المتأثرة، فإنه يحذف جميع قواعد الأمان، ثم يعيد تطبيق قواعد الأمان لجميع نهج الشبكة. بينما تتم إعادة تطبيق جميع قواعد الأمان، هناك فرصة للاتصال المؤقت وغير المتوقع للاتصالات الجديدة من/إلى pods على العقدة المتأثرة.

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

قبل البدء

تحتاج إلى الإصدار 2.0.61 من Azure CLI أو تثبيتها وتكوينها لاحقًا. قم بتشغيل az --version للعثور على الإصدار. إذا كنت بحاجة إلى التثبيت أو الترقية، فراجع تثبيت Azure CLI.

إنشاء مجموعة AKS وتمكين نهج الشبكة

لمشاهدة نهج الشبكة قيد التنفيذ، يمكنك إنشاء نظام مجموعة AKS يدعم نهج الشبكة ثم العمل على إضافة النهج.

لاستخدام Azure Network Policy Manager، يجب استخدام المكون الإضافي Azure CNI. يمكن استخدام Calico إما مع المكون الإضافي Azure CNI أو مع المكون الإضافي Kubenet CNI.

يقوم البرنامج النصي المثال التالي بإنشاء نظام مجموعة AKS مع هوية معينة من قبل النظام وتمكين نهج الشبكة باستخدام Azure Network Policy Manager.

إشعار

يمكن استخدام Calico مع --network-plugin azure المعلمات أو --network-plugin kubenet .

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

إنشاء نظام مجموعة AKS مع تمكين Azure Network Policy Manager - Linux فقط

في هذا القسم، يمكنك إنشاء نظام مجموعة مع تجمعات عقد Linux وتمكين Azure Network Policy Manager.

للبدء، يمكنك استبدال قيم $RESOURCE_GROUP_NAME المتغيرين و $CLUSTER_NAME .

$RESOURCE_GROUP_NAME=myResourceGroup-NP
$CLUSTER_NAME=myAKSCluster
$LOCATION=canadaeast

قم بإنشاء نظام مجموعة AKS وحدد azure ل network-plugin و network-policy.

لإنشاء نظام مجموعة، استخدم الأمر التالي:

az aks create \
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --node-count 1 \
    --network-plugin azure \
    --network-policy azure \
    --generate-ssh-keys

إنشاء نظام مجموعة AKS مع تمكين Azure Network Policy Manager - Windows Server 2022 (معاينة)

في هذا القسم، يمكنك إنشاء نظام مجموعة مع تجمعات عقد Windows وتمكين Azure Network Policy Manager.

إشعار

يتوفر Azure Network Policy Manager مع عقد Windows على Windows Server 2022 فقط.

تثبيت ملحق aks-preview Azure CLI

هام

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

لتثبيت الملحق aks-preview ، قم بتشغيل الأمر التالي:

az extension add --name aks-preview

للتحديث إلى أحدث إصدار من الملحق الذي تم إصداره، قم بتشغيل الأمر التالي:

az extension update --name aks-preview

تسجيل علامة ميزة WindowsNetworkPolicyPreview

قم بتسجيلWindowsNetworkPolicyPreviewميزة الإشارة باستخدامتسجيل ميزة az كما هو موضح في المثال التالي:

az feature register --namespace "Microsoft.ContainerService" --name "WindowsNetworkPolicyPreview"

يستغرق الأمر بضع دقائق حتى تظهر الحالة مُسجل. تحقق من حالة التسجيل باستخدام الأمر az feature show :

az feature show --namespace "Microsoft.ContainerService" --name "WindowsNetworkPolicyPreview"

عندما تعكس الحالة Registered، قم بتحديث تسجيل Microsoft.ContainerService موفر الموارد باستخدام الأمر az provider register :

az provider register --namespace Microsoft.ContainerService

قم بإنشاء مجموعة AKS

الآن، يمكنك استبدال قيم $RESOURCE_GROUP_NAME$CLUSTER_NAMEالمتغيرات و و$WINDOWS_USERNAME.

$RESOURCE_GROUP_NAME=myResourceGroup-NP
$CLUSTER_NAME=myAKSCluster
$WINDOWS_USERNAME=myWindowsUserName
$LOCATION=canadaeast

إنشاء اسم مستخدم لاستخدامه كبيانات اعتماد مسؤول لحاويات Windows Server على نظام المجموعة الخاص بك. يطالبك الأمر التالي باسم مستخدم. قم بتعيينه إلى $WINDOWS_USERNAME. تذكر أن الأوامر الواردة في هذه المقالة يتم إدخالها في Bash shell.

echo "Please enter the username to use as administrator credentials for Windows Server containers on your cluster: " && read WINDOWS_USERNAME

لإنشاء نظام مجموعة، استخدم الأمر التالي:

az aks create \
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --node-count 1 \
    --windows-admin-username $WINDOWS_USERNAME \
    --network-plugin azure \
    --network-policy azure \
    --generate-ssh-keys

يستغرق بضع دقائق لإنشاء المجموعة. بشكل افتراضي، يتم إنشاء نظام المجموعة الخاص بك باستخدام تجمع عقد Linux فقط. إذا كنت ترغب في استخدام تجمعات عقد Windows، يمكنك إضافة واحدة. إليك مثال:

az aks nodepool add \
    --resource-group $RESOURCE_GROUP_NAME \
    --cluster-name $CLUSTER_NAME \
    --os-type Windows \
    --name npwin \
    --node-count 1

إنشاء نظام مجموعة AKS مع تمكين Calico

قم بإنشاء نظام مجموعة AKS وحدد --network-plugin azureو و --network-policy calico. يتيح تحديد --network-policy calico Calico على كل من تجمعات عقد Linux وWindows.

إذا كنت تخطط لإضافة تجمعات عقد Windows إلى مجموعتك، فقم بتضمين windows-admin-username المعلمات و windows-admin-password التي تفي بمتطلبات كلمة مرور Windows Server.

هام

في هذا الوقت، يتوفر استخدام نهج شبكة Calico مع عقد Windows على مجموعات جديدة باستخدام Kubernetes الإصدار 1.20 أو أحدث مع Calico 3.17.2 ويتطلب استخدام شبكة Azure CNI. تحتوي عقد Windows على مجموعات AKS مع تمكين Calico أيضا على IP عائم ممكن بشكل افتراضي.

بالنسبة للمجموعات ذات تجمعات عقد Linux فقط التي تعمل بنظام Kubernetes 1.20 مع الإصدارات السابقة من Calico، يقوم إصدار Calico بالترقية تلقائيا إلى 3.17.2.

إنشاء اسم مستخدم لاستخدامه كبيانات اعتماد مسؤول لحاويات Windows Server على نظام المجموعة الخاص بك. يطالبك الأمر التالي باسم مستخدم. قم بتعيينه إلى $WINDOWS_USERNAME. تذكر أن الأوامر الواردة في هذه المقالة يتم إدخالها في Bash shell.

echo "Please enter the username to use as administrator credentials for Windows Server containers on your cluster: " && read WINDOWS_USERNAME
az aks create \
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --node-count 1 \
    --windows-admin-username $WINDOWS_USERNAME \
    --network-plugin azure \
    --network-policy calico \
    --generate-ssh-keys

يستغرق بضع دقائق لإنشاء المجموعة. بشكل افتراضي، يتم إنشاء نظام المجموعة الخاص بك باستخدام تجمع عقد Linux فقط. إذا كنت ترغب في استخدام تجمعات عقد Windows، يمكنك إضافة واحدة. على سبيل المثال:

az aks nodepool add \
    --resource-group $RESOURCE_GROUP_NAME \
    --cluster-name $CLUSTER_NAME \
    --os-type Windows \
    --name npwin \
    --node-count 1

تثبيت Azure Network Policy Manager أو Calico في مجموعة موجودة

يتم أيضا دعم تثبيت Azure Network Policy Manager أو Calico على مجموعات AKS الموجودة.

تحذير

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

مثال على الأمر لتثبيت Azure Network Policy Manager:

az aks update
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --network-policy azure

مثال على الأمر لتثبيت Calico:

تحذير

ينطبق هذا التحذير على ترقية مجموعات Kubenet مع تمكين Calico إلى تراكب Azure CNI مع تمكين Calico.

  • في مجموعات Kubenet مع تمكين Calico، يتم استخدام Calico كمحرك نهج شبكة وCNI.
  • في مجموعات Azure CNI، يتم استخدام Calico فقط لفرض نهج الشبكة، وليس ك CNI. يمكن أن يسبب هذا تأخيرا قصيرا بين وقت بدء تشغيل الجراب ومتى يسمح Calico بنسبة استخدام الشبكة الصادرة من الجراب.

يوصى باستخدام Cilium بدلا من Calico لتجنب هذه المشكلة. تعرف على المزيد حول Cilium في Azure CNI المشغل بواسطة Cilium

az aks update
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --network-policy calico

ترقية نظام مجموعة موجود يحتوي على Azure NPM أو Calico مثبت على Azure CNI المشغل بواسطة Cilium

لترقية نظام مجموعة موجود مثبت عليه محرك نهج الشبكة إلى Azure CNI المشغل بواسطة Cilium، راجع ترقية نظام مجموعة موجود إلى Azure CNI المشغل بواسطة Cilium

التحقق من إعداد نهج الشبكة

عندما تكون المجموعة جاهزة، يجب تكوين kubectl للاتصال بنظام مجموعتك من Kubernetes باستخدام أمر az aks get-credentials. هذا الأمر يقوم بتحميل بيانات الاعتماد وضبط Kubernetes CLI لاستخدامها:

az aks get-credentials --resource-group $RESOURCE_GROUP_NAME --name $CLUSTER_NAME

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

أولا، قم بإنشاء مساحة اسم تسمى demo لتشغيل أمثلة pods:

kubectl create namespace demo

الآن قم بإنشاء جرابين في نظام المجموعة المسمى client و server.

إشعار

إذا كنت تريد جدولة العميل أو الخادم على عقدة معينة، أضف البت التالي قبل الوسيطة --command في الأمر kubectl run لإنشاء pod:

--overrides='{"spec": { "nodeSelector": {"kubernetes.io/os": "linux|windows"}}}'

إنشاء جراب server . يعمل هذا الجراب على منفذ TCP 80:

kubectl run server -n demo --image=k8s.gcr.io/e2e-test-images/agnhost:2.33 --labels="app=server" --port=80 --command -- /agnhost serve-hostname --tcp --http=false --port "80"

إنشاء جراب client . يقوم الأمر التالي بتشغيل Bash على client pod:

kubectl run -it client -n demo --image=k8s.gcr.io/e2e-test-images/agnhost:2.33 --command -- bash

الآن، في نافذة منفصلة، بادر بتشغيل الأمر التالي للحصول على عنوان IP للخادم:

kubectl get pod --output=wide -n demo

يجب أن يبدو الإخراج كما يلي:

NAME     READY   STATUS    RESTARTS   AGE   IP            NODE             NOMINATED NODE   READINESS GATES
server   1/1     Running   0          30s   10.224.0.72   akswin22000001   <none>           <none>

اختبار الاتصال دون نهج الشبكة

في shell الخاص بالعميل، قم بتشغيل الأمر التالي للتحقق من الاتصال بالخادم. استبدل server-ip باستخدام IP الموجود في الإخراج من تشغيل الأمر السابق. إذا كان الاتصال ناجحا، فلا يوجد إخراج.

/agnhost connect <server-ip>:80 --timeout=3s --protocol=tcp

اختبار الاتصال مع نهج الشبكة

لإضافة نهج الشبكة، أنشئ ملفا باسم demo-policy.yaml والصق بيان YAML التالي:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: demo-policy
  namespace: demo
spec:
  podSelector:
    matchLabels:
      app: server
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: client
    ports:
    - port: 80
      protocol: TCP

حدد اسم بيان YAML الخاص بك وطبقه باستخدام kubectl apply:

kubectl apply –f demo-policy.yaml

الآن، في shell الخاص بالعميل، تحقق من الاتصال بالخادم عن طريق تشغيل الأمر التالي /agnhost :

/agnhost connect <server-ip>:80 --timeout=3s --protocol=tcp

يتم حظر الاتصال بحركة المرور لأن الخادم مسمى ب app=server، ولكن العميل غير مسمى. ينتج عن أمر الاتصال السابق هذا الإخراج:

TIMEOUT

قم بتشغيل الأمر التالي لتسمية client وتحقق من الاتصال بالخادم. يجب ألا يرجع الإخراج شيئا.

kubectl label pod client -n demo app=client

إلغاء تثبيت Azure Network Policy Manager أو Calico

المتطلبات:

  • الإصدار 2.63 من Azure CLI أو أحدث

إشعار

  • لا تزيل عملية إلغاء التثبيت تعريفات الموارد المخصصة (CRDs) والموارد المخصصة (CRs) المستخدمة من قبل Calico. تحتوي كل من CRDs وCS على أسماء تنتهي إما ب "projectcalico.org" أو "tigera.io". يمكن حذف CRDs هذه و CRs المقترنة يدويا بعد إلغاء تثبيت Calico بنجاح (حذف CRDs قبل إزالة Calico يكسر نظام المجموعة).
  • لن تزيل الترقية أي موارد NetworkPolicy في نظام المجموعة، ولكن بعد إلغاء تثبيت هذه النهج لم تعد مفروضة.

تحذير

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

لإزالة Azure Network Policy Manager أو Calico من نظام مجموعة، قم بتشغيل الأمر التالي:

az aks update
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --network-policy none

تنظيف الموارد

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

kubectl delete namespace demo

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

لمزيد من المعلومات حول موارد الشبكة، راجع مفاهيم الشبكة للتطبيقات في خدمة Azure Kubernetes (AKS).

لمعرفة المزيد حول النُهج، راجع نُهج شبكة Kubernetes.