GitLab Runners บน Kubernetes: การเพิ่มประสิทธิภาพต้นทุนแบบ hyperscale ด้วย Kubernetes executor

การเจาะลึกทางเทคนิค: GitLab Runners บน Kubernetes, การติดตั้ง Operator, ค่า Helm, autoscaling และโมเดลต้นทุน FinOps สำหรับฉบับย่อ อ่านหยุดจ่ายค่า CI ที่ไม่ได้ใช้งาน

ทีมส่วนใหญ่จ่ายค่า continuous integration เหมือนทุกคืนและวันหยุดสุดสัปดาห์ยังเป็นเช้าวันจันทร์ เซิร์ฟเวอร์ยังคงทำงานอยู่ ฮาร์ดดิสก์ยังคงถูกจองไว้ ไม่มีใคร merge code — และบิลก็ไม่ได้สังเกตเห็น ประโยคนี้ไม่ใช่สโลแกน; มันคือรูปร่างมาตรฐานของฟลีต runner แบบคงที่

บทความยาวชิ้นนี้เป็นคู่มือทางเทคนิคคู่กับการสาธิตแบบลงมือทำของGitLab Server และ GitLab Runner บน Kubernetes: ว่า executor Kubernetes แปลงงาน CI แต่ละงานให้เป็นพอดชั่วคราวได้อย่างไร ว่าสิ่งนี้ทำให้สามารถจัดเตรียมและปลดการจัดเตรียมความจุแบบไดนามิกได้อย่างไร และว่าการออกแบบนี้ปลดล็อกประหยัดต้นทุนมหาศาลโดยคืน CPU, RAM และพื้นที่จัดเก็บเมื่อความต้องการพังทลายลงกลางดึกและวันหยุดสุดสัปดาห์

ดูทั้งสองเซสชันก่อน แล้วใช้หน้านี้เป็นสถาปัตยกรรมและโมเดลต้นทุนแบบลายลักษณ์อักษร

1. Runners & pipelines— autoscaling โหลดงาน GitLab Runner โดยใช้ Kubernetes

ดู: GitLab Runners ครบถ้วนและ CI/CD บน Kubernetes· ฉบับภาษาธรรมดา:หยุดจ่ายค่า CI ที่ไม่ได้ใช้งาน

2. GitLab Server บน HA Kubernetes— ติดตั้ง GitLab ด้วย Operator ในไม่กี่นาที

ดูวิดีโอ: ติดตั้ง GitLab บน HA Kubernetes cluster โดยใช้ Operator· เอกสาร:การติดตั้ง GitLab Operator

1. ทฤษฎี

GitLab บน Kubernetes + executor ของ Kubernetesเปลี่ยนหน่วยความจุ CI จาก "เครื่องที่เราเป็นเจ้าของตลอดเดือน" เป็น "pods (และ nodes) ที่เราเช่าเฉพาะงาน" ผู้จัดการ runner ยังคงเล็กและทำงานตลอดเวลา Pods ของงานปรากฏขึ้นเมื่อมีการ build และหายไปหลังจากนั้น ด้วย cluster autoscaling โหนดทำงานจะตามแนวโน้มเดียวกัน นั่นคือวิธีที่คุณปกป้อง throughput ในช่วงเช้าวันจันทร์และหยุดจ่ายราคาช่วงเช้าวันจันทร์สำหรับงานวันอังคารเวลา 03:00 และวันหยุดเสาร์ที่เงียบสงบ

ในบรรทัดเดียว — บรรทัดเดียวกับคู่มือสำหรับผู้เริ่มต้น:จัดเตรียมทรัพยากรสำหรับช่วงสูงสุด และลดการจัดเตรียมสำหรับช่วงต่ำ.

2. ความเคยชินที่มีค่าใช้จ่ายสูง ซึ่งระบุว่าเป็นกลิ่นของสถาปัตยกรรม

CI แบบดั้งเดิมมักดูเหมือนกองเรือถาวร: ชุดเครื่องสร้างแบบคงที่ที่อยู่บน "เผื่อไว้ก่อน" ซึ่งทำงานได้ดีเมื่อการจราจรคงที่ แต่เป็นการสิ้นเปลืองเมื่อความต้องการพุ่งสูง

