pod进阶

2024-01-08 16:56:08

1、pod的重启策略

Always

无论状态码如何，均会重启。基于deployment的yaml文件只能是Always，pod的yaml三种模式均可

OnFailure

状态码非0才会重启，正常退出不重启

Never

无论状态码如何，均不重启

注：这三个状态对应的是容器的状态，容器退出了，pod才会重启。pod有一个或多个容器，只要有一个容器退出，整个pod都会重启

2、docker的重启策略

never

docker的默认策略（常用）

on-failure

非正常退出才会重启容器（特殊情况下使用）

always

只要容器退出，都会重启（常用）

unless-stopped

只要容器退出就会重启，docker的守护进程启动时已经停止的容器不再重启

3、比较docker和k8s的重启策略有何区别【面试题】

4、yaml文件快速生成（修改此文件变成自己想要的yaml文件）

（1）生成deployment的yaml文件

kubectl create deployment nginx --image=nginx:1.22 --replicas=3 --dry-run=client -o yaml > /opt/testdeployment.yaml

只调用对象，不生成命令

（2）生成pod的yaml文件

?kubectl run nginx --image=nginx:1.22 --dry-run=client -o yaml > /opt/testpod.yaml

（3）生成service的yaml文件

kubectl expose deployment nginx --port=80 --target-port=80 --type=NodePort --dry-run=client -o yaml > /opt/testservice.yaml

5、pod的状态

crashloopbackoff

pod中的容器退出，kubelet正在重启

imagepullbackoff

正在重试拉取镜像

errimagepull

拉取镜像出错（网速太慢，超时；镜像名字写错；镜像仓库挂了）

Evicte

pod被驱赶（node节点上的资源不够部署pod，或者是资源不足，kubelet自动选择一个pod驱逐）

pod状态大全

CrashLoopBackOff

容器退出，kubelet正在将它重启

InvalidImageName

无法解析镜像名称

ImageInspectError

无法校验镜像

ErrImageNeverPull

策略禁止拉取镜像

ImagePullBackOff

正在重试拉取

RegistryUnavailable

连接不到镜像中心

ErrImagePull

通用的拉取镜像出错

CreateContainerConfigError

不能创建kubelet使用的容器配置

CreateContainerError

创建容器失败

m.internalLifecycle.PreStartContainer

执行hook报错

RunContainerError

启动容器失败

PostStartHookError

执行hook报错

ContainersNotInitialized

容器没有初始化完毕

ContainersNotReady

容器没有准备完毕

ContainerCreating

容器创建中

PodInitializing

pod初始化中

DockerDaemonNotReady

docker还没有完全启动

NetworkPluginNotReady

网络插件还没有完全启动

Evicte

pod被驱赶

6、对pod内的容器使用节点资源限制

request

pod内的容器需要的资源

limit

pod内的容器能占用系统资源的上限

（需要多少，最多也只能占用这么多）

CPU

格式1：

1—可以占用1个CPU

2—可以占用2个CPU

0.5—可以占用0.5个CPU

0.2—可以占用1/5个CPU

0.1是最小单位，要么是整数，要么是小数点后只能跟一位

格式2：

m:millicores 单位

m表示CPU（根据CPU时间分片原理来的）

CPU时间分片：通过周期性的轮流分配CPU时间给各个进程。多个进程可以在CPU上交替执行，在k8s中表示占用CPU的比率

1000m—表示1个CPU

500m—表示0.5个CPU

100m是最小单位

内存（单位：Ki，Mi，Gi，Ti）

注：在创建pod时一定要给容器做资源限制

原因：资源不满足，将cpu资源调小一点

每个pod占用1个cpu，现有3个pod副本，总共占3个cpu，本机只有2核4G，cpu资源不足，所以要将cpu资源调小一点（没有requests，只有limits，有多少占用多少）

测试

①512M

在node2节点上查看内存

②超过1G

7、镜像的拉取策略

IfNotPresent

若本地镜像已存在，不再拉取镜像，本地没有才会去镜像仓库拉取（默认策略）

若涉及到外部部署，使用默认策略，但事前需把docker的镜像导入到目标主机

Never

仅仅使用本地镜像，即便本地没有该镜像，也不会去镜像仓库拉取

Always

无论镜像是否存在，创建（重启）时都会重新拉取镜像（一般不用）

（1）IfNotPresent默认策略

（2）Never策略

（3）Always策略

①创建

②重启

8、pod的容器健康检查（探针probe）【重要】

（1）作用：k8s对容器的定期检查、诊断

（2）探针的三种类型

存活探针

（livenessProbe）

探测容器是否正常运行。若探测失败，会杀死容器，容器会根据重启策略决定是否重启（不是杀死pod，只对容器操作）

就绪探针

探测容器是否进入ready就绪状态，并做好接收请求的准备。探测失败，ready变成0/1，表示没有进入ready状态。service会把这个资源对象的端点从中剔除，service也不会把请求转发到这个pod

启动探针

