Kubernetes 上の Spark の現状と課題

クラウドネイティブ時代において、Kubernetes の重要性はますます高まっています。この記事では、Spark を例に、Kubernetes 上のビッグデータ エコシステムの現状と課題について説明します。

1. スタンドアロンモード

Kubernetes クラスター上で Spark を実行する最初の実現可能な方法は、Spark をスタンドアロン モードで実行することですが、コミュニティはすぐに Kubernetes ネイティブ スケジューラ実行モード、つまりネイティブ モードを使用することを提案しました。ここでスタンドアロン モードについてさらに説明する必要はありません。

2. Kubernetes ネイティブモード

つまり、ネイティブ モードでは、ドライバーとエグゼキューターをポッド化します。ユーザーは、YARN に Spark ジョブを送信したのと同じ方法で、Kubernetes API サーバーに Spark ジョブを送信します。送信コマンドは次のとおりです。

 $ bin/spark-submit \
 --master k8s://https://<k8s-apiserver-host>:<k8s-apiserver-port> \  
 --deploy-mode クラスター \  
 --name スパークパイ \  
 --class org.apache.spark.examples.SparkPi \  
 --conf spark.executor.instances=5 \  
 --conf spark.kubernetes.container.image=<spark イメージ> \  
ローカルの:///path/から/examples.jarへ

ここで、master は kubernetes の apiserver アドレスです。送信後、ジョブ全体は次のように実行されます。最初に、ドライバーがポッドを介して起動され、次にドライバーがエグゼキューターのポッドを起動します。これらの方法は多くの人がよく知っているはずなので、詳細には触れません。詳細については、https://spark.apache.org/docs/latest/running-on-kubernetes.html を参照してください。

3. スパーク演算子

Kubernetes Scheduler に直接ジョブを送信するだけでなく、Spark Operator を介してジョブを送信することもできます。 Operator は Kubernetes における非常に重要なマイルストーンです。 Kubernetes が最初にリリースされたとき、StatefulSet が登場するまで、公式は Kubernetes 上でステートフル アプリケーションをデプロイする方法について議論することに消極的でした。 StatefulSet は、ステートフル アプリケーションのデプロイメントのための抽象化を実装します。簡単に言えば、ネットワーク トポロジとストレージ トポロジを保証します。ただし、ステートフル アプリケーションは多種多様であり、すべてのアプリケーションを StatefulSet に抽象化できるわけではありません。強制的な適応は、いずれにしても開発者の精神的負担を増大させます。

するとオペレーターが現れました。 Kubernetes は開発者にとって非常にオープンなエコシステムを提供していることがわかっています。 CRD、コントローラー、さらにはスケジューラーもカスタマイズできます。オペレーターは、CRD + コントローラーの組み合わせです。開発者は独自の CRD を定義できます。たとえば、EtcdCluster という CRD を次のように定義します。

 apiバージョン: "etcd.database.coreos.com/v1beta2"  
種類: "EtcdCluster"  
メタデータ:
名前: "example-etcd-cluster"  
仕様:
サイズ: 3
  バージョン: "3.1.10"  
  リポジトリ: "quay.io/coreos/etcd"  

Kubernetes に送信された後、Etcd Operator は yaml 内の各フィールドを処理し、最終的に 3 つのノードを持つ etcd クラスターをデプロイします。現在 Operator デプロイメントを実装している分散アプリケーションは、この github リポジトリで確認できます: https://github.com/operator-framework/awesome-operators。

GCP としても知られる Google Cloud Platform は、GitHub で Spark Operator をオープンソース化しました。リポジトリ アドレス:。 Operator の導入も非常に簡単です。以下のようにHelm Chartを使用してデプロイできます。これは、Kubernetes API オブジェクト (デプロイメント) をデプロイすると考えることができます。

 $ helm リポジトリにインキュベーターを追加しますhttp://storage.googleapis.com/kubernetes-charts-incubator
 $ helm インストール incubator/sparkoperator --namespace spark-operator  

