Как работают развертывания Kubernetes

Завершено

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

Варианты развертывания модулей pod

Существует несколько вариантов управления развертыванием модулей pod в кластере Kubernetes при использовании kubectl. Доступные параметры:

• Шаблоны модулей pod
• Контроллеры репликации
• Наборы реплик
• Развертывания

Вы можете использовать любое из этих четырех определений типа объектов Kubernetes для развертывания модулей pod или pod. Эти файлы используют YAML для описания предполагаемого состояния модуля pod или модулей pod для развертывания.

Что такое шаблон pod?

Шаблон pod позволяет определить конфигурацию модуля pod, который требуется развернуть. Шаблон содержит такие сведения, как имя образа контейнера и используемый реестр контейнеров для получения образов. Шаблон также содержит сведения о конфигурации среды выполнения, такие как порты для использования. Шаблоны определяются с помощью YAML таким же образом, как и при создании файлов DOCKER.

Шаблоны можно использовать для ручного развертывания модулей Pod. Тем не менее развернутый вручную модуль pod не перезапускается после сбоя, он удаляется или завершается. Чтобы управлять жизненным циклом pod, необходимо создать объект Kubernetes более высокого уровня.

Что такое контроллер репликации?

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

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

Что такое набор реплик?

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

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

Что такое развертывание?

Развертывание создает объект управления на одном уровне выше набора реплик и позволяет развертывать обновления для модулей pod в кластере и управлять ими.

Предположим, в кластере развернуто пять экземпляров приложения. Существует пять модулей pod с версией 1.0.0 вашего приложения.

Если вы решили обновить приложение вручную, вы можете удалить все модули pod, а затем запустить новые модули pod с версией 2.0.0 вашего приложения. С помощью этой стратегии приложение работает без простоя.

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

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

Развертывания также предоставляют стратегию отката, которую можно выполнить с помощью kubectl.

Развертывания используют файлы определений на основе YAML и упрощают управление развертываниями. Помните, что развертывания позволяют применять любые изменения в кластере. Например, можно развертывать новые версии приложения, обновлять метки и запускать другие реплики модулей pod.

kubectl имеет удобный синтаксис для автоматического создания развертывания при использовании команды kubectl run для развертывания модуля pod. Эта команда создает развертывание с необходимым набором реплик и модулями pod. Однако команда не создает файл определения. Рекомендуется управлять всеми развертываниями с помощью файлов определения развертывания и отслеживать изменения с помощью системы управления версиями.

Рекомендации по развертыванию

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

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

Сети Kubernetes

Предположим, у вас есть кластер с одним уровнем управления и двумя узлами. При добавлении узлов в Kubernetes IP-адрес автоматически назначается каждому узлу из внутреннего диапазона частной сети. Предположим, что диапазон локальной сети — 192.168.1.0/24.

Каждый развертываемый модуль pod назначает IP-адрес из пула IP-адресов. Допустим, что в конфигурации используется сетевой диапазон 10.32.0.0/12, как показано на приведенном ниже рисунке.

По умолчанию модули pod и узлы не могут взаимодействовать друг с другом, используя разные диапазоны IP-адресов.

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

Для упрощения взаимодействия Kubernetes ожидает следующих настроек сети.

• Модули pod могут взаимодействовать друг с другом между узлами без преобразования сетевых адресов (NAT).
• Узлы могут взаимодействовать со всеми модулями pod и, наоборот, без NAT.
• Агенты на узле могут взаимодействовать со всеми узлами и модулями pod.

Kubernetes предлагает несколько сетевых решений, которые можно установить для настройки сети. Например, Antrea, Cisco Application Centric Infrastructure (ACI), Cilium, Flannel, Kubenet, VMware NSX-T, Weave Net.

Поставщики облачных служб также предоставляют собственные сетевые решения. Например, служба Azure Kubernetes Service (AKS) поддерживает сетевой интерфейс контейнера виртуальной сети Azure, Kubenet, Flannel, Cilium и Antrea.

