Балансировщик внешней нагрузки для кластера Kubernetes

Question

Я хочу реализовать простой балансировщик уровня 7 в моем кластере kubernetes, который позволит мне предоставлять услуги кубернетов внешним потребителям.

Я создам простой ха-прокси на основе контейнера, который будет наблюдать за kubernetes услуги и соответствующие конечные точки и перезагружать его конфигурацию бэкенд/внешнего интерфейса (дополнена правилом SYN питания во время перезагрузки)

Это позволит мне получить доступ kubernetes услуги как SVCa, SVCb, SVCC над

http://load-balancer-ip:port/SVCa -------> Pod endpoints..... 
http://load-balancer-ip:port/SVCb -------> Pod endpoints..... 
http://load-balancer-ip:port/SVCc -------> Pod endpoints..... 

Как бы выше подход работы по сравнению с

(1) га-прокси переадресации всех запросов на clusterIP адрес kubernetes услуг.

http://load-balancer-ip:port/SVCa ------->clusterIP-SVCa 
http://load-balancer-ip:port/SVCb ------->clusterIP-SVCa 
http://load-balancer-ip:port/SVCc ------->clusterIP-SVCa 

(2) га-прокси балансировки нагрузки запросов рабочих-узлов, IP: порт, полученные путем создания сервисов типа NodePort

http://load-balancer-ip:port/SVCa --------> node1:p1, node2:p1, node3:p1 
http://load-balancer-ip:port/SVCb --------> node1:p2, node2:p2, node3:p2 
http://load-balancer-ip:port/SVCc --------> node1:p3, node2:p3, node3:p3 

Примечание: Мой K8S Кластера работает на индивидуальное решение (на -premise VM)

Answer 1

Я думаю, что nginx IngressController может работать лучше в этом случае. Вам нужно только установить серверную службу и имя хоста внутри определения входящего трафика.

Посмотрите здесь: https://github.com/kubernetes/contrib/tree/master/ingress/controllers/nginx

Answer 2

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

(1) Это будет работать, но полагается на прокси-сервер kube для проксирования на другой узел, который сейчас не супер интеллектуальный, вы, по существу, переходите от haproxy (мощный прокси) к прокси-серверу kube (относительно немой прокси) к pod - добавление дополнительного прыжка и некоторая (хотя и минимальная) латентность

Ваш первоначальный план, вероятно, самый лучший и по существу тот же, что и входной контроллер.