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的守护进程启动时已经停止的容器不再重启

pod进阶_第1张图片

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

只调用对象,不生成命令

pod进阶_第2张图片

(2)生成pod的yaml文件

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

pod进阶_第3张图片

(3)生成service的yaml文件

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

pod进阶_第4张图片

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时一定要给容器做资源限制

pod进阶_第5张图片pod进阶_第6张图片

pod进阶_第7张图片

原因:资源不满足,将cpu资源调小一点

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

pod进阶_第8张图片

pod进阶_第9张图片

测试

①512M

在node2节点上查看内存

pod进阶_第10张图片

②超过1G

pod进阶_第11张图片

pod进阶_第12张图片

pod进阶_第13张图片

7、镜像的拉取策略

IfNotPresent

若本地镜像已存在,不再拉取镜像,本地没有才会去镜像仓库拉取(默认策略)

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

Never

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

Always

无论镜像是否存在,创建(重启)时都会重新拉取镜像(一般不用)

(1)IfNotPresent默认策略

pod进阶_第14张图片

pod进阶_第15张图片

pod进阶_第16张图片

pod进阶_第17张图片

(2)Never策略

pod进阶_第18张图片

pod进阶_第19张图片

(3)Always策略

pod进阶_第20张图片

①创建

pod进阶_第21张图片

pod进阶_第22张图片

②重启

pod进阶_第23张图片

pod进阶_第24张图片

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方法检测探针

pod进阶_第25张图片

pod进阶_第26张图片

initialDelaySeconds: 3

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

periodSeconds: 2

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

failureThreshold: 2

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

pod进阶_第27张图片

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

pod进阶_第28张图片

pod进阶_第29张图片

检测不正常状态

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

pod进阶_第30张图片

httpGet方法检测探针

pod进阶_第31张图片pod进阶_第32张图片

pod进阶_第33张图片

pod进阶_第34张图片

pod进阶_第35张图片

检测不正常状态

pod进阶_第36张图片

pod进阶_第37张图片

pod进阶_第38张图片

tcpSocket方法检测容器

pod进阶_第39张图片

检测不正常状态

pod进阶_第40张图片

pod进阶_第41张图片

pod进阶_第42张图片

2)就绪探针

①exec方法检测容器

pod进阶_第43张图片

pod进阶_第44张图片

测试探测失败

pod进阶_第45张图片

②httpGet方法检测容器

pod进阶_第46张图片

pod进阶_第47张图片

测试探针失败

pod进阶_第48张图片

pod进阶_第49张图片

pod进阶_第50张图片

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

③tcpSocket方法检测容器

pod进阶_第51张图片

pod进阶_第52张图片

测试探针失败

pod进阶_第53张图片

pod进阶_第54张图片

pod进阶_第55张图片

pod进阶_第56张图片

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

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

3)启动探针

tcpSocket检测方法容器

pod进阶_第57张图片

pod进阶_第58张图片

pod进阶_第59张图片

pod进阶_第60张图片

测试探测失败

pod进阶_第61张图片

pod进阶_第62张图片

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

4)三种探针方式结合

pod进阶_第63张图片

pod进阶_第64张图片

pod进阶_第65张图片

pod进阶_第66张图片

测试启动探针失败

pod进阶_第67张图片

pod进阶_第68张图片

pod进阶_第69张图片

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

测试存活探针

pod进阶_第70张图片

pod进阶_第71张图片

pod进阶_第72张图片

pod进阶_第73张图片

pod进阶_第74张图片

测试就绪探针失败

pod进阶_第75张图片

pod进阶_第76张图片

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

pod进阶_第77张图片

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

【面试】

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

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

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

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

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

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

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

postSrart

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

preStart

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

作用:

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

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

pod进阶_第78张图片

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进阶_第79张图片

pod进阶_第80张图片

pod进阶_第81张图片

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

pod进阶_第82张图片

pod进阶_第83张图片

pod进阶_第84张图片

pod进阶_第85张图片

pod进阶_第86张图片

①测试启动探针

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

②测试存活探针

pod进阶_第87张图片

pod进阶_第88张图片

③测试就绪探针

删除就绪探针的触发条件

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

pod进阶_第89张图片

你可能感兴趣的:(docker,容器,运维)