k8s集群事件监控 k8s集群性能监控方案

1、scheduler：负责调度资源，把pod调度到指定的node节点

（1）预算策略

（2）优先策略

2、List-watch

（1）在k8s集群中，通过List-watch的机制进行每个组件的协作，保持数据同步，每个组件之间的解耦（减少每个组件之间的关联性）

（2）kubectl配置文件，向APIserver发送命令，apiserver把命令发送到各个组件

①kubectl run xx——apiserver——controller manager——scheduler——kubelet

②创建成功之后，kubectl get/describe/ pod——保存etcd的数据库中

（3）List-watch会在每一步把监听的消息（APIserver：6443），每个组件（controller manager、scheduler、kubelet、etcd）都会监听apiserver的6443端口

4、调度的过程和策略

（1）scheduler是k8s集群的调度器，把pod分配到集群的节点

①公平：每个节点都能分配到资源

②资源高效利用：集群中的资源可以被最大化使用

③效率：调度的性能要好，能够尽快的完成大批量的pod的调度工作

④灵活：允许用户根据自己的需求，控制和改变调度的逻辑

（2）scheduler是一个单独运行的程序，启动之后就会一直监听apiserver，获取报文中的字段：spec.node name，创建pod时，会为每一个pod创建一个binding（表示该往哪个节点上部署）

（3）创建pod到节点时，有两个策略，先执行预算策略，再执行优先策略，这两步的操作都必须成功，否则立即返回报错，也就是，部署的node必须满足这两个策略

预算策略：predicate自带一些算法，选择node节点（scheduler自带的算法策略，不需要人工干预）
podfitsresources	pod的适应资源：检测节点上的剩余资源，是否满足pod请求的资源（主要是CPU和内存）
podfitshost	pod适应主机：如果pod指定了一个node的name，指定节点后，来检测主机名是否存在，存在要和pod指定的名称相匹配，这才能调度过去
podselectormatches	pod选择器匹配：创建pod的时候可以根据node节点的标签来进行匹配，查找指定的node节点上标签是否存在，存在的标签是否匹配
nodiskconflict	无磁盘冲突：确保已挂载的卷和pod的卷不发生冲突。如发生冲突，会重新选择一个节点部署，除非目录是只读目录，只读目录会直接覆盖
如果预算策略无法满足，pod将始终处于pending状态，不断的重试调度，直到有节点满足条件为止
优先策略：
leastrequestedpriority		最低请求优先级：通过算法计算节点上的CPU和内存使用率，确定节点的权重，使用率越低的节点相应的权重越高，调度时会更倾向于使用率低的节点，实现资源合理的利用
balanceresourceallocation		平衡资源分配：CPU和内存的使用率，给节点赋予去昂走动，权重是CPU和内存的使用率接近，权重越高，和上面的leastrequestedpriority最低请求优先级一起使用
imagelocalitypriority		节点上是否己经有了要部署的镜像：镜像的总数成正比，满足的镜像数越多，权重越好，调度时优先级就越高
通过预算选择可以部署的节点，再通过优先选择出最好的节点，以上的策略都是自动的，scheduler自带的算法，k8s集群自己来选择

5、指定节点和标签

（1）指定节点（不经过scheduler调度算法、强制匹配）

①spec参数设置：nodeName:node2

②指定了节点，在参数中设置了nodeName，指定了节点的名称，会跳过scheduler的调度策略，这个规则是强制匹配

（2）指定标签（经过scheduler调度算法）

* 只要是走调度算法，在不满足预算策略的情况下，所有pod都是pending

①spec参数设置：nodeSelector:node2

②查看所有节点的标签：kubectl get nodes --show-labels

③创建节点标签：kubectl label nodes master test1=a

④查看已经部署的服务选择的标签：kubectl get deployments.apps -o wide

⑤根据指定标签部署pod：

⑥指定节点标签部署pod，要经过scheduler的调度算法，如果节点不满足条件，pod会进入pending状态，直到节点满足条件为止

⑦修改标签值：kubectl label nodes node1 test=3

⑧删除标签值：kubectl label nodes node1 test-

6、亲和性

（1）节点亲和性

（2）pod亲和性

①软策略和硬策略

②软策略：多个软策略看权重，权重高，执行指定的软策略

③软硬策略结合：先满足硬策略，再满足软策略

（3）node节点的亲和性

preferredDuringSchedulingIgnoredDuringExecution：软策略 选择node节点是，声明了最好能部署在node1，软策略会尽量满足这个条件，不一定会完全部署在node1节点上

requiredDuringSchedulingIgnoredDuringExecution：硬策略 选择pod时，声明了node1，选择硬策略，必须满足硬策略的条件，必须部署在node1，强制性要求，根据节点的标签匹配

（4）pod的亲和性

preferredDuringSchedulingIgnoredDuringExecution：软策略 要求调度器将pod调度到其他pod的亲和性匹配的节点上，可以是，也可以不是，尽量满足，不是一定满足

requiredDuringSchedulingIgnoredDuringExecution：硬策略 要求调度器将pod调度到其他pod的亲和性匹配的节点上，必须是

（5）键值的运算关系

标签，都是根据标签来选择亲和性
In	在，选择的标签值在node节点上存在
Notin	不在，选择label的值不在node节点上的
Gt	大于，大于选择的标签值（只能比较整数值）
Lt	小于，小于选择的标签值（只能比较整数值）
Exists	存在，选择标签对象，值不考虑（不能使用value字段）
DoseNotExist	不存在，选择不具有指定标签的对象，值不考虑（不能使用value字段）

（6）node节点的亲和性之硬策略

①In策略

②Notin策略（不能有标签为test1的节点）

③Gt策略

④Lt策略

⑤Exists策略

