chp:quota

Quota

Het verbruik van projecten worden op verschillende manieren gemeten in zichtbaar gemaakt, de volgende 3 statistieken zijn voor projecten en pods beschikbaar:

  • Request: geeft aan hoeveel cpu of memory je voor een pod nodig denkt te hebben en wat het platform voor je moet reserveren.
  • Limit: geeft aan hoeveel een pod mag gebruiken, dit is voornamelijk bedoeld zodat je niet teveel resources gaat gebruiken en is meer een beschermer van op hol geslagen processen en beschermer van de portomonee.
  • Usage: Dit is hoeveel cpu of memory momenteel actief gebruikt wordt door de pod

De request en limit zijn ook instelbaar voor DeploymentConfigs en BuildConfigs.
Deze is bijvoorbeeld instelbaar via DeploymentConfig:

apiVersion: build.openshift.io/v1
kind: DeploymentConfig
spec:
  resources:
    limits:
      cpu: "200m"
      memory: 256Mi

Hier is de cpu instelbaar via:

  • <getal>m voor mili cores (bijv. cpu: “200m” voor 200 mili cores of 0.2 volle cores)
  • <getal> (zonder m) voor volle cores (bijv. cpu: “1”)

Memory is in te stellen via een getal gevolgd door Mi (MegaByte) of Gi (GigaByte)

Standaard, zonder in te stellen, krijgt een pod 100m cores + 128Mi geheugen als request en 200m cores en 128Mi als limit. Dit zijn redelijk standaard limieten en hoeven vaak niet aangepast te worden tenzij echt nodig. Alleen voor database pods is het vaak aan te raden om de request en limit voor beide cpu en memory hoger te zetten.

Wij adviseren om de quota's niet te ruim/hoog te zetten. De request hoeveelheid wordt gebruikt om te bepalen waar een pod kan komen te draaien.

Dit kun je zien als een parkeerplaats, de hoger de request de groter de voertuig en de moeilijker deze te parkeren wordt de voller de parkeerplaats is. Een smart is stukken makkelijker te parkeren dan een vrachtwagen.

Standaard bewaard het platform alle oude builds, dit zijn de succesvolle builds voor rollback functionaliteit en gefaalde builds voor het debuggen. Het nadeel van dit bewaren is dat deze wel in je gereserveerde resources bijten en hierdoor je project door z'n maximale resources heen gaat.

Dit is op te lossen door in je BuildConfig te definieren hoeveel van deze builds je wil bewaren. Dit kan op de volgende manier:

apiVersion: "v1"
kind: "BuildConfig"
metadata:
  name: "sample-build"
spec:
  successfulBuildsHistoryLimit: 2 
  failedBuildsHistoryLimit: 2

met successfulBuildsHistoryLimit geef je aan hoeveel succesvolle builds je wilt bewaren, dit tbv rollbacks.
met failedBuildsHistoryLimit geef je aan hoeveel gefaalde builds je wilt bewaren, dit tbv debugging.

  • chp/quota.txt
  • Last modified: 2020/10/17 11:12
  • (external edit)