مشاركة عبر

طوبولوجيا الشبكة واعتبارات الاتصال ل Azure Red Hat OpenShift

  • مقالة

راجع اعتبارات التصميم والتوصيات لطوبولوجيا الشبكة والاتصال عند استخدام مسرع منطقة هبوط Azure Red Hat OpenShift.

اعتبارات التصميم

  • يتطلب Azure Red Hat OpenShift شبكة فرعية أساسية وشبكة فرعية ثانوية.

    • استخدم الشبكة الفرعية الأساسية لتوزيع العقد الأساسية لنظام المجموعة.
    • استخدم الشبكة الفرعية الثانوية لتوزيع العقد الثانوية لنظام المجموعة.
    • يجب أن تكون الشبكة الفرعية الثانوية والشبكة الفرعية الأساسية حد أدنى /27 من المسار.
    • لا يمكنك تغيير الشبكة الفرعية الثانوية أو الشبكة الفرعية الأساسية بعد نشر نظام المجموعة.
    • لا يمكن أن تحتوي الشبكة الفرعية الأساسية والشبكة الفرعية الثانوية على مجموعة أمان شبكة مقترنة بها. تقوم مجموعة Azure Red Hat OpenShift تلقائيا بإنشاء مجموعة أمان شبكة وإدارتها.
    • لا يمكن أن تتداخل الشبكة الفرعية الثانوية والشبكة الفرعية الأساسية مع الشبكات المحلية أو مع أي شبكة أخرى في Azure.

  • خطط بعناية لعناوين IP وحجم الشبكة الفرعية للشبكة الظاهرية لدعم تحجيم نظام المجموعة. قد تحتاج إلى إضافة عقد.

  • يمكنك عرض خدمات Azure Red Hat OpenShift ومساراته باستخدام موازنات التحميل العامة أو الداخلية. إعداد موازنات التحميل الداخلية في نفس الشبكة الفرعية مثل العقد الثانوية. في مجموعة خروج مقيدة، لا يمكنك استخدام موازنات التحميل العامة بسبب التوجيه غير المتماثل.

  • يستخدم Azure Red Hat OpenShift CoreDNS لتوفير تحليل الاسم للحجيرات التي تعمل في نظام المجموعة.

    • يحل CoreDNS المجالات الداخلية لنظام المجموعة مباشرة.
    • يدعم Azure Red Hat OpenShift أيضا خوادم DNS المخصصة في الشبكة الظاهرية.
    • تتم إعادة توجيه المجالات الأخرى إلى خوادم DNS التي تقوم بتكوينها في شبكة Azure الظاهرية. ستكون خوادم DNS إما محلل Azure DNS الافتراضي أو أي خوادم DNS مخصصة تقوم بتكوينها على مستوى الشبكة الظاهرية.
    • يمكنك تخصيص إعادة توجيه DNS في Azure Red Hat OpenShift CoreDNS.
    • إذا لم يتم تكوين خوادم DNS مخصصة في الشبكة الظاهرية، فإن Azure Red Hat OpenShift يستخدم محلل Azure DNS الافتراضي.

    لمزيد من المعلومات حول DNS، راجع تكوين Azure Private Endpoint DNS.

  • يمكنك إرسال نسبة استخدام الشبكة الصادرة (الخروج) من خلال جدار حماية Azure أو من خلال مجموعة أجهزة ظاهرية للشبكة.

  • بشكل افتراضي، يمكن لجميع الحجيرات في نظام مجموعة Azure Red Hat OpenShift إرسال نسبة استخدام الشبكة وتلقيها دون قيود. يمكن الوصول إلى جميع الحجيرات في المشروع من القرون الأخرى ونقاط نهاية الشبكة. لعزل حاوية واحدة أو أكثر في مشروع، يمكنك إنشاء NetworkPolicy كائنات في المشروع للإشارة إلى الاتصالات الواردة المسموح بها. تدعم شبكة Red Hat OpenShift المعرفة بالبرامج (SDN) استخدام نهج الشبكة في وضع عزل الشبكة الافتراضي.

  • توفر شبكة الخدمة إمكانات مثل إدارة نسبة استخدام الشبكة والمرونة والنهج والأمان والهوية القوية وإمكانية المراقبة. لمزيد من المعلومات حول شبكة خدمة Red Hat OpenShift، راجع Service Mesh واختلافات Istio.

  • تزيد آليات موازنة التحميل العمومية مثل Azure Traffic ManagerوAzure Front Door من المرونة عن طريق توجيه نسبة استخدام الشبكة عبر مجموعات متعددة، ربما في مناطق Azure المختلفة.

