не удалось найти искру при отправке PKIX - PullRequest
0 голосов
/ 16 ноября 2018

Итак, у меня есть узел кластера в Google Kubernetes Engine, и я делаю spark-submit для запуска некоторого задания spark.(Я не использовал spark-submit точно, я запускаю submit с использованием java-кода, но они по сути вызывают тот же класс Scala, который является SparkSubmit.class)

И в моем случае у меня есть два кластераЯ могу подключиться к ноутбуку с помощью команды gcloud.

например,

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

когда я подключаюсь к кластеру-1, а spark-submit отправляет в кластер-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)

Я искал некоторое время безуспех.Основная проблема, вероятно, заключается в том, что при запуске spark-submit он ищет на локальном компьютере какие-то учетные данные, относящиеся к Kubernetes, и изменение контекста предыдущими двумя командами gcloud испортило его.

Мне просто любопытноКогда мы делаем spark-submit, как именно удаленный сервер K8s знает, кто я?Какой процесс аутентификации связан со всем этим?

Заранее спасибо.

Ответы [ 2 ]

0 голосов
/ 17 ноября 2018

Если вы хотите увидеть, что делает команда 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

0 голосов
/ 17 ноября 2018

Ошибка 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. Начиная с Java 9 они также могут быть PKCS12.

В случае самозаверяющего ключа его можно экспортировать из хранилища ключей и импортировать в доверенное хранилище в качестве доверенного сертификата. Есть несколько сайтов с инструкциями, как это сделать. Я нахожу сайт Якоба Дженкова вполне читабельным.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...