只在容器启动后开始检测，检测容器内的应用是否启动成功。在启动探测成功之前，所有的其他探针都处于禁用状态，但是一旦启动探针结束，后续的操作不再受启动探针的影响

一个容器中有多个探针。所有的探针策略伴随整个pod的生命周期，除了启动探针

（3）探针的检查方法（三种探针都能用）

exec

在容器内部执行命令。若返回码是0，表示成功

适用于需要在容器内自定义命令来检查容器的健康状态情况

httpGet

对指定IP地址+端口的容器发送一个httpGet的请求。200≤响应状态码＜400均表示成功

适用于检查容器能否响应http的请求，比如web容器（nginx，tomcat）

tcpSocket

检查端口，对指定端口上的容器的IP地址进行TCP检查（三次握手）。若端口打开，表示探测成功

适用于检查特定容器的端口监听状态

诊断结果

成功

容器通过，正常运行

失败

存活探针重启

未知状态

诊断失败（很少见）

1）存活探针

①exec方法检测探针

initialDelaySeconds: 3

容器启动之后多少秒进行探测，时间不要太短，容器启动需要一定时间。容器还没启动好就开始探测，可能导致无效探测

periodSeconds: 2

探针探测的间隔时间（每隔多少秒进行一次检查），根据应用的延迟敏感度，这个应用非常重要，时间间隔设置的小一点

failureThreshold: 2

若探测失败，失败几次之后把容器标记为不健康。不设置，默认失败3次即容器不健康

在容器内部创建/opt/123.txt文件，成功

检测不正常状态

删除容器内部的/opt/123.txt文件

②httpGet方法检测探针

检测不正常状态

③tcpSocket方法检测容器

检测不正常状态

2）就绪探针

①exec方法检测容器

测试探测失败

②httpGet方法检测容器

测试探针失败

就绪探针：pod状态是running，ready状态是notready，容器不能提供正常业务访问，并且不会重启容器

③tcpSocket方法检测容器

测试探针失败

tcpSocket只是监听容器上的业务端口能否正常通信，8081端口没有，8080端口还在，正常端口可以访问。工作中不会出现这种情况，这个情况适用于更改容器的启动端口，自定义端口

注：存活探针和就绪探针会伴随整个pod的生命周期，只有检测还在就会一直检测容器的健康状态【面试题】

3）启动探针

tcpSocket检测方法容器

测试探测失败

startupProbe启动探针，若探测失败，pod状态是notready，启动探针探测容器失败会重启容器

4）三种探针方式结合

测试启动探针失败

启动探针没有成功之前，后续的探针都不会执行。启动探针执行成功后，后续探针才会执行

测试存活探针

测试就绪探针失败

启动探针成功之后，pod的生命周期内不会再检测启动探针

重启pod后，相当于重新部署了一个初始版的新的容器，上一步删除的/etc/passwd又回来了

【面试】

①在一个yaml文件中可以有多个探针，启动、存活、就绪都针对一个容器来探测

②启动探针的优先级最高，只有启动探针成功，后续探针才会执行

③启动探针成功之后，后续除非重启pod，否则不再触发启动探针

④在pod的生命周期中，伴随pod的，一直存在，一直探针的是存活探针和就绪探针

⑤在pod生命周期中，后续是满足哪个探针的条件，触发哪个探针的条件

⑥就绪探针，不影响容器运行，status处于running状态，容器不会重启，但容器退出还是会重启

9、容器启动和退出时的动作

postSrart

容器启动钩子。容器启动后触发的条件

preStart

容器退出钩子。容器退出后触发的条件

作用：

  1. 启动时可以自定义配置容器内的环境变量
  2. 通知机制，告知用户容器启动完毕

3、退出时可以执行自定义命令，删除或生成一些必要的程序，比如自定义销毁方式、自定义资源回收的方式、容器的退出等待时间

volumeMounts:

??????- name: test-yy

????????mountPath: /opt

????????readOnly: false

声明容器内部的挂载目录，要给这个挂载卷取名，不同挂载卷的名字不能重复，readOnly: false表示可读写

volumes:

??- name: test-yy

????hostPath:

??????path: /opt/test-ss

??????type: DirectoryOrCreate

声明node节点上和容器内的/opt的挂载目录。挂载卷的名称和要挂载的容器内挂载卷名一致，hostPath指定node节点上要和容器内的目录挂载，type: DirectoryOrCreate如果节点上的目录不存在，自动创建该目录。pod会经常重启或销毁，一旦容器和node节点挂载后，数据不会丢失

在这个pod的生命周期事件中，加入启动探针、存活探针、就绪探针加入到yaml文件中

①测试启动探针

启动探针成功后，不会再执行，即便删除启动探针的触发条件，根据pod的默认重启策略，也会重新启动，无法测试启动探针

②测试存活探针

③测试就绪探针

删除就绪探针的触发条件

kubectl exec -it nginx -- rm -rf /etc/passwd

文章来源:https://blog.csdn.net/2303_79207100/article/details/135390507
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。