ما هو Ingress وكيف يوجّه حركة المرور الخارجية إلى الـ Services؟

Question

IT Interview Practice · Accepted Answer

الـ **Ingress** كائن في Kubernetes يعرّف **قواعد توجيه HTTP/HTTPS** — يربط أسماء المضيفين ومسارات URL بـ **Services** خلفية. يُنفَّذ بواسطة **Ingress Controller** (nginx، Traefik، بوّابات سحابية) ويمنحك نقطة دخول واحدة، وإنهاء TLS، وتوجيهاً حسب المضيف/المسار بدلاً من LoadBalancer لكل خدمة.

## المشكلة التي يحلّها Ingress

```text
Exposing many services with type: LoadBalancer means MANY cloud LBs (and public IPs)
— expensive, and no shared hostname/path routing or TLS.
Ingress gives ONE entry point that routes by host & path to internal ClusterIP Services.
```

## كيف تتناسق الأمور معاً

```text
      Internet
         │
   ┌─────┴──────────────┐
   │ Ingress Controller │  (a Pod, e.g. nginx; usually behind ONE LoadBalancer)
   │  reads Ingress rules│
   └─────┬──────────────┘
         │ routes by host / path
   ┌─────┼───────────────┬───────────────┐
   ▼                     ▼               ▼
 Service: web        Service: api    Service: admin  (all ClusterIP)
   │                     │               │
 Pods                  Pods            Pods

Ingress (rules)  ≠  Ingress Controller (the running proxy that enforces them)
```

## manifest الخاص بـ Ingress

```yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  tls:
    - hosts: [shop.example.com]
      secretName: shop-tls        # شهادة/مفتاح TLS مخزّنان في Secret
  rules:
    - host: shop.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api
                port: { number: 80 }
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web
                port: { number: 80 }
```

```text
shop.example.com/api/... → Service "api" → api Pods
shop.example.com/...     → Service "web" → web Pods
TLS is terminated at the controller using the cert in the "shop-tls" Secret.
```

## نقاط مفتاحية

```text
• You MUST run an Ingress Controller — the Ingress object alone does nothing.
• ingressClassName selects which controller handles the rules.
• Ingress is HTTP/HTTPS (L7) only. For raw TCP/UDP use a Service or Gateway API.
• The newer Gateway API is the evolving successor with richer, role-oriented routing.
```

```bash
kubectl get ingress                  # سرد القواعد والمضيفين والعناوين
kubectl describe ingress app-ingress # رؤية الخلفيّات (backends) والأحداث
```

## لماذا يهم

الـ Ingress هو الطريقة القياسية لكشف تطبيقات HTTP/HTTPS للعالم الخارجي على Kubernetes، لذا فإن فهمه معرفةٌ شبكية ضرورية للمهندسين بمستوى متوسّط. المشكلة التي يحلّها ملموسة وشائعة: فكشف خدمات كثيرة عبر `type: LoadBalancer` يعني توفير موازن حِمل سحابي منفصل وعنوان IP عام لكل خدمة — مكلف ودون توجيه مشترك حسب اسم المضيف أو TLS — بينما يمنحك **Ingress** نقطة دخول واحدة توجّه حسب **المضيف والمسار** إلى خدمات ClusterIP الداخلية وتُنهي **TLS** مركزياً. التمييز الذي يُعثِر الناس هو بين **كائن Ingress** (قواعد التوجيه التصريحية) و**Ingress Controller** (الـ proxy الفعلي العامل — nginx، Traefik، بوّابة سحابية — الذي يراقب تلك القواعد ويفرضها)؛ فالقواعد لا تفعل شيئاً دون controller مُثبَّت، ويحدّد `ingressClassName` أيّ controller يتولّاها. إن فهم أن Ingress يعمل عند **L7 (HTTP/HTTPS فقط)** — فالـ TCP/UDP الخام يحتاج إلى Service أو الـ Gateway API الأحدث — وأن **Gateway API** هو الخلَف المتطوّر الأكثر تعبيراً، يعكس معرفةً حالية واقعية. ولأن كل تطبيق موجّه للمستخدم على Kubernetes تقريباً يحتاج إلى توجيه حسب المضيف/المسار وTLS من نقطة دخول واحدة، ولأن التمييز بين الكائن والـ controller مصدر التباس متكرّر في المقابلات والممارسة معاً، فإن الإلمام الجيّد بـ Ingress أساسٌ لكشف workloads الويب وتشغيلها على عنقود.

المشكلة التي يحلّها Ingress

كيف تتناسق الأمور معاً

manifest الخاص بـ Ingress

نقاط مفتاحية

لماذا يهم

أسئلة ذات صلة