Новости

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

Сервисы в Kubernetes

Благодаря базовым правилам организации сети в Kubernetes и сетевым дополнениям, реализующим эти правила, развертываемые pod могут взаимодействовать только внутри одного кластера. Некоторые дополнения CNI назначают pod IP-адреса в одном адресном пространстве с узлами, поэтому теоретически, зная данный IP, вы можете подключиться к pod напрямую из-за пределов Kubernetes. Но это не самый эффективный способ доступа к сервисам, поскольку pod в Kubernetes по своей природе непостоянны. Представьте, что у вас есть функция или система, которой нужно обратиться к API, доступному в pod. Какое-то время схема может работать нормально, однако рано или поздно возникнет добровольное или принудительное прерывание, в результате которого данный pod исчезнет. Kubernetes, вероятно, создаст ему замену с новыми именем и IP-адресом, поэтому очевидно, что для его поиска нужен некий механизм. Здесь вам пригодится API для работы с сервисами.

Данный API позволяет назначать конечным точкам сервиса постоянные IP-адрес и порт в пределах кластера и автоматически привязывать их к подходящим pod. Этот магический процесс основан на упомянутых выше механизмах iptables и IPVS, работающих на уровне узлов Linux; он привязывает IP-адрес и порт сервиса к реальным IP-адресам конечной точки или pod. Контроллер, который отвечает за это, называется kube-proxy; он выполняется на каждом узле кластера, управляя правилами iptables.

При определении объекта Service необходимо указать тип сервиса. От этого зависит, где будет доступна конечная точка: только внутри кластера или за его пределами. Существует четыре основных типа сервисов, которые мы кратко обсудим в следующих подразделах.

Тип сервисов ClusterIP

Если не указать в спецификации сервиса его тип, то по умолчанию будет использоваться ClusterIP. Сервисам данного типа назначаются IP-адреса из выделенного диапазона CIDR. Эти адреса действительны на протяжении всего жизненного цикла сервисов и привязываются к IP-адресам и портам клиентских pod с помощью поля selector. Но, как вы увидите сами, в некоторых случаях селектор использовать нельзя. В спецификации сервиса также указывается его доменное имя. На этом основан механизм обнаружения внутри кластера, позволяющий рабочим заданиям с легкостью обращаться к другим сервисам в том же кластере, используя DNS-запросы. Например, если у вас есть спецификация сервиса, представленная ниже, и вам нужно сделать HTTP-вызов к этому сервису из другого pod внутри того же кластера, то вы можете использовать адрес web1-svc (при условии, что клиент и сервис находятся в одном пространстве имен):

Если вам нужен доступ к сервисам в других пространствах имен, то вы можете использовать доменные имена вида <имя_сервиса>.<название_пространства_имен>.svc.cluster.local.

При отсутствии в определении сервиса селектора для него можно определить API с конечными точками. В результате сервис будет доступен по заданным IP-адресу и порту, и для этого не требуется атрибут selector, который автоматически обновляет конечные точки из pod, соответствующих селектору. Это может пригодиться в ряде ситуаций, если у вас есть база данных, предназначенная для тестирования, но находящаяся за пределами кластера, и вы хотите, чтобы ваш сервис использовал вместо нее другую БД, развернутую в Kubernetes. Такие сервисы иногда называют неуправляемыми (headless), поскольку они, в отличие от обычных, не управляются контроллером kube-proxy, но позволяют работать с конечными точками напрямую, как показано на рис. 9.4

Тип сервисов NodePort

Сервисы типа NodePort привязывают свои IP-адреса и порты к портам высшего уровня на каждом узле кластера. Порты высшего уровня находятся в диапазоне от 30 000 до 32 767 и могут быть либо динамически назначены, либо явно заданы в спецификации сервиса. Они обычно используются в кластерах с локальным размещением или в самописных решениях, которые не поддерживают конфигурацию с автоматической балансировкой нагрузки. Для прямого доступа к сервису из-за пределов кластера используйте адрес вида <IP_узла>:<порт_узла>, как показано на рис. 9.5

Тип сервисов ExternalName

Сервисы типа ExternalName редко применяются на практике, но могут пригодиться для привязки постоянных внутренних доменных имен кластера к сервисам с внешними доменными именами. Типичный пример — внешняя база данных облачного провайдера с уникальным доменным именем, таким как mymongodb.documents.azure.com.

Строго говоря, это можно легко прописать в спецификации pod, используя переменную Environment (см. главу 6). Но лучше задействовать более общее внутреннее имя, такое как prod-mongodb. что позволит изменить базу данных, на которую оно ссылается, простым редактированием спецификации сервиса. В случае изменения переменной Environment вам пришлось бы перезапускать pod.

Тип сервисов LoadBalancer

LoadBalancer — специальный тип сервисов, позволяющих автоматизировать взаимодействие с облачными провайдерами и другими программируемыми сервисами облачной инфраструктуры. С их помощью можно развернуть механизм балансировки нагрузки, предоставляемый облаком, в котором размещен кластер Kubernetes. Это означает, что в большинстве случаев сервис LoadBalancer будет работать примерно так же, как публично доступный балансировщик нагрузки от AWS, Azure, GCE, OpenStack и т.д. Однако каждый облачный провайдер предоставляет собственные аннотации для поддержки дополнительных возможностей, таких как сугубо внутреннее распределение нагрузки, установка параметров конфигурации для AWS ELB и т.д. В спецификации сервиса можно вдобавок указать IP-адрес балансировщика и допустимые диапазоны. Пример этого показан в следующем листинге и на рис. 9.6.

С полным содержанием статьи можно ознакомиться на сайте "Хабрахабр":

https://habr.com/ru/company/piter/blog/547344/