Kubernetes上でSparkを実行

• セキュリティ
  • ユーザ識別
  • ボリュームのマウント
• 必要条件
• どのように動くか
• Kubernetesへのアプリケーションの提出
  • Docker Images
  • クラスタ モード
  • クライアントモード
    • クライアントモードのネットワーク
    • クライアントモードのexecutor podのガベージコレクション
    • 認証のパラメータ
  • 依存性の管理
  • 秘密鍵の管理
  • Pod Template
  • Kubernetes ボリュームの使用
  • ローカルストレージ
    • ローカルストレージのためにRAMを使用
  • 内省とデバッグ
    • アクセス ログ
    • Driver UIのアクセス
    • デバッギング
  • Kubernetes 機能
    • 設定ファイル
    • Contexts
    • 名前空間
    • RBAC
  • Spark アプリケーション管理
  • 将来の作業
• 設定
  • Sparkのプロパティ

SparkはKubernetesによって管理されるクラスタ上で実行することができます。この機能はSparkに追加されたnative Kubernetesスケジューラを利用します。

セキュリティ

認証のようなセキュリティ機能はデフォルトでは有効にされていません。インターネットや信頼できないネットワークに開かれたクラスタを配備する場合、認証されていないアプリケーションをクラスタ上で実行することを防ぐためにクラスタへのアクセスを安全にすることが重要です。Sparkを実行する前にSpark セキュリティとこのドキュメントの特定のセキュリティの章を見てください。

ユーザ識別

Dockerfiles が提供するプロジェクトからビルドされたイメージは、デフォルトの UID 185 のデフォルトの USER ディレクティブ が含まれます。これは結果のイメージがコンテナ内でこのUIDとしてSparkプロセスを実行することを意味します。セキュリティを考慮する配備では、カスタムイメージに望ましい非特権UIDとGIDを指定するUSER ディレクティブを提供することを考慮する必要があります。結果の UID は、Spark 実行可能ファイルを実行できるようにするために、補足グループにルートグループを含める必要があります。提供された docker-image-tool.sh スクリプトを使って独自のイメージを構築するユーザは、望ましい UI を指定するために -u <uid> オプションを使うことができます。

あるいは、Pod Template機能を使用して、runAsUserを持つSecurity ContextをSparkがサブミットするポッドに追加することができます。これはイメージ自身の中で USER ディレクティブを上書きするために使うことができます。これはユーザの協力が必要であり、共有環境に適した解決策ではない可能性があることに注意してください。クラスタの管理者はポッドを実行するユーザを制限したい場合に、Pod セキュリティ ポリシーを使う必要があります。

ボリュームのマウント

このドキュメントで後述するように、K8SでのKubernetes ボリュームを使ったSparkは、特定のボリューム型をドライバおよび executorのポッドにマウントできるようにする設定オプションを提供します。特に、Kubernetesのドキュメントに記載されているように、既知のセキュリティ脆弱性を持つhostPathボリュームを許可します。

クラスタの管理者はhostPathヴォリュームを環境に適切にマウントする機能を制限するためにPod セキュリティ ポリシー を使う必要があります。

必要条件

• Spark 2.3以上の実行可能な配布物。
• kubectlを使ってアクセスが設定された version >= 1.6 の 実行中のKubernetes クラスタ。動作するKubernetesクラスタをまだ持っていない場合は、minikubeを使ってローカルマシーン上にテストクラスタをセットアップできます。
  • DNSのアドオンが有効にされたminikubeの最新リリースを使うことをお勧めします。
  • デフォルトのminikubeの設定はSparkアプリケーションを実行するためには十分では無いことに注意してください。1つのexecutorを持つ1つのSparkアプリケーションを開始できるように3つのCPUと4Gのメモリをお勧めします。
  • Spark環境のkubernetes-client ライブラリのバージョンと、Kubernetes クラスタのバージョンとの互換性を調べてください。
• クラスタ内の list, create, edit および delete ポッド に適切なパーミッションを持つ必要があります。kubectl auth can-i <list|create|edit|delete> podsを実行することでこれらのリソースをリスト化することを検証することができます。
  • ドライバpodによって使われるサービスアカウントの証明書がpod、サービスおよび設定マップを作成できる必要があります。
