> ## Content Index
> Fetch the complete content index at: https://arabroot.io/llms.txt
> Use this file to discover other available public pages before exploring further.

# هل تحتاج Kubernetes فعلاً؟ متى يكفي Docker Compose
- URL: https://arabroot.io/articles/هل-تحتاج-kubernetes-فعلا/
- Published: 2026-10-06T08:30:00.000Z
- Updated: 2026-10-09T09:43:43.000Z
- Description: ما الذي يحله Kubernetes وما الذي يكلفك، ومتى يكفيك Docker Compose على سيرفر واحد أو بضعة سيرفرات.
- Author: فريق عرب رووت
- Tags: الأدلة التقنية, DevOps والتشغيل, DevOps وCI/CD, Docker والحاويات, الاستضافة الذاتية

في كل فريق تقريباً يأتي يوم يقترح فيه أحدهم أن ننقل التطبيق إلى Kubernetes، لأن الشركات الكبيرة تستخدمه، ولأن إعلانات الوظائف تطلبه، ولأن ملف Docker Compose الذي يعمل منذ سنتين على سيرفر واحد يبدو فجأة بسيطاً أكثر من اللازم. وقد يكون الاقتراح صحيحاً، وقد يكون بداية أشهر من العمل على أدوات لا تضيف شيئاً للمستخدم، والفرق بين الحالتين لا يحدده اسم الأداة، وإنما تحدده المشكلة التي عندك فعلاً، وعدد السيرفرات التي تحتاجها، ومن سوف يشغل العنقود Cluster بعد أن ينتهي الحماس الأول.

