火花提交遭遇PKIX路径构建失败

Question

所以我在引擎上有集群节点，我确实提交了一些火花作业。(我没有确切地使用星火提交，我使用java代码启动提交，但它们实际上是调用相同的Scala类，即SparkSubmit.class)

在我的例子中，我可以使用gcloud命令在笔记本上连接两个集群。

例如：

1. gcloud container clusters get-credentials cluster-1
2. gcloud container clusters get-credentials cluster-2

当我连接到集群-1，而火花-提交是提交到集群-1，它工作。但是，当我运行第二个gcloud命令并仍然提交到集群-1时，它将无法工作，并出现以下堆栈跟踪(简写版本)。

io.fabric8.kubernetes.client.KubernetesClientException: Failed to start websocket
at io.fabric8.kubernetes.client.dsl.internal.WatchConnectionManager$2.onFailure(WatchConnectionManager.java:194)
at okhttp3.internal.ws.RealWebSocket.failWebSocket(RealWebSocket.java:543)
at okhttp3.internal.ws.RealWebSocket$2.onFailure(RealWebSocket.java:208)
at okhttp3.RealCall$AsyncCall.execute(RealCall.java:148)
at okhttp3.internal.NamedRunnable.run(NamedRunnable.java:32)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1514)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)

我已经找了一段时间了，但没有成功。主要问题可能是火花提交发布时，它在与Kubernetes相关的本地机器上搜索某种证书，而前两个gcloud命令更改的上下文将其搞砸了。

我只是好奇，当我们进行火花提交时，远程K8s服务器如何确切地知道我是谁？这一切都牵涉到什么过程？

提前谢谢你。

Answer 1

PKIX path building failed错误意味着Java试图打开SSL连接，但无法找到验证服务器提供的证书的证书链(路径)。

正在运行的代码不信任群集提供的证书。集群可能使用的是自签名证书。

从命令行运行时，Java将在位于jre/lib/security/cacerts的信任库中查找链。作为更大环境(Tomcat、Glassfish等)的一部分运行，它将使用该环境的证书信任库。

由于您手动启动了spark_submit，您可能缺少一个选项来指定在何处找到密钥存储库(服务器证书和私钥)和信任存储库(CA证书)。这些通常被规定为：

-Djavax.net.ssl.trustStore=/somepath/truststore.jks 
-Djavax.net.ssl.keyStore=/somepath/keystore.jks

如果在Java 9+上运行，还需要指定StoreType：

-Djavax.net.ssl.keyStoreType=<TYPE>
-Djavax.net.ssl.trustStoreType=<TYPE>

通过Java 8，密钥存储始终是JKS。因为Java9，所以它们也可以是PKCS12。

在自签名密钥的情况下，可以从密钥库导出密钥，并将其作为受信任的证书导入信任存储。有几个网站的指导如何做到这一点。我发现杰克布·詹科夫的网站是相当可读的。

Answer 2

如果您想查看gcloud container clusters get-credentials cluster-1命令是什么，可以从头开始，查看~/.kube/config的内容

rm -rf ~/.kube
gcloud container clusters get-credentials cluster-1
cat ~/.kube/config
gcloud container clusters get-credentials cluster-2
cat ~/.kube/config

有些东西可能不匹配或冲突。或者可能是用户/上下文。也许您拥有这两个集群的凭据，但是您正在使用cluster-1的上下文来访问cluster-2。

$ kubectl config get-contexts
$ kubectl config get-clusters

~/.kube/config文件的结构应该如下所示：

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: <redacted> or file
    server: https://<IP>:6443
  name: cluster-1
- cluster:
    certificate-authority: <redacted> or file
    server: https://<IP>:8443
  name: cluster-2
contexts:
- context:
    cluster: cluster-1
    user: youruser
  name: access-to-cluster-1
- context:
    cluster: cluster-2
    user: youruser
  name: access-to-cluster-2
current-context: access-to-cluster-1
kind: Config
preferences: {}
users:
- name: ....
  user:
   ...
- name: ....
  user:
   ...

在代码中，它似乎使用了io.fabric8.kubernetes.client.KubernetesClient库。例如，在这个文件中，KubernetesDriverBuilder.scala