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