Innstillinger for publisering

Oversikt over innstillingene i deployment/values.yaml som styrer hvordan appen kjører etter publisering

Når du publiserer appen, kjører den i et Kubernetes-cluster. Altinn bruker et felles Helm-chart for alle apper. Et Helm-chart er en mal som beskriver hvordan appen skal kjøre, for eksempel hvor mange kopier av appen som kjører samtidig, og hvor mye CPU og minne hver kopi får.

Chartet har standardverdier som passer for de fleste apper. Du finner dem i values.yaml i altinn-studio-charts. Altinn velger hvilken versjon av chartet appen bruker når du publiserer den. Du trenger ikke oppgradere chartet selv.

Endre innstillingene for appen

Du endrer innstillingene i filen deployment/values.yaml, som ligger i rotmappen til app-repoet. Det du skriver der, overstyrer standardverdien i chartet. Innstillinger du ikke skriver, beholder standardverdien.

Legg innstillingene på toppnivå i filen, slik den gjeldende app-malen og chartet gjør. Bruk mellomrom til innrykk, ikke tabulator.

Appen kan ikke ha egne Helm-maler. Har app-repoet filer som ligger direkte i mappen deployment/templates, feiler publiseringen.

Innstillinger for hvert miljø

Legg en valgfri deployment/values.<miljø>.yaml ved siden av deployment/values.yaml i rotmappen til app-repoet. Bruk det nøyaktige miljønavnet: values.tt02.yaml for TT02 eller values.production.yaml for produksjon.

Miljøfilen overstyrer fellesverdiene. Innstillinger du utelater, beholder verdiene sine. For lister erstatter miljøfilen hele listen. Verdier som Altinn setter ved publisering, går fortsatt foran. Legg innstillingene på toppnivå også i miljøfilen.

Dette eksempelet begrenser TT02 til én kopi med autoskalering slått på:

autoscaling:
  enabled: true
  replicas:
    min: 1
    max: 1

Uten en miljøfil fungerer publiseringen som før.

Skalering

Autoskalering

Appen skalerer seg selv opp og ned etter hvor mye CPU den bruker. Kubernetes starter flere kopier når belastningen øker, og stopper kopier når den går ned.

Standardverdier i chartet:

autoscaling:
  enabled: true
  replicas:
    min: 2
    max: 6
  avgCpuUtilization: 75
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
        - type: Pods
          value: 1
          periodSeconds: 15
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Pods
          value: 1
          periodSeconds: 60

• replicas.min og replicas.max er det laveste og det høyeste antallet kopier appen kan ha.
• avgCpuUtilization er hvor mange prosent av CPU-reservasjonen (resources.requests.cpu) kopiene i snitt skal bruke før Kubernetes starter flere.
• behavior styrer hvor raskt antallet endrer seg. Med standardverdiene starter Kubernetes høyst én ny kopi hvert 15. sekund så lenge belastningen er høy. Når belastningen går ned, venter Kubernetes fem minutter og stopper deretter høyst én kopi i minuttet.

Det tar tid å starte en ny kopi, og enda lengre tid hvis clusteret må starte en ny maskin først. Sett derfor avgCpuUtilization så lavt at appen tåler belastningen til de nye kopiene er klare.

Slik setter du for eksempel det høyeste antallet kopier til 10:

autoscaling:
  replicas:
    max: 10

Fast antall kopier

replicaCount bestemmer antallet kopier når autoskalering er slått av. Standardverdien er 2. Så lenge autoskalering er slått på, bruker Kubernetes ikke replicaCount.

autoscaling:
  enabled: false
replicaCount: 3

CPU og minne

resources bestemmer hvor mye CPU og minne hver kopi av appen får. Hva som passer, avhenger av hva appen gjør. Standardverdiene i chartet:

resources:
  requests:
    cpu: 50m
    memory: 256Mi

50m betyr 50 milli-CPU, altså fem prosent av én CPU-kjerne. 256Mi betyr 256 mebibyte, omtrent 268 megabyte.

Eksempel på egne verdier. Verdiene er bare et eksempel, ikke en anbefaling:

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

requests: det appen får reservert

requests er CPU og minne som Kubernetes reserverer for hver kopi. Kubernetes bruker tallene til å bestemme hvilken maskin kopien skal kjøre på, og hvor mange kopier som får plass på hver maskin.

Autoskaleringen regner også ut fra requests. Se avgCpuUtilization over.

requests er ikke et tak. En kopi kan bruke mer hvis maskinen har ledig kapasitet. Men når maskinen får for lite ressurser, kan Kubernetes stoppe kopier som bruker mer enn de har reservert.

limits: det meste appen kan bruke

limits er taket for hver kopi. Chartet setter ingen tak som standard.

• Bruker kopien mer CPU enn taket, går den tregere.
• Bruker kopien mer minne enn taket, stopper Kubernetes den med feilen Out Of Memory (OOM).

Linkerd

Alle apper er med i Linkerd, som krypterer trafikken mellom tjenestene i clusteret. Standardverdien i chartet er:

linkerd:
  enabled: true

Volumer

volumes og volumeMounts kobler filer og lagring til filsystemet i appen. volumes beskriver hva du kobler til, og volumeMounts sier hvor i filsystemet det havner.

values.yaml fra app-malen har allerede de to volumene appen trenger for å kommunisere med Altinn-plattformen, datakeys og accesstoken. Behold dem, og legg eventuelle nye volumer under dem.

Det vanligste du legger til volumer for, er innstillingene appen trenger for å koble seg til Azure Key Vault og hente hemmeligheter derfra. Les mer på siden om hemmeligheter.

Port

service bestemmer hvilken port appen svarer på inne i clusteret. Standardverdiene i chartet er:

service:
  type: ClusterIP
  externalPort: 80
  internalPort: 5005

App-malen svarer på port 5005. Har du endret porten i appen, setter du internalPort til samme port:

service:
  internalPort: 5007

Innstillinger Altinn setter ved publisering

Altinn setter disse innstillingene når du publiserer appen:

• image.repository, image.tag og image.pullSecrets
• image.envFrom og image.environment
• service.name
• altinn.studio/deployment-id under podAnnotations
• ingressRoute

Verdiene fra Altinn går foran verdiene i values.yaml. Ikke sett dem i values.yaml.