Kubernetes学习笔记-了解kubernetes机理-了解架构（2）20220712

继续学习kubernetes机理，了解kubernetes的架构，这篇主要讲了如下几点：

1）了解调度器

2）控制器管理器中运行的控制器

1、了解调度器

通常我们不会去指定pod应该允许在那个集群节点上，这项工作交给调度器。宏观来看，调度器操作比较简单，就是利用api服务器的监听机制等待新创建的pod，然后给每个新的、没有节点集的pod分配节点。

调度器不会命令选中的节点去运行pod，调度器做的就是通过api服务器更新pod的定义，然后api服务器再去通知kubelet该pod已经被调度过。当目标节点上的kubelet发现该pod被调度到本节点，他就会创建并运行pod的容器。

默认的调度算法

选择节点操作可以分解为两部分：

1）过滤所有节点，找出能分配给pod的可用节点列表

2）对可用节点按优先级排序，找出最优节点，如果多个节点都有最高优先级分数，那么则循环分配，确保平均分配给pod

查找可用节点

为了决定哪些节点对pod可用，调度器会给每个节点下发一组配置好的预测函数，这些函数检查：

• 节点是否能满足pod对硬件资源的请求
• 节点是否能耗尽资源（是否报告过内存／硬盘压力参数）
• pod是否要求被调度到指定节点（通过名字），是否是当前节点
• 节点是否有何破的规格定义里的节点选择器一致的标签（如果定义了的话）
• 如果pod要求绑定指定的主机端口那么这个节点上的这个端口是否已经被占用
• 如果pod要求有特定类型的卷，该节点是否能为此pod加载此卷，或者说该节点上是否已经有pod在使用该卷？
• pod是否能够容忍节点的污点。
• pod是否定义了节点、pod的亲缘性以及非亲缘性规则？如果是，那么调度节点给该pod是否会违反规则？

所有这些测试都必须通过，节点才有资格调度给pod。在对每个节点做过这些检查后，调度器得到节点集的一个子集。任何这些节点都可以运行pod，因为他们都有足够的可用资源，也确认过满足pod定义的所有要求。

为pod选择最佳节点

尽管所有节点都能运行pod，其中一些可能害是由于另一些的，假设有一个2节点集群，两个节点都可用，但是其中一个运行10过pod，而定一个，不知道什么原因，当前没有任何pod，明显调度器应该选第二个节点

pod高级调度

默认情况下，归属同一服务和ReplicaSet的pod会分散在多个节点上，但不保证每次都是这样，不过可以通过定义pod亲缘性、非亲缘规则枪支pod分散在集群内或者集中在一起。

使用多个调度器

可以在集群中运行多个调度器而非单个。然后，对每个pod，可以通过在pod特殊中设置schedulerName属性置顶调度器来调度特定的pod

未设置该属性的pod由默认调度器调度，因此其schedulerName被设置为default-scheduler。其他设置了该属性的pod会被默认调度器掉，他们要么是手动调用，要么被监听这类pod的调度器调用。

可以实现自己的调度器，部署到集群，或者可以部署有不同配置项的额外kubernetes调度器实例。

2、控制器管理器中运行的控制器

api服务器只做了存储器资源到etcd和通知客户端有变更的工作。调度器则只是给pod分配节点，需要有活跃的组件确保系统真实状态朝api服务器定义的期望的状态收敛。这个工作由控制器管理器里的控制器来实现。
单个控制器、管理器进程当前组合了多个执行不同非冲突任务的控制器。这些控制器最终会被分解到不同的进程，如果需要的话请，可以自定义实现替换他们每一个。控制器包括：

• Replication管理器（ReplicationController资源的管理器）
• ReplicaSet、DaemonSet以及Job控制器
• Deployment控制器
• StatefulSet控制器
• Node控制器
• Service控制器
• Endpoints控制器
• Namespace控制器
• PersistentVolume控制器
• 其他

