k8s之Deployment 声明式地升级应用(五)

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资源介绍完结。

 

posted @ 2019-10-22 14:42  zhming  阅读(1203)  评论(0编辑  收藏