المجموعات الخاصة

يمكن أن يكون عنوان IP لنظام مجموعة Azure Red Hat OpenShift API عاما أو خاصا. تعرض المجموعات الخاصة واجهة برمجة تطبيقات Azure Red Hat OpenShift عبر عنوان IP خاص ولكن ليس عبر عنوان عام. لا ينبغي الوصول إلى واجهة برمجة تطبيقات Azure Red Hat OpenShift من خلال عنوان IP الخاص بها. بدلا من ذلك، قم بالوصول إلى واجهة برمجة تطبيقات Azure Red Hat OpenShift من خلال اسم المجال المؤهل بالكامل (FQDN). يحل Azure DNS Azure Red Hat OpenShift API FQDN إلى عنوان IP الخاص به.

تماشيا مع الممارسات المثبتة لمنطقة Azure المنتقل إليها، يتم تقديم دقة DNS لأحمال عمل Azure بواسطة خوادم DNS المركزية التي يتم نشرها في اشتراك الاتصال. توجد خوادم Azure DNS إما في شبكة ظاهرية مركزية أو في شبكة ظاهرية للخدمات المشتركة متصلة بمثيل Azure Virtual WAN. تحل خوادم DNS الأسماء العامة والخاصة ب Azure بشكل مشروط باستخدام Azure DNS (عنوان 168.63.129.16IP). تحل الخوادم الأسماء الخاصة باستخدام خوادم DNS الخاصة بالشركة. نموذج الاتصال هذا شائع، ومن المهم السماح بالوصول الخاص إلى موارد Azure الأخرى إذا كنت تستخدم نقاط النهاية الخاصة.

رسم تخطيطي يوضح شبكة لنظام مجموعة خاصة.

نسبة استخدام الشبكة من مستخدمي التطبيق إلى نظام المجموعة

استخدم وحدات التحكم الواردة (الدخول) لعرض التطبيقات التي تعمل في مجموعات Azure Red Hat OpenShift.

  • توفر وحدات التحكم في الدخول التوجيه على مستوى التطبيق مع زيادة طفيفة في التعقيد فقط.
  • ينشئ Azure Red Hat OpenShift إدخال DNS عام يبسط الوصول إلى التطبيقات المكشوفة في نظام المجموعة. مثال على إدخال DNS هو *.apps.<cluster-ID>.<region>.aroapp.io. من المفيد لنظام مجموعة خاصة توجيه نسبة استخدام الشبكة للتطبيق.
  • يوفر Azure Red Hat OpenShift وحدة تحكم ومسارات دخول مضمنة.
  • يمكنك استخدام دخول Azure Red Hat OpenShift مع Azure Front Door.
  • قم بمحاذاة التكوين الخاص بك مع تصميم تصفية الخروج لتجنب التوجيه غير المتماثل. قد تتسبب UDRs في توجيه غير متماثل.
  • إذا كان السيناريو الخاص بك يتطلب إنهاء TLS، ففكر في كيفية إدارة شهادات TLS.

هام

