Deployment

Deployment

RC是kubernetes中的一个核心概念，Deployment 是新一代的RC，除了拥有RC的功能外，还具有一下特性：

• 支持事件和状态查看：能够查看Deployment升级的状态和详细过程
• 回滚：升级Pod后出现问题，可使用回滚功能回退到以前任一（总记录历史数之内）历史版本
• 版本记录：每一次对Deployment的操做,都能记录下来，保证回滚的基础
• 暂停和启动：对于每一次更新都能暂停和启动
• 金丝雀发布

Deployement 做为新一代的RC,不只在功能上更丰富了，同时官方推荐使用，在一些官方组件上，也能看到是使用Deployment部署，好比kube-proxy,kube-dns。

结构图层

能够看出，Deployment管理一个或多个Replica Set，一个Replica Set管理一个或多个Pod。Deployment 管理多个rs的做用，主要是为了支持回滚机制，每次操做Deployment后，都会生成一个新的RS对象保存下来，也能够设置保留历史版本数量，当须要之前的版本时能够一键回滚。

用例

如下是部署的典型用例：

• 建立一个部署以部署ReplicaSet。ReplicaSet在后台建立Pod。检查部署的状态，看是否成功。
• 经过更新部署的PodTemplateSpec 声明 Pod 的新状态。将建立一个新的ReplicaSet，而且Deployment负责以受控的速率将Pod从旧的ReplicaSet移至新的ReplicaSet。每一个新的ReplicaSet都会更新Deployment的修订版。
• 若是部署的当前状态不稳定，则回滚到早期的部署版本。每次回滚都会更新Deployment的修订版。
• 扩展部署以促进更多负载。
• 暂停部署到多个补丁应用到其PodTemplateSpec，而后恢复它开始一个新的部署。
• 使用“部署”的状态做为部署暂停的指示器
• 清理再也不须要的旧副本集

建立部署

官方模板 nginx-deployment.yaml

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

这是部署示例。它建立一个ReplicaSet来调出三个nginx Pod。

经过下载示例文件，而后运行如下命令来运行示例：

kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml

将kubectl标志设置--record为true容许您将当前命令记录在正在建立或更新的资源的注释中。这对于未来的自省颇有用：例如，查看每一个Deployment版本中执行的命令。

要查看“部署”推出状态，请运行：

$ kubectl rollout status deployment/nginx-deployment
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
deployment "nginx-deployment" successfully rolled out

建立的ReplicaSet确保始终有三个nginx Pod。

注意：您必须在Deployment中指定适当的选择器和pod模板标签（在本例中为 app = nginx）。也就是说，请勿与其余控制器（包括其余Deployment，ReplicaSet，StatefulSet等）重叠。Kubernetes不会阻止您重叠，而且若是多个控制器具备重叠的选择器，那么这些控制器可能会相互竞争，而且没法正常运行。

Pod模板哈希标签

注意： Do not change this label.

注意上面的pod标签中示例输出中的pod-template-hash标签。此标签由Deployment控制器添加到Deployment建立或采用的每一个ReplicaSet中。其目的是确保部署的子副本集不重叠。它是经过对ReplicaSet的PodTemplate进行散列并使用所得的散列做为将添加到ReplicaSet选择器，吊舱模板标签以及ReplicaSet可能具备的任何现有吊舱中的标签值来计算的。

更新部署

注意：只有且仅当.spec.template更改了部署的pod模板（即）（例如，模板的标签或容器映像已更新）时，才会触发部署的推出。其余更新，例如扩展部署，不会触发部署。

假设咱们如今要更新nginx Pods以使用nginx:1.9.1图像而不是nginx:1.7.9图像。

$ kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
deployment "nginx-deployment" image updated

或者，咱们能够edit部署和改变.spec.template.spec.containers[0].image从nginx:1.7.9到nginx:1.9.1：

$ kubectl edit deployment/nginx-deployment
deployment "nginx-deployment" edited

要查看部署状态，请运行：

$ kubectl rollout status deployment/nginx-deployment
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
deployment "nginx-deployment" successfully rolled out

部署成功后，您可能须要get部署：

$ kubectl get deployments
NAME               DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3         3         3            3           36s

最新副本数代表部署已将副本更新为最新配置。当前副本指示此Deployment管理的所有副本，可用副本指示可用的当前副本数。

