Deployment为Pod和ReplicaSet提供了一个声明式定义（declarative）方法，用来替代以前的ReplicationController来方便的管理应用。只需要在Deployment中描述一个期望状态，Deployment控制器以受控速率更改实际状态以达到期望状态。

本文主要Kubernetes的Deployment控制器进行简单总结。

一、环境信息

本文所使用的环境如下：

操作系统：CentOS Linux release 8.2.2004
Docker：19.03.12
kubernetes：v1.18.5

二、Deployment简介

Deployment为Pod和ReplicaSet提供声明式的更新方式。只需要在Deployment中描述一个期望状态，Deployment控制器以受控速率更改实际状态以达到期望状态。可以定义Deployment以创建新的ReplicaSet，或删除现有的Deployment并通过新的Deployment使用其所有资源。注意不要手动管理Deployment创建的ReplicaSet，否则逾越了Deployment控制器职责。下面是关于Deployment的典型用例：

创建Deployment以展开（rollout）ReplicaSet。ReplicaSet在后台创建Pod。检查ReplicaSet展开的状态，查看其是否成功。
通过更新Deployment的PodTemplateSpec字段来声明Pod的新状态。这将创建一个新的ReplicaSet，并且Deployment管理器会以受控速率将Pod从旧ReplicaSet移动到新ReplicaSet。每个新的ReplicaSet都会更新Deployment的修订历史（revision）。
如果Deployment的当前状态不稳定，支持回滚到较早的Deployment历史版本。每次回滚都会更新Deployment的修订历史（revision）。
扩容Deployment以满足更高的负载。
暂停Deployment对其PodTemplateSpec进行修改，然后恢复它以启动新的展开。
根据Deployment的状态判断展开是否卡住。
清理那些不再需要的旧的ReplicaSet。

三、创建Deployment

1.Deployment清单

可以通过以下命令查看Deployment资源清单规则：

kubectl explain deployment
kubectl explain deployment.spec
kubectl explain deployment.spec.template

也可以通过官方Kubernetes API手册进行查找。这里主要总结一下资源清单中重要的字段：

