背景

1，之前我們的yaml檔案裡面有就緒探針。

2，探針是檢測一個檔案是否生成，生成了說明服務正常。

3，現在要加一個檢測，也是一個檔案是否存在並且不為空。

4，只有兩個條件同時滿足了 服務才算正常。然後就可以給外部提供服務了。

一、k8s的探針

1，K8s的探針，其實就是一種檢測預設是否滿足一種條件，然後做出相應的動作。

2，比如檢測容器是否正常，服務是否正常，是一種提前做出反應的一種手段機制。

3，容器的啟動和服務的狀態是我們最關心的。

4， 存活探針：檢測容器是否啟動存活

就緒探針：檢測服務是否正常，不正常之前是unready，不加入endport。

啟動探針：設定了啟動探針，則禁止所有的其他探針，知道他成功為止。

二、探針的探測方式

1，exec，命令式探測，命令或者指令碼，返回非0為失敗。

2，HTTP請求介面，任何大於或等於 200 並且小於 400 的返回程式碼標示成功，其它返回程式碼都標示失敗。

3，TCP連結檢測，建立連線則為正常。

三、exec command 多個檢測條件


1，其實我們開發的需求還是非常的明確的，就是多加一個檢測條件。

2，如果檢測的檔案存在且不為空，那麼這個Pod就不讓提供服務。

3.1 分析

1，不讓pod提供服務，那麼只有就緒探針滿足。

2，我去檢查了一下我們的yaml檔案，裡面的就緒探針是有東西的。

3，那麼久只能在原先的基礎上面加。

3.2 原始的探針

其實就是檢測了一下這個檔案存不存在。

      readinessProbe:

          exec:

            command:

            - test

            - -f

            - /var/www/html/.env

          initialDelaySeconds: 2

          periodSeconds: 2

          timeoutSeconds: 2

          failureThreshold: 15

3.3 加上另一個檢測條件

1，那麼只要這個命令執行最後的返回值為0，那麼這個探針就是成功的

2，如果/tmp/database_migrate_error.log檔案存在且不為空，那麼就會執行ceshi命令，

這個命令根本就沒有，所以肯定會失敗。所以返回非0，所以這個容器就會一直處於unready狀態。

3，這樣就滿足了開發的需求。容器不提供服務。

        readinessProbe:

          exec:

            command:

            - /bin/sh

            - -c

            - test -f /var/www/html/.env && if [ -s /tmp/database_migrate_error.log ]; then ceshi; fi

          initialDelaySeconds: 2

          periodSeconds: 2

          timeoutSeconds: 2

          failureThreshold: 15

四、總結

1，首先我這篇隨筆只是記錄了一個點，探針的exec 多個檢測條件。

2，關於k8s整個探針的隨筆我後期會寫一篇單獨的。

3，附上官網地址：https://kubernetes.io/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes

寫的不好，請多多指教：https://www.cnblogs.com/fanfanfanlichun/