k8s之資源限制以及探針檢查

一、資源限制

1. 資源限制的使用

• 當定義Pod時可以選擇性地為每個容器設定所需要的資源數量。最常見的可設定資源是CPU和內存大小，以及其他類型的資源。

2. reuqest資源（請求）和limit資源（約束）

• 當為Pod中的容器指定了request資源時，調度器就使用該信息來決定將Pod調度到哪個節點上。當還為容器指定了limit資源時，kubelet就會確保運行的容器不會使用超出所設的limit資源量。kubelet還會為容器預留所設的request資源量，供該容器使用。
• 如果Pod所在的節點具有足夠的可用資源，容器可以使用超過所設置的request資源量。不過，容器不可以使用超出所設置的limit資源量。
• 如果給容器設置了內存的limit值，但未設置內存的request值，Kubernetes會自動為其設置與內存limit相匹配的request值。類似的，如果給容器設置了CPU的limit值但未設置CPU的request值，則Kubernetes自動為其設置CPU的request值，並使之與CPU的limit值匹配。

3. 官網示例

• https://kubernetes.io/zh/docs/concepts/configuration/manage-resources-containers/

4. Pod和容器的資源請求和限制

spec.containers[].resources.requests.cpu #定義創建容器時預分配的CPU資源 spec.containers[].resources.requests.memory #定義創建容器時預分配的內存資源 spec.containers[].resources.requests.hugepages-<size> #定義創建容器時預分配的巨頁資源 spec.containers[].resources.limits.cpu # 定義cpu的資源上限 spec.containers[].resources.limits.memory #定義內存的資源上限 spec.containers[].resources.limits.hugepages-<size>  # 定義巨頁的資源上限

5. 資源類型

CPU 和內存都是資源類型。每種資源類型具有其基本單位。 CPU 表達的是計算處理能力，其單位是 Kubernetes CPUs。 內存的單位是字節。 如果你使用的是 Kubernetes v1.14 或更高版本，則可以指定巨頁（Huge Page）資源。 巨頁是 Linux 特有的功能，節點內核在其中分配的內存塊比默認頁大小大得多。

例如，在默認頁面大小為 4KiB 的系統上，你可以指定約束 hugepages-2Mi: 80Mi。 如果容器嘗試分配 40 個 2MiB 大小的巨頁（總共 80 MiB ），則分配請求會失敗。

說明：

你不能過量使用 hugepages- * 資源。 這與 memory 和 cpu 資源不同。

6. CPU資源單位

• CPU資源的request和limit以cpu為單位。kubernetes中的一個cpu相當於1個vCPU（1個超線程）。
• Kubernetes也支持帶小數CPU的請求。spec.containers[].resources.requests.cpu為0.5的容器能夠獲得一個cpu的一半CPU資源（類似於cgroup對CPU資源的時間分片）。表達式0.1等價於表達式100m（毫核），表示每1000毫秒內容器可以使用的CPU時間總量為0.1*1000毫秒。

7. 內存資源單位

內存的request和limit以字節為單位。可以用證書表示，
也可以用以10為底數的指數的單位（E、P、T、G、M、K）來表示，
或者以2為底數的指數的單位（Ei、Pi、Ti、Gi、Mi、Ki）來表示。
如1KB=103=1000，1MB=106=1000000=1000KB，1GB=10^9=1000000000=1000MB
1KiB=210=1024，1MiB=220=1048576=1024KiB

PS：在買硬盤的時候，操作系統報的數量要比產品標出或商家號稱的小一些，主要原因是標出的是以MB、GB為單位的，1GB就是1,000,000,000Byte，而操作系統是以2進制為處理單位的，因此檢查硬盤容量時是以MiB、GiB為單位，1GiB=2^30=1,073,741,824Byte。相比較而言，1GiB要比1GB多出73,741,824Byte，所以檢測實際結果要比標出的少一些，單位越大，兩者的差值也就越大。

8. 官方文檔示例

apiVersion: v1 kind: Pod metadata: name: frontend spec: containers: - name: app image: images.my-company.example/app:v4 env: - name: MYSQL_ROOT_PASSWORD value: "password" resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m"
  - name: log-aggregator image: images.my-company.example/log-aggregator:v6 resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m"

