Почему использование TLS приводит к ошибке в восходящем направлении при использовании istio в кластере Kubernetes - PullRequest
Новая
       51

Почему использование TLS приводит к ошибке в восходящем направлении при использовании istio в кластере Kubernetes

0 голосов
/ 13 января 2020

Я пытаюсь развернуть службу в кластере Kubernetes. Все работает нормально, пока я не использую TLS.

Моя установка выглядит следующим образом: Azure Kubernetes Cluster с версией 1.15.7 Istio 1.4.2

То, что я до сих пор делал, это , Создание кластера и установка Istio с помощью следующей команды: 

istioctl manifest apply --set values.grafana.enabled=true \--set values.tracing.enabled=true \
--set values.tracing.provider=jaeger \
--set values.global.mtls.enabled=false \
--set values.global.imagePullPolicy=Always \
--set values.kiali.enabled=true \
--set "values.kiali.dashboard.jaegerURL=http://jaeger-query:16686" \
--set "values.kiali.dashboard.grafanaURL=http://grafana:3000"

Все запускается и все модули работают. Затем я создаю шлюз 

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: ddhub-ingressgateway
  namespace: config
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTP
      hosts:
        - "*.example.de"
    #  tls:
    #    httpsRedirect: true # sends 301 redirect for http requests
    - port:
        number: 443
        name: https
        protocol: HTTPS
      tls:
        mode: SIMPLE
        serverCertificate: /etc/istio/ingressgateway-certs/tls.crt
        privateKey: /etc/istio/ingressgateway-certs/tls.key
      hosts:
        - "*.example.de"
    - port:
        number: 31400
        name: tcp
        protocol: TCP
      hosts:
        - "*.example.de"

. Затем я импортирую свои пользовательские сертификаты, которые, как я полагаю, также работают, поскольку они смонтированы правильно, и при доступе к моей службе через браузер я вижу свойства защищенного соединения со всеми значениями.

Это моя развернутая служба: 

kind: Service
apiVersion: v1
metadata:
  name: hellohub-frontend
  labels:
    app: hellohub-frontend
  namespace: dev
spec:
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 8080
  type: ClusterIP
  selector:
    app: hellohub-frontend
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: hellohub-frontend
  namespace: dev
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: hellohub-frontend
    spec:
      containers:
        - image: ddhubregistry.azurecr.io/hellohub-frontend:latest
          imagePullPolicy: Always
          name: hellohub-frontend
          volumeMounts:
          - name: azure
            mountPath: /cloudshare
          ports:
          - name: http
            containerPort: 8080
      volumes:
      - name: azure
        azureFile:
          secretName: cloudshare-dev
          shareName: ddhub-share-dev
          readOnly: true

и виртуальная служба: 

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: hellohub-frontend
  namespace: dev
spec:
  hosts:
    - "dev-hellohub.example.de"
  gateways:
    - config/ddhub-ingressgateway
  http:
    - match:
        - uri:
            prefix: /
      route:
        - destination:
            host: hellohub-frontend.dev.svc.cluster.local
            port:
              number: 8080

Когда я получаю доступ к службе с помощью http. Страница моего сервиса появляется. При использовании https я всегда получаю сообщение «Ошибка подключения к исходящему каналу или отключение / сброс перед заголовками. Причина сброса: разрыв подключения».

Что мне не хватает или что я делаю неправильно? Какая разница, что делает Kubernetes не найти мою услугу. Я понимаю, что моя конфигурация завершает TLS на шлюзе, и связь внутри кластера одинакова, но, похоже, это не так.

Другой вопрос - как включить журналы отладки для колясок. Я не смог найти рабочий путь.

Заранее спасибо!

Ответы [ 2 ]

2 голосов
/ 14 января 2020

Вы пытались использовать istioctl для изменения уровня регистрации istio-proxy. 

istioctl proxy-config log <pod-name[.namespace]> --level all:warning,http:debug,redis:debug
2 голосов
/ 14 января 2020

Похоже, что шлюз пытался получить доступ к вашему восходящему каналу в режиме mtls через прокси-сервер-посредник, но в вашем контейнере "hellohub-frontend" не найден прокси-сервер-посланник. Включили ли вы istio-инъекцию для своего пространства имен "dev" или модуля, а также определил mtls-policy? 

apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
  name: "default"
spec:
  peers:
  - mtls:
      mode: STRICT
...