k8s集群中pod的容器资源限制和三种探针
例如:在买硬盘的时候,操作系统报的数量要比产品标出或商家号称的小一些,主要原因是标出的是以 MB、GB为单位的,1GB 就是1,000,000,000Byte,而操作系统是以2进制为处理单位的,因此检查硬盘容量时是以MiB、GiB为单位,1GiB=2^30=1,073,741,824,相比较而言,1GiB要比1GB多出1,073,741,824-1,000,000,000=73,741,824By
一、资源限制
总结:
requests表示创建pod时预留的资源,limits表示pod能够使用资源的最大值。requests值可以被超,limits值不能超过,如果是内存使用超过limits会触发oom然后杀掉进程,如果是cpu超过limits会压缩cpu的使用率。
官网示例如下:
1.1Pod 和 容器的资源请求和限制
spec.containers[].resources.requests.cpu #定义创建容器时预分配的CPU资源
spec.containers[].resources.requests.memory #定义创建容器时预分配的内存资源
spec.containers[].resources.limits.cpu #定义 cpu 的资源上限
spec.containers[].resources.limits.memory #定义内存的资源上限
spec.containers[].resources.limits.hugepages-<size>
spec.containers[].resources.requests.hugepages-<size>
1.2Kubernetes 中的资源单位
1.2.1CPU 资源单位
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 毫秒。
Kubernetes 不允许设置精度小于 1m 的 CPU 资源。
1.2.2内存 资源单位
内存的 request 和 limit 以字节为单位。可以以整数表示,或者以10为底数的指数的单位(E、P、T、G、M、K)来表示, 或者以2为底数的指数的单位(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
例如:在买硬盘的时候,操作系统报的数量要比产品标出或商家号称的小一些,主要原因是标出的是以 MB、GB为单位的,1GB 就是1,000,000,000Byte,而操作系统是以2进制为处理单位的,因此检查硬盘容量时是以MiB、GiB为单位,1GiB=2^30=1,073,741,824,相比较而言,1GiB要比1GB多出1,073,741,824-1,000,000,000=73,741,824Byte,所以检测实际结果要比标出的少一些。
cpu的单位可以是核个数如1.25,0.5等,可以是毫核如500m,1250m
memory的单位可以是128M或128Mi (分别是1000k=1M或1024Ki=1Mi)
1.3容器资源示例
官方文档
https://kubernetes.io/zh-cn/docs/concepts/configuration/manage-resources-containers/
以下 Pod 有两个容器。每个容器的请求为 0.25 CPU 和 64MiB(226 字节)内存, 每个容器的资源限制为 0.5 CPU 和 128MiB 内存。 你可以认为该 Pod 的资源请求为 0.5 CPU 和 128 MiB 内存,资源限制为 1 CPU 和 256MiB 内存
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"
1.4部署容器资源限制
mkdir /opt/pod/
cd /opt/pod/
apiVersion: v1
kind: Pod
metadata:
name: zzz-web-db
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: "64Mi"
cpu: "0.25"
limits:
memory: "128Mi"
cpu: "500m"
可以看到状态是OOMKilled、表示资源不足、需要修改资源
OOMKilled:资源不足被杀死
kubectl logs zzz-web-db -c db
然后进入修改配置
现在状态正常,running状态,创建成功
查看pod的详细信息
kubectl describe pod zzz-web-db
kubectl get pods -owide
看到调度到了node01上面,我们可以去查看详细信息,如下图
kubectl describe nodes
#查看资源占用多少
预分配:request
Pod 和 容器 的资源请求和限制:
spec.containers[].resources.requests.cpu #定义创建容器时预分配的CPU资源
spec.containers[].resources.requests.memory # 定义创建容器时预分配的内存资源#创建pod容器时需要预留你的资源量 示例:0.5 500m 内存 MI、GI(2为底的)MG(10为底的)
上限:limits 内存超过limits大小,就会报omm内存资源不足的错误
spec.containers[].resources.limits.cpu #定义 cpu 的资源上限
spec.containers[].resources.limits.memory #定义内存的资源上限#pod容器能够使用资源量的一个上限 示例 :4Gi内存上限 (不允许超过上限值)
kubectl describe 名称
#查看pod或者查看node资源使情况
k8s中的应用服务质量
可以用查看pod的详细信息
qos优先级:
二、健康检查:又称为探针(Probe)⭐⭐⭐⭐⭐
健康检查:又称为探针(Probe)
探针是由kubelet对容器执行的定期诊断
2.1探针的三种规则
总结:
不提供存活探针,默认为success,表示如果没有存活探针的情况下,都是认为探针成功正常的
在就绪探针中,判断容器是否准备好接受请求,表示,pod是否准备好接受客户端和通过service转发来的请求
先启动启动探针------随后启动存活探针或者就绪探针
2.2Probe支持三种检查方法
exec :在容器内执行指定命令。如果命令退出时返回码为0则认为诊断成功。
tcpSocket :对指定端口上的容器的IP地址进行TCP检查(三次握手)。如果端口打开,则诊断被认为是成功的。
httpGet :对指定的端口和路径上的容器的IP地址执行HTTPGet请求。如果响应的状态码大于等于200且小于400,则诊断被认为是成功的
建议使用httpget和tcpsocket
2.3每次探测都将获得以下三种结果之一
- 成功:容器通过了诊断。
- 失败:容器未通过诊断。
- 未知:诊断失败,因此不会采取任何行动
官网示例:
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
三、验证存活探针三大健康检查的方式
官网示例: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 在执行第一次探测前应该等待5秒,即第一次探测是在容器启动后的第6秒才开始执行。默认是 0 秒,最小值是 0。
#periodSeconds:指定了 kubelet 应该每 5 秒执行一次存活探测。默认是 10 秒。最小值是 1。
#failureThreshold: 当探测失败时,Kubernetes 将在放弃之前重试的次数。 存活探测情况下的放弃就意味着重新启动容器。就绪探测情况下的放弃 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。
#timeoutSeconds:探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。(在 Kubernetes 1.20 版本之前,exec 探针会忽略 timeoutSeconds 探针会无限期地 持续运行,甚至可能超过所配置的限期,直到返回结果为止。)
在这个配置文件中,可以看到 Pod 中只有一个 Container。 periodSeconds 字段指定了 kubelet 应该每 5 秒执行一次存活探测。 initialDelaySeconds 字段告诉 kubelet 在执行第一次探测前应该等待 5 秒。 kubelet 在容器内执行命令 cat /tmp/healthy 来进行探测。 如果命令执行成功并且返回值为 0,kubelet 就会认为这个容器是健康存活的。 当到达第 31 秒时,这个命令返回非 0 值,kubelet 会杀死这个容器并重新启动它
随后自己写一个例子:
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-exec
spec:
containers:
- name: liveness
image: busybox
imagePullPolicy: IfNotPresent
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 10; rm -rf /tmp/healthy; sleep 15
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
failureThreshold: 2
initialDelaySeconds: 5
periodSeconds: 5
kubectl apply -f exec.yaml
kubectl get pod -w
随后,去查看pod的详细信息,当82秒时检测存活探针失败,kubelet便会删除pod,随后重启pod
kubectl describe pod liveness-exec
3.2httpget健康检查方式(必不可少的时port+path路径)
可以通过检测是否端口没有开启或者path路径下面的html页面是否存在 检验httpget
示例: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 在执行第一次探测前应该等待 3 秒,则第4秒开始。periodSeconds 字段指定了 kubelet 每隔 3 秒执行一次存活探测。kubelet 会向容器内运行的服务(服务会监听 8080 端口)发送一个 HTTP GET 请求来执行探测。如果服务器上 /healthz 路径下的处理程序返回成功代码,则 kubelet 认为容器是健康存活的。如果处理程序返回失败代码,则 kubelet 会杀死这个容器并且重新启动它。
任何大于或等于 200 并且小于 400 的返回代码标示成功,其它返回代码都标示失败。
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 describe pod liveness-httpget
这里的重启 不是停止容器再次重启,而是删除容器 再次启动!!!
3.3tcpsocket健康检查方式 指定端口号
示例: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 秒后发送第一个 readinessProbe 探测。这会尝试连接 goproxy 容器的 8080 端口。如果探测成功,kubelet 将继续每隔 10 秒运行一次检测。除了 readinessProbe 探测,这个配置包括了一个 livenessProbe 探测。kubelet 会在容器启动 15 秒后进行第一次 livenessProbe 探测。就像 readinessProbe 探测一样,会尝试连接 goproxy 容器的 8080 端口。如果 livenessProbe 探测失败,这个容器会被重新启动。
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 apply -f tcpsocket.yaml
kubectl exec -it probe-tcp -- netstat -natp
kubectl describe pod probe-tcp #查看pod详细信息
重启原因:因为nginx的端口是80,而在yaml文件里面设置的tcpsocket的检测端口是8080 ,检测不到因此kubectl会杀死容器,随后重启。
四、就绪探针
4.1就绪探针1
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: 10
kubectl apply -f readiness-httpget.yaml
kubectl get pods
出现0/1 running 表示其中一个pod无法接受请求,svc要在endpoints删除未请求的ip地址
kubectl describe pod readiness-httpget
kubectl exec -it readiness-httpget sh
cd /usr/share/nginx/html/
echo "qin yu nian2" > index1.html
kubectl exec -it readiness-httpget -- rm -rf /usr/share/nginx/html/index.html
kubectl get pods -w
完成启动探针成功以后、就绪和存活探针才会生效
就绪探针与存活探针 是在启动探针探测成功以后才会生效
4.2就绪检测2
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: 80
kubectl apply -f readiness-myapp.yaml
kubectl get pod -owide -w
kubectl get pods,svc,endpoints -owide
删除页面,看效果
kubectl exec -it myapp1 -- rm -rf /usr/share/nginx/html/index.html
kubectl get svc,pod,endpoints -owide
readiness探测失败,Pod 无法进入READY状态,且端点控制器将从 endpoints 中剔除删除该 Pod 的 IP 地址
kubectl get pods -owide -w
恢复页面,查看内容
4.3启动、退出动作
poststart 启动动作
prestop 推出动作
vim demo-pod02.yaml
apiVersion: v1
kind: Pod
metadata:
name: lifecycle-demo
spec:
containers:
- name: lifecycle-demo-container
image: soscscs/myapp:v1
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-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: DirectoryOrCreate
kubectl apply -f demo-pod02.yaml
kubectl get pods -owide
kubectl exec -it lifecycle-demo -- cat /var/log/nginx/message
在 node02 节点上查看
#由上可知,init Container先执行,然后当一个主容器启动后,Kubernetes 将立即发送 postStart 事件。
删除 pod 后,再在 node02 节点上查看
kubectl delete pod lifecycle-demo
node02操作
cd /data/volumes/nginx/log/
cat message
#由上可知,当在容器被终结之前, Kubernetes 将发送一个 preStop 事件。
4.4验证启动探针、 就绪探针、存活探针的顺序
vim demo-pod03.yaml
apiVersion: v1
kind: Pod
metadata:
labels:
test: demo1
name: demo1
spec:
containers:
- name: nginx
image: soscscs/myapp:v1
ports:
- containerPort: 80
name: http
#设置存活探针,探测pod容器的运行状态,一旦探测失败,那么就会通过kubelet杀掉容器
livenessProbe:
httpGet: #采用httpGet的方式 会像podip的指定端口发送http GET请求
port: http
path: /index.html #做http健康检查的页面
failureThreshold: 2 #表示连续探测失败2次才为探测失败
initialDelaySeconds: 2 #表示初始等待2秒后再才是启动存活探针
periodSeconds: 8 #表示探测周期为8秒
#设置就绪探针,探测pod是否处于就绪状态,如果说探测失败则为未就绪状态,service会将其从关联的pod中删除,请求也不转发给该pod
readinessProbe:
httpGet: #采用httpGet的方式 会像podip的指定端口发送http GET请求
port: http
path: /index.html #做http健康检查的页面
failureThreshold: 2 #表示连续探测失败2次才为探测失败
initialDelaySeconds: 2 #表示初始等待2秒后再才是启动存活探针
periodSeconds: 10 #表示探测周期为10秒
#启动探针,为了探测容器应用是否处于运行状态,只有启动探针探测成功以后,就绪探针和存活探针才有效
startupProbe:
httpGet: #采用httpGet的方式 会像podip的指定端口发送http GET请求
port: http
path: /index1.html #做http健康检查的页面
failureThreshold: 3 #表示连续探测失败3次才为探测失败
initialDelaySeconds: 2 #表示初始等待2秒后再才是启动存活探针
periodSeconds: 15 #表示探测周期为15秒
kubectl apply -f demo-pod03.yaml
kubectl describe pod demo1
kubectl get pods -owide -w
查看日志
可验证 就绪探针与存活探针 是在启动探针探测成功以后才会生效,启动探针探测成功之后,不会再运行,接下来存活探针和就绪探针同时开始运行。
4.5k8s探针图解
五、 pod的状态
1、pending:pod已经被系统认可了,但是内部的container还没有创建出来。这里包含调度到node上的时间以及下载镜像的时间,会持续一小段时间。
2、Running:pod已经与node绑定了(调度成功),而且pod中所有的container已经创建出来,至少有一个容器在运行中,或者容器的进程正在启动或者重启状态。--这里需要注意pod虽然已经Running了,但是内部的container不一定完全可用。因此需要进一步检测container的状态。
3、Succeeded:这个状态很少出现,表明pod中的所有container已经成功的terminated了,而且不会再被拉起了。
4、Failed:pod中的所有容器都被terminated,至少一个container是非正常终止的。(退出的时候返回了一个非0的值或者是被系统直接终止)
5、unknown:由于某些原因pod的状态获取不到,有可能是由于通信问题。 一般情况下pod最常见的就是前两种状态。而且当Running的时候,需要进一步关注container的状态
六、Container生命周期
1、Waiting:启动到运行中间的一个等待状态。
2、Running:运行状态。
3、Terminated:终止状态。 如果没有任何异常的情况下,container应该会从Waiting状态变为Running状态,这时容器可用。
但如果长时间处于Waiting状态,container会有一个字段reason表明它所处的状态和原因,如果这个原因很容易能标识这个容器再也无法启动起来时,例如ContainerCannotRun,整个服务启动就会迅速返回。(这里是一个失败状态返回的特性,不详细阐述)
三种探针
存活探针(livenessProbe):探测Pod容器是否在正常运行。如果探测失败则kubelet杀掉容器,并根据容器重启策略决定是否重启容器
就绪探针(readinessProbe):探测Pod是否进入就绪状态(ready状态栏是否100%比例),并做好接收service转发来的请求准备。
如果探测失败则Pod变成未就绪状态(0/1 1/2),service就会删除相关联的Pod端点,并不再转发请求给处于未就绪状态的Pod
启动探针(startupProbe):探测Pod容器内的应用进程是否启动成功。在启动探针探测成功之前,存活探针和就绪探针都会处于暂停状态,直到启动探针探测成功为止
如果探测失败则kubelet杀掉容器,并根据容器重启策略决定是否重启容器
关于探针的3种探测方式
exec:在容器里执行linux命令,如果命令返回码为0则认为探测成功,如果命令返回码为非0值则认为探测失败
httpGet:向PodIP和指定的端口及URL路径发送HTTP GET请求,如果HTTP响应状态码为2XX 3XX则认为探测成功,如果HTTP响应状态码为4XX 5XX则认为探测失败
tcpSocket:向PodIP和指定的端口发送TCP连接请求(三次握手),如果端口正确且TCP连接成功则认为探测成功,如果TCP连接失败则认为探测失败
探针参数:
initialDelaySeconds:指定容器启动后延迟探测的时间(单位为秒)
periodSeconds:指定每次探测的间隔时间
failureThreshold:指定判定探测失败的连续失败次数
timeoutSeconds:指定探测超时等待的时间
Pod容器的启动动作和退出动作:lifecycle.postStart|preStop(lifecycle与image字段同一层级)
lifecycle.postStart 设置Pod容器启动时额外执行的操作,此操作不会作为容器pid=1的主进程
lifecycle.preStop 设置Pod容器被kubelet杀掉退出时执行的操作
更多推荐
所有评论(0)