此例子中 Pod 有兩個 Container。每個 Container 的請求為 0.25 cpu 和 64MiB（226 字節）內存， 每個容器的資源約束為 0.5 cpu 和 128MiB 內存。 你可以認為該 Pod 的資源請求為 0.5 cpu 和 128 MiB 內存，資源限制為 1 cpu 和 256MiB 內存。

9. 資源限制實操

（1）編寫yaml資源配置清單

apiVersion: v1 kind: Pod metadata: name: test1 spec: containers: - name: web image: nginx env: - name: WEB_ROOT_PASSWORD value: "password" resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m"
  - name: db image: mysql env: - name: MYSQL_ROOT_PASSWORD value: "password" resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m"

（2）釋放內存

• 由於mysql對於內存的使用要求比較高，因此需要先檢查內存的可用空間是否能夠滿足mysql的正常運行，若剩余內存不夠，可對其進行釋放操作。

①、查看內存

free -mh total used free shared buff/cache available Mem: 1.9G                  1.0G 86M 26M 870M 663M Swap: 0B 0B 0B

②、手動釋放緩存

echo [1\2\3] > /proc/sys/vm/drop_caches cat /proc/sys/vm/drop_caches 0echo 3 > /proc/sys/vm/drop_caches free -mh total used free shared buff/cache available Mem: 1.9G 968M 770M 26M 245M 754M Swap: 0B 0B 0B

0：0是系統默認值，默認情況下表示不釋放內存，由操作系統自動管理 1：釋放頁緩存 2：釋放dentries和inodes 3：釋放所有緩存

注意：
如果因為是應用有像內存泄露、溢出的問題，從swap的使用情況是可以比較快速可以判斷的，但free上面反而比較難查看。相反，如果在這個時候，我們告訴用戶，修改系統的一個值，“可以”釋放內存，free就大了。用戶會怎么想？不會覺得操作系統“有問題”嗎？所以說，既然核心是可以快速清空buffer或cache，也不難做到（這從上面的操作中可以明顯看到），但核心並沒有這樣做（默認值是0），我們就不應該隨便去改變它。

一般情況下，應用在系統上穩定運行了，free值也會保持在一個穩定值的，雖然看上去可能比較小。當發生內存不足、應用獲取不到可用內存、OOM錯誤等問題時，還是更應該去分析應用方面的原因，如用戶量太大導致內存不足、發生應用內存溢出等情況，否則，清空buffer，強制騰出free的大小，可能只是把問題給暫時屏蔽了。

 （3）創建資源

kubectl apply -f tets1.yaml kubectl apply -f test1.yaml pod/test1 created

（4）跟蹤查看 pod狀態

kubectl get pod -o wide -w NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES test1 0/2     ContainerCreating   0          4s    <none>   node01   <none>           <none> test1 2/2     Running             0          18s   10.244.1.55   node01   <none>           <none> test1 1/2     OOMKilled           0          21s   10.244.1.55   node01   <none>           <none> test1 2/2     Running             1          37s   10.244.1.55   node01   <none>           <none> test1 1/2     OOMKilled           1          40s   10.244.1.55   node01   <none>           <none> ......

OOM（OverOfMemory）表示服務的運行超過了我們所設定的約束值。
Ready:2/2，status:Running說明該pod已成功創建並運行，但運行過程中發生OOM問題被kubelet殺死並重新拉起新的pod。

（5）查看容器日志

kubectl logs test1 -c web

nginx啟動正常，接下來查看mysql日志

kubectl logs test1 -c mysql

（6）刪除pod

kubectl delete -f test1

（7）配置資源清單，提高mysql資源限制

vim test1.yaml apiVersion: v1 kind: Pod metadata: name: test1 spec: containers: - name: web image: nginx env: - name: WEB_ROOT_PASSWORD value: "password" resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m"
  - name: db image: mysql env: - name: MYSQL_ROOT_PASSWORD value: "password" resources: requests: memory: "512Mi" cpu: "0.5" limits: memory: "1024Mi" cpu: "1"

（8）再次創建資源

kubectl apply -f test1.yaml

（9）跟蹤查看 pod 狀態

get pod -o wide -w

（10）查看pod詳細信息