控制器做了很多不同的事，但是它们都通过ali服务器监听资源（部署、服务等）变更，并且不论是创建新对象还是更新、删除已有对象，都对变更执行相应操作。
控制器利用监听机制来订阅变更强，但是由于使用监听机制并不保证控制器不会漏掉时间，所以仍然需要定期执行重列举操作来确保不会丢掉什么。
控制器之间不会直接通信，它们甚至不知道其他控制器的存在。每个控制器都连接到api服务器，通过监听机制，请求订阅该控制器负责的一系列器资源的变更。

Replication管理器
启动ReplicationController资源的控制器叫做Replication管理器，之前学到的ReplicationController是如何工作的，其实不是ReplicationController做了实际工作，而是Replication管理器。
ReplicationController的操作可以理解为一个无限循环，每次循环，控制器就会查找符合其pod选择器定义的pod的数量，并将该数值和期望复制集（Replica）数量做比较。
因为api可以监听客户端，控制器不会每次循环去轮询pod，而是通过监听机制订阅可能影响其期望的复制集（replica）数量或符合条件pod数量的变更事件。
运行的pod实例太少时，ReplicationController会创建新的pod清单，发布到api服务器，让调度器以及kubelet来做调度工作并运行pod。
Replication管理器通过api服务器操纵pod api对象来完成其工作。所有控制器就是这样运作的

Deployment控制器
负责使deployment的实际状态与对应Deployment Apu对象的期望状态同步
每次Deployment对象修改后（如果修改会影响到部署的pod），Deployment控制器都会回滚升级到新的版本，通过创建一个ReplicaSet，然后按照Deployment中定义的策略同时伸缩新、旧ReplicaSet，直到旧pod被新的代替。并不会直接创建任何pod

StatefulSet控制器
类似于ReplicaSet控制器以及其他相关控制器，根据StatefulSet资源定义创建、管理、删除pod。其他的控制器只管理pod，而StatefulSet控制器会初始化并管理每个pod实例的持久卷声明字段

Node控制器
管理Node资源，描述了集群工作节点。其中，node控制器使节点对象与集群中实际运行的机器列表保持同步。同时监听每个节点的健康状态去，删除不可达节点的pod。
node控制器不是唯一对node对象做更改的组件，kubelet也可以做更改。

Service控制器
用来在loadbalance类型服务被创建或删除时，从基础设施服务请求、释放负载均衡器的

Endpoint控制器
Service不会直接连接到pod，而是包含一个端点列表（ip和端口），列表可以是手动，也可以根据service定义的pod选择器自动创建、更新。endpoint控制器作为活动的组件，定期根据匹配标签选择器的pod的ip、端口更新端口列表。
控制器同时监听了service和pod。当service被添加、修改，或者pod被添加、修改和删除时，控制器会选中匹配service的pod选择器的pod，将其ip和端口添加到endpoint资源中。
记住，endpoint对象是个独立的对象，所以当需要的时候控制器会创建它。同样，当删除service时，endpoint对象也会被删除。

Namespace控制器
大部分资源归属于某个特定的命名空间。当删除一个namespace资源时，该命名空间里的所有资源都会被删除去。这就是namespace控制器要做的事。当前收到删除namespace对象的通知时，控制器通过api服务器删除所有归属该命名空间的资源

PersistentVolume控制器
用户创建持久卷声明，kubernetes需要找一个合适的持久卷同时将其和声明绑定。这些由持久卷控制器实现。
对于一个持久卷声明，控制器为声明查找最佳匹配项，通过选择匹配声明中的访问模式，并且声明的容量大于需求的容量的最小持久卷。实现方式是保存一份有序的持久卷列表，对于每种访问模式按照容量升序排列，返回列表的第一个卷。
当用户删除持久卷声明时，会解绑卷，然后根据卷的回收策略进行回收

唤醒控制器
所有控制器是通过api服务器来操作api对象的。它们不会直接和kubelet通信或发送任何类型的指令。实际上，它们不知道kubelet的存在。控制器更新api服务器的一个资源后，kubelet和kubernetes service proxy会做他们的工作，如启动pod容器、加载网络存储。