pod进阶：探针和容器钩子

探针*

容器钩子：

poststart

prestop

pod的生命周期开始

Q：docker和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文件

[root@master01 opt]# kubectl create deployment nginx --image=nginx:1.22 --replicas=3 --dry-run=client

deployment.apps/nginx created (dry run)

[root@master01 opt]# kubectl get deployment.apps

NAME         READY   UP-TO-DATE   AVAILABLE   AGE

centos1      0/1     1            0           20h

[root@master01 opt]# kubectl create deployment nginx --image=nginx:1.22 --replicas=3 --dry-run=client -o yaml > /opt/test1.yml

[root@master01 opt]# ls

a.yml    cni-plugins-linux-amd64-v0.8.6.tgz  rh

b.yml    containerd                          test1.yml

[root@master01 opt]# kubectl run nginx1 --image=nginx:1.22 --dry-run=client -o yaml > /opt/test-pod.yaml

[root@master01 opt]# vim test-pod.yaml

[root@master01 opt]# kubectl expose deployment nginx2 --port=80 --target-port=80 --type=NodePort --dry-run=client -o yaml > /opt/testl-service.yaml

[root@master01 opt]# vim testl-service.yaml

--dry-run=client: 只是调用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的比率

m：millicores 单位

内存：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都是成功。

200<=x<400

适用于检查容器能否响应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。指定的容器的监听端口是否打开。是否能和指定的容器监听端口进行通信