Kubernetes من الأول: Pods و Deployments و Services و Probes

أهلًا بيك. لحد دلوقتي كنا بنشغّل الـ containers على server واحد بـ compose. طب لو عندك عشرين service، وكل واحدة تلات نسخ، على عشر servers؟ مين يقرّر كل container يروح فين؟ ولو server وقع، مين يشغّل اللي كان عليه في حتة تانية؟ ده دور Kubernetes. والفكرة الأساسية فيه اسمها desired state: انت مش بتقوله اعمل دي وبعدين دي، انت بتكتبله الحالة اللي عايزها، تلات نسخ من الـ image دي، وهو جُوّاه loop بتلف على طول، اسمها reconcile loop، بتقارن اللي موجود باللي انت عايزه وتصلّح الفرق. بص على k8s slash naive dot yaml.

قبل ما نشوف المشاكل، الكلمات اللي هتسمعها كل يوم. فين المشاكل في الـ naive؟ الـ selector بتاع الـ Deployment بيدوّر على app api، والـ template label هو app shop-api. الـ API server هيرفض ده أصلًا. والـ Service كمان بيدوّر على app api، يعني لو صلّحت الـ template لـ shop-api، الـ Service هيفضل مش لاقي حد، والـ requests هتروح مكان مفيهوش حد. replica واحدة: أي restart أو node بيتعمله maintenance، يبقى downtime. latest، اتكلمنا عنه في الدرس اللي فات. مفيش requests: الـ scheduler مش عارف الـ Pod محتاج قد إيه، فممكن يحط عشرة على node مش شايلة. ومفيش memory limit: memory leak واحد يقدر ياكل الـ node كلها. ومفيش readinessProbe: الـ Pod بياخد traffic أول ما الـ container يقوم، حتى لو لسه بيحمّل. والـ targetPort اسمه http، والـ container port مالوش اسم أصلًا.

الـ manifest الصح، k8s slash api dot yaml. تلات replicas، والـ selector والـ labels متطابقين. الـ image بالـ digest. الـ port ليه اسم، http، والـ probes والـ Service بيستخدموا الاسم، فلو الرقم اتغير، بتغيّره في حتة واحدة. الـ DATABASE_URL جاي من Secret، مش مكتوب في الـ yaml. requests: ربع core وميتين وستة وخمسين Mi. و limit للـ memory بس، هنعرف ليه حالًا. وتلات probes، ده أهم جزء في الدرس.

التلات probes، وكل واحد بيسأل سؤال مختلف. الـ liveness بيسأل: الـ process دي لسه عايشة ولا اتقفلت في deadlock؟ لو فشل، الـ kubelet بيعمل restart للـ container. علشان كده لازم يبقى غبي وسريع: الـ event loop شغّال؟ يبقى تمام. ما يسألش الـ database أبدًا. لأن لو الـ database وقعت، كل الـ Pods هتفشل في نفس الوقت، وكلهم هيتعملهم restart مع بعض، والـ restart مش هيصلّح الـ database، بالعكس، هيضيف ضغط وهي راجعة. الـ readiness بيسأل: ينفع أبعتلك traffic دلوقتي؟ هنا تسأل الـ dependencies المهمة، وتقول لأ وانت لسه بتعمل warm up. لو فشل، الـ Pod بيطلع من الـ Service endpoints بس، من غير restart. والـ startup بيسأل: خلّصت تقوم ولا لسه؟ ولحد ما ينجح، الـ liveness والـ readiness مش بيشتغلوا. ده بيحمي الـ app اللي بتاخد وقت تقوم من إن الـ liveness يقتلها.

