本日は、Linuxの運用と保守に関する知識を引き続きご紹介します。この記事の主な内容は、ポッドレディネスプローブの実際の戦闘です。
1.ポッドレディネスプローブの概要
一部のアプリケーションシナリオでは、Podオブジェクトが正常に実行された後、サービスを正常に提供する前に、いくつかの初期化プロセスを実行し、いくつかの命令を実行する必要があります。たとえば、データや構成のロード、またはプログラムの操作には、特定のクラスのウォームアップなどが必要です。ただし、Kubernetes自体はPodオブジェクトの初期化段階を認識できません。このノードのKubernetesクラスターがPodオブジェクトにサービスリクエストを導入すると、Podオブジェクトは正常にサービスを提供できなくなります。
この問題を解決するために、Kubernetesクラスターは準備プローブの構成を導入します。ライブネスプローブと同様に、準備プローブもポッドコンテナ内の指定されたコンテンツを定期的にプローブします。プローブが成功すると、コンテナの準備ができたことを意味します。ただし、活性プローブとは異なり、準備プローブは、障害を検出したときにコンテナーを強制終了または再起動しませんが、コンテナーを「使用不可」状態にし、準備完了状態に依存する操作をトリガーします。ポッド。
2.ポッドレディネスプローブHTTP戦闘
ポッドレディネスプローブには、Exec、HTTP、TCPの3種類があります。次に、ポッドレディネスプローブの実際の戦闘を行います。この実際の戦闘では、HTTPタイプのプローブと他のタイプのプローブを使用します。ここでは詳しく説明しません。
ポッドのリソース構成マニフェストであるready-probe.yamlを作成し、それに次のように書き込みます。
apiVersion: v1
kind: Pod
metadata:
name: ready-pod
namespace: default
labels:
probe: ready
spec:
containers:
- name: ready-probe
image: nginx:1.14
ports:
- name: http
containerPort: 80
readinessProbe:
httpGet:
path: /index.html
port: http
scheme: HTTP
この設定ファイルでは、Webサーバー下のindex.htmlファイルの存在を検出するHTTPタイプの準備プローブを導入しています。ファイルが存在しない場合は、コンテナが異常であることを意味します。
上記の構成が完了したら、マニフェストを実行してポッドを作成します。実行結果は次のとおり
です。ご覧のとおり、ポッドは正常に実行されています。次に、レディネスプローブの効果を調べてみましょう。Podコンテナに入り、Webサービスのルートディレクトリにあるindex.htmlファイルを削除してから、Podコンテナのステータスを確認します。結果は次のとおりです。
上の図からわかるように、ファイルを削除すると、プローブは例外を検出します。コンテナはまだ実行中ですが、使用不可に設定されています。ポッドレディネスプローブが正常に構成されました。
独創性は簡単ではありません。転載のソースを示してください：https：//blog.csdn.net/weixin_40228200