Deployment 声明式地升级应用
现在你已经知道如何将应用程序组件打包进容器，将他们分组到pod中，并为它们提供临时或者持久存储，将密钥或配置文件注入，并可以使pod之间互相通信。这就是微服务化：如何将一个大规模系统拆分成各个独立运行的组件。之后，你将会需要升级你的应用程序。如何升级再kubernetes集群中运行的程序，以及kubernetes如何帮助你实现真正的零停机升级过程。升级操作可以通过使用replicationController 或者 replicaSet实现，但Kubernetes提供了另一种基于ReplicaSet的资源Deployment,并支持声明式地更新应用程序。
看一个简单的例子：
现有一个应用 ，版本为V1 ,运行在Kubernetes的pod中，现在应用的镜像有更新，标记为v2,那么如何将新版本运行的pod替换掉V1版本的pod.
有以下两种方法更新pod:
1. 直接删除所有现有的pod，然后创建新pod
2. 新创建一组pod,等待运行后删除旧pod. 可以一次性创建，一次性删除，也可以一部分一部分操作。
这两种各有优缺点：第一种方法将会导致应用程序在一定的时间内不可用。第二种方法会导致新旧版本同时在线，如果对统一个数据的处理方式不一样，将会给系统带来数据损坏。
暂且不管优缺点，先来看看如何实现。
我们用replicationController来托管pod v1,可以直接通过将pod模版修改为v2,然后再删除旧pod,这时候rc就会按照新模版创建pod.
如果你可以接受短暂的服务不可用，那这是最简单更新pod的方法。
接下来我们用第二种方法。首先要保持两个版本同时在线，所以要双倍的硬件资源。
前提我们是用service来暴露pod的。保持rc v1不变，然后创建 rc v2 ,rc v2的pod模版选择新镜像标签V2. 创建rc v2 ，rc v2将运行pod v2 。等待pod v2运行正常后，我们使用 kubectl set selector 命令来修改service的pod选择器。
这种一次性从v1切到v2的方法即为蓝绿部署，主要问题就是硬件资源要两倍。如果我们不是一次切换，而是一点点切，资源将不需要两倍。比如你创建rc v2,成功后，缩容 rc v1 ，更改service的pod选择器。然后再扩容rc v2，在缩容 v1 这就是滚动更新。那么这个就要求你的应用允许存在两个不同版本，具体要根据实际需求来操作了。
以上第二种方法的两种情况，我们大概知道是怎么回事了。但我们在实际操作中，要创建两个rc,并且要修改service的pod selector. 这要是用滚动更新，pod副本越多，我们手动操作的次数就越多，手动操作越多越容易出现问题。那么问题来了，难道kubernetes没有提供自动完成这些操作的方法吗？答案是提供了。k8s中使用kubectl rolling-update kubia-v1 kubia-v2 --image=luksa/kubia:v2
我们来通过一个例子了解下：
用rc创建一个应用v1 ,并使用service的 loadbalancer将服务对外暴露。
apiVersion: v1
kind: ReplicationController
metadata:
name: kubia-v1
spec:
replicas: 3
template:
metadata:
name: kubia
labels:
app: kubia
spec:
containers:
- image: luksa/kubia:v1
name: nodejs
---
apiVersion: v1
kind: Service
metadata:
name: kubia
spec:
type: LoadBalancer
selector:
app: kubia
ports:
- port: 80
targetPort: 8080
查看loaderbalancer的IP
#kubectl get svc kubia
访问测试
# while true; do curl http://IP; done
this is v1 running in pod 主机名
接下来用v2版本升级，this is v2 running in pod 主机名
kubectl rolling-update kubia-v1 kubia-v2 --image=luksa/kubia:v2
使用 kubia v2版本应用替换运行着kubia-v1 的replicationController,将新的复制控制器命名为kubia-v2,并使用luksa/kubia:v2作为容器镜像。
kubectl 通过复制kubia-v1 的replicationController并在其pod模版中改变镜像版本。如果仔细观察控制器的标签选择器，会阿贤它也被做了修改。它不仅包含一个简单的app=kubia标签，而且还包含一个额外的deployment标签，为了由这个ReplicationController管理，pod必须具备这个标签。这也是为了避免使用新的和旧的RC来管理同一组Pod.但是即使新创建的pod添加了deployment标签，pod中还是有app=kubia标签，所以不仅新的RC要加deployment标签，旧的RC同样也要加上deployment标签，标签的值为 一个镜像hash（先这样理解）。要保证旧的RC添加deployment标签后依然可以管理之前创建的pod,因此也要修改旧pod，进行添加标签，而实际上正是在修改旧RC之前，kubectl修改了旧pod的标签：
kubectl get po --show-labels 进行查看标签
设置完成后，就开始执行更新操作了，过程就是我们上面描述的滚动更新过程。
为什么 kubectl rolling-update已经过时
我们可以在使用rolling-update命令的时候添加 --v 6 来提供日志级别，使得所有kubectl 发起的到API服务器的请求都会被输出。
你会看到一个put请求：
/api/v1/namespace/default/replicationcontrollers/kubia-v1
它是表示kubia-v1 ReplicationController资源的RESTful URL.这些请求减少了RC的副本数，这表明伸缩的请求是由kubectl 客户端执行的，而不是kubernetes master执行的。那么当kubectl执行升级时失去了网络连接，升级过程就会中断。对于中断后的结果处理起来将很麻烦。所以我们想尽量把这个过程让master负责。这就引出了DeployMent资源。
Deployment是一个高阶资源，replicationController和replicaSet都被认为是底层的概念。当创建一个Deployment时，ReplicaSet资源就会被创建，实际的pod是由Deployment的Replicaset创建和管理的，而不是由Deployment直接创建和管理的。
接下来我们创建一个简单的deployment，将上面的replicationController稍作修改：
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: kubia
spec:
replicas: 3
template:
metadata:
name: kubia
labels:
app: kubia
spec:
containers:
- image: luksa/kubia:v1
name: nodejs
因为之前RC只维护和管理了一个特定的版本的pod,并需要命名为kubia-v1,而一个deployment资源高于版本本身。可以同时管理多个版本的pod,所以在命名时不需要指定应用的版本号。
kubectl create -f kubia-deployment-v1.yaml --record
使用 --record选项会记录历史版本号，在之后操作中非常有用。
kubectl get deployment kubia
kubectl describe deployment kubia
还有一个命令，专门用于查看部署状态：
kubectl rollout status deployment kubia
查看pod，会发现使用deployment资源部署的pod名称有一定的规律，
deployment的名字 + replicaset pod模版的hash + 随机数,名称我曾怀疑是template模版的名字 + 模版的hash+随机数。经过验证发现不是，甚至可以不给模版定义name.
如：
kubia-15098375-otnsd
kubia-15098375-djc6s
而rc创建出来的名称是 ： rc名称 + 随机数
kubia-v1-kgysg
可以通过查看replicaSet来确认pod模版hash
kubectl get replicasets
kubia-15098375 ...
deployment正是根据pod模版的hash值，对给定版本的pod模版创建相同的（或使用已有的）ReplicaSet.
Deployment的高明之处
有不同的更新策略
Recreate 策略在删除旧的Pod之后才开始创建新的Pod。如果不允许多个版本共存，使用这个，但会有短暂的不可用。
RollingUpdate 策略会渐进地删除旧的pod,于此同时创建新的pod.这是deployment默认使用的策略。如果支持多个版本共存，推荐使用这个。
我们来演示下deployment滚动升级的过程。
在演示之前我们先减慢滚动升级的速度，以方便我们观察
kubectl path deployment kubia -p '{"spec": {"minReadySeconds": 10} }'
使用path对于修改单个或少量资源属性非常有用，不需要在通过编辑器编辑，使用minReadySeconds 配置正常检查后多少时间才属于正常。
注：使用patch命令更改Deployment的自有属性，并不会导致pod的任何更新，因为pod模版并没有被修改。更改其他Deployment的属性，比如所需要的副本数或部署策略，也不会触发滚动升级，现有运行中的pod也不会受影响。
触发滚动升级
kubectl set image deployment kubia nodejs=luksa/kubia:v2
执行完成后pod模版的镜像会被更改为luksa/kubia:v2
deployment的优点
使用控制器接管整个升级过程，不用担心网络中断。
仅仅更改pod模版即可。
注：如果Deployment中的pod模版引用了一个ConfigMap(或secret)，那么更改ConfigMap字眼本身将不会触发升级操作。如果真的需要修改应用程序的配置并想触发更新的话，可以通过创建一个新的ConfigMap并修改pod模版引用新的ConfigMap.
Deployment背后完成的升级过程和kubectl rolling-update命令相似。
一个新的ReplicaSet会被创建然后慢慢扩容，同时之前版本的Replicaset会慢慢缩容至0
deployment的另外一个好处是可以回滚
kubectl rollout undo deployment kubia
deployment会被回滚到上一个版本
undo命令也可以在滚动升级过程中运行，并直接停止滚动升级。在升级过程中一创建的pod会被删除并被老版本的pod替代。
显示deployment的滚动升级历史
kubectl rollout history deployment kubia
reversion change-cause
2 kubectl set image deployment kubia nodejs=luksa/kubia:v2
3 kubectl set image deployment kubia nodejs=luksa/kubia:v3
还记得创建Deployment的时候--record 参数吗？如果不给这个参数，版本历史中的Change-cause这一栏会空。这也会使用户很难辨别每次的版本做了哪些修改。
回滚到一个特定的Deployment版本
kubectl rollout undo deployment kubia --to-reversion=1
这些历史版本的replicaset都用特定的版本号保存Deployment的完整的信息，所以不应该手动删除ReplicaSet。如果删除会丢失Deployment的历史版本记录而导致无法回滚。
ReplicaSet默认保留最近的两个版本，可以通过制定Deployment的reversionHistoryLimit属性来限制历史版本数量。apps/v1beta2 版本的Deployment默认值为10.
控制滚动更新的速率
maxSurge 最多超过期望副本数多少个pod，默认为25%，可以设置为整数
maxUanavailable 最多允许期望副本数内多少个pod为不可用状态。
看图比较容易理解
暂停滚动更新：
kubectl rollout pause deployment kubia
恢复滚动更新：
kubectl rollout resume deployment kubia
阻止出错版本的滚动升级
使用minReadySeconds属性指定至少要成功运行多久之后，才能将其视为可用。在pod可用之前，滚动升级的过程不会继续。是由maxSurge属性和maxUanavailable属性决定。
例子：
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: kubia
spec:
replicas:3
minReadySeconds: 10
strategy:
rollingUpdate:
maxSurge: 1
maxUnavilable: 0
type: RollingUpdate
template:
metadata:
name: kubia
labels:
app: kubia
spec:
containers:
- image: luksa/kubia:v3
name: nodejs
readinessProbe:
periodSeconds: 1 1秒探测一次
httpGet:
path: /
port: 8080
kubectl apply -f kubia-deployment-v3-with-readinesscheck.yaml
kubectl rollout status deployment kubia
就绪探针是如何阻止出错版本的滚动升级的
首先luksa/kubia:v3镜像应用前5个应用是正常反馈，后面会500状态返回。因此pod会从service的endpoint中移除。当执行curl时，pod已经被标记为未就绪。这就解释了为什么请求不会到新的pod上了。
使用kubectl rollout status deployment kubia查看状体，发现只显示一个新副本启动，之后滚动升级便没有进行下去，因为新的pod一直处于不可用状态。即使变为就绪状态后，也至少需要保持10秒，才是真正可用。在这之前滚动升级过程将不再创建任何新的pod，因为当前maxUnavailable属性设置为0，所以不会删除任何原始的pod。如果没有定义minReadySeconds，一旦有一次就绪探针调用成功，便会认为新的pod已经处于可用状态。因此最好适当的设置minReadySeconds.另外就绪探针默认间隔为1秒。
deployment资源介绍完结。