k8s 存储管理

Pod 的定义？
Pod 是 K8S 最小的创建和运行管理单元

一个Pod能包含几个容器？
1个 pause容器（基础容器、父容器、根容器）
1个或多个应用容器（业务容器）

通常一个Pod最好只包含一个应用容器，一个应用容器里最好只运行一个业务进程

同一个Pod里的容器，都是运行在同一个Node节点上的，并且共享 NET MNT PID IPC UTS 命名空间

pause容器的作用？
是作为共享 NET MNT PID IPC UTS 命名空间的基础
给Pod中的其它容器提供网络、存储资源的共享
作为Pid=1的进程(init进程)管理整个Pod中容器组的生命周期

Pod的类型 3 种
自主式Pod：由scheduler进行调度，不被控制器管理的，没有自愈能力，一旦Pod挂掉了，是不会被重新拉起
           也没有副本管理、滚动升级等功能

控制器管理的Pod：由scheduler进行调度，被控制器管理的，有自愈能力，一旦Pod挂掉了，会被重新拉起
                 有副本管理、滚动升级等功能

静态Pod：不由scheduler调度，而是由kubelet自行管理，始终与kubelet运行在同一个Node节点上，不能被直接删除
         静态Pod资源配置文件默认保存在 /etc/kubernetes/manifests ，当这个目录中有文件出现或消失时会创建或删除 静态Pod
         

Pod 中的容器 3 种
pause容器（基础容器、父容器、根容器）给Pod中容器组环境初始化，具体见上

init容器（初始化容器、init container）可以为应用容器事先提供运行环境或辅助工具；还可以阻塞或延迟应用容器的启动
                                      Pod有多个init容器时，是串行启动的，要在上一个init容器成功的完成启动、运行和退出后才会启动下一个init容器

应用容器（业务容器、main container）提供应用程序业务
                                    Pod有多个应用容器时，默认是并行启动的。应用容器要在所有init容器都成功的完成启动、运行和退出后才会启动
                                    
                                    
Pod容器镜像拉取策略 3 种    imagePullPolicy 字段位置在 spec.containers 的下一层级里
IfNotPresent ：优先使用本地已存在的镜像，如果本地则从仓库中拉取镜像
Always ：总是从仓库拉取镜像，无论本地是否已存在镜像
Never ：仅使用本地镜像，并总是不从仓库拉取镜像

image: XXX:latest  或  XXX   镜像的标签为latest或无标签时，默认的镜像拉取策略为 Always
image: XXX:xxx               镜像的标签为非latest时，默认的镜像拉取策略为 IfNotPresent

docker run 启动的容器的重启策略：
           --restart no|always|unless-stopped|on-failure:N       no为默认重启策略
                     
Pod 容器的重启策略 3 种
Always  当Pod中的容器退出时，总是重启容器，无论容器退出状态码如何。为默认的重启策略
Never   当Pod中的容器退出时，总是不重启容器，无论容器退出状态码如何
OnFailure  当Pod中的容器异常退出（容器退出状态码为非0）时，才会重启容器；正常退出（容器退出状态码为0）时不重启容器

Pod 容器的资源限制
spec.containers.resources.requests.cpu/memory    设置Pod容器创建时需要预留的资源量        容器应用最低配置 <= requests <= limits
spec.containers.resources.limits.cpu/memory      设置Pod容器能够使用的资源量上限，如容器进程内存使用量超出limits.memory会引发OOM

cpu资源量单位： cpu数 1   2   0.1   0.25      毫核 1000m   2000m   100m    250m
内存资源量单位：  整数（默认单位为字节）     2的底数单位（Ki Mi Gi Ti）    10的底数单位（K M G T）

kubectl describe node  XXX   查看node节点中 每个pod 或 总的 资源量限制
kubectl describe pod  xxx    查看Pod中 每个容器的 资源量限制

Pod 容器的探针（健康检查） 3 种
存活探针（livenessProbe）探测容器是否正常运行。如果探测失败则Kubelet杀掉容器（Pod会根据重启策略决定是否重启）

就绪探针（readinessProbe）探测Pod是否能进入ready状态（比如ready状态栏变成1/1），并做好接收请求的准备。如果探测失败则Pod会变成notready状态（比如ready状态栏变成0/1），service会删除所关联的端点（endpoints），并且不再转发请求给就绪探测失败的Pod

启动探针（startupProbe）探测容器内的应用是否启动成功。在启动探测成功之前，存活探针和就绪探针都会暂时处于禁用状态，直到启动探测成功

探针的探测方式  3 种
exec ：通过command字段设置在容器内执行的Linux命令来进行探测，如果命令返回码为0，则认为探测正常，如命令返回码为非0则认为探测失败
tcpSocket ：通过向容器的指定端口发送tcp三次握手连接请求。如果端口正确且tcp连接成功，则认为探测正常，如tcp连接失败则探测失败
httpGet ：通过向容器的指定端口和URL路径发起HTTP GET请求。如果HTTP响应返回状态码为2XX 3XX则认为探测正常，如响应返回状态码为4XX 3XX则认为探测失败