Службы Kubernetes

Служба — это объект Kubernetes, который обеспечивает стабильное сетевое подключение для модулей pod. Служба Kubernetes обеспечивает обмен данными между узлами, модулями pod и пользователями приложения (как внутренними, так и внешними) с кластером.

Kubernetes назначает службе IP-адрес при создании, как узлу или модулю pod. Эти адреса назначаются из диапазона IP-адресов кластера служб; например, 10.96.0.0/12. Службе также назначается DNS-имя на основе имени службы и IP-порт.

В приложении отслеживания дронов сетевое взаимодействие выглядит следующим образом:

• Веб-сайт и RESTful API доступны пользователям за пределами кластера.

• Службы кэша в памяти и очереди сообщений доступны для интерфейсных и RESTful API соответственно, но не для внешних пользователей.

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

• База данных NoSQL доступна для кэша в памяти и службы обработки данных, но не для внешних пользователей.

Для поддержки этих сценариев можно настроить три типа служб для предоставления компонентов приложения.

Служба	Description
ClusterIP	Адрес, назначенный службе, предоставляющей нашу службу для набора служб в кластере. Например, связь между интерфейсными и серверными компонентами приложения.
NodePort	Порт узла от 30000 до 32767, который плоскость управления Kubernetes назначает службе; Например, 192.169.1.11 в кластерахs01. Затем вы настраиваете службу с целевым портом на модуле pod, который вы хотите предоставить. Например, настраиваете порт 80 на модуле pod, который работает на одном из внешних интерфейсов. Теперь вы можете получить доступ к интерфейсной части через IP-адрес и порт узла.
LoadBalancer	Подсистема балансировки нагрузки, позволяющая распределять нагрузку между узлами, на которых выполняется приложение, и предоставлять модуль pod для доступа из общедоступной сети. Обычно подсистемы балансировки нагрузки настраиваются при использовании поставщиков облачных служб. В этом случае трафик из внешней подсистемы балансировки нагрузки направляется в модули pod, выполняющие приложение.

В приложении отслеживания дронов вы можете решить предоставить веб-сайт отслеживания и API RESTful с помощью LoadBalancer и службы обработки данных с помощью ClusterIP.

Группировка модулей pod

Управлять модулями pod по IP-адресу неудобно. IP-адреса pod изменяются по мере их повторного создания контроллерами и могут работать с любым числом модулей pod.

Объект службы позволяет управлять отдельными модулями pod в кластере с помощью меток селектора. Установите метку селектора в определении службы в соответствии с меткой модуля pod, указанной в файле определения pod.

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

Хранилище Kubernetes

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

Kubernetes предоставляет возможности для подготовки постоянного хранилища с использованием PersistentVolumes. Вы также можете запросить определенное хранилище для модулей pod с помощью PersistentVolumeClaims.

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

Вопросы интеграции с облаком

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

Вспомним ранее, что Kubernetes не предоставляет следующие сервисы:

• ПО промежуточного слоя
• Платформы обработки данных
• Базы данных
• Кэши
• Кластерные системы хранения

В этом решении для отслеживания дронов есть три службы, которые предоставляют функциональные возможности ПО промежуточного слоя: база данных NoSQL, служба кэша в памяти и очередь сообщений. Вы можете выбрать MongoDB Atlas для решения NoSQL, Redis для управления кэшем в памяти и, RabbitMQ или Kafka в зависимости от потребностей очереди сообщений.

При использовании облачной среды, такой как Azure, рекомендуется использовать службы за пределами кластера Kubernetes. Это решение может упростить настройку кластера и управление им. Например, можно использовать кэш Azure для Redis для служб кэширования в памяти, обмен сообщениями служебной шины Azure для очереди сообщений и Azure Cosmos DB для базы данных NoSQL.