kubernetes Readiness and liveness and startupProbe

kubernetes Podのライフサイクル(Readiness and liveness and startupProbe)
容器プローブ
なぜreadiness and livenessを使うのですか?
k 8 sには大量の非同期メカニズムと多様なオブジェクト関係設計上のデカップリングが採用されているため、アプリケーションインスタンス数 / 、またはアプリケーションバージョンが変化してスクロールアップグレードをトリガーする場合、システムはアプリケーション関連のサービス、ingress構成が常にタイムリーにブラシを完了することを保証することはできない.場合によっては、新しいPodだけが自己初期化を完了し、システムがEndPoint、負荷イコライザなどの外部からのアクセス情報のリフレッシュを完了していないため、古いPodはすぐに削除され、最終的にはサービスの短い額が利用できなくなり、生産にとって受け入れられないため、この時に生存プローブ(Readiness)が登場した.
スタートプローブ
サービス開始後すぐに使用できるとは限らない場合がありますが、準備プローブを使用してinitialDelay(容器起動後何sから検出)の値を設定し、サービスが生存しているかどうかを判断することがよく行われています.

livenessProbe:
  httpGet:
    path: /test
    prot: 80
  failureThreshold: 1
  initialDelay：10
  periodSeconds: 10

しかし、この時、もし私たちのサービスAが起動するのに60 sが必要であれば、上のプローブを採用すれば、このpodは死の循環に陥ります.起動後10 sの探知を経て、正常ではないことが発見されたので、再起動戦略を持ってPodを再起動し、死の循環に入ります.initialDelayの値を調整すればいいのではないでしょうか.しかし、すべてのサービスが起動するのにどれだけのsが必要か知っていることを保証することができますか?賢いあなたはまた、failureThresholdの値を調整すればいいと思っていますが、どのくらい調整すればいいのでしょうか.もし私たちが

livenessProbe:
  httpGet:
    path: /test
    prot: 80
  failureThreshold: 5
  initialDelay：10
  periodSeconds: 10

このように設定すれば、最初のpodは正常に起動できますが、後で探知すると(5*10 s=50 s)サービスが利用できないことを発見する必要があります.これは生産中には許されないので、startupProbeとlivenessProbeと同じプローブを使用して、サービスが正常に起動したかどうかを判断します.

livenessProbe:
  httpGet:
    path: /test
    prot: 80
  failureThreshold: 1
  initialDelay：10
  periodSeconds: 10

startupProbe:
  httpGet:
    path: /test
    prot: 80
  failureThreshold: 10
  initialDelay：10
  periodSeconds: 10

このようにすれば,サービスが1010=100 s以内でいつ起動してもよいので,プローブプローブプローブが成功したらlivenessProbeに任せて継続的にプローブを行い,問題を発見したとき110=10が10 s以内で問題を発見し,タイムリーに応答することができる.
サービスプローブ
容器の中のプログラムが起動する準備ができているかどうかを検出します.容器の中のプログラムが起動に成功した後だけrunning状態になります.そうしないと、容器の起動に成功します.彼はまだ失敗した信号です(彼の中のサービスが検出に成功していないためです).
生存プローブ(livenessProbe)(動作するかどうか)
容器が動いているかどうかを検出するのは、単純に容器が生きているかどうかを検出するだけで、中のサービスが正常であるかどうかを検出するものではない.プローブが失敗した場合、彼は再起動戦略を開始する.
3種類のプロセッサ:

1,ExecAction:カスタムコマンドにより検出する、戻り値が0の場合は生存を示し、戻り値が0でない場合は生存を示す.

2,TCPSocketAction:コンテナ上のポートをtcpチェックし、ポートが開いている場合は

生存を示す.

3,HTTPGetAction:指定ポートとurlアドレスに対してHTTP Get要求を実行し、応答のステータスコードが200以上400未満である場合、

は生存すると考えられる.
プローブのたびに次の3つの結果しか得られません.

1、成功:容器はテスト

に合格した.

2、失敗:容器がテスト

に合格しなかった

3、不明:テストに失敗したため、

は何もしません.
プローブの例:
ExecAction

# cat nginx.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  restartPolicy: OnFailure
  containers:
  - name: nginx
    image: nginx:1.14.1
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80
      protocol: TCP
    - name: https
      containerPort: 443
      protocol: TCP
    livenessProbe:
      exec:
        command: ["test","-f","/usr/share/nginx/html/index.html"]
      failureThreshold: 3
      initialDelaySeconds: 5
      periodSeconds: 5
      timeoutSeconds: 5
    readinessProbe:
      httpGet:
        port: 80
        path: /index.html
      initialDelaySeconds: 15
      timeoutSeconds: 1

この容器を起動し、サービスプローブをテストします.

kubectl create -f nginx.yaml

私たちはnginxコンテナに入ってindexというファイルを削除しました.詳細を見てください.

#kubectl describe pod nginx
.....
Events:
  Type     Reason     Age                From                    Message
  ----     ------     ----               ----                    -------
  Normal   Scheduled  4m24s              default-scheduler       Successfully assigned default/nginx to 192.168.1.124
  Normal   Pulling    4m23s              kubelet, 192.168.1.124  pulling image "nginx:1.14.1"
  Normal   Pulled     4m1s               kubelet, 192.168.1.124  Successfully pulled image "nginx:1.14.1"
  Warning  Unhealthy  57s                kubelet, 192.168.1.124  Readiness probe failed: HTTP probe failed with statuscode: 404
  Warning  Unhealthy  50s (x3 over 60s)  kubelet, 192.168.1.124  Liveness probe failed:
  Normal   Killing    50s                kubelet, 192.168.1.124  Killing container with id docker://nginx:Container failed liveness probe.. Container will be killed and recreated.
  Normal   Pulled     50s                kubelet, 192.168.1.124  Container image "nginx:1.14.1" already present on machine
  Normal   Created    49s (x2 over 4m)   kubelet, 192.168.1.124  Created container
  Normal   Started    49s (x2 over 4m)   kubelet, 192.168.1.124  Started container

イベント情報から明らかなように、彼のサービス探知は404を間違えて報告し、すぐに容器を再起動する過程を実行した.
プローブパラメータの説明:
exec:カスタムコマンドを使用したプローブhttpGetの作成:httpアクセスを使用してtcpSocketを検出:tcpソケットを使用してfailureThresholdを検出する:連続失敗数回真の失敗を計算するinitialDelaySeconds:コンテナ起動数秒後にプローブを開始する(コンテナ内のサービス起動に時間がかかるため)periodSeconds:プローブ間隔数秒timeoutSeconds:コマンド実行のタイムアウト時間
HTTPGetのプローブパラメータ:

host:そのホスト(URL)を検出する

path:アクセスパス(URI)

port:アクセスするポート(必須フィールド)

scheme:ホストに接続するためのスキーマ(HTTPまたはHTTPS).デフォルトはHTTP

httpHeaders:リクエストに設定するカスタムヘッダー.HTTPは重複ヘッダーを許可する.