Kubernetes. Часть 4

Другие компоненты Kubernetes

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

Services

До сих пор мы использовали термин «служба» в обычном, Unix-подобном смысле: для обозначения длительно выполняющихся процессов, часто подключенных к сети, способных отвечать на запросы. Однако в Kubernetes Services - это компонент, который действует как базовый внутренний балансировщик нагрузки и представитель для подов.Services  группирует вместе логические коллекции модулей, которые выполняют одну и ту же функцию, чтобы представить их как единое целое.

Это позволяет развернуть службу, которая может отслеживать и направлять все серверные контейнеры определенного типа. Внутренним потребителям нужно знать только о стабильной конечной точке, предоставляемой Services . Между тем, абстракция Services позволяет масштабировать или заменять внутренние рабочие единицы по мере необходимости. IP-адрес службы остается стабильным независимо от изменений в модулях, на которые она направляется. Развертывая Services, вы легко получаете возможность обнаружения и можете упростить дизайн контейнеров.

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

Хотя службы по умолчанию доступны только с использованием IP-адреса с внутренней маршрутизацией, их можно сделать доступными за пределами кластера, выбрав одну из нескольких стратегий. NodePort конфигурация работает, открыв статический порт на внешнем сетевом интерфейсе каждого узла. Трафик на внешний порт будет автоматически маршрутизироваться на соответствующие модули с использованием внутренней IP-службы кластера.

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

Volumes and Persistent Volumes (Тома и постоянные тома)

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

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

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

Метки и аннотации (Labels and Annotations)

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

Ярлыки представлены в виде простых пар "ключ-значение". У каждого блока может быть более одной метки, но у каждого блока может быть только одна запись для каждого ключа. Обычно в качестве идентификатора общего назначения используется ключ «имя», но вы можете дополнительно классифицировать объекты по другим критериям, таким как стадия разработки, общедоступность, версия приложения и т. Д.

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