En applikation kører. Så kommer en opdatering, en server svigter, eller flere afdelinger har brug for mere kapacitet samtidig. Kubernetes organiserer, hvor containere kører, og hvordan den aftalte driftstilstand genskabes. Om det giver en mere pålidelig applikation, afhænger af hele arkitekturen.
Tag en intern ordreportal: medarbejdere registrerer bestillinger, en grænseflade overfører dem til lagerstyringen, og en baggrundsproces opretter dokumenter. Separate containere kan løse disse opgaver. Den, der starter dem enkeltvis, skal også koordinere opdateringer, genstarter og placering på maskiner. Det er her, orkestrering kommer ind.
Den ønskede tilstand bliver grundlaget for driften
I Kubernetes kan man eksempelvis angive, at to instanser af webapplikationen skal køre en bestemt softwareversion. Platformen sammenligner løbende den ønskede tilstand med den faktiske. Et Deployment beskriver udrulningen af en applikation og lader en ReplicaSet-controller administrere dens Pods. Mangler en instans, forsøger styringen at oprette en erstatning.
Det er også nyttigt ved opdateringer: en ny version kan rulles ud gradvist. Ressourcer, opstartsadfærd og den valgte opdateringsstrategi skal understøtte det. En teknisk vellykket udrulning viser ikke, om en ordre er behandlet korrekt. Den kontrol er fortsat en del af applikationen og dens test.
De vigtigste begreber forklaret med ordreportalen
- Containerimage
- Det pakkede grundlag for en applikation med de nødvendige filer og runtimekomponenter. Kørbare containere startes fra dette image.
- Pod
- Den mindste enhed, der kan udrulles i Kubernetes. Den indeholder typisk én applikationscontainer; tæt forbundne containere kan dele en Pod og blandt andet dens netværksnamespace. To kopier af webapplikationen betyder normalt to Pods.
- Node
- En maskine, der kører Pods. En node kan være en virtuel maskine eller en fysisk server. Kubernetes kan derfor supplere et virtualiseringslag frem for nødvendigvis at erstatte det.
- Klynge og kontrolplan
- Klyngen forbinder styringen med de noder, der udfører opgaverne. Kontrolplanet omfatter blandt andet API-server, tilstandsdatabase, scheduler og controllere. På noderne sørger kubelet og containerruntime for udførelsen.
- Service
- En stabil logisk adgang til en gruppe Pods. Deres adresser kan ændre sig, når de udskiftes. En Service adskiller adgangen fra de enkelte kortlivede instanser.
Hvad der faktisk sker ved et nedbrud
Hvis en node svigter, kan administrerede Pods oprettes igen på andre egnede noder. Det kræver registrering af fejlen, tilstrækkelig ledig kapacitet og adgang til de nødvendige data. En anden instans på samme fysiske vært beskytter ikke mod værtens nedbrud. Flere servere i samme strøm- eller netværksområde kan også dele et fejlpunkt.
For ordreportalen betyder det, at webgrænsefladen måske hurtigt kan erstattes. En dokumentopgave, der allerede er startet, skal dog være designet, så en gentagelse ikke opretter en dobbelt faktura eller ordre. Sessioner må ikke gå tabt ukontrolleret, når en instans erstattes. Det afhænger af softwarearkitekturen og de tilsluttede systemer.
Tre servere er derfor ikke i sig selv en tilgængelighedsplan. Styring, applikationer, netværk, lager og den kapacitet, der er tilbage efter et nedbrud, skal vurderes samlet. Det gælder også i skyen eller med en administreret Kubernetes-tjeneste: det konkrete serviceomfang afgør, hvilke opgaver udbyderen har, og hvilke der bliver i virksomheden.
Vedvarende data kræver deres egen plan
Pods kan erstattes. Forretningsdata må derfor ikke kun ligge i containerens skrivbare filsystem. Kubernetes kan tilslutte vedvarende lager gennem Persistent Volumes og de tilhørende anmodninger, Persistent Volume Claims. En StorageClass beskriver, hvordan egnet lager kan stilles til rådighed.
Disse objekter gør ikke automatisk det underliggende lager robust. En lokal disk er fortsat bundet til sin infrastruktur; en ekstern lagertjeneste har sine egne ydelses- og fejlegenskaber. En database uden for klyngen kan også være den rigtige løsning. Applikationssupport, datakonsistens, adgangsveje og den aftalte gendannelse er afgørende.
For portalen fastlægger vi derfor særskilt, hvor længe den må være utilgængelig, hvilket datatab der kan accepteres, og hvordan en gendannelse afprøves. En klynge, der pålideligt spreder en utilsigtet sletning til alle instanser, erstatter ikke en sikkerhedskopi. Læs mere om backup og gendannelse.
Hvornår den ekstra opsætning betaler sig
Kubernetes bliver interessant, når flere applikationer opdateres regelmæssigt, gentagelig udrulning er nødvendig, eller belastning og tilgængelige maskiner skal fordeles målrettet. Samtidig skaber det opgaver med platformopdateringer, adgangsstyring, netværk, lager og overvågning.
Til én stabil applikation kan en ordentligt vedligeholdt server med Docker Compose eller en almindelig virtuel maskine passe bedre økonomisk. Beslutningen bør begynde med de ønskede driftsegenskaber: hvilke afbrydelser er acceptable? Hvor ofte kommer ændringer? Hvem forstår miljøet og kan gendanne det, når noget går galt?
En nyttig pilot har mål, der kan efterprøves
- Test en repræsentativ forretningsproces med realistiske datamængder og uden kundedata fra produktion.
- Afprøv en opdatering med den planlagte vej tilbage. Vurder ændringer i databaseskemaet særskilt.
- Test under kontrollerede forhold fejl på én instans og én planlagt infrastrukturkomponent.
- Gendan en sikkerhedskopi i et separat testmiljø, og åbn den for at kontrollere, at forretningsdata kan bruges.
- Udpeg ansvarlige for alarmer, platformvedligeholdelse og applikationen.
DAXS hjælper med at vurdere applikationen og vælge passende infrastruktur samt med implementering og aftalt drift. En kortlægning med en konkret anvendelse og tydelige acceptkriterier er et praktisk første skridt.
Kilder: Kubernetes: platformens rolle og grænser · Klyngens komponenter · Pods og deres livscyklus · Deployments og opdateringer · Services · Vedvarende lager · Planlægning af produktionsmiljøer
