GitLab Runners على Kubernetes: تحسين التكاليف على نطاق واسع باستخدام مشغل Kubernetes

غوص تقني عميق: GitLab Runners على Kubernetes، تثبيت المشغل، قيم Helm، التوسع التلقائي ونموذج FinOps للتكاليف. للحصول على الإصدار المختصر، اقرأتوقف عن دفع ثمن CI غير النشط.

معظم الفرق تدفع ثمن التكامل المستمر وكأن كل ليلة وكل عطلة لا تزال صباح الاثنين. الخوادم تظل ساخنة. القرص يبقى مخصصًا. لا أحد يدمج أكوادًا — والفاتورة لا تلاحظ ذلك. هذه الجملة ليست شعارًا؛ إنها الشكل الافتراضي لأسطول مشغّلات ثابت.

هذا المقال الطويل هو المرافق التقني لرحلة عملية لـGitLab Server وGitLab Runner على Kubernetes: كيف يحول مشغّل Kubernetes كل مهمة CI إلى حاوية مؤقتة، وكيف يمكّن ذلك من تخصيص وإلغاء تخصيص السعة ديناميكيًا، وكيف يفتح هذا التصميم بابًا لـتوفير هائل في التكاليفباستعادة CPU والذاكرة والتخزين عندما ينهار الطلب بين عشية وضحاها وفي عطلة نهاية الأسبوع.

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

1. المشغّلات والأنابيب— توسيع أحمال GitLab Runner تلقائيًا باستخدام Kubernetes.

شاهد: GitLab Runners وCI/CD على Kubernetes بشكل كامل· الإصدار المبسط:توقف عن دفع ثمن CI غير النشط

2. خادم GitLab على HA Kubernetes— قم بتنفيذ GitLab باستخدام المشغل خلال دقائق قليلة.

شاهد: قم بتنفيذ GitLab في مجموعة HA Kubernetes باستخدام المشغل· الوثائق:تثبيت مشغل GitLab

1. الأطروحة

GitLab على Kubernetes + مشغل Kubernetesيغير وحدة سعة CI من "آلة نمتلكها طوال الشهر" إلى "حاويات (و عُقَد) نؤجرها للعمل". يبقى مدير التشغيل المستمر صغيرًا ودائمًا نشطًا. تظهر حاويات التشغيل المستمر لبناء معين ثم تختفي بعد ذلك. مع التوسع التلقائي للمجموعة، تتبع عُقَد العمال نفس المنحنى. هكذا تحمي الإنتاجية في صباح يوم الاثنين وتتوقف عن دفع أسعار صباح يوم الاثنين ليوم الثلاثاء الساعة 03:00 ولأيام السبت الهادئة.

في سطر واحد — نفس السطر في الدليل المبسط:قم بتوفير الموارد لذروة الحمل، وقم بإلغاء توفيرها لحدود الحمل.

2. عادة التكلفة العالية، التي تُصنف كعيب معماري

CI التقليدي غالبًا ما يبدو كأسطول دائم: مجموعة ثابتة من آلات البناء التي تبقى «للتأمين». هذا النهج يعمل عندما يكون الزخم مستقرًا. لكنه يهدر المال عندما يكون الطلب متقطعًا.

• نهارًا:المطورون يفرغون الفروع، يفتحون طلبات الدمج، ويشغّلون الاختبارات — يزداد الطلب.
• المساء والليل:ينخفض النشاط؛ والآلات لا تزال تستهلك CPU والذاكرة العشوائية.
• عطلة نهاية الأسبوع:غالبًا شبه خامل — ومع ذلك قد لا تزال أحجام التخزين والعُقد السحابية محجوزة ومُفوترة.

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

3. خريطة النظام

التشبيه من الدليل البسيط لا يزال ساريًا على هذه الطبقة: GitLab Runner هو العامل؛ Kubernetes هو الموزع الذي يستدعي العمال فقط عندما تصل الطرود (المهام)، ثم يرسلهم إلى منازلهم.

4. تثبيت GitLab على المجموعة (مسار المشغل)

