Pige på en scooter. Illustration , Nomad logo fra
Kubernetes er gorillaen på 300 pund inden for containerorkestrering. Det fungerer i nogle af de største containersystemer i verden, men er dyrt.
Særligt dyrt for mindre teams, som vil kræve meget supporttid og en stejl indlæringskurve. Det er for meget overhead for vores hold på fire. Så vi begyndte at lede efter alternativer – og forelskede os i .
Hvad vil du have
Vores team understøtter en række almindelige præstationsovervågnings- og analysetjenester: API-endepunkter for metrics skrevet i Go, Prometheus-eksport, log-parsere såsom Logstash og , samt databaser såsom InfluxDB eller Elasticsearch. Hver af disse tjenester kører i sin egen container. Vi har brug for et enkelt system til at holde det hele kørende.
Vi startede med en liste over krav til containerorkestrering:
- Kører et sæt tjenester på mange maskiner.
- Oversigt over kørende tjenester.
- Links mellem tjenester.
- Automatisk genstart, hvis tjenesten går ned.
- Infrastrukturvedligeholdelse af et lille team.
Derudover vil følgende ting være gode, men ikke nødvendige tilføjelser:
- Mærkningsmaskiner baseret på deres muligheder (f.eks. mærkningsmaskiner med hurtige diske til tunge I/O-tjenester).
- Evne til at køre tjenester uafhængigt af orkestratoren (for eksempel under udvikling).
- Et fælles sted at dele konfigurationer og hemmeligheder.
- Slutpunkt for metrics og logfiler.
Hvorfor Kubernetes ikke er det rigtige for os
Da vi lavede prototyper med Kubernetes, bemærkede vi, at vi tilføjede stadig mere komplekse lag af logik, som vi stolede meget på.
Som et eksempel understøtter Kubernetes indbyggede tjenestekonfigurationer via . Du kan hurtigt blive forvirret, især når du slår flere konfigurationsfiler sammen eller tilføjer yderligere tjenester til en pod. Kubernetes (eller i dette tilfælde) giver dig mulighed for dynamisk at implementere eksterne konfigurationer for at adskille bekymringer. Men dette resulterer i en tæt, skjult kobling mellem dit projekt og Kubernetes. Helm og ConfigMaps er dog yderligere muligheder, så du behøver ikke bruge dem. Du kan blot kopiere konfigurationen til Docker-billedet. Det er dog fristende at gå denne vej og bygge unødvendige abstraktioner, som du kan fortryde senere.
Derudover udvikler Kubernetes-økosystemet sig hurtigt. Det kræver meget tid og energi at holde sig ajour med bedste praksis og de nyeste værktøjer. Kubectl, minikube, kubeadm, helm, rorpind, kops, oc - listen bliver ved og ved. Ikke alle disse værktøjer er nødvendige, når du starter, men du ved ikke, hvad du skal bruge, så du skal være opmærksom på alt. På grund af dette er indlæringskurven ret stejl.
Hvornår skal du bruge Kubernetes
I vores virksomhed bruger mange mennesker Kubernetes og er ret tilfredse med det. Disse forekomster administreres af Google eller Amazon, som har ressourcerne til at understøtte dem.
Kubernetes kommer med , som gør containerorkestrering i skala mere overskuelig:
- Detaljeret .
- tilføje logik til klyngen. Disse er simpelthen programmer, der taler til Kubernetes API.
- ! Kubernetes kan skalere tjenester efter behov ved hjælp af servicemålinger og uden at kræve manuel indgriben.
Spørgsmålet er, om du virkelig har brug for alle disse funktioner. Man kan ikke kun stole på abstraktioner; .
Vores team leverer de fleste tjenester eksternt (på grund af den tætte forbindelse til hovedinfrastrukturen), så vi ønskede ikke at rejse vores egen Kubernetes-klynge. Vi ville bare levere tjenester.
Batterier medfølger ikke
Nomad er 20% af orkestreringen, der yder 80% af det nødvendige. Alt det gør er at administrere implementeringer. Nomad tager sig af udrulninger, genstarter containere i tilfælde af fejl... og det er det.
Hele pointen med Nomad er, hvad den gør mindste: ingen detaljeret rettighedsstyring eller , dette er specielt designet. Disse komponenter leveres eksternt eller slet ikke.
Jeg tror, at Nomad har fundet det perfekte kompromis mellem brugervenlighed og anvendelighed. Det er godt for små, uafhængige tjenester. Hvis du har brug for mere kontrol, bliver du nødt til at rejse dem selv eller bruge en anden tilgang. Nomad er bare orkestrator.
Det bedste ved Nomad er, at det er nemt erstatte. Der er praktisk talt ingen forbindelse til leverandøren, da dens funktioner nemt integreres i ethvert andet system, der administrerer tjenester. Det kører bare som en almindelig binær på hver maskine i klyngen, det er alt!
Nomadeøkosystem af løst koblede komponenter
Nomads virkelige styrke er dens økosystem. Den integreres rigtig godt med andre - helt valgfri - produkter som f.eks (nøgleværdi-lager) eller (behandler hemmeligheder). Inde i Nomad-filen er der sektioner til at udtrække 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 mens vi arbejder udsætter vi det for en miljøvariabel LOG_LEVEL. Vi præsenterer også nøglen secret/geo-api-key fra Vault as API_KEY. Enkel, men kraftfuld!
På grund af sin enkelhed er Nomad let at udvide med andre tjenester via API. For eksempel understøttes tags til opgaver. Vi tagger alle tjenester med metrics trv-metrics. På denne måde kan Prometheus nemt finde disse tjenester via Consul og med jævne mellemrum kontrollere endepunktet /metrics for nye data. Det samme kan for eksempel gøres for logs, vha .
Der er mange andre eksempler på udvidelsesmuligheder:
- Kør et Jenkins-job ved hjælp af en hook, og Consul overvåger omplaceringen af Nomad-jobbet, når tjenestekonfigurationen ændres.
- Ceph tilføjer et distribueret filsystem til Nomad.
- til belastningsbalancering.
Alt dette tillader uden nogen særlig forbindelse til sælgeren.
Retfærdig advarsel
Intet system er perfekt. Jeg anbefaler ikke straks at introducere de nyeste funktioner i produktionen. Selvfølgelig er der fejl og manglende funktioner, men det samme gælder for Kubernetes.
Sammenlignet med Kubernetes er Nomad-samfundet ikke så stort. Kubernetes har allerede omkring 75 commits og 000 bidragydere, mens Nomad har omkring 2000 commits og 14 bidragydere. Nomad vil have svært ved at følge med Kubernetes hastighed, men det behøver den måske ikke! Det er et mere specialiseret system, og det mindre fællesskab betyder også, at din pull-anmodning er mere tilbøjelig til at blive bemærket og accepteret sammenlignet med Kubernetes.
Resumé
Nederste linje: Brug ikke Kubernetes, bare fordi alle andre gør det. Vurder dine krav omhyggeligt og tjek, hvilket værktøj der er mest fordelagtigt.
Hvis du planlægger at implementere et væld af homogene tjenester på en storstilet infrastruktur, så er Kubernetes en god mulighed. Bare vær opmærksom på den ekstra kompleksitet og driftsomkostninger. Nogle omkostninger kan undgås ved at bruge et administreret Kubernetes-miljø som f.eks eller .
Hvis du bare leder efter en pålidelig orkestrator, der er nem at vedligeholde og kan udvides, hvorfor så ikke prøve Nomad? Du kan blive overrasket over, hvor langt dette vil tage dig.
Hvis Kubernetes sammenlignes med en bil, ville Nomad være en scooter. Nogle gange har du brug for én ting og nogle gange har du brug for noget andet. Begge har ret til at eksistere.
Kilde: www.habr.com