Infrastruktur für KGR-Runner

Überblick über Infrastruktur-Runner

Runner-Name/Tag-Präfix	Runner-Executor-Typ - Plattform
kgr1	Kubernetes - Tanzu Kubernetes Grid von Broadcom (VMware)
kgr2	Docker - Docker in bwCloud VM
kgr3	Kubernetes - microK8s auf bwCloud VM
kgr4	Kubernetes - k3s auf bwCloud VM

Tanzu Cluster - KGR1

Unser Kubernetes-Cluster ist wie folgt aufgebaut:

Knoten	Knotenzahl	CPU/RAM	Disk - /	Disk - /builds/
groß+	1	8/64	160	80
groß	4	8/32	160	80
Control plane	3

WARNUNG ⚠️: Die Knoten sind stellt als „best-effort“, d.h. die Tanzu Implementierung versucht, die Spezifikationen bestmöglich einzuhalten, kann diese aber unter Umständen nicht ganz erreichen.

HINWEIS 🗒️: Auf den Steuerungsknoten (Control Plane) laufen keine Workloads.

WARNUNG ⚠️: Der experimentelle Runner läuft auf einem Standard- oder Test-Cluster.

bwCloud - KGR2-4

HINWEIS 🗒️: Einige Ressourcen gehen an Docker/Kubernetes Implementierung und das Host-OS der VM, aber diese verbrauchen nicht viel.

Runner und seine VM's	Knotenzahl	CPU/RAM	Disk - /
kgr2-instance-hugedisk
large	1	4/8	128
kgr2-instance-standard
xlarge	1	8/16	128
kgr3-instance-standard
xlarge	1	8/16	128
kgr4-instance-standard
xlarge	1	8/16	128

Parametererklärung ℹ️

• Runner und seine VMs: Gruppen von Runnern und seine Knoten
• Knoten: Gruppe von Knoten
• Knotenzahl: Wie viele Knoten dieses Typs verfügbar sind
• CPU/RAM: Menge der Ressourcen, Speicher in GiB
• Disk - /: Größe des auf Root gemounteten Speichers im GiB für Jobs. Der Speicher wird auf dem gesamten Knoten zwischen Jobs und Prozessen geteilt, der Wert dient nur zur Information
• Disk - /builds/: Größe des gemounteten Speichers im GiB für Repository-Verzeichnisse (Build-Verzeichnis). Auch dieser Speicher wird zwischen Jobs auf dem gesamten Knoten geteilt, der Wert ist rein informativ (falls kein Verzeichnis /builds/ vorhanden ist, befindet sich der Speicherplatz auf derselben Festplatte wie /)

Beziehung zwischen Knotengrößen und Runner-Größen - Kubernetes Runners

Die Größen von Knoten und Runnern hängen eng zusammen. Hier ist die Verbindung zwischen mittlerem Knoten und Standard-Runner, dargestellt anhand der Regeln für „request“ (garantierte Werte für Jobs, untere Grenze) und „limit“ (begrenzende Werte, obere Grenze):

• Request und Limit:

  • Designknot - 4 Kerne Knot mit 16 GB Speicherplatz
  • Die Request-Werte sind so gesetzt, dass 3 Runner (1 Haupt- und 1 Hilfs-Container) auf einem Designknoten laufen können.
  • Die Limit-Werte sind so gesetzt, dass 2 Runner (1 Haupt-, 1 Hilfs- und 1 Service-Container) auf einem Designknoten laufen können.

• Überschreibungswerte (fortgeschrittene Benutzer können sie in der Pipeline-Spezifikation setzen):

  • Das Limit-Override ist so gesetzt, dass 2 Runner (1 Haupt- und 1 Hilfs-Container) auf einem großen Knoten laufen können.
  • Das Request-Override liegt knapp unter dem Limit-Override.

• Service-Container-Override:

  • Die Overrides für Service- und Hilfs-Container sind bewusst etwas höher gesetzt als der Standard.

• Speicher:

  • Der flüchtige Speicher (ephemeral storage) folgt ebenfalls diesen Regeln, allerdings weniger strikt.

Das Diagramm zeigt die Größenrelationen zwischen Runner-Requests/-Limits und Knotengrößen. Es zeigt die Entwurfsgröße des Knotens (virtuelle Einheit zur Planung der Runner-Größe). Die Standard-Runner werden so konzipiert, dass zwei hineinpassen und gleichzeitig die größtmöglichen Ressourcen für Haupt- und Hilfscontainer genutzt werden. Die Anforderung ist so formuliert, dass selbst bei Verwendung von Service-, Haupt- und Hilfscontainer drei Runner in einen Entwurfsknoten passen.

WARNUNG ⚠️: Ressourcenbeschränkung außer der Runner-Arbeitslast

• Es bleibt auf jedem Knoten etwas Reserve, selbst bei drei Pods mit Request-Werten.
• In der Realität läuft zusätzliche Last (z. B. Monitoring), daher unterscheidet sich der reale Einsatz leicht.
• Bei Verwendung von Best-Effort-Knoten am "kgr1 Cluster" kann die Knotengröße leicht abweichen.