Используя Istio, есть ли способ направить вход на службу кластера k8s, на которой не работает коляска посланника?

Question

Я использую кластер Azure AKS с виртуальными машинами Windows и Linux.

Я могу свернуть службу кластера по имени из модуля в пространстве имен Istio, поэтому я знаю, что TCP для модуля работает. Я считаю, что мне нужно каким-то образом сообщить моей Виртуальной службе , а не , через прокси-сервер-посредник, а просто перенаправить запросы непосредственно в конечную точку службы k8s - как если бы это была виртуальная машина, внешняя по отношению к me sh. У меня есть TLS, заканчивающийся на шлюзе - сама служба k8s только выставлена ​​в кластере на порту 80.

В настоящее время нет коляски посланника для контейнеров Windows, но с точки зрения k8s, это просто другая служба в том же кластере, в которой работает Istio.

http-gateway.yaml

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  annotations:
  name: http-gateway
  namespace: istio-system
spec:
  selector:    
    istio: ingressgateway
  servers:
  - hosts:
    - "*.myapp.com"
    port:
      number: 80
      name: http-80-gateway
      protocol: HTTP
    tls:
      httpsRedirect: true # sends 301 redirect for http requests
  - hosts:
    - "*.myapp.com"
    port:
      number: 443
      name: https-443-gateway
      protocol: HTTPS
    tls:
      credentialName: cert-azure-dns
      privateKey: sds
      serverCertificate: sds
      mode: SIMPLE

virtual-service.yaml

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: myapp-vsvc
  namespace: myapp-ns
spec:
  hosts:
  - foo #external DNS name is foo.myapp.com; gateway host for HTTPS is '*.myapp.com'
  gateways:
  - istio-system/http-gateway
  http:
  - route:
    - destination:
        host: myapp-svc.myapp-ns.svc.cluster.local
        port:
          number: 80

Попытка Envoy Passthrough Я добавил ServiceEntry, например:

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: myapp-se
  namespace: myapp-ns
spec:
  hosts:
  - myapp-svc.myapp-ns.svc.cluster.local
  ports:
  - number: 80
    name: http
    protocol: HTTP
  resolution: DNS
  location: MESH_EXTERNAL

Ответ сервера - 404 со значением заголовка «server», равным «istio-envoy».

DNS разрешается на шлюз правильно и сертификат acme действителен - поэтому эта ошибка обычно указывает, что я сделал это для виртуальной службы, но не был перенаправлен на службу кластера. В Kiali нет ошибок проверки Istio ни в одном из моих определений yaml: виртуальная служба, запись службы или шлюз.

Для моего global.outboundTrafficPolicy.mode установлено значение "ALLOW_ANY".

Интересно, является ли объявление "EXTERNAL_ME SH" для службы кластера проблемой? Istio знает, что служба k8s существует, поэтому он пытается отдать приоритет маршрутизации на коляску посланника и игнорирует мою регистрацию входа в службу?

Существует опция для полного обхода посланника для уточнения c диапазонов IP-адресов, что было бы возможным, если бы я мог как-то установить stati c IP для этой конкретной службы кластера. Я хочу обойти посланника для входа в этот один кластерный сервис.

Answer 1

Я мог бы поклясться, что попробовал это раньше, но, очевидно, все, что мне нужно было предоставить, это простая виртуальная служба без какого-либо правила назначения или входа в службу.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: myapp-vsvc
  namespace: myapp-ns
spec:
  hosts:
  - foo.myapp.com 
  gateways:
  - istio-system/http-gateway
  http:
  - route:
    - destination:
        host: myapp-svc.myapp-ns.svc.cluster.local
        port:
          number: 80

Answer 2

вы бы использовали serviceentry для этого:

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: httpbin-ext
spec:
  hosts:
  - httpbin.org
  ports:
  - number: 80
    name: http
    protocol: HTTP
  resolution: DNS
  location: MESH_EXTERNAL

https://istio.io/docs/tasks/traffic-management/egress/egress-control/