De containerisatie van workflows voor ontwikkeling, testen en productie zorgt voor een revolutie in IT-management op alle niveaus, of het nu gaat om klantgerichte of interne applicaties en services. Organisaties behalen efficiëntere ontwikkelings- en implementatietijden door gebruik te maken van microservice-architecturen gebouwd op containers en containerorkestratie-frameworks zoals Kubernetes.
De overgang van klassieke IT naar containergebaseerde benaderingen vindt vaak zijn oorsprong in initiatieven van DevOps- teams of -afdelingen die een prototypeomgeving creëren die vervolgens door andere teams wordt overgenomen. Hoewel deze teams dit doen om efficiëntie en flexibiliteit te winnen, resulteert dit vaak in geïsoleerde DevOps-clusters, met als gevolg slechte prestaties (onvoldoende resources) of een lage benutting (resources worden buiten de piekuren onvoldoende benut). Meestal is het een combinatie van beide: terwijl het ene team kampt met een tekort aan resources, hebben andere teams mogelijk veel ongebruikte rekentijd. Erger nog, teams overprovisioneren vaak, met enorme kosten tot gevolg. De industriestandaard voor clusterbenutting ligt vaak rond de 20%.
Het consolideren van clusters (of cloudaccounts trouwens) van veel naar minder, idealiter naar slechts één, en het delen van de middelen tussen teams en use cases is het recept om de prestaties en output te verbeteren en tegelijkertijd de kosten te verlagen. Door consolidatie en delen kunt u echt meer doen met minder - als u effectief, automatisch en eerlijk kunt delen.
De huidige frameworks voor containerorkestratie, zoals Kubernetes , Docker Swarm of Mesos, bieden deze mogelijkheid echter niet standaard. Kubernetes en Swarm bieden eenvoudige schema's voor de verdeling van workloads, zoals 'spread' (round-robin), 'pack' of 'random', en vereisen verder dat je clusterbronnen handmatig segmenteert via concepten zoals namespaces of labels. In Mesos brengen verschillende soorten workloads (bijvoorbeeld Spark, Hadoop of services onder Marathon) hun eigen scheduler mee, die al dan niet beleid voor het delen van resources biedt (met eigen logica en configuratie). De workloads zullen echter met elkaar concurreren om toegang tot resources en er is geen overkoepelend beleidssysteem dat begrijpt wat de belangrijkste workloads voor een bedrijf zijn en hoe aan de behoeften ervan te voldoen zonder resources te overbelasten.
Voor niet-triviale gebruiksscenario's voor het delen van bronnen, zal elk van deze systemen veel handmatige tussenkomst vereisen en nog steeds ofwel overprovisioning vereisen of last hebben van prestatie-impact veroorzaakt door resourceconflicten.
Wat echt nodig is om een resourcepool te kunnen delen tussen organisaties en willekeurige soorten (gecontaineriseerde maar ook niet-gecontaineriseerde) workloads, is een geavanceerd beleidssysteem dat de kenmerken van de workload en zakelijke prioriteiten begrijpt, zodat het de besluitvorming over de toewijzing van resources en middelen op verzoek opnieuw toewijzen wanneer de randvoorwaarden of eisen veranderen.
Navops Command is momenteel een vrij uniek voorbeeld van een dergelijke functionaliteit. Het breidt Kubernetes uit met geavanceerde, dynamische en vraaggestuurde beleidsregels die de besluitvorming over de prioritering van workloads en het resourceverbruik op elk willekeurig moment automatiseren. In vergelijking met andere frameworks voor containerorkestratie biedt Kubernetes de meest uitgebreide set productiegerichte mogelijkheden om workloads betrouwbaar te beheren (zoals geautomatiseerde controllers voor replica's, taken, implementaties, workloadacceptatie, enz.). Met Navops Command bovenop Kubernetes kunt u softwarebuilds, geautomatiseerde tests en productie-implementaties van verschillende applicaties en serviceomgevingen uitvoeren op hetzelfde cluster of in dezelfde cloudpool. De DevOps-taken en productieservices kunnen afkomstig zijn van meerdere teams en een verschillende prioriteit hebben die gedurende de dag kan variëren. Navops Command zorgt ervoor dat geen van de gerelateerde workloads elkaar in de weg zit, terwijl ze tegelijkertijd naar behoren functioneren.
Afbeelding 1: Navops Command-beleid 'Proportional Shares' automatiseert het delen van bronnen tussen groepen, projecten en individuen
Met Navops Command is het mogelijk om clusterbenuttingspercentages van 80% en zelfs hoger te behalen. Het biedt zijn voordelen zelfs binnen een enkel team wanneer u verschillende taken uitvoert, zoals bouwen, testen en bewerkingen, en het levert nog meer voordelen op wanneer u het over teams deelt.
Navops Command laat zien wat er nodig is om microservice-gebaseerde applicaties en andere gecontaineriseerde workloads effectief uit te voeren in een gedeelde omgeving (on-premise of in de cloud). Het is momenteel beschikbaar voor elk type Kubernetes-distributie en kan eenvoudig worden geëvalueerd zoals hier beschreven.
Over de auteur
Fritz Ferstl is de huidige CTO en Business Development EMEA bij Univa Corporation.
Fritz Ferstl brengt 20 jaar ervaring met grid- en cloudcomputing mee naar Univa, en als Chief Technology Officer zal hij helpen bij het bepalen van de technische visie en het leiden van strategische allianties. Fritz, lang beschouwd als de vader van Grid Engine-software en zijn voorlopers Codine en GRD, leidde de Grid Engine-softwarebusiness de afgelopen 10 jaar vanuit Sun Microsystems en Oracle, en bracht het van een beginnende technologie naar de meest gebruikte oplossing voor werklastbeheer in enkele van de meest uitdagende datacenteromgevingen ter wereld. Onder leiding van Fritz was de Grid Engine-software open source en is er een levendige gemeenschap ontstaan.
Amazon