Readiness و Liveness و Startup Probes: الـ pod جاهز ولا عايش؟

أهلًا بيك، وأهلًا بيك في آخر section في الـ course: الجاهزية للـ production. النهارده الـ health probes. بص على server dot naive dot js. endpoint واحد اسمه health، بيعمل query على Postgres، و ping على Redis، ولو الاتنين تمام يرجّع ok. وده بيستخدموه للـ liveness وللـ readiness مع بعض. وفيه catalog بيتحمّل في الـ memory لما الـ server يقوم. نفس الـ endpoint للـ liveness: لو الـ database وقعت أو علّقت، كل الـ pods هيفشلوا الـ liveness مع بعض، و Kubernetes يعمل restart لكلهم. والـ restart مش هيصلّح الـ database. الـ query من غير timeout: لو الـ database معلّقة، الـ probe معلّق، لحد ما الـ kubelet يقطعه. Redis هنا cache بس، والـ app يقدر يشتغل من غيره، بس لو وقع الـ pod بيتعلّم ميّت. كل probe بيعمل query، ولو عندك مِيّة pod و تلات probes كل كام second، ده load على الـ database من غير لازمة. الـ response بيطلّع الـ connection string. والـ server بيقول جاهز قبل ما الـ catalog يتحمّل.

Kubernetes عنده تلات probes، وكل واحد بيسأل سؤال مختلف، والرد على كل واحد بيعمل حاجة مختلفة. الـ startup probe: إنت خلّصت تقوم؟ لحد ما ينجح، الـ probes التانية مش بتشتغل. ده للـ apps اللي بتاخد وقت تقوم، زي تحميل cache أو migrations. الـ liveness probe: إنت عايش؟ لو فشل أكتر من مرة، Kubernetes يقتل الـ container ويعمله restart. الـ readiness probe: إنت جاهز تاخد traffic؟ لو فشل، الـ pod يتشال من الـ Service، يعني من الـ load balancer، بس ما بيتقتلش. ولما ينجح تاني، يرجع.

أهم قاعدة في الدرس كله: الـ liveness ما تبصّش على أي dependency. الـ liveness سؤاله: لو عملت restart للـ process ده، هيتصلّح؟ لو الـ database واقعة، الـ restart مش هيصلّحها. بالعكس، هيخلّي كل الـ pods يقوموا مع بعض، ويعملوا connect مع بعض، ويقصفوا الـ database اللي لسه بتحاول تقوم. ده اسمه cascading failure، وده سبب outages كتير قوي مشهورة. فالـ liveness بتفشل في حاجة واحدة: الـ process نفسه بايز بطريقة الـ restart بيصلّحها. زي deadlock، أو loop داخلية وقفت، أو memory leak خلّاه مش بيرد. وأبسط liveness: الـ HTTP server بيرد. لو الـ event loop واقف خالص، مش هيرد، والـ probe هيعمل timeout، وده كفاية.

الـ readiness بقى هي اللي بتبص على الـ dependencies، بس بعقل. مش كل dependency زي التانية. الـ critical: من غيرها الـ pod مش هيعرف يخدم ولا request، زي الـ database الأساسية. لو واقعة، readiness بـ خمسمية وتلاتة. الـ non critical: زي Redis اللي شغّال cache بس. لو واقع، الـ pod يقدر يخدم من الـ database، أبطأ شوية، بس شغّال. فالـ readiness ترجع ميتين، وفي الـ body تقول degraded، وفيه أسماء اللي واقعين، عشان الـ dashboard والـ alerts تشوفهم. وخلّي بالك: لو الـ dependency دي مشتركة بين كل الـ pods، ووقعت، وخلّيت الـ readiness تفشل، كل الـ pods هتتشال مع بعض، والـ Service هيبقى فاضي، والـ users هيشوفوا خمسمية وتلاتة من الـ load balancer بدل ما يشوفوا صفحة error لطيفة. عشان كده فكّر كويس قبل ما تحط dependency critical.

والـ readiness بتفشل كمان في تلات حالات مالهاش علاقة بالـ dependencies. starting: الـ pod لسه بيسخّن، بيحمّل الـ catalog، أو بيعمل connect للـ pool. لحد ما يقول markStarted، مش جاهز. draining: الـ pod جاله SIGTERM وهو بيقفل. أول حاجة يعملها إنه يخلّي الـ readiness خمسمية وتلاتة، عشان الـ load balancer يبطّل يبعتله requests جديدة، وهو يخلّص اللي في إيده. وده هنشرحه بالتفصيل في درس الـ graceful shutdown. overloaded: الـ event loop متأخر. لو الـ lag أكبر من حد معيّن، يعني الـ pod مخنوق، فنقول للـ load balancer: ابعت لغيري شوية. ولما الـ lag ينزل، يرجع لوحده.