• クラスタ内に設定されたKubernetes DNS を持たなければなりません。

どのように動くか

spark-submit はSparkアプリケーションをKubernetesクラスタにサブミットするために直接使うことができます。サブミットの仕組みは以下のように動作します:

• SparkはKubernetes pod内で実行するSparkドライバを作成します。
• ドライバは同じくKubernetes pod内で実行するexecutorを作成し、それらに接続し、アプリケーションコードを実行します。
• アプリケーションが完了する時、executor podは終了し一掃されますが、ドライバpodがログに残り、結果的にガベージコレクトあるいは手動で一掃されるまでKubernetes API内で“completed” 状態で残ります。

完了状態で、ドライバpodは何も計算資源あるいはメモリ資源を使わない事に注意してください。

ドライバとexecutor pode のスケジューリングはKubernetesによって扱われます。Kubernetes API への通信は、fabric8 を使います。設定プロパティを使って node selector によって利用可能なノードのサブセット上でドライバとexecutorのpodをスケジュールすることが可能です。将来のリリースではnode/pod affinitiesのようなより進んだスケジュールのヒントnode/pod affinitiesを使うことが可能でしょう。

Kubernetesへのアプリケーションの提出

Docker Images

Kubernetes はユーザにpod内のコンテナに配備することができるイメージを提供することを要求します。イメージはKubernetesがサポートするコンテナ実行環境内で実行されるように構築されます。DockerはKubernetesと一緒に頻繁に使われるコンテナ実行環境です。Spark (バージョン 2.3から) はこの目的に使うことができるか、個々のアプリケーションの必要に合致するようにカスタマイズされたDockerfileを同梱します。それはkubernetes/dockerfiles/ ディレクトリ内で見つけることができます。

SparkはKubernetesバックエンドと一緒に使うDockerイメージを構築および公開するために使うことができる bin/docker-image-tool.sh スクリプトを同梱します。

使い方の例:

$ ./bin/docker-image-tool.sh -r <repo> -t my-tag build
$ ./bin/docker-image-tool.sh -r <repo> -t my-tag push

これはデフォルトの Dockerfiles が提供するプロジェクトを使ってビルドします。カスタム Dockerfiles の提供など、このツールの動作をカスタマイズするために利用できるオプションを表示するには、-h フラグを付けて実行してください。

デフォルトでは、bin/docker-image-tool.sh は JVMジョブを実行するための docker イメージをビルドします。追加の言語バインディングのDockerイメージをビルドするには、オプトインする必要があります。

使い方の例

# To build additional PySpark docker image
$ ./bin/docker-image-tool.sh -r <repo> -t my-tag -p ./kubernetes/dockerfiles/spark/bindings/python/Dockerfile build

# To build additional SparkR docker image
$ ./bin/docker-image-tool.sh -r <repo> -t my-tag -R ./kubernetes/dockerfiles/spark/bindings/R/Dockerfile build

クラスタ モード

クラスタモードで Spark Piを実行するために、

$ ./bin/spark-submit \
    --master k8s://https://<k8s-apiserver-host>:<k8s-apiserver-port> \
    --deploy-mode cluster \
    --name spark-pi \
    --class org.apache.spark.examples.SparkPi \
    --conf spark.executor.instances=5 \
    --conf spark.kubernetes.container.image=<spark-image> \
    local:///path/to/examples.jar

spark-submitへの--master コマンドライン引数で渡すか、アプリケーション設定の中でspark.masterを設定するかのどちらかで指定されるSparkマスターは、k8s://<api_server_host>:<k8s-apiserver-port>の形式を持つURLでなければなりません。HTTPS ポート 443 であっても、ポートは常に指定する必要があります。マスター文字列にk8s://を前に付けることで、api_server_url.で接続されるAPIサーバを使ってSparkアプリケーションをKubernetesクラスタ上で起動させるでしょう。HTTPプロトコルがURL内で指定されない場合、デフォルトは https です。例えば、マスターをk8s://example.com:443 に設定することは、k8s://https://example.com:443 に設定することと等しいですが、異なるポート上でTLS無しで接続し、マスターはk8s://http://example.com:8080に設定されるでしょう。