الـ requests والـ limits. الـ request هو اللي الـ scheduler بيحسب بيه. الـ Pod ده محتاج ربع core، يبقى يتحط على node فيها ربع core فاضي. وده كمان اللي بتاخده مضمون وقت الزحمة. الـ limit هو السقف. والفرق المهم: الـ memory لو عدّت الـ limit، الـ container بيتقتل، OOMKilled. الـ cpu لو عدّت الـ limit، الـ container مش بيتقتل، بيتعمله throttling، يعني بيبطّأ. وده بيبان كـ latency عالية من غير سبب واضح. علشان كده ناس كتير بتحط limit للـ memory بس، وتسيب الـ cpu يستلف من الفاضي. ومن الـ requests والـ limits بيطلع الـ QoS class: Guaranteed لو الـ requests قد الـ limits بالضبط، و Burstable لو فيه requests بس مش متطابقة، و BestEffort لو مفيش خالص. ولما الـ node تزنق في الـ memory، الـ BestEffort هو أول واحد بيتطرد.

الـ rolling update. لما تغيّر الـ image، الـ Deployment بيعمل ReplicaSet جديد، ويبدّل الـ Pods شوية بشوية. وفيه رقمين بيتحكموا في السرعة: maxSurge: كام Pod زيادة عن العدد مسموح يبقوا موجودين في نفس الوقت. maxUnavailable: كام Pod مسموح يبقوا مش متاحين. عندنا surge واحد و unavailable صفر: يعني يعمل Pod جديد، يستنى لحد ما يبقى Ready، وبعدين بس يشيل واحد قديم. وخلّي بالك إن Ready هنا معناها الـ readiness probe نجح. فلو الـ image الجديدة فيها مشكلة والـ readiness بيفشل، الـ rollout بيقف لوحده، والقديم فاضل شغّال. يعني الـ readiness probe هو كمان أول خط دفاع في الـ deploy. والنسب: الـ surge بيتقرّب لفوق، والـ unavailable لتحت. والاتنين صفر مش مسموح، لأنه مش هيقدر يتحرك. والأوامر اللي هتكتبها كل يوم، في kubectl dot sh. مش هنشغّلها هنا، مفيش cluster في البيئة دي. get pods بـ dash l علشان الـ label، وبص على عمود RESTARTS. رقم بيزيد يعني فيه حاجة غلط. describe بيوريك الـ Events: probe فشل، OOMKilled، ImagePullBackOff. logs dash dash previous: دي اللي هتطلّعك من المشكلة، لأنها logs الـ container اللي مات، مش الجديد. rollout status بيستنى الـ rolling update، وده اللي الـ CI بيستخدمه، و rollout undo هو الـ rollback. و endpointslices بيقولك الـ Service بيبعت لمين فعلًا. لو فاضية، يبقى الـ selector غلط أو مفيش Pod Ready.

التحدي. عندك lab dot js، ده kubelet صغير: بيشغّل app حقيقية على loopback، وبيعمل probes حقيقية بـ HTTP كل خمسين ms، ولو الـ liveness فشل بيقفلها ويشغّلها تاني. والوقت مضغوط، الـ tick بدل عشر تواني. وعندك الـ manifests كـ JS objects في manifests dot js و manifests dot naive dot js. والمطلوب k8s dot js. كل التفاصيل في الكومنت: parse للـ cpu والـ memory، والـ QoS، و runProbe زي الـ kubelet بالضبط، والـ budget بتاع الـ boot، والـ rolling update خطوة خطوة، والـ endpoints، و lint بتسع rules. اقرا الكومنت كويس، وخصوصًا ترتيب الخطوات في الـ simulateRollout، ونشغّل test dot js لحد ما تبقى أربعتاشر من أربعتاشر.

الحل. الـ parse: regex واحدة لكل نوع، وجدول للـ units. الـ QoS: merge للـ limits وبعدين الـ requests، وبعدين نقارن بعد الـ parse، علشان ألف m هي هي واحد core. runProbe: عدّادين، كل نتيجة بتزوّد واحد وتصفّر التاني. simulateRollout: التلات خطوات بالترتيب، ولو الـ state ما اتغيرش، يبقى الـ rollout واقف. والـ lint: الـ Service بيدوّر في كل الـ Deployments، مش اللي قبله بس، لأن ترتيب الـ docs في الملف مش مهم لـ Kubernetes. نشغّل lab dot js. هياخد كام تانية، لأن الـ probes حقيقية.

