探针*
容器钩子：
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。指定的容器的监听端口是否打开。是否能和指定的容器监听端口进行通信