咱们能够kubectl get rs经过建立新的ReplicaSet并将其缩放到3个副本，以及将旧的ReplicaSet缩小到0个副原本看到Deployment更新了Pod。

过渡（又名进行中的多个更新）

每次部署控制器观察到新的部署对象时，若是没有现有的ReplicaSet，则会建立一个ReplicaSet来调出所需的Pod。标签匹配.spec.selector但模板不匹配的现有ReplicaSet控制Pod .spec.template按比例缩小。最终，新的副本集将被缩放为.spec.replicas，全部旧的副本集将被缩放为0。

若是在进行现有部署时更新部署，则部署将根据更新建立一个新的ReplicaSet并开始进行扩展，并将其先前扩展的ReplicaSet进行滚动-它将添加到其列表中旧的ReplicaSets，并将开始按比例缩小比例。

例如，假设您建立了一个Deployment来建立5个的副本nginx:1.7.9，可是nginx:1.9.1当只建立了3个副本时，更新了Deployment来建立5个的副本nginx:1.7.9。在这种状况下，Deployment将当即开始杀死nginx:1.7.9它已经建立的3个Pod，并将开始建立 nginx:1.9.1Pod。nginx:1.7.9更改路线以前，它不会等待建立5个副本。

标签选择器更新

一般不建议更新标签选择器，建议您预先计划选择器。不管如何，若是您须要执行标签选择器更新，请格外当心，并确保您已掌握全部含义。

• 添加选择器时，还须要使用新标签来更新Deployment规范中的pod模板标签，不然将返回验证错误。此更改是不重叠的更改，这意味着新选择器不会选择使用旧选择器建立的副本集和Pod，从而致使全部旧副本集孤立，并建立新的副本集。
• 选择器更新（即更改选择器键中的现有值）会致使与添加操做相同的行为。
• 选择器的删除（即从“部署”选择器中删除现有的密钥）不须要对窗格模板标签进行任何更改。没有孤立的现有ReplicaSet，也不会建立新的ReplicaSet，可是请注意，已删除的标签仍存在于任何现有Pod和ReplicaSet中。

滚动升级

如今咱们将刚刚保存的yaml文件中的nginx镜像修改成nginx:1.13.3，而后在spec下面添加滚动升级策略：

minReadySeconds: 5
strategy:
  # indicate which strategy we want for rolling update
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 1

• minReadySeconds:
  • Kubernetes在等待设置的时间后才进行升级
  • 若是没有设置该值，Kubernetes会假设该容器启动起来后就提供服务了
  • 若是没有设置该值，在某些极端状况下可能会形成服务不正常运行
• maxSurge:
  • 升级过程当中最多能够比原先设置多出的POD数量
  • 例如：maxSurage=1，replicas=5,则表示Kubernetes会先启动1一个新的Pod后才删掉一个旧的POD，整个升级过程当中最多会有5+1个POD。
• maxUnavaible:
  • 升级过程当中最多有多少个POD处于没法提供服务的状态
  • 当maxSurge不为0时，该值也不能为0
  • 例如：maxUnavaible=1，则表示Kubernetes整个升级过程当中最多会有1个POD处于没法服务的状态。

而后执行命令：

$ kubectl apply -f nginx-deployment.yaml
deployment "nginx-deploy" configured

回滚部署

有时您可能想回滚部署；例如，当部署不稳定时（例如崩溃循环）。默认状况下，全部“部署”的推出历史记录都保留在系统中，以便您能够随时回滚（能够经过修改修订历史记录限制来更改它）。

注意：触发展开部署时，将建立展开的修订版。这意味着只有且仅当.spec.template更改了部署的吊舱模板（）（例如，更新模板的标签或容器映像）时，才建立新修订。其余更新（例如扩展Deployment）不会建立Deployment版本，所以咱们能够促进同时进行手动或自动扩展。这意味着，当您回滚到较早的修订版时，只会回滚Deployment的pod模板部分。

假设咱们在更新Deployment时输入了图像名称，nginx:1.91而不是nginx:1.9.1：

$ kubectl set image deployment/nginx-deployment nginx=nginx:1.91
deployment "nginx-deployment" image updated

推出将被卡住。

