创建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: # 选择器 ， 用于找到匹配的rs
matchLabels: # 按照标签匹配
app: nginx-deploy # 匹配的标签key/value
strategy: # 更新策略
rollingUpdate: # 滚动更新的配置
maxSurge: 25% # 滚动更新时，更新的个数最多可以超过期望副本数的个数或者比例
maxUnavailable: 25% # 滚动更新时，最大不可用比例，表示在所有副本数中最多可以有多少个不更新成功
type: RollingUpdate # 更新的类型 ，滚动更新
template: # pod模板
metadata: # pod的元信息
labels: # pod的标签
app: nginx-deploy
spec: # 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
恢复他的更新
可以看到他又立马开始更新了
去查看更新也同样可以看到