В итоге нифига не понятно что там не так. CURL как и в случае с первым сервисом жалуется на curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to hub.domain.ru:443

Ну в общем никак всё же не удалось заставить работать шлюз не в istio-system неймспейсе..., стоило перенести сертификат и шлюз туда - все сразу заработало... что дает в итоге инджект шлюза непонятно...

хочу немного странного.
проксировать через Istio запросы на внешний сервер.

Делал по статье в блоге - все работает на ура.
https://istio.io/latest/blog/2019/proxy/

Далее пошли укашательства.

Поменял в гейтвее проброс TLS на терминацию - на сервер стали приходить запросы по http на 80 порт.
все работает.


ок. теперь хочу сделать так, чтобы истио передавал запросы по протоколу HTTPS на сервер. и тут похоже обломидзе наступило.

кусок манифеста из virtual server:

  hosts:
  - r1.k8s.net
  http:
  - route:
    - destination:
        host: r1.k8s.net
        port:
          number: 443
  tls:
  - match:
    - sniHosts:
      - r1.k8s.net
    route:
    - destination:
        host: r1.k8s.net
        port:
          number: 443

В service entry:

  hosts:
  - r1.k8s.net
  ports:
  - number: 80
    name: http
    protocol: HTTP
  - number: 443
    name: https
    protocol: HTTPS

но в ответ получаю от сервера конечного отлуп.
на HTTPS порт пришел plain-HTTP
как-то можно в virtual server указать, что надо TLS-трафик слать ?

ды, можно

ща поищу

во тут писали

нужно на gw сделать tls: mode: PASSTHROUGH

Я так понимаю он хочет сначала на гейтвее терминировать, а потом опять отправлять шифрованный

как тут писали - все работает.

агга

Всем привет, кто сетапил трейсинг в Istio (jaeger) и может подсказать плиз.
Трейсы трейсятся и спаны спанятся, но почему-то не могу связать трейсы
— Тоесть в jaeger вижу трейсы с envoy proxy
— Но когда дело доходит до сервиса, внутри сервиса почему то трейс не джойнится, а создается новый
— Поидее envoy должен писать информацию о трейсе в контекст, но судя по всему ее там нет

Кто сталкивался, буду крайне признаетлен, вот мой семпл
func (s *DealsService) ListDisputes(ctx context.Context, req *v1.ListDisputesRequest) (*v1.ListDisputesReply, error) {
 span := trace.SpanFromContext(ctx)
 span.AddEvent("entered rpc function")
 defer span.End()
 
 return &v1.ListDisputesReply{}, nil
}

trace c envoy proxy, и поидее внутри должен появится еще один спан(который в коде создается)

но спан, который определяется в коде, почему то не связывается с трейсом envoy proxy, а создает отдельный трейс

Я не го разработчик, но такая проблема была пока не стали нормально проксировать заголовки которые envoy проставляет:

https://istio.io/latest/docs/tasks/observability/distributed-tracing/

немного ошибся ссылкой
https://istio.io/latest/docs/tasks/observability/distributed-tracing/overview/#trace-context-propagation

🙏 благодарю за информацию

похоже на правду

Добрый день. Подскажите пжлста. Есть потребность закрыть сервисы от некоторых айпи. Даю такой манифест:
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: httpbin-access
 namespace: dev
spec:
 action: ALLOW
 rules:
 - from:
   - source:
       namespaces: ["istio-system"]
   when:
   - key: request.headers[X-Envoy-External-Address]
     values: ["<IP-ADDR>"] #Ip to allow
 selector:
   matchLabels:
     app: httpbin-app

Но доступ не закрывается. externalTrafficPolicy настроен. Не встречали такое?

а зачем по хедеру? почему не по
 rules:
   - from:
       - source:
           ipBlocks: