اختبار الوحدة: التشغيل في الإنتاج

السؤال 1 من 5

• تُعاد تشغيل كل الـ Pods مرارًا حتى يعود Postgres.
• يعيد Kubernetes جدولة الـ Pods على nodes أخرى.
• تصبح كل الـ Pods غير جاهزة وتغادر endpoints الـ Service؛ ثم تعود دون إعادة تشغيل حين يعود Postgres.
• لا شيء، لأن الـ probes تتوقّف مؤقتًا حين تتعطّل اعتمادية.

السؤال 2 من 5

• يُجدوَل هناك، لأن الاستهلاك الفعلي منخفض.
• يُجدوَل هناك وتُخنق Pods أخرى لإفساح المجال.
• يُجدوَل بـ request مخفّض إلى 200m.
• لا يُجدوَل على ذلك الـ node، لأنه لم يتبقَّ إلا 200m من المعالج القابل للطلب؛ فيذهب إلى مكان آخر أو يبقى Pending.

السؤال 3 من 5

• يحصل المستخدمون على أخطاء من Pod الإصدار 1.6.0.
• ما زالت Pods الإصدار 1.5.x القديمة تخدم بكامل السعة؛ والـ rollout عالق ويحتاج إلى undo أو إصلاح.
• تراجع Kubernetes فعلًا إلى الإصدار السابق.
• تقلّص الـ Deployment إلى صفر.

السؤال 4 من 5

• الحقل allowedRoutes في listener الـ Gateway لا يسمح بـ routes من الـ namespace ‏notes.
• الـ Service الخاص بـ notes-api ليس له endpoints.
• الـ HTTPRoute يستخدم apiVersion: gateway.networking.k8s.io/v1.
• الـ Pods تفتقر إلى readiness probe.

السؤال 5 من 5

• kubectl logs <pod> --previous
• ‏kubectl port-forward pod/<pod> 3000:3000 يليه kubectl events
• ‏kubectl debug -it <pod> --image=busybox:1.37 --target=api، ثم wget -qO- localhost:3000/healthz
• kubectl describe node