• ช่วงกลางวัน:นักพัฒนาผลักดันสาขา เปิดคำขอรวม และรันการทดสอบ — ความต้องการพุ่งสูง
• ช่วงเย็นและกลางคืน:กิจกรรมลดลง แต่เครื่องยังคงเผา CPU และ RAM
• วันหยุด:มักเกือบว่าง — อย่างไรก็ตาม ปริมาณการจัดเก็บและโหนดคลาวด์อาจยังคงสำรองและเรียกเก็บเงิน

คุณไม่ได้จ่ายสำหรับ "การสร้างที่ทำเสร็จ" คุณจ่ายสำหรับความสามารถที่มีอยู่ไม่ว่าใครจะใช้งานหรือไม่ กองเรือคงที่ก็สะสมสถานะติดแน่น: "ทำงานบนรันเนอร์ 3" แพ็กเกจที่ล่องลอย แคชที่ไม่เคยหมดอายุ พอดแบบยืดหยุ่นไม่ได้แก้ปัญหาวินัยด้วยตนเอง แต่ทำให้การเริ่มต้นใหม่แบบสะอาดเป็นค่าเริ่มต้น

3. แผนที่ระบบ

เปรียบเทียบจาก plain guide ยังคงใช้ได้ในระดับชั้นนี้: GitLab Runner คือ worker; Kubernetes คือ dispatcher ที่เรียก worker เฉพาะเมื่อ parcels (jobs) มาถึง แล้วส่งกลับบ้าน

4. การติดตั้ง GitLab บนคลัสเตอร์ (ทาง Operator)

ทาง Day 1 training path จะติดตั้ง GitLab โดยใช้ official operator ดังนั้นเซิร์ฟเวอร์จึงใช้ Kubernetes foundation เดียวกับ runners คลิปวิดีโอประกอบDeploy GitLab in HA Kubernetes cluster using the Operatorจะแนะนำการติดตั้งดังกล่าวในไม่กี่นาที ข้อกำหนดเบื้องต้น: คลัสเตอร์ที่มี ingress, Helm,kubectl, และ cert-manager เมื่อ chart จัดการ 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 shape (ปรับ domain และ issuer email ให้เหมาะกับสภาพแวดล้อมของคุณ):

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 นาที ในขณะที่ webservice, Sidekiq, data stores และส่วนประกอบที่เกี่ยวข้องทำงานจนเสถียร ดึงรหัสผ่าน root เริ่มต้นจาก cluster secret:

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

อ้างอิง:GitLab Operator installation(แท็บ Helm บนหน้านั้น) ภาพรวมของ Chart:docs.gitlab.com/charts· คู่มือการติดตั้ง:charts installation.

5. GitLab Runner พร้อม Kubernetes executor

GitLab Runner คือแอปพลิเคชันที่ทำหน้าที่ทำงานร่วมกับ GitLab CI/CD ในการรันงานใน pipeline ด้วยKubernetes executorผู้จัดการจะไม่คอมไพล์บนตัวมันเอง สำหรับแต่ละงานจะ:

1. สร้าง pod (รวมถึง helper/service containers ตามการกำหนด)
2. ส่ง stream log กลับไปยัง GitLab
3. รวบรวม artifacts และสถานะการออก
4. ลบ pod — คืน CPU และ RAM ให้กับคลัสเตอร์

วงจร create/run/delete นั้นคือจุดแรกของการลดต้นทุน งานที่เสร็จสิ้นไม่ควรทิ้งเครื่องที่เปิดค้างคืนไว้

5.1 Helm รูปแบบการติดตั้ง

สคริปต์การฝึกอบรมจะสร้าง namespace, ส่ง token สำหรับการลงทะเบียน และอาจติดตั้งการปล่อยมากกว่าหนึ่งครั้ง (เช่น runners แบบ alpine และ ubuntu) เพื่อให้งานสามารถเลือกสภาพแวดล้อมที่แตกต่างกันได้ ขั้นตอนอย่างเป็นทางการ:ติดตั้ง GitLab Runner โดยใช้แผน Helm; อ้างอิงค่า:กำหนดค่าแผน Helmของ GitLab Runner

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

