Kubernetes पर GitLab Runners: Kubernetes एक्जिक्यूटर के साथ हाइपरस्केल लागत अनुकूलन

तकनीकी गहरी समीक्षा: Kubernetes पर GitLab Runners, ऑपरेटर इंस्टॉल, Helm मान्यताएँ, ऑटोस्केलिंग और FinOps लागत मॉडल। संक्षिप्त संस्करण के लिए, पढ़ेंनिष्क्रिय CI के लिए बिल न भरें।

अधिकांश टीमें निरंतर एकीकरण (CI) के लिए भुगतान करती हैं मानो हर रात और हर छुट्टी का दिन अभी भी सोमवार की सुबह हो। सर्वर गर्म रहते हैं। डिस्क आवंटित रहती है। कोई कोड मर्ज नहीं कर रहा — और बिल को फर्क नहीं पड़ता। वह वाक्य एक नारा नहीं है; यह एक स्थिर रनर फ्लीट की निरंतर आकृति है।

यह लंबा लेख Kubernetes परGitLab सर्वर और GitLab Runnerके एक हस्तक्षेप-आधारित गाइड के तकनीकी साथी है: यह कैसे Kubernetes एक्जिक्यूटर प्रत्येक CI जॉब को एक क्षणिक पॉड में बदल देता है, यह कैसे क्षमता के गतिशील प्रोविजन और डि-प्रोविजन को सक्षम करता है, और यह डिज़ाइन कैसेविशाल लागत बचतको अनलॉक करता है CPU, RAM और स्टोरेज को जब मांग रात और हफ्ते के छुट्टी के दिन गिर जाती है।

दोनों सत्रों को पहले देखें, फिर इस पृष्ठ को लिखित आर्किटेक्चर और लागत मॉडल के रूप में उपयोग करें।

1. रनर्स और पाइपलाइंस— Kubernetes का उपयोग करके GitLab Runner वर्कलोड्स का ऑटोस्केलिंग।

देखें: पूर्ण GitLab Runners और CI/CD पर Kubernetes· सरल भाषा संस्करण:निष्क्रिय CI के लिए बिल न भरें

2. HA पर GitLab सर्वर Kubernetes— Operator के साथ कुछ मिनटों में GitLab डिप्लॉय करें।

देखें: Operator का उपयोग करके HA Kubernetes क्लस्टर में GitLab डिप्लॉय करें· दस्तावेज़:GitLab ऑपरेटर इंस्टॉलेशन

1. प्रस्ताव

Kubernetes पर GitLab + Kubernetes एक्जिक्यूटरCI क्षमता की इकाई को "महीने भर हमारे पास रहने वाली मशीन" से "जोब के लिए किराए पर लिए गए पॉड्स (और नोड्स)" में बदल देता है। रनर मैनेजर छोटा रहता है और हमेशा ऑन रहता है। जॉब पॉड्स एक बिल्ड के लिए आते हैं और उसके बाद गायब हो जाते हैं। क्लस्टर ऑटो-स्केलिंग के साथ, वर्कर नोड्स वही वक्र अपनाते हैं। यही तरीका है जिससे आप मंगल सुबह की प्रोडक्शन क्षमता की रक्षा करते हैं और मंगल सुबह के दामों को मंगल दोपहर 03:00 और शांत शनिवारों के लिए नहीं चुकते।

एक पंक्ति में — आम लोगों के गाइड की उसी पंक्ति में:शिखर के लिए प्रोव्जन करें, न्यूनतम के लिए डि-प्रोव्जन करें।

2. महंगी आदत, जिसे एक वास्तुकला गंध (architecture smell) के रूप में बताया गया है

परंपरागत CI अक्सर एक स्थायी दल (fleet) जैसा दिखता है: एक निश्चित समूह निर्माण मशीनें जो "बस तब के लिए" रहती हैं। यह तब काम करता है जब ट्रैफिक स्थिर होता है। यह तब पैसे बर्बाद करता है जब मांग चोटिदार (spiky) होती है।

• दिन का समय:विकसितकर्ता शाखाएँ धकेलते हैं, मर्ज अनुरोध खोलते हैं, परीक्षण चलाते हैं — मांग चोटिदार होती है।
• शाम और रात:गतिविधि कम हो जाती है; मशीनें अभी भी CPU और RAM जलाती हैं।
• हफ्ते के छुट्टी के दिन:अक्सर लगभग निष्क्रिय — फिर भी स्टोरेज आयतन और क्लाउड नोड्स आरक्षित और बिल किए जा सकते हैं।

