Зачем и как использовать контейнеры: разбираемся с docker, kubernetes и другими инструментами

Будущее Docker: сосуществование Docker и VM

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

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

Более того, контейнеры позволяют разбить ваше приложение на более функциональные отдельные части, чтобы создать разделение задач. Это также означает, что появится большое число частей для управления, и они могут быть громоздкими.

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

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

Применение двойного клика к контейнерам

Фух! Как много подвижных частей. Меня всегда интересовало: а как контейнеры вообще создаются? Вокруг них ведь нет какой-то абстрактной инфраструктуры. Я много читал, и теперь все стало ясно. Я попытаюсь объяснить это вам!

Термин «контейнер» на самом деле является просто абстрактным понятием, описывающим, как несколько различных функций работают вместе для визуализации «контейнера». Давайте очень быстро пробежимся по ним:

1) Пространства имен

Пространства имен предоставляют контейнерам свое собственное представление о базовой системе Linux. Это ограничивает то, что контейнер может видеть и к чему он может получать доступ. Когда вы запускаете контейнер, Docker создает пространства имен, которые будет использовать конкретный контейнер.

В ядре используется несколько различных типов пространств имен, например:

a. NET: Предоставляет контейнер с собственным представлением сетевого стека системы (например, собственные сетевые устройства, IP-адреса, таблицы IP-маршрутизации, каталог /proc/net, номера портов и т. д.);

b. PID: PID обозначает идентификатор процесса. Если вы когда-нибудь запускали в командной строке, чтобы проверить, какие процессы запущены в вашей системе, вы видели столбец с названием «PID». Пространство имен PID дает контейнерам свое собственное видение процессов, которые они могут просматривать и с которыми способны взаимодействовать, включая независимый init (PID 1), который является «предком всех процессов»;

c. MNT: дает контейнеру собственное представление о «монтировании» в системе. Таким образом, процессы в разных пространствах имеют разные представления об иерархии файловой системы;

d. UTS: UTS обозначает UNIX Timesharing System. Это позволяет процессу идентифицировать системные идентификаторы (т. е. имя хоста, имя домена и т. д.). UTS позволяет контейнерам иметь свое собственное имя хоста и имя домена NIS, которое не зависит от других контейнеров и хост-системы;

e. IPC: IPC расшифровывается как InterProcess Communication. Пространство имен IPC отвечает за изоляцию ресурсов IPC между процессами, выполняющимися внутри каждого контейнера;

f. USER: это пространство имен используется для изоляции пользователей в каждом контейнере. Он функционирует, позволяя контейнерам иметь другое представление диапазонов uid (идентификатор пользователя) и gid (идентификатор группы) по сравнению с хост-системой. В результате uid и gid процесса могут различаться внутри и снаружи пространства имен пользователя. Это позволяет процессу иметь непривилегированного пользователя вне контейнера, не жертвуя привилегиями root внутри него.

Docker использует эти пространства имен вместе, чтобы изолировать и начать создание контейнера. Следующий элемент — контрольные группы.

2) Контрольные группы

Контрольные группы (также называются cgroups) — это функция ядра Linux, которая изолирует, расставляет приоритеты и учитывает использование ресурсов (ЦП, память, дисковый ввод-вывод, сеть и т. д.) для набора процессов. Cgroup гарантирует, что контейнеры Docker используют только те ресурсы, которые им необходимы, и при необходимости устанавливает ограничения на то, какие ресурсы контейнер может использовать. Cgroups также гарантирует, что единственный контейнер не исчерпает один из этих ресурсов и не разрушит всю систему.

Наконец, Docker также использует Union FS.

3) Изолированная Union FS

Описана выше в разделе «Docker Image».

Вот и все, что существует в контейнере Docker. Конечно, все трудности начинаются в деталях осуществления: например, как управлять взаимодействиями между различными компонентами?

Контейнеры

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

С точки зрения всех целей и задач контейнеры ничем не отличаются от виртуальных машин. Например, они могут иметь личное пространство для обработки, выполнять команды, такие как root, иметь частный сетевой интерфейс и IP-адрес, разрешать кастомные маршруты и правила iptable, монтировать файловые системы и т. д.

Единственное крупное различие между контейнерами и виртуальными машинами заключается в том, что контейнеры используют ядро хост-системы совместно с другими контейнерами.

На этой диаграмме показано, что контейнеры содержат только пользовательское пространство, а не ядро или виртуальное оборудование, как в случае с VM. Каждый контейнер Docker получает свое изолированное пользовательское пространство, позволяющее нескольким контейнерам запускаться на одном хосте. Мы видим, что вся архитектура ОС делится между контейнерами. С нуля создаются только файлы bin, lib. Именно поэтому контейнеры такие легкие.

