أساسيات Kubernetes لتطبيقات الأعمال

أساسيات Kubernetes لتطبيقات الأعمال

يُعدّ Kubernetes (ويُختصر غالبًا إلى "K8s") المعيار القياسي لتشغيل التطبيقات المعتمدة على الحاويات في بيئة الإنتاج. وبالنسبة للأعمال، فإن القيمة ملموسة: فهو يُبقي تطبيقك يعمل عند تعطّل أحد الخوادم، ويوسّعه عند زيادة الحِمل، ويطرح إصدارات جديدة دون توقّف، ويمنح فريقك طريقة واحدة متّسقة لتشغيل كل شيء، من واجهة برمجة الفوترة إلى بوابة العملاء.

يشرح هذا الدليل اللبنات الأساسية، ويمرّ بنشر فعلي يمكنك نسخه، ويوضّح كيفية تشغيله على بنية تحتية داخل المملكة بحيث تبقى بياناتك خاضعة لمتطلبات نظام حماية البيانات الشخصية السعودي (PDPL) والهيئة الوطنية للأمن السيبراني (NCA) والهيئة السعودية للبيانات والذكاء الاصطناعي (SDAIA).

لماذا قد تستخدم الأعمال Kubernetes

لست بحاجة إلى Kubernetes من أجل موقع صغير واحد. تبدأ الحاجة إليه عندما يكون لديك عدة خدمات، أو بيئات متعددة، أو التزامات بزمن التشغيل. والفوائد العملية هي:

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

المكوّنات الأساسية بلغة واضحة

كل شيء في Kubernetes هو كائن تصريحي تصِفه بصيغة YAML، ويعمل العنقود باستمرار لجعل الواقع مطابقًا لما صرّحت به.

نادرًا ما تنشئ الـ pods مباشرة، بل تنشئ Deployment، وهو يدير الـ pods نيابةً عنك.

مثال عملي

فيما يلي نشر كامل ومبسّط لتطبيق ويب عديم الحالة خلف خدمة. احفظه باسم app.yaml.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  labels:
    app: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:1.27
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "250m"
              memory: "256Mi"
          readinessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 3
            periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 80
  type: ClusterIP

هناك أمران يستحقّان الفهم هنا. حقل selector هو الطريقة التي يعثر بها كلٌّ من الـ Deployment والـ Service على الـ pods الخاصة بهما: فهما يتطابقان على الوسم app: web وليس على الأسماء. كما يُخبر readinessProbe كوبرنيتس بألّا يرسل الحركة إلى الـ pod حتى تستجيب فعليًا على المنفذ 80 — وهذا ما يجعل التحديثات المتدرّجة آمنة.

طبّقه وراقب تقاربه نحو الحالة المطلوبة:

kubectl apply -f app.yaml
kubectl get pods -l app=web
kubectl rollout status deployment/web

سترى ثلاث pods تصل إلى الحالة Running. أوقف إحداها لترى التعافي الذاتي:

kubectl delete pod -l app=web --field-selector=status.phase=Running --grace-period=0 | head -1
kubectl get pods -l app=web   # يجري بالفعل إنشاء بديل

التوسّع والإصدارات الآمنة

التوسّع يتمّ بسطر واحد، وهو نفس الأمر الذي قد تُؤتمته لاحقًا:

kubectl scale deployment/web --replicas=6

ولإطلاق إصدار جديد، غيّر صورة الحاوية فيُنفّذ Kubernetes تحديثًا متدرّجًا — يُشغّل الـ pods الجديدة ويُزيل القديمة فقط عندما تجتاز الجديدة فحص الجاهزية:

kubectl set image deployment/web web=nginx:1.27.1
kubectl rollout status deployment/web
# إذا حدث خطأ ما:
kubectl rollout undo deployment/web

ولأنماط حركة الإنتاج، أضف HorizontalPodAutoscaler ليضيف العنقود نسخًا متماثلة تلقائيًا بناءً على استهلاك المعالج:

kubectl autoscale deployment/web --min=3 --max=10 --cpu-percent=70

التهيئة والأسرار

أبقِ التهيئة خارج صورة الحاوية، واحقنها وقت التشغيل:

kubectl create configmap web-config --from-literal=APP_ENV=production
kubectl create secret generic web-secret --from-literal=DB_PASSWORD='change-me'

ثم أشِر إليهما في مواصفات الـ pod عبر envFrom. يتيح هذا تشغيل نفس الصورة دون تغيير عبر الاختبار والإنتاج، مع إدارة بيانات الاعتماد بشكل منفصل ودون تضمينها في البناء أبدًا.

تشغيله داخل المملكة

بالنسبة للأعمال في السعودية ودول الخليج، فإن مكان تشغيل العنقود لا يقلّ أهمية عن طريقة تشغيله. فبموجب نظام حماية البيانات الشخصية (PDPL)، ينبغي عمومًا معالجة البيانات الشخصية للمقيمين في السعودية مع مراعاة توقّعات صاحب البيانات وقواعد النقل المعمول بها، كما تدفع أطر NCA وSDAIA الأعباء التشغيلية الخاضعة للتنظيم نحو الاستضافة داخل المملكة. وتشغيل عُقدك ووحدات التخزين الدائمة ونُسخك الاحتياطية داخل مركز بيانات سعودي يُبقي تلك البيانات مقيمة محليًا ويبسّط عمليات التدقيق.

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

وأول عنقود معقول لمعظم الأعمال هو ثلاث عُقد عمل صغيرة: يكفي للصمود أمام تعطّل عقدة واحدة ولاختبار التحديثات المتدرّجة بواقعية دون إفراط في الإنفاق.

قائمة بدء عملية

1. ابدأ بتحويل خدمة عديمة الحالة واحدة إلى حاوية، واترك قواعد البيانات على تخزين مُدار في البداية.
2. اكتب Deployment + Service مثل المثال أعلاه واحصل على rollout status نظيف.
3. أضف فحوص الجاهزية وطلبات/حدود الموارد — فهذه هي ما يجعل العنقود ينضبط في سلوكه.
4. انقل التهيئة إلى ConfigMaps وSecrets.
5. أضف الموسِّع التلقائي وIngress بعد استقرار الأساسيات.

ابدأ على Skyline Cloud

يمكنك تجهيز عُقد العمل، وربط التخزين داخل المملكة، وإبقاء بياناتك تحت الولاية القضائية السعودية في دقائق. أنشئ حساب Skyline Cloud وانشر أول عنقود لك ولديك دعم محلي يساندك.