Skip to content

Advanced runner specification

NOTE 🗒ī¸: The sizes have each individual sizes of help and service containers. If you are not using them specifically you can ignore the following specification

Parameter explanation ℹī¸

The specification is in format lower - upper. Lower number in the range is guaranteed and the upper number is the limit.

Terms explanation:

  • Concurrency per job: how many jobs can this runner process (always in separated environments for each user/project/job)
  • Cores: Available cores of the runner for one job
  • Memory: Available memory of the runner for one job in GiB
  • Disk: Available disk space of the runner for one job in GiB

Runner sizes

KGR1

Concurrency per Job Cores Memory Disk
kgr1-instance-mini
main container 1 0.5 - 0.5 1.6 - 2 4 - 13
service container 0 - N 0.2 - 0.3 0.4 - 0.8 2 - 4
helper container 1 0.1 - 0.15 0.5 - 0.5 0.25 - 0.5
kgr1-instance-standard
main container 1 1 - 1 2.8 - 3.7 10 - 26
service container 0 - N 0.3 - 0.6 1 - 2 2 - 8
helper container 1 0.2 - 0.3 0.5 - 0.75 0.25 - 1
kgr1-instance-extraordinary
main container 1 4 - 6 44 - 45 44 - 92
service container 0 - N 1 - 1 4 - 8 12 - 24
helper container 1 0.8 - 0.9 1 - 4 1 - 4

KGR2

NOTE 🗒ī¸: The values are maximum, the docker runner is running on its own machine and the maximum depends on the current system resources and other possible jobs.

Concurrency per job Cores Memory Disk
kgr2-instance-hugedisk
Haupt container 1 2 8 128
Service container 0-N 2 8 128
kgr2-instance-standard
Main container 1 16 32 128
Service container 0-N 16 32 128

KGR3

Concurrency per job Cores Memory Disk
kgr3-instance-standard
main container 1 1 - 1 2.8 - 3.7 10 - 26
service container 0 - N 0.3 - 0.6 1 - 2 2 - 8
helper container 1 0.2 - 0.3 0.5 - 0.75 0.25 - 1

Size modification for advanced user

WARNING ❗: The resource limit ranges has been tailored to fit the underlying infrastructure and should work fine with most of the workloads. If you change it, runners may not be starting or failing.

In some use cases you might need special resource setup. For such case you can overwrite the request (minimal guaranteed) and limit (maximal guaranteed) of each resources, but within predefined overwrite ranges.

KGR1

Cores Memory Disk
kgr1-instance-mini
main container 0.5 - 0.5 1.6 - 2 4 - 13
service container 0.2 - 0.3 0.4 - 0.8 2 - 4
helper container 0.1 - 0.15 0.5 - 0.5 0.25 - 0.5
kgr1-instance-standard
main container 1.5 - 1.56 5.37 - 5.47 24 - 32
service container 1 - 1 2 - 2.25 8 - 16
helper container 0.3 - 0.4 0.75 - 1 1 - 2
kgr1-instance-extraordinary
main container 7 - 7 50 - 53 116 - 116
service container 2 - 2 16 - 16 64 - 64
helper container 1 - 1 4 - 8 16 - 16

KGR2

Not supported

KGR3

Cores Memory Disk
kgr3-instance-standard
main container 1.5 - 1.56 5.37 - 5.47 24 - 32
service container 1 - 1 2 - 2.25 8 - 16
helper container 0.3 - 0.4 0.75 - 1 1 - 2

Concurrency and its limits

Runner concurrency limit

Each runner has assigned limit for concurrency, which limits how many jobs it can run at once (for all users together).

Global concurrency limit

alt text Explanational diagram

Global concurrency essentially means that the combining cpu and momery by conrrent value are only available resourc on the entire Tanzu cluster.

In our cluster no global concurrency is set by configuration, but by the hardware size. Our goal is to always use maximally the whole clusters for runners, so there is no hardcoded number for limitation. Still there exist a limit which globally borders the global concurrency, this limit is lower then total sum of each runner concurrences limits.