Основные принципы контейнеризации приложений

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

1 контейнер — 1 сервис

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

Неизменность образа

Все изменения внутри контейнера должны вноситься на стадии сборки образа — соблюдение этого принципа страхует вас от утраты данных при уничтожении контейнера. Неизменность контейнера также даёт возможность выполнять параллельные задачи в CI/CD системах — например, можно одновременно запустить разного рода тестирования, ускоряя тем самым процесс разработки продукта.

Утилизируемость контейнеров

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

Отчётность

Контейнер должен иметь точки проверки состояния его готовности (readiness probe) и жизнеспособности (liveness probe), предоставлять логи для отслеживания состояния запущенного в нём приложения.

Управляемость

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

Самодостаточность

Образ с приложением должен обладать всеми необходимыми зависимостями для работы — библиотеками, конфигами и прочим. Сервисы же к этим зависимостям не относятся, иначе это противоречило бы принципу «1 контейнер — 1 сервис». Связность контейнеров, зависящих друг от друга, можно определить с помощью инструментов оркестрирования, о чём будет рассказано ниже.

Лимитирование ресурсов

К лучшим практикам эксплуатации контейнеров относится настройка ресурсных лимитов (CPU и RAM): следование этой практике позволяет сохранять внимательное отношение к экономии ресурсов и вовремя реагировать на их избыточное потребление.

Examples

Filtering

The filtering flag () format is of “key=value”. If there is more
than one filter, then pass multiple flags (e.g., )

The currently supported filters are:

• until () — only remove containers created before given timestamp
• label (, , , or ) — only remove containers with (or without, in case is used) the specified labels.

The filter can be Unix timestamps, date formatted
timestamps, or Go duration strings (e.g. , ) computed
relative to the daemon machine’s time. Supported formats for date
formatted time stamps include RFC3339Nano, RFC3339, ,
, , and . The local
timezone on the daemon will be used if you do not provide either a or a
timezone offset at the end of the timestamp. When providing Unix
timestamps enter seconds, where seconds is the number of seconds
that have elapsed since January 1, 1970 (midnight UTC/GMT), not counting leap
seconds (aka Unix epoch or Unix time), and the optional .nanoseconds field is a
fraction of a second no more than nine digits long.

The filter accepts two formats. One is the ( or ),
which removes containers with the specified labels. The other
format is the ( or ), which removes
containers without the specified labels.

The following removes containers created more than 5 minutes ago:

The following removes containers created before :

Простая аналогияA simple analogy

Возможно, небольшая аналогия поможет вам быстрее освоить ключевую концепцию Docker.Perhaps a simple analogy can help getting the grasp of the core concept of Docker.

Вернемся ненадолго назад во времени, в 1950-е годы.Let’s go back in time to the 1950s for a moment. Тогда еще не было текстовых редакторов, и повсеместно использовались фотокопировальные устройства (то есть то, что тогда так называлось).There were no word processors, and the photocopiers were used everywhere (kind of).

В какой-то момент вы понимаете, что каждое письмо составлено из широкого набора абзацев, которые выбираются и упорядочиваются по мере необходимости с учетом назначения письма. Вы создаете систему, которая быстро создает нужные письма, и обоснованно надеетесь на существенную прибавку.At some point, you realize the letters are just a composition of a large set of paragraphs, which are picked and arranged as needed, according to the purpose of the letter, so you devise a system to issue letters quickly, expecting to get a hefty raise.

Вы создали простую систему со следующим алгоритмом:The system is simple:

1. У вас есть пачка прозрачных листов, каждый из которых содержит один абзац.You begin with a deck of transparent sheets containing one paragraph each.

2. Чтобы подготовить комплект писем, вы отбираете листы с нужными абзацами, собираете их в стопку и выравниваете так, чтобы все правильно читалось.To issue a set of letters, you pick the sheets with the paragraphs you need, then you stack and align them so they look and read fine.

3. Теперь вы помещаете готовый набор в фотокопировальное устройство и нажмите кнопку запуска, чтобы изготовить нужное количество копий.Finally, you place the set in the photocopier and press start to produce as many letters as required.

Это и есть основная концепция Docker в упрощенной форме.So, simplifying, that’s the core idea of Docker.

В Docker каждый слой представляет некоторый набор изменений, которые применяются к файловой системе после выполнения команды, такой как установка программы.In Docker, each layer is the resulting set of changes that happen to the filesystem after executing a command, such as, installing a program.