kubectl describe pod test1 ...... Containers: web: Container ID: docker://caf5bef54f878ebba32728b5e43743e36bbdf1457973f3ca130c98de5e1803d3
 Image: nginx ...... #nginx資源限制 Limits: cpu: 500m memory: 128Mi Requests: cpu: 250m memory: 64Mi #nginx環境變量 Environment: WEB_ROOT_PASSWORD: password Mounts: /var/run/secrets/kubernetes.io/serviceaccount from default-token-7lsdx (ro) db: Container ID: docker://2574f2bd02d9d7fc5bb0d2b74582b0bece3d8bd37d1d7ff3148ae8109df49367
 Image: mysql ...... #mysql資源限制 Limits: cpu: 1 memory: 1Gi Requests: cpu: 500m memory: 512Mi #mysql環境變量 Environment: MYSQL_ROOT_PASSWORD: password Mounts: /var/run/secrets/kubernetes.io/serviceaccount from default-token-7lsdx (ro) ...... #pod創建過程/事件記錄 Events: Type Reason Age From Message ----    ------     ----  ----               ------- Normal Scheduled 105s default-scheduler  Successfully assigned default/test1 to node01 Normal Pulling 104s kubelet, node01 Pulling image "nginx" Normal Pulled 103s kubelet, node01 Successfully pulled image "nginx" Normal Created 103s kubelet, node01 Created container web Normal Started 103s kubelet, node01 Started container web Normal Pulling 103s kubelet, node01 Pulling image "mysql" Normal Pulled 88s kubelet, node01 Successfully pulled image "mysql" Normal Created 88s kubelet, node01 Created container db Normal Started 88s kubelet, node01 Started container db

（11）查看node 資源使用

kubectl describe node node01

node01的配置為2C2G。
CPU Requests分析：
nginx的requests為250m，mysql的requests為500m，因此node01的CPU Requests為750m，在node01的兩個核中使用占比為37%。
CPU Limits分析：
nginx到的limit為500m，mysql的limit為1，因此node01到的CPU Limits為1500m，在node01的兩個核中使用占比為75%。
Memory Requests分析：
nginx的requests為64Mi，mysql的requests為512Mi，因此node01的內存Requests為576Mi，在node01的2G內存中使用占比為30%。
Memory Limits分析：
nginx的limits為128Mi，mysql的limit為1Gi，因此node01的1152Mi，在node01的2G內存中使用占比為61%。

二、健康檢查

1、健康檢查的定義

健康檢查又稱為探針（probe），是kubectl 對容器執行的定期診斷

2、探針的三種規則

（1）livenessProbe存活探針

• 判斷容器是否正在運行。如果探測失敗，則kubelet會殺死容器，並且容器將根據restartPolicy來設置Pod狀態，如果容器不提供存活探針，則默認狀態為Success。

（2）readinessProbe就緒探針

• 判斷容器是否准備好接受請求。如果探測失敗，端點控制器將從與Pod匹配的所有service endpoints中剔除刪除該Pod的IP地址。初始延遲之前的就緒狀態默認為Failure。如果容器不提供就緒探針，則默認狀態為Success。

（3）startupProbe啟動探針（1.17版本新增）

• 判斷容器內的應用程序是否已啟動，主要針對於不能確定具體啟動時間的應用。如果匹配了startupProbe探測，則在startupProbe狀態為Success之前，其他所有探針都處於無效狀態，直到它成功后其他探針才起作用。如果startupProbe失敗，kubelet將殺死容器，容器將根據restartPolicy來重啟。如果容器沒有配置startupProbe，則默認狀態為Success。

注：以上三種規則可同時定義。在readinessProbe檢測成功之前，Pod的running狀態是不會變成reasy狀態的。

3. Probe支持的三種檢測方法

（1）exec

• 在容器內執行執行命令，如果容器退出時返回碼為0則認為診斷成功。

（2）tcpSocket

• 對指定端口上的容器的IP地址進行TCP檢查（三次握手）。如果端口打開，則診斷被認為是成功的。

（3）httpGet

• 對指定的端口和路徑上的容器的IP地址執行httpGet請求。如果響應的狀態碼大於等於200且小於400（2xx和3xx），則診斷被認為是成功的。

4. 探測結果

