编者注：这是Kubernetes1.2新功能深度介绍系列的第7篇帖子。
Kubernetes令部署应用、管理应用变得简单直白，令大多数操作简化为单个API或单个命令行，包括发布新的应用程序，canary测试和升级。那么为什么我们还需要部署呢？
自动化Deployment和滚动更新程序。相比于kubectl滚动更新，Deployment API更加快速，具有描述性，实现服务端，还有更多的功能（比如，即使是在滚动更新完成之后，你也可以回滚到之前的版本，）。
在今天的博客中，我们介绍的内容包括如何使用Deployment来：
配置／推出一个新的应用程序
阶段性更新应用程序，中途没有服务中断
如果在你部署／更新应用的时候出现错误，你可以回滚到之前的版本。
让我们来尝试使用一下Deployment吧～
准备开始
如果你想要试用下面这个例子，基本上需要满足以下三个要求：
一个正在运行的kubernetes集群：如果你现在还没有创建过集群的话，查看教程：，里面有各种平台上的部署方案，包括你的笔记本，虚拟机，裸机服务器等等。
Kubectl，Kubernetes CLI：如果在运行kubectl cluster-info之后，看到了一个URL回应，那么就准备启动吧。否则的话，就按照指示安装配置kubectl；如果你有谷歌 GCE集群的话，也可以按照主机解决方案（）的指示来安装。
这个demo的配置文件，可以点击：
如果不想自己动手运行这个例子，那也可以。看这个视频了解每一步的细节。
开始
配置文件包括一个静态页面。首先，我们想要开始为它的静态内容服务。从Kubernetes repository的root开始，运行：
这个在8001端口运行了一个proxy。你现在可以访问： ，就是demo网页版（它现在登录进去显示出来的是一个空白页面）。现在我们想要运行一个应用，并且将它展示到网页上。
这些代码用“update－demo：nautilus”部署了一个应用的副本，你可以点击这里观看：
网页上展示的卡片代表的是：一个Kubernetes pod，pod的名称（ID），状态，镜像和标签。
数量变大
现在我们想要更多这个应用的复制件！
更新你的应用程序
更新应用会怎么样呢？
此代码打开了你的默认编辑器，然后你可以在fly上面更新配置。找到.spec.template.spec.containers[0].image，然后修改nautilus到kitty，然后你会看到：
此代码打开了你的默认编辑器，然后你可以在fly上面更新配置。找到.spec.template.spec.containers[0].image，然后修改nautilus到kitty，然后你会看到：
过一会儿，你就会发现更新似乎被绊住了。发生了什么呢？
调试rollout
如果你看的再仔细一点，你会发现那些带有“Kitty”标记的镜像仍处于待定状态。一旦运行失败，Deployment会自动停止roll。让我们来看一看新的pod上发生了什么：
看一下这个pod的events，你会注意到Kubernetes由于找不到“kitty”而无法pull镜像：
回滚
好的，现在我们想要撤销做出的修改，然后花时间理清楚我们应该使用哪个镜像标签。
所有东西都恢复到正常，耶！
为了学习更多的关于回滚的知识，访问：。
更新你的应用程序
之后，我们终于找出正确的镜像标签是“kitten”，而不是“Kitty”。现在将.spec.template.spec.containers[0].的镜像标签从“nautilus”改到“kitten”。
现在在demo网站上可以看到有4只小猫，这也就意味着我们已经成功地更新了应用！如果想要了解这背后的镜像，来看这个的Deployment吧：
从events章节可以看到配置正在管理另一个叫做Replica Set的资源，每一个都管理不同pod模版的副本的数字。
结论
现在，你已经了解了Deployment对象的基本用法：
部署有Deployment的应用，使用kubectl来运行
通过更新Deployment来更新应用，用kubectl编辑
回滚到之前部署的应用，用Kubectl rollout撤销
但是还有很多Deployment里的东西，在这里篇幅有限，无法详述。为了探究更多，点击这里了解更多：
注意：在Kubernetes1.2中，Deployment（测试版）功能完善，是默认启用的版本。你们之中试用过Kubernetes1.1中的Deployment的人，在Kubernetes1.2上尝试Deployment之前请删除所有的Deployment1.1资源（包括他们管理的RC和pods）。这个步骤很有必要，因为我们对API作了一些反向不兼容的修改。获取更多信息，请点击：点我
（如果需要转载，请联系我们哦，尊重知识产权人人有责）