ดึง token จาก GitLab UI (runners ของ instance / group / project) หรือจาก secrets ที่จัดการโดยผู้ปฏิบัติงาน ควรใช้ token สำหรับการรับรองตัวของ runner แบบสมัยใหม่; token สำหรับการลงทะเบียนจะเลิกใช้ไปใน GitLab 18ห้าม commit token แบบใช้งานได้— สคริปต์ในแล็บอาจมี placeholder ที่ต้องแทนที่ในท้องถิ่น

ค่าที่สำคัญสำหรับการขยายขนาดและการแยกส่วน

จากเทมเพลต 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. ความยืดหยุ่นของ Pod งาน— ถูกสร้างมาในตัว Kubernetes executor โดยตรง จำนวนงานเป็นศูนย์ → Pod งานเป็นศูนย์ สิ่งนี้เพียงอย่างเดียวช่วยลดความสิ้นเปลืองต่องานส่วนใหญ่บนคลัสเตอร์ร่วมกัน
2. Runnerconcurrentและการ Deployments ของ runner หลายตัว— แยก alpine ออกจาก ubuntu (หรือ CPU ออกจากเครื่องสร้างขนาดใหญ่) เพื่อให้ความสามารถเฉพาะทางไม่ต้องรอว่างเพราะสัดส่วนงานที่ไม่ตรง
3. การปรับขนาดคลัสเตอร์/โหนด— Pod ที่รอทำงานจะเพิ่มโหนด; โหนดว่างจะลดจำนวนลงหลังช่วงเย็น
4. นโยบายที่คำนึงถึงตารางเวลาแบบเลือกทำ— ลดขีดจำกัดการทำงานพร้อมกันหรือปรับขนาดกลุ่มโหนดตามปฏิทินสำหรับกลางคืน/วันหยุดสุดสัปดาห์ เพื่อเป็นมาตรการเสริมควบคู่กับการยุบตัวของความต้องการตามธรรมชาติ

การขยายขนาดระดับไฮเปอร์สเกลเป็นเรื่องเดียวกันแต่มีความรุนแรงมากขึ้น: ขยายออกไปเมื่อคิวลึก แล้วลดการจัดเตรียมทรัพยากรอย่างแข็งขัน เพื่อให้ครึ่งแรกของสัปดาห์ที่เงียบสงบไม่เหมือนกับครึ่งแรกสุดวุ่นในใบแจ้งหนี้

6.1 หมายเหตุเกี่ยวกับคำว่า "ว่าง" ในความหมายของ GitLab Runner

Executor บางตัวยังคงเครื่องทำงานจำนวนเล็กน้อยในสถานะว่างเพื่อรองรับงานถัดไปโดยไม่มีหน่วงเวลาเริ่มต้นเย็น บน Kubernetes การเริ่มต้นเย็นมักหมายถึงการสร้าง Pod (ไม่กี่วินาที) ไม่ใช่การบูต VM (หลายนาที) ควรปล่อยให้ Pod ลดลงเป็นศูนย์และยอมรับหน่วงเวลาตารางเวลาสั้นๆ แทนการคงโหนดว่างในกะกลางคืนไว้ "เผื่อกรณีฉุกเฉิน" หากจำเป็นต้องรักษาพื้นต่ำเล็กน้อย ให้กำหนดขนาดพื้นต่ำนั้นตามความเป็นจริงของงานที่ต้องรับผิดชอบ — ไม่ใช่ตามพายุ Merge ของวันจันทร์

6.2 การจัดเตรียมและยกเลิกการจัดเตรียมแบบ end-to-end

ติดตามงานใน pipeline หนึ่ง:

1. นักพัฒนาทำการ push; GitLab สร้างงานในคิวรอการดำเนินการ
2. ผู้จัดการ Runner รับงานและขอพอดจาก API
3. หากคลัสเตอร์ขาดแคลน CPU/RAM อัตโอสเกลอร์จะเพิ่มโหนด (การจัดเตรียม)
4. พอดทำงานสคริปต์ อัปโหลด artifacts และปิดการทำงาน
5. พอดถูกลบ; ทรัพยากรกลับสู่พูล (ยกเลิกการจัดprepareในระดับงาน)
6. เมื่อมีโหนดจำนวนมากนั่งว่างเกินเกณฑ์ scale-down — โดยทั่วไปหลังเวลาเย็นและตลอดวันหยุด — โหนดจะออก (ยกเลิกการจัดเตรียมในระดับโครงสร้างพื้นฐาน)