每次探測都將獲得以下三種結果之一：
● 成功：容器通過了診斷
● 失敗：容器未通過診斷
● 未知：診斷失敗，因此不會采取任何行動

5. 官方文檔

文檔鏈接： https://kubernetes.io/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

6. exec方式

（1）官方示例1

apiVersion: v1 kind: Pod metadata: labels: test: liveness name: liveness-exec spec: containers: - name: liveness image: k8s.gcr.io/busybox args: - /bin/sh - -c - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600 livenessProbe: exec: command: - cat - /tmp/healthy initialDelaySeconds: 5 periodSeconds: 5

initalDeploySeconds：指定kubelet在執行第一次探測前應該等待5秒，即第一次探測是在容器啟動后的第6秒才開始執行。默認是0秒，最小值是0。
periodSeconds：指定了kubelet應該每5秒執行一次存活探測。默認是10秒，最小值是1
補充：
failureThreshold：當探測失敗時，Kubernetes將在放棄之前重試的次數。存活探測情況下的放棄就意味着重新啟動容器，就緒探測情況下的放棄Pod會被打上未就緒的標簽。默認值是3，最小值是1。
timeoutSeconds：探測的超時后等待多少秒。默認值是1秒，最小值是1。（在Kubernetes 1.20版本之前，exec探針會忽略timeoutSeconds，探針會無限期地持續運行，甚至可能超過所配置的限期，直到返回結果為止。）

在這個配置文件中，可以看到 Pod 中只有一個容器。 periodSeconds 字段指定了 kubelet 應該每 5 秒執行一次存活探測。 initialDelaySeconds 字段告訴 kubelet 在執行第一次探測前應該等待 5 秒。 kubelet 在容器內執行命令 cat /tmp/healthy 來進行探測。 如果命令執行成功並且返回值為 0，kubelet 就會認為這個容器是健康存活的。 如果這個命令返回非 0 值，kubelet 會殺死這個容器並重新啟動它。

（2）編寫yaml 資源配置清單

apiVersion: v1 kind: Pod metadata: name: liveness-exec namespace: default spec: containers: - name: liveness-exec-container image: busybox imagePullPolicy: IfNotPresent command: ["/bin/sh","-c","touch /tmp/live; sleep 30; rm -rf /tmp/live; sleep 3600"] livenessProbe: exec: command: ["test","-e","/tmp/live"] initialDelaySeconds: 1 periodSeconds: 3

在這個配置文件中，可以看到Pod只有一個容器。
容器中的command字段表示創建一個/tmp/live文件后休眠30秒，休眠結束后刪除該文件，並休眠10分鍾。
僅使用livenessProbe存活探針，並使用exec檢查方式，對/tmp/live文件進行存活檢測。
initialDelaySeconds字段表示kubelet在執行第一次探測前應該等待1秒。
periodSeconds字段表示kubelet每隔3秒執行一次存活探測。

（3）創建資源

kubectl create -f exec.yaml

（4）跟蹤查看pod 狀態

kubectl get pod -o wide -w

（5）查看pod 事件描述

kubectl describe pod liveness-exec

7、httpGet 方式

（1）官網示例

apiVersion: v1 kind: Pod metadata: labels: test: liveness name: liveness-http spec: containers: - name: liveness image: k8s.gcr.io/liveness args: - /server livenessProbe: httpGet: path: /healthz port: 8080 httpHeaders: - name: Custom-Header value: Awesome initialDelaySeconds: 3 periodSeconds: 3

在這個配置文件中，可以看到Pod只有一個容器。initialDealySeconds字段告訴kubelet再執行第一次探測前應該等待3秒。preiodSeconds字段指定了kubelet每隔3秒執行一次存活探測。kubelet會向容器內運行的服務（服務會監聽8080端口）發送一個認為容器是健康存活的。如果處理程序返回失敗代碼，則kubelet會殺死這個容器並且重新啟動它。
任何大於或等於200並且小於400的返回代碼標示成功，其他返回代碼都標示失敗。

（2）編寫 yaml 資源配置清單

apiVersion: v1 kind: Pod metadata: name: liveness-httpget namespace: default spec: containers: - name: liveness-httpget-container image: nginx imagePullPolicy: IfNotPresent ports: - name: nginx containerPort: 80 livenessProbe: httpGet: port: nginx path: /index.html initialDelaySeconds: 1 periodSeconds: 3 timeoutSeconds: 10

