Kubernetes コンテナのベスト プラクティス: ヘルス チェック

TL; DR

• コンテナーとマイクロサービスの高い可観測性を実現するには、ログと主要なメトリクスだけでは十分ではありません。
• より迅速な回復と復元力の向上のために、アプリケーションは高可観測性原則 (HOP) を適用する必要があります。
• アプリケーション レベルでは、NOP には適切なロギング、綿密な監視、健全性チェック、およびパフォーマンス/遷移トレースが必要です。
• NOR の要素としてチェックを使用する レディネスプローブ и ライブネスプローブ Kubernetes。

ヘルスチェックテンプレートとは何ですか?

ミッションクリティカルで可用性の高いアプリケーションを設計する場合、フォールト トレランスなどの側面を考慮することが非常に重要です。 アプリケーションが障害から迅速に回復する場合、そのアプリケーションはフォールト トレラントであるとみなされます。 一般的なクラウド アプリケーションでは、各コンポーネントが個別のコンテナーに配置されるマイクロサービス アーキテクチャが使用されます。 また、クラスターを設計するときに k8s 上のアプリケーションの可用性を確実に高めるには、特定のパターンに従う必要があります。 その中にはヘルスチェックテンプレートも含まれます。 これは、アプリケーションが正常であることを k8s に伝える方法を定義します。 これは、ポッドが実行されているかどうかに関する情報だけでなく、ポッドがリクエストをどのように受信して応答するかに関する情報でもあります。 Kubernetes がポッドの状態を把握すればするほど、トラフィック ルーティングとロード バランシングに関してより賢明な決定を下せるようになります。 したがって、高可観測性の原則により、アプリケーションはリクエストにタイムリーに応答できます。

高可観測性の原則 (HOP)

高い可観測性の原理の XNUMX つは次のとおりです。 コンテナ化されたアプリケーションを設計するための原則。 マイクロサービス アーキテクチャでは、サービスはリクエストがどのように処理されるかを気にしません (当然のことですが) が、重要なのは受信サービスからの応答をどのように受け取るかです。 たとえば、ユーザーを認証するには、あるコンテナが別のコンテナに HTTP リクエストを送信し、特定の形式での応答を期待します。これですべてです。 PythonJS もリクエストを処理でき、Python Flask が応答できます。 コンテナは、互いに内容が隠されたブラック ボックスのようなものです。 ただし、NOP 原則では、各サービスがその健全性、準備状況、フォールト トレランスのステータスを示す複数の API エンドポイントを公開する必要があります。 Kubernetes は、ルーティングと負荷分散の次のステップを検討するために、これらのインジケーターを要求します。

適切に設計されたクラウド アプリケーションは、標準 I/O ストリーム STDERR および STDOUT を使用してメイン イベントをログに記録します。 次に、filebeat、logstash、fluentd などの補助サービスが登場し、集中監視システム (Prometheus など) やログ収集システム (ELK ソフトウェア スイート) にログを配信します。 以下の図は、ヘルス テスト パターンと高可観測性の原則に従ってクラウド アプリケーションがどのように動作するかを示しています。

Kubernetes でヘルス チェック パターンを適用するにはどうすればよいですか?