إذا كنت تستخدم Azure Firewall لتقييد نسبة استخدام الشبكة الخارجة وإنشاء UDR لفرض جميع نسبة استخدام الشبكة الخارجة، فتأكد من إنشاء قاعدة مناسبة لترجمة عناوين شبكة الوجهة (DNAT) في جدار حماية Azure للسماح بنسبة استخدام الشبكة للدخول بشكل صحيح. استخدام Azure Firewall مع UDR يقطع إعداد الدخول بسبب التوجيه غير المتماثل. تحدث المشكلة إذا كانت الشبكة الفرعية Azure Red Hat OpenShift تحتوي على مسار افتراضي ينتقل إلى عنوان IP الخاص بجدار الحماية، ولكنك تستخدم موازن تحميل عام (خدمة الدخول أو Kubernetes من النوع Load Balancer). في هذه الحالة، يتم تلقي حركة مرور موازن التحميل الواردة عبر عنوان IP العام الخاص به، ولكن مسار الإرجاع يمر عبر عنوان IP الخاص بجدار الحماية. نظرا لأن جدار الحماية ذو حالة، فإنه يسقط حزمة الإرجاع لأن جدار الحماية لا يكتشف جلسة عمل تم إنشاؤها. لمعرفة كيفية دمج Azure Firewall مع موازن تحميل الدخول أو الخدمة، راجع دمج Azure Firewall مع Azure Standard Load Balancer.

تصف الخطوات التالية التدفق إذا كنت تستخدم Azure Front Door مع نظام مجموعة Azure Red Hat OpenShift الخاص ووحدة تحكم الدخول:

  1. يحل العملاء من الإنترنت العام اسم DNS للتطبيق الذي يشير إلى Azure Front Door.
  2. يستخدم Azure Front Door خدمة Azure Private Link للوصول إلى عنوان IP الخاص لموازن تحميل شبكة Azure الداخلية والوصول إلى تطبيق في وحدة تحكم دخول Azure Red Hat OpenShift.

تصف هذه الخطوات تدفق تطبيق غير ويب يصل إلى مجموعة Azure Red Hat OpenShift الخاصة:

  1. يحل العملاء من الإنترنت العام اسم DNS للتطبيق الذي يشير إلى عنوان IP العام لجدار حماية Azure أو جهاز ظاهري للشبكة.
  2. يقوم جدار حماية Azure أو الجهاز الظاهري للشبكة بإعادة توجيه نسبة استخدام الشبكة (DNAT) إلى نظام مجموعة Azure Red Hat OpenShift الخاصة باستخدام عنوان IP الخاص لموازن تحميل شبكة Azure الداخلية للوصول إلى التطبيق في وحدة تحكم دخول Azure Red Hat OpenShift.

نسبة استخدام الشبكة من حجيرات Azure Red Hat OpenShift إلى الخدمات الخلفية

قد تحتاج الحجيرات التي تعمل داخل مجموعة Azure Red Hat OpenShift إلى الوصول إلى الخدمات الخلفية مثل Azure Storage وAzure Key Vault وقاعدة بيانات Azure SQL وAzure Cosmos DB. يمكنك استخدام نقاط نهاية خدمة الشبكة الظاهريةوAzure Private Link لتأمين الاتصال بهذه الخدمات المدارة من Azure.

إذا كنت تستخدم نقاط نهاية Azure الخاصة لنسبة استخدام الشبكة الخلفية، يمكنك استخدام مناطق Azure Private DNS لتحليل DNS لخدمات Azure. نظرا لأن محللات DNS للبيئة بأكملها موجودة في الشبكة الظاهرية المركزية (أو في الشبكة الظاهرية للخدمات المشتركة، إذا كنت تستخدم نموذج اتصال Virtual WAN)، فقم بإنشاء هذه المناطق الخاصة في اشتراك الاتصال. لإنشاء سجل A المطلوب لحل FQDN للخدمة الخاصة، يمكنك إقران منطقة DNS الخاصة في اشتراك الاتصال بنقطة النهاية الخاصة في اشتراك التطبيق. تتطلب هذه العملية أذونات محددة في تلك الاشتراكات.