Kubernetes モードでは、spark.app.name あるいはspark-submitへの--name引数によって指定されるSparkアプリケーション名がドライバとexecutorのように生成されるKubernetesリソースに名前を付けるためにデフォルトで使われます。ですので、アプリケーション名は英数字の小文字、- と . から成る必要があり、英数字で開始および終了しなければなりません。

Kubernetes クラスタ セットアップがある場合、apiサーバのURLを見つける一つの方法はkubectl cluster-infoを実行することです。

$ kubectl cluster-info
Kubernetes master is running at http://127.0.0.1:6443

上の例では、特定のKubernetesクラスタはspark-submitへの引数として--master k8s://http://127.0.0.1:6443で指定することでspark-submitと一緒に使うことができます。更に、Kubernetes APIと通信するために認証プロキシ、kubectl proxy を使うこともできます。

ローカルのプロキシは以下で開始することができます:

$ kubectl proxy

ローカルプロキシが localhost:8001 で実行中の場合、spark-submitの引数として--master k8s://http://127.0.0.1:8001を使うことができます。最後に、上の例ではlocal://のスキーマを持つ特定のURIを使ってjarを指定することに注意してください。このURIは既にDockerイメージ内にあるjarの例の場所です。

クライアントモード

Spark 2.4.0から、Kubernetes上でクライアントモードでSparkアプリケーションを実行することができます。アプリケーションがクライアントモードで実行する時、ドライバーはpod内あるいは物理ホスト上で実行することができます。アプリケーションをクライアントモードで実行する場合、以下の要素を明らかにすることをお勧めします:

クライアントモードのネットワーク

SparkのexecutorはSpark executorから道をたどることが可能なホスト名とポート上でSparkドライバに接続できなければなりません。Sparkがクライアントモードで動作するために必要とされる特定のネットワーク設定はセットアップごとに変わるでしょう。ドライバをKubernetes pod内で実行する場合、ドライバーpodが不変のホスト名によってexecutorから道をたどることができるようにheadless service を使うことができます。headlessサービスを配備する時は、サービスのラベルのセレクタが他のpodではなくドライバーpodだけに一致するようにしてください; ドライバーpodを十分にユニークなラベルに割り当て、headlessサービスのラベルセレクタ内でそのラベルを使うことをお勧めします。spark.driver.host を使ってドライバのホスト名を、sparkドライバのポートをspark.driver.portに指定します。

クライアントモードのexecutor podのガベージコレクション

Sparkドライバをポッド内で実行する場合、spark.kubernetes.driver.pod.nameをそのポッドの名前に設定することを強くお勧めします。このプロパティが設定された場合、SparkのスケジューラはexecutorポッドをOwnerReference付きで配備します。これにより、ドライバのポッドがクラスタから削除されると、アプリケーションの全てのexecutorポッドも削除されます。ドライバはspark.kubernetes.namespaceで指定された名前空間内の指定された名前のポッドを探し、そのポッドを指している OwnerReference が各executorポッドの OwnerReferences リストに追加されます。OwnerReferenceを実際にそのドライバポッドではないポッドに設定しないように注意してください。さもなければ、間違ったポッドが削除された時にexecutorが途中で終了するかもしれません。

アプリケーションがポッド内で実行されていない場合、あるいはアプリケーションが実際にポッド内で実行中の時にspark.kubernetes.driver.pod.name が設定されていない場合、アプリケーションが終了する時にexecutorポッドがクラスタから適切に削除されないかもしれないことに注意してください。Sparkスケジューラはこれらのポッドを削除しようとしますが、もしAPIサーバへのネットワーク リクエストが何らかの理由で失敗した場合、これらのポッドはクラスタ内に残ります。executor プロセスは、それらがドライバに到達できない場合に終了すべきです。つまり、executorポッドはアプリケーションが終了した後でクラスタ内のコンピュータ リソース (CPUとメモリ)を消費すべきではありません。

