Как да използвате силата на Kubernetes, за да оптимизирате разходите си за хостинг

През последните няколко години индустрията претърпя промяна към разработването на по-малки и по-фокусирани приложения.

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

И правилно е така.

Услугите с малки размери са:

  • по-бързо внедряване - защото ги създавате и пускате на по-малки парчета
  • по-лесно да се повтаря - тъй като добавянето на функции се случва независимо
  • еластична - цялостната услуга все още може да функционира, въпреки че един от компонентите не е наличен

По-малките услуги са отлични от гледна точка на продукта и развитието.

Но как тази културна промяна се отразява на инфраструктурата?

Управление на инфраструктура в мащаб

Оказва се, че нещата са доста прости, когато се занимавате с няколко оскъдни приложения.

Можете да ги преброите с ръцете си и имате достатъчно време да отделите за поддръжка и освобождаване.

В голяма организация управлението на стотици приложения е взискателно, но все пак изпълнимо. Имате няколко екипа, посветени на разработването, опаковането и пускането на приложения.

Развитието на услуги от по-малки компоненти, от друга страна, представлява различно предизвикателство.

Когато за всяко приложение можете да префабрикувате едни и същи приложения в колекция от четири компонента, имате поне четири пъти повече приложения за разработване, пакетиране и пускане.

Не е необичайно малка услуга да бъде направена от дузина компоненти, като приложение за предния край, бекенд API, сървър за оторизация, администраторско приложение и т.н.

В действителност, когато разработвате услуги, които взаимодействат помежду си, виждате експлозия на компоненти, разположени във вашата инфраструктура.

Става все по-трудно.

Вероятно губите парите си за изчисляване на ресурси

Повечето от услугите са внедрени във виртуални машини като Amazon EC2, Digital Ocean Droplets или Azure Virtual Machines.

Всяка виртуална машина се предлага с операционна система, която консумира част от паметта и ресурсите на процесора, разпределени за нея.

Когато създадете 1GB памет и 1 vCPU капчица в Digital Ocean, в крайна сметка използвате 700MB памет и 0.8 vCPU, след като премахнете режийните разходи на операционната система.

Или с други думи, за всяка пета виртуална машина режийните разходи добавят към пълна виртуална машина.

Вие плащате за пет, но можете да използвате само четири.

Не можете да избягате от него, дори ако сте на гол метал.

Все още трябва да стартирате услугите си от базова операционна система.

Добре е, че всеки трябва да работи с операционна система - казвате вие.

И си прав.

Въпреки това, парите, прахосани от операционни системи, са само върхът на айсберга.

Освен това вие губите много пари за използване на ресурсите

Вероятно сте разбрали, че когато разбивате услугите си на по-малки компоненти, всеки от тях идва с различни изисквания към ресурсите.

Някои компоненти като обработка на данни и приложения за извличане на данни са интензивни от процесора. Други, като сървъри за приложения в реално време, могат да използват повече памет от процесора.

Amazon Web Services и другите облачни доставчици наистина имат дълъг списък от изчислителни ресурси, които отговарят на всяка нужда: обща цел, оптимизиран процесор, оптимизирана памет, оптимизирана памет и графичен процесор.

Трябва да се стремите да използвате правилната виртуална машина за вашия компонент. В идеалния случай тя трябва да съответства на потреблението на памет и използването на процесора.

Работите ли върху критичен уеб компонент, написан на Java?

Може би трябва да използвате c5.4xlarge, оптимизиран за изчисляване на интензивни работни натоварвания.

Колкото по-близо отговаряте на изискванията, толкова по-добре използвате ресурсите си.

На практика това обаче е малко рядко.

Трябва ли да използвате c5.2xlarge или c5.4xlarge?

Има ли значение следващото ниво (8 vCPU и 16GB памет)?

Много по-лесно е да изберете няколко компютърни профила, които са достатъчно добри в 80% от случаите, и да ги използвате за всички компоненти.

Всъщност, какво лошо е да използвате предимно една и съща виртуална машина за всяко натоварване?

Нищо, ако се радвате да обвиете всеки компонент в 2 GB памет и vCPU изчислителен капацитет.

Дори ако вашият компонент може да работи само с 1 GB памет.

Да, бихте могли да оптимизирате в бъдеще.

Но нека бъдем честни: това е като смяна на гуми по време на шофиране.

Влагате много усилия в настройката на системата, само за да осъзнаете, че приложението се промени отново и трябва да започнете от нулата.

Така че в крайна сметка вземате единствения разумен избор: да изберете малък, среден и голям профил за виртуални машини и да ги използвате за всички натоварвания.

