Deployment

Konfigurering av deploy og kjøretids oppsett

På denne siden:

Fra versjon 2.0.0 av deployment helm-charten er autoskalering tilgjengelig og aktivert som standard.

Autoskalering benytter Horizontal Pod Autoscaler) for å automatisk skalere opp og ned en app basert på CPU forbruk.

Når man skal konfigurere hvordan autoskaleringen oppfører seg må man ta hensyn til to seksjoner i deployment/values.yaml.

1. resources cpu/minne garantier og grenser for app pods under kjøring, se: Resources konfigurasjon
2. autoscaling konfigurerer når din applikasjon skal skaleres opp eller ned.

Vi setter noen standard verdier basert på tester vi har utført og erfaringer vi har gjort oss, disse kan endre seg etter hvert som vi får mer erfaringer over tid.

Standard verdiene kan du se her

Et eksempel på hvordan du overskriver verdier:

I values.yaml i den sentrale helm-charten er replicaCount definert som følger:

replicaCount: 2
...

For å overskrive dette i den app endrer du filen deployment/values.yaml og legger replicaCount under deplyoment:

deployment:
  replicaCount: 3
...

Skalering

Initial skalering

Initial skalering er konfigurerbart med feltet replicaCount. Hvis autoskalering er aktivert vil autoskalerings logikken overstyre denne verdien. Eksempel hvor initial skalering er satt til 2:

deployment:
  replicaCount: 2

Autoscaling konfigurasjon

Autoscaling seksjonen konfigurerer når en applikasjon automatisk skal skaleres. Dette er håndtert av Horizontal Pod Autoscaler i kubernetes.

For å lese mer og Horizontal Pod Autoscaler kan du lese kubernetes sin dokumentasjon her.

Standard verdier hvis ikke overstyrt i deployment/values.yaml

deployment:
  autoscaling:
    enabled: true
    replicas:
      min: 2
      max: 10
    avgCpuUtilization: 70
    behavior:
      stabilizationWindowSeconds:
        scaleUp: 0
        scaleDown: 120

deployment.autoscaling.replicas

min: Det laveste antall pods autoskaleringen har lov til å sette. max: Det høyeste antall pods autoskalering har lov til å sette.

deployment.autoscaling.avgCpuUtilization

Terskelen for prosent av cpu request som er utnyttet før opp eller ned skalering skal skje.

Oppskaleringen er ikke umiddelbar siden en ny pod trenger tid på å starte (1-2 min i de fleste tilfeller). Hvis alle ressursene i et cluster er reservert må en ny node startes opp i azure (5-10 min i de fleste tilfeller). Det er derfor lurt å ha en liten buffer sånn at applikasjonen kan håndtere lasten frem til kapasiteten er utvidet.

deployment.autoscaling.behavior.stabilizationWindowSeconds

Stabiliserings vindu er benyttet for å begrense blafring av replikaer når metrikkene som er brukt for skalering svinger.

Som standard vil en oppskalering skje så fort forbruket er over terskelverdiene. Nedskalering vil vente i to minutter.

scaleUp: Antall sekunder kubernetes skal vente etter siste skalering før den gjør en ny evaluering om oppskalering. scaleDown: Antall sekunder kubernetes skal vente etter siste skalering før den gjør en ny evaluering om nedskalering.

Resources konfigurasjon

For å sette gode requests og eventuelt limits er kjennskap til appen viktig da koden og oppgavene applikasjonen utfører har stor innvirkning på dette. Vi forsøker å sette kode standard verdier som fungerer for så mange av alle appene i Altinn som mulig, men det er ikke sikkert de passer for din app.

Standard verdier hvis de ikke blir overskrevet i deployment/values.yaml

deplyoment:
  resources:
    requests:
      cpu: 300m
      memory: 256Mi

Verdier som er mulige å konfigurere (verdiene under er kun som et eksempel og på ingen måte en fasit)

deplyoment:
  resources:
    requests:
      cpu: 200m
      memory: 256Mi
    limits:
      cpu: 1000m
      memory: 512Mi

deployment.resources.requests

Denne seksjonen i values.yaml definerer ressursene som din app vil få reservert av kubelet i clusteret.

Requests er brukt av kubernetes sin skedulerer for å finne noden den skal plassere appen sine pods på. Dette vil begrense hvor mange pods en node kan kjøre før den er full.

Requests er også brukt av Horizontal Pod autoscaler for å avgjøre om det skal skalere opp eller ned antall replikaer av appen.

Gitt et cluster med noder som har 2 cores (2000 millicores) og 4Gi minne hvor alle pods har requests satt til 200m (200 millicores) og 256Mi.

Antall pods en node kan kjøre basert på CPU request er: 2000 / 200 = 10

Antall pods en node kan kjøre basert på minne request er: 4096Mi / 256Mi = 16

Antall pods en node kan kjøre, med eller uten last i løsningen er da: 10.

Requests begrenser ikke hvor mye CPU eller minne en applikasjon kan bruke dersom mer er tilgjengelig, men blir det lite ressurser og en pod bruker mer enn requests kan denne blir “kastet ut” av noden.

deployment.resources.limits

Denne seksjonen i values.yaml definerer hvor mye en pod kan maksimalt bruke.

Hvis en pod forsøker å benytte mer CPU en det som er satt som limit vil denne bli strupet.

Hvis en pod forsøker å allokere mer minne en det som er satt som limit vil den bli terminert med en Out Of Memory (OOM) error.

Linkerd

Alle applikasjoner som deployes er som standard innlemmet i Linkerd sitt service mesh.

Vi anbefaler på det sterkeste å ikke endre denne innstillingen da den legger på mutual TLS som krypterer all intern kommunikasjon mellom tjenester i klusteret før det forlater en maskin.

deployment:
...
  linkerd:
    enabled: true
...

Volumes and VolumeMounts

Disse delene gjør det mulig å mounte opp forskjellige ressurser til filsystemet til en applikasjon. Det er to predefinerte mounts som benyttes av standard funksjonalitet for å blant annet kommunisere med Altinn Platform.

deployment:
...
  volumeMounts:
    - name: datakeys
      mountPath: /mnt/keys
    - name: accesstoken
      mountPath: "/accesstoken"
  volumes:
    - name : datakeys
      persistentVolumeClaim:
        claimName: keys
    - name: accesstoken
      secret:
        secretName: accesstoken

På gjeldende tidspunkt er det kun en use case for å legge til andre volumer: Hente hemmeligheter fra Azure Key Vault

Service

Service konfigurasjonen gjør det mulig å endre hvilke port som eksponeres internt i clusteret og hvilken intern port dette skal mappes til. Det er sjelden disse verdiene må endres. Hvis din applikasjon kjører på annen port enn 5005 så endrer du internalPort. EksternalPort må ikke endres Standard oppsett er:

deployment:
...
  service:
    name: deployment
    type: ClusterIP
    externalPort: 80
    ## If your application is running on another port, change only the internal port.
    internalPort: 5005
...

Deler som blir overskrevet ved deploy

• image
• ingressRoute

Disse områdene blir overskrevet ved deploy så endringer her vil ha liten til ingen effekt.