كيفية إعداد NGINX تحكم إدخال على مجموعات AWS

TL. DR ببساطة انسخ أوامر الأوامر للحصول على وحدة تحكم NGINX تعمل بكامل طاقتها على أي مجموعة AWS Kubernetes

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

من المهم أن نلاحظ البيان الأول الذي أدليت به أعلاه.

أدوات التحكم في الدخول هي مديري البوابة لحركة مرور الشبكة

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

دعونا نفهم هذا مع مثال.

ضع في اعتبارك إعداد AWS مع مثيل EC2 واحد يدعم موازن التحميل المرن الذي يواجه الجمهور (ELB). ستكون بوابة حركة المرور في هذه الحالة هي ELB. مدير البوابة هو الكيان الذي يقوم بتكوين ELB ويقوم بتشغيله.

Nginx هو خيار رائع للوكيل العكسي لـ Kubernetes

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

تحميل موازن التخطيط

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

  1. قم بإعداد موازن تحميل على مستوى نظام المجموعة واستخدم SNI أو التوجيه المستند إلى المسار للخدمات
  2. قم بإعداد موازن التحميل لكل خدمة تحتاج إليها

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

الإدارة على مجموعات AWS Kubernetes

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

تعمل وحدة التحكم في الدخول هذه أولاً بإنشاء مثيل ELB للكتلة. تتيح لنا هذه الخاصية توصيل وحدة التحكم في إنجن إكس بسهولة مع المسار 53.

دعونا نفهم ذلك من خلال إعداد وحدة تحكم دخول nginx تعمل بكامل طاقتها ومثيلات إدخال.

إعداد وحدة تحكم دخول NGINX

ابدأ بإنشاء مساحة اسم لوحدة التحكم في الدخول لتشغيلها

$ kubectl create -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/namespace.yaml

ثم قم بإنشاء دور نظام المجموعة ودور وحدة تحكم إدخال nginx

$ kubectl create -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/rbac.yaml

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

config_map:
  البيانات:
    العميل الجسم العازلة الحجم: 32M
    hsts: "صحيح"
    وكيل الجسم الحجم: 1G
    التخزين المؤقت الوكيل: "خطأ"
    مهلة قراءة الوكيل: "600"
    مهلة إرسال الوكيل: "600"
    الرموز المميزة للخادم: "false"
    إعادة توجيه ssl: "false"
    اتصالات upstream-keepalive: "50"
    استخدام بروتوكول الوكيل: "صواب"
  تسميات:
    التطبيق: ingress-nginx
  الاسم: التكوين nginx
  مساحة الاسم: ingress-nginx
  الإصدار: v1
---
config_map:
  الاسم: خدمات التعاون الفني
  مساحة الاسم: ingress-nginx
  الإصدار: v1
---
config_map:
  الاسم: udp الخدمات
  مساحة الاسم: ingress-nginx
  الإصدار: v1

لاحظ التكوين مجموعة أعلاه. هذا هو التكوين القياسية التي عملت بشكل جيد بالنسبة لنا.

يوصى باستخدام HTTP Strict Transport Security (hsts). يتم استخدام هذا ، إلى جانب إعادة توجيه SSL ، لإعادة توجيه طلبات HTTP إلى HTTPS. يعتبر هذا عمومًا أكثر أمانًا. نوصي بذلك إلا إذا كانت خدمتك تحتاج على وجه التحديد إلى إنهاء SSL نفسها.

الخيار المهم الآخر أعلاه هو استخدام بروتوكول الوكيل. نظرًا لأنني سأقوم بإعداد L4 ELB loadbalancer (والذي لا يقوم بإعادة توجيه SRC IP و SRC Port و SRC proto وغيرها من المعلومات المهمة المحتملة إلى الخدمات التي تقف خلفه) ، فإن هذا الخيار يوفر آلية لإعادة توجيه رؤوس L7 هذه.

لنقم بإنشاء خريطة التكوين هذه

$ short -k -f configmap.short.yaml> configmap.yaml
kubectl $ إنشاء -f configmap.yaml

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

$ kubectl create -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/default-backend.yaml

يؤدي هذا إلى إنشاء جراب وخدمة مقابلة تعمل بمثابة "خدمة شاملة" عند تقديم طلب للحصول على عنوان URL غير متوفر.

الآن ، يجب أن نطلق قرون الوكيل nginx التي ستوجه حركة المرور إلى الواجهة الخلفية الافتراضية حتى تتم إضافة قاعدة الدخول.

kubectl create -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/with-rbac.yaml

