В края на май се проведе онлайн мийтап на тема . Говорихме за контейнери, Kubernetes и оркестрация като цяло, за критерии за избор на инфраструктура и много други. Участниците споделиха примери от собствената си практика.
Участници:
- Евгений Потапов, CEO на „ITSumma“. Повече от половината от клиентите му или вече преминават, или искат да преминат на Kubernetes.
- Дмитрий Столяров, CTO на „Флант“. Разполага с над 10 години опит в работа с контейнерни системи.
- Денис Ремчуков (aka Eric Oldmann), COO на argotech.io, бивш-РАО ЕЭС. Обеща да разкаже за примери в „кървавия“.enterprise.
- Андрей Федоровски, CTO на „News360.com“След придобиването на компанията от друг играч, отговаря за редица проекти в областта на ML и AI и за инфраструктурата.
- Иван Круглов, системен инженер, бивш-Booking.com.Този човек, който с ръцете си е направил много с Kubernetes.
Теми:
- Идеи на участниците за контейнери и оркестрация (Docker, Kubernetes и други); какво са пробвали на практика или анализирали.
- Пример: В компанията се изгражда план за развитие на инфраструктурата за години напред. Как се взема решение да се построи (или премести текущата) инфраструктура на контейнери и Kubernetes или не?
- Проблеми в света на cloud-native, какво ни липсва; нека пофантазираме какво ще бъде утре.
Създаде се интересна дискусия, мненията на участниците се оказаха толкова различни и предизвикаха толкова коментари, че искам да ги споделя с вас. Има , а по-долу – резюме от дискусията.
Kubernetes вече е стандарт или е чудесен маркетинг?
„Ние пристигнахме при него (Kubernetes. — Ред.) когато почти никой не знаеше за него. Пристигнахме при него, когато го нямаше. Искахме го преди това“ — Дмитрий Столяров
Снимка от Reddit.com
Преди 5-10 години съществуваше огромно количество инструменти и нямаше единен стандарт. На всеки шест месеца се появяваше нов продукт, а понякога и не един. Първо Vagrant, след това Salt, Chef, Puppet,… „И ти на всеки шест месеца преработваш инфраструктурата си. Имаш пет администратора, които постоянно се занимават с преписване на конфигурации“ — припомня Андрей Федоровски. Той смята, че Docker и Kubernetes „потиснаха“ останалите. Docker стана стандарт през последните пет години, Kubernetes — през последните две. И това е добре за индустрията..
Дмитрий Столяров и неговият екип обожават Кубер. Те желаеха такъв инструмент преди да се появи и се запознаха с него, когато все още никой не знаеше за него. В момента, поради удобство, те не приемат клиенти, ако разбират, че няма да внедрят Kubernetes. Според Дмитрий, компанията има „множество огромни успешни истории за трансформация на ужасяващо наследство“.
Kubernetes не е само контейнерна оркестрация, а система за управление на конфигурацията с развит API, мрежови компоненти, L3 балансиране и Ingress контролери, която позволява относително лесно управление на ресурсите, мащабиране и абстрахиране от долните слоеве на инфраструктурата.
За съжаление, в нашия живот всичко трябва да се плаща. И този данък е голям, особено когато става въпрос за преминаване на компаниите с развита инфраструктура към Kubernetes, смята Иван Круглов. Той свободно може да работи както с традиционна инфраструктура, така и с Кубер. Важно е да се разберат особеностите на компанията и пазара. Но, например, за Евгений Потапов, който би обобщил Kubernetes до всякакъв инструмент за оркестрация на контейнери, такъв въпрос не стои.
Евгений направи аналогия с ситуацията през 90-те години, когато се появи обектно-ориентираното програмиране като начин за програмиране на сложни приложения. В този момент дебатите не спираха и се появяваха нови инструменти, подкрепящи ООП. След това се появиха микросервизите като начин да се избегне монолитната концепция. Това, от своя страна, доведе до появата на контейнери и инструменти за управление на тях. „Мисля, че скоро ще стигнем до времето, когато не ще има въпрос дали да се пише малко приложение микросервисно, то ще се пише по подразбиране като микросервис“, смята той. Подобно, Docker и Kubernetes с времето ще станат стандартно решение без необходимост от избор.
Проблемата с базите е в stateless
Снимка от
В наше време може да се намерят много рецепти за стартиране на бази данни в Kubernetes. Дори как да се отдели част, работеща с диск I/O от, условно казано, частта на приложението на базата. Може ли бъдещето на базите данни да се променя така, че да се доставят в кутия, където едната част ще се управлява чрез Docker и Kubernetes, а в другата част на инфраструктурата, чрез отделен софтуер, ще се предоставя частта за съхранение? Ще се променят ли базите като продукт?
Това описание прилича на управление на опашки, но изискванията за надеждност и синхронност на информацията в традиционните бази данни са значително по-високи, смята Андрей. Показателят за уцеленост на кеша в нормалните бази е около 99 %. Ако worker се провали, стартира се нов и кешът се "разгрява" от нула. Докато кешът не е разгрят, worker работи бавно, което означава, че не може да понесе потребителска натовареност. Докато няма потребителска натовареност, кешът не се разгрява. Това е замкнат цикъл.
Дмитрий е абсолютно несъгласен — кворумите и шардировката решават проблема. Но Андрей настоява, че решението не е подходящо за всички. В някои ситуации кворумът може да е подходящ, но той създава допълнително натоварване на мрежата. Базата NoSQL не е подходяща във всички случаи.
Участниците в митинга се разделиха на два лагера.
Денис и Андрей твърдят, че всичко, което записва на диск — бази и други, — в текущата екосистема на Кубера е невъзможно да се направи. Невъзможно е да се запази целостта и консистентността на продуктивните данни в Kubernetes. Това е фундаментална характеристика. Решение: хибридна инфраструктура.
Даже съвременни cloud native бази данни, като MongoDB и Cassandra, или системи за съобщения, като Kafka или RabbitMQ, изискват постоянни хранилища извън Kubernetes.
Евгений възразява: „Базите в Кубера са травма, свързана с Русия, или около предприемаческа, свързана с това, че в Русия няма Cloud Adoption“. Малките или средни компании на Запад са в Cloud. Базите Amazon RDS са по-лесни за използване, отколкото самостоятелно да се занимавате с Kubernetes. В Русия използват Кубер „on-premise“ и пренасят в него бази, когато се опитват да се избавят от зоопарка.
Дмитрий също не се съгласи с твърдението, че не могат да се държат никакви бази в Kubernetes: „База база не е равна. И ако опитате да вкарате гигантска релационна база — тогава определено не. Ако сложите нещо малко и cloud native, което е морално готово за полуживот, всичко ще бъде наред.“ Дмитрий спомена също, че инструментите за управление на бази не са готови нито за Docker, нито за Kuber, затова възникват големи трудности.
Иван е убеден, че дори да абстрахираме от понятието stateful и stateless, екосистемата на корпоративните решения в Kubernetes все още не е готова. С Kubernetes е трудно да се съобразят изискванията на законодателните и регулаторните органи. Например, невъзможно е да се създаде решение за предоставяне на идентичност, при което се изискват строги гаранции за идентификация на сървъра, включително хардуера, който е внедрен в сървърите. Тази сфера се развива, но засега решение липсва.
Участниците не успяха да се споразумеят, така че в тази част заключения не следват. Вместо това ще приведем няколко практически примера.
Кейс 1. Киберсигурност на „мегарегулатора“ с бази извън Kubernetes
В случай на развита система за киберсигурност, използването на контейнери и оркестрация позволява да се защитите от атаки и нахлувания. Например, в един мегарегулатор Денис и неговият екип реализираха свързването на оркестратор с обучен SIEM-сервис, който анализира логовете в реално време и определя процеса на атака, хакване или срив. В случай на атака, опити за поставяне на нещо или при нахлуване на ransomware, той чрез оркестратора стартира контейнери с приложения по-бързо, отколкото те бъдат заразени, или по-бързо, отколкото зложелателят ги атакува.
Кейс 2. Частичен преход на бази данни на Booking.com в Kubernetes
В Booking.com основната база данни е MySQL с асинхронна репликация — има master и цяла йерархия на slave-ове. В момента на напускането на Иван от компанията е стартиран проект за преместване на slave-овете, които могат да бъдат „изключени“ с определени загуби.
Освен основната база има инсталация на Cassandra с ръчно написана оркестрация, която е била разработена преди Kubernetes да стане основен. Проблеми в тази насока няма, но тя е с persistent на локални SSD. Отдалечени хранилища, дори в рамките на един и същи дата център, не се използват поради проблеми с висока латентност.
Третият клас бази данни е търсачката на Booking.com, в която всяка нода на услугата е база данни. Опитите за прехвърляне на търсачката в Kubernetes не успяха, тъй като всяка нода е с 60-80 Гб локално хранилище, което е трудно да се „вдигне“ и „разгърне“.
В крайна сметка търсачката не бе преместена в Kubernetes и Иван не смята, че ще има нови опити в близко бъдеще. Базата MySQL бе преместена наполовина: само slave-овете, които не е страшно да се „изключат“. Cassandra „се утвърди“ отлично.
Изборът на инфраструктура като задача без общо решение
Снимка от
Да приемем, че имаме нова компания или компания, в която част от инфраструктурата е изградена по-старомоден начин. Там изграждат план за развитие на инфраструктурата за години. Как се взема решение да се изгражда инфраструктура на контейнери и Kubernetes или не?
Компаниите, които се борят за наносекунди, са изключени от дискусията. Здравият консерватизъм се изплаща от гледна точка на надеждността, но все пак, има компании, които трябва да разгледат нови подходи.
Иван: „Сега бих стартирал компания в облака, просто защото е по-бързо“, макар че не е непременно по-евтино. С развитието на рисковия капитал стартиращите компании нямат големи проблеми с парите и основната задача е да завоюват пазара.
Иван смята, че развитието на текущата инфраструктура е критерий за избор. Ако в миналото са направени сериозни инвестиции и то работи, няма смисъл да се преработва. Обаче, ако инфраструктурата не е развита и има проблеми с инструментите, сигурността и мониторинга, тогава има смисъл да се разгледа разпределената инфраструктура.
Данъците трябва да се платят в какъвто и да е случай, и Иван би платил такъв, който в бъдеще би му позволил да плати по-малко. „Защото просто заради факта, че пътувам с влак, който се движи от други, ще стигна много по-далеч, отколкото ако се кача в друг влак, в който трябва сам да складам гориво.“ — казва Иван. Когато компанията е нова и изискванията към латентността са десетки милисекунди, Иван би се насочил към „операторите“, в които днес „обгръщат“ класическите бази данни. Те изграждат репликационна верига, която сама превключва при отказ и т.н...
За малка компания с няколко сървъра в Kubernetes няма смисъл, — твърди Андрей. Но ако тя планира да израсне до стотици сървъри и повече, автоматизация и система за управление на ресурсите са необходими. 90 % от случаите оправдават разходите. Освен това, независимо от нивото на натоварване и ресурсите. На всички, от стартъпите до големите компании с милионна аудитория, им има смисъл постепенно да се насочват към продукти за оркестрация на контейнери. „Да, това е наистина бъдещето“, — е убеден Андрей.
Денис очерта два основни критерия — скалируемост и устойчивост на работа. Той ще избере инструментите, които най-добре подхождат за тази задача. «Това може да бъде събрано на коляно устройство, и на него Nutanix Community Edition. Може да бъде втора линия под формата на приложение на Kuber с база данни на бекенда, която се репликира и има зададени параметри RTO и RPO» (време/точки за възстановяване — пример).
Евгений обозначи възможен проблем с кадри. В момента на пазара няма много висококласни специалисти, разбиращи „в кишките“. Наистина, ако избраната технология е стара, трудно е да се наеме някой, освен немлади скучаещи и уморени от живота хора. Въпреки че други участници считат, че това е въпрос на подготовка на кадри.
Ако поставим въпроса за избора: да стартираме малка компания в Public Cloud с бази в Amazon RDS или „on premise“ с бази в Kubernetes, то въпреки някои недостатъци, изборът на участниците стана Amazon RDS.
Тъй като повечето от слушателите на митапа не са от „кървавия“ ентерпрайз, то разпределените решения са нещо, към което трябва да се стремим. Системите за съхранение на данни трябва да бъдат разпределени, надеждни и да създават latencies, измервани в единици милисекунди, максимум десетки, — резюмира Андрей.
Оценка на използването на Kubernetes
Слушателят Антон Жбанков зададе въпрос-паст за апологетите на Kubernetes: как избираха и провеждаха техническо-икономическо обоснование? Защо Kubernetes, а не виртуални машини, например?
Снимка от
На него отговориха Дмитрий и Иван. В двата случая чрез метод на проби и грешки бе направена последователност от решения, в резултат на което и двамата участници стигнаха до Kubernetes. Сега бизнесът започва самостоятелно да разработва софтуер, който има смисъл да бъде пренесен в Кубер. Става въпрос не за класически трети системи, тип 1С. Kubernetes помага, когато на разработчиците е необходимо бързо да правят релизи, при безостановочно Continuous Improvement.
Екипът на Андрей пробва да направи мащабируем клъстер на основата на виртуални машини. Нодовете падали като домино, което понякога довеждаше до падане на клъстера. «Теоретично може да бъде довършено и поддържано ръчно, но е изморително. И ако на пазара има решение, което позволява работа от кутия, то ние с удоволствие се стремим към него. И ние в крайна сметка преминахме на него.», — разказва Андрей.
Съществуват стандарти за подобен анализ и изчисление, но никой не може да каже колко верни са те на реален хардуер в експлоатация. За изчисленията е важно да се разбира във всеки инструмент и екосистема, но това е невъзможно.
Какво ни очаква
Снимка от
Когато технологиите напредват, се появяват все повече разрознени парчета, а след това настъпва фазов преход, възниква вендор, който е убил достатъчно «пари», за да се съберат всички парчета в единен инструмент.
Не ви ли се струва, че ще дойде момент, в който ще се появи инструмент, какъвто стана Ubuntu за света на Linux? Възможно е единният инструмент за контейнеризация и оркестрация да включва и Кубер. С него ще стане лесно да се изграждат on-premise облаци.
Отговорът даде Иван: «Google в момента строи Anthos — това е техният пакетен артикул, който разгърна облака и включва Kuber, Service Mesh, мониторинг — всичко необходимо за микросервизи в „on-premise“. Ние почти сме в бъдещето.»
Денис също спомена Nutanix и VMWare с продукта vRealize Suite, които могат да се справят с подобна задача без контейнеризация.
Дмитрий сподели мнението, че намаляването на «болката» и намаляването на данъка са двете направления, където можем да очакваме подобрения.
В заключение на дискусията, ще подчертаем следните проблеми на съвременната инфраструктура
- Малко преди трима участници обозначиха проблема със stateful.
- Различни видове проблеми с поддръжката на сигурността, включително вероятността в Docker да се окажат няколко версии на Python, application-сървъри и компоненти.
Прерасход, за който е по-добре да се направи отделен митап.
Проблемът с обучението, тъй като оркестрацията представлява сложна екосистема.
Общ проблем на индустрията – използването на инструменти не по предназначение.Другите извода оставям на вас. Все още остава усещането, че комбинацията Docker+Kubernetes не е лесно да стане „централна“ част от системата. Например, операционните системи се инсталират на хардуера първи, което не може да се каже за контейнерите и оркестрацията. Възможно е в бъдеще операционките и контейнерите да се свържат с софтуера за управление на облака.
Снимка отВъзползвайки се от случая, искам да предам поздрави на мама и да напомня, че имаме Facebook група , канал с интересни публикации от различни техно-блогове. И моят канал , където разказвам за управлението на разработката в продуктовите компании.
Източник: habr.com
