SSL_ERROR_SYSCALL的GKE入口与tls终止

Question

我有跟踪问题。我有部署和服务、前端配置和ingres，如下所示(跳过部署，因为它实际上并不有趣)：

---
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: backend-config
spec:
  healthCheck:
    type: HTTP
    requestPath: /readiness
    port: 8080
---
apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/app-protocols: '{"http":"HTTP"}'
    cloud.google.com/backend-config: '{"default": "backend-config"}'
  name: app
  labels:
    app: app
spec:
  type: ClusterIP
  selector:
    app: app
  ports:
    - name: http
      port: 80
      targetPort: http
      protocol: TCP
---
apiVersion: networking.gke.io/v1beta1
kind: FrontendConfig
metadata:
  name: frontend-config
spec:
  redirectToHttps:
    enabled: true
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    kubernetes.io/ingress.global-static-ip-name: 'app-ip'
    networking.gke.io/v1beta1.FrontendConfig: 'frontend-config'
    ingress.gcp.kubernetes.io/pre-shared-cert: 'ssl-certificate'
    kubernetes.io/ingress.allow-http: 'false'
  labels:
    app: app
spec:
#  tls:
#    - secretName: tls-secret
  rules:
    - host: myhost.com
      http:
        paths:
          - path: /*
            pathType: Prefix
            backend:
              service:
                name: app
                port:
                  name: http

如您所见，有静态IP地址和ssl证书，我向GCP注册了它们。

通过这种配置，我主要得到了

OpenSSL SSL_connect: SSL_ERROR_SYSCALL与.

如果我使用curl和“远程主机结束了与java客户端的握手”。但偶尔会有包进来。这和复制品的变化有关。正如您在上面看到的，我之前也尝试过使用kubernetes的秘密。也有同样的效果。

有没有人有同样的问题，或者有人知道我做错了什么？

只是为了防止ssl的问题。如您所见，证书作为自管理证书添加，并且是有效的。此外，它也在其他环境中工作。在证书部分是完整的链存储，直到根证书。

提前谢谢你。

更新：

我正在使用通配符证书。意味着我的sub.domain.com被*.domain.com证书所覆盖。试图像这样在入口中更改配置：

spec:
  tls:
    - hosts:
        - telematics.tranziit.com
      secretName: tranziit-tls-secret

下面是证书在GCP中的外观：GCP证书

没有成功-同样的效果。当我使用VM和正常的外部负载均衡器时，我使用这个证书作为自我管理-没有问题。

更新2：

在此期间，我删除了完全后端配置和前端配置。因此，服务和入口看起来如下：

---
apiVersion: v1
kind: Service
metadata:
  name: app-service
  labels:
    app: app-service
spec:
  type: ClusterIP
  selector:
    app: app
  ports:
    - name: http
      port: 80
      targetPort: http
      protocol: TCP 
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    kubernetes.io/ingress.global-static-ip-name: 'app-ip'
    kubernetes.io/ingress.allow-http: 'false'
  labels:
    app: app
spec:
  tls:
    - hosts:
        - sub.domain.com
      secretName: tls-secret
  rules:
    - host: sub.domain.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: app-service
                port:
                  name: http

当然是改名了。但是这个过程是这样的:一旦进入绿色，我就开始了几次curl -v https://mysubdomain-address，我最初得到了几个预期的答案和预期的响应，在冗长的卷曲日志中，我可以看到握手已经完成了。但在第三次左右之后，我又得到了这个问题。

curl -v https://mydomain/path
*   Trying XX.XXX.XXX.XX:443...
* Connected to mydomain (34.149.251.22) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to mydomain:443
* Closing connection 0
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to mydomain:443

我的意思是这不是稳定的结果。我可以看到数据包开始运行，也是因为这个接口接收消息并将它们推送到pub/sub，而在另一端，我有一个函数。因此，我可以看到调用该函数的方式如下：

函数调用

我真的不知道我还能尝试什么。唯一的办法是从GCP更改为托管的非通配符证书。这是IMHO唯一可以尝试的事情。

Answer 1

答案似乎是--使用NodePort，正如它在文档中描述的那样。由于我已经将服务类型更改为NodePort，所以入口正在稳定运行。不幸的是，谷歌声明没有任何限制，可以通过代理与NodePort或ClusterIP合作，但这一说法并没有得到证实。在我的特殊情况下，入口是用ClusterIP后端创建的，但是在tls握手过程中是不稳定的。

感谢@boredabdel的精神支持:)