आप "किए गए निर्माणों" के लिए नहीं भुगतान कर रहे हैं। आप उस क्षमता के लिए भुगतान कर रहे हैं जो तब भी मौजूद रहती है जब कोई भी उसे उपयोग न करे। स्थिर दल भी चिपके हुए अवस्था (sticky state) जमा करते हैं: "रनर 3 पर काम करता है", विचलित पैकेज, कभी समाप्त न होने वाले कैश। लोचदार पॉड (elastic pods) अपने आप अनुशासन को हल नहीं करते, लेकिन वे सफेद पन्ना (clean-slate) को मानक बना देते हैं।

3. सिस्टम मानचित्र

इस परत पर भी साधारण गाइड से आलोक्या (एनालॉजी) अभी भी लागू रहती है: GitLab Runner वर्कर है; Kubernetes वह डिस्पैचर है जो तब तक वर्करों को कॉल नहीं करता जब तक पैकेट (नौकरी) आते नहीं हैं, फिर उन्हें घर भेज देता है।

4. क्लस्टर पर GitLab स्थापित करना (ऑपरेटर पथ)

डे 1 प्रशिक्षण पथ आधिकारिक ऑपरेटर के साथ GitLab स्थापित करता है ताकि सर्वर रनर्स के समान Kubernetes आधार साझा करे। साथी वीडियोKubernetes क्लस्टर में GitLab को HA में डेप्लॉय करनाउस स्थापना को कुछ मिनटों में चला जाता है। पूर्व शर्तें: एक क्लस्टर जिसमें इंग्रेस, 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· स्थापना मार्गदर्शक:charts installation.

5. Kubernetes एक्जिक्यूटर के साथ GitLab रनर

एक GitLab रनर वह अनुप्रयोग है जो GitLab CI/CD के साथ काम करता है और पाइपलाइन में नौकरियों को चलाने के लिए।Kubernetes एक्जिक्यूटरके साथ, मैनेजर स्वयं पर कंपाइल नहीं करता है। प्रत्येक नौकरी के लिए:

1. एक पॉड बनाता है (जैसा कि कॉन्फ़िगर किया गया है, सहायक/सर्विस कंटेनर भी)।
2. लॉग्स को GitLab में वापस स्ट्रीम करता है।
3. आर्टिफैक्ट्स और एक्जिट स्टेटस एकत्र करता है।
4. पॉड को हटाता है — CPU और RAM को क्लस्टर में वापस कर देता है।

वह बनाने/चलाने/हटाने का लूप पहला लागत लीवर है। समाप्त कार्य रात भर एक गर्म मशीन को समर्पित नहीं छोड़ना चाहिए।

5.1 Helm स्थापना पैटर्न

प्रशिक्षण स्क्रिप्ट एक namespace बनाते हैं, एक रजिस्ट्रेशन टोकन पास करते हैं, और एक से अधिक रिलीज को स्थापित कर सकते हैं (उदाहरण के लिए alpine-based और ubuntu-based runners) ताकि जॉब्स अलग-अलग वातावरण चुन सकें। आधिकारिक प्रक्रिया:Helm चार्ट के साथ GitLab Runner को स्थापित करें; मानों संदर्भ: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 UI (instance / group / project runners) या ऑपरेटर-नियंत्रित सीक्रेट्स से टोकन प्राप्त करें। आधुनिक runner प्रामाणिकरण टोकन को प्राथमिकता दें; रजिस्ट्रेशन टोकन GitLab 18 की ओर पुराने होते जा रहे हैं।कभी भी जीवित टोकन— लैब स्क्रिप्ट कभी-कभी ऐसे प्लेसहोल्डर रखते हैं जिन्हें स्थानीय रूप से बदलना आवश्यक होता है।

5.2 स्केल और इसोलेशन के लिए महत्वपूर्ण मान