// k8s.js: الـ quantities والـ QoS، والـ probes، والـ rolling update، والـ Service endpoints، و lint للـ manifests
const CPU = /^(\d+(?:\.\d+)?)(m?)$/;
const MEM = /^(\d+(?:\.\d+)?)(Ki|Mi|Gi|Ti|k|M|G|T)?$/;
const UNITS = { Ki: 2 ** 10, Mi: 2 ** 20, Gi: 2 ** 30, Ti: 2 ** 40, k: 1e3, M: 1e6, G: 1e9, T: 1e12 };

export function parseCpu(q) {
  const m = CPU.exec(String(q).trim());
  if (!m) throw new Error(`cpu مش مفهوم: ${q}`);
  return m[2] === "m" ? Number(m[1]) / 1000 : Number(m[1]);
}

export function parseMemory(q) {
  const m = MEM.exec(String(q).trim());
  if (!m) throw new Error(`memory مش مفهومة: ${q}`);
  return Math.round(Number(m[1]) * (m[2] ? UNITS[m[2]] : 1));
}

export function qosClass(containers) {
  const res = containers.map((c) => c.resources ?? {});
  const none = res.every((r) => !Object.keys(r.requests ?? {}).length && !Object.keys(r.limits ?? {}).length);
  if (none) return "BestEffort";
  const guaranteed = res.every((r) => {
    const req = { ...(r.limits ?? {}), ...(r.requests ?? {}) };
    const lim = r.limits ?? {};
    return ["cpu", "memory"].every((k) => lim[k] != null && req[k] != null &&
      (k === "cpu" ? parseCpu(lim[k]) === parseCpu(req[k]) : parseMemory(lim[k]) === parseMemory(req[k])));
  });
  return guaranteed ? "Guaranteed" : "Burstable";
}

export function runProbe(probe, results, initial) {
  const fail = probe.failureThreshold ?? 3, succ = probe.successThreshold ?? 1;
  let state = initial, fails = 0, oks = 0;
  return results.map((r) => {
    if (r) { oks++; fails = 0; if (oks >= succ) state = true; }
    else { fails++; oks = 0; if (fails >= fail) state = false; }
    return state;
  });
}

export function probeBudget(probe) {
  return (probe.initialDelaySeconds ?? 0) + (probe.periodSeconds ?? 10) * (probe.failureThreshold ?? 3);
}

export function killedDuringBoot(container, bootSeconds) {
  const p = container.startupProbe ?? container.livenessProbe;
  if (!p) return false;
  return bootSeconds > probeBudget(p);
}

function resolve(v, replicas, roundUp) {
  if (typeof v === "string" && v.endsWith("%")) {
    const x = (Number(v.slice(0, -1)) * replicas) / 100;
    return roundUp ? Math.ceil(x) : Math.floor(x);
  }
  return Number(v);
}

export function rollingPlan(replicas, { maxSurge = "25%", maxUnavailable = "25%" } = {}) {
  const surge = resolve(maxSurge, replicas, true);
  const unavailable = resolve(maxUnavailable, replicas, false);
  if (surge === 0 && unavailable === 0) throw new Error("maxSurge و maxUnavailable مينفعش الاتنين صفر");
  return { surge, unavailable, maxPods: replicas + surge, minAvailable: replicas - unavailable };
}