executorのポッド名を完全に制御するために、spark.kubernetes.executor.podNamePrefixを使うことができます。このプロパティを設定する時は、同じ名前空間内の全てのジョブで壱位にすることを強くお勧めします。

認証のパラメータ

クライアントモードのKubernetes認証パラメータには、正確なプリフィックスspark.kubernetes.authenticateを使ってください。

依存性の管理

アプリケーションの依存がHDFSあるいはHTTPサーバのようなリモートの場所でホストされる場合、それらは適切なリモートURIで参照されるかもしれません。また、アプリケーションの依存は独自のビルドDockerイメージへあらかじめマウントすることができます。それらの依存はDockerファイル内でlocal:// URI および/あるいは SPARK_EXTRA_CLASSPATH環境変数を使って参照されるクラスパスに追加することができます。spark-submit内の独自のビルドDockerイメージ内で依存物を参照する場合、local:// スキーマも必要です。file:// スキーマを使うか、(フルパスを使って)スキーマ無しで、送信クライアントのファイルシステムからの依存関係をサポートします。宛先は Hadoop 互換のファイルシステムでなければなりません。S3 を使った一般的な例では、以下のオプションを渡します:

...
--packages org.apache.hadoop:hadoop-aws:3.2.2
--conf spark.kubernetes.file.upload.path=s3a://<s3-bucket>/path
--conf spark.hadoop.fs.s3a.access.key=...
--conf spark.hadoop.fs.s3a.impl=org.apache.hadoop.fs.s3a.S3AFileSystem
--conf spark.hadoop.fs.s3a.fast.upload=true
--conf spark.hadoop.fs.s3a.secret.key=....
--conf spark.driver.extraJavaOptions=-Divy.cache.dir=/tmp -Divy.home=/tmp
file:///full/path/to/app.jar

アプリケーションの jar ファイルは S3 にアップロードされ、ドライバが起動される時にドライバポッドにダウンロードされ、クラスパスに追加されます。Spark は、並列して実行されている Spark アプリケーションとの競合を避けるために、アップロードパスの下にランダムな名前のサブディレクトリを作成します。ユーザは自分のニーズに応じて作成されたサブディレクトリを管理することができます。

クライアントスキーマはアプリケーション jar、およびプロパティspark.jars、spark.filesおよびspark.archivesで指定された依存関係によってサポートされます。

重要: 全てのクライアント側の依存関係は、フラットなディレクトリ構造で指定されたパスにアップロードされるため、ファイル名はユニークでなければなりません。そうでなければファイルは上書きされます。また、派生した s8s イメージのデフォルトの ivy ディレクトリに必要なアクセス権を持つか、上のように設定を変更するようにしてください。後者では、クラスタモードで --packages を使う場合にも重要です。

秘密鍵の管理

Kubernetes のSecrets はSparkアプリケーションが安全なサービスにアクセスするための証明書を提供するために使うことができます。ユーザ定義の secret をドライバコンテナにマウントするために、ユーザはspark.kubernetes.driver.secrets.[SecretName]=<mount path>形式の設定プロパティを使うことができます。同様に、spark.kubernetes.executor.secrets.[SecretName]=<mount path>形式の設定プロパティは、ユーザ定義のsecretをexecutorのコンテナにマウントするために使うことができます。マウントされるsecretはドライバとexecutor podと同じ名前空間にあると仮定されることに注意してください。例えば、spark-secretという名前のsecretをドライバとexecutorの両方のコンテナのパス/etc/secretsにマウントするには、以下のオプションをspark-submit コマンドに追加してください:

--conf spark.kubernetes.driver.secrets.spark-secret=/etc/secrets
--conf spark.kubernetes.executor.secrets.spark-secret=/etc/secrets

環境変数を介して秘密鍵を使うには、spark-submitコマンドに次のオプションを使用します:

--conf spark.kubernetes.driver.secretKeyRef.ENV_NAME=name:key
--conf spark.kubernetes.executor.secretKeyRef.ENV_NAME=name:key

Pod Template

