المستوى المطلوب: متوسط. الكلام ده مبني على فرضية إنك تعرف أساسيات Kubernetes (يعني عارف الـ Pod والـ Service وبتشغّل kubectl)، ومش لازم تكون لمست الـ Ingress قبل كده.

Kubernetes Ingress: ازاي توصّل كل خدماتك من باب واحد

لو بتعمل type=LoadBalancer لكل خدمة في الكلاستر، انت بتدفع IP عام وفاتورة سحابية منفصلة لكل خدمة. الـ Ingress بيخلّيك تخرّج عشرات الخدمات من باب HTTP/HTTPS واحد، بـ IP واحد، وبتوفّر أغلب الفاتورة دي. هنا هتطلع بملف Ingress شغّال تقدر تنسخه دلوقتي.

المشكلة باختصار

عندك كلاستر فيه 12 microservice، وكل واحدة محتاجة توصل من برّه. الطريقة المباشرة إنك تعمل لكل خدمة Service بنوع LoadBalancer. اللي بيحصل فعلاً إن السحابة بتـ provision لك Load Balancer حقيقي + IP عام لكل خدمة. يعني 12 خدمة = 12 Load Balancer = 12 فاتورة + 12 IP تديرهم وتأمّنهم. ده غالي ومتعب من غير داعي.

يعني إيه Ingress؟ بمثال الأول

تخيّل مبنى شركة كبير فيه أقسام كتير: مبيعات، دعم فني، حسابات. مفيش مدخل خارجي مستقل لكل قسم. فيه باب واحد، وعنده موظف استقبال. الزائر بيقول "أنا جاي لقسم المبيعات"، الموظف بيوجّهه للمكان الصح جوّه. الزوار كلهم بيدخلوا من باب واحد، والتوجيه بيحصل بالداخل.

الـ Ingress هو موظف الاستقبال ده بالظبط. وعلميًا: الـ Ingress هو كائن في الـ Kubernetes API بيعرّف قواعد توجيه لطلبات HTTP وHTTPS الجاية من برّه الكلاستر لخدمات جوّاه، بناءً على الـ host (زي shop.example.com) أو الـ path (زي /api). بيدعم كمان إنهاء الـ TLS في مكان واحد.

نقطة مهمة: الـ Ingress لوحده مش بيعمل حاجة

ركز هنا، لأن دي بتوقّع ناس كتير. الـ Ingress مجرد قواعد. اللي بينفّذ القواعد دي اسمه Ingress Controller — وده reverse proxy حقيقي (زي NGINX أو Traefik أو HAProxy) شغّال جوّه الكلاستر وبيقرا قواعدك ويعمل الـ routing الفعلي. لو طبّقت ملف Ingress من غير ما يكون عندك Controller متركّب، مفيش حاجة هتحصل خالص. الـ Controller هو اللي بياخد الـ Load Balancer الواحد بتاعك.

مثال تطبيقي: ملف Ingress كامل قابل للنسخ

أول حاجة، ركّب الـ NGINX Ingress Controller بـ Helm:

# تركيب الـ controller (بيـ provision لك Load Balancer واحد بس)
helm upgrade --install ingress-nginx ingress-nginx \
  --repo https://kubernetes.github.io/ingress-nginx \
  --namespace ingress-nginx --create-namespace

# استنى لحد ما ياخد IP خارجي
kubectl get svc -n ingress-nginx ingress-nginx-controller

بعدين عرّف قاعدة توجيه بـ host وpath، مع TLS:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop-ingress
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - shop.example.com
      secretName: shop-tls        # سيرت الـ HTTPS
  rules:
    - host: shop.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: orders-service
                port:
                  number: 80
          - path: /shop
            pathType: Prefix
            backend:
              service:
                name: catalog-service
                port:
                  number: 80

طبّق وتأكّد إنه اشتغل:

kubectl apply -f shop-ingress.yaml
kubectl get ingress shop-ingress

# اختبار التوجيه فعليًا
curl -H "Host: shop.example.com" http://<INGRESS_IP>/api/health   # ⟵ orders-service
curl -H "Host: shop.example.com" http://<INGRESS_IP>/shop/list    # ⟵ catalog-service

دلوقتي الخدمتين بقوا ClusterIP عاديين (مالهمش IP عام)، والـ Ingress Controller بس هو اللي معرّض للنت.

الأرقام: قبل وبعد

على معظم مزوّدي السحابة، الـ Load Balancer الواحد بيكلّف حوالي $18 في الشهر كأساس قبل حساب الترافيك. الافتراض إن عندك 12 خدمة:

• قبل: 12 خدمة × type=LoadBalancer ≈ $216 / شهر + 12 IP عام تديرهم.
• بعد: Ingress Controller واحد = Load Balancer واحد ≈ $18 / شهر + IP واحد.

يعني توفير حوالي 92% في تكلفة الـ Load Balancers، غير إن سطح الهجوم (الـ IPs المعرّضة) نزل من 12 لـ 1. الأرقام دي أساس تقريبي؛ الفاتورة الفعلية بتختلف حسب الترافيك والمزوّد.

الـ trade-offs اللي لازم تعرفها

مفيش حاجة ببلاش. لما تجمّع كل الترافيك في باب واحد:

• بتكسب: IP واحد، فاتورة أقل، TLS مركزي، توجيه مرن بالـ host والـ path.
• بتخسر: الـ Controller بيبقى نقطة فشل لو شغّلته replica واحدة — شغّله بـ replicas ≥ 2 عشان يفضل HA.
• طبقة proxy زيادة بتضيف latency بسيط (عادةً ~1 إلى 3 مللي ثانية لكل طلب). مقبول لمعظم الـ APIs.
• الـ annotations الخاصة بكل Controller (زي nginx.ingress.kubernetes.io/...) مش portable — لو غيّرت من NGINX لـ Traefik هتعيد كتابتها.

متى متستخدمش Ingress

الـ Ingress معمول للطبقة السابعة (HTTP/HTTPS) بس. متستخدمهوش في الحالات دي:

• خدمة TCP/UDP خام زي PostgreSQL أو Redis — دول مش HTTP، استخدم Service type=LoadBalancer أو Gateway API.
• عندك خدمة واحدة بس ومفيش خطة للتوسّع — LoadBalancer مباشر أبسط وأوضح.
• محتاج توجيه على مستوى L4 أو mTLS بين الخدمات الداخلية — ده شغل Service Mesh مش Ingress.

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

افتح الكلاستر بتاعك واعمل kubectl get svc --all-namespaces | grep LoadBalancer. لو طلعلك أكتر من واحد، اختار أبسط خدمتين، حوّلهم لـ ClusterIP، وحطّ قاعدة Ingress واحدة زي اللي فوق. بعد ما تتأكد إنهم شغّالين، عدّ الـ Load Balancers تاني — المفروض الرقم ينزل. لو لسه ثابت، يبقى الـ Controller نفسه مش متركّب صح.

المصادر

• توثيق Kubernetes الرسمي — Ingress وIngress Controllers (تعريف الـ Ingress، الـ pathType، وإن الـ Controller شرط للتشغيل).
• توثيق NGINX Ingress Controller (أوامر التركيب بـ Helm والـ annotations).
• توثيق Kubernetes Gateway API (البديل الأحدث لحالات L4/TCP والـ routing المتقدّم).
• صفحات تسعير الـ Load Balancer لدى مزوّدي السحابة (AWS ELB وGCP Cloud Load Balancing) لأساس تكلفة الـ ~$18/شهر.
• الصور من مشروع CNCF Artwork وأيقونات موارد Kubernetes Community (رخص مفتوحة).