目錄
資源限制
官網(wǎng)示例：
Pod 和 容器 的資源請(qǐng)求和限制：
CPU 資源單位
內(nèi)存 資源單位?
示例1：
示例2：
重啟策略（restartPolicy）
1、Always
2、OnFailure
3、Never
示例
容器進(jìn)入error狀態(tài)不會(huì)進(jìn)行重啟
健康檢查：又稱為探針（Probe）?
探針的三種規(guī)則：
●livenessProbe?
●readinessProbe
●startupProbe（這個(gè)1.17版本增加的）
Probe支持三種檢查方法：
●exec
●tcpSocket
●httpGet
每次探測(cè)都將獲得以下三種結(jié)果之一
官網(wǎng)示例：
示例1：exec方式
示例2：httpGet方式
示例3：tcpSocket方式
示例4：就緒檢測(cè)
readiness探測(cè)失敗，無(wú)法進(jìn)入READY狀態(tài)
示例5：就緒檢測(cè)2
readiness探測(cè)失敗，Pod 無(wú)法進(jìn)入READY狀態(tài)，且端點(diǎn)控制器將從 endpoints 中剔除刪除該 Pod 的 IP 地址
啟動(dòng)、退出動(dòng)作
在 node02 節(jié)點(diǎn)上查看
刪除 pod 后，再在 node02 節(jié)點(diǎn)上查看
資源限制
當(dāng)定義 Pod 時(shí)可以選擇性地為每個(gè)容器設(shè)定所需要的資源數(shù)量。 最常見的可設(shè)定資源是 CPU 和內(nèi)存大小，以及其他類型的資源。
當(dāng)為 Pod 中的容器指定了 request 資源時(shí)，代表容器運(yùn)行所需的最小資源量，調(diào)度器就使用該信息來(lái)決定將 Pod 調(diào)度到哪個(gè)節(jié)點(diǎn)上。當(dāng)還為容器指定了 limit 資源時(shí)，kubelet 就會(huì)確保運(yùn)行的容器不會(huì)使用超出所設(shè)的 limit 資源量。kubelet 還會(huì)為容器預(yù)留所設(shè)的 request 資源量， 供該容器使用。
如果 Pod 運(yùn)行所在的節(jié)點(diǎn)具有足夠的可用資源，容器可以使用超出所設(shè)置的 request 資源量。不過(guò)，容器不可以使用超出所設(shè)置的 limit 資源量。
如果給容器設(shè)置了內(nèi)存的 limit 值，但未設(shè)置內(nèi)存的 request 值，Kubernetes 會(huì)自動(dòng)為其設(shè)置與內(nèi)存 limit 相匹配的 request 值。 類似的，如果給容器設(shè)置了 CPU 的 limit 值但未設(shè)置 CPU 的 request 值，則 Kubernetes 自動(dòng)為其設(shè)置 CPU 的 request 值 并使之與 CPU 的 limit 值匹配。
官網(wǎng)示例：
https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/
Pod 和 容器 的資源請(qǐng)求和限制：
spec.containers[].resources.requests.cpu?? ??? ?//定義創(chuàng)建容器時(shí)預(yù)分配的CPU資源
spec.containers[].resources.requests.memory?? ??? ?//定義創(chuàng)建容器時(shí)預(yù)分配的內(nèi)存資源
spec.containers[].resources.limits.cpu?? ??? ??? ? //定義 cpu 的資源上限?
spec.containers[].resources.limits.memory?? ??? ? //定義內(nèi)存的資源上限CPU 資源單位
CPU 資源的 request 和 limit 以 cpu 為單位。Kubernetes 中的一個(gè) cpu 相當(dāng)于1個(gè) vCPU（1個(gè)超線程）。
Kubernetes 也支持帶小數(shù) CPU 的請(qǐng)求。spec.containers[].resources.requests.cpu 為 0.5 的容器能夠獲得一個(gè) cpu 的一半 CPU 資源（類似于Cgroup對(duì)CPU資源的時(shí)間分片）。表達(dá)式 0.1 等價(jià)于表達(dá)式 100m（毫核），表示每 1000 毫秒內(nèi)容器可以使用的 CPU 時(shí)間總量為 0.1*1000 毫秒。
Kubernetes 不允許設(shè)置精度小于 1m 的 CPU 資源。?
內(nèi)存 資源單位?
內(nèi)存的 request 和 limit 以字節(jié)為單位?？梢砸哉麛?shù)表示，或者以10為底數(shù)的指數(shù)的單位（E、P、T、G、M、K）來(lái)表示， 或者以2為底數(shù)的指數(shù)的單位（Ei、Pi、Ti、Gi、Mi、Ki）來(lái)表示。
如：1KB=10^3=1000，1MB=10^6=1000000=1000KB，1GB=10^9=1000000000=1000MB
1KiB=2^10=1024，1MiB=2^20=1048576=1024KiB
PS：在買硬盤的時(shí)候，操作系統(tǒng)報(bào)的數(shù)量要比產(chǎn)品標(biāo)出或商家號(hào)稱的小一些，主要原因是標(biāo)出的是以 MB、GB為單位的，1GB 就是1,000,000,000Byte，而操作系統(tǒng)是以2進(jìn)制為處理單位的，因此檢查硬盤容量時(shí)是以MiB、GiB為單位，1GiB=2^30=1,073,741,824，相比較而言，1GiB要比1GB多出1,073,741,824-1,000,000,000=73,741,824Byte，所以檢測(cè)實(shí)際結(jié)果要比標(biāo)出的少一些。
示例1：
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 有兩個(gè)容器。每個(gè)容器的 request 值為 0.25 cpu 和 64MiB 內(nèi)存，每個(gè)容器的 limit 值為 0.5 cpu 和 128MiB 內(nèi)存。那么可以認(rèn)為該 Pod 的總的資源 request 為 0.5 cpu 和 128 MiB 內(nèi)存，總的資源 limit 為 1 cpu 和 256MiB 內(nèi)存。
示例2：
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)前虛擬機(jī)有2個(gè)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 中的容器退出時(shí)通過(guò)節(jié)點(diǎn)上的 kubelet 重啟容器。適用于 Pod 中的所有容器。
1、Always
當(dāng)容器終止退出后，總是重啟容器，默認(rèn)策略
2、OnFailure
當(dāng)容器異常退出（退出狀態(tài)碼非0）時(shí)，重啟容器；正常退出則不重啟容器
3、Never
當(dāng)容器終止退出，從不重啟容器。
注意：K8S 中不支持重啟 Pod 資源，只有刪除重建。
? ? ? 在用 yaml 方式創(chuàng)建 Deployment 和 StatefulSet 類型時(shí)，restartPolicy 只能是 Always，kubectl run 創(chuàng)建 Pod 可以選擇 Always,OnFailure,Never 三種策略
kubectl edit deployment nginx-deployment
......
? restartPolicy: Always示例
vim pod3.yaml
apiVersion: v1
kind: Pod
metadata:
? name: foo
spec:
? containers:
? - name: busybox
? ? image: busybox
? ? args:
? ? - /bin/sh
? ? - -c
? ? - sleep 30; exit 3
kubectl apply -f pod3.yaml查看Pod狀態(tài)，等容器啟動(dòng)后30秒后執(zhí)行exit退出進(jìn)程進(jìn)入error狀態(tài)，就會(huì)重啟次數(shù)加1
kubectl get pods
NAME ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?READY ? STATUS ? ? ? ? ? ? RESTARTS ? AGE
foo ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 1/1 ? ? Running ? ? ? ? ? ?1 ? ? ? ? ?50skubectl delete -f pod3.yamlvim 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同一個(gè)級(jí)別
kubectl apply -f pod3.yaml容器進(jìn)入error狀態(tài)不會(huì)進(jìn)行重啟
kubectl get pods -w健康檢查：又稱為探針（Probe）?
探針是由kubelet對(duì)容器執(zhí)行的定期診斷。
探針的三種規(guī)則：
●livenessProbe?
判斷容器是否正在運(yùn)行。如果探測(cè)失敗，則kubelet會(huì)殺死容器，并且容器將根據(jù) restartPolicy 來(lái)設(shè)置 Pod 狀態(tài)。 如果容器不提供存活探針，則默認(rèn)狀態(tài)為Success。
●readinessProbe
判斷容器是否準(zhǔn)備好接受請(qǐng)求。如果探測(cè)失敗，端點(diǎn)控制器將從與 Pod 匹配的所有 service endpoints 中剔除刪除該P(yáng)od的IP地址。 初始延遲之前的就緒狀態(tài)默認(rèn)為Failure。如果容器不提供就緒探針，則默認(rèn)狀態(tài)為Success。
●startupProbe（這個(gè)1.17版本增加的）
判斷容器內(nèi)的應(yīng)用程序是否已啟動(dòng)，主要針對(duì)于不能確定具體啟動(dòng)時(shí)間的應(yīng)用。如果配置了 startupProbe 探測(cè)，則在 startupProbe 狀態(tài)為 Success 之前，其他所有探針都處于無(wú)效狀態(tài)，直到它成功后其他探針才起作用。 如果 startupProbe 失敗，kubelet 將殺死容器，容器將根據(jù) restartPolicy 來(lái)重啟。如果容器沒(méi)有配置 startupProbe， 則默認(rèn)狀態(tài)為 Success。
#注：以上規(guī)則可以同時(shí)定義。在readinessProbe檢測(cè)成功之前，Pod的running狀態(tài)是不會(huì)變成ready狀態(tài)的。
Probe支持三種檢查方法：
●exec
在容器內(nèi)執(zhí)行指定命令。如果命令退出時(shí)返回碼為0則認(rèn)為診斷成功。
●tcpSocket
對(duì)指定端口上的容器的IP地址進(jìn)行TCP檢查（三次握手）。如果端口打開，則診斷被認(rèn)為是成功的。
●httpGet
對(duì)指定的端口和uri路徑上的容器的IP地址執(zhí)行HTTPGet請(qǐng)求。如果響應(yīng)的狀態(tài)碼大于等于200且小于400，則診斷被認(rèn)為是成功的
每次探測(cè)都將獲得以下三種結(jié)果之一
●成功（Success）：表示容器通過(guò)了檢測(cè)。
●失?。‵ailure）：表示容器未通過(guò)檢測(cè)。
●未知（Unknown）：表示檢測(cè)沒(méi)有正常進(jìn)行。
官網(wǎng)示例：
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
示例1：exec方式
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 60
? ? livenessProbe:
? ? ? exec:
? ? ? ? command:
? ? ? ? - cat
? ? ? ? - /tmp/healthy
? ? ? failureThreshold: 1
? ? ? initialDelaySeconds: 5
? ? ? periodSeconds: 5initialDelaySeconds：指定 kubelet 在執(zhí)行第一次探測(cè)前應(yīng)該等待5秒，即第一次探測(cè)是在容器啟動(dòng)后的第6秒才開始執(zhí)行。默認(rèn)是 0 秒，最小值是 0。
#periodSeconds：指定了 kubelet 應(yīng)該每 5 秒執(zhí)行一次存活探測(cè)。默認(rèn)是 10 秒。最小值是 1。
failureThreshold: 當(dāng)探測(cè)失敗時(shí)，Kubernetes 將在放棄之前重試的次數(shù)。 存活探測(cè)情況下的放棄就意味著重新啟動(dòng)容器。就緒探測(cè)情況下的放棄 Pod 會(huì)被打上未就緒的標(biāo)簽。默認(rèn)值是 3。最小值是 1。
timeoutSeconds：探測(cè)的超時(shí)后等待多少秒。默認(rèn)值是 1 秒。最小值是 1。（在 Kubernetes 1.20 版本之前，exec 探針會(huì)忽略 timeoutSeconds 探針會(huì)無(wú)限期地 持續(xù)運(yùn)行，甚至可能超過(guò)所配置的限期，直到返回結(jié)果為止。）
可以看到 Pod 中只有一個(gè)容器。kubelet 在執(zhí)行第一次探測(cè)前需要等待 5 秒，kubelet 會(huì)每 5 秒執(zhí)行一次存活探測(cè)。kubelet 在容器內(nèi)執(zhí)行命令 cat /tmp/healthy 來(lái)進(jìn)行探測(cè)。如果命令執(zhí)行成功并且返回值為 0，kubelet 就會(huì)認(rèn)為這個(gè)容器是健康存活的。 當(dāng)?shù)竭_(dá)第 31 秒時(shí)，這個(gè)命令返回非 0 值，kubelet 會(huì)殺死這個(gè)容器并重新啟動(dòng)它。
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: 3vim 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 get pods -w
NAME ? ? ? ? ? ? ? ?READY ? STATUS ? ?RESTARTS ? AGE
liveness-exec ? ? ? 1/1 ? ? Running ? 1 ? ? ? ? ?85s示例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
? ? ? ? port: 8080
? ? ? ? httpHeaders:
? ? ? ? - name: Custom-Header
? ? ? ? ? value: Awesome
? ? ? initialDelaySeconds: 3
? ? ? periodSeconds: 3在這個(gè)配置文件中，可以看到 Pod 也只有一個(gè)容器。initialDelaySeconds 字段告訴 kubelet 在執(zhí)行第一次探測(cè)前應(yīng)該等待 3 秒。periodSeconds 字段指定了 kubelet 每隔 3 秒執(zhí)行一次存活探測(cè)。kubelet 會(huì)向容器內(nèi)運(yùn)行的服務(wù)（服務(wù)會(huì)監(jiān)聽 8080 端口）發(fā)送一個(gè) HTTP GET 請(qǐng)求來(lái)執(zhí)行探測(cè)。如果服務(wù)器上 /healthz 路徑下的處理程序返回成功代碼，則 kubelet 認(rèn)為容器是健康存活的。如果處理程序返回失敗代碼，則 kubelet 會(huì)殺死這個(gè)容器并且重新啟動(dòng)它。
任何大于或等于 200 并且小于 400 的返回代碼標(biāo)示成功，其它返回代碼都標(biāo)示失敗。文章來(lái)源：http://www.zghlxwxcb.cn/news/detail-646623.html
vim httpget.yaml
apiVersion: v1
kind: Pod
metadata:
? name: liveness-httpget
? namespace: default
spec:
? containers:
? - name: liveness-httpget-container
? ? image: soscscs/myapp:v1
? ? imagePullPolicy: IfNotPresent
? ? ports:
? ? - name: http
? ? ? containerPort: 80
? ? livenessProbe:
? ? ? httpGet:
? ? ? ? port: http
? ? ? ? path: /index.html
? ? ? initialDelaySeconds: 1
? ? ? periodSeconds: 3
? ? ? timeoutSeconds: 10kubectl create -f httpget.yaml
kubectl exec -it liveness-httpget -- rm -rf /usr/share/nginx/html/index.htmlkubectl get pods
NAME ? ? ? ? ? ? ? READY ? STATUS ? ?RESTARTS ? AGE
liveness-httpget ? 1/1 ? ? Running ? 1 ? ? ? ? ?2m44s示例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:
? ? ? tcpSocket:
? ? ? ? port: 8080
? ? ? initialDelaySeconds: 5
? ? ? periodSeconds: 10
? ? livenessProbe:
? ? ? tcpSocket:
? ? ? ? port: 8080
? ? ? initialDelaySeconds: 15
? ? ? periodSeconds: 20這個(gè)例子同時(shí)使用 readinessProbe 和 livenessProbe 探測(cè)。kubelet 會(huì)在容器啟動(dòng) 5 秒后發(fā)送第一個(gè) readinessProbe 探測(cè)。這會(huì)嘗試連接 goproxy 容器的 8080 端口。如果探測(cè)成功，kubelet 將繼續(xù)每隔 10 秒運(yùn)行一次檢測(cè)。除了 readinessProbe 探測(cè)，這個(gè)配置包括了一個(gè) livenessProbe 探測(cè)。kubelet 會(huì)在容器啟動(dòng) 15 秒后進(jìn)行第一次 livenessProbe 探測(cè)。就像 readinessProbe 探測(cè)一樣，會(huì)嘗試連接 goproxy 容器的 8080 端口。如果 livenessProbe 探測(cè)失敗，這個(gè)容器會(huì)被重新啟動(dòng)。文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-646623.html
vim tcpsocket.yaml
apiVersion: v1
kind: Pod
metadata:
? name: probe-tcp
spec:
? containers:
? - name: nginx
? ? image: soscscs/myapp:v1
? ? livenessProbe:
? ? ? initialDelaySeconds: 5
? ? ? timeoutSeconds: 1
? ? ? tcpSocket:
? ? ? ? port: 8080
? ? ? periodSeconds: 10
? ? ? failureThreshold: 2kubectl create -f tcpsocket.yamlkubectl exec -it probe-tcp ?-- netstat -natp
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 prokubectl 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示例4：就緒檢測(cè)
vim readiness-httpget.yaml
apiVersion: v1
kind: Pod
metadata:
? name: readiness-httpget
? namespace: default
spec:
? containers:
? - name: readiness-httpget-container
? ? image: soscscs/myapp:v1
? ? 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: 10kubectl create -f readiness-httpget.yamlreadiness探測(cè)失敗，無(wú)法進(jìn)入READY狀態(tài)
kubectl get pods?
NAME ? ? ? ? ? ? ? ?READY ? STATUS ? ?RESTARTS ? AGE
readiness-httpget ? 0/1 ? ? Running ? 0 ? ? ? ? ?18skubectl exec -it readiness-httpget sh
?# cd /usr/share/nginx/html/
?# ls
50x.html ? ?index.html
?# echo 123 > index1.html?
?# exitkubectl get pods?
NAME ? ? ? ? ? ? ? ?READY ? STATUS ? ?RESTARTS ? AGE
readiness-httpget ? 1/1 ? ? Running ? 0 ? ? ? ? ?2m31skubectl exec -it readiness-httpget -- rm -rf /usr/share/nginx/html/index.htmlkubectl get pods -w
NAME ? ? ? ? ? ? ? ?READY ? STATUS ? ?RESTARTS ? AGE
readiness-httpget ? 1/1 ? ? Running ? 0 ? ? ? ? ?4m10s
readiness-httpget ? 0/1 ? ? Running ? 1 ? ? ? ? ?4m15s示例5：就緒檢測(cè)2
vim readiness-myapp.yaml
apiVersion: v1
kind: Pod
metadata:
? name: myapp1
? labels:
? ? ?app: myapp
spec:
? containers:
? - name: myapp
? ? image: soscscs/myapp:v1
? ? 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: soscscs/myapp:v1
? ? 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: soscscs/myapp:v1
? ? 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 ? ? ? ? ?3m42s ? 10.244.2.13 ? node02 ? <none> ? ? ? ? ? <none>
pod/myapp2 ? 1/1 ? ? Running ? 0 ? ? ? ? ?3m42s ? 10.244.1.15 ? node01 ? <none> ? ? ? ? ? <none>
pod/myapp3 ? 1/1 ? ? Running ? 0 ? ? ? ? ?3m42s ? 10.244.2.14 ? node02 ? <none> ? ? ? ? ? <none>
NAME ? ? ? ? ? ? ? ? TYPE ? ? ? ?CLUSTER-IP ? ? EXTERNAL-IP ? PORT(S) ? AGE ? ? SELECTOR
......
service/myapp ? ? ? ?ClusterIP ? 10.96.138.13 ? <none> ? ? ? ?80/TCP ? ?3m42s ? app=myapp
NAME ? ? ? ? ? ? ? ? ? ENDPOINTS ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?AGE
......
endpoints/myapp ? ? ? ?10.244.1.15:80,10.244.2.13:80,10.244.2.14:80 ? 3m42skubectl exec -it pod/myapp1 -- rm -rf /usr/share/nginx/html/index.htmlreadiness探測(cè)失敗，Pod 無(wú)法進(jìn)入READY狀態(tài)，且端點(diǎn)控制器將從 endpoints 中剔除刪除該 Pod 的 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 ? ? ? ? ?5m17s ? 10.244.2.13 ? node02 ? <none> ? ? ? ? ? <none>
pod/myapp2 ? 1/1 ? ? Running ? 0 ? ? ? ? ?5m17s ? 10.244.1.15 ? node01 ? <none> ? ? ? ? ? <none>
pod/myapp3 ? 1/1 ? ? Running ? 0 ? ? ? ? ?5m17s ? 10.244.2.14 ? node02 ? <none> ? ? ? ? ? <none>
NAME ? ? ? ? ? ? ? ? TYPE ? ? ? ?CLUSTER-IP ? ? EXTERNAL-IP ? PORT(S) ? AGE ? ? SELECTOR
......
service/myapp ? ? ? ?ClusterIP ? 10.96.138.13 ? <none> ? ? ? ?80/TCP ? ?5m17s ? app=myapp
NAME ? ? ? ? ? ? ? ? ? ENDPOINTS ? ? ? ? ? ? ? ? ? ? ? AGE
......
endpoints/myapp ? ? ? ?10.244.1.15:80,10.244.2.14:80 ? 5m17s啟動(dòng)、退出動(dòng)作
vim post.yaml
apiVersion: v1
kind: Pod
metadata:
? name: lifecycle-demo
spec:
? containers:
? - name: lifecycle-demo-container
? ? image: soscscs/myapp:v1
? ? lifecycle: ? #此為關(guān)鍵字段
? ? ? 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-myservice
? ? image: soscscs/myapp:v1
? ? 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: DirectoryOrCreatekubectl create -f post.yamlkubectl 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>kubectl exec -it lifecycle-demo -- cat /var/log/nginx/message
Hello initContainers
Hello from the postStart handler在 node02 節(jié)點(diǎn)上查看
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)一個(gè)主容器啟動(dòng)后，Kubernetes 將立即發(fā)送 postStart 事件。刪除 pod 后，再在 node02 節(jié)點(diǎn)上查看
kubectl delete pod lifecycle-democat message?
Hello initContainers
Hello from the postStart handler
Hello from the poststop handler
#由上可知，當(dāng)在容器被終結(jié)之前， Kubernetes 將發(fā)送一個(gè) preStop 事件。到了這里，關(guān)于【kubernetes】Pod進(jìn)階的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