الـ event loop lag بنقيسه إزاي؟ بنعمل setInterval كل مِيّة ms. كل مرة بنحسب: المفروض أشتغل إمتى، واشتغلت إمتى فعلًا. الفرق ده هو الـ lag. لو فيه request تقيل قفل الـ event loop نص second، الـ interval هيتأخر نص second، فالـ lag هيبقى خمسمية. وبنخلّي الـ samples في window، يعني آخر اتنين second كده، وناخد أكبر قيمة. ليه أكبر قيمة؟ لأن الـ probe بيسأل كل كام second، ولو سأل بعد ما البلوك خلص، المتوسط هيبان كويس وإحنا لسه في مشكلة. وبعد ما الـ window يعدّي، الـ samples القديمة تتمسح، والـ readiness ترجع ميتين.

الـ startup probe. زمان كانوا بيحطّوا initialDelaySeconds كبير على الـ liveness، يعني استنّى ستين second قبل أول probe. المشكلة: لو الـ app قام في خمس second، إنت مستني على الفاضي. ولو قام في سبعين مرة، الـ liveness هيقتله وهو بيقوم، ويدخل في restart loop. الـ startup probe بيحل ده. Kubernetes يسأل كل periodSeconds، ويستحمل لحد failureThreshold مرة. يعني failureThreshold تلاتين و periodSeconds اتنين يبقى أقصى وقت للقيام دقيقة. أول ما ينجح، الـ liveness والـ readiness يبدأوا. فالـ app اللي بيقوم بسرعة بيبدأ بسرعة، والبطيء بياخد وقته من غير ما يتقتل.

الغلطة الكبيرة في الـ naive: كل probe بيعمل query للـ database. تخيّل عندك تلاتين pod، وكل pod عليه kubelet بيسأل كل خمس second، وكمان الـ load balancer بيسأل، والـ monitoring بيسأل. ده سيل queries على الفاضي. والأسوأ: لو الـ database بطيئة، الـ probe بيستنى، ويعمل timeout، والـ pod يتشال، مع إن الـ pod نفسه كويس. الحل: الـ checks تشتغل في الـ background كل interval، كل check بـ timeout خاص بيه، والنتيجة تتخزّن في الـ memory. والـ probe بيقرا الـ state المتخزّن بس. يعني خمسين probe ورا بعض، ومفيش ولا query زيادة. والـ probe بيرد في أقل من ms. والـ timeout مهم قوي. لو فيه check واحد معلّق، زي search service مش بترد خالص، من غير timeout الـ Promise.all هيفضل مستني للأبد، والـ state مش هيتغيّر. فبنعمل withTimeout بـ Promise.race بين الـ check و timer، واللي يخلص الأول يكسب. ولو الـ timer كسب، الـ error اسمه TIMEOUT. ولازم نعمل clearTimeout في الـ finally، عشان ما نسيبش timers كتير شغّالة. وكمان: الـ check ممكن يعمل throw على طول، مش reject. فبنلفّه في new Promise جوّاها try، عشان الـ throw يبقى failure عادي مش crash للـ health كله.

وخلّي بالك من الـ body. الـ naive كان بيرجّع الـ error message كامل، وفيه الـ connection string بالـ password. والـ health endpoint ده ساعات بيبقى مفتوح للـ internet من غير auth. فالـ body فيه حاجات بسيطة بس: اسم الـ check، healthy، critical، الـ latency، والـ error code زي ECONNREFUSED أو TIMEOUT. من غير stack ومن غير messages ومن غير versions حسّاسة. وكمان header اسمه cache-control بـ no-store، عشان ما فيش proxy يعمل cache للرد ويقول للـ load balancer إن الـ pod كويس وهو واقع.

الـ hysteresis. الـ network بيهنّج. packet واحدة اتأخرت، والـ check فشل مرة. لو بنشيل الـ pod من أول failure، ونرجّعه من أول نجاح، الـ pod هيفضل داخل خارج، داخل خارج، وده اسمه flapping. والـ load balancer كل مرة بيعيد توزيع الـ connections. فبنعد: الـ check يبقى unhealthy بعد failureThreshold فشل ورا بعض، تلاتة يعني. ويرجع healthy بعد successThreshold نجاح ورا بعض، اتنين يعني. أي نجاح في النص بيصفّر عدّاد الفشل، وأي فشل بيصفّر عدّاد النجاح. وأول مرة خالص، قبل ما يكون عندنا أي تاريخ، بناخد النتيجة على طول.

