Deployment vs ReplicationController in Kubernetes

Tencent Cloud Container Service is based on Kubernetes. In Kubernetes, the creation and management of containers are implemented by controllers, such as Replication Controller, Deployment, PetSet, etc. Using the controller to manage containers allows users to easily expand and shrink the number of containers, upgrade containers, and other operations. This article mainly selects the two most commonly used controllers, and compares them from their respective functions, advantages and disadvantages, so that you can refer to them when you directly use the native Kubernetes functions in the future.

Replication Controller

Replication Controller is a core content of Kubernetes. After the application is hosted on Kubernetes, it needs to ensure that the application can run continuously. Replication Controller is the key to this guarantee. The main functions are as follows:

  • Ensure the number of pods : It will ensure that the specified number of pods are running in Kubernetes. If there are less than the specified number of pods, the Replication Controller will create new ones, otherwise it will delete the redundant ones to keep the number of pods unchanged.

  • Make sure pods are healthy : When pods are unhealthy, run wrong, or fail to provide services, Replication Controller will also kill unhealthy pods and recreate new ones.

  • Elastic scaling  : During peak or low-peak business hours, the Replication Controller can dynamically adjust the number of pods to improve resource utilization. At the same time, configure the corresponding monitoring function (Hroizontal Pod Autoscaler), which will automatically obtain the overall resource usage of the Pod associated with the Replication Controller from the monitoring platform on a regular basis to achieve automatic scaling.

  • Rolling upgrade : Rolling upgrade is a smooth upgrade method. Through the strategy of gradual replacement, the stability of the overall system is ensured. When the upgrade is initialized, problems can be discovered and solved in time to avoid the continuous expansion of problems.

最后,来看一下官方的解释: 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。

 

http://blog.csdn.net/yjk13703623757/article/details/53746273

https://www.qcloud.com/community/article/695320001482723928

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=326688777&siteId=291194637