Meisje op een scooter. Illustratie Freepik, Nomad-logo van HashiCorp

Kubernetes is de 300-pond gorilla van containerorkestratie. Het werkt in enkele van de grootste containersystemen ter wereld, maar is duur.

Vooral duur voor kleinere teams, die veel ondersteuningstijd en een steile leercurve vergen. Dit is te veel overhead voor ons team van vier. Dus gingen we op zoek naar alternatieven - en werden er verliefd op Nomade.

Wat wil je

Ons team ondersteunt een aantal algemene prestatiemonitoring- en analyseservices: API-eindpunten voor statistieken geschreven in Go, Prometheus-exports, log-parsers zoals Logstash en Gollum, evenals databases zoals InfluxDB of Elasticsearch. Elk van deze services draait in een eigen container. We hebben een eenvoudig systeem nodig om alles draaiende te houden.

We zijn begonnen met een lijst met vereisten voor containerorkestratie:

• Het uitvoeren van een reeks services op veel machines.
• Overzicht van lopende services.
• Verbindingen tussen diensten.
• Automatische herstart als de service uitvalt.
• Onderhoud van de infrastructuur door een klein team.

Daarnaast zijn de volgende zaken leuke, maar niet noodzakelijke toevoegingen:

• Machines taggen op basis van hun mogelijkheden (bijvoorbeeld machines taggen met snelle schijven voor zware I/O-services).
• Mogelijkheid om services onafhankelijk van de orkestrator uit te voeren (bijvoorbeeld tijdens de ontwikkeling).
• Een gemeenschappelijke plek om configuraties en geheimen te delen.
• Eindpunt voor statistieken en logboeken.

Waarom Kubernetes niet geschikt is voor ons

Toen we prototypen maakten met Kubernetes, merkten we dat we steeds complexere lagen logica toevoegden waar we sterk op vertrouwden.

Kubernetes ondersteunt bijvoorbeeld ingebouwde serviceconfiguraties via configuratiekaarten. U kunt snel in de war raken, vooral wanneer u meerdere configuratiebestanden samenvoegt of extra services aan een pod toevoegt. Kubernetes (of roer in dit geval) kunt u op dynamische wijze externe configuraties implementeren om problemen te scheiden. Maar dit resulteert in een nauwe, verborgen koppeling tussen jouw project en Kubernetes. Helm en ConfigMaps zijn echter aanvullende opties, dus u hoeft ze niet te gebruiken. U kunt de configuratie eenvoudig naar de Docker-image kopiëren. Het is echter verleidelijk om dit pad te bewandelen en onnodige abstracties op te bouwen waar je later misschien spijt van krijgt.

Bovendien evolueert het Kubernetes-ecosysteem snel. Het kost veel tijd en energie om op de hoogte te blijven van best practices en de nieuwste tools. Kubectl, minikube, kubeadm, roer, helmstok, kops, oc - de lijst gaat maar door. Niet al deze hulpmiddelen zijn nodig als je begint, maar je weet niet wat je nodig hebt, dus je moet van alles op de hoogte zijn. Hierdoor is de leercurve behoorlijk steil.

Wanneer moet u Kubernetes gebruiken?

In ons bedrijf gebruiken veel mensen Kubernetes en zijn er best tevreden over. Deze instanties worden beheerd door Google of Amazon, die over de middelen beschikken om ze te ondersteunen.

Kubernetes wordt meegeleverd geweldige eigenschappen, waardoor containerorkestratie op schaal beter beheersbaar wordt:

• Gedetailleerd rechtenbeheer.
• Aangepaste controllers logica toevoegen aan het cluster. Dit zijn simpelweg programma’s die met de Kubernetes API praten.
• Automatisch schalen! Kubernetes kan services op aanvraag schalen met behulp van servicestatistieken en zonder handmatige tussenkomst.

De vraag is of je al deze features echt nodig hebt. Je kunt niet alleen op abstracties vertrouwen; je zult moeten uitzoeken wat er onder de motorkap gebeurt.

Ons team levert de meeste diensten op afstand (vanwege de nauwe verbinding met de hoofdinfrastructuur), dus we wilden niet ons eigen Kubernetes-cluster oprichten. Wij wilden alleen maar diensten verlenen.

Batterijen niet inbegrepen

Nomad is 20% van de orkestratie die 80% levert van wat nodig is. Het enige wat het doet is implementaties beheren. Nomad zorgt voor de implementaties, herstart containers in geval van fouten... en dat is alles.

