اضبط خدمة من نوع LoadBalancer

تحصل الخدمة من نوع LoadBalancer على موزّع حمل من المنصّة على العنوان العام لمساحة عملك (انظر Kubernetes، وموزّعات الحمل لتعرف أين يتصل العملاء). وتضبط موزّع الحمل هذا من الخدمة نفسها، عبر الحقل القياسي loadBalancerSourceRanges وبضعة تعليقات توضيحية (annotations) تحت lb.sahabti.com/. المجموعة هي مرجع الحقيقة: تعرض لوحة التحكم هذه الإعدادات في صفحة موزّع الحمل للقراءة فقط، ومع كل إعداد الحقل أو التعليق التوضيحي الذي يأتي منه.

في قسم نظرة عامة من صفحة موزّع الحمل، تعرض لوحة التحكم مكان اتصال العملاء على أنه نقطة اتصال لتطبيقاتك: اسم المضيف مع المنفذ العام، مثل prod-default-db-e5f6a7b8-q2w7ze.lb.sahabti.app:40002، والبروتوكول، جاهزة للنسخ. وهي ليست عنوان موقع ويب: تستخدم المواقع رابط المجموعة، https://<cluster>.sahabti.app، الذي تخدمه البوابة المُدارة للمجموعة.

ما الذي يمكنك ضبطه

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

اسمح لمصادر بعينها فقط

apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  type: LoadBalancer
  selector:
    app: web
  ports:
    - port: 443
      targetPort: 8443
  loadBalancerSourceRanges:
    - 203.0.113.0/24
    - 198.51.100.7/32

لا يتصل بمنافذ الخدمة إلا هذه المصادر، ويُسقَط اتصال كل من عداها. ولتغيير القائمة في خدمة تعمل:

kubectl patch service web -p '{"spec":{"loadBalancerSourceRanges":["203.0.113.0/24"]}}'

• يُعامَل العنوان المفرد على أنه /32، ووجود 0.0.0.0/0 في أي موضع من القائمة يعني أي شخص.
• لموزّع الحمل عنوان IPv4 فقط، لذا تُتجاهَل نطاقات IPv6. ولا يمكن تطبيق قائمة لا تضم إلا نطاقات IPv6.
• يُحذَف النطاق الذي يحتويه نطاق آخر في القائمة.

ارفض مصادر بعينها

metadata:
  annotations:
    lb.sahabti.com/denied-sources: "192.0.2.15, 198.51.100.0/24"

kubectl annotate service web lb.sahabti.com/denied-sources="192.0.2.15,198.51.100.0/24" --overwrite

تُسقَط المصادر المرفوضة قبل أن تصل إلى أي منفذ من منافذ موزّع الحمل، ما دامت مدرجة في القائمة. افصل بينها بفواصل أو مسافات أو أسطر جديدة. أما المصادر التي يحظرها موزّع الحمل من تلقاء نفسه لتجاوزها حدًّا من حدود الحماية فأمرها مختلف: ينتهي حظرها وحده، وتظهر تحت المصادر المحظورة في صفحة الأمان الخاصة بموزّع الحمل.

اختر ملف الحماية

يحدّ كل موزّع حمل من الاتصالات الجديدة والمتزامنة ومن الإغراق لكل مصدر، ويحظر المصدر الذي يتجاوز حدًّا منها. والملف strict يشدّد هذه الحدود، وهو مناسب لقواعد البيانات ومنافذ الإدارة المكشوفة:

kubectl annotate service web lb.sahabti.com/protection-profile=strict --overwrite

وللمنافذ التي تستقبل كثيرًا من الاتصالات القصيرة لسبب مشروع، مثل أدوات المراقبة أو عملاء خلف عنوان مكتب واحد، اضبط lb.sahabti.com/short-session-bans: "off" كي لا تُحظر مصادرها؛ وتبقى بقية الحدود سارية.

اضبط مهلة الخمول

المدة التي يمكن أن يبقى فيها اتصال TCP خاملًا، دون أن يُرسَل شيء في أي من الاتجاهين، قبل أن يغلقه موزّع الحمل. ارفعها للاتصالات الطويلة مثل WebSockets وطوابير الرسائل وجلسات قواعد البيانات التي تهدأ بين الاستعلامات.

kubectl annotate service web lb.sahabti.com/idle-timeout=900 --overwrite

مرّر عنوان العميل

ترى حاوياتك الاتصالات قادمة من موزّع الحمل لا من العميل. ومع proxy-protocol يبدأ كل اتصال TCP بترويسة PROXY protocol v2 تحمل عنوان العميل ومنفذه:

kubectl annotate service web lb.sahabti.com/client-ip=proxy-protocol --overwrite

فعّل PROXY protocol في الخادم الذي يستقبل الاتصالات، كمتحكّم الدخول (ingress controller) أو خادم الويب، قبل أن تضبط التعليق التوضيحي: فالخادم الذي لا يتوقّع الترويسة يعاملها كطلب معطوب. ولا تحمل منافذ UDP هذه الترويسة أبدًا.

أما preserve، الذي يُبقي عنوان العميل على الحزم نفسها، فغير متاح لموزّع حمل خاص بمجموعة: فعُقد المجموعة لا توجّه ردودها عبره.

مثال كامل

apiVersion: v1
kind: Service
metadata:
  name: shop
  annotations:
    lb.sahabti.com/protection-profile: strict
    lb.sahabti.com/idle-timeout: "300"
    lb.sahabti.com/denied-sources: "192.0.2.15"
    lb.sahabti.com/client-ip: proxy-protocol
spec:
  type: LoadBalancer
  selector:
    app: shop
  ports:
    - name: https
      port: 443
      targetPort: 8443
  loadBalancerSourceRanges:
    - 203.0.113.0/24

ضع الأرقام في التعليقات التوضيحية بين علامتي تنصيص كما في المثال، فقيم التعليقات التوضيحية نصوص.

تحقّق مما طُبِّق

تخبرك أحداث الخدمة وحالتها lb.sahabti.com/SettingsApplied بما فعلته المنصّة بإعداداتها:

kubectl describe service shop
kubectl get service shop -o jsonpath='{.status.conditions}'

يُسجَّل حدث تحذير LoadBalancerSettingsInvalid حين يتعذّر تطبيق قيمة، وحدث عادي LoadBalancerSettingsApplied حين تُطبَّق كل الإعدادات من جديد. ولا تحمل الخدمة التي لا تضبط شيئًا من هذه الإعدادات هذه الحالة.

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

حين يتعذّر تطبيق قيمة

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

تغييرات الإعدادات محدودة بثلاثين تغييرًا في الدقيقة لكل مجموعة. وما زاد على ذلك تطبّق المنصّة أحدث إعداداته بعد ثوانٍ قليلة.