Я намагався знайти спосіб визначення служби в одному просторі імен, який посилається на Pod, який працює в іншому просторі імен. Я знаю, що контейнери в Pod, що працює в, namespaceAможуть отримати доступ до serviceXвизначеного namespaceB, посилаючись на нього в кластері DNS як serviceX.namespaceB.svc.cluster.local, але я б краще не мав коду всередині контейнера, щоб знати про місцезнаходження serviceX. Тобто я хочу, щоб код просто шукав, serviceXа потім мав доступ до нього.
Документація Kubernetes говорить про те, що це можливо. Це говорить про те, що одна з причин того, що ви б визначили службу без селектора, полягає в тому, що ви хочете вказати свою послугу на службу в іншому просторі імен або на іншому кластері .
Це підказує мені, що я повинен:
- Визначте
serviceXпослугу вnamespaceAбез селектора (оскільки ПОД, який я хочу вибрати, не входитьnamespaceA). - Визначте послугу (яку я також зателефонував
serviceX) уnamespaceB, а потім - Визначити об'єкт в Endpoints
namespaceAдо точки , щобserviceXвnamespaceB.
Саме цей третій крок я не зміг здійснити.
Спочатку я спробував визначити об’єкт Кінцевих точок таким чином:
kind: Endpoints
apiVersion: v1
metadata:
name: serviceX
namespace: namespaceA
subsets:
- addresses:
- targetRef:
kind: Service
namespace: namespaceB
name: serviceX
apiVersion: v1
ports:
- name: http
port: 3000Це здавалося логічним підходом, і очевидно, для чого це targetRefбуло. Але це призвело до помилки, сказавши, що ipполе в addressesмасиві є обов'язковим. Отже, моя наступна спроба була призначити фіксований адресу ClusterIP , щоб serviceXв namespaceB, і покласти , що в поле IP (зверніть увагу , що service_cluster_ip_rangeналаштована як 192.168.0.0/16і 192.168.1.1був призначений в якості ClusterIP для serviceXв namespaceB, serviceXв namespaceAбуло автоматично призначений іншим ClusterIP на 192.168.0.0/16підмережі) :
kind: Endpoints
apiVersion: v1
metadata:
name: serviceX
namespace: namespaceA
subsets:
- addresses:
- ip: 192.168.1.1
targetRef:
kind: Service
namespace: namespaceB
name: serviceX
apiVersion: v1
ports:
- name: http
port: 3000Це було прийнято, але звернення до serviceXin namespaceAне переадресували до Pod namespaceB-, вони вичерпалися. Дивлячись на налаштування iptables, схоже, що для цього потрібно було б зробити попереднє маршрутизацію NAT двічі.
Єдиним , що я знайшов , що працювало - але не є задовільним рішенням - це для пошуку фактичного IP - адреси Pod , що забезпечує serviceXв namespaceBі помістити цю адресу в об'єкті Endpoints в namespaceA. Звичайно, це не задовільно, тому що IP-адреса Pod може змінитися з часом. Ось цю проблему IP-адреси служб вирішувати.
Отже, чи є спосіб виконати те, що здається обіцянкою документації, що я можу вказати службу в одному просторі імен на службу, що працює в іншому просторі імен?
Коментолог запитав, чому ви хочете це зробити - ось випадок використання, який має для мене сенс, принаймні:
Скажімо, у вас є система багатоорендарів, яка також включає загальну функцію доступу до даних, якою можна ділитися між орендарями. Тепер уявіть, що ця функція доступу до даних має різні смаки із загальними API, але різними характеристиками. Деякі орендарі отримують доступ до одного з них, інші орендарі мають доступ до іншого.
Кожні орендарі працюють у власних просторах імен, але кожен повинен отримати доступ до однієї з цих загальних служб доступу до даних, яка обов'язково буде знаходитися в іншому просторі імен (оскільки до неї звертаються кілька орендарів). Але ви не хочете, щоб орендар повинен змінити свій код, якщо підписка зміниться, щоб отримати доступ до високоефективної послуги.
Потенційним рішенням (найчистішим, про яке я можу придумати, якби воно працювало) є включення визначення служби у простір імен кожного орендаря для служби доступу до даних, з кожним з яких налаштовано для відповідної кінцевої точки. Це визначення послуги було б налаштовано так, щоб вказувати на належну послугу доступу до даних, яку кожен орендар має право використовувати.