Конечные точки служб (Endpoints) Kubernetes используются для подключения к службам, находящимся за пределами кластера. Иногда через функционал служб Kubernetes требуется обеспечить доступ к внешним службам, чтобы она перенаправляла подключения на внешние IP-адреса и порты, что позволяет использовать преимущества и балансировки нагрузки служб и обнаружения служб. Клиентские модули, работающие в кластере, могут подключаться к внешней службе так же, как и к внутренним службам.
Службы (Service) не связываются с модулями напрямую. Вместо этого между ними находится ресурс конечных точек (Endpoints). Ресурс Endpoints – это список IP-адресов и портов, предоставляющих доступ к службе. Ресурс конечных точек похож на любой другой ресурс Kubernetes, поэтому можно вывести его основную информацию с помощью команды kubectl get:

$ kubectl get endpoints kubia

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

Создание службы без селектора
В создаваемой службе селектор не определен и имя службы (external-service) должно совпадать с именем объекта Endpoints, служба будет принимать входящие подключения на порту 80.
Листинг YAML файла для создания службы без селектора модулей: external-service.yaml

apiVersion: v1
kind: Service
metadata:
name: external-service
spec:
ports:
– port: 80

Создание ресурса конечных точек для службы без селектора
Конечные точки (Endpoints) представляют собой отдельный ресурс, а не атрибут службы. Если служба создана без селектора, соответствующий ресурс Endpoints не создается автоматически, поэтому его создание зависит от администратора. Соответствующий манифест external-service-endpoints.yaml приведен ниже:

apiVersion: v1
kind: Endpoints
metadata:
name: external-service
subsets:
– addresses:
– ip: 11.11.11.11
– ip: 22.22.22.22
ports:
– port: 80

Объект Endpoints должен иметь то же имя (external-service), что и служба, и содержать для службы список целевых IP-адресов и портов. После того как служба и ресурс Endpoints будут отправлены на сервер Kubernetes, служба будет готова к использованию, как обычная служба с селектором модулей. Контейнеры, созданные после создания службы, будут включать переменные среды для службы, и все подключения с ее парой IP:port будут балансироваться между конечными точками службы.
Если позднее вы решите перенести внешнюю службу в модули, работающие внутри Kubernetes, вы можете добавить селектор в службу, тем самым сделав ее конечные точки управляемыми автоматически. То же верно и в обратном направлении – путем удаления селектора из службы Kubernetes прекращает обновление конечных точек. Это значит, что IP-адрес службы может оставаться постоянным при изменении фактической реализации службы.

Создание псевдонима для внешней службы (ExternalName)
Имеется более простой способ предоставления доступа к внешней службе, который позволяет ссылаться на внешнюю службу по ее полностью квалифицированному доменному имени (FQDN).
Для этого необходимо создать ресурс Service с полем type, установленным в ExternalName. Например, предположим, что общедоступный API имеется по адресу api.some.com. Как показано в следующем ниже листинге, вы можете определить службу, которая на него указывает.

apiVersion: v1
kind: Service
metadata:
name: external-service
spec:
type: ExternalName
externalName: someapi.some.com
ports:
– port: 80

После создания службы вместо использования FQDN службы модули могут подключаться к внешней службе через доменное имя external-service.default.svc.cluster.local (или external-service). В результате чего фактическое имя службы и ее местоположение будут скрыты от модулей, которые потребляют службу, позволяя администратору модифицировать определение службы и указывать ее на другую службу в любое время позже путем изменения только атрибута externalName или путем возврата типа обратно в ClusterIP и создания объекта Endpoints для службы – вручную либо путем указания селектора меток на службе и давая ей создаваться автоматически.
Службы ExternalName реализуются исключительно на уровне DNS – для службы создается DNS-запись CNAME. Клиенты, подключающиеся к службе, будут подключаться к внешней службе напрямую, полностью минуя служебный прокси. По этой причине эти виды служб не получают кластерный IP.

Использование службы NodePort для предоставления внешним клиентам доступа к службам

Создавая службу NodePort, вы заставляете Kubernetes резервировать порт на всех его узлах (во всех из них используется один и тот же номер порта) и перенаправлять входящие подключения в модули, которые являются частью службы. К службе NodePort можно получить доступ не только через внутренний кластерный IP-адрес службы, но и через IP-адрес любого узла и зарезервированный порт узла.

Реклама: Если у Вас проблемы с  Iphone, обращайтесь в А сервис https://a-service.ua/remont-iphone