Msichana kwenye skuta. Kielelezo freepik, Nembo ya Nomad kutoka HashiCorp

Kubernetes ni sokwe wa pauni 300 wa okestra ya kontena. Inafanya kazi katika mifumo mingine mikubwa zaidi ya kontena ulimwenguni, lakini ni ghali.

Ni ghali zaidi kwa timu ndogo, ambayo itahitaji muda mwingi wa usaidizi na mkondo mwinuko wa kujifunza. Hili ni jambo la ziada sana kwa timu yetu ya wachezaji wanne. Kwa hivyo tulianza kutafuta njia mbadala - na tukapendana kuhamahama.

Unataka nini

Timu yetu inaauni idadi ya huduma za kawaida za ufuatiliaji na uchanganuzi wa utendakazi: Vipimo vya API vya vipimo vilivyoandikwa katika Go, usafirishaji wa Prometheus, vichanganuzi vya kumbukumbu kama vile Logstash na Gollum, pamoja na hifadhidata kama vile InfluxDB au Elasticsearch. Kila moja ya huduma hizi huendesha kwenye chombo chake. Tunahitaji mfumo rahisi ili kuendelea kufanya kazi.

Tulianza na orodha ya mahitaji ya ochestration ya kontena:

• Kuendesha seti ya huduma kwenye mashine nyingi.
• Muhtasari wa huduma zinazoendeshwa.
• Viungo kati ya huduma.
• Anzisha upya kiotomatiki ikiwa huduma itapungua.
• Matengenezo ya miundombinu na timu ndogo.

Kwa kuongezea, mambo yafuatayo yatakuwa mazuri, lakini sio nyongeza zinazohitajika:

• Mashine za kuweka alama kulingana na uwezo wao (kwa mfano, mashine za kuweka alama na diski za haraka kwa huduma nzito za I/O).
• Uwezo wa kuendesha huduma kwa kujitegemea na orchestrator (kwa mfano, wakati wa maendeleo).
• Mahali pa kawaida pa kushiriki usanidi na siri.
• Mwisho wa vipimo na kumbukumbu.

Kwa nini Kubernetes sio sawa kwetu

Tulipokuwa tukiiga Kubernetes, tuligundua kuwa tulikuwa tunaongeza tabaka tata za mantiki ambazo tulizitegemea sana.

Kwa mfano, Kubernetes inasaidia usanidi wa huduma iliyojumuishwa kupitia ConfigMaps. Unaweza kuchanganyikiwa haraka, hasa wakati wa kuunganisha faili nyingi za usanidi au kuongeza huduma za ziada kwenye pod. Kubernetes (au Helm katika kesi hii) hukuruhusu kutekeleza kwa nguvu usanidi wa nje ili kutenganisha wasiwasi. Lakini hii inasababisha muunganisho mgumu, uliofichwa kati ya mradi wako na Kubernetes. Walakini, Helm na ConfigMaps ni chaguo za ziada, kwa hivyo sio lazima uzitumie. Unaweza kunakili tu usanidi kwenye picha ya Docker. Walakini, inajaribu kufuata njia hii na kuunda vifupisho visivyo vya lazima ambavyo unaweza kujuta baadaye.

Zaidi ya hayo, mfumo ikolojia wa Kubernetes unabadilika kwa kasi. Inachukua muda na nguvu nyingi kusasisha mbinu bora na zana za hivi punde. Kubectl, minikube, kubeadm, helm, tiller, kops, oc - orodha inaendelea na kuendelea. Sio zana hizi zote zinahitajika unapoanza, lakini hujui utahitaji, kwa hivyo unahitaji kufahamu kila kitu. Kwa sababu hii, mkondo wa kujifunza ni mwinuko kabisa.

Wakati wa kutumia Kubernetes

Katika kampuni yetu, watu wengi hutumia Kubernetes na wanafurahiya sana nayo. Matukio haya yanadhibitiwa na Google au Amazon, ambao wana nyenzo za kuvisaidia.

Kubernetes anakuja na vipengele vya kushangaza, ambayo hufanya ochestration ya kontena kwa kiwango kudhibitiwa zaidi:

• Kina usimamizi wa haki.
• Vidhibiti maalum ongeza mantiki kwenye nguzo. Hizi ni programu tu zinazozungumza na Kubernetes API.
• Kuongeza kasi kiotomatiki! Kubernetes inaweza kuongeza huduma inapohitajika kwa kutumia vipimo vya huduma na bila kuhitaji uingiliaji kati wa mtu mwenyewe.

Swali ni ikiwa unahitaji vipengele hivi vyote. Huwezi tu kutegemea vifupisho; itabidi kujua nini kinaendelea chini ya kofia.

Timu yetu hutoa huduma nyingi kwa mbali (kutokana na muunganisho wa karibu wa miundombinu kuu), kwa hivyo hatukutaka kuinua nguzo yetu wenyewe ya Kubernetes. Tulitaka tu kutoa huduma.

Betri hazijajumuishwa

