Предоставление виртуальной службы с глобальным включением istio и mTLS - PullRequest
Новая
       43

Предоставление виртуальной службы с глобальным включением istio и mTLS

0 голосов
/ 11 октября 2019

У меня есть эта конфигурация в моей сервисной сетке:

  • Глобальная поддержка mTLS и сетевая политика по умолчанию
  • Простое веб-развертывание, представленное как clusterip на порту 8080
  • http-шлюз для порта 80 и маршрутизация виртуальной службы на моем сервисе

Здесь gw и vs yaml 

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: http-gateway
spec:
  selector:
    istio: ingressgateway # Specify the ingressgateway created for us
  servers:
  - port:
      number: 80 # Service port to watch
      name: http-gateway
      protocol: HTTP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: simple-web
spec:
  gateways:
  - http-gateway
  hosts:
  - '*'
  http:
  - match:
    - uri:
        prefix: /simple-web
    rewrite:
      uri: /
    route:
    - destination:
        host: simple-web
        port:
          number: 8080

И vs, и gw находятся в одном и том же пространстве имен. Развертывание было создано и показано с помощью этих команд: 

k create deployment --image=yeasy/simple-web:latest simple-web
k expose deployment simple-web --port=8080 --target-port=80 --name=simple-web

и с помощью k get pods я получаю это: 

pod/simple-web-9ffc59b4b-n9f85   2/2     Running

Что происходит снаружи, указывая на нагрузку входного шлюзабалансировщик получаю 503 ошибку HTTP. Если я попытаюсь свернуться из шлюза ingressgateway, я доберусь до простого веб-сервиса. Почему я не могу зайти на сайт с включенным mTLS? Какая правильная конфигурация?

Ответы [ 2 ]

1 голос
/ 15 октября 2019

Как отметил @uren в своем ответе, эта проблема отсутствует в версии 1.3.2 istio. Поэтому одним из решений является использование более новой версии.

Если вы решили обновить istio до более новой версии, просмотрите документацию 1.3 Уведомление об обновлении и Шаги обновления , поскольку Istio все еще работаетв разработке и кардинально меняется с каждой версией.

Также, как упоминалось в комментариях @Manuel Castro, эта проблема, скорее всего, решена в Избегайте ошибок 503 при перенастройке маршрутов обслуживания , а более новая версия просто их обрабатываетлучше.

Создание как VirtualServices, так и DestinationRules, которые определяют соответствующие подмножества, с помощью одного вызова kubectl (например, kubectl apply -f myVirtualServiceAndDestinationRule.yaml недостаточно, поскольку ресурсы распространяются (с сервера конфигурации,т. е. сервер API Kubernetes) для экземпляров Pilot в конечном итоге непротиворечивым образом. Если VirtualService, использующий подмножества, прибывает до DestinationRule, где определены подмножества, конфигурация Envoy, сгенерированная Pilot wouСсылка на несуществующие восходящие пулы. Это приводит к ошибкам HTTP 503 до тех пор, пока все объекты конфигурации не станут доступны для Pilot.

Эту проблему можно избежать, временно отключив mTLS или используя permissive mode во время развертывания.

0 голосов
/ 11 октября 2019

Я только что установил istio-1.3.2 и k8s 1.15.1, чтобы воспроизвести вашу проблему, и она работала без каких-либо изменений. Вот что я сделал:

0.- создайте пространство имен с именем istio и включите автоматическое добавление коляски.

1.- $ kubectl run nginx --image nginx -n istio

2.- $ kubectl expose deploy nginx --port 8080 --target-port 80 --name simple-web -n istio

3.- $kubectl craete -f gw.yaml -f vs.yaml

Примечание: это ваши файлы.

Тест: 

$ curl a.b.c.d:31380/simple-web -I
HTTP/1.1 200 OK
server: istio-envoy
date: Fri, 11 Oct 2019 10:04:26 GMT
content-type: text/html
content-length: 612
last-modified: Tue, 24 Sep 2019 14:49:10 GMT
etag: "5d8a2ce6-264"
accept-ranges: bytes
x-envoy-upstream-service-time: 4


[2019-10-11T10:04:26.101Z] "HEAD /simple-web HTTP/1.1" 200 - "-" "-" 0 0 6 4 "10.132.0.36" "curl/7.52.1" "4bbc2609-a928-9f79-9ae8-d6a3e32217d7" "a.b.c.d:31380" "192.168.171.73:80" outbound|8080||simple-web.istio.svc.cluster.local - 192.168.171.86:80 10.132.0.36:37078 - -

И, конечно, mTLSбыл включен, это из команды ingress-gateway description:

--controlPlaneAuthPolicy MUTUAL_TLS

Итак, я не знаю, что не так, но вы можете пройти через эти шаги и отказаться от вещей.

Примечание: причина, по которой я атакую ​​шлюз istio на порту 31380, заключается в том, что мой k8s сейчас находится на виртуальных машинах, и я не хотел раскручивать кластер GKE для теста.

EDIT

Просто развернул другое развертывание с вашим образом, выставил его как simple-web-2 и снова работал. Может быть, мне повезло с istio: 

$ curl a.b.c.d:31380/simple-web -I
HTTP/1.1 200 OK
server: istio-envoy
date: Fri, 11 Oct 2019 10:28:45 GMT
content-type: text/html
content-length: 354
last-modified: Fri, 11 Oct 2019 10:28:46 GMT
x-envoy-upstream-service-time: 4

[2019-10-11T10:28:46.400Z] "HEAD /simple-web HTTP/1.1" 200 - "-" "-" 0 0 5 4 "10.132.0.36" "curl/7.52.1" "df0dd00a-875a-9ae6-bd48-acd8be1cc784" "a.b.c.d:31380" "192.168.171.65:80" outbound|8080||simple-web-2.istio.svc.cluster.local - 192.168.171.86:80 10.132.0.36:42980 - -

Какая у вас среда k8s?

EDIT2 

# istioctl authn tls-check curler-6885d9fd97-vzszs simple-web.istio.svc.cluster.local -n istio
HOST:PORT                                   STATUS     SERVER     CLIENT     AUTHN POLICY     DESTINATION RULE
simple-web.istio.svc.cluster.local:8080     OK         mTLS       mTLS       default/         default/istio-system
...