Iespējams, jums nav nepieciešams Kubernetes
Meitene uz skrejriteni. Ilustrācija freepik, Nomad logo no HashiCorp

Kubernetes ir 300 kilogramu smaga gorilla konteineru orķestrēšanai. Tā darbojas dažās lielākajās konteineru sistēmās pasaulē, bet tā ir dārga.

Īpaši dārga mazām komandām, kurām būs jātērē daudz laika atbalstam un sarežģītai mācību līknei. Mūsu četru cilvēku komandai tas ir pārāk liels izdevums. Tādēļ mēs sākām meklēt alternatīvas – un iemīlējāmies Nomad.

Ko vēlamies

Mūsu komanda atbalsta virkni tipisku dienestu monitorēšanai un veiktspējas analīzei: API galapunktus metriku apkopošanai, kas rakstītas Go, Prometheus eksportētājus, žurnālu analizatorus, piemēram, Logstash un Gollum, kā arī datubāzes, piemēram, InfluxDB vai Elasticsearch. Katrs no šiem pakalpojumiem darbojas savā konteinerā. Mums ir nepieciešama vienkārša sistēma, lai uzturētu visu to darba kārtībā.

Mēs sākām ar prasību sarakstu konteineru orķestrēšanai:

Pakalu jumtu uzstādīšana uz vairākām mašīnām.
Pārskats par uzstādītajām pakalpojumiem.
Attiecības starp pakalpojumiem.
Automātiska atkārtota palaišana, ja pakalpojums avarē.
Infrastruktūras apkalpošana ar nelielu komandu.

Turklāt sekojošas lietas būs patīkamas, bet ne obligātas papildinājumus:

Mašīnu apzīmēšana pēc to iespējām (piemēram, ātru disku apzīmēšana smagiem I/O pakalpojumiem).
Iespēja palaist pakalpojumus neatkarīgi no orķestratora (piemēram, izstrādes laikā).
Kopējā vieta konfigurāciju un noslēpumu apmaiņai.
Galapunkts metriku un žurnālu apkopošanai.

Kāpēc Kubernetes mums neder

Veidojot prototipu ar Kubernetes, mēs pamanījām, ka sākam pievienot arvien sarežģītākas loģikas kārtas, uz kurām mēs bez ierunām paļāvāmies.

Piemēram, Kubernetes atbalsta iebūvētās pakalpojumu konfigurācijas caur ConfigMaps. Jūs varat ātri apjukt, īpaši apvienojot vairākas konfigurācijas failus vai pievienojot papildu pakalpojumus podā. Kubernetes (vai helm šajā gadījumā) ļauj ieviest dinamiskas ārējās konfigurācijas interesu sadalīšanai. Tomēr tas noved pie stingras slēptās saiknes starp jūsu projektu un Kubernetes. Jā, Helm un ConfigMaps ir papildus iespējas, tāpēc nav obligāti tās izmantot. Jūs varat vienkārši kopēt konfigurāciju Docker attēlā. Tomēr vilinoši ir iet pa šo ceļu un veidot nevajadzīgas abstrakcijas, par ko vēlāk varat nožēlot.

Turklāt Kubernetes ekosistēma ātri attīstās. Nepieciešams daudz laika un enerģijas, lai sekotu jaunākajām labākajām praksēm un rīkiem. Kubectl, minikube, kubeadm, helm, tiller, kops, oc — saraksts turpinās un turpinās. Darba sākumā nav nepieciešami visi šie rīki, bet jūs nezināt, kas būs nepieciešams, tāpēc jābūt informētam par visu. Tas padara mācību līkni diezgan stāvu.

Kad lietot Kubernetes

Mūsu uzņēmumā daudzi izmanto Kubernetes un ir diezgan apmierināti ar to. Šos instance pārvalda Google vai Amazon, kuriem ir pietiekami daudz resursu atbalstam.

Kubernetes nāk ar pārsteidzošām funkcijām, kas padara plašu konteineru orķestrāciju vieglāk pārvaldāmu:

Detalizēta tiesību pārvaldība.
Pielāgotie kontrolieri pievieno loģiku klasterim. Tie ir tikai programmas, kas runā ar Kubernetes API.
Automātiskā mērogošana! Kubernetes spēj mērogot pakalpojumus pēc pieprasījuma, izmantojot pakalpojumu metriku un neprasot manuāru iejaukšanos.

Jautājums ir, vai jums tiešām nepieciešamas visas šīs funkcijas. Nav iespējams paļauties tikai uz abstrakcijām; jums būs jāiemācās, kas notiek aizkulisēs.

Mūsu komanda nodrošina lielāko daļu pakalpojumu attālināti (sakarā ar tuvu saikni ar galveno infrastruktūru), tāpēc mēs nevēlējāmies uzcelt savu Kubernetes klasteri. Mēs vēlējāmies vienkārši sniegt pakalpojumus.

Baterijas nav iekļautas

