Все о Kubernetes: контейнеры, оркестрация, тулинг, виртуальные машины, конкуренты и экосистема #1

Эксперты «Онланты», Ксения Ваганова, руководитель направления DevOps, и Кирилл Буев, системный архитектор, приняли участие в подкасте «Люди и код». В выпуске вы узнаете, что такое Kubernetes, какие инструменты существуют в экосистеме Kubernetes и используются в связке с ней, а также что такое Kubernetes-платформа собственной разработки, как такие платформы устроены, для чего они нужны и многое другое. Ведущий подкаста – Тимур Тукаев, выпускающий редактор Skillbox.

Полностью послушать подкаст вы можете  на нашем канале. А если вам по каким-то причинам неудобен аудиоформат, вы можете прочитать текстовую версию.

Все о Kubernetes: контейнеры, оркестрация, тулинг, виртуальные машины, конкуренты и экосистема. Часть 1.

Тимур Тукаев: Привет, я Тимур Тукаев, и это новый выпуск подкаста «Люди и код». Мы разбираем интересные технологии и говорим о людях в IT. «Люди и код» – проект медиапрограммирования от Skillbox.

Сегодня мы поговорим о Kubernetes, что это такое, как он связан с контейнеризацией и виртуализацией, есть ли у него аналоги, какие инструменты существуют в этой экосистеме, а также разберем самые типичные ошибки при внедрении Kubernetes. Наши гости – Кирилл Буев и Ксения Ваганова.

Кирилл, Ксения, привет. Для начала можете представиться, рассказать о себе, где работаете, чем занимаетесь, какими языками, технологиями владеете.

Ксения Ваганова: Тимур, привет. Меня зовут Ксения Ваганова, я работаю в компании «Онланта», это один из крупнейших поставщиков облачных сервисов и IT-услуг на рынке России. Я работаю в должности старшего продакт-менеджера. Продакт-менеджеры у нас в компании являются внутренними предпринимателями, и они также возглавляют и развивают направления конкретные. Я занимаюсь направлением DevOps.

Со мной мой коллега Кирилл Буев, это наш технический гуру, маэстро, и просто очень классный человек, которые тоже сейчас расскажет пару слов о себе.

Кирилл Буев: Да, Ксюша, спасибо. Всем привет, меня зовут Кирилл Буев, и я тоже работаю в компании «Онланта», работаю в ней системным архитектором и руковожу командой, которая делает нашу Kubernetes-платформу. Во время работы в качестве архитектора мне, так или иначе, приходится сталкиваться с очень многими популярными и не очень популярными решениями из области Cloud Native, из той области, про которую мы сегодня будем говорить.

В IT я суммарно около 12 лет, начинал свой путь с системного администрирования, но в какой-то момент мне захотелось делать что-то новое, а не только поддерживать уже существующие вещи. С темой, которую мы сегодня будем обсуждать, я столкнулся примерно пять лет назад, потом все завертелось, и вот я здесь.

Тимур Тукаев: Да, давай, Кирилл, тогда начнем с тебя. Расскажи вообще, что такое Kubernetes и что такое оркестрация контейнеров.

Кирилл Буев: Да. Начать, собственно, следует с того, что такое вообще контейнеризация, зачем ее придумали, зачем она нужна нам как разработчикам и как специалистам по эксплуатации. Контейнеризация сейчас – это один из самых популярных способов упаковки ПО для последующей доставки в какие-то целевые окружения, неважно, какие. Если это объяснить на очень таких верхнеуровневых понятиях, то, когда говорят, что приложение запущено в контейнере, то обычно подразумевают как минимум две вещи. Во-первых, мы контролируем, как оно видит окружение свое, в котором оно работает, то есть, например, смонтированные файловые системы, с которыми оно может работать, или другие процессы в операционной системе, которые работают рядом с ним.

Вторая вещь, которую обычно подразумевают, это то, что мы контролируем, как оно может использовать возможности, которые предоставляются ему окружением, каким образом и в какой мере оно может их использовать. Например, сколько оперативной памяти может потреблять наше приложение, или какие системные вызовы оно может делать. Нам, как разработчикам или администраторам, это дает одну очень ценную вещь: мы можем наше приложение упаковать таким образом, что где бы оно ни запускалось, на ноутбуке разработчика или в каком-нибудь публичном облаке, или на нашем собственном «железе», оно всегда сможет рассчитывать на то, что вокруг него находится ровно та среда, которая ему нужна для работы, то есть в действии такой принцип, «все свое ношу с собой». От этого мы получаем собственно прямое преимущество, мы в одной и той же системе, на одних и тех же виртуальных машинах или «железных» серверах можем запускать приложение с очень разными требованиями к окружению, то есть к версиям различных библиотек, сред исполнения и так далее. За счет этого мы можем плотнее набивать наши машины и серверы полезной нагрузкой, то есть эффективнее использовать аппаратный ресурс. Это преимущество как с технической точки зрения, так и с бизнесовой.