วงจรทั้งหมดนั่นคือสิ่งที่วิดีโอหมายถึงโดย GitLab Runners ในระดับไฮเปอร์สเกลเพื่อการประหยัดต้นทุน: ไม่ใช่แบนเนอร์ฟังค์เดียว แต่วงจรชีวิตของงานร่วมกับความยืดหยุ่นของคลัสเตอร์ทำงานร่วมกัน

7. แบบจำลองต้นทุน: ที่ไหนที่การประหยัดมหาศาลเกิดขึ้น

ให้แม่นยำ อัตโอสเกลิงไม่ได้ทำให้การคอมไพล์ฟรี มันหยุดการจ่ายอัตราสูงสุดในช่วงเวลาที่ไม่ใช่เวลาเร่งด่วน การประหยัดมาจากการจับคู่การใช้จ่ายกับความต้องการจริง — สี่จุดจากคู่มือแบบเรียบง่าย ขยายสำหรับผู้ปฏิบัติงาน

7.1 ขยายขนาดเฉพาะเมื่อมีคน (หรือบอท) ทำงาน

เมื่อเช้าที่คึกคักทำให้มี pipeline หลายสิบงาน Kubernetes กำหนดตารางพอดงานจำนวนมากทำงานพร้อมกันตามขีดจำกัดความขนานและคลัสเตอร์ ความสามารถในการผ่านปรากฏเมื่อแรงกดดันในการรวมงานเป็นความจริง

7.2 ลดขนาดลงอย่างรวดเร็วเมื่อความต้องการหายไป

เมื่างานเสร็จ โปดย่อมหายไป ด้วยระบบขยายคลัสเตอร์อัตโนมัติ (หรือโหนดพูลขนาดเหมาะสม) โหนดคลาวด์ที่ไม่ได้ใช้งานจะออกจากพูล เวลากลางคืนและวันหยุดสุดสัปดาห์ — โดยปกติเป็นช่วงเวลาเงียบที่สุดของทีมผลิตภัณฑ์ — คือความจุแรกที่คุณควรหยุดชำระค่าใช้จ่าย

7.3 หยุดการสิ้นเปลือง CPU, RAM และพื้นที่จัดเก็บ

ตลอดเดือนหนึ่ง เวลากลางคืนและวันหยุดสุดสัปดาห์ครองเวลาส่วนใหญ่ การคืนเวลากลางคืนและวันหยุดสุดสัปดาห์คือจุดที่การประหยัดเงินสะสม

7.4 ชำระเงินตามผลลัพธ์ ไม่ใช่ตามเฟอร์นิเจอร์

คุณยังคงชำระค่า GitLab และระบุควบคุมแบบบาง (ผู้จัดการ runner + สิ่งจำเป็นของคลัสเตอร์) สิ่งที่คุณหยุดชำระคือคลังเก้าอี้ว่างเปล่า

7.5 ความเข้าใจจากการทำงาน (ไม่ใช่เกณฑ์ที่ประดิษฐ์ขึ้น)

สมมติว่ากลางวันต้องการสล็อต executor จำนวน 20 สล็อตที่ทำงานเต็มที่ แต่กลางคืนและวันหยุดต้องการเพียง 2 สล็อต ฟลีตแบบคงที่ที่มีขนาดสำหรับ 20 จะจ่ายค่า 20 ตลอดเวลา ในขณะที่พูลแบบยืดหยุ่นจะจ่ายค่าประมาณ ~20 ในช่วงกลางวันและประมาณ ~2 (บวกกับ control plane) เมื่อเงียบสงบ สำหรับทีมผลิตภัณฑ์จำนวนมาก ช่วงเวลาเงียบสงบเป็นสัดส่วนขนาดใหญ่ของเดือน — ดังนั้นการกู้คืนช่วงเวลานี้จึงทำให้การประหยัดมหาศาลโดยไม่ต้องประดิษฐ์เปอร์เซ็นต์การตลาด การเงินคูณราคาต่อชั่วโมงของโหนดท้องถิ่น; งานของสถาปัตยกรรมคือการทำให้ชั่วโมงว่างนั้นว่างจริงๆ ในบัญชีบิล

