Een applicatie draait. Dan verschijnt een update, valt een server uit of hebben meerdere afdelingen tegelijk meer capaciteit nodig. Kubernetes organiseert waar containers draaien en hoe de afgesproken bedrijfstoestand wordt hersteld. Of dit de applicatie betrouwbaarder maakt, hangt af van de hele architectuur.
Neem een intern orderportaal: medewerkers voeren orders in, een interface draagt ze over aan het voorraadbeheersysteem en een achtergrondproces maakt documenten. Afzonderlijke containers kunnen deze taken uitvoeren. Wie ze los start, moet ook updates, herstarts en plaatsing op machines coördineren. Daar komt orkestratie in beeld.
De gewenste toestand wordt de basis voor beheer
In Kubernetes kunt u bijvoorbeeld vastleggen dat twee instanties van een webapplicatie een bepaalde softwareversie moeten draaien. Het platform vergelijkt deze gewenste toestand voortdurend met de werkelijke toestand. Een Deployment beschrijft de uitrol van een applicatie en beheert de Pods via een ReplicaSet-controller. Ontbreekt een instantie, dan probeert de besturing vervanging te regelen.
Dit helpt ook bij updates: een nieuwe versie kan geleidelijk worden uitgerold. Resources, opstartgedrag en de gekozen updatestrategie moeten dit ondersteunen. Een technisch geslaagde rollout bewijst niet dat een order correct is verwerkt. Die controle blijft onderdeel van de applicatie en haar tests.
Kernbegrippen uitgelegd via het orderportaal
- Containerimage
- De verpakte basis voor een applicatie, inclusief benodigde bestanden en runtimecomponenten. Vanuit dit image worden uitvoerbare containers gestart.
- Pod
- De kleinste uitrolbare eenheid in Kubernetes. Meestal bevat deze één applicatiecontainer; nauw verbonden containers kunnen een Pod delen en daarmee onder meer dezelfde netwerknamespace gebruiken. Twee kopieën van de webapplicatie betekenen normaal twee Pods.
- Node
- Een machine die Pods uitvoert. Een Node kan een virtuele machine of een fysieke server zijn. Kubernetes kan een virtualisatielaag dus aanvullen zonder deze noodzakelijk te vervangen.
- Cluster en control plane
- Het cluster verbindt de besturing met de Nodes die workloads uitvoeren. De control plane bevat onder meer API-server, toestandsdatabase, scheduler en controllers. Op de Nodes verzorgen kubelet en containerruntime de uitvoering.
- Service
- Een stabiel logisch toegangspunt voor een groep Pods. Hun adressen kunnen bij vervanging veranderen. De Service scheidt toegang van de afzonderlijke kortlevende instanties.
Wat er bij een storing werkelijk gebeurt
Als een Node uitvalt, kunnen beheerde Pods opnieuw op andere geschikte Nodes worden uitgerold. Dit vereist storingsdetectie, voldoende reservecapaciteit en toegang tot de benodigde gegevens. Een tweede instantie op dezelfde fysieke host beschermt niet tegen uitval van die host. Ook meerdere servers binnen hetzelfde stroom- of netwerkdomein kunnen een gezamenlijk uitvalpunt hebben.
Voor ons orderportaal betekent dit dat de webinterface mogelijk snel kan worden vervangen. Een al begonnen documenttaak moet echter zo zijn ontworpen dat herhaling geen dubbele factuur of order maakt. Sessies mogen bij vervanging van een instantie niet ongecontroleerd verloren gaan. Deze eigenschappen hangen af van de softwarearchitectuur en aangesloten systemen.
Drie servers vormen op zichzelf dus geen beschikbaarheidsplan. Besturing, applicaties, netwerk, opslag en de na uitval resterende capaciteit moeten samen worden beoordeeld. Hetzelfde geldt in de cloud of bij een managed Kubernetes-dienst: de feitelijke dienstverlening bepaalt welke verantwoordelijkheden bij de aanbieder liggen en welke bij het bedrijf blijven.
Persistente gegevens hebben een eigen plan nodig
Pods zijn vervangbaar. Bedrijfsgegevens mogen daarom niet uitsluitend in het beschrijfbare bestandssysteem van een container staan. Kubernetes kan persistente opslag koppelen via Persistent Volumes en de bijbehorende aanvragen, Persistent Volume Claims. Een StorageClass beschrijft hoe geschikte opslag kan worden ingericht.
Deze objecten maken de onderliggende opslag niet automatisch bestand tegen uitval. Een lokale schijf blijft aan haar infrastructuur gebonden; een externe opslagdienst heeft eigen prestatie- en uitvaleigenschappen. Ook een database buiten het cluster kan de juiste oplossing zijn. Applicatieondersteuning, gegevensconsistentie, toegangswegen en het afgesproken herstelproces zijn doorslaggevend.
Voor het portaal leggen we daarom apart vast hoelang het onbeschikbaar mag zijn, welk gegevensverlies aanvaardbaar is en hoe herstel wordt getest. Een cluster dat een onbedoelde verwijdering betrouwbaar naar elke instantie doorgeeft, vervangt geen back-up. Lees meer over back-up en herstel.
Wanneer de extra opzet zinvol is
Kubernetes wordt interessant wanneer meerdere applicaties regelmatig worden bijgewerkt, herhaalbare uitrol nodig is of workloads en beschikbare machines bewust moeten worden verdeeld. Het brengt ook taken voor platformupdates, toegangsbeheer, netwerk, opslag en bewaking mee.
Voor één stabiele applicatie kan een degelijk onderhouden server met Docker Compose of een gewone virtuele machine economisch beter passen. De beslissing moet beginnen bij het vereiste bedrijfsgedrag: welke onderbrekingen zijn aanvaardbaar? Hoe vaak zijn er wijzigingen? Wie doorgrondt de omgeving en kan die herstellen als er iets misgaat?
Een bruikbare pilot heeft toetsbare doelen
- Test een representatief bedrijfsproces met realistische gegevensvolumes en zonder productiegegevens van klanten.
- Oefen een update met de geplande terugweg. Beoordeel databaseschemawijzigingen afzonderlijk.
- Test onder gecontroleerde omstandigheden de uitval van één instantie en één geplande infrastructuurcomponent.
- Herstel een back-up in een aparte testomgeving en open de gegevens om te controleren of zij zakelijk bruikbaar zijn.
- Wijs benoemde verantwoordelijkheden toe voor alarmen, platformonderhoud en de applicatie.
DAXS helpt de applicatie te beoordelen en passende infrastructuur te kiezen en verzorgt implementatie en afgesproken beheer. Een eerste beoordeling met een concrete toepassing en heldere acceptatiecriteria is een praktische eerste stap.
Bronnen: Kubernetes: rol en grenzen van het platform · Clustercomponenten · Pods en hun levenscyclus · Deployments en updates · Services · Persistente opslag · Productieomgevingen plannen
