Services

الهدف من الدرس

ستتعلم لماذا نحتاج Service، وكيف تختار بين ClusterIP و NodePort و LoadBalancer، وكيف تشخص مشاكل selector و endpoints.

الفكرة ببساطة

Pods مؤقتة. Service يعطيك اسم DNS و IP ثابت داخل cluster، ثم يوجه traffic إلى Pods التي تطابق selector.

شكل الحركة

flowchart LR
  C[Client Pod] --> DNS[web.default.svc.cluster.local]
  DNS --> S[Service web]
  S --> E[EndpointSlices]
  E --> P1[Pod web-1]
  E --> P2[Pod web-2]

YAML كامل

استخدم Deployment من الدرس السابق، ثم أنشئ service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: web
  namespace: default
  labels:
    app: web
spec:
  type: ClusterIP
  selector:
    app: web
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: http

شرح سريع:

الجزء	المعنى
`type: ClusterIP`	Service داخلي داخل cluster
`selector.app: web`	يختار Pods التي عندها label `app=web`
`port`	المنفذ الذي يتصل به العميل على Service
`targetPort`	المنفذ داخل Pod أو اسم المنفذ

أنواع Service

النوع	متى أستخدمه؟
`ClusterIP`	اتصال داخلي بين التطبيقات داخل cluster
`NodePort`	تجربة محلية أو بيئة بسيطة بدون load balancer
`LoadBalancer`	تعريض خدمة مباشرة عبر cloud load balancer
`ExternalName`	اسم داخلي يشير إلى DNS خارجي

في Production غالبا تستخدم ClusterIP خلف Ingress أو Gateway، وليس NodePort مباشرة.

أوامر kubectl

kubectl apply -f deployment.yaml
kubectl apply -f service.yaml
kubectl get svc web
kubectl get endpoints web
kubectl get endpointslices -l kubernetes.io/service-name=web

Expected output:

NAME   TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
web    ClusterIP   10.96.120.10    <none>        80/TCP    20s

NAME   ENDPOINTS                         AGE
web    10.244.0.10:80,10.244.0.11:80     20s

اختبار Service من داخل cluster

kubectl run curl --rm -it --image=curlimages/curl:8.10.1 --restart=Never -- curl -s http://web

Expected output:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>

تشخيص مشاكل Service

flowchart TD
  A[Service لا يعمل] --> B{هل endpoints موجودة؟}
  B -->|لا| C[راجع selector و labels]
  B -->|نعم| D{هل port صحيح؟}
  D -->|لا| E[راجع port و targetPort]
  D -->|نعم| F[افحص التطبيق و NetworkPolicy]

المشكلة	أمر التشخيص	الحل
لا توجد endpoints	`kubectl get endpoints web`	طابق `selector` مع labels الخاصة بالـ Pods
connection refused	`kubectl describe svc web`	تأكد من `targetPort` والمنفذ داخل container
DNS لا يعمل	`kubectl exec` داخل Pod ثم `nslookup web`	افحص CoreDNS و namespace
يعمل داخليا ولا يعمل خارجيا	`kubectl get ingress` أو `kubectl get gateway`	راجع Ingress/Gateway وليس Service فقط

Lab: Service داخلي لتطبيق web

المستوى: مبتدئ الوقت: 35 دقيقة الأدوات: kubectl

الهدف: إنشاء Service يوجه traffic إلى Deployment، ثم اختبار الاتصال من Pod مؤقت.

Prerequisites

Deployment باسم web يعمل بثلاث Pods.
labels في Pods تحتوي app: web.

Steps

احفظ YAML في service.yaml.
طبق Service:

kubectl apply -f service.yaml
kubectl get svc web

تأكد من endpoints:

kubectl get endpoints web

اختبر الاتصال:

kubectl run curl --rm -it --image=curlimages/curl:8.10.1 --restart=Never -- curl -s http://web

غيّر selector عمدا إلى app: wrong وطبق الملف، ثم راقب endpoints:

kubectl apply -f service.yaml
kubectl get endpoints web

أعد selector إلى app: web.

Expected output

قبل الخطأ:

web   10.244.0.10:80,10.244.0.11:80,10.244.0.12:80

بعد الخطأ:

web   <none>

Cleanup

kubectl delete -f service.yaml

الربط بالمشروع النهائي

في كل المشاريع ستستخدم Services داخلية بين frontend و backend و database. Ingress سيقف أمام frontend أو API، أما Service فسيظل طبقة التوجيه الداخلية.