Watchdogs. قلنا الـ liveness ما تبصّش على dependencies. بس فيه حاجة الـ HTTP server مش هيكشفها: الـ job loop. تخيّل worker بياخد jobs من queue في loop. الـ loop علّق على await مش هيخلص، أو حصل exception وقف الـ loop. الـ HTTP server لسه بيرد عادي، بس الـ process مش بيعمل شغله. والـ restart هيصلّح ده. فالـ loop كل لفّة يعمل heartbeat. والـ liveness يبص: آخر heartbeat من إمتى؟ لو أكتر من الحد، يرجّع خمسمية وتلاتة واسم الـ loop اللي واقف في stale. و Kubernetes يعمل restart. وخلّي الحد ده أكبر بكتير من أطول job عادي، عشان ما تقتلش worker شغّال على job كبير.

إعدادات الـ probes في Kubernetes. periodSeconds: كل قد إيه يسأل، عشرة يعني. timeoutSeconds: يستنى الرد قد إيه، واحد أو اتنين. وعشان الـ probe بتاعنا بيقرا من الـ memory، الرد بيبقى فوري. failureThreshold: كام فشل ورا بعض قبل ما يعمل حاجة. successThreshold: كام نجاح عشان يرجع، وده للـ readiness بس، لأن الـ liveness لازم يبقى واحد. ونصيحة: خلّي الـ liveness متسامح أكتر من الـ readiness. يعني failureThreshold للـ liveness أكبر، عشان الـ pod يتشال من الـ traffic الأول، ويدّي نفسه فرصة يتعافى، وما يتقتلش إلا لو فعلًا مش هيرجع.

والـ readiness في الـ rolling update. لما بتعمل deploy، Kubernetes بيقوّم pod جديد، ومستني الـ readiness بتاعه تنجح، وبعدين يشيل pod قديم. ولو الـ pod الجديد ما بقاش ready أبدًا، الـ rollout بيقف، والقديم فاضل شغّال. يعني الـ readiness الصح بتحميك من deploy بايز. والإعداد اللي بيتحكّم في ده: maxUnavailable و maxSurge. maxUnavailable بصفر، و maxSurge بواحد، يعني دايمًا عندك العدد الكامل جاهز، والجديد بيدخل الأول. وكمان minReadySeconds: الـ pod يفضل ready كام second قبل ما Kubernetes يعتبره متاح، عشان لو بيقع بعد ما يقوم بشوية، يتمسك. التحدي. عندك lab dot js بيشغّل pod حقيقي بـ Postgres و Redis، وبيعمل probes زي الـ kubelet، و test dot js. والمطلوب health dot js. كل التفاصيل في الكومنت: withTimeout، و pgCheck و redisCheck، و createHealth بالـ checks في الـ background، والـ hysteresis، والـ watchdogs، والـ event loop lag، و markStarted و setDraining، والـ handler بالتلات paths. اقرا الكومنت كويس، ونشغّل test dot js لحد ما تبقى أربعتاشر من أربعتاشر.

الحل. withTimeout: race بين الـ promise و timer، و clearTimeout في الـ finally. كل check ليه state: healthy وعدّاد فشل وعدّاد نجاح وآخر error code. الـ runCheck بيلف الـ run في new Promise عشان الـ throw العادي يبقى failure. الـ hysteresis في سطرين: يقلب لـ false بس لو كان true والفشل وصل الحد، والعكس. الـ liveness بيبص على الـ watchdogs بس. والـ readiness بالترتيب: starting، بعدين draining، بعدين الـ critical، بعدين الـ lag، وفي الآخر degraded أو ok. والـ handler بيقرا الـ state بس، ومفيش ولا query. نشغّل lab dot js.

// health.js: startup و liveness و readiness probes صح: checks في الـ background بـ timeouts و hysteresis، و watchdogs، و event loop lag، و draining
// lab.js و test.js بيعملوا import من هنا: withTimeout و createHealth و pgCheck و redisCheck
export function withTimeout(promise, ms) {
  let timer;
  const timeout = new Promise((_, reject) => {
    timer = setTimeout(() => reject(Object.assign(new Error("TIMEOUT"), { code: "TIMEOUT" })), ms);
  });
  return Promise.race([Promise.resolve(promise), timeout]).finally(() => clearTimeout(timer));
}

