Kubernetes – Tips, triks og litt om oppsider og nedsider

Det er en endring i vinden for tiden i Europa hvor flere land som Sveits, Frankrike og Tyskland går bort fra det å bruke kommersielle løsninger som Google og Microsoft, til fordel for å bruke åpne løsninger (også kalt open source) som Nextcloud og Libreoffice. Vi på Offcenit bruker ofte åpne løsninger til hverdagslig jobb så vi tenkte vi skulle skrive litt om en av mest brukte åpne verktøy, Kubernetes.

Fordeler med Kubernetes

Grønne systemer og nettsider Selv om Kubernetes krever litt mer ressurser i starten, kan systemene kjøres over flere leverandører og utnytte ressursene optimalt. Det er sjeldent en maskin i Kubernetes som ikke utnyttes fullt. Utover dette kan du enkelt velge leverandører som kjører på grønn energi. Nettsiden Green Web Foundation har gode ressurser for å sjekke leverandører. Ofte kan for eksempel skyleverandører ikke være grønne.

Kubernetes gjør så du enkelt kan standardisere applikasjoner og koble på egne tjenester, som f.eks tar seg av loggføring, førstegangs oppsett av for eksempel brukere i en applikasjon som tar seg av loggføring, førstegangsoppsett av brukere i en applikasjon, som for eksempel å lage en admin-bruker for et CMS, håndtering av roller i databaser, og mer. Det gjorde compliance jobben plutselig mye lettere.

I Kubernetes krever alle applikasjoner «health checks” for å kjøre. Dette gjør at Kubernetes kan automatisk restarte applikasjoner som ikke kjører som de skal, men i tillegg standardiserer det også applikasjonene som gir merverdi for sikkerhet og overvåking av applikasjonene.

Gjør det mulig å håndtere infrastruktur på egenhånd, uten behov for store dedikerte team eller tredjeparter. På grunn av den automatiserte naturen til Kubernetes, så kan Kubernetes driftes av de samme som utvikler applikasjonene – så fremst de har kompetansen og systemet ikke er for kompleks.

Billig for robusthet Hvis du har satt opp Kubernetes riktig så kan du få 100% SLA, altså oppetid, 24/7. Du kan også som et lite selskap lage ditt egne enterprise klare miljø for kostnaden av et par VPS/servere. Altså VPS, det billigste du kan få. En database som du ville betalt 600,- kr betaler du nå under 50,- kr for.

Billig å utvikle og teste En annen stor fordel med lav kostnad gjør at du enkelt kan prøve nye applikasjoner i et lukket miljø som bare du og de du velger har tilgang til. Test så mye du vil og du kan enkelt koble til de eksisterende applikasjonene du har. Kubernetes har gitt oss en mulighet vi ikke ville fått med andre løsninger hvor vi ikke må bry oss om kostnaden rundt å ha flere miljø og finne de beste verktøyene.

Fallgruver

• Det tar tid å lære seg, men er ikke umulig å lære seg godt nok i løpet av ett par måneder. Det er best å holde seg til et begrenset antall tjenester i starten når man skal få ut et produksjonsmiljø. Les igjennom Kubernetes dokumentasjonen og lær deg alle de forskjellige ressursene som Pod, Noder (maskiner), Deployment, Secrets, Statefulset, PVC og PV, Services og Ingress (eller gateway).
• Kubernetes er et system hvor du bytter bort vedlikehold av drift for utviklingstid. Det krever mer tid på å sette opp den første gangen, men kan drastisk forminske driftskostnader og tiden du bruker på drift over tid. Driver du et oppstartselskap som har lite intern kompetanse på Kubernetes så kan det være bedre å skaffe seg en tredjepart som du vet allerede har mye av oppsettet og konfigurasjonen ferdig.
• Det virker kanskje noe overveldende til å begynne med, men alle ressursene i Kubernetes har et viktig formål som også finnes i mer tradisjonell infrastruktur. Forskjellen her er at du får alt i samme system istedenfor at du må lære flere system for å oppnå det samme.
• Dårlig oppsett kan gjøre at ting går ned. Ta tiden som trengs for å lære deg hver nye applikasjon, del applikasjoner i namespaces og de mest kritiske kan du kjøre på egne noder. Skal du teste noe nytt så kan du også ha egne noder for det så det ikke påvirker resten av clusteret.

Ting å vite før du kjører applikasjoner i Kubernetes

Legacy Applikasjoner

“Legacy” applikasjoner kan ofte lagre det som heter “state”, altså midlertidig data som forsvinner når applikasjonen restartes. Disse applikasjonene er ofte vanskelig å kjøre i Kubernetes ettersom om de restartes så kan det skape uforventede situasjoner. Dette er også et problem i tradisjonell infrastruktur, men i Kubernetes så restartes program oftere, så det vil bli et mer hyppig problem. Heldigvis er dette sett på som dårlig praksis og de fleste program lagrer midlertidige data i systemer som er laget for dette som “Redis” som fikser dette problemet. Innloggings data og “rate-limiting” for å hindre misbruk er typiske områder som man bruker slik type data. 

GitOps

