詳細ポッドヘルスチェック（生存性、即応、ロールオーバー）

環境の紹介

ホストコンピューター	IPアドレス	サービス
主人	192.168.1.21	K8S + httpdの+ nginxの
node01	192.168.1.22	K8S
node02	192.168.1.23	K8S

[に基づいてhttps://blog.51cto.com/14320361/2464655続ける]（）実験

A、プローブおよび生存性のポッドの準備

　　容器を再起動するかを決定するKubelet使用ライブネスプローブ（プローブ生存）。アプリケーションが実行されているが、さらなる操作を行うことができず、生存性プローブは、デッドロックをキャプチャする時期たとえば、この状態でコンテナを再起動し、アプリケーションがまだバグの存在下で永遠に実行し続けることができる
　　（レディKubelet使用準備プローブ容器は、トラフィックを受け入れる準備ができるかどうかを判断するために）プローブ。レディ状態のkubeletでコンテナ内のポッドは、ポッド準備を特定する場合のみです。サービスのポッド後端ように制御されるべき信号の役割はどのようなものです。非準備状態でポッド場合、それらはでロードバランササービスから削除されます。

プローブは、次の3つの方法をサポートしています。

<1> exec-コマンド

ユーザがコマンド容器を行う内、終了コードは、コマンドの実行がアプリケーション稼働し、他のタスクアプリケーションが正常に動作していないと考えられる場合は0です。

  livenessProbe:
    exec:
      command:
      - cat
      - /home/laizy/test/hostpath/healthy

<2> TCPSocket

（：ポートで、IPアドレス）、ユーザのソケット接続のコンテナを開こうとします。私たちは、この接続を確立することができれば、それはアプリケーション稼働して考えられている、またはアプリケーションが正しく機能していないこと。

livenessProbe:
tcpSocket:
   port: 8080

<3> HTTPGET

200と399の間に返されたHTTPステータスコードは、アプリケーションの起動やアプリケーションが正常に機能していない、または動作していることを考慮すれば、Webアプリケーションは、コンテナのウェブフックを呼び出します。各HTTPヘルスチェックが再び指定されたURLにアクセスします。

  httpGet: #通过httpget检查健康，返回200-399之间，则认为容器正常
    path: / #URI地址
    port: 80 #端口号
    #host: 127.0.0.1 #主机地址
    scheme: HTTP #支持的协议，http或者https
  httpHeaders：’’ #自定义请求的header

パラメータ説明

initialDelaySeconds：最初の実行容器は探査を開始した後は、待機する秒数です。

periodSeconds：プローブの周波数を実行します。デフォルトは10秒、1秒の最小値です。

timeoutSecondsの：プローブのタイムアウト。1秒、1秒の最小デフォルト。

successThresholdは：プローブした後にのみ成功として認識された回数、連続したプローブの少なくとも成功を失敗しました。デフォルトは1です。生存性のために1でなければなりません。最小値は1です。

以下の三つのいずれかの探査の結果：

成功：コンテナは、試験に合格しました。
失敗：コンテナが検査に失敗しました。
不明：ので、任意のアクションを取ることはありません、チェックの実行に失敗しました。

1. LivenessProbe（活性）

（1）livenss YAMLファイルの調製

[root@node02 ~]# vim livenss.yaml
kind: Pod
apiVersion: v1
metadata:
  name: liveness
  labels:
    test: liveness
spec:
  restartPolicy: OnFailure
  containers:
  - name: liveness
    image: busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/test; sleep 60; rm -rf /tmp/test; sleep 300
    livenessProbe:              #存活探测
      exec:                     #通过执行命令来检查服务是否正常
        command:                #命令模式
        - cat
        - /tmp/test
      initialDelaySeconds: 10    #pod运行10秒后开始探测
      periodSeconds: 5           #检查的频率，每5秒探测一次

コンテナの構成にポッドの設定ファイル。periodSecondsは生存性プローブを実行するために5秒ごとにkubelet所定。initialDelaySecondsは10秒を待つために最初の実行プローブの前にkubeletを教えてください。プローブ検出コマンドは、容器の中に猫を/ tmp /健康のコマンドを実行しています。コマンドが成功した場合、それは0を返し、kubeletは、コンテナが生きていると非常に健全であると結論します。それがゼロ以外の値を返す場合、kubeletは、コンテナを殺して、それを再起動します。

（2）それを実行します

[root@master ~]# kubectl apply -f liveness.yaml 

（3）の外観

[root@master ~]# kubectl get pod -w

責任、通常がある場合は、ファイルは、サービスが正常に動作しているかどうかを判断するためのプローブが存在するかどうかに応じてライブネスアクティビティ検出は、それはあなたが設定したポリシーのリブートポッドポッドに応じて動作します。

2.準備（高感度検出、検出準備）

使用シーンlivenessProbe ReadinessProbeプローブは時々アプリケーションは、このようなポッドがすでに実行しているとして、要求を受け入れることが一時的にできないことがあり、わずかに異なっているが、ないReadinessProbeが存在しない場合は、コンテナアプリケーション内で、この場合には、正常に起動していなかった、そしてKubernetesを考えますそれは要求を処理することができますが、今回は、私たちは、プログラムは、私はkubernetesそれは、その後、ReadinessProbeプローブを使用し派遣する要求をしたくないので成功し、ユーザの要求を受信していない起動しなかったことを知っています。
ReadinessProbeとlivenessProbeが同じ検出方法を使用しますが、ポッドの異なる処分することができ、ReadinessProbeはポッドIPです：ポートはlivenessProbeキル容器のに対し、再起動戦略ポッドのに応じて対応策を講じ決定に、エンドポイントがリストに対応するから削除します。
ReadinessProbeは準備ができていませんその後、kubernetesは、このポッドにはないトラフィックを転送しない場合容器は、準備ができているかどうかをプロービングします。
ReadinessProbeプローブlivenessProbeサポート幹部、HTTPGET、TCP検出モード、同じ構成が、livenessProbeフィールドReadinessProbe変更されているよう。

YAMLファイルの準備（1）の調製

[root@master ~]# vim readiness.yaml 
kind: Pod
apiVersion: v1
metadata:
  name: readiness
  labels:
    test: readiness
spec:
  restartPolicy: Never
  containers:
  - name: readiness
    image: busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/test; sleep 60; rm -rf /tmp/test; sleep 300
    readinessProbe:
      exec:
        command:
        - cat
        - /tmp/test
      initialDelaySeconds: 10
      periodSeconds: 5

（2）それを実行します

[root@master ~]# kubectl apply -f readiness.yaml 

（3）の外観

[root@master ~]# kubectl get pod -w

3.まとめ生存性の検出と即応

（1）ライブネス及び準備は、2つのヘルスチェック機構であり、成功を監視するかどうかを決定する、すなわち、戻り値はブートプロセスを決定するために、コンテナがゼロであり、同一のデフォルトの動作をとる2つのプローブをK8S。

（2）検出法の二種類のプローブ不良の動作点を除いて全く同じ構成。

ライブネス検出は容器の動作を再開するための戦略に基づいており、コンテナのほとんどが再起動されます。

準備が吸引されたコンテナが使用できないように設定され、サービスを受けていない要求が転送されます。

二つの検出方法（3）は、同時に存在することができ、独立した存在によって推奨されてもよいです。livensessで自己治癒を達成するために、かどうかを再起動するかを決定、コンテナがサービスを提供する準備ができているかどうかを判断するための準備を。

第二に、アプリケーションの検出

スケールの1.アプリケーション（膨張/収縮容量）。

YAMLファイルの準備（1）の調製

[root@master ~]# vim hcscal.yaml
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: web
spec:
  replicas: 3
  template: 
    metadata:
      labels:
        run: web
    spec:
      containers:
      - name: web
        image: httpd
        ports:
        - containerPort: 80
        readinessProbe:
          httpGet:
            scheme: HTTP   #探测的协议
            path: /healthy  #访问的目录
            port: 80
          initialDelaySeconds: 10
          periodSeconds: 5

---
kind: Service
apiVersion: v1
metadata:
  name: web-svc
spec:
  type: NodePort
  selector:
    run: web
  ports:
  - protocol: TCP
    port: 90
    targetPort: 80
    nodePort: 30321

設定ファイルで、httpdのイメージを使用して、periodSecondsフィールドの指定は、検出を実行するために、5秒ごとにkubelet前記ポッドを作成し、initialDelaySecondsフィールドは10秒kubelet遅延待機を指示し、コンテナで実行中のサービスにHTTP GETリクエストを送信するための検出方法、要求8080で/ healthz、より大きいか小さくないコードの200未満、400に等しい成功を示します。他のコードは失敗を示します。

（2）HTTPGET検出方法は、以下のオプションの制御フィールドを有します

ホスト：ホスト名が接続される、デフォルトポッドIPによって、ホストヘッダーのHTTPリクエストヘッドに設けられてもよいです。
スキーム：ホストのプロトコル接続は、デフォルトではHTTPです。
パス：サーバー上の訪問のhttp URI。
httpHeaders：カスタムHTTPリクエストヘッダ、HTTPヘッダを繰り返すことができます。
ポート：コンテナのポート番号または名前をアクセスします。

（3）それを実行します

[root@master ~]# kubectl apply -f readiness.yaml 

（4）の外観

[root@master ~]# kubectl get pod -w

[root@master ~]# kubectl get pod -o wide

[root@master ~]# kubectl get service -o wide

（5）それにアクセス

[root@master ~]# curl  10.244.1.21/healthy

（6）は、指定されたディレクトリにファイルを作成するために、ポッド

[root@master ~]# kubectl exec web-69d659f974-7s9bc touch /usr/local/apache2/htdocs/healthy

（7）の外観

[root@master ~]# kubectl get pod -w

更新処理2.

YAMLファイルの準備（1）の調製

[root@master ~]# vim app.v1.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: app
spec:
  replicas: 10
  template:
    metadata:
      labels:
        run: app
    spec:
      containers:
      - name: app
        image: busybox
        args:
        - /bin/sh
        - -c
        - sleep 10; touch /tmp/healthy; sleep 3000
        readinessProbe:
          exec:
            command:
            - cat
            - /tmp/healthy
          initialDelaySeconds: 10
          periodSeconds: 5

（2）について実行して、バージョン情報を記録

[root@master ~]# kubectl apply -f readiness.yaml --record 

ルック

[root@master ~]# kubectl rollout history deployment app 

（3）の外観

[root@master ~]# kubectl get pod -w

3.アップグレードビットの展開

YAMLファイルの準備（1）の調製

[root@master ~]# cp app.v1.yaml app.v2.yaml 

[root@master ~]# vim app.v2.yaml 

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: app
spec:
  replicas: 10
  template:
    metadata:
      labels:
        run: app
    spec:
      containers:
      - name: app
        image: busybox
        args:
        - /bin/sh
        - -c
        - sleep 3000        #修改命令
        readinessProbe:
          exec:
            command:
            - cat
            - /tmp/healthy
          initialDelaySeconds: 10
          periodSeconds: 5

（2）について実行して、バージョン情報を記録

[root@master ~]# kubectl apply -f readiness.yaml --record 

ルック

[root@master ~]# kubectl rollout history deployment app 

（3）の外観

[root@master ~]# kubectl get pod -w

再び展開をアップグレードする（4）外観

<1> YAMLファイルの準備状況を書きます

[root@master ~]# cp app.v1.yaml app.v3.yaml 

[root@master ~]# vim app.v2.yaml 

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: app
spec:
  replicas: 10
  template:
    metadata:
      labels:
        run: app
    spec:
      containers:
      - name: app
        image: busybox
        args:
        - /bin/sh
        - -c
        - sleep 3000        #修改命令

<2>について実行して、バージョン情報を記録

[root@master ~]# kubectl apply -f readiness.yaml --record 

ルック

[root@master ~]# kubectl rollout history deployment app 

<3>表情

[root@master ~]# kubectl get pod -w

4. v2のバージョンのロールバック

[root@master ~]# kubectl rollout undo deployment app --to-revision=2

ルック

[root@master ~]# kubectl get pod

YAMLファイルの準備（1）の調製

[root@master ~]# vim app.v2.yaml 
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: app
spec:
  strategy:
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 2
  replicas: 10
  template:
    metadata:
      labels:
        run: app
    spec:
      containers:
      - name: app
        image: busybox
        args:
        - /bin/sh
        - -c
        - sleep 3000
        readinessProbe:
          exec:
            command:
            - cat
            - /tmp/healthy
          initialDelaySeconds: 10
          periodSeconds: 5

パラメータ説明

minReadySeconds：

Kubernetes在等待设置的时间后才进行升级
如果没有设置该值，Kubernetes会假设该容器启动起来后就提供服务了
如果没有设置该值，在某些极端情况下可能会造成服务服务正常运行

maxSurge:

升级过程中最多可以比原先设置多出的POD数量
例如：maxSurage=1，replicas=5,则表示Kubernetes会先启动1一个新的Pod后才删掉一个旧的POD，整个升级过程中最多会有5+1个POD。

maxUnavaible:

升级过程中最多有多少个POD处于无法提供服务的状态
当maxSurge不为0时，该值也不能为0
例如：maxUnavaible=1，则表示Kubernetes整个升级过程中最多会有1个POD处于无法服务的状态。

（2） 运行一下并记录版本信息

[root@master ~]# kubectl apply -f app.v2.yaml --record 

查看一下

[root@master ~]# kubectl rollout history deployment app 

（3） 查看一下

[root@master ~]# kubectl get pod -w

三、小实验

1）写一个Deployment资源对象，要求2个副本，nginx镜像。使用Readiness探测，自定义文件/test是否存在，容器开启之后10秒开始探测，时间间隔为10秒。

（1）编写一个readiness的yaml文件

[root@master yaml]# vim nginx.yaml

kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: web
spec:
  replicas: 2
  template:
    metadata:
      labels:
        run: web
    spec:
      containers:
      - name: readiness
        image: 192.168.1.21:5000/nginx:v1
        readinessProbe:
          exec:
            command:
            - cat
            - /usr/share/nginx/html/test
          initialDelaySeconds: 10
          periodSeconds: 10

（2）运行一下并记录版本信息

[root@master ~]# kubectl apply -f nginx.yaml --record 

查看一下

[root@master ~]# kubectl rollout history deployment web 

（3）查看一下

[root@master ~]# kubectl get pod -w

2）在运行之后两个Pod里，进入一个Pod，创建文件/test。

[root@master yaml]# kubectl exec -it web-864c7cf7fc-gpxq4  /bin/bash
root@web-68444bff8-xm22z:/# touch /usr/share/nginx/html/test

查看一下

[root@master yaml]# kubectl get pod -w

3）创建一个Service资源对象，跟上述Deployment进行关联，运行之后，查看Service资源详细信息，确认EndPoint负载均衡后端Pod。

（1）编写service的yaml文件

[root@master yaml]# vim nginx-svc.yaml
kind: Service
apiVersion: v1
metadata:
  name: web-svc
spec:
  type: NodePort
  selector:
    run: web
  ports:
  - protocol: TCP
    port: 90
    targetPort: 80
    nodePort: 30321

（2）执行一下

[root@master yaml]# kubectl apply -f nginx-svc.yaml 

（3）给两个pod刚更改页面

查看一下pod

[root@master yaml]# kubectl get pod -o wide

更改页面

[root@master yaml]# kubectl exec -it  web-864c7cf7fc-gpxq4  /bin/bash
root@web-864c7cf7fc-gpxq4:/# echo "123">/usr/share/nginx/html/test
root@web-864c7cf7fc-gpxq4:/# exit

[root@master yaml]# kubectl exec -it  web-864c7cf7fc-pcrs9   /bin/bash
root@web-864c7cf7fc-pcrs9:/# echo "321">/usr/share/nginx/html/test
root@web-864c7cf7fc-pcrs9:/# exit

4）观察状态之后，尝试将另一个Pod也写入/test文件，然后再去查看SVC对应的EndPoint的负载均衡情况。

（1）查看一下service

[root@master yaml]# kubectl get service

（2）访问一下

[root@master ~]# curl 192.168.1.21:30321/test

5）通过httpGet的探测方式，重新运行一下deployment资源，总结对比一下这两种Readiness探测方式。

（1）修改deployment的yaml文件

[root@master yaml]# vim nginx.yaml 
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: web
spec:
  replicas: 2
  template:
    metadata:
      labels:
        run: web
    spec:
      containers:
      - name: readiness
        image: 192.168.1.21:5000/nginx:v1
        readinessProbe:
          httpGet:
            scheme: HTTP
            path: /usr/share/nginx/html/test
            port: 80
          initialDelaySeconds: 10
          periodSeconds: 10

（2）执行一下

[root@master yaml]# kubectl apply -f nginx.yaml 

（3）查看一下pod

[root@master yaml]# kubectl get pod -w

maxSurge：此参数控制滚动更新过程中，副本总数超过预期数的值。可以是整数，也可以是百分比，默认是1。所以现在是3台pod

（4）访问一下

[root@master yaml]# curl 192.168.1.21:30321/test

6）总结对比liveness和readiness探测的相同和不同之处，以及它们的使用场景。

<1>readiness和liveness的核心区别

实际上readiness 和liveness 就如同字面意思。readiness 就是意思是否可以访问，liveness就是是否存活。如果一个readiness 为fail 的后果是把这个pod 的所有service 的endpoint里面的改pod ip 删掉，意思就这个pod对应的所有service都不会把请求转到这pod来了。但是如果liveness 检查结果是fail就会直接kill container，当然如果你的restart policy 是always 会重启pod。

<2>什么样才叫readiness／liveness检测失败呢?

实际上k8s提供了3中检测手段，

http get 返回200-400算成功，别的算失败
tcp socket 你指定的tcp端口打开，比如能telnet 上
cmd exec 在容器中执行一个命令 推出返回0 算成功。
每中方式都可以定义在readiness 或者liveness 中。比如定义readiness 中http get 就是意思说如果我定义的这个path的http get 请求返回200-400以外的http code 就把我从所有有我的服务里面删了吧，如果定义在liveness里面就是把我kill 了。

<3>の準備の準備や使用環境

たとえば、HTTPサービスならば、あなたは私がコンテナを再起動したかった問題一度にアクセスしたいです。そして、あなたはライブネス検出手段を定義するHTTP GETです。問題がある場合一方、私はちょうどそれがここに聞かせてはいけないの上場廃止を要求したい、それが再起動させたくありません。コンフィギュレーションの準備で。

注、ライブネスない再起動ポッド、あなたが再起動ポリシー（再起動戦略）で制御再起動しますかポッド。

参考：
https://www.jianshu.com/p/16a375199cf2