k8s探针

k8s的pod重启策略

1,Deploy 的yaml文件只能是always。Pod的 yaml三种模式都可以。

2,OnFailure:只有状态码非0才会重启。正常状态不重启的。

3,Never:正常退出和非正常退出都不重启。容器退出了,pod才会重启。

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

Docker的重启策略:

  1. docker的默认策略是never。
  2. on-failure:非正常退出。才会重启容器
  3. Always:只要容器退出都会重启
  4. Unless-stopped:只要容器退出就会重启,docker守护进程时已经停止的容器,不再重启。

单机部署:docker足够了

集群化部署k8s

Yaml文件快速生成模版:

--dry-run=client:只是调用api的对象不执行命令

生成pod 的yaml模版

生成service的yaml模版

pod的状态:

Crashloopbackoff:pod当中的容器退出。Kubelet正在重启。

Imagepullbackoff:正在重试拉取镜像。

Errimagepull:拉取镜像出错了(1网速太慢,2镜像名称写错,3镜像仓库挂了)

Evicte:pod被驱赶(node节点的资源不够部署pod,或者是资源不足,kubelet自动选择一个pod驱逐)

InvalidImageName: 无法解析镜像名称

ImageInspectError: 无法校验镜像

ErrImageNeverPull: 策略禁止拉取镜像

ImagePullBackOff: 正在重试拉取

RegistryUnavailable: 连接不到镜像中心

ErrImagePull: 通用的拉取镜像出错

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

CreateContainerError: 创建容器失败

m.internalLifecycle.PreStartContainer 执行hook报错

RunContainerError: 启动容器失败

PostStartHookError: 执行hook报错

ContainersNotInitialized: 容器没有初始化完毕

ContainersNotReady: 容器没有准备完毕

ContainerCreating: 容器创建中

PodInitializing:pod 初始化中

DockerDaemonNotReady: docker还没有完全启动

NetworkPluginNotReady: 网络插件还没有完全启动

如何对pod内的容器使用节点资源的限制:

  1. request:需要的资源
  2. Limit:最高能占用系统多少资源。 limit:需要多少,最多也只能这么多。

对pod的两个限制:

cpu 内存

Cpu:在k8s集群中限制格式:

  1. 数字加小数点 1可以占用一个CPU 2可以占用两个 0.5占半个CPU 0.2一个CPU的五分之一 要么是整数,要么就是小数点后只能跟一位,最小单位0.1

m来表示CPU

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

M:millicores单位。 100m就是最小单位。

内存:

Ki Mi Gi Ti 注意大写的。

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

k8s怎么设置镜像的拉取策略:

默认策略:

IFNotPresent:如果本地镜像有,就不再拉取,本没有才会去镜像仓库拉取。

Always:不论镜像是否存在,创建时(重启)都会重新拉取镜像。

Never:仅仅使用本地镜像,本地没有也不会主动拉取。

Pod的容器健康检查:

探针

Probe

K8s对容器执行的定期检查,诊断。

探针有三种规则:

1,**存活探针:**livenessProbe,探测容器是否正常运行,如果发现探测失败,会杀容器,容器会根据重启策略来决定是否重启,不是杀掉pod。

**2,就绪探针:**探测容器是否进入ready状态,并做好接受请求的准备。

探测失败 READY 0/1 容器当前没有进入ready状态,service会把这个资源对象的端点从当中剔除2,service也不会把请求转发到pod。

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

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

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

Probe的检测方法:

  1. **exec探针:**在容器内部执行命令,如果命令的返回码是0,表示成功。适用于需要在容器内自定义命令来检查容器的健康状况。
  2. **httpGet:**指定ip+端口的容器发送一个httpget的请求。响应状态码大于等于200,小于400都是成功。200-400 x >=200<400 适用于检测容器能否响应http的请求,web容器(nginx tomcat)
  3. **tcpSocket:**端口,对指定端口上的容器的ip地址进行tcp检查(三次握手)端口打开,认为探测成功。 检查特定容器的端口监听状态。

诊断结果:

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

总结:

探针的三个方法:

存活探针:检查失败之后,会杀死容器,然后重启。探针将伴随整个容器的生命周期。

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

Shell命令执行成功。

返回码:0表示成功。

成功一次就是探测 成功

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

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

相关推荐
南猿北者5 小时前
docker容器
docker·容器
YCyjs6 小时前
K8S群集调度二
云原生·容器·kubernetes
Hoxy.R6 小时前
K8s小白入门
云原生·容器·kubernetes
€☞扫地僧☜€9 小时前
docker 拉取MySQL8.0镜像以及安装
运维·数据库·docker·容器
全能全知者10 小时前
docker快速安装与配置mongoDB
mongodb·docker·容器
为什么这亚子12 小时前
九、Go语言快速入门之map
运维·开发语言·后端·算法·云原生·golang·云计算
ZHOU西口14 小时前
微服务实战系列之玩转Docker(十八)
分布式·docker·云原生·架构·数据安全·etcd·rbac
牛角上的男孩14 小时前
Istio Gateway发布服务
云原生·gateway·istio
JuiceFS16 小时前
好未来:多云环境下基于 JuiceFS 建设低运维模型仓库
运维·云原生
景天科技苑16 小时前
【云原生开发】K8S多集群资源管理平台架构设计
云原生·容器·kubernetes·k8s·云原生开发·k8s管理系统