Het hele punt van Nomad is wat het doet minimum: geen gedetailleerd rechtenbeheer of uitgebreid netwerkbeleid, deze is speciaal ontworpen. Deze componenten worden extern of helemaal niet geleverd.

Ik denk dat Nomad het perfecte compromis heeft gevonden tussen gebruiksgemak en bruikbaarheid. Het is goed voor kleine, onafhankelijke diensten. Als je meer controle nodig hebt, zul je deze zelf moeten verhogen of een andere aanpak moeten gebruiken. Nomade wel gewoon orkestrator.

Het beste aan Nomad is dat het gemakkelijk is заменить. Er is vrijwel geen verbinding met de leverancier, omdat de functies ervan eenvoudig kunnen worden geïntegreerd in elk ander systeem dat services beheert. Het draait gewoon als een normaal binair bestand op elke machine in het cluster, dat is alles!

Nomaden-ecosysteem van losjes gekoppelde componenten

De echte kracht van Nomad is zijn ecosysteem. Het integreert zeer goed met andere – volledig optionele – producten zoals Consul (sleutelwaardeopslag) of Gewelf (geheimen verwerken). In het Nomad-bestand bevinden zich secties voor het extraheren van gegevens uit deze services:

template {
  data = <<EOH
LOG_LEVEL="{{key "service/geo-api/log-verbosity"}}"
API_KEY="{{with secret "secret/geo-api-key"}}{{.Data.value}}{{end}}"
EOH

  destination = "secrets/file.env"
  env         = true
}

Hier lezen we de sleutel service/geo-api/log-verbosity van Consul en stel deze tijdens bedrijf bloot aan een omgevingsvariabele LOG_LEVEL. Ook overhandigen wij de sleutel secret/geo-api-key van kluis als API_KEY. Eenvoudig maar krachtig!

Door zijn eenvoud is Nomad via API eenvoudig uit te breiden met andere diensten. Tags voor taken worden bijvoorbeeld ondersteund. We taggen alle services met statistieken trv-metrics. Zo kan Prometheus deze diensten eenvoudig via Consul vinden en periodiek het eindpunt controleren /metrics voor nieuwe gegevens. Hetzelfde kan bijvoorbeeld worden gedaan voor logboeken, met behulp van Loki.

Er zijn nog veel meer voorbeelden van uitbreidbaarheid:

• Voer een Jenkins-taak uit met behulp van een hook, en Consul bewaakt de herimplementatie van de Nomad-taak wanneer de serviceconfiguratie verandert.
• Ceph voegt een gedistribueerd bestandssysteem toe aan Nomad.
• fabio voor loadbalancing.

Dit alles maakt het mogelijk organisch infrastructuur ontwikkelen zonder enige speciale band met de verkoper.

Eerlijke waarschuwing

Geen enkel systeem is perfect. Ik raad niet aan om de nieuwste functies onmiddellijk in productie te nemen. Natuurlijk zijn er bugs en ontbrekende features, maar hetzelfde geldt voor Kubernetes.

Vergeleken met Kubernetes is de Nomad-gemeenschap niet zo groot. Kubernetes heeft al ongeveer 75 commits en 000 bijdragers, terwijl Nomad ongeveer 2000 commits en 14 bijdragers heeft. Nomad zal moeite hebben om de snelheid van Kubernetes bij te houden, maar misschien hoeft dat ook niet! Het is een meer gespecialiseerd systeem en de kleinere community betekent ook dat de kans groter is dat uw pull-verzoek wordt opgemerkt en geaccepteerd, vergeleken met Kubernetes.

Beknopt

Kort gezegd: gebruik Kubernetes niet alleen omdat iedereen het doet. Evalueer uw vereisten zorgvuldig en kijk welke tool voordeliger is.

Als u van plan bent een heleboel homogene services op een grootschalige infrastructuur in te zetten, dan is Kubernetes een goede optie. Houd wel rekening met de extra complexiteit en bedrijfskosten. Sommige kosten kunnen worden vermeden door gebruik te maken van een beheerde Kubernetes-omgeving zoals Google Kubernetes-engine of Amazon EX.

Als u gewoon op zoek bent naar een betrouwbare orkestrator die gemakkelijk te onderhouden en uitbreidbaar is, waarom probeert u dan niet Nomad? Het zal je misschien verbazen hoe ver dit je zal brengen.

Als Kubernetes wordt vergeleken met een auto, zou Nomad een scooter zijn. Soms heb je het ene nodig en soms heb je het andere nodig. Beiden hebben bestaansrecht.

Bron: www.habr.com