跳到主要内容

8、控制器

控制器

前面我们一起学习了 Pod 的原理和一些基本使用,但是在实际使用的时候并不会直接使用 Pod,而是会使用各种控制器来满足我们的需求,Kubernetes 中运行了一系列控制器来确保集群的当前状态与期望状态保持一致,它们就是 Kubernetes 的大脑/心脏。例如,ReplicaSet 控制器负责维护集群中运行的 Pod 数量Node 控制器负责监控节点的状态,并在节点出现故障时及时做出响应总而言之,在 Kubernetes 中,每个控制器只负责某种类型的特定资源

通过前面的课程学习我们知道了 master 的各组件中,API Server 仅负责将资源存储于 etcd 中,并将其变动通知给各其他组件,如 kubelet、kube-scheduler、kube-proxy 和 kube-controller-manager 等。kube-scheduler监控到处于未绑定状态的 Pod 对象出现时就启动调度器为其挑选最合适的工作节点。另外 Kubernetes 的核心功能之一还在于要确保各资源对象的当前状态(status)已匹配用户期望的状态(spec),使当前状态不断地向期望状态**“调谐”(Reconcile)**来完成容器应用管理,这些就是 kube-controller-manager 的任务,kube-controller-manager是一个独立的组件,但是它却包含了很多功能不同的控制器。

img

Kubernetes 控制器会监听资源的 创建/更新/删除 事件,并触发 Reconcile 调谐函数作为响应,整个调整过程被称作 “Reconcile Loop”(调谐循环) 或者 “Sync Loop”(同步循环)。**Reconcile 是一个使用资源对象的命名空间和资源对象名称来调用的函数,使得资源对象的实际状态与 资源清单中定义的状态保持一致。调用完成后,Reconcile 会将资源对象的状态更新为当前实际状态。**我们可以用下面的一段伪代码来表示这个过程:

for {
desired := getDesiredState() // 期望的状态
current := getCurrentState() // 当前实际状态
if current == desired { // 如果状态一致则什么都不做
// nothing to do
} else { // 如果状态不一致则调整编排,到一致为止
// change current to desired status
}
}

这个编排模型就是 Kubernetes 项目中的一个通用编排模式,即:控制循环(control loop)

创建为具体的控制器对象之后,每个控制器均通过 API Server 提供的接口持续监控相关资源对象的当前状态,并在因故障、更新或其他原因导致系统状态发生变化时,尝试让资源的当前状态向期望状态迁移。简单来说,每个控制器对象运行一个调谐循环负责状态同步,并将目标资源对象的当前状态写入到其 status 字段中。

img

实现调谐功能是依靠的 Kubernetes 实现的核心机制之一的 List-Watch,在资源对象的状态发生变动时,由 APServer 负责写入 etcd 并通过水平触发机制主动通知给相关的客户端程序以确保其不会错过任何一个事件。控制器通过API Server 的 Watch 接口实时监控目标资源对象的变动并执行调谐操作,但并不会与其他控制器进行任何交互。

工作负载(workload)一类的控制器资源类型包括 ReplicaSet、Deployment、DaemonSet、StatefulSet、Job 和CronJob 等,它们分别代表了一种类型的 Pod 控制器资源,接下来我们将分别介绍这些工作负载控制器的使用。

img

img

  • k8s常见的3种类型控制器

deployment应用场景:部署无状态应用,例如网站、API、微服务 daemonset应用场景:部署节点守护进程应用,例如监控agent、日志agent statefulset应用场景:部署有状态应用,例如mysql主从、zookeeper集群、etcd集群