Kanskje du ikke trenger Kubernetes
Jente på scooter. Illustrasjon freepik, Nomad-logoen fra HashiCorp

Kubernetes er en 300-kilos gorilla for orkestrering av containere. Den fungerer i noen av de største containermiljøene i verden, men er kostbar.

Spesielt kostbart for små team, som vil måtte bruke mye tid på vedlikehold og en bratt læringskurve. For vårt team på fire personer er dette for mye overhead. Derfor begynte vi å se etter alternativer - og ble forelsket i Nomad.

Hva vi ønsker

Vårt team støtter en rekke typiske tjenester for overvåking og ytelsesanalyse: API-endepunkter for metrikker, skrevet i Go, Prometheus-eksport, loggparere som Logstash og Gollum, samt databaser som InfluxDB eller Elasticsearch. Hver av disse tjenestene kjører i sin egen container. Vi trenger et enkelt system for å holde alt dette oppe og gå.

Vi startet med en liste over krav for orkestrering av containere:

Kjøre et sett med tjenester på mange maskiner.
Oversikt over kjørende tjenester.
Forbindelser mellom tjenester.
Automatisk omstart hvis en tjeneste krasjer.
Vedlikehold av infrastrukturen av et lite team.

I tillegg ville følgende ting vært hyggelige, men ikke obligatoriske tillegg:

Merking av maskiner etter deres muligheter (for eksempel å merke maskiner med raske disker for tunge I/O-tjenester).
Mulighet for å kjøre tjenester uavhengig av orkestratoren (for eksempel under utvikling).
Et felles sted for deling av konfigurasjoner og hemmeligheter.
Endepunkt for metrikker og logger.

Hvorfor Kubernetes ikke passer for oss

Da vi prototype med Kubernetes, la vi merke til at vi begynte å legge til stadig mer kompliserte lag av logikk som vi pliktoppfyllende stole på.

Som et eksempel støtter Kubernetes innebygde tjenestekonfigurasjoner gjennom ConfigMaps. Du kan raskt bli forvirret, spesielt når du slår sammen flere konfigurasjonsfiler eller legger til flere tjenester i en pod. Kubernetes (eller helm I dette tilfellet) tillater det å implementere dynamiske eksterne konfigurasjoner for å skille interessene. Men dette fører til en rigid skjult kobling mellom prosjektet ditt og Kubernetes. Likevel er Helm og ConfigMaps ekstra alternativer, så du er ikke nødvendigvis forpliktet til å bruke dem. Du kan ganske enkelt kopiere konfigurasjonen til Docker-bildet. Likevel er det fristende å gå denne veien og bygge unødvendige abstraksjoner, noe du kanskje vil angre på senere.

I tillegg utvikler Kubernetes-økosystemet seg raskt. Det krever mye tid og energi å holde seg oppdatert med beste praksis og de nyeste verktøyene. Kubectl, minikube, kubeadm, helm, tiller, kops, oc – listen fortsetter og fortsetter. I begynnelsen er ikke alle disse verktøyene nødvendige, men du vet ikke hva du vil trenge, så du må være oppmerksom på alt. På grunn av dette er læringskurven ganske bratt.

Når man skal bruke Kubernetes

I vårt selskap er mange fornøyde med å bruke Kubernetes. Disse instansene administreres av Google eller Amazon, som har tilstrekkelige ressurser til å støtte dem.

Kubernetes leveres med fantastiske funksjoner, som gjør storskala orkestrering av containere mer håndterbar:

Detaljert rettighetsforvaltning.
Egendefinerte kontrollerere legger logikk til klyngen. Dette er bare programmer som kommuniserer med Kubernetes API.
Automatisk skalering! Kubernetes kan skalere tjenester etter behov, ved hjelp av tjenestemetrikk og uten at det kreves manuell inngripen.

Spørsmålet er om du virkelig trenger alle disse funksjonene. Det er ikke nok å stole på abstraksjoner; du må lære deg hva som skjer under panseret.

Teamet vårt tilbyr de fleste tjenestene eksternt (på grunn av den nære forbindelsen med hovedinfrastrukturen), så vi ønsket ikke å sette opp vår egen Kubernetes-klynge. Vi ønsket bare å tilby tjenester.

Batterier ikke inkludert

