Jente på scooter. Illustrasjon Freepik, Nomad logo fra Hashi Corp

Kubernetes er gorillaen på 300 pund innen containerorkestrering. Det fungerer i noen av de største containersystemene i verden, men er dyrt.

Spesielt dyrt for mindre team, som vil kreve mye støttetid og en bratt læringskurve. Dette er for mye overhead for vårt team på fire. Så vi begynte å se etter alternativer – og ble forelsket i Nomad.

Hva vil du

Teamet vårt støtter en rekke vanlige ytelsesovervåkings- og analysetjenester: API-endepunkter for beregninger skrevet i Go, Prometheus-eksporter, loggparsere 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 det hele i gang.

Vi startet med en liste over krav til containerorkestrering:

• Kjører et sett med tjenester på mange maskiner.
• Oversikt over løpende tjenester.
• Koblinger mellom tjenester.
• Automatisk omstart hvis tjenesten går ned.
• Infrastrukturvedlikehold av et lite team.

I tillegg vil følgende ting være fine, men ikke nødvendige tillegg:

• Merkemaskiner basert på deres evner (for eksempel merkemaskiner med raske disker for tunge I/O-tjenester).
• Evne til å drive tjenester uavhengig av orkestrator (for eksempel under utvikling).
• Et vanlig sted å dele konfigurasjoner og hemmeligheter.
• Endepunkt for beregninger og logger.

Hvorfor Kubernetes ikke er riktig for oss

Da vi laget prototyper med Kubernetes, la vi merke til at vi la til stadig mer komplekse lag med logikk som vi stolte sterkt på.

Som et eksempel støtter Kubernetes innebygde tjenestekonfigurasjoner via ConfigMaps. Du kan raskt bli forvirret, spesielt når du slår sammen flere konfigurasjonsfiler eller legger til tilleggstjenester til en pod. Kubernetes (eller ror i dette tilfellet) lar deg implementere eksterne konfigurasjoner dynamisk for å skille problemer. Men dette resulterer i en tett, skjult kobling mellom prosjektet ditt og Kubernetes. Imidlertid er Helm og ConfigMaps tilleggsalternativer, så du trenger ikke å bruke dem. Du kan ganske enkelt kopiere konfigurasjonen til Docker-bildet. Det er imidlertid fristende å gå denne veien og bygge unødvendige abstraksjoner som du kan angre på senere.

I tillegg utvikler Kubernetes-økosystemet seg raskt. Det tar mye tid og energi å holde seg oppdatert med beste praksis og de nyeste verktøyene. Kubectl, minikube, kubeadm, helm, rorkult, kops, oc - listen fortsetter og fortsetter. Ikke alle disse verktøyene er nødvendige når du starter opp, men du vet ikke hva du trenger, så du må være klar over alt. På grunn av dette er læringskurven ganske bratt.

Når du skal bruke Kubernetes

I vårt selskap er det mange som bruker Kubernetes og er ganske fornøyde med det. Disse forekomstene administreres av Google eller Amazon, som har ressursene til å støtte dem.

Kubernetes kommer med fantastiske funksjoner, som gjør containerorkestrering i skala mer håndterlig:

• Detaljert rettighetsforvaltning.
• Tilpassede kontrollere legge til logikk i klyngen. Dette er ganske enkelt programmer som snakker med Kubernetes API.
• Autoskalering! Kubernetes kan skalere tjenester på forespørsel ved hjelp av tjenestemålinger og uten å kreve manuell intervensjon.

Spørsmålet er om du virkelig trenger alle disse funksjonene. Du kan ikke bare stole på abstraksjoner; du må finne ut hva som skjer under panseret.

Teamet vårt leverer de fleste tjenester eksternt (på grunn av den nære forbindelsen til hovedinfrastrukturen), så vi ønsket ikke å oppdra vår egen Kubernetes-klynge. Vi ville bare tilby tjenester.

Batterier følger ikke med

Nomad er 20 % av orkestreringen som gir 80 % av det som trengs. Alt den gjør er å administrere distribusjoner. Nomad tar seg av utplasseringer, restarter containere ved feil... og det er det.

Hele poenget med Nomad er hva den gjør minimum: ingen detaljert rettighetsadministrasjon eller utvidede nettverkspolicyer, denne er spesialdesignet. Disse komponentene leveres eksternt eller ikke i det hele tatt.

Jeg tror Nomad har funnet det perfekte kompromisset mellom brukervennlighet og nytte. Det er bra for små, uavhengige tjenester. Hvis du trenger mer kontroll, må du oppdra dem selv eller bruke en annen tilnærming. Nomad er bare orkestrator.

Det beste med Nomad er at det er enkelt erstatte. Det er praktisk talt ingen tilknytning til leverandøren, siden funksjonene enkelt integreres i ethvert annet system som administrerer tjenester. Det kjører bare som en vanlig binær på hver maskin i klyngen, det er alt!

Nomadeøkosystem av løst koblede komponenter

Nomads virkelige styrke er økosystemet. Den integreres veldig godt med andre – helt valgfrie – produkter som f.eks Konsul (nøkkelverdilager) eller Vault (behandling av hemmeligheter). Inne i Nomad-filen er det seksjoner for å trekke ut 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 mens vi jobber eksponerer vi den for en miljøvariabel LOG_LEVEL. Vi presenterer også nøkkelen secret/geo-api-key fra Vault as API_KEY. Enkel, men kraftig!

På grunn av sin enkelhet kan Nomad enkelt utvides med andre tjenester via API. For eksempel støttes tagger for oppgaver. Vi merker alle tjenester med beregninger trv-metrics. På denne måten kan Prometheus enkelt finne disse tjenestene via Consul og med jevne mellomrom sjekke endepunktet /metrics for nye data. Det samme kan gjøres for eksempel for logger, ved hjelp av Loki.

Det er mange andre eksempler på utvidbarhet:

• Kjør en Jenkins-jobb med en krok, og Consul overvåker omdistribueringen av Nomad-jobben når tjenestekonfigurasjonen endres.
• Ceph legger til et distribuert filsystem til Nomad.
• fabio for lastbalansering.

Alt dette tillater organisk utvikle infrastruktur uten noen spesiell tilknytning til leverandøren.

Rettferdig advarsel

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

Sammenlignet med Kubernetes er ikke Nomad-samfunnet så stort. Kubernetes har allerede rundt 75 forpliktelser og 000 bidragsytere, mens Nomad har rundt 2000 forpliktelser og 14 bidragsytere. Nomad vil ha vanskelig for å holde tritt med Kubernetes-hastigheten, men det trenger det kanskje ikke! Det er et mer spesialisert system, og det mindre fellesskapet betyr også at pull-forespørselen din er mer sannsynlig å bli lagt merke til og akseptert, sammenlignet med Kubernetes.

Oppsummering

Bunnlinjen: Ikke bruk Kubernetes bare fordi alle andre gjør det. Vurder dine behov nøye og sjekk hvilket verktøy som er mest fordelaktig.

Hvis du planlegger å distribuere massevis av homogene tjenester på en storskala infrastruktur, er Kubernetes et godt alternativ. Bare vær oppmerksom på den ekstra kompleksiteten og driftskostnadene. Noen kostnader kan unngås ved å bruke et administrert Kubernetes-miljø som f.eks Google Kubernetes Engine eller Amazon EX.

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

Hvis Kubernetes sammenlignes med en bil, ville Nomad vært en scooter. Noen ganger trenger du en ting og noen ganger trenger du en annen. Begge har rett til å eksistere.

Kilde: www.habr.com