google广告联盟网站,创新优典网站建设,深圳网站建设网站,招聘网站可以做劳务派遣吗探针*
容器钩子#xff1a;
poststart
prestop pod的生命周期开始 Q#xff1a;docker和k8s的重启策略对比
A#xff1a;
k8s的pod重启策略#xff1a;
Always#xff1a;正常退出和非正常退出都重启#xff08;deployment的yaml文件只能是Always。pod的yaml文件三…探针*
容器钩子
poststart
prestop pod的生命周期开始 Qdocker和k8s的重启策略对比
A
k8s的pod重启策略
Always正常退出和非正常退出都重启deployment的yaml文件只能是Always。pod的yaml文件三种模式都可以
Never正常退出和非正常退出都不重启
OnFailure只有状态码非0才会重启。正常退出不重启
容器退出了pod才会重启
pod可以有多个容器只要有一个容器整个pod都会重启pod内的所有容器都会重启 docker的重启策略
docker的默认策略是Never
on-failure非正常退出才会重启容器
always只要容器退出都会重启
unless-stopped只要容器推出就会重启docker守护进程时已经停止的容器不再重启 单机部署docker足够
集群化部署K8S 如何快捷生成yaml文件
[rootmaster01 opt]# kubectl create deployment nginx --imagenginx:1.22 --replicas3 --dry-runclient
deployment.apps/nginx created (dry run)
[rootmaster01 opt]# kubectl get deployment.apps
NAME READY UP-TO-DATE AVAILABLE AGE
centos1 0/1 1 0 20h
[rootmaster01 opt]# kubectl create deployment nginx --imagenginx:1.22 --replicas3 --dry-runclient -o yaml /opt/test1.yml
[rootmaster01 opt]# ls
a.yml cni-plugins-linux-amd64-v0.8.6.tgz rh
b.yml containerd test1.yml
[rootmaster01 opt]# kubectl run nginx1 --imagenginx:1.22 --dry-runclient -o yaml /opt/test-pod.yaml
[rootmaster01 opt]# vim test-pod.yaml
[rootmaster01 opt]# kubectl expose deployment nginx2 --port80 --target-port80 --typeNodePort --dry-runclient -o yaml /opt/testl-service.yaml
[rootmaster01 opt]# vim testl-service.yaml --dry-runclient: 只是调用api的对象不执行命令 pod内的容器使用节点资源的限制
1、request: 需要的资源
2、limit最高能占用系统多少资源 如果只设置request没有limit会占用所有
工作中一般就写一个limit
limit需要多少最多也只能占用这么多
如果只有limit没有request会按照limit来 两个限制内存 CPU
CPU的限制格式
法一
1 2 0.2 0.1 【最小单位】
可以占用1个cpu 可以占用2个cpu 可以占用0.2个cpu 可以占用0.1个cpu 要么是整数要么就是小数点后只能跟一位最小单位0.1 法二
m来表示CPU
1000m表示一个cpu
CPU时间分片原理
CPU时间分片通过周期性的轮流分配CPU时间给各个进程。多个进程可以在CPU上交替执行
在K8S中就是表示占用的CPU的比率
mmillicores 单位 内存Ki/Mi/Gi/Ti
#在创建pod时一定要给容器做资源限制 k8s怎么设置拉取镜像的策略
默认策略:
lfNotPresent如果本地镜像有则不再拉取。本地没有才会去镜像仓库拉取
Always不论镜像是否存在创建/重启时都会重新拉取镜像
Never仅仅使用本地镜像。本地没有也不会主动拉取 都是本地部署Never
如果涉及到外部部署默认策略 (事前要把docker的镜像导入到目标主机)
Always一般不用 pod的容器健康检查探针probe
K8S对容器执行的定期检查、诊断 探针的三种规则
1、存活探针livenessProbe
探测容器是否正常运行
如果发现探测失败会杀掉容器容器会根据重启策略决定是否重启。不是杀掉pod只是对容器 2、流量/就绪探针
探测容器是否进入ready状态并做好接受请求的状态
探测失败ready 0/1 没有进入ready状态。但是status依旧是running实际不可用
service会把资源对象的端点从当中剔除service也不会把请求转发到pod 3、启动探针
只是在容器启动后开始检测容器内的应用是否启动成功。在启动探测成功之前所有其他的探针都处于禁用状态。一旦启动探针结束后续的操作就不再受启动探针的影响 在一个容器当中的可以有多个探针
启动探针只在容器启动时探测
存活
就绪 probe的检查方法
1、exec探针: 在容器内部执行命令如果命令的返回码是0表示成功。
适用于需要在容器内自定义命令来检查容器的健康状况
2、httpGet:
对指定ip端口的容器发送一个httpget的请求。响应状态码大于等于200,小于400都是成功。
200x400
适用于检查容器能否响应http的请求web容器nginx、tomcat
3、tcpSocket
端口。对指定端口上的容器的IP地址进行tcp检查三次握手端口打开认为探测成功否则都是失败。
适用于检查特定容器的端口监听状态
类似于telnet 192.168.233.10 80 诊断结果
1、成功
容器通过了正常运行
2、失败
只有存活探针会重启就绪探针会启动探针会
3、未知
诊断失败少见 exec方式 successThreshold: 1
timeoutSeconds: 1
这两个可以不加其他的三个都要加是核心指标 总结:
探针:
存活探针: 检测失败之后会杀死容器然后重启
探针将伴随整个容器的生命周期
exec相当于执行了一个shell命令: 容器里面执行
shell命令执行成功返回码是0表示成功
成功一次即可。只要成功一次就是探测成功 httpGet对web容器发起的一次Get请求可以添加path指定访问的资源。返回码在[200,400)之间都算成功 tcpSocket相当于telnet。指定的容器的监听端口是否打开。是否能和指定的容器监听端口进行通信
