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