Если вы «посмотрите» на файловую систему после копирования очередного слоя, вы увидите все файлы в том состоянии, которое они приняли после установки программы.So, when you «look» at the filesystem after the layer has been copied, you see all the files, included the layer when the program was installed.

Такой образ можно рассматривать как дополнительный жесткий диск, доступный только для чтения, который готов к установке на «компьютер» с уже установленной операционной системой.You can think of an image as an auxiliary read-only hard disk ready to be installed in a «computer» where the operating system is already installed.

Соответственно, роль «компьютера» здесь выполняет контейнер, в который устанавливается жесткий диск этого образа.Similarly, you can think of a container as the «computer» with the image hard disk installed. Контейнер, как и обычный компьютер, можно включать и отключать.The container, just like a computer, can be powered on or off.

Контейнеры — это Linux

Давайте сразу определим для себя, что представляют собой контейнеры, и чем они отличаются от виртуальных машин, чтобы избежать путаницы которая часто случается между ними. Контейнер — это набор ограничений для запуска приложений, которые поддерживаются ядром (kernel) операционной системы Linux. Эти ограничения заставляют приложение исполняться в закрытой файловой системе, со своим пространством процессов (приложение не видит процессы вне своей группы), и с квотами на использование памяти, мощности процессоров CPU, дисков, и возможно сети. При этом у приложения в таком ограниченном пространстве существует свой сетевой IP-адрес и полный набор портов, а также полная поддержка ядра системы — устройств ввода/вывода, управление памятью и процессором, многозадачность, и наконец самое главное, возможность установить любые расширения и библиотеки, не беспокоясь о конфликтах с другими приложениями.

Можно сказать, что приложение, запускающееся в контейнере Linux, “видит” стандартное ядро (kernel) операционной системы, так, как если бы ничего кроме этого приложения, и этого ядра, больше не существовало. Файловая система пуста, нет никаких дополнительных пакетов и библиотек, интерпретаторов shell и тем более никакого намека на графический интерфейс GUI. Примерно так же “ощущает” себя приложение, запускающееся в виртуальной машине, на которой установлена операционная система Linux, только в крайне урезанном варианте.

Иметь только возможности ядра Linux для большинства современных приложений недостаточно, они как правило зависят от множества расширений и библиотек, а также имеют свои файлы с данными. Здесь контейнеры также хороши — приложение свободно распоряжаться своим пространством контейнера так, как если бы оно находилось на своем отдельном виртуальном (или реальном) сервере. Возможно установить любые пакеты, расширения, библиотеки и скопировать файлы и данные внутрь контейнера, не опасаясь конфликтов. Все это будет закрыто внутри контейнера и недоступно другим приложениям из других контейнеров.

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

“Что же, если я использую Mac OS или Windows?” спросите вы? Благодаря инструментам Docker контейнеры Linux доступны на любых популярных операционных системах. Еще раз вспомним, что для работы контейнеров требуется доступ к минимальному ядру Linux — именно это и предоставляет Docker, как правило с помощью скрытой внутри него минимальной виртуальной машиной. Отличная возможность не только использовать контейнеры, но и получить доступ к настоящему ядру Linux за считанные секунды на любой операционной системе и лэптопе без запуска тяжелых виртуальных машин с полной операционной системой!

Хотя идея контейнеров и сама их суть — это операционная система Linux, их растущая популярность и прекрасно подходящая для облачных приложений архитектура не могла пройти мимо всех провайдеров облака, особенно облака Microsoft Azure с большим фокусом внимания на серверные варианты операционных систем Windows. Компания Microsoft уже поддерживает контейнеры (и Docker) в своих операционных системах без использования виртуальных машин. Конечно это уже не Linux, но если вы работаете с кодом .Net, это неоценимая возможность использовать архитектуру контейнеров не переписывая свои приложения.

Когда же в дело вступает Docker?

Docker — проект с открытым исходным кодом, основанный на контейнерах Linux. Он использует функции ядра Linux, такие как пространства имен и контрольные группы, для создания контейнеров поверх ОС.

Контейнеры — это не новое изобретение. Google использует собственные технологии контейнеров уже многие годы. Другие технологии контейнеров на Linux включают в себя Solaris Zones, BSD jails и LXC, которые существуют уже много лет.

Так почему же Docker внезапно набирает обороты?

