Я думал изначально, что через переменные задать можно, но похоже нет.

м, если чарт\оператор поддерживают

не, даже чарт не поддерживает: https://istio.io/v1.5/docs/reference/config/installation-options/#sidecarinjectorwebhook-options

Всем ку, кто может поделиться знанием.
Кто сетапил Kiali с помощью helm-chart-a (оператор или просто)
https://github.com/kiali/helm-charts
не могу сообразить как серверу сказать, что пром находится в другом неймспейсе)

это из истио чарта, но идея должна быть такая же

огонь, благодарю за выручку)
попробую сейчас через оператора поставить
жесть у них там за ансибл шарят))

а правильно ли понимаю если например есть балансер, который принимает api запросы:
client —> cloudlflare —> ingress-gateway(load balancer) —> istio-gateway(kind: Gateway) —> virtual_service
на балансировшик прилетает шифрованный трафик, а с балансировщика уже идет разтерминированный трафик на gateway?

kind: Gateway
metadata:
  name: api-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTP
      hosts:
        - "api-staging.org.com"

похоже на бред, понимаю)
просто в envoy летит опять https трафик, получается он снова шифруется?

Gateway же виртуальная хрень, которая настраивает ingress-gateway, а с него идет напрямую в под в соответствии с virtual-service и destination-rule, и вероятно из-за mtls трафик между istio-ingressgateway и pod:istio-proxy шифруется куберовскими ключами уже, и потом от istio-proxy в приложение просто http

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
 name: mygateway
spec:
 selector:
   istio: ingressgateway # use istio default ingress gateway
 servers:
 - port:
     number: 443
     name: https
     protocol: HTTPS
   tls:
     mode: SIMPLE
     credentialName: httpbin-credential # must be the same as secret
   hosts:
   - httpbin.example.com
EOF

Видно разницу?

с чем

всем привет!

Изучаю истио, возник вопрос как работает балансировка.

В истио правила балансировки описываются в destinationrule.  Как я понял, envoy в каждом поде выполняет клиентскую балансировку на основе этих правил. Т.е. envoy шлет запросы непосредственно в поды.

Но во всех примерах создается куберовский сервис (который так же балансирует поды), и без этого сервиса приложение не работает. Т е получается envoy шлет запросы в кубер Service.

Может кто то пояснить как связаны destinationrule и кубер Service ?

Может есть какие то статьи, где детальнее описано как работает балансировка в Istio?

Сайдкар истио находится в поде

Балансировка куба идет по подам

Было бы странно чтобы в Кубе  были поды без сервисов

@serb21 можно для начала с этой статьей ознакомиться ;)

https://habr.com/ru/company/southbridge/blog/441616/

Спасибо. хорошая статья.
—-
Istio настраивает Envoy на основе сервисов и конечных точек в кластере Kubernetes и использует умные функции маршрутизации и балансировки нагрузки Envoy, чтобы обойти сервис Kubernetes. Вместо проксирования по одному IP Envoy подключается прямо к IP пода. Для этого Istio сопоставляет конфигурацию Kubernetes с конфигурацией Envoy.
—--

Хотелось бы больше конкретики, истио из сервисов получает перечень ендпоинтов и передает их в каждый envoy + протокол по которому идет траффик?

Протокол нужен для реализации circuit breaker, типа если HTTP то можно исопльзовать HTTP код ответа?

в кубе да.

Вопрос про истио, по логике VirtualService и DestinationRule полностью заменяют куберовский сервис. Истио по другому реализует балансировку. Но без куберовского сервиса траффик не идет и я не понимаю зачем куберовский сервис нужен истио