Kubernetes では、テンプレートファイルからポッドを定義することができます。Spark ユーザは同様にテンプレートファイルを使って、Spark 構成でサポートされないドライバまたは executor のポッド構成を定義することができます。そのためには、spark プロパティ spark.kubernetes.driver.podTemplateFile と spark.kubernetes.executor.podTemplateFile を指定して、spark-submit プロセスにアクセスできるファイルを示します。

--conf spark.kubernetes.driver.podTemplateFile=s3a://bucket/driver.yml
--conf spark.kubernetes.executor.podTemplateFile=s3a://bucket/executor.yml

ドライバポッドが executor ポッドテンプレートファイルにアクセスできるようにするために、ファイルは作成時にドライバポッドのボリュームに自動的にマウントされます。Spark は、これらのテンプレートファイルをアンマーシャリングした後で何も検証を行わず、検証は Kubernetes API サーバに依存します。

It is important to note that Spark is opinionated about certain pod configurations so there are values in the pod template that will always be overwritten by Spark. したがって、この機能のユーザは、ポッドテンプレートファイルを指定すると、Sparkはポッドのビルドプロセス中に空のポッドではなくテンプレートファイルポッドでのみ開始できることに注意する必要があります。詳細については、spark によって上書きされるポッドテンプレートの値の完全なリストを見てください。

ポッドテンプレートファイルは複数のコンテナを定義することもできます。このような場合、ドライバまたは executor のベースとしてどのコンテナを使うかを指定するために、spark プロパティ spark.kubernetes.driver.podTemplateContainerName と spark.kubernetes.executor.podTemplateContainerName を使うことができます。指定されない場合、あるいはコンテナ名が無効な場合、Spark はリストの一番最初のコンテナがドライバまたは executor であると想定します。

Kubernetes ボリュームの使用

ユーザは以下の型のKubernetes ボリュームをドライバとexecutorポッドにマウントできます。

• hostPath: ホストノードのファイルシステムからファイルまたはディレクトリをポッドにマウントします。
• emptyDir: ポッドがノードに割り当てられた時に作成される、初期の空のボリューム。
• nfs: 既存のNFS(Network File System)をポッドにマウントします。
• persistentVolumeClaim: PersistentVolumeをポッドにマウントします。

NB: ボリュームのマウントに関するセキュリティ問題については、このドキュメントのセキュリティの章を見てください。

上記のいずれかのタイプのボリュームをドライバ ポッドにマウントするには、以下の設定プロパティを使ってください:

--conf spark.kubernetes.driver.volumes.[VolumeType].[VolumeName].mount.path=<mount path>
--conf spark.kubernetes.driver.volumes.[VolumeType].[VolumeName].mount.readOnly=<true|false>
--conf spark.kubernetes.driver.volumes.[VolumeType].[VolumeName].mount.subPath=<mount subPath>

具体的には、VolumeType は、hostPath, emptyDir, nfs およびpersistentVolumeClaim のいずれかの値になります。VolumeName はポッド仕様のvolumesフィールドの下にあるボリュームに使う名前です。

サポートされる各タイプのボリュームは、以下の形式の設定プロパティを使って指定することができる特定の設定オプションを持ちます:

spark.kubernetes.driver.volumes.[VolumeType].[VolumeName].options.[OptionName]=<value>

例えば、ボリューム名がimages のnfsのサーバとパスは、以下のプロパティを使って指定できます:

spark.kubernetes.driver.volumes.nfs.images.options.server=example.com
spark.kubernetes.driver.volumes.nfs.images.options.path=/data

また、ボリューム名checkpointpvcのpersistentVolumeClaimのクレーム名は、以下のプロパティを使って指定できます:

spark.kubernetes.driver.volumes.persistentVolumeClaim.checkpointpvc.options.claimName=check-point-pvc-claim

ボリュームをexecutorポッドにマウントするための設定プロパティは、プリフィックスspark.kubernetes.driver.の代わりにspark.kubernetes.executor.を使います。

例えば、以下のように、OnDemandをクレーム名として使い、storageClassとsizeLimitオプションを使って、executorごとに動的に作成された永続化ボリュームクレームをマウントできます。これは、動的割り当ての場合に役立ちます。