وهذا المقال هو الأول في [مرحلة Kubernetes وGitOps في خريطة الطريق](https://arabroot.io/start/#stage-kubernetes)، والهدف منه أن تقرر قبل أن تتعلم التفاصيل، أما المصطلحات نفسها فقد شرحناها بالرسم في [مصطلحات Kubernetes بالرسم](https://arabroot.io/articles/%D9%85%D8%B5%D8%B7%D9%84%D8%AD%D8%A7%D8%AA-kubernetes-%D8%A8%D8%A7%D9%84%D8%B1%D8%B3%D9%85/)، وسوف نناقش في هذا المقال ما يلي:

- ما الذي يحله Kubernetes فعلاً: الجدولة Scheduling على عدة سيرفرات، والإصلاح الذاتي Self-healing، والتحديث التدريجي Rolling Update، واكتشاف الخدمات Service Discovery.
- ما الذي يفعله Docker Compose على سيرفر واحد، وأين يتوقف.
- ما الذي يكلفه Kubernetes: التعقيد، والناس، وأجزاء التحكم Control Plane، والشبكة، والتخزين، والتحديث كل سنة على الأقل.
- متى يكفيك Compose على سيرفر واحد أو بضعة سيرفرات قوية.
- الحلول الوسط: Docker Swarm وNomad وK3s على سيرفر واحد.
- دليل قرار من ثلاثة أسئلة، ثم ترتيب التعلم إذا قررت أن تبدأ.

## ما الذي يحله Kubernetes فعلاً؟

Kubernetes نظام لإدارة ال Containers على عدة سيرفرات، وفكرته الأساسية أنك لا تقول له «شغل هذا ال Container على هذا السيرفر»، وإنما تكتب في ملف الحالة التي تريدها Desired State، مثل «أريد ثلاث نسخ من هذا التطبيق بهذه ال Docker Image»، ثم تعمل داخله حلقات تحكم Control Loops تسمى المتحكمات Controllers، كل واحد منها يراقب الحالة الحالية ويقارنها بما طلبته ويصلح الفرق، كما يصف [توثيق Kubernetes للمتحكمات](https://kubernetes.io/docs/concepts/architecture/controller/?ref=arabroot.io). والتشبيه الأقرب هو منظم الحرارة في البيت: أنت لا تشغل المكيف وتطفئه كل ساعة، وإنما تحدد 23 درجة، والجهاز يراقب ويتدخل كلما ابتعدت الحرارة عن الرقم.

ومن هذه الفكرة تأتي أربع خدمات يقدمها لك، وهي التي يجب أن تسأل نفسك هل تحتاجها فعلاً، والصورة التالية تبين الأربع معاً:

![أربع لوحات: في الأولى المجدول kube-scheduler يوزع ثلاث نسخ على ثلاث عقد، وفي الثانية عقدة متوقفة عليها علامة خطأ ونسختها تنتقل إلى عقدة سليمة، وفي الثالثة تحديث تدريجي من النسخة 1.4.1 إلى 1.4.2 على أربع مراحل، وفي الرابعة Pod يطلب الاسم web.shop.svc فيوزع الطلب على ثلاث نسخ بعناوين مختلفة](https://arabroot.io/content/images/2026/10/k8s-need-01-what-it-solves.webp)

الجدولة والإصلاح الذاتي والتحديث التدريجي واكتشاف الخدمات

### الجدولة على عدة سيرفرات Scheduling

عندما يكون لديك عشرة سيرفرات وثلاثون خدمة، فإن السؤال «أين أشغل هذه النسخة؟» يصبح عملاً يومياً، فهناك سيرفر امتلأت ذاكرته، وآخر عليه قرص سريع تحتاجه قاعدة البيانات، وثالث لا تريد أن تضع عليه نسختين من الخدمة نفسها حتى لا تتوقفا معاً. وفي Kubernetes يقوم بهذا العمل المجدول kube-scheduler، الذي يبحث عن كل Pod لم تحدد له عقدة Node بعد ويختار له العقدة المناسبة بحسب الموارد التي يطلبها والقيود التي تكتبها، كما في [مكونات Kubernetes](https://kubernetes.io/docs/concepts/overview/components/?ref=arabroot.io). ولاحظ أن هذه الميزة لا قيمة لها إذا كان لديك سيرفر واحد، فلا يوجد خيار أصلاً.

### الإصلاح الذاتي Self-healing

إذا توقف Container داخل Pod أعاد ال Kubelet تشغيله، وإذا فشل فحص الحياة Liveness Probe الذي تكتبه أعاد تشغيله أيضاً حتى لو كانت العملية ما زالت تعمل لكنها متجمدة، كما في [توثيق الفحوص Probes](https://kubernetes.io/docs/concepts/configuration/liveness-readiness-startup-probes/?ref=arabroot.io). وإذا توقفت عقدة كاملة فإن المتحكمات تنشئ Pods بديلة على العقد السليمة حتى يعود العدد إلى ما طلبته.

وقد يتساءل البعض: هل يحدث هذا فوراً؟ والإجابة لا، فبحسب [توثيق Taints وTolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/?ref=arabroot.io) يضيف Kubernetes تلقائياً لكل Pod سماحية Toleration للحالتين `not-ready` و`unreachable` مدتها 300 ثانية، وهذا يعني أن ال Pods تبقى مرتبطة بالعقدة المتوقفة خمس دقائق قبل أن تنقل، إلا إذا غيرت هذه القيمة. والإصلاح الذاتي إذن يحميك من أن تستيقظ في الثالثة فجراً، والمستخدم سوف يلاحظ دقائق التوقف إذا كانت الخدمة نسخة واحدة، ولذلك شغل نسختين على الأقل على عقدتين مختلفتين لأي خدمة مهمة.

### التحديث التدريجي Rolling Update والتراجع

عندما تغير رقم ال Docker Image في ال Deployment لا يوقف Kubernetes كل النسخ ثم يشغل الجديدة، وإنما ينشئ نسخاً جديدة ويحذف القديمة تدريجياً، والقيم الافتراضية في [توثيق ال Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/?ref=arabroot.io) هي `maxSurge` بنسبة 25% و`maxUnavailable` بنسبة 25%، أي أنه لا يتجاوز العدد المطلوب بأكثر من الربع ولا ينقص عن ثلاثة أرباعه أثناء التحديث، والنسخة الجديدة لا تستقبل طلبات إلا بعد أن ينجح فحص الجاهزية Readiness Probe. وإذا ظهرت مشكلة فالأمر `kubectl rollout undo` يعيدك إلى النسخة السابقة، لأن ال Deployment يحتفظ افتراضياً بعشر نسخ قديمة من إعداده.

### اكتشاف الخدمات Service Discovery وتوزيع الحمل

ال Pods تتغير عناوينها كلما استبدلت، ولذلك يعطيك Kubernetes كائناً اسمه Service له اسم ثابت في DNS داخل العنقود بالشكل `my-svc.my-namespace.svc.cluster-domain.example` كما في [توثيق DNS](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/?ref=arabroot.io)، ويوزع الطلبات على النسخ الجاهزة فقط. وفي Compose يوجد شيء قريب من هذا داخل السيرفر الواحد، فكل خدمة يصل إليها غيرها باسمها كما شرحنا في [شبكات Docker](https://arabroot.io/articles/%D8%B4%D8%A8%D9%83%D8%A7%D8%AA-docker-%D9%88%D8%A3%D9%81%D8%B6%D9%84-%D8%A7%D9%84%D9%85%D9%85%D8%A7%D8%B1%D8%B3%D8%A7%D8%AA/#compose-networks)، والفرق أن Kubernetes يقوم بذلك عبر عدة سيرفرات.

## ما الذي يفعله Docker Compose على سيرفر واحد؟

قبل أن تحكم على Compose بأنه بسيط أكثر من اللازم، لاحظ أن جزءاً كبيراً مما سبق موجود فيه بشكل أبسط، وأن ما ينقصه كله تقريباً مرتبط بوجود أكثر من سيرفر:

- **إعادة التشغيل Restart Policy:** القيمة `restart: unless-stopped` تجعل Docker يعيد تشغيل ال Container إذا خرج وبعد إعادة تشغيل السيرفر، وكل سياسات Docker في [التوثيق الرسمي](https://docs.docker.com/engine/containers/start-containers-automatically/?ref=arabroot.io) مبنية على خروج العملية، ولذلك فال Container الذي يتجمد دون أن يخرج يبقى يعمل بحالة unhealthy حتى تتدخل أنت أو أداة مراقبة، وهذا الفرق الأول الحقيقي عن فحص الحياة في Kubernetes.
- **عدة نسخ على السيرفر نفسه:** الحقل `deploy.replicas` في [مواصفات Compose](https://docs.docker.com/reference/compose-file/deploy/?ref=arabroot.io) أو الخيار `--scale` يشغل أكثر من نسخة من الخدمة، لكنها كلها على السيرفر نفسه، فإذا توقف توقفت جميعها.
- **التحديث:** `docker compose pull` ثم `docker compose up -d` يستبدل ال Container، وهناك ثوان من التوقف بين القديم والجديد، إلا إذا وضعت أمام التطبيق Reverse Proxy ونسختين وبدلتهما واحدة بعد الأخرى بنفسك.
- **الأسرار والإعدادات والشبكات وال Volumes:** كلها موجودة، وتقرؤها في ملف واحد بعينك، وتنسخها احتياطياً بنسخ مجلد.

والصورة التالية تضع الطريقتين بجانب بعضهما:

![على اليمين ملف compose.yaml يشغل أربعة Containers على سيرفر واحد مع Volume محلي وعبارة كل شيء يعيش ويموت مع هذا السيرفر، وعلى اليسار عنقود Kubernetes فيه kubectl وأجزاء تحكم على ثلاثة سيرفرات مع etcd وثلاث عقد عاملة على كل منها kubelet وkube-proxy وcontainerd وPods، مع شبكة وتخزين CSI، وعبارة أجزاء أكثر للتثبيت والتحديث والمراقبة والحماية](https://arabroot.io/content/images/2026/10/k8s-need-02-compose-vs-kubernetes.webp)

ملف واحد على سيرفر واحد، أم وصف للحالة على عنقود كامل

### التطبيق نفسه في الطريقتين

لنأخذ مثالاً تطبيق ويب مع قاعدة PostgreSQL وكلمة مرور في ملف سري، وهذا ملف Compose الذي يشغله على سيرفر واحد:

```yaml
services:
  web:
    image: ghcr.io/example/shop:1.4.2
    restart: unless-stopped
    environment:
      APP_MODE: production
      DB_HOST: db
      DB_PASSWORD_FILE: /run/secrets/db_password
    secrets: [db_password]
    ports:
      - "127.0.0.1:8080:8080"
    depends_on: [db]
  db:
    image: postgres:18
    restart: unless-stopped
    environment:
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    secrets: [db_password]
    volumes:
      - db-data:/var/lib/postgresql
volumes:
  db-data:
secrets:
  db_password:
    file: ./db_password.txt
```

والتطبيق نفسه في Kubernetes يحتاج سبعة كائنات: ConfigMap للإعدادات، وSecret لكلمة المرور، وDeployment بثلاث نسخ مع فحص الجاهزية وحدود الموارد، وService للتطبيق، وIngress للنطاق، وService من نوع Headless لقاعدة البيانات، وStatefulSet لها مع طلب تخزين دائم. وقد كتبنا الملفين كاملين ثم عددنا أسطرهما وتحققنا أن كل واحد منهما YAML صحيح بمكتبة PyYAML، والمخرج سوف يكون كما يلي:

```text
compose.yaml 1 documents ['compose']
k8s-app.yaml 7 documents ['ConfigMap', 'Secret', 'Deployment', 'Service', 'Ingress', 'Service', 'StatefulSet']
  25 compose.yaml
 132 k8s-app.yaml
 157 total
```

في المخرج أعلاه لاحظ التالي:

- 25 سطراً مقابل 132، وعدد الأسطر نفسه ليس المشكلة، فهو يكتب مرة واحدة، والمشكلة أن كل كائن من السبعة مفهوم يجب أن يفهمه من يصلح العطل.
- نسخة Kubernetes تعطيك ثلاث نسخ من التطبيق على عقد مختلفة وتحديثاً دون توقف، ونسخة Compose لا تعطيك ذلك، فالمقارنة ليست بين ملفين يفعلان الشيء نفسه.
- لم نطبق ملف Kubernetes على عنقود حقيقي في هذا المقال، والسبب أن المساحة على جهاز التجربة لم تسمح بتنزيل Docker Images جديدة، لذلك تحققنا من صحة ال YAML وبنينا الكائنات على أمثلة [توثيق Kubernetes](https://kubernetes.io/docs/concepts/overview/?ref=arabroot.io)، وشرحنا كل كائن منها في [مقال المصطلحات](https://arabroot.io/articles/%D9%85%D8%B5%D8%B7%D9%84%D8%AD%D8%A7%D8%AA-kubernetes-%D8%A8%D8%A7%D9%84%D8%B1%D8%B3%D9%85/).

## ما الذي يكلفه Kubernetes؟

سعر السيرفرات هو أصغر بنود التكلفة، والبنود الحقيقية هي ما تشغله أنت حول تطبيقك ليعمل العنقود أصلاً، والصورة التالية تبين ذلك:

![جبل جليد فوق الماء فيه تطبيقك مع Deployment وService وIngress، وتحت الماء ثمانية صناديق: أجزاء التحكم مع etcd وثلاث عقد، والتحديثات ثلاث مرات في السنة مع سنة دعم، والشبكة CNI وDNS وNetworkPolicy، والدخول عبر Ingress أو Gateway وcert-manager، والتخزين CSI أو Longhorn، والصلاحيات RBAC وسجل التدقيق، والمراقبة، والناس](https://arabroot.io/content/images/2026/10/k8s-need-03-hidden-costs.webp)

كل صندوق تحت الماء نظام تثبته وتحدثه وتراقبه

### التعقيد وعدد المفاهيم

في Compose تحتاج أن تعرف الخدمة والشبكة وال Volume، أما في Kubernetes فقبل أن تشغل تطبيقاً واحداً بشكل صحيح تحتاج Pod وDeployment وReplicaSet وService وIngress أو Gateway وConfigMap وSecret وNamespace وPersistentVolumeClaim، ثم RBAC وServiceAccount عندما تبدأ بالصلاحيات. وكل مفهوم منها له حالات فشل خاصة به، فال Pod الذي لا يبدأ قد يكون سببه Docker Image لم تنزل، أو طلب تخزين لم يرتبط بقرص، أو عقدة لا تملك الذاكرة المطلوبة، أو Secret غير موجود في ال Namespace الصحيح، وكل حالة لها أمر مختلف لتفحصها.

### الناس: من يشغل العنقود؟

هذا البند الذي يغفل عنه أغلب الفرق، فالعنقود ليس أداة تثبتها وتنساها، وإنما نظام يحتاج شخصاً على الأقل يعرف أجزاءه ويستطيع أن يصلحه ليلاً، ويحدثه، ويراجع صلاحياته، ويقرأ سجل التدقيق الذي شرحناه في [سجل تدقيق Kubernetes](https://arabroot.io/articles/%D8%B3%D8%AC%D9%84-%D8%A7%D9%84%D8%AA%D8%AF%D9%82%D9%8A%D9%82-audit-trail-%D9%85%D9%86-%D9%81%D8%B9%D9%84-%D9%85%D8%A7%D8%B0%D8%A7-%D9%88%D9%85%D8%AA%D9%89/#kubernetes). وفي [مدخل إلى تصميم الأنظمة](https://arabroot.io/articles/%D9%85%D8%AF%D8%AE%D9%84-%D8%A7%D9%84%D9%89-%D8%AA%D8%B5%D9%85%D9%8A%D9%85-%D8%A7%D9%84%D8%A7%D9%86%D8%B8%D9%85%D8%A9-%D9%85%D9%86-%D8%B3%D9%8A%D8%B1%D9%81%D8%B1-%D9%88%D8%A7%D8%AD%D8%AF-%D8%A7%D9%84%D9%89-%D9%85%D9%84%D8%A7%D9%8A%D9%8A%D9%86/) ذكرنا أن فريقاً من ثلاثة أشخاص لا يستطيع تشغيل Kafka وKubernetes وعشر خدمات مهما كان التصميم جميلاً على الورق، والسبب أن وقت الفريق يذهب إلى المنصة بدلاً من المنتج.

### أجزاء التحكم Control Plane وetcd

حالة العنقود كلها محفوظة في etcd، وهو مخزن يعمل بالإجماع Consensus عبر خوارزمية Raft التي شرحناها في [الأنظمة الموزعة](https://arabroot.io/articles/%D8%A7%D9%84%D8%A7%D9%86%D8%B8%D9%85%D8%A9-%D8%A7%D9%84%D9%85%D9%88%D8%B2%D8%B9%D8%A9-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-cap-%D9%88%D8%A7%D9%84%D8%A7%D8%AA%D8%B3%D8%A7%D9%82-%D9%88%D8%A7%D9%84%D8%A7%D8%AC%D9%85%D8%A7%D8%B9/#raft)، ولذلك يوصي [توثيق تشغيل etcd](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/?ref=arabroot.io) بعدد فردي من الأعضاء وبعنقود من خمسة أعضاء للإنتاج Production مع نسخ احتياطي دوري، ويطلب [توثيق التوفر العالي في kubeadm](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/ha-topology/?ref=arabroot.io) ثلاث عقد تحكم على الأقل إذا وضعت etcd عليها، أو ثلاثاً للتحكم وثلاثاً ل etcd إذا فصلتهما. وهذا يعني أن العنقود الذي يتحمل توقف سيرفر واحد يبدأ بثلاثة سيرفرات للتحكم قبل أن تضيف أي سيرفر لتطبيقك، إلا إذا جمعت التحكم والعمل على العقد نفسها.

### التحديث كل سنة على الأقل

يصدر Kubernetes ثلاث نسخ Minor في السنة منذ [تغيير دورة الإصدار سنة 2021](https://kubernetes.io/blog/2021/07/20/new-kubernetes-release-cadence/?ref=arabroot.io)، ويدعم المشروع آخر ثلاث نسخ فقط، وكل نسخة من 1.19 فما بعد تحصل على قرابة سنة من التحديثات، كما في [صفحة الإصدارات](https://kubernetes.io/releases/?ref=arabroot.io)، والنسخ المدعومة عند كتابة المقال هي 1.37 و1.36 و1.35\. وبالتالي فالتحديث ليس خياراً تؤجله، وإنما عمل ثابت مرة في السنة على الأقل، وكل تحديث قد يحذف واجهات API قديمة أو يغير سلوكاً تعتمد عليه أداة ثبتها أحدهم قبل سنوات.

📌

في 14 مارس 2023 بدأ فريق البنية في Reddit تحديث أقدم عناقيد Kubernetes عندهم وأكبرها من النسخة 1.23 إلى 1.24، وخلال دقائق توقفت الشبكة بين ال Pods في العنقود كله، وبقي الموقع متعطلاً أكثر من خمس ساعات كما كتب الفريق في [تقرير ما بعد الحادثة](https://www.reddit.com/r/RedditEng/comments/11xx5o0/you%5Fbroke%5Freddit%5Fthe%5Fpiday%5Foutage/?ref=arabroot.io). والسبب أن `kubeadm upgrade apply` في النسخة 1.24 يحذف ال Label القديم `node-role.kubernetes.io/master` من عقد التحكم كما في [سجل تغييرات 1.24](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.24.md?ref=arabroot.io)، بينما كانت إعدادات Calico القديمة في هذا العنقود تختار عاكسات المسارات Route Reflectors بهذا ال Label تحديداً، ولم تكن هذه الإعدادات محفوظة في أي مستودع، فلما اختفى ال Label لم يبق أي عاكس. ولأن Kubernetes لا يملك طريقة مدعومة للرجوع إلى نسخة أقدم، استعاد الفريق العنقود من نسخة احتياطية. والدرس أن كل جزء تحت الماء في الصورة أعلاه قد يكسر التحديث، وأن الإعداد الذي لا يوجد في Git لا يعرف أحد أنه موجود.

### الشبكة ودخول الطلبات

Kubernetes نفسه لا يأتي بشبكة بين ال Pods، وإنما يحتاج إضافة شبكة CNI مثل Flannel أو Calico أو Cilium، ثم يحتاج متحكماً لدخول الطلبات من الإنترنت. وهنا تغير الكثير مؤخراً: فصفحة [Ingress في التوثيق](https://kubernetes.io/docs/concepts/services-networking/ingress/?ref=arabroot.io) تقول إن واجهة Ingress مجمدة ولن تضاف إليها ميزات، وإن المشروع يوصي ب Gateway API بدلاً منها، مع بقاء Ingress مدعومة دون نية لحذفها. وفي نوفمبر 2025 أعلن المشروع [إيقاف مشروع Ingress NGINX](https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/?ref=arabroot.io)، وهو أشهر متحكم Ingress، مع صيانة محدودة حتى مارس 2026 ثم لا توجد إصدارات ولا إصلاحات أمنية بعدها. فمن ثبت Ingress NGINX قبل سنتين يحتاج الآن أن ينتقل إلى متحكم آخر، وهذا مثال واضح على أن المنصة تتغير تحتك حتى لو لم تغير أنت شيئاً.

### التخزين

في Compose ال Volume مجلد على قرص السيرفر، وتنسخه احتياطياً كما تنسخ أي مجلد. أما في Kubernetes فال Pod قد ينتقل إلى عقدة أخرى، ولذلك يحتاج قرصاً يتبعه، وهذا يعني مشغل تخزين CSI من مزود السحابة، أو نظام تخزين موزع مثل Longhorn أو Ceph تشغله أنت، أو تخزيناً محلياً يربط ال Pod بعقدة واحدة فيلغي جزءاً من فائدة العنقود. وقد شرحنا أنواع التخزين في [أنواع التخزين Block وFile وObject](https://arabroot.io/articles/%D8%A7%D9%86%D9%88%D8%A7%D8%B9-%D8%A7%D9%84%D8%AA%D8%AE%D8%B2%D9%8A%D9%86-block-%D9%88-file-%D9%88-object-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/)، ولاحظ أن قواعد البيانات داخل Kubernetes قرار مستقل له تكلفته، ففي [عناقيد قواعد البيانات](https://arabroot.io/articles/%D8%B9%D9%86%D8%A7%D9%82%D9%8A%D8%AF-%D9%82%D9%88%D8%A7%D8%B9%D8%AF-%D8%A7%D9%84%D8%A8%D9%8A%D8%A7%D9%86%D8%A7%D8%AA-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/#decision) ذكرنا أن أغلب الفرق يكفيها سيرفر قاعدة بيانات قوي مع نسخة احتياطية مجربة.

## متى يكفيك Compose على سيرفر واحد أو بضعة سيرفرات؟

السيرفر الواحد يتحمل أكثر بكثير مما يظن أغلب الناس، وقد رأينا في [كيف بنى Stack Overflow موقعه بسيرفرات قليلة](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%A8%D9%86%D9%89-stack-overflow-%D9%85%D9%88%D9%82%D8%B9%D9%87-%D8%A8%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D8%A7%D8%AA-%D9%82%D9%84%D9%8A%D9%84%D8%A9/) أن موقعاً من أكبر مواقع العالم خدم زواره سنوات بعدد قليل من السيرفرات القوية وتطبيق واحد، ولم ينتقل إلى Kubernetes إلا عندما انتقل إلى السحابة لأسباب أخرى. ويكفيك Compose غالباً في الحالات التالية:

- **سيرفر واحد يتحمل الحمل:** قس أولاً كما شرحنا في [قس قبل أن تغير](https://arabroot.io/articles/%D9%85%D8%AF%D8%AE%D9%84-%D8%A7%D9%84%D9%89-%D8%AA%D8%B5%D9%85%D9%8A%D9%85-%D8%A7%D9%84%D8%A7%D9%86%D8%B8%D9%85%D8%A9-%D9%85%D9%86-%D8%B3%D9%8A%D8%B1%D9%81%D8%B1-%D9%88%D8%A7%D8%AD%D8%AF-%D8%A7%D9%84%D9%89-%D9%85%D9%84%D8%A7%D9%8A%D9%8A%D9%86/#measure-first)، فإذا كان المعالج والذاكرة بعيدين عن الحد فالحل الأبسط هو سيرفر أكبر عند الحاجة.
- **توقف دقائق مقبول:** نظام داخلي لمؤسسة، أو موقع محتوى، أو أداة للفريق، يمكن أن تتوقف عشر دقائق في الشهر للتحديث دون خسارة حقيقية، والنسخ الاحتياطي المجرب يحميك من الخسارة الكبيرة.
- **خدمات قليلة وثابتة:** خمس خدمات أو عشر تعرفها كلها، ولا تضيف خدمة جديدة كل أسبوع.
- **فريق صغير:** لا يوجد من يملك الوقت لتشغيل منصة، والأفضل أن يذهب الوقت إلى التطبيق.

وإذا أردت النشر من Git وبيئات معاينة دون Kubernetes، فهناك منصات تقوم على Docker نفسه، مثل [Coolify](https://arabroot.io/articles/%D8%AA%D8%AB%D8%A8%D9%8A%D8%AA-coolify-%D9%84%D9%86%D8%B4%D8%B1-%D8%A7%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA/) و[Dokploy](https://arabroot.io/articles/%D8%AA%D8%AB%D8%A8%D9%8A%D8%AA-dokploy-%D9%84%D9%86%D8%B4%D8%B1-%D8%A7%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA/)، وقد قارنا بينهما وبين Portainer في [أيها تختار؟](https://arabroot.io/articles/%D9%85%D9%82%D8%A7%D8%B1%D9%86%D8%A9-portainer-%D9%88-coolify-%D9%88-dokploy/#which-one). وشرحنا كيف تبني بيئات وفريق GitOps بملفات Compose في [الشكل نفسه لفريق بدون Kubernetes](https://arabroot.io/articles/%D8%A7%D9%84%D8%A8%D9%8A%D8%A6%D8%A7%D8%AA-%D9%88%D9%85%D8%B9%D8%A7%D9%8A%D9%86%D8%A9-%D8%A7%D9%84%D9%85%D9%8A%D8%B2%D8%A7%D8%AA-%D9%88-gitops-%D9%84%D9%84%D9%81%D8%B1%D9%82/#config-repo-compose).

وعندما يكبر الحمل فالخطوة التالية ليست Kubernetes بالضرورة، وإنما سيرفران أو ثلاثة عليها ملف Compose نفسه خلف موزع حمل Load Balancer، وقاعدة بيانات على سيرفر مستقل، كما في [نسخ متعددة من التطبيق خلف موزع الحمل](https://arabroot.io/articles/%D9%85%D8%AF%D8%AE%D9%84-%D8%A7%D9%84%D9%89-%D8%AA%D8%B5%D9%85%D9%8A%D9%85-%D8%A7%D9%84%D8%A7%D9%86%D8%B8%D9%85%D8%A9-%D9%85%D9%86-%D8%B3%D9%8A%D8%B1%D9%81%D8%B1-%D9%88%D8%A7%D8%AD%D8%AF-%D8%A7%D9%84%D9%89-%D9%85%D9%84%D8%A7%D9%8A%D9%8A%D9%86/#load-balancer). والذي تخسره هنا هو التوزيع التلقائي، فإذا توقف سيرفر يبقى الآخران يخدمان الزوار، لكنك تعيد السيرفر المتوقف بنفسك.

⚠️

لا تنقل إلى Kubernetes تطبيقاً لا تعرف كيف تنسخه احتياطياً وتستعيده على Compose، والسبب أن العنقود لا يحل مشكلة النسخ الاحتياطي، وإنما يضيف إليها نسخ etcd وال Volumes الموزعة.

## حلول وسط بين Compose وKubernetes

بين سيرفر واحد مع Compose وعنقود Kubernetes كامل توجد ثلاث طرق شائعة، ولكل منها مكانها:

### Docker Swarm

وضع Swarm مدمج في Docker Engine نفسه كما في [توثيق Docker](https://docs.docker.com/engine/swarm/?ref=arabroot.io)، وتفعله بالأمر `docker swarm init`، ثم تنشر ملف Compose تقريباً كما هو على عدة سيرفرات بالأمر `docker stack deploy`، ومعه التوزيع على العقد والتحديث التدريجي والأسرار وشبكة overlay. ويجدر التمييز هنا بين Swarm المدمج في Docker و«Docker Classic Swarm» القديم الذي يقول التوثيق إنه لم يعد يطور. وأما مستقبله فقد أعلنت شركة Mirantis في يوليو 2025 أن [Swarm مدعوم بالكامل حتى 2030 على الأقل](https://www.mirantis.com/blog/mirantis-guarantees-long-term-support-for-swarm/?ref=arabroot.io) ضمن منتجها Mirantis Kubernetes Engine 3، و[Dokploy](https://arabroot.io/articles/%D8%AA%D8%AB%D8%A8%D9%8A%D8%AA-dokploy-%D9%84%D9%86%D8%B4%D8%B1-%D8%A7%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA/#remote-servers) يعتمد عليه لتشغيل أكثر من عقدة.

- **نقاط القوة:** لا يوجد شيء جديد لتثبيته، والملف هو ملف Compose الذي تعرفه، وعنقود من ثلاثة سيرفرات يجهز في دقائق.
- **نقاط الضعف:** المنظومة حوله صغيرة مقارنة ب Kubernetes، وأغلب الأدوات الجديدة في المراقبة والتخزين والأمان تكتب ل Kubernetes أولاً، والتخزين الموزع ما زال مسؤوليتك.

### Nomad

Nomad من HashiCorp يجدول ال Containers وغيرها من البرامج، مثل ملفات تنفيذية وتطبيقات Java، ويعمل كملف تنفيذي واحد للسيرفر والعميل دون خدمات خارجية للتخزين أو التنسيق كما في [توثيق Nomad](https://developer.hashicorp.com/nomad/docs/what-is-nomad?ref=arabroot.io)، ويتوقع [توثيق البنية](https://developer.hashicorp.com/nomad/docs/architecture?ref=arabroot.io) ثلاثة سيرفرات Servers أو خمسة في كل منطقة لأنها تعمل بالإجماع، وآخر إصدار عند كتابة المقال هو 2.0.7\. ولاحظ أن ترخيصه تغير في أغسطس 2023 من MPL 2.0 إلى Business Source License 1.1 كما في [ملف الترخيص في المستودع](https://github.com/hashicorp/nomad/blob/main/LICENSE?ref=arabroot.io)، وهو ترخيص يسمح بالاستخدام في مؤسستك لكنه ليس ترخيصاً مفتوح المصدر بالمعنى المعتمد، وقد شرحنا الفرق في [البرمجيات مفتوحة المصدر وتراخيصها](https://arabroot.io/articles/%D9%85%D8%A7-%D9%87%D9%8A-%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D9%8A%D8%A7%D8%AA-%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-%D8%A7%D9%84%D9%85%D8%B5%D8%AF%D8%B1-%D9%88%D8%AA%D8%B1%D8%A7%D8%AE%D9%8A%D8%B5%D9%87%D8%A7/).

- **نقاط القوة:** أبسط بكثير في التشغيل، ويناسب من يشغل خليطاً من Containers وبرامج تقليدية.
- **نقاط الضعف:** الترخيص، ومنظومة أصغر، وتحتاج غالباً Consul وVault بجانبه للخدمات والأسرار.

### K3s على سيرفر واحد

K3s توزيعة Kubernetes كاملة ومعتمدة، تأتي كملف تنفيذي واحد حجمه أقل من 100 ميغابايت، ومعها containerd وشبكة Flannel وCoreDNS ومتحكم Traefik لدخول الطلبات وموزع حمل بسيط ServiceLB وتخزين محلي local-path-provisioner، وتستخدم SQLite بدلاً من etcd بشكل افتراضي عندما يكون لديك سيرفر واحد، كما في [توثيق K3s](https://docs.k3s.io/?ref=arabroot.io) و[خيارات قاعدة البيانات](https://docs.k3s.io/datastore?ref=arabroot.io)، والحد الأدنى للسيرفر نواتان و2 غيغابايت ذاكرة بحسب [صفحة المتطلبات](https://docs.k3s.io/installation/requirements?ref=arabroot.io)، وآخر إصدار عند كتابة المقال هو v1.37.1+k3s1.

وقد يتساءل البعض: ما فائدة Kubernetes على سيرفر واحد إذا كانت ميزته الأولى التوزيع على عدة سيرفرات؟ والإجابة أن فائدته هنا ليست التوفر العالي، فالسيرفر الواحد ما زال نقطة الفشل الوحيدة، وإنما هي ثلاثة أشياء: أن تتعلم Kubernetes على بيئة حقيقية رخيصة، وأن تكتب ملفات Kubernetes من اليوم الأول فتضيف عقداً لاحقاً دون إعادة كتابة، وأن تستفيد من التحديث التدريجي وفحوص الحياة على سيرفر واحد. وتثبيت K3s على سيرفر واحد هو المقال التالي في هذه المرحلة.

- **نقاط القوة:** Kubernetes حقيقي بكل واجهاته وأدواته، بتكلفة سيرفر واحد.
- **نقاط الضعف:** كل تعقيد Kubernetes المذكور أعلاه موجود ما عدا التوفر العالي، فأنت تدفع ثمن المفاهيم دون أن تحصل على أهم فائدة.

| الطريقة                                   | عدد السيرفرات                             | إذا توقف سيرفر         | التحديث              | ما تتعلمه           |
| ----------------------------------------- | ----------------------------------------- | ---------------------- | -------------------- | ------------------- |
| Compose على سيرفر واحد                    | 1                                         | يتوقف كل شيء حتى تعيده | ثوان من التوقف       | Docker وCompose     |
| Compose على عدة سيرفرات خلف Load Balancer | 2 أو 3                                    | الآخران يخدمان الزوار  | سيرفر بعد سيرفر بيدك | Docker وموزع الحمل  |
| Docker Swarm                              | 3 فأكثر                                   | تنقل النسخ تلقائياً    | تدريجي               | ملف Compose نفسه    |
| Nomad                                     | 3 أو 5 سيرفرات Servers ثم العملاء Clients | تنقل المهام تلقائياً   | تدريجي               | لغة HCL وNomad      |
| K3s على سيرفر واحد                        | 1                                         | يتوقف كل شيء حتى تعيده | تدريجي دون توقف      | Kubernetes كاملاً   |
| Kubernetes بعدة عقد                       | 3 للتحكم ثم العقد العاملة                 | تنقل ال Pods بعد مهلة  | تدريجي مع تراجع      | Kubernetes ومنظومته |

## دليل القرار: ثلاثة أسئلة

الصورة التالية تلخص القرار في ثلاثة أسئلة بالترتيب، والسؤال الثالث هو الذي يقرر في النهاية:

![مخطط قرار من ثلاثة أسئلة: هل يتحمل سيرفر واحد الحمل مع نسخ احتياطي وتقبل بتوقف دقائق؟ نعم تعني Docker Compose على سيرفر واحد مع Coolify أو Dokploy. لا تقود إلى: هل يكفيك سيرفران أو ثلاثة والخدمات قليلة؟ نعم تعني Compose خلف Load Balancer أو Docker Swarm. لا تقود إلى: هل لديك من يملك الوقت لتشغيل العنقود؟ نعم تعني Kubernetes بدءاً ب K3s، ولا تعني Kubernetes مداراً من مزود السحابة أو البقاء على الحل الأبسط، ومربع جانبي: تريد أن تتعلم فقط؟ K3s على سيرفر واحد](https://arabroot.io/content/images/2026/10/k8s-need-04-decision.webp)

الحمل والتوقف المقبول، ثم عدد السيرفرات، ثم من سوف يشغل العنقود

وفي المخطط أعلاه لاحظ التالي:

- السؤال الأول يحسم أغلب الحالات، فالمواقع والأنظمة الداخلية ومعظم تطبيقات الشركات الناشئة في سنتها الأولى تعمل على سيرفر واحد قوي مع نسخ احتياطي، ولا تحتاج أكثر.
- Kubernetes المدار Managed من مزود السحابة يشغل عنك أجزاء التحكم وetcd، وتبقى عليك التطبيقات والتحديث والتخزين والصلاحيات، فهو يخفف البند الثالث ولا يلغيه، وقائمة المزودين والتوزيعات المعتمدة في [صفحة الحلول الجاهزة](https://kubernetes.io/docs/setup/production-environment/turnkey-solutions/?ref=arabroot.io).
- هناك أسباب صحيحة لاختيار Kubernetes حتى مع حمل صغير، مثل مؤسسة لديها فريق منصة يشغل عناقيد لكل الفرق، أو عميل يشترط تسليم التطبيق كملفات Helm، أو عشرات الخدمات الصغيرة التي تنشر كل يوم، وفي هذه الحالات أنت تجيب بنعم عن السؤال الثالث أصلاً.

## إذا قررت أن تبدأ: ترتيب التعلم

إذا كان القرار Kubernetes، أو أردت أن تتعلمه قبل أن تحتاجه، فابدأ بالمصطلحات في [مصطلحات Kubernetes بالرسم](https://arabroot.io/articles/%D9%85%D8%B5%D8%B7%D9%84%D8%AD%D8%A7%D8%AA-kubernetes-%D8%A8%D8%A7%D9%84%D8%B1%D8%B3%D9%85/)، ثم تثبيت K3s على سيرفر واحد، ثم عنقود من ثلاث عقد، ثم Helm، ثم الإعدادات والأسرار، ثم التخزين، ثم الصلاحيات، ثم GitOps مع Argo CD، وهذا هو ترتيب [مرحلة Kubernetes في خريطة الطريق](https://arabroot.io/start/#stage-kubernetes)، وسوف نضيف مقالاتها تباعاً بإذن الله. وقبل كل ذلك تأكد أنك تعرف Docker جيداً كما في [تثبيت Docker على Ubuntu](https://arabroot.io/articles/%D8%AA%D8%AB%D8%A8%D9%8A%D8%AA-docker-%D8%B9%D9%84%D9%89-ubuntu/)، فكل Pod في النهاية Container يعمل من Docker Image.

## الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

- Kubernetes يحل أربع مشكلات: توزيع النسخ على عدة سيرفرات، وإعادتها عند العطل، وتحديثها دون توقف، وإعطاؤها اسماً ثابتاً، وكلها تفقد أغلب قيمتها إذا كان لديك سيرفر واحد.
- Compose يعطيك إعادة التشغيل عند الخروج وعدة نسخ على السيرفر نفسه وملفاً تقرؤه بعينك، وما ينقصه مرتبط كله تقريباً بوجود أكثر من سيرفر.
- تكلفة Kubernetes الحقيقية ليست السيرفرات، وإنما أجزاء التحكم وetcd والشبكة والتخزين والتحديث كل سنة على الأقل، والشخص الذي يعرف كل ذلك.
- Ingress مجمدة والمشروع يوصي ب Gateway API، وIngress NGINX توقف تطويره في مارس 2026، فالمنصة تتغير تحتك حتى لو لم تغير شيئاً.
- بين الطرفين توجد حلول وسط: Compose على بضعة سيرفرات خلف موزع حمل، وDocker Swarm المدعوم حتى 2030 على الأقل عند Mirantis، وNomad بترخيص BSL، وK3s على سيرفر واحد للتعلم.
- القرار في ثلاثة أسئلة: هل يكفي سيرفر واحد؟ هل يكفي سيرفران أو ثلاثة؟ ومن سوف يشغل العنقود؟

[![](https://arabroot.io/content/images/2026/10/k8s-terms-cover-cover-1.webp)دليلمصطلحات Kubernetes مشروحة بالترتيب، من Pod إلى Ingressشرح مصطلحات Kubernetes بالترتيب الذي يبني بعضها على بعض، مع رسم لكل مفهوم وملفات YAML حقيقية.](https://arabroot.io/articles/%D9%85%D8%B5%D8%B7%D9%84%D8%AD%D8%A7%D8%AA-kubernetes-%D8%A8%D8%A7%D9%84%D8%B1%D8%B3%D9%85/)[![](https://arabroot.io/content/images/2026/10/stackoverflow-architecture-cover-cover.webp)دليلكيف بنى Stack Overflow موقعه بسيرفرات قليلة؟كيف خدم Stack Overflow أكثر من مئتي مليون طلب يومياً بعدد قليل من السيرفرات، وما الدروس التي تأخذها منه لمشروعك.](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%A8%D9%86%D9%89-stack-overflow-%D9%85%D9%88%D9%82%D8%B9%D9%87-%D8%A8%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D8%A7%D8%AA-%D9%82%D9%84%D9%8A%D9%84%D8%A9/)[![](https://arabroot.io/content/images/2026/10/system-design-intro-cover-cover.webp)دليلمدخل إلى تصميم الأنظمة: من سيرفر واحد إلى ملايين المستخدمينكيف يكبر متجر إلكتروني من سيرفر واحد إلى نظام يخدم ملايين المستخدمين، وما الثمن الذي تدفعه في كل خطوة.](https://arabroot.io/articles/%D9%85%D8%AF%D8%AE%D9%84-%D8%A7%D9%84%D9%89-%D8%AA%D8%B5%D9%85%D9%8A%D9%85-%D8%A7%D9%84%D8%A7%D9%86%D8%B8%D9%85%D8%A9-%D9%85%D9%86-%D8%B3%D9%8A%D8%B1%D9%81%D8%B1-%D9%88%D8%A7%D8%AD%D8%AF-%D8%A7%D9%84%D9%89-%D9%85%D9%84%D8%A7%D9%8A%D9%8A%D9%86/)[![](https://arabroot.io/content/images/2026/10/compare-platforms-cover-cover-1.webp)مقارنةأي أداة تدير بها تطبيقاتك على السيرفر؟متى تكفيك واجهة تدير بها ال Containers، ومتى تحتاج منصة تنشر تطبيقاتك من Git مباشرة على سيرفرك.](https://arabroot.io/articles/%D9%85%D9%82%D8%A7%D8%B1%D9%86%D8%A9-portainer-%D9%88-coolify-%D9%88-dokploy/)[![](https://arabroot.io/content/images/2026/10/db-clustering-cover-cover.webp)دليلعناقيد قواعد البيانات Database Clustering ومتى تحتاجهاماذا تعني كلمة Cluster في كل قاعدة بيانات، ومتى تحتاج نسخاً أو انتقالاً تلقائياً، ومتى يكفيك سيرفر واحد مع نسخ احتياطية جيدة.](https://arabroot.io/articles/%D8%B9%D9%86%D8%A7%D9%82%D9%8A%D8%AF-%D9%82%D9%88%D8%A7%D8%B9%D8%AF-%D8%A7%D9%84%D8%A8%D9%8A%D8%A7%D9%86%D8%A7%D8%AA-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/)

## سجل التحديثات

- أكتوبر 2026: كتابة المقال، ومراجعة توثيق Kubernetes للإصدار 1.37 وتوثيق Docker وK3s وNomad وإعلان Mirantis عن Swarm، والتحقق من ملف Compose وملف Kubernetes المكافئ بمكتبة PyYAML دون تشغيلهما على عنقود حقيقي.