Ben je van plan om Kubernetes in Google Cloud te gebruiken? Dat is geweldig, maar voordat je erin duikt, moet je er wel voor zorgen dat je een aantal veelgemaakte vergissingen mijdt die veel teams maken. Deze tips zullen je tijd, hoofdpijn en middelen besparen.
Vergissing 1: theoretische functionaliteit boven ontwikkelaarsvriendelijkheid verkiezen
Veel teams beginnen hun clusters te ontwerpen op basis van het potentieel dat Kubernetes biedt. Dit is een vergissing. In een algemeen DevOps-team leidt het onderschatten van de overhead en ontwikkelvriendelijkheid van een systeem tot een gebrek aan adoptie en een vertraagde ontwikkelingscyclus. Hierdoor worden de flow en creativiteit van ontwikkelaars belemmerd.
Om dit te beperken, begin je met het ontwerpen van software met een menselijke gebruiker in gedachten. In plaats van functionaliteit te ontwerpen, ontwerp je een interface en pas je het ‘niet nodig’-principe toe. Vertrouw erop dat je creatief kan zijn in het bouwen van oplossingen wanneer ze echt nodig zijn. Onthoud dat eenvoud de sleutel is tot toekomstige aanpassingen.
Het ‘you aren’t gonna need it‘-principe (YAGNI) betekent dat je best begint met de meest eenvoudige oplossing bij het ontwerpen van software en dat je het toevoegen van onnodige functies of complexiteit zoveel mogelijk vermijdt.
Vertrouw erop dat je creatief kan zijn en in de toekomst extra oplossingen kan bouwen als en wanneer ze echt nodig zijn, in plaats van je systeem vanaf het begin te belasten met onnodige zaken. Dit past in de bredere visie van flexibele ontwikkeling. Die is erop gericht om flexibel te blijven, zodat feedback van gebruikers tijdens de ontwikkeling kan worden geïntegreerd, in plaats van overdreven ontwikkeling en planning vooraf.
Vergissing 2: het doel van Kubernetes verkeerd begrijpen
Sommige teams adopteren Kubernetes eerder omdat het een bekend systeem is, in plaats van het beste systeem te kiezen voor hun specifiek doel. Dit leidt tot fouten zoals vertrouwen op enkele nodes of enkele pods, wat de betrouwbaarheid van Kubernetes door redundantie tenietdoet.
Het idee om voor elk project in Kubernetes een nieuw cluster op te zetten verkeerd begrijpen: op het eerste gezicht lijkt dit een erg eenvoudige opzet, maar het maakt activiteiten zoals systeemupgrades net uitdagender.
Voor onderhoud, complexiteitsbeheer en betrouwbaarheid is het meestal beter om één grote cluster met veel nodes te hebben, voor meer betrouwbaarheid en een kleinere kans op systeemfalen. Een gewenste scheiding van de alle noden kan worden bereikt door namespaces efficiënt te gebruiken en via een goed netwerk met service-meshes. Eenvoudigweg: twee clusters vereisen twee updates, twee clusters met twee nodes leiden tot een volledige uitval van het systeem als beide nodes uitvallen. Terwijl met één cluster met vier nodes is het mogelijk dat twee nodes uitvallen en dat het systeem gewoon operationeel blijft.
In het verlengde hiervan zouden teams altijd nog eenvoudigere systeemontwerpen moeten overwegen, zoals serverless-functionaliteit.
Vergissing 3: verkeerd monitoren en beperkte middelen
Het monitoren en instellen van de juiste limieten voor je middelen zijn cruciaal voor efficiënt Kubernetes-gebruik. Veel teams maken de fout om te veel middelen in te zetten, wat leidt tot onnodige kosten. Terwijl anderen in het rond gokken, wat resulteert in pod-evicties en flessenhalzen in het systeem.
De oplossing ligt bij kalibratie door middel van experimenten en monitoring.
Vergissing 4: automatisch schalen en flexibiliteit verwaarlozen
Dit legt de veelgemaakte fout bloot van het horizontaal automatisch schalen van pods of de automatische piloot van GCP niet te implementeren. Dit leidt tot onnodige kosten tijdens periodes met weinig verkeer en systeemknelpunten tijdens periodes met veel verkeer. Om dit op te lossen, schakel je automatisch schalen en autopilot in, zodat Kubernetes automatisch pods of nodes toevoegt op basis van de vraag.
Vergissing 5: onvoldoende veiligheidsmaatregelen en denken dat namespacing je Kubernetes-omgeving kan beveiligen
Denken dat namespacing alleen zorgt voor een veilige scheiding tussen omgevingen binnen een cluster is een misvatting. Verkeer tussen namespaces blijft mogelijk en een enkele doorlatende pod in een vergeten namespace kan de hele cluster beïnvloeden. Netwerkbeleid kan het moeilijker maken voor pods om met elkaar te connecteren, maar zonder versleuteling en authenticatie van verkeer binnen een cluster blijven aanvallen zoals spoofing en snooping mogelijk. Om een cluster die meerdere systemen host te beveiligen, moeten dreigingssessies dus altijd rekening houden met de noodzaak van een service-mesh.
Vergissing 6: Kubernetes gebruiken voor stateful applicaties tenzij noodzakelijk
Op een Kubernetes-cluster gebruiken bedrijven vaak pods voor caching. Wanneer een caching-pod de limieten van zijn bronnen overschrijdt, wordt hij uitgezet en gaat zijn cache verloren. Het is natuurlijk mogelijk om StatefulSets te gebruiken, maar vaak is een beheerde service zoals Memorystore beter voor caching-behoeften. Hetzelfde geldt voor databases. Geloof ons, het gebeurt. Vertrouwen op Kubernetes voor databases is niet optimaal in vergelijking met het kiezen van een meer stateful oplossing zoals VM’s of managed services zoals Cloud SQL die daarop vertrouwen.
Vergissing 7: Kubernetes te veel gebruiken in plaats van managed services
Dit brengt ons bij een andere algemene fout. Hoewel GKE een nuttige facilitator van Kubernetes (k8) is, vereist het nog steeds substantieel onderhoud en gedetailleerde onderhoudsexpertise is zowel kostbaar als schaars. Om bronnen te optimaliseren, is het erg nuttig om onnodig Kubernetes-onderhoud helemaal te vermijden. Managed services zoals Cloud Run en Pub/Sub zijn vaak even bruikbaar, maar veel efficiëntere alternatieven vanuit een HR-oogpunt.
Vergissing 8: onnodig opsplitsen van microservices
Opsplitsen in microservices zonder er goed over na te denken kan leiden tot complexiteit en onderhoudsproblemen, samen met netwerklatency-kosten. Niet alles wat gescheiden kan worden, moet dat ook ondergaan.
Het is cruciaal om te denken in termen van functionele componenten en te streven naar eenvoud. Scheiden moet alleen gedaan worden als het de functionaliteit verbetert; anders krijg je verminderde functionaliteit, lastiger onderhoud en een verhoogde overhead.
Om dit probleem op te lossen is een architecturale aanpak nodig. Denk bovenop je gewone sequentiediagrammen en architectonisch overzicht na over functionele grenzen door een praktisch overzicht te maken in een Venndiagram om grenzen rond en relaties tussen functionele componenten te illustreren. Als sub-componenten zich van nature clusteren, kan het voordeliger zijn om ze binnen één systeem te houden.
Dit is een ingezonden bijdrage van DevoTeam. Klik hier voor meer informatie over het bedrijf.