Tyttö skootterilla. Kuva Freepik, Nomad logo alkaen Hashi Corp

Kubernetes on 300 kiloa painava konttiorkestroinnin gorilla. Se toimii joissakin maailman suurimmista konttijärjestelmistä, mutta on kallis.

Erityisen kallista pienemmille tiimeille, mikä vaatii paljon tukiaikaa ja jyrkkää oppimiskäyrää. Tämä on liikaa meidän neljän hengen joukkueellemme. Joten aloimme etsiä vaihtoehtoja - ja rakastuimme niihin Nomadi.

Mitä haluat

Tiimimme tukee useita yleisiä suorituskyvyn seuranta- ja analysointipalveluita: API-päätepisteet Go-sovelluksella kirjoitetuille mittareille, Prometheus-vientit, lokijäsentimet, kuten Logstash ja Gollumsekä tietokannat, kuten InfluxDB tai Elasticsearch. Jokainen näistä palveluista toimii omassa konttissaan. Tarvitsemme yksinkertaisen järjestelmän pitääksemme kaiken käynnissä.

Aloitimme luettelolla kontin orkestroinnin vaatimuksista:

• Palvelusarjan suorittaminen monilla koneilla.
• Yleiskatsaus käynnissä oleviin palveluihin.
• Linkit palveluiden välillä.
• Automaattinen uudelleenkäynnistys, jos palvelu lakkaa.
• Infrastruktuurin ylläpito pienellä tiimillä.

Lisäksi seuraavat asiat ovat mukavia, mutta ei pakollisia lisäyksiä:

• Koneiden merkitseminen ominaisuuksiensa perusteella (esimerkiksi merkintäkoneet nopeilla levyillä raskaille I/O-palveluille).
• Kyky ajaa palveluita orkestraattorista riippumatta (esimerkiksi kehittämisen aikana).
• Yhteinen paikka kokoonpanojen ja salaisuuksien jakamiseen.
• Mittareiden ja lokien päätepiste.

Miksi Kubernetes ei ole oikea meille

Kun loimme prototyyppiä Kubernetesin kanssa, huomasimme, että lisäämme yhä monimutkaisempia logiikkakerroksia, joihin luotimme voimakkaasti.

Esimerkiksi Kubernetes tukee sisäänrakennettuja palvelumäärityksiä kautta ConfigMaps. Voit hämmentyä nopeasti, varsinkin kun yhdistät useita määritystiedostoja tai lisäät lisäpalveluita koteloon. Kubernetes (tai ruori Tässä tapauksessa) voit ottaa dynaamisesti käyttöön ulkoisia konfiguraatioita erillisten ongelmien ratkaisemiseksi. Mutta tämä johtaa tiiviiseen, piilotettuun kytkentään projektisi ja Kubernetesin välille. Helm ja ConfigMaps ovat kuitenkin lisävaihtoehtoja, joten sinun ei tarvitse käyttää niitä. Voit yksinkertaisesti kopioida kokoonpanon Docker-kuvaan. On kuitenkin houkuttelevaa mennä tälle tielle ja rakentaa tarpeettomia abstraktioita, joita saatat katua myöhemmin.

Lisäksi Kubernetes-ekosysteemi kehittyy nopeasti. Parhaiden käytäntöjen ja uusimpien työkalujen ajan tasalla pysyminen vie paljon aikaa ja energiaa. Kubectl, minikube, kubeadm, helm, tiller, kops, oc - lista jatkuu ja jatkuu. Kaikki nämä työkalut eivät ole välttämättömiä aloittaessasi, mutta et tiedä mitä tarvitset, joten sinun on oltava tietoinen kaikesta. Tästä johtuen oppimiskäyrä on melko jyrkkä.

Milloin Kubernetesia käytetään

Yrityksessämme monet ihmiset käyttävät Kubernetesia ja ovat siihen melko tyytyväisiä. Näitä tapauksia hallinnoi Google tai Amazon, joilla on resurssit tukea niitä.

Mukana tulee Kubernetes hämmästyttäviä ominaisuuksia, jotka tekevät kontin orkestroinnista mittakaavassa helpommin hallittavissa:

• Yksityiskohtainen oikeuksien hallinta.
• Mukautetut ohjaimet lisää logiikkaa klusteriin. Nämä ovat yksinkertaisesti ohjelmia, jotka puhuvat Kubernetes API:lle.
• Automaattinen skaalaus! Kubernetes voi skaalata palveluja tarpeen mukaan käyttämällä palvelumetriikkaa ja ilman manuaalista toimenpiteitä.

Kysymys kuuluu, tarvitsetko todella kaikkia näitä ominaisuuksia. Et voi luottaa vain abstraktioihin; sinun täytyy ottaa selvää, mitä konepellin alla tapahtuu.

Tiimimme tarjoaa suurimman osan palveluista etänä (johtuen läheisestä yhteydestä pääinfrastruktuuriin), joten emme halunneet nostaa omaa Kubernetes-klusteriamme. Halusimme vain tarjota palveluita.

