首页 » 翻译 » Kubernetes » 正文

Kubernetes系列翻译04 Replication Controller 第三部分

原文地址:http://kubernetes.io/v1.0/docs/user-guide/replication-controller.html

常见的使用模式

Rescheduling(重新规划)

正如我们之前提到的,无论你是有1个或者有1000个pod需要运行,Replication Controller 会确保该数量的pod在运行,甚至在节点(node)失败或者节点(node)终止的情况下

Scaling(缩放)

Replication Controller让我们更容易的控制pod的副本的数量,不管我们是手动控制还是通过其它的自动管理的工具,最简单的:修改replicas的值

Rolling updates(动态更新)

Replication Controller 可以支持动态更新,当我们更新一个服务的时候,它可以允许我们一个一个的替换pod

正如我们在#1353中解释的,推荐的方法是创建一个新的只有1个pod副本的Replication Controller,然后新的每次+1,旧的每次-1,直到旧的Replication Controller 的值变成0,然后我们就可以删除旧的了,这样就可以规避省级过程中出现的未知错误了

理论上,动态更新控制器应考虑应用的可用性,并确保足够的pod制成服务在任何时间都能正常提供服务

两个 Replication Controller创建的pod至少要由一个不同的标签,可以是镜像的标签,因为一般镜像的更新都会带来一个新的更新

kubectl是实现动态更新的客户端

Multiple release tracks多个发布版本追踪
除了在程序更新过程中同时运行多个版本的程序外,在更新完成之后的一段时间内或者持续的同时运行多个版本(新旧),通过多国版本的追踪(版本的追踪是通过label来实现的)

举个例子来说:一个服务可能绑定的Pod为tier in (frontend), environment in (prod),现在我们旧假设我们由10个副本来组成这个tier,现在我们要发布一个新的版本canary,这个时候,我们就应该设置一个Replication Controller,并且设置replcas的值为9,并且标签为tier=frontend, environment=prod, track=stable,然后再设置另外一个Replication Controller,并且把replacas的值设置为1标签为:tier=frontend, environment=prod, track=canary.现在这个服务就同时使用了新版和旧版两个版本了,这个时候我们旧可以通过不同的Replication Controller进行一些测试,监控…

发表评论