مسار التدريب في اليوم الأول يقوم بتثبيت GitLab باستخدام المشغل الرسمي، بحيث يشارك الخادم نفس Kubernetes الأساس الذي تستخدمه الوحدات الفرعية. يشرح الفيديو المرافقنشر GitLab في مجموعة Kubernetes عالية التوفر باستخدام المشغلعملية التثبيت خلال دقائق معدودة. المتطلبات المسبقة: مجموعة مزودة بـ ingress و Helm وkubectlو cert-manager عندما يدير الرسم البياني TLS.

helm repo add gitlab https://charts.gitlab.io
helm repo update

helm install gitlab-operator gitlab/gitlab-operator \
  --create-namespace \
  --namespace gitlab-system

kubectl -n gitlab-system get deployment gitlab-controller-manager

# Apply the GitLab custom resource (pin chart version in the manifest)
kubectl -n gitlab-system apply -f deploy_gitlab_server.yaml

نموذج CR (يمكنك تخصيص النطاق و البريد الإلكتروني للمصدر ليناسب بيئتك):

apiVersion: apps.gitlab.com/v1beta1
kind: GitLab
metadata:
  name: gitlab
spec:
  chart:
    version: "9.2.2"
    values:
      global:
        hosts:
          domain: "example.com"
        ingress:
          configureCertmanager: true
      certmanager-issuer:
        email: you@example.com

يستغرق التثبيت الأولي عادةً ما بين 10 إلى 15 دقيقة بينما تستقر مكونات الخدمة الجانبية و Sidekiq وقواعد البيانات والمكونات ذات الصلة. احصل على كلمة المرور الجذرية الأولية من السري في المجموعة:

kubectl get secret gitlab-gitlab-initial-root-password -n gitlab-system \
  -o jsonpath='{.data.password}' | base64 -d

المرجع:تثبيت مشغل GitLab(تبويب Helm على تلك الصفحة). نظرة عامة على الرسم البياني:docs.gitlab.com/charts· دليل التثبيت:تثبيت الرسم البياني.

5. GitLab Runner مع Kubernetes كمُنفِّذ

GitLab Runner هو التطبيق الذي يعمل مع GitLab CI/CD لتشغيل المهام في خط الأنابيب. معKubernetes كمُنفِّذ، لا يقوم المدير بالتجميع على نفسه. بالنسبة لكل مهمة يقوم بـ:

1. إنشاء حاوية (بالإضافة إلى حاويات المساعدة/الخدمة حسب الإعداد).
2. إرسال السجلات مرة أخرى إلى GitLab.
3. جمع المنتجات النهائية وحالة الخروج.
4. حذف الحاوية — مما يعيد CPU والذاكرة إلى المجموعة.

يمثل حلقة الإنشاء/التشغيل/الحذف أول رافعة للتكلفة. يجب ألا تترك الأعمال المنجزة آلة دافئة مخصصة طوال الليل.

نمط التثبيت 5.1 لـ Helm

تُنشئ سكريبتات التدريب مساحة أسماء، وتُمرر رمز تسجيل، وقد تقوم بتثبيت أكثر من إصدار (على سبيل المثال، مشغّلات تعتمد على Alpine وأخرى تعتمد على Ubuntu) حتى يتمكن الوظائف من اختيار بيئات مختلفة. الإجراء الرسمي:قم بتثبيت GitLab Runner باستخدام الرسم البياني Helm; مرجع القيم:قم بتكوين رسم بياني GitLab Runner Helm.

helm upgrade --install --namespace gitlab-runner gitlab-runner-alpine \
  -f config-runner-alpine.yaml \
  --set serviceAccount.create=true \
  gitlab/gitlab-runner \
  --create-namespace

احصل على الرموز من واجهة GitLab (مشغّلات المجموعة/المشروع/المنشأة) أو من الأسرار التي يديرها المشغّل. تفضّل رموز المصادقة الحديثة للمشغّلات؛ رموز التسجيل قديمة وستُزال مع GitLab 18.لا تُلخّص أبدًا الرموز النشطة— قد تحتوي سكريبتات المختبر على رموز افتراضية يجب استبدالها محليًا.

5.2 القيم التي تهم على مستوى النطاق والعزل

من قوالب Workstation (gitlab-runner-values-template.yaml/ تم إنشاؤهاconfig-runner-*.yaml):

gitlabUrl: http://gitlab-webservice-default.gitlab-system.svc.cluster.local:8080/
concurrent: 2
rbac:
  create: true
  clusterWideAccess: true
