Когато получихме задачата да направим цялостен одит на Kubernetes за наш клиент, за първи път се сблъскахме със сценарий, в който Kubernetes беше изцяло on-prem, на физически машини в клъстери, и очаква продукция, т.е. финалната зелена светлина. За да бъде още по-интересно, клиентът беше мобилен виртуален оператор в Германия. Телефония и Kubernetes определено е нещо, което не се среща всеки ден.
Изискванията на клиента изглеждаха прости. Щяхме да получим read-only достъп до dev клъстера, да направим детайлен списък с описание на функционирането, за да се уверим, че разбираме как работи тяхната система и преценим дали са избрани подходящите решения, а ако не са – да предложим алтернативни.
Звучеше лесно. Щеше да отнеме много време, но въпреки това – лесно.
Така мислехме.
И сгрешихме.
Екипът ни е свикнал с облака – с особеностите му и с предимствата, които предоставя. Леко се изненадахме, когато (съвсем очаквано) открихме, че някои ресурси не са подходящи за облак. Двамата колеги, които работеха по проекта, имаха общо около 40 години IT опит, който датира от епохата преди облаците. Бързо разбрахме, че трябва да се върнем към old school системите и стария начин на мислене.
Лесно получихме достъп до dev клъстера и ни увериха, че dev, staging и бъдещата продукция са идентични, с изключение на разликите, които ще ни бъдат представени навреме. Самият клъстер следваше философията, че за всеки best practice сегмент има отделно решение. Поради това в Kubernetes бяха инсталирани много компоненти, тъй като всеки от тях имаше своята роля.
Първото, което попитахме, беше дали наистина всички тези компоненти бяха необходими.
Полученият отговор се основаваше на типичното мислене на програмистите: всичко се наблюдава като отделна цялост и всяко изискване, което трябва да се изпълни, представлява един компонент. Не може да се каже, че това е грешен начин на мислене.
Ops подходът предполага изграждане на скелет, инсталиране на минимума и използване на всичко, което може да се използва. За всяко изискване на нашия клиент обаче трябваше да има отделно, подходящо решение. Нямаше как да оспорим този подход, затова се наложи да се адаптираме.
Като начало трябваше да разберем какво и как работи нашият клиент работи и начина на функциониране на неговото приложение. Макар че получихме app диаграма с обяснения, трябваше ръчно да преминем през цялата вътрешна комуникация на компонентите, за да разберем всички отношения в рамките Kubernetesa и самия стак (stack).
Тъй като приложението служи за комуникация и обмен на информация, беше ясно, че всичко е напълно сигурно и протича в рамките на клъстера. С оглед на това, че read-only подходът позволява само преглед на ресурсите, но не и установяване на сесия към тях, разчитахме на анализа на ресурсите и конфигурация на файловете, които представляват config maps. Имената на сървисите, ingress-i i endpoints са само някои от аспектите, които чрез конфигурацията ни разкриха кой сървис с какво комуникира. При анализа открихме, че екипите бяха избрали доста иновативни решения, като всички бяха от екосистемата FOSS, което е изключително похвално.
Предизвикателство № 1: HA storage (висока наличност на съхранение на данни)
Едно от предизвикателствата беше решението на клиента да използва локални дискове на сървъри чрез local path доставчик. Много е трудно да се използва storage по този начин, а освен това да се постигне и висока наличност. Клиентът беше изградил GlusterFS, което не е най-доброто решение, тъй като Kubernetes не го разпознава и доставените обеми не могат да функционират правилно в смисъла на backup and recovery.
Справихме се с това, като предложихме да се откажем от GlusterFS и да преминем към комбинацията CEPH + Rook. CEPH като дистрибутирана система може да въведе широка палитра хранилища (storage), които Rook да управлява. Предложението ни включваше хранилището (storage) изцяло да премине на отделен сървър в рамките на дейта центъра, който да прави offsite beckap, с което адресирахме предизвикателството на DFS.
Предизвикателство № 2: Конфигурацията
Второто предизвикателство беше да се осигури контрол на процесите в рамките на Kubernetes, за може автоматизацията на процесите непрекъснато да следва правилата, които не бива да се нарушават. Избраното от клиента решение беше комбинация от инструментите Falco и Kyverno. Всеки от тях беше конфигуриран само до демо правилата, което е приемливо, но проблемно, тъй като тези решения са предвидени да работят с въведени настройки. Трудно е да се конфигурират в dev клъстер, който не е изцяло настроен. Беше ясно, че dev средата се различава от продуктовата. Предизвикателство за нас беше да въведем 2 политики за управление и предложихме два комплекта функциониращи заедно политики.
Предизвикателство № 3: Мониторингът
При анализа открихме проблем при дистрибутирания мониторинг, върху който би повлияло падане на някой node. По-конкретно: клиентът използва master-worker setup, в който всяка среда има еднакъв брой workers и nodеs. Мониторингът имаше същия проблем като хранилището (storage). Какво правим при неминуем отказ на bare metal сървъра или при изключване на някой node заради поддръжка?
Дилемата беше къде да сложим мониторинга. В тази фаза на проекта клиентът не беше склонен да премести мониторинга в клъстерния сървър. Избраното решение беше стандартен Prometheus stack, който е създаден да бъде дистрибутиран. Разбира се, има федерация, но това не решава проблема. След дискусия с клиента предложихме да се използва Thanos – дистрибутиран overlay над Prometheus, позволяващ наличието на независими инстанции без значение къде се намират.
Решението ни разчиташе на използването на предложения от нас DFS и предполагаше storage layer да остане абстрактен за цялата система и промените на нивото на същия да нямат никакви последствия за постоянния прилив на данни от мониторинга. Thanos беше дефакто решение за цялото приложение и трите среди в момента, когато клиентът реши да премести мониторинг стака извън Kubernetes сървъра.
Предизвикателство № 4: Бекъп решение
Клиентът се опитваше да използва Velero за бекъп решение. Това е зрял бекъп проект, който позволява бекъп на обеми в Kubernetes, но не това е основното му предназначение и замисъл.
Предложението ни приличаше на подхода на разработчиците на клиента. Velero наистина е бекъп решение, но първоначално замислено да извършва цялостен бекъп на Kubernetes клъстера като система за оркестрация на контейнерите. Kubernetes се състои от редица компоненти и не е налична интегрирана система за бекъп, позволяваща да се направи restore на клъстер, който е безвъзвратно повреден. Velero решава този проблем като скрива виталните конфигурации на преместена и сигурна бекъп локация по избор. В нашия случай това беше ползваното от клиента обектно хранилище, което се намираше в същия дейта център.
Предизвикателство № 5: Бекъп на обемите
Към бекъп предизвикателствата спада и бекъпът на обемите. Тук на помощ идва студио Kanister – проект с отворен код, който позволява да се дефинира API в рамките на Kubernetes под формата на ресурс, който се извиква и прави бекъп по начина, от който се нуждае клиентът. Kanister се предлага с дефиниции за бекъп на различни видове бази данни SQL, NoSQL, GraphQL, timeseries и др. Бекъп на свободното хранилище (storage) се дефинира като job, точно както и restore.
Да се работи с традиционни технологии в съвременната епоха е голямо предизвикателство. Облако-центричната IT сцена променя всички, но винаги е добро упражнение да се върнеш към корените и да мислиш ръчно, компонент по компонент. Точно тук виждаме как като Ops продължаваме да се стиковаме с разработчиците и подходът им един компонент да решава един проблем на практика децентрализира процесите и прави така, че система, която функционира (ненужно) стабилно, всъщност може да работи изключително добре и да е много устойчива при бедствия.
По време на проекта открихме нови инструменти, които могат да са полезни в различни ситуации , напр. Kanister, Reflector, Karpenter и Kyverno.
Научихме и че, не всяко дистрибутирано решение може да бъде дистрибутирано във всяка ситуация. Нещо трябва да се създаде целево за on-prem ситуации, иначе се държи като обикновен съюз с ресурси, които зависят от това кога и как са добавени. Такъв набор от ресурси не е устойчив, а поради това не е и особено ефективен.
Свържете се с нас на business.bg@mainstream.bg или попълнете нашата контактна форма.
Открийте как да извършите преглед на средата на Kubernetes, който надхвърля основните контролни списъци. Идентифицирайте рисковете за сигурността, оптимизирайте производителността и приоритизирайте корекциите въз основа на действителното въздействие.
Партньорството между Mainstream и HC Center представлява синергия от иновативни облачни решения и опит в дигиталната трансформация, предоставяйки модерни услуги за ускоряване на цифровизацията в Югоизточна Европа.
Изкуственият интелект е във фокуса на компаниите, заедно с използването на облачни технологии. Какви възможности предлага симбиозата между AI и облака и как да ги използвате най-добре?
Mainstream е найголемият доставчик на иновативни облачни решения и управлявани хостинг услуги с мрежа от 10+ центъра за данни в Югоизточна Европа.
Mainstream 2012-2025 Всички права запазени.
HC Center и Mainstream официално обединиха сили
