для чего нужен кубернетис
Зачем нужен Kubernetes и почему он больше, чем PaaS?
В большой production пришёл не только Docker, но и Kubernetes. И если даже с контейнерами далеко не всегда всё достаточно просто, то уж «кормчий» и подавно остаётся за гранью правильного понимания среди многих системных администраторов, DevOps-инженеров, разработчиков. В этой небольшой статье предпринята попытка ответить на один из вечных вопросов (в контексте Kubernetes) с помощью наглядного объяснения идеи и особенностей данного проекта. Возможно, именно этого вам не хватало для того, чтобы начать плотное знакомство с Kubernetes или даже его эксплуатацию?
Соучредитель и архитектор крупного онлайн-сервиса Box (около 1400 сотрудников) Sam Ghods в своём прошлогоднем выступлении на KubeCon указал на типовую ошибку восприятия Kubernetes. Многие рассматривают этот продукт как очередной фреймворк для оркестровки контейнеров. Но если бы всё действительно было так, то зачем его разработчики неустанно напоминают про «корни Kubernetes API, уходящие в архитектуру*, создаваемую более 10 лет в рамках проекта Google Borg».
Google Borg — это менеджер кластеров, предназначенный для параллельного запуска тысяч задач, распределённых по тысячам приложений, запускаемых на многочисленных кластерах. Именно эту архитектуру и унаследовал Kubernetes, перенося кластерные идеи на современную почву контейнеров. Чем же это отличается от многочисленных облачных платформ, существующих сегодня? Начнём с самого понятия платформы.
* Архитектура Kubernetes создана таким образом, что позволяет расширять эту платформу, но разработчиков при этом просят следовать основополагающим принципам.
Kubernetes как платформа
Архитектор Box даёт такой вариант определения: «Платформа предоставляет уровень абстракции, забирающий у вас какую-либо проблему, чтобы вы могли творить поверх неё [не думая о ней]». Примеры: платформа Linux даёт возможность исполнять системные вызовы вне зависимости от аппаратного обеспечения компьютера, а платформа Java — исполнять приложения вне зависимости от операционной системы. Какова же должна быть платформа для запуска приложений, созданных по принципам микросервисной архитектуры?
Ключевые характеристики такой платформы — портируемость и расширяемость. Каждая облачная платформа предлагает свои варианты для достижения этих целей. Например, для автоматического масштабирования у AWS имеются Auto Scaling Groups, у Google Cloud Platform — Autoscaler, у Microsoft Azure — Scale Set, у OpenStack — autoscaling API в Heat. Всё это само по себе неплохо, т.к. потребности выполняются, однако у конечного пользователя начинаются сложности. Чтобы разместить приложение, для каждого сервисного провайдера необходимо поддерживать его механизмы: добавлять поддержку API, учитывать специфику работы используемой реализации и т.п. Вдобавок, всем этим решениям не хватает системы обнаружения сервисов для по-настоящему удобного и автоматизированного развёртывания микросервисов. А если вам нужно быть гибким и иметь возможность размещать приложения в разных окружениях (в публичном облаке, в своём дата-центре, на серверах клиента…)?
В этом заключается первый плюс и суть Kubernetes как платформы, то есть по-настоящему универсальной системы для развёртывания приложений, физическое размещение которых может производиться где и как угодно: на голом железе, в публичных или частных облаках вне зависимости от их разработчиков и специфичных API. Но здорово в Kubernetes не только то, где запускать, но и что: ведь это могут приложения на разных языках и под разные ОС, они могут быть stateless и stateful. Поддерживается принцип «если приложение может запускаться в контейнере, оно должно отлично запускаться в Kubernetes».
Предназначение Kubernetes как платформы — предоставить базовую, абстрактную платформу как услугу (Platform as a Service, PaaS), сохранив гибкость в выборе конкретных компонентов этой PaaS.
Kubernetes и PaaS
О том, что Kubernetes не является традиционной PaaS, рассказывается в документации проекта, где поясняется, что авторы стремятся сохранить возможность пользовательского выбора в местах, где это важно. В частности, поэтому:
Заключение
Что должно быть в стандартной библиотеке C++? Идеалом для программиста является возможность найти каждый интересный, значимый и разумно обобщённый класс, функцию, шаблон и т.п. в библиотеке. Однако вопрос не в том, «что должно быть в какой-то библиотеке», а в том, «что должно быть в стандартной библиотеке». И ответ «Всё!» — первое разумное приближение к ответу на первый вопрос, но не последний. Стандартная библиотека — то, что должен предоставлять каждый автор и делать это так, чтобы каждый программист мог на это положиться [т.е. действительно нуждался в этом — прим. перев.].
Применительно к Kubernetes можно сказать, что эта система — фундамент, та самая «стандартная библиотека» для построения PaaS и других подобных решений.
Kubernetes как сервис — изучение рынка
Привет, Хабр! Как и многие другие, в прошлом году мне пришлось внезапно мигрировать из тесного привычного офиса к себе домой. Я и раньше работал из дома, когда была такая нужда. Но чтобы несколько месяцев подряд — такое со мной случилось впервые. Появилось свободное время, которое я сначала не знал, куда девать. Но потом приспособился, начав изучать вещи, до которых раньше не доходили руки.
Я поковырялся в инвестиционных играх на бирже, познакомился с облачным геймингом, а ещё успел почитать о том, что за зверь такой появился, про который из каждого умного утюга говорят — Kubernetes. Начав с блога Фланта, я убедился, что конкретно мне и конкретно сейчас эта штука не нужна, но выглядит она интересно.
Почитал, одобрил и забыл, да вот только буржуйский Facebook про меня забывать не хотел. И где-то с неделю показывал мне рекламу с самыми наивыгодными предложениями этого самого кубернетиса. В результате я в очередной раз продемонстрировал моральную слабость и решил лично познакомиться с этим зверем.
Главное, что я понял, так это что если вы не слышали про Kubernetes и не понимаете, как его использовать в вашей работе, то в 99% случаев он вам и не нужен. Но сама идея сокращения цикла разработки за счёт быстрой доставки пользователю и возможности тестировать версии приложений на узких сегментах аудитории прекрасна. Посмотрел, что получилось, после чего можно распространить версию приложения на всех пользователей или немедленно её откатить.
Но продолжу тему знакомства с этой модной платформой управления контейнерами. Я решил не ограничивать себя одной компанией, наиболее часто мозолившей глаз в Facebook. А выбрать несколько более-менее крупных фирм, у которых есть толковое предложение.
Как выбирал
Вы удивитесь, но поиском. Погуглил «Kubernetes в облаке», пролистал пару страниц. Так и нашёл семь компаний, которые наиболее активно продвигают эту услугу: Mail.ru Cloud Solutions, Cloud4Y, CloudMTS, Yandex.Cloud, КРОК, DataLine, Selectel.
Было бы круто воспользоваться сервисом подбора провайдеров, где можно указать фильтры по ценам, возможностям и прочему. Но увы, я такого сервиса не нашёл, так что делал всё ручками. И если кого шибко важного и крупного не указал, так это не по причине моей зловредности, а потому что реклама у них слабенькая. Ну, и или страницы в поиске глубоко находятся. В общем, кого нет в списке, того я не нашёл. Прошу понять, простить и не гнобить.
Про субъективность
Это абсолютно необъективная статья. Было просто интересно, что это за зверь, какой сервис выглядит удобнее и надёжнее остальных, какой проще и понятнее именно для меня. Так что учитывайте, что мой опыт — это всего лишь мой опыт. У вас могут быть другие предпочтения и знания. Рассматривайте данный текст просто как информацию, абстрактное общее сравнение, а не прямое руководство к действию.
Ещё момент: я собирал информацию, которая есть в открытом доступе, стараясь не задалбывать менеджеров глупыми частыми вопросами по почте и телефону. Мне было неловко звонить и расспрашивать, если покупать всё равно не планирую. Тратить чужое время из-за неуёмного моего любопытства было как-то стыдно. Ну захотелось мне проверить, будет ли работать их сервис, нравится ли он мне как пользователю. Были некоторые моменты, которые я узнавал по телефону и почте, но в основном все данные брал из документации и маркетинговых материалов.
Здесь возникли первые сложности. Я старался звонить по-минимуму, но тот же Яндекс без звонка хоть что-то сообщать отказывался. Остальные без проблем написали о том, что они предлагают и как всё это работает. Ну и ладно, подумал я. Информации в свободном доступе тоже хватает. Вернусь позднее и пообщаюсь, раз они такие буки. Или не пообщаюсь, если к тому времени уже натестируюсь по самый докер. Это была зима 2020, и у меня было много свободного времени.
Знакомство
Звонить и писать сразу всем компаниям — гиблое дело, особенно если не готов покупать, а хочешь лишь проверить, как оно работает. Поэтому я потихоньку запрашивал тестовый доступ у каждой компании по очереди. Быстрее всех ответили Selectel, Cloud4Y и MCS, а вот Крок и DataLine оказались не столь быстрыми. Мне даже пришлось несколько раз ментально их пнуть напоминать о себе, чтобы получить какой-то ответ.
И уже на этом этапе круг подопытных кроликов провайдеров сузился. DataLine вообще никак не захотел со мной общаться. Письма ушли в молоко. «Ну и ладно», — подумал я. «И нечего нас дёргать со всякими глупостями», — подумал неизвестный мне менеджер DataLine. КРОК вежливо извинился и сообщил, что мелочь вроде меня им не интересна. Неприятно, но честно. Спасибо за это. Лучше честный отказ, чем игнор или затягивание времени.
Отмечу, что прямо-таки агрессивных продаж не наблюдалось. Понятно, что я не самая крупная рыбка, которая водится в облачном море. Но всё же. Порадовало, что мне не впаривают, а предлагают. Убеждают. Правда, почти все компании сочли своим долгом сделать меня подписчиком полезных корпоративных рассылок. Но к этому я был готов.
Чуть забегая вперёд скажу, что поскольку компаний стало меньше, а я вошёл во вкус, то в процессе тестирования сервисов Kubernetes вспомнил и про Яндекс. «А не позвонить ли мне им?», подумалось мне. Как оказалось, не зря — у этих ребят оказалось не самое плохое решение из тех, что мне удалось посмотреть.
Тестирование
Теперь давайте посмотрим, чего я натестировал.
Основы Kubernetes
В этой публикации я хотел рассказать об интересной, но незаслуженно мало описанной на Хабре, системе управления контейнерами Kubernetes.
Что такое Kubernetes?
Kubernetes является проектом с открытым исходным кодом, предназначенным для управления кластером контейнеров Linux как единой системой. Kubernetes управляет и запускает контейнеры Docker на большом количестве хостов, а так же обеспечивает совместное размещение и репликацию большого количества контейнеров. Проект был начат Google и теперь поддерживается многими компаниями, среди которых Microsoft, RedHat, IBM и Docker.
Компания Google пользуется контейнерной технологией уже более десяти лет. Она начинала с запуска более 2 млрд контейнеров в течение одной недели. С помощью проекта Kubernetes компания делится своим опытом создания открытой платформы, предназначенной для масштабируемого запуска контейнеров.
Проект преследует две цели. Если вы пользуетесь контейнерами Docker, возникает следующий вопрос о том, как масштабировать и запускать контейнеры сразу на большом количестве хостов Docker, а также как выполнять их балансировку. В проекте предлагается высокоуровневый API, определяющее логическое группирование контейнеров, позволяющее определять пулы контейнеров, балансировать нагрузку, а также задавать их размещение.
Концепции Kubernetes
Nodes (node.md): Нода это машина в кластере Kubernetes.
Pods (pods.md): Pod это группа контейнеров с общими разделами, запускаемых как единое целое.
Replication Controllers (replication-controller.md): replication controller гарантирует, что определенное количество «реплик» pod’ы будут запущены в любой момент времени.
Services (services.md): Сервис в Kubernetes это абстракция которая определяет логический объединённый набор pod и политику доступа к ним.
Volumes (volumes.md): Volume(раздел) это директория, возможно, с данными в ней, которая доступна в контейнере.
Labels (labels.md): Label’ы это пары ключ/значение которые прикрепляются к объектам, например pod’ам. Label’ы могут быть использованы для создания и выбора наборов объектов.
Kubectl Command Line Interface (kubectl.md): kubectl интерфейс командной строки для управления Kubernetes.
Архитектура Kubernetes
Работающий кластер Kubernetes включает в себя агента, запущенного на нодах (kubelet) и компоненты мастера (APIs, scheduler, etc), поверх решения с распределённым хранилищем. Приведённая схема показывает желаемое, в конечном итоге, состояние, хотя все ещё ведётся работа над некоторыми вещами, например: как сделать так, чтобы kubelet (все компоненты, на самом деле) самостоятельно запускался в контейнере, что сделает планировщик на 100% подключаемым.
Нода Kubernetes
При взгляде на архитектуру системы мы можем разбить его на сервисы, которые работают на каждой ноде и сервисы уровня управления кластера. На каждой ноде Kubernetes запускаются сервисы, необходимые для управления нодой со стороны мастера и для запуска приложений. Конечно, на каждой ноде запускается Docker. Docker обеспечивает загрузку образов и запуск контейнеров.
Kubelet
Kubelet управляет pod’ами их контейнерами, образами, разделами, etc.
Kube-Proxy
Также на каждой ноде запускается простой proxy-балансировщик. Этот сервис запускается на каждой ноде и настраивается в Kubernetes API. Kube-Proxy может выполнять простейшее перенаправление потоков TCP и UDP (round robin) между набором бэкендов.
Компоненты управления Kubernetes
Система управления Kubernetes разделена на несколько компонентов. В данный момент все они запускаются на мастер-ноде, но в скором времени это будет изменено для возможности создания отказоустойчивого кластера. Эти компоненты работают вместе, чтобы обеспечить единое представление кластера.
Состояние мастера хранится в экземпляре etcd. Это обеспечивает надёжное хранение конфигурационных данных и своевременное оповещение прочих компонентов об изменении состояния.
Kubernetes API Server
Kubernetes API обеспечивает работу api-сервера. Он предназначен для того, чтобы быть CRUD сервером со встроенной бизнес-логикой, реализованной в отдельных компонентах или в плагинах. Он, в основном, обрабатывает REST операции, проверяя их и обновляя соответствующие объекты в etcd (и событийно в других хранилищах).
Scheduler
Scheduler привязывает незапущенные pod’ы к нодам через вызов /binding API. Scheduler подключаем; планируется поддержка множественных scheduler’ов и пользовательских scheduler’ов.
Kubernetes Controller Manager Server
Все остальные функции уровня кластера представлены в Controller Manager. Например, ноды обнаруживаются, управляются и контролируются средствами node controller. Эта сущность в итоге может быть разделена на отдельные компоненты, чтобы сделать их независимо подключаемыми.
ReplicationController — это механизм, основывающийся на pod API. В конечном счете планируется перевести её на общий механизм plug-in, когда он будет реализован.
Пример настройки кластера
В качестве платформы для примера настройки была выбрана Ubuntu-server 14.10 как наиболее простая для примера и, в то же время, позволяющая продемонстрировать основные параметры настройки кластера.
Для создания тестового кластера будут использованы три машины для создания нод и отдельная машина для проведения удалённой установки. Можно не выделять отдельную машину и производить установку с одной из нод.
Подготовка нод
Требования для запуска:
Установка ПО на ноды
Установку Docker можно произвести по статье в официальных источниках:
Дополнительная настройка Docker после установки не нужна, т.к. будет произведена скриптом установки Kubernetes.
Установка bridge-utils:
Добавление ssh-ключей
Выполняем на машине, с которой будет запущен скрипт установки.
Если ключи ещё не созданы, создаём их:
Копируем ключи на удалённые машины, предварительно убедившись в наличии на них необходимого пользователя, в нашем случае core.
Установка Kubernetes
Далее мы займёмся установкой непосредственно Kubernetes. Для этого в первую очередь скачаем и распакуем последний доступный релиз с GitHub:
Настройка
Для того, чтобы использовать последний, на момент написания статьи, релиз 0.17.0 необходимо заменить:
На этом настройка заканчивается и можно переходить к установке.
Установка
Первым делом необходимо сообщить системе про наш ssh-agent и используемый ssh-ключ для этого выполняем:
В процессе установки скрипт потребует пароль sudo для каждой ноды. По окончанию установки проверит состояние кластера и выведет список нод и адреса Kubernetes api.
Посмотрим, какие ноды и сервисы присутствуют в новом кластере:
Видим список из установленных нод в состоянии Ready и два предустановленных сервиса kubernetes и kubernetes-ro — это прокси для непосредственного доступа к Kubernetes API. Как и к любому сервису Kubernetes к kubernetes и kubernetes-ro можно обратиться непосредственно по IP адресу с любой из нод.
Запуск тестового сервиса
Для запуска сервиса необходимо подготовить docker контейнер, на основе которого будет создан сервис. Дабы не усложнять, в примере будет использован общедоступный контейнер nginx. Обязательными составляющими сервиса являются Replication Controller, обеспечивающий запущенность необходимого набора контейнеров (точнее pod) и service, который определяет, на каких IP адресе и портах будет слушать сервис и правила распределения запросов между pod’ами.
Любой сервис можно запустить 2-я способами: вручную и с помощью конфиг-файла. Рассмотрим оба.
Запуск сервиса вручную
Начнём с создания Replication Controller’а:
Далее создаём service который будет использовать наш Replication Controller как бекенд.
Для http:
Для проверки запущенности можно зайти на любую из нод и выполнить в консоли:
В выводе curl увидим стандартную приветственную страницу nginx. Готово, сервис запущен и доступен.
Запуск сервиса с помощью конфигов
Для этого способа запуска необходимо создать конфиги для Replication Controller’а и service’а. Kubernetes принимает конфиги в форматах yaml и json. Мне ближе yaml поэтому будем использовать его.
Предварительно очистим наш кластер от предыдущего эксперимента:
Был создан Replication Controller с именем nginx и количеством реплик равным 6. Реплики в произвольном порядке запущены на нодах, местоположения каждой pod’ы указано в столбце HOST.
Можно заметить, что при использовании конфига за одним сервисом могут быть закреплены несколько портов.
Применяем конфиг:
Для проверки запущенности можно зайти на любую из нод и выполнить в консоли:
В выводе curl увидим стандартную приветственную страницу nginx.
Заметки на полях
В качестве заключения хочу описать пару важных моментов, о которые уже пришлось запнуться при проектировании системы. Связаны они были с работой kube-proxy, того самого модуля, который позволяет превратить разрозненный набор элементов в сервис.
PORTAL_NET. Сущность сама по себе интересная, предлагаю ознакомиться с тем, как же это реализовано.
Недолгие раскопки привели меня к осознанию простой, но эффективной модели, заглянем в вывод iptables-save:
На этом всё, спасибо за внимание
К сожалению, всю информацию, которую хочется передать, не получается уместить в одну статью.
Про Kubernetes все уши прожужжали. А нужен ли он вашему проекту?
Недавно мы писали статью на VC про аудит Kubernetes. И получили несколько личных сообщений примерно такого характера: «А вы можете по-человечески объяснить, зачем и в каких случаях этот кубернетис нужен? А то все ставят, все хвалят, а понять, нужен ли он моему проекту, — не получается. «
Технически корректный ответ на вопрос «что такое Kubernetes?» — «система для оркестрации контейнезированных приложений» — не особо помогает понять, почему он так популярен в технологических компаниях. Поэтому давайте начнём с того, что попробуем разобраться, почему и для чего компании используют Kubernetes — при этом не прибегая к очевидной формулировке «чтобы управлять контейнерами, зачем же ещё. »
Основная причина использования Kubernetes в компаниях, зарабатывающих на производстве и применении ПО, заключается в том, что изменился подход к разработке. Подход в построении технологических архитектур сместился с больших единых приложений в сторону множества маленьких программ, которые взаимодействуют между собой. Грубо говоря, вместо Microsoft Word разработчики предпочитают делать набор сервисов, наделённых каждый своей функцией, от проверки орфографии до вставки маркированного списка, и объединённых в единую систему. Идея в том, чтобы помогать бизнесу легче внедрять изменения.
Давайте представим, что большое приложение — это дом. В нём нельзя просто убрать одну из стен, другую переместить, а третью переделать на лету из какого-то совершенно иного материала: дом станет неустойчивым или вообще рассыплется. А теперь представим, что приложение похоже на улей. В нём гораздо проще передвигать и изменять соты… Но когда в улье десятки тысяч компонентов, этих микросервисов, и все они работают сами по себе, появляется вопрос: как этим всем управлять? Как узнать, что все они правильно общаются между собой и что ничего не отвалилось? Как не сойти с ума, дирижируя этим оркестром?
Около шести лет назад для этих целей появились специальные системы. Так получилось, что Google и еще несколько компаний выпустили продукт под названием Kubernetes, который оказался гибче и мощнее остальных. Так как его функциональность для управления инфраструктурой различных приложений была шире, Kubernetes набрал большую популярность. Есть и другие решения, например, HashiCorp Nomad и Docker Swarm, но Kubernetes сейчас используется активнее прочих.
Однако бизнесу нужен не Kubernetes как таковой. На идеологическом уровне бизнесу нужна система, которая позволит микросервисной архитектуре не рассыпаться, чтобы бизнес мог постоянно меняться.
С точки зрения бизнеса будет правильнее сказать: «Мы решили быть гибкими, способными легко подстраиваться под запросы рынка и внедрять фичи быстрее конкурентов. И для этого используем подходящую из доступных технологий». А доступная технология, в свою очередь, сейчас это Kubernetes.
Чтобы найти ответ на вопрос «почему?» из заголовка, полезно понять, почему же другие компании стали использовать Kubernetes, какой в этом был бизнес-интерес. Примерить на себя, подходит ли компании переход к микросервисной архитектуре и DevOps. И если да, то имеет смысл внедрить Kubernetes. Но не «внедрить Kubernetes и всё», а изменить процесс разработки.
Исследование DORA’s State of DevOps подсказывает, какие понадобятся изменения, и одно из самых существенных — это сокращение цикла разработки от идеи до доставки пользователю. Чем он короче, чем чаще разработчик выкладывает свой код в продакшен-окружение, тем ниже риск аварий и тем выше гибкость. Частые изменения позволяют быстро проверять гипотезы, но при этом, так как они малы, меньше вероятность серьезных аварий. А если всё же что-то пошло не так, изменения легче откатить и устранить последствия аварии.
Успешный бизнес отличают не конкретные технологические решения, а идеологические и процессные. Так, многие технологичные компании добиваются лидерства, внедряя методологию DevOps. DevOps и другие гибкие подходы к разработке позволяют эффективнее использовать ресурсы и не тратить годы на проект, который, неизвестно, выстрелит или прогорит. С помощью изменений, позволяющих проверить жизнеспособность гипотезы, компании, выбравшие такой путь, минимизируют риски. Но для того, чтобы разрабатывать приложения небольшими шагами, нужно подготовить команду разработки. А для этого, в свою очередь, организовать инфраструктуру: развернуть Kubernetes-кластеры или другую систему, которая будет управлять ульем приложений, и адаптироваться к частым изменениям кодовой базы.
Главное бизнес-преимущество DevOps — снижается количество инвестиций на проверку теорий и запуск новой функциональности.
Раньше, когда эксперимент оказывался неудачным и пользователи требовали «вернуть стену», нужно было откатывать всё приложение на предыдущую версию, разворачивать бэкапы, чтобы вернуть структуру данных, и грустить. Теперь же с современными технологиями можно сделать небольшой редизайн и проверить его на части аудитории (часто экспериментируют на отдельных странах, например, Турции), посмотреть на реакцию пользователей и дальше уже по ситуации, распространить на всех, либо немедленно откатить. К тому же в DevOps-идеологии и с использованием возможностей, которые дают Kubernetes и микросервисная архитектура, меньше ресурсов требуется на тестирование. Так как изменения маленькие, то в процессе разработки новой фичи тестирование и анализ занимают небольшое место. Потому что, если окажется, что есть проблема и она простая, — мы исправим её за несколько минут и выкатим новую версию. Если проблема серьезная — быстро откатимся к предыдущей версии и пользователи не пострадают. Если будет ошибка в тестировании — проверим на стране с маленьким трафиком, поймём, что нужно оптимизировать, и пустим больше трафика. Это всё также сокращает цену эксперимента.
Kubernetes дает унификацию в способе обслуживания всего «улья приложений». Можно сказать, что это задача любой системы оркестрации, но Kubernetes здесь де-факто стандарт. С практической точки зрения распространённость Kubernetes означает уверенность в том, что это решение, которое:
Большое сообщество вокруг ПО — важный (если не решающий) момент. Например, вспомним ситуацию с операционными системами лет пятнадцать лет назад: кроме Linux, были ещё FreeBSD, SunOS и др. У них были свои преимущества, но так получилось, что Linux стал популярней. Во многом это произошло, потому что у Linux была большая группа поддержки, многие люди его использовали, работали над улучшениями и продолжают это делать. С технической точки зрения Kubernetes на своём сайте акцентирует внимание на трёх преимуществах. Попробуем объяснить, что все они значат на практике.
А кроме того, Kubernetes — унифицированная технология, поэтому снижается порог входа новых сотрудников и нет рисков велосипедостроения. Kubernetes применяется в огромном количестве компаний, а значит, не окажется, что всё изначально было сделано неправильно, как может получиться с самописными решениями.
Если вы не знаете, зачем вам Kubernetes, то, вполне возможно, он вам и незачем. Если вы слышите, что все Kubernetes применяют, и думаете, что наверное вам тоже нужно, но не понимаете точно, какую задачу с его помощью собираетесь решать, то Kubernetes вам не нужен. Вопрос, стоит ли применить Kubernetes как техническое решение, примерно такой же, как вопрос, стоит ли перейти с Linux CentOS (упокой господь его душу) на Linux Ubuntu. Фичи там, скорее всего, похожие, и важнее, есть ли в компании люди, которые к этому готовы и которым будет удобнее после перехода, есть ли процессы, которые станут эффективнее, и т.п. Техническое решение в данном случае очень тесно связано с организационными решениями.
Kubernetes не нужен:
Но! Даже в этом случае есть два аргумента в пользу того, чтобы попробовать Kubernetes (точнее, попробовать изменить все свои технологические подходы и к администрированию, и к разработке) отчасти под влиянием популярности. Во-первых, технарям всегда хочется технически развиваться и пробовать что-то новое. Это большой вопрос для бизнеса, стоит ли идти на поводу у любопытства сотрудников, но если его игнорировать, то рано или поздно им станет скучно, и они уйдут. Во-вторых, если вы решитесь на внедрение Kubernetes, то расширить штат будет относительно просто. Всё-таки это самая популярная система оркестрации, и через найти в команду Kubernetes-инженера ощутимо проще, чем знатока того же HashiCorp.
Если вы всё-таки берётесь за внедрение Kubernetes, то нужно решить ещё один вопрос: поднимать его на выделенных серверах или в облаке.
Вариант облака предпочтительнее, потому что Kubernetes изначально ориентирован на облачные хостинг-решения. В облаке легко добавлять узлы, изменять конфигурацию и создавать сущности буквально за минуту.
К тому же облачные провайдеры уже справились с болезнями стабильного дискового хранилища, с которыми придётся столкнуться при разворачивании кластера на собственных серверах. Нет смысла набивать собственные шишки, когда есть AWS, Google Cloud, Azure Cloud, DigitalOcean и российские Яндекс.Облако, Selectel, Mail.Ru Cloud Solutions и другие. С точки зрения гибкости, для которой, собственно, и применяется Kubernetes, правильно использовать их.
Для компаний разного размера на рентабельность решения будут влиять разные факторы.
В небольшом стартапе даже разработчики должны понимать, хотя бы базово, как управлять Kubernetes-кластером и деплоить туда приложения. Это усложняет подбор участников команды, но иначе в стартапе никак. И совершенно точно нужно воспользоваться услугами облачного хостинг-провайдера. Возможно, в этом случае будет сложнее оценить будущие затраты на инфраструктуру, зато полностью снимается вопрос внедрения, потому что в большинстве облаков Kubernetes уже есть по умолчанию.
Средние и крупные компании ждёт тяжелая работа и по подготовке инфраструктуры, и по организационным изменениям. Здесь трудно точно рассчитать все риски и потенциальную пользу и строго определить, при каких условиях начинать внедрение Kubernetes. Но похожая ситуация и с любыми элементами технологического стека, рано или поздно требующими изменений, например, старыми языками программирования. Pearl не то чтобы фундаментально плохой язык программирования, с ним возможно жить. Но ему на смену пришли другие языки, лучше подходящие под современные запросы.
Конечно, стоимость внедрения будет отличаться в зависимости от ситуации и сложности инфраструктуры. Но почти всегда её можно снизить, воспользовавшись облачным хостинг-провайдером, хотя бы за счет того, что не потребуется создавать саму базу инфраструктуры Kubernetes на железных серверах.
Также снизить расходы могут готовые решения. Компании, предоставляющие такие решения, и мы в ITSumma в частности, уже набили шишки, которые не понадобится набивать заново в поисках верного пути. Мы можем проанализировать процессы разработки и найти наиболее удачный канал доставки программного обеспечения в каждом конкретном случае.
Если ваша компания до сих пор не перешла к гибким процессам, у вас длинный цикл разработки и вам кажется, что новые фичи слишком медленно доходят до пользователей, то скорее всего пора что-то менять. И прежде всего менять нужно мышление. Наш совет не в том, чтобы использовать Kubernetes, а в том, чтобы изменится так, чтобы вам потребовался Kubernetes или то, что придёт ему на смену.
Если вы по-прежнему не понимаете, почему все вокруг говорят Kubernetes и зачем он конкретно вам — то и нафиг он вам нужен. Серьёзно.
А если не хотите отставать от лидеров, но вам нужна помощь с адаптацией инфраструктуры под работу с контейнеризированными приложениями или с тем, как, собственно, измениться, — вы знаете, как её найти 🙂