$ kubectl rollout status deployments nginx-deployment
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...

按Ctrl-C中止上述推出状态监视。有关卡住的卷展栏的更多信息，请参见 此处。

您还将看到旧副本（nginx-deployment-1564180365和nginx-deployment-2035384211）和新副本（nginx-deployment-3066724191）的数量均为2。

$ kubectl get rs
NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-1564180365   2         2         0       25s
nginx-deployment-2035384211   0         0         0       36s
nginx-deployment-3066724191   2         2         2       6s

查看建立的Pod，您将看到由新的ReplicaSet建立的2个Pod陷入了图像提取循环中。

$ kubectl get pods
NAME                                READY     STATUS             RESTARTS   AGE
nginx-deployment-1564180365-70iae   1/1       Running            0          25s
nginx-deployment-1564180365-jbqqo   1/1       Running            0          25s
nginx-deployment-3066724191-08mng   0/1       ImagePullBackOff   0          6s
nginx-deployment-3066724191-eocby   0/1       ImagePullBackOff   0          6s

注意： Deployment Controller将自动中止不良的部署，并将中止扩展新的ReplicaSet。这取决于maxUnavailable您指定的rollingUpdate参数（特别是）。Kubernetes默认状况下将值设置为1，spec.replicas设置为1，所以若是您不关心设置这些参数，则默认状况下您的Deployment可能不可用100％！未来的版本将在Kubernetes中修复此问题。

$ kubectl describe deployment

要解决此问题，咱们须要回滚到稳定的Deployment的先前版本。

检查部署的推出历史记录

首先，检查此部署的修订：

$ kubectl rollout history deployment/nginx-deployment
deployments "nginx-deployment"
REVISION    CHANGE-CAUSE
1           kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
2           kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
3           kubectl set image deployment/nginx-deployment nginx=nginx:1.91

由于咱们在使用建立此Deployment时记录了命令--record，因此咱们能够轻松地看到咱们在每一个修订版中所作的更改。

要进一步查看每一个修订的详细信息，请运行：

$ kubectl rollout history deployment/nginx-deployment --revision=2
deployments "nginx-deployment" revision 2
  Labels:       app=nginx
          pod-template-hash=1159050644
  Annotations:  kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
  Containers:
   nginx:
    Image:      nginx:1.9.1
    Port:       80/TCP
     QoS Tier:
        cpu:      BestEffort
        memory:   BestEffort
    Environment Variables:      <none>
  No volumes.

回滚到之前的修订

如今，咱们决定撤消当前的推出并回滚到之前的版本：

$ kubectl rollout undo deployment/nginx-deployment
deployment "nginx-deployment" rolled back

另外，您能够经过如下方式回滚到特定修订--to-revision：

$ kubectl rollout undo deployment/nginx-deployment --to-revision=2
deployment "nginx-deployment" rolled back

有关与推出相关命令的更多详细信息，请阅读kubectl rollout。

如今，部署已回滚到之前的稳定版本。

扩展部署

您可使用如下命令扩展部署：

$ kubectl scale deployment nginx-deployment --replicas=10
deployment "nginx-deployment" scaled

假设在集群中启用了水平Pod自动缩放，则能够为Deployment设置一个自动缩放器，并根据现有Pod的CPU利用率选择要运行的Pod的最小和最大数量。

$ kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80
deployment "nginx-deployment" autoscaled

比例缩放

RollingUpdate部署支持同时运行一个应用程序的多个版本。当您或自动缩放器缩放在推出期间（正在进行或已暂停）的RollingUpdate部署时，部署控制器将平衡现有活动副本集（带有Pod的副本集）中的其余副本，以下降风险。这称为比例缩放。

例如，您正在运行具备10个副本，maxSurge = 3和maxUnavailable = 2 的Deployment 。

经过按比例缩放，咱们将其余副本分布在全部副本集中。较大比例的副本将进入具备最多副本的副本集，而较低比例的副本将进入具备较少副本的副本集。任何剩余的都将被添加到具备最多副本的ReplicaSet中。副本数为零的副本集不会按比例放大。

在上面的示例中，将3个副本添加到旧的ReplicaSet中，将2个副本添加到新的ReplicaSet中。假设新副本运行情况良好，推出过程最终应将全部副本移至新的ReplicaSet。