字段	类型	说明
apiVersion	string	api版本定义
kind	string	资源类型定义
metadata	object	元数据定义
spec	object	Deployment的Spec定义
spec.replicas	integer	Pod副本的期望数目，默认值为1。为可选字段
spec.selector	object	标签选择器，定义匹配Pod的标签。`spec.selector`必须匹配`spec.template.metadata.labels`，否则请求会被API拒绝。为必要字段
spec.selector.matchLabels	object	{key，value}对的映射
spec.template	object	Pod模板定义，除了它是嵌套的并且没有`apiVersion`和`kind`之外，与Pod资源清单的语法几乎完全一致。为必要字段
spec.template.metadata	object	Pod的元数据定义
spec.template.metadata.name	string	定义Pod的名称
spec.template.metadata.labels	object	定义Pod的标签，必须与`spec.selector`匹配（可以多出其他标签），否则它将被API拒绝
spec.template.spec	object	Pod的Spec定义
spec.strategy	object	指定可用于用新Pod替换旧Pod的策略
spec.strategy.type	string	指定Deployment的策略类型，可以是Recreate或RollingUpdate，RollingUpdate是默认值。当`spec.strategy.type==Recreate`时，在创建新Pod之前，所有现有的Pod都将被杀死。当`spec.strategy.type==RollingUpdate`时，Deployment会以滚动更新方式更新Pod，可以指定`maxUnavailable`和`maxSurge`来控制滚动更新过程
spec.strategy.rollingUpdate	object	滚动更新配置参数，仅在`spec.strategy.type==RollingUpdate`时生效
spec.strategy.rollingUpdate.maxSurge		指定在期望的Pod副本数的基础之上再创建的最大Pod数量。该值可以是绝对数字（例如，5）或所需Pod的百分比（例如，10％）。如果`spec.strategy.rollingUpdate.maxUnavailabl`为0，则该值不能为0。绝对数字通过四舍五入从百分比中得出的。默认值为25%。例如：当此值设置为30%时，滚动更新开始时会立即按比例扩展新的ReplicaSet，以使新旧Pod的总数不超过所需Pod的130%。一旦旧Pod被杀死，就可以进一步扩展新的ReplicaSet，以确保更新期间任何时间运行的Pod总数最多为所需Pod数的130%
spec.strategy.rollingUpdate.maxUnavailable		指定更新期间不可用的Pod的最大数量。该值可以是绝对数字（例如，5）或所需Pod的百分比（例如，10％）。绝对数字是通过四舍五入从百分比中得出的。如果`spec.strategy.rollingUpdate.maxSurge`为0，则该值不能为0。默认为25％。例如：当此值设置为30%时，滚动更新开始时会立即将旧ReplicaSet向下缩减到期望Pod的70%。新Pod准备就绪后，可以进一步向下缩减旧ReplicaSet，然后向上扩展新的ReplicaSet，确保可用的Pod总数在更新期间的任何时候都至少为期望Pod数的70%
spec.progressDeadlineSeconds	integer	在Deployment失败之前，部署进行的最长时间，以秒为单位。Deployment制器将继续处理失败的部署，并且在部署状态中将显示带有ProgressDeadlineExceeded原因的条件。在部署暂停期间不会估计进度。默认为600s。如果指定，此字段需要大于`spec.minReadySeconds`。为可选字段
spec.minReadySeconds	integer	指定新创建的Pod在没有任何容器崩溃情况下的最小就绪时间，以便将其视为可用。默认值为0（Pod在准备就绪后将立即被视为可用）。为可选字段
spec.revisionHistoryLimit	integer	指定要保留的旧ReplicaSet的数量以允许回滚。这些旧ReplicaSet消耗etcd中的资源，并占用`kubectl get rs`的输出。每个Deployment修改版的配置都存储在其ReplicaSet中，一旦删除了旧的ReplicaSet，将失去回滚到旧的Deployment版本的能力。默认值为10。将此字段设置为0意味着将清理所有具有0个Pod副本的旧ReplicaSet，这种情况下，无法撤消新的Deployment展开，因为它的修改历史被清除了。为可选字段
spec.paused	boolean	用于暂停和恢复Deployment的可选布尔字段。暂停的Deployment和未暂停的Deployment唯一的区别就是，只要暂停Deployment处于暂停状态，PodTemplateSpec的任意修改都不会触发新的展开。默认Deployment在创建时是不会被暂停的

注意：

在APIapps/v1版本中，spec.selector和.metadata.labels不会被默认设置为.spec.template.metadata.labels，如果没有设置需要明确进行设置。同时在 apps/v1版本中，Deployment创建后spec.selector是可变的。

当Pod的标签和选择器匹配时，若此类Pod的模板和spec.template不同，或者此类Pod的总数超过spec.replicas， Deployment会终止这些Pod。如果Pod总数达不到期望值，会用spec.template创建新的Pod。

不应直接通过创建另一个Deployment或创建另一个诸如ReplicaSet或ReplicationController的控制器来创建其标签与该选择器匹配的其他Pod。如果这样做，第一个Deployment会认为是它创建了这些其他的Pod。如果有多个具有重叠选择器的控制器，则控制器之间会因冲突而故障。

2.Deployment示例

创建Deployment会展开（rollout）ReplicaSet，ReplicaSet会在后台创建Pod。一个简单的Deployment示意图如下：

首先准备一个镜像，创建一个名为mynginx1的Dockerfile文件：

FROM nginx:alpine
RUN echo 'mynginx:v1' > /usr/share/nginx/html/index.html

构建mynginx:v1镜像：

docker build -t mynginx:v1 -f mynginx1 .

创建Deployment资源清单文件mynginx-deployment.yaml：

apiVersion: apps/v1
kind: Deployment
metadata:name: mynginx-deploymentlabels:app: mynginxenv: test
spec:replicas: 3selector:matchLabels:app: mynginxenv: testtemplate:metadata:labels:app: mynginxenv: testspec:containers:- name: nginximage: mynginx:v1imagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80

执行以下命令创建Deployment：

