kubernetes 调度控制原理

1.Controller Manager

         Controller Manager 作为集群内部的管理控制中心，负责集群内的 Node，Pod 副本、服务端点（Endpoint）、命名空间（Namespace）、服务账号（ServiceAccount）、资源定额（ResourceQuota）等的管理并执行自动化修复流程，确保集群处于预期的工作状态。比如在出现某个 Node 意外宕机时，Controller Manager 会在集群的其他节点上自动补齐 Pod 副本。

        Controller Manager 内部包含 Replication Controller、Node Controller、ResourceQuota Controller、Namespace Controller、ServiceAccount Controller、Token Controller、Service Controller 及 Endpoint Controller 等多个控制器，Controller Manager 是这些控制器的核心管理者。一般来说，智能系统和自动系统通常会通过一个操纵系统来不断修正系统的状态。在 Kubernetes 集群中，每个 Controller 就是一个操纵系统，它通过 API Server 监控系统的共享状态，并尝试着将系统状态从 “现有状态”修正到“期望状态”。

        在 kubernetes  集群中与 Controller Manager 并重的另一个组件是 kubernetes scheduler，它的作用是将待调度的 Pod（包含通过 API Server 新建的 Pod 及 RC 为补足副本而创建的 Pod 等）通过一些复杂的调度流程绑定到某个合适的 Node 上。

2 Replication Controller

        为了区分 Controller Manager 中的 Replication Controller（副本控制器）和资源对象 Replication Controller，我们将资源对象 Replication Controller 简写成 RC。

        Replication Controller 的核心作用是确保在任何时候集群中一个 RC 关联的 Pod 都保持一定数量的 Pod 副本处于正常运行的状态。如果该类 Pod 的 Pod 副本数量太多，则 Replication Controller 会销毁一些 Pod 副本；反之 Replication Controller 会添加 Pod 副本，直到该类 pod 的 pod副本数量达到预设的副本数量。最好不要越过 RC 直接创建 Pod，因为 Replication Controller 会通过 RC 管理 Pod 副本，实现自动创建、补足、替换、删除 Pod 副本，这样就能提高系统容灾能力，减少由于节点崩溃等意外状况造成的损失。即使你的应用程序只用到一个 Pod 副本，我们也强烈建议使用 RC 来定义 Pod。

        Service 可能由被不同 RC 管理的多个 Pod 副本组成，在 Service 的整个生命周期里，由于需要发布不同版本的 Pod，因此希望不断有旧的 RC 被销毁，新的 RC 被创建。Service 自身及它的客户端应该不需要关注 RC。

        Replication Controller 管理的对象的 Pod，因此其操作和 Pod 的状态及重启策略息息相关。Pod 状态值如下：

        pending : API Server 已经创建该 Pod，但 Pod 内还有一个或多个容器的镜像没有创建。

        running  : Pod 内所有的容器均已创建，且至少有一个容器处于运行状态或正在启动或重启

        succeeded : Pod 内所有容器均成功中止，且不会再重启。

        failed : Pod 内所有容器均已退出，且至少有一个容器因为发生错误而退出。

        

        Pod 的重启策略包含：Always、OnFailure 和 Never。当 Pod 的重启策略 RestartPolicy = Always 时，Replication Controller 才会管理该 Pod 的操作 （列如创建，销毁，重启等）。

        通常情况下，Pod 对象被成功创建后不会消失，用户或 Replication Controller 会销毁 Pod 对象。唯一的例外是当 Pod 处于 succeeded 或 failed 状态的时间长（超时参数由系统设定）时，该 Pod 会被系统自动回收。当 Pod 副本变成 failed 状态或被删除，且其 RestartPolicy = Always 时，管理该 Pod 的副本控制器将在其他工作节点上重新创建、运行该 Pod 副本。

        为了理解 Replication Controller 的机制，我们需要先进一步理解RC。被 RC 管控的所有 Pod 实例都是通过 RC 里定义的 Pod 模板（Template）创建的，该模板包含 Pod的标签属性，同时 RC 里包含一个标签选择器（Label Selector），Selector 的值表明了该 RC 所关联的 pod。RC 会保证每个由它创建的 Pod 都包含与它的标签选择器相匹配的 label。通过这种标签选择器技术，kubernetes 实现了一种简单地过滤，选择资源对象的机制，并且这个机制被 kubernetes 大量使用。另外，通过 RC 创建的 Pod 副本在初始阶段状态是一致的，从某种意义上讲是可以完全互相替换的。这种特性非常适合副本无状态服务，当然，RC 同样可以用于构建有状态的服务。

3.Node Controller

         Node Controller 负责发现，管理和监控集群中的各个 Node 节点。Kubelet 在启动时通过 API Server 注册节点信息，并定时向 API Server 发送节点信息。API Server 接收到这些信息后，将这些信息写入 etcd。存入 etcd 的节点信息包括节点健康状况、节点资源、节点名称、节点地址信息，操作系统版本信息，docker版本，kubelete 版本等。节点健康状态包含 “就绪” （True）“未就绪”（false）和“未知”（Unknown）三种。

4.ResourceQuota Controller

        作为容器集群的资源平台，kubernetes 也提供了资源配置管理。（ResourceQuota Controller），资源配置管理确保了指定的对象在任何时候都不会超量占用系统资源，避免了由于某些业务进程的设计或实现的缺陷导致整个系统紊乱甚至意外宕机，对整个集群的平稳运行和稳定性有非常重要的作用。

        目前 kubernetes 支持如下三个层次的资源配置管理。

        （1）容器级别，可以对 cpu 和 memory 进行限制。

        （2）Pod 级别，可以对一个 Pod 内所有容器的可用资源进行限制。

         （3）NameSpace级别，为 namespace （可以用于多租户）级别的资源限制，包括：Pod数量，Replication Controller 数量，Service数量，ResourceQuota数量。Secret 数量，可持有 PV（Pesistent Volume）数量。

5.Namespace Controller

        用户通过 API Server 可以创建新的 Namespace 并保存在 etcd 中，Namespace Controller 定时通过 API Server 读取这些 NameSpace 信息。如果 Namespace 被 API 标识为优雅删除（设置删除期限，DeletionTimestamp 属性被设置），则将该 NameSpace 的状态设置为 “Terminating” 并保持到 etcd 中。同时 NameSpace Controller 删除该 NameSpace 下的 ServiceAccount、RC、Pod、Secret、PersistentVolume，ListRange、ResourceQuota 和 Event 等资源对象。

6. ServiceAccount  Controller 与 Token Controller

         这是与安全相关的两个控制器