Kubernetes عبر عدة قارات: k3s وk8s بتوافر عالٍ في مراكز بيانات حول العالم

Kubernetes هو المعيار عندما يُراد للتطبيقات أن تصمد أمام الأعطال وأن تتوسع تلقائياً. غير أن الفكرة التي تتبادر إلى الذهن أولاً، أي مدّ عنقود (Cluster) واحد من Kubernetes ليشمل خوادم في الولايات المتحدة وأوروبا وآسيا، تفشل بسبب تفصيل واحد: etcd، قاعدة البيانات التي يحفظ فيها Kubernetes حالته بالكامل. يبيّن هذا المقال كيف يعمل Kubernetes عبر عدة قارات رغم ذلك، وبطريقة تحتمل تعطل قارة كاملة: عنقود لكل منطقة، ونشر مشترك عبر GitOps، وGeo-DNS يوجّه المستخدمين إلى أقرب منطقة سليمة.

نبني هذه البنية باستخدام k3s، وهي توزيعة Kubernetes خفيفة ومعتمدة بالكامل يمكن تثبيتها في دقائق، ونعرض في النهاية ما الذي يتغير مع Kubernetes التقليدي المُعدّ عبر kubeadm. أما أساسيات التوافر والنصاب (Quorum) وتجاوز الفشل (Failover) عبر عدة مواقع فتجدونها مفصّلة في مقال Docker Swarm عبر ثلاث قارات؛ وهنا نتناول ما يختلف في Kubernetes.

عنقود واحد عبر كل القارات أم عنقود لكل منطقة؟

لتشغيل Kubernetes عبر عدة قارات، البنية الصحيحة هي عنقود لكل منطقة، وليس عنقوداً واحداً يمتد عبر كل القارات. يعمل كل عنقود مستقلاً، وتُنشر العناقيد كلها من مستودع Git نفسه، ويتولى Geo-DNS مع فحوص السلامة (Health Checks) توزيع المستخدمين. وإذا تعطلت منطقة، تتولى المناطق الأخرى العمل دون الحاجة إلى التوافق على حالة عنقود مشتركة عبر المحيط.

لماذا لا يحتمل etcd المسافات البعيدة

يحفظ Kubernetes كل حالة وكل إعداد وكل تغيير في etcd، وهو مخزن مفتاح وقيمة (Key-Value) يعتمد على إجماع Raft. وتحتاج كل عملية كتابة إلى تأكيد من أغلبية أعضاء etcd. يعمل etcd افتراضياً بفاصل نبضات (Heartbeat) قدره 100 ميلي ثانية ومهلة انتخاب مدتها ثانية واحدة، بينما يتراوح زمن انتقال الحزم بين أوروبا وأمريكا الشمالية وآسيا من 80 إلى 250 ميلي ثانية. يمكن رفع هذه القيم، لكن عندها تصبح كل عملية كتابة في العنقود بطيئة، من جدولة Pod إلى حفظ Secret. ووثائق k3s واضحة في هذه النقطة: etcd المدمج غير مدعوم في العناقيد الموزعة عبر عدة شبكات، وينبغي أن تكون جميع الخوادم في الموقع نفسه. كما أن Kubernetes نفسه مصمم بحيث يغطي العنقود الواحد عدة مناطق فرعية (Zones) داخل منطقة واحدة، لا عدة قارات.

مقارنة بين الأنماط الثلاثة

لنهج «عنقود لكل منطقة» ميزة ثانية كثيراً ما يُستهان بها: الخطأ في مستوى التحكم، أو التغيير الخاطئ في العنقود، أو الترقية التي تفشل، لا يصيب في كل مرة إلا منطقة واحدة. ولا يلاحظ مستخدمو المناطق الأخرى شيئاً من ذلك.

k3s أم k8s؟

كلاهما Kubernetes حقيقي، بواجهة API نفسها، وملفات البيان (Manifests) نفسها، والأدوات نفسها. ويكمن الفرق في البنية وفي الجهد المطلوب:

لبنية عنقود لكل منطقة نوصي بـ k3s: فتشغيل ثلاثة عناقيد لا يكون مريحاً إلا إذا كان كل واحد منها بسيطاً. ومن لديه خبرة سابقة مع kubeadm يعتمد البنية نفسها دون تغيير، ويبيّن القسم الخاص بـ kubeadm أدناه الفروق.

