Containers efficiënt opzetten met Kubernetes in de praktijk - Technical fact

Containers efficiënt opzetten met Kubernetes: de praktijkversie – Technical fact

De laatste jaren is er heel wat technologische vooruitgang geboekt. Deze vooruitgang is overweldigend voor sommigen, terwijl het net spannend is voor anderen. We schreven een aantal boeiende en verrassende feitjes uit over technologie en uitdagingen die we tegenkwamen tijdens het werk. Dit in de hoop dat ze jou vooruit helpen. Je zult misschien verrast en verbaasd zijn over wat we ontdekten. In dit technisch feitje staan we stil bij een case waarin we Kubernetes-clusters installeerden bij een klant. Lees zeker verder om te kijken hoe we te werk gingen.

Beginsituatie

Een van onze klanten vroeg zich af hoe hij containers in zijn omgeving kon laten draaien, zonder dat de set-up en het beheer ervan onoverkomelijk technisch was. Het gebruik van containers zou het werk van het IT-team enorm vereenvoudigen. De applicaties van het bedrijf worden namelijk ontwikkeld door verschillende teams die elk hun eigen tempo en manier van werken hebben. Vandaar de vereiste om containers te laten draaien in een omgeving die gemakkelijk te beheren en te upgraden is en die verdeeld kan worden over verschillende applicaties.

Core ICT's oplossing

Hoe zag de bestaande omgeving eruit?

Als eerste startten we met een analyse van de huidige omgeving, de behoeften en de middelen die voor handen waren. Op deze manier kregen we een beter zicht op de omgeving van onze klant. De omgeving bestond uit twee Nutanix clusters in een productie- en disaster recovery opstelling. De keuze voor het platform was dus snel gemaakt. Het Nutanix-platform is namelijk uitermate geschikt voor het hosten van Kubernetes. Het host niet alleen jouw clusters, maar het is ook in staat blokopslag, objectopslag en NFS-opslag op één enkel platform aan te bieden.

Set-up van de nieuwe Kubernetes omgeving

Vervolgens moesten we nog kiezen welke Kubernetes distributie (dus welke container management software) we zouden gebruiken, gezien er meerdere opties mogelijk waren. Een van de opties was de keuze voor een opensource Kubernetes-clusters. Een andere optie was het kiezen voor andere management frameworks die op de markt beschikbaar zijn.

In deze case besloten we de Nutanix Kubernetes Engine van Nutanix te gebruiken in plaats van de DIY setup. Waarom? Dit vanwege het vermogen om zonder al te veel moeite meerdere Kubernetes clusters te maken en te beheren. Een andere belangrijke reden was de Nutanix-ondersteuning die er automatisch mee gepaard gaat.

De effectieve installatie, een heel keuzeproces:

Clusters

We kozen er in deze case voor om voor elke omgeving een aparte cluster te maken, dat ze (de DTAP en andere applicaties) fysiek van elkaar scheidde. Hiermee konden we voorkomen dat wanneer we wijzigingen aanbrachten in de ene omgeving, dit een impact had op de andere. Op deze manier konden we dus een nieuwe Kubernetes-versie testen via DTAP.

Het opzetten van een cluster op zich is niet veel werk. Je moet echter wel over verschillende dingen nadenken, voordat je de knop ‘Creëer cluster’ indrukt. Enkele voorbeelden: welk IP range ga je gebruiken voor de nodes, moet je iets bereikbaar maken buiten de cluster, welke IP range wil je hiervoor gebruiken, etc.

Netwerkprovider

Net als de IP range moet je ook een netwerkprovider zoals Calico of Flannel kiezen. Beide providers hebben hun voordelen en interessante toepassingen. In deze case kozen we voor Calico. Deze provider is misschien wat complexer dan Flannel, maar hij geeft betere prestaties. Daarnaast wordt het verkeer niet ingekapseld, wat het makkelijker maakt te debuggen indien nodig.

Opslag

Op opslagniveau hadden we voor dit project alleen blokopslag nodig, dus gebruikten we de Nutanix opslaglaag. We maakten voor elke cluster een aparte opslagcontainer aan. Zo kunnen we later eventueel quota’s toepassen en zijn de aangemaakte volumes gesegmenteerd voor elke cluster.

Cluster grootte

Je moet ook de grootte van de Kubernetes-cluster bepalen. Het is uiteraard van essentieel belang dat deze de werklast aan kan. We bepaalden de grootte op basis van de vereiste vCPU en geheugen. Rekening houdend met het feit dat de cluster moet kunnen draaien met N-1 worker node.

High available of niet?

Wanneer je een cluster aanmaakt, moet je ook nog kiezen of je een ontwikkelingsclustersjabloon of een productieclustersjabloon gebruikt. Het enige verschil is of de management nodes en ETCD nodes al dan niet high available zijn.

Voor elk projectteam startten we met de ontwikkelingsclustersjabloon. Op deze cluster konden zij hun CI/CD pipelines, aanvullende componenten en manier van werken testen. Indien nodig konden we de cluster verwijderen en eenvoudig een nieuwe aanmaken. Dit liet ons toe verschillende methoden te testen, zonder impact op de andere omgevingen. Wanneer het projectteam klaar was, creëerden we de volgende cluster zodat het team hun volgende omgeving kon configureren.

Voor de productieomgeving gebruikten we de productieclustersjabloon. Dit om een high available beschikbare Kubernetes opstelling te creëren. Deze geeft je 3 worker nodes, 3 ETCD nodes en 2 control plane nodes.

Zodra we alle clusters hadden ingesteld en de teams de software hadden uitgerold, gingen we over naar het monitoren van de omgeving. Naast het Nutanix Kubernetes Engine dashboard (waar je een overzicht hebt van de gezondheid van je clusters) kun je ook verbinding maken met de build in Prometheus omgeving. Hierdoor kan je nog meer gedetailleerde informatie over de cluster verkrijgen, zowel op namespace niveau als op pod niveau. Zo heb je een heel duidelijk inzicht in hoe alle componenten zich binnen de clusters gedragen.

Conclusie:

Kubernetes heeft vele voordelen voor je IT-omgeving en brengt efficiëntie in het werken met containers. Hopelijk heeft deze case je wat duidelijkheid kunnen geven over het installatieproces ervan.

Heb je toch nog vragen, of wil je de mogelijkheden bekijken voor jouw omgeving? Aarzel niet ons te contacteren via onderstaand formulier.