Nomad ni 20% ya okestration ambayo hutoa 80% ya kile kinachohitajika. Inachofanya ni kudhibiti uwekaji. Nomad hutunza upelekaji, huwasha tena kontena endapo kutakuwa na makosa... na ndivyo hivyo.

Jambo zima la Nomad ni nini hufanya kiwango cha chini: hakuna usimamizi wa haki punjepunje au sera za mtandao zilizopanuliwa, hii imeundwa mahsusi. Vipengele hivi hutolewa nje au sio kabisa.

Nadhani Nomad amepata maelewano kamili kati ya urahisi wa utumiaji na matumizi. Ni nzuri kwa huduma ndogo, zinazojitegemea. Ikiwa unahitaji udhibiti zaidi, itabidi uwainue mwenyewe au utumie mbinu tofauti. Nomad ni tu orchestrator.

Jambo bora zaidi kuhusu Nomad ni kwamba ni rahisi badala. Kwa kweli hakuna uhusiano na muuzaji, kwani kazi zake zinaunganishwa kwa urahisi katika mfumo mwingine wowote unaosimamia huduma. Inaendesha tu kama binary ya kawaida kwenye kila mashine kwenye nguzo, ni hayo tu!

Mfumo ikolojia wa kuhamahama wa vijenzi vilivyounganishwa kwa urahisi

Nguvu halisi ya Nomad ni mfumo wake wa ikolojia. Inaunganishwa vizuri na zingine - za hiari kabisa - bidhaa kama vile Dhulumu (duka la thamani-muhimu) au Vault (usindikaji wa siri). Ndani ya faili ya Nomad kuna sehemu za kutoa data kutoka kwa huduma hizi:

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
}

Hapa tunasoma ufunguo service/geo-api/log-verbosity kutoka kwa Balozi na tunapofanya kazi tunaiweka wazi kwa mabadiliko ya mazingira LOG_LEVEL. Pia tunawasilisha ufunguo secret/geo-api-key kutoka Vault kama API_KEY. Rahisi lakini yenye nguvu!

Kwa sababu ya unyenyekevu wake, Nomad inaweza kupanuliwa kwa urahisi na huduma zingine kupitia API. Kwa mfano, vitambulisho vya kazi vinatumika. Tunatambulisha huduma zote kwa kutumia vipimo trv-metrics. Kwa njia hii Prometheus anaweza kupata huduma hizi kwa urahisi kupitia Balozi na kuangalia mara kwa mara sehemu ya mwisho /metrics kwa data mpya. Vile vile vinaweza kufanywa, kwa mfano, kwa magogo, kwa kutumia Loki.

Kuna mifano mingine mingi ya upanuzi:

• Endesha kazi ya Jenkins kwa kutumia ndoano, na Balozi hufuatilia utumaji upya wa kazi ya Nomad wakati usanidi wa huduma unabadilika.
• Ceph inaongeza mfumo wa faili uliosambazwa kwa Nomad.
• Fabio kwa kusawazisha mzigo.

Yote hii inaruhusu kuendeleza miundombinu kikaboni bila muunganisho maalum kwa muuzaji.

Onyo la haki

Hakuna mfumo kamili. Sipendekezi kuanzishwa mara moja vipengele vipya zaidi katika uzalishaji. Kwa kweli kuna mende na sifa zinazokosekana, lakini hiyo hiyo inatumika kwa Kubernetes.

Ikilinganishwa na Kubernetes, jamii ya Nomad sio kubwa hivyo. Kubernetes tayari ina takriban 75 na wachangiaji 000, wakati Nomad ina takriban 2000 na wachangiaji 14. Nomad atakuwa na wakati mgumu kuendana na kasi ya Kubernetes, lakini labda si lazima! Ni mfumo maalum zaidi, na jumuiya ndogo pia inamaanisha kuwa ombi lako la kuvuta lina uwezekano mkubwa wa kutambuliwa na kukubaliwa, ikilinganishwa na Kubernetes.

Muhtasari

Jambo la msingi: Usitumie Kubernetes kwa sababu tu kila mtu anaifanya. Tathmini mahitaji yako kwa uangalifu na uangalie ni chombo gani kina manufaa zaidi.

Ikiwa unapanga kupeleka tani ya huduma za homogeneous kwenye miundombinu ya kiasi kikubwa, basi Kubernetes ni chaguo nzuri. Jihadharini tu na ugumu ulioongezwa na gharama za uendeshaji. Baadhi ya gharama zinaweza kuepukwa kwa kutumia mazingira ya Kubernetes yanayosimamiwa kama vile Injini ya Google Kubernetes au Amazon EKS.

Ikiwa unatafuta tu okestra anayeaminika ambaye ni rahisi kudumisha na kupanuliwa, kwa nini usijaribu Nomad? Unaweza kushangaa jinsi hii itakupeleka.

Ikiwa Kubernetes inalinganishwa na gari, Nomad angekuwa skuta. Wakati mwingine unahitaji kitu kimoja na wakati mwingine unahitaji kingine. Wote wawili wana haki ya kuwepo.

Chanzo: mapenzi.com