​Kubernetes и Docker

Различия и сходства между двумя наиболее влиятельными проектами с открытым исходным кодом в области облачных вычислений.

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

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

Симбиоз между Kubernetes и Docker

Сам вопрос «Kubernetes или Docker?» довольно абсурден, это как сравнивать яблоки с апельсинами. Одно не является альтернативой другому. Совсем наоборот, Kubernetes может работать без Docker, а Docker может функционировать без Kubernetes. Но Kubernetes может (и действительно) значительно выигрывает от Docker, и наоборот.

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

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

Зачем вообще нужны несколько узлов? Две основные причины этого:

1. Для повышения надежности инфраструктуры — ваше приложение будет доступно онлайн, даже если некоторые узлы выйдут из строя, то есть, будет обеспечена высокая доступность.

2. Чтобы сделать ваше приложение более масштабируемым — при увеличении рабочей нагрузки просто запустите больше контейнеров и/или добавьте больше узлов в ваш кластер Kubernetes.

«Kubernetes автоматизирует процесс масштабирования, управления, обновления и удаления контейнеров. Другими словами, это платформа оркестровки контейнеров. Хотя Docker лежит в основе контейнеризации, он позволяет нам вообще использовать контейнеры».

Различия между Kubernetes и Docker

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

Аналогичным образом, компания Docker Inc., создатель Docker, предлагает собственный механизм оркестровки контейнеров под названием Docker Swarm. Но даже они осознали тот факт, что Kubernetes достиг такого уровня развития, что даже Docker для настольных компьютеров (MacOS и Windows) поставляется со своим собственным дистрибутивом Kubernetes.

Если кто-то опасался внедрения Kubernetes в свой продукт на основе Docker, то последний пункт развеет все сомнения. Оба проекта с энтузиазмом дополнили друг друга и получили огромную пользу от этого симбиоза.

Сходства между Kubernetes и Docker

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

Вот некоторые из идей, которые разделяют и Kubernetes, и Docker:

- Их любовь к архитектуре на основе микросервисов (подробнее об этом позже).

- Их объединяет любовь к сообществу открытого исходного кода. Оба проекта в значительной степени являются проектами с открытым исходным кодом.

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

- Они используют удобочитаемые YAML-файлы для описания стеков приложений и их развертывания.

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

Давайте углубимся в эту тему...

Что такое Docker?

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

Давайте подробнее рассмотрим две разные точки зрения...

Обзор контейнеров Docker

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

Компания VMware одной из первых популяризировала эту концепцию. Однако у виртуализации есть несколько проблем. Во-первых, выделение ресурсов занимает время. Каждый образ виртуального диска большой и громоздкий, и подготовка виртуальной машины к использованию может занять до минуты!

Во-вторых, и это более важная проблема, — неэффективное использование системных ресурсов. Ядра операционных систем — это перфекционисты, которые хотят управлять всем, что, по их мнению, им доступно. Поэтому, когда гостевая ОС считает, что ей доступно 2 ГБ памяти, она берет под контроль эту память, даже если приложения, работающие под этой ОС, используют только половину из нее.

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

Docker — как инструмент для разработчиков

Одна из проблем, с которыми сталкиваются разработчики, — это разница между производственным сервером, на котором работают приложения, и их собственными машинами для разработки (обычными ноутбуками и рабочими станциями), где разрабатываются приложения. Представим, что у вас на настольном компьютере установлена Windows 10, но вы хотите писать приложения для Ubuntu 18.04. Возможно, вы используете Python версии 3.6 для написания приложения, в то время как сервер Ubuntu все еще работает на Python версии 3.4.

Слишком много переменных нужно учитывать, поэтому мы используем Docker, чтобы абстрагироваться от этой сложности. Docker можно установить на любую ОС, даже Windows и Mac OS X хорошо поддерживаются. Таким образом, вы можете упаковать свой код в образ Docker, запустить и протестировать его локально, используя Docker, чтобы гарантировать, что контейнеры, созданные из этого образа Docker, будут вести себя так же в производственной среде.

Примечание: Все зависимости, такие как версия языка программирования, стандартная библиотека и т. д., содержатся в этом образе.

Такой подход к образам Docker как к программному пакету привел к появлению следующей популярной цитаты:

«Docker сделает с pt то же, что pt сделал с tar».

Apt, менеджер пакетов, по-прежнему использует tar, но пользователям не нужно об этом беспокоиться. Аналогично, при использовании Docker нам никогда не придется беспокоиться о менеджере пакетов, хотя он все равно будет присутствовать. Даже при разработке, например, на основе технологии Node.js, разработчики предпочитают создавать свои образы Docker на основе официального образа Docker для Node.

Итак, это краткий обзор того, что такое Docker и почему стоит о нем знать, даже если вы не работаете в сфере DevOps.

Теперь перейдём к Kubernetes.

Что такое Kubernetes?

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

Если вы посетите их официальный сайт , Kubernetes довольно ясно заявляет о своем предназначении следующим образом:

«Kubernetes — это система с открытым исходным кодом для автоматизации развертывания, масштабирования и управления контейнеризированными приложениями».

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

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

Архитектура Kubernetes — краткий обзор