spark.kubernetes.executor.volumes.persistentVolumeClaim.data.options.claimName=OnDemand
spark.kubernetes.executor.volumes.persistentVolumeClaim.data.options.storageClass=gp
spark.kubernetes.executor.volumes.persistentVolumeClaim.data.options.sizeLimit=500Gi
spark.kubernetes.executor.volumes.persistentVolumeClaim.data.mount.path=/data
spark.kubernetes.executor.volumes.persistentVolumeClaim.data.mount.readOnly=false

サポートされる各種類のボリュームで利用可能なオプションの完全なリストについては、以下のSpark Properties の章を参照してください。

ローカルストレージ

Spark は、シャッフルおよび他の操作時にデータを逃がすためのボリュームをサポートします。ボリュームをストレージとして使うには、ボリューム名は spark-local-dir- で始まる必要があります。例えば:

--conf spark.kubernetes.driver.volumes.[VolumeType].spark-local-dir-[VolumeName].mount.path=<mount path>
--conf spark.kubernetes.driver.volumes.[VolumeType].spark-local-dir-[VolumeName].mount.readOnly=false

特に、ジョブがexecutor内で大規模なシャッフルおよびソートを必要とする場合、永続的なボリュームクレームを使うことができます。

spark.kubernetes.executor.volumes.persistentVolumeClaim.spark-local-dir-1.options.claimName=OnDemand
spark.kubernetes.executor.volumes.persistentVolumeClaim.spark-local-dir-1.options.storageClass=gp
spark.kubernetes.executor.volumes.persistentVolumeClaim.spark-local-dir-1.options.sizeLimit=500Gi
spark.kubernetes.executor.volumes.persistentVolumeClaim.spark-local-dir-1.mount.path=/data
spark.kubernetes.executor.volumes.persistentVolumeClaim.spark-local-dir-1.mount.readOnly=false

もしボリュームがローカルストレージとして設定されていない場合、Spark はシャッフルおよび他の操作時のディスクとして一時的なスクラッチスペースを使います。Kubernetes をリソースマネージャとして使っている場合、ポッドは spark.local.dir または環境変数 SPARK_LOCAL_DIRS にリストされている各ディレクトリにマウントされた emptyDir ボリュームで作成されます。ディレクトリが明示的に指定されない場合は、デフォルトのディレクトリが作成され、適切に構成されます。

emptyDir ボリュームは Kubernetes の一時ストレージ機能を使い、ポッドの生存期間を超えて存続することはありません。

ローカルストレージのためにRAMを使用

emptyDir volumes use the nodes backing storage for ephemeral storage by default, this behaviour may not be appropriate for some compute environments. 例えば、ネットワーク経由でリモートストレージがマウントされたディスクレスノードがある場合、このリモートストレージへの IO を実行する多くの executorr がいると、実際にパフォーマンスが低下する可能性があります。

この場合、構成に spark.kubernetes.local.dirs.tmpfs=true を設定して、emptyDir ボリュームをtmpfs 例えば RAMのボリュームとして構成することが望ましい場合があります。このように設定すると、Spark のローカルストレージの使用量がポッドのメモリ使用量にカウントされるため、spark.kubernetes.memoryOverheadFactor の値を適切に増やして、メモリリクエストを増やしたいかもしれません。

内省とデバッグ

これらは、実行中/完了した Sparkアプリケーションの調査、進捗の監視、処置とは異なる方法です。

アクセス ログ

ログは Kubernetes API と kubectl CLI を使ってアクセスすることができます。Sparkアプリケーションが実行中の場合、以下を使ってアプリケーションからログをストリームすることができます:

$ kubectl -n=<namespace> logs -f <driver-pod-name>

クラスタ内にインストールされている場合は、同じログがKubernetes dashboardを使ってアクセスすることもできます。

Driver UIのアクセス

全てのアプリケーションに関係するUIがkubectl port-forwardを使ってローカルにアクセスすることができます。

$ kubectl port-forward <driver-pod-name> 4040:4040

そして、Sparkドライバ UI はhttp://localhost:4040でアクセスすることができます。

