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

относительно внешнего IP входа nginx

Обязательно ли использовать внешние поле для контроллера входа nginx, когда у меня тип a Балансировщик нагрузки?

apiVersion: v1
kind: Service
metadata:
  name: ingress-nginx
  namespace: ingress-nginx
  labels:
    app: ingress-nginx
spec:
  type: LoadBalancer
  externalIPs:
  - {{  vip_address }}
  ports:
  - port: 80
    targetPort: 80
  selector:
    app: ingress-nginx

Есть ли какой-либо инструмент aws для создания и управления VIP в кластере?
Допускает ли aws эластичный IP вместо VIP для прямого доступа к LB извне?

Нет, указав externalIPs для LoadBalancer тип услуги не требуется.

внешние IP это немного другая особенность кластера Kubernetes:

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

В ServiceSpec внешний IP-адрес может быть указан вместе с любым из ServiceTypes.

Для LoadBalancer Тип Обслуживания loadBalancerIP вместо этого можно указать:

Предоставляет сервис извне с помощью балансировщика нагрузки облачного провайдера. Сервисы NodePort и ClusterIP, к которым будет маршрутизировать внешний балансировщик нагрузки, создаются автоматически.

В облачных провайдерах, которые поддерживают внешние балансировщики нагрузки, установка в поле типа значения LoadBalancer предоставит балансировщик нагрузки для вашей службы. Фактическое создание балансировщика нагрузки происходит асинхронно, и информация о подготовленном балансировщике будет опубликована в ServiceС .status.loadBalancer поле.

Трафик от внешнего балансировщика нагрузки будет направлен на серверные модули, хотя то, как именно это работает, зависит от облачного провайдера. Некоторые облачные провайдеры позволяют loadBalancerIP подлежит уточнению. В этих случаях балансировщик нагрузки будет создан с указанным пользователем loadBalancerIP. Если loadBalancerIP поле не указано, loadBalancer будет назначен временный IP. Если loadBalancerIP указано, но облачный провайдер не поддерживает эту функцию, поле будет проигнорировано.

Особые примечания для Azure: Чтобы использовать указанный пользователем общедоступный тип loadBalancerIPсначала необходимо создать ресурс общедоступного IP-адреса статического типа, и он должен находиться в той же группе ресурсов, что и другие автоматически созданные ресурсы кластера.

Взаимодействие с облаком осуществляется посредством Облачный контроллер. Вы можете найти список поддерживаемых облачных провайдеров на Облачные провайдеры страница.

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

Начиная с версии 1.8, диспетчер облачного контроллера может реализовывать:

  • контроллер узлов - отвечает за обновление узлов кубернетов с помощью облачных API и удаление узлов кубернетов, которые были удалены в вашем облаке.
  • Контроллер службы - отвечает за балансировщики нагрузки в вашем облаке по отношению к службам типа LoadBalancer.
  • контроллер маршрута - отвечает за настройку сетевых маршрутов в вашем облаке
  • контроллер постоянных меток томов - отвечает за установку меток зон и регионов в PersistentVolumes, созданных в облаках GCP и AWS.
  • любые другие функции, которые вы хотели бы реализовать, если у вас запущен поставщик вне дерева.