ما هي الـ Services في Kubernetes، وما الفرق بين ClusterIP وNodePort وLoadBalancer؟

Question

IT Interview Practice · Accepted Answer

الـ **Service** يمنح هويّة شبكية ثابتة (عنوان IP افتراضي واسم DNS) لـ *مجموعة من الـ Pods* مُختارة عبر الـ labels. ولأن الـ Pods عابرة وتغيّر عناوين IP الخاصة بها، فإن الـ Service هو العنوان الدائم الذي يستخدمه العملاء، وهو **يوازن الحِمل (load-balances)** عبر الـ Pods السليمة خلفه.

## لماذا توجد الـ Services

```text
Pods come and go (new IP each time). Clients need a STABLE endpoint.
A Service:
  → selects Pods by label  (selector: app=web)
  → gets a fixed virtual IP + DNS name (web.default.svc.cluster.local)
  → load-balances requests across the matching, READY Pods
```

## أنواع الـ Service الرئيسية الثلاثة

```text
ClusterIP    (default)  → reachable ONLY inside the cluster
                          for pod-to-pod / internal service communication
NodePort               → opens a port on EVERY node (30000-32767)
                          external traffic hits nodeIP:nodePort → Service → Pods
LoadBalancer           → provisions an external cloud load balancer
                          gives a public IP that routes to the Service
```

```text
       Internet
          │
   ┌──────┴───────┐
   │ LoadBalancer │  (cloud LB, public IP)   ← for public services
   └──────┬───────┘
          │
   ┌──────┴───────┐
   │  NodePort    │  (node:30080)            ← exposes on each node
   └──────┬───────┘
          │
   ┌──────┴───────┐
   │  ClusterIP   │  (10.96.x.x, internal)   ← the base building block
   └──────┬───────┘
       Pods (app=web)
LoadBalancer builds on NodePort, which builds on ClusterIP.
```

## ClusterIP (داخلي)

```yaml
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  type: ClusterIP          # الافتراضي؛ يمكن حذفه
  selector:
    app: web               # يطابق الـ Pods التي تحمل label app=web
  ports:
    - port: 80             # منفذ الـ Service
      targetPort: 8080     # منفذ الحاوية
```

تصل إليه الـ Pods الأخرى عبر DNS: `http://web` (نفس namespace) أو `http://web.default.svc.cluster.local`.

## NodePort وLoadBalancer

```yaml
# NodePort — كل عقدة تستمع على nodePort وتوجّه إلى الـ Service
spec:
  type: NodePort
  selector: { app: web }
  ports:
    - port: 80
      targetPort: 8080
      nodePort: 30080      # اختياري؛ 30000-32767
---
# LoadBalancer — تُوفّر السحابة موازن حِمل خارجياً بعنوان IP عام
spec:
  type: LoadBalancer
  selector: { app: web }
  ports:
    - port: 80
      targetPort: 8080
```

```bash
kubectl get svc            # عرض الأنواع وعناوين cluster IP وexternal IP
kubectl get endpoints web  # عناوين IP الفعلية للـ Pods خلف الـ Service
```

## لماذا يهم

الـ Services هي كيفية عمل الشبكة في Kubernetes، لذا فإن فهمها وفهم التسلسل الهرمي لأنواعها معرفةٌ يومية ضرورية. ولأن الـ Pods عابرة وتحصل على عناوين IP جديدة عند كل إعادة إنشاء، لا يمكنك توجيه العملاء إلى عناوين IP الخاصة بالـ Pods مباشرةً؛ يحلّ الـ **Service** هذا بتوفير **عنوان IP افتراضي واسم DNS ثابتين** أمام مجموعة من الـ Pods مُختارة عبر الـ labels، وبـ**موازنة الحِمل** لحركة المرور عبر الـ Pods الجاهزة (Ready) فقط. تشكّل الأنواع الثلاثة تدرّجاً متعدّد الطبقات: يمنح **ClusterIP** (الافتراضي) عنواناً داخلياً فقط للتواصل بين الـ Pods وبين الخدمات وهو حجر البناء الأساسي؛ ويفتح **NodePort** منفذاً ثابتاً على كل عقدة كي تصل حركة المرور الخارجية إلى الـ Service؛ ويذهب **LoadBalancer** أبعد بتوفير موازن حِمل سحابي خارجي بعنوان IP عام — وكل نوع يُبنى على النوع الذي تحته. إن معرفة أيّها تختار — ClusterIP لحركة مرور الخدمات المصغّرة الداخلية، وNodePort للوصول الخارجي الأساسي أو البيئات المحليّة، وLoadBalancer لكشف نقطة نهاية عامة على سحابة (وفي الممارسة، Ingress أمام خدمات ClusterIP لتوجيه HTTP) — أمرٌ جوهري لتصميم كيفية تحادث المكوّنات فيما بينها ومع العالم الخارجي. ولأن كل workload حقيقي تقريباً يحتاج إلى اتصال ثابت وموازنة حِمل، فإن فهم الـ Services وأنواعها معرفةٌ أساسية في شبكات Kubernetes تظهر باستمرار في كلٍّ من التصميم وتصحيح الأخطاء.

لماذا توجد الـ Services

أنواع الـ Service الرئيسية الثلاثة

ClusterIP (داخلي)

NodePort وLoadBalancer

لماذا يهم

أسئلة ذات صلة