Meisie op 'n bromponie. Illustrasie , Nomad logo van
Kubernetes is die 300-pond-gorilla van houerorkestrasie. Dit werk in van die grootste houerstelsels ter wêreld, maar is duur.
Veral duur vir kleiner spanne, wat baie ondersteuningstyd en 'n steil leerkurwe sal verg. Dit is te veel oorhoofse koste vir ons span van vier. Ons het dus na alternatiewe begin soek – en verlief geraak op .
Wat wil jy hê
Ons span ondersteun 'n aantal algemene prestasiemonitering en ontledingsdienste: API-eindpunte vir metrieke geskryf in Go, Prometheus-uitvoere, log-ontleders soos Logstash en , sowel as databasisse soos InfluxDB of Elasticsearch. Elkeen van hierdie dienste loop in sy eie houer. Ons het 'n eenvoudige stelsel nodig om dit alles aan die gang te hou.
Ons het begin met 'n lys vereistes vir houerorkestrasie:
- Begin 'n stel dienste op baie masjiene.
- Oorsig van lopende dienste.
- Skakels tussen dienste.
- Outomatiese herbegin as die diens afgaan.
- Infrastruktuuronderhoud deur 'n klein span.
Daarbenewens sal die volgende dinge lekker wees, maar nie vereiste toevoegings nie:
- Merkmasjiene gebaseer op hul vermoëns (byvoorbeeld merkmasjiene met vinnige skywe vir swaar I/O-dienste).
- Vermoë om dienste onafhanklik van die orkestreerder uit te voer (byvoorbeeld tydens ontwikkeling).
- 'n Algemene plek om konfigurasies en geheime te deel.
- Eindpunt vir metrieke en logs.
Waarom Kubernetes nie reg is vir ons nie
Soos ons prototipeer met Kubernetes, het ons opgemerk dat ons toenemend komplekse lae logika byvoeg waarop ons sterk staatmaak.
As voorbeeld ondersteun Kubernetes ingeboude dienskonfigurasies via . U kan vinnig deurmekaar raak, veral wanneer u veelvuldige konfigurasielêers saamvoeg of bykomende dienste by 'n pod voeg. Kubernetes (of in hierdie geval) laat jou toe om eksterne konfigurasies dinamies te implementeer om bekommernisse te skei. Maar dit lei tot 'n noue, versteekte koppeling tussen jou projek en Kubernetes. Helm en ConfigMaps is egter bykomende opsies, so jy hoef dit nie te gebruik nie. U kan die konfigurasie eenvoudig na die Docker-beeld kopieer. Dit is egter aanloklik om hierdie pad te gaan en onnodige abstraksies te bou waaroor jy later spyt kan wees.
Boonop ontwikkel die Kubernetes-ekosisteem vinnig. Dit neem baie tyd en energie om op hoogte te bly met beste praktyke en die nuutste nutsgoed. Kubectl, minikube, kubeadm, helm, dissel, kops, oc - die lys gaan aan en aan. Nie al hierdie gereedskap is nodig wanneer jy begin nie, maar jy weet nie wat jy nodig het nie, so jy moet bewus wees van alles. As gevolg hiervan is die leerkurwe redelik steil.
Wanneer om Kubernetes te gebruik
In ons maatskappy gebruik baie mense Kubernetes en is baie tevrede daarmee. Hierdie gevalle word bestuur deur Google of Amazon, wat die hulpbronne het om hulle te ondersteun.
Kubernetes kom met , wat houerorkestrasie op skaal meer hanteerbaar maak:
- Gedetailleerd .
- voeg logika by die groepering. Dit is bloot programme wat met die Kubernetes API praat.
- ! Kubernetes kan dienste op aanvraag skaal deur diensstatistieke te gebruik en sonder om handmatige ingryping te vereis.
Die vraag is of jy regtig al hierdie kenmerke nodig het. Jy kan nie net op abstraksies staatmaak nie; .
Ons span verskaf die meeste dienste op afstand (as gevolg van die noue verbinding met die hoofinfrastruktuur), so ons wou nie ons eie Kubernetes-kluster oprig nie. Ons wou net dienste lewer.
Batterye nie ingesluit nie
Nomad is 20% van die orkestrasie wat 80% verskaf van wat nodig is. Al wat dit doen is om ontplooiings te bestuur. Nomad sorg vir ontplooiings, herbegin houers in geval van foute ... en dit is dit.
Die hele punt van Nomad is wat dit doen minimum: geen korrel regte bestuur of , dit is spesiaal ontwerp. Hierdie komponente word ekstern verskaf of glad nie.
Ek dink Nomad het die perfekte kompromie tussen gebruiksgemak en bruikbaarheid gevind. Dis goed vir klein, onafhanklike dienste. As jy meer beheer nodig het, sal jy hulle self moet verhoog of 'n ander benadering moet gebruik. Nomad is net orkeseerder.
Die beste ding van Nomad is dat dit maklik is te vervang. Daar is feitlik geen verbinding met die verkoper nie, aangesien sy funksies maklik geïntegreer word in enige ander stelsel wat dienste bestuur. Dit loop net soos 'n gewone binêre op elke masjien in die groep, dit is al!
Nomade-ekosisteem van losgekoppelde komponente
Nomad se werklike sterkpunt is sy ekosisteem. Dit integreer baie goed met ander - heeltemal opsioneel - produkte soos bv (sleutel-waarde winkel) of (verwerking van geheime). Binne die Nomad-lêer is daar afdelings om data uit hierdie dienste te onttrek:
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
}
Hier lees ons die sleutel service/geo-api/log-verbosity van Consul en terwyl ons werk stel ons dit bloot aan 'n omgewingsveranderlike LOG_LEVEL. Ons bied ook die sleutel aan secret/geo-api-key van Vault as API_KEY. Eenvoudig maar kragtig!
As gevolg van sy eenvoud, is Nomad maklik uit te brei met ander dienste via API. Merkers vir take word byvoorbeeld ondersteun. Ons merk alle dienste met maatstawwe trv-metrics. Op hierdie manier kan Prometheus hierdie dienste maklik via Consul vind en die eindpunt periodiek nagaan /metrics vir nuwe data. Dieselfde kan gedoen word, byvoorbeeld, vir logs, met behulp van .
Daar is baie ander voorbeelde van uitbreidbaarheid:
- Begin 'n Jenkins-werk deur 'n haak te gebruik, en Consul monitor die herontplooiing van die Nomad-werk wanneer die dienskonfigurasie verander.
- Ceph voeg 'n verspreide lêerstelsel by Nomad.
- vir vragbalansering.
Dit alles laat toe sonder enige spesiale verbintenis met die verkoper.
Regverdige waarskuwing
Geen stelsel is perfek nie. Ek beveel nie aan om die nuutste kenmerke onmiddellik in produksie bekend te stel nie. Natuurlik is daar foute en ontbrekende kenmerke, maar dieselfde geld vir Kubernetes.
In vergelyking met Kubernetes is die Nomad-gemeenskap nie so groot nie. Kubernetes het reeds sowat 75 000 commits en 2000 14 bydraers, terwyl Nomad sowat 000 300 commits en XNUMX bydraers het. Nomad sal moeilik by die spoed van Kubernetes hou, maar miskien hoef dit nie! Dit is 'n meer gespesialiseerde stelsel, en die kleiner gemeenskap beteken ook dat jou trekversoek meer geneig is om opgemerk en aanvaar te word, in vergelyking met Kubernetes.
Opsomming
Bottom line: Moenie Kubernetes gebruik net omdat almal anders dit doen nie. Evalueer jou vereistes noukeurig en kyk watter instrument meer voordelig is.
As u van plan is om 'n ton homogene dienste op 'n grootskaalse infrastruktuur te ontplooi, dan is Kubernetes 'n goeie opsie. Wees net bewus van die bykomende kompleksiteit en bedryfskoste. Sommige koste kan vermy word deur 'n bestuurde Kubernetes-omgewing te gebruik soos of .
As jy net op soek is na 'n betroubare orkestreerder wat maklik is om te onderhou en uit te brei, hoekom probeer jy nie Nomad nie? Jy sal dalk verbaas wees hoe ver dit jou sal bring.
As Kubernetes met 'n motor vergelyk word, sal Nomad 'n bromponie wees. Soms het jy een ding nodig en soms het jy 'n ander nodig. Albei het 'n bestaansreg.
Bron: will.com