В какой-то момент у нас машин, на которых мы хотим запускать контейнеризованный софт, становится очень много. В этот момент появляется понятие оркестрации контейнеров. Ручное управление всем этим хозяйством становится слишком затратным, и собственно в этот момент на сцену выходят оркестраторы.

Оркестратор, опять же, если говорить в общем о термине, это ПО, по сути, менеджер кластеров, которое позволяет автоматизировать управление жизненным циклом контейнеров, то есть, например, реализовывать высокую доступность того, что в них работает, автоматизировать восстановление при сбоях, бесшовные деплои, автоматическое масштабирование зависимости от нагрузки и так далее.

Сейчас, в настоящий момент, хорошо это или плохо, каждый решает сам для себя, но самый популярный оркестратор – это Kubernetes. Если очень упростить и описать принцип, по которому он работает, то это софт, который на вход принимает описание желаемого состояния кластера и того ПО, которое там должно быть запущено в контейнерах в виде текстовых манифестов, а с другой стороны, он следит за тем, чтобы реальное положение дел соответствовало желаемому.

Kubernetes был впервые анонсирован компанией Google в 2014 году, и в 2015 году вышла версия 1.0. Как мы знаем, по крайней мере, по той информации, которая есть, Kubernetes, его дизайн, его архитектура в большой степени вдохновлена другим менеджером кластеров, который используется внутри самой компании Google, под названием Borg. Многие решения, которые принимались и принимаются до сих пор при развитии Kubernetes, корни у них растут именно оттуда.

Вместе с релизом Kubernetes 1.0 в 2015 году была создана ассоциация компаний под названием Cloud Native Computing Foundation (CNCF). В нее вошли крупные компании, которые, так или иначе, были заинтересованы в развитии технологий контейнеризации и оркестрации, в развитии всей экосистемы вокруг этих продуктов, которая начала тогда активно развиваться. Среди прочих это такие компании, как Google, IBM, Red Hat, VMware, Сisco и так далее. Собственно, с тех пор процент компаний, которые используют Kubernetes либо в продакшене, либо в каких-то тестовых окружениях, уверенно растет, и можно сказать на текущий момент, что среди конкурентов и аналогов он сейчас победил, на текущий момент.

Тимур Тукаев: Расскажи, пожалуйста, рядом с Kubernetes очень часто употребляют такие слова, как Docker, Virtualbox, VMware и другие понятия. Как они соотносятся между собой?

Кирилл Буев: Хороший вопрос. Собственно, чем отличается контейнеризация от виртуализации? Эти понятие очень часто, действительно, употребляют рядом. Иногда их путают, иногда их отождествляют, что, естественно, неправильно. Когда я говорил про то, что нам дает контейнеризация, важно было заметить, что, в принципе, примерно те же задачи можно решить с помощью виртуализации. Мы точно так же можем изолировать приложения друг от друга, управлять распределением нагрузки в нашем пуле аппаратных ресурсов. Основное отличие в том, что при виртуализации появляется больше накладных расходов на саму виртуализацию. По сути, каждое приложение, если мы будем запускать, скажем, приложения не в отдельных контейнерах, а в небольших виртуальных машинах, каждое приложение будет работать в отдельной собственной копии операционной системы, каждая виртуальная машина будет работать, собственно, ядро операционной системы. Естественно, это приведет к дополнительным накладным расходам, то есть мы просто больше ресурсов потратим не на работу нашей полезной нагрузки. Контейнеризация позволяет получить примерно те же плюсы, примерно те же возможности, но с меньшими накладными затратами. Естественно, с определенными нюансами, то есть говорить, что виртуализацию можно заменить контейнеризацией, или контейнеризацию виртуализацией, нельзя. Это немного разные инструменты, для разных задач.

Что касается Docker, Docker – это инструмент для сборки образов контейнеров, для запуска контейнеров из этих образов, для работы с репозиториями, в которых хранятся образы контейнеров. Это был, в принципе, первый популярный инструмент для работы с контейнерами в том виде, в котором мы сейчас их знаем. Когда сейчас говорят о контейнерах, обычно подразумевают именно то, с чем нам дал возможность когда-то, собственно в 2014 году, работать Docker. При этом само по себе понятие «контейнер» не тождественно Docker, то есть это просто один из инструментов, который позволяет это делать.

В самом начале своего пути, своего развития Kubernetes умел работать только с Docker для запуска контейнеров. В настоящее время он поддерживает большое количество различных контейнерных рантаймов, не ограничиваясь Docker.

