Deployment vs ReplicationController in Kubernetes

作者介绍:王天夫 腾讯云后台开发工程师

腾讯云容器服务是基于Kubernetes打造的。在Kubernetes中,创建和管理容器都是以controller来实现,例如:Replication Controller,Deployment,PetSet等。使用controller来管理容器,可以使用户方便的对容器数量做扩缩容,升级容器等操作。此文主要选择了两个最常用的controller,从各自功能,优缺点方面进行对比,方便大家在后续自己直接使用原生的Kubernetes功能时做参考。

Replication Controller

Replication Controller为Kubernetes的一个核心内容,应用托管到Kubernetes之后,需要保证应用能够持续的运行,Replication Controller就是这个保证的key,主要的功能如下:

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

最后,来看一下官方的解释:

A replication controller ensures that a specified number of pod “replicas” are running at any one time. In other words, a replication controller makes sure that a pod or homogeneous set of pods are always up and available. If there are too many pods, it will kill some. If there are too few, the replication controller will start more. Unlike manually created pods, the pods maintained by a replication controller are automatically replaced if they fail, get deleted, or are terminated. For example, your pods get re-created on a node after disruptive maintenance such as a kernel upgrade. For this reason, we recommend that you use a replication controller even if your application requires only a single pod. You can think of a replication controller as something similar to a process supervisor, but rather than individual processes on a single node, the replication controller supervises multiple pods across multiple nodes.

Deployment

Deployment同样为Kubernetes的一个核心内容,主要职责同样是为了保证pod的数量和健康,90%的功能与Replication Controller完全一样,可以看做新一代的Replication Controller。但是,它又具备了Replication Control,ler之外的新特性:

Replication Controller全部功能:Deployment继承了上面描述的Replication Controller全部功能。

事件和状态查看:可以查看Deployment的升级详细进度和状态。

回滚:当升级pod镜像或者相关参数的时候发现问题,可以使用回滚操作回滚到上一个稳定的版本或者指定的版本。

版本记录: 每一次对Deployment的操作,都能保存下来,给予后续可能的回滚使用。

暂停和启动:对于每一次升级,都能够随时暂停和启动。

多种升级方案:Recreate----删除所有已存在的pod,重新创建新的; RollingUpdate----滚动升级,逐步替换的策略,同时滚动升级时,支持更多的附加参数,例如设置最大不可用pod数量,最小升级间隔时间等等。

下面同样是官方的解释:

A Deployment provides declarative updates for Pods and Replica Sets (the next-generation Replication Controller). You only need to describe the desired state in a Deployment object, and the Deployment controller will change the actual state to the desired state at a controlled rate for you. You can define Deployments to create new resources, or replace existing ones by new ones.

Replication Controller vs Deployment

Deployment做为新一代的Replication Controller,好处不言而喻,不仅在功能上更为丰富,同时官方的文档中,也都推荐使用Deployment来管理pod,在google容器服务中,集群的系统pod,例如kube-dns,kube-proxy也都使用deployment来管理的,所以当大家需要选择的时候,也推荐使用Deployment在来管理pod。

Rolling updates Between Replication Controller and Deployment

Replication Controller

Replication Controller是使用kubectl rolling-update 来进行升级

$ kubectl rolling-update NAME \
    ([NEW_NAME] --image=IMAGE | -f FILE)

首先 我们定义一个nginx-v1.yaml的文件,副本数量为2:

apiVersion: v1
kind: ReplicationController
metadata:
  name: nginx-v1
spec:
  replicas: 2
  selector:
  app: nginx
  template:
  metadata:
  name: nginx
  labels:
  app: nginx
  spec:
  containers:
  - name: nginx
  image: nginx:1.8
  ports:
  - containerPort: 80

创建rc

$ kubectl create -f nginx-v1.yaml

然后是用kubeclt查看创建的rc

$ kubectl get rc/nginx-v1

现在需要将nginx的版本进行升级,从1.8升级到1.9,我们在定义一个1.9版本的Replication Controller的yaml文件:

apiVersion: v1
kind: ReplicationController
metadata:
  name: nginx-v2
spec:
replicas: 2
selector:
app: nginx
template:
metadata:
name: nginx
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.9
ports:
- containerPort: 80

开始滚动升级,update-period为更新间隔,这里设置的是10s:

$ kubectl rolling-update nginx-v1 -f nginx-v2.yaml --update-period=10s
Scaling up nginx-v2 from 0 to 2.scaling down nginx-v1 from 2 to 0
Scaling nginx-v2 up to 1
Scaling nginx-v1 down to 1
Scaling nginx-v2 up to 2
Scaling nginx-v1 down to 0
Update successed.Delete nginx-v1
replicationcontroller "nginx-v1" rolling updated to "nginx-v2"
Deployment

Deployment直接使用kubectl edit deployment/deploymentName 或者kubectl set方法就可以直接升级:

首先 我们同样定义一个nginx-deploy-v1.yaml的文件,副本数量为2:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nginx-deployment2
spec:
replicas: 3
template:
metadata:
labels:
test: nginx
spec:
containers:
- name: nginx
image: nginx:1.8
ports:
 - containerPort: 80

创建deployment

$ kubectl create -f nginx-deploy-v1.yaml

然后是用kubeclt查看创建的rc

$ kubectl get deployment/nginx-deployment2

现在需要将nginx的版本进行升级,从1.8升级到1.9,有两种方法可以使用: 直接set镜像:

$ kubectl set image deployment/nginx-deployment2 nginx=nginx:1.9
deployment "nginx-deployment2" image updated

或者直接edit:

$ kubectl edit deployment/nginx-deployment
deployment "nginx-deployment2" edited

最后,查看详细信息来确定升级进度:

$ kubectl describe deployments

同时介绍一下附加的一些操作,暂停和继续,回滚升级:

$ kubectl rollout pause deployment/nginx-deployment2
$ kubectl rollout resume deployment/nginx-deployment2
$ kubectl rollout undo deployment/nginx-deployment2

总结:在腾讯云容器服务中,我们创建的无状态服务都是以Deployment来管理的容器,因为Deployment功能更多,并且也是官方推荐的,下一代的Replication Controller。

原创声明,本文系作者授权云+社区-专栏发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏小尘哥的专栏

springboot中mybatis使用PageHelper和tk.mybatis

公司要做前后端分离,后端决定采用springboot提供接口程序,持久层采用mybatis,为了方便,需要对mapper进一步封装,继续整合PageHelper...

772
来自专栏程序员的SOD蜜

(PDF.NET框架实例讲解)将存储过程映射为实体类

PDF.NET数据开发框架可以将表,视图,表值函数,自定义的查询语句和存储过程映射为实体类,在上一篇《(PDF.NET框架实例讲解)将任意复杂的SQL查询映射成...

20010
来自专栏CLEAN_CODER

基于Consul的服务注册和服务发现

上节课我们 使用Rancher Compose部署了mst-user-service,我们的Pipeline已经搭建完毕,这节课我们切换到跟开发人员更密切的主题...

422
来自专栏张善友的专栏

微软开源 C++ REST SDK

微软的代号为Casablanca的C++ REST SDK已经基于Apache许可证开源。它被描述为“微软为了以原生代码支持基于云的客户端/服务器通信所做的努力...

21410
来自专栏大内老A

深入剖析ASP.NET的编译原理之二:预编译(Precompilation)

在本篇文章的第一部分:深入剖析ASP.NET的编译原理之一:动态编译(Dynamical Compilation),详细讨论了ASP.NET如何进行动态编译的,...

1717
来自专栏Linyb极客之路

单点登录原理与简单实现

  web应用采用browser/server架构,http作为通信协议。http是无状态协议,浏览器的每一次请求,服务器会独立处理,不与之前或之后的请求产生关...

1002
来自专栏Java架构沉思录

你不得不知道的HTTP状态码有哪些

100 (继续) 请求者应当继续提出请求。 服务器返回此代码表示已收到请求的第一部分,正在等待其余部分。

682
来自专栏java一日一条

关于HTTP状态码详细解析

多种选择,请求的资源包括多个位置,响应可返回同一个资源特征与地址的列表用于用户终端选择。

671
来自专栏青玉伏案

JavaEE开发之SpringMVC中的静态资源映射及服务器推送技术

在上篇博客中,我们聊了《JavaEE开发之SpringMVC中的自定义拦截器及异常处理》。本篇博客我们继续的来聊SpringMVC的东西,下方我们将会聊到js、...

1836
来自专栏Web项目聚集地

HTTP协议状态码详解

使用PHP/JSP 或者javascript都会用到http的不同状态,一些常见的状态码为: 200 – 服务器成功返回网页 404 – 请求的网页不存在 5...

743

扫码关注云+社区