Kubernetes のベスト プラクティス。 正しいシャットダウン 終了

Kubernetes のベスト プラクティス。 小さなコンテナの作成
Kubernetes のベスト プラクティス。 名前空間を使用した Kubernetes の構成
Kubernetes のベスト プラクティス。 Readiness および Liveness テストによる Kubernetes の Liveness の検証
Kubernetes のベスト プラクティス。 リソースのリクエストと制限の設定

分散システムの運用における重要なポイントは、障害の処理です。 Kubernetes は、システムの健全性を監視し、動作を停止したサービスを再起動するコントローラーを使用してこれを支援します。 ただし、Kubernetes はアプリケーションを強制的に停止して、システム全体の健全性を確保できます。 このシリーズでは、Kubernetes がより効率的にジョブを実行し、アプリケーションのダウンタイムを削減する方法を見ていきます。

コンテナーが登場する前は、ほとんどのアプリケーションは仮想マシンまたは物理マシン上で実行されていました。 アプリケーションがクラッシュまたはフリーズした場合、進行中のタスクをキャンセルしてプログラムを再ロードするのに長い時間がかかりました。 最悪のシナリオでは、誰かが夜間、最も不適当な時間にこの問題を手動で解決しなければなりませんでした。 重要なタスクを実行している作業マシンが 1 ～ 2 台だけである場合、そのような混乱はまったく許容できません。
そのため、手動で再起動する代わりに、プロセス レベルの監視を使用して、異常終了が発生した場合にアプリケーションを自動的に再起動するようになりました。 プログラムが失敗すると、監視プロセスが終了コードを取得し、サーバーを再起動します。 Kubernetes のようなシステムの出現により、システム障害に対するこの種の対応はインフラストラクチャに単純に統合されるようになりました。

Kubernetes は、observer-difference-take-action イベント ループを使用して、コンテナーからノード自体に到達する途中でリソースが正常な状態を維持できるようにします。

つまり、プロセス監視を手動で実行する必要がなくなりました。 リソースがヘルスチェックに失敗した場合、Kubernetes は代替リソースを自動的にプロビジョニングします。 ただし、Kubernetes はアプリケーションの障害を監視するだけではありません。 複数のマシンで実行するアプリケーションのコピーをさらに作成したり、アプリケーションを更新したり、アプリケーションの複数のバージョンを同時に実行したりできます。
したがって、Kubernetes が完全に正常なコンテナを終了できる理由は数多くあります。 たとえば、デプロイメントをアップグレードすると、Kubernetes は新しいポッドを開始しながら古いポッドをゆっくりと停止します。 ノードをシャットダウンすると、Kubernetes はそのノード上のすべてのポッドの実行を停止します。 最後に、ノードのリソースが不足すると、Kubernetes はすべてのポッドをシャットダウンして、それらのリソースを解放します。

したがって、エンド ユーザーへの影響を最小限に抑え、回復時間を最小限に抑えてアプリケーションを終了することが重要です。 つまり、シャットダウンする前に、保存する必要があるすべてのデータを保存し、すべてのネットワーク接続を閉じ、残りの作業を完了し、その他の緊急タスクを管理する必要があります。

実際には、これは、アプリケーションが SIGTERM メッセージ (Unix オペレーティング システム上の kill ユーティリティのデフォルトの信号であるプロセス終了信号) を処理できなければならないことを意味します。 このメッセージを受信したら、アプリケーションをシャットダウンする必要があります。

Kubernetes がポッドの終了を決定すると、多くのイベントが発生します。 コンテナーまたはポッドをシャットダウンするときに Kubernetes が実行する各ステップを見てみましょう。

ポッドの XNUMX つを終了したいとします。 この時点で、新しいトラフィックの受信が停止します。ポッド内で実行されているコンテナーは影響を受けませんが、すべての新しいトラフィックはブロックされます。

preStop フックを見てみましょう。これは、ポッド内のコンテナーに送信される特別なコマンドまたは HTTP リクエストです。 SIGTERM の受信時にアプリケーションが正しくシャットダウンしない場合は、preStop を使用して正しくシャットダウンできます。

ほとんどのプログラムは、SIGTERM シグナルを受信すると正常に終了しますが、サードパーティのコードや完全には制御できないシステムを使用している場合、preStop フックは、アプリケーションを変更せずに正常にシャットダウンを強制する優れた方法です。

このフックを実行した後、Kubernetes はポッド内のコンテナーに SIGTERM シグナルを送信し、まもなく切断されることをコンテナーに知らせます。 このシグナルを受信すると、コードはシャットダウン プロセスに進みます。 このプロセスには、データベース接続や WebSocket ストリームなどの長期間存続する接続の停止、現在の状態の保存などが含まれる場合があります。

preStop フックを使用する場合でも、SIGTERM シグナルを送信したときにアプリケーションに正確に何が起こるか、およびアプリケーションがどのように動作するかを確認し、ポッドのシャットダウンによって引き起こされるシステム動作のイベントや変更が発生しないようにすることが非常に重要です。あなたへの驚き。

この時点で、Kubernetes は、terminationGracePeriodSecond と呼ばれる指定された時間、または SIGTERM シグナルを受信したときに正常にシャットダウンするまでの期間待機してから、次のアクションを実行します。

デフォルトでは、この期間は 30 秒です。 preStop フックおよび SIGTERM シグナルと並行して実行されることに注意することが重要です。 Kubernetes は preStop フックと SIGTERM が終了するのを待ちません。TerminationGracePeriod が終了する前にアプリケーションが終了した場合、Kubernetes はすぐに次のステップに進みます。 したがって、この期間の値 (秒) がポッドを正しくシャットダウンするのに必要な時間以上であることを確認し、30 秒を超える場合は、期間を YAML で必要な値まで増やします。 与えられた例では、それは 60 代です。

そして最後のステップは、terminationGracePeriod 後もコンテナがまだ実行されている場合、コンテナは SIGKILL シグナルを送信して強制的に削除されます。 この時点で、Kubernetes は他のすべてのポッド オブジェクトもクリーンアップします。

Kubernetes はさまざまな理由でポッドを終了するため、安定したサービスを確保するために、どのような場合でもアプリケーションが正常に終了するようにしてください。

Kubernetes のベスト プラクティス。 外部サービスのマッピング

いくつかの広告 🙂

いつもご宿泊いただきありがとうございます。 私たちの記事が気に入っていますか? もっと興味深いコンテンツを見たいですか? 注文したり、友人に勧めたりして私たちをサポートしてください。 開発者向けのクラウド VPS は 4.99 ドルから, 当社があなたのために発明した、エントリーレベルのサーバーのユニークな類似物です。 VPS (KVM) E5-2697 v3 (6 コア) 10GB DDR4 480GB SSD 1Gbps 19 ドルからの真実、またはサーバーを共有する方法? (RAID1 および RAID10、最大 24 コア、最大 40GB DDR4 で利用可能)。

アムステルダムのエクイニクス Tier IV データセンターでは Dell R730xd が 2 倍安い? ここだけ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV 199 ドルから オランダで！ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 ドルから! について読む インフラストラクチャー企業を構築する方法730 ペニーで 5 ユーロの価値がある Dell R2650xd E4-9000 vXNUMX サーバーを使用したクラスですか?

出所： habr.com