Nomad er 20% av orkestreringen som gir 80% av det nødvendige. Alt den gjør, er å administrere distribusjoner. Nomad tar seg av distribusjoner, starter containere på nytt ved feil… og det er alt.

Hele poenget med Nomad er det den gjør minimum: ingen detaljert rettighetsforvaltning eller avanserte nettverkspolitikker, slik det er spesifikt designet. Disse komponentene leveres fra tredjepart eller tilbys ikke i det hele tatt.

Jeg tror at Nomad har funnet den perfekte balansen mellom brukervennlighet og nytte. Den er flott for små, uavhengige tjenester. Hvis du trenger mer kontroll, må du opprette dem selv eller bruke en annen tilnærming. Nomad er bare en orkestrator.

Det beste med Nomad er at den enkelt kan erstattes. Leverandøravhengighet er nærmest fraværende, ettersom funksjonene lett kan integreres i ethvert annet system som håndterer tjenester. Den fungerer bare som en vanlig binærfil på hver maskin i klyngen, det er alt!

Nomads økosystem består av svakt sammenkoblede komponenter

Den virkelige styrken til Nomad ligger i økosystemet. Den integrerer seg veldig godt med andre — helt valgfrie — produkter, som Consul (nøkkel-verdi lagring) eller Vault (behandling av hemmeligheter). Inne i Nomad-filen er det seksjoner for å hente data fra disse tjenestene:

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
}

Her leser vi nøkkelen service/geo-api/log-verbosity fra Consul og presenterer den som en miljøvariabel LOG_LEVEL. Vi presenterer også nøkkelen secret/geo-api-key fra Vault som API_KEY. Enkelt, men kraftig!

På grunn av sin enkelhet kan Nomad enkelt utvides med andre tjenester via API. For eksempel støttes etiketter for oppgaver. Vi merker alle tjenester med metrikker etiketten trv-metrics. Slik finner Prometheus enkelt disse tjenestene via Consul og sjekker jevnlig endepunktet /metrics for nye data. Det samme kan gjøres, for eksempel for logger, ved å bruke Loki.

Det finnes mange andre eksempler på utvidbarhet:

Kjøre en Jenkins-oppgave ved hjelp av en webhook, og Consul overvåker gjenopprettingsdistribusjonen av Nomad-oppgaven ved endringer i tjenestekonfigurasjonen.
Ceph legger til et distribuert filsystem i Nomad.
fabio for lastbalansering.

Alt dette gjør det mulig å organisk utvikle infrastrukturen uten stor leverandøravhengighet.

Ærlig advarsel

Ingen systemer er perfekte. Jeg anbefaler ikke å implementere de nyeste funksjonene i produksjon med en gang. Selvfølgelig er det feil og manglende funksjoner, men det samme gjelder Kubernetes.

Sammenlignet med Kubernetes er Nomad-samfunnet ikke så stort. Kubernetes har allerede rundt 75 000 commits og 2000 bidragsytere, mens Nomad har omtrent 14 000 commits og 300 bidragsytere. Det vil være vanskelig for Nomad å holde følge med hastigheten til Kubernetes, men kanskje det ikke er nødvendig! Det er et mer spesialisert system, og et mindre samfunn betyr også at pull-forespørselen din sannsynligvis vil bli lagt merke til og akseptert mer enn med Kubernetes.

Sammendrag

Konklusjon: ikke bruk Kubernetes bare fordi alle andre gjør det. Vurder kravene dine nøye og sjekk hvilket verktøy som er mer kostnadseffektivt.

Hvis du planlegger å rulle ut mange ensartede tjenester på en storskala infrastruktur, er Kubernetes et godt alternativ. Bare husk den ekstra kompleksiteten og driftskostnadene. Noen av kostnadene kan unngås ved å bruke en administrert Kubernetes-miljø, som Google Kubernetes Engine eller Amazon EKS.

Hvis du bare ser etter en pålitelig orkestrator som er enkel å vedlikeholde og utvide, hvorfor ikke prøve Nomad? Du kan bli overrasket over hvor langt dette tar deg.

Hvis du sammenligner Kubernetes med en bil, vil Nomad være en scooter. Noen ganger trenger du det ene, og noen ganger det andre. Begge har sin plass.

Kilde: habr.com