Kubernetes

Kubernetes werkt met containers waarin zich de functionaliteiten (microservices) van een applicatie bevinden. Containers zijn niet meer dan afgebakende delen van een host machine (server, VM), ontkoppeld van de onderliggende infrastructuur. Lichtgewicht, makkelijk verplaats- en reproduceerbaar, stabiel én goed te isoleren. Zo wordt gecontaineriseerde software “portable” en kan deze moeiteloos in een willekeurig ander deel van het host-systeem of de cloud geplaatst worden.

Door containerisatie kan de uitvoering van applicaties en workloads flexibel gepland, geïmplementeerd, gecompileerd én geschaald worden. Zo kun je container-apps ook overhevelen van lokale computers naar on-premises productie of verschuiven tussen hybride en meervoudige cloud-omgevingen, terwijl de consistentie tussen de omgevingen onaangetast blijft.

Een video over de meest gebruikelijke Kubernetes scenario’s:

Dat klinkt meteen weer ietwat gecompliceerd, maar hét kritieke punt in al deze scenario’s is de  Container Routering. Oftewel, het management van al die containers. Gerelateerde containers die samen een functie/applicatie uitvoeren, moeten immers voortdurend met elkaar communiceren. Een tiental communicerende containers manueel beheren is nog geen probleem. Maar zodra een applicatie groeit en je honderden of zelfs duizenden containers op servers in je datacenter moet beheren, verlies je het overzicht en wordt het een extreem arbeidsintensieve aangelegenheid. Het beheer moet dan geautomatiseerd worden. Dat wordt “orkestratie” genoemd. En dát is dus wat Kubernetes doet: Container Orchestration.

Kubernetes zorgt ervoor dat containers geheel automatisch en volgens vooraf vastgelegde criteria gestart en gestopt kunnen worden. Op deze wijze regelt Kubernetes taken als routeren, configureren, op- en neerschalen, load balancing, replicatie, maar ook bijvoorbeeld failover (het bij uitval overschakelen naar een redundant(e) of stand-by server, systeem, hardware component of netwerk). Loopt een container vast, dan zorgt Kubernetes voor een nieuwe. Complexe toepassingen worden in containers geplaatst en geschaald geïmplementeerd in een (of meerdere) cluster(s), zonder dat de containerstatus aangetast wordt. Zo kunnen ontwikkelaars sneller nieuwe features en applicaties schaalbaar ontwikkelen, testen en uitrollen.

De werking van Kubernetes samengevat:

• Geautomatiseerde planning (vele geavanceerde mogelijkheden om de lancering van containers op cluster nodes te plannen en te managen)
• Zelfhelend vermogen (automatisch her(in)plannen, vervangen en herstarten van defecte containers)
• Geautomatiseerde rollout en rollback (om de gewenste status (desired state) van een gecontaineriseerde applicatie te bereiken)
• Horizontaal schalen en Load balancing: (automatisch op- en neerschalen van applicaties afhankelijk van de vereiste en beschikbare resources)

1. Je raakt het overzicht kwijt
Een van de issues met Kubernetes is dat organisaties vaak alles te snel én tegelijkertijd willen: én naar de cloud én Kubernetes voor modernisering van het gehele applicatielandschap én meteen alle workloads migreren. Dat is niet verstandig. Kubernetes gaat niet zo zeer over het ‘draaien’ van de afzonderlijke applicaties in containers, maar juist over het inzetten van en werken met deze containers in je ecosysteem. Met containers kun je weliswaar eindeloos schuiven en schalen, maar het gevaar bestaat dat je, ondanks de orkestratie met Kubernetes, redelijk snel het overzicht over je infrastructuur verliest. Een container is nu eenmaal géén virtuele server, maar een relatief vluchtige eenheid binnen het VM-cluster. Containers zijn agile: in een seconde aangemaakt, maar ook in no time weer ‘weg’. En je overzicht net zo.

