kubernetes Pod的详细总结

kubernetes Pod的详细总结

Pod生命周期

Pod健康检测

Pod亲和性调度

Pod控制器：

ReplicationController、ReplicationSet、Deployment、Statefulset、DeamonSet、Job、CroninJob

Pod资源限制

污点和容忍度

Pod资源限制

kind: Podmetadata: name: lidabai namespace: default labels: app: lidabaispec: containers: - name: string image: xxx resources: #资源限制和请求的设置 limits: #资源限制的设置，节点上最低可 cpu: string #cpu的限制，单位为core数 memory: string #内存限制，单位可以为Mib/Gib requests: #node节点剩余资源不足该值则不会调度到该节点 cpu: string #cpu请求，容器启动的初始可用数量 memory: string #内存请求，容器启动的初始可用内存

limits: 如果节点上可用资源为满足设定的值则不允许Pod调度到该节点； requests：Pod最少使用的资源；

pod重启策略（RestartPolicy）

Pod重启策略应用于Pod内的所有容器，并且仅在Pod所处的Node上由kubelet进行判断和重启操作。当某个容器异常退出或者健康检查失败时，kubelet将根据 RestartPolicy 的设置来进行相应的操作。

Always：当容器失败时，由kubelet自动重启该容器(默认)

OnFailure：当容器终止运行且退出码不为0时，由kubelet自动重启该容器。

Never：不论容器运行状态如何，kubelet都不会重启该容器。

$ kubectl explain pod.spec restartPolicy：Always #Always、OnFailure 和 Never

亲和性与反亲和性调度

$ kubectl explain pods.spec.affinity nodeAffinity： #node节点亲和性调度 podAffinity： #Pod节点亲和性调度 podAntiAffinity:： # Pod反亲和性

prefered表示有节点尽量满足这个位置定义的亲和性，这不是一个必须的条件，软亲和性

require表示必须有节点满足这个位置定义的亲和性，这是个硬性条件，硬亲和性

matchExpressions：匹配表达式的

matchFields： 匹配字段的

1. node节点选择器

​ 将Pod调度到满足一定条件的节点上。

我们在创建pod资源的时候，pod会根据schduler进行调度，那么默认会调度到随机的一个工作节点，如果我们想要pod调度到指定节点或者调度到一些具有相同特点的node节点，怎么办呢？

可以使用pod中的nodeName或者nodeSelector字段指定要调度到的node节点

1）nodeName

​ 指定Pod调度到具体的某个节点。

kind: Podspec: nodeName: node01 #将Pod调度到node01节点 containers: ...

2）nodeSelector

​ 将Pod调度到具有指定标签的节点上。

kind: Podspec: nodeSelector: memory: enough #自定义标签 containers:

然后给node节点打上自定义的标签，则Pod会调度到打上该标签节点中的一个。

2.Pod亲和性调度（podAffinity）

​ 将关联性较强的两个Pod调度到一起。

一个Pod和另一个Pod频繁的互相访问，如果将两个Pod都调度到同一个节点上，则可以降低网络的延迟，提升通信效率。

kind: Podspec: container: ... affinity： podAffinity: #Pod亲和性调度 requiredDuringSchedulingIgnoredDuringExecution: #硬亲和性（必须满足指定条件） nodeSelectorTerms: - matchExpressions: #匹配表达式的 - key: zone #检查label operator: In #做等值选则还是不等值选则 values: #给定值 - foo - bar

3.Pod反亲和性（podAntiAffinity）

​ pod和pod更倾向不腻在一起，如果部署两套程序，那么这两套程序更倾向于反亲和性，这样相互之间不会有影响。

spec: containers: ... affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - {key: app1, operator: In, values: ["myapp1"]} #格式必须为该样式 topologyKey: kubernetes.io/hostname #位置拓扑键

污点（Taint）和容忍度（tolerations)

​ 给节点打上污点（taint)，在pod上定义容忍度，如果Pod不能容忍节点上的污点，则Pod不会调度到该节点。

​ 污点就是定义在节点上的键值属性数据，可以定决定拒绝那些pod；

排斥等级（effect）

NodeSchedule: 仅影响pod调度过程，当pod能容忍这个节点污点，就可以调度到当前节点，后来这个节点的污点改了，加了一个新的污点，使得之前调度的pod不能容忍了，那这个pod会怎么处理，对现存的pod对象不产生影响NoExecute：

​ 既影响调度过程，又影响现存的pod对象，如果现存的pod不能容忍节点后来加的污点，这个pod就会被驱逐

PreferNoSchedule：

​ 最好不，也可以，是NoSchedule的柔性版本

污点（taints)

K8S常见内置的污点：

当某些条件为真时，节点控制器会自动为该节点添加污点。

Node.kubernetes.io/NoSchedule:

Node.kubernetes.io/NoExecute:

定义Pod的驱逐行为，以应对节点故障；

Node.kubernetes.io/not-ready:

节点尚未准备好；

，对应于NodeConditionReady为Unknown;

Node.kubernetes.io/out-of-disk:

节点磁盘不足；

Node.kubernetes.io/memory-pressure：

节点有内存压力；

Node.kubernetes.io/:disk-pressure：

节点有磁盘压力；

Node.kubernetes.io/:network-unavailable：

节点的网络不可用；

Node.kubernetes.io/:unschedulable:

节点不可调度；

给节点打上污点

$ kubectl taint node node2 node-type=production:NoSchedule

查看节点上的污点

$ kubectl describe node master1 | grep Taints #查看master1节点上的污点Taints: node-role.kubernetes.io/master:NoSchedule

删除节点上的污点

$ kubectl describe node master1 | grep TaintsTaints: node-role.kubernetes.io/master:NoSchedule$ kubectl taint node master1 node-role.kubernetes.io/master-

容忍度（tolerations)

kind: Podspec: containers: tolerations - key："node-type" operator： Equal #Equal(默认). Exists value： "production" effect: "NoExecute" #定义对pod对象的排斥等级 tolerationSeconds: 3600

operator= Equal：等值判断，key和Value完全匹配

operator= Exists：存在性判断，key和effect必须同时匹配，value可以是空

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。