kubernetes услуги связи внутри кластера

Question

У меня есть составной сервис S.c, который потребляет 2 атомарные службы S.a и S.b, где все три службы запущены в кластере Кубернетес. Что бы быть лучше рисунок на

1) Создание Sa, Sb, как обезглавленные службы и пусть Sc интегрировать с ними через внешний Loadbalancer как NGINX + (который использует DNS распознаватель для поддержания обновленных серверных стручков)

2) Созданием Sa , Sb с помощью clusterIP и разрешить Sc доступ к ним/разрешать их через DNS-кластер (приложение skyDNS). Что будет внутренне использовать балансировку нагрузки на основе IP-таблицы для контейнеров.

Примечание: Мой кластер k8s работает на настраиваемом решении (на виртуальной машине) У нас есть много составных сервисов, которые потребляют от 1 до многих атомных сервисов (например, пример выше).

Редактировать: В нескольких сценариях мне также нужно будет выставлять службы во внешнюю сеть , подобно Sb, нужен доступ как от Sc, так и снаружи. В этом было бы разумнее создать Sb в качестве службы безглавых, иначе DNS-резольвер всегда возвращал бы только адрес clusterIP, и весь внешний запрос также будет перенаправлен на адрес clusterIP. Моя задача состоит в том, оба сценария (внутри- против интер) конфликтуют друг с другом

Например: Nginx-сервис (который имеет clusterIP) и Nginx-безголовый-сервис (без головы)

/# nslookup nginx-service 
Server: 172.16.48.11 
Address 1: 172.16.48.11 kube-dns.kube-system.svc.cluster.local 

Name:  nginx-service 
Address 1: 172.16.50.29 nginx-service.default.svc.cluster.local 

/# nslookup nginx-headless-service 
Server: 172.16.48.11 
Address 1: 172.16.48.11 kube-dns.kube-system.svc.cluster.local 

Name:  nginx-headless-service 
Address 1: 11.11.1.13 wrkfai1asby2.my-company.com 
Address 2: 11.11.1.15 imptpi1asby.my-company.com 
Address 3: 11.11.1.4 osei623a-sby.my-company.com 
Address 4: 11.11.1.6 osei511a-sby.my-company.com 
Address 5: 11.11.1.7 erpdbi02a-sbyold.my-company.com 

Answer 1

Использование DNS + кластера IP-адреса - это более простой подход и не требует раскрытия ваших услуг в общедоступном Интернете. Если вам не нужны конкретные функции балансировки нагрузки от nginx, я бы рекомендовал перейти с №2.