k8s は、すぐに使用できるコントローラー (デプロイメント, レプリカセット, デーモンセット, ステートフル セット など）。 何らかの理由でポッドが落ちたことを発見したコントローラーは、ポッドを再起動するか、別のノードに移動しようとします。 ただし、ポッドは稼働中であると報告する場合がありますが、ポッド自体は機能していません。 例を挙げてみましょう。アプリケーションは Web サーバーとして Apache を使用し、コンポーネントをクラスターのいくつかのポッドにインストールしました。 ライブラリが正しく構成されていないため、アプリケーションへのすべてのリクエストはコード 500 (内部サーバー エラー) で応答します。 配送を確認する場合、ポッドのステータスを確認すると正常な結果が得られますが、顧客の考え方は異なります。 この望ましくない状況を次のように説明します。

この例では、k8s は次のことを行います。 機能チェック。 このタイプの検証では、kubelet はコンテナ内のプロセスの状態を継続的にチェックします。 プロセスが停止したことを理解したら、プロセスを再開します。 アプリケーションを再起動するだけでエラーが解決でき、プログラムがエラー時にシャットダウンするように設計されている場合、NOP とヘルス テスト パターンに従うために必要なのはプロセスのヘルス チェックだけです。 唯一残念なのは、再起動してもすべてのエラーが解消されるわけではないことです。 この場合、k8s はポッドの問題を特定するための 2 つのより詳細な方法を提供します。 ライブネスプローブ и レディネスプローブ.

LivenessProbe

その間 ライブネスプローブ kubelet は 3 種類のチェックを実行します。ポッドが実行されているかどうかだけでなく、リクエストを受信して​​適切に応答する準備ができているかどうかも判断します。

• ポッドへの HTTP リクエストを設定します。 応答には、200 ～ 399 の範囲の HTTP 応答コードが含まれている必要があります。したがって、コード 5xx と 4xx は、プロセスが実行中であっても、ポッドに問題があることを示します。
• 非 HTTP サービス (Postfix メール サーバーなど) を使用してポッドをテストするには、TCP 接続を確立する必要があります。
• ポッドに対して任意のコマンドを実行します（内部的に）。 コマンド完了コードが 0 の場合、チェックは成功したとみなされます。

これがどのように機能するかの例。 次のポッド定義には、HTTP リクエストで 500 エラーをスローする NodeJS アプリケーションが含まれています。このようなエラーを受け取ったときにコンテナが確実に再起動されるようにするには、 livenessProbe パラメータを使用します。

apiVersion: v1
kind: Pod
metadata:
 name: node500
spec:
 containers:
   - image: magalix/node500
     name: node500
     ports:
       - containerPort: 3000
         protocol: TCP
     livenessProbe:
       httpGet:
         path: /
         port: 3000
       initialDelaySeconds: 5

これは他のポッド定義と変わりませんが、オブジェクトを追加しています。 .spec.containers.livenessProbe。 パラメータ httpGet HTTP GET リクエストの送信先のパスを受け入れます (この例では、これは /、しかし戦闘シナリオでは次のようなものがあるかもしれません /api/v1/status）。 別の livenessProbe はパラメータを受け取ります initialDelaySecondsこれは、検証操作が指定された秒数待機するように指示します。 コンテナーの起動には時間が必要であり、再起動するとしばらくの間使用できなくなるため、遅延が必要になります。

この設定をクラスターに適用するには、次を使用します。

kubectl apply -f pod.yaml

数秒後、次のコマンドを使用してポッドの内容を確認できます。

kubectl describe pods node500

出力の最後で、 それは何ですか.

ご覧のとおり、livenessProbe は HTTP GET リクエストを開始し、コンテナーはエラー 500 を生成し (これがプログラムされた内容です)、kubelet がコンテナーを再起動しました。

NideJS アプリケーションがどのようにプログラムされたか知りたい場合は、使用された app.js と Dockerfile を次に示します。

app.js

var http = require('http');

var server = http.createServer(function(req, res) {
    res.writeHead(500, { "Content-type": "text/plain" });
    res.end("We have run into an errorn");
});

server.listen(3000, function() {
    console.log('Server is running at 3000')
})

ドッカーファイル

FROM node
COPY app.js /
EXPOSE 3000
ENTRYPOINT [ "node","/app.js" ]

これに注意することが重要です。livenessProbe は、コンテナーが失敗した場合にのみコンテナーを再起動します。 コンテナーの実行を妨げているエラーが再起動によって修正されない場合、kubelet は問題を修正するためのアクションを実行できません。

レディネスプローブ

readinessProbe は、トラブルシューティング アクションを除き、livenessProbes (GET リクエスト、TCP 通信、コマンド実行) と同様に機能します。 障害が検出されたコンテナは再起動されませんが、受信トラフィックからは隔離されます。 コンテナーの XNUMX つが大量の計算を実行しているか、負荷が高く、応答時間が増加していると想像してください。 livenessProbe の場合、応答の可用性チェックが (timeoutSeconds チェック パラメーター経由で) トリガーされ、その後 kubelet がコンテナーを再起動します。 コンテナは開始されると、リソースを大量に消費するタスクの実行を開始し、再び再起動されます。 これは、応答速度が必要なアプリケーションにとって非常に重要です。 たとえば、道路を走行中の車がサーバーからの応答を待っていて、応答が遅れて事故に遭ったとします。

GET リクエストの応答時間を 5 秒以内に設定する redinessProbe 定義を作成しましょう。アプリケーションは XNUMX 秒後に GET リクエストに応答します。 pod.yaml ファイルは次のようになります。

apiVersion: v1
kind: Pod
metadata:
 name: nodedelayed
spec:
 containers:
   - image: afakharany/node_delayed
     name: nodedelayed
     ports:
       - containerPort: 3000
         protocol: TCP
     readinessProbe:
       httpGet:
         path: /
         port: 3000
       timeoutSeconds: 2

kubectl を使用してポッドをデプロイしましょう。

kubectl apply -f pod.yaml

数秒待ってから、readinessProbe がどのように機能するかを見てみましょう。

kubectl describe pods nodedelayed

出力の最後で、いくつかのイベントが類似していることがわかります。 これ.

ご覧のとおり、チェック時間が 2 秒を超えても、kubectl はポッドを再起動しませんでした。 代わりに、彼はリクエストをキャンセルしました。 受信した通信は、他の動作中のポッドにリダイレクトされます。

ポッドがオフロードされたので、kubectl はリクエストを再びポッドにルーティングすることに注意してください。GET リクエストへの応答は遅延しなくなりました。

比較のために、変更された app.js ファイルを以下に示します。

var http = require('http');

var server = http.createServer(function(req, res) {
   const sleep = (milliseconds) => {
       return new Promise(resolve => setTimeout(resolve, milliseconds))
   }
   sleep(5000).then(() => {
       res.writeHead(200, { "Content-type": "text/plain" });
       res.end("Hellon");
   })
});

server.listen(3000, function() {
   console.log('Server is running at 3000')
})

TL; DR
クラウド アプリケーションが登場する前は、ログがアプリケーションの健全性を監視およびチェックする主な手段でした。 しかし、是正措置を講じる手段はありませんでした。 ログは現在でも役に立ちます。緊急事態を分析し、意思決定を行うためには、ログを収集してログ収集システムに送信する必要があります。 [これらすべては、たとえば monit を使用するクラウド アプリケーションなしでも実行できますが、k8s を使用するとはるかに簡単になりました :) – 編集者注。 ]

現在では、修正はほぼリアルタイムで行う必要があるため、アプリケーションをブラックボックスにする必要はなくなりました。 いいえ、必要に応じて即座に応答できるように、監視システムがプロセスの状態に関する貴重なデータをクエリおよび収集できるようにするエンドポイントを示す必要があります。 これはパフォーマンス テスト設計パターンと呼ばれ、高可観測性原則 (HOP) に準拠しています。

Kubernetes は、readinessProbe と livenessProbe という 2 種類のヘルスチェックをデフォルトで提供します。 どちらも同じタイプのチェック (HTTP GET リクエスト、TCP 通信、コマンド実行) を使用します。 これらは、ポッド内の問題に応じてどのような決定を下すかが異なります。 livenessProbe はエラーが再び発生しないことを期待してコンテナを再起動し、readinessProbe は問題の原因が解決されるまで受信トラフィックからポッドを隔離します。

適切なアプリケーション設計では、両方のタイプのチェックを組み込み、特に例外がスローされた場合に十分なデータが収集されるようにする必要があります。 また、監視システム (Prometheus) に重要な健康指標を提供する必要な API エンドポイントも表示されます。

出所： habr.com