Flicka på en skoter. Illustration , Nomad logotyp från
Kubernetes är 300-pundsgorillan för containerorkestrering. Det fungerar i några av de största containersystemen i världen, men är dyrt.
Särskilt dyrt för mindre team, vilket kommer att kräva mycket supporttid och en brant inlärningskurva. Det här är för mycket omkostnader för vårt team på fyra. Så vi började leta efter alternativ – och blev förälskade i .
Vad vill du
Vårt team stöder ett antal vanliga prestandaövervaknings- och analystjänster: API-slutpunkter för mätvärden skrivna i Go, Prometheus-exporter, logparsers som Logstash och , samt databaser som InfluxDB eller Elasticsearch. Var och en av dessa tjänster körs i sin egen container. Vi behöver ett enkelt system för att hålla det hela igång.
Vi började med en lista över krav för containerorkestrering:
- Köra en uppsättning tjänster på många maskiner.
- Översikt över drifttjänster.
- Länkar mellan tjänster.
- Automatisk omstart om tjänsten går ner.
- Infrastrukturunderhåll av ett litet team.
Dessutom kommer följande saker att vara trevliga, men inte nödvändiga tillägg:
- Taggningsmaskiner baserat på deras kapacitet (till exempel taggningsmaskiner med snabba diskar för tunga I/O-tjänster).
- Förmåga att driva tjänster oberoende av orkestratorn (till exempel under utveckling).
- En gemensam plats för att dela konfigurationer och hemligheter.
- Slutpunkt för mätvärden och loggar.
Varför Kubernetes inte är rätt för oss
När vi gjorde prototyper med Kubernetes märkte vi att vi lade till allt mer komplexa lager av logik som vi förlitade oss mycket på.
Som ett exempel stöder Kubernetes inbyggda tjänstekonfigurationer via . Du kan snabbt bli förvirrad, särskilt när du slår ihop flera konfigurationsfiler eller lägger till ytterligare tjänster till en pod. Kubernetes (eller i det här fallet) tillåter dig att dynamiskt implementera externa konfigurationer för att separera problem. Men detta resulterar i en tät, dold koppling mellan ditt projekt och Kubernetes. Men Helm och ConfigMaps är ytterligare alternativ, så du behöver inte använda dem. Du kan helt enkelt kopiera konfigurationen till Docker-bilden. Det är dock frestande att gå in på den här vägen och bygga onödiga abstraktioner som du kan ångra senare.
Dessutom utvecklas Kubernetes ekosystem snabbt. Det tar mycket tid och energi att hålla sig uppdaterad med bästa praxis och de senaste verktygen. Kubectl, minikube, kubeadm, rod, rorkult, kops, oc - listan fortsätter och fortsätter. Alla dessa verktyg är inte nödvändiga när du börjar, men du vet inte vad du behöver, så du måste vara medveten om allt. På grund av detta är inlärningskurvan ganska brant.
När ska du använda Kubernetes
I vårt företag är det många som använder Kubernetes och är ganska nöjda med det. Dessa instanser hanteras av Google eller Amazon, som har resurserna för att stödja dem.
Kubernetes kommer med , som gör containerorkestrering i skala mer hanterbar:
- Detaljerad .
- lägga till logik i klustret. Det här är helt enkelt program som pratar med Kubernetes API.
- ! Kubernetes kan skala tjänster på begäran med hjälp av tjänstemått och utan att behöva manuellt ingripa.
Frågan är om du verkligen behöver alla dessa funktioner. Du kan inte bara lita på abstraktioner; .
Vårt team tillhandahåller de flesta tjänster på distans (på grund av den nära kopplingen till huvudinfrastrukturen), så vi ville inte bygga upp vårt eget Kubernetes-kluster. Vi ville bara tillhandahålla tjänster.
Batterier ingår ej
Nomad är 20% av orkestreringen som ger 80% av det som behövs. Allt det gör är att hantera distributioner. Nomad tar hand om utplaceringar, startar om containrar vid fel... och det är allt.
Hela poängen med Nomad är vad den gör minimum: ingen granulär rättighetshantering eller , detta är specialdesignat. Dessa komponenter tillhandahålls externt eller inte alls.
Jag tror att Nomad har hittat den perfekta kompromissen mellan användarvänlighet och användbarhet. Det är bra för små, oberoende tjänster. Om du behöver mer kontroll måste du höja dem själv eller använda ett annat tillvägagångssätt. Nomad är bara orkestrator.
Det bästa med Nomad är att det är enkelt ersätta den. Det finns praktiskt taget ingen koppling till leverantören, eftersom dess funktioner enkelt integreras i alla andra system som hanterar tjänster. Det går bara som en vanlig binär på varje maskin i klustret, det är allt!
Nomadekosystem av löst kopplade komponenter
Nomads verkliga styrka är dess ekosystem. Den integrerar väldigt bra med andra – helt valfria – produkter som t.ex (nyckel-värde butik) eller (bearbetar hemligheter). Inuti Nomad-filen finns det sektioner för att extrahera data från dessa tjänster:
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
}
Här läser vi nyckeln service/geo-api/log-verbosity från Consul och under arbetet exponerar vi det för en miljövariabel LOG_LEVEL. Vi presenterar också nyckeln secret/geo-api-key från Vault as API_KEY. Enkelt men kraftfullt!
På grund av sin enkelhet är Nomad lätt att utöka med andra tjänster via API. Till exempel stöds taggar för uppgifter. Vi taggar alla tjänster med mätvärden trv-metrics. På så sätt kan Prometheus enkelt hitta dessa tjänster via Consul och regelbundet kontrollera slutpunkten /metrics för nya data. Detsamma kan göras, till exempel för stockar, med hjälp av .
Det finns många andra exempel på töjbarhet:
- Kör ett Jenkins-jobb med en krok, och Consul övervakar omdistribueringen av Nomad-jobbet när tjänstens konfiguration ändras.
- Ceph lägger till ett distribuerat filsystem till Nomad.
- för lastbalansering.
Allt detta tillåter utan någon speciell koppling till säljaren.
Rättvis varning
Inget system är perfekt. Jag rekommenderar inte att omedelbart introducera de senaste funktionerna i produktionen. Naturligtvis finns det buggar och saknade funktioner, men detsamma gäller Kubernetes.
Jämfört med Kubernetes är Nomad-gemenskapen inte så stor. Kubernetes har redan cirka 75 000 commits och 2000 14 bidragsgivare, medan Nomad har cirka 000 300 commits och XNUMX bidragsgivare. Nomad kommer att ha svårt att hänga med hastigheten på Kubernetes, men det kanske inte måste! Det är ett mer specialiserat system, och det mindre samhället innebär också att din pull-förfrågan är mer sannolikt att uppmärksammas och accepteras, jämfört med Kubernetes.
Sammanfattning
Sammanfattning: Använd inte Kubernetes bara för att alla andra gör det. Utvärdera dina krav noggrant och kontrollera vilket verktyg som är mer fördelaktigt.
Om du planerar att distribuera massor av homogena tjänster på en storskalig infrastruktur, är Kubernetes ett bra alternativ. Var bara medveten om den extra komplexiteten och driftskostnaderna. Vissa kostnader kan undvikas genom att använda en hanterad Kubernetes-miljö som t.ex eller .
Om du bara letar efter en pålitlig orkestrator som är lätt att underhålla och utbyggbar, varför inte prova Nomad? Du kanske blir förvånad över hur långt detta kommer att ta dig.
Om Kubernetes jämförs med en bil skulle Nomad vara en skoter. Ibland behöver man en sak och ibland behöver man en annan. Båda har rätt att existera.
Källa: will.com