首页 » 翻译 » Kubernetes » 正文

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

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

什么是Replication Controller

Replication Controller 保证了在所有时间内,都有特定数量的Pod副本正在运行,如果太多了,Replication Controller就杀死几个,如果太少了,Replication Controller会新建几个,和直接创建的pod不同的是,Replication Controller会替换掉那些删除的或者被终止的pod,不管删除的原因是什么(维护阿,更新啊,Replication Controller都不关心)。基于这个理由,我们建议即使是只创建一个pod,我们也要使用Replication Controller。Replication Controller 就像一个进程管理器,监管着不同node上的多个pod,而不是单单监控一个node上的pod,Replication Controller 会委派本地容器来启动一些节点上服务(Kubelet ,Docker)。

正如我们在pod的生命周期中讨论的,Replication Controller只会对那些RestartPolicy = Always的Pod的生效,(RestartPolicy的默认值就是Always),Replication Controller 不会去管理那些有不同启动策略pod
如我们在issue #503讨论的,我们希望在将来别的控制器被加入到Kubernete中来管理一些例如负载阿,测试等相关功能

Replication Controller永远不会自己关闭,但是,我们并不希望Replication Controller成为一个长久存在的服务。服务可能会有多个Pod组成,这些Pod又被多个Replication Controller控制着,我们希望Replication Controller 会在服务的生命周期中被删除和新建(例如在这些pod中发布一个更新),对于服务和用户来说,Replication Controller是通过一种无形的方式来维持着服务的状态

Replication Controller是如何工作的
Pod template

一个Replication Controller通过模版来创建pod,这个是Replication Controller对象内置的功能,但是我们计划要将这个功能从Replication Controller剥离开来

与其说Pod的模版是一个多有Pod副本的期望状态,Pod的模版更像是一个饼干的模具,一旦从模具中出来之后,饼干就和饼干模具美啥关系了,没有任何关联。模版的改变甚至是模版的更改对已经存在的pod没有任何影响,Replication Controller创建的pod可以在之后直接的修改,这对Pod来说是非常重要的,这样就定制了Pod中的所有容器的期望状态。这从根本上简化系统复杂度增加了灵活性,正如下面的这个例子

Replication Controller 创建的的Pod 是可以相互替代和语义上相同的,尽管他们的配置文件可能会随着是时间的变化而不一样,这非常适合无状态服务器,但是Replication Controller也可以被用在保持主从的高可用,共享,work-pool类应用程序,这样的程序应该使用的是动态分配机制,例如etcd lock module和RabbitMQ 的队列,相对于静态/一次性的定制的Pod的配置文件,应该是一种反模式,任何定制化的pod,例如垂直的自动变化资源(cpu,内存),应该被其它的线上Controller管理,而不是Replication Controller

发表评论