1. 概要

このチュートリアルでは、OpenShift内にデプロイされたアプリケーションを正常に保つ方法を説明します。 

2. 健全なアプリケーションとは何ですか？

まず、アプリケーションを正常に保つことの意味を理解してみましょう。

多くの場合、ポッド内のアプリケーションで問題が発生します。 特に、アプリケーションが応答を停止したり、誤って応答し始めたりする場合があります。 

構成エラーやデータベース、ストレージ、その他のアプリケーションなどの外部コンポーネントへの接続などの一時的な問題が原因で、アプリケーションが異常になる可能性があります。

復元力のあるアプリケーションを構築するための最初のステップは、ポッドに自動ヘルスチェックを実装することです。 問題が発生した場合、ポッドは手動で介入することなく自動的に再起動されます。

3. プローブを使用したヘルスチェック

Kubernetes、つまりOpenShiftは、ライブネスプローブとレディネスプローブの2種類のプローブを提供します。 

ライブネスプローブを使用して、コンテナーを再起動する必要がある時期を認識します。ヘルスチェックが失敗してポッドが使用できなくなった場合、OpenShiftはポッドを再起動します。 

準備プローブトラフィックを受け入れるためのコンテナの可用性を確認します。すべてのコンテナの準備ができたら、ポッドの準備ができていると見なします。 サービスロードバランサーは、ポッドが準備完了状態でない場合にポッドを削除します。

コンテナの起動に時間がかかる場合、このメカニズムにより、必要なトラフィックを受け入れる準備ができているポッドに接続をルーティングできます。 これは、たとえば、データセットを初期化する必要がある場合や、別のコンテナまたは外部サービスへの接続を確立する必要がある場合に発生する可能性があります。

ライブネスプローブは、次の2つの方法で構成できます。

  • ポッドデプロイメントファイルの編集
  • OpenShiftウィザードの使用

どちらの場合も、得られる結果は同じままです。 T 最初のメカニズムはKubernetesから直接継承されます。 別のチュートリアルですでに説明されています 。

このチュートリアルでは、代わりに、OpenShiftグラフィカルユーザーインターフェイスを使用してプローブを設定する方法を示します。

4. ライブネスプローブ

ライブネスプローブは、展開構成ファイル内の特定のコンテナーのパラメーターとして定義します。 ポッド内のすべてのコンテナは、この構成を継承します。 

プローブがHTTPまたはTCPチェックとして作成されている場合、プローブはコンテナが実行されているノードから実行されます。 OpenShiftは、プローブがスクリプトとして作成されるときに、コンテナー内でプローブを実行します。

それでは、OpenShift内にデプロイされたアプリケーションに新しい活性プローブを追加しましょう。

  1. アプリケーションが属するプロジェクトを選択しましょう
  2. 左側のパネルから、アプリケーション->展開をクリックできます。
  3. 選択したアプリケーションを選択しましょう
  4. [アプリケーション展開の構成]タブで、ヘルスチェックの追加アラートのリンクを選択します。 アラートは、アプリケーションにヘルスチェックが構成されていない場合にのみ表示されます
  5. 新しいページから、ライブネスプローブの追加を選択しましょう
  6. 次に、活気プローブを好みに合わせて構成しましょう。

これらのLivenessProbe設定のそれぞれの意味を分析してみましょう。

  • Type ：ヘルスチェックのタイプ。 HTTP（S）チェック、コンテナ実行チェック、またはソケットチェックから選択できます
  • HTTPSを使用：このチェックボックスを選択するのは、活性サービスがHTTPSで公開されている場合のみです。
  • Path ：アプリケーションが活性プローブを公開するパス
  • ポート：アプリケーションがライブネスプローブを公開するポート
  • 初期遅延：コンテナーの開始後、プローブが実行されるまでの秒数–空白のままにすると、デフォルトで0になります。
  • Timeout ：プローブタイムアウトが検出されるまでの秒数–空白の場合はデフォルトで1秒

OpenShiftは、アプリケーション用に新しいDeploymentConfigを作成します。 新しいDeploymentConfigには、新しく構成されたプローブの定義が含まれます。

5. 準備プローブ

コンテナがアクティブであると見なされる前にトラフィックを受信する準備ができていることを確認するために、準備プローブを構成できます。 活性プローブとは異なり、コンテナが準備チェックに失敗した場合、そのコンテナはアクティブなままですが、トラフィックを処理できません。 

