Batang babae na naka-scooter. Ilustrasyon freepik, Nomad logo mula sa Hashi Corp

Ang Kubernetes ay ang 300-pound gorilla ng container orchestration. Gumagana ito sa ilan sa pinakamalaking container system sa mundo, ngunit mahal.

Partikular na mahal para sa mas maliliit na team, na mangangailangan ng maraming oras ng suporta at isang matarik na curve sa pag-aaral. Ito ay sobrang overhead para sa aming pangkat ng apat. Kaya nagsimula kaming maghanap ng mga alternatibo - at umibig Pagala.

Anong gusto mo

Sinusuportahan ng aming team ang ilang karaniwang serbisyo sa pagsubaybay at pagsusuri ng pagganap: Mga endpoint ng API para sa mga sukatan na nakasulat sa Go, Prometheus exports, log parser gaya ng Logstash at Gollum, pati na rin ang mga database gaya ng InfluxDB o Elasticsearch. Ang bawat isa sa mga serbisyong ito ay tumatakbo sa sarili nitong lalagyan. Kailangan natin ng isang simpleng sistema para mapanatiling tumatakbo ang lahat.

Nagsimula kami sa isang listahan ng mga kinakailangan para sa orkestrasyon ng lalagyan:

• Pagpapatakbo ng isang hanay ng mga serbisyo sa maraming makina.
• Pangkalahatang-ideya ng mga tumatakbong serbisyo.
• Mga link sa pagitan ng mga serbisyo.
• Awtomatikong i-restart kung bumaba ang serbisyo.
• Pagpapanatili ng imprastraktura ng isang maliit na pangkat.

Bilang karagdagan, ang mga sumusunod na bagay ay magiging maganda, ngunit hindi kinakailangang mga karagdagan:

• Mga tagging machine batay sa kanilang mga kakayahan (halimbawa, mga tagging machine na may mabilis na disk para sa mabibigat na serbisyo ng I/O).
• Kakayahang magpatakbo ng mga serbisyo nang hiwalay sa orkestra (halimbawa, sa panahon ng pag-unlad).
• Isang karaniwang lugar para magbahagi ng mga configuration at lihim.
• Endpoint para sa mga sukatan at log.

Bakit hindi tama ang Kubernetes para sa atin

Habang nag-prototype kami sa Kubernetes, napansin namin na nagdaragdag kami ng mga mas kumplikadong layer ng logic na lubos naming pinagkakatiwalaan.

Bilang halimbawa, sinusuportahan ng Kubernetes ang mga built-in na configuration ng serbisyo sa pamamagitan ng ConfigMaps. Mabilis kang malito, lalo na kapag pinagsasama ang maraming configuration file o nagdaragdag ng mga karagdagang serbisyo sa isang pod. Kubernetes (o timon sa kasong ito) ay nagbibigay-daan sa iyo na pabago-bagong ipatupad ang mga panlabas na pagsasaayos upang paghiwalayin ang mga alalahanin. Ngunit nagreresulta ito sa isang mahigpit, nakatagong pagsasama sa pagitan ng iyong proyekto at ng Kubernetes. Gayunpaman, ang Helm at ConfigMaps ay mga karagdagang opsyon, kaya hindi mo na kailangang gamitin ang mga ito. Maaari mo lamang kopyahin ang pagsasaayos sa imahe ng Docker. Gayunpaman, nakakaakit na pumunta sa landas na ito at bumuo ng mga hindi kinakailangang abstraction na maaari mong pagsisihan sa huli.

Bukod pa rito, mabilis na umuunlad ang Kubernetes ecosystem. Kailangan ng maraming oras at lakas upang manatiling napapanahon sa pinakamahuhusay na kagawian at mga pinakabagong tool. Kubectl, minikube, kubeadm, timon, tiller, kops, oc - nagpapatuloy ang listahan. Hindi lahat ng mga tool na ito ay kailangan kapag nagsisimula ka, ngunit hindi mo alam kung ano ang kakailanganin mo, kaya kailangan mong magkaroon ng kamalayan sa lahat. Dahil dito, medyo matarik ang learning curve.

Kailan gagamitin ang Kubernetes

Sa aming kumpanya, maraming tao ang gumagamit ng Kubernetes at lubos na nasisiyahan dito. Ang mga pagkakataong ito ay pinamamahalaan ng Google o Amazon, na may mga mapagkukunan upang suportahan ang mga ito.

Kasama ang Kubernetes kamangha-manghang mga tampok, na ginagawang mas madaling pamahalaan ang orkestrasyon ng lalagyan sa sukat:

• Detalyadong pamamahala ng mga karapatan.
• Mga custom na controller magdagdag ng lohika sa kumpol. Ito ay mga programa lamang na nakikipag-usap sa Kubernetes API.
• Autoscaling! Maaaring sukatin ng Kubernetes ang mga serbisyo on demand gamit ang mga sukatan ng serbisyo at nang hindi nangangailangan ng manu-manong interbensyon.

Ang tanong ay kung talagang kailangan mo ang lahat ng mga tampok na ito. Hindi ka maaaring umasa lamang sa mga abstraction; kailangan mong malaman kung ano ang nangyayari sa ilalim ng hood.

Ang aming koponan ay nagbibigay ng karamihan sa mga serbisyo nang malayuan (dahil sa malapit na koneksyon sa pangunahing imprastraktura), kaya hindi namin nais na itaas ang aming sariling Kubernetes cluster. Nais lang naming magbigay ng mga serbisyo.