Знаете, че трябва да живеете със загуба на стотици мегабайти RAM и много CPU цикли.

Ако ви кара да се чувствате по-добре, има много компании, страдащи от подобни неефективности.

Някои използват едва 10% от разпределените ресурси.

Вие плащате $ 1000 в EC2 случаи в Amazon, вие всъщност използвате само $ 100 от него.

Това не звучи като най-добрият начин да изразходвате бюджета си.

Трябва да си върнете парите за ресурсите, които не използвате.

Но защо така или иначе тези изисквания са толкова различни ?!

При избора на подходящия инструмент прави повече вреда, отколкото полза

Когато разработчиците имат свободата да използват правилния инструмент за работата, те обикновено се разяждат.

Node.js за предния край, Spring Boot за бекенд API, Flask и Celery за обработката на фоновите задания, React.js за страната на клиента, вие го наречете.

Инфраструктурата се превръща в тематичен парк, стотици приложения работят на съвсем различни времена на изпълнение.

Наличието на подходяща технология за работата позволява по-голяма итерационна скорост, но обикновено идва с допълнителна тежест от управлението на още един език за програмиране.

Въпреки че можете да смекчите разпространението на инструменти и езици, на практика е по-сложно от това.

Две приложения, споделящи едно и също JVM време на изпълнение, може да разчитат на различен набор от зависимости и библиотеки.

Може би някой разчита на ImageMagick за преоразмеряване на изображенията.

Другият разчита на двоичен файл като PhantomJS или ZeroMQ, за да бъде на разположение в неговия път.

Трябва да пакетирате тези зависимости заедно с нейното приложение.

И така в крайна сметка се справяте с десетки конфигурации, които са еднакви, но различни по своя уникален начин.

Не бива да се отнасяте към инфраструктурата като замислена. Трябва да се грижите за зависимостите си и да ги пакетирате, докато разработвате приложението, още в началото.

В идеалния случай трябва да архивирате всички части, необходими за стартиране на вашия компонент като един пакет.

Повече няма да се губите в гонене на зависимости точно преди издаване.

Да, по-лесно казано, отколкото направено.

Или може би не.

Заемни контейнери от корабоплаването

Информационните технологии не са единствената индустрия със същия проблем.

Транспортирането на стоки с товари по целия свят е трудно, когато трябва да съхранявате вещи поотделно.

Представете си, че имате хиляди кутии с всякакви форми и размери, които да съхранявате в трюма. Трябва да обърнете допълнително внимание на това как опаковате артикулите, защото не искате да пропуснете нито един, когато дойде време за разтоварване.

Товарната индустрия излезе с решение: контейнери.

Товарната компания не превозва стоки; тя превозва контейнери.

Искате ли да превозите безопасно всичките си стоки? Поставете ги в контейнер. Когато контейнерът се разтовари, вие гарантирано разполагате с всичко там.

Можете да приложите същия принцип към вашите приложения.

Искате ли да разгърнете безопасно приложението си и цялата му зависимост?

Увийте ги в контейнер за Linux.

Контейнерът на Linux е подобен на товарен контейнер, но той капсулира всички файлове, двоични файлове и библиотеки, необходими за стартиране на вашия процес.

Това не ви ли звучи много като виртуални машини?

Виртуални машини на диета

Всъщност, ако присвивате и гледате отдалеч на виртуални машини, те приличат на контейнери.

Те капсулират приложението и неговите зависимости като контейнери.

Виртуалните машини обаче стартират бавно, обикновено по-големи и - както научихте - загуба на ресурси.

Всъщност трябва да заделите фиксиран брой процесор и памет, за да стартирате приложението си.

Те също трябва да подражават на хардуер и да се снабдят с допълнителния багаж на операционна система.

Linux контейнерите, от друга страна, са просто процеси, изпълнявани на вашия хост.

Всъщност, за една и съща операционна система и сървър, можете да имате десетки контейнери, работещи на този хост.

И въпреки че живеете на един и същ компютър, процесите, работещи в контейнери, не могат да се виждат.

Приложенията, работещи в контейнери, са изцяло изолирани и не могат да установят разликата между виртуална машина и контейнер.

Това е страхотна новина!

Linux контейнерите са като виртуални машини, но по-ефективни.

Но от какво са направени тези Linux контейнери?

Linux контейнерите са изолирани процеси с ползи

Магията на контейнерите идва от две функции в Linux ядрото: контролни групи и пространства от имена.

Контролните групи са удобен начин за ограничаване на процесора или паметта, които даден процес може да използва.