デバッギング

幾つかの種類の障害があるかもしれません。Kubernetes API サーバがspark-submitから作成されたリクエストを拒否、あるいは接続が異なる理由で拒否された場合、サブミットのロジックはエラーに遭遇したことを示す必要があります。しかし、もしアプリケーションを実行中にエラーがあった場合、Kubernetes UIを使って調査することがしばしば一番良い方法です。

ドライバ pod周りで決定されたスケジューリングについての基本的な情報を取得するために、以下を実行することができます:

$ kubectl describe pod <spark-driver-pod>

もしpodが実行時エラーに遭遇した場合、状態は以下を使って更に調査することができます:

$ kubectl logs <spark-driver-pod>

失敗したexecutor podの状態とログは同じ方法で調べることができます。最後に、ドライバ pod の削除は、全てのexecutor、関連するサービスなどを含むspark アプリケーション全体を一掃するでしょう。ドライバ pod はSparkアプリケーションのKubernetes表現と考えることができます。

Kubernetes 機能

設定ファイル

Kubernetes 構成ファイルは通常、ホームディレクトリの .kube/config の下、または環境変数 KUBECONFIG で指定された場所にあります。Kubernetes 上の Spark は、このファイルを使って、Kubernetes クラスタとのやりとりに使われる Kubernetes クライアントの初期自動構成を試みます。クライアント構成をさらにカスタマイズできる、例えば別の認証方法を使う、ようにする様々な構成プロパティが用意されています。

Contexts

Kubernetes 構成ファイルには、異なるクラスタやユーザ ID の切り替えを可能にする、複数のコンテキストを含めることができます。デフォルトでは、Kubernetes 上の Spark は、Kubernetes クライアントの初期自動構成を行う時に、現在のコンテキスト(kubectl config current-context を実行することで確認できる)を使います。

別のコンテキストを使うために、ユーザは Sjpark 構成プロパティ spark.kubernetes.context を介して目的のコンテキストを指定することができます。例えば、spark.kubernetes.context=minikube。

名前空間

Kubernetesは名前空間の概念を持ちます。名前空間はクラスタのリソースを複数のユーザ間で(リソース クォータを使って)分ける方法です。Kubernetes上のSparkはSparkアプリケーションを起動するために名前空間を使うことができます。これはspark.kubernetes.namespace設定を利用することで行うことができます。

Kubernetes によりResourceQuota を使って個々の名前空間上にリソース、オブジェクトの数などの制限を設定することができます。名前空間とResourceQuota は管理者によってSparkアプリケーションが実行中のKubernetesクラスタ内で共有とリソースの割り当てを制御するために組み合わせて使うことができます。

RBAC

RBAC を有効にしたKubernetesクラスタ内で、ユーザはKubernetesコンポーネント上の様々なSparkによって使われるKubernetes RBACの役割とサービスアカウントをKubernetes APIサーバにアクセスするために設定することができます。

Spark ドライバ pod はexecutor podを作成および監視するためにKubernetes API サーバにアクセスするためにKubernetesサービスアカウントを使います。ドライバ podによって使われるサービスアカウントはドライバがその作業を行うことができるように適切なパーミッションを持つ必要があります。特に、最小でも、サービスのアカウントはドライバ podがpodとサービスを作成することができる Role あるいは ClusterRole を与えられる必要があります。もしpodが作成された時にサービスのアカウントが指定されない場合には、デフォルトでドライバのpodは自動的に spark.kubernetes.namespaceによって指定される名前空間内でdefaultサービスアカウントを割り当てられます。

デプロイされたKubernetesのバージョンとセットアップに応じて、このdefaultサービス アカウントはデフォルトのKubernetesRBACポリシーの元にドライバ podがpodおよびサービスを作成することができるroleを持つか、あるいは持たないかもしれません。時にはユーザは正しいroleが与えられた独自のサービスアカウントを指定する必要があるかもしれません。Kubernetes上のSparkは設定プロパティ spark.kubernetes.authenticate.driver.serviceAccountName=<service account name>を使ってドライバpodによって使われる独自のサービスアカウントの指定をサポートします。例えば、ドライバpodを作るには、sparkサービスアカウントを使います。ユーザは単純に以下のオプションをspark-submitコマンドに追加します:

