pod进阶:
探针*
poststart
prestop
pod的生命周期:pod的状态
k8s的重启策略
Always deployment的yaml文件只能是Always pod的yaml三种模式都可以。不论正常退场还是非正常退出都重启
OnFailure:只有状态码非0才会重启，正常退出是不重启的
Never: 正常退出和非正常退出都不重启。
这三个都是对应的容器的状态，容器退出了，pod才会重启。
pod可以有多个容器，只要有一个容器退出，整个pod都会重启。所有的pod内的所有容器都会重启。
docker的重启策略:
docker的默认策略是never。
on-failure:非正常退出时才会重启容器。
always:只要容器退出都会重启。
unless-stoppde:只要容器退出就会重启，docker的守护进程启动时，已经停止的容器，不再重启。
问单机部署:docker就够了
集群化部署；k8s，至少三个节点
yaml文件快速生成:
kubectl create deployment nginx1 --image=nginx:1.22 --replicas=3 --dry-run=client
--dry-run=client:只是调用了api的对象不执行命令
kubectl create deployment nginx1 --image=nginx:1.22 --replicas=3 --dry-run=client -o yaml > /opt/test3.yaml
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被驱赶 |
crashloopbackoff:pod当中的容器退出，kubelet正在重启
imagepullbackoff:正在重试拉取镜像
errorimagepull:拉去镜像出错了(网速太慢、镜像名字写错了、镜像仓库挂了)
Evicte:POD被驱赶(node节点的资源不够部署pod，或者是资源不足，kubelet自动选择一个pod)
如何对pod内的容器使用节点资源的限制:
1、request:pod内的容器需要的资源
2、limit:限制，最高能占用系统多少资源
写一个limit:需要多少，最多也只能占用这么多
主要两个限制
cpu:
cpu的限制格式:
1、数字加小数点：1占用一个 2两个 0.5半个 .0.2五分之一 0.3，0.1是最小单位，要么是整数，要么是小数点后只能跟一位。
2、m来表示cpu，根据cpu的时间分片原理:通过周期性的轮流分配cpu给各个进程，多个进程可以在cpu上交替执行。
在k8s中就是表示占用cpu的比率: m:millicores 单位
1000m表示1个cpu 500m半个cpu 100m是最小单位
内存:单位用Ki、Mi、Gi、Ti
给内存和cpu做资源限制
apiVersion: apps/v1
kind: Deployment
metadata:labels:app: centosname: centos
spec:replicas: 1selector:matchLabels:app: centostemplate:metadata:labels:app: centosspec:containers:- image: centos:7name: centoscommand: ["/bin/bash", "-c", "sleep 3600"]resources:limits:memory: "1Gi"cpu: "1000m"#在创建pod时，一定要给容器做资源限制。镜像的拉取策略:
默认策略:
ifNotPresent:如果本地镜像已经存在，就不再拉去，本地没有才回去镜像仓库拉取
Always:不论镜像是否存在，创建时(重启)，都会拉去镜像
Never:仅仅使用本地镜像，本地没有也不会主动拉取
如果本地部署用Never，如果涉及到外地部署，默认策略(事前要把docker的镜像导入到目标主机)，Always一般不用
apiVersion: apps/v1
kind: Deployment
metadata:labels:app: centosname: centos
spec:replicas: 1selector:matchLabels:app: centostemplate:metadata:labels:app: centosspec:containers:- image: centos:8name: centosimagePullPolicy: Alwayscommand: ["/bin/bash", "-c", "sleep 3600"]resources:limits:memory: "1Gi"cpu: "1000m"
pod容器健康检查
探针
prode
k8s对容器执行的定期诊断
探针三种规则
存活探针livenessProbe探测容器是否正常运行，如果发现探测失败，会杀掉容器，容器会根据重启策略来决定是否重启，不是杀掉pod，只是对容器。
就绪探针readinessProbe:探测容器是否进入ready状态，并做好接收请求的准备，如果探测失败 READY 0/1 没有进入ready状态，但是status还是running状态，但是不可用，service会把这个资源对象的端点从当中剔除。service也不会把请求转发到这个pod
启动探针starupProbe:只是在容器的启动后开始检测，容器内的应用是否启动成功。在启动探测成功之前，所有的其他探针都会处于禁用状态。
但是一旦启动探针结束，后续的操作就不在受启动探针的影响。
在一个容器当中可以有多个探针
第一个启动太真:只在容器启动时探测 、存活探针、就绪谈着
probe的检测方法：
1、exec探针:需要在容器内部执行命令，如果命令返回码0表示成功
适用于在容器内部自定义命令来检查容器的健康状态。
2、httpGet:就是对指定ip+端口的容器发送一个httpGet的请求。响应状态码大于等于200，但是小于400都是成功。400< x >=200
主要时适用于检查容器能否响应http的请求，web容器(nginx,tomcat)
3、tcpSocket:检查端口，对指定端口上的容器的ip地址进行tcp检查(三次握手)，端口打开，认为探测成功。 适用于检查特定容器端口的监听状态。 类似于telnet
诊断结果:
1、成功，容器通过了，正常运行
2、失败，只有存活探针会重启
3、未知状态:也是诊断失败
exec方式:
LivenessProbe: exec: command: ["/usr/bin/test", "-e", "/opt/123.txt"
#周期性探测命令，表示容器启动之后多少秒来进行探测，时间不要设置太短，否则容器还>没启动好就探测，可能导致无效探测 initialDelaySeconds: 5 #表示探针探测的间隔时间。每隔多少秒进行一次检查,看应用的延迟敏感度，这个应用非常 重要，是要给核心组件， periodSeconds: 2 #表示如果探测失败，失败几次，把容器标记为不健康 failureThreshold: 2 #只要成功一次即可就标记为就绪，健康或者ready successThreshold: 1 #表示每一次探测的超时时间，在多少秒内必须完成探测，不能比perioSeconds大 timoutSecond: 1
liveness杀死容器重启，所有探针策略伴随整个pod的生命了，除了启动探针
apiVersion: v1
kind: Pod
metadata:labels:run: nginx1name: nginx1
spec:containers:- image: tomcat:8.0.52name: nginx1livenessProbe:httpGet:scheme: HTTPport: 8080path: /index.jspinitialDelaySeconds: 4periodSeconds: 2总结
探针三个方法
存活探针：检测失败之后，会杀死容器然后重启
探针将伴随整个容器的生命周期
exec相当于执行了一个shell命令:容器里面执行
返回码为0，表示成功，成功1次就是探测成功
httpGet:对外部容器发起了一次get请求，可以添加path指定访问的资源
返回码在大于等200小于400都算成功
tcpSocket：相当于telnet，指定的容器监听端口是否打开，是否能和指定的容器监听端口进行通信
