《深入剖析Kubernetes》总结五:控制器与编排

在线任务编排

控制器(Controller):操作容器,比如Deployment,是k8s第一个重要的设计思想,叫作控制器模式

kube-controller-manager:一系列控制器的集合

$ ls -d kubernetes/pkg/controller/
deployment/ job/ podautoscaler/
cloud/ disruption/ namespace/
replicaset/ serviceaccount/ volume/
cronjob/ garbagecollector/ nodelifecycle/

该目录下的控制器遵循同一个通用编排模式:控制循环(control loop)。原理类似CAS操作,即如果对象X的实际状态等于期望状态,则可以什么都不做;如果不等于,则执行编排动作,将实际状态调整为期望状态

实际状态来源:kubelet 通过心跳汇报的容器状态和节点状态、监控系统中保存的应用监控数据,控制器主动收集的它自己感兴趣的信息等

期望状态:一般来自于用户提交的 YAML 文件

主要编排逻辑就是对比操作,被叫作调谐(Reconcile),这个调谐的过程,则被称作“Reconcile Loop”(调 谐循环)或者“Sync Loop”(同步循环);
而调谐的最终结果,往往都是对被控制对象的某种写操作。 比如,增加 Pod,删除已有的 Pod,或者更新 Pod 的某个字段,这也是 Kubernetes “面向 API 对象编程”的一个直观体现。

以Deployment为例:
在这里插入图片描述
如上图所示,类似 Deployment 这样的一个控制器,实际上都是由上半部分的控制器定义(包括期望状态),加上下半部分的被控制对象的模板组成的;
Deployment 里的 replicas=2 这个字段负责定义被管理对象的期望状态;
被控制对象的定义,则来自于一个“模板”,比如,Deployment 里的 template 字段, 这个 template 字段里的内容,跟一个标准的 Pod 对象的 API 定义是一样的,所有被这个 Deployment 管理的 Pod 实例,其实都是根据这个 template 字段的内容创建出来的。

在所有 API 对象的 Metadata 里,都有一个字段叫作 ownerReference,用于保存当前这个 API 对象的拥有者(Owner)的信息;
对于一个 Deployment 所管理的 Pod,其ownerReference为ReplicaSet,详情请继续往下看

控制器模式的实现介绍:Deployment

Deployment实现了Pod 的“水平扩展 / 收缩”(horizontal scaling out/in);
比如如果更新了 Deployment 的 Pod 模板(比如,修改了容器的镜像),那么 Deployment 就需要遵循一种叫作“滚动更新”(rolling update)的方式,来升级现有的容器。

实现方式:ReplicaSet(API对象),其结构为:

apiVersion: apps/v1
kind: Rep
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值