การประหยัดต้นทุนมหาศาลปรากฏขึ้นเมื่อด้านบนสุดของวันจันทร์不再กำหนดบิลของวันอังคารตอน 3 โมงเช้า — และเมื่อสันติภาพของวันเสาร์สุดท้ายดูเหมือนเงียบบนใบแจ้งบิลด้วย

7.6 สิ่งที่คุณยังคงจ่ายโดยเจตนา

• ส่วนประกอบ GitLab Server — ขนาดสำหรับผู้ใช้และการประสานงาน CI ไม่ใช่สำหรับฟาร์มคอมไพล์
• Runner manager Deployment(s) — ขนาดเล็กเมื่อเทียบกับฟาร์มงาน
• แคชโดยเจตนา (dependency proxy, PVCs) — มีประโยชน์ แต่มีขนาด; แคชไม่ใช่พื้นที่จัดเก็บฟรี
• DinD แบบพิเศษ — สะดวกและหนักกว่า; พิจารณา Kaniko/BuildKit เมื่อความหนาแน่นและการแยกส่วนสำคัญกว่าความคุ้นเคย

8. CI/CD ท่อส่งงานในทางปฏิบัติ

เมื่อมี runners ทำงานออนไลน์.gitlab-ci.ymlจะกำหนดขั้นตอนและงาน GitLab ทำการกำหนดตารางเวลา และ Kubernetes executor จะสร้างพอดให้พร้อมใช้งาน รักษาความถูกต้องของท่อส่งงานในแง่ต้นทุน:

• ล้มเหลวอย่างรวดเร็วในการตรวจสอบลินต์/ยูนิตก่อนการสร้างภาพขนาดใหญ่
• ใช้rules/workflowเพื่อให้สาขาแบบร่างไม่กระจายเมทริกซ์เต็ม
• เลือกใช้แคชร่วมกันที่มีคีย์ชัดเจน แทนการเติบโตของดิสก์ต่อ VM แบบไร้ขอบเขต
• ติดป้ายงานไปยังพูล runner ที่เหมาะสม (alpine vs ubuntu, small vs large builders)

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"

แนวคิดทางเศรษฐศาสตร์นั้นเหมือนกับแนวคิดของแพลตฟอร์ม: อย่ากำหนดตารางเวลาสำหรับงานราคาแพงเมื่อการตรวจสอบราคาถูกจะล้มเหลว และอย่ารักษา runners เฉพาะไว้ให้พร้อมสำหรับงานที่ไม่เคยมาถึงในวันเสาร์

9. หมายเหตุด้านความปลอดภัยและการเช่า

พอดแบบชั่วคราวช่วยปรับปรุงความสะอาด (สถานะติดก้อยีน้อยลง) แต่ DinD แบบมีสิทธิ์พิเศษและ RBAC ในระดับคลัสเตอร์อาจขยายขอบเขตการทำลายล้าง Defaults ทางปฏิบัติสำหรับทีมส่วนใหญ่:

• ทำงานพอดงานในเนมสเปซเฉพาะพร้อม ResourceQuotas และ LimitRanges
• เลือกการสร้างแบบไม่ใช้สิทธิ์พิเศษเมื่อเป็นไปได้; แยก runner DinD ไว้ด้านหลังแท็กเฉพาะ
• หลีกเลี่ยงการ挂载憑据ของคลาวด์ระยะยาวลงในงานทุกงาน; ฉีดโทเค็นระยะสั้นตามท่อส่งงาน
• จัดการโทเค็นการลงทะเบียน runner ว่าเป็นความลับ — หมุนเวียนเมื่อคนออกหรือห้องแล็บถูกแบ่งปัน
• หากหลายทีมใช้คลัสเตอร์ร่วมกัน ให้แยกผู้จัดการ runner (และพูลโหนดตามตัวเลือก) เพื่อให้เพื่อนบ้านเสียงดังไม่สามารถทำให้ฟาร์มร้อนทั้งฟาร์ม — และรักษาเรื่องราวต้นทุนให้สามารถระบุตามทีมได้

