الأمر المباشر kubectl create deployment من الدرس السابق كان جيدًا لعرض توضيحي، وبلا فائدة لفريق. لا أحد يستطيع مراجعته، ولا أحد يعرف أي خيارات استُخدمت، وفي الأسبوع القادم لا أحد يستطيع تكراره. من الآن فصاعدًا، تعيش إعدادات Kubernetes الخاصة بـ notes-api في ملفات YAML تحت k8s/، بجوار الـ Dockerfile، وتُراجع مثل الكود.
الـ Pod هو container واحد أو أكثر تُجدوَل معًا على node واحد، وتتشارك network namespace واحدة (عنوان IP واحد، وlocalhost واحد) وأي volumes تصرّح بها. معظم الـ Pods لها container رئيسي واحد. والـ container الثاني يكون لشيء مرتبط بالأول ارتباطًا وثيقًا، مثل أداة شحن سجلات أو proxy يجب أن يعيش ويموت معه.
يبدو manifest الـ Pod الأدنى هكذا:
\napiVersion: v1\nkind: Pod\nmetadata:\n name: notes-api-test\nspec:\n containers:\n - name: api\n image: ghcr.io/skylane/notes-api:1.4.0\n ports:\n - containerPort: 3000لن تنشئ Pods بهذه الطريقة عمليًا. الـ Pod المجرّد لا يُستبدل إذا انهار على node ميت، ولا يمكن تغيير عدد نسخه، ولا يمكن تحديثه إلى image جديدة تدريجيًا. الـ Pods قطيع يُستبدل: كل واحد منها يمكن التخلّص منه، ويحصل على اسم وIP جديدين حين يُستبدل، ويديره شيء فوقه.
\nالـ Deployment هو ذلك الشيء. إنه يملك ReplicaSet، ومهمّته الوحيدة إبقاء N من الـ Pods المتطابقة قيد التشغيل. أما مهمّة الـ Deployment فهي إدارة الـ ReplicaSets عبر الزمن: حين تغيّر قالب الـ Pod، ينشئ ReplicaSet جديدًا وينقل الـ Pods إليه، وهذا هو التحديث المتدرّج (rolling update) الذي ستدرسه في القسم الخامس.
\napiVersion: apps/v1\nkind: Deployment\nmetadata:\n name: notes-api\n labels:\n app.kubernetes.io/name: notes-api\nspec:\n replicas: 3\n selector:\n matchLabels:\n app.kubernetes.io/name: notes-api\n template:\n metadata:\n labels:\n app.kubernetes.io/name: notes-api\n spec:\n containers:\n - name: api\n image: ghcr.io/skylane/notes-api:1.4.0\n ports:\n - name: http\n containerPort: 3000\n env:\n - name: PORT\n value: \"3000\"اقرأه على نصفين. النصف العلوي هو الـ Deployment نفسه: اسمه، وعدد النسخ، والـ Pods التي يملكها (selector). وكل ما تحت template هو مواصفات Pod، المخطّط الذي تُطبع منه كل نسخة. لاحظ أن apiVersion يختلف حسب النوع: الـ Pods في v1 الأساسية، والـ Deployments في apps/v1.
كائنات Kubernetes لا يشير بعضها إلى بعض بالاسم. إنها تجد بعضها عبر الـ labels (الوسوم)، وهي أزواج مفتاح-قيمة في metadata.labels، وعبر الـ selectors (المحدِّدات)، وهي استعلامات على تلك الـ labels. يعدّ الـ ReplicaSet الـ Pods الخاصة به بتشغيل الـ selector الخاص به؛ وفي الدرس التالي سيجد Service الـ Pods التي يرسل إليها الحركة بالطريقة نفسها.
لهذا يجب أن يطابق selector.matchLabels في الـ Deployment الحقل template.metadata.labels: يجب أن يستطيع الـ Deployment إيجاد الـ Pods التي ينشئها قالبه. يتحقّق الـ API server من ذلك ويرفض عدم التطابق. والـ selector أيضًا غير قابل للتغيير (immutable) بعد وجود الـ Deployment، فاختره بعناية. المفتاح app.kubernetes.io/name أحد الـ labels الموصى بها في Kubernetes؛ تفهمه الأدوات ولوحات المتابعة، واستخدامه باتّساق يؤتي ثماره.
kind load docker-image ghcr.io/skylane/notes-api:1.4.0 --name notes\nkubectl apply -f k8s/deployment.yaml\nkubectl get deploy,rs,pods -l app.kubernetes.io/name=notes-api\nkubectl describe deployment notes-apiالأمر kind load ينسخ الـ image إلى الـ cluster باسمها الكامل، فيستطيع الـ manifest استخدام المرجع نفسه الذي سيستخدمه الإنتاج. و-l يصفّي حسب الـ label، وهي الآلية نفسها التي تستخدمها الـ controllers. انظر إلى أسماء الـ Pods: notes-api-6c8f9d7b5-x2k4q هو اسم الـ Deployment، ثم الـ pod-template-hash الخاص بالـ ReplicaSet، ثم لاحقة عشوائية. غيّر أي شيء في القالب وستحصل على ReplicaSet جديد بـ hash جديد.
لزيادة عدد النسخ، غيّر replicas: 3 إلى 5 في الملف وطبّق مجددًا. يقارن kubectl apply ملفك بما هو مخزّن ولا يرسل إلا الفرق. والأمر kubectl diff -f k8s/ يعرض ذلك الفرق قبل أن تلتزم به، ويجب أن تعتاد تشغيله.
الأمر kubectl scale deployment/notes-api --replicas=5 يعمل أيضًا، وله مكانه في حالات الطوارئ. لكن الملف ما زال يقول 3، فيُرجع الـ apply الروتيني التالي العدد إلى 3 بصمت. كل ما تغيّره يدويًا، غيّره في Git مباشرة بعده.
الـ Pods لديك تعمل، لكن كلًّا منها يملك عنوان IP خاصًا يتغيّر في كل مرة يُستبدل فيها. لا شيء يستطيع الوصول إليها بشكل موثوق بعد. وهذا ما وُجدت الـ Services من أجله.
\n","toc":[{"id":"sec-1","text":"الـ Pods: الوحدة التي يشغّلها Kubernetes","level":2},{"id":"sec-2","text":"الـ Deployments والـ ReplicaSets والـ Pods","level":2},{"id":"sec-3","text":"الـ Labels والـ Selectors","level":2},{"id":"sec-4","text":"طبّق وافحص ووسّع","level":2}],"takeaways":["الـ Pod هو container واحد أو أكثر تتشارك هوية شبكية وتخزينًا؛ إنه أصغر شيء يُجدوِله Kubernetes، ويمكن التخلّص منه.","نادرًا ما تنشئ Pods مجرّدة؛ فالـ Deployment يدير ReplicaSet، وهذا الأخير يُبقي العدد الصحيح من الـ Pods قيد التشغيل.","يجب أن يطابقspec.selector.matchLabels في الـ Deployment الـ labels الموجودة في spec.template.metadata.labels، ولا يمكن تغيير الـ selector بعد الإنشاء.","احفظ الـ manifests في Git وغيّرها بـ kubectl apply -f، حتى تبقى الملفات مصدر الحقيقة.","استخدم إصدارات الـ API الحالية مثل apps/v1؛ فالـ manifests المنسوخة من مقالات قديمة بـ extensions/v1beta1 لم تعد تعمل."],"further":[{"title":"Pods","url":"https://kubernetes.io/docs/concepts/workloads/pods/"},{"title":"Deployments","url":"https://kubernetes.io/docs/concepts/workloads/controllers/deployment/"},{"title":"Labels and Selectors","url":"https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/"},{"title":"Recommended Labels","url":"https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/"}],"quiz":[{"q":"لماذا نشغّل notes-api عبر Deployment بدلًا من إنشاء ثلاثة Pods مباشرة؟
","options":[{"text":"لأن الـ Pods لا يمكن إنشاؤها من ملفات YAML.","why":"يمكن ذلك. manifest الـ Pod المجرّد صالح؛ لكن لا شيء يديره."},{"text":"لأن الـ Pods المنشأة مباشرة لا تستطيع استخدام images من registry.","why":"سحب الـ images يعمل بالطريقة نفسها لأي Pod. الإدارة هي الفرق."},{"text":"لأن الـ Deployments تشغّل الـ containers أسرع من الـ Pods المجرّدة.","why":"سرعة البدء متطابقة. الـ containers تعمل بالطريقة نفسها."},{"text":"لأن الـ Pod المجرّد لا يُستبدل إذا مات هو أو الـ node الخاص به، ولا يمكن نشر إصدار جديد له تدريجيًا؛ والـ Deployment يتولّى الأمرين.","why":"صحيح. الـ Deployment، عبر الـ ReplicaSet الخاص به، يُبقي العدد صحيحًا ويدير التحديثات."}],"answer":3},{"q":"يرفض kubectl apply كائن Deployment بالرسالة: selector does not match template labels. ما الخطأ؟
spec.selector.matchLabels يطلب labels لا يضبطها spec.template.metadata.labels.","why":"صحيح. يجب أن يستطيع الـ Deployment إيجاد الـ Pods التي ينشئها قالبه، لذا يتحقّق الـ API server من تطابقهما."},{"text":"الـ Deployment في namespace مختلف عن الـ Pods الخاصة به.","why":"الـ Pods الخاصة بـ Deployment تُنشأ دائمًا في الـ namespace الخاص به."},{"text":"الـ tag الخاص بالـ image ليس قيمة label صالحة.","why":"الـ image ليست label أصلًا؛ ولا تشارك في الاختيار."}],"answer":1},{"q":"تشغّل kubectl get pods فترى notes-api-6c8f9d7b5-x2k4q. ما هو 6c8f9d7b5؟
kubectl get pods -o wide لرؤية الـ nodes."},{"text":"hash لقالب الـ Pod، يحدّد الـ ReplicaSet الذي أنشأ هذا الـ Pod.","why":"صحيح. كل نسخة من القالب تحصل على ReplicaSet خاص بها، وتحمل الـ Pods التابعة له الـ pod-template-hash الخاص به. سترى لماذا يهمّ هذا في التراجع."},{"text":"لاحقة عشوائية بلا معنى.","why":"الجزء الأخير وحده (x2k4q) عشوائي. أما الجزء الأوسط فمقصود."}],"answer":2},{"q":"شغّل أحدهم kubectl scale deployment/notes-api --replicas=6 أثناء حادث. ماذا يحدث عند kubectl apply -f k8s/ التالي والملف يضبط replicas على 3؟
اقتبس زميلك هذا الـ Deployment من مقالة في مدوّنة. يفشل kubectl apply، وبعد إصلاح الخطأ الأول يفشل مجددًا بخطأ مختلف. اختر السطرين الاثنين اللذين يجب إصلاحهما.
السطر 1 يستخدم extensions/v1beta1، الذي أُزيل منذ زمن بعيد؛ فيفشل apply برسالة no matches for kind "Deployment". استخدم apps/v1.
السطر 13 يعطي الـ Pods الـ label notes، بينما يطلب الـ selector notes-api، فيرفض الـ API server الـ Deployment لأن الـ selector الخاص به لا يطابق قالبه. اجعلهما متطابقين:
apiVersion: apps/v1\n# …\n selector:\n matchLabels:\n app.kubernetes.io/name: notes-api\n template:\n metadata:\n labels:\n app.kubernetes.io/name: notes-api