2. Je hebt geen eigen blauwdruk gemaakt
Met Kubernetes is ieder systeem uniek georkestreerd. Alles gebeurt automatisch. Maar elk systeem gaat uit van de zogenaamde ‘desired state’. Die beschrijft hóé het systeem moet functioneren: de blauwdruk waarin staat wat op welk moment automatisch uitgevoerd moet worden. Een voorbeeld: als je 16 containers met een bepaalde functie hebt en één daarvan valt uit, dan moet er ook automatisch weer eentje bijkomen. Ook het op- of neerschalen van loads gebeurt automatisch, maar moet wél exact gedefinieerd worden. Stel het je zo voor: iemand leert zwemmen. Aan de kant staat de instructeur die continu roept welke bewegingscombinaties de zwemmer moet maken om vooruit te komen. En jíj bent degene die de instructeur vertelt, wat hij op welk moment moet roepen om de zwemmer goed te laten zwemmen. Dat moet heel nauwkeurig en gedetailleerd, want anders gaat de zwemmer kopje onder. Dát is je blauwdruk.

3. Je beheerst de functionaliteiten niet
Containers kunnen enkel één functionaliteit bevatten, geen content (voor gegevensopslag zijn eigen pods en persistent volumes nodig). Een container is dus steeds maar voor één functie of Microservice verantwoordelijk. Die functionaliteitenscheiding moet je heel consequent – bijna tot in het extreme – doorvoeren. Alles in één monstercontainer stoppen, is namelijk precies wat je níét wilt. Naast containers voor upload, load balancing, logging, infrastructurele requests etc. heb je ook nog eens speciale containers voor de specifieke apps. Een symbiose tussen development en operations (DevOps) is dus absolute noodzaak voor de beheersing van alle functionaliteiten.

4. Je creëert een kettingreactie
Door die strikte scheiding tussen functionaliteiten (van een applicatie of site) moeten alle containers 24/7 naadloos samenwerken. Die coöperatie moet je wederom beschrijven (zie blauwdruk). Zo weten containers elkaar te vinden. Maar als dat niet goed gaat, moet je debuggen. Daarvoor zijn ook weer containers nodig die de fouten loggen. Het ene containerprobleem creëert weer een andere container om dat probleem op te lossen. Dan krijg je een kettingreactie met oneindig veel containers. Dat moet je voorkomen. Containers kun je ook niet updaten. Falende containers worden meteen uitgerangeerd en op basis van je blauwdruk vervangen door een nieuwe versie. Ook daarmee moet je rekening houden.

ls je met Kubernetes en containers werkt, zul je een nieuwe, stringente en consequente denkwijze moeten adopteren. Alles draait om overzichtelijkheid en vooruitzien. Met Kubernetes los je problemen op voordat ze zich voordoen. Dat vraagt om een totaal andere mindset. Niet alleen moet je alle orkestratieregels van tevoren vastleggen. Dat zijn regels als: het minimum aantal actieve instanties per container, responstijden en drempelwaarden, of het bijplaatsen en herstarten van instanties in geval van problemen. Je moet bijvoorbeeld ook heel goed nadenken waar je je data opslaat, want die opslagplaatsen moeten door de diverse containers gelijktijdig benaderd en bevraagd kunnen worden.

Ook moet je van tevoren een draaiboek hebben voor de omgang met gevoelige gegevens, het zogenaamde ‘secret management’. Identiteiten en inloggegevens (bijvoorbeeld usernames en wachtwoorden voor websites) mogen zich nooit als tekst in je containers bevinden; die moeten elders opgeslagen en opgevraagd worden. In een hybride omgeving met een mix van container- en andere infrastructuur moeten alle servers benaderbaar blijven. Dat vergt een integrale, bijna symbiotische manier van ontwikkelen, werken en denken.

En dat is meteen het enige nadeel van Kubernetes: met zóveel opties, variabelen en mogelijkheden moet je kunnen omgaan. Zonder de nodige technische kennis kan Kubernetes al snel een ondoordringbare jungle worden. Het is daarom belangrijk dat je met goede Kubernetesspecialisten werkt, die precies weten waarop je moet letten bij het plannen, ontwerpen, schalen, beveiligen en inrichten van je clusters. Dan weet je zeker dat je ook uit jouw Kubernetes omgeving alle genoemde voordelen kunt halen!