البنية: ثلاث مناطق، ثلاثة عناقيد، مدخل واحد

البداية والتوسعة

نقطة البداية ثلاثة خوادم: واحد في الولايات المتحدة، وواحد في أوروبا، وواحد في آسيا، وكل منها عنقود مستقل بعقدة واحدة. إذا تعطل خادم تعطلت منطقته، فيوجّه Geo-DNS مستخدميها إلى المنطقة المجاورة. وهذه المرحلة مصممة بالفعل لتحمّل تعطل قارة كاملة. وفي مرحلة التوسعة تحصل كل منطقة على ثلاثة خوادم في الموقع نفسه، فتصمد عندها كل منطقة بمفردها أمام تعطل خادم واحد، دون الحاجة إلى إعادة توجيه المستخدمين.

مواقع KernelHost المناسبة

تشغّل KernelHost خوادم في مركز بيانات maincubes في فرانكفورت أم ماين، وتقدم خوادم افتراضية في مواقع أخرى في أوروبا وأمريكا الشمالية وآسيا والمحيط الهادئ، منها ثلاثة مواقع في الولايات المتحدة، وكندا، ولندن، وستراسبورغ، ووارسو، وهلسنكي، وسنغافورة، واليابان، وسيدني، ومومباي. القائمة الكاملة موجودة في صفحة مواقع الخوادم. ويستخدم مثال هذا المقال فرانكفورت أم ماين لأوروبا، والساحل الشرقي للولايات المتحدة لأمريكا الشمالية، وسنغافورة لآسيا.

دليل: Kubernetes مع k3s في ثلاث مناطق

يستخدم المثال ثلاثة خوادم تعمل بنظام Debian 12 أو 13: k3s-eu وk3s-us وk3s-asia. العناوين العامة مأخوذة من شبكة التوثيق 203.0.113.0/24، والنطاق هو example.com. استبدلوا كليهما بقيمكم.

الخطوة 1: تجهيز الخوادم في ثلاث مناطق

اطلبوا ثلاثة خوادم في ثلاث مناطق، بمواصفات 2 vCPU و4 GB RAM على الأقل، ليبقى بجانب k3s متسع لتطبيقكم أيضاً. طبّقوا التحصين الأساسي الوارد في قائمة التحقق للخوادم الجذرية الجديدة، واختاروا أسماء مضيفين واضحة الدلالة. يستفيد etcd بشكل ملموس من أقراص SSD السريعة، وأقراص NVMe في خوادم KernelHost تلبي ذلك.

الخطوة 2: تثبيت k3s

على كل خادم من الخوادم الثلاثة تثبّتون k3s بأمر واحد. وبذلك يصبح كل خادم عنقود Kubernetes كاملاً بعقدة واحدة:

curl -sfL https://get.k3s.io | sh -
kubectl get nodes

بعد نحو دقيقة يُظهر الأمر kubectl get nodes العقدة بالحالة Ready. والمكونات المضمّنة هي: Traefik كمتحكم Ingress، وFlannel للشبكة، ومزوّد (Provisioner) لوحدات التخزين المحلية (Volumes).

الخطوة 3: التوسعة إلى ثلاثة خوادم لكل منطقة

إذا أردتم أن تصبح المنطقة نفسها عالية التوافر، فضعوا ثلاثة خوادم في الموقع نفسه. يشغّل الخادم الأول etcd المدمج، وينضم الخادمان الآخران برمز (Token) مشترك. يتطلب etcd عدداً فردياً من الخوادم، ومع ثلاثة خوادم تتحمل المنطقة تعطل خادم واحد:

curl -sfL https://get.k3s.io | K3S_TOKEN=الرمز_السري sh -s - server \
    --cluster-init \
    --tls-san=api.eu.example.com

curl -sfL https://get.k3s.io | K3S_TOKEN=الرمز_السري sh -s - server \
    --server https://203.0.113.21:6443 \
    --tls-san=api.eu.example.com

