Replication Controller详解

Replication Controller简称RC，它能够保证Pod持续运行，并且在任何时候都有指定数量的Pod副本，在此基础上提供一些高级特性，比如滚动升级和弹性伸缩。

  • 确保pod数量：它会确保Kubernetes中有指定数量的Pod在运行。如果少于指定数量的pod，Replication Controller会创建新的，反之则会删除掉多余的以保证Pod数量不变。
  • 确保pod健康：当pod不健康，运行出错或者无法提供服务时，Replication Controller也会杀死不健康的pod，重新创建新的。
  • 弹性伸缩 ：在业务高峰或者低峰期的时候，可以通过Replication Controller动态的调整pod的数量来提高资源的利用率。同时，配置相应的监控功能（Hroizontal Pod Autoscaler），会定时自动从监控平台获取Replication Controller关联pod的整体资源使用情况，做到自动伸缩。
  • 滚动升级：滚动升级为一种平滑的升级方式，通过逐步替换的策略，保证整体系统的稳定，在初始化升级的时候就可以及时发现和解决问题，避免问题不断扩大。

当我们需要启动多个pod的时候我们就可以通过以下方式来确保pod的启动

1
2
3
4
spec.replicas：副本数量3
 spec.selector：RC通过spec.selector来筛选要控制的Pod
 spec.template：这里写Pod的定义（但不需要apiVersion和kind）
 spec.template.metadata.labels：Pod的label，可以看到这个label与spec.selector相同

ReplicaSet

ReplicaSet是下一代复本控制器。ReplicaSet和 Replication Controller之间的唯一区别是现在的选择器支持。Replication Controller**只支持基于等式的selector（env=dev或environment!=qa），但ReplicaSet还支持新的，基于集合的selector**（version in (v1.0, v2.0)或env notin (dev, qa)）。

ReplicaSet可确保指定数量的pod“replicas”在任何设定的时间运行。然而，Deployments是一个更高层次的概念，它管理ReplicaSets，并提供对pod的声明性更新以及许多其他的功能。因此，我们建议您使用Deployments而不是直接使用ReplicaSets，除非您需要自定义更新编排或根本不需要更新。

直接使用Deployments并在规范部分定义应用程序。

Deployments

Deployment为Pod和Replica Set（下一代Replication Controller）提供声明式更新。

你只需要在Deployment中描述你想要的目标状态是什么，Deployment controller就会帮你将Pod和Replica Set的实际状态改变到你的目标状态。你可以定义一个全新的Deployment，也可以创建一个新的替换旧的Deployment。

Deployment拥有更加灵活强大的升级、回滚功能。

在执行过程中也只能通过ctrl+C来终止，进行恢复。当rc升级完成后就没有办法回滚了，因为新的rc会替换掉旧的rc.

一个Deployment控制多个rs主要是为了支持回滚机制，每当Deployment操作时，Kubernetes会重新生成一个Replica Set并保留，以后有需要的话就可以回滚至之前的状态。

  • 使用Deployment来创建ReplicaSet。ReplicaSet在后台创建pod。检查启动状态，看它是成功还是失败。
  • 然后，通过更新Deployment的PodTemplateSpec字段来声明Pod的新状态。这会创建一个新的ReplicaSet，Deployment会按照控制的速率将pod从旧的ReplicaSet移动到新的ReplicaSet中。
  • 如果当前状态不稳定，回滚到之前的Deployment revision。每次回滚都会更新Deployment的revision。
  • 扩容Deployment以满足更高的负载。
  • 暂停Deployment来应用PodTemplateSpec的多个修复，然后恢复上线。
  • 根据Deployment 的状态判断上线是否hang住了。
  • 清除旧的不必要的ReplicaSet。

Deployment

声明式的升级应用

rc的滚动升级

1
kubectl rolling-update kubia-v1 kubia-v2 --image=luksa/kubia:v2

使用kubia-v2版本应用来替换运行着kubia-v1的RC，将新的复制控制器命名为kubia-v2，并使用luksa/kubia:v2最为镜像。

升级完成后使kubectl describe rc kubia-v2查看升级后的状态。

1.直接更新pod和RC的标签并不是一个很的方案；

