Назад | Перейти на главную страницу

Kubernetes - Ingress против Nginx с Loadbalancer

AFAIK Ingress - это просто уровень абстракции для службы LoadBalancer, ориентированной на Nginx (или другие)

Есть ли функции, которые может предоставить только вход? Есть ли недостатки использования LoadBalancer + Nginx?

AFAIK Ingress - это просто уровень абстракции для службы LoadBalancer, ориентированной на Nginx (или другие)

Это правда лишь отчасти; ты можешь использовать hostNetworking: true и, если хотите, выставьте контроллер Ingress непосредственно за узлами, пропуская SDN и необходимость в балансировщике нагрузки (хотя с недостаток открытия портов ваших узлов напрямую в Интернет) - и примерно такая же идея с Service из type: NodePort только с дополнительной глупостью порта

Многие люди действительно используют контроллер Ingress за LoadBalancer, чтобы отделить узлы от Интернета, но это не требование

Также следует знать о ALB Ingress Controller что идет в обратном направлении: попросить LB выполнить host: и маршрутизация URI до того, как он достигнет кластера, и без (?) компонента nginx, работающего в кластере

Есть ли функции, которые может предоставить только вход?

Только? Вряд ли. Удобный и переносное облако? Чрезвычайно

Я не уверен, что это то, о чем вы спрашиваете, но причина, по которой большинство людей используют один LB и контроллер Ingress в кластере, заключается в огромной экономии средств, просто заплатив за один LB с почти неограниченными ресурсами Ingress. Без Ingress нужно было бы использовать Service из type: LoadBalaner, а затем подождите, пока Kubernetes предоставит новый LB для каждой Услуги, тратя время и деньги.

Есть ли недостатки использования LoadBalancer + Nginx?

В основном вокруг ошибок и управления затратами:

  • будет дополнительный сетевой переход от LB к httpd в кластере
  • у большинства LB есть свои своя схема проверки работоспособности, и LB может не пройти проверку работоспособности независимо от входного контроллера, не прошедшего проверку работоспособности, что приведет к искусственному отключению

    это также верно в отношении проблем с маршрутизацией, разрешениями, облачными квотами и т. д.

  • потенциально существует два разных механизма безопасности: LB и входной контроллер, и если они не совпадают, это может привести к отключению
  • если у кого-то включено ведение журнала доступа, он будет регистрироваться дважды, один раз на LB и один раз на входе
  • нужно знать о том, что внутри кластера происходит маршрутизация, иначе будет неочевидно, почему все использует только один LB