k8sヘルスチェック-ヘルスチェック

1.k8sヘルスチェックのデフォルトの方法

k8sのデフォルトのヘルスチェックメカニズム：DockerfileのCMDまたはENTRYPOINTに基づいて、プロセスの終了時にリターンコードがゼロ以外の場合、コンテナに障害があると見なされ、k8sはrestartPolicyに従ってコンテナを再起動します。

1）dockerのrestartPolicyには次の4つのタイプがあります。

常に:(どのコードが終了しても、dockerデーモンは終了したコンテナーを再起動しようとします。手動で停止すると、ポリシーは有効になりません）。
OnFailure：エラー（ゼロ以外の出口）のためにコンテナーが停止しました。Max-retriesは、再起動の最大試行回数を指定できます。
停止しない限り：いつものように、コンテナを手動で停止した後、dockerデーモンが再起動されても、コンテナポリシーは有効になりません。
いいえ：自動的に再起動しません（デフォルトモード）

2）k8sでフォーマットする

...
spec：
  restartPolicy: OnFailure   #重启策略
  containers:
...

3）欠陥

このメカニズムの欠点は、コンテナに障害が発生してもプロセスが終了しない場合があることです。たとえば、コンテナの内部Webサービスに500が表示されたり、システムが過負荷になったりしても、この時点でhttpdプロセスが異常に終了することはありません。したがって、コンテナは引き続き通常の実行です。つまり、コンテナ内のサービスリリースが正常であると判断することは不可能です。

2.ヘルスチェック->活性検出

1）活気の目的

ユーザーは、コンテナが正常であるかどうかを判断する条件をカスタマイズできます。検出に失敗した場合、k8sはコンテナを再起動し、自己回復を実現するためにコンテナを再起動するタイミングをk8sに通知します。

2）livenessProbeのキーワード

...
spec：
  containers：
  ...
  livenessProbe：           #Health Check的机制
httpGet：                   #探测方式：http的方式
path：/example/index.html   #默认的索引目录
port: 8080                 #服务的端口
scheme: http               #用到的协议
    initialDelaySeconds: 5 #容器启动10秒后开始执行liveness探测；若某个容器启动需要30秒，则这个值就要设置大于30秒
    periodSeconds: 10      #每次执行liveness探测的时间间隔
    failureThreshold: 3    #liveness探测失败的次数；如果连续三次失败，就会杀掉进程重启容器
    successThreshold: 1    #liveness探测成功的次数；如果成功1次，就表示容器正常
timeoutSeconds: 5          #执行livesness的超时时间，如果执行后5秒没有结果，则重启执行liveness

3.ヘルスチェック->準備検出

1）準備の目的

読み取り可能性検出は、コンテナーをsvc負荷分散プールにいつ追加できるかを通知するもので
あり、読み取り可能性検出の構成構文は、活性の構成構文とまったく同じです。

4.まとめ

活性と読み取りが特に構成されていない場合、k8sはデフォルトの方法を使用します。つまり、コンテナ起動プロセスの戻り値がゼロかどうかを判断して、検出が成功したかどうかを判断します。
LivesとReadnessの構成はまったく同じで、構文とパラメーターは同じです。違いは、検出が失敗した後の動作です。Lives検出はコンテナーを再起動しますが、Readness検出はコンテナーを使用不可として設定し、転送された要求を受け入れません。サービスによって
活気と準備は独立して実行され、2つの間に依存関係はなく、単独で使用することも、同時に使用することもできます：
Liveness探测判断的是容器是否需要重启实现自愈;
Readness探测判断的是容器是否已准备好对外提供服务。

5.活気と準備の検出方法

http Get：返回200-400算成功，别的算失败;
ここに画像の説明を挿入
tcp socket：你指定的tcp端口打开，比如能telnet 上;
cmd exec：在容器中执行一个命令推出返回0 算成功。