【k8s系列三】k8s的核心概念2-控制器管理的Pod

summerSunShine
132 阅读9分钟

持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第4天，点击查看活动详情

控制器管理的Pod

控制器管理的Pod有三种：ReplicationController & ReplicaSet & Deployment ， 这三种控制器有很多相似的地方

i.ReplicationController

ReplicationController简称rc. 它的作用是确保容器应用的副本数始终保持在用户定义的副本数, 这是用户的期望。即如果有容器异常退出, 会自动创建新的Pod来代替; 而如果异常多出来的容器也会自动回收. 在新版本的k8s中, 建议使用ReplicaSet来取代ReplicationController.

ii.ReplicaSet:

ReplicaSet简称rs. 跟ReplicationController没有本质上的区别, 除了名字不同, ReplicaSet支持集合式的 .

这个集合式的选择器是什么呢？就是在我们创建Pod的时候, 可以给他打标签. 比如: app = http, version = v1版本等等. 我们会打一堆的标签. 当我们想删除容器的时候, 我们可以这样说: 当app=http, version = v1的时候, 执行什么操作. rs支持这种集合方案, 但是rc不支持. 所以在大型项目中, rs比rc会更简单, 更有效率. 所以, 在新版本中, 官方抛弃rc, 全部转用rs.

在小的集群下，有没有标签都没所谓，但当集群越来越大，pod越来越多的时候，标签就很有用了。我们可以通过标签定位某一个pod。

所以，rc适合小集群使用，rs适合多集群，pod量很大的时候使用。rs包含了rc的功能，所以官方都建议使用rs。

iii.Deployment:

虽然replicaSet可以独立使用, 但一般还是建议使用Deployment来自动管理ReplicaSet, 这样就无需担心跟其他机制的不兼容问题(比如ReplicaSet不支持 rolling-update滚动更新, 但Deployment支持) 。Deployment为何要和RS一起使用呢？是因为Deployment本身不能创建Pod。

滚动更新还是很有意义的, 尤其是在生成环境中

比如：我们现在有两个容器, 我们要将现在容器的版本从v1版本升级到v2版本. 这时候, 怎么办呢? 我们可以进行滚动更新.

　　　　　　img

首先, 先生成一个新的pod. 然删除一个旧的pod, 如下如所示. 先生成一个v2版本的pod, 然后删除一个v1版本的pod .再把v2版本的pod挂载到集群上，然后以此类推，所有服务器以此替换。最后，所有服务器就都是v2版本的，这就是滚动更新.

img

那么, Deployment是如何管理rs并滚动更新的呢?

  • 首次部署的时候，要做那些事呢？

第一步：会创建一个Deployment控制器，在Deployment控制器中定义了pod的模板和副本数量。

第二步，Deployment会主动创建一个RS。也就是说rs不是我们自己定义的, 是Deployment自动生成的. RS会创建多个pod

第三步，RS主动帮我们创建Pod，并维持pod副本数的稳定。

Deployment定义出来以后, 他会定义一个rs, RS会创建多个pod. 如下图

image

  • 当需要更新版本的时候. 怎么做呢？

官方开发出了v2版本，这时我们要进行滚动更新了。如何滚动更新呢？

第一步：Deployment会更改pod模板为V2。

第二步：Deployment控制器再创建一个新的RS。我们的期望是从左边的RS迁移到右边的RS。

