أفضل الممارسات لاتصال الشبكة والأمان في Azure Kubernetes

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

تركز هذه المقالة على أفضل الممارسات لاتصال الشبكة والأمان لعوامل تشغيل نظام مجموعة. في هذه المقالة، ستتعرف على كيفية:

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

اختر نموذج الشبكة المناسب.

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

استخدم شبكات Azure CNI في AKS للتكامل مع الشبكات الافتراضية الموجودة أو الشبكات المحلية. يسمح نموذج الشبكة هذا بفصل الموارد وعناصر التحكم في بيئة المؤسسة بشكل أكبر.

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

• شبكة Azure CNI: ينشر في شبكة ظاهرية ويستخدم المكون الإضافي Azure CNI Kubernetes. تستلم كائنات Pod برامج عنوان بروتوكول الإنترنت الفردية التي يمكن أن توجهك إلى خدمات الشبكة الأخرى أو الموارد المحلية.
• شبكة Kubenet: يدير Azure موارد الشبكة الظاهرية أثناء نشر نظام المجموعة ويستخدم المكون الإضافي kubenet Kubernetes.

Azure CNI وkubenet كلاهما خياران صالحان لنشر الإنتاج.

شبكات CNI

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

وتجدر الإشارة إلى أن شبكات Azure CNI للإنتاج تسمح بفصل التحكم في الموارد وإدارتها. فمن ناحية الأمان، قد تحتاج غالبًا إلى فرق مختلفة لإدارة هذه الموارد وتأمينها. يمكنك باستخدام شبكة Azure CNI، الاتصال بموارد Azure الحالية أو الموارد المحلية أو الخدمات الأخرى مباشرةً عبر عناوين بروتوكول الإنترنت المخصص لكل كائن Pod

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

إذا رغبت في تعريفدور مخصص بدلاً من استخدام دور "مساهم الشبكة" المدمج، تكون الأذونات التالية مطلوبة:

• Microsoft.Network/virtualNetworks/subnets/join/action
• Microsoft.Network/virtualNetworks/subnets/read

يستخدم AKS بشكل افتراضي هوية مُدارة لتحديد هوية نظام مجموعة ومع ذلك، يمكنك استخدام كيان الخدمة بدلا من ذلك.

• لمزيد من المعلومات حول التفويض الأساسي لخدمة AKS، راجع تفويض الوصول إلى موارد Azure الأخرى.
• لمزيد من المعلومات حول الهويات المدارة، راجع استخدام الهويات المدارة.

نظرًا لاستلام كل عقدة وكائن Pod عنوان بروتوكول الإنترنت المخصص، تُخطط نطاقات العنوان لشبكات AKS الفرعية. ضع المعايير التالية في الاعتبار:

• يجب أن تكون الشبكة الفرعية كبيرة بما يكفي لتوفير عناوين IP لكل عقدة وجراب ومورد شبكة تقوم بنشره.
  • مع كل من شبكات kubenet وAzure CNI، يكون لكل عقدة قيد التشغيل حدود افتراضية لعدد pods.
• تجنب استخدام نطاقات عناوين بروتوكول الإنترنت التي تتداخل مع موارد الشبكة الموجودة.
  • من الضروري السماح بالاتصال بالشبكات المحلية أو الشبكات النظيرة في Azure.
• لمعالجة توسيع نطاق الأحداث أو ترقيات نظام المجموعة، تحتاج عناوين بروتوكول إنترنت إضافية متوفرة في الشبكة الفرعية المعينة.
  • تُعد مساحة العنوان الإضافية مهمة بشكل خاص إذا كنت تستخدم حاويات خادم ويندوز حيث تطلب تجمعات العقد الترقية لتشغيل أحدث تحديثات الأمان. للمزيد من المعلومات حول عملية ترقية عقدة خادم ويندوزراجع ترقية تجمع عقدة في AKS.

لحساب عنوان بروتوكول الإنترنت المطلوب، راجع تهيئة شبكات Azure CNI في AKS.

عند إنشاء نظام مجموعة باستخدام شبكة اتصال Azure CNI، تُحدد نطاقات عنوان آخر لنظام المجموعة، كعنوان جسر Docker وبروتوكول إنترنت خادم نظام أسماء النطاقات ونطاق عنوان الخدمة بشكل عام، تأكد من أن نطاقات العناوين هذه لا تتداخل مع بعضها البعض أو أي شبكات مرتبطة بالمجموعة، بما في ذلك أي شبكات ظاهرية وشبكات فرعية وشبكات محلية وشبكات نظيرة.

للحصول على تفاصيل محددة حول الحدود وتحجيم نطاقات العناوين هذه، راجع تهيئة شبكات Azure CNI في AKS.

شبكات Kubenet

على الرغم من أن kubenet لا يتطلب منك تكوين الشبكات الظاهرية قبل نشر نظام المجموعة، هناك عيوب في الانتظار، مثل:

• نظرًا لتركيز العقد وكائنات pod على شبكات عناوين بروتوكول إنترنت فرعية، والتوجيه المعرف من قِبل المستخدم ونسبة استخدام الشبكة في مسارات إعادة توجيه بروتوكول الإنترنت بين كائنات pod والعقد. قد يقلل هذا التوجيه الإضافي من أداء الشبكة.
• قد تتعقد الاتصالات بالشبكات المحلية الموجودة أو الشبكات النظيرة بشبكات Azure الافتراضي الأخرى.