export function simulateRollout(replicas, strategy, { healthy = true, maxTicks = 1000 } = {}) {
  const { maxPods, minAvailable } = rollingPlan(replicas, strategy);
  let old = replicas, ready = 0, pending = 0;
  const steps = [];
  for (let t = 0; t < maxTicks; t++) {
    const before = `${old},${ready},${pending}`;
    if (healthy) { ready += pending; pending 
…

$ node lab.js
— الـ timeline: R يعني Ready وبيستقبل traffic، والـ dot يعني لسه، و X يعني الـ kubelet عمل restart، و _ يعني الـ database واقعة —

الـ boot تلتمية ms، و liveness من غير startupProbe (بيستحمل تلات ticks بس):
  ..X..X..X..X..X..X..X..X..X..X..X..X..X. ← restarts: 13
نفس الـ app ومعاه startupProbe (بيستحمل عشرين tick):
  ......RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR ← restarts: 0
  killedDuringBoot بالأرقام الحقيقية، app بتاخد خمسة وأربعين ثانية: true من غير startup، و false معاه

الـ database وقعت من tick اتناشر لحد ستة وعشرين، والـ liveness بيسأل readyz (يعني بيسأل الـ database):
  ..RRRRRRRRRRR_X____X____X_.RRRRRRRRRRRRR ← restarts: 3
الـ liveness بيسأل livez بس، والـ readiness هو اللي بيسأل الـ database:
  ..RRRRRRRRRRR_____________RRRRRRRRRRRRRR ← restarts: 0
  runProbe على نفس نتايج الـ liveness: عمره ما وقع 

rolling update لأربع replicas، maxSurge واحد و maxUnavailable صفر، image سليمة:
   old 4 / new 0+1  →  old 3 / new 1+1  →  old 2 / new 2+1  →  old 1 / new 3+1  →  old 0 / new 4+0 ← خلص
rolling update لأربع replicas، maxSurge واحد و maxUnavailable صفر، image الـ readiness بتاعها فاشل:
   old 4 / new 0+1 ← واقف، والقديم لسه شغّال

الـ endpoints بتاعة Service api: 10
…

أول سطر: الـ app بتاخد تلتمية ms تقوم، والـ liveness بيستحمل تلات فشلات بس. فبيقتلها قبل ما تخلص، وتقوم تاني، ويقتلها تاني. ده الـ CrashLoopBackOff المشهور، والـ app نفسها سليمة. السطر التاني: نفس الـ app ومعاها startupProbe بعشرين فرصة. قامت، و Ready، وصفر restarts. وبالأرقام الحقيقية: app بتاخد خمسة وأربعين تانية، والـ liveness من غير startup بيستحمل تلاتين بس. بعدها الـ database وقعت. لما الـ liveness بيسأل readyz، كل شوية X: restarts على الفاضي، والـ app بتقوم تلاقي الـ database لسه واقعة. ولو عندك عشرين Pod، العشرين بيعملوا كده مع بعض. ولما الـ liveness بيسأل livez بس: الـ Pod طلع من الـ traffic وقت الـ outage، وأول ما الـ database رجعت، رجع Ready لوحده، من غير ولا restart. الـ rolling update السليم: واحد جديد، وبعدين واحد قديم يتشال، لحد ما خلص. والفاشل: وقف عند أول Pod، والأربعة القدام لسه شغّالين. والـ endpoints فيها api-a بس. والـ lint مسك السبع مشاكل في الـ naive. ونشغّل test dot js.

$ node test.js
✅ parseCpu: millicores و cores و كسور 
✅ parseMemory: Mi و Gi بـ ألف وأربعة وعشرين، و M بـ ألف، و bytes 
✅ qosClass: BestEffort و Burstable و Guaranteed 
✅ qosClass: limits من غير requests تبقى Guaranteed، وأي container ناقص يخلّيها Burstable 
✅ runProbe: failureThreshold متتالية بس، و successThreshold 
✅ runProbe: الـ defaults تلاتة وواحد 
✅ probeBudget و killedDuringBoot 
✅ rollingPlan: الـ surge بيتقرّب لفوق والـ unavailable لتحت 
✅ simulateRollout: واحدة واحدة، ومفيش أقل من أربعة available أبدًا 
✅ simulateRollout: الـ new مش Ready ← بيقف، والقديم فاضل على الـ minAvailable 
✅ matches و endpointsFor: Ready بس، والـ labels، والـ named port 
✅ lintManifests: naive فيه السبع مشاكل بالترتيب 
✅ lintManifests: من غير tag، و liveness زي readiness، و targetPort مش معروف 
✅ lintManifests: الـ Service قبل الـ Deployment في الملف عادي، و targetPort رقم مش بيتشيك 

14/14

كله نجح، وكده خلّصنا Docker والنشر. من الدرس الجاي بنبدأ جزء جديد: الـ distributed systems والتكاملات. وأول سؤال فيه: لازم microservices أصلًا؟ الدرس الجاي عن الـ modular monolith و Domain Driven Design: إزاي تقسّم الـ code لـ modules ليها حدود واضحة، وكل module بيكلّم التاني من interface بس، من غير ما تدفع تمن الـ network.

# k8s/naive.yaml: أول محاولة
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 1
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: shop-api
    spec:
      containers:
        - name: api
          image: "ghcr.io/shop/api:latest"
          ports:
            - containerPort: 3000
          livenessProbe:
            httpGet:
              path: /health
              port: 3000
            periodSeconds: 5
            failureThreshold: 3
---
apiVersion: v1
kind: Service
metadata:
  name: api
spec:
  selector:
    app: api
  ports:
    - port: 80
      targetPort: http

# k8s/api.yaml: Deployment و Service جاهزين للـ production
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
  labels:
    app: api
spec:
  replicas: 3
  revisionHistoryLimit: 5
  selector:
    matchLabels:
      app: api
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    metadata:
      labels:
        app: api
        version: "1.6.1"
    spec:
      terminationGracePeriodSeconds: 30
      containers:
        - name: api
          image: "ghcr.io/shop/api@sha256:4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f4f"
          ports:
            - name: http
              containerPort: 3000
          env:
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef:
                  name: api-secrets
                  key: database-url
          resources:
            requests:
              cpu: 250m
              memory: 256Mi
            limits:
              memory: 512Mi
          startupProbe:
            httpGet:
              path: /livez
              port: http
            periodSeconds: 2
            failureThreshold: 30
          livenessProbe:
            httpGet:
              path: /livez
              port: http
            periodSeconds: 10
            timeoutSeconds: 2
            failureThreshold: 3
          readinessProbe:
            httpGet:
              path: /readyz
              port: http
            periodSeconds: 5
            timeoutSeconds: 2
            failureThreshold: 2
---
apiVersion: v1
kind: Service
metadata:
  name: api
spec:
  selector:
    app: api
  ports:
    - port: 80
      targetPort: http

# kubectl.sh: الأوامر اللي هتستخدمها كل يوم (مش بنشغّلها هنا، مفيش cluster في البيئة دي)
kubectl apply -f k8s/api.yaml                       # اعمل apply للـ desired state
kubectl get pods -l app=api -o wide                 # مين شغّال، و Ready ولا لأ، و RESTARTS كام، وعلى أنهي node
kubectl describe pod api-7d9f-x2k4q                 # الـ Events: probe فشل؟ OOMKilled؟ ImagePullBackOff؟
kubectl logs api-7d9f-x2k4q --previous              # logs الـ container اللي مات قبل الـ restart
kubectl rollout status deploy/api --timeout=5m      # استنى الـ rolling update يخلص، ولو وقف يرجّع error
kubectl rollout history deploy/api                  # الـ revisions
kubectl rollout undo deploy/api                     # rollback للـ revision اللي قبلها
kubectl get endpointslices -l kubernetes.io/service-name=api   # الـ Service بيبعت لمين فعلًا
kubectl port-forward svc/api 8080:80                # جرّب الـ Service من جهازك
kubectl exec -it api-7d9f-x2k4q -- sh               # ادخل جُوّه الـ container (للـ debugging بس)
kubectl top pods -l app=api                         # الـ cpu والـ memory الفعليين قصاد الـ requests
kubectl scale deploy/api --replicas=5               # مؤقتًا، الـ HPA أو الـ manifest هو اللي يكسب في الآخر