//資源限制
當(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/
//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 資源（類似于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
舉例PS：在買硬盤的時候，操作系統(tǒng)報的數(shù)量要比產(chǎn)品標(biāo)出或商家號稱的小一些，主要原因是標(biāo)出的是以 MB、GB為單位的，1GB 就是1,000,000,000Byte，而操作系統(tǒng)是以2進制為處理單位的，因此檢查硬盤容量時是以MiB、GiB為單位，1GiB=2^30=1,073,741,824，相比較而言，1GiB要比1GB多出1,073,741,824-1,000,000,000=73,741,824Byte，所以檢測實際結(jié)果要比標(biāo)出的少一些。
https://kubernetes.io/zh-cn/docs/concepts/configuration/manage-resources-containers/
示例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 有兩個容器。每個容器的 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)存。
示例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" 128
cpu: "0.5"
limits:
memory: "1Gi" 256
cpu: "1"
#根據(jù)提供的 pod2.yaml 文件中的配置信息，創(chuàng)建或更新一個 Pod 對象
kubectl apply -f pod2.yaml
#獲取有關(guān)名為 "frontend" 的 Pod 的詳細信息
kubectl describe pod frontend
#查看pods的詳細信息
kubectl get pods -o wide
#獲取有關(guān)名為 "node01" 的節(jié)點的詳細信息
kubectl describe nodes node01
top 按下1
查看cpu個數(shù)：
cat /proc/cpuinfo | grep processor
總結(jié)：
了解資源限制（cpu內(nèi)存）
pod 容器資源的限制
spec.container.resource.request.cpu/memory #創(chuàng)建pod容器時需要預(yù)留的資源 舉例
0.5 500m（0.5cpu 500毫核）
pod容器資源的上限
spec.container.resource.limits.cpu/memory#pod容器能夠 使用的資源的上限MI GI（2為底數(shù)）
M G（10為底數(shù)）
kubectl descrbe pod/node 名稱 查看pod或者node 資源使用情況
-----健康檢查：又稱為探針（Probe）
探針是由kubelet對容器執(zhí)行的定期診斷。
探針的三種規(guī)則：
●livenessProbe ：判斷容器是否正在運行。如果探測失敗，則kubelet會殺死容器，并且容器將根據(jù) restartPolicy 來設(shè)置 Pod 狀態(tài)。 如果容器不提供存活探針，則默認狀態(tài)為Success。
●readinessProbe ：判斷容器是否準(zhǔn)備好接受請求。如果探測失敗，端點控制器將從與 Pod 匹配的所有 service 址endpoints 中剔除刪除該Pod的IP地。 初始延遲之前的就緒狀態(tài)默認為Failure。如果容器不提供就緒探針，則默認狀態(tài)為Success。
●startupProbe（這個1.17版本增加的）：判斷容器內(nèi)的應(yīng)用程序是否已啟動，主要針對于不能確定具體啟動時間的應(yīng)用。如果配置了 startupProbe 探測，在則在 startupProbe 狀態(tài)為 Success 之前，其他所有探針都處于無效狀態(tài)，直到它成功后其他探針才起作用。 如果 startupProbe 失敗，kubelet 將殺死容器，容器將根據(jù) restartPolicy 來重啟。如果容器沒有配置 startupProbe， 則默認狀態(tài)為 Success。
#注：以上規(guī)則可以同時定義。在readinessProbe檢測成功之前，Pod的running狀態(tài)是不會變成ready狀態(tài)的。
Probe支持三種檢查方法：
●exec ：在容器內(nèi)執(zhí)行指定命令。如果命令退出時返回碼為0則認為診斷成功。
●tcpSocket ：對指定端口上的容器的IP地址進行TCP檢查（三次握手）。如果端口打開，則診斷被認為是成功的。
●httpGet ：對指定的端口和路徑上的容器的IP地址執(zhí)行HTTPGet請求。如果響應(yīng)的狀態(tài)碼大于等于200且小于400，則診斷被認為是成功的
每次探測都將獲得以下三種結(jié)果之一：
●成功：容器通過了診斷。
●失?。喝萜魑赐ㄟ^診斷。
●未知：診斷失敗，因此不會采取任何行動
官網(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: 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 會殺死這個容器并重新啟動它。
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: 3
kubectl create -f exec.yaml
kubectl describe pods liveness-exec
#獲取當(dāng)前運行的Pod的列表，并實時監(jiān)視它們的狀態(tài)。
kubectl get pods -w
//示例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
在這個配置文件中，可以看到 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)示失敗。
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: 10
kubectl create -f httpget.yaml
kubectl get pod -owide
#獲取當(dāng)前運行的Pod的列表，并顯示更詳細的信息。
通過運行這個命令，您將獲得一個包含所有Pod的表格，其中包括每個Pod的名稱、所屬命名空間、狀態(tài)、重啟次數(shù)、IP地址、節(jié)點名稱和容器運行時等更詳細的信息。
訪問：curl 10.244.1.6/index.html
kubectl exec -it liveness-httpget -- rm -rf /usr/share/nginx/html/index.html
或者：
kubectl exec -it liveness-httpget sh #進入到 "liveness-httpget" Pod 的容器中，并打開一個交互式的Shell會話
cd /usr/share/nginx/html/
rm -rf index.html
kubectl get pods
#刪除后 看見重啟后又恢復(fù)正常，相當(dāng)于重新恢復(fù)
//示例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
這個例子同時使用 readinessProbe 和 livenessProbe 探測。kubelet 會在容器啟動 5 秒后發(fā)送第一個 readinessProbe 探測。這會嘗試連接 goproxy 容器的 8080 端口。如果探測成功，kubelet 將繼續(xù)每隔 10 秒運行一次檢測。除了 readinessProbe 探測，這個配置包括了一個 livenessProbe 探測。kubelet 會在容器啟動 15 秒后進行第一次 livenessProbe 探測。就像 readinessProbe 探測一樣，會嘗試連接 goproxy 容器的 8080 端口。如果 livenessProbe 探測失敗，這個容器會被重新啟動。
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: 2
kubectl create -f tcpsocket.yaml
kubectl exec -it probe-tcp -- netstat -natp
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
文章來源：http://www.zghlxwxcb.cn/news/detail-737104.html
總結(jié)：文章來源地址http://www.zghlxwxcb.cn/news/detail-737104.html
pod 容器資源的限制
spec.container.resource.request.cpu/memory #創(chuàng)建pod容器時需要預(yù)留的資源 舉例
0.5 500m（0.5cpu 500毫核）
pod容器資源的上限
spec.container.resource.limits.cpu/memory#pod容器能夠 使用的資源的上限MI GI（2為底數(shù)）
M G（10為底數(shù)）
kubectl descrbe pod/node 名稱 查看pod或者node 資源使用情況
探針（健康檢查） 存活 就緒 啟動
存活探針(livenessProbe)：判斷容器是否正常運行，如果探測失敗則殺掉容器（不是pod）,容器會根據(jù)容器策略決定是否重啟。
就緒探針(readinessProbe)：判斷pod是能夠進入ready狀態(tài)，做好就緒請求的準(zhǔn)備：
如果探測失敗就會進入notready狀態(tài)并且service資源的endpoints中剔除，service將不會把請求轉(zhuǎn)發(fā)給這個pod。
啟動探針(startupProbe)：判斷容器是否會成功，在探測成功狀態(tài)為success之前，其他探針都會處于失效狀態(tài)。
三種探測方式：
exec：通過command設(shè)置執(zhí)行在容器內(nèi)執(zhí)行的linux命令來探測，如果返回碼為0，則為探測成功.
httpget：通過http get請求指定的容器端口和url路徑，如果返回狀態(tài)為>=200且<400(2xx 3xx),則為探測成功。
tcpsocket:通過指定的端口發(fā)送tcp連接，如果端口無誤，且三次握手成功（tcp連接成功），則認為探測成功。
到了這里，關(guān)于k8s---pod進階的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
