資源限制
當(dāng)定義 Pod 時可以選擇性地為每個容器設(shè)定所需要的資源數(shù)量。 最常見的可設(shè)定資源是 CPU 和內(nèi)存大小，以及其他類型的資源。
當(dāng)為 Pod 中的容器指定了 request 資源時，代表容器運行所需的最小資源量，調(diào)度器就使用該信息來決定將 Pod 調(diào)度到哪個節(jié)點上。當(dāng)還為容器指定了 limit 資源時，kubelet 就會確保運行的容器不會使用超出所設(shè)的 limit 資源量。kubelet 還會為容器預(yù)留所設(shè)的 request 資源量， 供該容器使用。
如果 Pod 運行所在的節(jié)點具有足夠的可用資源，容器可以使用超出所設(shè)置的 request 資源量。不過，容器不可以使用超出所設(shè)置的 limit 資源量。
如果給容器設(shè)置了內(nèi)存的 limit 值，但未設(shè)置內(nèi)存的 request 值，Kubernetes 會自動為其設(shè)置與內(nèi)存 limit 相匹配的 request 值。 類似的，如果給容器設(shè)置了 CPU 的 limit 值但未設(shè)置 CPU 的 request 值，則 Kubernetes 自動為其設(shè)置 CPU 的 request 值 并使之與 CPU 的 limit 值匹配。
官網(wǎng)示例：
https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/
資源限制 總結(jié)
limit與request區(qū)別【重中之重】
spec.containers.resources.requests.cpu|memory ? ? 設(shè)置Pod容器創(chuàng)建時需要預(yù)留的資源量 ? ?容器應(yīng)用最低配置 <= requests <= limits
spec.containers.resources.limits.cpu|memory? ? ? ? ? ?設(shè)置Pod容器能夠使用的資源量上限，如果容器進程內(nèi)存使用量超過limits.memory會引發(fā)OOM資源單位?
CPU資源量單位： cpu個數(shù) ?1 ?2 ?0.1 ?0.5 ?0.25 ? ? 毫核 ?100m ? 250m ? 1000m ? 1500m
內(nèi)存資源量單位：整數(shù)（默認單位為字節(jié)） ? ? ?2的底數(shù)單位（Ki Mi Gi Ti） ? ?10的底數(shù)單位（K M G T）kubectl describe -n 命名空間 pod <pod名稱> 查看Pod中每個容器的資源量限制 kubectl describe node <node名稱> 查看Node節(jié)點中的每個Pod或總的資源限制使用情況
Pod 和 容器 的資源請求和限制
spec.containers[].resources.requests.cpu?? ??? ?//定義創(chuàng)建容器時預(yù)分配的CPU資源 spec.containers[].resources.requests.memory?? ??? ?//定義創(chuàng)建容器時預(yù)分配的內(nèi)存資源 spec.containers[].resources.limits.cpu?? ??? ??? ?//定義 cpu 的資源上限? spec.containers[].resources.limits.memory?? ??? ?//定義內(nèi)存的資源上限
CPU 資源單位
CPU 資源的 request 和 limit 以 cpu 為單位。Kubernetes 中的一個 cpu 相當(dāng)于1個 vCPU（1個超線程）。
Kubernetes 也支持帶小數(shù) CPU 的請求。spec.containers[].resources.requests.cpu 為 0.5 的容器能夠獲得一個 cpu 的一半（cpu中一個核的一半。多核需要乘以核數(shù)） CPU 資源（類似于Cgroup對CPU資源的時間分片）。表達式 0.1 等價于表達式 100m（毫核），表示每 1000 毫秒內(nèi)容器可以使用的 CPU 時間總量為 0.1*1000 毫秒。
Kubernetes 不允許設(shè)置精度小于 1m 的 CPU 資源。?內(nèi)存 資源單位?
內(nèi)存的 request 和 limit 以字節(jié)為單位?？梢砸哉麛?shù)表示，或者以10為底數(shù)的指數(shù)的單位（E、P、T、G、M、K）來表示， 或者以2為底數(shù)的指數(shù)的單位（Ei、Pi、Ti、Gi、Mi、Ki）來表示。
如：1KB=10^3=1000，1MB=10^6=1000000=1000KB，1GB=10^9=1000000000=1000MB
1KiB=2^10=1024，1MiB=2^20=1048576=1024KiB
示例1：
apiVersion: v1 kind: Pod metadata: ? name: frontend spec: ? containers: ? - name: app ? ? image: images.my-company.example/app:v4 ? ? env: #MySQL必須要有這個環(huán)境變量 并且內(nèi)存至少1G ? ? - 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 有兩個容器。每個容器的 request 值為 0.25 cpu 和 64MiB 內(nèi)存，每個容器的 limit 值為 0.5 cpu 和 128MiB 內(nèi)存。
那么可以認為該 Pod 的總的資源 request 為 0.5 cpu 和 128 MiB 內(nèi)存，總的資源 limit 為 1 cpu 和 256MiB 內(nèi)存。
MySQL需要的內(nèi)存至少1G，這里可能會報錯OOM不停重啟。實例2將修改內(nèi)存限制
示例2：cpu限制的簡便寫法，并放寬內(nèi)存限制
vim pod2.yaml apiVersion: v1 kind: Pod metadata: ? name: frontend 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: "abc123" ? ? resources: ? ? ? requests: ? ? ? ? memory: "512Mi" ? ? ? ? cpu: "0.5" ? ? ? limits: ? ? ? ? memory: "1Gi" ? ? ? ? cpu: "1"kubectl apply -f pod2.yaml kubectl describe pod frontendkubectl get pods -o wide NAME ? ? ? READY ? STATUS ? ?RESTARTS ? AGE ? IP ? ? ? ? ? NODE ? ? NOMINATED NODE ? READINESS GATES frontend ? 2/2 ? ? Running ? 5 ? ? ? ? ?15m ? 10.244.2.4 ? node02 ? <none> ? ? ? ? ? <none>kubectl describe nodes node02?? ??? ??? ??? ?#由于當(dāng)前虛擬機有2個CPU，所以Pod的CPU Limits一共占用了50% Namespace ? ? ? ? ? ? ? ? ?Name ? ? ? ? ? ? ? ? ? ? ? ? ? CPU Requests ?CPU Limits ?Memory Requests ?Memory Limits ?AGE ? --------- ? ? ? ? ? ? ? ? ?---- ? ? ? ? ? ? ? ? ? ? ? ? ? ------------ ?---------- ?--------------- ?------------- ?--- ? default ? ? ? ? ? ? ? ? ? ?frontend ? ? ? ? ? ? ? ? ? ? ? 500m (25%) ? ?1 (50%) ? ? 128Mi (3%) ? ? ? 256Mi (6%) ? ? 16m ? kube-system ? ? ? ? ? ? ? ?kube-flannel-ds-amd64-f4pbp ? ?100m (5%) ? ? 100m (5%) ? 50Mi (1%) ? ? ? ?50Mi (1%) ? ? ?19h ? kube-system ? ? ? ? ? ? ? ?kube-proxy-pj4wp ? ? ? ? ? ? ? 0 (0%) ? ? ? ?0 (0%) ? ? ?0 (0%) ? ? ? ? ? 0 (0%) ? ? ? ? 19h Allocated resources: ? (Total limits may be over 100 percent, i.e., overcommitted.) ? Resource ? ? ? ? ? Requests ? ?Limits ? -------- ? ? ? ? ? -------- ? ?------ ? cpu ? ? ? ? ? ? ? ?600m (30%) ?1100m (55%) ? memory ? ? ? ? ? ? 178Mi (4%) ?306Mi (7%) ? ephemeral-storage ?0 (0%) ? ? ?0 (0%)
重啟策略（restartPolicy）
當(dāng) Pod 中的容器退出時通過節(jié)點上的 kubelet 重啟容器。適用于 Pod 中的所有容器。
- Always：當(dāng)容器終止退出后，總是重啟容器，默認策略
- OnFailure：當(dāng)容器異常退出（退出狀態(tài)碼非0）時，重啟容器；正常退出則不重啟容器
- Never：當(dāng)容器終止退出，從不重啟容器。
#注意：K8S 中不支持重啟 Pod 資源，只有刪除重建。
? ? ? 在用 yaml 方式創(chuàng)建 Deployment 和 StatefulSet 類型時，restartPolicy 只能是 Always，kubectl run 創(chuàng)建 Pod 可以選擇 Always,OnFailure,Never 三種策略kubectl edit deployment nginx-deployment ...... ? restartPolicy: Always
//示例 命令每過30s退出，但是根據(jù)重啟策略默認always會不斷重啟
vim pod3.yaml apiVersion: v1 kind: Pod metadata: name: foo spec: containers: - name: busybox image: busybox args: - /bin/sh - -c - sleep 30; exit 3kubectl apply -f pod3.yaml//查看Pod狀態(tài)，等容器啟動后30秒后執(zhí)行exit退出進程進入error狀態(tài)，就會重啟次數(shù)加1
kubectl get pods -w NAME READY STATUS RESTARTS AGE foo 0/1 ContainerCreating 0 7s foo 1/1 Running 0 21s foo 0/1 Error 0 50s foo 1/1 Running 1 66s foo 0/1 Error 1 97s foo 0/1 CrashLoopBackOff 1 111s foo 1/1 Running 2 2m7s foo 0/1 Error 2 2m37s foo 0/1 CrashLoopBackOff 2 2m52s foo 1/1 Running 3 3m23s foo 0/1 Error 3 3m53s foo 0/1 CrashLoopBackOff 3 4m7s foo 1/1 Running 4 5m foo 0/1 Error 4 5m30s foo 0/1 CrashLoopBackOff 4 5m43s foo 1/1 Running 5 6m51s foo 0/1 Error 5 7m21s foo 0/1 CrashLoopBackOff 5 7m36s foo 1/1 Running 6 10m foo 0/1 Error 6 10mkubectl delete -f pod3.yaml?更改為從不重啟
vim pod3.yaml apiVersion: v1 kind: Pod metadata: ? name: foo spec: ? containers: ? - name: busybox ? ? image: busybox ? ? args: ? ? - /bin/sh ? ? - -c ? ? - sleep 30; exit 3 ? restartPolicy: Never#注意：跟container同一個級別
kubectl apply -f pod3.yaml//容器進入error狀態(tài)不會進行重啟
kubectl get pods -w
健康檢查：又稱為探針（Probe）
探針是由kubelet對容器執(zhí)行的定期診斷。
官網(wǎng)示例：
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
Pod 容器的 3 種探針（健康檢查）【重中之重】
- 存活探針（livenessProbe）：探測是否正常運行。如果探測失敗則kubelet殺掉容器（Pod容器會根據(jù)重啟策略決定是否重啟）
- 就緒探針（readinessProbe）：探測Pod是否進入就緒狀態(tài)（ready狀態(tài)欄1/1），并做好接收service請求的準備。如果探測失敗則Pod會變成未就緒狀態(tài)（ready狀態(tài)欄0/1），service資源會刪除所關(guān)聯(lián)的端點（endpoints），并不再轉(zhuǎn)發(fā)請求給就緒探測失敗的Pod
- 啟動探針（startupProbe）：探測容器內(nèi)的應(yīng)用是否啟動成功。在啟動探針探測成功之前，存活探針和就緒探針都會暫時處于禁用狀態(tài)，直到啟動探針探測成功
探針的 3 種探測方式
- exec：在command字段中指定在容器內(nèi)執(zhí)行的Linux命令來進行探測，如果命令返回碼為0則認為探測成功，如果返回碼為非0則認為探測失敗
- tcpSocket：向指定的Pod容器端口發(fā)送tcp連接請求，如果端口正確且tcp連接成功則認為探測成功，如果tcp連接失敗則認為探測失敗
- httpGet：向指定的Pod容器端口和URL路徑發(fā)送http get請求，如果http響應(yīng)狀態(tài)碼為2XX 3XX則認為探測成功，如果響應(yīng)狀態(tài)碼為4XX 5XX則認為探測失敗
探針參數(shù)
initialDelaySeconds：指定容器啟動后延遲幾秒開始探測
periodSeconds：每天探測的間隔時間（秒數(shù)）
failureThreshold：探測連續(xù)失敗幾次后判斷探測失敗
timeoutSeconds：指定探測超時等待時間（秒數(shù)）How to know the args probe have?
kubectl explain pod.spec.containers 查看有哪些探針 kubectl explain pod.spec.containers.livenessprobe #查看具體探針參數(shù)
//示例1：exec方式 根據(jù)命令行執(zhí)行結(jié)果判斷
apiVersion: v1 kind: Pod metadata: ? labels: ? ? test: liveness ? name: liveness-exec spec: ? containers: ? - name: liveness ? ? image: k8s.gcr.io/busybox ? ? args: ? ? - /bin/sh ? ? - -c #容器運行命令 創(chuàng)建文件夾 30秒后刪除。 ? ? - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 60 ? ? livenessProbe: ? ? ? exec: ? ? ? ? command: #探針命令，檢查文件夾是否存在。由于30s刪除，30s后存活探針失效，重啟容器 ? ? ? ? - cat ? ? ? ? - /tmp/healthy ? ? ? failureThreshold: 1 ? ? ? initialDelaySeconds: 5 ? ? ? periodSeconds: 5 initialDelaySeconds： 指定 kubelet 在執(zhí)行第一次探測前應(yīng)該等待5秒，即第一次探測是在容器啟動后的第6秒才開始執(zhí)行。默認是 0 秒，最小值是 0。 periodSeconds： 指定了 kubelet 應(yīng)該每 5 秒執(zhí)行一次存活探測。默認是 10 秒。最小值是 1。 failureThreshold: 當(dāng)探測失敗時，Kubernetes 將在放棄之前重試的次數(shù)。 存活探測情況下的放棄就意味著重新啟動容器。 就緒探測情況下的放棄 Pod 會被打上未就緒的標(biāo)簽。默認值是 3。最小值是 1。 timeoutSeconds：探測的超時后等待多少秒。默認值是 1 秒。最小值是 1。 （在 Kubernetes 1.20 版本之前，exec 探針會忽略 timeoutSeconds 探針會無限期地 持續(xù)運行，甚至可能超過所配置的限期，直到返回結(jié)果為止。）可以看到 Pod 中只有一個容器。kubelet 在執(zhí)行第一次探測前需要等待 5 秒，kubelet 會每 5 秒執(zhí)行一次存活探測。kubelet 在容器內(nèi)執(zhí)行命令 cat /tmp/healthy 來進行探測。如果命令執(zhí)行成功并且返回值為 0，kubelet 就會認為這個容器是健康存活的。 當(dāng)?shù)竭_第 31 秒時，這個命令返回非 0 值，kubelet 會殺死這個容器并重新啟動它。
.
編寫測試yaml文件（與上面那段原理無太大區(qū)別，命令格式稍作修改）
vim exec.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: 3kubectl create -f exec.yaml30秒后刪除文件，導(dǎo)致存活探針認為寄寄，重啟容器?
kubectl describe pods liveness-exec -w Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 5m13s default-scheduler Successfully assigned default/liveness-exec to node1 Normal Killing 2m17s (x3 over 4m35s) kubelet Container liveness-exec-container failed liveness probe, will be restarted Normal Pulled 107s (x4 over 5m13s) kubelet Container image "busybox" already present on machine Normal Created 107s (x4 over 5m13s) kubelet Created container liveness-exec-container Normal Started 107s (x4 over 5m13s) kubelet Started container liveness-exec-container Warning Unhealthy 5s (x13 over 4m41s) kubelet Liveness probe failed:kubectl get pods -w NAME READY STATUS RESTARTS AGE liveness-exec 1/1 Running 4 5m45s liveness-exec 1/1 Running 5 5m45s若容器是NGINX等，用創(chuàng)建文件再檢測的方法太蠢了，可以直接命令行檢測，指定必定存在的文件?（如index.html）
注意不要混淆，并不是一定通過檢測文件存在性，其本質(zhì)原理是根據(jù)命令行執(zhí)行結(jié)果返回值判斷。
示例2：httpGet方式
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 #原理為通過8080端口 發(fā)送http get請求 get /healthz 查看返回的狀態(tài)碼 ? ? ? ? port: 8080 ? ? ? ? httpHeaders: ? ? ? ? - name: Custom-Header ? ? ? ? ? value: Awesome ? ? ? initialDelaySeconds: 3 ? ? ? periodSeconds: 3在這個配置文件中，可以看到 Pod 也只有一個容器。initialDelaySeconds 字段告訴 kubelet 在執(zhí)行第一次探測前應(yīng)該等待 3 秒。periodSeconds 字段指定了 kubelet 每隔 3 秒執(zhí)行一次存活探測。kubelet 會向容器內(nèi)運行的服務(wù)（服務(wù)會監(jiān)聽 8080 端口）發(fā)送一個 HTTP GET 請求來執(zhí)行探測。如果服務(wù)器上 /healthz 路徑下的處理程序返回成功代碼，則 kubelet 認為容器是健康存活的。如果處理程序返回失敗代碼，則 kubelet 會殺死這個容器并且重新啟動它。
任何大于或等于 200 并且小于 400 的返回代碼標(biāo)示成功，其它返回代碼都標(biāo)示失敗。
編寫測試yaml文件
vim httpget.yaml apiVersion: v1 kind: Pod metadata: name: liveness-httpget namespace: default spec: containers: - name: liveness-httpget-container image: nginx imagePullPolicy: IfNotPresent ports: - name: http containerPort: 80 livenessProbe: httpGet: port: http path: /index.html initialDelaySeconds: 1 periodSeconds: 3 timeoutSeconds: 10
?? ? ?kubectl create -f httpget.yaml 創(chuàng)建podkubectl get pods -w #-w實時更新 NAME ? ? ? ? ? ? ? READY ? STATUS ? ?RESTARTS ? AGE liveness-httpget ? 1/1 ? ? Running ? 1 ? ? ? ? ?2m44s?再開個終端，執(zhí)行刪除
kubectl exec -it liveness-httpget -- rm -rf /usr/share/nginx/html/index.html -- 為免交互不進入容器執(zhí)行命令 去容器里刪除探針指向的主頁文件，這樣探針不通過，容器重啟
只會重啟一次，因為刪除了文件，容器重啟，根據(jù)鏡像又生成了這個文件。?
示例3：tcpSocket方式
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: #就緒探針，效果是node顯示notready，不會重啟容器 ? ? ? tcpSocket: ? ? ? ? port: 8080 #與8080端口 進行tcp三次握手 檢測 ? ? ? initialDelaySeconds: 5 ? ? ? periodSeconds: 10 ? ? livenessProbe: #存活探針，不通過重啟容器 ? ? ? tcpSocket: ? ? ? ? port: 8080 ? ? ? initialDelaySeconds: 15 ? ? ? periodSeconds: 20這個例子同時使用 readinessProbe 和 livenessProbe 探測。kubelet 會在容器啟動 5 秒后發(fā)送第一個 readinessProbe 探測。這會嘗試連接 goproxy 容器的 8080 端口。如果探測成功，kubelet 將繼續(xù)每隔 10 秒運行一次檢測。除了 readinessProbe 探測，這個配置包括了一個 livenessProbe 探測。kubelet 會在容器啟動 15 秒后進行第一次 livenessProbe 探測。就像 readinessProbe 探測一樣，會嘗試連接 goproxy 容器的 8080 端口。如果 livenessProbe 探測失敗，這個容器會被重新啟動。
編寫測試yaml?
vim tcpsocket.yaml apiVersion: v1 kind: Pod metadata: name: probe-tcp spec: containers: - name: nginx image: nginx livenessProbe: initialDelaySeconds: 5 timeoutSeconds: 1 tcpSocket: port: 8080 #監(jiān)聽8080口 但是由于NGINX提供80端口服務(wù)，所以存活探針會重啟容器 periodSeconds: 10 failureThreshold: 2kubectl create -f tcpsocket.yamlkubectl exec -it probe-tcp ?-- netstat -natp -- 為免交互不進入容器執(zhí)行命令 Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address ? ? ? ? ? Foreign Address ? ? ? ? State ? ? ? PID/Program name ? ? tcp ? ? ? ?0 ? ? ?0 0.0.0.0:80 ? ? ? ? ? ? ?0.0.0.0:* ? ? ? ? ? ? ? LISTEN ? ? ?1/nginx: master pro監(jiān)聽8080口 但是由于NGINX提供80端口服務(wù)，所以存活探針會重啟容器?
kubectl get pods -w NAME ? ? ? ?READY ? STATUS ? ?RESTARTS ? AGE probe-tcp ? 1/1 ? ? Running ? ? ? ? ? ? 0 ? ? ? ? ?1s probe-tcp ? 1/1 ? ? Running ? ? ? ? ? ? 1 ? ? ? ? ?25s ? ? ? #第一次是 init(5秒) + period(10秒) * 2 probe-tcp ? 1/1 ? ? Running ? ? ? ? ? ? 2 ? ? ? ? ?45s ? ? ? #第二次是 period(10秒) + period(10秒) ?重試了兩次 probe-tcp ? 1/1 ? ? Running ? ? ? ? ? ? 3 ? ? ? ? ?65s若要通過探針測試，將探針監(jiān)聽端口改為NGINX的80口，就不會在重啟容器。?
示例4：存活探針 就緒探針 啟動探針 合集
vim readiness-httpget.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 startupProbe: #啟動探針 /index2.html存在，才會將檢測權(quán)限交給 存活探針 就緒探針 httpGet: port: http path: /index2.html failureThreshold: 30 periodSeconds: 10 livenessProbe: #存活探針 /index.html存在，不會重啟 httpGet: port: http path: /index.html initialDelaySeconds: 1 periodSeconds: 3 timeoutSeconds: 10 readinessProbe: #就緒探針 /index1.html存在，才會ready httpGet: port: http path: /index1.html initialDelaySeconds: 1 periodSeconds: 3因為有啟動探針 應(yīng)用最多有5分鐘的（?failureThreshold * periodSeconds =30*10=300s ）的時間完成啟動
一旦成功一次，存活探針和就緒探針就會接管對容器的檢測
若啟動探針一直沒有成功，容器在300s后被殺死，并且根據(jù)重啟策略進行重啟。
根據(jù)配置文件創(chuàng)建pod資源kubectl create -f readiness-httpget.yaml
?啟動探針部分
kubectl describe pod readiness-httpget 查看錯誤詳細信息?目前是啟動探針出錯（啟動探針完成后才會把后續(xù)探測權(quán)限交給 存活和就緒探針）
進入容器，創(chuàng)建啟動探針需要的文件?
kubectl exec -it readiness-httpget -- touch /usr/share/nginx/html/index2.html -- 為免交互不進入容器執(zhí)行命令?啟動探針條件滿足，此時步進到就緒探針無文件
kubectl describe pod readiness-httpget 查看錯誤詳細信息
?就緒探針部分
?//readiness就緒探針探測失敗，無法進入READY狀態(tài)
kubectl get pods NAME ? ? ? ? ? ? ? ?READY ? STATUS ? ?RESTARTS ? AGE readiness-httpget ? 0/1 ? ? Running ? 0 ? ? ? ? ?18s進入容器，滿足就緒探針需求?
kubectl exec -it readiness-httpget sh cd /usr/share/nginx/html/ ls 50x.html ? ?index.html echo 123 > index1.html exit ········································ 或者免交互命令 kubectl exec -it readiness-httpget -- touch /usr/share/nginx/html/index1.html就緒探針滿足，pod就緒?
kubectl get pods NAME ? ? ? ? ? ? ? ?READY ? STATUS ? ?RESTARTS ? AGE readiness-httpget ? 1/1 ? ? Running ? 0 ? ? ? ? ?2m31s
存活探針部分
若此時再刪除存活探針指向的文件（http get不到index.html 容器重啟）
kubectl exec -it readiness-httpget -- rm -rf /usr/share/nginx/html/index.html -- 為免交互不進入容器執(zhí)行命令kubectl get pods -w NAME ? ? ? ? ? ? ? ?READY ? STATUS ? ?RESTARTS ? AGE readiness-httpget ? 1/1 ? ? Running ? 0 ? ? ? ? ?4m10s readiness-httpget ? 0/1 ? ? Running ? 1 ? ? ? ? ?4m15s
//示例5：同一pod內(nèi) 多容器就緒檢測 查看ready與service相關(guān)信息
vim readiness-myapp.yaml apiVersion: v1 kind: Pod metadata: name: myapp1 labels: app: myapp spec: containers: - name: myapp image: nginx ports: - name: http containerPort: 80 #三個一樣的容器，一樣的就緒探針和條件，測試多就緒探針顯示 readinessProbe: httpGet: port: 80 path: /index.html initialDelaySeconds: 5 periodSeconds: 5 timeoutSeconds: 10 --- apiVersion: v1 kind: Pod metadata: name: myapp2 labels: app: myapp spec: containers: - name: myapp image: nginx ports: - name: http containerPort: 80 readinessProbe: httpGet: port: 80 path: /index.html initialDelaySeconds: 5 periodSeconds: 5 timeoutSeconds: 10 --- apiVersion: v1 kind: Pod metadata: name: myapp3 labels: app: myapp spec: containers: - name: myapp image: nginx ports: - name: http containerPort: 80 readinessProbe: httpGet: port: 80 path: /index.html initialDelaySeconds: 5 periodSeconds: 5 timeoutSeconds: 10 --- apiVersion: v1 kind: Service metadata: name: myapp spec: selector: app: myapp type: ClusterIP ports: - name: http port: 80 targetPort: 80kubectl create -f readiness-myapp.yamlkubectl get pods,svc,endpoints -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod/myapp1 1/1 Running 0 66s 10.244.1.33 node1 <none> <none> pod/myapp2 1/1 Running 0 66s 10.244.2.34 node2 <none> <none> pod/myapp3 1/1 Running 0 66s 10.244.2.33 node2 <none> <none> NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 2d8h <none> service/myapp ClusterIP 10.111.198.14 <none> 80/TCP 66s app=myapp service/nginx-service666 NodePort 10.96.38.38 <none> 80:31537/TCP 6h2m app=nginx NAME ENDPOINTS AGE endpoints/kubernetes 192.168.80.101:6443 2d8h endpoints/myapp 10.244.1.33:80,10.244.2.33:80,10.244.2.34:80 66s endpoints/nginx-service666 <none> 6h2m刪除 myapp1 就緒探針指向的文件?
kubectl exec -it pod/myapp1 -- rm -rf /usr/share/nginx/html/index.html//readiness探測失敗，Pod 無法進入READY狀態(tài)，且端點控制器將從 endpoints 中剔除刪除該 Pod（myapp1 ） 的 IP 地址
kubectl get pods,svc,endpoints -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod/myapp1 0/1 Running 0 2m48s 10.244.1.33 node1 <none> <none> pod/myapp2 1/1 Running 0 2m48s 10.244.2.34 node2 <none> <none> pod/myapp3 1/1 Running 0 2m48s 10.244.2.33 node2 <none> <none> NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 2d8h <none> service/myapp ClusterIP 10.111.198.14 <none> 80/TCP 2m48s app=myapp service/nginx-service666 NodePort 10.96.38.38 <none> 80:31537/TCP 6h4m app=nginx NAME ENDPOINTS AGE endpoints/kubernetes 192.168.80.101:6443 2d8h endpoints/myapp 10.244.2.33:80,10.244.2.34:80 2m48s endpoints/nginx-service666 <none> 6h4m
啟動、退出動作
啟動 退出 動作，不像command一樣會把鏡像內(nèi)的默認命令覆蓋掉。
而是在容器啟動和結(jié)束時執(zhí)行。
Pod 應(yīng)用容器生命周期的啟動動作和退出動作
spec.containers.lifecycle.postStart ? 配置子字段 exec.command 設(shè)置 Pod 容器啟動時額外的命令操作
spec.containers.lifecycle.preStop ? ? 配置子字段 exec.command 設(shè)置 Pod 容器運行中被kubelet殺掉退出時所執(zhí)行的命令操作（不包含容器自行退出的情況）
vim post.yaml apiVersion: v1 kind: Pod metadata: name: lifecycle-demo spec: containers: - name: lifecycle-demo-container image: nginx lifecycle: #此為關(guān)鍵字段 postStart: #執(zhí)行完init所需要的內(nèi)容后創(chuàng)建容器，先執(zhí)行poststart exec: command: ["/bin/sh", "-c", "echo Hello from the postStart handler >> /var/log/nginx/message"] preStop: #在容器結(jié)束時候執(zhí)行prestop exec: command: ["/bin/sh", "-c", "echo Hello from the poststop handler >> /var/log/nginx/message"] volumeMounts: #由于容器結(jié)束，日志會隨一并消失，所以加上掛載卷，存放日志。 - name: message-log mountPath: /var/log/nginx/ readOnly: false #可讀可寫 initContainers: #init容器在普通容器之前執(zhí)行完畢，用于提供容器依賴項。所以第一個執(zhí)行。 - name: init-myservice 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 #不存在就創(chuàng)建kubectl apply -f post.yaml查看在哪個節(jié)點上?（因為雖然pod可以隨地查看，但是掛載的宿主機目錄在對應(yīng)宿主機上）
kubectl get pods -o wide NAME ? ? ? ? ? ? READY ? STATUS ? ?RESTARTS ? AGE ? ?IP ? ? ? ? ? ?NODE ? ? NOMINATED NODE ? READINESS GATES lifecycle-demo ? 1/1 ? ? Running ? 0 ? ? ? ? ?2m8s ? 10.244.2.28 ? node02 ? <none> ? ? ? ? ? <none>免交互查看容器內(nèi)輸出
kubectl exec -it lifecycle-demo -- cat /var/log/nginx/message Hello initContainers Hello from the postStart handler//在 node02 節(jié)點（宿主機）上查看
cd /data/volumes/nginx/log/ ls access.log ?error.log ?message cat message? Hello initContainers Hello from the postStart handler #由上可知，init Container先執(zhí)行，然后當(dāng)一個主容器啟動后，Kubernetes 將立即發(fā)送 postStart 事件。//刪除 pod 后，再在 node02 節(jié)點上（宿主機）查看
kubectl delete pod lifecycle-demo[root@node02 log]# cat message? Hello initContainers Hello from the postStart handler Hello from the poststop handler
#由上可知，當(dāng)在容器被終結(jié)之前， Kubernetes 將發(fā)送一個 preStop 事件。并且無論是kubectl delete結(jié)束pod（容器），還是由于存活探針不滿足導(dǎo)致kubelet將容器重啟（刪除），都不會影響prestop的執(zhí)行。
但是！如果是容器執(zhí)行完命令自行退出（無論容器內(nèi)執(zhí)行 exit 0 正常退出還是執(zhí)行 exit 3 異常退出），不會執(zhí)行prestop。文章來源：http://www.zghlxwxcb.cn/news/detail-646152.html
概括一下就是，只有在容器 運行時 被第三方 退出 才會執(zhí)行prestop。文章來源地址http://www.zghlxwxcb.cn/news/detail-646152.html
到了這里，關(guān)于kubernetes pod 資源限制 探針的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