準備プローブは、ダウンタイムゼロの展開を実行するために不可欠です。

ライブネスプローブの場合と同様に、OpenShiftウィザードを使用するか、ポッドデプロイメントファイルを直接編集することで、レディネスプローブを設定できます。

ライブネスプローブはすでに構成されているので、準備プローブを構成しましょう。

  1. アプリケーションが属するプロジェクトを選択します
  2. 左側のパネルから、アプリケーション->展開をクリックできます。
  3. 選択したアプリケーションを選択しましょう
  4. [アプリケーション展開の構成]タブ内で、右上隅にあるアクションボタンをクリックし、ヘルスチェックの編集を選択できます。
  5. 新しいページから、レディネスプローブの追加を選択しましょう。
  6. 次に、準備プローブを好みに合わせて構成しましょう。

 

活性プローブで見られるように、構成可能なパラメーターは次のとおりです。

  • タイプ：ヘルスチェックのタイプ。 HTTP（S）チェック、コンテナ実行チェック、またはソケットチェックから選択できます
  • HTTPSを使用：準備サービスがHTTPSで公開されている場合にのみチェックボックスを選択します
  • Path ：アプリケーションが準備プローブを公開するパス
  • ポート：アプリケーションが準備プローブを公開するポート
  • 初期遅延：コンテナーの開始後、プローブが実行されるまでの秒数（デフォルトは0）
  • Timeout ：プローブタイムアウトが検出されてからの秒数（デフォルトは1）

繰り返しになりますが、OpenShiftは、アプリケーション用に、レディネスプローブを含む新しいDeploymentConfigを作成します。

6. 急いでください

私たちが提示したものをテストする時が来ました。 OpenShiftクラスター内にデプロイするSpringBootアプリケーションがあるとします。 これを行うには、チュートリアルを参照できます。ここでは、テストアプリケーションが段階的な展開として示されています。

アプリケーションが正しくデプロイされたら、前の段落で示した内容に従って、プローブを設定することから始めることができます。 Spring Bootアプリケーションは、SpringBootActuatorを使用してヘルスチェックエンドポイントを公開します。 アクチュエータの構成の詳細については、専用チュートリアルを参照してください。

セットアップの最後に、[展開の構成]ページに、新しく構成されたプローブに関する情報が表示されます。

次に、準備と活性のプローブが正しく機能していることを確認します。

6.1. レディネスプローブをテストする

新しいバージョンのアプリケーションのデプロイメントをシミュレートしてみましょう。 準備プローブにより、ダウンタイムなしで展開できます。 この場合、新しいバージョンをデプロイすると、OpenShiftは新しいバージョンに対応する新しいポッドを作成します。 古いポッドは、新しいポッドがトラフィックを受信する準備ができるまで、つまり、新しいポッドの準備プローブが肯定的な結果を返すまで、トラフィックを処理し続けます。

プロジェクトのページ内のOpenShiftダッシュボードから、デプロイフェーズの途中を見ると、ダウンタイムゼロのデプロイの表現を確認できます。

6.2. ライブネスプローブをテストする

代わりに、活性プローブの障害をシミュレートしてみましょう。

この時点でアプリケーションによって実行されたヘルスチェックが否定的な結果を返すと仮定しましょう。 これは、ポッドの作業に必要なリソースが利用できないことを示しています。

OpenShiftはポッドをn回キルし（デフォルトでは n は3に設定されています）、再作成します。 このフェーズで問題が解決されると、ポッドは正常な状態に復元されます。 それ以外の場合、試行中に依存リソースが引き続き使用できない場合、OpenShiftはポッドをFailedステータスと見なします。

この動作を確認してみましょう。 ポッドに関連するイベントのリストを含むページを開きましょう。 次のような画面が表示されます。

ご覧のとおり、OpenShiftはヘルスチェックの失敗を記録し、ポッドを強制終了し、再起動を試みました。

7. 結論

このチュートリアルでは、OpenShiftの2種類のプローブについて説明しました。

同じコンテナ内で準備プローブと活性プローブを並行して使用しました。 両方を使用して、問題が発生したときにOpenShiftがコンテナーを再起動し、コンテナーがまだ提供する準備ができていないときにトラフィックがコンテナーに到達できないようにしました。 ここでの例の完全なソースコードは、いつものように、GitHub上にあります。