Start med GitOps umiddelbart. For de som kanskje ikke kjenner til GitOps så er dette delvis relatert til IAC (infrastruktur som kode) og lignende verktøy som Terraform. Med mindre du kjører noe hjemme for å teste så vil du gjerne ha en struktur som lar deg se hva som ble gjort 1-2 mnd siden. Du får også en full oversikt over hva som kjører i Kubernetes og hvis du har gjort det rett kan enkelt kjøre det opp på ett nytt cluster senere.

Lagring i Kubernetes

I Kubernetes har du noe som heter PVC og PV som er et abstraksjonslag for containere som tar seg av hvor applikasjoner kan lagre data og hvordan de lagres. PVC’er har et par forskjellige “Modus” som er viktig å vite, de viktigste er ReadWriteOnce (RWO) og ReadWriteMany (RWX), det mest brukte er “ReadWriteOnce” som gjør at et lagringsvolum bare kan være koblet på en maskin. Dette er vanligvis greit, men kan skape problematikk for applikasjoner som ikke er laget for å skalere, altså om du har flere applikasjoner som kjører for å få et mer robust oppsett så vil ikke disse kommunisere for å samkjøre data. Dette er typisk for del CMS systemer som Ghost, WordPress, CraftCMS, Strapi og PayloadCMS. Da må ReadWriteMany brukes, men mange leverandører støtter ikke dette, så i praksis må du da kjøre program som “rook-ceph” for å ordne dette for deg.

Operators – Tenk formål

Operators er små program som kjører i Kubernetes for å håndtere andre programmer, konfigurasjoner, secrets m.m i Kubernetes. De brukes spesielt for å gjøre det enklere og mer robust å kjøre databaser i Kubernetes, men som alt så varierer kvaliteten på de en del. Noen av de vedlikeholdes av et fåtall personer, hvor kanskje bare en person aktivt utvikler prosjektet. Ikke bare se på funksjonalitet, men også om de oppdateres jevnlig, det slippes jevnlig feilrettinger for sikkerhet både av operativsystem, programmeringsspråk, pakke versjoner ol. så et aktivt prosjekt som tar sikkerhet seriøst burde være oppdatert relativt ofte. Hvis prosjektet har automatisert oppdatering av pakker (som renovate bot) så er det ofte et godt tegn. Når du skal velge en operator, sørg for at du sjekker at de er aktivt utviklet og har gode retningslinjer/prosesser rundt sikkerhet.

Operators har ofte forskjellige formål, noen er kanskje for å forenkle administrering av program, noe er for å gjøre ting mer robust, andre ting er for å utvide funksjonalitet. Husk at alle operators legger til kompleksitet og kan være et “single point of failure”, hvis operatoren ikke forenkler bruksformålet ditt så er det kanskje ikke et godt valg.

Lærdom etter fire år med Kubernetes

Vi har jobbet lenge med Kubernetes, og vi begynte faktisk å bruke Kubernetes i 2020, noe alle i selskapet behersker i dag. Her er et par «best practices» som vi tenker er greit å dele.

Del opp applikasjoner i namespaces

Del opp applikasjoner for forskjellige formål i det som heter «Namespaces». Dette gjør så du lett kan filtere på logger senere og i tillegg så kan secrets/sensitive data i Kubernetes bare leses av applikasjoner som ligger i samme namespace. Du kan også sette network policies som går fra/til andre namespaces, noe som gjør det enklere å isolere applikasjonene.

Må man være ekspert og trenger man et stort team?

Kubernetes er såpass automatisert at man ikke trenger et stort team for å drifte det. Men vi anbefaler at alle som utvikler applikasjoner som skal kjøres i Kubernetes også vet hvordan de gjør det som man tradisjonelt må kunne for å sette opp en applikasjon på en vanlig server.

Kubernetes har mye av de samme konseptene som tradisjonell drift men i en tilsvarende i Kubernetes format. Det er ikke en-til-en sammenligning, ettersom det er gjort mye som er gjort for å få en mer stabil og automatisert løsning ved bruk av «containere». Men vi kan ta et par grove oversettelser:

1. «Ingress» og «service» kan være DNS og brannmur.
2. «Node» er en VPS/server/maskin.
3. «Deployment»/»Statefulset» er en applikasjon/prosess som kjører på en server.
4.  «PV» er en harddisk, eller en nettverksdisk.
5. «PVC» er koblingen mellom disken og en maskin/node.

Og som ved tradisjonell drift, hvor man kanskje er en utvikler med litt DevOps ansvar; De som utvikler burde vite hvordan man sjekker logger, kjøre ut en ny applikasjon, legger til «environment variabler», gi tilgang fra applikasjonen til omverden osv. Det er logisk å ha en eller to person(er) på et utviklingsteam som kan Kubernetes skikkelig, imens resten kan Kubernetes «godt nok». Det å lære Kubernetes er som å lære et programmeringsspråk, så i et fungerende team så vil alle lære seg mer som de tar det i bruk.

Det er også en fordel om man har erfaring med «containere» eller containerdrift selv om man ikke trenger å vite alt om hvordan f.eks nettverk i Docker fungerer.

Husk å sett resource limits så du ikke tar livet av applikasjoner