Nomad ir 20% orķestrācijas, kas sniedz 80% nepieciešamā. Viss, ko tas dara, ir pārvalda dislokācijas. Nomad rūpējas par dislokācijām, restartē konteinerus kļūdu gadījumā... un tas ir viss.

Visa Nomad jēga ir tā, ko tas dara minimāli: nav nekādas detalizētas tiesību pārvaldības vai paplašinātām tīkla politikām, tā speciāli izstrādāts. Šie komponenti tiek piedāvāti no ārpuses vai vispār netiek piedāvāti.

Domāju, ka Nomad atrada ideālu līdzsvaru starp lietošanas vieglumu un lietderību. Tas ir lieliski piemērots mazajiem, neatkarīgajiem pakalpojumiem. Ja nepieciešama lielāka kontrole, tad būs jādibina tie pašiem vai jāizmanto cits pieejas veids. Nomad ir vienkāršs orķestrators.

Vislabākais Nomad ir tas, ka to ir viegli aizstāt. Piekļuve pie piegādātājām gandrīz nav, jo tā funkcijas viegli integrējas ar jebkuru citu sistēmu, kas pārvalda pakalpojumus. Tas darbojas kā parasts binārais fails uz katras mašīnas klasterī, un tas ir viss!

Nomad ekosistēma sastāv no vāji saistītiem komponentiem.

Reālā jauda Nomad ir tās ekosistēmā. Tas ļoti labi integrējas ar citiem — pilnīgi izvēles — produktiem, piemēram, Consul (atslēga-vērtība krātuve) vai Vault (noslēpumu apstrāde). Iekš Nomad faila ir sadaļas, lai iegūtu datus no šiem pakalpojumiem:

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
}

Šeit mēs lasām atslēgu service/geo-api/log-verbosity no Consul un procesa gaitā piešķiram to kā vides mainīgo LOG_LEVEL. Mēs arī piešķiram atslēgu secret/geo-api-key no Vault kā API_KEY. Viegli, bet jaudīgi!

Pateicoties savai vienkāršībai, Nomad viegli paplašinās ar citiem pakalpojumiem caur API. Piemēram, tiek atbalstīti marķējumi uz uzdevumiem. Mēs apzīmējam visus pakalpojumus ar metrikām ar marķējumu trv-metrics. Tādējādi Prometheus viegli atrod šos pakalpojumus caur Consul un regulāri pārbauda gala punktu /metrics jauniem datiem. To pašu var izdarīt, piemēram, ar žurnāliem, izmantojot Loki.

Ir daudz citu paplašināmības piemēru:

Jenkins uzdevuma palaišana ar sākuma signālu, un Consul uzrauga Nomad uzdevuma atkārtotu izvietošanu, ja mainās pakalpojuma konfigurācija.
Ceph pievieno Nomad izplatītu failu sistēmu.
fabio slodzes līdzsvarošana.

Visi šie aspekti ļauj organiski attīstīt infrastruktūru bez lielas saistīšanās ar piegādātāju.

Godīgais brīdinājums

Neviens sistēma nav perfekta. Neiesaku uzreiz ieviest produkcijā visjaunākās funkcijas. Protams, ir kļūdas un trūkstošas funkcijas, bet tas pats attiecas arī uz Kubernetes.

Salīdzinājumā ar Kubernetes, Nomad kopiena nav tik liela. Kubernetes ir ap 75 000 apņemšanos un 2000 līdzdalībnieku, kamēr Nomad ir ap 14 000 apņemšanos un 300 līdzdalībnieku. Nomad būs grūti noturēt un neatpalikt no Kubernetes ātruma, taču varbūt tas arī nav nepieciešams! Tā ir specializētāka sistēma, un mazāka kopiena nozīmē, ka jūsu pull pieprasījums tiks pamanīts un pieņemts ātrāk, salīdzinot ar Kubernetes.

CV

Secinājums: nelietojiet Kubernetes tikai tāpēc, ka to dara visi. Rūpīgi novērtējiet savas prasības un pārbaudiet, kurš rīks ir izdevīgāks.

Ja plānojat izvērst lielu homogēnu pakalpojumu apjomu plašā infrastruktūrā, tad Kubernetes ir laba izvēle. Tikai atcerieties par papildu sarežģījumiem un uzturēšanas izmaksām. Kādas izmaksas var izvairīties, izmantojot pārvaldītu Kubernetes vidi, piemēram, Google Kubernetes Engine vai Amazon EKS.

Ja vienkārši meklējat uzticamu orķestratoru, kas ir viegli uzturams un paplašināms, kāpēc gan neizmēģināt Nomad? Varbūt jūs pārsteigs, cik tālu tas jūs novedīs.

Ja Kubernetes salīdzinātu ar mašīnu, tad Nomad būtu skūteris. Dažreiz jums nepieciešams viens, dažreiz otrs. Abiem ir tiesības pastāvēt.

Avots: habr.com