Docker Swarm, Kubernetes и Mesos — самые популярные платформы оркестрации контейнеров.
В своем выступлении Арун Гупта сравнивает следующие аспекты Docker, Swarm и Kubernetes:
- Местное развитие.
- Функции развертывания.
- Многоконтейнерные приложения.
- Открытие службы.
- Масштабирование сервиса.
- Одноразовые задачи.
- Интеграция с Maven.
- «Прокатное» обновление.
- Создание кластера базы данных Couchbase.
Арун Гупта — главный технолог продуктов с открытым исходным кодом в Amazon Web Services, который более 10 лет занимается разработкой сообществ разработчиков Sun, Oracle, Red Hat и Couchbase. Имеет обширный опыт работы в ведущих межфункциональных командах, разрабатывающих и реализующих стратегию маркетинговых кампаний и программ.
Он возглавлял команды инженеров Sun, является одним из основателей команды Java EE и создателем американского филиала Devoxx4Kids. Арун Гупта — автор более 2 тысяч постов в IT-блогах и выступал с докладами более чем в 40 странах.
Конференция DEVOXX UK. Выберите фреймворк: Docker Swarm, Kubernetes или Mesos. Часть 1 Конференция DEVOXX UK. Выберите фреймворк: Docker Swarm, Kubernetes или Mesos. Часть 2 Строка 55 содержит COUCHBASE_URI, указывающий на эту службу базы данных, которая также была создана с использованием файла конфигурации Kubernetes. Если вы посмотрите на строку 2, вы увидите вид: Служба — это служба, которую я создаю, под названием «couchbase-service», и то же имя указано в строке 4. Ниже приведены некоторые порты.
Ключевые строки - 6 и 7. В сервисе говорю "Эууу, вот эти метки я ищу!" и эти метки — не что иное, как имена пар переменных, а строка 7 указывает на мое приложение Couchbase-RS-Pod. Ниже приведены порты, которые обеспечивают доступ к этим же меткам.
В строке 19 я создаю новый тип ReplicaSet, строка 31 содержит имя изображения, а строки 24–27 указывают на метаданные, связанные с моим модулем.
Это именно то, что ищет сервис и к чему следует осуществлять подключение.
В конце файла есть какая-то связь между строками 55-56 и 4, говорящая: «воспользуйтесь этим сервисом!» Итак, я запускаю свой сервис, когда есть набор реплик, а поскольку каждый набор реплик имеет свой порт с соответствующей меткой, он включается в сервис.
С точки зрения разработчика, вы просто вызываете сервис, который затем использует необходимый вам набор реплик.
В результате у меня есть модуль WildFly, который взаимодействует с серверной частью базы данных через сервис Couchbase. Я могу использовать интерфейс с несколькими модулями WildFly, которые также взаимодействуют с серверной частью Couchbase через службу Couchbase.
Позже мы рассмотрим, как служба, расположенная вне кластера, взаимодействует через свой IP-адрес с элементами, расположенными внутри кластера и имеющими внутренний IP-адрес.
Итак, контейнеры без сохранения состояния — это здорово, но насколько хорошо использовать контейнеры с сохранением состояния? Давайте посмотрим на системные настройки для контейнеров с отслеживанием состояния или постоянных контейнеров.
В Docker есть 4 разных подхода к организации хранения данных, на которые вам следует обратить внимание.
Первый — Implicit Per-Container, что означает, что при использовании контейнеров Couchbase, MySQL или MyDB все они начинаются с песочницы по умолчанию.
То есть все, что хранится в базе данных, хранится в самом контейнере.
Если контейнер исчезает, данные исчезают вместе с ним.
Второй — Explicit Per-Container, когда вы создаете конкретное хранилище с помощью команды docker Volume create и сохраняете в нем данные.
Третий подход Per-Host связан с отображением хранилища, когда все, что хранится в контейнере, одновременно дублируется на хосте.
Если контейнер выйдет из строя, данные останутся на хосте.
Последнее заключается в использовании нескольких хостов Multi-Host, что целесообразно на этапе производства различных решений.
Допустим, ваши контейнеры с вашими приложениями работают на хосте, но вы хотите хранить свои данные где-то в Интернете, и для этого вы используете автоматическое сопоставление для распределенных систем.
Каждый из этих методов использует определенное место хранения.
Неявные и явные данные для каждого контейнера хранят данные на хосте в /var/lib/docker/volumes. При использовании метода Per-Host хранилище монтируется внутри контейнера, а сам контейнер монтируется на хосте.
Для мультихостов можно использовать такие решения, как Ceph, ClusterFS, NFS и т. д. При выходе из строя постоянного контейнера каталог хранения становится недоступным в первых двух случаях, но в последних двух случаях доступ сохраняется.
Однако в первом случае вы можете получить доступ к репозиторию через хост Docker, работающий на виртуальной машине.
Во втором случае данные тоже не потеряются, ведь вы создали Явное хранилище.
В случае сбоя хоста каталог хранения недоступен в первых трех случаях; в последнем случае связь с хранилищем не прерывается.
Наконец, разделяемая функция полностью исключена для хранения в первом случае и возможна в остальных.
Во втором случае вы можете разделить хранилище в зависимости от того, поддерживает ли ваша база данных распределенное хранилище или нет. В случае Per-Host распределение данных возможно только на данном хосте, а при мультихосте это обеспечивается расширением кластера.
Это следует учитывать при создании контейнеров с сохранением состояния.
Еще один полезный инструмент Docker — плагин Volume, который работает по принципу «батарейки есть, но их необходимо заменить».
При запуске Docker-контейнера пишет: "? Как только вы запустите контейнер с базой данных, вы сможете хранить свои данные в этом контейнере!" Это функция по умолчанию, но вы можете ее изменить.
Этот плагин позволяет вам использовать сетевой диск или что-то подобное вместо базы данных-контейнера.
Он включает в себя драйвер по умолчанию для хранилища на базе хоста и обеспечивает интеграцию контейнера с внешними системами хранения, такими как Amazon EBS, Azure Storage и постоянными дисками GCE.
На следующем слайде показана архитектура плагина Docker Volume.
Синий цвет представляет клиент Docker, связанный с синим хостом Docker, который имеет механизм локального хранения, предоставляющий контейнеры для хранения данных.
Зеленый цвет указывает на клиент плагина и демон плагина, которые также подключены к хосту.
Они предоставляют возможность хранить данные в сетевом хранилище нужного вам типа Storage Backend.
Плагин Docker Volume можно использовать с хранилищем Portworx. Модуль PX-Dev на самом деле представляет собой запускаемый вами контейнер, который подключается к вашему хосту Docker и позволяет легко хранить данные в Amazon EBS.
Клиент Portworx позволяет вам отслеживать состояние различных контейнеров хранения, подключенных к вашему хосту.
Если вы посетите мой блог, вы сможете прочитать, как максимально эффективно использовать Portworx с Docker. Концепция хранилища в Kubernetes аналогична Docker и представлена каталогами, доступными вашему контейнеру в поде.
Они не зависят от срока службы любого контейнера.
Наиболее распространенными типами хранения являются hostPath, nfs, awsElasticBlockStore и gsePersistentDisk. Давайте посмотрим, как эти хранилища работают в Kubernetes. Обычно процесс их подключения состоит из 3 шагов.
Во-первых, кто-то на стороне сети, обычно администратор, предоставляет вам постоянное хранилище.
Для этого существует соответствующий файл конфигурации PersistentVolume. Затем разработчик приложения записывает файл конфигурации под названием PersistentVolumeClaim или запрос хранилища PVC, в котором говорится: «У меня выделено 50 ГБ распределенного хранилища, но для того, чтобы другие люди также могли использовать его емкость, я сообщаю этому PVC, что в данный момент я нужно всего 10 ГБ».
Наконец, третий шаг — ваш запрос монтируется как хранилище, и приложение, имеющее под, или набор реплик, или что-то подобное, начинает его использовать.
Важно помнить, что этот процесс состоит из упомянутые 3 шага и масштабируемы.
На следующем слайде показан контейнер персистентности Kubernetes архитектуры AWS.
Внутри коричневого прямоугольника, обозначающего кластер Kubernetes, находится один главный узел и два рабочих узла, обозначенных желтым цветом.
Один из рабочих узлов содержит оранжевый модуль, хранилище, контроллер реплики и зеленый контейнер Docker Couchbase. Внутри кластера, над узлами, фиолетовый прямоугольник обозначает Сервис, доступный извне.
Эта архитектура рекомендуется для хранения данных на самом устройстве.
При необходимости я могу хранить свои данные в EBS вне кластера, как показано на следующем слайде.
Это типичная модель масштабирования, но при ее использовании следует учитывать финансовый аспект — хранение данных где-то в сети может оказаться дороже, чем на хосте.
При выборе решений по контейнеризации это один из веских аргументов.
Как и в случае с Docker, вы можете использовать постоянные контейнеры Kubernetes с Portworx.
Это то, что в текущей терминологии Kubernetes 1.6 называется «StatefulSet» — способ работы с приложениями с отслеживанием состояния, который обрабатывает события об остановке пода и выполнении Graceful Shutdown. В нашем случае такими приложениями являются базы данных.
В моем блоге вы можете прочитать, как создать StatefulSet в Kubernetes с помощью Portworx. Давайте поговорим о аспекте развития.
Как я уже говорил, у Docker есть 2 версии — CE и EE, в первом случае речь идет о стабильной версии Community Edition, которая обновляется раз в 3 месяца, в отличие от ежемесячно обновляемой версии EE. Вы можете скачать Docker для Mac, Linux или Windows. После установки Docker автоматически обновится, и начать работу очень легко.
Для Kubernetes я предпочитаю версию Minikube — это хороший способ начать работу с платформой, создав кластер на одном узле.
Для создания кластеров из нескольких нод выбор версий шире: это kops, kube-aws (CoreOS+AWS), kube-up (устаревший).
Если вы хотите использовать Kubernetes на базе AWS, я рекомендую присоединиться к AWS SIG, которая каждую пятницу собирается онлайн и публикует множество интересных материалов по работе с AWS Kubernetes. Давайте посмотрим, как выполняется Rolling Update на этих платформах.
Если есть кластер из нескольких нод, то он использует определенную версию образа, например WildFly:1. Последовательное обновление означает, что версия образа последовательно заменяется новой на каждом узле, один за другим.
Для этого я использую команду docker service update (имя сервиса), в которой указываю новую версию образа WildFly:2 и метод обновления update-parallelism 2. Цифра 2 означает, что система обновит 2 образа приложения.
одновременно, затем 10-секундная задержка обновления 10 с, после чего следующие 2 образа будут обновлены еще на 2 узлах и т. д. Этот простой механизм непрерывного обновления предоставляется вам как часть Docker. В Kubernetes скользящее обновление работает следующим образом.
Контроллер репликации rc создает набор реплик одной и той же версии, и каждому поду в этом веб-приложении-rc присваивается метка, расположенная в etcd. Когда мне нужен модуль, я использую службу приложений для доступа к репозиторию etcd, который предоставляет мне модуль с использованием указанной метки.
В этом случае у нас есть 3 модуля в контроллере репликации, на которых работает приложение WildFly версии 1. При обновлении в фоновом режиме создается еще один контроллер репликации с тем же именем и индексом в конце — — xxxxx, где x — случайные числа, и с такими же метками.
Теперь в Application Service есть три модуля со старой версией приложения и три модуля с новой версией в новом контроллере репликации.
После этого старые поды удаляются, контроллер репликации с новыми подами переименовывается и вводится в эксплуатацию.
Перейдем к мониторингу.
В Docker имеется множество встроенных команд мониторинга.
Например, интерфейс командной строки DockerContainer Stats позволяет ежесекундно выводить на консоль информацию о состоянии контейнеров — использование процессора, использование диска, загрузку сети.
Инструмент Docker Remote API предоставляет данные о том, как клиент взаимодействует с сервером.
Он использует простые команды, но основан на Docker REST API. В данном случае слова REST, Flash, Remote означают одно и то же.
Когда вы общаетесь с хостом, это REST API. Docker Remote API позволяет получить дополнительную информацию о запущенных контейнерах.
В моем блоге излагаются подробности использования этого мониторинга с Windows Server. Мониторинг системных событий докера при запуске многохостового кластера дает возможность получить данные о сбое хоста или сбое контейнера на конкретном хосте, масштабировании сервисов и тому подобное.
Начиная с Docker 1.20, он включает Prometheus, который встраивает конечные точки в существующие приложения.
Это позволяет получать метрики по HTTP и отображать их на дашбордах.
Еще одна функция мониторинга — cAdvisor (сокращение от консультанта по контейнерам).
Он анализирует и предоставляет данные об использовании ресурсов и производительности запущенных контейнеров, предоставляя метрики Prometheus прямо из коробки.
Особенность этого инструмента в том, что он предоставляет данные только за последние 60 секунд. Поэтому вам нужно уметь собирать эти данные и помещать их в базу данных, чтобы можно было отслеживать долгосрочный процесс.
Его также можно использовать для графического отображения показателей информационной панели с помощью Grafana или Kibana. В моем блоге есть подробное описание того, как использовать cAdvisor для мониторинга контейнеров с помощью панели управления Kibana. На следующем слайде показано, как выглядят выходные данные конечной точки Prometheus, и метрики, доступные для отображения.
Слева внизу вы видите метрики HTTP-запросов, ответов и т. д., справа — их графическое отображение.
Kubernetes также включает встроенные инструменты мониторинга.
На этом слайде показан типичный кластер, содержащий один главный и три рабочих узла.
Каждый из рабочих узлов содержит автоматически запускаемый cAdvisor. Кроме того, существует Heapster — система мониторинга производительности и сбора метрик, совместимая с Kubernetes версии 1.0.6 и выше.
Heapster позволяет собирать не только метрики производительности рабочих нагрузок, подов и контейнеров, но также события и другие сигналы, генерируемые всем кластером.
Для сбора данных он обращается к Kubelet каждого модуля, автоматически сохраняет информацию в базе данных InfluxDB и выводит ее в виде показателей на панель управления Grafana. Однако имейте в виду, что если вы используете miniKube, эта функция по умолчанию недоступна, поэтому вам придется использовать дополнения для мониторинга.
Так что все зависит от того, где вы запускаете контейнеры и какие инструменты мониторинга вы можете использовать по умолчанию, а какие нужно устанавливать как отдельные дополнения.
На следующем слайде показаны информационные панели Grafana, которые показывают рабочее состояние моих контейнеров.
Здесь довольно много интересных данных.
Конечно, существует множество коммерческих инструментов мониторинга процессов Docker и Kubernetes, таких как SysDig, DataDog, NewRelic. Некоторые из них имеют 30-летний бесплатный пробный период, поэтому вы можете попробовать найти тот, который подходит вам лучше всего.
Лично я предпочитаю использовать SysDig и NewRelic, которые хорошо интегрируются с Kubernetes. Существуют инструменты, которые одинаково хорошо интегрируются как с платформами Docker, так и с Kubernetes.
Немного рекламы :)
Спасибо, что остаетесь с нами.Вам нравятся наши статьи? Хотите увидеть больше интересных материалов? Поддержите нас, разместив заказ или порекомендовав друзьям, облачный VPS для разработчиков от $4,99 , уникальный аналог серверов начального уровня, который мы придумали для вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от 19$ или как правильно раздать сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40 ГБ DDR4).
Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только здесь 2 x Intel TetraDeca-Core Xeon, 2 x E5-2697v3, 2,6 ГГц, 14C, 64 ГБ DDR4, 4 твердотельных накопителя по 960 ГБ, 1 Гбит/с, 100 ТВ от 199 долларов США в Нидерландах! Dell R420 — 2x E5-2430, 2,2 ГГц, 6C, 128 ГБ DDR3, 2 твердотельных накопителя по 960 ГБ, 1 Гбит/с, 100 ТБ — от 99 долларов США! Прочтите об этом Как построить корпоративную инфраструктуру класса, используя серверы Dell R730xd E5-2650 v4 стоимостью 9000 евро за копейки? Теги: #ИТ-инфраструктура #Системное администрирование #Kubernetes #Конференции #docker swarm #mesos
-
Лакруа, Жан
19 Oct, 24 -
Телевизор Как Монитор
19 Oct, 24 -
Переключение Раскладки В Kde
19 Oct, 24 -
Что Такое Evpn/Vxlan
19 Oct, 24 -
Расскажите, Люди Добрые, О Rss Хабра.
19 Oct, 24