Istio 503: между (публичным) шлюзом и сервисом

Question

Я играл с моей конфигурацией кластера Istio, и я оказался в состоянии, из которого я не могу отладить выход.

У меня есть шлюз SDS + с настроенным публичным IP,Я развернул приложение Istio HelloWorld на порту 5000. Я могу:

• exec в istio-proxy на модуле helloworld-[rnd] и curl localhost:5000/hello - это прекрасно работает
• . Проверьте с помощьюistioctl proxy-config cluster (и т. Д.) Из https://istio.io/docs/ops/troubleshooting/network-issues/ и https://istio.io/docs/ops/troubleshooting/proxy-cmd/ - все сообщают о ОК всем, SYNC: ed и т. П.
• Я могу сделать kubectl exec istio-ingressgateway-[rnd] /bin/bash, а затем curl helloworld.mynamespace:5000/helloуспешно (возвращается Hello version: v2 ...

Но я не могу сделать так, чтобы ingressgateway фактически возвращал ничего, кроме 503, при запросе его публично связанного IP-адреса. Если я запрашиваю без пути /hello, он возвращает 404 вместо этого, так что он явно пытается маршрутизировать к службе / развертыванию helloworld и терпит неудачу.

Так что я нахожусь в состоянии, когда я могу фактически связаться со своей helloworld службой с шлюза Istio Ingress Gateway, когдаспрашивая сам шлюз curl localhost/hello -i, или с нашей стороны сеть curl -i http://35.x.y.z/hello Я всегда получаю 503 Service Unavailable Back

У меня нет ни DestinationRule, ни политики, применяемой к helloworld, и у меня Istio в строгом mTLS.

Ранее я мог сегодня получить доступ к (другим) услугам черезgress gateway, но потом я начал убирать вещи (до того момента, когда у меня есть только сервис helloworld VirtualService + Gateway и никаких других), и теперь он не работает. Должна быть возможность отладки.

Что не так?

Не связано (могу сказать):

• Входной шлюз Kubernetes Istio отвечает503 всегда (у меня нет clusterIP: нет)
• При доступе к сервису с использованием istio ingress выдается ошибка 503, когда mTLS включен (после k exec -c istio-proxy helloworld-[rnd] -- curl http://localhost:15000/logging?level=true, посланник istio-proxyвообще не получает вызовов от istio-ingressgateway, трафик никогда не покидает входной модуль, в отличие от этого вопроса)
• У меня включена сетевая политика CNI + GKE (но ее отключение не помогло) иправило Calico-allow-all не помогло, поэтому так быть не должно;Кроме того, я могу свернуться с входного шлюза, поэтому есть возможность подключения
• https://github.com/istio/istio/tree/master/samples/helloworld - config

Answer 1

Прежде всего для использования curl с SDS-шлюзом Вам необходимо использовать его, как описано в документации Istio .

$ curl -v -HHost:httpbin.example.com \
--resolve httpbin.example.com:$SECURE_INGRESS_PORT:$INGRESS_HOST \
--cacert httpbin.new.example.com/2_intermediate/certs/ca-chain.cert.pem \
https://httpbin.example.com:$SECURE_INGRESS_PORT/status/418

...
HTTP/2 418
...
-=[ teapot ]=-

   _...._
 .'  _ _ `.
| ."` ^ `". _,
\_;`"---"`|//
  |       ;/
  \_     _/
    `"""`

---

Во-вторых, согласно Документация Istio , использующая строгую политику аутентификации mTLS (взаимный TLS), требует, чтобы обе службы выполняли связь TLS. В вашем случае вы пытаетесь получить доступ к текстовому (HTTP) сервису через Istio, который использует TLS. Это вызывает конфликт взаимной конфигурации TLS.

Это можно проверить с помощью команды istioctl в этом разделе документации:

istioctlКоманда предоставляет опцию для этой цели. Вы можете сделать:

$ istioctl authn tls-check $CLIENT_POD httpbin.default.svc.cluster.local

HOST:PORT                                  STATUS     SERVER     CLIENT     AUTHN POLICY        DESTINATION RULE
httpbin.default.svc.cluster.local:8000     OK         mTLS       mTLS       default/            default/istio-system

Где $CLIENT_POD - идентификатор одного из модулей клиентской службы.

См. Проверка конфигурации взаимной TLS длядополнительная информация.

Чтобы решить эту проблему, mTLS должен быть отключен для этой службы, чтобы Istio принимала подключение от простого текста к службам TLS. Следуйте этому руководству , чтобы создать правило назначения, разрешающее не-TLS-связь для указанной службы

. Чтобы подтвердить, что это вызывает эту проблему, вы можете временно включить режим Permissive . .

---

Редактировать:

По ссылке, указанной вами в последнем файле развертывания helloworld.yaml, нет targetPort, и поэтому nginx недоступен.

Вот как это должно выглядеть:

apiVersion: v1
kind: Service
metadata:
  name: helloworld
  labels:
    app: helloworld
spec:
  ports:
  - port: 5000
    name: http
    targetPort: 80
  selector:
    app: helloworld
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloworld-v1
  labels:
    version: v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: helloworld
      version: v1
  template:
    metadata:
      labels:
        app: helloworld
        version: v1
    spec:
      terminationGracePeriodSeconds: 0
      containers:
      - name: helloworld
        image: docker.io/istio/examples-helloworld-v1
        resources:
          requests:
            cpu: "100m"
        imagePullPolicy: IfNotPresent #Always
        ports:
        - containerPort: 5000
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloworld-v2
  labels:
    version: v2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: helloworld
      version: v2
  template:
    metadata:
      labels:
        app: helloworld
        version: v2
    spec:
      terminationGracePeriodSeconds: 0
      containers:
      - name: helloworld
        image: docker.io/istio/examples-helloworld-v2
        resources:
          requests:
            cpu: "100m"
        imagePullPolicy: IfNotPresent #Always
        ports:
        - containerPort: 5000