что такое kubernetes и docker
В чем разница между Docker и Kubernetes?
В этой статье мы сравним Docker и Kubernetes, чтобы увидеть, где эти две технологии противостоят друг другу.
Мы также поговорим о некоторых альтернативах инструментам оркестровки, кроме Kubernetes. Далее мы подробно рассмотрим сравнение Docker Swarm и Kubernetes.
Что такое Docker?
Это способ, который позволяет пользователям полностью управлять своим приложением во время разработки и во время запуска, а также смягчает проблемы, возникающие на этих этапах. Он также помогает получить точное представление о том, как приложение должно быть подключено к сети, управляет использованием хранилища и памяти, а также обрабатывает права доступа вне приложения.
Подводя итог, это способ обеспечить согласованную среду на любом OS-совместимом хосте (Linux или Windows).
Особенности Docker
Многие приложения работают на Docker.
Что такое Kubernetes (или K8s)?
Это портативная платформа с открытым исходным кодом, разработанная Google и управляемая облачным вычислительным фондом. Он помогает обновлять приложения более простым и быстрым способом без каких-либо простоев, а также управляет работой планирования контейнеров в кластере и рабочей нагрузкой.
Эта платформа оркестровки автоматизирует многие ручные процессы, такие как развертывание, управление и масштабирование приложений в контейнере.
Особенности Kubernetes
Docker VS Kubernetes
Давайте разберемся в этом подробно с изображением ниже.
Оно показывает, что Docker и Kubernetes идут рука об руку и работают параллельно.
Давайте рассмотрим некоторые сходства между Docker и Kubernetes.
Предпочтение Docker и Kubernetes
Если мы посмотрим на любое приложение с теоретической точки зрения, оно будет выглядеть гладким и без каких-либо проблем. Реальные проблемы можно увидеть только после практической реализации. Точки, которые необходимо учитывать для успешного результата любого приложения, являются:
Затем из Docker или Kubernetes мы должны выбрать один или другой в зависимости от варианта использования.
Когда выбрать Docker?
Когда выбрать Kubernetes?
Что такое Docker Swarm?
Это внутренний инструмент оркестровки контейнеров, разработанный Docker для взаимодействия с контейнерами, работающими в среде Docker. Он используется для кластеризации и планирования. Это позволяет управлять несколькими контейнерами, развернутыми на нескольких хостах. Он использует стандартный интерфейс Docker API и работу в сети, что позволяет легко перейти в любую среду Dcoker.
Заключение
В чём разница между Docker и Kubernetes?
Что такое Docker?
Инструмент контролирует приложения и во время разработки, и в рантайме, помогает управлять хранилищем, памятью и правами приложений, обеспечивает согласованную среду на любом совместимом хосте (* ni x или Windows).
Особенности Docker
Что такое Kubernetes?
Kubernetes – инструмент управления контейнерами, автоматизирующий развёртывание. Это платформа с открытым исходным кодом, разработанная компанией Google, а теперь управляемая Cloud Native. Kubernetes помогает в обновлении приложений простым и быстрым способом, управляет рабочей нагрузкой и планированием контейнеров в кластере, автоматизирует многие ручные процессы, например, управлением приложенияй в контейнере и их масштабированием.
Особенности Kubernetes
Docker vs Kubernetes
Docker и Kubernetes – это разные технологии. Не совсем справедливо сравнивать два этих варианта или ставить вопрос о том, кому из них следует отдать приоритет.
Docker – это контейнерная площадка, а Kubernetes является инструментом оркестровки контейнеров для таких платформ, как Docker.
Разница в Docker и Kubernetes
Docker и Kubernetes часто работают вместе. Docker используется для изоляции приложений в контейнерах, а Kubernetes как планировщик для развёртывания и масштабирования.
Сходства Docker и Kubernetes:
Когда использовать Docker и Kubernetes?
Если в вашей работе используется микросервисная архитектура – берите Docker и назначайте контейнер для каждого микросервиса.
Kubernetes – это быстро развивающаяся технология, но она нужна только если у вас крупный штат разработчиков, которым нужна серьезная продакшн-среда. Для маленького проекта и трёх-четырёх разработчиков накладные расходы могут «съесть» всю пользу.
Муки выбора
Когда и что использовать?
Если организация не привязана к одному облачному провайдеру, то использование Kube является самым разумным. Причина в том, что он работает одинаково на всех системах. Вот почему его называют вендор-независимым.
Что такое Docker Swarm?
Принципы работы
Kubernetes vs Docker Swarm
Развёртывание
Kubernetes: приложения могут быть развёрнуты с использованием сочетания модулей и сервисов/микросервисов.
Docker Swarm: приложения могут быть развёрнуты как сервисы/микросервисы в Swarm-кластере или при помощи Docker Compose. Для обозначения универсальных контейнеров используется файл YAML.
Установка
Kubernetes: здесь установка полностью ручная. Это требует тщательного планирования, чтобы поднять Kube и заставить работать. Процесс установки может отличаться для разных ОС и зависит от поставщика услуг.
Docker Swarm: установка в сравнении с Kubernetes отличается скоростью и простотой. Понадобится лишь один набор инструментов, чтобы научиться строить на его основе среды и конфигурации.
Функционирование
Kubernetes: для перемещения внутри структуры и запуска Kubernetes понадобятся знания и представление о Docker CLI. Для запуска и настройки нужно общее понимание инфраструктуры.
Журналирование
Kubernetes: для развернутой в кластере службы, например Elasticsearch/Kibana, Kubernetes поддерживает несколько версий мониторинга и ведения журнала.
Масштабирование
Docker Swarm: в отличие от Kubernetes, скорость развёртывания контейнеров намного выше. Масштабирование по требованию позволяет добиться быстрого времени реакции.
Kubernetes: сеть в Kube – плоская. Все контейнеры могут общаться друг с другом. В Kubernetes необходимы два CIDR – один для получения IP-адреса, а другой – для внутренних сервисов.
Docker Swarm поддерживает возможность самостоятельно шифровать пользовательский трафик в контейнере во время оверлея.
Выводы
Если вы только начинаете знакомство с контейрными технологиями и вас интересует Docker, обратите внимание на другие наши материалы:
Docker vs. Kubernetes: Давайте жить дружно
В мире современного ПО мало что может сравниться по крутости с Docker и Kubernetes.
Возьмем, к примеру, Docker. Название самой платформы, по сути, уже стало нарицательным и часто используется для обозначения технологии контейнеризации как таковой. Сегодня можно запросто услышать, как разработчик говорит «докер», имея в виду контейнеры в целом, и скорее всего он считает Docker лучшей платформой контейнеризации.
Kubernetes, в свою очередь, называют одной из самых скоростных платформ за всю историю ПО с открытым исходным кодом, и в действительности так оно и есть. Изначально компания Google разрабатывала инструмент для внутреннего пользования под названием Borg, который затем разросся до платформы контейнерной оркестрации с открытым исходным кодом, известной как Kubernetes.
Хотя первопроходцы уже получили хороший гандикап, многие ИТ-специалисты и организации только начинают осваивать контейнеры, технологии контейнерной оркестрации и сопутствующие тренды. В этой статье мы объясним, что такое и Docker, и Kubernetes, а также с чем их едят, разберем главные тренды и сценарии использования, расскажем об основных принципах их работы и ответим на самые животрепещущие вопросы, например: «Обязательно ли я должен выбрать одно или другое?» (спойлер: нет, не обязательно, и мы сейчас объясним, почему).
Docker и контейнеры
Согласно собственному определению Docker, образ контейнера — это «легкий, автономный, исполняемый программный пакет, в котором есть всё необходимое для его выполнения: код, среда выполнения, служебные программы, системные библиотеки и настройки».
Главная причина, по которой название Docker стало нарицательным среди платформ контейнеризации, заключается в том, что Docker первым научился упаковывать расширенные функции ядра Linux вместе, тем самым позволив командам разработчиков быстрее создавать упаковываемые продукты, способные работать на разных серверах.
Контейнеры Docker существенно облегчили жизнь разработчиков, которые теперь могут одинаково эффективно работать в локальных, тестовых, промежуточных и продуктивных средах, везде запуская один и тот же готовый продукт или образ контейнера Docker.
Это ускорило разработку и развертывание: вместо того, чтобы строить с нуля целый сервер для запуска сервиса или приложения, можно запустить образ контейнера Docker на хосте и, задействовав немного ресурсов хоста, запустить сервис или приложение, даже в нескольких средах.
Разница особенно заметна при сравнении с образами традиционных виртуальных машин: контейнеры весят меньше и эфемерны, а значит их можно разворачивать и сворачивать по мере увеличения или уменьшения ресурсов или масштабирования приложения.
Контейнеризация дает много преимуществ в эпоху DevOps, облачных архитектур и набирающих популярность распределенных вычислительных сред, что поспособствовало быстрому и широкому распространению Docker.
Kubernetes и контейнерная оркестрация
Конечно, контейнеризированные процессы могут быть сложными. Первые адепты Docker очень скоро обнаружили, что они заполнили контейнеры сотнями или даже тысячами рабочих нагрузок. Всё это быстро привело к проблемам эксплуатации, ведь масштабируемость стоит денег.
Когда у вас 10 контейнеров и четыре приложения, контейнерная оркестрация — это не повод для беспокойства. Но если у вас 1 000 контейнеров и четыре сотни сервисов, то все уже не так просто. Еще немного, и черт ногу сломит.
Добро пожаловать в эпоху Kubernetes и контейнерной оркестрации. Kubernetes — это инструмент, автоматизирующий развертывание, масштабирование и управление контейнерными приложениями. Автоматизация — ключевое слово и одна из причин, по которой Kubernetes становится все более популярным среди инженеров и других специалистов, отвечающих за работоспособность веб-сайтов, инфраструктур и эксплуатацию систем. Kubernetes позволяет управлять непрерывной оркестрацией тысяч контейнеров, т.е. ваши сервисы будут всегда доступны.
На первых порах организации использовали один из нескольких инструментов с открытым исходным кодом, в том числе Kubernetes, или создавали собственные для управления контейнерами в масштабе. Однако Kubernetes постепенно становится для оркестрации тем, чем Docker уже стал для контейнеризации, т.е. именем нарицательным.
По сути Docker и Kubernetes не исключают, а, наоборот, дополняют друг друга как части более крупной системы, и вопрос выбора между ними просто не стоит. К слову, недавний опрос, проведенный организацией The New Stack, показал, что переход на контейнеры приводит к внедрению Kubernetes, причем оба процесса неразрывно связаны между собой. (Мы подробнее осветим эту тему ниже в обзоре рынка.)
Kubernetes vs. Docker Swarm
О Docker и Kubernetes закрепилось ложное представление как о конкурентах (либо одно, либо другое), но, как говорится, нет дыма без огня. Дело в том, что в экосистеме Docker есть собственное решение для контейнерной оркестрации Docker Swarm — функциональный аналог Kubernetes.
Кто бы ни одержал безоговорочную победу в контейнерной оркестрации, Kubernetes был как никогда к этому близок в 2018 г. Доказательства? Docker добавил мощную поддержку для Kubernetes в начале года, выпустив официальный релиз Docker Enterprise Edition 2.0, которой позволяет пользователям запускать Kubernetes и Docker Swarm на одном кластере.
Иногда, если речь идет не о продуктивной среде, а только о средах разработки или тестирования, использовать контейнеры Docker можно и без Kubernetes. Принято считать, что Docker Swarm легче использовать, тогда как большинству пользователей освоение Kubernetes дается куда труднее.
Однако стоит организациям переместить огромные контейнеризированные рабочие нагрузки в продуктивную среду, сразу становится понятно, что нет ничего лучше Kubernetes (статистические данные будут уже через пару строк). Теперь, когда Docker облегчил бизнесу использование Kubernetes, у этого легендарного дуэта появится еще больше фанатов.
Обзор рынка контейнеризации
Давайте немного сменим тему и посмотрим на ценность контейнеров в долларовом эквиваленте. По прогнозам исследовательской группы 451 Research, рынок контейнеров приложений вырастет с запланированных 1,5 млрд долл. США в 2018 году до 2,7 млрд долл. США в 2020 году. Неплохо, учитывая, что Docker существует всего лишь пять лет, а Kubernetes 1.0 вышел в июле 2015 года.
Достоверные данные о доле рынка контейнеризации достаточно сложно найти, потому что рынок еще только формируется, но приведенные выше цифры указывают на то, что он стремительно растет.
Например, исследовательская группа 451 Research во время ежеквартального опроса Voice of the Enterprise обнаружила, что 23,7% респондентов уже применяют контейнеризацию, а недавний опрос, проведенный компанией New Relic, показал, что эта тенденция гораздо ярче прослеживается среди пользователей публичного облака: 26% респондентов предпочитают пользоваться контейнерами, а 39% — контейнерной оркестрацией. Кроме того, группа 451 Research отмечает, что все больше компаний используют контейнеры в продуктивной среде, т.е. мы сейчас переживаем переходный период, и скоро еще больше компаний будут использовать контейнеры уже не только в средах разработки и тестирования, но и в продуктивной среде.
В марте 2018 года по случаю пятилетнего юбилея Docker компания подвела итоги: скачано 37 млрд контейнеров, 3,5 млн приложений упаковано в контейнеры Docker, более 450 клиентов пользуются корпоративной версией Enterprise Edition.
Kubernetes тоже продолжает завоевывать мир. Организация New Stack опубликовала электронную книгу «Текущее состояние экосистемы Kubernetes», где собран богатый пользовательский опыт и, в частности, сказано, что многие организации не осознают, насколько важна оркестрация, пока не начнут развертывать контейнеры в продуктивной среде.
Данные исследования можно посмотреть на сайте New Stack: 60% организаций, активно использующих контейнеры в продуктивной среде, используют и Kubernetes, а еще 19% — только начали использовать Kubernetes в продуктивной среде. Аналогично, 58% компаний, которые только начинают использовать контейнеры в продуктивной среде, сообщают, что только начали использовать в ней и Kubernetes. При этом 22% респондентов пока думают, стоит ли переходить на Kubernetes.
Последние тренды: Docker и контейнеры
Чем же обусловлен такой спрос на контейнеры? Рассмотрим несколько значимых и часто пересекающихся примеров, когда точно стоит использовать контейнеры:
Последние тренды: Kubernetes и оркестрация
Возможно, главной причиной перехода на Kubernetes, на самом деле, стало внедрение контейнеров. Как уже было сказано выше, многие организации осознают, что использование внушительного количества контейнеров, особенно в продуктивной среде, требует хорошей оркестрации.
Помимо этого, еще несколько трендов повлияли на развитие Kubernetes.
Хотя Docker и Kubernetes появились относительно недавно, они стремительно развиваются и демонстрируют внушительный потенциал. Многие компании и команды DevOps только начинают вгрызаться в этот гранит, и им точно понадобятся крепкие зубы.
Зачем и как использовать контейнеры: разбираемся с Docker, Kubernetes и другими инструментами
Авторизуйтесь
Зачем и как использовать контейнеры: разбираемся с Docker, Kubernetes и другими инструментами
Цитируя разработчиков Docker, «контейнер — это стандартная единица программного обеспечения, в которую упаковано приложение со всеми необходимыми для его работы зависимостями — кодом приложения, средой запуска, системными инструментами, библиотеками и настройками».
Контейнеры используются уже более десяти лет и на сегодняшний день примерно четверть компаний-лидеров в сфере IT задействуют контейнерные решения в продакшене, а ещё столько же, согласно опросам, планировали приступить к этому в 2019-м году.
На рынке существует немало решений, представляющих среды запуска контейнеров и оркестрации, таких как CoreOS rkt, LXC, OpenVZ, containerd, Apache Mesos и Docker Swarm. Однако более 4/5 контейнеров запускается в среде Docker, а для оркестрации более половины пользователей выбрали Kubernetes. Об этих системах мы и поговорим.
Чем полезны контейнеры
Легковесность, быстродействие и возможность работать на высоком уровне абстракции, делегируя проблемы с железом и ОС провайдеру, — это преимущества контейнеров, позволяющие снизить операционные расходы, связанные с разработкой и эксплуатацией приложений, делающих решения на их базе столь привлекательными для бизнеса.
Техническим же специалистам контейнеры прежде всего полюбились за возможность упаковать приложение вместе с его средой запуска, решая тем самым проблему зависимостей в разных окружениях. Например, различие версий языковых библиотек на ноутбуке разработчика и в последующих окружениях рано или поздно приведёт к сбоям, и нужно будет как минимум потратить время на их анализ, а как максимум — решать проблему проникших в продакшен багов. Использование контейнеров устраняет проблему «А на моей машине все работало! ¯\_(ツ)_/¯».
Также контейнеры позволяют сократить время разработки приложения и упрощают управление им в продакшене благодаря лёгкости в настройке и изменении конфигурации, возможности версионировать её вместе с кодом приложения и удобным инструментам оркестрирования, позволяющим быстро масштабировать инфраструктуру. Кроме того, фактическое отсутствие привязки контейнеров к хостинговой платформе даёт огромную гибкость при выборе или смене провайдера — вы можете запускать их без принципиальных отличий в конечном результате на личном компьютере, bare metal серверах и в облачных сервисах.
Чем контейнеры отличаются от виртуальных машин
Наиболее частым вопросом при выборе среды запуска приложения является вопрос о различии между контейнерами и виртуальными машинами — двумя самыми популярными опциями на текущий момент. Между ними есть принципиальная разница. Контейнер, в сущности, является ограниченным внутри ОС пространством, использующим для доступа к аппаратным ресурсам ядро host-системы. ВМ представляет собой машину целиком со всеми необходимыми для её работы устройствами. Из этого образуются отличия, имеющие практическое значение:
Основные принципы контейнеризации приложений
Для эффективной работы приложения в контейнерах недостаточно просто создать образ контейнера и запустить его. Нужно позаботиться о том, чтобы архитектура приложения и контейнера соответствовала базовым принципам контейнеризации, которые хорошо изложила компания RedHat.
1 контейнер — 1 сервис
Контейнер должен выполнять только одну функцию — не следует помещать в него все сущности, от которых зависит приложение. Следование этому принципу позволяет добиться большей переиспользуемости образов и, что самое главное, позволяет более тонко масштабировать приложение — узким местом вашего сервиса может оказаться только какая-то часть используемого стэка технологий, и разведение всех его частей по разным контейнерам позволит точечно увеличивать производительность вашего сервиса.
Неизменность образа
Все изменения внутри контейнера должны вноситься на стадии сборки образа — соблюдение этого принципа страхует вас от утраты данных при уничтожении контейнера. Неизменность контейнера также даёт возможность выполнять параллельные задачи в CI/CD системах — например, можно одновременно запустить разного рода тестирования, ускоряя тем самым процесс разработки продукта.
Утилизируемость контейнеров
Этот принцип являет собой яркий пример современной концепции «Обращайся с инфраструктурой как со скотом, не как с питомцами». Это значит, что любой контейнер может быть в любой момент уничтожен и заменён на другой без остановки обслуживания. Конфигурация контейнера в виде его образа сущностно отделена от непосредственно выполняющего работу экземпляра контейнера, что позволяет «пускать под нож» экземпляры, когда потребуется — при сбое проверки состояния контейнера, масштабировании на понижение и т. д. Соответствие этому принципу означает, что выход контейнеров из строя не должен быть новостью для вашего приложения: ротация контейнеров должна стать одним из требований к разработке.
Отчётность
Контейнер должен иметь точки проверки состояния его готовности (readiness probe) и жизнеспособности (liveness probe), предоставлять логи для отслеживания состояния запущенного в нём приложения.
Управляемость
Приложение в контейнере должно иметь возможность взаимодействовать с контролирующим его процессом — например для корректного завершения своей работы по команде извне. Это позволит аккуратно закрывать транзакции, препятствуя потере пользовательских данных в результате остановки или уничтожения контейнера.
Самодостаточность
Образ с приложением должен обладать всеми необходимыми зависимостями для работы — библиотеками, конфигами и прочим. Сервисы же к этим зависимостям не относятся, иначе это противоречило бы принципу «1 контейнер — 1 сервис». Связность контейнеров, зависящих друг от друга, можно определить с помощью инструментов оркестрирования, о чём будет рассказано ниже.
Лимитирование ресурсов
К лучшим практикам эксплуатации контейнеров относится настройка ресурсных лимитов (CPU и RAM): следование этой практике позволяет сохранять внимательное отношение к экономии ресурсов и вовремя реагировать на их избыточное потребление.
Docker
Когда мы говорим о контейнерах в современных IT-системах, прежде всего мы подразумеваем Docker — open-source-технологию, благодаря своей популярности ставшую в IT синонимом слова «контейнер».
Основные сущности Docker
Dockerfile
Текстовый файл, используемый для создания образа контейнера. Содержит в себе ссылку на базовый образ, служащий отправной точкой при формировании нового образа и набор инструкций для сборки, таких как установка зависимостей, компиляция приложения и копирование конфигов. Также он содержит точку входа в контейнер — команду, выполняемую при его запуске.
Image
Готовая файловая система, сформированная по инструкциям из Dockerfile и служащая прообразом для запускаемых контейнеров.
Instance
Запущенный экземпляр образа, минимальная единица деплоя в Docker.
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), создаст контейнер, используя этот образ, и выдаст приветственную фразу:
Hello from Docker!
This message shows that your installation appears to be working correctly.
.
Оркестрирование контейнеров: Kubernetes
Оркестрирование — это в высокой степени автоматизированный процесс управления связанными сущностями, такими как группы виртуальных машин или контейнеров.
Kubernetes (также встречается в виде акронима K8s) — это совокупность сервисов, реализующих контейнерный кластер и его оркестрирование. Kubernetes не заменяет Docker — он серьёзно расширяет его возможности, упрощая управление развертыванием, сетевой маршрутизацией, расходом ресурсов, балансировкой нагрузки и отказоустойчивостью запускаемых приложений.
NetApp Kubernetes Service позволит создать cloud-agnostic кластер с уже реализованными механизмами деплоя и управления жизненным циклом приложения, автоматическим масштабированием инфраструктуры, интеграцией с сервисами хранилищ данных и многим другим, снизив затраты на конфигурацию и поддержку сложной инфраструктуры.
Основные сущности, которыми оперирует Kubernetes
Node (master и slave)
Узлы, из которых состоит кластер Kubernetes. Master-нода осуществляет контроль над кластером через планировщик и менеджер контроллеров, обеспечивает интерфейс взаимодействия с пользователями посредством API-сервера и содержит хранилище etcd, где находится конфигурация кластера, статусы его объектов и метаданные. Slave-нода предназначена исключительно для запуска контейнеров, для этого на ней установлены два сервиса Kubernetes — сетевой маршрутизатор и агент планировщика.
Namespace
Структурный объект, позволяющий разграничивать ресурсы кластера между пользователями и командами.
Минимальная единица развёртывания в Kubernetes, группа из одного или более контейнеров, собранных для совместного деплоя на ноде. Группировать контейнеры разного вида в Pod имеет смысл, когда они зависят друг от друга и потому должны быть запущены на одной ноде, чтобы сократить время отклика при их взаимодействии. Пример — контейнеры с веб-приложением и кэширующим его сервисом.
ReplicaSet
Объект, описывающий и контролирующий соответствие запущенного на кластере количества реплик Pod’ов. Установка количества реплик больше одной требуется для повышения отказоустойчивости и масштабирования приложения. Общепринято создавать ReplicaSet с помощью Deployment.
Deployment
Объект, декларативно описывающий Pod’ы, количество реплик и стратегию их замены при обновлении параметров.
StatefulSet
Действует по тому же принципу, что и ReplicaSet, однако дополнительно позволяет описывать и сохранять при перезапуске уникальный сетевой адрес Pod’ов или их дисковое хранилище.
DaemonSet
Объект, обеспечивающий контроль за тем, что на каждой ноде (или нескольких выбранных) будет запущено по экземпляру указанного Pod’а.
Job и CronJob
Объекты, запускающие соответственно однократно и регулярно по расписанию указанный Pod и отслеживающие результат завершения его работы.
Label и Selector
Метки, позволяющие маркировать ресурсы и тем самым упрощать групповые манипуляции, связанные с ними.
Service
Инструмент для публикации приложения в качестве сетевого сервиса, в том числе реализующий балансировку нагрузки между Pod’ами приложения.
Если сравнить объекты Docker и Kubernetes, то станет понятна разница в задачах, решаемых этими инструментами: можно сказать, что Docker управляет контейнерами, в то время как Kubernetes управляет самим Docker.
Управление конфигурацией (Configuration/Complexity Management)
Развитие IT-систем ведёт ко всё большему их усложнению, и это порождает проблемы управления — даже на небольшом количестве серверов или контейнеров ручное управление приложением превращает практически любое изменение конфигурации в трудовой подвиг, а на десятках или сотнях делает его абсолютно невозможным. К счастью, новые проблемы ведут и к новым решениям — в этом разделе мы расскажем о некоторых инструментах управления конфигурацией (configuration management) или, как ещё принято говорить, управления сложностью (complexity management). Они используются для установки, управления и обновления приложений Kubernetes: например, с их помощью можно описать приложение, состоящее из фронтенда, бэкенда и всех необходимых для их работы сервисов, таких как объекты Kubernetes, контейнеры с веб-серверами, базами данных, серверами очередей и т. д.
Перечисленные в этом разделе инструменты обладают обширными сообществами и множеством готовых пользовательских конфигураций, что поможет сэкономить массу времени при начальной настройке сервисов, переиспользуя и адаптируя уже написанный другими пользователями код.
Kustomize
Благодаря популярности у пользователей и своей простоте, начиная с версии Kubernetes 1.14, Kustomize является встроенным инструментом управления конфигурацией. Для описания приложений использует чистый язык разметки YAML без возможности шаблонизации и использования параметров, что является одновременно его сильной и слабой сторонами, упрощая процесс настройки и вместе с тем сильно его ограничивая.
Ansible
Многофункциональный инструмент, для которого конфигурация Kubernetes-приложений — лишь одно из великого множества применений, реализованная с помощью специального модуля интеграции. Например, Ansible может быть использован для настройки виртуальных машин, развертывания облачной инфраструктуры, выполнения бэкапов и т.д. Его универсальность позволяет решать разнообразные задачи, связанные с IT-проектами, одним инструментом — но ценой меньшей функциональности в отношении управления конфигурацией приложений Kubernetes. Для описания использует YAML и язык шаблонов Jinja2.
Управляйте хранилищами данных в автоматизированном режиме с помощью модулей интеграции Ansible NetApp.
Jsonnet
Также как и Ansible, Jsonnet не является чем-то специфичным для Kubernetes, однако многие знакомы с ним именно благодаря K8s. Jsonnet описывает объекты с помощью расширенного JSON, включающего комментарии, текстовые блоки, параметры, переменные, условные включения и функции. Очень мощный и гибкий инструмент.
Пакетный менеджер приложений Kubernetes. Этот инструмент описывает приложения в виде декларативных диаграмм (charts), создающихся с помощью языка разметки YAML и шаблонов Golang. Helm обладает широкой базой готовых диаграмм, даёт возможность версионировать конфигурации и переключаться между версиями релизов, т. е. откатывать конфигурацию. Из всех приведенных здесь инструментов является наиболее функциональным в отношении управления приложениями Kubernetes и одновременно обладает наиболее сложным способом описания конфигурации из-за шаблонов Golang, весьма требователен к пользовательским навыкам.
В этой статье перечислены лишь те инструменты, что наиболее заслуживают внимания по нашему мнению. Помимо них существует ещё с добрый десяток решений для задач управления конфигурацией в Kubernetes: такие как Kapitan, Ksonnet, Replicated Ship и т. д. При выборе менеджера управления конфигурацией мы рекомендуем определиться с требованиями, предъявляемыми к нему, и руководствоваться принципом разумной достаточности, не используя без нужды излишне сложный инструмент — хорошим путем будет начать с чего-то простого, дополнительно задействуя более мощный инструмент, когда возникнет необходимость.
Платформы для хостинга контейнеров
Одним из основных моментов при выводе в продакшен контейнерного приложения является выбор того, где же в конечном счёте это приложение будет запущено. В этой части статьи мы постараемся помочь вам, описав два основных на сегодняшний день варианта, их сильные и слабые стороны.
Своё железо (bare metal)
Этот подход можно назвать консервативным — выбрав его, вы покупаете или арендуете серверы, нанимаете специалистов и строите свой собственный кластер. Очевидные его плюсы — тонкая настройка, возможность полного контроля над инфраструктурой и, как следствие, превосходящая производительность с более высокой отдачей от бюджета в долгой перспективе. Из минусов можно отметить большие финансовые (в том числе капитальные) и временные затраты на конфигурацию и поддержку, а также зависимость от специалистов по её поддержке. Как правило, этот вариант выбирают компании, имеющие выверенные долгосрочные планы, уже обеспеченные солидным бюджетом.
Облачные решения (SaaS)
Крупные облачные провайдеры предоставляют своим клиентам сервисы для запуска контейнеров — готовые среды, обёрнутые удобным интерфейсом управления. Построенные по такому принципу решения называются Software as a Service (SaaS). Они не требуют никаких капитальных затрат, поскольку вся инфраструктура арендуется, а конфигурация создаётся в минимальном объёме, относящемуся исключительно к запускаемому приложению. Сами же кластеры настраиваются провайдером по указанному пользователем небольшому объему параметров. SaaS-решения — оптимальный вариант для стартап-компаний, небольших и развивающихся проектов. Самым большим минусом этого решения можно назвать повышенную в сравнении с bare metal стоимость при условии многолетнего использования.
Хотите обеспечить максимальную сохранность данных, создаваемых и используемых в контейнерах? NetApp Trident позволит легко интегрировать в вашу контейнерную инфраструктуру надежное и функциональное хранилище данных enterprise-уровня.
Заключение
Ещё недавно не смолкали дебаты на тему оправданности использования контейнеров в продакшене, то и дело были слышны обвинения в их ненадежности. Однако время не стоит на месте, индустрия оценила их перспективность, сделала свой выбор, и инвестиции в контейнерные решения потекли широкой рекой, с каждым днем делая решения на их базе всё удобнее и привлекательнее. На сегодняшний день примитивную настройку кластера и деплой приложений в него можно выполнить используя один лишь веб-интерфейс, предварительно прочитав несколько страниц документации — настолько это стало просто. А их низкая по сравнению с виртуальными машинами стоимость откусывает у ВМ всё большую долю рынка, забирая то, что не требует для своей работы специфики устройства ВМ. Безусловно, контейнеры зарекомендовали себя как жизне- и конкурентоспособное решение, сокращающее время вывода продукта на рынок, стоимость его разработки и эксплуатации.
Рассказывает Сергей Бродин. Текст подготовили вместе с NetApp