`　　　　　　image

第三步：RS-2再创建一个新的 Pod, 将其升级到v2版本. 然后下掉一个v1版本的Pod

　　　　　　image

第四步：在创建一个Pod, 将其版本升级到v2, 在下掉一个v1版本的Pod

　　　　　　image

第五步：直至全部下完.

image

这就是Deployment管理的滚动rolling-update滚动升级。

如果升级的过程中, 发现新版本有一些小bug, 我们还可以回滚. 如何回滚, 执行undo即可. 回滚的逻辑和版本升级的原理一样. 恢复一个v1, 下掉一个v2. 直至全部恢复.

image

为什么RS能够恢复呢?

因为, 下掉的RS没有被删掉. 只是停用了. 当回滚的时候, 老旧的RS就会被启动.　　　

iv. HPA控制器

Horizontal Pod Autoscaling 简称HPA控制器，仅适用于Deployment和ReplicaSet，在V1版本中仅支持根据Pod的CPU利用率扩缩容，在vlalpha版本中，可以根据内存和用户自定义的metric扩缩容。

举个例子：

首先，我们创建出一个Deployment控制器或者RS控制器，这个控制器会创建pod副本，在Deployment或者RS之上可以增加一个HPA控制器。HPA也是一个对象, 他是基于RS创建的。HPA控制器可以定义一个阈值，比如CPU使用率大于80%的时候，进行扩容；CPU使用率小于20%的时候进行缩容。pod副本数最小2个，最大20个。

image

于是，当cpu使用率超过80%的时候，RS会自动进行扩容，最大扩容到20个副本。

image

如果创建了20个副本以后，CPU依然大于80%，那么就爱莫能助了。

缩容也是一样的，当cpu使用率很小的时候，就缩容，但最小是2个。也即是减到只剩2个pod, 不能再减了.

这样就达到了一个水平扩展的目的. 这也是HPA帮我们实现的.

v. statefulSet

statefulSet主要解决的是有状态服务的问题. docker主要面对的是无状态服务。

服务的分类: 
​
1. 无状态服务: 踢出去过段时间放回来, 依然能正常工作. 比如LVS调度器, APACHE(http服务) 
　　　　为什么apache是无状态服务呢? 因为apache中的数据可以通过共享服务来完成. 对于组件本身他不需要数据, 也没有数据的更新. 所以, apache被定义到无状态服务里面.
　　　　docker: 对于docker来说, 他更适合运行的是无状态服务. 
​
2. 有状态服务:  踢出集群后过段时间再放回来, 就不能正常工作了, 这样的服务就是有状态服务. 比如: 数据库DBMS, 因为有很大一部分数据缺失了.
 　　　　Kubernetes的一个难点就是必须要攻克有状态服务. 那么, 有状态服务, 有些数据需要持久化, 需要保存起来, 这时,我们就会引入存储的概念.

主要解决的是有状态服务的问题. docker主要面对的是无状态服务, 无状态服务的含义时, 没有对应的存储需要实时的保留. 或者是把他摘出来, 经过一段时间以后, 放回去依然能够工作. 典型的无状态服务有哪些呢? 比如: apache服务, LVS服务(负载均衡调度器) . 典型的有状态服务有哪些呢?mysql, mongodb, 他们需要实时的对数据进行更新和存储. 把他抽离出集群,再放回来就没办法工作了. statefulSet就是为了解决有状态服务而诞生的. Deployment 和 ReplicaSet是无状态服务

statefulset的应用场景包括:

1>稳定的持久化存储.

即Pod重新调度后还是能访问到相同的持久化数据. 基于PVC来实现.

Pod重新调度指的是Pod死亡以后, 我们会在调度回来。也就是创建一个新的Pod，创建的这个新的Pod取代原来的Pod的时候, 他的存储依然是之前的存储, 并不会变, 并且里面的数据也不会丢失.

2> 稳定的网络标识:

即Pod重新调度后，其PodName和HostName是不变的，也就是说之前的Pod叫什么, 现在Pod就叫什么. 之前的主机名是什么，现在的主机名还是哪个。 基于Headless Service(即没有Cluster IP 的Service)来实现。

3> 有序部署.

有序部署分为扩展和回收两个阶段.

  • 有序扩展. 即Pod是有顺序的, 再部署或扩展的时候, 要依据定义的顺序一次进行(即从0到n-1, 在下一个pod运行之前, 所有之前的Pod必须都是Running和Ready的标志), 基于init Containars实现

只有当前一个Pod处于running和ready的状态, 第二个才可以被创建. 为什么需要这样部署呢? 原因是, 我们构建一个集群化, 比如集群里有nginx, apache, mysql. 我们的启动顺序是先启mysql, 再启apache, 再启nginx, 因为他们之间是有依赖关系的. nginx依赖apache, apache依赖mysql. 这就是有序部署.

4> 有序收缩, 有序删除

回收也是一样的是有序的, 不同的是, 他是逆序回收. 从n-1开始, 一直到0.

vi. DaemonSet:

确保全部(或一些)Node上运行一个Pod的副本. 当有Pod加入集群时, 也会为他们增加一个Pod副本, 当有Pod从集群移除时, Pod副本也会被回收,删除DeamonSet会删除对应的所有的Pod.

  • 这里说的是确保全部或者一些，为什么会是一些呢？这是因为，我们可以在node上打污点，打上污点的node是不被调度的。所以，在DaemonSet运行的时候，打了污点的node是不会被创建的。默认情况下，所有node都会被运行。每个pod只会创建一个副本。

使用DaemonSet的典型用法:

  1. 运行集群存储daemon, 例如在每个Node上运行glusterd, ceph.
  2. 在每个节点上运行日志收集daemon, 例如fluentd, logstash.
  3. 在每个节点上运行监控daemon, 例如Prometheus, Node Exporter.

只要有需求，每个node上都可以运行一个守护进程，去帮我们做一些事情，这个时候就可以使用DaemonSet

vii. Job, CronJob

  • Job是负责批处理的任务. 仅执行一次的任务, 它保证批处理任务的一个或多个Pod成功结束

    比如: 我想备份数据库, 备份代码可以放在Pod里, 我们将其放到Job里去执行，脚本是可以正常执行正常工作。直接在linux操作, 到时间就可以把脚本运行, 执行出来. linux操作系统执行不也是一样的么?

    一方面封装成pod, 我们可以重复利用;

    另一方面,如果脚本执行意外退出,是没办法重复执行的,job如果判断当前脚本不是正常退出,她会重新执行一遍脚本.直到正常退出为止,并且还可以设置政策退出的次数.

  • CronJob管理基于时间的Pob, 在特定的时间可以执行

    即

    》在给定的时间点只运行一次

    》周期性的再交给时间点运行

avatar
文章
阅读
粉丝