Resource limit (og request limit) er viktig i Kubernetes, siden det sier noe om hvor mye en applikasjon er forventet å ha av ressursbruk og hvor mye de har lov til å ta i bruk. Hvis dette ikke blir satt på alle ressurser så risikerer du at en applikasjon spiser alt av ressursene på en node/maskin eller blir kjørt opp på en maskin med for lite ressurser. Hvis dette skjer, så gjør det at alle andre ressurser på samme maskin risikerer å gå ned.

Ofte oversett: Network policies

Network policies blir ofte oversett, selv om det er relativt enkelt å ta i bruk. Network policies tar i bruk Kubernetes sitt nettverkslag og sier noe om hvilke applikasjoner som har lov til å få tilgang til hva. Disse kan også knyttes fra og til namespaces.

Hva med multi-arkitektur?

Når du skal sette opp et nytt cluster så har du i noen valg å kjøre aarch/ARM eller AMD64 CPU arkitektur. Ofte er servere med ARM litt eller ganske mye billigere.

I skrivende stund så kjører den underliggende infrastrukturen helt fint på ARM, men program som kjører på toppen av Kubernetes ligger fortsatt bak. Om du tenker å kjøre ARM eller multi-arkitektur så er det viktig du skriver ned og tester det på en ARM maskin først. Eller så blir feilmeldingen exec: format error din nye daglige irritasjon og hodepine. Program som sliter med ARM i skrivende stund som jeg bare har vært borti de siste dager er: flamingo for ArgoCD, en WordPress operator og en MySQL operator. Ofte er databasene laget for å kjøre på ARM, men støttesystemer fungerer bare på AMD64.

Hva med nodeSelector? Node selector kan brukes for å gjøre at program kjører på et utvalg av maskiner og dette kan også gjøres for ARM64 ved å gjøre

nodeSelector:

beta.kubernetes.io/arch: amd64 #eller arm64

beta.kubernetes.io/arch er innebygd i Kubernetes, så dette støttes av alle K8S distribusjoner som kjører LTS (long term stability versjonering). Ulempen med dette er at om du bruker Helm, som for øyeblikket er industristandarden for å sette opp tjenester basert på maler, og de som har laget Helm charten ikke har nodeSelector lagt inn i values.yaml så må du nesten lage ditt eget Helm chart. Noe som kanskje kan være smart å gjøre uansett om du kjører et produksjonsmiljø ettersom en del Helm chart utviklere kan ha ganske spesifikke bruksområder som ikke overlapper med dine egne.

Sikkerhetsscanning, loggføring og automatiske oppdateringer

Områdene som sikkerhet, loggføring og automatiske oppdateringer er hvor Kubernetes virkelig skinner. Vi bruker dette hyppig i Offcenit.

Sikkerhetsscanning gjøres i dag ofte i en CICD pipeline om du utvikler og før du publiserer en ny versjon av et program. Men hva med de tjenestene som allerede kjører på et cluster? Hva skjer om versjonen av en database du kjører plutselig får en nulldagssårbarhet som må fikses “NÅ”, hvordan oppdager du dette når systemet du kjører har 50+ databaser? Der kommer sikkerhetsscanning inn og her finnes det mange valg i Kubernetes. Alle av de har fordeler og ulemper, som et forslag så kjører vi kubeclarity som gjør scanning ved regelmessige intervall. Et slikt program er både enkelt å sette opp og gir god innsikt av hvilke tjenester du kjører i et cluster med mest sårbarheter. Det finnes ingen helt 100% trygt system, men ved bruk av slike verktøy kan du gjøre en faktisk vurdering og sikre systemet fra en ende til en annen, helt i den grad det gir mening. Noe ikke mange andre kan skryte av.

Loggføring eller også det mer omfattende ordet “observabilitet” er også noe Kubernetes gjør mye enklere en andre system. Jeg vil fortsatt anbefale at de som lager applikasjonene gjør en god jobb og kanskje sender loggene flere steder. Men med Kubernetes kan du lett samle alle logger fra alle system som kjører bare ved bruk av det som heter en “sidecar”, et program som kjører ved siden av andre program og for eksempel samler logger fra “logsys” eller fra programprosessen og sender det til et sentralisert system. Her er ofte Grafana med Loki, Prometheus og hvis du liker OpenTelemetry, så har du Grafana Tempo.

Skjult kostnad Ofte har loggføring en høy “skjult” kostnad hos flere leverandører. En faktura på mange titusen for logger per måned er nok noe alle utviklere har hørt om eller erfart. Hos Kubernetes kan du logge alt av data hvor du vil for en lav penge (altså kroner, ikke tusenlapper), hvis du ønsker å sende det til en leverandør så kan du enkelt filtrere ut bare de dataene som er relevant så du ikke sprenger budsjettet i prosessering og lagringskostander.

Automatiske oppdateringer finnes i nesten alle systemer som Kubernetes kjører, ikke bare finnes det men det er ofte ganske enkelt å sette opp med automatisk “rollback” hvis noe går feil. Systemer som renovate bot, fluxcd (GitOps verktøy), ArgoCD og Helm gjør dette mulig.