Можеби нема да ви требаат Kubernetes

Можеби нема да ви требаат Kubernetes
Девојка на скутер. Илустрација фрипик, логото на Номад од ХашиКорп

Кубернетес е горила тешка 300 килограми на контејнерска оркестрација. Работи во некои од најголемите контејнерски системи во светот, но е скап.

Особено скапо за помалите тимови, што ќе бара многу време за поддршка и стрмна крива на учење. Ова е премногу трошоци за нашиот тим од четири лица. Така почнавме да бараме алтернативи - и се заљубивме Номад.

Што сакаш

Нашиот тим поддржува голем број заеднички услуги за следење и анализа на перформансите: крајни точки на API за метрика напишана во Go, извоз на Prometheus, анализатори на дневници како што се Logstash и Голум, како и бази на податоци како што се InfluxDB или Elasticsearch. Секоја од овие услуги работи во свој контејнер. Ни треба едноставен систем за сето тоа да работи.

Започнавме со список на барања за оркестрација на контејнери:

  • Водење сет на услуги на многу машини.
  • Преглед на водење на услуги.
  • Врски помеѓу услугите.
  • Автоматско рестартирање ако услугата се прекине.
  • Одржување на инфраструктурата од мал тим.

Дополнително, следните работи ќе бидат убави, но не и потребни додатоци:

  • Машини за означување врз основа на нивните можности (на пример, машини за означување со брзи дискови за тешки I/O услуги).
  • Способност да се водат услуги независно од оркестраторот (на пример, за време на развојот).
  • Заедничко место за споделување конфигурации и тајни.
  • Крајна точка за метрика и дневници.

Зошто Kubernetes не е во право за нас

Додека правевме прототип со Kubernetes, забележавме дека додаваме сè покомплексни слоеви на логика на кои многу се потпиравме.

Како пример, Kubernetes поддржува вградени конфигурации на услуги преку ConfigMaps. Може брзо да се збуните, особено кога спојувате повеќе датотеки за конфигурација или додавате дополнителни услуги во подлогата. Кубернетис (или кормилото во овој случај) ви овозможува динамично да ги имплементирате надворешните конфигурации за да ги одделите грижите. Но, ова резултира со тесна, скриена спојка помеѓу вашиот проект и Кубернетес. Сепак, Helm и ConfigMaps се дополнителни опции, така што не мора да ги користите. Можете едноставно да ја копирате конфигурацијата во сликата на Docker. Сепак, примамливо е да одите по овој пат и да изградите непотребни апстракции за кои подоцна може да зажалите.

Дополнително, екосистемот Кубернетес брзо се развива. Потребно е многу време и енергија за да останете во тек со најдобрите практики и најновите алатки. Kubectl, minikube, kubeadm, helm, tiller, kops, oc - списокот продолжува и продолжува. Не се потребни сите овие алатки кога започнувате, но не знаете што ќе ви треба, па затоа треба да бидете свесни за сè. Поради ова, кривата на учење е прилично стрмна.

Кога да се користи Kubernetes

Во нашата компанија, многу луѓе користат Kubernetes и се сосема задоволни со тоа. Овие примероци се управувани од Google или Amazon, кои имаат ресурси да ги поддржат.

Kubernetes доаѓа со неверојатни карактеристики, кои ја прават оркестрацијата на контејнери на размер поуправлива:

Прашањето е дали навистина ви се потребни сите овие карактеристики. Не можете само да се потпрете на апстракции; ќе мора да дознаете што се случува под хаубата.

Нашиот тим ги обезбедува повеќето услуги од далечина (поради блиската поврзаност со главната инфраструктура), така што не сакавме да го подигнеме нашиот сопствен кластер Кубернетес. Сакавме само да даваме услуги.

Батериите не се вклучени

Номад е 20% од оркестрацијата која обезбедува 80% од она што е потребно. Сè што прави е да управува со распоредувањата. Номад се грижи за распоредувањата, ги рестартира контејнерите во случај на грешки... и тоа е тоа.

Целата поента на Номад е што прави минимум: нема грануларно управување со правата или проширени мрежни политики, ова е специјално дизајнирано. Овие компоненти се обезбедени однадвор или воопшто не.

Мислам дека Nomad го најде совршениот компромис помеѓу леснотијата на користење и корисноста. Добро е за мали, независни услуги. Ако ви треба поголема контрола, ќе мора сами да ги подигнете или да користите поинаков пристап. Номад е само оркестратор.

Најдоброто нешто за Номад е тоа што е лесно замени. Практично нема врска со продавачот, бидејќи неговите функции лесно се интегрираат во кој било друг систем што управува со услуги. Само работи како обичен бинарен на секоја машина во кластерот, тоа е сè!

Номадски екосистем од лабаво поврзани компоненти

Вистинската сила на Номад е неговиот екосистем. Многу добро се интегрира со други - целосно опционални - производи како што се Конзул (продавница со клуч-вредност) или Свод (обработка на тајни). Внатре во датотеката Nomad има делови за извлекување податоци од овие услуги:

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
}

Тука го читаме клучот service/geo-api/log-verbosity од Конзул и додека работиме го изложуваме на променлива на околината LOG_LEVEL. Го презентираме и клучот secret/geo-api-key од Трезорот како API_KEY. Едноставно, но моќно!

Поради својата едноставност, Номад лесно може да се прошири со други услуги преку API. На пример, поддржани се ознаки за задачи. Ги означуваме сите услуги со метрика trv-metrics. На овој начин Прометеј лесно може да ги најде овие услуги преку конзулот и периодично да ја проверува крајната точка /metrics за нови податоци. Истото може да се направи, на пример, за логови, користејќи Локи.

Постојат многу други примери за растегливост:

  • Извршете ја работата на Џенкинс користејќи кука, а конзулот го следи прераспоредувањето на работата Номад кога ќе се промени конфигурацијата на услугата.
  • Ceph додава дистрибуиран датотечен систем на Nomad.
  • fabio за балансирање на оптоварување.

Сето ова дозволува органски развиваат инфраструктура без некоја посебна врска со продавачот.

Фер предупредување

Ниту еден систем не е совршен. Не препорачувам веднаш да ги воведете најновите карактеристики во производството. Се разбира, има грешки и функции што недостасуваат, но истото важи и за Kubernetes.

Во споредба со Кубернетес, заедницата Номад не е толку голема. Kubernetes веќе има околу 75 обврзници и 000 придонесувачи, додека Nomad има околу 2000 обврзувања и 14 придонесувачи. На Номад ќе му биде тешко да ја следи брзината на Кубернетес, но можеби и не мора! Тоа е поспецијализиран систем, а помалата заедница исто така значи дека вашето барање за повлекување е поверојатно да биде забележано и прифатено, во споредба со Kubernetes.

Краток преглед

Крајна линија: Не користете Kubernetes само затоа што сите други го прават тоа. Внимателно проценете ги вашите барања и проверете која алатка е покорисна.

Ако планирате да распоредите еден тон хомогени услуги на голема инфраструктура, тогаш Kubernetes е добра опција. Само бидете свесни за дополнителната сложеност и оперативните трошоци. Некои трошоци може да се избегнат со користење на управувана околина на Kubernetes како на пр Google Kubernetes Engine или Амазон ЕКС.

Ако само барате сигурен оркестратор кој е лесен за одржување и проширување, зошто да не го пробате Nomad? Можеби ќе се изненадите колку далеку ќе ве однесе ова.

Ако Кубернетес се спореди со автомобил, Номад би бил скутер. Некогаш ти треба едно, а некогаш друго. И двајцата имаат право да постојат.

Извор: www.habr.com

Додадете коментар