Pige på scooter. Illustration freepik, Nomad-logoen fra HashiCorp

Kubernetes er en 300 kilo tung gorilla til orkestrering af containere. Den kører i nogle af verdens største container-systemer, men er dyr.

Særligt dyrt for små teams, der vil bruge meget tid på vedligeholdelse og den stejlere indlæringskurve. For vores team på fire personer er det for mange omkostninger. Derfor begyndte vi at lede efter alternativer – og blev forelsket i Nomad.

Hvad vi ønsker

Vores team understøtter en række typiske tjenester til overvågning og analyse af ydeevne: API-endpoints til metrics skrevet i Go, Prometheus-eksport, logparser som Logstash og Gollum, samt databaser som InfluxDB eller Elasticsearch. Hver af disse tjenester kører i sin egen container. Vi har brug for et simpelt system til at holde det hele kørende.

Vi startede med en liste over krav til orkestrering af containere:

• Kørsel af et sæt tjenester på mange maskiner.
• Oversigt over kørende tjenester.
• Forbindelser mellem tjenester.
• Automatisk genstart, hvis en tjeneste fejler.
• Vedligeholdelse af infrastrukturen af et lille team.

Derudover vil følgende ting være dejlige, men ikke nødvendige tilføjelser:

• Tagging af maskiner efter deres kapaciteter (for eksempel, tagging af maskiner med hurtige diske til tunge I/O-tjenester).
• Mulighed for at køre tjenester uafhængigt af orkestratoren (for eksempel under udvikling).
• Et fælles sted til at dele konfigurationer og secrets.
• En endpoint til metrics og logs.

Hvorfor Kubernetes ikke passer til os

Ved oprettelse af en prototype med Kubernetes bemærkede vi, at vi begyndte at tilføje stadig mere komplekse lag af logik, som vi stolede ubetinget på.

Som eksempel understøtter Kubernetes indbyggede konfigurationer af tjenester gennem ConfigMaps. Du kan hurtigt blive forvirret, især når du fusionerer flere konfigurationsfiler eller tilføjer ekstra tjenester til pod. Kubernetes (eller helm I dette tilfælde) giver mulighed for dynamisk at integrere eksterne konfigurationer til interessedeling. Men det fører til en stram skjult forbindelse mellem dit projekt og Kubernetes. Helm og ConfigMaps er dog yderligere muligheder, så du er ikke nødvendigvis nødt til at bruge dem. Du kan simpelthen kopiere konfigurationen til Docker-billedet. Alligevel er det fristende at gå denne vej og opbygge unødvendige abstraktioner, som du måske senere vil fortryde.

Derudover udvikler Kubernetes-økosystemet sig hurtigt. Det kræver meget tid og energi at holde sig opdateret med bedste praksis og de nyeste værktøjer. Kubectl, minikube, kubeadm, helm, tiller, kops, oc - listen fortsætter og fortsætter. I starten er ikke alle disse værktøjer nødvendige, men du ved ikke, hvad du får brug for, så det er vigtigt at være opmærksom på alt. Derfor er læringskurven ret stejl.

Hvornår man skal bruge Kubernetes

I vores virksomhed bruger mange Kubernetes og er ganske tilfredse med det. Disse instanser administreres af Google eller Amazon, som har nok ressourcer til at understøtte dem.

Kubernetes leveres med fantastiske funktioner, der gør storskala containerorkestrering mere håndterbar:

• Detaljeret rettighedsstyring.
• Tilpassede controllere tilføjer logik til klyngen. Det er bare programmer, der taler med Kubernetes API.
• Automatisk skalering! Kubernetes kan skalere tjenester efter behov, ved hjælp af tjenestemetrikker og uden manuel indgriben.

Spørgsmålet er, om du virkelig har brug for alle disse funktioner. Du kan ikke bare stole på abstraktioner; du bliver nødt til at forstå, hvad der sker under overfladen.

Vores team leverer de fleste tjenester eksternt (på grund af nær tilknytning til den primære infrastruktur), så vi ønskede ikke at oprette vores egen Kubernetes-klynge. Vi ville bare tilbyde tjenester.

Batterier ikke inkluderet

