حلقة التحكّم وأول cluster لك

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

حلقة التحكّم

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

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

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

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

أجزاء الـ cluster

• الـ API server هو الباب الأمامي. ‏kubectl والـ controllers والـ kubelets كلها تتحدّث معه، وهو يتحقّق من صحة كل طلب ومن هوية مرسله وصلاحياته.
• الـ etcd مخزن مفتاح-قيمة متّسق يحفظ كل الكائنات. لا يتحدّث معه إلا الـ API server.
• الـ scheduler (المُجدوِل) يراقب الـ Pods التي لا node لها ويختار لها واحدًا، بناءً على الموارد الحرّة والقيود والتوزيع.
• الـ controller manager يشغّل الـ controllers المدمجة: الـ Deployments، والـ ReplicaSets، والـ Jobs، وصحة الـ nodes، وغيرها.
• على كل node (عقدة) عامل، يراقب الـ kubelet الـ Pods المسندة إلى الـ node الخاص به ويشغّل الـ containers الخاصة بها عبر container runtime، وهو عادةً containerd. الـ images التي بنيتها بـ Docker تعمل هناك دون تغيير، لأن الـ images تتبع معيار OCI.

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

cluster على حاسوبك

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

kind create cluster --name notes
kubectl config current-context      # kind-notes
kubectl get nodes
kind load docker-image notes-api:1.0.0 --name notes

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

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

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

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

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

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

kubectl get deployment notes-api -o yaml
kubectl explain deployment.spec.replicas
kubectl delete deployment notes-api

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

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