⑥DoseNotExist策略

（7）node的亲和性之软策略

（8）node的亲和性之多个软策略、看权重

（9）node的亲和性之软策略和硬策略结合

①第一种

②第二种

③第三种

④第四种

⑤第五种

⑥第六种

⑦第七种

7、pod的亲和性和反亲和性

（1）pod和node的亲和性

①拓扑域：k8s集群节点当中的一个组织结构，可以根据节点的物理关系或者逻辑关系进行划分，可以用来表示节点之间的空间关系，网络关系或者其他类型的关系

pod和node的亲和性
调度策略	node的亲和性	pod的亲和性	pod的反亲和性
匹配标签	主机标签	pod的标签	pod的标签
操作符	In NotIn Exists DoesNotExsit Gt Lt	In NotIn Exists DoesNotExsit	In NotIn Exists DoesNotExsit
拓扑域	不支持	支持	支持
调度目标	指定主机	pod和指定标签的pod部署在同一拓扑域	pod和指定标签的pod部署在不同拓扑域

（2）pod的亲和性

①创建pod标签

②创建节点标签

③配置deployment

④第二种

⑤第三种

* 基于deployment创建的pod修改标签，不可以直接apply -f，要把前一个标签的资源对象删除，再创建新的deployment

⑥软策略：preferredDuringSchedulingIgnoredDuringExecution

（3）pod的反亲和性（使用较少，类似于亲和性的NotIn）

（4）总结

①pod的亲和性策略，在配置时，必须要加上拓扑域的关键字topologykey（指向的是节点标签）

②pod亲和性的策略分为硬策略和软策略

③pod亲和性的notin可以替代反亲和性

④pod亲和性的作用主要是为了把相关联的pod部署在同一节点（类似lnmp）

8、污点

（1）在进行部署的时候，如何考虑node节点：软硬策略、污点和容忍

①污点和容忍可以配合node的亲和性一起使用，污点是node调用机制，不是pod

被设为污点的节点，不会部署pod

②污点和亲和性相反，亲和性是尽量选择和一定选择，污点的节点一定不被选择？

（2）污点（taint）的类型

NoSchedule	k8s不会把pod调度到这个节点上
PreferNoSchedule	此类型的污点，尽量避免把pod部署在改节点上，不是一定（master节点的污点一般就是PerferNoSchedule）
NoExecute	此类型的污点，k8s将会把该节点上的pod全部驱逐，而且也不会调度到这个节点
①基于控制器创建的pod，虽然被驱逐，会在其他节点重新部署 ②自主创建的pod会被直接杀死

（3）查看污点：kubectl describe nodes master | grep -i taints

（4）设置污点：kubectl taint node master key=1:NoSchedule

（5）删除污点：

①kubectl taint node node2 key:PreferNoSchedule-

（6）NoExecute（驱逐、慎重）

①NoExecute的使用场景：资源回收或节点维护

* 节点服务器需要维护的，服务器关机，节点上pod将会失效。在工作中，主要部署pod的方式是控制器部署、deployment部署最多。一旦节点设置为驱逐，控制器创建的pod会在其他节点重新部署，NoExecute主要用于：资源回收或节点维护

* 使用NoExecute，所有的pod都会被驱逐，所有的一切都会被驱逐，kube-proxy属于组件pod，依旧存在

* 不论创建方式是什么，都会被驱逐，系统集群组件不会被驱逐

9、容忍机制：表示可以部署pod在有污点的节点上

（1）配置容忍机制

①设置污点

②配置容忍

（2）NoExecute的容忍机制：设置时间限制

①NoExecute依然可以部署pod，但是有生命周期，pod会被销毁，生命周期结束后会驱逐一部分pod到其他节点

②NoExecute的容忍机制：该节点维护完毕，测试一下该节点的工作是否正常

（3）污点的容忍机制

①不指定节点标签key，指定污点类型effect

②指定节点标签key，不指定污点类型effect：所有节点上只要有key，都容忍

（4）总结

①指定key的值、节点的标签值，但是不指定污点的类型，那么所有节点上只要包含这个指定的标签名，可以容忍所有的污点

②不指定key的值，不匹配节点的标签，但是指定污点类型，容忍所有指定类型的污点

（5）node的亲和性、pod的亲和性和反亲和性、污点和容忍：作用：如何选择node节点部署pod，选择一个期望的节点部署pod

①多个master节点:kubectl taint node master节点名称 ： node-role.kubernetes.io/master=:PreferNoSchedule尽量不往master节点上部署pod,但是不是一定的，防止资源浪费，自定义一个标签。

②业务维护： node2需要维护2小时，但是这个节点还有业务pod在运行，就需要把这个节点的污点设置为：noexecute，部署pod一般都是使用deployment部署，会在其他的节点重新部署，并不是被杀死，自主式的pod会被杀死。一旦节点恢复，一定要把污点删除

10、cordon和drain

（1）cordon：可以直接把节点标记为不可用状态

①设置cordon：kubectl cordon master node1

②取消cordon：kubectl uncordon master node1

（2）drain：把该节点下的pod全部转移到其他的node节点上运行

①一旦指定drain，被执行的节点不会变成不可调度状态

②会驱逐该节点上的所有pod

③kubectl drain node1 --ignore-daemonsets --delete-local-data --force

drain	驱逐，标记node节点为不可调度，然后驱逐pod
--ignore-daemonsets	无视daemonset部署的pod，此类pod还在节点上 daemonset部署的一般是重要的后台运行的、系统pod，所以不动
--delete-local-data	有本地挂载卷的pod会被强制杀死
--force	强制释放不是控制器管理的pod（不是控制器管理的pod会被杀死）

④删除drain：kubectl uncordon node1