Comments 10
В случае self hosted Kubernetes обычно используют NodePort и затем вручную устанавливают балансировщик нагрузки. Так что практически в каждом случае балансировщик нагрузки размещается перед вашим Ingress Controller, что означает наличие двойного проксирования, через которые должен пройти трафик для достижения приложений.
Вы же можете публиковать pod'ы ingress controller'а с помощью опции hostNetwork: true, получать трафик напрямую без лишних проксирований. Нет никакой необходимости иметь внешний балансировщик или вытаскивать ingress controller из кластера.
Все это в целом может работать, но начинаются проблемы, если узлы кластера все в приватной сети и нужно как-то извне пробросить доступ к нему. Необходим какой-либо edge узел, способный принять трафик, но дальше он должен все же прийти на узел кластера (желательно на любой) и попасть на ingress-контроллер. Получаем двойное проксирование, чего можно избежать например с подобным решением как в статье
Необходим какой-либо edge узел, способный принять трафик, но дальше он должен все же прийти на узел кластера (желательно на любой) и попасть на ingress-контроллер. Получаем двойное проксирование, чего можно избежать например с подобным решением как в статье
Делаете такие узлы воркерами кластера. Шедулите туда pod'ы ingress-controller'а с hostNentwork: true, и никаких двойных проксирований не будет. pod'у будет досупна как сеть внутри кластера, так и сеть хоста (то есть сеть edge узла).
Эта схема ничем принципиально не отличается от того что вы сделали. Только ingress-controller будет у вас в кластере, и деплоить вы его будете с помощью абстракций k8s. Любой pod k8s может иметь доступ в сеть хоста. На мой взгляд нет никаких причин выносить ingress-controller из куба. Вы сделали тоже самое решение что и с hostNetwork: true, только деплой реализовали сами (вместо того чтобы деплоить с помощью k8s).
Очень странное решение. Во-первых, как написали выше, hostNetwork прекрасно работает. Во-вторых, лично мое мнение, лучше всего для ingress в self-hosted кластере смотрелся бы hostNetwork+DaemonSet, если нужен внешний доступ. Таким образом мы еще и избавляемся от единой точки отказа в кластере.
Как написал выше, что зачастую кластера находятся во внутренней сети и просто так трафик не пропустить в кластер. Хочется еще отметить, что в вашем предложении с DaemonSet+hostnetwork есть проблема - а как в итоге клиенту выбрать на какой узел попасть? Помещать в dns все узлы кластера плохой путь - при добавлении/удалении узла из кластера нужно вносить изменения в dns, а они распространяются не моментально. Поэтому желательно иметь какую-то одну точку входа, желательно отказоустойчивую.
С подходом внешнего ингресс контроллера можно как избежать лишних проксирований, так и запустить несколько балансировщиков в HA режиме, например с помощью keepalived.
Автор, наверное, отлично поупражнялся, но ставить такое кому-то точно не стоит, да и себе зачем, если существует как минимум несколько описанных выше в комментариях более "нативных" для куба решений, которыми гораздо удобнее управлять и они более гибкие.
Запускаем HAProxy Kubernetes Ingress Controller вне Kubernetes-кластера