一、資源限制
1、資源限制的概念
當(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 資源量， 供該容器使用。
request就是預(yù)留值
如果 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/
2、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)存的資源上限
3、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 資源。
4、內(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)出的少一些。
?
示例1：
apiVersion: v1
kind: Pod
metadata:
name: pod-resources
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
resources: # 資源配額
limits: # 限制資源（上限）
cpu: "2" # CPU限制，單位是core數(shù)
memory: "10Gi" # 內(nèi)存限制
requests: # 請求資源（下限）
cpu: "1" # CPU限制，單位是core數(shù)
memory: "10Mi" # 內(nèi)存限制
#以上是可以正常創(chuàng)建pod的，然后再將requests的最小內(nèi)存限制改為10Gi，再創(chuàng)建pod，查看是否創(chuàng)建成功
#發(fā)現(xiàn)是無法創(chuàng)建成功的，因為requests最小請求量不僅需要滿足容器內(nèi)部的應(yīng)用啟動大小， 也需要在當(dāng)前node節(jié)點上能劃分出該設(shè)定的資源的。不然資源無法請求成功到，容器也無法運行。
kubectl apply -f pod-resources.yaml
kubectl get pods -n dev
kubectl describe pod pod-resources -n dev
#查看詳細(xì)信息kubectl logs pod-resources -c nginx
#查看對象的容器日志信息
此例子中的 Pod 有兩個容器。每個容器的 request 值為 0.25 cpu 和 64MiB 內(nèi)存，每個容器的 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：
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 create -f pod-resource2.yaml
kubectl get pods -owide
kubectl describe pods frontend
kubectl describe nodes node02
二：健康檢查：又稱為探針（Probe）?
探針是由kubelet對容器執(zhí)行的定期診斷。
1、探針的三種規(guī)則：
●存活探針（livenessProbe） ：判斷容器是否正在運行。如果探測失敗，則kubelet會殺死容器，并且容器將根據(jù)容器策略來決定是否重啟。 如果容器不提供存活探針，則默認(rèn)狀態(tài)為Success。
●就緒探針（readinessProbe） ：判斷容器是否準(zhǔn)備好接受請求。如果探測失敗，就會加入notready狀態(tài)，并且service資源的endpoints中剔除，service將不會把訪問請求轉(zhuǎn)發(fā)給這個pod
●啟動探針（startupProbe）（這個1.17版本增加的）：判斷容器內(nèi)的應(yīng)用程序是否已啟動，在探測成功轉(zhuǎn)換為suuccess之前，其他探針都會處于失效狀態(tài)。
#注：以上規(guī)則可以同時定義。在readinessProbe檢測成功之前，Pod的running狀態(tài)是不會變成ready狀態(tài)的。
2、Probe支持三種檢查方法：
●exec ：在容器內(nèi)執(zhí)行指定命令。如果命令退出時返回碼為0則認(rèn)為診斷成功。
●tcpSocket ：對指定端口上的容器的IP地址進行TCP檢查（三次握手）。如果端口打開，則診斷被認(rèn)為是成功的。
●httpGet ：對指定的端口和路徑上的容器的IP地址執(zhí)行HTTPGet請求。如果響應(yīng)的狀態(tài)碼大于等于200且小于400，則診斷被認(rèn)為是成功的。
每次探測都將獲得以下三種結(jié)果之一：
●成功：容器通過了診斷。
●失?。喝萜魑赐ㄟ^診斷。
●未知：診斷失敗，因此不會采取任何行動
官網(wǎng)示例：
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
?
示例1：exec方式
apiVersion: v1
kind: Pod
metadata:
name: pod-liveness-exec
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
ports:
- name: nginx-port
containerPort: 80
livenessProbe:
exec:
command: ["/bin/cat","/tmp/hello.txt"] # 執(zhí)行一個查看文件的命令
kubectl create -f pod-liveness-exec.yaml
#創(chuàng)建podkubectl describe pods pod-liveness-exec -n dev
#查看pod詳情kubectl get pods pod-liveness-exec -n dev
#查看pod的狀態(tài)//以上進行探測的時候，會探測失敗，所以就導(dǎo)致pod不停的重啟，后面將command命令中的執(zhí)行命令換成可執(zhí)行的正常命令即可。
#initialDelaySeconds：指定 kubelet 在執(zhí)行第一次探測前應(yīng)該等待5秒，即第一次探測是在容器啟動后的第6秒才開始執(zhí)行。默認(rèn)是 0 秒，最小值是 0。
#periodSeconds：指定了 kubelet 應(yīng)該每 5 秒執(zhí)行一次存活探測。默認(rèn)是 10 秒。最小值是 1。
#failureThreshold: 當(dāng)探測失敗時，Kubernetes 將在放棄之前重試的次數(shù)。 存活探測情況下的放棄就意味著重新啟動容器。就緒探測情況下的放棄 Pod 會被打上未就緒的標(biāo)簽。默認(rèn)值是 3。最小值是 1。
#timeoutSeconds：探測的超時后等待多少秒。默認(rèn)值是 1 秒。最小值是 1。（在 Kubernetes 1.20 版本之前，exec 探針會忽略 timeoutSeconds 探針會無限期地 持續(xù)運行，甚至可能超過所配置的限期，直到返回結(jié)果為止。）
可以看到 Pod 中只有一個容器。kubelet 在執(zhí)行第一次探測前需要
示例2：httpGet方式
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-exec
namespace: dev
spec:
containers:
- name: liveness
image: busybox
imagePullPolicy: IfNotPresent
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
------------------------------------------------------------
failureThreshold: # 當(dāng)探測失敗是，k8s將在放棄之前重試次數(shù)。存活探測情況下的放棄就意味著重新啟動。就緒性探測情況下放棄Pod 會被打傷未就緒的標(biāo)簽，默認(rèn)值是3，最小值是1。
(簡單理解:就是探測的失敗次數(shù),允許連續(xù)探測幾次)
initialDelaySeconds: #指定kubelet在執(zhí)行第一次探測前應(yīng)該等待的時間，也就就是第一次探測的時間初始化結(jié)束后的第1秒，初始化時間默認(rèn)0秒，最小值0秒。
(簡單理解:就是每次的第一次探測前需要等待的時間，如果探測多次，不用等待)
periodSeconds: #指定了kubelet 應(yīng)該多久時間執(zhí)行一次探測，默認(rèn)10秒，最小值是1秒。
timeoutSeconds: #探測的超時后等待多少秒，默認(rèn)值是1秒，最小值是1秒。(在kubernetes 1.20版本之前，exec探針會忽略此事件，探針會無限期的持續(xù)運行，升值可能超過所配置的限期，知道返回結(jié)果為止)
下面進行創(chuàng)建pod，觀察探測結(jié)果
kubectl create -f pod-liveness2.yaml
#創(chuàng)建podkubectl get pods -n dev -w?
#提前時實監(jiān)控一個pod
示例3：tcpSocket方式
apiVersion: v1
kind: Pod
metadata:
name: pod-liveness-tcpsocket
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
ports:
- name: nginx-port
containerPort: 80
livenessProbe:
tcpSocket:
port: 8080 # 嘗試訪問8080端口
kubectl create -f pod-liveness-tcpsocket.yaml
#創(chuàng)建podkubectl get pods pod-liveness-tcpsocket -n dev
#查看容器狀態(tài)kubectl describe pods pod-liveness-tcpsocket -n dev
#查看容器的詳細(xì)狀態(tài)//觀察上面的信息，發(fā)現(xiàn)嘗試訪問8080端口，但是失敗了
//稍微一會之后，再觀察pod信息，就可看到RESTART不再是0 ，而是一直增長。表示pod在重啟
#當(dāng)然接下來，可以修改一個可以訪問的端口，比如80，正常訪問后，活性檢測就正常。
?
文章來源：http://www.zghlxwxcb.cn/news/detail-738907.html
文章來源地址http://www.zghlxwxcb.cn/news/detail-738907.html
到了這里，關(guān)于【k8s】pod進階的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
