Здравствуйте, меня зовут Дмитрий Краснов.
Более пяти лет я занимаюсь администрированием кластеров Kubernetes и построением сложных микросервисных архитектур.
В начале этого года мы запустили сервис по управлению кластерами Kubernetes на базе Containerum. Пользуясь случаем, расскажу, что такое Kubernetes и чем интеграция с вендором отличается от open source. Для начала, что такое Кубернетес .
Это система управления контейнерами на большом количестве хостов.
С греческого, кстати, оно переводится как «пилот» или «рулевой».
Первоначально разработанный Google, а затем переданный в качестве технологического вклада в Cloud Native Computing Foundation, международную некоммерческую организацию, объединяющую ведущих мировых разработчиков, конечных пользователей и поставщиков контейнерных технологий.
Управляйте большим количеством контейнеров
Теперь давайте разберемся, что это за контейнеры.Это приложение со всем его окружением — в основном библиотеками, от которых зависит программа.
Все это запаковано в архивы и представлено в виде образа, который можно запускать независимо от операционной системы, тестировать и прочее.
Но есть проблема — управлять контейнерами на большом количестве хостов очень сложно.
Вот почему был создан Kubernetes. Образ контейнера представляет собой приложение и его зависимости.
Приложение, его зависимости и образ файловой системы ОС располагаются в разных частях образа, так называемых слоях.
Слои можно повторно использовать для разных контейнеров.
Например, все приложения в компании могут использовать базовый уровень Ubuntu. При запуске контейнеров нет необходимости хранить на хосте несколько копий одного базового слоя.
Это позволяет оптимизировать хранение и доставку изображений.
Когда мы хотим запустить приложение из контейнера, необходимые слои накладываются друг на друга и формируется оверлейная файловая система.
Сверху размещается записывающий слой, который удаляется при остановке контейнера.
Это гарантирует, что при запуске контейнера приложение всегда будет иметь одну и ту же среду, которую нельзя изменить.
Это гарантирует воспроизводимость среды на разных хостовых ОС.
Будь то Ubuntu или CentOS, среда всегда будет одинаковой.
Кроме того, контейнер изолируется от хоста с помощью механизмов, встроенных в ядро Linux. Приложения в контейнере не видят файлы, процессы хоста и соседних контейнеров.
Такая изоляция приложений от операционной системы хоста обеспечивает дополнительный уровень безопасности.
Существует множество инструментов для управления контейнерами на хосте.
Самый популярный из них — Docker. Это позволяет обеспечить полный жизненный цикл контейнеров.
Однако это работает только на одном хосте.
Если вам нужно управлять контейнерами на нескольких хостах, Docker может превратить жизнь инженеров в ад. Вот почему был создан Kubernetes. Востребованность Kubernetes обусловлена как раз возможностью управлять группами контейнеров на нескольких хостах как некой единой сущностью.
Популярность системы дает возможность строить DevOps или Development Operations, в которых Kubernetes используется для запуска процессов этого самого DevOps. 
Рисунок 1. Схематическое изображение того, как работает Kubernetes.
Полная автоматизация
DevOps — это, по сути, автоматизация процесса разработки.Грубо говоря, разработчики пишут код, который загружается в репозиторий.
Потом этот код можно автоматически собрать сразу в контейнер со всеми библиотеками, протестировать и «выкатить» на следующий этап — Staging, а потом сразу на Production. Вместе с Kubernetes DevOps позволяет автоматизировать этот процесс так, что он происходит практически без участия самих разработчиков.
За счет этого сборка происходит существенно быстрее, так как разработчику не обязательно делать это на своем компьютере — он просто пишет кусок кода, запихивает код в репозиторий, после чего запускается конвейер, который может включать в себя процесс создания, тестирования и развертывания.
И это происходит с каждым коммитом, поэтому тестирование происходит непрерывно.
При этом использование контейнера позволяет быть уверенным, что вся среда этой программы будет выпущена в производство именно в том виде, в котором она тестировалась.
То есть не будет проблем типа «были одни версии в тесте, другие в производстве, но когда мы их установили, всё упало».
А поскольку сегодня у нас тенденция к микросервисной архитектуре, когда вместо одного огромного приложения сотни маленьких, то для администрирования их вручную потребуется огромный штат сотрудников.
Вот почему мы используем Kubernetes.
Плюсы, плюсы, плюсы
Если говорить о преимуществах Kubernetes как платформы, то он имеет существенные преимущества с точки зрения управления микросервисной архитектурой.Управление несколькими репликами.
Самое важное — управление контейнерами на нескольких хостах.
Что еще более важно, управляйте несколькими репликами приложений в контейнерах как единым объектом.
Благодаря этому инженерам не приходится беспокоиться о каждом отдельном контейнере.
Если один из контейнеров выйдет из строя, Kubernetes увидит это и перезапустит его снова.
Кластерная сеть.
Kubernetes также имеет так называемую кластерную сеть с собственным адресным пространством.
Благодаря этому каждый под имеет свой адрес.
Под сабподом понимается минимальная структурная единица кластера, в которой непосредственно запускаются контейнеры.
Кроме того, Kubernetes обладает функциональностью, сочетающей в себе балансировщик нагрузки и обнаружение сервисов.
Это позволяет избавиться от ручного управления IP-адресами и делегировать эту задачу Kubernetes. А автоматические проверки работоспособности помогут обнаружить проблемы и перенаправить трафик на рабочие модули.
Управление конфигурацией.
При управлении большим количеством приложений становится сложно управлять конфигурацией приложений.
Для этого в Kubernetes есть специальные ресурсы ConfigMap. Они позволяют централизованно хранить конфигурации и предоставлять их модулям при запуске приложений.
Этот механизм позволяет гарантировать согласованность конфигурации как минимум в десяти или сотне реплик приложения.
Постоянные тома.
Контейнеры по своей сути неизменяемы, и когда контейнер останавливается, все данные, записанные в файловую систему, будут уничтожены.
Но некоторые приложения хранят данные прямо на диске.
Для решения этой проблемы в Kubernetes есть функция управления дисковым хранилищем — Persistent Volumes. Этот механизм использует внешнее хранилище для данных и может переносить постоянное хранилище, блок или файл, в контейнеры.
Данное решение позволяет хранить данные отдельно от воркеров, что сохраняет их в случае поломки этих самых воркеров.
Балансировщик нагрузки.
Хотя в Kubernetes мы управляем абстрактными сущностями, такими как Deployment, StatefulSet и т. д., в конечном итоге контейнеры запускаются на обычных виртуальных машинах или аппаратных серверах.
Они не идеальны и могут упасть в любой момент. Kubernetes увидит это и перенаправит внутренний трафик на другие реплики.
Но что делать с трафиком, поступающим извне? Если просто направить трафик на одного из воркеров, то в случае его сбоя сервис станет недоступен.
Для решения этой проблемы в Kubernetes есть такие сервисы, как Load Balancer. Они предназначены для автоматической настройки внешнего облачного балансировщика для всех воркеров кластера.
Этот внешний балансировщик направляет внешний трафик на воркеры и сам отслеживает их статус.
Если один или несколько рабочих процессов становятся недоступными, трафик перенаправляется другим.
Это позволяет создавать высокодоступные сервисы с помощью Kubernetes. Kubernetes лучше всего работает при использовании микросервисной архитектуры.
Внедрить систему в классическую архитектуру можно, но это бессмысленно.
Если приложение не может работать на нескольких репликах, то какая разница — в Kubernetes или нет?
Кубернетес с открытым исходным кодом
Kubernetes с открытым исходным кодом — отличная вещь: я установил его, и он работает. Вы можете развернуть его на собственных аппаратных серверах, в собственной инфраструктуре, установить мастер- и воркеры, на которых будут работать все приложения.И самое главное, все это бесплатно.
Однако есть нюансы.
Первое — это потребность в знаниях и опыте администраторов и инженеров, которые все это будут развертывать и поддерживать.
Поскольку клиент получает полную свободу действий в кластере, он сам отвечает за работоспособность кластера.
И здесь очень легко все сломать.
Во-вторых, отсутствие интеграции.
Если вы запустите Kubernetes без популярной платформы виртуализации, вы не получите всех преимуществ программы.
Например, использование постоянных томов и служб балансировки нагрузки.
Рисунок 2. Архитектура k8s
Кубернетес от вендора
Интеграция с облачным провайдером предоставляет два варианта: Во-первых, человек может просто нажать на кнопку «создать кластер» и получить уже настроенный и готовый к использованию кластер.Во-вторых, вендор сам устанавливает кластер и настраивает интеграцию с облаком.
Как это происходит здесь.
Инженер, запускающий кластер, указывает, сколько воркеров ему нужно и с какими параметрами (например, 5 воркеров, каждый с 10 процессорами, 16 ГБ ОЗУ и, скажем, 100 ГБ диска).
После чего он получает доступ к уже сформированному кластеру.
В этом случае воркеры, на которых запускается нагрузка, полностью передаются клиенту, но вся плоскость управления остается под ответственностью вендора (если услуга предоставляется по модели управляемого сервиса).
Однако эта схема имеет свои недостатки.
Из-за того, что плоскость управления остается за вендором, вендор не дает полного доступа клиенту, а это снижает гибкость в работе с Kubernetes. Иногда бывает, что клиент хочет добавить в Kubernetes какой-то специфический функционал, например аутентификацию через LDAP, но конфигурация плоскости управления этого не позволяет. 
Рисунок 3. Пример кластера Kubernetes от облачного провайдера
Что выбрать: open source или вендор
Итак, Kubernetes имеет открытый исходный код или зависит от поставщика? Если взять Kubernetes с открытым исходным кодом, то пользователь делает с ним все, что хочет. Но велика вероятность выстрелить себе в ногу.С вендором сложнее, потому что все продумано и настроено под компанию.
Самый большой недостаток Kubernetes с открытым исходным кодом — потребность в специалистах.
Благодаря выбору поставщика компания освобождается от этой головной боли, но ей придется решать, платить ли ее специалистам или поставщику.
Ну плюсы очевидны, минусы тоже известны.
Одно неизменно: Kubernetes решает множество проблем, автоматизируя управление множеством контейнеров.
И какой выбрать, open source или вендорный — решение каждый принимает сам.
Статью подготовил Дмитрий Краснов, ведущий архитектор сервиса Containerum провайдера #CloudMTS. Теги: #Kubernetes #Облачные вычисления #контейнеризация #DevOps #Микросервисы #облачные технологии #МТС
-
Учебное Пособие По Javafx: Стилизация Css
19 Oct, 24 -
Emblocks — Это Ide Для Stm32.
19 Oct, 24
