Een applicatie in containers heeft een passend beheermodel nodig. Docker Compose kan voldoende zijn voor een productiedienst met overzichtelijke complexiteit. Kubernetes wordt interessant wanneer applicaties over meerdere machines moeten draaien en hun uitrol gecoördineerde besturing nodig heeft. De beslissing begint bij de eisen van de applicatie.
Een bedrijf beheert een intern portaal met webinterface, database en achtergrondverwerking. Er is een onderhoudsvenster, een overzichtelijke belasting en een aangewezen beheerder. Een ander bedrijf brengt meerdere keren per week nieuwe versies van verschillende diensten uit en moet tijdens gepland onderhoud beschikbaar blijven. Beide gebruiken containers, maar verschillende beheermodellen kunnen passend zijn.
Docker, Compose en Kubernetes hebben verschillende doelen
Een containerruntime voert de containers uit. Docker Engine biedt hiervoor een veelgebruikt platform. Docker Compose beschrijft de diensten van een applicatie in een YAML-bestand. Daarin kunnen images, netwerken, persistente volumes en configuratie samenkomen. De Compose-tools maken en beheren de applicatie op de Docker-host waarmee zij verbonden zijn.
Kubernetes beheert een gewenste toestand voor workloads in een cluster. Het plant Pods op geschikte Nodes en kan beheerde instanties vervangen of geleidelijk bijwerken. Elke Node heeft nog steeds een geschikte containerruntime nodig. Een Compose-bestand en Kubernetes-resources beschrijven uitrol verschillend; migratie omvat dus meer dan een bestand hernoemen.
De bedrijfsgrootte zegt weinig over deze beslissing. Een klein softwareteam met frequente releases kan baat hebben bij orkestratie. Een veel groter bedrijf kan voor één ondersteunde bedrijfsapplicatiedienst goed geholpen zijn met één degelijk onderhouden host.
Docker Compose is ook bedoeld voor productiegebruik
Docker documenteert het gebruik van Compose in productie uitdrukkelijk, met name op één server. Ontwikkel- en productieconfiguraties kunnen gescheiden blijven of gericht worden uitgebreid. Herstartbeleid, gepubliceerde poorten, logging en het updateproces moeten bij de productieomgeving passen.
Voor een intern documentenportaal kan dit een overzichtelijke opzet zijn: een beheersbare set diensten, vastgelegde versies, beschermde gegevens en geteste herstelprocedures. Hostuitval vereist nog steeds een afzonderlijk plan. Een herstartbeleid verplaatst een applicatie niet naar een andere machine. Redundantie van een onderliggend virtualisatieplatform en applicatieback-ups zijn eveneens aparte lagen.
Ook de door de softwareleverancier ondersteunde installatiemethode telt. Een officieel onderhouden Compose-uitrol kan in beheer waardevoller zijn dan een eigen clusterinstallatie zonder betrouwbaar updatepad.
Een beslismatrix voor het beheer
| Vraag | Docker Compose op één host | Kubernetes |
|---|---|---|
| Hoe groot is de omgeving? | Geschikt voor afzonderlijke applicaties met een overzichtelijke set diensten. | Meerdere workloads en Nodes kunnen met gezamenlijk platformbeleid worden beheerd. |
| Wat gebeurt er bij hostuitval? | Herstel of infrastructuurredundantie wordt buiten Compose georganiseerd. | Vervanging op andere Nodes is mogelijk wanneer applicatie, capaciteit, control plane en gegevenstoegang daarop zijn voorbereid. |
| Hoe worden releases uitgerold? | Betrokken diensten worden via een vastgelegd en waar nuttig geautomatiseerd proces vervangen. | Uitrolbeleid ondersteunt gecontroleerde rollouts. Gegevenswijzigingen en functionele tests vragen nog steeds een eigen plan. |
| Waar staan bedrijfsgegevens? | In volumes of externe diensten met eigen back-up- en herstelprocedures. | In persistente opslag of externe diensten waarvan de robuustheid en back-up nog moeten worden beoordeeld. |
| Wie onderhoudt het platform? | De verantwoordelijkheid omvat host, runtime, images en applicatie. | Daar komen cluster, netwerkintegratie, opslagintegratie en hun levenscycli bij. |
| Hoe wordt de toestand van de dienst beoordeeld? | Host, diensten en bedrijfsprocessen worden bewaakt. | Ook het cluster en de wisselwerking tussen platformcomponenten worden bewaakt; alleen een draaiende Pod is onvoldoende. |
| Wat ondersteunt de leverancier? | De ondersteunde installatiemethode en het updatepad zijn doorslaggevend. | Er moeten een beheersbare Kubernetes-uitrol en passende leveranciersondersteuning beschikbaar zijn. |
Wanneer Kubernetes concreet voordeel biedt
Een goede reden kan zijn om veel vergelijkbare uitrollen consistent te beheren of beschikbare rekencapaciteit over verschillende diensten te verdelen. Ook frequente updates met helder uitrolbeleid en gescheiden verantwoordelijkheden voor applicatiegebieden kunnen ervoor pleiten. Dit vraagt een applicatie die in meerdere instanties kan draaien en mensen die het extra platformwerk aankunnen.
Stel vóór de keuze voor een dienst vast of de aanbieder de control plane beheert, welke componenten u zelf onderhoudt en welke incidenttaken bij u blijven. Een managed cluster vermindert bepaalde platformtaken. Verantwoordelijkheid voor applicaties, toegangsrechten, gegevens en kosten blijft bestaan.
Aannames over gedeelde gegevens zijn een veelvoorkomend struikelblok. Kan de bedrijfsapplicatie met meerdere actieve instanties werken? Waar schrijft zij bestanden? Waar staan sessies? Kan een achtergrondtaak veilig opnieuw worden uitgevoerd? Deze vragen moeten vóór migratie worden beantwoord. Een bereikbare container bewijst niet dat orders correct worden verwerkt.
De inspanning omvat de hele levenscyclus
Alleen server- of cloudkosten zijn onvoldoende voor een vergelijking. Implementatie, documentatie, updates, bewaking, back-ups en tijd voor incidenten tellen ook mee. Kubernetes vraagt daarnaast platformkennis en afstemming tussen cluster-, netwerk- en opslagcomponenten. Gestandaardiseerd beheer kan terugkerend werk verminderen, maar die standaard moet eerst worden opgezet en onderhouden.
Drie scenario’s maken een bruikbare kostenvergelijking mogelijk: de bestaande applicatie degelijk blijven beheren, standaardiseren op Compose of een Kubernetes-platform invoeren. Gebruik voor elk scenario dezelfde bedrijfseisen. Anders wordt al snel een eenvoudige zelfstandige server met een veel hoger beschikbaarheidsdoel vergeleken zonder dat het verschil duidelijk is.
Zo komt u tot een onderbouwde beslissing
- Beheereisen vastleggen: beschrijf aanvaardbare uitval, onderhoudsvensters, gegevensverlies en verwachte wijzigingen.
- Applicatie beoordelen: leg ondersteunde installatiemethoden, meerdere instanties, bestanden, sessies en externe interfaces vast.
- Verantwoordelijkheid toewijzen: bepaal wie onderhoud, alarmen, herstel en vervanging bij afwezigheid verzorgt.
- Eén dienst testen: oefen een update, een storing en herstel in de voorgestelde omgeving en documenteer de inspanning.
- Daarna uitbreiden: beoordeel verdere applicaties aan de hand van dezelfde criteria.
DAXS combineert een beoordeling van de applicatie en haar interfaces met infrastructuurplanning en een passend beheermodel. Voor een eerste beoordeling volstaan een concrete dienst, zijn afhankelijkheden en de vereiste beheerresultaten. Een persoonlijk gesprek begint daar.
Bronnen: Docker: het Compose-applicatiemodel · Docker Compose in productie · Kubernetes: componenten en verantwoordelijkheden · Kubernetes: Deployments en rollouts · Een Kubernetes-productieomgeving plannen
