专业电商网站开发,视频网站开发书籍,设计大神云集的网站是,车陂手机网站建设Pod调度策略 一.污点-Taint二.容忍度-Tolerations三.Pod常见状态和重启策略1.Pod常见状态2.Pod的重启策略2.1测试Always重启策略2.2测试Never重启策略2.3测试OnFailure重启策略#xff08;生产环境中常用#xff09; 一.污点-Taint
在 Kubernetes 中#xff0c;污点#x… Pod调度策略 一.污点-Taint二.容忍度-Tolerations三.Pod常见状态和重启策略1.Pod常见状态2.Pod的重启策略2.1测试Always重启策略2.2测试Never重启策略2.3测试OnFailure重启策略生产环境中常用 一.污点-Taint
在 Kubernetes 中污点Taint是一种标记用于标识一个Node节点上的某些资源或条件不可用或不可接受。当一个节点被标记了污点后只有那些能够容忍该污点的 Pod 才能被调度到该节点上。
污点常用与以下场景
将某些节点标记为“故障”以防止新的 Pod 被调度到这些节点上将某些节点标记为“高负载”以防止过多的 Pod 被调度到这些节点上导致节点过载将某些节点标记为“专用”以保证只有特定的 Pod 能够被调度到这些节点上。
pod亲和性是pod属性但是污点是节点的属性污点定义在k8s集群的节点上的一个字段。
# 查看控住节点定义的污点
[rootmaster1]# kubectl describe nodes master1 | grep Taints
Taints: node-role.kubernetes.io/control-plane:NoSchedule# 两个工作节点是没有定义污点
[rootnode1]# kubectl describe nodes node1 | grep Taints
Taints: none[rootnode2]# kubectl describe nodes node2 | grep Taints
Taints: none1.查看定义taint的信息
# 查看帮助命令
[rootmaster1]# kubectl explain node.spec
······taints []ObjectIf specified, the nodes taints.
[rootmaster1]# kubectl explain node.spec.taints
KIND: Node
VERSION: v1
RESOURCE: taints []Object
DESCRIPTION:If specified, the nodes taints.The node this Taint is attached to has the effect on any pod that doesnot tolerate the Taint.FIELDS:effect string -required-Required. The effect of the taint on pods that do not tolerate the taint.Valid effects are NoSchedule, PreferNoSchedule and NoExecute.Possible enum values:- NoExecute Evict any already-running pods that do not tolerate thetaint. Currently enforced by NodeController.- NoSchedule Do not allow new pods to schedule onto the node unlessthey tolerate the taint, but allow all pods submitted to Kubelet withoutgoing through the scheduler to start, and allow all already-running pods tocontinue running. Enforced by the scheduler.- PreferNoSchedule Like TaintEffectNoSchedule, but the scheduler triesnot to schedule new pods onto the node, rather than prohibiting new podsfrom scheduling onto the node entirely. Enforced by the scheduler.key string -required-Required. The taint key to be applied to a node.timeAdded stringTimeAdded represents the time at which the taint was added. It is onlywritten for NoExecute taints.value stringThe taint value corresponding to the taint key.污点排斥等级
NoSchedule表示Pod不会被调度到具有该污点的节点上不影响已经存在的PodPreferNoSchedule表示调度器会尽量避免将Pod调度到具有该污点的节点上。但是Pod没有定义容忍度依然会被调度到这两个节点上NoExecute既影响Pod调度过程又影响现存Pod对象如果现存Pod不能容忍节点加的污点那么这个Pod就会被驱逐
2.定义污点
kubectl taint nodes node1 node-typedev:NoSchedule3.查看污点
kubectl describe nodes node1 | grep Taint4.删除污点
kubectl taint nodes node1 node-typedev:NoSchedule-二.容忍度-Tolerations
当我们节点定义污点后如果我们不定义对应的容忍度那么Pod将不会调度到此Node节点。
方便下面实验我把所有node节点全部定义上污点
kubectl taint nodes node1 node-typedev:NoSchedule
kubectl taint nodes node2 node-typedev:NoSchedule查看容忍度的帮助
kubectl explain pod.spec.tolerations1.定义Pod容忍度容忍node-typedev且排斥等级等于NoExecute使用了operatorEqual这三点必须同时能满足。
cat pod1.yml
---
apiVersion: v1
kind: Pod
metadata:name: pod1namespace: defaultlabels:app: nginxenv: devspec:tolerations:- effect: NoExecute # 指定排斥等级key: node-type # 污点keyoperator: Equal # Equal表示等于value: dev # 污点valuetolerationSeconds: 3600 # 删除Pod前等待时间,默认30scontainers:- name: nginximage: nginximagePullPolicy: IfNotPresentports:- containerPort: 80执行文件
kubectl apply -f pod1.yaml查看状态因为没有任何节点满足该Pod容忍所以该Pod处于Pending状态
kubectl get pods pod1NAME READY STATUS RESTARTS AGE
pod1 0/1 Pending 0 10m2.定义Pod容忍度将排斥等级改为 NoSchedule这样我们污点keyvalue排斥等级都满足了Pod才会调度 Pod资源清单文件如下
cat pod2.yml
---
apiVersion: v1
kind: Pod
metadata:name: pod2namespace: defaultlabels:app: nginxenv: devspec:tolerations:- effect: NoSchedule # 指定排斥等级key: node-type # 污点keyoperator: Equal # Equal表示等于value: dev # 污点valuecontainers:- name: nginximage: nginximagePullPolicy: IfNotPresentports:- containerPort: 80执行文件
kubectl apply -f pod2.yaml查看状态Pod成功调度且状态为 Running
kubectl get pods pod2NAME READY STATUS RESTARTS AGE
pod2 1/1 Running 0 5m32s3.定义Pod容忍度将 operatorExists表示满足其中一项即可容忍下面Pod没有定义keyvalue表示没有keyvalue方面限制容忍排斥等级NoSchedule的节点。
cat pod3.yml
---
apiVersion: v1
kind: Pod
metadata:name: pod3namespace: defaultlabels:app: nginxenv: devspec:tolerations:- effect: NoSchedule # 指定排斥等级 operator: Exists # Exists表示满足一项即可containers:- name: nginximage: nginximagePullPolicy: IfNotPresentports:- containerPort: 80执行文件
kubectl apply -f pod3.yaml查看状态Pod调度成功且状态为Running
kubectl get pods pod-3NAME READY STATUS RESTARTS AGE
pod3 1/1 Running 0 5m16s三.Pod常见状态和重启策略
1.Pod常见状态 第一阶段
挂起Pending 正在创建Pod但是Pod中的容器还没有全部被创建完成处于此状态的Pod应该检查Pod依赖的存储是否有权限挂载、镜像是否可以下载、调度是否正常等我们在请求创建pod时条件不满足调度没有完成没有任何一个节点能满足调度条件已经创建了pod但是没有适合它运行的节点叫做挂起调度没有完成。 失败FailedPod 中的所有容器都已终止了并且至少有一个容器是因为失败终止。也就是说容器以非0状态退出或者被系统终止。未知Unknown未知状态所谓pod是什么状态是apiserver和运行在pod节点的kubelet进行通信获取状态信息的如果节点之上的kubelet本身出故障那么apiserver就连不上kubelet得不到信息了就会看Unknown通常是由于与pod所在的node节点通信错误。Error 状态Pod 启动过程中发生了错误成功SucceededPod中的所有容器都被成功终止即pod里所有的containers均已terminated。
第二阶段
UnschedulablePod不能被调度 scheduler没有匹配到合适的node节点PodScheduledpod正处于调度中在scheduler刚开始调度的时候还没有将pod分配到指定的node在筛选出合适的节点后就会更新etcd数据将pod分配到指定的nodeInitialized所有pod中的初始化容器已经完成了ImagePullBackOffPod所在的node节点下载镜像失败RunningPod内部的容器已经被创建并且启动。
扩展还有其他状态如下
Evicted状态出现这种情况多见于系统内存或硬盘资源不足可df-h查看docker存储所在目录的资源使用情况如果百分比大于85%就要及时清理下资源尤其是一些大文件、docker镜像。CrashLoopBackOff容器曾经启动了但可能又异常退出了。如pod一直在重启
2.Pod的重启策略
Pod的重启策略RestartPolicy应用于Pod内的所有容器当某个容器异常退出或者健康检查失败时kubelet将根据 重启策略来进行相应的操作。 Pod 的 spec 中包含一个 restartPolicy 字段其可能取值包括 Always、OnFailure 和 Never。默认值是 Always。Always只要容器异常退出kubelet就会自动重启该容器。这个是默认的重启策略OnFailure当容器终止运行且退出码不为0时由kubelet自动重启该容器。生产环境中常用Never不论容器运行状态如何kubelet都不会重启该容器。
2.1测试Always重启策略
[rootmaster1]# vim pod.yaml
apiVersion: v1
kind: Pod
metadata:name: demo-podnamespace: defaultlabels:app: myapp
spec:restartPolicy: Alwayscontainers:- name: tomcatports:- containerPort: 8080image: tomcat:latestimagePullPolicy: IfNotPresent[rootmaster1]# kubectl apply -f pod.yaml
pod/demo-pod created
[rootmaster1]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
demo-pod 1/1 Running 0 10s 10.244.169.153 node2 none none# 动态显示pod状态信息
[rootmaster1]# kubectl get pods -o wide -w
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
demo-pod 1/1 Running 0 22s 10.244.169.153 node2 none none# 另起一个终端会话进入pod内部容器正常停止 tomcat 容器服务。-c 指定容器名称。
[rootmaster1]# kubectl exec -it demo-pod -c tomcat -- /bin/bash
rootdemo-pod:/usr/local/tomcat# ls
rootdemo-pod:/usr/local/tomcat# bin/shutdown.sh 可以看到容器服务停止后被重启了一次Pod又恢复正常
# 非正常停止容器里的tomcat服务
[rootmaster1]# kubectl exec -it demo-pod -c tomcat -- bash
rootdemo-pod:/usr/local/tomcat# ps -ef | grep tomcat
rootdemo-pod:/usr/local/tomcat# kill 1容器被终止再一次重启重启次数加一
2.2测试Never重启策略
# 修改 pod.yaml把 Always 改为 Never
[rootmaster1]# kubectl delete pods demo-pod
pod demo-pod deleted
[rootmaster1]# kubectl apply -f pod.yaml
pod/demo-pod created
[rootmaster1]# kubectl get pods -o wide -w# 在另一个终端进入容器正常停止服务
[rootmaster1]# kubectl exec -it demo-pod -c tomcat-pod-java -- /bin/bash
rootdemo-pod:/usr/local/tomcat# bin/shutdown.sh 查看Pod状态发现正常停止tomcat服务Pod正常运行但是容器没有重启
# 非正常停止容器里的tomcat服务
[rootmaster1]# kubectl delete pods demo-pod
pod demo-pod deleted
[rootmaster1]# kubectl apply -f pod.yaml
pod/demo-pod created
[rootmaster1]# kubectl get pods -o wide -w# 在另一终端进入容器内容
[rootmaster1]# kubectl exec -it demo-pod -c tomcat-pod-java -- bash
rootdemo-pod:/usr/local/tomcat# kill 1看到容器的状态时Pod的状态是Error并且没有重启说明重启策略是Never那么Pod里容器服务无论如何终止都不会重启
2.3测试OnFailure重启策略生产环境中常用
# 修改 pod.yaml 文件把 Never 改为 OnFailure
[rootmaster1]# kubectl delete pods demo-pod
pod demo-pod deleted
[root-master1]# kubectl apply -f pod.yaml
pod/demo-pod created
[rootmaster1]# kubectl get pods -o wide -w# 在另一终端进入容器内部正常停止服务
[rootmaster1]# kubectl exec -it demo-pod -c tomcat-pod-java -- bash
rootdemo-pod:/usr/local/tomcat# bin/shutdown.sh发现正常通知容器退出码时0容器不会重启
# 非正常停止容器里的tomcat服务
[rootmaster1]# kubectl delete pods demo-pod
pod demo-pod deleted
[rootmaster1]# kubectl apply -f pod.yaml
pod/demo-pod created
[rootmaster1]# kubectl get pods -o wide -w# 在另一终端进入容器内部
[rootmaster1]# kubectl exec -it demo-pod -c tomcat-pod-java -- bash
rootdemo-pod:/usr/local/tomcat# kill 1看到非正常停止的pod里的容器容器退出码不是0容器会被重启。