Като пример можете да кажете, че вашият компонент трябва да използва само 2 GB памет и едно от четирите ви ядра на процесора.

От друга страна, пространствата от имена отговарят за изолацията на процеса и ограничаването на това, което може да вижда.

Компонентът може да вижда само мрежовите пакети, които са пряко свързани с него. Той няма да може да види всички мрежови пакети, преминаващи през мрежовия адаптер. Контролните групи и пространствата от имена са примитиви на ниско ниво.

С времето разработчиците създадоха все повече слоеве за абстракции, за да улеснят контрола върху тези функции на ядрото.

Една от първите абстракции беше LXC, но истинската сделка беше Docker, която беше освободена през 2013 година.

Docker не само абстрахира горните функции на ядрото, но е приятно да се работи.

Изпълнението на Docker контейнер е толкова просто, колкото:

docker run 

И тъй като всички контейнери изпълняват стандартен интерфейс, можете да стартирате всеки друг контейнер със същата команда:

докер пусни mysql

И вие имате MySQL база данни.

Преносимостта на приложението и стандартен интерфейс за създаване и стартиране на процеси е това, което прави контейнерите толкова популярни.

Контейнерите са страхотни!

  • Спестете пари от работа на десетки операционни системи
  • Вие пакетирате приложения като преносими устройства
  • Имате разпространение на контейнери

Изглежда, че контейнерите не са решили всички проблеми в края на краищата.

Трябва ви начин за управление на контейнерите.

Управление на контейнери в мащаб

Когато имате стотици, ако не и хиляди контейнери, трябва да намерите начин да стартирате няколко контейнера на един и същ сървър. И трябва да планирате контейнерите да се разпространяват и на няколко сървъра.

Така че можете да разпределите натоварването в няколко възли и да предотвратите, че една грешка може да свали цялата услуга.

Проследяването на това, къде се разполага всеки контейнер във вашата инфраструктура, не изглежда като най-доброто използване на вашето време.

Може би има начин да го автоматизирате?

А какво ще стане, ако имате алгоритъм, който да решава къде да поставите и тези контейнери?

Може би би било толкова умно да се пакетират ефективно контейнери, така че да се увеличи максимално плътността на сървъра. Може би дори да запазите списък на разгърнатите контейнери и техния хост.

Оказва се, че някой е имал точно тази идея и е намерил решение.

Kubernetes, могъщият оркестров контейнер

Kubernetes първоначално е създаване на Google.

Google използва технология, подобна на контейнерите, и трябваше да намери ефективен начин за планиране на работните натоварвания.

Те не искаха да поддържат и ръчно актуализират дълъг списък от контейнери и сървъри. Затова решиха да напишат платформа, която да може автоматично да анализира използването на ресурси, да планира и разгръща контейнери.

Но това беше затворен източник.

Няколко Google решиха да пренапишат платформата като усилие с отворен код. А останалото е история.

И така, какво е Kubernetes?

Можете да мислите за Kubernetes като планировчик.

Kubernetes проверява вашата инфраструктура (гол метал или облак, публичен или частен) и измерва процесора и паметта за всеки компютър.

Когато поискате да разгърнете контейнер, Kubernetes идентифицира изискванията за памет за вашия контейнер и намира най-добрия сървър, който удовлетворява вашата заявка.

Вие не решавате къде се разполага приложението. Центърът за данни е абстрахиран далеч от вас.

С други думи, Kubernetes ще играе на Tetris с вашата инфраструктура.

Докер контейнерите са блоковете, сървърите са дъските, а Kubernetes е играчът.

Това, че Kubernetes ефективно опакова вашата инфраструктура, означава, че получавате повече компютри за парите си. Можете да направите много повече с много по-малко.

И общото ви използване на сметките трябва да намалее в резултат на това.

Спомняте ли си компаниите, които използват само 10% от разпределения си ресурс?

Е, Kubernetes просто спаси деня ви.

Но има още.

Kubernetes има убийствена функция, която обикновено се забравя или отхвърля.

Kubernetes като API слой над вашия център за данни

Всичко, което правите в Kubernetes, е едно API обаждане далеч от вас.

Трябва ли да разгърнете контейнер? Има REST крайна точка за това.

Може би искате да осигурите балансиращ товар? Не е проблем. Просто се обадете на този API.

Искате ли да осигурите място за съхранение? Моля, изпратете POST заявка до този URL адрес.

Всичко, което правите в Kubernetes, е да извиквате API.

