Deployment

Deployment 为 Pod 和 Replica Set（下一代 Replication Controller）提供声明式更新。你只需要在 Deployment 中描述你想要的目标状态是什么，Deployment controller 就会帮你将 Pod 和 Replica Set 的实际状态改变到你的目标状态。你可以定义一个全新的 Deployment，也可以创建一个新的替换旧的 Deployment。

deployment demo

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

deployment.spec.replicas : 代表pod实例个数

deployment.spec.template： 代表生成pod实例的模板

创建depployment

创建deployment后，deployment-controller 会根据deployment 信息生成对应的replicaset，通过后台查看，会发现replicaset 的name 为 {deployment.name}-{根据deployment.spec.template生成hash}，replicaset 实例个数为deployment.spec.replicas 数值。

根据replicaset 创建后续pods 实例，deployment-controller 会根据pods 实例的创建过程更新 deployment status

status:
  availableReplicas: 2
  conditions:
  - lastTransitionTime: 2016-10-04T12:25:42Z
    lastUpdateTime: 2016-10-04T12:25:42Z
    message: Deployment has minimum availability.
    reason: MinimumReplicasAvailable
    status: "True"
    type: Available
  observedGeneration: 3
  replicas: 2
  unavailableReplicas: 2

status.replicas 代表当前实例个数

status.avaliableReplicas： 代表已ready的实例个数

status.unavaliableReplicas： 代表还未ready的实例个数

更新deployment

更新deployment，deployment-controller会生成新的rs 或者沿用旧rs，这个根据deployment.spec.template 生成的hash 是否一致决定。

deployment关于更新策略有两种：Recreate 与 RollingUpdate

Recreate 策略： 在创建出新的 Pod 之前会先杀掉所有已存在的 Pod；也就是说更新deployment，旧deployment生成的pods会先进行删除，删除完毕后，再创建新deployment下的pods，这种做法，会导致服务中断，故生产环境是不允许这种策略的。

RollingUpdate 策略： 根据配置策略，创建部分新pods实例，等待新的pods实例ready 后，删除相同个数的旧pods实例，循环这样的操作，直到所有新pods 实例个数为deployment设定的deployment.spec.replicas

RollingUpdate 策略配置：

strategy：
     rollingUpdate:
         maxSurge: 0
         maxUnavailable: 1
      type: RollingUpdate

spec.strategy.rollingUpdate.maxUnavailable :   是可选配置项，用来指定在升级过程中不可用 Pod 的最大数量。该值可以是一个绝对值（例如 5），也可以是期望 Pod 数量的百分比（例如 10%）。通过计算百分比的绝对值向下取整。如果 .spec.strategy.rollingUpdate.maxSurge 为 0 时，maxUnavailable 这个值不可以为 0。默认值是 1。

spec.strategy.rollingUpdate.maxSurge 是可选配置项，用来指定可以超过期望的 Pod 数量的最大个数。该值可以是一个绝对值（例如 5）或者是期望的 Pod 数量的百分比（例如 10%）。当 MaxUnavailable 为 0 时该值不可以为 0。通过百分比计算的绝对值向上取整。默认值是 1

当deployment 进行了更新且启用Rollingupdate策略：deployment controller 会根据deployment的最新内容，生成新 rs， 然后根据Rollingupdate策略来调节 新旧rs 的replicas

新旧rs replicas 变迁公式

新rs的replicas 变迁：newRs.replicas + (deploy.replicas+maxSurge-allPods)

旧rs的replicas 变迁：oldRs.replicas – (allReadyPods-(deploy.replicas-maxUnavailable))

例子： 当前deployment replicas为5 ，maxSurge为1 ， maxUnavailable为0

NewRS 初步创建，replicas为0，根据公式，replicas变为1，等待new rs对应的pod变为ready，则oldrs replicas变为4 ，之后new RS replicas 变为 2，等待new rs对应的pod变为ready，则oldrs replicas变为3…..

扩容缩容

通过修改 deployment.spec.replicas 来达到 修改replicaset 的replicas，从而扩容缩容服务

kubernetes 存在一种资源 horizontal pod autoscaling（hpa），该资源写着扩容缩容的规则，hpa-controller 会根据 hpa配置的规则，自动扩容缩容对应的服务

hpa demo

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: nginx
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      targetAverageUtilization: 50

hpa.spec.scaleTargetRef: 代表该规则生效于哪些服务

hpa.spec.minReplicas : 代表自动缩容，最小值不可比minreplicas 小

hpa.spec.maxReplicas: 代表自动扩容，最大值不可比maxreplicas 大

hpa.spec.metrics ： 代表自动扩容缩容规则

hpa.spec.metrics[].resource  代表该规则类型为资源类型，根据资源使用量，来判定是否扩容缩容

hpa.spec.metrics[].resource.targetAverageUtilization: 代表目标百分比，举例现场景就是50%cpu

HPA允许一定范围内的CPU使用量的不稳定，只有avg(CurrentPodsConsumption) / Target小于90%或者大于110%时才会触发扩容或缩容，避免频繁扩容、缩容造成颠簸。

hpa-controller  流程

1、创建HPA资源，设定目标CPU使用率限额，以及最大、最小实例数

2、收集一组中（PodSelector）每个Pod最近一分钟内的CPU使用率，并计算平均值

3、读取HPA中设定的CPU使用限额

4、计算：平均值之和/限额，求出目标调整的实例个数

5、目标调整的实例数不能超过1中设定的最大实例数，如果没有超过，则扩容；超过，则扩容至最大的实例个数

6、回到2，不断循环

暂停/恢复deployment

对deployment进行暂停/恢复操作，其实就是对deployment.spec.paused状态修改；

当deployment 处于暂停状态，去修改deployment 内容，不会因此创建出对应的pods；相应的deployment-controller处于这个状态，不会去更新与创建replicaset。

回滚deployment

当服务不稳定，需要回滚到一个稳定版本，deployment 提供版本回滚机制；

当deployment 修后，创建或更新对应的replicaset，该replicaset 会有一个标志位

replicaset.annotations: 
          deployment.kubernetes.io/revision: "5"

revision 值会随着deployment 的更新次数不断累加，故deployment 回滚 到某版本，可以根据revision找到replicaset，从而确定pod teamplate内容，来达到更新deployment 达到指定版本

清除旧replicaset

随着deployment修改次数变多，相应的replicaset的个数也会增多，为了避免过多的replicaset，可以通过设置 .spec.revisonHistoryLimit 项来指定 deployment 最多保留多少 revison 历史记录