Hoe pas je CI/CD toe op Kubernetes?

Hoe pas je Continuous Integration en Continuous Delivery (CI/CD) toe op Kubernetes? Je geeft aan Kubernetes door dat er een nieuwe versie van je container is en hij zal deze uitrollen. Het is één commando, maar je moet wel zorgen dat je alles klaar hebt staan. Daarnaast moet je de microservice in een workload controller stoppen. In deze blog gaan we het hebben over Workload Controllers en Config map & Images.

Kubernetes workload controllers

Een deployment wordt vaak gebruikt. Dit is de standaard manier om een microservice te draaien. In Kubernetes deploy je de gehele applicaties in onderdelen ofwel in deployments. Als je een deployment gebruikt dan zal deze pods aanmaken. Een specifiek kenmerk van een deployment is dat elke pod een unieke naam krijgt. Je kan met een deployment tegen Kubernetes vertellen hoeveel pods je zou willen hebben en dan gaat hij ze voor je maken. Super handig, dus je kan het ene moment er twee hebben en als je wilt ook 10. Een onderdeel van een deployment is een ReplicaSet. Die zal je in de regel niet apart gebruiken. Maar die zit er nog wel in. Met een deployment kan je ook perfect continuous delivery doen. De kan in de deployment definiëren welke versie van de container je wilt gebruiken. En zodra je hier een nieuwe versie in zet dan zal Kubernetes deze via de vaste procedure willekeurig de nieuwe versie neerzetten.

Je kan een rollout procedure definiëren, dat betekent dat je aangeeft hoeveel containers er moeten blijven staan en hoeveel er tegelijk van een nieuwe versie mogen worden voorzien. En dan pakt hij willekeurig een van de containers. Als de eerste container niet werkt en foutmeldingen geeft dan zal hij de rest ook niet van een nieuwe versie voorzien.

Wat als je wil dat hij de containers één voor één doet in een vaste volgorde? Dat kan niet met een deployment dat is een andere workload controller. Hiervoor kan je een statefulset gebruiken.  Een statefulset lijkt op een deployment maar met een aantal grote verschillen. De namen van de pod's worden voorspelbaar worden dan statfulsetnaam nummer 0 en 1. Als developer begin je bij 0. Daarnaast worden de containers 1 voor 1 geüpdatet. En je start bij 0 met een update. Hier ook geld weer als je eerste container niet werkt dan zal hij niet de rest den. 

Voor de normale applicatie is het niet slim om een statefulset te gebruiken. je bent dan wat minder flexibel. De applicaties waar het perfect voor is dat zijn state full clusters. Een mooi voorbeeld hiervan is een database cluster. Een database is statefull en hiervan kan je een mooi cluster maken met een statefulset. Een mooi voorbeeld is een mongodb of een elastic search cluster, deze heeft hostnames in zijn config nodig om het cluster te maken.  Anders weten ze niet waar zijn cluster vriendjes zijn. Dus dit is een hele sterke maar je moet dus w el opletten waarvoor je het gebruikt. 

Een script heeft een doel en dat doel zou eindig moeten zijn, want anders is het een programma. Dat is het verschil, maar hiervoor hebben ze een job workload controller gemaakt. Een job is een container die eindig is. Dus job maakt 1 of meer pod's die een taak uitvoeren waarbij de taak een aantal keer herstart kan worden tot hij succes heeft. Een job laat een aantal oude jobs staan, dit is instelbaar, maar dit is super handig om te zien of alles goed gegaan is. Je kan meerdere jobs tegelijk starten.

Maar hij wil dat het maar 1 keer per dag gaat op een bepaalde tijd. Dat kunnen we met een Cronjob, deze start de job op een bepaalde tijd. Deze conjob gebruikt de normale tijds notatie van een linux cronjob. Maar dan zou het kunnen als ik de cronjob zo instel dat er meerdere starten tegelijk van dezelfde job, dat zou niet handig kunnen zijn.

Daar moet je natuurlijk goed over nadenken, het is belangrijk om een job idempotent te maken. Dat betekend dat het goed is dat de job onafhankelijk kan lopen zonder dat hij last heeft van meerdere jobs.

Kubernetes kan wel kijken of er al een job bezig is. Je kan dat met de concurrency Policy zetten, maar dan moet er wel een delay in zitten. Anders kan Kubernetes niet controleren of er al 1 actief is. Dat doe je door de startingDeadlineSeconds  minimaal op 10 te zetten van de cronjob controller check het maar 1 keer per 10 seconden. Anders zou het niet werken. Dus het antwoord op mijn eerste vraag is dat je een workload controller nodig hebt om  Continuous Integration en Continuous Delivery te doen. En met 1 commande je deze van een nieuwe versie kan worden voorzien. En makkelijker kan je het dus niet maken. 

Config map en secrets

In Kubernetes zijn er verschillende omgevingen zoals een ontwikkel- en testomgeving. Om de database connecties anders te maken voor deze omgevingen kan je gebruik maken van configmap en secrets. Een configmap is een object waarin je configuratie kan opslaan zoals environment variables of een configuratiebestand. Dit kan gebruikt worden om de configuratie aan te passen per situatie of namespace. Een secret is een configmap waarbij de waarden base64 encoded zijn en gebruikt worden om veilige informatie op te slaan zoals wachtwoorden. Deze kunnen gebruikt worden door te mounten via een volume mount. Voor elke omgeving heb je een eigen configmap en secret nodig.

Container Images

Hierbij gaat het over de rol van containers en Kubernetes in de workload controllers. Kubernetes is gemaakt om containers te managen en container images zijn de basis hiervan. Er wordt gesproken over verschillende container software, waaronder Podman (de redhat versie van Docker). Ook wordt er besproken dat containerd de onderliggende techniek is voor de meeste container software en dat deze techniek is gedoneerd aan de CNCF en volgt de standaard van Open Container Initiative (OCI). Er zijn verschillende initiatieven die gebruik maken van OCI, maar als de software OCI gebruikt, maakt het niet zoveel uit welke software je gebruikt. Er wordt ook gesproken over het verdienmodel van Docker, dat nu meer focus legt op de toegevoegde waarde van de container technologie en dat er betaalde tools en features zijn. Containers zijn al 20 jaar oud en Docker heeft hierin toekomst gegeven. Container image namen zitten als volgt in elkaar: het opgeven een image tag nummer en het gebruik van een eigen hostname en poortnummer bij een eigen container registry.

Conclusie

Na het lezen van deze blog weet je hoe CI/CD toegepast kan worden op Kubernetes door gebruik te maken van workload controllers zoals deployments, replica sets, stateful sets en jobs. Deployments zijn de standaard manier om een microservice te draaien en zorgen ervoor dat pod's met unieke namen worden aangemaakt. Continuous delivery kan perfect gedaan worden met een deployment door te specificeren welke versie van de container gebruikt moet worden. Stateful sets zijn geschikt voor state full clusters, zoals een database of elastic search cluster. Jobs zijn eindige containers die een taak uitvoeren en kunnen herstarten tot ze succes hebben. Er moet wel opgelet worden waarvoor deze workload controllers gebruikt worden omdat ze verschillende eigenschappen hebben.

No items found.
Deel deze post