نحن على وشك الانتهاء. الوكيل موجود ويعمل. ومع ذلك ، لتوجيه حركة المرور من خارج الكتلة باستخدام عنوان URL واحد ، نحتاج إلى إنشاء مثيل ELB. يمكن القيام بذلك عن طريق إنشاء خدمة Kubernetes من نوع Loadbalancer.

apiVersion: v1
النوع: الخدمة
البيانات الوصفية:
  الشروح:
    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: tcp
    service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout: "3600"
    service.beta.kubernetes.io/aws-load-balancer-proxy-protocol: '*'
    service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn: aws: acm: us-east-1: 1234567: certificate / 1234294-232-4f89-bca8
    service.beta.kubernetes.io/aws-load-balancer-ssl-ports: https
  تسميات:
    الملحق k8s: ingress-nginx.addons.k8s.io
  الاسم: ingress-nginx
  مساحة الاسم: ingress-nginx
المواصفات:
  externalTrafficPolicy: الكتلة
  الموانئ:
  - الاسم: https
    الميناء: 443
    البروتوكول: TCP
    targetPort: http
  - الاسم: http
    الميناء: 80
    البروتوكول: TCP
    targetPort: http
  محدد:
    التطبيق: ingress-nginx
  النوع: LoadBalancer

لاحظ أنني قمت بتعيين شهادة ssl (تم التأكيد عليها أعلاه). هذه هي الشهادة لإنهاء طبقة المقابس الآمنة ويجب أن تنتمي إلى المجال الذي تملكه. سنرى كيفية توجيه حركة المرور من هذا المجال إلى خدمات محددة لاحقًا في هذه المقالة. من أجل هذا المثال ، دعنا نعتبر أن هذا المجال هو:

kube-example.com

يمكن استخدام مدير شهادات AWS لإنشاء شهادة لهذا المجال. بمجرد الإنشاء ، لاحظ arn لـ cert واستخدمه هنا لإنهاء SSL في ELB. الآن ، لننشر خدمة Loadbalancer

$ short -k -f nginx-service.short.yaml> nginx-service.yaml
kubectl $ إنشاء -f nginx-service.yaml

ستحتوي المجموعة على موازن تحميل nginx يعمل بكامل طاقته ويتجه ELB.

إعداد الطريق 53 وإعادة توجيه حركة المرور

لاحظ أن هذا الجزء غير مطلوب للاختبار البسيط. يمكنك استخدام عناوين URL العامة ELB لاختبار قدرات التوجيه.

الآن وبعد تشغيل ELB ، يمكنك تكوين مجال / مجال فرعي في route53 للإشارة إلى موازن التحميل هذا. تعليمات لهذا ويمكن الاطلاع هنا.

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

دعونا نفهم هذا بمثال. وكخلاصة سريعة ، فإن النطاق الذي نعمل به هو kube-example.com

اطلع على مثال تعريض لوحة معلومات Grafana لمجموعة Kubenretes في المسار / الشاشة. يمكن تحقيق ذلك عن طريق إنشاء مورد دخول:

دخول:
  الشروح:
    ingress.kubernetes.io/rewrite-target: /
    بيانات اعتماد nginx.ingress.kubernetes.io/cors-allow-: "صواب"
    nginx.ingress.kubernetes.io/cors-allow-headers: إذن أو أصل أو قبول
    nginx.ingress.kubernetes.io/cors-allow-methods: GET، OPTIONS
    nginx.ingress.kubernetes.io/cors-allow-origin: kube-example.com/monitor
    nginx.ingress.kubernetes.io/enable-cors: "true"
  الاسم: kubernetes-grafana-ingress
  مساحة الاسم: نظام kube
  قواعد:
  - المضيف: kube-example.com
    مسارات:
    - المسار: / الشاشة
      الميناء: 80
      الخدمة: مراقبة غرافانا
  TLS:
  - المضيفين:
    - kube-example.com
  الإصدار: ملحقات / v1beta1

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

ما يطلبه المستخدم: kube-example.com/monitor
ما يحصل عليه Grafana: kube-example.com/

أيضا grafana يتطلب دعم كورس. يظهر التكوين لإضافة هذا في التعليقات التوضيحية الواردة أعلاه.

خاتمة

يمكن استخدام إعداد nginx ingress هذا أمام خدمات Kubernetes الخاصة بك وعرضها على العالم.

هناك الكثير من التهيئة لـ nginx وتُلزم العديد من منشورات المدونة بشرحها. إذا كنت مهتمًا بجميع الطرق المثيرة للاهتمام لتهيئة nginx ، فيرجى التعليق أدناه. سوف أقوم بإنشاء سلسلة مدونة عليها.

ترقبوا المزيد من الغطس العميق Kubernetes!