svc во вне, k8s предлагает типы NodePort и LoadBalancer. Если k8s в облаке, то в принципе понятно что делать - добавляешь тип LB и поехали. А что делать,
когда ks8 на bare-metal? Есть проект MetalLB, который не решает волшебно проблему, также у них на сайте написано
two main limitations you should be aware of: single-node bottlenecking, and potentially slow failover.
Вроде можно просто поднимать сервисы с типом NodePort с зашитым жестко портом, впереди где-то поставить nginx и через proxy_pass проксировать. Минусы конечно же понятны (так поди некоторые и делают на k8s bare-meal).
А если какое-либо решение, которое "смотрит" в k8s API, видит, что появился k8s service на каком-то NodePort, у себя добавляет в конфиге, что например такой-то домен просто проксировать на NodePort таких-то нод? Этакий "самосборный" LoadBalancer вкупе с Nginx Ingress Controller , но который находится вне кластера k8s (т.е. также может слушать обычные 80 и 443 порты на ноде)
1) metallb в bgp режиме еще есть (описанные ограничения как будто про arp режим) 2) есть purbelb 3) можно юзать ingress controller который с hostNetwork: true - этот вариант ксати удобнее, чем предложенный тобой вариант с nginx и nodePort 4) можно cluster ip сделать внешними и анонсить (bgp) другие варианты с внешними балансировщиками Если задача именно получить type: LoadBalancer, то metallb, purelb стоит рассмотреть
> А если какое-либо решение, которое "смотрит" в k8s API... А это чистой воды ingress controller же. LoadBalancer для такой задачи не нужен. При желании ingress controller можно держать снаружи кластера, но правда непонятно зачем
Обсуждают сегодня