تحتاج جميع خوادم المنطقة الواحدة إلى الإعدادات نفسها لنطاقات الشبكة والوظائف. ويجب أن تكون المنافذ التالية مفتوحة فيما بينها: من 2379 إلى 2380/TCP لـ etcd، و6443/TCP لواجهة API، و10250/TCP لـ Kubelet، و8472/UDP لشبكة Flannel، أما نحو الخارج فتبقى مغلقة. والرمز سرّ: من يعرفه يستطيع إدخال خوادمه الخاصة إلى العنقود.

الخطوة 4: إعداد الوصول إلى العناقيد الثلاثة

يحفظ k3s بيانات الوصول في /etc/rancher/k3s/k3s.yaml. انسخوا ملف كل عنقود إلى حاسوب العمل لديكم، واستبدلوا فيه 127.0.0.1 بعنوان الخادم، وسمّوا السياقات (Contexts) باسم المنطقة:

kubectl config rename-context default eu
kubectl config use-context eu
kubectl --context us get nodes

واجهة API على المنفذ 6443 هي أقوى مدخل إلى العنقود. اسمحوا بها في جدار الحماية من عنوانكم الخاص أو من VPN فقط، ولا تفتحوها للإنترنت كله أبداً. يحتوي الملف k3s.yaml على شهادة مدير، ويجب حفظه بالعناية نفسها التي تُحفظ بها كلمة مرور الجذر.

الخطوة 5: GitOps مع Flux في كل عنقود

لكي تشغّل المناطق الثلاث التطبيق نفسه بالإصدار نفسه، توضع الحالة المرغوبة في مستودع Git، ويعمل في كل عنقود Flux الذي يحقق هذه الحالة تلقائياً. أي أن كل عنقود يجلب إعداداته بنفسه؛ ولا يوجد خادم نشر مركزي قد يتعطل. وهذه بنية مجرَّبة للمستودع:

apps/
  web/            ملفات البيان المشتركة للتطبيق
clusters/
  eu/             الإعدادات والإصدار لأوروبا
  us/             الإعدادات والإصدار لأمريكا الشمالية
  asia/           الإعدادات والإصدار لآسيا

flux bootstrap git --url=ssh://git@git.example.com/infra/fleet.git --branch=main --path=clusters/eu

نفّذوا الأمر نفسه مع --path=clusters/us و--path=clusters/asia في السياق المعني. ولأن لكل منطقة مجلدها الخاص، يمكنكم نشر إصدار جديد في منطقة واحدة أولاً، ثم في المناطق الأخرى بعد ذلك فقط.

الخطوة 6: وصف التطبيق بحيث يصمد أمام الأعطال

داخل المنطقة الواحدة تضمن ثلاثة أمور أن يصمد التطبيق أمام أعمال الصيانة وتعطل الخوادم: عدة نسخ (Replicas) موزعة على عُقد مختلفة، وفحوص تكتشف الـ Pods المعتلة، وميزانية (Budget) تمنع أن تزيل أعمال الصيانة جميع الـ Pods في الوقت نفسه:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: ScheduleAnyway
          labelSelector:
            matchLabels:
              app: web
      containers:
        - name: web
          image: registry.example.com/web:1.0
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /health
              port: 8080
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /health
              port: 8080
            periodSeconds: 10
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: web

يُخرج فحص الجاهزية (Readiness) الـ Pod من حركة المرور ما دام لا يستجيب، ويعيد فحص الحيوية (Liveness) تشغيله إذا علق. وفي عنقود بعقدة واحدة لا يكون للتوزيع على عدة عُقد أثر بعد، ويبدأ مفعوله تلقائياً حالما تصبح في المنطقة ثلاثة خوادم.

الخطوة 7: Ingress والشهادات

يتولى Traefik المضمّن استقبال الطلبات الواردة. ولأن المناطق الثلاث تخدم النطاق نفسه، احصلوا على شهادات TLS باستخدام cert-manager عبر تحدي DNS: فهو يعمل في كل منطقة بغض النظر عن الوجهة التي يشير إليها سجل DNS في تلك اللحظة. أما تحدي HTTP فيفشل في كل منطقة لا يشير إليها السجل في تلك اللحظة. ومن يعمل دون Ingress في Kubernetes يجد الأساسيات في مقال إعداد nginx كوكيل عكسي (Reverse Proxy).

الخطوة 8: إعداد Geo-DNS مع تجاوز الفشل