يمكنك إنشاء سجلات A يدويا، ولكن يؤدي ربط منطقة DNS الخاصة بنقطة النهاية الخاصة إلى إعداد أقل عرضة للتكوينات الخاطئة.

يتبع الاتصال الخلفي من حاويات Azure Red Hat OpenShift إلى نظام Azure الأساسي كخدمة (PaaS) المكشوفة من خلال نقاط النهاية الخاصة هذا التسلسل:

  1. تقوم حجيرات Azure Red Hat OpenShift بحل FQDN ل Azure PaaS باستخدام خوادم DNS المركزية في اشتراك الاتصال، والتي يتم تعريفها على أنها خوادم DNS مخصصة في شبكة Azure Red Hat OpenShift الظاهرية.
  2. عنوان IP الذي تم حله هو عنوان IP الخاص لنقاط النهاية الخاصة، والتي يتم الوصول إليها مباشرة من حجيرات Azure Red Hat OpenShift.

لا تمر نسبة استخدام الشبكة بين حجيرات Azure Red Hat OpenShift ونقاط النهاية الخاصة بشكل افتراضي عبر مثيل Azure Firewall في الشبكة الظاهرية المركزية (أو المركز الظاهري الآمن، إذا كنت تستخدم Virtual WAN)، حتى إذا تم تكوين مجموعة Azure Red Hat OpenShift لتصفية الخروج باستخدام جدار حماية Azure. تنشئ نقطة النهاية الخاصة مسارا /32 في الشبكات الفرعية للشبكة الظاهرية للتطبيق التي يتم فيها نشر Azure Red Hat OpenShift.

توصيات التصميم

  • إذا كان نهج الأمان يتطلب منك استخدام عنوان IP خاص لواجهة برمجة تطبيقات Azure Red Hat OpenShift، فوزع مجموعة Azure Red Hat OpenShift خاصة.
  • استخدم Azure DDoS Protection Standard لحماية الشبكة الظاهرية التي تستخدمها لمجموعة Azure Red Hat OpenShift ما لم تستخدم جدار حماية Azure أو جدار حماية تطبيق الويب في اشتراك مركزي.
  • استخدم تكوين DNS المرتبط بإعداد الشبكة الشامل مع Azure Virtual WAN أو بنية مركزية ومتحدثة ومناطق Azure DNS والبنية الأساسية لنظام أسماء النطاقات الخاصة بك.
  • استخدم Azure Private Link لتأمين اتصالات الشبكة، واستخدم الاتصال الخاص المستند إلى IP بخدمات Azure المدارة الأخرى التي تدعم Private Link، مثل Azure Storage وAzure Container Registry وAzure SQL Database وAzure Key Vault.
  • استخدم وحدة تحكم الدخول لتوفير توجيه HTTP وأمان متقدمين ولتقديم نقطة نهاية واحدة للتطبيقات.
  • يجب أن تستخدم جميع تطبيقات الويب التي تقوم بتكوينها لاستخدام الدخول تشفير TLS ويجب ألا تسمح بالوصول عبر HTTP غير المشفرة.
  • استخدم Azure Front Door مع Web Application Firewall لنشر تطبيقات Azure Red Hat OpenShift بأمان على الإنترنت.
  • إذا كان نهج الأمان الخاص بك يتطلب منك فحص جميع حركة مرور الإنترنت الصادرة التي تم إنشاؤها في نظام مجموعة Azure Red Hat OpenShift، وتأمين نسبة استخدام شبكة الخروج باستخدام جدار حماية Azure أو جهاز ظاهري لشبكة خارجية يتم نشره في الشبكة الظاهرية للمركز المدار. لمزيد من المعلومات، راجع التحكم في نسبة استخدام الشبكة الخارجة إلى مجموعة Azure Red Hat OpenShift.
  • استخدم طبقة Azure Load Balancer Standard بدلا من المستوى الأساسي للتطبيقات غير التابعة للويب.

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