pod探针

Pod进阶：

探针*

Poststart

Prestop

pod的声明周期开始：

k8s的pod重启策略：

Always deployment的yaml三种模式都可以，不论正常退出还是非正常退出都重启

OnFailure:只有状态码非零才会重启，正常退出事不重启的

Never：正常退出和非正常退出都不重启

容器的退出，pod才会重启

Pod可以有多个容器，只要有一个容器退出，整个pod都会重启，pod内的所有容器都会重启

Docker的重启策略：

Docker的默认策略是Never

on-failure：非正常退出才会重启容器

Always：只要容器退出都会重启

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

单机部署：docker足够了

集群化部署：k8s

Yaml文件快速生成：

--dry-run=client 只是调用了对象，而不是执行命令

基于server

Pod的状态补充：

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

Imagepullbackoff：正在重试拉取镜像

Errorimagepull：拉取镜像出现错（1.网速太慢，2.镜像名字写错了，3.镜像仓库挂了）

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被驱赶

Pod内的容器使用节点资源的限制：

1. request：需要的资源
2. Limit：限制，最高能占用系统多少资源，limit需要多少，最多也只能占用这么多，两个限制：

CPU ：CPU的限制格式：1  2  0.5  0.2  0.3

1表示可以占用一个CPU，2表示可以占用两个。0.5可以占用半个 0.2：一个CPU的五分之一，0.1是最小单位，要么是整数，要么就是小数点后只能跟一位，最小单位0.1

m来表示CPU：CPU时间分片原理：通过周期性的轮流分配CPU时间给各个进程，多个进程可以在CPU上交替执行，在k8s就是表示占用的CPU比率，m:millicores单位 1表示1000m,意思就是1000m表示一个CPU，是1000100m是最小单位，表示0.1

内存：

注意一下单位格式即可：ki Mi Gi Ti

演示：

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

进入容器：

详细查看节点信息

去node节点输入top查看

k8s当中怎么设置拉取镜像的策略：

默认策略：

IfNotPresent:如果本地镜像有，就不在拉取，本地没有才会去镜像仓库拉取

Always:不论镜像是否存在，创建时（重启时），都会拉取镜像

Never：仅仅使用本地镜像，本地没有，也不会主动拉取

如果都是本地部署，用Never

如果涉及到外部部署，默认策略（事前要把docker的镜像导入到目标主机）

Always：一般不用

演示：

Never：本地没有，也不会去拉取

今天的重点：

Pod的容器健康检查：

探针 probe k8s对容器执行的定期检查，诊断。

探针有三种规则：

1. 存活探针：livenessProbe探测容器是否正常运行，如果发现探测失败会杀掉容器，容器会根据重启策略来决定是否重启，不是杀掉pod，只是对容器
2. 就绪探针：探测容器是否进入ready状态，并做好接受请求的准备，探测失败ready0/1 就表示没有进入ready状态，service会把这个资源对象的端点从当中剔除，service也不会把请求转发到这个pod
3. 启动探针：只是在容器的启动后开始检测，容器内的应用是否启动成功，在启动探测成功之前，所有的其他探针都会处于禁用状态，但是，一旦启动探针结束，后续的操作就不会再受启动探针的影响

在一个容器当中可以有多个探针。

启动探针：只在容器启动时探测

存活探针

就绪探针

Probe的检测方法：

1. exec探针：在容器当中执行命令，如果命令的返回码是0，表示成功，适用于需要再容器内自定义命令来检查容器的健康的情况
2. httpGet:对指定IP+端口的容器发送一个httpget的请求，响应状态码大于等于200，小于400都是成功，范围200-400之间，适用于检查容器能否响应http的请求，web容器（nginx，Tomcat）
3. TcpSocker:检查端口的，对指定端口上的容器的IP地址进行tcp检查（产生三次握手），端口打开，认为探测成功，检查特定容器的端口监听状态，例如端口从80改为999，telnet 20.0.0.71 80

诊断结果：

1. 成功 容器通过了，正常运行
2. 失败，存活探针就会重启
3. 未知状态：诊断失败

Exec方式：

解析意思：

查看详细信息：

演示探针失败

删除

重新创建文件后依然可以检测

小结：Liveness杀死容器重启，所有探针策略伴随整个pod生命周期，除了启动探针

通过http方式做健康检测

为了实验效果，将pod删除

换端口检测

kubectl describe pod nginx1

还可以指定path路径

正在拉镜像

改正确

没有报错

TcpSocket方式:

强制删除

端口改错，为了实验效果

总结一下今天的全部内容：

探针的三个方法：

存活探针：检测失败之后，会杀死容器，然后重启

探针将伴随整个容器生命周期

Exec：相当于执行了一个shell命令：容器里面执行

Shell命令要执行成功，返回码为0，表示成功

只要成功一次即可，就是探测成功

httpGet:对web容器发起一次get请求，可以添加path，指定访问的资源，返回码大宇等于200，小于400的范围之内都算成功

TcpSocket:相当于telnet,指定的容器监听端口是否打开，是否能和指定的容器监听进行通信