Workstation टेम्पलेट्स से (gitlab-runner-values-template.yaml/ generatedconfig-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. दो (वास्तव में चार) स्तरों पर ऑटोस्केलिंग

"Kubernetes पर GitLab Runners का ऑटोस्केलिंग" एक स्विच नहीं है। इन लीवरों को स्टैक करें:

1. जॉब पॉड लचक (elasticity)— यह Kubernetes एक्जिक्यूटर में ही बिल्ट-इन है। शून्य जॉब्स → शून्य जॉब पॉड्स। यह अकेले ही शेअर्ड क्लस्टर पर अधिकांश जॉब-प्रति खर्च को हटा देता है।
2. रनरconcurrentऔर कई रनर डेप्लॉयमेंट्स— अल्पाइन बनाम यूबंटू (या CPU बनाम बड़े बिल्डर) को अलग रखें ताकि विशेषीकृत क्षमता गलत मिश्रण के लिए खाली न रहे।
3. क्लस्टर / नोड ऑटोस्केलिंग— लंबित पॉड्स नोड्स जोड़ते हैं; खाली नोड्स शाम की भागदौड़ के बाद बाहर निकलते हैं।
4. वैकल्पिक समय-संवेदनशील नीति— रातों/हफ्ते के अंत में कैलेंडर पर कंसर्रेंट कैप्स कम करें या नोड पूल स्केल करें, जो प्राकृतिक मांग पतन पर बेल्ट-एंड-ब्रैस के रूप में काम करता है।

हाइपरस्केल वही कहानी है लेकिन तीव्र आयाम के साथ: गहरी कतारों के लिए फैलें, फिर कठोर रूप से डिप्रोव्जन करें ताकि हफ्ते की शांत आधी अवधि बिल पर व्यस्त आधी अवधि जैसी न दिखे।

6.1 "खाली" पर एक नोट GitLab Runner के अर्थ में

कुछ एक्जिक्यूटर अगले जॉब को अवशोषित करने के लिए कुछ खाली मशीनों को गर्म रखते हैं ताकि कूल-स्टार्ट लैटेंसी न हो। Kubernetes पर, कूल स्टार्ट आमतौर पर एक पॉड बनाना (सेकंड्स) होता है, न कि एक VM को बूट करना (मिनट्स)। पॉड्स को शून्य पर छोड़ने और थोड़ी योजना-विलंब को स्वीकार करने को प्राथमिकता दें, न कि "बस-एक-बाद" के लिए खाली नोड्स की एक रात-शिफ्ट को बनाए रखने को। यदि आपको एक छोटे फ्लोर को गर्म करना ही पड़े, तो उस फ्लोर का आकार ऑन-कॉल वास्तविकता के लिए रखें — मंगलवार की मर्ज तूफान के लिए नहीं।

6.2 गतिशील प्रदान और निरसन (provision and de-provision) संपूर्ण रूप से

एक पाइपलाइन जॉब का पालन करें:

1. डेवलपर पुश करता है; GitLab पेंडिंग क्यू में एक जॉब बनाता है।
2. रनर मैनेजर जॉब को क्लेम करता है और API से एक पॉड मांगता है।
3. यदि क्लस्टर में CPU/RAM की कमी है, तो ऑटोस्केलर एक नोड जोड़ता है (प्रदान)।
4. पॉड स्क्रिप्ट चलाता है, आर्टिफैक्ट्स अपलोड करता है और बाहर निकल जाता है।
5. पॉड हटा दिया जाता है; संसाधन पूल में वापस जाते हैं (जॉब स्तर पर निरसन)।
6. जब कई नोड्स स्केल-डाउन थ्रेशोल्ड से पार खाली बैठे रहते हैं — आमतौर पर शाम और पूरे हफ्ते के बाद — नोड्स छोड़ देते हैं (इंफ्रास्ट्रक्चर स्तर पर निरसन)।

वह पूरा लूप वीडियो का मतलब है कि हाइपरस्केल पर GitLab Runners लागत अनुकूलन के लिए क्या हैं: कोई भी एक अल्टरनेटिव फ्लैग नहीं, बल्क जॉब लाइफसाइकल + क्लस्टर एलैस्टिसिटी एक साथ काम कर रहे हैं।

7. लागत मॉडल: जहां बड़ी डॉलर बचतें दिखाई देती हैं

सटीक रहें। ऑटोस्केलिंग बिल्ड्स को मुफ्त नहीं बनाती। यह आपको ऑफ-पीक घंटों के लिए शिखर दरों का भुगतान करना बंद कर देती है। बचत वास्तविक मांग के अनुरूप खर्च करने से आती है — साधारण गाइड से चार बिंदु, ऑपरेटर्स के लिए विस्तारित।

7.1 तब ही स्केल अप करें जब लोग (या बॉट्स) काम कर रहे हों

जब एक व्यस्त सुबह कई पाइपलाइनों को जमीन पर लाती है, Kubernetes कई जॉब पॉड्स को समानांतर रूप से शेड्यूल करता है, कनकरेंसी और क्लस्टर सीमाओं तक। थ्रूपुट तब दिखाई देता है जब मर्ज दबाव वास्तविक होता है।

7.2 जब मांग खत्म होती है, तब कठोर रूप से घटें

जब नौकरियां समाप्त होती हैं, तो पॉड्स गायब हो जाते हैं। क्लस्टर ऑटोस्केलिंग (या सही आकार के नोड पूल) के साथ, अनावश्यक क्लाउड नोड्स पूल से बाहर हो जाते हैं। रातें और हफ्ते के अंत — आमतौर पर उत्पाद टीमों के लिए सबसे शांत खिड़कियां — वे पहली क्षमता हैं जिस पर आप भुगतान करना बंद कर सकते हैं।

7.3 CPU, RAM और स्टोरेज की बर्बादी बंद करें

एक महीने के दौरान, शांत घंटे घड़ी पर प्रभुत्व पाने लगते हैं। रातें और हफ्ते के अंत को वापस पाना वह जगह है जहांडॉलर बचतें गुणा होती हैं।

7.4 परिणामों के लिए भुगतान करें, फर्नीचर के लिए नहीं

आप अभी भी GitLab और एक पतले नियंत्रण प्लेन (रनर मैनेजर + क्लस्टर आवश्यकताएं) के लिए भुगतान करते हैं। वह जो आप बंद कर देते हैं, वह खाली कुर्सियों के गोदाम का भुगतान है।

7.5 काम किया गया अंतिदृष्टि (एक काल्पनिक मानक नहीं)

मान लीजिए कि दिन के समय को सतत रूप से 20 व्यस्त एक्जिक्यूटर स्लॉट्स की समतुल्यता की आवश्यकता होती है, लेकिन रात और हफ्ते के छुट्टी के दिन केवल 2 की आवश्यकता होती है। एक निश्चित फ्लीट जो 20 के लिए आकारित है, पूरे दिन और रात में 20 का भुगतान करती है। एक लचीला पूल दिन के दौरान ~20 और शांत समय पर ~2 (प्लस कंट्रोल प्लेन) का भुगतान करता है। कई उत्पाद टीमों के लिए, शांत घंटे महीने का एक बड़ा अंश हैं — इसलिए उन्हें वापस लेना यह है कि बचतेंविशालबन जाती हैं बिना मार्केटिंग प्रतिशत का आविष्कार किए। वित्त स्थानीय नोड-घंटे मूल्यों को गुणा करता है; आर्किटेक्चर का काम यह है कि बिलिंग खाते में खाली घंटे वास्तव में खाली हों।

विशाल लागत बचत तब दिखाई देती है जब मंगलवार की चरम सीमा अब मंगलवार-सुबह-3 बिल को निर्धारित नहीं करती — और जब शनिवार की चुप्पी अंततः बिल पर भी शांत दिखती है।

7.6 आप जानबूझकर क्या अभी भी भुगतान करते हैं

• GitLab सर्वर घटक — उपयोगकर्ताओं और CI समन्वय के लिए आकारित, न कि कंपाइल फार्म के लिए।
• रनर मैनेजर डेप्लॉयमेंट(s) — जॉब फार्मों के मुकाबले छोटा।
• जानबूझाए गए कैश (डिपेंडेंसी प्रॉक्सी, PVCs) — सहायक, लेकिन आकारित; कैश मुफ्त स्टोरेज नहीं हैं।
• प्राइविलिज्ड DinD — सुविधाजनक और भारी; जब घनत्व और अलग-थलग होने की तुलना में परिचित होने से अधिक महत्व है, तो Kaniko/BuildKit पर विचार करें।

8. CI/CD व्यावहारिक पाइपलाइन

रनर्स ऑनलाइन होने पर,.gitlab-ci.ymlचरणों और नौकरियों को परिभाषित करता है। GitLab शेड्यूल करता है; Kubernetes एक्जिक्यूटर पॉड्स को संचालित करता है। लागत के बारे में पाइपलाइन को सही रखें:

• लिनट/यूनिट पर तुरंत विफल होने पर भारी इमेज निर्माण से पहले।
• rules/workflowका उपयोग करें ताकि ड्राफ्ट शाखाएँ पूर्ण मैट्रिक्स में फैलें न।
• स्पष्ट कुंजियों वाले साझा कैशों को अनबाउंडड पर-VM डिस्क वृद्धि पर पसंद करें।
• नौकरियों को सही रनर पूल (alpine vs ubuntu, छोटे vs बड़े निर्माता) के साथ टैग करें।

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 मांग हो या जोरदार क्लस्टर पर प्रतिबंध हों। बाकी सभी जिनकी पंपीय मानव-चालित पाइपलाइनें हैं, वे फर्नीचर कर (furniture tax) भर रहे हैं।

12. आप क्या नहीं छोड़ रहे

ऑटोस्केलिंग का मतलब "नियंत्रण नहीं" नहीं है। आप अभी भी समानांतरता, अनुमति प्राप्त छवियाँ, DinD विशेषाधिकार, नेटवर्क नीति और रजिस्ट्रेशन दायरे को सेट करते हैं। बिंदु यह है कि उन नियंत्रणों को बनाए रखते हुए अनावश्यक क्षमता को वाष्पित होने देना — साधारण भाषा वाले टुकड़े जैसी ही पुनः आश्वासन, अब RBAC, नामांतर (namespaces) और अलग रनर रिलीज के साथ लागू किया गया।

13. संचालन की जाँच सूची

1. पिन ऑपरेटर/चार्ट संस्करण; जानबूझकर अपग्रेड करें।
2. रनर टोकन घुमाएँ; प्रकाशन से पहले किसी भी स्क्रिप्ट से प्रयोगशाला टोकन हटाएँ।
3. अलग-अलग नामांतरित स्थान: GitLab सिस्टम बनाम रनर नौकरियाँ।
4. देखेंलट्केपॉड — बढ़ते लट्के पॉड का मतलब यह है कि चरम पर समानांतरता या नोड क्षमता कम है।
5. देखेंखाली नोड घंटे— रात भर खाली रहने वाले नोड का मतलब है कि स्केल-डाउन में देरी है या पूल नीति को समायोजित करने की आवश्यकता है।
6. विशेषाधिकार वाले रनरों को उन नौकरियों तक सीमित रखें जिनकी उन्हें आवश्यकता है।
7. रनर लोच के अलावा GitLab की पृथक पृथक्करण करें।
8. जब लोचदार CI सक्रिय हो, तो हफ्ते के घंटे के अनुसार बिल की समीक्षा करें — रात और शनिवार-रविवार स्पष्ट रूप से कम होना चाहिए।

14. यह किसके लिए है

• प्लेटफॉर्म इंजीनियर और SRE जो Kubernetes पर GitLab CI लागू कर रहे हैं।
• DevOps नेता जो खड़े रनर VMs को एक्जिक्यूटर पॉड्स से बदल रहे हैं।
• इंजीनियरिंग और वित्त सहयोगी जो CI को उपयोग-आधारित सार्वजनिक सेवा की तरह व्यवहार करने की आवश्यकता रखते हैं, न कि फर्नीचर की तरह।

15. आधिकारिक GitLab दस्तावेज़

ये पृष्ठ ऊपर वर्णित Helm विनियोजन और स्केलिंग व्यवहार के लिए मानक संदर्भ हैं। जब संस्करण बदलें तो ब्लॉग पोस्टों के बजाय इन्हें पसंद करें।

Kubernetes पर GitLab सर्वर

• GitLab ऑपरेटर को स्थापित करें— प्रशिक्षण वॉकथ्रू में उपयोग किया गया ऑपरेटर + Helm इंस्टॉल पथ।
• GitLab Helm चार्ट— छाता चार्ट दस्तावेज़ीकरण।
• Helm चार्ट के साथ GitLab स्थापित करें— जब आप चार्ट के माध्यम से GitLab डिप्लॉय करते हैं, न कि ऑपरेटर के माध्यम से।
• gitlab-runner सबचार्ट (GitLab चार्ट)— मुख्य चार्ट के साथ GitLab के बगल में बंडल किया गया रनर (अलग-थलग रनर चार्ट से भिन्न)।

GitLab Runner Helm चार्ट

• Helm चार्ट के साथ GitLab Runner स्थापित करें—helm repo add gitlab, स्थापित/अपग्रेड, OCI चार्ट नोट्स।
• GitLab Runner Helm चार्ट की कॉन्फ़िगरेशन करें—concurrent, कॉन्फ़िगरेशन टेम्पलेट्स, RBAC, कैशेस, इमेज चॉइस।
• gitlab-runner चार्टvalues.yaml— पूर्ण डिफ़ॉल्ट मान (सामिल वैकल्पिक HPA स्टब्स)।

Kubernetes एग्जेक्यूटर और ऑटोस्केलिंग

• Kubernetes एग्जेक्यूटर— जॉब पॉड्स, हेल्पर, सर्विसेस (जैसे DinD), रिसोर्स रिक्वेस्ट, RBAC क्रियाएँ।
• ऑटोस्केलिंग कॉन्फ़िगर करें (Kubernetes एग्जेक्यूटर / चार्ट)— पॉड्स को रोकें,[runners.kubernetes.autoscaler], पेरियड पॉलिसीज (रात/हफ्ते के अंत में खाली)।
• GitLab Runner का ऑटोस्केलिंग— सामान्य ऑटोस्केलिंग मॉडल (इसमें वितरित कैशिंग भी शामिल है)।
• GitLab Runner फ्लीट की योजना बनाएं और प्रबंधित करें— फ्लीट-स्तरीय स्केलिंग और संचालन।
• उन्नत कॉन्फ़िगरेशन (config.toml)— वैश्विकconcurrentऔर एग्जेक्यूटर खंड जो Helmrunners.configमें एम्बेड किए गए हैं।

GitLab में CI जॉब्स, बिल्ड्स और रनर सेटिंग्स

• GitLab में रनर कॉन्फ़िगर करें— रजिस्ट्रेशन, टैग्स, run-untagged, सुरक्षित रनर।
• Docker का उपयोग करके CI में इमेज बनाएं— DinD और विकल्प (जबprivileged/ Docker सर्विस रनर वैल्यूज में सक्षम हो)।

रात और हफ्ते के अंत की लागत नियंत्रण के लिए, इनका संयोजन करें: (1) Kubernetes एग्जेक्यूटर जॉब पॉड्स जो शून्य पर पहुँचें, (2) चार्टconcurrentऔर ऑटोस्केलरपॉलिसीजजिनमें ऑफ-पीकidle_count = 0हो, और (3) क्लस्टर/नोड ऑटोस्केलिंग ताकि खाली नोड्स पूल से बाहर चले जाएं — जैसा कि अनुभाग 6–7 में वर्णित है।

16. वीडियो और रिपो में वापस मैपिंग

YouTube सत्र —लगभग 20 मिनटों में पूरा GitLab। Kubernetes पर GitLab Runner वर्कलोड्स का ऑटोस्केलिंग— Kubernetes पर GitLab, Helm के माध्यम से रनर्स, और हाइपरस्केल लागत कहानी को दर्शाता है: इंफ्रास्ट्रक्चर को गतिशील रूप से प्रोव्हाइड और डी-प्रोव्हाइड करें ताकि आप खाली रातों और हफ्ते के छुट्टियों के लिए शिखर दरें न चुकें। इस रिपो मेंgitlab-runners-k3s-hyperscale-course.prompt.mdकोर्स बिल्ड प्रॉम्प्ट का उपयोग करें, और ऊपर दिए गए आधिकारिक दस्तावेज़ों को संस्करणित सत्य के स्रोत के रूप में उपयोग करें। उसी विचारों के गैर-तकनीकी ढांचे के लिए, देखेंखाली CI के लिए भुगतान बंद करें।

समापन

Kubernetes केवल GitLab रनर्स को होस्ट नहीं करता है। सही तरीके से उपयोग करने पर, यह CI की अर्थव्यवस्था को बदल देता है:आवश्यकता पर प्रोव्हाइड करें, खाली होने पर डी-प्रोव्हाइड करें, जब लोग घर जाते हैं तो CPU/RAM/स्टोरेज वापस प्राप्त करें। यह हाइपरस्केल पैटर्न है — जो किसी भी टीम के लिए उपलब्ध है जो एक स्थायी फ्लीट को पॉड्स की कतार के लिए बदलने को तैयार है।

वीडियो से शुरू करें, ऑपरेटर + रनर Helm को एक प्रयोगशाला में स्थापित करें, नोड ऑटोस्केलिंग चालू करें, फिर बिल पर शनिवार अंततः शांत दिखता है या नहीं, यह जांचें।

Workstation द्वारा प्रकाशित।