Pod的生命周期开始
| 1 | k8s的pod重启策略：Always(默认，deployment的yaml文件只能是Always)pod的yaml文件三种模式都可以，不论正常退出还是非正常退出都重启 |
| 2 | OnFailure:只有状态码非0才会重启，正常退出是不重启的 |
| 3 | Never：正常退出和非正常退出都不重启 |
| 这三个状态都是容器退出了pod才会重启或不重启 Pod可以有多个容器，只要有一个容器退出，整个pod都会重启，pod内 的所有容器都会重启 |
docker的重启策略
| never | Docker：的默认策略是never |
| on-Failure | 也就是非正常退出才会重启容器 |
| always | 只要容器退出都会重启 |
| Unless-stopped | 只要容器退出就会重启，docker守护进程已经停止的容器，不再重启 |
Yaml文件快速生成
[root@master01 ~]# kubectl create deployment nginx1 --image=nginx:1.22 --replicas=1 --dry-run=client
deployment.apps/nginx1 created (dry run)
[root@master01 ~]# kubectl create deployment nginx1 --image=nginx:1.22 --replicas=1 --dry-run=client -o yaml > /opt/test1.yaml
#--dry-run=client 表示只是调用了api的对象，不执行命令 ， -o yaml表示指定为yaml文件
[root@master01 opt]# kubectl expose deployment nginx-chen --port=80 --target-port=80 --type=NodePort --dry-run=client -o yaml > /opt/test1-service.yaml
#生成service模版Pod状态
常见
| Crashloopbackoff： 表示pod当中的容器已经退出，kubelet正在重启 Imagepullbackoff： 表示正在重试拉取镜像 Errimagepull： 拉取镜像出错了，原因：网速太慢，镜像名字写错了，镜像仓库挂了 Evicte： pod被驱赶，node节点上的资源不够部署pod或者资源不足，kubelet自动选择一个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被驱赶 |
Pod内的容器使用节点资源的限制
| request | 需要的资源 |
| Limit | 限制最高能占用系统多少资源 Limit：需要多少，最多也只能占用这么多 两个限制： Cpu：cpu的限制格式：1，2，0.5,0.2,0.3 1表示可以占用1个cpu 2可以占用2个cpu 0.5可以占用半个 0.2：一个cpu的五分之一 0.1是最小单位 要么是整数，要么就是小数点后只能跟一位，最小单位0.1 m来表示cpu Cpu时间分片原理：cpu时间分片，通过周期性的轮流分配cpu时间给各个进程，多个进程可以在cpu上交替执行，在k8s中就是表示占用cpu的比率：m：millicores：单位1000m表示1个cpu，其他以此类推 |
| 内存 | 内存：都是大写开头后面小写 Ki Mi Gi Ti |
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: centos
name: centos
spec:
replicas: 1
selector:
matchLabels:
app: centos
template:
metadata:
labels:
app: centos
spec:
containers:
- image: centos:7
name: centos
resources:
limits:
memory: "1Gi"
cpu: "1"
#在创建pod时，一定要给容器做资源限制
k8s怎么设置拉取镜像的策略
| ifNotPresent | 果本地镜像有，就不再拉取，本地没有才会去镜像仓库拉取（默认策略） |
| Always | 不论镜像是否存在，创建时(重启)都会拉取镜像 |
| Never | 仅仅使用本地镜像，本地没有也不会主动拉取 |
| 如果都是本地部署，那么用Never 如果涉及到外部部署，默认策略（事前要把docker的镜像导入到目标主机） Always：一般不用 |
pod的容器健康检查
| 探针 Probe k8s对容器执行的定期诊断检查 探针有三种规则 | |
| 存活探针 | livenessProbe，探测容器是否正常运行，如果探测失败，会杀掉容器，容器会根据重启策略来决定是否重启，不是杀掉pod，只对容器 |
| 流量探针/就绪探针 | 探测容器是否进入ready状态，并做好接收请求的准备，如果探测失败 READY 0/1没有进入ready状态，service会把这个资源对象的端点从endpoints中移除，service也不会把请求转发到这个pod |
| 启动探针 | 只是在容器的启动后开始检测，容器内的应用是否启动成功，在启动探测成功之前，所有的其他的其他探针都会处于禁用状态，一旦启动探针结束，后续的操作不再受启动探针的影响 |
| 结论：在一个容器当中可以有多个探针，启动探针只在容器启动时探测，存活探针，就绪探针 |
probe的检查方法
| exec探针 | 在容器内部执行命令，如果命令的返回码是0，表示成功，适用于需要容器neutral自定义命令来检查容器的健康状态情况 Exec相当于执行了一个shell命令：容器里面执行 Shell命令执行成功： 返回码：0表示成功 成功一次就是探测成功 |
| httpGet | 对指定ip+端口的容器发送一个httpget的请求，响应状态码大于等于200，小于400都是成功x>=200<400，适用于检查容器能否响应http的请求，web容器(nginx,tomcat) 对web容器发起了一次get请求，可以添加path，指定访问的资源，返回码在大于等于200，小于400的范围内都算成功 |
| tcpSocket | 端口，对指定端口上的容器ip地址进行tcp检查(三次握手)，端口打开，认为探测成功，检查特定容器的端口监听状态 相当于telnet，指定的容器监听端口是否打开，是否能和指定的容器监听端口进行通信 |
| 诊断的结果 1.成功，容器通过了，正常运行 2.失败，存活探针会重启 3.未知，诊断失败 |
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: centos
name: centos
spec:
replicas: 1
selector:
matchLabels:
app: centos
template:
metadata:
labels:
app: centos
spec:
containers:
- image: centos:7
name: centos
command: ["/bin/bash","-c", "touch /opt/123.txt ; sleep 3600"]
livenessProbe:
exec:
command: ["/usr/bin/test","-e", "/opt/123.txt"]
initiaDelaySeconds: 3
#表示容器启动之后多少秒来进行探测，时间不要设置的太短，可能导致无效探测
periodSeconds: 2
#表示探针探测的间隔时间，每隔多少秒进行一次检查，应用的延迟敏感度，这个应用非常重要，是核心组件
failureThreshold: 2
#表示如果探测失败，失败几次之后，把容器标记为不健康
successThreshold: 1
#只要成功一次就标记位就绪，健康，ready
timeoutSeconds: 1
#表示每次探测的超时时间，在多少秒内必须完成探测
#liveness，杀死容器重启，所有的探针策略伴随整个pod的生命周期，除了启动探针