kubectl apply -f mynginx-deployment.yaml --record

注意：可以指定--record选项来写入在资源注释（annotation）kubernetes.io/change-cause中执行的命令。它对以后的检查很有用。例如，查看在每个Deployment修订历史（revision）中执行的命令。

查看Deployment展开状态，为成功状态：

kubectl rollout status deployment.v1.apps/mynginx-deployment

查看Deployment，发现Deployment已创建了所有的三个最新且可用的副本：

kubectl get deployment

Deployment的输出显示的字段解释如下：

NAME：列出名称空间中Deployment的名称。
READY：显示用户可以使用多少个应用程序副本。它遵循准备/期望的模式。
UP-TO-DATE：显示已更新以实现期望状态的副本数。
AVAILABLE：显示应用程序可供用户使用的副本数。
AGE：显示应用程序运行的时间。

查看Deployment创建的ReplicaSet，发现ReplicaSet的名称格式为[DEPLOYMENT-NAME]-[RANDOM-STRING]，其中随机字符串是以pod-template-hash为基础随机生成的：

kubectl get rs

ReplicaSet的输出显示的字段的解释如下：

NAME：列出名称空间中ReplicaSet的名称。
DESIRED：显示应用程序的期望副本数，这些副本是在创建展开时定义的，这只是期望的状态。
CURRENT：显示当前正在运行的副本数。
READY：显示用户可以使用多少个应用程序副本。
AGE：显示应用程序运行的时间。

查看每个Pod及其标签，发现创建的ReplicaSet确保总是有3个nginx的Pod存在，Pod的名字为ReplicaSet的名字加上5位随机字符：

kubectl get pod -o wide --show-labels

注意有一个名为pod-template-hash的标签，不要更改。此标签将被Deployment控制器添加到Deployment创建或使用的每个ReplicaSet中，可确保Deployment的子ReplicaSet不重复。它是通过对ReplicaSet的PodTemplate进行哈希处理并使用生成的哈希值添加到ReplicaSet选择器、Pod模板标签以及ReplicaSet可能具有的任何现有Pod中的标签而生成的。最后执行以下命令清理之前创建的资源对象：

kubectl delete all -l app=mynginx

四、更新Deployment

仅当Deployment的Pod模板即spec.template更改时，例如模板的标签或容器镜像已更新，才会触发Deployment的展开（rollout）。其他更新，如Deployment扩容，则不会触发Deployment的展开。首先准备一个mynginx:v2镜像用于更新，创建一个名为mynginx2的Dockerfile文件：

FROM nginx:alpine
RUN echo 'mynginx:v2' > /usr/share/nginx/html/index.html

构建mynginx:v2镜像：

docker build -t mynginx:v2 -f mynginx2 .

1.更新策略

Deployment控制器支持两种更新策略：

滚动更新（rollingUpdate）：在删除一部分旧版本Pod的同时，补充创建一部分新版本的Pod对象进行升级，其优势是升级期间，容器中应用提供的服务不会中断，但更新期间，不同客户端得到的相应内容可能会来自不同版本的应用。为默认更新策略。
重新创建（Recreate）：在创建新Pod之前，所有现有的Pod都将被杀死。

Deployment控制器的滚动更新并非在同一个ReplicaSet控制器对象下删除并创建Pod，会先创建一个新的ReplicaSet控制器，然后新控制器的Pod数量不断增加，旧控制器的Pod相应不断减少，直到旧控制器不再拥有Pod，而新控制器的Pod副本数量达到期望值为止。如下图所示：

滚动更新可以指定spec.strategy.rollingUpdate.maxSurge和spec.strategy.rollingUpdate.maxUnavailable来控制滚动更新过程。其功能如下：

maxSurge：指定在期望的Pod副本数的基础之上再创建的最大Pod数量。该值可以是绝对数字（例如，5）或所需Pod的百分比（例如，10％）。如果spec.strategy.rollingUpdate.maxUnavailabl为0，则该值不能为 0。绝对数字通过四舍五入从百分比中得出的。默认值为25%。
maxUnavailable：指定更新期间不可用的Pod的最大数量。该值可以是绝对数字（例如，5）或所需Pod的百分比（例如，10％）。绝对数字是通过四舍五入从百分比中得出的。如果spec.strategy.rollingUpdate.maxSurge为0，则该值不能为0。默认为25％。

