Deployment相对ReplicaSet优势

系列目录

RS与Deployment主要用于替代RC。RS的全称为Replica Set。相对于RC，RS与Deployment的优势如下：

• RC只支持基于等式的selector，如env=dev或者environment!=qa。但在RS中，还支持新的基于集合的selector，如version in (v1.0,v2.0)或者env not in (dev,qa)。这给复杂的运维管理带来方便

• 使用Deployment升级Pod只需要定义Pod的最终状态，k8s会为你执行必要的操作。虽然使用kubectl rolling-update也可以完成滚动升级，但它是在客户端与服务端多次交互控制RC完成的，所以REST API中并没有rolling-update的接口，这为定制自己的管理系统带来了一些麻烦。Deployment拥有更加灵活的升级、回滚功能。

Replica Set目前与RC的区别只是支持的selector不同，后续会加入更多的功能。Deployment使用了Replica Set，是更高一层的概念。除非需要自定义升级功能或者根本不需要升级Pod，否则还是建议使用Deployment而不直接使用Replica Set。

Deployment配置文件

Deployment的配置与RC基本相同，详细配置可以参考官方文档下面直接给出一个配置示例deployment.yml内容如下：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
    name: hello-deployment
    namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      name: hello-deployment
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 10%
      maxUnavailable: 0
  template:
    metadata:
      labels:
        name: hello-deployment
    spec:
      containers:
      - name: webserver
        image: nginx:1.14
        ports:
        - containerPort:80

需要说明的是strategy部分，用于定义deployment的升级策略。具体的deployment滚动升级的详细操作可以参考另一篇文章《Service滚动更新》。这里简单说下这几个配置项的意义：

• spec.strategy：用于定义升级的策略

• spec.strategy.type：定义使用何种方式升级。一种是RollingUpdate，即滚动升级。另一种方式为Recreate。即先将所有旧的Pod停止，然后再启动新的pod。默认策略即为RollingUpdate

• spec.strategy.type.rollingUpdate：如果采用RollingUpdate的方式进行升级操作，则可以定义更详细的滚动升级策略

• spec.strategy.type.rollingUpdate.maxSurge： 指定在升级时，最大可以创建多少个pod。这个值可以是一个绝对值数字，也可以是个百分比。例如，当这个值指定为30%时，也就是说，新旧pod的总量不能超过130%。简单来讲，就是在滚动升级时，会先启动30%的新的pod。然后开始杀掉旧的pod，每当一个旧的pod被杀掉，一个新的pod的会被启动，始终保持总量不超过130%，直至更新完成。需要说明的是，当maxUnavailable为0时，maxSurge的值不能为0。

• spec.strategy.type.rollingUpdate.maxUnavailable： 指定在升级时，最大不可用的pods的值。可以是一个绝对值数字，也可以是个百分比。例如，当这个值指定为30%时，最少可用的Pod为70%,也就是说，在滚动升级的时候，会先杀掉30%旧的pod，然后开始启动新pod。当一个新的Pod被创建，一个旧的Pod就会被销毁。始终保持可用的pod在总量的70%，直至升级完成。需要说明的是，当maxSurge为0时，maxUnavailable的值不能为0。

创建deployment：

kubectl create -f deployment.yml --record