неохота NGINX пробовать! Как то начал c  Istio (правда на маленьких нагрузках это было) очень прост в развёртовании/настройке

сейчас пытаюсь дать нагрузку в милион запросов в минуту - и такой облом :(

А это логи из чьего Envoy proxy? В приложениях? Или в Ingress / Egress gateway?

Имеет смысл Horizontal Pod Autoscaler настроить для приложений и для шлюзов, что бы распределялась нагрузка между подами.

Всем привет! Возникла такая проблема: реализован api gateway на istio ingress. Есть сервис который отвечает за аутентификацию и отдаёт  jwks ручку. И почти все ручки закрыты авторизацией с помощью JWT. Эта часть хорошо работает, но есть ручки например ручка рефреша токена, на ней разрешены все запросы с помощью AuthorizationPolicy. Но гейтвей отдаёт 401 jwt expired. Как я понял envoy проверяет токен, если он пришёл в заголовке до того как проверяет правила описанные в AuthorizationPolicy и поэтому невалидный токен автоматически 401. Как можно обойти эти проблему

RequestAuthenification настроен на гейтвей

Привет
Подскажите как в рамках одного неймспейса поднять разные версии приложений, так что приложение когда делает запрос "app1:8080"  обращается к app1 с такой же версией и к app1 с другой версией не обращается?

Насколько я нашел destination rule работает только для входящего трафика через гейтвей

вроде бы нет

Т.е. если у меня указан сабсет по лейблам, то он будет только внутри этого сабсета гонять трафик?

да, если я вас правильно понял

Просто сделал 15 реплик истио-ингресс и милион держит

Привет всем
Подскажите в HTTPMatchRequest в virtualService параметр sourceLabels работает так что проверяется лейбл у поды, которая делала реквест или я что-то не так прочитал?)

Всем привет! Подскажите куда копать...
Задача такая:
Доступ к определенным URL-ам должен быть ограничен по хэшу сертификата
Должно что-то типа того получиться?! :

configPatches:
    - applyTo: FILTER_CHAIN
      match:
        context: GATEWAY
        listener:
          portNumber: 443
      patch:
        operation: MERGE
        value:
          transport_socket:
            name: envoy.transport_sockets.tls
            typed_config:
              "@type": type.googleapis.com/envoy.api.v2.auth.DownstreamTlsContext
              require_client_certificate: true
              common_tls_context:
                validation_context:
                  trusted_ca:
                    filename: /etc/istio/ingressgateway-ca-certs/ca.crt
                  verify_certificate_hash:
                    - 94:B3:22:10:DD:08:9B:9B:98:2B:8C:94:C4:B3:EB:C1:87:5A:62:19:70:83:23:D5:8C:A5:80:DC:39:DA:E0:B6
                tls_certificates:
                  - certificate_chain:
                      filename: /etc/istio/ingressgateway-certs/cert.crt
                    private_key:
                      filename: /etc/istio/ingressgateway-certs/cert.key
                alpn_protocols:
                  - 'h2'
                  - 'http/1.1'

Поднял два ingress-gateway - хочу создать два ingressclassа - не могу в доке найти как

apiVersion: networking.k8s.io/v1beta1
kind: IngressClass
metadata:
 name: istio
spec:
 controller: istio.io/ingress-controller

ссылается на мой ingress-gateways или как задать конкретный gateway для класса

Направьте други

привет
Нашел пример конфига для гита для serviceEntry,  сделал так же - список хостов гита в аддрессес, в порте тип tcp, location mesh external, но доступа из-за истио до гита так и нет
подскажите где теоретически может быть косяк?
не могу приложить сам конфиг, он в другой сети

traffic policy какой?

а это где🙈

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

почему serviceEntry не работает, если указать подсеть 10.111.111.111/24 и работает если указать точный адрес который в нее входит