«В ИТ только и разговоров, что о Kubernetes и облаках!» — так могла бы звучать легендарная фраза из фильма «Достучаться до небес», если бы его герои хотели напоследок понаблюдать за выкатом в продакшен нескольких микросервисов, а не посмотреть на море. Kubernetes действительно стремительно становится стандартном для облачных вычислений и работы с контейнерами, нередко его даже называют «операционной системой для облаков».
Так что такое этот Kubernetes, зачем он нужен и почему стал настолько популярным? На эти вопросы мы и попытаемся ответить в этой статье — причем максимально простым и неинженерным языком, так, чтобы вы могли объяснить Kubernetes своей бабушке или понять его сами без погружения в технические подробности.
Что такое Kubernetes и зачем он нужен
Если давать формальное определение, то Kubernetes — это средство оркестрации контейнеров. Может прозвучать сложно, но на деле всё просто: Kubernetes позволяет задавать правила «поведения» для огромного количества контейнеров и следит за тем, чтобы все следовали этим правилам. Причем он может задавать правила как для отдельных контейнеров, так и для групп контейнеров.
Стиль управления и механика работы Kubernetes называются декларативностью. Вы просто говорите ему: «Хочу, чтобы контейнеры такого-то типа потребляли не больше такого-то количества ресурсов и не меньше такого-то объема оперативной памяти. А еще мне надо, чтобы они не запускались на одном сервере с другим типом контейнеров. И если вдруг нагрузка на эти контейнеры возрастет, запусти еще штук 10 таких же контейнеров». Всё. Дальше в дело вступает магия Kubernetes: он сам следит, чтобы это состояние всегда поддерживалось, а если что-то будет отклоняться от заданных правил, будет настойчиво пытаться вернуть всё к идеальному состоянию.
Вот мы и разобрались, что такое Kubernetes и для чего он нужен. А теперь пойдем дальше и посмотрим на предпосылки его появления, как он связан с контейнерами и микросервисами, какие основные сущности надо знать, чтобы лучше понимать Kubernetes.
Что такое контейнеры и контейнеризация
Проще всего понять контейнеризацию через сравнение с виртуализацией. Виртуализация — это когда вы запускаете внутри одной операционной системы одну или несколько других операционных систем, в каждой из которых работают необходимые вам приложения. Допустим у вас есть мощный сервер с Ubuntu Linux и вы создаете на нем несколько виртуальных машин: в одной у вас Windows Server 2003, в другой — тоже Ubuntu Linux, в третьей — FreeBSD и так далее. Чтобы запустить приложение в виртуальной машине, внутри этой виртуальной машины должна быть своя полноценная операционная система.
Контейнеризация работает немного по-другому. Внутри каждого контейнера собирается всё необходимое для запуска приложений, а в качестве операционной системы используется операционная система сервера. Это позволяет экономить ресурсы — ведь вам уже не надо запускать и поддерживать работу полноценной операционной системы как в случае с виртуальными машинами. Но это привносит и свои ограничения: с помощью виртуальных машин вы можете запускать на любом сервере приложения, которые могут работать только в каких-то специфических ОС, а в случае контейнеризации — только те приложения, которые умеют работать в операционной системе, установленной на сервере.
Почему же тогда просто не поставить все приложения на этот самый сервер — зачем собирать какие-то контейнеры? Ведь на любом компьютере, с которого мы работаем или занимаемся домашними делами, установлено множество программ и они друг другу не мешают? Но когда мы говорим о серьезных веб-сервисах или нагруженных приложениях, нам важно четко выделять под них ресурсы и понимать, что они не съедят ресурсы друг друга. Плюс серьезно встает вопрос безопасности: если злоумышленники проникнут в одно приложение, они смогут создать проблемы и всем остальным приложениям, а когда мы запускаем приложения в контейнерах, они ограничены рамками контейнеров и не могут дать доступ к операционной системе сервера или другим контейнерам (как обычно, на практике всё немного сложнее).
Kubernetes и микросервисы
Kubernetes стал особенно популярным благодаря распространению микросервисов. Сейчас объясним, что это такое. Раньше программы и сервисы были в основном монолитными — то есть все их компоненты были тесно связаны и если вы пытались изменить что-то в одном кусочке программы, это могло вызвать ошибки и сбои всей программы. Плюс разработчикам приходилось пользоваться одним узким набором технологий, а когда они устаревали, поделать с этим ничего было нельзя — разве что переписывать всю программу с нуля.
Представьте, что вы храните вещи в гараже без стеллажей, полок и удобных ячеек — он просто свалены в одну большую кучу. Вы захотели достать лыжи, и вся куча обвалилась прямо на вас. Ситуация не самая приятная. И так всегда: пытаясь что-то достать из кучи, вы рискуете заработать шишку.
И вот в какой-то момент вам все это надоедает: вы покупаете удобные стеллажи с полочками и ячейками и раскладываете все вещи по ним, а те самые злополучные лыжи кладете на самый верх стеллажа.Теперь вы можете легко доставать нужные вам вещи с гарантией, что вам на голову ничего не упадет.
Микросервисы — это что-то вроде такого стеллажа. Каждый компонент приложения пишется независимо от других, а связь обеспечивается за счет API (Application Program Interface) — набора команд и правил, по которым эти компоненты общаются между собой. Это открывает целый ряд перспектив:
- Вы можете писать каждый компонент на своем наборе технологий, максимально подходящим именно для этой задачи.
- Вы не привязаны к устаревшим технологиям — переписать на свежий стек один небольшой компонент гораздо проще, чем огромную программу.
- Ваши команды разработчиков будут работать эффективнее — им не надо знать и понимать всю программу, достаточно разбираться в работе своего компонента.
- Вы можете задавать четкие ограничения по ресурсам для каждого из компонентов — в том числе точечно масштабировать отдельные компоненты. При монолитном подходе ресурсы добавляются сразу всему приложению и все компоненты могут их расходовать по принципу «кто раньше встал, того и тапки», а в случае микросервисов вы будете уверены, что, например, добавленная оперативная память используется по своему назначению — только для компонента просмотра видео, но не для блоков, которые отвечают за фото или обмен текстовыми сообщениями.
И Kubernetes идеально вписывается в мир микросервисов — ведь он как раз позволяет задавать наборы правил и ограничений для каждого контейнера или типа контейнеров, то есть для каждого компонента вашего приложения, а также автоматически следит за соблюдением этих правил.
Главные сущности Kubernetes
Чтобы лучше понимать, что такое Kubernetes, надо понять, какими сущностями он оперирует.
- Узел (нода) — это машина в кластере Kubernetes, отдельная «железка», физический сервер. Бывают мастер-узлы и рабочие узлы. Мастер-узел — это такая машина, на которой запущены инструменты управления Kubernetes, а рабочий узел — это машина, на которой запускаются контейнеры.
- Под — группа контейнеров, которые запускаются как единое целое и имеют общее хранилище и настройки. Почему они запускаются как единое целое? Потому что в них, например, может быть упакована какая-то одна функциональность приложения или одно приложение.
- Кластер — это набор узлов (в кластере может быть и один узел), объединенных одной установкой Kubernetes.
Подробнее о компонентах Kubernetes можно почитать в официальной документации.
Как появился Kubernetes
Kubernetes появился в 2013 году — незадолго до этого группа разработчиков из Google, вдохновившись Docker, решила сделать оркестратор контейнеров. Дело в том, что Docker умел работать только с отдельными контейнерами, а в масштабах Google это было очень неудобно: представьте, что вам надо управлять сотнями тысяч контейнеров и задавать правила поведения для каждого из них вручную, вручную добавлять им ресурсы, вручную управлять ими.
Еще одной важной предпосылкой появления Kubernetes стала банальная конкуренция с AWS. Дело в том, что облачный сервис от Amazon, основанный на виртуальных машинах, в то время был дико популярным — и Google Cloud со своим подходом к облакам выглядел для большинства пользователей непонятным или ненужным. Поэтому инженеры Google придумали гениальный ход: мы не можем конкурировать с AWS с помощью рекламы и классических маркетинговых приемов, следовательно, надо навязать всем новый стандарт и подход к облакам, который будет соответствовать модели Google Cloud. Задача столь же амбициозная, сколь и сумасбродная.
Kubernetes 1.0 сразу вышел как Open Source-продукт — команде разработки проекта каким-то чудом удалось убедить менеджмент Google, что именно такой подход поможет в конкурентной борьбе. В итоге все конкуренты объединились вокруг Kubernetes, привнесли в него свой опыт и свои подходы к облачным вычислениям.
В каком виде подают Kubernetes
Сам по себе Kubernetes используется очень редко — ему не хватает множества удобных функций: более гибкие политики авторизации, работа с сетями и т.п. Поэтому вокруг него появилось немало приложений вроде Istio, Cilium, Dex и других. Все они расширяют функциональность Kubernetes и добавляют ему разные суперсилы. Поэтому чаще всего Kubernetes используется в связке с достаточно большим количеством другого ПО. Кроме того, Kubernetes необходимо встроить в свою инфраструктуру: подружить с базами данных, операционными системами на серверах, микросервисами.
Способ №1
А так как Kubernetes даже сам по себе — очень продвинутая система с кучей настроек и «крутилок» под капотом, то интеграция его в инфраструктуру становится достаточно сложной задачей, справиться с которой может только команда квалифицированных инженеров. Им необходимо выбрать подходящие для конкретного проекта дополнительные сервисы и программы, расширяющие функциональность K8s, подружить это всё с текущей инфраструктурой, какие-то устаревшие решения заменить, покрутить настройки внутри K8s и т. п.
Это мы описали первый способ приготовления Kubernetes — взять все ингредиенты и «смешать» их самостоятельно. Но этот способ подходит далеко не всем — как мы уже упоминали, понадобится как минимум команда квалифицированных инженеров.
Что делать, если вы не хотите растить/нанимать такую команду или у вас просто нет на это ресурсов? Тут на помощью приходят другие два метода приготовления Kubernetes: Kubernetes-платформы и Managed Kubernetes.
Способ №2
Managed Kubernetes — самый простой способ начать использование Kubernetes, он требует минимального погружения в технологию. Такую услугу обычно предоставляют облачные провайдеры: вы просто «накликиваете» мышкой в интерфейсе провайдера необходимые ресурсы и пользуетесь ими. Техническая поддержка и состав компонентов — на стороне провайдеров. Главный минус такого подхода — вам будет сложно перейти на Managed Kubernetes от другого провайдера и вы никак не сможете влиять на состав услуги, всё предопределено провайдером.
Способ №3
Kubernetes-платформы дают больше гибкости, но в то же время позволяют не так глубоко погружаться в технические детали. Фактически, это сборки Kubernetes и необходимых компонентов, заточенные под разные сценарии использования, тщательно протестированные и преднастроенные. Как дистрибутив Linux: ядро операционной системы одно на всех, но настроено оно по-разному и в каждый дистрибутив входят те программы, которые показались наиболее важными и полезными разработчикам дистрибутива.
Используя Kubernetes-платформу, бизнес уходит от зависимости от одного облачного провайдера, получает гибкость в настройке платформы под себя. Но и в этом случае есть свои ограничения, которые могут быть более или менее серьезными в зависимости от особенностей платформы:
- Vendor lock-in — зависимость от вендора, то есть компании, создавшей платформу. Особенно сильной эта зависимость может быть, если в платформе используется не «ванильный», то есть оригинальный Kubernetes, а его сильно видоизмененная копия. Проверить это можно, посмотрев на сайте некоммерческой организации CNCF, протестирована ли платформа на совместимость с «ванильным» Kubernetes.
- Стоимость. Как правило, Kubernetes-платформы довольно дорогие, хотя при этом они дают множество преимуществ и позволяют значительно экономить на команде инженеров, поддержке и обновлениях своего решения.
Почему Kubernetes стал так популярен
Трудно выделить одну основную причину популярности Kubernetes, поэтому попробуем перечислить несколько важных предпосылок:
- Удачное время выхода — конкурентов, фактически, не было.
- Изначальный курс разработчиков на Open Source и развитие технологии как независимой от конкретного вендора или конкретной компании, а также удачная попытка собрать вокруг проекта всех главных ИТ-игроков и конкурентов того времени.
- Популярность контейнеров и микросервисов — Kubernetes затачивался именно под них, а потому рос с ростом их популярности.
- Грамотный менеджмент проекта — в том числе техническое визионерство и понимание, куда развивать проект. Этот пункт, конечно, может вызвать споры: мне не хватает вот такой фичи, зачем в K8s эта ненужная штука, разработчики всё делают неправильно и т.п. Но если посмотреть верхнеуровнево, то разработка явно удачная и сбалансированная.
- Рост важности ИТ в нормальном функционировании практически любого бизнеса, в том числе развитие облачных вычислений, стремление оптимизировать процессы с помощью соответствующего ПО.
- Ну и конечно же, банальное везение или удачное расположение звезд — без них в таких проектах не обойтись.
Когда Kubernetes не поможет
Как и любая технология, Kubernetes не является серебряной пулей и не решит всех проблем по мановению волшебной палочки. Есть случаи, когда он практически бесполезен. Кратко рассмотрим их:
- У вас маленькое приложение из нескольких компонентов или ваше приложение умещается в одном контейнере и у него крошечная нагрузка, а масштабирование не нужно. В этом случае Kubernetes будет просто избыточен.
- По каким-то причинам вы не хотите вкладываться в инфраструктуру: например, ваш рынок идет на спад, совсем нет и не предвидится сильных конкурентов и т.д.
- У вас нет сильной команды инженеров, которая умеет работать с Kubernetes и вы не хотите покупать внешнюю экспертизу в виде аутсорсинг-команд или Kubernetes-платформ.
- У вас монолитное приложение и вы не планируете делить его на микросервисы.
Выводы
Kubernetes — это уже стандарт де-факто среди систем оркестрации контейнеров, причём и в мире, и в России. Его основные преимущества: небывалая гибкость в управлении большим количеством контейнеров, автоматизация множества рутинных ручных операций, огромная экосистема смежных cloud native-инструментов.
Однако в то же время внедрение Kubernetes остается очень нетривиальной задачей, потому что он очень сложен и имеет кучу настроек, о которых знает далеко не каждый инженер. Кроме того, Kubernetes — это не готовое решение, а центр экосистемы с кучей решений для разных задач, то есть его внедрение похоже на сборку модели из деталек конструктора «вслепую» и без чертежа: что выбрать для тех или иных условий, а какие вообще потребности могут появиться в будущем, как правильно сконфигурировать систему, чтобы не столкнуться с ограничениями и т.п. Естественно, ручная поддержка подобной системы будет тоже сложной и недешевой задачей.
Все эти сложности привели к тому, что компании задумываются о платформенных решениях, и здесь есть несколько путей:
- Сделать платформу самостоятельно на базе «ванильного» Kubernetes, дистрибутива Linux и разных Open Source-компонентов. Как правило, подобное могут себе позволить самые большие компании с мощными бюджетами и командами разработки.
- Использовать managed-решение от облачных провайдеров вроде VK Cloud или Yandex Cloud. Это, пожалуй, самый простой путь, но он в основном подходит для решения относительно небольших задач и не дает необходимой гибкости.
- Использовать готовую платформу от вендоров — в этом случае важно правильно выбрать платформу, чтобы она подходила под задачи бизнеса (мы проводили вебинар на эту темы и рассказывали о том, как выбирать платформу контейнеризации и даже опубликовали памятку «О чём не забыть подумать при выборе и внедрении платформы контейнеризации»). Кроме того, платформы от вендоров зачастую можно комбинировать с публичными облаками (хороший пример — в еще одном нашем вебинаре).