Входной шлюз Istio: доменное имя и перенаправление портов

Я установил сервисную сетку Istio. Пока все работает нормально, как я хочу. Снаружи я могу получить доступ только с номером порта, например http://www.mytest.com:41333. Что мне нужно сделать, чтобы переслать 80 к 41333 чтобы я мог получить к нему доступ с помощью http://www.mytest.com

Вот мой шлюз:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: mytest-gateway
spec:
  selector:
    istio: ingressgateway # use istio default controller
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "www.mytest.com"

Не уверен, что делать...

Источник

1 ответ

Я предполагаю, что ваш тип службы входного шлюза istio - NodePort, если входящий шлюз istio - это NodePort, тогда вам нужно использовать http://www.mytest.com:41333.

Если вы хотите использовать http://www.mytest.com, вам придется изменить его на LoadBalancer.

Вы можете проверить, является ли ваш входной шлюз istio NodePort с помощью

       kubectl get svc -n istio-system

И проверьте тип шлюза istio ingress.

NodePort: предоставляет услугу на каждом IP-адресе узла на статическом порте (NodePort). Служба ClusterIP, к которой маршрутизируется служба NodePort, создается автоматически. Вы сможете связаться со службой NodePort извне кластера, запросив NodeIP:NodePort.

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

Как упоминалось в документации istio

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

Если вы используете облако, такое как aws, вы можете настроить Istio с AWS Load Balancer с соответствующими аннотациями.

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

Если это локально, например minikube, то вы можете взглянуть на metalLB

MetalLB - это реализация балансировщика нагрузки для кластеров Kubernetes без операционной системы, использующая стандартные протоколы маршрутизации.

Kubernetes не предлагает реализацию балансировщиков сетевой нагрузки (службы типа LoadBalancer) для кластеров без операционной системы. Реализации Network LB, которые поставляет Kubernetes, представляют собой связующий код, который обращается к различным платформам IaaS (GCP, AWS, Azure…). Если вы не работаете на поддерживаемой платформе IaaS (GCP, AWS, Azure…), LoadBalancers останутся в состоянии "ожидания" неопределенное время при создании.

Операторам "чистого металла" остаётся два менее значительных инструмента для доставки пользовательского трафика в свои кластеры: сервисы "NodePort" и "externalIPs". Оба этих варианта имеют существенные недостатки для производственного использования, что делает кластеры без операционной системы второстепенными в экосистеме Kubernetes.

MetalLB стремится исправить этот дисбаланс, предлагая реализацию Network LB, которая интегрируется со стандартным сетевым оборудованием, чтобы внешние сервисы на кластерах без операционной системы также "просто работали" в максимально возможной степени.

Вы можете узнать больше об этом по ссылке ниже:

Источник
Другие вопросы по тегам