k8s的pod重启策略
1，Deploy 的yaml文件只能是always。Pod的 yaml三种模式都可以。
2，OnFailure：只有状态码非0才会重启。正常状态不重启的。
3，Never：正常退出和非正常退出都不重启。容器退出了，pod才会重启。
Pod可以有多个容器，只要有一个容器退出，整个pod都会重启，pod内的所有容器都会重启。
Docker的重启策略：
- docker的默认策略是never。
- on-failure：非正常退出。才会重启容器
- Always：只要容器退出都会重启
- Unless-stopped：只要容器退出就会重启，docker守护进程时已经停止的容器，不再重启。
单机部署：docker足够了
集群化部署：k8s
Yaml文件快速生成模版：
–dry-run=client：只是调用api的对象不执行命令
生成pod 的yaml模版
生成service的yaml模版
pod的状态：
Crashloopbackoff：pod当中的容器退出。Kubelet正在重启。
Imagepullbackoff：正在重试拉取镜像。
Errimagepull：拉取镜像出错了（1网速太慢，2镜像名称写错，3镜像仓服务器托管网库挂了）
Evicte：pod被驱赶（node节点的资源不够部署pod，或者是资源不足，kubelet自动选择一个pod驱逐）
InvalidImageName： 无法解析镜像名称
ImageInspectError： 无法校验镜像
ErrImageNeverPull： 策略禁止拉取镜像
ImagePullBackOff： 正在重试拉取
RegistryUnavailable： 连接不到镜像中心
ErrImagePull： 通用的拉取镜像出错
CreateContainerConfigError： 不能创建kubelet使用的容器配置
CreateContainerError： 创建容器失败
m.internalLifecycle.PreStartContainer 执行hook报错
RunContainerError： 启动容器失败
PostStartHookError： 执行hook报错
ContainersNotInitialized： 容器没有初始化完毕
ContainersNotReady： 容器没有准备完毕
ContainerCreating： 容器创建中
PodInitializing：pod 初始化中
DockerDaemonNotReady： docker还没有完全启动
NetworkPluginNotReady： 网络插件还没有完全启动
如何对pod内的容器使用节点资源的限制：
- request：需要的资源
- Limit：最高能占用系统多少资源。 limit：需要多少，最多也只能这么多。
对pod的两个限制:
cpu 内存
Cpu：在k8s集群中限制格式：
- 数字加小数点 1可以占用一个CPU 2可以占用两个 0.5占半个CPU 0.2一个CPU的五分之一 要么是整数，要么就是小数点后只能跟一位，最小单位0.1
m来表示CPU
CPU时间分片原理：通过周期性的轮流分配CPU时间给各个进程。多个进程可以在CPU上交替执行。在k8s中就是表示占用的CPU的比率。
M：millicores单位。 100m就是最小单位。
内存：
Ki Mi Gi Ti 注意大写的。
在创建pod时一定要给容器资源做限制。
k8s怎么设置镜像的拉取策略：
默认策略：
IFNotPresent：如果本地镜像有，就不再拉取，本没有才会去镜像仓库拉取。
Always：不论镜像是否存在，创建时（重启）都会重新拉取镜像。
Never：仅仅使用本地镜像，本地没有也不会主动拉取。
Pod的容器健康检查：
探针
Probe
K8s对容器执行的定期检查，诊断。
探针有三种规则：
1，存活探针：livenessProbe，探测容器是否正常运行，如果发现探测失败，会杀容器，容器会根据重启策略来决定是否重启，不是杀掉pod。
2，就绪探针：探测容器是否进入ready状服务器托管网态，并做好接受请求的准备。
探测失败 READY 0/1 容器当前没有进入ready状态，service会把这个资源对象的端点从当中剔除2，service也不会把请求转发到pod。
3，启动探针：只是在容器的启动开始检测之后开始检测，容器内的应用是否启动成功。在启动探测成功之前，所有的其他的其他探针会处于禁用状态。但是一个启动探针结束，后续的操作不再受启动探针的影响。
在一个容器当中可以有多个探针。
启动探针：只在容器启动时探测
Probe的检测方法：
- exec探针：在容器内部执行命令，如果命令的返回码是0，表示成功。适用于需要在容器内自定义命令来检查容器的健康状况。
- httpGet：指定ip+端口的容器发送一个httpget的请求。响应状态码大于等于200，小于400都是成功。200-400 x >=200
- tcpSocket: 端口，对指定端口上的容器的ip地址进行tcp检查（三次握手）端口打开，认为探测成功。 检查特定容器的端口监听状态。
诊断结果：
- 成功 容器通过了，正常运行。
- 失败 存活探针会重启。
- 未知状态 诊断失败。
总结：
探针的三个方法：
存活探针：检查失败之后，会杀死容器，然后重启。探针将伴随整个容器的生命周期。
Exec 相当于执行了一个shell命令：容器里面执行
Shell命令执行成功。
返回码：0表示成功。
成功一次就是探测 成功
Httpcet：对web容器发起一次get请求，可以添加path，指定访问的资源。返回码在大于等于200，小于400 的范围之内都算成功
tcpSocket：相当于 指定的容器监听端口是否打开，是否能和指定的容器监听端口进行通信。
服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
相关推荐: 【SpringCloud】-GateWay源码解析
GateWay系列 【SpringCloud】-GateWay网关 一、背景介绍 当一个请求来到 Spring Cloud Gateway 之后，会经过一系列的处理流程，其中涉及到路由的匹配、过滤器链的执行等步骤。今天我们来说说请求经过 Gateway 的主要…