Тимур Тукаев: Хотел подвести итог такой вводной части. Ксения, можешь тогда рассказать, бизнесу в чем выгода от контейнеризации? Может быть, даже в цифрах можно что-то показать.

Ксения Ваганова: В цифрах, наверное, сейчас не покажу, к сожалению, но мы считаем, что самым главным имуществом контейнеризации и оркестрации для бизнеса является снижение затрат на масштабирование проекта. Если, например, бизнес активно растет, или есть, например, активная волнообразная нагрузка, как это бывает у Интернет-магазинов, сезонные всплески, к примеру, то правильно внедренный Kubernetes ускоряет масштабирование и сокращает затраты на него за счет того, что он предоставляет готовые инструменты для решения большого пласта типичных задач в рамках этого сценария, и позволяет двигаться быстрее, не тратить время на борьбу с инфраструктурой. Однако ключевое в этой фразе – «правильно внедренный Kubernetes», потому что неправильно внедренный Kubernetes придет к совершенно обратному эффекту. Поэтому, когда заказчики у нас спрашивают: «А нужно ли нам это?», мы с Кириллом всегда говорим, что для начала нам нужно привести хотя бы небольшой анализ и аудит и сделать расчеты для того, чтобы понять, как получить максимальный профит от внедрения этого инструмента, потому что Kubernetes не всегда полезен заказчикам.

Тимур Тукаев: А в каких случаях он может быть неполезен? Наверное, здесь плавно переходим к плюсам и минусам контейнеризации и оркестрации.

Кирилл Буев: Как контейнеризация, так и оркестрация – это, безусловно, не «серебряная пуля». Имеется как достаточно большое количество плюсов, о которых я говорил, так и минусов.

Основной плюс, про который я сказал, это то, что в результате контейнеризации приложения мы получаем такой конечный, неизменяемый и самодостаточный артефакт, который можно запустить почти где угодно, и быть уверенным, что запустится ровно то, что нужно, и ровно так, как нужно. Но, конечно, есть и минусы. Ксения сейчас об одном важном минусе сказала. Собственно, это и есть такая самая распространенная ошибка компаний при внедрении Kubernetes. На самом деле, это не только связано с тем, что мы сейчас обсуждаем, это в принципе в IT достаточно распространенная ошибка, внедрение большого и сложного стека инструментов без оглядки на потребности бизнеса и, что тоже немаловажно, с игнорированием обратной связи от пользователей этих инструментов, то есть тех, для кого это собственно внедряется, как правило, это разработчики. Принцип тут очень простой. Если в результате наших всех изменений работы стало больше, она занимает больше времени, значит, что-то пошло не так. Собственно, это, с одной стороны, очень очевидно, а с другой стороны, про это достаточно часто забывают. Все эти новые уровни абстракции, модные инструменты должны в итоге нам всем упрощать работу и повышать нашу эффективность, а не наоборот, иначе это, по сути, просто игрушки, с которыми, конечно, интересно повозиться, но бизнесу они ничего не принесут, кроме дополнительных затрат. С этим связан один из основных минусов как контейнеризации, так и оркестрации, в особенности оркестрации, то, что при переходе к этой новой парадигме упаковки и доставки софта в целевое окружение вопрос наблюдаемости, то есть мониторинга, по сути, встает очень часто. Нам становится гораздо сложнее диагностировать неисправности, такая диагностика требует больше знаний и больше времени. Требования к специалистам, которые с этим работают, растут. Получит ли бизнес какие-то от таких изменений преимущества, это очень сильно зависит от потребности проекта.

В качестве примера проекта, которому внедрение, допустим, того же Kubernetes принесет только вред, можно привести какой-нибудь небольшой проект, допустим, какой-нибудь медиапортал, который в настоящее время спокойно умещается на четырех виртуальных машинах, разработчики деплоят туда свой софт напрямую руками, какими-нибудь самописными скриптами, все в целом хорошо. Если на таком проекте начать внедрять это все модное, молодежное и очень популярное просто ради того, чтобы это было, в результате произойдет катастрофа. Мы были свидетелями таких катастроф, то есть мы сталкивались с последствиями такого внедрения на проектах, с которыми имели дело, и зрелище это обычно печальное.

Основной минус в том, что, читая различные статьи в блогах, смотря выступления с какого-нибудь KubeCon и других конференций на тему DevOps и всего, что связанно с этим, очень легко загореться и побежать внедрять эти все инструменты, про которые уверенно себя чувствующие люди рассказывали на конференциях, без оглядки собственно на то, к чему это приведет, и какие затраты нужно будет сделать. Вот это основной минус, на мой взгляд.

Тимур Тукаев: Как у волка с зайцем из анекдота: «Ничего не изменилось, только писанины добавилось».

Кирилл Буев: Да, так и есть.

Читайте продолжение здесь - часть 2.