1. Простота использования: Docker упростил для всех (разработчиков, системных администраторов, архитекторов и других) использование контейнеров для быстрой сборки и тестирования портативных приложений. Это позволяет кому угодно передавать приложение на свой ноутбук. Такое приложение, в свою очередь, может работать без изменений в любом общедоступном облаке, в частном облаке или даже на чистом сервере. Девиз таков: «Создайте один раз, запускайте откуда угодно»;
2. Скорость: Контейнеры в Docker очень легкие и быстрые. Поскольку контейнеры — это помещенные в «песочницу» среды, работающие на ядре, они потребляют меньше ресурсов. На создание и запуск Docker контейнеров тратятся мгновения по сравнению с VM. Работа с ними может занять больше времени, потому что каждый раз они должны загружать полную виртуальную ОС;
3. Docker Hub: Пользователи Docker также получают выгоду от все больше богатеющей экосистемы Docker Hub, которую вы можете назвать «магазином приложений для образов Docker». Docker Hub содержит десятки тысяч общедоступных образов, созданных сообществом. Они легко доступны для использования. Теперь невероятно легко найти образы, которые отвечают вашим потребностям. Их уже можно взять и использовать практически без изменений;
4. Модульность и масштабируемость: Docker позволяет легко разбить функциональность вашего приложения на отдельные контейнеры. Например, ваша база данных Postgres может работать в одном контейнере, а сервер Redis — в другом, приложение Node.js — в третьем. С Docker стало проще связать эти контейнеры вместе для создания приложения. В будущем это упростит масштабирование или обновление компонентов независимо друг от друга.

И наконец: кто же не любит кита Docker?

Чем полезны контейнеры

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

Техническим же специалистам контейнеры прежде всего полюбились за возможность упаковать приложение вместе с его средой запуска, решая тем самым проблему зависимостей в разных окружениях. Например, различие версий языковых библиотек на ноутбуке разработчика и в последующих окружениях рано или поздно приведёт к сбоям, и нужно будет как минимум потратить время на их анализ, а как максимум — решать проблему проникших в продакшен багов. Использование контейнеров устраняет проблему «А на моей машине все работало! ¯\_(ツ)_/¯».

Также контейнеры позволяют сократить время разработки приложения и упрощают управление им в продакшене благодаря лёгкости в настройке и изменении конфигурации, возможности версионировать её вместе с кодом приложения и удобным инструментам оркестрирования, позволяющим быстро масштабировать инфраструктуру. Кроме того, фактическое отсутствие привязки контейнеров к хостинговой платформе даёт огромную гибкость при выборе или смене провайдера — вы можете запускать их без принципиальных отличий в конечном результате на личном компьютере, bare metal серверах и в облачных сервисах.

Docker

Когда мы говорим о контейнерах в современных IT-системах, прежде всего мы подразумеваем Docker — open-source-технологию, благодаря своей популярности ставшую в IT синонимом слова «контейнер».

Основные сущности Docker

Dockerfile

Текстовый файл, используемый для создания образа контейнера. Содержит в себе ссылку на базовый образ, служащий отправной точкой при формировании нового образа и набор инструкций для сборки, таких как установка зависимостей, компиляция приложения и копирование конфигов. Также он содержит точку входа в контейнер — команду, выполняемую при его запуске.

Image

Готовая файловая система, сформированная по инструкциям из Dockerfile и служащая прообразом для запускаемых контейнеров.

Volume

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

Registry

Репозиторий, используемый для хранения Docker-образов. Registry может быть как публичным, так и приватным, защищённым механизмом аутентификации.

Процесс разработки в среде Docker

Типичный процесс разработки в среде Docker выглядит следующим образом: разработчики устанавливают на свои машины Docker, загружают собранный заранее образ с установленной средой сборки и выполнения приложения, а затем запускают контейнер командой, которая также пробросит в него директорию с исходниками. Для установки Docker не требуется особого железа — он может быть установлен на вполне заурядной машине. Однако у него имеются ограничения по версиям ОС — Windows 7 64bit или выше для ПК с поддержкой Hyper-V, macOS Sierra 10.12 для устройств от Apple и версией ядра 3.10 для систем с Linux. Контейнеры Docker являются родной технологией для ОС Linux и запускаются на других с помощью виртуальных машин под её управлением.

Инструкции по установке Docker на разных платформах: Windows, Mac, Linux Ubuntu.

Чтобы запустить ваш первый контейнер на Docker, после его установки введите в командной строке docker run hello-world — эта команда загрузит образ hello-world с Docker hub’а (публично доступный Docker registry), создаст контейнер, используя этот образ, и выдаст приветственную фразу:

Related commands

Управление конфигурацией (Configuration/Complexity Management)