Paristot eivät sisälly toimitukseen

Nomad on 20% orkestraatiosta, joka tarjoaa 80% siitä, mitä tarvitaan. Se vain hallitsee käyttöönottoja. Nomad huolehtii käyttöönotoista, käynnistää kontit uudelleen virheiden sattuessa... ja siinä kaikki.

Nomadin koko pointti on siinä, mitä se tekee vähimmäis-: ei yksityiskohtaista oikeuksien hallintaa tai laajennetut verkkokäytännöt, tämä on erityisesti suunniteltu. Nämä komponentit toimitetaan ulkoisesti tai ei ollenkaan.

Mielestäni Nomad on löytänyt täydellisen kompromissin käytön helppouden ja hyödyllisyyden välillä. Se sopii pienille, itsenäisille palveluille. Jos tarvitset enemmän valvontaa, sinun on nostettava ne itse tai käytettävä erilaista lähestymistapaa. Nomad on vain orkestraattori.

Parasta Nomadissa on, että se on helppoa vaihda. Yhteyttä toimittajaan ei käytännössä ole, koska sen toiminnot on helppo integroida mihin tahansa muuhun palveluita hallitsevaan järjestelmään. Se vain toimii tavallisena binaarina jokaisessa klusterin koneessa, siinä kaikki!

Nomad ekosysteemi löyhästi kytketyistä komponenteista

Nomadin todellinen vahvuus on sen ekosysteemi. Se integroituu erittäin hyvin muihin - täysin valinnaisiin - tuotteisiin, kuten Konsuli (avainarvovarasto) tai Holvi (käsittelysalaisuudet). Nomad-tiedoston sisällä on osiot tietojen poimimiseen näistä palveluista:

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
}

Tässä luemme avaimen service/geo-api/log-verbosity Consulilta ja työskennellessämme altistamme sen ympäristömuuttujalle LOG_LEVEL. Esittelemme myös avaimen secret/geo-api-key Holvista as API_KEY. Yksinkertaista mutta tehokasta!

Yksinkertaisuudensa ansiosta Nomad on helposti laajennettavissa muihin palveluihin API:n kautta. Esimerkiksi tehtävien tunnisteet ovat tuettuja. Merkitsemme kaikki palvelut mittareilla trv-metrics. Näin Prometheus voi helposti löytää nämä palvelut Consulin kautta ja tarkistaa päätepisteen säännöllisesti /metrics uusia tietoja varten. Sama voidaan tehdä esimerkiksi tukille käyttämällä Loki.

On monia muita esimerkkejä laajennettavuus:

• Suorita Jenkins-työ koukun avulla, ja Consul tarkkailee Nomad-työn uudelleensijoittamista, kun palvelun kokoonpano muuttuu.
• Ceph lisää hajautetun tiedostojärjestelmän Nomadiin.
• Fabio kuormituksen tasapainottamiseen.

Kaikki tämä mahdollistaa kehittää infrastruktuuria orgaanisesti ilman erityistä yhteyttä myyjään.

Reilu varoitus

Mikään järjestelmä ei ole täydellinen. En suosittele uusimpien ominaisuuksien heti käyttöönottoa tuotantoon. Tietysti on bugeja ja puuttuvia ominaisuuksia, mutta sama pätee Kubernetesiin.

Kubernetesiin verrattuna Nomad-yhteisö ei ole niin suuri. Kubernetesilla on jo noin 75 000 sitoumusta ja 2000 14 avustajaa, kun taas Nomadilla on noin 000 300 sitoumusta ja XNUMX avustajaa. Nomadin on vaikea pysyä Kubernetesin vauhdissa, mutta ehkä sen ei tarvitsekaan! Se on erikoistuneempi järjestelmä, ja pienempi yhteisö tarkoittaa myös sitä, että vetopyyntösi huomataan ja hyväksytään todennäköisemmin kuin Kubernetes.

Yhteenveto

Bottom line: Älä käytä Kubernetesia vain siksi, että kaikki muut tekevät niin. Arvioi tarpeitasi huolellisesti ja tarkista, kumpi työkalu on hyödyllisempi.

Jos aiot ottaa käyttöön tonnia homogeenisia palveluita laajamittaisessa infrastruktuurissa, Kubernetes on hyvä vaihtoehto. Ole vain tietoinen lisääntyneestä monimutkaisuudesta ja käyttökustannuksista. Joitakin kustannuksia voidaan välttää käyttämällä hallittua Kubernetes-ympäristöä, kuten Google Kubernetes -moottori tai Amazon EX.

Jos etsit vain luotettavaa orkestraattoria, jota on helppo ylläpitää ja joka on laajennettavissa, mikset kokeilisi Nomadia? Saatat yllättyä kuinka pitkälle tämä vie.

Jos Kubernetesia verrataan autoon, Nomad olisi skootteri. Joskus tarvitset yhtä ja joskus toista. Molemmilla on oikeus olemassaoloon.

Lähde: will.com