export const pgCheck = (pool, { name = "postgres", timeoutMs = 1000 } = {}) => ({ name, critical: true, timeoutMs, run: () => pool.query("select 1") });
export const redisCheck = (redis, { name = "redis", critical = false, timeoutMs = 500 } = {}) => ({ name, critical, timeoutMs, run: () => redis.ping() });

export function createHealth({ checks = [], failureThreshold = 3, successThreshold = 2, maxLagMs = 500, lagWindowMs = 2000, watchdogs = {}, now = Date.now } = {}) {
  const state = new Map(checks.map((c) => [c.name, { healthy: null, consecutiveFailures: 0, consecutiveSuccesses: 0, lastError: null, latencyMs: null, runs: 0 }]));
  const beats = new Map(Object.keys(watchdogs).map((n) => [n, now()]));
  let started = false, draining = false, timer = null, lagTimer = null;
  let lagSamples = [];

  async function runCheck(c) {
    const s = state.get(c.name);
    const t0 = performance.now();
    s.runs++;
    try {
      await withTimeout(new Promise((resolve, reject) => { try { resolve(c.run()); } catch (e) { reject(e); } }), c.timeoutMs ?? 1000);
      s.consecutiveSuccesses++;
      s.consecutiveFailures = 0;
      s.lastError = null;
      if (s.healthy === null || (!s.healthy && s.consecutiveSuccesses >= successThreshold)) s.healthy = true;
    } catch (e) {
      s.consecutiveFailures++;
      s.consecutiveSuccesses = 0;
      s.lastError = e.code ?? e.message;
      if (s.healthy === null || (s.healthy && s.consecutiveFailures >= failureThreshold)) s.healthy = false;
    }
    s.latencyMs = Math.round(performance.now() - t0);
  }

  const runOnce = () => Promise.all(checks.map(runCheck));

  function lagMs() {
    const cutoff = performance.now() - lagWindowMs;
    lagSamples = lagSamples.filter((x) => x.at >= cutoff);
    return lagSamples.reduce((m, x) => Math.max(m, x.lag), 0);
  }

  function start({ intervalMs = 1000, lagIntervalMs = 100 } = {}) {
    stop();
    runOnce();
    timer = setInterval(runOnce, intervalMs);
    let expected = performance.now() + lagIntervalMs;
    lagTimer = setInterval(() => {
      const t = performance.now();
      lagSamples.push({ at: t, lag: Math.max(0, t - expected) });
      expected = t + lagIntervalMs;
    }, lagIntervalMs);
    timer.unref?.();
    lagTimer.unref?.();
  }

  function stop() {
    clearInterval(timer);
    clearInterval(lagTimer);
    timer = lagTimer = null;
  }

  const heartbeat = (name) => beats.set(name, now());
  const markStarted = ()
…

$ node lab.js
① الـ pod لسه بيحمّل الـ catalog:
   warming up                         startup 503 | live 200 ok   | ready 503 starting
   الـ catalog اتحمّل                 startup 200 | live 200 ok   | ready 200 ok

② Redis وقع (cache بس):
   redis down                         startup 200 | live 200 ok   | ready 200 degraded
   redis رجع                          startup 200 | live 200 ok   | ready 200 ok

③ payments-db بتفصل:
   payments-db down                   startup 200 | live 200 ok   | ready 503 fail
   payments-db رجعت                   startup 200 | live 200 ok   | ready 200 ok

④ request تقيل قفل الـ event loop:
   بعد البلوك                         startup 200 | live 200 ok   | ready 503 overloaded
   بعد البلوك                         startup 200 | live 200 ok   | ready 200 ok

⑤ الـ job loop علّق:
   مفيش heartbeat                     startup 200 | live 503 fail | ready 200 ok

⑥ SIGTERM ← draining:
   draining                           startup 200 | live 200 ok   | ready 503 draining

الأول: الـ pod لسه بيسخّن، فالـ startup والـ readiness خمسمية وتلاتة، والـ liveness ميتين. وبعد ما الـ catalog اتحمّل، كله ميتين. التاني: Redis وقع، والـ readiness فضلت ميتين بس degraded، يعني الـ pod لسه بياخد traffic. التالت: payments-db فصلت، وبعد كام check ورا بعض الـ readiness بقت fail، والـ liveness فضلت ميتين، فمفيش restart. ولما رجعت، استنّت نجاحين. الرابع: البلوك خلّى الـ readiness overloaded لحد ما الـ window عدّى. الخامس: الـ job loop وقف، والـ liveness بقت خمسمية وتلاتة، وده الوقت الوحيد اللي الـ restart بيصلّح فيه. والسادس: draining. ونشغّل test dot js.