0

Ec2 Container Engine クラスタが作成されると、Compute Engine マネージド インスタンス グループが作成され、作成されたインスタンスが管理されます。これらのインスタンスは Ec2 サービスからのものです。つまり、それらは仮想マシンです。

しかし、コンテナーは、重量があり移植性がない VM のようなハードウェア仮想化ではなく、オペレーティング システム レベルの仮想化に基づいてコンテナーをデプロイする新しい方法であることはわかっていますが、矛盾していませんか? 私が間違っている場合は修正してください。

VM と比較して (起動時間またはタスク実行のいずれかで) 非常に高速であり、多くのスペース ストレージを節約できるため、コンテナーを使用します。したがって、最大 4 つのコンテナーをサポートできるノード (vm) が 1 つある場合、クライアントは 4 つのコンテナーを迅速に起動できますが、この数を超えると、Ec2 オートスケーラーは今後のコンテナーをサポートするために新しいノード (vm) を起動する必要があり、いくつかのタスクが発生します。遅れ。

物理マシン上でコンテナを起動することは不可能ですか?

また、重要な時間の実行タスクを実行するために何をお勧めしますか?

4

1 に答える 1

3

ECS が仮想マシン (「コンテナ インスタンス」 - コンテナが実行されるインスタンス) をタスクの需要に合わせて直接スケーリングするという誤った仮定の下で作業していると思います。

それが本当なら、十分なコンテナ インスタンス リソースがすぐに利用できないときはいつでも、クラスターの動作が遅くなり、応答しなくなるため、あなたの考えには一理あります。

Auto Scaling Group の存在にもかかわらず、ECS はそれを行いません。

クラスターで使用する Amazon EC2 インスタンスの種類と、クラスター内にあるコンテナー インスタンスの数に応じて、タスクの実行時に使用できるリソースの量が制限されます。ECS は、クラスター内で使用可能なリソースを監視して、スケジューラーと連携してタスクを配置します。クラスターがメモリなどのこれらのリソースのいずれかで不足している場合、コンテナー インスタンスを追加するか、サービスで必要なタスクの数を減らすか、またはサービスで実行中のタスクの一部を停止するまで、最終的にそれ以上のタスクを起動できなくなります。クラスタを使用して、制約されたリソースを解放します。（強調追加）

http://docs.aws.amazon.com/AmazonECS/latest/developerguide/cloudwatch_alarm_autoscaling.html

いいえ...容量が不足している場合、新しいタスクをゆっくりと起動することはありません。それらはまったく起動しません。

しかし、私に先んじないでください。

上記のリンクでは、仮想マシン (コンテナー インスタンス) のスケーリングが実際に機能するように設計されている方法について、例を挙げて説明しています。

もちろん、それらを適応的にスケーラブルにする必要はまったくありません。物理サーバーモデルを使用できます（注：物理サーバーモデルと言います-- 仮想マシンは EC2 が提供するものであるため、常に実行されている仮想マシン上の固定された非弾性のリソース プールを意味し、物理サーバーを本質的にエミュレートして、常に実行するために待機するインスタンスの数を選択するだけです。たとえば、8 つのコンテナー インスタンスが必要な場合、「自動スケーリング グループ」は常に 8 つを維持し、たとえばそのうちの 1 つにハードウェア障害が発生した場合に代替を作成します。その「自動的な」達成とは、現状を維持することです。そしてもちろん、この構成では、手動で 8 から 12 に再構成することができ、「自動」の達成は、既存の 8 に追加する 4 つの新しいものを自動的に取得することです。

ただし、このサービスの理想的な使用方法の考え方は、仮想マシンのグループを、考案したルールに従ってスケールアップおよびスケールダウンして、将来のタスクで必要なリソース (または将来のタスクの不足) を予測することです。

与えられた例では、メモリ予約がトリガーです:

クラスターのメモリー予約が 75% を超えると (つまり、クラスター内のメモリーの 25% のみが新しいタスクの予約に使用できることを意味します)、アラームは Auto Scaling グループをトリガーして別のインスタンスを追加し、より多くのリソースをユーザーに提供します。タスクとサービス。

コンテナー インスタンスの追加がトリガーされるため、余剰容量の適切なしきい値であると判断したものは、必要になるまでに常にオンラインになっています。

もちろん、メモリは 1 つのリソースにすぎず、75% はこの例で選択された任意のしきい値にすぎません。

Auto Scaling Groups は、月のフレーズ、株式市場の価格動向など、希望する余剰容量を予測するのに適切であり、定量化および監視が可能なものであれば、さまざまなトリガーでスケーリングできます。このサービスは、リソース不足のためにタスクを起動できない場合に、新しいタスクを実際に起動しようとしても、それ自体を直接スケーリングしません。

ここにあなたの最初の議論の欠陥があります。

仮想マシンを選ぶ理由 簡単に言うと、容量が必要ないと予想されるために仮想マシンを破棄すると、料金の支払いが停止するからです。

この観点から、おそらくこれは弱点ではなく、強みであることに同意するでしょう. 物理サーバーは、使用していないときでもコストがかかることはありません。

VM で必要としないキャパシティーに対しては、何も支払う必要はありません。使用しているキャパシティーと、予想される需要を処理するためにすぐに利用できるようにしておく必要がある量に対して支払うだけで済みます。

支払う意思があるだけのアイドル状態の余剰をすぐに用意することも、遅延なくアクセスできることに満足している限り余剰容量を最小限に抑えることで節約を最大化することもできます。

于 2016-03-19T01:40:11.617 に答える