kubernetes Pod的详细总结 _KUBERNETES

吾生也有涯,而知也无涯。这篇文章主要讲述kubernetes Pod的详细总结相关的知识，希望能为你提供帮助。

Pod生命周期

Pod健康检测

Pod亲和性调度

Pod控制器：

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

Pod资源限制

污点和容忍度

Pod资源限制

kind: Pod
metadata:
name: lidabai
namespace: default
labels:
app: lidabai
spec:
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节点亲和性调度
pod< strong> Anti< /strong> Affinity:： # Pod反亲和性

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

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

matchExpressions：匹配表达式的

matchFields：匹配字段的

1. node节点选择器
? 将Pod调度到满足一定条件的节点上。

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

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

1）nodeName
? 指定Pod调度到具体的某个节点。

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

2）nodeSelector
? 将Pod调度到具有指定标签的节点上。

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

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

2.Pod亲和性调度（podAffinity）
? 将关联性较强的两个Pod调度到一起。

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

kind: Pod
spec:
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:
如果一个Pod没有声明容忍这个Taint，则系统不会把该Pod调度到这个Taint的node上；

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 Taints
Taints:node-role.kubernetes.io/master:NoSchedule
$ kubectl taint nodemaster1node-role.kubernetes.io/master-

容忍度（tolerations)

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

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

【kubernetes Pod的详细总结】operator= Exists：存在性判断，key和effect必须同时匹配，value可以是空