И има много добри причини да се вълнуваме от това:

  • Можете да създавате скриптове и демони, които взаимодействат програмно с API
  • API е версиониран; когато надстроите клъстера, можете да продължите да използвате стария API и постепенно да мигрирате
  • Можете да инсталирате Kubernetes във всеки облачен доставчик или център за данни и можете да използвате същия API

Можете да мислите за Kubernetes като слой върху вашата инфраструктура.

И тъй като този слой е общ и може да бъде инсталиран навсякъде, винаги можете да го вземете със себе си.

Amazon Web Services е твърде скъпо?

Без проблем.

Можете да инсталирате Kubernetes в Google Cloud Platform и да премествате работните си натоварвания там.

Или може би можете да запазите и двете, защото стратегията за висока наличност винаги е полезна.

Но може би не ми вярвате

Прекалено хубаво е, за да е вярно, и продавам дим и огледала.

Нека ти покажа.

Спестяване на сметката ви в облака с Kubernetes

Netlify е платформа за изграждане, разполагане и управление на статични уебсайтове.

Той има собствен CI тръбопровод, така че всеки път, когато натиснете промяна в хранилище, вашият уебсайт се преустройва.

Netlify успя да мигрира към Kubernetes, удвои потребителската им база, но въпреки това запази разходите непроменени.

Това е страхотна новина!

Представете си, че спестявате 50% от сметката си в облачната платформа за Google!

Но Netlify не е единственият.

Qbox - компания, която се фокусира върху хоствано Elastic Search - успя отново да спести 50% на месец от AWS сметки!

В този процес те също отварят усилията си в многооблачните операции.

Ако все още не сте впечатлени, трябва да проверите пресата, направена от OpenAI.

OpenAI е изследователска компания с нестопанска цел, която се фокусира върху изкуствения интелект и машинното обучение. Те написаха алгоритъм за игра на много играч онлайн игра Dota, както всеки човешки играч.

Но те отидоха на допълнителната стъпка и обучиха екип от машини, които да играят заедно.

И използваха Kubernetes, за да мащабират своя модел на машинно обучение в облака.

Чудите ли се подробностите на клъстера им?

128000 vCPU

Това е около 16000 MacBook плюсове.

256 Nvidia Tesla P100

Това е 1600-битова производителност с плаваща запетая от Teraflops.

Същото, както бихте пускали 525 PlayStation 4.

Можете ли да познаете цената на час?

Не?

Само $ 1280 / час за 128000 vCPU и $ 400 за 256 Nvidia P100.

Това не е много, като се има предвид, че спечелването на Dota турнири може да ви обедини награди от порядъка на милиони долари.

И така, какво чакате?

Пригответе се да приемете Kubernetes и спестете от сметката си в облака!

Заключителни бележки

Кубернетите и контейнерите са тук, за да останат.

С подкрепата на компании като Google, Microsoft, Red Hat, Pivotal, Oracle, IBM и много други е трудно да се повярва, че това няма да се хване.

Много компании се насочват към Kubernetes и се присъединяват към революцията.

Не само стартиращите фирми и МСП, но големите корпорации като банки, финансови институции и застрахователни компании залагат на контейнери и Kubernetes да бъдат бъдещето.

Дори компаниите инвестираха в Интернет на нещата и вградени системи.

Все още са ранни дни и общността има време да узрее, но трябва да следите внимателно иновациите в това пространство.

Това е всичко приятели!

Много благодаря на Анди Грифитс, Джон Топли и Уолтър Миани за четенето на проект на тази публикация и предлагането на някои безценни предложения.

Ако ви хареса тази статия, може да ви се стори интересно четиво:

  • Започнете с Docker и Kubernetes в Windows 10, където ще си изцапате ръцете и ще инсталирате Docker и Kubernetes във вашата Windows среда.
  • 3 прости трика за по-малки изображения на Docker. Изображенията на Docker не трябва да са големи. Научете как да поставите вашите изображения на Докер на диета!

Станете експерт по разгръщането и мащабирането на приложения в Kubernetes

Започнете с нашите практически курсове и научете как да овладеете мащабируемостта в облака.

Научете как да:

  • Работете с най-натоварените уебсайтове за трафик, без да нарушавате потта
  • Мащабирайте заданията си на хиляди сървъри и намалете времето за чакане от дни на минути
  • Насладете се на спокойствието, като знаете, че вашите приложения са много достъпни с мулти-облачна настройка
  • Спестете тона пари в сметката си в облака, като използвате само необходимите ресурси
  • Допълнете тръбопровода за доставка и внедрете приложение денонощно

Станете експерт в Kubernetes →

Статията първоначално е публикувана на сайта learnk8s.io