Посещение развернутого веб-сайта Istio без порта - PullRequest
Новая
       151

Посещение развернутого веб-сайта Istio без порта

1 голос
/ 18 июня 2020

У меня есть несколько AWS экземпляров EC2, и на них я развернул экземпляр Rancher. На Rancher я развернул веб-сайт с использованием Kubernetes, и он развернут с использованием Istio для обработки сети, я могу войти в систему с помощью http://portal.website.com:31380. У меня также есть AWS Route 53 для работы URL-адреса и nginx для балансировщика нагрузки между экземплярами EC2.

Но я хочу иметь возможность входить в систему только с http://portal.website.com, поэтому удалите порт . Есть ли у меня способ сделать это? 

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
 name: portal-gateway
spec:
 selector:
   istio: ingressgateway
 servers:
 - port:
     number: 80
     name: http
     protocol: HTTP
   hosts:
   - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
 name: ingress
spec:
 hosts:
 - "*"
 gateways:
 - portal-gateway
 http:
 - match:
   - uri:
       prefix: "/"
   rewrite:
     uri: "/"
   route:
   - destination:
       host: portal
       port:
         number: 80
   websocketUpgrade: true
---
apiVersion: v1
kind: Service
metadata:
 name: portal
spec:
 ports:
   - protocol: TCP
     port: 80
     targetPort: 8080
 selector:
   app: portal
 type: ClusterIP

Изменить: я обращаюсь к этому на 31380, потому что он настроен на использование NodePort (https://kubernetes.io/docs/concepts/services-networking/service/#nodeport). Документы Istio говорят: If the EXTERNAL-IP value is <none> (or perpetually <pending>), your environment does not provide an external load balancer for the ingress gateway. In this case, you can access the gateway using the service’s node port.

Вот результат kubectl get svc istio-ingressgateway -n istio-system

ИМЯ ТИП КЛАСТЕР-IP ВНЕШНИЙ IP-ПОРТ (И) ВОЗРАСТ istio-ingressgateway NodePort 10.43.200.101 15020: 30051 / TCP, 80: 31380 / TCP, 443: 31390 / TCP, 31400: 31400 / TCP, 15029: 30419 / TCP, 15030: 30306 / TCP, 15031: 31130 / TCP, 15032: 32720 / TCP, 15443: 30361 / TCP 3ч27м

1 Ответ

1 голос
/ 22 июня 2020

Как вы упомянули, istio документация говорит, что

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

Если мы посмотрим на kubernetes документацию о NodePort

Если вы установите поле типа в NodePort, плоскость управления Kubernetes выделяет порт из диапазона, указанного - -service-node-port-range флаг (по умолчанию: 30000-32767). Каждый узел передает этот порт (один и тот же номер порта на каждом узле) в вашу службу. Ваша служба сообщает о выделенном порте в своем поле .spe c .ports [*]. NodePort.

Итак, если ваш входной шлюз - NodePort, тогда вам нужно использовать http://portal.website.com : 31380 .

Если вы хотите использовать http://portal.website.com, нужно будет изменить его на LoadBalancer .

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

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

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

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

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

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

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

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

Подробнее об этом можно прочитать по ссылке ниже:

...