2.重新创建

先创建资源清单mynginx-deploy-recreate.yaml：

apiVersion: apps/v1
kind: Deployment
metadata:name: mynginx-deploy-recreatelabels:app: mynginxenv: test
spec:replicas: 3selector:matchLabels:app: mynginxenv: teststrategy:type: Recreate  template:metadata:labels:app: mynginxenv: testspec:containers:- name: nginximage: mynginx:v1imagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80

创建Deployment并查看Deployment、ReplicaSet和Pod，然后访问其中一个Pod可知更新前使用的mynginx:v1镜像：

将Deployment的spec.template.spec.containers[0].image从mynginx:v1改为mynginx:v2：

kubectl edit deployment.v1.apps/mynginx-deploy-recreate

之后马上查看Pod的状态，由于删除得太快，这里只截到有两个旧Pod已经被删除，只剩一个旧的Pod处于正在终止状态，并且3个Pod都被删除后才开始创建新的Pod：

同时新开三个终端查看Deployment、ReplicaSet和Pod变化过程：

kubectl get deployment mynginx-deploy-recreate -w
kubectl get rs -w
kubectl get pod -o wide -w

查看Deployment和ReplicaSet：

再次查看Pod，发现旧Pod已全部被新创建的Pod取代：

查看Deployment描述信息：

然后访问其中一个Pod，发现使用了mynginx:v2镜像，说明更新成功：

最后清理之前创建的资源对象。

3.滚动更新

先通过之前的Deployment示例的清单文件mynginx-deployment.yaml创建Deployment，然后在此基础上进行滚动更新操作。在更新之前先查看Deployment、ReplicaSet和Pod，然后访问其中一个Pod可知更新前使用的mynginx:v1镜像：

下面更新nginx的Pod，可以执行以下命令更新：

kubectl --record deployment.apps/mynginx-deployment set image deployment.v1.apps/mynginx-deployment nginx=mynginx:v2

也可以使用edit将Deployment的spec.template.spec.containers[0].image从mynginx:v1改为mynginx:v2：

kubectl edit deployment.v1.apps/nginx-deployment

之后马上查看Pod的状态，可以发现旧的pod正在被终止，而一个新的ReplicaSet也在创建新的pod：

查看展开状态，新ReplicaSet已成功展开：

同时新开三个终端查看Deployment、ReplicaSet和Pod变化过程：

查看Deployment和ReplicaSet：

再次查看Pod，发现旧Pod已全部被新创建的Pod取代：

查看Deployment描述信息：

访问其中一个Pod，发现使用了mynginx:v2镜像，说明更新成功：

最后清理之前创建的资源对象。

3.Rollover

每次Deployment控制器观察新Deployment时，都会创建一个ReplicaSet以启动所期望的Pod。如果更新了Deployment ，则已存在的 ReplicaSet控制其标签spec.selector匹配但其模板与spec.template不匹配的Pod缩容。最终，新的ReplicaSet将会扩容出spec.replicas指定数目的Pod，旧的ReplicaSet会缩容到0。

如果更新了一个的已存在并正在进行中的Deployment，每次更新Deployment都会创建一个新的ReplicaSet并扩容它，同时回滚之前扩容的ReplicaSet——将它添加到旧的ReplicaSet列表中并开始缩容。例如，假设创建一个Deployment以创建5个nginx:1.7.9的副本，然后更新Deployment以创建5个 nginx:1.9.1 的副本，而此时只有3个nginx:1.7.9 的副本已创建。在这种情况下， Deployment会立即开始杀死3个nginx:1.7.9的Pod，并开始创建nginx:1.9.1的Pod。它不会等到5个nginx:1.7.9的副本都创建完成之后才改变任务。

五、回滚Deployment

默认情况下，所有Deployment历史记录都保留在系统中，以便可以随时回滚。

1.查看Deployment历史记录

