kubernetes之亲合性调度

目录
实验环境
实验软件
本节实践
调度
创建一个Pod的工作流程
- 1.架构图
- 2.剖析过程
- 3.Pod中影响调度的主要属性
- 4.调度器需要充分考虑诸多的因素
- 5.Kubernetes中的资源分配
- 6.Init container的资源需求
1、nodeSelector
2、亲和性和反亲和性调度
- 1.节点亲和性
- 2.pod 亲和性和pod 反亲和性
3、污点与容忍
4、nodeName
思考
- 1.不用 DaemonSet，如何使用 Deployment 是否实现同样的功能？
- 2.同样的如果想在每个节点（或指定的一些节点）上运行2个（或多个）Pod 副本，如何实现？
关于我
最后

实验环境

实验环境：
1、win10,vmwrokstation虚机；
2、k8s集群：3台centos7.6 1810虚机，1个master节点,2个node节点k8s version：v1.22.2containerd://1.5.5

实验软件

链接：https://pan.baidu.com/s/1P3Z_ujk22dYDXzM37WI5FA?pwd=v01w
提取码：v01w

2022.2.18-39.亲合性调度-实验代码.zip

本节实践

实践：nodeSelector测试(测试成功)-2022.5.16
实践：节点亲和性测试(测试成功)-2022.5.16
实践：pod亲和性(测试成功)-2022.5.16
实践：pod反亲和性(测试成功)-2022.5.16
实践：污点与容忍(测试成功)-2022.5.16
实践：nodeName测试(测试成功)-2022.5.16

调度

一般情况下我们部署的 Pod 是通过集群的自动调度策略来选择节点的，默认情况下调度器考虑的是资源足够，并且负载尽量平均。但是有的时候我们需要能够更加细粒度的去控制 Pod 的调度，比如我们希望一些机器学习的应用只跑在有 GPU 的节点上；但是有的时候我们的服务之间交流比较频繁，又希望能够将这服务的 Pod 都调度到同一个的节点上。这就需要使用一些调度方式来控制 Pod 的调度了，主要有两个概念：亲和性和反亲和性，亲和性又分成节点亲和性(nodeAffinity)和 Pod 亲和性(podAffinity)。

创建一个Pod的工作流程

1.架构图

Kubernetes基于list-watch机制的控制器架构，实现组件间交互的解耦。
其他组件监控自己负责的资源，当这些资源发生变化时，kube-apiserver会通知这些组件，这个过程类似于发布与订阅。

2.剖析过程

我们通过命令行创建一个pod：

当我们在执行命令kubectl run pod4 --image=nginx后，各组件之间的调用流程是如何的呢？

1、kubectl向apiserver发送一个创建pod的请求
2、apiserver接收到并向etcd写入存储，写入成功返回一个提示#这个过程类似于老板和顾客之间的关系:api-server:开店老板etcd：仓库其他组件：顾客

注意：如果在执行如下kubectl run pod4 --image=nginx命令时，卡着了，说明什么问题呢？

–>说明：
etcd数据库写入有问题/达到性能瓶颈，或者，api-server和etcd 2者总有一个有问题：

继续：scheduler向apiserver查询未分配的pod资源，通过自身调度算法选择一个合适的node进行绑定（给这个pod资源打一个标记，标记分配到node1）注意：它这个调度算法还是比较复杂、均匀一点的，它会考虑到你的机器的硬件配置，pod属性等等一些综合的属性；

问题：如果scheduler组件有问题，那么此时pod会出现什么状态？

答：pod会出现通过kubectl get pod根本看不到你刚创建的pod信息的，更别说它的状态了，因为它根本没分配。

因此，如果你创建的pod信息根本看不到，那么会是哪个组件可能有问题？–>scheduler组件可能出在问题。

如果是pending状态：pod是已经绑定到某个节点了。
继续流程讲解：

4、kubelet向apiserver查询分配到自己节点的pod，调用docker api（/var/run/docker.sock）创建容器
5、kubelet获取docker创建容器的状态，并汇报给apiserver，apiserver更新状态到etcd存储
6、kubectl get pods就能查看pod状态备注：
kubelet的功能主要是管理容器：这个是默认调用的docker api接口
[root@k8s-master ~]#ll /var/run/docker.sock
srw-rw---- 1 root docker 0 Jun 14 11:46 /var/run/docker.sock

问题：controller-manager为什么没用到?

controller-manager是用于管理控制器，例如deployment（rs）、service，因为创建的是一个pod，不受它管理。

如果controller-manager要放在这里，一般是放在etcd后面的：

kube-proxy为什么没用到？

proxy是用于管理pod网络，例如service，因为没创建service。

kube-proxy的主要功能就是维护好service，service是k8s的抽象资源；

扩展

比如，这个容器创建的时候创建失败了，不是一个running状态，也不是一个pending状态。可能就是docker在启动容器时，用你那个镜像启动容器失败了。所以这是你需要用docker去run一个镜像看能不能起来。

3.Pod中影响调度的主要属性

⚠️ 注意

resources: {} 资源调度依据这个，挺重要的；
很多大厂都会去二开"schedulerName: default-scheduler"这个调度器的，会去加一些调度策略，进而完成他们的需求；