探针参数
initialDelaySeconds ：设置容器启动后延迟几秒后开始探测
periodSeconds ：每次探测的间隔时间（秒数）
failureThreshold ：探测连续失败几次后判断探测失败
timeoutSeconds ： 探测超时等待时间（秒数）

Pod 应用容器生命周期的启动动作和退出动作
spec.containers.lifecycle.postStart    配置 exec.command 字段设置 Pod 中的应用容器启动时额外的命令操作
spec.containers.lifecycle.preStop      配置 exec.command 字段设置删除 Pod 时应用容器退出前执行的命令操作

K8S是通过 List-Watch 机制实现每个组件的协作
controller-manager ，scheduler ，kubelet 通过 List-Watch 机制监听 apiserver 发出的事件，apiserver 通过 List-Watch 机制监听 etcd 发出的事件

scheduler的调度策略
预选策略 ：根据调度算法过滤掉不满足条件的Node节点，如果没有满足条件的Node节点，Pod会处于Pending状态，直到有符合条件的Node节点出现
优选策略 ：根据优先级选项为满足条件的Node节点进行优先级权重排序，最终选择优先级最高的Node节点来调度Pod

Pod 调度到指定Node节点
1、nodeName 指定Node节点名称
2、nodeSelector  指定Node节点的标签

标签的管理操作
kubectl get 资源类型 --show-labels
kubectl get 资源类型 -l 标签key[=标签value]

kubectl label 资源类型 资源名称  标签key=标签value
kubectl label 资源类型 资源名称  标签key=标签value  --overwrite
kubectl label 资源类型 资源名称  标签key-

亲和性
节点亲和性：匹配指定的Node节点标签，将Pod调度到满足指定条件的Node节点上

Pod亲和：匹配指定的Pod标签，将要部署的Pod调度到与指定Pod所在的Node节点处于 同一个拓扑域 的Node节点上
Pod反亲和：匹配指定的Pod标签，将要部署的Pod调度到与指定Pod所在的Node节点处于 不同的拓扑域 的Node节点上

硬策略：要强制性的满足指定条件，如果没有满足条件的Node节点，Pod会处于Pending状态，直到有符合条件的Node节点出现
软策略：非强制性的，会优先选择满足条件的Node节点调度，即使没有满足条件的Node节点，Pod依然会完成调度
如果硬策略和软策略同时存在，则要先满足硬策略，之后会从满足硬策略的Node节点中优先选择满足软策略的Node节点调度

怎么判断是否在同一个拓扑域？
看拓扑域key（topologyKey），如果有其它Node节点拥有与指定Pod所在的Node节点相同的 拓扑域key和值的标签，那么它们就在同一个拓扑域中

污点
kubectl describe nodes 节点名称 | grep Taints

kubectl taint node 节点名称  key=value:effect
                                       (NoSchedule一定不会被调度  PreferNoSchedule尽量不被调度  NoExecute不会被调度，并驱逐节点上的Pod)

kubectl taint node 节点名称 key[:effect]-

容忍
spec:
  tolerations:
  - key: 键名
    operator: Equal|Exists
    value: 键值
    effect: NoSchedule|PreferNoSchedule|NoExecute

不可调度
kubectl cordon 节点名称
kubectl uncordon 节点名称

不可调度+驱逐
kubectl drain 节点名称  --ignore-daemonsets --delete-emptydir-data --force

Pod 生命周期的 5 种状态
pending      Pod已经已经创建，但是至少有一个容器没有创建完成，包括Pod还未完成调度到Node节点的过程或者处于镜像拉取过程中、存储卷挂载失败
running      Pod中至少有一个容器正在运行
succeeded    Pod中的所有容器都已成功终止，并且不会再重启（Completed）
failed       Pod中的所有容器都已终止，并且至少有一个容器异常退出（Error）
unknown      无法获取Pod的状态，通常是因为Master节点与Pod所在的Node节点通信失败

Pod遵循预定义的生命周期，起始于Pending阶段，如果至少其中有一个主要容器正常启动，则进入Running阶段，之后取决于Pod中是否有容器以失败状态结束而进入Succeeded或者Failed阶段。

排障手段
kubectl get pods                        查看Pod状态
kubectl describe pod                    查看资源的详细信息和事件
kubectl logs [-c 容器名] [--previous]   查看Pod容器的日志
kubectl exec -it [-c 容器名]            进去Pod容器查看相关状态信息
kubectl debug   --target=目标Pod        临时创建Pod容器进入目标Pod进行调试

kubectl get nodes       查看Node节点状态
kubectl get cs          查看Master组件状态
kubectl cluster-info    查看集群信息

journalctl -u -f kubelet   跟踪kubelet进程日志

k8s 存储卷 volumes
emptyDir ：可实现Pod中的容器之间共享目录数据，但emptyDir存储卷没有持久化数据的能力，存储卷会随着Pod生命周期结束而一起删除

hostPath ：将Node节点上的目录/文件挂载到容器的指定目录中，有持久化数据的能力，但只能在单个Node节点上持久化数据，不能实现跨节点的Pod共享数据

nfs ：使用NFS服务将存储设备的共享目录挂载到容器的指定目录中，有持久化数据的能力，且也能实现跨节点的Pod共享数据