الاختبار النهائي

اثنا عشر سؤالًا تغطي الدورة كلها. احصل على 70% أو أكثر لتنجح وتفتح شهادتك. يمكنك إعادته متى شئت.

أنهِ كل الدروس لتحصل على الشهادة، ويمكنك خوض الاختبار في أي وقت.

يريد مهندس في Skylane بناءً أسرع لـ notes-api في الـ CI. البناء يعمل على runners جديدة بـ cache فارغ لـ Docker، والـ Dockerfile مرتّب بشكل صحيح أصلًا. ما الذي يساعد أكثر؟

التحويل من npm ci إلى npm install.
تصدير الـ build cache واستيراده بـ --cache-to و--cache-from (مثلًا إلى registry).
البناء بـ --no-cache من أجل الاتّساق.
إضافة المزيد من خطوات RUN حتى توجد نقاط cache أكثر.

أي سطر في الـ Dockerfile يعرّض بيانات اعتماد للخطر رغم حذفها لاحقًا في البناء نفسه؟

RUN --mount=type=secret,id=npmrc,target=/root/.npmrc npm ci
COPY package.json package-lock.json ./
USER node
‏COPY .npmrc . يليه لاحقًا RUN rm .npmrc

الـ image الخاصة بـ notes-api تعمل بـ USER node، والـ securityContext في الـ Deployment يضبط runAsNonRoot: true. تفشل الـ Pods بـ CreateContainerConfigError. ما أنظف حل؟

اضبط مستخدمًا رقميًا، إمّا USER 1000 في الـ Dockerfile أو runAsUser: 1000 في الـ securityContext، حتى يستطيع الـ kubelet التحقّق من أنه ليس root.
احذف runAsNonRoot من الـ securityContext.
أعِد الـ image إلى التشغيل كـ root.
أضف allowPrivilegeEscalation: true.

بيئة Compose تبدأ بشكل موثوق على حاسوبك، لكن في الـ CI تعمل اختبارات التكامل أحيانًا قبل أن يجهز الـ API. أي تغيير يحلّ ذلك دون تخمين؟

أضف sleep 30 قبل الاختبارات.
استخدم restart: always على الـ API.
أعطِ الـ API وقاعدة البيانات healthchecks، وشغّل البيئة بـ docker compose up -d --wait.
انشر منفذ قاعدة البيانات حتى تستطيع الاختبارات استطلاعه.

ترث Deployment بلا readiness probe ومع إعدادات التحديث المتدرّج الافتراضية. يخرج إصدار فيه عنوان قاعدة بيانات معطوب. ماذا يحدث؟

يتوقّف الـ rollout وتستمر الـ Pods القديمة في الخدمة.
يكتشف Kubernetes العنوان المعطوب ويرفض الإصدار.
يُستبدل Pod واحد فقط، بسبب maxSurge.
تُعلَّم الـ Pods الجديدة جاهزة حالما تبدأ الـ containers الخاصة بها، فيستبدل الـ rollout كل Pod يعمل بآخر يفشل.

لدى notes-api ‏request للمعالج قدره 500m ولا حدّ للمعالج، وrequest وحدّ للذاكرة قدرهما 512Mi. تحت قفزة في الحركة يصل استهلاكه للمعالج إلى 1.5 نواة على node فيه سعة خاملة. ماذا يحدث؟

يُقتل بسبب نفاد الذاكرة لتجاوزه الـ request.
يستخدم المعالج الخامل، لأنه لا يوجد حدّ للمعالج يخنقه؛ والـ request الخاص به ما زال يضمن 500m عند التزاحم.
يُخنق إلى 500m.
ينقله الـ scheduler إلى node أكبر.

أي manifest صالح في Kubernetes الحالي؟

‏apiVersion: extensions/v1beta1 مع kind: Deployment
‏apiVersion: autoscaling/v1 مع HPA يستخدم metrics وbehavior
‏apiVersion: networking.k8s.io/v1beta1 مع kind: Ingress
‏apiVersion: apps/v1 مع kind: Deployment

أضاف notes-api 1.5.0 عمودًا، وكوده يكتب في العمودين القديم والجديد معًا. في 1.5.0 خلل، فتشغّل kubectl rollout undo. لماذا هذا التراجع آمن؟

لأن rollout undo يستعيد لقطة من قاعدة البيانات.
لأن تغيير المخطّط كان إضافيًا، فما زال 1.4.0 يجد كل ما يتوقّعه.
لأن Postgres يتجاهل الأعمدة المجهولة في جمل UPDATE.
لأن التراجع آمن دائمًا في Kubernetes.

الـ HPA الخاص بـ notes-api يستهدف استخدامًا للمعالج بنسبة 60% مع request للمعالج قدره 200m. أربعة Pods يبلغ متوسط كل منها 240m. كم نسخة تقريبًا سيريد الـ HPA؟

4، لأن الـ HPA لا يوسّع إلا حين يتجاوز الاستهلاك الـ request.
5
8
2، لأنه يأخذ متوسط الـ request والاستهلاك.

الـ controller ‏ingress-nginx الذي كان الـ cluster لديك يستخدمه تقاعد ولم يعد يتلقّى إصلاحات أمنية. ما الاتجاه الموصى به لإعدادات توجيه HTTP الجديدة؟

اعرض كل خدمة بـ NodePort خاص بها.
أبقِ على الـ controller المتقاعد؛ ستصونه نواة Kubernetes.
استبدل الـ Ingress بـ Service من نوع LoadBalancer لكل تطبيق.
‏Gateway API: ‏Gateway يملكه فريق المنصّة، وHTTPRoutes يملكها فريق كل تطبيق.

‏Pod من notes-api يُظهر CrashLoopBackOff وLast State: Terminated, Exit Code: 137. والأمر kubectl logs --previous يعرض سجلات طلبات عادية، ثم لا شيء. ما السبب المرجّح والحل؟

تجاوز الـ container حدّ ذاكرته فقُتل بسبب نفاد الذاكرة؛ تحقّق في describe من OOMKilled، ثم ارفع الحدّ أو أصلح التسرّب وضع سقفًا للـ heap في V8.
استثناء JavaScript أسقط العملية.
لا يمكن سحب الـ image.
فشل الـ readiness probe.

أي مجموعة تعطي notes-api عمليات نشر دون توقّف؟

استراتيجية Recreate مع liveness probe على /readyz.
لا probes، وmaxUnavailable: 25%، وقيمة عالية لـ terminationGracePeriodSeconds.
‏readiness probe، وmaxUnavailable: 0، وتوقّف preStop قصير، ومعالج SIGTERM يفرّغ الطلبات الجارية.
‏replicas: 1 مع kubectl rollout restart بعد كل تغيير.

12 سؤالًا بلا إجابة