このオペレータに関係する CRD は次のとおりです。

スケジュールされた Spark アプリケーション
|__ スケジュールされた Spark アプリケーション仕様
    |__ Sparkアプリケーション
|__ スケジュールされた Spark アプリケーション ステータス
 
 |__ Sparkアプリケーション
|__Sparkアプリケーション仕様
    |__ ドライバースペック
        |__SparkPodスペック
    |__エグゼキュータ仕様
        |__SparkPodスペック
    |__ 依存関係
    |__ モニタリングスペック
        |__ プロメテウススペック
|__Sparkアプリケーションステータス
    |__ ドライバー情報

ジョブを送信する場合は、次の SparkApplication yaml を定義できます。 yaml 内のフィールドの意味については、上記の CRD ドキュメントを参照してください。

 APIバージョン: sparkoperator.k8s.io/v1beta1
種類: SparkApplication
メタデータ:
  ...
仕様:
  依存関係: {}
  ドライバ：
    コア制限: 200m
    コア: 0.1
    ラベル:
      バージョン: 2.3.0
    メモリ: 512m
    サービスアカウント: spark
  執行者:
    コア数: 1
    インスタンス: 1
    ラベル:
      バージョン: 2.3.0
    メモリ: 512m
  画像: gcr.io/ynli-k8s/spark:v2.4.0
  メインアプリケーションファイル:ローカル:///opt/spark/examples/jars/spark-examples_2.11-2.3.0.jar
  メインクラス: org.apache.spark.examples.SparkPi
  モード: クラスター
  再起動ポリシー:
      タイプ: OnFailure
      失敗時の再試行回数: 3
      失敗時の再試行間隔: 10
      送信失敗時の再試行回数: 5
      送信失敗時の再試行間隔: 20
  タイプ: Scala
状態：
  スパークアプリケーション ID: スパーク-5f4ba921c85ff3f1cb04bef324f9154c9
  アプリケーション状態:
    状態: 完了
  完了時間: 2018-02-20T23:33:55Z
  ドライバー情報:
    ポッド名: spark-pi-83ba921c85ff3f1cb04bef324f9154c9-driver
    webUIアドレス: 35.192.234.248:31064
    ウェブUIポート: 31064
    webUIサービス名: spark-pi-2402118027-ui-svc
    webUIIngress 名: spark-pi-ui-ingress
    webUIIngressアドレス: spark-pi.ingress.cluster.com
  実行者状態:
    spark-pi-83ba921c85ff3f1cb04bef324f9154c9- exec -1: 完了
  最終送信試行時間: 2018-02-20T23:32:27Z

課題を提出してください。

 $ kubectl を適用 -f spark-pi.yaml

それに比べると、Operator のジョブ送信方法はより長くて複雑に見えますが、より Kubernetes ベースの API 展開方法、つまり Declarative API でもあります。

4. 課題

基本的に、市場のほとんどの企業は現在、上記の 2 つの方法を使用して Kubernetes 上に Spark を実装しています。ただし、Spark Core での Kubernetes のネイティブ サポートはまだ十分に成熟しておらず、改善できる領域がまだ多くあることもわかっています。

1. スケジューラの違い。

リソース スケジューラは、集中型リソース スケジューラと 2 レベル リソース スケジューラに簡単に分類できます。 2 レベルのリソース スケジューラには、マクロ リソースのスケジューリングを担当する中央スケジューラがあり、特定のアプリケーションのスケジューリングは、その下のパーティション リソース スケジューラによって行われます。 2 レベルのリソース スケジューラは、パフォーマンスなどの大規模アプリケーションの管理とスケジューリングに優れたサポートを提供できることが多いですが、欠点も明らかであり、実装も複雑です。実際、この設計思想は、メモリ管理における tcmalloc アルゴリズムや Go 言語のメモリ管理実装など、多くの場所に適用されています。ビッグデータ リソース スケジューラ Mesos/Yarn は、ある程度 2 レベルのリソース スケジューラに分類できます。

