Wie met containers en Kubernetes aan de slag gaat moet zich ineens een heel andere manier van denken eigen maken. Jan-Paul van Burgsteden, één van de oprichters van True, legt dat in een aantal duidelijke voorbeelden uit.
Dit artikel verscheen eerder op Computerworld.nl.
Bekijk onze Managed Kubernetes dienst.
Het grote voordeel van containers is dat het werken ermee een heel flexibele infrastructuur oplevert. Een container is binnen een seconde in de lucht en als je er goed over nadenkt kun je eindeloos horizontaal bijschalen. Alleen krijg je zo wel snel een groot aantal containers, waardoor je infrastructuur onoverzichtelijk wordt. Dat probleem is weer op te lossen met Kubernetes, waarmee je je containers kunt orchestreren.
Ga je ‘from scratch’ met containers en Kubernetes gaat werken, dan moet je er wel op rekenen dat het lang gaat duren en dat je een paar keer opnieuw zult moeten beginnen, stelt Jan-Paul. “Kennis is schaars en best practises zul je zelf moeten uitvinden en ervaren.” Ter gelegenheid van de nieuwe Managed Kubernetes dienstverlening die True binnenkort lanceert, licht hij tegenover Computerworld een aantal zaken uit die de combinatie containers en Kubernetes speciaal maken.
Containers zijn vluchtig
Allereerst moet je goed doorhebben wat containers nou eigenlijk zijn. Het zijn namelijk geen virtuele servers. Jan-Paul ziet containers als een volgende stap in de evolutie die begon bij de server in de meterkast. De volgende stap was de server in het datacenter, waarna de server werd gevirtualiseerd. De container komt daar weer na. Hij vindt het een mooi concept, maar het is wel superingewikkeld. Dat komt vooral doordat containers vluchtig zijn, zegt hij. Ze zijn binnen een seconde opgezet. Maar ze zijn ook zo weer weg en dat proces moet je zien te beheersen. Dat betekent onder andere dat je altijd meerdere containers hebt die hetzelfde doen, omdat je voldoende backup nodig hebt. Bovendien kun je er alleen functionaliteit in stoppen, geen content die bewaard moet blijven. Storage heeft dus zijn eigen pods.
Scheiden van functionaliteit
Containers vertegenwoordigen volgens Jan-Paul vooral een manier om je infrastructuur te versnijden. Een container is namelijk maar voor één ding verantwoordelijk, benadrukt hij. “Die scheiding van functionaliteit moet je tot in het extreme doorvoeren. Je kunt wel een monstercontainer maken met heel veel functionaliteit erin, maar dan combineer je het slechtste van twee werelden.”
Je hebt dus een groep containers voor het parsen van de website, voor het opslaan van uploads, voor het verdelen van verzoeken over de infrastructuur, voor het opslaan van logfiles, en ga zo maar door. Een heel basaal vertrekpunt bestaat al uit 16 verschillende groepen. “En dan heb je nog niks, want dan moet je nog de containers toevoegen die specifiek voor jouw applicatie gelden.” Hierdoor is het ook van cruciaal belang dat developers en operations naadloos op elkaar zijn aangesloten.
Het maken van een recept
Als je met Kubernetes werkt ga je uit van een desired state, zegt Jan-Paul. Maar je doet vervolgens niets om dat te bereiken, want dat wordt allemaal automatisch voor je gedaan. Je desired state is bijvoorbeeld dat er tien containers met een bepaalde functionaliteit zijn. Als er dan twee down gaan, dan komen er automatisch weer twee bij. Of je kunt bepalen dat als er een zekere load wordt bereikt, dat er dan bijgeschaald moet worden, wat dan ook automatisch gebeurt.
Lees ook: True lanceert Managed Kubernetes
“Je beschrijft dus de blauwdruk van een omgeving. Maar in tegenstelling tot traditionele omgevingen, met fysieke of gevirtualiseerde servers ga je niet zelf aan de slag om servers op te zetten en live te zetten.” Jan-Paul vergelijkt het met het maken van een recept, zonder dat je werkelijk in de keuken staat. “Je beschrijft welke ingrediënten je nodig hebt en hoe je die samenvoegt en bereidt. Maar dat doe je zelf niet, dat gaat automatisch.” Je moet dus kunnen omgaan met een bepaalde mate van droogzwemmen, en natuurlijk is Kubernetes hier niet helemaal uniek in. Als je gewend bent aan Puppet, of andere orkestratie software, dan weet je hoe dit ongeveer werkt.
Oneindige reeks containers
Doordat alle functionaliteit van een applicatie of website gescheiden is, moeten de containers allemaal naadloos samenwerken, wat je heel goed moet beschrijven. “Als je dat goed doet, dan weten de containers elkaar te vinden”, zegt Jan-Paul. “Maar wat als het niet goed gaat? Hoe ga je dat dan debuggen?”, vraagt hij zich hardop af. Natuurlijk heb je ook weer een container om fouten te loggen. “En zo creëert iedere container wel een probleem dat is op te lossen met een andere container.” Dat is een kettingreactie die je ergens moet stoppen, anders wordt het onbeheersbaar, waarschuwt Jan-Paul.
Updaten van containers
Het concept van containers werkt ook verder richting het beheer. Je kunt een container namelijk niet updaten. In plaats daarvan zet je er een nieuwe container voor in de plaats. Jan-Paul vergelijkt het met het updaten van een laptop. Als je die updatet, blijft alles er op staan wat er op stond. Maar als je hem updatet zoals je dat met een container doet, dan ruk je hem weg en geef je de gebruiker direct een heel nieuwe laptop, zonder iets erop. Zo heb je voor een container alleen een blauwdruk, en dus vervang je een container gewoon door een nieuwe versie ervan. Dat is weer een voorbeeld van de vluchtigheid van de container dat in alles doorwerkt. “Daarnaast heeft Kubernetes een vrij agressief updateschema waar je rekening mee moet houden.”
Lees ook: Is de Kubernetes hype voorbij?
Een andere manier van denken
Wat hierboven beschreven staat, heeft natuurlijk ook zijn weerslag op hoe er ontwikkeld wordt. Daarbij moet er bijvoorbeeld goed worden nagedacht waar je je data opslaat. De harde schijven moeten door de verschillende containers in een functionaliteitsgroep worden aangesproken, zodat er nooit data verloren gaat. Maar je moet bijvoorbeeld ook bedenken hoe je met secret management omgaat, vindt Jan-Paul. “Je hebt een website en daar heb je een username en wachtwoord voor nodig. Je moet er natuurlijk voor zorgen dat die niet in plain text binnen je container zit, maar waar laat je hem dan?”
Een andere uitdaging is volgens Jan-Paul het praten met servers in een hybride situatie, want vaak zit niet alles in een infrastructuur in een container. En zo zijn er heel veel zaken die net even anders werken, en waar je je een heel andere manier van denken voor moet eigen maken. Maar het is het waard, want wie wil er nou geen flexibele en oneindig schaalbare omgeving?
Container technologie kan je een hoop operationele zaken uit handen nemen, zo sluit Jan-Paul af. Maar hij waarschuwt wel dat het van cruciaal belang is dat er specialisten betrokken zijn die continu nadenken over het ontwerp, de prestaties, de veiligheid en de onderliggende infrastructuur van je cluster.
Wil je meer leren over de mogelijkheden van Kubernetes? Bezoek dan Managed Kubernetes.
E-book – Zes Kubernetes cases gebundeld
Net als elke nieuwe technologie is er ook bij Kubernetes sprake van ‘early adapters’. Lees van de uitdagingen, fouten en oplossingen die deze pioniers hebben meegemaakt bij de inzet van Kubernetes.
Download het e-book
Vul onderstaand formulier in om direct het e-book te ontvangen.