暂停和恢复部署

您能够在触发一个或多个更新以前暂停部署，而后再恢复它。这样，您能够在暂停和恢复之间应用多个修复程序，而不会触发没必要要的部署。

经过运行如下命令来暂停：

$ kubectl rollout pause deployment/nginx-deployment
deployment "nginx-deployment" paused

而后更新部署的映像：

$ kubectl set image deploy/nginx-deployment nginx=nginx:1.9.1
deployment "nginx-deployment" image updated

请注意，没有新的部署开始：

$ kubectl rollout history deploy/nginx-deployment
deployments "nginx"
REVISION  CHANGE-CAUSE
1   <none>

$ kubectl get rs
NAME               DESIRED   CURRENT   READY     AGE
nginx-2142116321   3         3         3         2m

您能够根据须要进行任意数量的更新，例如，更新将使用的资源：

$ kubectl set resources deployment nginx -c=nginx --limits=cpu=200m,memory=512Mi
deployment "nginx" resource requirements updated

部署在暂停以前的初始状态将继续其功能，可是只要暂停部署，对部署的新更新将不会有任何效果。

最终，恢复部署并观察新的ReplicaSet以及全部新更新：

$ kubectl rollout resume deploy/nginx-deployment
deployment "nginx" resumed
$ kubectl get rs -w
NAME               DESIRED   CURRENT   READY     AGE
nginx-2142116321   2         2         2         2m
nginx-3926361531   2         2         0         6s
nginx-3926361531   2         2         1         18s
nginx-2142116321   1         2         2         2m
nginx-2142116321   1         2         2         2m
nginx-3926361531   3         2         1         18s
nginx-3926361531   3         2         1         18s
nginx-2142116321   1         1         1         2m
nginx-3926361531   3         3         1         18s
nginx-3926361531   3         3         2         19s
nginx-2142116321   0         1         1         2m
nginx-2142116321   0         1         1         2m
nginx-2142116321   0         0         0         2m
nginx-3926361531   3         3         3         20s
^C
$ kubectl get rs
NAME               DESIRED   CURRENT   READY     AGE
nginx-2142116321   0         0         0         2m
nginx-3926361531   3         3         3         28s

注意：您不能回滚已暂停的部署，直到您将其恢复。

部署状态

部署在其生命周期中会进入各类状态。它能够前进，同时推出新ReplicaSet，也能够是完整的，也能够不取得进展。

进行中的部署

Kubernetes标记的部署做为前进当执行下列任务之一：

• 部署将建立一个新的ReplicaSet。
• 部署正在扩展其最新的ReplicaSet。
• 部署正在缩减其较旧的ReplicaSet。
• 新Pod已准备就绪或可用（至少已准备好MinReadySeconds）。

您可使用监视部署的进度kubectl rollout status。

完成部署

Kubernetes 具备如下特征时，将Deployment标记为完成：

• 与Deployment关联的全部副本均已更新为您指定的最新版本，这意味着您请求的全部更新均已完成。
• 与部署关联的全部副本都可用。
• 没有运行用于部署的旧副本。

您可使用来检查部署是否已完成kubectl rollout status。若是推出成功完成，则kubectl rollout status返回零退出代码。

$ kubectl rollout status deploy/nginx-deployment
Waiting for rollout to finish: 2 of 3 updated replicas are available...
deployment "nginx" successfully rolled out
$ echo $?
0

部署失败

尝试部署其最新的ReplicaSet可能会遇到麻烦，而没有完成。这多是因为如下因素引发的：

• 配额不足
• 准备就绪探针故障
• 图像拉出错误
• 权限不足
• 极限范围
• 应用程序运行时配置错误

检测这种状况的一种方法是在“部署”规范中指定一个截止日期参数：（spec.progressDeadlineSeconds）。spec.progressDeadlineSeconds表示部署控制器在指示（处于部署状态）部署进度已中止以前等待的秒数。

如下kubectl命令设置规范progressDeadlineSeconds以使控制器在10分钟后报告部署进度不足：

$ kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'
"nginx-deployment" patched

一旦超过了最后期限，Deployment控制器就会将具备如下属性的DeploymentCondition添加到Deployment的status.conditions：

• Type=Progressing
• Status=False
• Reason=ProgressDeadlineExceeded