（3）創建資源

kubectl create -f httpget.yaml pod/liveness-httpget created kubectl get pod NAME READY STATUS RESTARTS AGE liveness-httpget   1/1     Running   0          6s

（4）刪除 pod index.html

kubectl exec -it liveness-httpget -- rm -rf /usr/share/nginx/html/index.html kubectl exec -it liveness-httpget -- rm -rf /usr/share/nginx/html/index.html

（5）查看 pod狀態

get pod -w kubectl get pod -w NAME READY STATUS RESTARTS AGE liveness-httpget   1/1     Running   0 5m35s liveness-httpget   1/1     Running   1          5m37s

（6）查看容器事件

kubectl describe pod liveness-httpget

重啟原因是HTTP探測得到的狀態返回碼是404，HTTP probe failed with statuscode: 404。
重啟完成后，不會再次重啟，因為重新拉取的鏡像中包含了index.html文件。

8、tcpSocker 方式

（1）官方示例

apiVersion: v1 kind: Pod metadata: name: goproxy labels: app: goproxy spec: containers: - name: goproxy image: k8s.gcr.io/goproxy:0.1 ports: - containerPort: 8080 readinessProbe: tcpSocket: port: 8080 initialDelaySeconds: 5 periodSeconds: 10 livenessProbe: tcpSocket: port: 8080 initialDelaySeconds: 15 periodSeconds: 20

這個例子同時使用readinessProbe和livenessProbe探測。kubelet會在容器啟動5秒后發送第一個readiness探測。這會嘗試連接goproxy容器的8080端口。如果探測成功，kubelet將繼續每隔10秒運行一次檢測。除了readinessProbe探測，這個配置包括了一個livenessProbe探測。kubelet會在容器啟動15秒后進行第一次livenessProbe探測。就像readinessProbe探測一樣，會嘗試連接goproxy容器的8080端口。如果livenessProbe探測失敗，這個容器會被重新啟動。

（2）編寫yaml資源配置清單

apiVersion: v1 kind: Pod metadata: name: liveness-tcpsocket spec: containers: - name: liveness-tcpsocket-container image: nginx livenessProbe: initialDelaySeconds: 5 timeoutSeconds: 1 tcpSocket: port: 8080 periodSeconds: 3

（3）創建資源

kubectl apply -f tcpsocket.yaml 

（4）跟蹤查看 pod狀態

kubectl get pod -w

• pod 異常重啟

（5）查看pod事件

kubectl describe pod liveness-tcpsocket

（6）修改tcpSocket端口

apiVersion: v1 kind: Pod metadata: name: liveness-tcpsocket spec: containers: - name: liveness-tcpsocket-container image: nginx livenessProbe: initialDelaySeconds: 5 timeoutSeconds: 1 tcpSocket: #修改端口為80 port: 80 periodSeconds: 3

（7）再次創建資源

kubectl apply -f tcpsocket.yaml

（8）跟蹤查看 pod狀態

kubectl get pod -o wide -w

（9）查看pod 事件

kubectl describe pod liveness-tcpsocket

9、readinessProbe就緒探針1

（1）編寫 yaml 資源配置清單

apiVersion: v1 kind: Pod metadata: name: readiness-httpget namespace: default spec: containers: - name: readiness-httpget-container image: nginx imagePullPolicy: IfNotPresent ports: - name: http containerPort: 80 readinessProbe: httpGet: port: 80 #注意，這里設置個錯誤地址 path: /index1.html initialDelaySeconds: 1 periodSeconds: 3 livenessProbe: httpGet: port: http path: /index.html initialDelaySeconds: 1 periodSeconds: 3 timeoutSeconds: 10

（2）創建資源

kubectl apply -f readiness-httpget.yaml

（3）查看pod 狀態

kubectl get pod

（4）查看pod 事件

kubectl describe pod readiness-httpget

（5）查看日志

kubectl logs readiness-httpget

（6）為容器創建 index.html

kubectl exec -it readiness-httpget -- touch /usr/share/nginx/html/index1.html

（7）查看容器狀態

kubectl get pod

10. readinessProbe就緒探針2

