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