k8sDeployment控制器

简写为deploy，是k8s控制器的另一种实现，它构建于ReplicaSet之上，可为pod和rs资源提供声明式更新。

deploy控制器资源的大部分功能均可通过调用rs来实现，同时，还增添了部分特性：

事件和状态查看：必要时可以查看deploy对象升级的详细进度和状态

回滚：升级操作完成后发现问题时，支持使用回滚机制将应用返回到前一个或由用户指定的历史记录中的版本

版本记录：对deploy对象的每一次操作都予以保存，以提供后续可能执行的回滚操作

暂停和启动：对于每一次升级，都能够随时暂停和启动

多种自动更新方案：一是Recreate，即重建更新机制，全面停止、删除旧的pod后用新版本替代；另一个RollingUpdate，即滚动升级机制，逐步替换旧的pod至新的版本

一、创建deploy

其spec字段中嵌套使用的字段包含了rs控制器支持的replicas、selector、template和minReadySeconds，它也正是利用这些信息完成了其二级资源rs对象的创建，如下示例：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deploy
spec:
  replicas:
  selector:
    matchLabels:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: ikubernetes/myapp:v1
        ports:
        - containerPort:
          name: http

使用命令“kubectl apply -f myapp-deploy.yaml --record”命令部署，使用“kubectl get deploy”命令可以列出创建的deploy对象相关信息。deploy控制器会自动创建相关的rs控制器，并以“[deployment_name]-[template-hash-value]”格式为其命名，其中的hash值由deploy自动生成。由deploy创建的rs对象会自动使用相同的标签选择器。deploy借助于rs管理pod资源，其大部分管理操作与rs相同，不过，deploy也有rs所不具有的部分高级功能，这其中最著名的为自动滚动更新机制。

二、更新策略

depoly只需要由用户指定在pod模板中要改动的内容交由其自动完成更新，更新应用程序的规模也只需要修改期望的副本数量，余下的事情交给deploy控制器即可。

deploy控制器支持两种更新策略：滚动更新和重新创建，默认为滚动更新。重新创建即首先删除现有的pod对象，而后由控制器基于新模板重新创建出新版本资源对象。通常，只应该在应用的新旧版本不兼容时才会使用recreate策略。

滚动更新在删除一部分旧版本pod资源的同时，补充创建一部分新版本的pod对象进行应用升级，其优势是升级期间，容器中应用提供的服务不会中断，但要求应用程序能够应对新旧版本同时工作的情形。

deploy控制器的滚动更新操作并非在同一个rs控制器对象下删除并创建pod资源，而是将它们分置于两个不同的控制器之下：旧控制器的pod对象数量不断减少的同时，新控制器的pod对象数量不断增加，直到旧控制器不再拥有pod对象，而新控制器的副本数量变得完全符合期望值为止。

滚动更新时，应用升级期间还要确保可用的pod对象数量不低于某阈值以确保可以持续处理客户端的服务请求，变动的方式和pod对象的数量范围将通过spec.strategy.rollingUpdate.maxSurge和spec.rollingUpdate.maxUnavailable两个属性协同进行定义。

maxSurge：指定升级期间存在的总pod对象数量最多可超出期望值的个数，其值可以是0或正整数，也可以是一个期望值的百分比

maxUnavailable：升级期间正常可用的pod副本数（包括新旧版本）最多不能低于期望数值的个数，其值可以是0或正整数，也可以是一个期望值的百分比；默认值为1.

maxSurge和maxUnavailable属性的值不可同时为0，否则pod对象的副本数在符合用户期望的数量后无法做出合理变动以进行滚动更新操作。

配置时，用户还可以使用deploy控制器的spec.minReadySeconds属性来控制应用的升级速度。新旧更替过程中，新创建的pod对象一旦成功响应就绪探测即被视为可用，而后即可立即开始下一轮的替换操作。而spec.minReadySeconds能够定义在新的pod对象来让k8s在每次创建出pod资源后都要等上一段时长后再开始下一轮的更替，这个时间长度的理想值是等到pod对象中的应用已经可以接受并处理请求流量。

deploy控制器也支持用户保留其滚动更新历史中的旧rs对象版本，控制器可保存的历史版本数量由spec.revisionHistoryLimit属性进行定义。在创建deploy对象时使用“--record”选项来保存版本升级的历史。

三、升级deploy

修改pod模板相关的配置参数便能完成deploy控制器资源的更新，对deploy控制器资源的修改尤其适合使用apply和patch命令来进行；

四、金丝雀发布

deploy控制器还支持自定义控制更新过程中的滚动节奏，如暂停（pause）或继续（resume）更新操作，尤其时借助于maxSurge和maxUnavailable属性还能实现更为精巧的过程控制。例如，待第一批新pod对象创建完成后立即暂停更新过程，此时，仅存在一小部分新版本的应用，主体部分还是旧版本。然后再根据用户特征精心筛选出小部分用户的请求路由至新版本的pod应用，并持续观察其是否能稳定低按期望的方式运行。确定没有问题后再继续完成余下pod资源的滚动更新，否则立即回滚更新操作，这便是金丝雀发布。

五、回滚deploy控制器下的应用发布

若因各种原因导致滚动更新无法正常进行，则应将应用回滚到之前的版本，或者回滚到由用户指定的历史记录中的版本，可使用命令“kubectl rollout undo”完成，也可使用选项“--to-version=*”来指定版本。回滚操作中，其revision记录中的信息会发生变动，回滚操作会被当作一次滚动更新追加进历史记录中，而被回滚的条目则会被删除。需要注意的是，如果此前的滚动更新过程处于暂停状态，那么回滚操作就需要先将pod模板的版本改回到之前的版本，然后继续更新，否则，其将一直处于暂停状态无法回滚。

六、扩容和缩容

通过修改spec.replicas即可修改deploy中pod资源副本数量，它将实时作用于控制器并直接生效。deploy是声明式配置，replicas属性的值可直接修改资源配置文件，然后使用kubectl apply进行应用，也可以使用kubectl edit对其进行实时修改。而前一种方式能够将修改结果予以长期留存。另外，kubectl scale命令是专用于扩展某些控制器类型的应用规模的，包括deploy和job等。而deploy通过replicaset控制其pod资源，因此扩缩容的方式是相同的。