Как подключить Kubernetes Pod к пункту назначения, доступному только подмножеству узлов?

Question

У меня кластер Kubernetes v1.13 с фланелью Calico + в качестве CNI. Все узлы имеют общедоступный IP-адрес и работают под управлением Ubuntu 16.04.

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

Рассмотрим упрощенный пример выше. Я хочу, чтобы Pod Kubernetes имел доступ к Internal Server C (это обычный сервер, а не часть кластера). Я мог бы принудительно настроить Pod на внутреннюю Node B, но поскольку для соединения требуются только малая задержка и пропускная способность, а на Node A ресурсов гораздо больше, я бы предпочел использовать Node B просто как какой-то шлюз . (Рассмотрим несколько Node B с, поэтому SPOF фактически не существует).

В настоящее время мой подход заключается в использовании DaemonSet с селектором узлов для всех внутренних ( B ) узлов, определяющих Pod HAProxy. Эти экземпляры HAproxy могут быть доступны в качестве службы Kubernetes и перенаправлять запросы внутренним службам назначения.

Видите ли вы лучший или более простой способ реализовать соединение от Блока, расположенного в любом Узле, с целью, которая может быть достигнута только подмножеством Узлов?

Answer 1

Если вам нравится решение сетевого уровня, попробуйте это:

1. Выберите один B-узел, найдите его IP-адрес, который находится в одной подсети с A. Допустим, этот IP-адрес b_ip
2. Добавить маршрут к серверу C (возможно, сети), используя b_ip в качестве шлюза.

Это решение имеет некоторое преимущество: вам не нужно изменять конфигурацию HAproxy, когда вам нужно посетить новый сервис на сервере C. Также есть что-то плохое, узел B, который вы выбрали на шаге 1, был бы единственной точкой в ​​вашей системе. Я думаю, что вы можете использовать плавающий IP в качестве обходного пути.

Answer 2

Исходя из того, что вы говорите здесь:

Я мог бы принудительно планировать Pod на внутреннем узле B, но поскольку для соединения требуются только малая задержка и пропускная способность, а на узле A гораздо больше ресурсов, я бы предпочел использовать узел B просто как какой-то шлюз.

Я думаю, что вы ищете шаблон Амбассадор . Обычно вы создаете контейнеры такого типа, расположенные в вашей зоне B, и ваш трафик будет направляться на эти контейнеры / контейнеры с использованием службы ClusterIP, поскольку она находится внутри кластера.

Тогда эти контейнеры будут иметь внутри себя прокси (вроде того, что у вас сейчас есть в ваших демонах), который будет прозрачно перенаправлять трафик на обычный сервер, на который вы нацелены.

Другие ссылки, которые могут быть полезны, могут быть это от MS или это слайд-шоу (стр.42) .

Если это дает большие преимущества по сравнению с тем, что у вас уже запущено, я не уверен, но я предпочитаю работать только с модулями и минимизировать другие компоненты, если это возможно.