--conf spark.kubernetes.authenticate.driver.serviceAccountName=spark

独自のサービスアカウントを作成するために、ユーザはkubectl create serviceaccount コマンドを使うことができます。例えば、以下のコマンドはsparkという名前のサービスアカウントを作成します:

$ kubectl create serviceaccount spark

サービスアカウントに Role あるいは ClusterRole を与えるには、RoleBinding あるいは ClusterRoleBinding が必要です。RoleBinding あるいは ClusterRoleBinding を作成するために、ユーザは kubectl create rolebinding (あるいは ClusterRoleBindingについてはclusterrolebinding) コマンドを使うことができます。例えば、以下のコマンドはdefault名前空間に edit ClusterRoleを作成し、それを上で作成した spark サービスアカウントに与えます:

$ kubectl create clusterrolebinding spark-role --clusterrole=edit --serviceaccount=default:spark --namespace=default

Role は1つの名前空間内で(podsのような) リソースにアクセスを与えるためだけに使うことができることに注意してください。一方、 ClusterRoleは(nodeのような)クラスタスコープのリソースと全ての名前空間に渡った(podsのような)名前空間のリソースにアクセスを与えるために使うことができます。Kubernetes上のSparkについては、ドライバは常に同じ名前空間にexecutor podを作成するため、Role で十分ですが、ユーザは代わりにClusterRoleを使うかもしれません。RBAC認証についての詳細な情報とpodのためにKubernetesサービスアカウントを設定する方法については、RBAC 認証の使用 と Podのためのサービスアカウントの設定を参照してください。

Spark アプリケーション管理

Kubernetes はクラスタモードの spark-submit CLI ツールを介してシンプルなアプリケーション管理を提供します。ユーザはジョブを送信する時に出力されるサブミッション ID を提供することで、ジョブを強制終了することができます。サブミッション ID は namespace:driver-pod-name の形式に従います。ユーザが名前空間を省略すると、現在の k8s コンテキストで設定されている名前空間が使われます。例えば、ユーザが kubectl config set-context minikube --namespace=spark のように特定の名前空間を設定した場合、デフォルトで spark 名前空間が使われます。一方で、特定のコンテキストに名前空間が追加されていない場合、デフォルトで全ての名前空間が考慮されます。つまり、名前空間に関係なく、指定されたサブミッション ID に一致する全てのアプリケーションに操作が影響することを意味します。さらに、アプリケーション管理用の spark-submit はドライバを送信するために使われる同じバックエンドコードを使います。つまり、spark.kubernetes.context などのような同じプロパティが再利用できます。

例えば:

$ spark-submit --kill spark:spark-pi-1547948636094-driver --master k8s://https://192.168.2.8:8443

ユーザは --status フラグを使ってアプリケーションの状態を一覧表示することもできます:

$ spark-submit --status spark:spark-pi-1547948636094-driver --master  k8s://https://192.168.2.8:8443

どちらの操作も glob パターンをサポートします。例えば、ユーザは以下を実行することができます:

$ spark-submit --kill spark:spark-pi* --master  k8s://https://192.168.2.8:8443

上記は特定のプレフィックスを持つ全てのアプリケーションを強制終了します。

ユーザは、spark.kubernetes.appKillPodDeletionGracePeriod プロパティを使ってポッド終了の猶予期間を指定することができます。これを提供する手段として --conf を使うことができます (全ての K8s ポッドのデフォルト値は30秒です)。

将来の作業

現在作業中あるいは作業予定の幾つかのSpark on Kubernetesの機能があります。これらの機能は、最終的にspark-kubernetes統合の将来のバージョンに組み込まれる予定です。

これらの幾つかには、以下が含まれます:

• 動的なリソースの割り当てと、外部シャッフル サービス
• ジョブ キューとリソース管理

設定

Sparkの設定の情報については 設定ページを見てください。以下の設定はKubernetes上のSparkに固有です。

Sparkのプロパティ