Развитие IT-систем ведёт ко всё большему их усложнению, и это порождает проблемы управления — даже на небольшом количестве серверов или контейнеров ручное управление приложением превращает практически любое изменение конфигурации в трудовой подвиг, а на десятках или сотнях делает его абсолютно невозможным. К счастью, новые проблемы ведут и к новым решениям — в этом разделе мы расскажем о некоторых инструментах управления конфигурацией (configuration management) или, как ещё принято говорить, управления сложностью (complexity management). Они используются для установки, управления и обновления приложений Kubernetes: например, с их помощью можно описать приложение, состоящее из фронтенда, бэкенда и всех необходимых для их работы сервисов, таких как объекты Kubernetes, контейнеры с веб-серверами, базами данных, серверами очередей и т. д.

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

Kustomize

Благодаря популярности у пользователей и своей простоте, начиная с версии Kubernetes 1.14, Kustomize является встроенным инструментом управления конфигурацией. Для описания приложений использует чистый язык разметки YAML без возможности шаблонизации и использования параметров, что является одновременно его сильной и слабой сторонами, упрощая процесс настройки и вместе с тем сильно его ограничивая.

Ansible

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

Jsonnet

Также как и Ansible, Jsonnet не является чем-то специфичным для Kubernetes, однако многие знакомы с ним именно благодаря K8s. Jsonnet описывает объекты с помощью расширенного JSON, включающего комментарии, текстовые блоки, параметры, переменные, условные включения и функции. Очень мощный и гибкий инструмент.

Helm

Пакетный менеджер приложений Kubernetes. Этот инструмент описывает приложения в виде декларативных диаграмм (charts), создающихся с помощью языка разметки YAML и шаблонов Golang. Helm обладает широкой базой готовых диаграмм, даёт возможность версионировать конфигурации и переключаться между версиями релизов, т. е. откатывать конфигурацию. Из всех приведенных здесь инструментов является наиболее функциональным в отношении управления приложениями Kubernetes и одновременно обладает наиболее сложным способом описания конфигурации из-за шаблонов Golang, весьма требователен к пользовательским навыкам.

В этой статье перечислены лишь те инструменты, что наиболее заслуживают внимания по нашему мнению. Помимо них существует ещё с добрый десяток решений для задач управления конфигурацией в Kubernetes: такие как Kapitan, Ksonnet, Replicated Ship и т. д. При выборе менеджера управления конфигурацией мы рекомендуем определиться с требованиями, предъявляемыми к нему, и руководствоваться принципом разумной достаточности, не используя без нужды излишне сложный инструмент – хорошим путем будет начать с чего-то простого, дополнительно задействуя более мощный инструмент, когда возникнет необходимость.

Платформы для хостинга контейнеров

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

Своё железо (bare metal)

Этот подход можно назвать консервативным — выбрав его, вы покупаете или арендуете серверы, нанимаете специалистов и строите свой собственный кластер. Очевидные его плюсы — тонкая настройка, возможность полного контроля над инфраструктурой и, как следствие, превосходящая производительность с более высокой отдачей от бюджета в долгой перспективе. Из минусов можно отметить большие финансовые (в том числе капитальные) и временные затраты на конфигурацию и поддержку, а также зависимость от специалистов по её поддержке. Как правило, этот вариант выбирают компании, имеющие выверенные долгосрочные планы, уже обеспеченные солидным бюджетом.

Облачные решения (SaaS)

Крупные облачные провайдеры предоставляют своим клиентам сервисы для запуска контейнеров — готовые среды, обёрнутые удобным интерфейсом управления. Построенные по такому принципу решения называются Software as a Service (SaaS). Они не требуют никаких капитальных затрат, поскольку вся инфраструктура арендуется, а конфигурация создаётся в минимальном объёме, относящемуся исключительно к запускаемому приложению. Сами же кластеры настраиваются провайдером по указанному пользователем небольшому объему параметров. SaaS-решения — оптимальный вариант для стартап-компаний, небольших и развивающихся проектов. Самым большим минусом этого решения можно назвать повышенную в сравнении с bare metal стоимость при условии многолетнего использования.

Тремя наиболее популярными облачными платформами на сегодня являются Amazon Web Services, Microsoft Azure и Google Cloud. Все три провайдера имеют доступный в виде сервиса Kubernetes, и все три из них предлагают пробный период пользования сервисами, выдавая депозит на сумму 200–300 $. Чтобы оценить удобство и качество облачных решений и сравнить друг с другом их поставщиков, вам даже не придется тратить свои деньги.