起動する仕組みになっています。これを使って、Node単位でやりたい処理を仕込むことができます。......恒例のスポットインスタンスの強制Terminate対策とか、してみましょうそうしましょう。いう名前のPodが起動します。こいつに関する詳しい公式説明が見つからないのが、ちょっと残念なところ。して活躍しております。関連の記事を記載しておきます。使っているものがあります。退避する手法をとっていることがわかります。これはこれで、採用するべき構造の場合があると思うので、選択肢の1つとして知っておきたいところです。これまでのスポット対策の流れ私の場合、既存の仕組みを使いまわしたい意図があったため、独自の路線をいくことにしました。いっても、そう変なことをするわけでもありません。内にスポット検知用のデーモンを常駐させ、検知したら(当時は)ELBから自身を外すなど、安全な状態にしてから死を待つ、という処理をしていました。悪い内容なわけではないですが、それなりに煩雑な処理をイメージに組み込むのは、開発・運用上において非常に気持ち悪いものがあり、機をみて改善することにしました。非同期で実行して終わり、というように変更しました。探して外したり、監視サービスの該当ホストを無効にする、といった処理を担当するようになりました。変更するだけ、というように綺麗に切り分けられたと思います。今回のダメな案スポット対策に必須な機能として、EC2のメタデータから強制Teminate発動2分前を検知するサービスからサーバーリソースを切り離すこの2つがあり、どこで検知して、誰が切り離すかを考えることになります。検知することになりますが、イメージは公式配布のEKS用を使っています。あたりで汚らしく埋め込むことになりますが、どちらもお断りです。取得できるので、EC2の時と同じようにスケール用Podにデーモンを仕込むこともできますが、せっかくコンテナなので、サービス用Podに汚れ仕事はさせたくないですよ、と。やればカッコ可愛いじゃない、と降臨するわけです。スポット対策という流れで、旧来のEC2から移植することになりました。やったのと同じように、DaemonSet用のイメージを作成します。そのためのレポジトリはこちらです。スポットTerminate検知と、Lambda発火が書いてあります。EC2の時のをそのまま移植しました。追加でやらせるのがほどよいと思います。EKSがNodeに最初から仕込んでいるラベルに合わせています。120秒弱の猶予があるので、このくらいは余裕で終わります。適当なNodeを、まぁまぁ落とされやすそうなインスタンスタイプのスポットで起動しておいて、放置しておくと発動し、何箇所かでその確認をすることができます。そのあとは、たいてい何分かは余剰リソースがないために起動エラーが続きます。Lambdaログにて、その処理内容を確認できます。Lambdaを書く時は、ログ出力は気持ち多めにやっておくとよいですね。飛ばしたメッセージを、メールなりなんなりで確認できます。今回の方法は、ALB前提の構成ではありますが、なかなか綺麗に処理の分別ができているのではないかと思います。コンテナでスポットを適用するのは、なんとなく気持ち悪い感じがするかもですが、リソースや費用の都合的にはEC2でやるのとあまり変わらないので、今まで使ってきた人は、EKSでも使えるようにすればいいと思うのです。コメントをキャンセルメールアドレスが公開されることはありません。data-url="">外道父ドリコムで主にインフラエンジニアをやっている何でも屋。WordPress.。