نظرا لأنك لا تنشئ الشبكة الظاهرية والشبكات الفرعية بشكل منفصل عن مجموعة AKS، فإن Kubenet مثالي للسيناريوهات التالية:

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

بالنسبة إلى عمليات توزيع الإنتاج، يمثل كل من kubenet وAzure CNI خيارين صالحين. البيئات التي تتطلب فصل التحكم والإدارة، قد يكون Azure CNI الخيار المفضل. بالإضافة إلى ذلك، kubenet مناسب لبيئات Linux فقط حيث يكون الحفاظ على نطاق عناوين IP أولوية.

يمكنك أيضًا تهيئة نطاقات عناوين بروتوكول الإنترنت الخاصة بك والشبكات الافتراضية باستخدام kubenet. مثل شبكات Azure CNI، يجب ألا تتداخل نطاقات العناوين هذه مع بعضها البعض أو أي شبكات مرتبطة بالمجموعة (الشبكات الظاهرية والشبكات الفرعية والشبكات المحلية والشبكات النظيرة).

للحصول على التفاصيل المحددة حول الحدود وتحجيم نطاقات العناوين هذه، راجع استخدام شبكة kubenet من خلال نطاقات عنوان بروتوكول الإنترنت في AKS

توزيع نسبة استخدام الشبكة عند الدخول

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

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

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

يجب أن تستخدم معظم تطبيقات الويب التي تستخدم HTTP أو HTTPS موارد ووحدات تحكم دخول Kubernetes، والتي تعمل في الطبقة 7. يمكن توزيع نسبة استخدام الشبكة استنادًا إلى عنوان محدد مواقع ويب للتطبيق ومعالجة إنهاء TLS/SSL. يقلل الدخول عدد عناوين بروتوكول الإنترنت التي تعرضها والمخطط.

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

يوجد نوعان من المكونات للدخول:

1. مورد دخول
2. وحدة التحكم في الدخول

مورد الدخول

يمثل مورد الدخول بيان YAML المقدم منkind: Ingress . حيث يعرف المضيف والشهادات وقواعد توجيه نسبة استخدام الشبكة إلى الخدمات التي تعمل في نظام مجموعة AKS.

يوزع بيان YAML المثال التالي نسبة استخدام الشبكة myapp.com إلى إحدى خدمتين، خدمة المدونة أو خدمة المتجر، ويوجه العميل إلى خدمة واحدة أو أخرى استنادا إلى عنوان URL الذي يصل إليه.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: myapp-ingress
spec:
 ingressClassName: PublicIngress
 tls:
 - hosts:
   - myapp.com
   secretName: myapp-secret
 rules:
   - host: myapp.com
     http:
      paths:
      - path: /blog
        backend:
         service:
           name: blogservice
           port: 80
      - path: /store
        backend:
         service:
           name: storeservice
           port: 80

جهاز التحكم في الدخول

تعتبروحدة التحكم في الدخول العنصر الخفي الذي يعمل على تشغيل عقدة AKS ومراقبة الطلبات الواردة. ثم يتم توزيع نسبة استخدام الشبكة استنادًا إلى القواعد المحددة في موارد الدخول. بالرغم من اعتماد وحدة التحكم في الدخول إلى NGINX، فلن يقيدك AKS بوحدة تحكم محددة. يمكنك استخدام Contour، وHAProxy، وTraefik وما إلى ذلك.

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

الدخول باستخدام ملحق توجيه التطبيق

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

• تكوين سهل لوحدات تحكم دخول NGINX المدارة استنادا إلى وحدة تحكم دخول Kubernetes NGINX.

• التكامل مع Azure DNS لإدارة المنطقة العامة والخاصة.

• إنهاء SSL مع الشهادات المخزنة في Azure Key Vault.

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

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

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

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

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

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

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

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

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

تأمين نسبة استخدام الشبكة باستخدام نُهج الشبكة

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

استخدم نهج الشبكة للسماح بتحديد نسبة استخدام الشبكة في كائنات Pods أو رفضها. يُسمح افتراضيًا بتحديد نسبة استخدام الشبكة بين كائنات Pods داخل نظام المجموعة. لتحسين الأمان، حدد القواعد التي تحد من اتصال كائنات Pod.

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

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

إشعار

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

تُنشئ نهج شبكة كمورد Kubernetes باستخدام بيان YAML. تُطبق السياسات على كائنات Pod المحددة من خلال استخدام قواعد الدخول أو الخروج التي تحدد تدفق نسبة استخدام الشبكة.

يطبق المثال التالي نهج شبكة على كائنات pod باستخدام تطبيق: وتُطبق تسمية الخلفيةعليها. تسمح قاعدة الدخول فقط بنسبة استخدام الشبكة من pods مع التطبيق: تسمية الواجهة الأمامية .

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

للبدء في استخدام النهج، راجع تأمين نسبة استخدام الشبكة بين كائنات pod باستخدام نهج الشبكة في خدمة Azure Kubernetes (AKS).

الاتصال بأمان بالعقد من خلال مضيف محمي

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

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

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

يجب عليك أيضا تأمين شبكة الإدارة لمضيف bastion. استخدم بوابة Azure ExpressRoute أو VPN للاتصال بشبكة محلية والتحكم في الوصول باستخدام مجموعات أمان الشبكة.

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

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