runners:
  privileged: true
  config: |
    [[runners]]
      environment = ["GIT_SSL_NO_VERIFY=1"]
      [runners.kubernetes]
        namespace = "gitlab-runner"
        image = "alpine/git:latest"
        service_account = "gitlab-runner"
        privileged = true

التزامن بدون CPU يطيل فقط طابور الانتظار. اقترنconcurrentمع مساحة رأسية حقيقية للعقد أو توسيع العقد التلقائي.

6. التوسع التلقائي على مستويين (في الواقع أربعة)

"توسيع GitLab Runners تلقائياً على Kubernetes" ليس مفتاحاً واحداً. ضع هذه المقابض فوق بعضها:

1. مرونة وحدات عمل الحاويات (Job pods)— مدمجة في مشغل Kubernetes. صفر مهام → صفر وحدات عمل مهام. هذا وحده يلغي معظم الهدر لكل مهمة على عناقيد مشتركة.
2. المشغلconcurrentوعمليات نشر متعددة للمشغلات— افصل بين alpine و ubuntu (أو CPU والمُصنِّعين الأكبر) حتى لا تبقى سعة متخصصة خاملة لخلط غير مناسب.
3. توسيع العناقيد/العُقَد تلقائياً— تضيف العُقَد الحاويات المعلقة؛ تغادر العُقَد الفارغة بعد الذروة المسائية.
4. سياسة اختيارية واعية بالجدول الزمني— خفض حدود التوازي أو توسيع مجموعات العُقَد على تقويم ليالي/أيام عطلة كإجراء احتياطي إضافي فوق الانهيار الطبيعي للطلب.

القصة نفسها تنطبق على التوسع الضخم مع سعة أكبر: وفرِّد للصفوف العميقة، ثم أزل الموارد بنشاط حتى لا تشبه النصف الهادئ من الأسبوع النصف المزدحم في الفاتورة.

6.1 ملاحظة حول "خامل" بمعني GitLab Runner

يحافظ بعض المشغلات على عدد صغير من الآلات الخاملة ساخنة لامتصاص المهمة التالية دون تأخير بدء بارد. على Kubernetes، يكون بدء العمل البارد عادةً بإنشاء حاوية (ثوانٍ)، وليس تشغيل آلة افتراضية (دقائق). تفضّل ترك الحاويات تتجه للصفر وتحمل تأخيراً جدولياً قصيراً بدلاً من الاحتفاظ بقدرة ليلية فارغة "لحالة الطوارئ". إذا اضطررت لرفع أرضية صغيرة، فقم بتعديله واقع الاستدعاء — لا عاصفة اندماج الاثنين.

6.2 توفير وإلغاء التوفير ديناميكيًا من البداية إلى النهاية

تتبع مهمة خط أنابيب واحد:

1. يقوم المطور بالضغط (Push)، ويُنشئ GitLab مهمة في قائمة الانتظار.
2. يُطلب المهمة من قبل مدير الـ Runner ويطلب من API إنشاء Pod.
3. إذا كان العنقود (Cluster) يعاني من نقص في CPU/الذاكرة العشوائية (RAM)، يضيف مقياس التلقائي عقدة (توفير).
4. ينفذ الـ Pod السكريبت، يرفع الملفات الناتجة، ويخرج.
5. يتم حذف الـ Pod؛ تعود الموارد إلى المجموعة (إلغاء التوفير على مستوى المهمة).
6. عندما تجلس العديد من العقد فارغة بعد عتبة التقليل — وهو أمر شائع بعد المساء طوال عطلة نهاية الأسبوع — تغادر العقد (إلغاء التوفير على مستوى البنية التحتية).

هذا الحلقة الكاملة هي ما يقصده الفيديو بـ "Runners GitLab على نطاق ضخم" لتحقيق تحسين التكلفة: ليس مجرد علم (Flag) واحد متقن، بل دورة حياة المهمة + مرونة العنقود يعملان معًا.

7. نموذج التكلفة: حيث تظهر الوفورات الكبيرة بالدولار

كن دقيقًا. لا يجعل التوسع التلقائي عمليات البناء مجانية. إنه يمنعك من دفع أسعار الذروة خلال ساعات غير الذروة. تأتي الوفورات من مطابقة الإنفاق مع الطلب الحقيقي — النقاط الأربعة من الدليل المبسط، موسعة للمشغلين.

