pod进阶
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 | 容器退出钩子。容器退出后触发的条件 |
| 作用：
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
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。 如若内容造成侵权/违法违规/事实不符，请联系我的编程经验分享网邮箱：chenni525@qq.com进行投诉反馈，一经查实，立即删除！