Ssl Istio:无法通过HTTP/HTTPS通过网关访问服务 Istio:1.3（在更新到1.3之前也尝试了1.1） K8s:1.16.2 云提供商：DigitalOcean

我有一个带Istio的集群设置。我已经启用了grafana/kiali，还安装了kibana和RabbitMQ管理UI，对于所有这些，我已经配置了网关和虚拟服务（都在istio系统名称空间中），以及使用SDS和cert manager的HTTPS，并且一切正常。这意味着我可以通过一个子域通过HTTPS在浏览器中访问这些资源

然后，我部署了一个微服务（实际应用程序的一部分），并为它创建了

服务

、

虚拟服务

和

网关

资源（目前，除了使用不同子域和不同端口的rabbitmq之外，它是唯一的一个服务和网关）。并且它位于默认名称空间中

$ kubectl get gateway

NAME             AGE
gateway-rabbit   131m
tg-gateway       45m

$ kubectl get po

NAME                           READY     STATUS    RESTARTS   AGE
rabbit-rabbitmq-0              2/2       Running   2          134m
tg-app-auth-79c578b94f-mqsz9   2/2       Running   0          46m

如果我尝试通过端口转发连接到我的服务，我可以从

localhost:8000/api/me

获得成功响应（同样是healthz，readyz都返回200，pod有0次重新启动），因此它工作正常

kubectl port-forward $(kubectl get pod --selector="app=tg-app-auth" --output jsonpath='{.items[0].metadata.name}') 8000:8000

但我既不能通过HTTP也不能通过HTTPS访问它。我使用HTTP获得

404

，并使用HTTPS获得以下响应：

*   Trying MYIP...
* TCP_NODELAY set
* Connected to example.com (MYIP) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to www.example.com:443 
* Closing connection 0
curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to www.example.com:443

以下是我的yaml文件：

网关：

apiVersion: networking.istio.io/v1alpha3

kind: Gateway

metadata:
  name: tg-gateway
  namespace: default

spec:
  selector:
    istio: ingressgateway

  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - www.example.com
    tls:
      httpsRedirect: true
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - www.example.com
    tls:
      mode: SIMPLE
      serverCertificate: sds
      privateKey: sds
      credentialName: tg-certificate

apiVersion: v1

kind: Service

metadata:
  name: tg-app-auth
  namespace: default
  labels:
    app: tg-app-auth

spec:
  selector:
    app: tg-app-auth

  ports:
  - name: http
    port: 8000

服务：

apiVersion: networking.istio.io/v1alpha3

kind: Gateway

metadata:
  name: tg-gateway
  namespace: default

spec:
  selector:
    istio: ingressgateway

  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - www.example.com
    tls:
      httpsRedirect: true
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - www.example.com
    tls:
      mode: SIMPLE
      serverCertificate: sds
      privateKey: sds
      credentialName: tg-certificate

apiVersion: v1

kind: Service

metadata:
  name: tg-app-auth
  namespace: default
  labels:
    app: tg-app-auth

spec:
  selector:
    app: tg-app-auth

  ports:
  - name: http
    port: 8000

虚拟服务

apiVersion: networking.istio.io/v1alpha3

kind: VirtualService

metadata:
  name: tg-app-auth-vs
  namespace: default

spec:
  hosts:
  - www.example.com

  gateways:
  - tg-gateway

  http:
  - match:
    - port: 443
    - uri:
        prefix: /api/auth
    rewrite:
      uri: /api
    route:
    - destination:
        host: tg-app-auth
        port:
          number: 8000

---

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: tg-app-auth-dr
  namespace: default
spec:
  host: tg-app-auth
  trafficPolicy:
    tls:
      mode: DISABLE

我试图删除所有HTTPS和TLS的详细信息，并仅使用HTTP进行配置，但仍然无法得到任何响应。我阅读了github上的所有问题，但没有任何帮助，似乎我犯了一个非常愚蠢的错误。所有这些配置与我对grafana/kibana/kiali/rabbit的配置基本相同，并且都可以正常工作

UPD：试着得到回应，它也很好，但我不能 从LB IP或域获取响应

kubectl exec $(kubectl get pod --selector app=tg-app-auth --output jsonpath='{.items[0].metadata.name}') -c istio-proxy -- curl -v http://$(kubectl get endpoints tg-app-auth -o jsonpath='{.subsets[0].addresses[0].ip}'):8000/api/me

UPD

所有状态都正常。有很多不同的端口，但我只复制了80/443

$ istioctl authn tls-check <pod_name>

cert-manager-webhook.istio-system.svc.cluster.local:443 
istio-galley.istio-system.svc.cluster.local:443
istio-ingressgateway.istio-system.svc.cluster.local:80
istio-ingressgateway.istio-system.svc.cluster.local:443
istio-sidecar-injector.istio-system.svc.cluster.local:443
kubernetes.default.svc.cluster.local:443

---

这个问题非常简单和愚蠢。我在Istio values.yml中启用了global.k8sIngress.enabled=true。将其更改为false后，所有操作都开始工作。

您是否可以尝试在istio命名空间中使用kibana、rabbitmq等创建网关、vs、sv和目标规则？我想知道这是否有效，或者我们必须找其他地方，对我来说yamls look ok，我在这里没有看到任何错误。谢谢你的回复！接下来的情况是：如果我们按原样移动所有内容（仅更改名称空间），结果是相同的，如果我们将HTTPS端口从443更改为31400（在istio gateway/values.yml配置中显示的非标准端口），它将开始工作！在HTTP上，我总是得到404（重定向到HTTPS不工作，并且将端口从80更改为31400也不工作）。我将所有内容从istio系统移回默认，但保留31400端口，而不是443端口，并且其行为方式与istio系统相同。太奇怪了。下一步我们应该尝试什么？你能告诉我为什么使用

tls:mode:SIMPLE-serverCertificate:sds-privateKey:sds-credentialName:tg-certificate

，然后使用

trafficPolicy:tls:mode:DISABLE

，就像你创建了tls，然后在目标规则中禁用它一样，也许这就是问题所在？你能检查一下istio入口网关是否正在监听端口443吗？哦，这是我试图让它工作的一个实验。无论如何，无论是否使用此目的地规则（以及启用/禁用的流量策略），我们都有相同的行为。是的，istio ingressgateway正在侦听443（80:31380/TCP、443:31390/TCP、31400:31400/TCP等）1.您使用nodeport还是loadbalancer？是库比德，对吗？3.当你回显主机和端口一切正常时，你是否像这样导出了主机和端口？4.您是否在默认命名空间上启用了sidecar注入？5.您是否在默认命名空间中创建了secret<代码>必须在istio系统命名空间中将该秘密命名为istio ingressgateway certs，以与此任务中使用的istio默认入口网关的配置一致。我有一个类似的问题-http/80正常工作，但https/443不正常-您知道为什么将其更改为false有效吗？它有什么作用？