خدمة DNS تدعم التوجيه الجغرافي (Geo-Routing) وفحوص السلامة توجّه المستخدمين من أوروبا إلى فرانكفورت أم ماين، ومن أمريكا إلى الساحل الشرقي للولايات المتحدة، ومن آسيا إلى سنغافورة، وتتحقق كل 30 إلى 60 ثانية مما إذا كان مدخل كل منطقة يستجيب. وإذا تعطلت منطقة، تتوقف الخدمة عن إعطاء عنوانها. اضبطوا قيمة TTL للسجلات على 60 ثانية، فيكتمل التحويل عادةً بعد دقيقة إلى دقيقتين. ومن يريد إدارة السجلات من داخل العنقود يمكنه استخدام external-dns لذلك.

الخطوة 9: النشر منطقة تلو الأخرى واختبار التعطل

سجّلوا الإصدار الجديد أولاً في مجلد منطقة واحدة، وراقبوا تلك المنطقة بضع دقائق، ثم اعتمدوا الإصدار بعد ذلك للمناطق الأخرى. بهذا لا يصل الخطأ الذي لا يكتشفه أي فحص إلى أكثر من منطقة واحدة. ولتجربة تعطل منطقة، أوقفوا k3s على خادمها، وتحققوا في أثناء ذلك مما إذا كان Geo-DNS يُخرج المنطقة من إجاباته وما إذا كانت المنطقة المجاورة تتحمل الحمل:

systemctl stop k3s
systemctl start k3s

وفي منطقة بثلاثة خوادم جرّبوا إضافة إلى ذلك صيانة خادم منفرد. ينقل kubectl drain الـ Pods مع مراعاة الميزانية من الخطوة 6، ويعيد kubectl uncordon الخادم إلى الخدمة:

kubectl drain k3s-eu-2 --ignore-daemonsets --delete-emptydir-data
kubectl uncordon k3s-eu-2

البيانات عبر المناطق

يوزّع Kubernetes الـ Pods، لا البيانات. يقع PersistentVolume الذي ينشئه المزوّد المضمّن على عقدة واحدة بالضبط، ولا يوجد بين العناقيد افتراضياً أي تخزين مشترك للبيانات إطلاقاً. لذلك ينطبق على كل ما يتعلق بالبيانات ما ينطبق على أي عنقود يمتد عبر عدة مواقع:

• قواعد البيانات تتولى النسخ المتماثل بنفسها. والنهج المجرَّب هو مثيل أساسي (Primary) في منطقة واحدة مع نسخ متماثلة (Replicas) في المناطق الأخرى؛ وتدعم مشغّلات قواعد البيانات (Operators) مثل CloudNativePG لـ PostgreSQL هذه النسخ المتماثلة حتى عبر حدود العناقيد. عبر القارات يجري النسخ المتماثل بشكل غير متزامن، وفي حالة الطوارئ قد تُفقد عمليات الكتابة التي جرت في الثواني الأخيرة. وللكتابة دون أي فقدان على مستوى العالم توجد قواعد بيانات مصممة لعدة مناطق مثل CockroachDB أو YugabyteDB.
• الملفات والمرفوعات مكانها تخزين كائنات متوافق مع S3، مع نسخ متماثل إلى منطقة ثانية.
• الجلسات تُحفظ في قاعدة بيانات أو ذاكرة تخزين مؤقت (Cache) منسوخة تماثلياً، أو يستخدم التطبيق رموزاً موقّعة (Signed Tokens).
• النسخ الاحتياطية تبقى إلزامية، لأن النسخ المتماثل ينشر الأخطاء كما ينشر البيانات السليمة. ولكائنات Kubernetes ووحدات التخزين (Volumes) يناسب Velero، وللأساسيات راجعوا استراتيجية النسخ الاحتياطي للخوادم.

Kubernetes مع kubeadm بدلاً من k3s

تبقى البنية مع kubeadm كما هي: عنقود لكل منطقة، وGitOps، وGeo-DNS. أما ما يختلف فهو بناء كل عنقود. تثبّتون على جميع العُقد بيئة تشغيل حاويات مثل containerd، إضافة إلى kubeadm وkubelet وkubectl، وتضعون أمام واجهة API الخاصة بالمنطقة موازن تحميل أو عنواناً افتراضياً، مثلاً باستخدام kube-vip، ثم تهيّئون أول عقدة لمستوى التحكم:

kubeadm init --control-plane-endpoint "api.eu.example.com:6443" --upload-certs

تحتوي المخرجات على أمرَي انضمام: أحدهما مع --control-plane --certificate-key لعقدتَي مستوى التحكم الإضافيتين، والآخر لعُقد Worker. بعد ذلك تثبّتون إضافة شبكة مثل Calico أو Cilium، ومتحكم Ingress، وهو ما يأتي مضمّناً مسبقاً في k3s. ويستحق الجهد الإضافي العناء إذا كنتم بحاجة إلى اختيار مكونات بعينها بدقة، أو إلى البقاء قريبين من الإصدار الأصلي (Upstream).

لماذا KernelHost لتشغيل Kubernetes عبر عدة قارات

تجدون نظرة عامة على جميع باقات السحابة ومقارنة للتكاليف مع كبار مزودي السحابة في صفحة استئجار خوادم سحابية.

أخطاء شائعة وكيف تتجنبونها

• مدّ etcd عبر القارات. والنتيجة عمليات كتابة بطيئة وانتخابات غير مستقرة، وفي k3s مع etcd المدمج هذا غير مدعوم. الحل: عنقود لكل منطقة.
• خادمان في منطقة واحدة. يحتاج etcd إلى أغلبية، والخادمان لا يتحملان أي تعطل. الحل: خادم واحد أو ثلاثة.
• واجهة API مفتوحة للإنترنت كله. المنفذ 6443 هو المفتاح الرئيسي للعنقود. الحل: الوصول من عنوانكم الخاص فقط أو عبر VPN.
• خادم نشر مركزي. إذا تعطل، يتعذر نشر أي شيء. الحل: Flux في كل عنقود، يجلب ما يحتاجه من Git بنفسه.
• التحديث في جميع المناطق في وقت واحد. عندها يصيب الخطأ جميع المستخدمين. الحل: منطقة تلو الأخرى عبر المجلدات في المستودع.
• الشهادات عبر تحدي HTTP. يفشل التجديد في المناطق التي لا يشير إليها سجل DNS في تلك اللحظة. الحل: تحدي DNS.
• قاعدة بيانات على وحدة تخزين محلية (Volume) دون نسخ متماثل. إذا تعطلت العقدة، يتعذر الوصول إلى البيانات. الحل: النسخ المتماثل عبر مشغّل قاعدة بيانات (Operator).
• لا فحوص (Probes) ولا ميزانية. تستمر الـ Pods المعتلة في تلقي حركة المرور، وتُخرج أعمال الصيانة جميع الـ Pods من الخدمة في وقت واحد. الحل: فحص الجاهزية (Readiness) وفحص الحيوية (Liveness) إضافة إلى PodDisruptionBudget.

الخلاصة باختصار

• لتشغيل Kubernetes عبر عدة قارات، الصواب هو عنقود لكل منطقة، أما العنقود الواحد عبر كل القارات فيفشل بسبب زمن التأخير (Latency) في etcd.
• نقطة البداية ثلاثة خوادم، واحد في كل من الولايات المتحدة وأوروبا وآسيا؛ وهذه المرحلة وحدها تصمد أمام تعطل قارة كاملة.
• في مرحلة التوسعة تحصل كل منطقة على ثلاثة خوادم في الموقع نفسه، فتصمد كل منطقة أيضاً أمام تعطل خوادم منفردة.
• ينشر Flux في كل عنقود التطبيق من مستودع Git نفسه، منطقة تلو الأخرى.
• يوجّه Geo-DNS، مع فحوص السلامة وقيمة TTL قصيرة، المستخدمين إلى أقرب منطقة سليمة، وتُستخرج الشهادات عبر تحدي DNS.
• يوزّع Kubernetes الـ Pods، لا البيانات: تحتاج قواعد البيانات إلى نسخ متماثل خاص بها، والنسخ الاحتياطية تبقى إلزامية.
• k3s هو في الغالب الخيار الأفضل من kubeadm لهذه البنية، لأن تشغيل ثلاثة عناقيد بسيطة أسهل من تشغيل ثلاثة عناقيد معقدة.