Pige på en scooter. Illustration , Nomad-logo af
Kubernetes er den 300 kg tunge gorilla inden for containerorkestrering. Det opererer i nogle af de største containersystemer i verden, men det kommer med en pris.
Særligt dyrt for små teams, som bliver nødt til at bruge meget tid på support og en stejl læringskurve. For vores hold på fire er det for meget overhead. Så vi begyndte at lede efter alternativer - og blev forelskede i .
Hvad vil du?
Vores team understøtter en række almindelige tjenester til overvågning og performanceanalyse: API-slutpunkter til metrikker skrevet i Go, Prometheus-eksport, logparsere såsom Logstash og , såvel som 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 alt dette kørende.
Vi startede med en liste over krav til containerorkestrering:
- Kørsel af et sæt tjenester på mange maskiner.
- Oversigt over kørende tjenester.
- Forholdet mellem tjenester.
- Automatisk genstart, hvis tjenesten går ned.
- Vedligeholdelse af infrastruktur af et lille team.
Derudover ville følgende ting være fine, men ikke nødvendige tilføjelser:
- Mærkning af maskiner efter deres kapaciteter (f.eks. mærkning af maskiner med hurtige diske til tunge I/O-tjenester).
- Mulighed for at køre tjenester uafhængigt af orkestratoren (f.eks. under udvikling).
- Et fælles sted til deling af konfigurationer og hemmeligheder.
- Slutpunkt for metrikker og logfiler.
Hvorfor Kubernetes ikke er det rigtige for os
Da vi prototypede med Kubernetes, bemærkede vi, at vi tilføjede stadig mere komplekse lag af logik, som vi implicit stolede på.
Som et eksempel understøtter Kubernetes indbyggede servicekonfigurationer via . Man kan hurtigt blive forvirret, især når man fletter flere konfigurationsfiler eller tilføjer yderligere tjenester til en pod. Kubernetes (eller i dette tilfælde) muliggør dynamisk implementering af 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 valgfrie funktioner, så du behøver ikke at bruge dem. Du kan blot kopiere konfigurationen ind i Docker-billedet. Det er dog fristende at gå denne vej og bygge unødvendige abstraktioner, som man senere kan fortryde.
Derudover vokser Kubernetes-økosystemet 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, rorpind, kops, oc - listen fortsætter og fortsætter. 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 læringskurven ret stejl.
Hvornår skal man bruge Kubernetes
I vores virksomhed bruger mange Kubernetes, og de er ret tilfredse med det. Disse instanser administreres af Google eller Amazon, som har ressourcerne til at understøtte dem.
Kubernetes leveres med , hvilket gør containerorkestrering i stor skala mere håndterbar:
- Detaljeret .
- Tilføj logik til klyngen. De er bare programmer, der kommunikerer med Kubernetes API'en.
- ! 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. Det vil ikke fungere blot at stole på abstraktioner; .
Vores team leverer de fleste af vores tjenester eksternt (på grund af tæt kobling til den primære infrastruktur), så vi ønskede ikke at oprette vores egen Kubernetes-klynge. Vi ville bare tilbyde tjenester.
Batterier medfølger ikke
Nomad er 20% orkestrering, der giver dig 80% af det, du har brug for. Alt, hvad den gør, er at administrere implementeringer. Nomad tager sig af implementeringer, genstarter containere i tilfælde af fejl... og det er det.
Hele pointen med Nomad er, hvad den gør mindsteingen detaljeret rettighedsstyring eller , den var specielt designet på den måde. Disse komponenter leveres af tredjeparter eller leveres slet ikke.
Jeg synes, 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 hæve dem selv eller bruge en anden tilgang. Nomad er bare orkestrator.
Det bedste ved Nomad er, at det er nemt erstatte. Der er stort set ingen leverandørbinding, da funktionerne nemt kan integreres i ethvert andet servicestyringssystem. Den kører bare som en almindelig binær fil på alle maskiner i klyngen, det er alt!
Nomadisk økosystem af løst koblede komponenter
Nomads virkelige styrke er dens økosystem. Det integreres rigtig godt med andre - helt valgfrie - produkter som f.eks. (nøgle-værdi-lagring) eller (behandling af hemmeligheder). Inde i Nomad-filen er der sektioner til udtrækning af 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 under arbejdsprocessen repræsenterer vi den som en miljøvariabel LOG_LEVEL. Vi præsenterer også nøglen secret/geo-api-key fra Vault som API_KEY. Simpelt men kraftfuldt!
På grund af sin enkelhed kan Nomad nemt udvides med andre tjenester via en API. For eksempel understøttes tags til opgaver. Vi tagger alle tjenester med metrikker med tagget trv-metrics. På denne måde kan Prometheus nemt finde disse tjenester via Consul og regelmæssigt kontrollere slutpunktet. /metrics for nye data. Det samme kan for eksempel gøres for logfiler, der bruger .
Der er mange andre eksempler på udvidelsesmuligheder:
- Udløs et Jenkins-job ved hjælp af en hook, og Consul overvåger Nomad-jobbet for genimplementering, når tjenestekonfigurationen ændres.
- Ceph tilføjer et distribueret filsystem til Nomad.
- til belastningsbalancering.
Alt dette tillader uden nogen særlig leverandørtilknytning.
Retfærdig advarsel
Intet system er perfekt. Jeg anbefaler ikke at implementere de nyeste funktioner i produktion med det samme. Jo, der er fejl og manglende funktioner, men det samme gælder for Kubernetes.
Sammenlignet med Kubernetes er Nomad-fællesskabet 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 måske behøver den ikke! Det er et mere specialiseret system, og det mindre fællesskab betyder også, at din pull request er mere tilbøjelig til at blive bemærket og accepteret end med Kubernetes.
Resumé
Konklusion: Brug ikke Kubernetes bare fordi alle andre gør det. Vurder omhyggeligt dine krav, og tjek hvilket værktøj der er mest rentabelt.
Hvis du planlægger at implementere mange homogene tjenester på en storstilet infrastruktur, så er Kubernetes en god mulighed. Vær blot opmærksom på den øgede kompleksitet og driftsomkostninger. Nogle omkostninger kan undgås ved at bruge et administreret Kubernetes-miljø, f.eks. eller .
Hvis du bare leder efter en robust orkestrator, der er nem at vedligeholde og udvidelig, hvorfor så ikke prøve Nomad? Du vil måske blive overrasket over, hvor langt dette vil føre dig.
Hvis Kubernetes er som en bil, er Nomad som en scooter. Nogle gange har du brug for én, nogle gange har du brug for en anden. Begge har ret til at eksistere.
Kilde: www.habr.com