首先通过资源清单文件mynginx-deployment.yaml创建Deployment，然后更新镜像为v2版。更新后的Pod信息如下：

查看Deployment修改历史：

kubectl rollout history deployment.v1.apps/mynginx-deployment

查看修改历史的详细信息：

kubectl rollout history deployment.v1.apps/mynginx-deployment --revision=2

2.回滚到上一版本

回滚到上一版本：

kubectl rollout undo deployment.v1.apps/mynginx-deployment

然后立马查看Pod：

查看Deployment和ReplicaSet：

查看Deployment描述信息：

访问其中一个Pod，发现使用了mynginx:v1镜像，说明回滚到上一版本成功：

3.回滚到指定历史版本

回滚到版本2：

kubectl rollout undo deployment.v1.apps/mynginx-deployment --to-revision=2

然后立马查看Pod：

查看Deployment和ReplicaSet：

查看Deployment描述信息：

访问其中一个Pod，发现使用了mynginx:v2镜像，说明回滚到版本2成功：

4.清理策略

在Deployment中设置spec.revisionHistoryLimit，以指定此Deployment要保留的旧ReplicaSet的数量以允许回滚，多余的ReplicaSet将在后台进行垃圾回收，默认值为10。如果显式将此字段设置为0将会清理Deployment的所有历史记录，因此Deployment将无法回滚。

六、缩放Deployment

扩容到10个副本：

kubectl scale deployment.v1.apps/mynginx-deployment --replicas=10

查看Deployment和Pod：

缩容到3个副本：

kubectl scale deployment.v1.apps/mynginx-deployment --replicas=3

查看Deployment和Pod：

如果集群中启用了HPA，可以为Deployment设置autoscale，基于现有Pod的CPU利用率进行自动缩放，当CPU利用率超过80%，Pod最多不超过15个，当CPU利用率低于80%，Pod最低不少于10个：

kubectl autoscale deployment.v1.apps/mynginx-deployment --min=10 --max=15 --cpu-percent=80

最后清理之前创建的资源对象。

七、暂停和恢复Deployment

可以在触发一个或多个更新之前暂停Deployment，然后再恢复它。这允许在Deployment暂停和恢复之间修复应用多个程序，而不会触发不必要的展开（rollout）。首先通过资源清单文件mynginx-deployment.yaml创建Deployment，然后查看Deployment和ReplicaSet信息：

执行以下命令暂停Deployment：

kubectl rollout pause deployment.v1.apps/mynginx-deployment

然后更新Deployment中Pod使用的镜像：

kubectl set image deployment.v1.apps/mynginx-deployment nginx=mynginx:v2

查看Deployment修改历史，发现没有新的展开：

可以进行任意多次更新，例如更新使用到的资源：

kubectl set resources deployment.v1.apps/mynginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi

Deployment暂停前的初始状态将继续提供它的功能，但只要暂停Deployment，对Deployment的新的更新将不会产生任何效果。最后，恢复Deployment：

kubectl rollout resume deployment.v1.apps/mynginx-deployment

查看ReplicaSet变化过程和最近展开的状态：

注意：暂停的Deployment不可回滚，除非恢复它以后。

最后清理之前创建的资源对象。

八、Deployment状态

Deployment在其生命周期中进入各种状态。当展开新的ReplicaSet时可能是Progressing状态，可能是Complete，也可能是Failed状态。下面简单总结一下这几种状态。

1.Progressing

执行以下任务之一时，Kubernetes会将Deployment标记为Progressing：

Deployment创建新的ReplicaSet。
Deployment正在扩容最新的ReplicaSet。
Deployment正在缩减旧的ReplicaSet。
新Pod已准备就绪或可用（至少在MinReadySeconds内就绪）。

可以使用kubectl rollout status监视Deployment的进度。

2.Complete

Kubernetes具有以下特征时，会将Deployment标记为Complete：

与Deployment关联的所有Pod副本都已更新为指定的最新版本，这意味着所有更新均已完成。
与Deployment关联的所有Pod副本均可用。
未运行Deployment的旧的Pod副本。