7.1 قم بالتوسع فقط عندما يعمل الناس (أو الروبوتات)

عندما يحل صباح مزدحم بعشرات خطوط الأنابيب، يُجدول Kubernetes العديد من Pods المهام بالتوازي حتى حدود التوازي وحدود العنقود. يظهر الإنتاجية عندما يكون ضغط الدمج حقيقيًا.

7.2 قلل الحجم بشدة عندما يختفي الطلب

عندما تنتهي المهام، تختفي الحاويات. مع توسيع العنقود تلقائيًا (أو مجموعة عقد بحجم مناسب)، تغادر العقد السحابية غير المستخدمة المجموعة. الليالي والأيام العطلية — وهي عادةً النوافذ الأكثر هدوءًا لفِرق المنتجات — هي أول سعة يجب أن تتوقف عن دفع ثمنها.

7.3 توقف عن إهدار CPU والذاكرة والتخزين

على مدار شهر، تهيمن الساعات الهادئة على المؤقت. استعادة الليالي والأيام العطلية هي حيث تتراكمتوفيرات الدولار.

7.4 ادفع مقابل النتائج، لا مقابل الأثاث

لا تزال تدفع مقابل GitLab ولوحة تحكم رقيقة (مدير التشغيل الافتراضي + أساسيات العنقود). ما تتوقف عن دفع ثمنه هو مستودع من الكراسي الفارغة.

7.5 الحدس العملي (ليس معيارًا مصطنعًا)

افترض أن النهار يحتاج بشكل مستدام إلى ما يعادل 20 فتحة مشغّل نشطة، بينما الليل والأيام العطلية تحتاج 2. أسطول ثابت بحجم 20 يدفع ثمن 20 على مدار الساعة. حوض مرن يدفع ثمن ~20 خلال النهار و~2 (بما في ذلك مستوى التحكم) عندما يكون الهدوء. بالنسبة لكثير من فرق المنتجات، تشكل ساعات الهدوء نسبة كبيرة من الشهر — لذا فإن استردادها هو كيف تصبحكبيرةدون اختراع نسبة تسويقية. يضاعف المالية أسعار ساعة العقدة المحلية؛ وظيفة الهندسة المعمارية هي جعل الساعات الفارغة حقًا فارغة في حساب الفواتير.

تظهر وفورات التكلفة الكبيرة عندما لا يحدد ذروة يوم الاثنين فاتورة يوم الثلاثاء في الساعة 3 صباحًا — وعندما تبدو صمت يوم السبت أخيرًا هادئًا على الفاتورة أيضًا.

7.6 ما تدفعه عمدًا

• مكونات سيرفر GitLab — حجمها للمستخدمين وتنسيق CI، وليس لمزرعة التجميع.
• مدير Runner Deployment(s) — صغير مقارنة بمزارع الوظائف.
• ذاكرات التخزين المؤقت المتعمدة (وكيل الاعتماديات، PVCs) — مفيدة، لكنها بحجم محدد؛ ذاكرات التخزين المؤقت ليست تخزينًا مجانيًا.
• DinD ذو الامتيازات — مريح وأثقل؛ فكر في Kaniko/BuildKit عندما تكون الكثافة والعزل أكثر أهمية من الألفة.

8. خطوط الأنابيب CI/CD في الممارسة العملية

مع تشغيل العدّائين عبر الإنترنت، يُعرّف.gitlab-ci.ymlالمراحل والوظائف. يُجدّز GitLab؛ ويُحقّق Kubernetes العدّاء حاويات. حافظ على دقة خطوط الأنابيب فيما يتعلق بالتكلفة:

• أخفِض السرعة سريعًا على lint/unit قبل بناء الصور الثقيلة.
• استخدمrules/workflowحتى لا تتفرّع الفروع المسودة عبر مصفوفات كاملة.
• اعتمد على التخزين المؤقت المشترك بمفاتيح واضحة بدل نمو القرص لكل آلة افتراضية دون حدود.
• وسمّ الوظائف بالبركة المناسبة من العدّائين (alpine مقابل ubuntu، مصمّرات صغيرة مقابل كبيرة).

