Pod高级用法：如何管理pod生命周期 落日映苍穹つ 2023-01-17 08:19 103阅读 0赞 ![3b8635a05cfc04eb5bf47967940bb40b.gif][] 1.1 Pod高级用法：node节点选择器 我们在创建pod资源的时候，pod会根据schduler进行调度，那么默认会调度到随机的一个工作节点，如果我们想要pod调度到指定节点或者调度到一些具有相同特点的node节点，怎么办呢？ 可以使用pod中的nodeName或者nodeSelector字段指定要调度到的node节点 1、nodeName： 指定pod节点运行在哪个具体node上 [root@master1 ~]# cat pod.yaml apiVersion: v1 kind: Pod metadata: name: demo-pod namespace: default labels: app: myapp env: dev spec: nodeName: node2 containers: - name: tomcat-pod-java ports: - containerPort: 8080 image: tomcat:8.5-jre8-alpine imagePullPolicy: IfNotPresent - name: busybox image: busybox:latest command: - "/bin/sh" - "-c" - "sleep 3600" 2、nodeSelector： 指定pod调度到具有哪些标签的node节点上 #给node节点打标签，打个具有disk=ceph的标签 [root@master1 ~]# kubectl label nodes node1 disk=ceph node/node1 labeled #定义pod的时候指定要调度到具有disk=ceph标签的node上 [root@master1 ~]# cat pod.yaml apiVersion: v1 kind: Pod metadata: name: demo-pod namespace: default labels: app: myapp env: dev spec: nodeSelector: disk: ceph containers: - name: tomcat-pod-java ports: - containerPort: 8080 image: tomcat:8.5-jre8-alpine imagePullPolicy: IfNotPresent 1.2 Pod高级用法：污点和容忍度 1.2.1 node节点亲和性 node节点亲和性调度：nodeAffinity [root@master1 ~]# kubectl explain pods.spec.affinity KIND: Pod VERSION: v1 RESOURCE: affinity <Object> DESCRIPTION: If specified, the pod's scheduling constraints Affinity is a group of affinity scheduling rules. FIELDS: nodeAffinity <Object> podAffinity <Object> podAntiAffinity <Object> [root@master1 ~]# kubectl explain pods.spec.affinity.nodeAffinity KIND: Pod VERSION: v1 RESOURCE: nodeAffinity <Object> DESCRIPTION: Describes node affinity scheduling rules for the pod. Node affinity is a group of node affinity scheduling rules. FIELDS: preferredDuringSchedulingIgnoredDuringExecution <[]Object> requiredDuringSchedulingIgnoredDuringExecution <Object> prefered表示有节点尽量满足这个位置定义的亲和性，这不是一个必须的条件，软亲和性 require表示必须有节点满足这个位置定义的亲和性，这是个硬性条件，硬亲和性 [root@master1 ~]# kubectl explain pods.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution KIND: Pod VERSION: v1 RESOURCE: requiredDuringSchedulingIgnoredDuringExecution <Object> DESCRIPTION: FIELDS: nodeSelectorTerms <[]Object> -required- Required. A list of node selector terms. The terms are ORed. [root@master1 ~]# kubectl explain pods.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms KIND: Pod VERSION: v1 RESOURCE: nodeSelectorTerms <[]Object> DESCRIPTION: Required. A list of node selector terms. The terms are ORed. A null or empty node selector term matches no objects. The requirements of them are ANDed. The TopologySelectorTerm type implements a subset of the NodeSelectorTerm. FIELDS: matchExpressions <[]Object> matchFields <[]Object> matchExpressions：匹配表达式的 matchFields： 匹配字段的 [root@master1 ~]# kubectl explain pods.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms.matchFields KIND: Pod VERSION: v1 RESOURCE: matchFields <[]Object> DESCRIPTION: FIELDS: key <string> -required- values <[]string> [root@master1 ~]# kubectl explain pods.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms.matchExpressions KIND: Pod VERSION: v1 RESOURCE: matchExpressions <[]Object> DESCRIPTION: FIELDS: key <string> -required- operator <string> -required- values <[]string> key：检查label operator：做等值选则还是不等值选则 values：给定值 例1：使用requiredDuringSchedulingIgnoredDuringExecution硬亲和性 [root@master1 ~]# cat pod-nodeaffinity-demo.yaml apiVersion: v1 kind: Pod metadata: name: pod-node-affinity-demo namespace: default labels: app: myapp tier: frontend spec: containers: - name: myapp image: ikubernetes/myapp:v1 affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: zone operator: In values: - foo - bar 我们检查当前节点中有任意一个节点拥有zone标签的值是foo或者bar，就可以把pod调度到这个node节点的foo或者bar标签上的节点上 kubectl apply -f pod-nodeaffinity-demo.yaml [root@master1 ~]# kubectl get pods -o wide | grep pod-node pod-node-affinity-demo 0/1 Pending 0 node2 status的状态是pending，上面说明没有完成调度，因为没有一个拥有zone的标签的值是foo或者bar，而且使用的是硬亲和性，必须满足条件才能完成调度 kubectl label nodes node2 zone=foo 给这个node2节点打上标签zone=foo，在查看 kubectl get pods -o wide 显示如下： pod-node-affinity-demo 1/1 Running 0 node2 例2：使用preferredDuringSchedulingIgnoredDuringExecution软亲和性 [root@master1 ~]# cat pod-nodeaffinity-demo-2.yaml apiVersion: v1 kind: Pod metadata: name: pod-node-affinity-demo-2 namespace: default labels: app: myapp tier: frontend spec: containers: - name: myapp image: ikubernetes/myapp:v1 affinity: nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: - preference: matchExpressions: - key: zone1 operator: In values: - foo1 - bar1 weight: 60 [root@master1 ~]# kubectl apply -f pod-nodeaffinity-demo-2.yaml [root@master1 ~]# kubectl get pods -o wide |grep demo-2 pod-node-affinity-demo-2 1/1 Running 0 node2 上面说明软亲和性是可以运行这个pod的，尽管没有运行这个pod的节点定义的zone1标签 1.2.2 Pod节点亲和性 pod自身的亲和性调度有两种表示形式 podaffinity：pod和pod更倾向腻在一起，把相近的pod结合到相近的位置，如同一区域，同一机架，这样的话pod和pod之间更好通信，比方说有两个机房，这两个机房部署的集群有1000台主机，那么我们希望把nginx和tomcat都部署同一个地方的node节点上，可以提高通信效率； podunaffinity：pod和pod更倾向不腻在一起，如果部署两套程序，那么这两套程序更倾向于反亲和性，这样相互之间不会有影响；我们通过节点亲和性也可以来定义pod之间的亲和性，一般来讲我们用户必须为pod指定节点标签，这样就可以通过节点亲和性来控制pod亲和性；那么为什么还要定义pod亲和性呢，因为通过节点亲和性来控制pod亲和性并不是最优的选则，我们必须确定节点和pod双方向可以完全匹配到，还需要精心布局节点是如何打标签的才能达到目的，这种方式难度较大；定义pod亲和性最理想的方式： 第一个pod随机选则一个节点，做为评判后续的pod能否到达这个pod所在的节点上的运行方式，这就称为pod亲和性；我们怎么判定哪些节点是相同位置的，哪些节点是不同位置的；我们在定义pod亲和性时需要有一个前提，哪些pod在同一个位置，哪些pod不在同一个位置，这个位置是怎么定义的，标准是什么？以节点名称为标准，这个节点名称相同的表示是同一个位置，节点名称不相同的表示不是一个位置。 [root@master1 ~]# kubectl explain pods.spec.affinity.podAffinity KIND: Pod VERSION: v1 RESOURCE: podAffinity <Object> DESCRIPTION: Describes pod affinity scheduling rules (e.g. co-locate this pod in the same node, zone, etc. as some other pod(s)). Pod affinity is a group of inter pod affinity scheduling rules. FIELDS: preferredDuringSchedulingIgnoredDuringExecution <[]Object> requiredDuringSchedulingIgnoredDuringExecution <[]Object> requiredDuringSchedulingIgnoredDuringExecution： 硬亲和性 preferredDuringSchedulingIgnoredDuringExecution：软亲和性 [root@master1 ~]# kubectl explain pods.spec.affinity.podAffinity.requiredDuringSchedulingIgnoredDuringExecution KIND: Pod VERSION: v1 RESOURCE: requiredDuringSchedulingIgnoredDuringExecution <[]Object> DESCRIPTION: FIELDS: labelSelector <Object> namespaces <[]string> topologyKey <string> -required- topologyKey： 位置拓扑的键，这个是必须字段 怎么判断是不是同一个位置： rack=rack1 row=row1 使用rack的键是同一个位置 使用row的键是同一个位置 labelSelector： 我们要判断pod跟别的pod亲和，跟哪个pod亲和，需要靠labelSelector，通过labelSelector选则一组能作为亲和对象的pod资源 namespace： labelSelector需要选则一组资源，那么这组资源是在哪个名称空间中呢，通过namespace指定，如果不指定namespaces，那么就是当前创建pod的名称空间 [root@master1 ~]# kubectl explain pods.spec.affinity.podAffinity.requiredDuringSchedulingIgnoredDuringExecution.labelSelector KIND: Pod VERSION: v1 RESOURCE: labelSelector <Object> DESCRIPTION: A label query over a set of resources, in this case pods. A label selector is a label query over a set of resources. The result of matchLabels and matchExpressions are ANDed. An empty label selector matches all objects. A null label selector matches no objects. FIELDS: matchExpressions <[]Object> matchLabels <map[string]string> 例1：pod节点亲和性 定义两个pod，第一个pod做为基准，第二个pod跟着它走 [root@master1 ~]# cat pod-required-affinity-demo.yaml apiVersion: v1 kind: Pod metadata: name: pod-first labels: app: myapp tier: frontend spec: containers: - name: myapp image: ikubernetes/myapp:v1 --- apiVersion: v1 kind: Pod metadata: name: pod-second labels: app: backend tier: db spec: containers: - name: busybox image: busybox:latest imagePullPolicy: IfNotPresent command: ["sh","-c","sleep 3600"] affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - {key: app, operator: In, values: ["myapp"]} topologyKey: kubernetes.io/hostname #上面表示创建的pod必须与拥有app=myapp标签的pod在一个节点上 kubectl apply -f pod-required-affinity-demo.yaml kubectl get pods -o wide 显示如下： pod-first running node2 pod-second running node2 上面说明第一个pod调度到哪，第二个pod也调度到哪，这就是pod节点亲和性 kubectl delete -f pod-required-affinity-demo.yaml 例2：pod节点反亲和性 定义两个pod，第一个pod做为基准，第二个pod跟它调度节点相反 [root@master1 ~]# cat pod-required-anti-affinity-demo.yaml apiVersion: v1 kind: Pod metadata: name: pod-first labels: app: myapp tier: frontend spec: containers: - name: myapp image: ikubernetes/myapp:v1 --- apiVersion: v1 kind: Pod metadata: name: pod-second labels: app: backend tier: db spec: containers: - name: busybox image: busybox:latest imagePullPolicy: IfNotPresent command: ["sh","-c","sleep 3600"] affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - {key: app, operator: In, values: ["myapp"]} topologyKey: kubernetes.io/hostname kubectl apply -f pod-required-anti-affinity-demo.yaml kubectl get pods -o wide 显示两个pod不在一个node节点上，这就是pod节点反亲和性 pod-first running node2 pod-second running node1 kubectl delete -f pod-required-anti-affinity-demo.yaml 例3：换一个topologykey kubectl label nodes node1 zone=foo kubectl label nodes node2 zone=foo [root@master1 ~]# cat pod-required-anti-affinity-demo-1.yaml apiVersion: v1 kind: Pod metadata: name: pod-first labels: app: myapp tier: frontend spec: containers: - name: myapp image: ikubernetes/myapp:v1 --- apiVersion: v1 kind: Pod metadata: name: pod-second labels: app: backend tier: db spec: containers: - name: busybox image: busybox:latest imagePullPolicy: IfNotPresent command: ["sh","-c","sleep 3600"] affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - {key: app, operator: In, values: ["myapp"]} topologyKey: zone kubectl apply -f pod-required-anti-affinity-demo.yaml kubectl get pods -o wide 显示如下： pod-first running node2 pod-second pending <none> 第二个节点现是pending，因为两个节点是同一个位置，现在没有不是同一个位置的了，而且我们要求反亲和性，所以就会处于pending状态，如果在反亲和性这个位置把required改成preferred，那么也会运行。 podaffinity：pod节点亲和性，pod倾向于哪个pod nodeaffinity：node节点亲和性，pod倾向于哪个node 1.2.3 污点、容忍度 给了节点选则的主动权，我们打一个污点，不容忍的pod就运行不上来，污点就是定义在节点上的键值属性数据，可以定决定拒绝那些pod； taints是键值数据，用在节点上，定义容忍度； tolerations是键值数据，用在pod上，定义容忍度，能容忍哪些污点 节点亲和性是pod属性，pod亲和性也是pod属性；但是污点是节点的属性，污点定义在nodeSelector上 kubectl get nodes node1 -o yaml [root@master1 ~]# kubectl explain node.spec.taints KIND: Node VERSION: v1 RESOURCE: taints <[]Object> DESCRIPTION: If specified, the node's taints. The node this Taint is attached to has the "effect" on any pod that does not tolerate the Taint. FIELDS: effect <string> -required- key <string> -required- timeAdded <string> value <string> taints的effect用来定义对pod对象的排斥等级（效果）： NoSchedule： 仅影响调度过程，当pod能容忍这个节点污点，就可以调度到当前节点，后来这个节点的污点改了，加了一个新的污点，使得之前调度的pod不能容忍了，那这个pod会怎么处理，对现存的pod对象不产生影响 NoExecute： 既影响调度过程，又影响现存的pod对象，如果现存的pod不能容忍节点后来加的污点，这个pod就会被驱逐 PreferNoSchedule： 最好不，也可以，是NoSchedule的柔性版本 在pod对象定义容忍度的时候支持两种操作： 1.等值密钥：key和value上完全匹配 2.存在性判断：key和effect必须同时匹配，value可以是空 在pod上定义的容忍度可能不止一个，在节点上定义的污点可能多个，需要琢个检查容忍度和污点能否匹配，每一个污点都能被容忍，才能完成调度，如果不能容忍怎么办，那就需要看pod的容忍度了 kubectl describe nodes master1 查看master这个节点是否有污点，显示如下： 上面可以看到master这个节点的污点是Noschedule 所以我们创建的pod都不会调度到master上，因为我们创建的pod没有容忍度 kubectl describe pods kube-apiserver-master -n kube-system 显示如下： 可以看到这个pod的容忍度是NoExecute，则可以调度到master1上 管理节点污点 kubectl taints --help 例1：把node1当成是生产环境专用的，其他node是测试的 kubectl taint node node1 node-type=production:NoSchedule （给node1打污点，pod如果不能容忍就不会调度过来） kubectl apply -f deploy-demo.yaml kubectl get pods -o wide 显示如下： myapp-deploy-6wtcddgg-efghth running node2 my-pp-deploy-6wtcddgg-efg2wg running node2 myapp-deploy-6wtcddgg-efg3gd running node2 可以看到都被调度到node1上了，因为node1这个节点打了污点，而我们在创建pod的时候没有容忍度，所以node1上不会有pod调度上去的 例2：给node2也打上污点 kubectl taint node node2 node-type=dev:NoExecute kubectl get pods -o wide 显示如下： mympp-deploy-6wtcddgg-efghth pending myapp-deploy-6wtcddgg-efg2wg pending myapp-deploy-6wtcddgg-efg3gd pending 上面可以看到已经存在的pod节点都被撵走了 [root@master1 ~]# cat deploy-demo-1.yaml apiVersion: apps/v1 kind: Deployment metadata: name: myapp-deploy namespace: default spec: replicas: 3 selector: matchLabels: app: myapp release: canary template: metadata: labels: app: myapp release: canary spec: containers: - name: myapp image: ikubernetes/myapp:v1 ports: - name: http containerPort: 80 tolerations: - key: "node-type" operator: "Equal" value: "production" effect: "NoExecute" tolerationSeconds: 3600 kubectl apply -f deploy-demo-1.yaml kubectl get pods -o wide 还是显示pending，因为我们使用的是equal（等值匹配），所以key和value，effect必须和node节点定义的污点完全匹配才可以，把上面配置文件修改effect: "NoSchedule"成这个；tolerationSeconds: 3600这行去掉 kubectl apply -f deploy-demo-1.yaml kubectl get pods -o wide 显示如下： myapp-deploy-6wtcddgg-efghth running node1 my-pp-deploy-6wtcddgg-efg2wg running node1 myapp-deploy-6wtcddgg-efg3gd running node1 上面就可以调度到node1上了，因为在pod中定义的容忍度能容忍node节点上的污点 例3：再次修改 修改如下部分： tolerations: - key: "node-type" operator: "Exists" value: "" effect: "NoSchedule" 只要对应的键是存在的，exists，其值被自动定义成通配符 kubectl apply -f deploy-demo-1.yaml kubectl get pods -o wide 显示如下: myapp-deploy-6wtcddgg-efghth running node1 my-pp-deploy-6wtcddgg-efg2wg running node1 myapp-deploy-6wtcddgg-efg3gd running node1 发现还是调度到node1上 再次修改： tolerations: - key: "node-type" operator: "Exists" value: "" effect: "" 有一个node-type的键，不管值是什么，不管是什么效果，都能容忍 kubectl apply -f deploy-demo-1.yaml kubectl get pods -o wide 显示如下: myapp-deploy-6wtcddgg-efghth running node1 my-pp-deploy-6wtcddgg-efg2wg running node2 myapp-deploy-6wtcddgg-efg3gd running node1 可以看到node1和node2节点上都有pod被调度 1.3 Pod高级用法：Pod状态和重启策略 1.3.1 常见的pod状态 Pod的status定义在PodStatus对象中，其中有一个phase字段。它简单描述了Pod在其生命周期的阶段。熟悉Pod的各种状态对我们理解如何设置Pod的调度策略、重启策略是很有必要的。下面是 phase 可能的值，也就是pod常见的状态： 挂起（Pending）：我们在请求创建pod时，条件不满足，调度没有完成，没有任何一个节点能满足调度条件，已经创建了pod但是没有适合它运行的节点叫做挂起，调度没有完成，处于pending的状态会持续一段时间：包括调度Pod的时间和通过网络下载镜像的时间。 运行中（Running）：Pod已经绑定到了一个节点上，Pod 中所有的容器都已被创建。至少有一个容器正在运行，或者正处于启动或重启状态。 成功（Succeeded）：Pod 中的所有容器都被成功终止，并且不会再重启。 失败（Failed）：Pod 中的所有容器都已终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止。 未知（Unknown）：未知状态，所谓pod是什么状态是apiserver和运行在pod节点的kubelet进行通信获取状态信息的，如果节点之上的kubelet本身出故障，那么apiserver就连不上kubelet，得不到信息了，就会看Unknown 扩展：还有其他状态，如下： Evicted状态：出现这种情况，多见于系统内存或硬盘资源不足，可df-h查看docker存储所在目录的资源使用情况，如果百分比大于85%，就要及时清理下资源，尤其是一些大文件、docker镜像。 CrashLoopBackOff：容器曾经启动了，但可能又异常退出了 Error 状态：Pod 启动过程中发生了错误 1.3.2 pod重启策略 Pod的重启策略（RestartPolicy）应用于Pod内的所有容器，并且仅在Pod所处的Node上由kubelet进行判断和重启操作。当某个容器异常退出或者健康检查失败时，kubelet将根据 RestartPolicy 的设置来进行相应的操作。 Pod的重启策略包括 Always、OnFailure和Never，默认值为Always。 Always：当容器失败时，由kubelet自动重启该容器。 OnFailure：当容器终止运行且退出码不为0时，有kubelet自动重启该容器。 Never：不论容器运行状态如何，kubelet都不会重启该容器。 失败的容器由 kubelet 以五分钟为上限的指数退避延迟（10秒，20秒，40秒…）重新启动，并在成功执行十分钟后重置。 [root@master1 ~]# vim pod.yaml apiVersion: v1 kind: Pod metadata: name: demo-pod namespace: default labels: app: myapp spec: restartPolicy: Always containers: - name: tomcat-pod-java ports: - containerPort: 8080 image: tomcat:8.5-jre8-alpine imagePullPolicy: IfNotPresent 1.4 Pod高级用法：Pod生命周期 1.4.1 Init容器 Pod 里面可以有一个或者多个容器，部署应用的容器可以称为主容器，在创建Pod时候，Pod 中可以有一个或多个先于主容器启动的Init容器,这个init容器就可以成为初始化容器，初始化容器一旦执行完，它从启动开始到初始化代码执行完就退出了，它不会一直存在，所以在主容器启动之前执行初始化，初始化容器可以有多个，多个初始化容器是要串行执行的，先执行初始化容器1，在执行初始化容器2等，等初始化容器执行完初始化就退出了，然后再执行主容器，主容器一退出，pod就结束了，主容器退出的时间点就是pod的结束点，它俩时间轴是一致的； Init容器就是做初始化工作的容器。可以有一个或多个，如果多个按照定义的顺序依次执行，只有所有的初始化容器执行完后，主容器才启动。由于一个Pod里的存储卷是共享的，所以Init Container里产生的数据可以被主容器使用到，Init Container可以在多种K8S资源里被使用到，如Deployment、DaemonSet, StatefulSet、Job等，但都是在Pod启动时，在主容器启动前执行，做初始化工作。 Init容器与普通的容器区别是: 1、Init 容器不支持 Readiness,因为它们必须在Pod就绪之前运行完成 2、每个Init容器必须运行成功,下一个才能够运行 3、如果 Pod 的 Init 容器失败,Kubernetes 会不断地重启该 Pod,直到 Init 容器成功为止，然而,如果Pod对应的restartPolicy值为 Never,它不会重新启动。 1.4.2 主容器 1、容器钩子 初始化容器启动之后，开始启动主容器，在主容器启动之前有一个post start hook（容器启动后钩子）和pre stop hook（容器结束前钩子），无论启动后还是结束前所做的事我们可以把它放两个钩子，这个钩子就表示用户可以用它来钩住一些命令，来执行它，做开场前的预设，结束前的清理，如awk有begin，end，和这个效果类似； postStart：该钩子在容器被创建后立刻触发，通知容器它已经被创建。如果该钩子对应的hook handler执行失败，则该容器会被杀死，并根据该容器的重启策略决定是否要重启该容器，这个钩子不需要传递任何参数。 preStop：该钩子在容器被删除前触发，其所对应的hook handler必须在删除该容器的请求发送给Docker daemon之前完成。在该钩子对应的hook handler完成后不论执行的结果如何，Docker daemon会发送一个SGTERN信号量给Docker daemon来删除该容器，这个钩子不需要传递任何参数。 在k8s中支持两类对pod的检测，第一类叫做livenessprobe（pod存活性探测）： 存活探针主要作用是，用指定的方式检测pod中的容器应用是否正常运行，如果检测失败，则认为容器不健康，那么Kubelet将根据Pod中设置的 restartPolicy来判断Pod 是否要进行重启操作，如果容器配置中没有配置 livenessProbe，Kubelet 将认为存活探针探测一直为成功状态。 第二类是状态检readinessprobe（pod就绪性探测）：用于判断容器中应用是否启动完成，当探测成功后才使Pod对外提供网络访问，设置容器Ready状态为true，如果探测失败，则设置容器的Ready状态为false。 1.4.3 创建pod需要经过哪些阶段？ 当用户创建pod时，这个请求给apiserver，apiserver把创建请求的目标状态保存在etcd中； 接下来apiserver会请求scheduler来完成调度，如果调度成功，会把调度的结果（如调度到哪个节点上了，运行在哪个节点上了，把它更新到etcd的pod资源状态中）保存在etcd中，一旦存到etcd中并且完成更新以后，那么目标节点，如调度到node2上，那么node2节点上的kubelet通过apiserver当中的状态变化知道有一些任务被执行了，所以此时此kubelet会拿到用户创建时所提交的清单，这个清单会在当前节点上运行或者启动这个pod，如果创建成功或者失败会有一个当前状态，当前这个状态会发给apiserver，apiserver在存到etcd中；在这个过程中，etcd和apiserver一直在打交道，不停的交互，scheduler也参与其中，负责调度pod到合适的node节点上，这个就是pod的创建过程 pod在整个生命周期中有非常多的用户行为： 1、初始化容器完成初始化 2、主容器启动后可以做启动后钩子 3、主容器结束前可以做结束前钩子 4、在主容器运行中可以做一些健康检测，如liveness probe，readness probe 1.5 Pod高级用法：Pod容器探测深度讲解 1.5.1 容器钩子：postStart和preStop postStart：容器创建成功后，运行前的任务，用于资源部署、环境准备等。 preStop：在容器被终止前的任务，用于优雅关闭应用程序、通知其他系统等。 演示postStart和preStop用法 ...... containers: - image: sample:v2 name: war lifecycle： postStart: exec: command: - “cp” - “/sample.war” - “/app” prestop: httpGet: host: monitor.com psth: /waring port: 8080 scheme: HTTP ...... 以上示例中，定义了一个Pod，包含一个JAVA的web应用容器，其中设置了PostStart和PreStop回调函数。即在容器创建成功后，复制/sample.war到/app文件夹中。而在容器终止之前，发送HTTP请求到http://monitor.com:8080/waring，即向监控系统发送警告。 优雅的删除资源对象 当用户请求删除含有pod的资源对象时（如RC、deployment等），K8S为了让应用程序优雅关闭（即让应用程序完成正在处理的请求后，再关闭软件），K8S提供两种信息通知： 1）、默认：K8S通知node执行docker stop命令，docker会先向容器中PID为1的进程发送系统信号SIGTERM，然后等待容器中的应用程序终止执行，如果等待时间达到设定的超时时间，或者默认超时时间（30s），会继续发送SIGKILL的系统信号强行kill掉进程。 2）、使用pod生命周期（利用PreStop回调函数），它执行在发送终止信号之前。 默认情况下，所有的删除操作的优雅退出时间都在30秒以内。kubectl delete命令支持--grace-period=的选项，以运行用户来修改默认值。0表示删除立即执行，并且立即从API中删除pod，这样一个新的pod会在同时被创建。在节点上，被设置了立即结束的的pod，仍然会给一个很短的优雅退出时间段，才会开始被强制杀死。如下： kind: Deployment metadata: name: nginx-demo labels: app: nginx-demo spec: replicas: 1 template: metadata: labels: app: nginx-demo spec: containers: - name: nginx-demo image: centos:nginx lifecycle: preStop: exec: # nginx -s quit gracefully terminate while SIGTERM triggers a quick exit command: ["/usr/local/nginx/sbin/nginx","-s","quit"] ports: - name: http containerPort: 80 1.5.3 探测：livenessProbe和readinessProbe livenessProbe：存活性探测 许多应用程序经过长时间运行，最终过渡到无法运行的状态，除了重启，无法恢复。通常情况下，K8S会发现应用程序已经终止，然后重启应用程序pod。有时应用程序可能因为某些原因（后端服务故障等）导致暂时无法对外提供服务，但应用软件没有终止，导致K8S无法隔离有故障的pod，调用者可能会访问到有故障的pod，导致业务不稳定。K8S提供livenessProbe来检测应用程序是否正常运行，并且对相应状况进行相应的补救措施。 readinessProbe：就绪性探测 在没有配置readinessProbe的资源对象中，pod中的容器启动完成后，就认为pod中的应用程序可以对外提供服务，该pod就会加入相对应的service，对外提供服务。但有时一些应用程序启动后，需要较长时间的加载才能对外服务，如果这时对外提供服务，执行结果必然无法达到预期效果，影响用户体验。比如使用tomcat的应用程序来说，并不是简单地说tomcat启动成功就可以对外提供服务的，还需要等待spring容器初始化，数据库连接连接上等等。对于spring boot应用，默认的actuator带有/health接口，可以用来进行启动成功的判断。 目前LivenessProbe和ReadinessProbe两种探针都支持下面三种探测方法： 1、ExecAction：在容器中执行指定的命令，如果执行成功，退出码为 0 则探测成功。 2、TCPSocketAction：通过容器的 IP 地址和端口号执行 TCP 检 查，如果能够建立 TCP 连接，则表明容器健康。 3、HTTPGetAction：通过容器的IP地址、端口号及路径调用 HTTP Get方法，如果响应的状态码大于等于200且小于400，则认为容器健康 探针探测结果有以下值： 1、Success：表示通过检测。 2、Failure：表示未通过检测。 3、Unknown：表示检测没有正常进行。 Pod探针相关的属性： 探针(Probe)有许多可选字段，可以用来更加精确的控制Liveness和Readiness两种探针的行为 initialDelaySeconds： Pod启动后首次进行检查的等待时间，单位“秒”。 periodSeconds： 检查的间隔时间，默认为10s，单位“秒”。 timeoutSeconds： 探针执行检测请求后，等待响应的超时时间，默认为1s，单位“秒”。 successThreshold： 探针检测失败后认为成功的最小连接成功次数，默认为 1s，在 Liveness 探针中必须为1s，最小值为1s。 failureThreshold： 探测失败的重试次数，重试一定次数后将认为失败，在 readiness 探针中，Pod会被标记为未就绪，默认为 3s，最小值为 1s。 两种探针区别： ReadinessProbe 和 livenessProbe 可以使用相同探测方式，只是对 Pod 的处置方式不同： readinessProbe 当检测失败后，将 Pod 的 IP:Port 从对应的 EndPoint 列表中删除。 livenessProbe 当检测失败后，将杀死容器并根据 Pod 的重启策略来决定作出对应的措施。 Pod探针使用示例： 1、LivenessProbe 探针使用示例 （1）、通过exec方式做健康探测 示例文件 liveness-exec.yaml apiVersion: v1 kind: Pod metadata: name: liveness-exec labels: app: liveness spec: containers: - name: liveness image: busybox args: #创建测试探针探测的文件 - /bin/sh - -c - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600 livenessProbe: initialDelaySeconds: 10 #延迟检测时间 periodSeconds: 5 #检测时间间隔 exec: command: - cat - /tmp/healthy 容器启动设置执行的命令： /bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600" 容器在初始化后，首先创建一个 /tmp/healthy 文件，然后执行睡眠命令，睡眠 30 秒，到时间后执行删除 /tmp/healthy 文件命令。而设置的存活探针检检测方式为执行 shell 命令，用 cat 命令输出 healthy 文件的内容，如果能成功执行这条命令，存活探针就认为探测成功，否则探测失败。在前 30 秒内，由于文件存在，所以存活探针探测时执行 cat /tmp/healthy 命令成功执行。30 秒后 healthy 文件被删除，所以执行命令失败，Kubernetes 会根据 Pod 设置的重启策略来判断，是否重启 Pod。 （2）、通过HTTP方式做健康探测 示例文件 liveness-http.yaml apiVersion: v1 kind: Pod metadata: name: liveness-http labels: test: liveness spec: containers: - name: liveness image: mydlqclub/springboot-helloworld:0.0.1 livenessProbe: initialDelaySeconds: 20 #延迟加载时间 periodSeconds: 5 #重试时间间隔 timeoutSeconds: 10 #超时时间设置 httpGet: scheme: HTTP port: 8081 path: /actuator/health 上面 Pod 中启动的容器是一个 SpringBoot 应用，其中引用了 Actuator 组件，提供了 /actuator/health 健康检查地址，存活探针可以使用 HTTPGet 方式向服务发起请求，请求 8081 端口的 /actuator/health 路径来进行存活判断： 任何大于或等于200且小于400的代码表示探测成功。 任何其他代码表示失败。 如果探测失败，则会杀死 Pod 进行重启操作。 httpGet探测方式有如下可选的控制字段: scheme: 用于连接host的协议，默认为HTTP。 host：要连接的主机名，默认为Pod IP，可以在http request head中设置host头部。 port：容器上要访问端口号或名称。 path：http服务器上的访问URI。 httpHeaders：自定义HTTP请求headers，HTTP允许重复headers。 （3）、通过TCP方式做健康探测 示例文件 liveness-tcp.yaml apiVersion: v1 kind: Pod metadata: name: liveness-tcp labels: app: liveness spec: containers: - name: liveness image: nginx livenessProbe: initialDelaySeconds: 15 periodSeconds: 20 tcpSocket: port: 80 TCP 检查方式和 HTTP 检查方式非常相似，在容器启动 initialDelaySeconds 参数设定的时间后，kubelet 将发送第一个 livenessProbe 探针，尝试连接容器的 80 端口，如果连接失败则将杀死 Pod 重启容器。 2、ReadinessProbe 探针使用示例 Pod 的ReadinessProbe 探针使用方式和 LivenessProbe 探针探测方法一样，也是支持三种，只是一个是用于探测应用的存活，一个是判断是否对外提供流量的条件。这里用一个 Springboot 项目，设置 ReadinessProbe 探测 SpringBoot 项目的 8081 端口下的 /actuator/health 接口，如果探测成功则代表内部程序以及启动，就开放对外提供接口访问，否则内部应用没有成功启动，暂不对外提供访问，直到就绪探针探测成功。 示例文件 readiness-exec.yaml apiVersion: v1 kind: Service metadata: name: springboot labels: app: springboot spec: type: NodePort ports: - name: server port: 8080 targetPort: 8080 nodePort: 31180 - name: management port: 8081 targetPort: 8081 nodePort: 31181 selector: app: springboot --- apiVersion: v1 kind: Pod metadata: name: springboot labels: app: springboot spec: containers: - name: springboot image: mydlqclub/springboot-helloworld:0.0.1 ports: - name: server containerPort: 8080 - name: management containerPort: 8081 readinessProbe: initialDelaySeconds: 20 periodSeconds: 5 timeoutSeconds: 10 httpGet: scheme: HTTP port: 8081 path: /actuator/health 3、ReadinessProbe + LivenessProbe 配合使用示例 一般程序中需要设置两种探针结合使用，并且也要结合实际情况，来配置初始化检查时间和检测间隔，下面列一个简单的 SpringBoot 项目的 Deployment 例子。 apiVersion: v1 kind: Service metadata: name: springboot labels: app: springboot spec: type: NodePort ports: - name: server port: 8080 targetPort: 8080 nodePort: 31180 - name: management port: 8081 targetPort: 8081 nodePort: 31181 selector: app: springboot --- apiVersion: apps/v1 kind: Deployment metadata: name: springboot labels: app: springboot spec: replicas: 1 selector: matchLabels: app: springboot template: metadata: name: springboot labels: app: springboot spec: containers: - name: readiness image: mydlqclub/springboot-helloworld:0.0.1 ports: - name: server containerPort: 8080 - name: management containerPort: 8081 readinessProbe: initialDelaySeconds: 20 periodSeconds: 5 timeoutSeconds: 10 httpGet: scheme: HTTP port: 8081 path: /actuator/health livenessProbe: initialDelaySeconds: 30 periodSeconds: 10 timeoutSeconds: 5 httpGet: scheme: HTTP port: 8081 path: /actuator/health **公众号后台回复** \[ 加群 \]，加入linux+docker+k8s+devops技术交流群，一起进步、一起成长！ 精彩文章推荐 [安装kubernetes集群-灵活安装k8s各个版本高可用集群][kubernetes_-_k8s] [Prometheus+Grafana+Alertmanager搭建全方位的监控告警系统-超详细文档][Prometheus_Grafana_Alertmanager_-] [基于Jenkins和k8s构建企业级DevOps容器云平台][Jenkins_k8s_DevOps] [k8s+jenkins+SonarQube+harbor构建DevOps自动化容器云平台][k8s_jenkins_SonarQube_harbor_DevOps] [k8s如何学习？搞清k8s关键技术点][k8s_k8s][ ][Link 1] [Kubernetes将弃用Docker，不必恐慌][Kubernetes_Docker][ ][Link 2] [5个维度对 Kubernetes 集群优化][5_ Kubernetes] [K8s自动扩缩容工具KEDA发布2.0版本，全面升级应用扩展能力][K8s_KEDA_2.0] [应该监控哪些Kubernetes健康指标？][Kubernetes][ ][k8s_k8s] [如何在 Kubernetes 上扩展微服务][Kubernetes 1] [容器运行时Containerd基础][Containerd] [K8S 集群中的认证、授权与kubeconfig][K8S _kubeconfig] [Kubernetes 1.21正式发布 | 主要变化解读][Kubernetes 1.21_ _] [k8s控制器Statefulset详细介绍：资源清单编写技巧][k8s_Statefulset] ![602e19deade938fc213d55f73d1dc9d9.png][] 公众号后台回复 \[ 加群 \]，加入linux+docker+k8s+devops技术交流群，一起进步、一起成长！ [3b8635a05cfc04eb5bf47967940bb40b.gif]: /images/20221021/99637f12979642e7a7b7c73a04623e68.png [kubernetes_-_k8s]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb6384b8cc140dae0e6efba75100e29549cc440a010a5c7976bdd313e9c6139569b197e20a8f&idx=1&mid=2247486381&scene=21&sn=f07ae730cdc3ca2442462e0c7f2caed1#wechat_redirect [Prometheus_Grafana_Alertmanager_-]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb638b08cc14021e5e025f2f0b89d18ec5ef19f9dec4429a56f356e8b596d01095e313dab3e3&idx=1&mid=2247484445&scene=21&sn=bf8928e7aae815b8e7f9ac56a67289ce#wechat_redirect [Jenkins_k8s_DevOps]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639ad4cc1413c29af69c3c0c3e48d17ef9a2cf5948696d70fb8fad23eecabc5d75b5d23657&idx=1&mid=2247488961&scene=21&sn=a4ea6111d7b613f2948032a3a16a1ac9#wechat_redirect [k8s_jenkins_SonarQube_harbor_DevOps]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639c31cc1415277a4203065c3aaa468949e48dc8c75d65026c59584b0517cef18e26273373&idx=1&mid=2247488292&scene=21&sn=d81030fed2368e707ee984929b2ee6a5#wechat_redirect [k8s_k8s]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639ba0cc1412b6c2e6d7c057dceaf125787fe4a0a0e12caf94b7bb3796296dbb3a278c36fe&idx=1&mid=2247488693&scene=21&sn=5ad25ab1809828acfa7e75dcfb824542#wechat_redirect [Link 1]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639f9bcc14168dbffbc995646942ed75995d1181296af73df1cd13b6d3f0052d42934648cc&idx=1&mid=2247487630&scene=21&sn=d4cbb1afb6d2d059c0e9d319dd47fdf0#wechat_redirect [Kubernetes_Docker]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639f68cc14167e344cea74d031c8f466e51cb00f19d112d07aeb73fa062a7be5b473d055d7&idx=1&mid=2247487613&scene=21&sn=61308d2c58562ad51ad8c1327a2353e1#wechat_redirect [Link 2]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639f7acc14166ca2176a440bbcde9d563c78df76bff8a5a8e0cff467f23dfc9415b2c5c4ef&idx=1&mid=2247487599&scene=21&sn=8f107a8d869238058e50e8cd73175c5a#wechat_redirect [5_ Kubernetes]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb6383aecc140ab8050df002d52f6063e85ad2777f4ec0941c9d40ea49c50c11f23542f43dfc&idx=1&mid=2247486651&scene=21&sn=2fe1be9d4a335077757c46a36cb1aea2#wechat_redirect [K8s_KEDA_2.0]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639d51cc141447eb0ded990df4abe27860fc66b782875f3e656bcdfe5a7b00b2bfb76b9d15&idx=1&mid=2247488068&scene=21&sn=f24c1e2561160fe5feb9a17c6bcc8d1c#wechat_redirect [Kubernetes]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639dc8cc1414de4ad7398463fb0a5bbb414e1444a0f4b6d3bb8e922697a1d7b3db6130b650&idx=1&mid=2247488221&scene=21&sn=b7cc4fe1347303ba87f226f24b5985ab#wechat_redirect [Kubernetes 1]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639b80cc141296252512e6456dbdcd4d19629630bff9ae07a0aada93029e87dc359d754f46&idx=1&mid=2247488661&scene=21&sn=2e55fb79ddef40022ff4beb642361c95#wechat_redirect [Containerd]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639b5ecc141248b6378ace908c840a942257e4790b2b91254ca519ff1cfb13e2924a41d8db&idx=1&mid=2247488587&scene=21&sn=e111dff943411a657b5e9106e73f9dfe#wechat_redirect [K8S _kubeconfig]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639bfccc1412ea3cefc4a38f79a735081ec861baeb9b20234a36f893a9517815018b3617d6&idx=1&mid=2247488745&scene=21&sn=d17e44969fe9859282a0cfbd25214bde#wechat_redirect [Kubernetes 1.21_ _]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639ad9cc1413cf9c9788f98afc87b2b9c50f8670780653667a29590b95fb930d8a298fedd1&idx=1&mid=2247488972&scene=21&sn=88bb2915bb615507cb3c30dcd3fed1db#wechat_redirect [k8s_Statefulset]: http://mp.weixin.qq.com/s?__biz=MzU0NjEwMTg4Mg%3D%3D&chksm=fb639a24cc1413324eef71861544aa3d322b669d37752e078c23714beeaef664d54f2a47e015&idx=2&mid=2247488817&scene=21&sn=5baea68480d87d6de2fe8e70b8338aff#wechat_redirect [602e19deade938fc213d55f73d1dc9d9.png]: /images/20221021/fd063a417b84490ab1ef02fa844d2c13.png
还没有评论，来说两句吧...