Neska scooter batean. Ilustrazioa , Nomad logotipoa
Kubernetes edukiontzien orkestrazioaren 300 kiloko gorila da. Munduko edukiontzi handienetako sistema batzuetan funtzionatzen du, baina garestia da.
Bereziki garestia talde txikiagoentzat, laguntza-denbora asko eta ikasketa-kurba aldapatsuak beharko ditu. Hau gehiegizko gastua da gure lauko taldearentzat. Beraz, alternatibak bilatzen hasi ginen, eta maitemindu ginen .
Zer nahi duzu
Gure taldeak errendimenduaren monitorizazio eta analisi zerbitzu komun batzuk onartzen ditu: Go-n idatzitako metriketarako API amaiera-puntuak, Prometheus-en esportazioak, Logstash bezalako log-analisi-analisiatzaileak eta , baita InfluxDB edo Elasticsearch bezalako datu-baseak ere. Zerbitzu horietako bakoitza bere edukiontzian exekutatzen da. Sistema sinple bat behar dugu dena martxan mantentzeko.
Edukiontzien orkestraziorako eskakizun zerrenda batekin hasi ginen:
- Makina askotan zerbitzu multzo bat exekutatzen.
- Exekutatzen diren zerbitzuen ikuspegi orokorra.
- Zerbitzuen arteko loturak.
- Berrabiarazi automatikoa zerbitzua jaisten bada.
- Azpiegituren mantentze-lanak talde txiki batek.
Gainera, ondoko gauza hauek politak izango dira, baina ez dira beharrezko gehigarriak:
- Makinak beren gaitasunen arabera etiketatzea (adibidez, I/O zerbitzu astunetarako disko bizkorreko makinak etiketatzea).
- Zerbitzuak orkestratzailearengandik independentean exekutatzeko gaitasuna (adibidez, garapenean).
- Konfigurazioak eta sekretuak partekatzeko leku arrunta.
- Neurrietarako eta erregistroetarako amaierako puntua.
Zergatik Kubernetes ez den egokia guretzat
Kubernetes-ekin prototipoa egiten genuen heinean, asko fidatzen ginen gero eta logika geruza konplexuagoak gehitzen ari ginela ohartu ginen.
Adibide gisa, Kubernetes-ek zerbitzu integratuen konfigurazioak onartzen ditu . Azkar nahas zaitezke, batez ere hainbat konfigurazio-fitxategi batuz edo zerbitzu gehigarriak pod batean gehitzean. Kubernetes (edo kasu honetan) kanpoko konfigurazioak dinamikoki ezartzeko aukera ematen du kezkak bereizteko. Baina horrek zure proiektuaren eta Kubernetesen arteko lotura estu eta ezkutuan sortzen du. Hala ere, Helm eta ConfigMaps aukera osagarriak dira, beraz, ez dituzu erabili beharrik. Konfigurazioa Docker irudian kopiatu besterik ez duzu egin. Hala ere, tentagarria da bide horretatik jotzea eta gero damutu zaitezkeen alferrikako abstrakzioak eraikitzea.
Gainera, Kubernetes ekosistema azkar eboluzionatzen ari da. Denbora eta energia asko behar da praktika onen eta azken tresnekin eguneratuta egoteko. Kubectl, minikube, kubeadm, helm, tiller, kops, oc - zerrendak aurrera egiten du. Tresna hauek guztiak ez dira behar hasten zarenean, baina ez dakizu zer beharko duzun, beraz, guztiaren berri izan behar duzu. Horregatik, ikasketa kurba nahiko aldapatsua da.
Noiz erabili Kubernetes
Gure enpresan, jende askok erabiltzen du Kubernetes eta nahiko pozik daude horrekin. Instantzia hauek Googlek edo Amazonek kudeatzen dituzte, haiek laguntzeko baliabideak dituztenak.
Kubernetesekin dator , edukiontzien orkestrazioa eskalan kudeagarriagoa egiten dutenak:
- Xehetasuna .
- gehitu logika klusterari. Kubernetes APIarekin hitz egiten duten programak besterik ez dira.
- ! Kubernetes-ek zerbitzuak eska ditzake, zerbitzu-neurriak erabiliz eta eskuzko esku-hartzea beharrik gabe.
Ezaugarri horiek guztiak benetan behar dituzun ala ez da galdera. Ezin zara abstrakzioetan soilik fidatu; .
Gure taldeak urrunetik eskaintzen ditu zerbitzu gehienak (azpiegitura nagusiarekiko lotura estua dela eta), beraz, ez dugu Kubernetes kluster propioa sortu nahi izan. Zerbitzuak eskaintzea besterik ez genuen nahi.
Pilak ez daude barne
Nomad orkestrazioaren % 20 da, behar denaren % 80 ematen duena. Egiten duen guztia inplementazioak kudeatzea da. Nomad inplementazioez arduratzen da, akatsen kasuan edukiontziak berrabiarazten ditu... eta kitto.
Nomad-en puntu osoa egiten duena da gutxieneko: eskubide zehatzik ez kudeaketa edo , hau bereziki diseinatuta dago. Osagai hauek kanpotik ematen dira edo batere ez.
Uste dut Nomad-ek erabilera erraztasunaren eta erabilgarritasunaren arteko konpromiso ezin hobea aurkitu duela. Zerbitzu txiki eta independenteetarako ona da. Kontrol gehiago behar baduzu, zuk zeuk planteatu beharko dituzu edo beste ikuspegi bat erabili. Nomada da besterik ez orkestratzailea.
Nomad-en gauzarik onena erraza dela da ordeztu. Saltzailearekin ia ez dago konexiorik, bere funtzioak zerbitzuak kudeatzen dituen beste edozein sistematan erraz integratzen baitira. Bitar arrunt bat bezala exekutatzen da klusterreko makina guztietan, hori da dena!
Akoplatutako osagaien ekosistema nomada
Nomad-en benetako indarra bere ekosistema da. Oso ondo integratzen da beste produktu batzuekin - guztiz aukerakoak - esaterako (gako-balioen biltegia) edo (sekretuak tratatzea). Nomad fitxategiaren barruan zerbitzu hauetako datuak ateratzeko atalak daude:
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
}
Hemen irakurri dugu gakoa service/geo-api/log-verbosity Kontsuletik eta lanean ari zaren bitartean ingurune-aldagai baten aurrean jartzen dugu LOG_LEVEL. Gakoa ere aurkezten dugu secret/geo-api-key gangatik as API_KEY. Sinple baina indartsua!
Bere sinpletasuna dela eta, Nomad erraz heda daiteke beste zerbitzu batzuekin API bidez. Adibidez, zereginetarako etiketak onartzen dira. Zerbitzu guztiak neurgailuekin etiketatzen ditugu trv-metrics. Modu honetan, Prometheus-ek erraz aurki ditzake zerbitzu hauek Consul bidez eta aldian-aldian amaierako puntua egiaztatu /metrics datu berrietarako. Gauza bera egin daiteke, adibidez, erregistroetarako, erabiliz .
Hedagarritasunaren beste adibide asko daude:
- Exekutatu Jenkins lan bat kako bat erabiliz, eta Consul-ek Nomad lanaren birmoldaketa kontrolatzen du zerbitzuaren konfigurazioa aldatzen denean.
- Ceph-ek banatutako fitxategi-sistema gehitzen du Nomad-i.
- karga orekatzeko.
Horrek guztiak ahalbidetzen du saltzailearekin lotura berezirik gabe.
Bidezko abisua
Ez da sistema perfektua. Ez dut gomendatzen ekoizpenean funtzio berrienak berehala sartzea. Jakina, akatsak eta funtzioak falta dira, baina gauza bera gertatzen da Kubernetesekin.
Kubernetesekin alderatuta, Nomad komunitatea ez da horren handia. Kubernetes-ek dagoeneko 75 konpromiso eta 000 laguntzaile inguru ditu, eta Nomad-ek, berriz, 2000 konpromiso eta 14 laguntzaile inguru ditu. Nomad-ek zaila izango du Kubernetesen abiadurari eustea, baina agian ez du zertan! Sistema espezializatuagoa da, eta komunitate txikiagoak ere esan nahi du zure tira eskaera gehiago nabarituko eta onartuko dela, Kubernetesekin alderatuta.
Laburpena
Beheko lerroa: ez erabili Kubernetes beste guztiak egiten ari direlako bakarrik. Ebaluatu arretaz zure baldintzak eta egiaztatu zein tresna den onuragarriena.
Eskala handiko azpiegitura batean zerbitzu homogeneo ugari zabaltzeko asmoa baduzu, Kubernetes aukera ona da. Kontuan izan konplexutasun gehigarriaren eta funtzionamendu kostuen berri. Kostu batzuk ekidin daitezke Kubernetes ingurune kudeatu bat erabiliz, adibidez edo .
Mantentzen erraza eta hedagarria den orkestratzaile fidagarri baten bila bazabiltza, zergatik ez probatu Nomad? Harritu zaitezke noraino eramango zaituen honek.
Kubernetes auto batekin konparatzen bada, Nomad scooter bat izango litzateke. Batzuetan gauza bat behar duzu eta beste batzuetan beste bat. Biek dute existitzeko eskubidea.
Iturria: www.habr.com