Hindi kasama ang mga baterya

Ang Nomad ay 20% ng orkestra na nagbibigay ng 80% ng kailangan. Ang ginagawa lang nito ay pamahalaan ang mga deployment. Si Nomad ang nag-aalaga ng mga deployment, nagre-restart ng mga container kung sakaling magkaroon ng mga error... at iyon lang.

Ang buong punto ng Nomad ay kung ano ang ginagawa nito minimum: walang butil na pamamahala ng mga karapatan o pinahabang mga patakaran sa network, ito ay espesyal na idinisenyo. Ang mga sangkap na ito ay ibinigay sa labas o hindi sa lahat.

Sa tingin ko, natagpuan ng Nomad ang perpektong kompromiso sa pagitan ng kadalian ng paggamit at utility. Ito ay mabuti para sa maliliit at independiyenteng serbisyo. Kung kailangan mo ng higit pang kontrol, kakailanganin mong itaas ang mga ito sa iyong sarili o gumamit ng ibang diskarte. Nomad ay lamang orkestra.

Ang pinakamagandang bagay tungkol sa Nomad ay madali ito palitan. Halos walang koneksyon sa vendor, dahil ang mga function nito ay madaling isinama sa anumang iba pang sistema na namamahala sa mga serbisyo. Gumagana lang ito tulad ng isang regular na binary sa bawat makina sa cluster, iyon lang!

Nomad na ecosystem ng maluwag na pinagsamang mga bahagi

Ang tunay na lakas ng Nomad ay ang ecosystem nito. Napakahusay na pinagsama nito sa iba pang - ganap na opsyonal - mga produkto tulad ng Consul (key-value store) o Vault (pagproseso ng mga lihim). Sa loob ng Nomad file mayroong mga seksyon para sa pagkuha ng data mula sa mga serbisyong ito:

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
}

Dito namin nabasa ang susi service/geo-api/log-verbosity mula sa Consul at habang nagtatrabaho ay inilalantad namin ito sa isang variable ng kapaligiran LOG_LEVEL. Iniharap din namin ang susi secret/geo-api-key mula sa Vault bilang API_KEY. Simple ngunit makapangyarihan!

Dahil sa pagiging simple nito, madaling mapalawak ang Nomad sa iba pang mga serbisyo sa pamamagitan ng API. Halimbawa, sinusuportahan ang mga tag para sa mga gawain. Tina-tag namin ang lahat ng serbisyo ng mga sukatan trv-metrics. Sa ganitong paraan, madaling mahanap ng Prometheus ang mga serbisyong ito sa pamamagitan ng Consul at pana-panahong suriin ang endpoint /metrics para sa bagong data. Ang parehong ay maaaring gawin, halimbawa, para sa mga log, gamit Loki.

Mayroong maraming iba pang mga halimbawa ng pagpapalawak:

• Magpatakbo ng trabahong Jenkins gamit ang hook, at sinusubaybayan ng Consul ang muling pag-deploy ng Nomad job kapag nagbago ang configuration ng serbisyo.
• Nagdagdag si Ceph ng distributed file system sa Nomad.
• Fabio para sa load balancing.

Ang lahat ng ito ay nagpapahintulot organikong bumuo ng imprastraktura nang walang anumang espesyal na koneksyon sa vendor.

Makatarungang babala

Walang sistemang perpekto. Hindi ko inirerekomenda na agad na ipakilala ang mga pinakabagong feature sa produksyon. Siyempre, may mga bug at nawawalang feature, ngunit ganoon din ang naaangkop sa Kubernetes.

Kung ikukumpara sa Kubernetes, hindi ganoon kalaki ang komunidad ng Nomad. Ang Kubernetes ay mayroon nang humigit-kumulang 75 commit at 000 contributor, habang ang Nomad ay may humigit-kumulang 2000 commit at 14 contributor. Mahihirapan ang Nomad na makasabay sa bilis ng Kubernetes, pero hindi naman siguro kailangan! Ito ay isang mas espesyal na sistema, at ang mas maliit na komunidad ay nangangahulugan din na ang iyong kahilingan sa paghila ay mas malamang na mapansin at matanggap, kumpara sa Kubernetes.

Buod

Bottom line: Huwag gumamit ng Kubernetes dahil lang ginagawa ito ng iba. Maingat na suriin ang iyong mga kinakailangan at suriin kung aling tool ang mas kapaki-pakinabang.

Kung plano mong mag-deploy ng isang tonelada ng mga homogenous na serbisyo sa isang malakihang imprastraktura, kung gayon ang Kubernetes ay isang magandang opsyon. Magkaroon lamang ng kamalayan sa karagdagang pagiging kumplikado at mga gastos sa pagpapatakbo. Ang ilang mga gastos ay maaaring iwasan sa pamamagitan ng paggamit ng isang pinamamahalaang kapaligiran ng Kubernetes tulad ng Google Kubernetes Engine o Amazon EKS.

Kung naghahanap ka lang ng maaasahang orkestra na madaling mapanatili at mapalawak, bakit hindi subukan ang Nomad? Maaaring mabigla ka kung gaano kalayo ito magdadala sa iyo.

Kung ihahambing ang Kubernetes sa isang kotse, magiging scooter si Nomad. Minsan kailangan mo ng isang bagay at minsan kailangan mo ng iba. Parehong may karapatang umiral.

Pinagmulan: www.habr.com