可以使用kubectl rollout status检查Deployment是否已完成。如果展开成功完成，kubectl rollout status返回退出代码0。

3.Failed

Deployment在尝试部署其最新的ReplicaSet的时候可能因为以下某些因素遇到问题，从而导致没有完成：

配额不足
就绪探测失败
镜像拉取错误
权限不足
限制范围
应用程序运行时配置错误

检测这种情况的一种方法是在Deployment的spec中指定一个截止时间参数：spec.progressDeadlineSeconds。 spec.progressDeadlineSeconds表示在Deployment失败之前，部署进行的最长时间。可以通过以下kubectl命令使用progressDeadlineSeconds设置spec，使控制器在10分钟后报告 Deployment进度不足：

kubectl patch deployment.v1.apps/mynginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'

超过截止时间后，Deployment控制器将添加具有以下属性到Deployment的status.conditions：

Type=Progressing
Status=False
Reason=ProgressDeadlineExceeded

九、蓝/绿发布（Blue/Green Deployment）

蓝/绿发布是版本2（绿）与版本1（蓝）一起发布，然后将流量从版本1切换到版本2。版本2与版本1一起部署，在新版本测试完成满足要求后，可以通过一个负载均衡器将流量发送到新版本，再删除旧版本。Kubernetes中不提供内置的蓝/绿发布，但可以通过Service或Ingress来实现，通过替换Service的标签选择器中的版本标签来将流量发送到新版本。蓝/绿发布流程如下图所示：

这里通过单个Service来实现蓝绿发布。首先创建版本1应用的资源清单文件mynginx-v1.yaml：

apiVersion: apps/v1
kind: Deployment
metadata:name: mynginx-deployment-v1labels:app: mynginx
spec:replicas: 3selector:matchLabels:app: mynginxversion: v1.0.0template:metadata:labels:app: mynginxversion: v1.0.0spec:containers:- name: nginximage: mynginx:v1imagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80
---
apiVersion: v1
kind: Service
metadata:name: mynginx-servicelabels: app: mynginx
spec:type: NodePortselector:app: mynginxversion: v1.0.0ports:- name: httpport: 88targetPort: 80nodePort: 30008

部署版本1应用，查看Pod并验证是否部署成功，成功返回mynginx:v1说明部署成功：

创建版本2的资源清单文件mynginx-v2.yaml：

apiVersion: apps/v1
kind: Deployment
metadata:name: mynginx-deployment-v2labels:app: mynginx
spec:replicas: 3selector:matchLabels:app: mynginxversion: v2.0.0template:metadata:labels:app: mynginxversion: v2.0.0spec:containers:- name: nginximage: mynginx:v2imagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80

新开一个终端查看Pod的变化过程并部署版本2应用，发现多了3个mynginx-deployment-v2开头的Pod：

待这些Pod部署成功后，再去访问当前的应用：

发现访问到的都是版本1的应用，这是因为Service中通过标签选择器匹配的是version=v1.0.0这个标签。下面修改Service的匹配标签，将流量路由到标签version=v2.0.0的Pod上：

kubectl patch service mynginx-service -p '{"spec":{"selector":{"version":"v2.0.0"}}}'

然后再去访问应用，发现现在都是版本2的信息了：

如果你需要回滚到版本1，同样只需要更改Service的匹配标签即可：

kubectl patch service mynginx-service -p '{"spec":{"selector":{"version":"v1.0.0"}}}'

如果新版本已经完全满足要求，就可以删除版本1应用。删除版本1应用并查看Pod，蓝绿发布完成：

最后清理之前创建的资源对象。

十、金丝雀发布（Canary Deployment）

需要多个标签的另一种情况是区分同一组件的不同版本或配置的Deployment。常见的做法是部署一个使用金丝雀发布来部署新版本应用（在Pod模板中通过镜像标签指定），保持新旧版本应用同时运行。这样，新版本在完全发布之前也可以接收实时的生产流量。金丝雀发布流程如下图所示：

这里使用Kubernetes原生特性来实现一个简易版的金丝雀发布。首先，创建版本1应用的资源清单mynginx-v1-canary.yaml：