stages: [lint, test, build]

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

lint:
  stage: lint
  image: alpine:3.19
  script:
    - echo "cheap checks first"

test:
  stage: test
  tags: [kubernetes, alpine]
  script:
    - echo "unit tests"

build:
  stage: build
  tags: [kubernetes, dind]
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  script:
    - echo "heavy image build only on default branch"

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

9. ملاحظات الأمان والإيجار

تحسّن الحاويات المؤقتة النظافة (حالة أقلّ لاصقة) لكن DinD المُفضّل والـ RBAC على مستوى العنقود يمكن أن يوسّع نطاق الانفجار. الافتراضات العملية لمعظم الفرق:

• شغّل حاويات الوظائف في مساحة مخصصة مع ResourceQuotas و LimitRanges.
• اعتمد على البناء غير المُفضّل قدر الإمكان؛ عزّل عدّائين DinD خلف وسمّات محددة.
• تجنّب تحميل بيانات اعتماد سحابية طويلة الأمد في كل وظيفة؛ حقّن رموزًا قصيرة الأمد لكل خط أنابيب.
• معالج رموز تسجيل العدّائين كسرّيات — دوّرها عند مغادرة الأشخاص أو مشاركة المختبرات.
• إذا شاركت عدة فرق عنقودًا، افصِل مديري العدّائين (وباختيار مجموعات العقد) حتى لا يبقّي جارٌ ضاغط كامل المزرعة ساخّنًا — واحفظ قصة التكلفة قابلةً للنسبة لكل فريق.

10. قابلية المراقبة التي تثبت الوفورات

لا يمكنك ادعاء الوفورات الليلية وال выходные دون النظر. راقب على الأقل:

إذا انخفضت أعداد الوحدات ليلا لكن فاتورة العقد لا تنخفض، فإن إعدادات التقليل من النطاق — وليس GitLab — هي الدواسة التالية.

11. VMs ثابتة مقابل Kubernetes (جدول قرارات)

اختر VMs ثابتة فقط عندما يكون لديك طلب مسطح 24×7 حقيقي أو قيود تمنع التجميع. الجميع الآخرون مع خطوط أنابيب مدفوعة بالبشر ذات القمم المدفوعة يدفعون ضريبة الأثاث.

12. ما لا تفقده

التوسيع التلقائي لا يعني "لا تحكم". لا تزال تحدد التزامن، الصور المسموح بها، امتيازات DinD، سياسة الشبكة، ونطاق التسجيل. النقطة هي الحفاظ على هذه التحكيمات مع السماح للسعة غير المستخدمة بالتبخر — نفس الطمأنينة كما في القطعة بلغة بسيطة، الآن تُنفَّذ مع RBAC، المساحات، وإصدارات منفصلة للـ runners.

13. قائمة التحقق التشغيلية

1. إصدارات مشغّل الرسم البياني/المخطط؛ قم بالترقية بوعي.
2. دوّر رموز التشغيل؛ امسح رموز المختبر من أي سكريبت قبل النشر.
3. مساحات أسماء منفصلة: نظام GitLab مقابل مهام التشغيل.
4. راقبالقواريرالمعلقة — ارتفاع القوارير المعلقة يعني أن التوازي أو سعة العقد غير كافٍ في ذروة الحمل.
5. راقبساعات العقد الفارغة— بقاء العقد فارغة طوال الليل يعني تأخير في تقليص الحجم أو حاجة لضبط سياسة المجموعة.
6. حدّد مشغّلات الامتيازات إلى المهام التي تحتاجها فقط.
7. احتفظ بنسخ احتياطية لـ GitLab بشكل مستقل عن مرونة تشغيلات التشغيل.
8. راجع الفاتورة حسب ساعة الأسبوع بمجرد تشغيل CI المرن — يجب أن تنخفض الليالي والأيام العطل بشكل واضح.

14. من هذا المنشور موجه إليه

• مهندسو المنصات و SREs الذين يطبقون GitLab CI على Kubernetes.
• قادة DevOps الذين يستبدلون خوادم تشغيل افتراضية دائمة بـ Pods تنفيذية.
• شركاء الهندسة والمالية الذين يحتاجون إلى أن يتصرف CI كخدمة تعتمد على الاستخدام، وليس أثاثًا.

