増加のタイミングは、Podがリソース不足で増やせない状態になった時であり、平均CPU使用率は全く関係ないところが特徴です。いうPod管理グループを編集して台数を増減してくれます。いった流れになります。最近のシステムだと、何かが落ちたり機能不全になったら、破棄して可能な限り同じ条件で自動起動する、というのが主流だと思います。この辺はだいたい良くできているので、しっかり確認だけはしておきたいところです。異常が起きたら再起動したり、指定台数を保つようにできています。見て確認するのではなく、どこか外部に吐き出してアラートを上げる仕組みなど考える必要があります。なるので、障害が起きても台数は保ってくれます。スポットを扱う場合は、強制Terminateも考慮する必要があり、その対応は従来と変わりません。急なダウンのときは一部のリクエストにエラーが返るのは仕方ありません。よってヘルスチェックされているため、ダウン~ダウン判定完了までは、そのNode/Podへ転送されたリクエストがエラーになるからです。いう部分は許容するのが基本であり、大事なのは各所の障害時に何分何秒程度で復旧するのか把握するのと、ログやアラートによって認知して改善していくことで、その辺はKubernetesだからナニということはありません。普通に使えるので、複数のインスタンスタイプを指定したりスポットで自動オンデマンド価格、ということは可能です。なるため、CPU性能やメモリ容量の差でどうなるのか考えられる人にしかオススメできない気がします。Master的な機能スポットはいつもどおり、いつTerminateされてもおかしくない前提で組むのですが、スポットダウンに限らず、AutoscalingのDecreaseに巻き込まれてダウンしない方がよいシステムがいくつかあるため、配置について考える必要があります。いうAutoscalingに関わるHelmのPod。いうEKSが管理しているDNSサーバー。ダウンしたら他のNodeで起動しますし、Nodeを落とそうとする前に移行しようとしてくれるのですが、Master的機能のPodにとってはそれらはそもそも起きない一定の環境に収めておくべきと考えました。役割に分け、いろんな設定で任意の配置をできるようにしたのですが、ややこしいので別途記事で書きます。落ちるとわかっていれば、事前に安全に落とす方法がありますよ。速やかに切断するのがシンプルな構成でしょって思ったので、Pod配置とNodeでのスポット対応を適切に行えば十分スポットも使えるなと判断しました。結論付いたので満足しています。環境変数コンテナは環境変数の扱いが大切なのですが、これも扱い方がいくつかあるので迷いどころです。どのように扱えば安全なのか、そもそも安全ってどういう状態なのか、どの方法なら要件を満たせるのか、考える必要が出てきます。そのため、いくつかある方法を試しておき、それぞれの効果やメリット・デメリットを知っておくとよいです。続くんぢゃここまでの内容が全てではないですが、だいたいここまでのことを考えつつ進めていって、ようやく基本的な構築が完了するくらいのイメージです。実際に運用するには、もっと細かいことを調査したり調整しなくては全然足りていないので、途中でぶん投げないように少しずつ続編を書いていきたいと思いますん。コメントをキャンセルメールアドレスが公開されることはありません。data-url="">外道父ドリコムで主にインフラエンジニアをやっている何でも屋。WordPress.。