Nomad er 20% af orkestreringen, der giver 80% af det nødvendige. Alt, hvad det gør, er at administrere udsendelser. Nomad håndterer udsendelser, genstarter containere i tilfælde af fejl ... og det er alt.

Meningen med Nomad er, hvad det gør mindst: ingen detaljeret rettighedsstyring eller udvidede netværkspolitikker, som er designet sådan. Disse komponenter leveres fra tredjepart eller tilbydes slet ikke.

Jeg mener, at Nomad har fundet den perfekte balance mellem brugervenlighed og funktionalitet. Den er god til små, uafhængige tjenester. Hvis der er brug for mere kontrol, skal de opsættes manuelt eller en anden tilgang anvendes. Nomad er bare en orkestrator.

Det bedste ved Nomad er, at den er let udskiftes. Leverandørbindingen er næsten ikke-eksisterende, da dens funktioner let kan integreres med ethvert andet system, der styrer tjenester. Den fungerer blot som en almindelig binar på hver maskine i klyngen, og det er det!

Nomads økosystem består af svagt sammenkoblede komponenter.

Den reelle styrke ved Nomad ligger i dens økosystem. Den integreres rigtig godt med andre — helt valgfri — produkter som Consul (nøgle-værdi-lager) eller Vault (håndtering af hemmeligheder). Inden i Nomad-filen er der sektioner til at hente data fra disse tjenester:

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 læser vi nøglen service/geo-api/log-verbosity fra Consul og præsenterer den som en miljøvariabel LOG_LEVEL. Vi præsenterer også nøglen secret/geo-api-key fra Vault som API_KEY. Simpelt, men effektivt!

Takket være sin enkelhed kan Nomad nemt udvides med andre tjenester via API. For eksempel understøttes tags til job. Vi mærker alle tjenester med metrik-tagget trv-metrics. Dermed finder Prometheus nemt disse tjenester via Consul, og tjekker jævnligt endpointet /metrics for nye data. Det samme kan gøres, for eksempel for logs, ved at bruge Loki.

Der er mange andre eksempler på udvidelse:

• Kørsel af en Jenkins-job via et hook, og Consul overvåger genudrulningen af Nomad-jobbet ved ændringer i tjenestekonfigurationen.
• Ceph tilføjer et distribueret filsystem til Nomad.
• fabio til belastningsfordeling.

Alt dette gør det muligt at organisk udvikle infrastrukturen uden særlig binding til en leverandør.

En ærlig advarsel

Ingen system er perfekt. Jeg anbefaler ikke at implementere de nyeste funktioner direkte i produktion. Selvfølgelig er der fejl og manglende funktioner, men det samme gælder for Kubernetes.

Sammenlignet med Kubernetes er Nomads fællesskab ikke så stort. Kubernetes har allerede omkring 75.000 commits og 2.000 bidragsydere, mens Nomad har omkring 14.000 commits og 300 bidragsydere. Det vil være svært for Nomad at holde trit med hastigheden af Kubernetes, men måske er det ikke nødvendigt! Det er et mere specialiseret system, og et mindre fællesskab betyder også, at din pull-anmodning sandsynligvis vil blive bemærket og accepteret hurtigere sammenlignet med Kubernetes.

CV

Konklusion: Brug ikke Kubernetes bare fordi alle andre gør det. Vurder omhyggeligt dine krav og se, hvilket værktøj der er mere fordelagtigt.

Hvis du planlægger at implementere mange ensartede tjenester på en storstilet infrastruktur, så er Kubernetes et godt valg. Bare husk på den ekstra kompleksitet og driftsomkostninger. Nogle udgifter kan undgås ved at bruge et administreret Kubernetes-miljø som Google Kubernetes Engine eller Amazon EKS.

Hvis du bare leder efter en pålidelig orkestrator, der er let at vedligeholde og skalerbar, hvorfor så ikke prøve Nomad? Du vil måske blive overrasket over, hvor langt det kan føre dig.

Hvis Kubernetes sammenlignes med en bil, vil Nomad være en scooter. Nogle gange har du brug for det ene, og nogle gange det andet. Begge har deres berettigelse.

Kilde: habr.com