apiVersion: apps/v1
kind: Deployment
metadata:name: mynginx-deployment-v1labels:app: mynginx
spec:replicas: 10selector:matchLabels:app: mynginxversion: v1.0.0template:metadata:labels:app: mynginxversion: v1.0.0spec:containers:- name: nginximage: mynginx:v1imagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80
---
apiVersion: v1
kind: Service
metadata:name: mynginx-servicelabels: app: mynginx
spec:type: NodePortselector:app: mynginxports:- name: httpport: 88targetPort: 80nodePort: 30008

部署版本1应用，查看Pod并验证是否部署成功，成功返回mynginx:v1说明部署成功：

创建版本2的资源清单文件mynginx-v2-canary.yaml：

apiVersion: apps/v1
kind: Deployment
metadata:name: mynginx-deployment-v2labels:app: mynginx
spec:replicas: 1selector:matchLabels:app: mynginxversion: v2.0.0template:metadata:labels:app: mynginxversion: v2.0.0spec:containers:- name: nginximage: mynginx:v2imagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80

新开一个终端查看Pod的变化过程并部署版本2应用，发现多了1个Pod：

然后不断访问该应用，发现大部分是版本1的信息，会有少部分是版本2的信息，说明金丝雀发布成功：

版本2的应用经测试无误后可以扩容为10个，版本1的应用则可以相应缩容为1个，再次不断访问该应用，发现大部分是版本2的信息，只有少部分是版本1的信息：

最后删除版本1应用，再次不断访问该应用，发现全是版本2的信息，最终保留的全是新版本的Pod，金丝雀发布完成：

Kubernetes控制器之Deployment相关推荐

K8S控制器之Deployment详解及配置。
目录: 一,引入Deployment 二,Deployment支持的功能三,Deployment资源清单文件详解四,滚动更新及回滚实验五,弹性伸缩实验一,引入Deployment 对于kube ...
Kubernetes控制器之ReplicaSet
ReplicaSet用来维护一组在任何时候都处于运行状态的Pod保持稳定的副本数.因此,它通常用来保证给定数量的完全相同的Pod的可用性.现在ReplicaSet基本取代了ReplicationCon ...
Pod控制器之hpa
简述 HPA全称HorizontalPodAutoscaler Pod水平自动扩缩容,Kubernetes控制器HPA是一种用于自动调整Pod数量的控制器.它可以根据资源使用情况自动增加或减少Pod的 ...
Proteus模拟STM32F103R6微控制器之串口通信USART的方法
Proteus模拟STM32F103R6微控制器之串口通信USART的方法,实验环境如下: 模拟软件:Proteus 8.11 SP0 开发环境:Keil MDK 5.33 参考资料:ST公司官方参考 ...
容器编排技术 -- Kubernetes kubectl create deployment 命令详解
容器编排技术 -- Kubernetes kubectl create deployment 命令详解 1 kubectl create deployment 2 语法 3 示例 4 Flags ku ...
kubernetes对象之deployment
系列目录简述 Deployment为Pod和ReplicaSet提供了一个声明式定义(declarative)方法,用来替代以前的ReplicationController来方便的管理应用.典型的应 ...
Kubernetes学习之Deployment控制器
一.认识Deployment控制器 Deployment控制器为Pod和Replica Set控制器提供声明式的更新:你只需要在Deployment中描述你想要的目标状态是什么,Deployment ...
k8s(Kubernetes)中Pod,Deployment,ReplicaSet,Service之间关系分析
看完k8s文档,好多概念似乎明白了,又似乎不明白,多个概念之间的关系也很混乱,不是很明白,不要紧,接下来,好好分析一下. 结论您有可能在急着找答案搜到我这篇文章,不费话,结论就在开头,请看下图. d ...
3.1 控制器之ReplicaSet/ReplicationController
文章目录 ReplicaSet使用 1.创建ReplicaSet 2.删除一个pod 3.修改pod标签 4.标签选择器 4.修改ReplicaSet标签选择器 5.水平缩放pod 6.删除Repli ...

Kubernetes控制器之Deployment