Kubernetesが事実上の標準コンテナの配置システムとなっており、今、クラウド・コンテナ・オペレーティング・システム間で主流のアプリケーションです。
しかし、 Kubernetesの目標は、コンテナ自体ではなく、その用途に運び、本質的には上の（コンテナ）クラウドアプリケーション解決するために、この問題を。
コンテナと K8Sが登場し、彼らが可能彼らのビジネスは曇り達成囲むように、それは、抽象コアの統一セットを提供します。
だから、どのようにコンテナ以外のアプリケーションはありますか？
この記事のお得な情報は、あなたを教えて K8Sを関係なく、私たちがどのように制御するかの：
コンテナアプリケーションの曇りを実行するには？
我々 K8Sは3つの大きな動きを学びました
非コンテナアプリケーションがどのように曇りを実行するには？
いくつかの雲が非常に魅力的な失敗を表示された場合に曇りの環境下では、それは、上のエンタープライズ・アプリケーションにほとんど影響を持っていますか？
、コンテナの使用をサポートしていない非コンテナアプリケーションの両方レガシーAPPため、商業的な理由のアプリケーションコンテナのものを含むが、サポートされていない、など多くの伝統的などのHPC アプリケーションに最適です。私たちは、ライフサイエンス直面好き/ 半導体/ 自動車製造業を、これらのユーザーは、頻繁に使用するコンテナ以外のアプリケーションです。
ローカルに基づい + アプリケーションレイヤ、サービスレイヤのスケジューリング、リソース割り当て層、層のクラウドプロバイダ：以下の4つのレベルに分けられた濁ったシステムアーキテクチャ。
クラウドプロバイダは、基盤となるインフラや資源です。
リソース層の割り当ては、クラウド・プロバイダーのクラスタリソース管理、さらにプール、抽象化され、ダイナミックプールになります。
それは私達のユーザーのニーズに一定値ではありませんので、変動は、時々 、短期的には大きな需要があるだろうがあるが、これらの時間に加えて、時間ではなくので、大きな需要のほとんど、私たちは動的管理必要 / ダイナミックを抽象的なクラウドリソースを適用します。
レイヤサービススケジューリング問題は、上記の私たちのリソースを抽象的に良い走行を適用する方法をここで実行し、これらの問題を実行する方法について説明します。
1
曇りを実行するためにどのようにコンテナアプリケーション
アプリケーションのコンテナの場合：
K8Sは、上記の環境で動作しているアプリケーションは、我々はアプリケーションのコンテナが統一スケジューリングオブジェクトを提供して構成されたどのように、この層のサービスのスケジューリングを解決します。のでK8Sが統一抽象化を持っているので、あなたが置くことができK8S 曇りの作業負荷分散を実現するために、統一された管理を通じて、上記の異なるクラウドに配備を。
しかし K8S 未解決の問題は、各クラウド上で構築する方法であるK8S クラスタ。
けれども CNCF （ネイティブのクラウドコンピューティング財団）コミュニティのようなツールは、さまざまな多くの持っているテラフォームを、ユーザーがクラスタを構築することができますが、すべての後に、それはスタンドアロンツールで、ユーザーは必然的に学習のコストが増加します。そして、あなたが特定のコントロールしたい場合は、ワークロードを動的にこれらのリソースを適用し、あなたが自分自身を開発する必要があり、これらの余分なものをカスタマイズしました。
ユーザーの場合、これらは曇りを達成するための障害となっています。
2
我々 K8Sは3つの大きな動きを学びました
均一な抽象化レイヤ
統合制御インターフェース（抽象化 APIを）、異なるクラウドリソースの管理に似た根本的な違いを、マスクすることができます。基礎となるリソースに直接接触していないいいえ、私たちはこの抽象に応じて、よりスケーラブルを提供することができますスタック。
インフラの道の宣言的記述
同じセットが異なるクラウド上で使用することができ記載抽象制御インターフェース、相互にクラウドコンピューティングリソース制服説明、使用。
K8Sは状態を説明し、我々は、これは良いことだと思います。なぜ？
それはこのこの種のものを達成するためにどのように宣言的状態を記述する枠組み、その状態であるため、プラットフォーム自体に、我々は、そのような私たちが展開する方法にこれらの側面の価格となりましプラットフォームの状態と、これらのリソースの状態を、することができますこの状態に到達するようなもの。
オートメーション管理
使用する APIを、ビジネスプロセスのほとんどは、保守要員の負担を軽減し、自動化することができます。
たとえば、リソースの使用を最大化するために、ユーザーが指定したサイズと戦略的事業動的にスケーラブルなクラスタサイズに応じました。いくつかの計算例について同時に交換することができると、代替の回復計算を自動化することができます。
3
非コンテナアプリケーションがどのように曇りを実行するには？
コンテナのアプリケーションが適切でないために、我々はまた、リソース要件を定義し、宣言型のファッションを操作し、アプリケーションの内部ロジックを変更せずに、アプリケーションが曇った環境で実行されますことができます。私たちは、コア要件が対処しなければなりません。
ユーザは、例えば、配列を有するであろうこれらのアプリケーションを使用する場合は、起動したアプリケーション、及びその後の中間データの数を生成し、中間データは、アプリケーションの次のステージに供給され、アプリケーションは、次の段階を、消費していますワークフローアプリケーションは、最終的には彼が望んでいたします。このプロセスは、抽象的になり、私たちは、これらのアプリケーションの配布ポイントをスケジュールするために使用しました。
5つの主要なコンポーネントの内側に設計された当社のシステム：
クラウドサービスの抽象化サーバレス層
統一されたクラスタシステムの説明
インテリジェントポリシー制御システム
ワークフロー・エンジン
分散ファイルシステムキャッシュ
クラウドサービスの抽象化サーバレス層
などに使用されるコンポーネントのいくつかの上記各クラウドへのクラウド抽象化レイヤ、インスタンスの仮想マシン、ネットワーク、ミラーリング、サブネット、ファイアウォール、我々は要約を行うこれらの共通の特徴の。すべてのクラウドリソース、リソースの大きなプールに、ローカルまたは公共のかどうか。そして、機能とリソースは、曇りの異種が低く、動的にユーザーのためのサービスを提供するコンピューティングリソースの使用を開いて分割することができます。各リソースの動作のために、それは、対応するクラウド・プロバイダに変換されたAPI 操作。
この抽象化層もできる私たちはいくつかの雲を達成するため、いくつかは持っている、いくつかの雲はしていません。
例えば、 AWSが今あるスポットフリートの機能、あなたは、あなたがどこへ行くの範囲を選択することができ、マシンの種類、私は必要とどのように多くのマシンにそれを伝えることができます。我々はアリクラウドや他のクラウド上でこの機能を見ていない、我々は今、このような機能への抽象化を実現することができます。
残念ながら、すべてのクラウドリソースは、次のような、特にいくつかのハイエンドのリソースで、この統一された抽象化を介してアクセスすることができる AWSラムダ我々はでき抽象的ではないこと。それは洗練のより高いレベル、またはより高いレベルの簡略化した形を行うための基礎となるリソースの使用であるため、異なるクラウド上のいくつかの雲がないかもしれないが、同じではありません。
統一されたクラスタシステムの説明
私たちは学んだ K8Sを宣言型の記述を通じてインフラを定義するには、これに基づいて説明した統一されたインフラシステムを提供し、。簡単に言えば、あなたがしたいか、これらの仮想マシンの仮想マシン間の関係を定義する方法です。
同様 Hashicorpが提供テラフォームは、「提案コードASインフラストラクチャ、つまり、コードのアーキテクチャを」。我々はまた、あなたが何をお使いのアーキテクチャを見ることができ、メリットが明確であるこのアイデアを使用して、あなたはこの状態を記述することができます。たとえば、あなたが定義および実装ようなフレームワーク上の雲の中にある、あなたは別のクラウドに移行するためにそれを置くことができる、と間違って行くことはありません。
達成「一度書けばどこでも動くとクラウド間の浮遊」。
インテリジェントポリシー制御システム
基礎として、前の2で、我々は達成することができ、ユーザの嗜好インテリジェントなスケジューリングに基づきます。
以前の私たちは、クラスタがどこプロセスにおけるこれらの事業を実行することができ、ダイナミッククラスタが戦略やクラウド上の状態に応じて決定することで述べたように、私たちは持っているインテリジェントスケジューリングシステム、それが入力されますが、ユーザーのこのデータは、スケジュールするユーザの好みが何であるか、どのくらいです。
ユーザーの嗜好がコストである場合は、ある程度受け入れることが遅くなることがあります。私たちは、次のようないくつかの格安のリソース、見つけることができ AWS のスポットインスタンスを（SPOTは、我々は非常に低価格を使用することができるリソースである）が、これは資源が常にされていることを保証するものではありません。ユーザーはこの設定を選択した場合、我々は上がるだろうと、私たちは時々実行するためのリソースを持っているときにある程度このリソースは、夕方にすることができ、タスクを再実行するためのリソースや時間を持っています。ユーザーすぐに結果を入れて非常に多くの希望が出て働いた場合、我々はクラウド最速を動員することができ、我々は、ユーザーがこの事を計算する得るのを助けるためにリソースを適用することができます。
ワークフロー・エンジン
一般的に、そのアプリケーションの使用中のユーザーは、ワークフローを持つことになります。例えば、どのような手順、どの第二のステップ・プログラムの最初のステップ。私たちは、ユーザーがグラフィカルなワークフローを編集することができ、システム内のワークフローエンジンを統合しています。そして、このシステムは、すでにタスクを実行するためにサポートするために、いくつかの一般的な手順をインストールされています。
異なるステップは、異なる特性を持っています。例えば、いくつかのステップは、いくつかのタスクを実行すると同時に、ノードの多くを必要とする場合があり、より多くの量によって複雑に、いくつかのステップがそれほど大きくないかもしれません。また、ユーザーはコストを節約することができたワークフローに従って、当社のクラスタサイズを調整することができます。
分散ファイルシステムキャッシュ
データアクセス：これは、より重要な点です。
プログラムまたはアプリケーションは確かにあなたがデータを必要とし、一人で完全な仕事ではありません。ほとんどのアプリケーションでは、伝統的に設計されてのLinux / UNIX 上で、ユーザーが直接ファイルを介してデータにアクセスすることができます。
だから我々は2つのことが必要になります。
まず、直接データアクセス、データアクセスがあり、上曇りを構築します。
第二に、ユーザデータが既になど、いくつかの既存のストレージ・システム上に存在してもよい S3 / OSS / NFS 。私たちは、これらのデータのユーザーの既存の使用に直接行くのではなく、再びそれをコピーし、新しいストレージシステムをやるべきだと思います。このデータウェアハウスを使用するように、元の場所からデータをコピーし、データの一時的な倉庫の設立をクラスタを構築するために、使用が終了した後、再度コピーします。一般的な方法です。私たちは、この重複を避けるために、このようなキャッシュシステムを構築したい、それがクラスタを構築するために、ユーザーの時間を節約できます。何度もユーザーがデータ収集、データを使用する必要もコピーさを回避することは困難であるオリジナルな方法をたくさん入れています。例えば、我々は分散コンピューティングを持って、この計算は、それが出てコピーしたために我々が持っているデータを使用する必要はありません。これを念頭に置いて、キャッシュの一部は、我々は唯一のバック内部のターゲット・ストレージ・システムへの書き込みの後に計算される既存のシステムを使用する必要があります。
そして、この設計は、スケールアウトアーキテクチャのユーザーは、時間のパフォーマンス要件に達したとき、あなたはノードの方法を追加することにより、パフォーマンスを拡張することができます。
我々はまた、異なるキャッシュ戦略をサポートしています。複数の異なる存在でき、データサーバー、データ・サーバは、異なるクラウド上にあるので、データを置くことができるローカル・コンピューティングにキャッシュされて、本当にあなたは、データアクセスを高速化することができ、必要があります。例えば、カウントが終わった後、私は、上記の雲で計算し、私は、ストレージターゲットの上にそれを書き戻すことを願っています。
サポート自動および手動プリフェッチをプリフェッチ。これは、我々が計算を行うときにどこのアプリケーションを置くために知っているので、我々は我々のキャッシュシステム、これに迅速訪問の際に、不要なコピーをすることができ避け、行くためにデータを移行する必要性を伝えることができる、ということを意味しますデータを使用します。
4
いくつかの雲が非常に魅力的な失敗を表示された場合に曇りの環境下では、それは、上のエンタープライズ・アプリケーションにほとんど影響を持っていますか？
具体的な効果は、特定の展開と分析にアプリケーション自体を参照する必要があります。
私たちは、使用ダブルスケジューリングコンセプト：
最初のレベルのスケジューリング配信ビジネスの場所、私はリソースを配置する場所の問題を解決するためです。
内部のワークロード・スケジューリング割当の第二の層。
私は、クラウド上のワークロードが、私は雲のクラスタを作成します。この時間を置くことにしました。タスクの一部は、このクラスタ内で実行されます、我々は、上側のスケジューラは、この問題を見つけるだろう、我々は自動的にスケジュールされます、タスクへの障壁は、何らかの理由でどこかに停止した場合、監視の過程にあり、別の場所、または別のクラウドへ。一般的なスケジュールすると、全体としてビジネスをクラウドに割り当てられます。何らかの理由で全体のクラウドリソースにアクセスできない場合は、第一層は、別のサービススケジューリングクラウドを派遣します。
だから我々は、の使用をサポートすることができますスポットへ行くか、別の場所に時間にスケジュールすることができ、資源を横取りすることができます。