Существует два основных понятия, которые необходимо знать о кластере Kubernetes. Первое — это узел (node). Это распространенный термин для виртуальных машин и/или физических серверов, которыми управляет Kubernetes. Второе — это под (pod), базовая единица развертывания в Kubernetes. Под — это набор связанных контейнеров Docker, которые должны сосуществовать вместе. Например, ваш веб-сервер может быть развернут вместе с сервером кэширования Redis, поэтому вы можете объединить их в один под. Kubernetes развертывает их параллельно. Если вам так проще, вы можете представить себе под, состоящий из одного контейнера, и это будет вполне понятно.

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

Вот краткое изложение схемы Kubernetes, показанной выше.

На главном узле Kubernetes у нас есть:

1. kube-controller-manager: Этот компонент отвечает за учет текущего состояния кластера (например, X количество запущенных подов) и принятие решений для достижения желаемого состояния (например, наличие Y количества активных подов). Он прослушивает kube-apiserver для получения информации о состоянии кластера.

2.

3. kube-scheduler: Этот компонент определяет, как будут планироваться события и задания в кластере в зависимости от доступности ресурсов, политики, установленной операторами, и т. д. Он также отслеживает состояние кластера с помощью kube-apiserver.

4. etcd: Это «стек хранения» для главных узлов Kubernetes. Он использует пары ключ-значение и применяется для сохранения политик, определений, секретов, состояния системы и т. д.

Мы можем использовать несколько главных узлов, чтобы Kubernetes мог выжить даже в случае отказа одного из них.

На рабочем узле у нас есть:

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

- kube-proxy: Этот сетевой прокси позволяет различным микросервисам вашего приложения взаимодействовать друг с другом внутри кластера, а также, при желании, предоставлять доступ к вашему приложению остальному миру. В принципе, каждый под может взаимодействовать с каждым другим подом через этот прокси.

- Docker: Это последний недостающий элемент головоломки. На каждом узле установлен Docker Engine для управления контейнерами.

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

Внедрение Docker и Kubernetes в масштабах всей отрасли

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

Docker в производственной среде

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

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

Kubernetes в производственной среде

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

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

«Это довольно рискованно, если у вас нет глубоких знаний системы. Всё может легко выйти из строя».

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

Однако существуют облачные платформы Kubernetes, которые организации могут использовать для запуска своих приложений. Доступность центров обработки данных по всему миру, предлагаемых такими компаниями, как AWS, Azure, Joyent или GCE, может помочь вам максимально эффективно использовать распределенную природу Kubernetes. И, конечно же, вам не нужно беспокоиться о поддержке кластера.

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

Итак, Kubernetes в продакшене? Да, но большинству пользователей я бы рекомендовал облачные решения.

Контейнеры и новая эра облачных вычислений

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

Автоматизированные сборки стали намного проще благодаря Dockerfile. Сложные развертывания с использованием нескольких контейнеров теперь стандартизированы благодаря docker-compose. Программисты довели использование контейнеров до логического предела, создав комплексные решения для CI/CD, включающие сборку и тестирование образов Docker, а также управление публичными или частными реестрами Docker.

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

Аргументы в пользу распределенной операционной системы

Теперь, когда я высказал своё недовольство по поводу компаний, внедряющих Kubernetes, не до конца понимая его суть, позвольте мне привести аргументы в пользу того, почему вам следует внедрить Kubernetes. Облачные вычисления превратились в высококонкурентный рынок, где Google, Microsoft, Amazon и многие другие игроки соревнуются друг с другом.

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

Вот как компания Azure представляет свой сервис Kubernetes:

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

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

Аналогичные решения предлагают Amazon, Google, а вскоре и DigitalOcean. Даже небольшие компании и индивидуальные разработчики теперь могут масштабировать свои приложения по всему миру. Небольшое понимание того, как это достигается, не помешает, поэтому вам следует хотя бы поверхностно ознакомиться с Kubernetes и Docker.

Каждый раз, когда вы думаете: «Kubernetes против Docker?», скептики отвечают: «Docker — это круто, а Kubernetes — это немного экстремально». Но вся компьютерная наука построена на экстремальной автоматизации, и Kubernetes доводит модель контейнеризации до логического предела!

Более тонкие различия — Нетворкинг

Многие споры о Kubernetes и Docker коренятся в таких базовых вещах, как реализация стека хранения и сетевых технологий. И Docker, и Kubernetes используют разные подходы.

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

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

«Первый предназначен для работы в кластере, а второй — на одном узле».

На самом деле, альтернативы этой дилемме нет, и вам просто нужно набраться терпения, пока вы будете осваивать новые навыки. Постепенно общая картина станет вам яснее.

Подход к внедрению Docker и Kubernetes.

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

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

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

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

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

Заключение

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

Разработка нового программного обеспечения для платформы, ориентированной на контейнеры, не только повысит масштабируемость ваших приложений, но и обеспечит их перспективность на будущее. Использование старых виртуальных машин может сработать сейчас, но через несколько лет вам придётся либо понести значительные затраты на миграцию всего в контейнеры, либо вовсе отказаться от своих проектов. Надеюсь, теперь, если кто-то затронет тему «Kubernetes против Docker», вас не запутает обилие терминов.