{"id":"l-dk-4-1","courseId":"docker-kubernetes","lang":"ar","kind":"lesson","summary":"اشرح كيف يحوّل Kubernetes الحالة المرغوبة المصرَّح بها إلى containers تعمل عبر حلقات التحكّم، وسمِّ المكوّنات الرئيسية في الـ cluster، وأنشئ cluster محليًا بـ kind لتعمل فيه.","html":"

‏Compose يشغّل بيئتك على جهاز واحد. حين يموت ذلك الجهاز، تموت خدمتك معه، ولا شيء يعيدها حتى يلاحظ أحد. ‏Kubernetes موجود للحالة الأخرى: أجهزة كثيرة، وcontainers يجب أن تستمر في العمل حين يفشل أي جهاز منها، وتغييرات تُنشر دون توقّف للخدمة. لتستخدمه جيدًا، تحتاج إلى فكرة واحدة أكثر من حاجتك إلى أي أمر.

\n

حلقة التحكّم

\n

في Kubernetes لا تقول «شغّل ثلاثة containers». تقول «يجب أن توجد ثلاث نسخ من notes-api»، وتخزّن ذلك ككائن في الـ cluster (العنقود). ثم يشغّل controller حلقة، بلا توقّف:

\n
    \n
  1. راقب الحالة الفعلية: كم Pod من notes-api موجود ويعمل؟
    2. \n
  2. قارن بينها وبين الحالة المرغوبة في الكائن.
    3. \n
  3. تصرّف لسدّ الفجوة: أنشئ Pod، أو احذف واحدًا، أو استبدل واحدًا.
    4. \n
\n

الحلقة لا تنتهي أبدًا. إذا مات node وأخذ معه Pod، فالدورة التالية ترى اثنين حيث المطلوب ثلاثة فتنشئ واحدًا. إذا غيّرت العدد المرغوب إلى خمسة، تنشئ اثنين آخرين. وإذا حذف أحدهم Pod يدويًا، يُستبدل خلال ثوانٍ. هذا ما يقصده الناس بـ التصريحي (declarative): تصف الوجهة، والنظام يواصل التوجّه نحوها.

\n

تشبيه منظّم الحرارة مفيد هنا. تضبطه على 21°C؛ فلا يشغّل المنظّم سكربتًا ثابتًا من نوع «سخّن لمدة 20 دقيقة». إنه يقيس ويقارن ويشغّل المدفأة أو يطفئها ما دام موصولًا بالكهرباء.

\n

أجزاء الـ cluster

\n
\n ‏kubectl يرسل الكائنات إلى الـ API server، الذي يخزّنها في etcd. الـ scheduler والـ controller manager يراقبان الـ API server. على كل node عامل، يراقب الـ kubelet الـ Pods المسندة إليه ويشغّل الـ containers عبر الـ container runtime.\n \n kubectl\n \n مستوى التحكّم (control plane)\n \n API server\n \n etcd\n \n scheduler\n \n controller\n manager\n \n \n \n \n \n node 1\n kubelet → containerd\n pod pod\n \n node 2\n kubelet → containerd\n pod\n \n \n مراقبة: Pods هذا الـ node\n
كل مكوّن يتحدّث مع الـ API server؛ والـ controllers والـ kubelets توفّق الحالة
\n\n

الخدمات المُدارة مثل Amazon EKS تشغّل مستوى التحكّم نيابة عنك. لكنك ما زلت تحتاج إلى فهمه، لأن كل رسالة خطأ ستقرؤها تشير إلى أحد هذه الأجزاء.

\n

cluster على حاسوبك

\n

‏kind ‏(“Kubernetes in Docker”) يشغّل cluster كاملًا داخل containers في Docker. إنشاؤه سريع والتخلّص منه سريع، وهذا بالضبط ما تريده للتعلّم:

\n
Terminal
kind create cluster --name notes\nkubectl config current-context      # kind-notes\nkubectl get nodes\nkind load docker-image notes-api:1.0.0 --name notes
\n

الأمر الأخير ينسخ الـ image المحلية إلى الـ node في kind، فيستطيع الـ cluster تشغيلها دون registry. يعمل minikube وKubernetes المدمج في Docker Desktop أيضًا؛ وأوامر kubectl في هذه الدورة هي نفسها في كل مكان.

\n

في kind، يعمل مستوى التحكّم نفسه كـ Pods على الـ node المخصّص له. شغّل kubectl get pods -n kube-system وسترى الـ API server وetcd والـ scheduler والـ controller manager مدرجة مثل أي حمل عمل آخر، ومعها DNS الخاص بالـ cluster ‏(CoreDNS) وkube-proxy. أما في cluster مُدار فلن ترى مستوى التحكّم هناك، لأن المزوّد يشغّله بعيدًا عن الأنظار.

\n

راقب الحلقة وهي تعمل

\n

أنشئ Deployment بالأوامر المباشرة، مرة واحدة، لترى التوفيق بعينيك:

\n
Terminal
kubectl create deployment notes-api --image=notes-api:1.0.0 --replicas=3\nkubectl get pods\nkubectl delete pod <one-of-the-pod-names>\nkubectl get pods --watch
\n

خلال ثوانٍ يظهر Pod جديد باسم جديد. لم تطلبه؛ الـ controller أدّى عمله. والآن انظر إلى ما أنشأته:

\n
Terminal
kubectl get deployment notes-api -o yaml\nkubectl explain deployment.spec.replicas\nkubectl delete deployment notes-api
\n

الخيار -o yaml يعرض الكائن الكامل الذي خزّنه Kubernetes، بما فيه قيم افتراضية كثيرة لم تضبطها. والأمر kubectl explain يوثّق أي حقل من الـ cluster نفسه؛ إنه أسرع مرجع لديك. بدءًا من الدرس التالي ستكتب هذه الكائنات كملفات وتطبّقها، وهكذا تعمل الفرق الحقيقية.

\n\n

التالي: الكائنات التي لمحتها للتوّ، مكتوبة كما يجب. الـ Pods والـ ReplicaSets والـ Deployments.

\n","toc":[{"id":"sec-1","text":"حلقة التحكّم","level":2},{"id":"sec-2","text":"أجزاء الـ cluster","level":2},{"id":"sec-3","text":"cluster على حاسوبك","level":2},{"id":"sec-4","text":"راقب الحلقة وهي تعمل","level":2}],"takeaways":["تخبر Kubernetes بالحالة التي تريدها؛ والـ controllers تواصل مقارنتها بالحالة الفعلية وتتصرّف لسدّ الفجوة، إلى الأبد.","الـ API server هو الباب الأمامي، وهو المكوّن الوحيد الذي يتحدّث مع etcd، حيث تُخزَّن كل حالة الـ cluster.","الـ scheduler يختار node لكل Pod جديد؛ والـ kubelet على ذلك الـ node يشغّل الـ containers الخاصة به عبر الـ container runtime.","حذف Pod يديره controller لا يزيله لوقت طويل، لأن الـ controller يرى أن واحدًا ناقص فينشئ بديلًا.","تحقّق دائمًا من الـ cluster الذي يشير إليه kubectl بالأمر kubectl config current-context قبل تغيير أي شيء."],"further":[{"title":"Kubernetes components","url":"https://kubernetes.io/docs/concepts/overview/components/"},{"title":"Controllers","url":"https://kubernetes.io/docs/concepts/architecture/controller/"},{"title":"Install and set up kubectl","url":"https://kubernetes.io/docs/tasks/tools/"}],"quiz":[{"q":"

‏Deployment يريد 3 نسخ (replicas). ينهار node ويأخذ معه Pod واحدًا. ما الذي يعيد الـ Pod الثالث؟

","options":[{"text":"يلاحظ controller وجود 2 من الـ Pods حيث المطلوب 3، فينشئ واحدًا جديدًا، ويضعه الـ scheduler على node سليم.","why":"صحيح. الـ controller الخاص بالـ ReplicaSet يواصل التوفيق بين الفعلي والمرغوب، فيستبدل الـ Pod المفقود دون أن يشغّل أحد أي أمر."},{"text":"يعيد الـ kubelet على الـ node المنهار تشغيل الـ Pod حين يعود الـ node.","why":"إذا ذهب الـ node، ذهب معه الـ kubelet الخاص به. التعافي يجب أن يأتي من مستوى التحكّم."},{"text":"لا شيء؛ يجب أن يعيد أحدهم تشغيل kubectl apply.","why":"الحالة المرغوبة مخزّنة أصلًا. إعادة تطبيق الملف نفسه لا تغيّر شيئًا لا تفرضه الـ controllers بالفعل."},{"text":"يعيد etcd تشغيل الـ Pod من نسخته الاحتياطية.","why":"الـ etcd يخزّن الحالة. لا يشغّل أي شيء ولا يوقفه أبدًا."}],"answer":0},{"q":"

أي مكوّن هو الوحيد الذي يقرأ etcd ويكتب فيه مباشرة؟

","options":[{"text":"الـ scheduler","why":"الـ scheduler يراقب الـ Pods ويحدّثها عبر الـ API server، مثل كل المكوّنات الأخرى."},{"text":"الـ kubelet","why":"الـ kubelets تتحدّث مع الـ API server لمعرفة الـ Pods التي يجب تشغيلها وللإبلاغ عن حالتها."},{"text":"‏kubectl","why":"‏kubectl عميل للـ API server. لا يرى etcd أبدًا."},{"text":"الـ API server","why":"صحيح. كل شيء آخر يمرّ عبره، وهناك يحدث التحقّق والمصادقة والتفويض."}],"answer":3},{"q":"

تحذف Pod أنشأه Deployment بالأمر kubectl delete pod notes-api-7d9c-xk2lp. ماذا ترى بعد بضع ثوانٍ في kubectl get pods؟

","options":[{"text":"‏Pod أقل بواحد، حتى توسّع الـ Deployment من جديد.","why":"العدد المرغوب في الـ Deployment لم يتغيّر، فيُصحَّح النقص فورًا."},{"text":"‏Pod جديد باسم مختلف، أُنشئ ليحلّ محلّه.","why":"صحيح. يرى الـ controller الخاص بالـ ReplicaSet أن واحدًا ناقص فينشئ بديلًا. لإزالة الـ Pods نهائيًا، غيّر الـ Deployment."},{"text":"الـ Pod نفسه، مستعادًا بالاسم نفسه وعنوان IP نفسه.","why":"الـ Pods لا تُستعاد أبدًا. البديل Pod جديد باسم جديد، وغالبًا بعنوان IP جديد."},{"text":"خطأ، لأن Pods الـ Deployment لا يمكن حذفها.","why":"تستطيع حذفها. لكن الـ controller لن يسمح ببقاء العدد منخفضًا."}],"answer":1},{"q":"

قبل تشغيل kubectl delete deployment notes-api، ما الذي يجب أن تتحقّق منه؟

","options":[{"text":"أن الـ image ما زالت موجودة في الـ registry.","why":"حذف Deployment لا يعتمد على الـ image. أما الـ cluster الذي تتحدّث معه فيهمّ فعلًا."},{"text":"أن لدى etcd نسخة احتياطية حديثة.","why":"ممارسة جيدة لمشغّلي الـ clusters، لكن الخطر المباشر هنا هو التصرّف على الـ cluster الخطأ."},{"text":"الـ cluster والـ namespace اللذين يشير إليهما kubectl، بالأمر kubectl config current-context.","why":"صحيح. يتصرّف kubectl على أي context هو الحالي. الأمر نفسه يعني أشياء مختلفة جدًا في kind وفي الإنتاج."},{"text":"أن الـ Deployment فيه أقل من 10 نسخ.","why":"عدد النسخ لا يغيّر كون الحذف آمنًا أم لا."}],"answer":2}],"exercise":{"kind":"order","items":["send","store","rs","pods","schedule","start","report"],"title":"من kubectl apply إلى container يعمل","prompt":"

تشغّل kubectl apply -f deployment.yaml لـ notes-api مع 3 نسخ على cluster جديد. رتّب ما يحدث بعد ذلك.

\n","hints":["لا شيء يحدث في أي مكان قبل أن يُخزَّن الكائن.","الـ Deployment لا ينشئ الـ Pods بنفسه؛ بل يدير شيئًا يفعل ذلك.","يجب أن يُسند الـ Pod إلى node قبل أن يتصرّف أي kubelet بشأنه."],"explanation":"

يرسل kubectl الكائن إلى الـ API server، الذي يتحقّق منه ويخزّنه في etcd. يرى الـ controller الخاص بالـ Deployments كائن Deployment جديدًا فينشئ ReplicaSet؛ وينشئ الـ controller الخاص بالـ ReplicaSet ثلاثة كائنات Pod. يُسند الـ scheduler كل Pod غير مُجدوَل إلى node. يسحب الـ kubelet على كل node مختار الـ image ويشغّل الـ containers، ثم يُبلغ عن حالة الـ Pod عبر الـ API server. كل خطوة مكوّن منفصل يتفاعل مع تغيير كان يراقبه.

\n","checkLabels":{},"itemText":{"send":"يرسل kubectl الـ Deployment إلى الـ API server","store":"يتحقّق الـ API server منه ويخزّنه في etcd","rs":"ينشئ الـ controller الخاص بالـ Deployments كائن ReplicaSet","pods":"ينشئ الـ controller الخاص بالـ ReplicaSet ثلاثة كائنات Pod","schedule":"يُسند الـ scheduler كل Pod إلى node","start":"يسحب الـ kubelet في كل node الـ image ويشغّل الـ containers","report":"يُبلغ الـ kubelet عن حالة الـ Pod إلى الـ API server"}},"words":617,"readMinutes":4}