10. ความสามารถในการมองเห็นที่พิสูจน์การประหยัดต้นทุน

คุณไม่สามารถอ้างการประหยัดในเวลากลางคืนและวันหยุดสุดสัปดาห์ได้หากไม่ตรวจสอบ ติดตามอย่างน้อย:

หากจำนวน pod ลดลงในเวลากลางคืนแต่ค่านodeบิลไม่ลดลง การตั้งค่า scale-down — ไม่ใช่ GitLab — คือปุ่มถัดไป

11. VMs คงที่เทียบกับ Kubernetes executors (ตารางตัดสินใจ)

เลือก VMs คงที่เฉพาะเมื่อคุณมีความต้องการ 24×7 แบบราบเรียบหรือข้อจำกัดที่ห้ามใช้ cluster เท่านั้น ทุกคนที่เหลือที่มี pipelines ขับเคลื่อนโดยมนุษย์แบบพุ่งแหลนกำลังจ่ายภาษีเฟอร์นิเจอร์

12. สิ่งที่คุณไม่ได้สูญเสีย

Autoscaling ไม่ได้หมายความว่า "ไม่มีควบคุม" คุณยังคงตั้งค่า concurrency, ภาพที่อนุญาต, สิทธิ DinD, นโยบายเครือข่าย, และขอบเขตการลงทะเบียน จุดประสงค์คือการรักษาการควบคุมเหล่านั้นในขณะที่ให้ความจุที่ไม่ได้ใช้งานระเหย — ความมั่นใจเดียวกันกับในบทความภาษาธรรมดา ตอนนี้บังคับใช้ด้วย RBAC, namespaces และ runner releases แยก

13. รายการตรวจสอบการดำเนินงาน

1. เวอร์ชัน Pin operator/chart; อัปเกรดโดยเจตนา
2. หมุนเวียน runner tokens; ลบ lab tokens ออกจากสคริปต์ใดๆ ก่อนเผยแพร่
3. แยก namespaces: GitLab system vs runner jobs
4. ตรวจสอบpendingpods — หาก pending เพิ่มขึ้น แสดงว่ามีความพร้อมใช้งานหรือความจุของโหนดไม่เพียงพอในช่วงเวลาสูงสุด
5. ตรวจสอบชั่วโมงโหนดว่าง— หากโหนดยังคงว่างค้างข้ามคืน แสดงว่ามีความล่าช้าในการลดขนาดหรือจำเป็นต้องปรับจูนนโยบายพูล
6. จำกัด privileged runners เฉพาะงานที่ต้องการเท่านั้น
7. สำรอง GitLab แยกจาก runner elasticity
8. ทบทวนบิลตามช่วงเวลาของสัปดาห์เมื่อ elastic CI ทำงาน — ช่วงกลางคืนและวันหยุดสุดสัปดาห์ควรลดลงอย่างเห็นได้ชัด

14. ใครคือกลุ่มเป้าหมาย

• วิศวกรแพลตฟอร์มและ SREs ที่นำ GitLab CI มาใช้บน Kubernetes
• ผู้นำ DevOps ที่แทนที่ VM runner แบบถาวรด้วย executor pods
• คู่ความร่วมมือด้านวิศวกรรมและการเงินที่ต้องการให้ CI ทำงานเหมือนสาธารณูปโภคแบบตามการใช้งาน ไม่ใช่เฟอร์นิเจอร์

15. เอกสารทางการของ GitLab

หน้าเหล่านี้เป็นเอกสารอ้างอิงมาตรฐานสำหรับการใช้งาน Helm และการขยายขนาดตามที่อธิบายข้างต้น ควรเลือกใช้แทนบทความในบล็อกเมื่อมีการเปลี่ยนแปลงเวอร์ชัน

GitLab Server บน Kubernetes

