Linux：kubernetes（k8s）Deployment的操作（13）

创建deployment

命令 

kubectl create deploy nginx-deploy --image=nginx:1.7.9

再去使用以下命令分别查询

ubectl get deploy

kubectl get replicaset

kubectl get pod

他是一个层层嵌套的一个关系

首先是创建了一个 deploy  里面包含着replicaset  replicaset里面含有一个pod

---

yaml文件 

我们刚刚通过命令去创建了一个peployment，我们可以直接通过，命令去获取他的yaml，直接利用上

kubectl get deploy nginx-deploy -o yaml

nginx-deploy是刚刚创建的deploy名称

会立马输出出来一段yaml配置文件这里的文件我们不全都要只取一部分

就是我截图的这一部分，下面还有，那些就不要了，再去创建一个yaml文件放进去，我这里的名字为nginx-deploy

下面这些是经过精简的yaml文件 

apiVersion: apps/v1 # deployment api版本
kind: Deployment    # 资源类型为deployment 
metadata:           # 元信息labels:           #标签app: nginx-deploy   # 具体的key:value配置形式name: nginx-deploy    # deployment的名字namespace: default    # 所在的命名空间
spec:replicas: 1   # 期望副本数revisionHistoryLimit: 10       # 进行回滚更新后，保留历史版本数selector:     # 选择器 ， 用于找到匹配的rsmatchLabels:        # 按照标签匹配app: nginx-deploy # 匹配的标签key/valuestrategy:             # 更新策略rollingUpdate:      # 滚动更新的配置maxSurge: 25%     # 滚动更新时，更新的个数最多可以超过期望副本数的个数或者比例maxUnavailable: 25%       # 滚动更新时，最大不可用比例，表示在所有副本数中最多可以有多少个不更新成功type: RollingUpdate # 更新的类型 ，滚动更新template:     # pod模板metadata:   # pod的元信息labels:   # pod的标签app: nginx-deployspec:       # pod的期望信息containers:       # pod的容器- image: nginx:1.7.9      # 镜像imagePullPolicy: IfNotPresent   # 拉取策略name: nginx     # 容器名称restartPolicy: Always     # 重启策略terminationGracePeriodSeconds: 30  # 删除操作最多宽限时间
~                                                                   

这些就是创建的一个文件，下面留着用

---

滚动更新

修改了deployment文件中的template中的属性后，才触发了更新操作

现在可以看到我们当前部署的信息就这一个

由于我们刚刚创建的deploy是通过命令创建的所以我们在本地的文件里改是不会有任何效果的 

直接使用命令进入deploy 修改

我先在这添加了一个标签test：‘123’ 后再去查看deploy

发现并没有什么变化，但是标签确实是给我们加上了，因为他的ready一直是1并没有滚动创建副本的一个变化

在详细信息里也是确确实实没有显示

在滚动更新之前我先去修改一下他的副本数，这样可以更佳清楚的看到滚动更新的效果

可以看到他的副本数是1 我直接给他改成3 

让后再去get一下

可以看到他后面是变成3/3了但是他还是一个deploy

rs也同样是1个

 但是pod变成了3个，而且标签还都是用的一个

现在开始展示滚动更新 ，再去deploy里面进行一个配置

kubectl edit deploy nginx-deploy

把1.7.9改成1.9.1

 这时我们快速的去查看

可以到ready一直是3最后就成功的全部滚动更新完毕

其实在滚动更新的时候还可以使用命令去进行查看

现在我们开启两个ssh窗口，一个用于更新一个用于查看 

kubectl set image deployment/nginx-deploy nginx=nginx:1.7.9

 这个命令就相当于我们进去修改把镜像1.9.1又改回1.7.9一样

在更新时候使用命令

kubectl rollout status deploy nginx-deploy

就可以看到当前滚动情况

kubectl describe deploy nginx-deploy

 也是可以看到滚动更新的情况

可以看到他是开启一个关闭一个开启一个关闭一个

rs也是从原来的rs中更新到了另一个rs中        

---

 回滚

假如说当我们要去进行滚动更新的时候，把版本本来要写1.9.1但是误写成1.91这时候看看怎么办

kubectl set image deployment/nginx-deploy nginx=nginx:1.91

开始更新

kubectl rollout status deploy nginx-deploy

再去查看一下，让后就会一直卡住，因为版本号不对所以他一直卡住

发现下面rs一直是1 还可以看到pod也报错了

kubectl describe pod nginx-deploy

这里可以看到详细的一个信息了

我们可以通过

kubectl rollout history deployment/nginx-deploy

去查看一个系统版本更新的历史记录

因为在更新的时候没有加--record后面加描述

我们可以通过他前面的数进行回滚

kubectl rollout history deployment/nginx-deploy --revision=3

 

可以看那次的信息

 kubectl rollout undo deployment/nginx-deploy

这个是回滚到上一次 

kubectl rollout undo deployment/nginx-deploy --to-revision=2

回滚到指定的那次 

 现在回退完了再使用edit进行查看一下

可以看到又回到1.9.1了

可以通过设置 .spec.revisonHistoryLimit 来指定 deployment 保留多少 revison，如果设置为 0，则不允许 deployment 回退了 

---

扩容和缩容

假如我的服务器在某一时间段，突然需要大量访问，而过了这个时间访问量会急剧缩减

在访问量大的时候，我们可以去做一个副本个数的修改，我们每次都要去edit修改，副本的修改非常常用，总不可能每次都去修改，当我们真正需要去扩容缩容的时候我们应该更方便，越方便越好，所以我们就用这个扩容和缩容去快速实现

通过 kube scale 命令可以进行自动扩容/缩容，以及通过 kube edit 编辑 replcas 也可以实现扩容/缩容

 扩容与缩容只是直接创建副本数，没有更新 pod template 因此不会创建新的 rs

可以看到当前我们是这样的 

kubectl scale --replicas=6 deploy nginx-deploy

 我直接给他扩容到6个

可以发现pod是6了但是rs还是没有变化

缩容也是一样的，直接把6改成3就立马缩回来了

kubectl scale --replicas=3 deploy nginx-deploy

直接就搞定了

---

暂停与恢复

由于每次对 pod template 中的信息发生修改后，都会触发更新 deployment 操作，那么此时如果频繁修改信息，就会产生多次更新，而实际上只需要执行最后一次更新即可，当出现此类情况时我们就可以暂停 deployment 的 rollout

 我现在直接对我的模板去edit编辑一下

kubectl edit deploy nginx-deploy

在里面添加了这么一段然后直接保存退出

他接着就会自动进行更新了，这个是没有暂停的情况，现在直接将他暂停更新

kubectl rollout pause deploy nginx-deploy

直接就暂停了，接下来我再去进行修改

我新加了一个limits

再保存退出

可以发现他并没有去更新，再去看一下他的历史更新记录

可以看到他最后一次更新是更新requests的内容，哪怕是把他的镜像版本再改回1.7.9他也是不会更新的

kubectl rollout resume deploy nginx-deploy

恢复他的更新

可以看到他又立马开始更新了

去查看更新也同样可以看到