Kvinna på scooter. Illustration , Nomad-logotyp från
Kubernetes är en 300 kilo tung gorilla för orkestrering av containrar. Den används i några av de största containrar systemen i världen, men den är kostsam.
Särskilt kostsam för små team som måste lägga mycket tid på underhåll och en brant inlärningskurva. För vårt team på fyra personer är det för mycket overhead. Därför började vi leta efter alternativ – och blev förälskade i .
Vad man önskar
Vårt team stöder en rad typiska tjänster för övervakning och prestandaanalys: API-endpointar för metrik, skrivna i Go, Prometheus-export, loggparserare som Logstash och , samt databaser som InfluxDB eller Elasticsearch. Varje av dessa tjänster körs i sin egen container. Vi behöver ett enkelt system för att hålla allt detta igång.
Vi började med en lista över krav för orkestrering av containrar:
- Kör en uppsättning tjänster på många maskiner.
- Översikt över aktiva tjänster.
- Relationer mellan tjänster.
- Automatisk omstart om en tjänst kraschar.
- Underhåll av infrastrukturen av ett litet team.
Dessutom skulle följande saker vara trevliga men inte obligatoriska tillägg:
- Märkning av maskiner efter deras resurser (till exempel märkning av maskiner med snabba diskar för tunga I/O-tjänster).
- Möjlighet att köra tjänster oberoende av orkestratorn (till exempel under utveckling).
- En gemensam plats för att dela konfigurationer och hemligheter.
- Endpoint för metrik och loggar.
Varför Kubernetes inte passar oss
När vi skapade en prototyp med Kubernetes märkte vi att vi började lägga till allt mer komplexa logiklager som vi litade på utan förbehåll.
Som exempel stöder Kubernetes inbyggda konfigurationer av tjänster via . Du kan snabbt bli förvirrad, särskilt när du slår samman flera konfigurationsfiler eller lägger till extra tjänster i en pod. Kubernetes (eller i det här fallet) möjliggör att dynamiskt implementera externa konfigurationer för intresseavskiljning. Men detta leder till en strikt dold koppling mellan ditt projekt och Kubernetes. Helm och ConfigMaps är dock extra alternativ, så du behöver inte använda dem. Du kan helt enkelt kopiera konfigurationen till Docker-bilden. Ändå är det frestande att gå denna väg och bygga onödiga abstraktioner, något du kanske kommer att ångra senare.
Dessutom utvecklas Kubernetes-ekosystemet snabbt. Det krävs mycket tid och energi för att hålla sig uppdaterad om bästa praxis och de senaste verktygen. Kubectl, minikube, kubeadm, helm, tiller, kops, oc - listan fortsätter. I början behöver du inte alla dessa verktyg, men du vet inte vad som kan komma att behövas, så det är viktigt att vara informerad om allt. Därför är inlärningskurvan ganska brant.
När man ska använda Kubernetes
Vi på företaget använder Kubernetes och är ganska nöjda med det. Dessa instanser hanteras av Google eller Amazon, som har tillräckligt med resurser för att stödja dem.
Kubernetes kommer med , som gör storskalig containerorkestrering mer hanterbar:
- Detaljerad .
- lägger till logik i klustret. Det är helt enkelt program som pratar med Kubernetes API.
- ! Kubernetes kan skala tjänster på begäran, med hjälp av tjänstemetrik och utan att kräva manuell intervention.
Frågan är om du verkligen behöver alla dessa funktioner. Du kan inte bara förlita dig på abstraktioner; .
Vårt team tillhandahåller de flesta tjänster på distans (på grund av nära koppling till den underliggande infrastrukturen), så vi ville inte starta vårt eget Kubernetes-kluster. Vi ville bara tillhandahålla tjänster.
Batterier ingår ej
Nomad är 20% orkestrering som ger 80% av det som behövs. Allt vad det gör är att hantera distributioner. Nomad sköter om distributionerna, startar om containrar vid fel... och det är allt.
Hela poängen med Nomad är att den gör minimum: ingen detaljerad åtkomstkontroll eller , så är det avsiktligt designat. Dessa komponenter tillhandahålls från tredje part eller tillhandahålls inte alls.
Jag tror att Nomad har hittat den perfekta balansen mellan användarvänlighet och funktionalitet. Det är bra för små, oberoende tjänster. Om mer kontroll behövs måste man hantera dem själv eller använda en annan metod. Nomad är enkel en orkestrator.
Det bästa med Nomad är att den är lätt att ersätta. Bindningen till leverantören är praktiskt taget obefintlig, eftersom dess funktioner enkelt kan integreras i vilket annat system som helst som hanterar tjänster. Den fungerar helt enkelt som en vanlig binär på varje maskin i klustret, och det är allt!
Nomads ekosystem består av svagt kopplade komponenter.
Den verkliga styrkan med Nomad finns i dess ekosystem. Den integreras mycket väl med andra – helt valfria – produkter, såsom (nyckel-värde-lagring) eller (hantering av hemligheter). Inuti Nomad-filen finns det avsnitt 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 i realtid presenterar vi den som miljövariabeln LOG_LEVEL. Vi presenterar även nyckeln secret/geo-api-key från Vault som API_KEY. Enkelt men kraftfullt!
Tack vare sin enkelhet kan Nomad enkelt utvidgas med andra tjänster via API. Till exempel stöds taggar för jobb. Vi märker alla tjänster med mätningar med taggen trv-metrics. På så sätt hittar Prometheus enkelt dessa tjänster genom Consul och kontrollerar regelbundet slutpunkten /metrics för nya data. Det samma kan göras för loggar, med hjälp av .
Det finns många andra exempel på utvidgbarhet:
- Kör ett Jenkins-jobb med hjälp av en hook, medan Consul övervakar omdistribueringen av Nomad-jobbet vid ändringar i tjänstekonfigurationen.
- Ceph lägger till ett distribuerat filsystem i Nomad.
- för lastbalansering.
Allt detta gör det möjligt att utan stark bindning till en leverantör.
Ett ärligt varningsmeddelande
Ingen system är perfekt. Jag rekommenderar inte att man omedelbart inför nyaste funktioner i produktion. Självklart finns det buggar och saknade funktioner, men samma sak gäller Kubernetes.
Jämfört med Kubernetes är Nomads gemenskap inte lika stor. Kubernetes har redan runt 75 000 commits och 2000 bidragsgivare, medan Nomad har runt 14 000 commits och 300 bidragsgivare. Det blir svårt för Nomad att hålla jämna steg med Kubernetes, men kanske är det inte nödvändigt! Det är ett mer specialiserat system, och en mindre gemenskap betyder också att din pull-begäran troligen får mer uppmärksamhet och godkänns snabbare än i Kubernetes.
Sammanfattning
Sammanfattning: Använd inte Kubernetes bara för att alla andra gör det. Utvärdera noggrant dina krav och se vilket verktyg som är mest fördelaktigt.
Om du planerar att distribuera en mängd homogena tjänster på en stor infrastruktur är Kubernetes ett bra alternativ. Tänk bara på den extra komplexiteten och driftskostnaderna. Vissa kostnader kan undvikas genom att använda en hanterad Kubernetes-miljö, som eller .
Om du bara letar efter en pålitlig orkestrator som är enkel att underhålla och skalbar, varför inte prova Nomad? Du kanske blir förvånad över hur långt det kan ta dig.
Om Kubernetes är som en bil, då är Nomad som en scooter. Ibland behöver du det ena, ibland det andra. Båda har rätt att existera.
Källa: habr.com
