19、K8S控制器-控制基础知识【理论-回顾】
1、集群基本结构图
1.1、文字介绍
k8s集群通过 master角色主机 和 node角色主机 实现集群的环境搭建，所有的资源对象都是以pod为 单元进行管理的。pod内部都是一个个相互关联的 容器对象。这些容器对象是来源于镜像仓库的镜像文件创建出来的。 也就是说，k8s主要有 控制层面和数据层面来组成： 1、控制层面 API Server - 提供数据的注册和监视各种资源对象的功能 Scheduler - 将资源对象调度到合适的节点中。 Controller - 大量控制功能的集合,他是与API Server结合起来完成控制层面操作的最重要的组成部分。 2、数据层面
2、组件基本流程图
2.1、文字介绍
k8s集群中的所有资源对象都是 - 通过 master角色主机上的各种组件进行统一管理， - 基于node角色上的kubelet组件实现信息的交流。 - pod内部的应用对象 - 基于CRI让应用本身是运行在容器内部。 - 基于CSI实现各种持久化数据的保存。 - 基于CNI实现多个pod应用程序之间的通信交流。
3、资源对象流程图
3.1、说明
对于k8s集群应用来说，所有的程序应用都是 - 运行在 Pod资源对象里面， - 借助于service资源对象向外提供服务访问。 - 借助于各种存储资源对象实现数据的可持久化 - 借助于各种配置资源对象实现配置属性、敏感信息的管理操作
4、应用编排
4.1、简介
我们在工作中为了完成大量的业务目标，首先会根据业务应用内部的关联关系，把业务拆分成多个子任务，然后对这些子任务进行顺序组合，
当子任务按照方案执行完毕后，就完成了业务目标。任务编排，就是对多个子任务执行顺序进行确定的过程。 对于k8s来说， - 对于紧密相关的多个子任务，我们把它们放到同一个pod内部， - 对于非紧密关联的多个任务，分别放到不同的pod中， - 然后借助于 endpoint+service的方式实现彼此之间的 相互调用。 - 为了让这些纷乱繁杂的任务能够互相发现自己，我们通过集群的 CornDNS组件实现服务注册发现功能。
4.2、k8s编排
对于k8s场景中的应用任务来说，这些任务彼此之间主要存在 部署、扩容、缩容、更新、回滚等。虽然
我基于pod的方式实现了应用任务的部署功能操作，但是对于我们自主式的pod来说，它并不能实现其他的几
种任务。
而这显然 距 k8s的核心功能 是有一定的距离的，因此，在k8s集群的核心功能之上，有一群非常重要的组件，
这些组件就是用于对pod实现所谓的任务编排功能，这些组件我们统统将其称为 -- 控制器。
4.3、控制器
对于控制器来说，他有很多中种类:
节点控制器(Node Controller): 负责在节点出现故障时进行通知和响应
任务控制器(Job controller): 监测代表一次性任务的 Job 对象，然后创建 Pods 来运行这些任务直至完成
端点控制器(Endpoints Controller): 填充端点(Endpoints)对象(即加入 Service 与 Pod)
服务帐户和令牌控制器(Service Account & Token Controllers): 为新的命名空间创建默认帐户和API 访问令牌
5、控制原理
5.1、Master节点组件解析
根据我们之前对各种应用程序对象的操作，比如pod、service、token、configmap等等。我们知道，这些 应用程序主要有两种在形式： 数据形态(应用程序的条目) - 存储在API Server中的各种数据条目 实体形态(真正运行的对象) - 通过kube-controller-manager到各节点上创建的具体对象。 API Server 从某种层面上来说，它仅仅是一个DB，只不过 - 它支持对资源数据条目的 watch/notify 的功能， - 它对于数据存储的格式进行了限制定制，也就是说，只能接收固定格式的数据规范。 如果我们仅仅将相关对象的属性信息插入到 APIServer上，就相当于我们做企业规划的时候，准备为某 个项目配置多少资源，而这个时候，这些资源是没有到位的，无法进行项目运行的。而kube-controllermanager就相当于企业的创始人，根据APIServer上的规划，通过招人、拉投资等方式，将一个个的具体对 象落地。 示例： 比如每一个Service，就是一个Service对象的定义，同时它还代表了每个节点上iptables或ipvs规 则，而这些节点上的规则，是由kube-controller-manager结合 kube-proxy来负责进行落地。
5.2、pod的调度
每一个Pod，就是一个应用程序的定义，同时它还代表了每个节点上资源的限制，而这些节点上的应用程 序，是由kube-controller-manager 结合 kubelet来负责进行落地。
资源在创建的时候，一般会由Scheduler调度到合适的Node节点上。这个时候，kubeServer在各个节 点上的客户端kubelet组件，如果发现调度的节点是本地，那么会在本地节点将对应的资源进行落地，同时负 责各个节点上的与APIServer相关的资源对象的监视功能。 注意，kubelet只负责单个节点上的Pod管理和调度。一旦我们需要对pod进行扩容缩容，涉及到了跨节 点的资源调度，kubelet是做不到的。对于这些更高层级的应用资源调度，我们只能通过构建在 k8s 核心基 础资源对象之上的控制资源来实现。
6、流程梳理
6.1、检查实践
cat > pod-test.yml<<'EOF' apiVersion: v1 kind: Pod metadata: name: nginx-test spec: containers: - name: nginx image: 192.168.10.33:80/k8s/my_nginx:v1 env: - name: HELLO value: "Hello kubernetes nginx" EOF master1 ]# kubectl apply -f pod-test.yml pod/nginx-test created master1 ]# kubectl get pod nginx-test -o yaml
6.2、流程梳理
1 用户向 APIserver中插入一个应用资源的数据形态 - 这个数据形态中定义了该资源对象的 "期望"状态， - 数据经由 APIserver 保存到 ETCD 中。 2 kube-controller-manager 中的各种控制器会监视 Apiserver上与自己相关的资源对象的变动 比如 Service Controller只负责Service资源的控制，Pod Controller只负责Pod资源的控制 等。 3 一旦APIServer中的资源对象发生变动，对应的Controller执行相关的配置代码，到对应的node节点上 运行 - 该资源对象会在当前节点上，按照用户的"期望"进行运行 - 这些实体对象的运行状态我们称为 "实际状态" - 即，控制器的作用就是确保 "期望状态" 与 "实际状态" 相一致 4 Controller将这些实际的资源对象状态，通过APIServer存储到ETCD的同一个数据条目的status的字 段中 5 资源对象在运行过程中，Controller 会循环的方式向 APIServer 监控 spec 和 status 的值是否 一致 - 如果两个状态不一致，那么就指挥node节点的资源进行修改，保证 两个状态一致 - 状态一致后，通过APIServer同步更新当前资源对象在ETCD上的数据
7、控制器分类
控制器 解析
ReplicationController 最早期的Pod控制器，目前已被废弃。
RelicaSet 副本集，负责管理一个应用(Pod)的多个副本状态
Deployment 它不直接管理Pod，而是借助于ReplicaSet来管理Pod；最常用的无状态应用控制器；
DaemonSet 守护进程集，用于确保在每个节点仅运行某个应用的一个Pod副本。用于完成系统级任务。
StatefulSet 功能类似于Deployment，但StatefulSet专用于编排有状态应用
Job 有终止期限的一次性作业式任务，而非一直处于运行状态的服务进程；
CronJob 有终止期限的周期性作业式任务
8、控制器 vs pod
控制器主要是通过管理pod来实现任务的编排效果，那么控制器是通过什么机制找到pod的呢？
- 标签 或者 标签选择器
