Istio Mtls配置错误导致行为不一致

时间:2020-04-25 10:07:20

标签: kubernetes tls1.2 istio mtls

我已经在GKE群集上部署了2个istio启用的服务。

istio的版本为1.1.5,GKE位于v1.15.9-gke.24

istio已与global.mtls.enabled=true一起安装

serviceA能够正确通信

serviceB显然存在与TLS相关的问题。

我启动了一个非istio启用的部署,仅用于测试,然后执行到此curl这两个服务端点的测试包中。

/ # curl -v serviceA
* Rebuilt URL to: serviceA/
*   Trying 10.8.61.75...
* TCP_NODELAY set
* Connected to serviceA (10.8.61.75) port 80 (#0)
> GET / HTTP/1.1
> Host: serviceA
> User-Agent: curl/7.57.0
> Accept: */*
>
< HTTP/1.1 200 OK
< content-type: application/json
< content-length: 130
< server: istio-envoy
< date: Sat, 25 Apr 2020 09:45:32 GMT
< x-envoy-upstream-service-time: 2
< x-envoy-decorator-operation: serviceA.mynamespace.svc.cluster.local:80/*
<
{"application":"Flask-Docker Container"}
* Connection #0 to host serviceA left intact


/ # curl -v serviceB
* Rebuilt URL to: serviceB/
*   Trying 10.8.58.228...
* TCP_NODELAY set
* Connected to serviceB (10.8.58.228) port 80 (#0)
> GET / HTTP/1.1
> Host: serviceB
> User-Agent: curl/7.57.0
> Accept: */*
>
* Recv failure: Connection reset by peer
* Closing connection 0
curl: (56) Recv failure: Connection reset by peer

进入有问题的服务的envoy代理并打开跟踪级别日志记录后,我看到此错误

serviceB-758bc87dcf-jzjgj istio-proxy [2020-04-24 13:15:21.180][29][debug][connection] [external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:168] [C1484] handshake error: 1
serviceB-758bc87dcf-jzjgj istio-proxy [2020-04-24 13:15:21.180][29][debug][connection] [external/envoy/source/extensions/transport_sockets/tls/ssl_socket.cc:201] [C1484] TLS error: 268435612:SSL routines:OPENSSL_internal:HTTP_REQUEST

两个容器的特使边车,在调试其证书时显示类似的信息。

我通过在两个istio容器中执行,cd-/etc/certs/..data并运行

openssl x509 -in root-cert.pem -noout -text

两个root-cert.pem是相同的!

由于这2个istio代理在证书方面具有完全相同的tls配置,为什么在serviceB上出现这种神秘的SSL错误?

FWIW serviceB与未启用istio的postgres服务进行通信。

那是造成问题的原因吗?

curling serviceB的容器容器本身会返回健康的响应。

0 个答案:

没有答案