集中型リソース スケジューラはすべてのリソース要求に応答して決定を下すため、クラスターのサイズが大きくなると必然的に単一ポイントのボトルネックが発生します。それに疑いの余地はない。しかし、Kubernetes のスケジューラには別の違いがあります。これは、共有状態に基づく集中型リソース スケジューラのアップグレード バージョンです。 Kubernetes は、クラスター全体のリソースをスケジューラ内にローカルにキャッシュし、リソースをスケジュールする際にキャッシュされたリソースの状態に基づいて「楽観的な」割り当て (想定 + コミット) を実行することで、スケジューラの高いパフォーマンスを実現します。

ある程度、Kubernetes のデフォルトのスケジューラは、Spark のジョブ スケジューリング要件に十分に適合することができません。実現可能な技術的解決策は、カスタム スケジューラを提供することです。たとえば、ビッグデータ企業であり、Spark on Kubernetes Native アプローチの参加者の 1 社である Palantir は、カスタム スケジューラを github リポジトリでオープンソース化しています: https://github.com/palantir/k8s-spark-scheduler。

2. クラスタースケールのボトルネック。

基本的に、クラスターのサイズが 5,000 台に達すると、Kubernetes がボトルネックに達することは間違いありません。しかし、Spark が初期の頃に論文を発表したとき、Spark スタンドアロン モードは 10,000 台のマシン規模をサポートできると主張していました。 Kubernetes のボトルネックは、主にメタデータの保存に使用される raft コンセンサス プロトコルに基づく etcd や apiserver などのマスターに反映されます。この点に関して、先日終了した2019年上海KubeConカンファレンスで、アリババはマスターパフォーマンスの向上に関するセッション「Kubernetesマスターのスケーラビリティとパフォーマンスの理解」を開催しました。興味のある方はさらに詳しく知ることができます。

3.ポッドの排除の問題。

Kubernetes では、リソースは圧縮可能なリソース (CPU など) と非圧縮可能なリソース (メモリなど) に分けられます。圧縮不可能なリソースが不足すると、一部の Pod が現在のノードから排除されます。国内大手企業がKubernetes上でSparkを使用していたところ、ディスクIO不足によりSparkジョブが失敗し、間接的にテストセット全体の結果が得られないという問題が発生しました。 Spark のジョブポッド (ドライバー/エグゼキューター) が削除されないようにするにはどうすればよいですか?これには優先順位の問題が関係しており、これは 1.10 以降でサポートされます。しかし、優先順位に関して言えば、アプリケーションの優先順位をどのように設定するかという疑問は避けられません。一般的に、オンライン アプリケーションや長時間実行されるアプリケーションはバッチ ジョブよりも優先度が高くなりますが、これは Spark ジョブには明らかに適した方法ではありません。

4.ジョブログ。

Spark on Yarn モードでは、ログを集約してから表示できますが、Kubernetes では、現時点では Pod ログを通じてのみログを表示できます。 Kubernetes エコシステムに接続する場合は、fluentd または filebeat を使用して、ドライバーおよびエグゼキューター ポッドのログを ELK に集約して表示することを検討できます。

5.Prometheus エコシステム。

CNCF を卒業した 2 番目のプロジェクトとして、Prometheus は基本的に Kubernetes モニタリングの標準となっています。現在、Spark は Prometheus Sink を提供していません。さらに、Prometheus はデータの読み取りに pull メソッドを使用しますが、これは Spark のバッチ ジョブには適していません。 Prometheus の pushgateway を導入する必要があるかもしれません。

5. 結論

クラウド OS として知られる Kubernetes は、クラウド ネイティブ コンセプトの技術的な担い手であり具体化ですが、Kubernetes を使用してビッグ データ アプリケーションをサポートする方法については、まだ多くの検討の余地があります。コミュニケーションへようこそ。