pod 基础 2

2024-01-07 23:10:19

pod 进阶

探针

poststart

prestop

pod的生命周期开始:

重启:k8s的pod重启策略

deployment的yaml文件只能是Always pod的yaml三种模式都可以。

OnFailure:只有状态码非0才会重启,正常退出是不重启的

Never:正常退出和非正常退出都不重启。

容器退出了,pod才会重启。

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

docker的重启策略:

面试题:k8s和docker重启策略有什么不同

docker的默认策略是never。

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

always:只要容器退出都会重启

unless-stopped:只要容器退出,就会重启。docker的守护进程启动时已经停止的容器,不再重启。

单机部署:就使用docker足够了,

集群化部署:k8s

yaml文件快速生成:

基于模板来改。

基于deployment来创建

--dry-run=client -o yaml >:只是调用方法对象,不是执行命令,不会创建到集群中。

指定输出到opt

基于pod来创建

基于service创建

pod的状态:

crashloopbackoff:pod当中的容器已经退出,kubelet正在重启

imagepullbackoff:正在重试拉取镜像

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

Evicte:POD被驱赶(node节点资源不够部署pod,或者是资源不足,kubelet自动选择一个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,数字加小数点

1 2 0.5 0.2 可以占用几个cpu,最小是0.1单位

要么是整数,要么就是小数点后只能跟一位

2,m来表示cpu

cpu时间分片原理:

cpu时间分片:提供周期性的轮流分配cpu时间给各个进程,多个进程可以在cpu上交替执行。

在k8s中就是表示占用cpu的比率:

m:millicores 单位

1000m 500m 2000m 100m就是最小单位

1000m就是一个cpu

内存:

Ki

Mi(常见)

Gi(常见)

Ti

实验:

做限制条件。

kubectl apply -f test.yaml

进入容器:

kubectl exec -it centos-847ddb86c-ks44p bash

安装epel源

yum -y install epel-release

安装压力测试工具:

yum -y install stress

模拟压力测试:

超过直接杀进程

request 可以不设置,生产中一般不设置,只要不超过,用多少给多少

在master节点直接查看

kubectl describe nodes node02

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

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

默认策略:(默认策略即可)ifNotPresent

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

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

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

都是本地部署,Never

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

Always:不用

默认就是ifNotPresent,可以不加。

设置为Never

(本地有没有都不拉)不拉:

设置为:Always

本地有还是拉取

pod内容器的健康检查:

探针:

probe

k8s对容器执行的定期诊断。

探针有三种规则:

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

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

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

3,启动探针

只是在容器的启动后开始检测,容器内的应用是否启动成功。在启动探测成功之前,所有的其他探针都会处于禁用状态。

但是,一旦启动探针结束,后续的操作不再受探针影响。

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

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

存活探针:

就绪探针:

livenessprobe的检查方法:

1,exec探针:在容器内部执行命令,如果命令的返回码是0,表示成功。

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

相当于执行了一条命令行命令

2,httpGet:对指定ip+端口的容器发送一个httpget的请求。响应状态码大于或者等于200,小于400都是成功。

200

相当于发放http请求

适用于检查容器能否响应http的请求,web容器(nginx,tomcat)

3,tcpSocket:端口,对指定端口上的容器的IP地址进行的tcp检查(三次握手),端口打开认为 探测成功。检查特点容器的打开济安泰状态。

就是检查端口

检查结果:

1:成功容器提供,正常运行

2:失败存活探针会重启

3:未知结果

实验:

1,exec探针

initialDelaySeconds: 3

#表示容器启动之后多少秒来进行探测,时间不要设置的太短,可能导致无效探测

periodSeconds: 2

#表示探针探测的间隔时间。每隔多少秒进行一次检查。应用的延迟敏感度。这个应用非常重要,是核心组件。

failureThreshold: 2

#表示如果探测失败,失败几次之后,把容器标记为不健康。

successThreshold: 1

#只要成功一次就标记为就绪,健康,

timeoutSeconds: 1

#表示每次探测的超时时间,在多少秒内必须完成探测。

间隔的时间一定要比检测时间长。

前三个面试时要说出来。

成功次数可以不加,默认1次就成功,失败默认是3次

kubectl apply -f test.yaml

进入容器删除

kubectl exec -it centos-797bc57596-ghkvm -- rm -rf /opt/123.txt

探针检测不健康

在创建回去

kubectl exec -it centos-797bc57596-ghkvm -- touch /opt/123.txt

探测健康

liveness杀死容器重启。所有的探针策略伴随整个pod的生命周期。除了启动探针

2,httpGET

scheme:HTTP

协议是http

port: 80 端口为80

成功:

把80换成81,检测3次失败,就重启容器。

加上path:/index.html

加路径,检测访问资源是否存在。

kubectl describe pod nginx1

404 3次失败杀掉容器,继续重启

一直重启

改成对的

成功

3,tcpSocket 查看端口服务的监听状态

通过三次握手检测端口

改端口:

检测失败

总结:

探针的三个方法:

存活探针:检测失败,会杀死容器,然后重启。

探针将伴随整个生命周期

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

shell命令执行成功:

返回码:0表示成功。

成功一次结束探测成功

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

tcpSocket:相当于telnet,指定的容器济安泰端口是否打开。是否能和指定的容器监听

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