（1）編寫yaml 資源配置清單

apiVersion: v1 kind: Pod metadata: name: nginx1 labels: app: nginx spec: containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent ports: - name: http containerPort: 80 readinessProbe: httpGet: port: http path: /index.html initialDelaySeconds: 5 periodSeconds: 5 timeoutSeconds: 10
--- apiVersion: v1 kind: Pod metadata: name: nginx2 labels: app: nginx spec: containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent ports: - name: http containerPort: 80 readinessProbe: httpGet: port: http path: /index.html initialDelaySeconds: 5 periodSeconds: 5 timeoutSeconds: 10
--- apiVersion: v1 kind: Pod metadata: name: nginx3 labels: app: nginx spec: containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent ports: - name: http containerPort: 80 readinessProbe: httpGet: port: http path: /index.html initialDelaySeconds: 5 periodSeconds: 5 timeoutSeconds: 10
--- apiVersion: v1 kind: Service metadata: name: nginx-svc spec: #service通過selector綁定到nginx集群中 selector: app: nginx type: ClusterIP ports: - name: http port: 80 targetPort: 80

（2）創建資源

kubectl apply -f readiness-multi-nginx.yaml

（3）查看 pod，service 狀態

kubectl get pod,svc -o wide

（4）刪除 nginx中的 index.html

kubectl exec -it nginx1 -- rm -rf /usr/share/nginx/html/index.html

（5）查看pod 狀態

kubectl get pod -o wide -w

（6）查看pod 事件

kubectl describe pod nginx

（7）查看service 詳情

kubectl describe svc nginx-svc

（8）查看終端

kubectl get endpoints

三、啟動、退出動作

1、編寫 yaml 資源配置清單

apiVersion: v1 kind: Pod metadata: name: lifecycle-test spec: containers: - name: lifecycle-test-container image: nginx lifecycle: postStart: exec: command: ["/bin/sh","-c","echo Hello from the postStart handler >> /var/log/nginx/message"] preStop: exec: command: ["/bin/sh","-c","echo Hello from the postStop handler >> /var/log/nginx/message"] volumeMounts: - name: message-log mountPath: /var/log/nginx/ readOnly: false initContainers: - name: init-nginx image: nginx command: ["/bin/sh","-c","echo 'Hello initContainers' >> /var/log/nginx/message"] volumeMounts: - name: message-log mountPath: /var/log/nginx/ readOnly: false volumes: - name: message-log hostPath: path: /data/volumes/nginx/log/ type: DirectoryOrCreate

2、創建資源

kubectl apply -f post.yaml

3、跟蹤查看pod 狀態

kubectl get pod -o wide -w

4、查看 pod 事件

kubectl describe po lifecycle-test

5、查看容器日志

kubectl exec -it lifecycle-test -- cat /var/log/nginx/message

6、關閉容器后查看節點掛載文件

kubectl delete -f post.yaml

7、重新創建資源，查看容器日志

kubectl apply -f post.yaml

四、總結

1. 探針

探針分為3種

• livenessProbe（存活探針）∶判斷容器是否正常運行，如果失敗則殺掉容器（不是pod），再根據重啟策略是否重啟容器
• readinessProbe（就緒探針）∶判斷容器是否能夠進入ready狀態，探針失敗則進入noready狀態，並從service的endpoints中剔除此容器
• startupProbe∶判斷容器內的應用是否啟動成功，在success狀態前，其它探針都處於無效狀態

2. 檢查方式

檢查方式分為3種

• exec∶使用 command 字段設置命令，在容器中執行此命令，如果命令返回狀態碼為0，則認為探測成功
• httpget∶通過訪問指定端口和url路徑執行http get訪問。如果返回的http狀態碼為大於等於200且小於400則認為成功
• tcpsocket∶通過tcp連接pod（IP）和指定端口，如果端口無誤且tcp連接成功，則認為探測成功

3. 常用的探針可選參數

常用的探針可選參數有4個

• initialDelaySeconds∶ 容器啟動多少秒后開始執行探測
• periodSeconds∶探測的周期頻率，每多少秒執行一次探測
• failureThreshold∶探測失敗后，允許再試幾次
• timeoutSeconds ∶ 探測等待超時的時間