15. وثائق GitLab الرسمية

هذه الصفحات هي المراجع القياسية لتوزيعات Helm وسلوك التوسع المذكور أعلاه. تفضّلها على المقالات المدوَّنة عند تغيير الإصدارات.

خادم GitLab على Kubernetes

• قم بتثبيت مشغل GitLab— مسار تثبيت المشغل + Helm المستخدم في شرح التدريب.
• مخططات GitLab Helm— توثيق مخطط المظلة.
• قم بتثبيت GitLab باستخدام مخطط Helm— عند نشر GitLab عبر المخططات بدلاً من المشغل.
• مخطط gitlab-runner الفرعي (مخطط GitLab)— runner مدمج بجانب GitLab في المخطط الرئيسي (مختلف عن مخطط runner المستقل).

مخطط GitLab Runner Helm

• قم بتثبيت GitLab Runner باستخدام مخطط Helm—helm repo add gitlab، تثبيت/ترقية، ملاحظات مخطط OCI.
• قم بتكوين GitLab Runner باستخدام مخطط Helm—concurrent، قوالب التكوين، RBAC، التخزين المؤقت، خيارات الصور.
• مخطط gitlab-runnervalues.yaml— قيم افتراضية كاملة (بما في ذلك مسودات HPA الاختيارية).

Kubernetes executor وautoscaling

• Kubernetes executor— job pods، helpers، services (مثل DinD)، resource requests، RBAC verbs.
• إعداد autoscaling (Kubernetes executor / chart)— إيقاف pods،[runners.kubernetes.autoscaler]، سياسات الفترة (خامل ليلاً/في عطلة نهاية الأسبوع).
• Autoscaling GitLab Runner— نموذج autoscaling عام (يتضمن أيضًا التوزيعية caching).
• تخطيط وإدارة أسطول GitLab Runner— توسيع وتشغيل على مستوى الأسطول.
• إعداد متقدم (config.toml)— أقسامconcurrentالعالمية وexecutor المدمجة في Helmrunners.config.

مهام CI، builds، وإعدادات runner في GitLab

• إعداد runners في GitLab— التسجيل، tags، run-untagged، runners محمية.
• استخدام Docker لبناء الصور في CI— DinD والبديلات (مُطبّق عندماprivileged/ خدمة Docker مفعّلة في runner values).

للتحكم في التكلفة ليلاً وفي عطلة نهاية الأسبوع، الجمع بين: (1) Kubernetes executor job pods التي تصل إلى صفر، (2) chartconcurrentوسياسات autoscalerمع off-peak، و(3) autoscaling cluster/node بحيث تغادر العقد الفارغة pool — كما هو موصوف في الأقسام 6–7.

16. العودة إلى الفيديو والمستودع

جلسة يوتيوب —GitLab الكامل في حوالي 20 دقيقة. توسيع نطاق GitLab Runner تلقائيًا باستخدام Kubernetes— يوضح GitLab على Kubernetes، والمُشغِّلات عبر Helm، وقصة التكلفة على نطاق واسع: توفير وإلغاء توفير البنية التحتية ديناميكيًا حتى لا تدفع أسعار الذروة في الليالي والأيام العطلات الخاملة. استخدم أمر البناء في هذا المستودعgitlab-runners-k3s-hyperscale-course.prompt.mdمع الوثائق الرسمية أعلاه كمصدر الحقيقة الموثق. للحصول على الإطار غير التقني لنفس الأفكار، انظرتوقف عن دفع تكاليف CI الخامل.

الخاتمة

لا يستضيف Kubernetes فقط مشغِّلات GitLab Runner. عند استخدامه بشكل صحيح، يغيّر اقتصاديات CI:توفير عند الطلب، إلغاء التوفير عند الخمول، استعادة CPU/الذاكرة/التخزين عندما يذهب البشر إلى المنزل. هذا هو نمط النطاق الواسع — متاح لأي فريق مستعد لتبادل الأسطول الدائم بصف من الحاويات.

ابدأ بالفيديو، أقم المشغِّل + المُشغِّل Helm في مختبر، فعّل توسيع نطاق العقد تلقائيًا، ثم افحص ما إذا كان السبت أخيرًا يبدو هادئًا في الفاتورة.

نُشر بواسطةWorkstation.