• ติดตั้ง GitLab Operator— Operator + Helm เส้นทางติดตั้งที่ใช้ในการสาธิตการฝึกอบรม
• แผนภูมิ GitLab Helm— เอกสารแผนภูมิหลัก
• ติดตั้ง GitLab ด้วยแผนภูมิ Helm— เมื่อคุณติดตั้ง GitLab ผ่านแผนภูมิแทน Operator
• แผนภูมิย่อย 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 stubs แบบเลือกได้)

Kubernetes executor และ autoscaling

• Kubernetes executor— job pods, helpers, services (เช่น DinD), resource requests, RBAC verbs.
• กำหนดค่า autoscaling (Kubernetes executor / chart)— pause pods,[runners.kubernetes.autoscaler], นโยบายช่วงเวลา (idle ในตอนกลางคืน/วันหยุดสุดสัปดาห์).
• Autoscaling GitLab Runner— แบบจำลอง autoscaling โดยทั่วไป (รวมถึง distributed caching ด้วย).
• วางแผนและจัดการ GitLab Runner fleet— fleet-level scaling และ operations.
• การกำหนดค่าขั้นสูง (config.toml)— globalconcurrentและ executor sections ที่ฝังอยู่ใน Helmrunners.config.

CI jobs, builds, และ runner settings ใน GitLab

• กำหนดค่า runners ใน GitLab— registration, tags, run-untagged, protected runners.
• ใช้ Docker ในการสร้าง images ใน CI— DinD และทางเลือกอื่น (เกี่ยวข้องเมื่อprivileged/ Docker service เปิดใช้งานใน runner values).

สำหรับการควบคุมต้นทุนในเวลากลางคืนและวันหยุดสุดสัปดาห์ ให้รวม: (1) Kubernetes executor job pods ที่ลดลงเป็นศูนย์, (2) chartconcurrentและ autoscalerpoliciesที่มี off-peakidle_count = 0และ (3) cluster/node autoscaling เพื่อให้โหนดว่างออกจากรายการ — ตามที่อธิบายในบทที่ 6–7.

16. ย้อนกลับไปดูวิดีโอและ repo

การประชุมบน YouTube —GitLab ครบถ้วนภายใน ~20 นาที การปรับขนาด GitLab Runner แบบอัตโนมัติโดยใช้ Kubernetes— แสดงให้เห็น GitLab บน Kubernetes, runners ผ่าน Helm และเรื่องราวต้นทุนแบบ hyperscale: จัดเตรียมและยกเลิกการเตรียมโครงสร้างพื้นฐานแบบไดนามิกเพื่อให้คุณไม่ต้องจ่ายอัตราสูงสุดในช่วงกลางคืนและวันหยุดสุดสัปดาห์ที่ว่างเปล่า ใช้คำสั่งสร้างใน repo นี้gitlab-runners-k3s-hyperscale-course.prompt.mdร่วมกับเอกสารทางการด้านบนในฐานะแหล่งความจริงที่เป็นเวอร์ชันแล้ว สำหรับกรอบแนวคิดที่ไม่ใช่ทางเทคนิคของแนวคิดเดียวกัน ดูหยุดการจ่ายค่า CI ที่ว่างเปล่า

บทสรุป

Kubernetes ไม่ได้เพียงแค่โฮสต์ GitLab Runners เมื่อใช้อย่างถูกต้อง มันเปลี่ยนแปลงเศรษฐศาสตร์ของ CI:จัดเตรียมตามความต้องการ ยกเลิกการเตรียมเมื่อว่างเปล่า ฟื้นคืน CPU/RAM/storage เมื่อมนุษย์กลับบ้านนั่นคือรูปแบบ hyperscale — เข้าถึงได้สำหรับทีมใดก็ตามที่พร้อมจะแลกเปลี่ยนกองกำลังถาวรเป็นคิวของ pods

เริ่มต้นจากวิดีโอ ตั้ง operator + runner Helm ในห้องปฏิบัติการ เปิดการปรับขนาดโหนดแบบอัตโนมัติ แล้วตรวจสอบว่าวันเสาร์สุดท้ายดูเหมือนเงียบบนบิลหรือไม่

เผยแพร่โดยWorkstation