2.kubectl只是执行升级中的客户端，但如果执行kubectl过程中失去了网络连接，升级将会被中断，pod和RC将会处于一个中间的状态，所以才有了Deployment资源的引入。

RC的滚动升级不具有Deployment在应用版本升级过程中的历史记录、新旧版本数量的精细控制等功能

使用Deployment声明式的升级应用

升级应用

　　Rs替代Rc来复制个管理pod。

　　创建Deployment前确保删除所有的RC和pod，但是暂时保留Service，

　　kubectl delete rc –all

　　创建Deployment

1
2
3
4
5
6
7
8
#kubectl create -f kubectl.depl-v1.yaml --record //--record可以记录历史版本

#查看Deployment的相关信息
#kubectl get deployment
#kubectl describe deployment

#查看部署状态：
#kubectl rollout status deployment kubia

触发deployment升级

1
2
3
4
#kubectl edit deployment kubia //修改完后资源对象会被更新
#kubectl patch deployment kubia -p '{...}' //只能包含想要更新的字段
#kubectl apply -f kubia-deploy-v2.yml //如果yml中定义的资源不存在，会自动被创建
#kubectl replace -f kubia-deploy-v2.yml //如果yml中定义的资源不存在，则会报错

　　修改configmap并不会触发升级，如果想要触发，可以创建新的configmap并修改pod模板引用新的configmap。

回滚deployment

　　在上述升级deployment过程中可以使用如下命令来观察升级的过程

1
#kubectl rollout status deployment kubia

　　如果出现报错，如何进行停止？可以使用如下命令进行回滚到先前部署的版本

1
#kubectl rollout undo deployment kubia

　　如何显示deployment的历史版本？

1
#kubectl rollout history deployment kubia

　　如何回滚到特定的版本？

1
#kubectl rollout undo deployment kubia --to-revision=1

控制滚动升级的速率

　　在deployment的滚动升级过程中，有两个属性决定一次替换多少个pod：maxSurge、maxUnavailable,可以通过strategy字段下的rollingUpdate的属性来配置，

　　maxSurge：决定期望的副本数，默认值为25%，如果副本数设置为4个，则在滚动升级过程中，不会运行超过5个pod。

　　maxUnavaliable: 决定允许多少个pod处于不可用状态，默认值为25%，如果副本数为4，那么只能有一个pod处于不可用状态，

​ 默认情况下如果10分钟内没有升级完成，将被视为失败，如果要修改这个参数可以使用kubectl describe deploy kubia 查看到一条ProgressDeadline-Exceeded的记录，可以修改此项参数修改判断时间。

升级策略

滚动升级

是默认的更新策略

它在删除一部分旧版本Pod资源的同时，补充创建一部分新版本的Pod对象进行应用升级，其优势是升级期间，容器中应用提供的服务不会中断，但要求应用程序能够应对新旧版本同时工作的情形，例如新旧版本兼容同一个数据库方案等。不过，更新操作期间，不同客户端得到的响应内容可能会来自不同版本的应用。
Deployment控制器的滚动更新操作并非在同一个ReplicaSet控制器对象下删除并创建Pod资源，而是将它们分置于两个不同的控制器之下：旧控制器的Pod对象数量不断减少的同时，新控制器的Pod对象数量不断增加，直到旧控制器不再拥有Pod对象，而新控制器的副本数量变得完全符合期望值为止

滚动更新时，应用升级期间还要确保可用的Pod对象数量不低于某阈值以确保可以持续处理客户端的服务请求，变动的方式和Pod对象的数量范围将通过spec.strategy.rollingUpdate.maxSurge和spec.strategy.rollingUpdate.maxUnavailable两个属性协同进行定义，它们的功用如图所示

滚动升级

eployment控制器也支持用户保留其滚动更新历史中的旧ReplicaSet对象版本,这赋予了控制器进行应用回滚的能力：用户可按需回滚到指定的历史版本。控制器可保存的历史版本数量由“spec.revisionHistoryLimit”属性进行定义。当然，也只有保存于revision历史中的ReplicaSet版本可用于回滚，因此，用户要习惯性地在更新操作时指定保留旧版本。
回滚操作