Knabino sur skotero. Ilustraĵo , la Nomad-emblemo de
Kubernetes estas 300kg ujo orkestra gorilo. Ĝi funkcias en iuj el la plej grandaj ujsistemoj en la mondo, sed ĝi kostas.
Precipe multekosta por malgrandaj teamoj, kiuj devas pasigi multan tempon por subteno kaj kruta lernadkurbo. Por nia teamo de kvar, ĉi tio estas tro multe da ŝarĝo. Tial, ni komencis serĉi alternativojn - kaj enamiĝis .
Kion vi volas
Nia teamo subtenas kelkajn tipajn agado-monitoradon kaj analizajn servojn: API-finpunktoj por metrikoj skribitaj en Go, Prometheus-eksportoj, log-analiziloj kiel Logstash kaj , same kiel datumbazoj kiel ekzemple InfluxDB aŭ Elasticsearch. Ĉiu el ĉi tiuj servoj funkcias en sia propra ujo. Ni bezonas simplan sistemon por ke ĉio funkcias.
Ni komencis kun listo de postuloj por ujo-instrumentado:
- Kurante aron da servoj sur multaj maŝinoj.
- Superrigardo pri funkciado de servoj.
- Rilatoj inter servoj.
- Aŭtomata rekomenco se servo kraŝas.
- Prizorgado de infrastrukturo fare de malgranda teamo.
Krome, la sekvaj aferoj estus belaj, sed ne postulataj aldonoj:
- Markante maŝinojn laŭ iliaj kapabloj (ekzemple, markante maŝinojn per rapidaj diskoj por pezaj I/O-servoj).
- La kapablo prizorgi servojn sendepende de la orkestro (ekzemple, dum evoluo).
- Komuna loko por kunhavi agordojn kaj sekretojn.
- Finpunkto por metrikoj kaj protokoloj.
Kial Kubernetes ne estas por ni
Dum prototipado per Kubernetes, ni rimarkis, ke ni komencis aldoni pli kaj pli kompleksajn tavolojn de logiko, pri kiuj ni implicite fidis.
Ekzemple, Kubernetes subtenas enkonstruitajn servo-agordojn per . Vi povas konfuziĝi rapide, precipe dum kunfandado de pluraj agordaj dosieroj aŭ aldonante pliajn servojn al pod. Kubernetes (aŭ ĉi-kaze) permesas al vi dinamike injekti eksterajn agordojn por apartigo de zorgoj. Sed ĉi tio kondukas al malmola kaj malhela ligo inter via projekto kaj Kubernetes. Tamen Helm kaj ConfigMaps estas laŭvolaj, do vi ne devas uzi ilin. Vi povas simple kopii la agordon al la bildo de Docker. Tamen, estas tenta iri tiun vojon kaj konstrui nenecesajn abstraktaĵojn, kiujn vi eble bedaŭros poste.
Krome, la ekosistemo de Kubernetes rapide evoluas. Necesas multe da tempo kaj energio por resti ĝisdatigita kun plej bonaj praktikoj kaj la plej novaj iloj. Kubectl, minikube, kubeadm, helm, tiller, kops, oc - la listo daŭras kaj pluiras. Ne ĉiuj ĉi tiuj iloj estas necesaj por komenci, sed vi ne scias, kion vi bezonos, do vi devas esti konscia pri ĉio. Pro tio, la lernadkurbo estas sufiĉe kruta.
Kiam uzi Kubernetes
Multaj homoj en nia kompanio uzas Kubernetes kaj estas sufiĉe feliĉaj pri ĝi. Ĉi tiuj kazoj estas administritaj de Google aŭ Amazon, kiuj havas sufiĉajn subtenajn rimedojn.
Kubernetes venas kun , kiuj igas grandskalan ujan instrumentadon pli regebla:
- detala .
- aldoni logikon al la areto. Ili estas nur programoj, kiuj parolas kun la Kubernetes API.
- ! Kubernetes kapablas grimpi servojn laŭ postulo uzante servajn metrikojn sen postuli manan intervenon.
La demando estas, ĉu vi vere bezonas ĉiujn ĉi tiujn funkciojn. Vi ne povas simple fidi je abstraktaĵoj; .
Nia teamo provizas plej multajn servojn malproksime (pro la proksima konekto al la kerna infrastrukturo), do ni ne volis kreskigi nian propran Kubernetes-grupon. Ni nur volis provizi servojn.
Baterioj ne inkluzivitaj
Nomad estas 20% orkestrado kiu donas 80% de kio estas bezonata. Ĉio, kion ĝi faras, estas administri deplojojn. Nomad zorgas pri deplojoj, rekomencas ujojn kaze de eraroj... kaj jen.
La tuta celo de Nomad estas tio, kion ĝi faras. minimumo: neniu fajna administrado de rajtoj aŭ , tiel speciale konceptita. Ĉi tiuj komponantoj estas provizitaj ekstere aŭ tute ne provizitaj.
Mi pensas, ke Nomad trovis la perfektan kompromison inter facileco de uzado kaj utileco. Ĝi estas bona por malgrandaj, sendependaj servoj. Se vi bezonas pli da kontrolo, vi devos levi ilin mem aŭ uzi alian aliron. nomado estas nur orkestro.
La plej bona afero pri Nomad estas, ke ĝi estas facila anstataŭigi. Preskaŭ ne ekzistas vendisto-ŝlosado, ĉar ĝiaj funkcioj facile integriĝas en iu ajn alia sistemo, kiu administras servojn. Ĝi funkcias same kiel regula duuma sur ĉiu maŝino en la areto, jen ĉio!
Loze kunligita Nomad-ekosistemo
La vera forto de Nomad estas en sia ekosistemo. Ĝi tre bone integriĝas kun aliaj - tute laŭvolaj - produktoj kiel ekz (ŝlosilvalora vendejo) aŭ (traktante sekretojn). Ene de la Nomad-dosiero, estas sekcioj por ĉerpi datumojn de ĉi tiuj servoj:
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
}
Ĉi tie ni legas la ŝlosilon service/geo-api/log-verbosity de Konsulo kaj dum la laboro ni reprezentas ĝin per mediovariablo LOG_LEVEL. Ni ankaŭ prezentas la ŝlosilon secret/geo-api-key el Volbo kiel API_KEY. Simpla sed potenca!
Pro ĝia simpleco, Nomad estas facile etendebla kun aliaj servoj per API. Ekzemple, laboretikedoj estas subtenataj. Ni etikedas ĉiujn servojn per metrikoj per la etikedo trv-metrics. Tiel Prometheus facile trovas ĉi tiujn servojn per Konsulo kaj kontrolas la finpunkton periode /metrics por novaj datumoj. La sama povas esti farita, ekzemple, por ŝtipoj, uzante .
Ekzistas multaj aliaj ekzemploj de etendebleco:
- Kuru Jenkins-laboron per hoko, kaj Konsulo observas la Nomad-laboron redeplojita kiam la servo-agordo ŝanĝiĝas.
- Ceph aldonas distribuitan dosiersistemon al Nomad.
- por ekvilibro de ŝarĝo.
Ĉio ĉi permesas sen speciala referenco al la vendisto.
Justa Averto
Neniu sistemo estas perfekta. Mi ne konsilas vin tuj enkonduki la plej novajn funkciojn en produktadon. Certe, estas eraroj kaj mankantaj funkcioj, sed la sama validas por Kubernetes.
Kompare kun Kubernetes, la Nomad-komunumo ne estas tiom granda. Kubernetes jam havas ĉirkaŭ 75 kommitaĵojn kaj 000 kontribuantojn, dum Nomad havas ĉirkaŭ 2000 kommitaĵojn kaj 14 kontribuantojn. Estos malfacile por Nomad daŭrigi kun Kubernetes rapide, sed ĝi eble ne estos necesa! Ĝi estas pli specialigita sistemo, kaj la pli malgranda komunumo ankaŭ signifas, ke via tira peto pli verŝajne estos rimarkita kaj akceptita ol Kubernetes.
Resumo
Konsumo: Ne uzu Kubernetes nur ĉar ĉiuj aliaj faras ĝin. Zorge taksu viajn postulojn kaj kontrolu, kiu ilo estas pli profita.
Se vi planas disfaldi multajn homogenajn servojn sur grandskala infrastrukturo, tiam Kubernetes estas bona elekto. Nur estu konscia pri la plia komplekseco kaj kurantaj kostoj. Iuj kostoj povas esti evititaj uzante administritan Kubernetes-medion kiel ekzemple aŭ .
Se vi nur serĉas solidan orkestranton, kiu estas facile konservebla kaj etendebla, kial ne provi Nomad? Vi eble surprizos kiom malproksimen ĉi tio kondukos vin.
Se Kubernetes estas kiel aŭto, Nomad estas skotero. Foje oni bezonas unu kaj foje la alian. Ambaŭ havas la rajton ekzisti.
fonto: www.habr.com