当在k8s管理大量的应用时，这些应用之间存在大量的关系，紧密关系可以将其组织在同一个Pod中进行，而非紧密关系的应用之间则需要借助服务注册和服务发现将其关联起来，在K8s中实现服务注册和服务发现功能是由CoreDNS来实现的。

有时候各种应用之间存在各种复杂的关系，这时候就需要借助Service来实现应用的管理。

应用编排的核心

所谓应用编排的核心就是应用的部署，扩展，更新，回滚

  • 部署：在k8s中应用部署是由应用清单来定义的。
  • 扩展：应用部署的核心还有扩展，扩展就是扩容，扩容又两种方法垂直扩容和横向扩容。在k8s中垂直扩容是指调大pod的资源限制。而横向扩容则是指多扩展几个pod副本。
  • 更新：在如今敏捷开发的环境下，更新的速度将是非常快，我们要随时迭代旧的版本。
  • 回滚：当更新后应用出现Bug时，则需要将版本进行回滚。
    之前部署的Pod都是裸Pod其不具备应用的扩展，更新，回滚的能力。而k8s上还有一种资源称之为控制器

控制器

K8S上有各种控制器，有的用来控制节点，有的用来控制名称空间，还有一种用来管理Pod的成为Pod控制器。

整个K8S是由控制平面和数据平面组成：

  • 控制平面：指的是K8S-Master节点上的控制组件
  • APIServer
  • Controller Manager
  • Scheduler
  • 数据平面：主要指运行应用的Pod的节点。

Pod控制器

专用于编排以Pod形式运行的应用的控制器，统称为Pod控制器。

控制器的工作逻辑

API Server是一种有着特殊功能的DB，支持资源的Watch和Notify。同时又将底层ETCD存储做了定义和限制，定义了存储的方案。

Controller是真正让用户存进API-Server所对应的实体。Controller是用来将API-Server中的数据项，在对应的集群中创建出实体来。

用户向API-Server中插入一个资源，而于此同时k8s上有多种资源控制器，每一种资源控制器专门监视着API-Server上与自己类型相关的资源的变动，一旦API-Server发生变，动控制器中的一段代码会更具用户所插入的资源将其创建为实体，实体创建完毕后其会立即将实际状态存回API-Server上的Status字段中，随后Controller会不断的去监控比对，实例上的status字段和资源清单中的spec字段是否一致。如果不一致则会再次执行代码，改变状态将结果存回API server，然后再次比对，此过程将不断循环，直到用户的期望状态和实际状态相同。

在此过程中kubelet不断的监控自身节点上的pod，一旦pod状态发生改变，其会将pod的status存回API-Server中。而后Controller会发现pod发生变化，再次执行其内部的代码使其不断逼近用户的期望状态。

controller的监控时长

在一个较大Service环境的k8s中，为了防止APIServer被controller的监控请求所淹没，所以默认的Controller loop监控时长为5分钟。

但是5分钟的时间太长，所以APIServer要对Controller做通知。

负责应用编排的控制器

负责应用编排的控制器有以下几个：

  • ReplicationController：早期的Pod控制器，已经被废除。
  • ReplicaSet：副本集，用来管理一组Pod的相同副本。
  • Deployment：部署，其不直接管理Pod而是借助于ReplicaSet来管理Pod；最常用的无状态应用控制器；
  • DaemonSet：守护进程集，用于确保在每个节点上仅运行某个应用的一个Pod副本
  • StatefulSet：功能类似于Deployment，但StatefulSet专用于编排有状态应用；
  • Job：有终止期限的作业式任务，而非一直处于运行状态的服务进程；
  • CronJob：周期性作业任务。

控制器定义格式

定义要素：

  • 标签选择器：用标签选择器来定义被关联到的pod
  • 期望的副本数：
  • pod模板